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
