Re: ITK packaging (Was: OTB)

[Gert Wollny <gw.fossdev@gmail.com>]

Hello Sebastiaan, 

[...]
> > #805933  FTBFS on recent systems
> > - probably a fluke, If the current build works I will close it. 
> 
> I'm not so sure it's a fluke, this issue affected the buildd builds 
> of ITK4, and my local build in an up-to-date sid chroot had the same
> test failures.
> 
> Fixing these test failures to allow the amd64 & i386 builds to 
> succeed again is the biggest issue affecting OTB. It will prevent 
> testing migration otherwise.
> 
> #808491 is a duplicate of this issue.

Unlikely, #805933 is reported against gdcm-2.4, #808491 fails because
of a regression introduced with gdcm-2.6, or at least that's what gdcm
upstream (Mathieu) thinks (The fixed version is already in the
archives).


> > #801367  please reduce the size of the swig generated translation
> > units
> > - No idea how to tackle this 
> 
> I'd start by forwarding the issue upstream, and request feedback from
> the ITK developers.
The problem is that these compile units are generated completely
automatically by castxml + swig. The only option I see is to reduce the
number of supported data types and dimensions in wrapping. 

> > #724711 insighttoolkit4: Drops architecture support
> > - upstream, quite a few tests fail on e.g. powerpc and armhf 
> 
> This is relevant for OTB, because ITK4 limits the architectures to 
> amd64 & i386. It should be available on all the modern release
> architectures at least (specifically arm*). 
Actually, I tested to compile on armhf and their some tests fail. 

> s390x and powerpc should also be more than powerful enough for
> insighttoolkit4, but I suspect insighttoolkit4 doesn't support big
> endian architectures.
I seem to remember that I read somewhere that it's actually GDCM that
does fail here, but it doesn't provide the corresponding tests itself. 
I recently did a build on an 32bit powerpc laptop and GDCM tests are
amongst those which fail (but pass on armhf). 

> When upstream developers are unwilling or unstable to fix 
> architecture specific test failures, I choose to ignore the test 
> failures instead of excluding the architecture entirely.
Well, failing tests means the software is broken, IMHO one should then
not disable only the tests but the features that do not work. 

As for upstream, they are quite responsive, but when it comes to such
specifics they usually point to the option to set up a build-server
that sends the build results to their dashboard (as did Matt McCormick
[1]) which gives them the required information to fix these issues. 

I can't do this, because my powerpc hardware is a G4 based laptop that
takes >24 hours to compile ITK (without language bindings) and my armhf
device is a Utilite mini PC also has barely enough disk space to
compile ITK. 

> The FTBFS with the new GDCM is the most important blocker for OTB
> currently.
We'll see tomorrow whether this persists. 

Best, 
Gert 

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724711#36