Re: ITK packaging (Was: OTB)

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

Hello all, 

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.  

> Currently insighttoolkit4 is maintained in Debian Med SVN by Steve 
> and Gert.  I guess both have no problem to move to Git if needed. 

With me that's okay, one of the reasons I didn't do this so far is that
ITK is a rather large source package and there is also en extra data
tarball for the tests, and I would not know how to integrate the latter
into the git work-flow. 


> You are kindly invited to work on the packaging for sure if you have
> some enhancements and I could easily add you to the Debian Med team.
+1


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
 
#805933  FTBFS on recent systems
- probably a fluke, If the current build works I will close it. 
  
#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. 
  
#801367  please reduce the size of the swig generated translation units
- No idea how to tackle this 
  
#724711 insighttoolkit4: Drops architecture support
- upstream, quite a few tests fail on e.g. powerpc and armhf 

#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).

#808491 Most likely a problem in GDCM which is already fixed since
yesterday - Currently building to see if that is true. 


Best,
Gert