Hi everyone,
Furthermore I would like to mention another page[3] with lots of information about Debian Med packages. Besides the list of RC bugs you can also see packages that can not be built on a Debian architecture, packages that are not allowed to migrate from unstable to testing (and thus won't be included in the next release) and packages with a new upstream version. I think those packages need some care as well.+1
I am trying to understand the mechanism of the "excuses" given for the package CamiTK that is in the list of blocked packages in [1]. As I am a very inexperienced in debian packaging, I am not sure what action can be taken. In the great page [2], the excuses for CamiTK point to a problem with insightoolkit, which itself mention gdcm which now mention not yet built on sparc and ia64 (which I suppose are the show stoppers). But a while ago gdcm excuses were about the fact gdcm was part of a transition (itself mentioning mono or something).
What can be done concretely to fix this problem?If there is anything in my reach, I will try to help (might not be for the advent calendar, but maybe for the spring cleaning!).
Another question, may be more addressed to the itk/vtk/gdcm specialists:is it time to switch the dependencies from insighttoolkit to insighttoolkit4?
And as Andreas always encouraged me to ask question even if they looked silly, here it is: More generally, where can I see what lib version are deprecated or which version is advocated in Jessie/next stable?
For instance the CamiTK package depends on huge libs such as qt, vtk, insighttoolkit and gdcm. When is the best time to try a transition to Qt5, Vtk6, itk4 and gdcm2.4?
Kind regards and thanks for all the efforts, Mahnu[1] http://udd.debian.org/dmd.cgi?email=debian-med-packaging@lists.alioth.debian.org
[2] http://release.debian.org/migration/testing.pl?package=camitk
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature