Re: Progress on Debian Package for FSL
On Thu, 12 Jan 2006, Michael Hanke wrote:
Some of the problems are solved now, but others remain. First for the
solved ones: ...
Great!
And now for the remaining problems. There is still no official package
for 'newmat'. Although there has been a RFS lately:
http://lists.debian.org/debian-mentors/2006/01/msg00047.html
I also made an unofficial package of 'newmat', because the above
packaging attempt did not work with FSL due to some differences in the
build configuration. I asked the maintainer for the appropriate changes.
If this is done so I can add this package to the build-dependencies of
the FSL package.
If it is in your (=Debian-Med's) interest I would volunteer to sponsor
a newmat package provided that it fits your needs. So if a missing
sponsor for newmat would be the final show stopper for FSL just come
back to me.
I was not able to use the Debian version of libgdchart. Neither did
compiling FSL worked nor was I able to locate the problem.
Can you specify the problem more detailed? I have no experiences with
libgdchart, but dicussing the problem on debian-devel is very often
helpful.
The last remaining library is CEPHES. There is still no package. But as
I do not know of any other application that uses this lib, it might be
ok to keep this one compiled from the FSL source code.
Well, this depends (as always). If you ask me issuing a RFP or rather
ITP and packaging it from a clean upstream source would be the
clean way to go (TM). If this does not fit your time frame we could
find the intermediate solution to build it from the FSL source code.
But in this case I would strictly vote for building a separate package
for this library if possible in any way.
I think I cannot do anything against the 'csh-considered-harmful'-thing
as most scripts in the FSL package are csh scripts.
Please checke whether they are *really* csh scripts or whether they are
normal POSIX compliant scripts that just start by "#!/bin/sh". I had
faced some cases in the past where a simple "s#/bin/csh#/bin/sh#" was
enough.
The 'shell-script-fails-syntax-check' is in a way of the same nature. All
mentioned scripts start like this:
------------
#!/bin/sh
# Check for display being set \
if [ _`uname | grep CYGWIN` = _ -a _$DISPLAY = _ ] ; then echo "DISPLAY
is not set. Please set your DISPLAY environment variable!" ; exit 1 ; fi
# the next line restarts using wish \
if [ _$FSLWISH = _ ] ; then echo "You need to source an FSL setup file -
either fsl.sh or fsl.csh in \$FSLDIR/etc/fslconf !" ; exit 1 ; else exec
$FSLWISH "$0" -- "$@" ; fi
....
-------------
But the problem seems to be somewhere else because if I check this code
using bash -n this works. Have you tried a bash -n on the scripts?
One last open issue is that upstream still does not version the source
tarballs. That's why the orig tarballs cannot be verified reliably, as
there might be (and have been) sudden changes to the sources without any
increment in the version number. I reported the problem to upstream,
but there was no response yet.
That's really sad, but I know this situation. The recommended way is
to make a version number from the file date of the tarball. Thus if
you downloaded a tarball that has a time stamp from today the version
number would be
0.0.20060112 ( 0.0.YYYYMMDD )
Rationale: The leading zeros are useful if upstream finally starts
a real version numbering starting by for instance 0.1. The numbering
scheme above guarantees that this version number is higher than your
previous version numbers.
There is a source package available for inspection. This package
currently build-depends on my newmat package (see above). Both packages are
available from here:
I have currently no time to verify the sources but I hope the hints
are helpful anyway.
Many thanks for your work
Andreas.
--
http://fam-tille.de
Reply to: