[MINC-development] minc 2.0.14 issues

[Andrew Janke]

> Just to let you know, I've recently uploaded MINC 2.0.14 to Debian.
> There's an active project to get all kinds of medical imaging software
> into Debian; see http://wiki.debian.org/DebianMedImaging.  FSL is in,
> and there is interest in AFNI, Caret, and FreeSurfer.  Since the
> latter is built on MINC, work was started on a number of BIC packages,
> including mni_autoreg and N3.

I presume you are talking about Michael Hanke here. I have been in
contact with him a few times about this and the plan is to join build
forces. He is apparently busy until feb though so I was happy to leave
it until them.  I dont think there is a ITP for them yet though?

> Since Andrew says 2.0.15 is imminent, I thought I'd share a couple of
> issues that have come up, in case you're not closely following the
> Debian packaging effort (http://packages.qa.debian.org/m/minc.html).

> 1. The 2.0.14 upload failed to build on Arm and on Sparc.  See
> http://buildd.debian.org/build.php?pkg=minc for build logs.  The
> failures are in test cases in libsrc2/test.  I will poke around, but
> if you have any hints for me: I'm all ears.

I am more than keen to get things right upstream.  I note there are a
number of patches in the deb build. I presume you will commit these
upstream also?  I have been also working on removing all instances of
(t)csh in MINC in order to make things work nice on OSX/etc. This
should clean up at least one dependency.  I suspect i will convert
mincview to perl as opposed to sh given the lack of ARRAY variables
unless you resort to bash.  mincview should in any case be not much
more than a wrapper around mincpik with a bit more work on mincpik to
get it to output a range of images slices.

> 2. I built MINC using --enable-acr-nema for the first time, and
> discovered that it produces a program named "extract" that simply
> extracts bytes from the middle of the input.  Unfortunately, this name
> clashes with a pre-existing software package that has more claim to
> the name (http://bugs.debian.org/459834).  Fortunately, it looks to me
> like MINC's extract can be replaced by "dd".  So I plan to solve this
> by removing "extract" from Debian's package.  The same goes for
> byte_swap.  Maybe they can be removed completely?  Is anyone really
> using these tools (and can't switch to using dd)?

I would go further than this.  I see no reason as to why acr-nema
should be a library. Berts intention here probably was noble but
no-one else that I know of would use it that I can think of when there
are things like dc3tools from david clunie.  My suggestion would be to
mod the build process so that the library is not built at all.  As for
extract there is no reason as to why it should not be dd.

byte_swap is a little more interesting though, there was at one stage
a byte_swap4 and a byte_swap8 I have no idea if these still exist as
these are a tad more difficult to implement with dd.


a