[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Alert about several medical imaging packages (Was: insighttoolkit4 is marked for autoremoval from testing)



Hi Steve,

thanks a lot for your helpful update.  Some remarks from my (totally
uneducated about medical imaging) view:

On Tue, Aug 04, 2015 at 07:25:55AM -0500, Steve M. Robbins wrote:
> On August 2, 2015 07:13:09 AM Andreas Tille wrote:
> > Hi,
> > 
> > you might have noticed that we have gathered several gcc-5 related bugs.
> > The situation in several medical imaging packages is specifically hard
> > since it is a longer chain of dependencies and these seem to be
> > specifically hard to solve.  
> 
> Hi Andreas,
> 
> I appreciate your concern about these packages and raising the alarm is 
> probably useful.  To avoid the appearance that nothing is happening, I suppose 
> it would be useful to report on my activities and plans.
> 
> CastXml: is now in sid and testing, building on all architectures.

Thanks for this.
 
> ITK: I have gotten latest version (4.8.0) into VCS as reported [1].  With help 
> from Paul Novotny and Gert Wollny two of the issues in [1] are solved and I've 
> been making progress with the last, which is to tweak the CMake flags.  I was 
> also intentionally delaying the upload until after the GCC switch (now 
> complete) so that we don't have to change the SONAME artificially. 

Sounds sensible.  I think its not only gcc-5 but also libc++6 switch.
 
> Gccxml: I have taken your idea of a compatibility wrapper around castxml, 
> implemented the suggestions of Brad King [2] and am in the process of testing 
> it with all the packages that build using gccxml.  

Cool.  This might hopefully enable us to simplify the porting of other
packages.
 
> mummy and activiz.net: I have not looked in detail at either, yet.  However, I 
> have recently used both -- and debugged both -- in my paid employment.  So I 
> have a reasonable idea of how they work.  The released activiz.net does not 
> work with recent VTK, but Corentin Desfarges reports [3] that the git repo has 
> updates.  So my expectation is that we'd have to package the latest git 
> version.  

I'd also recommend this.  I would *really* love if somebody could
convince upstream to use some proper tagging to enable us noticing what
they consider a stable release.  As far as I know previous attempts to
contact them were ignored. :-(
 
> Above is roughly the order in which I plan to work on things.  My progress is 
> admittedly slow.  Some of the above may well get removed temporarily from 
> testing, but I believe we can eventually get back the ones we need.  Some may 
> be permanently removed; e.g. in my view, ITK v3 is old enough that I propose 
> we allow it to be removed.

+1
As far as I can see it would drain our time we need to push ITK v4.

> I'd also like to remove cableswig because it was 
> mainly used in pre-castxml days for ITK, but presently mummy needs it to.  I'm 
> hoping that upstream mummy would update to remove this usage.

When I recently looked mummy locked unmaintained and not updated in VCS
but I might be wrong.
 
> In the short term, my goals are:
> 
> ITK:
>  1. Check the build with gcc 5 on all architectures.
>  2. Enable more of the system libs, ensuring they build on all architectures.
>  3. Review the list of modules to see if we need more enabled.
>  4. Upload.
> 
> Gccxml:
>  1. Check the list of dependent packages [4] build with the script
>  2. Upload.
> 
> If you can help with any of the above, get in touch!

Thanks a lot for taking over the ball.  Unfortunately I feel on one hand
incompetent and on the other hand my time for full time Debian work has
ended now (and my backlog at payed work is huge).

Kind regards

     Andreas.
 
> [1] https://lists.debian.org/debian-med/2015/07/msg00152.html
> [2] http://public.kitware.com/pipermail/castxml/2015-July/000014.html
> [3] https://lists.debian.org/debian-med/2015/07/msg00055.html
> [4] Packages that build-depend on gccxml:
> activiz.net
> cableswig
> gdcm
> mummy
> pygccxml
> pyplusplus
> python-ctypeslib
> spring   



-- 
http://fam-tille.de


Reply to: