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 `-
signature.asc
Description: PGP signature
