Bug#911793: Control: reassign -1 src:gdcm 2.8.7-2

[Mattia Rizzolo]

Hi,

so, if you don't particularly mind, I'm happy to just take the least and
fix all the involved packages here, so src:vtk7 and src:gdcm (and
rebuilding fw4spl).  At the very least, I'm going to rename
libvtkgdcm2.8 to something else; thinking about libvtkgdcm2.8a
(libvtk7gdcm2.8 would be somewhat against policy, as it wouldn't match
the SONAME anymore, and I don't really like to change a library's SONAME
without coordingation with upstream).


On Fri, Nov 23, 2018 at 04:30:16PM +0100, Emmanuel Promayon wrote:
> So I suppose the problem is in vtk7

nah, that's just an unrelated breakage for which a patch is even already
available..

> 1) gdcm 2.8.7-2 moved to python3 (probably because a move from python2 to
> python3 was required) which I think triggered the choice of moving from vtk6
> to vtk7 (which probably made more sense, as I presume vtk6 is also on its
> way out of buster).

My gut feeling is that the culprit is more the vtk6→vtk7 change rathe
than the py2→py3, but it's not relevant.

> 2) When gdcm 2.8.7-2 arrived in sid, it generated a SegFaults during  camitk
> 4.1.2-1 as camitk 4.1.2-1 was still based on vtk6, and loading any camitk
> executable meant that both vtk6 and vtk7 were loaded in memory.

I'd hope the "both vtk6 and vtk7 were loaded in memory" is not so
relevant... after all they are different libraries, they shouldn't mess
with each other that much (there chances of it, but…).

> 4) gdcm 2.8.7-5 then fixed the double dependency to vtk6 and vtk7 but camitk
> 4.1.2-2 was not rebuilt against it, therefore generating the initial error
> that triggered bug #911793

the camitk that is currently in unstable is built against gdcm 2.8.7-5,
which should have been a fine version.  So does camitk really segfault
with the current libvtkgdcm2.8?

> 5) vtk7 (which was updated in the meantime) seems to have now some missing
> libraries and as hdf5 is broken as well camitk 4.1.2-2 can not be rebuilt
> yet

It needs a rebuild against hdf5, blocked by
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914347 but a patch is
already available, so..

> On a side discussion:
> Does the fact that I moved the dependency of camitk from vtk6 in 4.1.2-1 to
> vtk7 in 4.1.2-2 might generate another ABI break? If this is the case, I
> will take any advice regarding how to specify this properly!

I will check this out.

> I will also welcome any information/documentation about how to track the
> symbol.

TBH, I got kinda tired at writing stuff about how to properly deal with
symbols every now and then, so I'll probably just go ahead and commit
something.


Gert: you mention you gave up on symbols, but at least in gdcm's
changelog I don't see anything about that.  Had you had troubles there
as well?


What I would welcome your help with is explaining the camitk FTBFS on
i386.

-- 
regards,
                        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540      .''`.
more about me:  https://mapreri.org                             : :'  :
Launchpad user: https://launchpad.net/~mapreri                  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/debian-science-maintainers/attachments/20181123/dd91c286/attachment-0001.sig>