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
