Hi Gert, On 22-12-15 12:10, Gert Wollny wrote: > On Tue, 2015-12-22 at 09:55 +0100, Andreas Tille wrote: > >> On Sat, Dec 19, 2015 at 02:59:52PM +0100, Rashad Kanavath wrote: >>> How do we fix itk packaging? Is it possible to move it to DebianGIS >>> ?. I am okay to provide help to resolve the current bugs. But I >>> need to check this if it possible for me to pass more time on itk >>> packaging. > > Currently, I'm building against the latest dcmtk and gdcm, so I would > suggest no to touch the package until I tell you that the new version > is uploaded or failed to build. I will know by tomorrow morning.
Agreed. Before anyone else starts work on insighttoolkit4 they should be aware of its large disk space and build time requirements. If you thought the build time for OTB was bad, ITK4 is much worse. > I would be interested to know what are specific bugs you'd like to > resolve. > > we have: > #686402 kfreebsd-kernel-headers: several headers assume _BSD_SOURCE > - no idea kfreebsd-amd64 & kfreebsd-i386 are not release architectures any more, so this would just be nice to have. > #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. > #733629 Convenient lib: double-conversion > - In the works, i.e. I sent a patch upstream and they will probably > include it in the next (4.9) release. It changes the ABI, that's why I > didn't include it in the current version. Probably not relevant for OTB. > #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. > #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*). s390x and powerpc should also be more than powerful enough for insighttoolkit4, but I suspect insighttoolkit4 doesn't support big endian architectures. 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. In the Debian GIS team we had to exclude the mips* architectures for mapnik because the buildds were simply unable to build it successfully due to the large memory and address space requirements. It's our most demanding package to build. > #759794 insighttoolkit4: FTBFS on amd64 with ENOSPC > - currently not a problem anymore, because the build daemons are now > configured with enough space, but this is only sufficient for one > language binding (currently we have python). It's not a direct blocker for OTB, but it does show that insighttoolkit4 is so large that it's common for even powerful architecture to not meet its requirements. I expect more issues like this to hinder OTB packaging in the future due to testing autoremoval or blocking of testing migration. Because new builds cannot be done quickly, this raises the barrier for others to contribute fixes. > #808491 Most likely a problem in GDCM which is already fixed since > yesterday - Currently building to see if that is true. As mentioned above this is a duplicate of #805933. The FTBFS with the new GDCM is the most important blocker for OTB currently. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
