Re: ITK packaging (Was: OTB)

[Sebastiaan Couwenberg <sebastic@xs4all.nl>]

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