[Debian-med-packaging] Bug#909120: camitk FTBFS: tests segfault (Bug #909120)

[Emmanuel Promayon]

Hello all

Thanks again to Andreas and Bernhard. You are right: the problem comes 
from gdcm 2.8.7-2.

I tried to build the package with the previous version of vtkgdcm. With 
version 2.8.7-1 all the tests pass and the packages are built normally 
(and autopkgtest does not fail either).

If I understood well (let me know otherwise), the history of this bug 
goes like this:
- the gdcm package was updated to support python3
- in the process, the dependency of gdcm was updated from vtk6 to vtk7 
(see this commit [1], which took effect in gdcm 2.8.7-2)
- one extension (i.e., plugin) of CamiTK requires gdcm to read DICOM 
images. During the first build after gdcm 2.8.7-2 was available on sid, 
vtk6 was used to build CamiTK core library and gdcm 2.8.7-2 (using vtk7) 
was used to build the dicom extension of CamiTK.
- In the test where the dicom extension is loaded (this is not all the 
CamiTK test, hence the specific test failures), the class RendererWidget 
of CamiTK was confused with both vtk share library loaded in memory (as 
Berhnard message pointed out).
- This bug was born
- Berhnard (bravely!) decided to update the dependency of CamiTK from 
vtk6 to vtk7, which resulted in other problem (probably due to the use 
of VTK class QVTKWidget2 in the CamiTK class RendererWidget)

My questions to all:
- is there any other package using vtk6 and gdcm 2.8.7-2 that are 
affected by this?
- should the gdcm package not add (some kind of) conflict flag with vtk6 
(so that this problem can be more easily detected in the future)?
- if there is no (easy) way to go back to vtk6 in gdcm (or to support 
both vtk6 and vtk7), does this means that we (upstream) need to update 
CamiTK to be based on VTK7 in order to fix this bug?

And two bonus subsidiary questions to Gert , Steve and Sébastien :
- About VTK8 : is there any plan to add a vtk8 package in debian? I 
don't really know what is the release policy of VTK, but it seems they 
went from 7.0 to 7.1 to directly 8.0 and then 8.1, and I saw VTK 9 
mentioned (if you have more information or pointer about the release 
policy or the roadmap, I will be very thankful!). I found an article on 
the Kitware blog saying that they have their own apt repository for sid 
providing nightly builds of VTK [2]. Do you know any more about that? 
What is your "vision" about vtk8 in debian?
- (more technical and may be not in the proper context) about VTK Qt and 
OpenGL: VTK8 seems to have introduced a different class to manage VTK 
renderer inside Qt widget (QVTKOpenGLWidget instead of QVTKWidget). This 
is an area where we add a lot of problem with Qt5+VTK6 (especially on 
linux+intel integrated video cards and windows virtual machines). So it 
seems that transition to VTK8 brings more hope. Do you have any 
experience of migrating QVTKWidget from VTK6 to VTK7 or VTK8?

Thanks again to Andreas and Bernhard and in advance to Gert, Steve and 
Sébastien!
Hopefully this bug can be solved soon...

Best regards,
Emmanuel

PS : and of course the double delete discovered by Bernhard [3] should 
be solved upstream as well!

[1] 
https://salsa.debian.org/med-team/gdcm/commit/dd4f5d00b99730388512f512743e0be48ce56ae2
[2] 
https://blog.kitware.com/rethinking-debian-packaging-for-vtk-and-other-cmake-projects-part-1/
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909120#10