Bug#1057398: [Debian-med-packaging] Bug#1057398: FTBFS: libITKIOGDCM-5.3.so.1: undefined reference to `gdcm::DirectionCosines::~DirectionCosines()'
Hi, This seems due to bug#1056953 [1] as the error message is linked to the same missing symbol. Best regards, Emmanuel [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056953 On 04/12/2023 13:36, Chris Hofstaedtler wrote: Source: elastix Version: 5.1.0-1 Severity: serious Tags: ftbfs Dear Maintainer, your package FTBFS in a test rebuild in unstable: ... /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libITKIOGDCM-5.3.so.1: undefined reference to `gdcm::DirectionCosines::~DirectionCosines()' collect2: error: ld returned 1 exit status ... [ 29%] Built target elxCommon make[2]: Leaving directory '/<>/obj-x86_64-linux-gnu' make[1]: *** [Makefile:149: all] Error 2 make[1]: Leaving directory '/<>/obj-x86_64-linux-gnu' dh_auto_build: error: cd obj-x86_64-linux-gnu && make -j16 "INSTALL=install --strip-program=true" VERBOSE=1 returned exit code 2 make: *** [debian/rules:11: binary] Error 25 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 Please find a full build log attached. Best, Chris ___ Debian-med-packaging mailing list debian-med-packag...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
Bug#1056953: [Debian-med-packaging] Bug#1056953: gdcm: ABI broke in last version 3.0.22-1
Thanks for the clarification. To add my 2 cents, the problem appears to be raised by libITKIOGDCM shared object (from the insighttoolkit5 package), which is indeed used by libitkimage shared object of CamiTK. Best regards, Emmanuel On 27/11/2023 09:43, Gianfranco Costamagna wrote: Source: gdcm Version: 3.0.22-1 Severity: serious Hello, as seen, gdcm is not migrating because of camitk test regression. Looking at the failure, looks like the fault is not in camitk, but in gdcm itself, changing the ABI without a SONAME bump quoting https://ci.debian.net/data/autopkgtest/testing/amd64/c/camitk/40209513/log.gz 159s 2023-11-26 13:11:35.182 [ERROR ] Extension manager error: 159s Loading component extension failed after 10 tries. 159s 159s Plugin: 159s "/usr/lib/x86_64-linux-gnu/camitk-5.1/components/libitkimage.so.5.1.0" 159s 159s Error: 159s Cannot load library : (/lib/x86_64-linux-gnu/libITKIOGDCM-5.3.so.1: undefined symbol: _ZN4gdcm16DirectionCosinesD1Ev 159s 159s List of library paths: 159s - /usr/lib/x86_64-linux-gnu/camitk-5.1/viewers 159s - /usr/lib/x86_64-linux-gnu/camitk-5.1/components 159s - /usr/lib/x86_64-linux-gnu/camitk-5.1/actions 159s - /usr/lib/x86_64-linux-gnu/camitk-5.1 159s - /usr/lib/x86_64-linux-gnu/qt5/plugins 159s - /usr/bin 159s $ echo _ZN4gdcm16DirectionCosinesD1Ev |c++filt gdcm::DirectionCosines::~DirectionCosines() Checking the changes in header files for new release I see -DirectionCosines::~DirectionCosines() = default; and - ~DirectionCosines(); + ~DirectionCosines() = default; But this object is used in external packages, so it can't change signature or be dropped. G. ___ Debian-med-packaging mailing list debian-med-packag...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging -- Emmanuel Promayon Professeur Univ. Grenoble Alpes - Polytech Grenoble Laboratoire TIMC - équipe GMCAO
Bug#1013153: camitk: vtk[6,7] removal
Dear Andreas, Thanks again for all the work. CamiTK is now fully compatible with VTK9 upstream [1], but there is no official release yet. The new version of CamiTK with VTK9 support should be available before the end of July, and my objective is to have the package ready as well in the same time-frame. Again, thanks to you and all the debian-med team for all the work you are doing for the community. Best regards, Emmanuel [1] https://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/commit/88fa21f1cb8c74a4f1b168bd03167b9f5b1c1537 (this was done during bookworm freeze, using testing, so it will have to be tested with sid, but I am quite hopeful) On 22/06/2023 09:45, Andreas Tille wrote: Am Mon, Jun 19, 2023 at 10:26:02AM +0200 schrieb Sebastiaan Couwenberg: Would you consider doing a nocheck upload to unstable to unblock the vtk7 removal? The FTBFS on the buildds and autopkgtest failures would keep blocking testing migration until the vtk9 support is fully fixed. I've deactivated build time test results with '|| true' and uploaded. The package will not migrate to testing anyway since its autopkgtests are failing. @Emmanuel: Do you think you will manage to adapt camitk to vtk9 in the foreseable future or is it rather time to remove this package from Debian? Kind regards Andreas. -- Emmanuel Promayon Professeur Univ. Grenoble Alpes - Polytech Grenoble Laboratoire TIMC - équipe GMCAO
Bug#1013153: camitk: vtk[6,7] removal
Dear Andreas, On 01/02/2023 13:35, Andreas Tille wrote: Hi Emmanuel, Am Tue, Jan 31, 2023 at 01:53:15PM +0100 schrieb Emmanuel Promayon: could you simply push your patch and we can see the build log in Salsa CI? I just pushed both (VTK9 compatibility and dicom component disability) to salsa (in the main branch, hopefully that's ok) Unfortunately Salsa CI failed for whatever reason in the first stage. Yes I noticed that (it seems it does that since the setup of the CI for this project). I don't know where to look to fix this (it looks like an disk access mis-configuration). If I try to build the package in my local pbuilder chroot all tests are failing: ... 543: Test command: /usr/bin/cmake "-DCAMITK_TEST_COMMAND=/build/camitk-5.0.2/camitk-build/bin/camitk-testloggercrash" "-DCAMITK_TEST_COMMAND_ARG=-d /build/camitk-5.0.2/camitk-build/ tutorials/applications/testloggercrash/testlogger" "-DCAMITK_TEST_PASS_FILE=/build/camitk-5.0.2/tutorials/applications/testloggercrash/log-default.log" "-DCAMITK_TEST_OUTPUT_DIR=/build/ camitk-5.0.2/camitk-build/Testing/Temporary/application-testloggercrash-5" "-DCAMITK_TEST_NAME=application-testloggercrash-5" "-P" "/build/camitk-5.0.2/sdk/cmake/modules/macros/camitk/ test/CamiTKTestPassFile.cmake" 543: Working Directory: /build/camitk-5.0.2/camitk-build 543: Test timeout computed to be: 1800 543: /build/camitk-5.0.2/camitk-build/bin/camitk-testloggercrash: error while loading shared libraries: libjawt.so: cannot open shared object file: No such file or directory 543: -- Comparing file "/build/camitk-5.0.2/tutorials/applications/testloggercrash/log-default.log" to "/build/camitk-5.0.2/camitk-build/Testing/Temporary/application-testloggercrash-5/ command-output"... 543: -- [FAIL] 543: CMake Error at /build/camitk-5.0.2/sdk/cmake/modules/macros/camitk/test/CamiTKTestPassFile.cmake:67 (message): 543: application-testloggercrash-5: 543: /build/camitk-5.0.2/camitk-build/Testing/Temporary/application-testloggercrash-5/command-output 543: does not match 543: /build/camitk-5.0.2/tutorials/applications/testloggercrash/log-default.log 543: 543: 543/543 Test #543: application-testloggercrash-5 ...***Failed0.03 sec 0% tests passed, 505 tests failed out of 506 ... The following tests FAILED: 1 - component-msh-level3-1 (Failed) 2 - component-msh-level3-2 (Failed) 3 - component-obj-level3-1 (Failed) 4 - component-obj-level3-2 (Failed) ... 541 - application-testloggercrash-3 (Failed) 542 - application-testloggercrash-4 (Failed) 543 - application-testloggercrash-5 (Failed) Errors while running CTest Output from these tests are in: /build/camitk-5.0.2/camitk-build/Testing/Temporary/LastTest.log Use "--rerun-failed --output-on-failure" to re-run the failed cases verbosely. Are you able to reproduce this and do you have any idea what might be wrong here? Thank you for trying. Yes I have exactly the same problem on my own machine. libjawt.so is provided by openjd. There is nothing in CamiTK source itself that depends on Java. That's made me think the error is linked with a Java installation problem (maybe temporary?). Or may be due to some linkage problem in one of the CamiTK dependency. I will try to invistigate using ldd on camitk-testloggercrash and let you know as soon as possible. Best regards, Emmanuel
Bug#1013153: camitk: vtk[6,7] removal
On 31/01/2023 11:22, Andreas Tille wrote: Dear Emmanuel, could you simply push your patch and we can see the build log in Salsa CI? I just pushed both (VTK9 compatibility and dicom component disability) to salsa (in the main branch, hopefully that's ok) Kind regards
Bug#1013153: camitk: vtk[6,7] removal
Dear Andreas,
I managed to patch the current CamiTK 5.0.2version to build with VTK9
(vtk9-compatibility.patch in attachment).
The build then stopped with the following error:
/build/camitk-5.0.2/imaging/components/dicom/DicomComponent.cpp:40:10:
fatal error: vtkGDCMImageReader.h: No such file or directory
When this plugin is disabled in d/r (see below), the compilation ends
with no error, (which is good news!) but all tests failed with the
following error:
/build/camitk-5.0.2/camitk-build/bin/camitk-testcomponents: error while
loading shared libraries: libjawt.so: cannot open shared object file: No
such file or directory
This error seems to be linked with a Java installation problem (maybe
temporary?)
Let me know what will be the best course of action from this.
Best regards,
Emmanuel
PS: this is the d/r diff to disable the dicom component,
--- a/debian/rules
+++ b/debian/rules
@@ -42,6 +42,7 @@ CMAKE_EXTRA_FLAGS = \
-DCEP_IMAGING:BOOL=TRUE \
-DCEP_MODELING:BOOL=TRUE \
-DCEP_TUTORIALS:BOOL=TRUE \
+ -DCOMPONENT_DICOM:BOOL=FALSE \
\
-DAPIDOC_SDK:BOOL=TRUE
--- a/modeling/actions/mml/GenerateModel.cpp
+++ b/modeling/actions/mml/GenerateModel.cpp
@@ -127 +127 @@ void GenerateModel::saveSOFAFile(QString baseFilename) {
-ofstream scnFile(SOFAFileName.toUtf8());
+std::ofstream scnFile(SOFAFileName.toUtf8());
@@ -188 +188 @@ void GenerateModel::saveMMLFiles(QString baseFilename) {
-ofstream lmlofs(lmlFilename.toStdString().c_str());
+std::ofstream lmlofs(lmlFilename.toStdString().c_str());
@@ -235 +235 @@ void GenerateModel::saveMMLFiles(QString baseFilename) {
-ofstream mmlofs(mmlFilename.toStdString().c_str());
+std::ofstream mmlofs(mmlFilename.toStdString().c_str());
@@ -268 +268 @@ void GenerateModel::saveMMLFiles(QString baseFilename) {
-ofstream pmlofs(completePmlFilename.toStdString().c_str(), std::ios_base::trunc);
+std::ofstream pmlofs(completePmlFilename.toStdString().c_str(), std::ios_base::trunc);
--- a/modeling/components/mmlcomponent/MMLComponent.cpp
+++ b/modeling/components/mmlcomponent/MMLComponent.cpp
@@ -80 +80 @@ MMLComponent::MMLComponent(const QString& fileName) : Component(fileName, QFileI
-ofstream ofs(exportedMml.toStdString().c_str());
+std::ofstream ofs(exportedMml.toStdString().c_str());
--- a/sdk/actions/image/multipicking/PickedPixelMap.cpp
+++ b/sdk/actions/image/multipicking/PickedPixelMap.cpp
@@ -165 +165 @@ void PickedPixelMap::savePixelList(QString fileName) {
-ofstream myFile;
+std::ofstream myFile;
deleted file mode 100644
Binary files a/sdk/actions/image/volumerendering/resources/Thumbs.db and /dev/null differ
--- a/sdk/actions/mesh/meshprocessing/MergeMeshs.cpp
+++ b/sdk/actions/mesh/meshprocessing/MergeMeshs.cpp
@@ -338 +338 @@ void MergeMeshs::printKToFile() {
-ofstream mshFile(fileNeigh.toUtf8());
+std::ofstream mshFile(fileNeigh.toUtf8());
--- a/sdk/actions/mesh/meshprocessing/MeshClipping.cpp
+++ b/sdk/actions/mesh/meshprocessing/MeshClipping.cpp
@@ -93,0 +94 @@ QWidget* MeshClipping::getWidget() {
+#if VTK_MAJOR_VERSION < 9
@@ -95 +96,3 @@ QWidget* MeshClipping::getWidget() {
-
+#else
+vtkRenderWindowInteractor* iren = default3DViewer->getRendererWidget()->renderWindow()->GetInteractor();
+#endif
--- a/sdk/applications/imp/main.cpp
+++ b/sdk/applications/imp/main.cpp
@@ -107 +107 @@ int main(int argc, char* argv[]) {
-
+
--- a/sdk/components/msh/MshExtension.cpp
+++ b/sdk/components/msh/MshExtension.cpp
@@ -72 +72 @@ bool MshExtension::save(Component* component) const {
-ofstream mshFile(meshComp->getFileName().toStdString().c_str());
+std::ofstream mshFile(meshComp->getFileName().toStdString().c_str());
--- a/sdk/components/obj/ObjExtension.cpp
+++ b/sdk/components/obj/ObjExtension.cpp
@@ -90 +90 @@ bool ObjExtension::save(camitk::Component* component) const {
-ofstream objFile(fileName.toUtf8());
+std::ofstream objFile(fileName.toUtf8());
--- a/sdk/components/off/OffExtension.cpp
+++ b/sdk/components/off/OffExtension.cpp
@@ -77 +77 @@ bool OffExtension::save(Component* component) const {
-ofstream offFile(offFilename.toUtf8());
+std::ofstream offFile(offFilename.toUtf8());
--- a/sdk/components/vrml/VRMLComponentExtension.cpp
+++ b/sdk/components/vrml/VRMLComponentExtension.cpp
@@ -80,0 +81 @@ bool VRMLComponentExtension::save(Component* component) const {
+#if VTK_MAJOR_VERSION < 9
@@ -81,0 +83,3 @@ bool VRMLComponentExtension::save(Component* component) const {
+#else
+exporter->SetInput(default3DViewer->getRendererWidget()->renderWindow());
+#endif
deleted file mode 100644
--- a/sdk/libraries/core/viewer/InteractiveViewer.cpp
+++ b/sdk/libraries/core/viewer/InteractiveViewer.cpp
@@ -151,0 +152 @@ void InteractiveViewer::init() {
+#if VTK_MAJOR_VERSION < 9
@@ -152,0 +154,3 @@ void InteractiveViewer::init() {
+#else
+
Bug#1013153: camitk: vtk[6,7] removal
Dear Andreas, Just to let you know that I managed to compile CamiTK with VTK9 but I had to replace the base class that allows for the interaction between VTK and Qt. This is also related to bug ##979306 [1]. I can patch CamiTK to build with VTK9, but there are some major problem with the user interaction in the 3D windows that I have to tackle first. As user interaction is not tested automatically, this bug probably will not be detected during the test/autotest. I did not test the package build yet. I could add a patch and test the packaging, but if it works users will have major issue with the interaction. Would that be preferable than to wait for me to fix the interaction problem? Thanks for your help and wisdom Emmanuel [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979306
Bug#1013153: camitk: vtk[6,7] removal
Dear Andreas, Thank you for your commit on salsa. The VTK API is generally stable enough and some little things might have to be modified in the source code. However, my experience with transition to a new VTK version is that it may cause some problem in the way 3D rendering is handled, which is harder to tackle. I have not tested CamiTK with VTK9 yet, but I will try to do so in the next few days and will get back to you ASAP. Kind regards and thanks again for the time and attention Emmanuel On 14/01/2023 08:42, Andreas Tille wrote: Control: tags -1 upstream Control: tags -1 help Control: forwarded -1 Emmanuel Promayon, Celine Fouard Hi Emmanuel and Celine, Debian has dropped support for VTK 6/7 and camitk needs to be ported to VTK9. Currently libvtk9-qt-dev is not installable to do a test build. It would be great if you could confirm that camitk builds with VTK9. Kind regards Andreas. -- Emmanuel Promayon Professeur Univ. Grenoble Alpes - Polytech Grenoble Laboratoire TIMC - équipe GMCAO
Bug#997120: [Debian-med-packaging] Bug#997120:
Dear Jose and Andreas, On 14/02/2022 17:02, Andreas Tille wrote: Am Mon, Feb 14, 2022 at 12:18:47AM +0100 schrieb Jose Luis Rivero: You are welcome. This bug is preventing one of my packages (Gazebo) from being migrated to testing. Could we please upload a revision bump of the current version to solve this issue while we work on 5.0.2? Hmmm, that's a bit tricky now. I've uploaded 5.0.2 to new[1]. May be pinging #debian-ftp could help? (I'm hesitating a bit to do so myself since I used that option recently a bit frequently.) Sorry about that: I did not notice that bug 997120 was blocking gazebo (should there did not be a flag or message somewhere to alert about that? Being quite inexperienced I might well as missed it...) Let me know if (and how!) I can help with asking the ftpmaster team. Best regards, Emmanuel
Bug#997120:
Hello, Thank you very much for this patch, you are absolutely right: your patch fixes the problem! It should also work perfectly well to make the last upstream version (5.0.2) build properly. Andreas started to check on last month but with your patch, it should work. I can confirm anyway that camitk version 5.0.2 builds well with ITK5 with the help of your patch. Best regards, Emmanuel On Mon, 7 Feb 2022 18:09:37 +0100 Jose Luis Rivero wrote: > Hi. I've been looking into the camitk compilation, I think I have a patch > for it. > > The build is currently failing by trying to find the file > CommandLineOptions.ixx.o. Problem is really in > the line above where the compiler does not identify the file > CommandLineOptions.ixx as a valid > c++ file, so the object file is not being generated: > """ > c++: warning: > /build/camitk-o5Au93/camitk-4.1.2/sdk/applications/testactions/CommandLineOptions.ixx: > > linker input file unused because linking not done > "" > > The compiler can be informed about the format of the file by using -x c++ > but the result > won't compile at all since the file seems to be designed to be used in > combination with > other headers (other headers include .ixx at the end of the file). The code > is in the compilation > units via include in other headers, no reason to add it to CMake. > > Removing the .ixx makes the compilation work in an Sid sbuild environment. > """ > +--+ > | Summary > | > +--+ > > Autopkgtest: pass > Build Architecture: amd64 > Build Type: full > Build-Space: 6204608 > Build-Time: 725 > Distribution: unstable > Host Architecture: amd64 > Install-Time: 72 > Job: /home/jrivero/code/debian/camitk_4.1.2-5.dsc > Lintian: warn > Machine Architecture: amd64 > Package: camitk > Package-Time: 801 > Piuparts: pass > Source-Version: 4.1.2-5 > Space: 6204608 > Status: successful > Version: 4.1.2-5 > """ > > Attached is the debdiff. -- Emmanuel Promayon Professeur Univ. Grenoble Alpes - Polytech Grenoble Laboratoire TIMC - équipe GMCAO
Bug#945453: camitk: FTBFS, uninstallable build-deps in unstable
Dear Steve, Thank you for this bug report. After checking the build log you provided, I found this: CMake Error at /usr/lib/cmake/ITK-4.13/Modules/ITKMINC.cmake:15 (find_package): By not providing "FindLIBMINC.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "LIBMINC", but CMake did not find one. Could not find a package configuration file provided by "LIBMINC" with any of the following names: LIBMINCConfig.cmake libminc-config.cmake Add the installation prefix of "LIBMINC" to CMAKE_PREFIX_PATH or set "LIBMINC_DIR" to a directory containing one of the above files. If "LIBMINC" provides a separate development package or SDK, be sure it has been installed. Call Stack (most recent call first): /usr/lib/cmake/ITK-4.13/ITKModuleAPI.cmake:71 (include) /usr/lib/cmake/ITK-4.13/ITKModuleAPI.cmake:26 (itk_module_load) /usr/lib/cmake/ITK-4.13/ITKModuleAPI.cmake:124 (_itk_module_config_recurse) /usr/lib/cmake/ITK-4.13/ITKConfig.cmake:82 (itk_module_config) sdk/cmake/modules/macros/camitk/CamiTKExtension.cmake:234 (find_package) imaging/components/itkimage/CMakeLists.txt:2 (camitk_extension) Which suggest that bug #945453 is linked with bug #944636 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944636 for which there is fix waiting if I understood correctly. I am not sure how to properly tag the bug #945453 to say it will (probably) be fixed when #944636 is fixed. Kind regards, Emmanuel smime.p7s Description: S/MIME Cryptographic Signature
Bug#945454: elastix: FTBFS with current opencv and gdcm
Dear Steve, Thank you for this bug report. After checking the build log you provided, I found the same CMake error message as in #945453 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945453 Therefore I think all packages that depends on insight-toolkit will fail the same way due to bug #944636 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944636 for which there is a fix waiting (if I understood correctly). Kind regards, Emmanuel smime.p7s Description: S/MIME Cryptographic Signature
Bug#926430: [Debian-med-packaging] Bug#926430: fixed in camitk 4.1.2-3
Thank you for this very quick and efficient bug fix! Emmanuel On 06/04/2019 07:45, Andreas Tille wrote: On Fri, Apr 05, 2019 at 11:33:24PM +0200, Tobias Frost wrote: Hi Andreas, thanks for the upload! Can you file an unblock request so that the package will migrate? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926435 It was even unblocked now. :-)
Bug#914817: [Debian-med-packaging] Bug#914817: Bug#914817: camitk: FTBFS on i386
Hi, These are the steps I followed to investigate this bug: - modified the debian/rules of the vtk7 package by adding: ifeq ($(DEB_BUILD_ARCH),i386) # prevent undesirable excess precision export DEB_CXXFLAGS_MAINT_APPEND=-ffloat-store endif - rebuild vtk7 for i386 locally with this new flag - rebuild camitk for i386 using the resulting vtk7 packages Results: tests #46 and #341 both succeed without any problem and camitk did not FTBFS on i386 locally. Gert was right about the flag, but it seems that it is required in vtk7 not in camitk. What will be the next step to solve this bug? Best regards, Emmanuel PS : I added Gert in cc: (and btw thank you Gert for your answer about the future of vtk package, I saw that vtk 8.2 is on its way from upstream, hopefully vtk8 will be available soon in debian!)
Bug#914817: [Debian-med-packaging] Bug#914817: camitk: FTBFS on i386
X-Debbugs-Cc: Gert Wollny Thank you Mattia for this report. I rebuild locally and got the same two tests failing. After a first investigation, I think Gert is probably right about this "-ffloat-store" or at least about floating point precision. For instance, for test #46, which complains about a difference between expected output and actual output: diff .../camitk-build/Testing/Temporary/action-reconstruction-integration-test/output-1.vtk ... /camitk-build/Testing/Temporary/action-reconstruction-integration-test/2018-11-29T16-54-57/output-1.vtk gives 3626c3626 < 0.804485 -0.417868 -0.422127 0.224294 -0.343943 -0.911809 -0.567178 -0.335857 -0.752004 --- 0.804485 -0.417868 -0.422127 0.224294 -0.343943 -0.911809 -0.567178 -0.335857 -0.752003 3632c3632 < -0.346881 0 -0.937909 -0.150485 -0.0767808 -0.985626 -0.458605 -0.843355 -0.280059 --- -0.346881 0 -0.937909 -0.150485 -0.0767809 -0.985626 -0.458605 -0.843355 -0.280059 3635c3635 < 0.13497 -0.236088 -0.962313 -0.487965 -0.150704 -0.859755 -0.484595 -0.281462 -0.828219 --- 0.13497 -0.236088 -0.962313 -0.487964 -0.150704 -0.859755 -0.484595 -0.281462 -0.828219 Note the floating point precision difference. In both cases the vtk class that is used is the marching cube reconstruction algorithm. May be the "-ffloat-store" cxx flag is not added in VTK (or more specically is just erased somewhere just for the marching cube reconstruction algorithm, as other filters seem to not have this problem? I will check a little bit further to see if the problem is in camitk or vtk7 Best regards, Emmanuel On 27/11/2018 17:48, Mattia Rizzolo wrote: Source: camitk Version: 4.1.2-1 Severity: serious X-Debbugs-Cc: Gert Wollny Hi, so camitk FTBFS on i386; I don't know why it sometimes suceeds on the buildds, but for example on the r-b infra it always failed recently. In particular, it fails two tests: 47: Test command: /usr/bin/cmake "-DCAMITK_TEST_COMMAND=/build/camitk-4.1.2/camitk-build/bin/camitk-actionstatemachine" "-DCAMITK_TEST_COMMAND_ARG=-f /build/camitk-4.1.2/camitk-build/Testing/Temporary/action-reconstruction-integration-test/asm-input.scxml -o /build/camitk-4.1.2/camitk-build/Testing/Temporary/action-reconstruction-integration-test -a" "-DCAMITK_TEST_EXPECTED_FILES=output-1.vtk" "-DCAMITK_TEST_OUTPUT_DIR=/build/camitk-4.1.2/camitk-build/Testing/Temporary/action-reconstruction-integration-test" "-DCAMITK_TEST_NAME=action-reconstruction-integration-test" "-P" "/build/camitk-4.1.2/sdk/cmake/modules/macros/camitk/test/CamiTKTestActionStateMachine.cmake" 47: Test timeout computed to be: 1800 47: QStandardPaths: XDG_RUNTIME_DIR points to non-existing path '/run/user/1000', please create it with 0700 permissions. 47: [FAIL] 47: CMake Error at /build/camitk-4.1.2/sdk/cmake/modules/macros/camitk/test/CamiTKTestActionStateMachine.cmake:115 (message): 47: action-reconstruction-integration-test: (one or more) output file do(es) 47: not match the corresponding expected file. 47: 47: Action state machine regression test called with: 47: 47:- CAMITK_TEST_NAME=action-reconstruction-integration-test 47:- CAMITK_TEST_COMMAND=/build/camitk-4.1.2/camitk-build/bin/camitk-actionstatemachine 47:- CAMITK_TEST_COMMAND_ARG=-f /build/camitk-4.1.2/camitk-build/Testing/Temporary/action-reconstruction-integration-test/asm-input.scxml -o /build/camitk-4.1.2/camitk-build/Testing/Temporary/action-reconstruction-integration-test -a 47:- CAMITK_TEST_EXPECTED_FILES=output-1.vtk 47:- CAMITK_TEST_OUTPUT_DIR=/build/camitk-4.1.2/camitk-build/Testing/Temporary/action-reconstruction-integration-test 47: 47: = 47: 47: Comparing 47: /build/camitk-4.1.2/camitk-build/Testing/Temporary/action-reconstruction-integration-test/2018-11-27T16-12-36/output-1.vtk 47: with 47: /build/camitk-4.1.2/camitk-build/Testing/Temporary/action-reconstruction-integration-test/output-1.vtk 47: 47: 47: Output: 47: 47: 47: 47: Result: 47: 47: action-reconstruction-integration-test: comparing output-1.vtk failed: 47: 47: Output file 47: /build/camitk-4.1.2/camitk-build/Testing/Temporary/action-reconstruction-integration-test/output-1.vtk 47: is not the same as 47: /build/camitk-4.1.2/camitk-build/Testing/Temporary/action-reconstruction-integration-test/2018-11-27T16-12-36/output-1.vtk 47: 47: 47: 47: 47: 47: 47/550 Test #47: action-reconstruction-integration-test ..***Failed3.00 sec and similarly for test 341. I've tried the proposed change by Gert, i.e. passing -ffloat-store, but it didn't help. ___ Debian-med-packaging mailing list debian-med-packag...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging -- Emmanuel Promayon Professeur Univ. Grenoble Alpes
Bug#911793: Control: reassign -1 src:gdcm 2.8.7-2
Dear all Thank to Paul for your answers about the autoremoval and explanation about the ABI problem. It seems that Adrian Bunk's triage message in 909120 (added blocking bug(s) of 909120: 911793) did push the autoremoval for another month (thanks to Adrian as well, as that's exactly what is happening). Thank you to Mattia for finding the ABI problem and to Matthieu for his comments. Thank you to Gert for the explanation about vtk7 (by the way do you have any idea about the possible future introduction of vtk8 or vtk9?). You are right about camitk-imp and camitk-config: they are not linked with gdcm. When camitk-imp or camitk-config are run they load some plugins (e.g. the dicom plugin) that itself is linked with gdcm. Running ldd on one of the pluging get the similar missing vtk symbols and so. So I suppose the problem is in vtk7 From what I can understand (sorry in advance for any approximation or stating the obvious): 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). 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. 3) camitk 4.1.2-2 introduced a patch so that it only depends on vtk7 (and like gdcm 2.8.7 without changing the upstream source version). 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 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 Let me know if there is anything I can do to help. 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 also welcome any information/documentation about how to track the symbol. Best regards Emmanuel
Bug#911793: [Debian-med-packaging] Bug#911793: autopkgtest regression: Segmentation fault
Dear Paul, On 19/11/2018 19:32, Paul Gevers wrote: It seems camitk-4.1.2-2 is not very lucky! So you are caught in the hdf5 transition: https://release.debian.org/transitions/html/auto-hdf5.html Yes, you are right. The current deadline for camitk package removal is 22 November. What do you think is the best course of action? If you comment on the RC bug that is triggering the autoremoval, then the timer gets reset. Just explain there why it can't be fixed NOW. I still agree with Mattia: "This is the signature of an ABI break not correctly handled." so I believe that should be fixed first. The RC bug that triggered the autoremoval is #909120 [1] and (I hope it) should be fixed by camitk version 4.1.2-2 (now in unstable and struggling to get into testing). The bug was closed automatically by the upload ot 4.1.2-2. Just to make sure that I understand correctly about the autoremoval: if I comment on #909120 it should delay the autoremoval? I understand as well that it might not be the best thing to do first (I just like to understand a bit better). About the ABI break: I am sorry to say that I don't really understand how to fix this. Is it possible that this ABI breaks comes from the fact camitk 4.1.2-1 is based on vtk6 (which introduced #909120 in the first place when gdcm >= 2.8.7-2 moved from python2 to python3 and consequently from vtk6 to vtk7) while camitk-4.1.2-2 is based on vtk7 and gdcm >= 2.8.7-2? If yes, should I add a "Breaks: vtk6" in d/control of camitk?And/or as you suggested earlier should I add "gdcm >= 2.8.8"? Or it is something (like "Breaks:vtk6") that should be done in gdcm or vtk7 instead? Thank you again for your message... and for your patience (and do not hesitate to refer me to some documentation or example, my packager training is far from being finished, as you can see!) Best regards, Emmanuel [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909120
Bug#911793: autopkgtest regression: Segmentation fault
Dear Mattia and Paul, On 16/11/2018 11:08, Mattia Rizzolo wrote: On Fri, Nov 16, 2018 at 07:28:21AM +0100, Emmanuel Promayon wrote: Thanks to the (great work) of Gert on vtk7 and gdcm packages, version 7.1.1+dfsg1-9 of vtk7 and version 2.8.8-2 of gdcm are now both in testing. I sent a retry request for the autopkgtest of camitk version 4.1.2-2 but it naturally failed as camitk 4.1.2-2 was built with the problematic version of gdcm (error was at run time: "libvtkRenderingFreeTypeFontConfig-7.1.so.7.1: cannot open shared object file: No such file or directory"). This is the signature of an ABI break not correctly handled. Thank you Mattia for your answer. From what I can understand, this autopkgtest regresion (bug #911793) originated in a dependency mismatch in gdcm (when gdcm 2.8.7-2 moved its dependency from python2 to python3 and consequently from vtk6 to vtk7), see my explanation tentative [1]. The current binary version of camitk was compiled with gdcm 2.8.7-5 [2]. This is the reason why I initially asked for a rebuild as there was a temporary mixup in vtk7/gdcm dependency and I supposed that now with gdcm 2.8.8-2 in testing, the dependency problem should be solved. That's not the right action to take (or better, not only). That situation must not happen, so most likely some versioned dependency or versioned break was missed somewhere. Maybe Paul has more insight on the problem (I just read this single email and wanted to block a "simple" rebuild) Thanks to Paul for his answer. Mattia you can find Paul's initial answer about this is in the bug tracker [3]. In the meanwhile I tried to rebuild the camitk package locally (on last Friday), and autopkgtest ran with no error. Unfortunately, this is not the case anymore! Since yesterday I cannot rebuild the package anymore. There is a "pbuilder-satisfydepends failed." error due to hdf5: > The following packages have unmet dependencies: > libhdf5-103 : Conflicts: libhdf5-100 but 1.10.0-patch1+docs-4+b2 is to be installed > libhdf5-cpp-103 : Conflicts: libhdf5-cpp-100 but 1.10.0-patch1+docs-4+b2 is to be installed > libhdf5-openmpi-103 : Conflicts: libhdf5-openmpi-100 but 1.10.0-patch1+docs-4+b2 is to be installed > Unable to resolve dependencies! Giving up... It seems camitk-4.1.2-2 is not very lucky! The current deadline for camitk package removal is 22 November. What do you think is the best course of action? Thanks again for your help (and sorry about my newbie statements!) Emmanuel [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911793#10 [2] https://buildd.debian.org/status/fetch.php?pkg=camitk=amd64=4.1.2-2=1540312520=0 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911793#15
Bug#911793: autopkgtest regression: Segmentation fault
Dear Paul, Gert and all, Thanks to the (great work) of Gert on vtk7 and gdcm packages, version 7.1.1+dfsg1-9 of vtk7 and version 2.8.8-2 of gdcm are now both in testing. I sent a retry request for the autopkgtest of camitk version 4.1.2-2 but it naturally failed as camitk 4.1.2-2 was built with the problematic version of gdcm (error was at run time: "libvtkRenderingFreeTypeFontConfig-7.1.so.7.1: cannot open shared object file: No such file or directory"). Would it possible for someone with the right credentials to ask for a complete rebuild of camitk 4.1.2-2? (or please let me know if I am wrong thinking that it is not the right course of actions!) Thank you again to Gert and Paul, Best regards Emmanuel [1] https://ci.debian.net/data/autopkgtest/testing/amd64/c/camitk/1322100/log.gz
Bug#911793: autopkgtest regression: Segmentation fault
Dear Paul, Thank you for your investigation. From the autopkgtest log [1], it seems that vtk6 is installed along side vtk7. My understanding of this problem is as follow (I put the debian-med list in copy so that they can correct me if I am wrong) - gdcm 2.8.7-1 depends on vtk6 - gdcm 2.8.7-2 moved to python3 and vtk7 - as camitk-4.1.2-1 depends on vtk6 and gdcm, when gdcm 2.8.7-2 went into unstable, this generated bug #909120, which is a FTBS on unstable due to the fact that both vtk6 and vtk7 were installed and at run time the conflict generated a segfault (and I think that the same segfault is causing #911793) - gdcm was blocked into unstable because of other issues, and was updated recently to fix these other issues (mainly python version conflict and a problem with poppler). gdcm 2.8.7-5 is now in unstable, and should fix all problems (big thanks to Gert and Gianfranco!) - I updated to camitk-4.1.2-2 so that it only depends on vtk7. vtk6 should not be installed by autopkgtest (and is not when run inside unstable). IMHO is that this autopkgtest regression is due to the fact that testing has gdcm 2.8.7-1 (that depends on vtk6), while unstable has gdcm 2.8.7-5 (uploaded 22 october, that depends on vtk7 only). This problem should go away when gdcm 2.8.7-5 enters testing. Let me know what you think of this analysis and what I can do to help (I just have a partial understanding on how these kind of problems should be solved/displayed). Best regards, Emmanuel [1] https://ci.debian.net/data/autopkgtest/testing/amd64/c/camitk/1201581/log.gz
Bug#909120: camitk FTBFS: tests segfault (Bug #909120)
Dear all, I have read that upstream is joining Debian Science to package recent upstream version VTK8. I expect that VTK6 will be removed from Debian soon. So yes, I'd strongly recommend to follow the stable release cycle of VTK upstream, which means that porting camitk to VTK7 is necessary for including camitk into Debian and it is sensible to do some checks with VTK8 since at some point in time this will be used in Debian. We will not be able to support more than two VTK versions in Debian (most probably only one). Just to let you know about my progress: I finally find some time to try to get the current camitk to work with vtk7 and suppress all the dependencies to vtk6. The main problem is due to the necessary change to OpenGL2 backend. This effort is on a good way thanks to some tweak I found in a post on vtk user back in 2016 [1]. To avoid any other potential problem is some other package, should gdcm not be set as to conflict with vtk6? So far for a short note - more details from VTK maintainers ... I would still love to know more about the progress towards an official debian package for vtk8 (or 9 as it seems on its way!). I found some discussion about vtk7 and vtk8 packages on debian science mailing list and kitware blog, but I am not sure I well understood the meaning or consequences. So any idea about the (near) future would be a great help! Kind regards, Emmanuel [1] http://vtk.1045678.n5.nabble.com/Find-reason-for-exclusion-of-vtkGUISupportQtOpenGL-in-build-output-td5738976.html
Bug#909120: camitk FTBFS: tests segfault (Bug #909120)
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
Bug#909120: camitk FTBFS: tests segfault (Bug #909120)
s/core/viewer/InteractiveViewer.cpp:192 #3 0x77f33533 in camitk::InteractiveViewer::getNewViewer(QString, camitk::InteractiveViewer::ViewerType) () at ./sdk/libraries/core/viewer/InteractiveViewer.cpp:90 #4 0x77f337c5 in camitk::InteractiveViewer::getViewer(QString) () at /usr/include/x86_64-linux-gnu/qt5/QtCore/qstring.h:953 #5 0x77f33b25 in camitk::InteractiveViewer::getAxialViewer() () at /usr/include/x86_64-linux-gnu/qt5/QtCore/qstring.h:953 #6 0x77efea2f in camitk::SingleImageComponent::initRepresentation() () at ./sdk/libraries/core/component/image/SingleImageComponent.cpp:94 #7 0x77efeb67 in camitk::SingleImageComponent::SingleImageComponent(camitk::Component*, camitk::Slice::SliceOrientation, QString const&, vtkSmartPointer) () at ./sdk/libraries/core/component/image/SingleImageComponent.cpp:58 #8 0x77ef5fbf in camitk::ImageComponent::buildImageComponents() () at /usr/include/vtk-6.3/vtkSmartPointer.h:26 #9 0x77ef8b4d in camitk::ImageComponent::setImageData(vtkSmartPointer, bool, camitk::ImageOrientationHelper::PossibleImageOrientations, vtkSmartPointer) () at ./sdk/libraries/core/component/image/ImageComponent.cpp:313 #10 0x7fffdb5f1df9 in VtkImageComponent::createComponent(QString const&) () at /usr/include/vtk-6.3/vtkSmartPointer.h:26 #11 0x7fffdb5f2905 in VtkImageComponent::VtkImageComponent(QString const&) () at ./sdk/components/vtkimage/VtkImageComponent.cpp:53 #12 0x7fffdb5f2f3a in VtkImageComponentExtension::open(QString const&) () at ./sdk/components/vtkimage/VtkImageComponentExtension.cpp:76 #13 0x77ec6c24 in camitk::Application::open(QString const&) () at ./sdk/libraries/core/application/Application.cpp:470 #14 0xb3df in main () at /usr/include/c++/8/bits/basic_string.h:2293 #15 0x76e90b17 in __libc_start_main (main=0xae80 , argc=5, argv=0x7fffeb58, init=, fini=, rtld_fini=, stack_end=0x7fffeb48) at ../csu/libc-start.c:310 #16 0xc1aa in _start () at ./sdk/applications/testactions/main.cpp:189 It is very strange as this specific call to vtkTextProperty::ShallowCopy never generated a segfault in any version of the code. Is this a problem linked with X11/OpenGL? This is where I am at the moment, nothing solved at all, but I wanted to let you know of this findings. I suspect something changed in one of the dependencies that generates this. I tried to check which package was modified recently and might have influence this. I found that xvfb might changed recently and I am currently rebuilding with an older version installed to checked (but that looks like groping my way along!) Andreas, do you have any smart way to check the list of packages that have changed/been uploaded in sid in the dependencies of a package during a period of time (here from 9 Sep to 15 Sep)? This might help me finding how to solve this. Thanks for your help again and hopefully this will be tackled down soon! Mahnu On 20/09/2018 20:59, Andreas Tille wrote: Control: tags -1 upstream Hi Bernhard, thanks a lot for your investigation. Emmanuel Promayon is Uploader and Upstream and I think he will come back to you and hopefully will implement the fix soon. Kind regards Andreas. On Thu, Sep 20, 2018 at 06:01:38PM +0200, Bernhard Übelacker wrote: Hello all, I tried to reproduce this issue. Unfortunately I never get the "(SEGFAULT)" output for all tests, just "(Failed)" for most. But some do really segfault in my amd64 VM. I think the segfaults are caused by the line "delete component;", that invalidates the iterator by removing its element from the components vector. For some reason the iterator contains still the previous pointer and therefore we try to delete the same pointer twice. Attached patch tries to change the loop assuming that the deleted element will always be removed inside the delete operation. With that patch I do not get any segfault, but still tests fail for some reason. Kind regards, Bernhard # Here we crash: (gdb) bt #0 0x0061 in ?? () #1 0x7fffeb32c0d6 in MultiComponent::deleteAllSubComponents (this=this@entry=0x56d98330) at ./modeling/libraries/pml/MultiComponent.cpp:50 #2 0x7fffeb32c11f in MultiComponent::~MultiComponent (this=0x56d98330, __in_chrg=) at ./modeling/libraries/pml/MultiComponent.cpp:41 #3 0x7fffeb32c149 in MultiComponent::~MultiComponent (this=0x56d98330, __in_chrg=) at ./modeling/libraries/pml/MultiComponent.cpp:38 #4 0x7fffeb32ce3a in PhysicalModel::clear (this=this@entry=0x55705ef0) at ./modeling/libraries/pml/PhysicalModel.cpp:99 #5 0x7fffeb32cf17 in PhysicalModel::~PhysicalModel (this=0x55705ef0, __in_chrg=) at ./modeling/libraries/pml/PhysicalModel.cpp:68 #6 0x7fffeb32cf59 in PhysicalModel::~PhysicalModel (this=0x55705ef0, __in_chrg=) at ./modeling/libraries/pml/
Bug#897715: link to #897899
This is the actual error (it occurs everytime the gcc changes its major version) ``` /usr/include/ITK-4.12/vcl_compiler.h:90:4: error: #error "Dunno about this gcc" # error "Dunno about this gcc" ``` This bug should probably be reassigned to src:insighttoolkit4 bug #897899 This is the same problem for #897756 #897759 and #897859 Thanks
Bug#853341: can not reproduce
Dear all, Now that gcc-7 is available directly in sid, I tried again using the following steps: 1. start from a clean sid 2. install g++-7 using |apt-get install -y g++-7| 3. setup gcc and g++ alternatives : |update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-6 10 update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-7 20 update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-6 10 update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-7 20 update-alternatives --install /usr/bin/cc cc /usr/bin/gcc 30 update-alternatives --set cc /usr/bin/gcc update-alternatives --install /usr/bin/c++ c++ /usr/bin/g++ 30 update-alternatives --set c++ /usr/bin/g++ update-alternatives --config gcc sudo update-alternatives --config g++ | 1. build the package (using |gbp buildpackage --git-ignore-new|) The package does not build and stop with this error: |... [ 52%] Building CXX object imaging/components/itkimage/CMakeFiles/component-itkimage.dir/ItkImageComponent.cpp.o cd /home/promayon/docker/camitk-debian/camitk-build/imaging/components/itkimage && /usr/bin/c++ -DITK_IO_FACTORY_REGISTER_MANAGER -DQT_CORE_LIB -DQT_GUI_LIB -DQT_HELP_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_OPENGLEXTENSIONS_LIB -DQT_OPENGL_LIB -DQT_UITOOLS_LIB -DQT_WIDGETS_LIB -DQT_XMLPATTERNS_LIB -DQT_XML_LIB -D_SCL_SECURE_NO_WARNINGS -Dcomponent_itkimage_EXPORTS -DvtkFiltersFlowPaths_AUTOINIT="1(vtkFiltersParallelFlowPaths)" -DvtkIOExodus_AUTOINIT="1(vtkIOParallelExodus)" -DvtkIOGeometry_AUTOINIT="1(vtkIOMPIParallel)" -DvtkIOImage_AUTOINIT="1(vtkIOMPIImage)" -DvtkIOParallel_AUTOINIT="1(vtkIOMPIParallel)" -DvtkIOSQL_AUTOINIT="2(vtkIOMySQL,vtkIOPostgreSQL)" -DvtkRenderingContext2D_AUTOINIT="1(vtkRenderingContextOpenGL)" -DvtkRenderingCore_AUTOINIT="3(vtkInteractionStyle,vtkRenderingFreeType,vtkRenderingOpenGL)" -DvtkRenderingFreeType_AUTOINIT="2(vtkRenderingFreeTypeFontConfig,vtkRenderingMatplotlib)" -DvtkRenderingLIC_AUTOINIT="1(vtkRenderingParallelLIC)" -DvtkRenderingVolume_AUTOINIT="1(vtkRenderingVolumeOpenGL)" -I/home/promayon/docker/camitk-debian/camitk-build/imaging/components/itkimage/component-itkimage_autogen/include -I/home/promayon/docker/camitk-debian/camitk-build/imaging/components/itkimage/ITKIOFactoryRegistration -I/usr/include/hdf5/serial -I/usr/include/dcmtk/dcmseg -I/usr/include/dcmtk/dcmfg -I/usr/include/dcmtk/dcmiod -I/usr/include/dcmtk/dcmrt -I/usr/include/dcmtk/dcmpstat -I/usr/include/dcmtk/dcmqrdb -I/usr/include/dcmtk/dcmwlm -I/usr/include/dcmtk/dcmsign -I/usr/include/dcmtk/dcmsr -I/usr/include/dcmtk/dcmnet -I/usr/include/dcmtk/dcmtls -I/usr/include/dcmtk/dcmjpls -I/usr/include/dcmtk/dcmjpeg -I/usr/include/dcmtk/dcmimage -I/usr/include/dcmtk/dcmimgle -I/usr/include/dcmtk/dcmdata -I/usr/include/dcmtk/oflog -I/usr/include/dcmtk/ofstd -I/usr/include/dcmtk/config -I/usr/include/x86_64-linux-gnu -I/usr/include/nifti -I/usr/include/gdcm-2.6 -I/usr/include/double-conversion -isystem /usr/include/ITK-4.10 -I/usr/include/vtk-6.3 -I/usr/include/freetype2 -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent/include -I/usr/lib/x86_64-linux-gnu/openmpi/include -I/usr/include/python2.7 -I/usr/include/hdf5/openmpi -I/usr/include/libxml2 -I/usr/include/jsoncpp -I/usr/include/tcl -I/home/promayon/docker/camitk-debian/camitk-build/include/camitk-4.0 -I/home/promayon/docker/camitk-debian/camitk-build/include/camitk-4.0/libraries -I/home/promayon/docker/camitk-debian/camitk-build/include/camitk-4.0/libraries/qtpropertybrowser -I/home/promayon/docker/camitk-debian/camitk-build/include/camitk-4.0/libraries/camitkcore -I/home/promayon/.config/CamiTK/include/camitk-4.0 -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem /usr/include/x86_64-linux-gnu/qt5/QtWidgets -isystem /usr/include/x86_64-linux-gnu/qt5/QtGui -isystem /usr/include/x86_64-linux-gnu/qt5/QtCore -isystem /usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++-64 -isystem /usr/include/x86_64-linux-gnu/qt5/QtXml -isystem /usr/include/x86_64-linux-gnu/qt5/QtXmlPatterns -isystem /usr/include/x86_64-linux-gnu/qt5/QtNetwork -isystem /usr/include/x86_64-linux-gnu/qt5/QtHelp -isystem /usr/include/x86_64-linux-gnu/qt5/QtUiTools -isystem /usr/include/x86_64-linux-gnu/qt5/QtOpenGL -isystem /usr/include/x86_64-linux-gnu/qt5/QtOpenGLExtensions -I/home/promayon/docker/camitk-debian/camitk-build/imaging/components/itkimage -I/home/promayon/docker/camitk-debian/imaging/components/itkimage -g -O2 -fdebug-prefix-map=/home/promayon/docker/camitk-debian=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++11 -w -fPIC -fPIC -fPIC -std=gnu++11 -o CMakeFiles/component-itkimage.dir/ItkImageComponent.cpp.o -c /home/promayon/docker/camitk-debian/imaging/components/itkimage/ItkImageComponent.cpp
Bug#848815: camitk: FTBFS: make[2]: *** [sdk/libraries/core/CMakeFiles/library-camitkcore.dir/all] Error 2
On 21/12/16 09:39, Adrian Bunk wrote: On Tue, Dec 20, 2016 at 10:55:33AM +0100, Andreas Tille wrote: Hi Emmanuel, just to make sure you noticed this RC critical error. On Mon, Dec 19, 2016 at 10:29:47PM +0100, Lucas Nussbaum wrote: Source: camitk Version: 4.0.4-1 Severity: serious Tags: stretch sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20161219 qa-ftbfs Justification: FTBFS on amd64 Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Relevant part (hopefully): I admit I have nothing in this extract to get a clue about the problem. make[2]: *** [sdk/libraries/core/CMakeFiles/library-camitkcore.dir/all] Error 2 The full build log is available from: http://aws-logs.debian.net/2016/12/19/camitk_4.0.4-1_unstable.log Most probably you need to inspect the full log ... The error is: make[3]: *** No rule to make target '/usr/lib/libmpi.so', needed by 'lib/libcamitkcore.so.4.0.4'. Stop. That's #848785 in libvtk6-dev, I'll merge this bug with the others. Thank you Andreas and Adrian. I was just about to post a comment and say that the error can be seen at line 30981 of the full log and is probably link with #848793 in libvtk6-dev. Thank you Adrian for the bug merge. I suppose it will be seen as FTBS in all the packages that depends on libvtk6-dev to build. What can I do to help from here? Best regards, Emmanuel
Bug#836990: libcamitk4: fails to upgrade from 'jessie' - trying to overwrite /usr/bin/camitk-config
On 06/10/16 22:53, Adrian Bunk wrote: Note that coninstallable implies either renaming /usr/bin/camitk-config, or moving it to a libcamitk-bin package (depending on whether it is specific for one libcamitk version or usable with all). Yes, thank you Adrian. This was discussed and explained to me by Mattia on the debian-med-packaging mailing list (see [1] for example). My intention is to add a new package "camitk-config" that just contains the binary, the man page and the pixmap. Everything was just commited to git. I am testing it at the moment and if everything is alright, I will ask for an upload very soon. Kind regards, Emmanuel [1] http://lists.alioth.debian.org/pipermail/debian-med-packaging/2016-October/046452.html smime.p7s Description: S/MIME Cryptographic Signature
Bug#836990: libcamitk4: fails to upgrade from 'jessie' - trying to overwrite /usr/bin/camitk-config
Dear Andreas, Thank you for this bug report. I will try to fix this as well as packaging the new release (that fixes an OpenGL rendering problem on laptop when using integrated card). I am planning to have this done soonish (hopefully by the end of september, I am new to packaging with git and would like to do it properly). I am also planning, following Gianfranco Costamagna's advice to remove the SONAME number in the package name. Namely libqtpropertybrowser4-dev will be replaced by libqtpropertybrowser-dev and libcamitk4-dev by libcamitk-dev. Is this ok with you? Is it the right time? For uniformity sake, should I do the same for the non -dev suffixed package (e.g. libcamitk4 -> libcamitk)? FYI we are not planning to support two different versions (e.g., 3 and 4). Emmanuel smime.p7s Description: S/MIME Cryptographic Signature
Bug#798167: camitk and vtk/itk transitions
On 27/04/16 02:03, Mattia Rizzolo wrote:
From there I am not quite sure how to ask for an upload using the
"experimental" branch (or should experimental be first merged to master?)
Not sure what Gianfranco already told you, but the "experimental" branch
was created mainly to allow the maintainers (=> you) to check it out
before putting it to master.
And let me say, that you shouldn't really be afraid to commit stuff to
the git repository! It's just a git repository, after all: very easy to
revert or discard even.
Understood. It is just that in the private (well inferred!) follow-up
with Gianfranco (which was very useful to me), I send an email to ask
him if he was ok with the idea of me commiting directly to the origin
experimental branch. Once I realized that he would most certainly not
object, it was too late: I had asked him, and felt bound to my question.
I will not hesitate next time.
Lintian still gives two types of warnings (repeated multiple times):
1) libcamitk4-data: package-contains-timestamped-gzip
For these ones, I think the best is to redo the gzip upstream (and therefore
wait for the next upstream to clean this)
This is weird. That warning is produced only for tarballs with a gzip
timestamp that is after the date in d/changelog: that means that the .gz
is created at build time.
I couldn't find any gzip(1) call in all the sources of camitk, but:
mattia@chase ~/devel/TEAM/camitk/camitk (git)-[master] % rgrep
--exclude-dir=.git 'tar '
sdk/cmake/ctest/nightly.cmake:# %APPDATA%\MySoft\Star Runner.ini
sdk/cmake/ctest/nightly.cmake:# $HOME/.config/MySoft/Star Runner.ini
sdk/cmake/modules/macros/camitk/packaging/CamiTKOpenSourcePackaging.cmake:#! To
make a source tar ball, just use the custom target camitk_package_sourc
sdk/cmake/modules/macros/camitk/packaging/CamiTKCEPPackaging.cmake:COMMAND ${CMAKE_COMMAND} -E
tar cvz "${CMAKE_BINARY_DIR}/${CEP_PACKAGE_NAME}" "${CEP_PACKAGING_DIR}/"
sdk/cmake/modules/CamiTKConfig.cmake.in:# %APPDATA%\MySoft\Star Runner.ini
sdk/cmake/modules/CamiTKConfig.cmake.in:# $HOME/.config/MySoft/Star
Runner.ini
sdk/libraries/qtpropertybrowser/INSTALL.TXT:tar xvf some-package.tar
Of those, this one is relevant, I think:
sdk/cmake/modules/macros/camitk/packaging/CamiTKCEPPackaging.cmake:COMMAND ${CMAKE_COMMAND} -E
tar cvz "${CMAKE_BINARY_DIR}/${CEP_PACKAGE_NAME}" "${CEP_PACKAGING_DIR}/"
There, iit creates a tar.gz at build time, I think.
See https://wiki.debian.org/ReproducibleBuilds/TimestampsInGzipHeaders
for some bits on that. Basically you need to pass the -n option to
gzip, which can be done either by setting the GZIP variable, or by
piping the tar output through gzip, like
tar cv blabla_stuff_to_tar_up | gzip -n -f blalba_tarball.tar.gz
the GZIP variable has (sadly) been declared obsolete by upstream, and we
don't know for how long it'll be around, therefore I suggest to
implement the piping thing, but YMMV.
This is weird, you are right, because:
1) the affected gzip files are just .gz (not tar.gz) provided in the
upstream tarball and are not modified at build time. They are just
copied to share/
2) CamiTKCEPPackaging.cmake is not called during build, so we can rule
this out.
And in fact this tar command is a cmake function (it is not the tar from
the command line, although it probably call it in the end).
Running:
file imaging/components/itkimage/testdata/BigEndianCompressed.img.gz
returns:
imaging/components/itkimage/testdata/BigEndianCompressed.img.gz: gzip
compressed data, last modified: Tue Mar 4 17:11:43 2003, max
compression, from Unix
So I suppose that as this gzip files were produced back in 2003, they
are time stamped, which probably
I did not found the code exected by lintian to produce this warning,
which could have confirmed this.
I ran:
gzip -9n imaging/components/itkimage/testdata/BigEndianCompressed.img
and then
file imaging/components/itkimage/testdata/BigEndianCompressed.img.gz
returns:
imaging/components/itkimage/testdata/BigEndianCompressed.img.gz: gzip
compressed data, max compression, from Unix
(with no time stamp)
Then, after temporarily adding the file in source/include-binaries, the
package build correctly and the error disappeared.
The gzip will be cleaned in the next upstream version, so the lintian
warning should disappear.
2) debug-file-with-no-debug-symbols for all *-dbgsym package
For this one, I am a bit puzzled. I am not sure at all what causes this
error. Is it because the package is build using the "--builddirectory"
option:
dh $@ --builddirectory=camitk-build
and all the .debug files end up in another (non default) directory?
no, it's not that. It's usually because one builds with -g or something
like that. I'm sorry I can't give more directions on this right now.
Ok, I will try to find information about this (any hint welcome).
And you also have a bunch of informational tags (mostly related to
hardening not being enabled, and a lot
Bug#798167: camitk and vtk/itk transitions
On 24/04/16 18:30, Mattia Rizzolo wrote: On Sun, Apr 24, 2016 at 05:56:00PM +0200, Emmanuel Promayon wrote: > I checked Gianfranco's experimental branch and his work is great! > There is few build-depend packages that can be removed (and I noticed > the problem with the pixmaps), but this would be my pleasure to fix > that very soon. cool! If you could fine some minutes to trimmer the build-deps, etc would be awesome. I managed to do some work on polishing the package, and once Gianfranco has agree, I will pull everything to the "experimental" branch. From there I am not quite sure how to ask for an upload using the "experimental" branch (or should experimental be first merged to master?) Thanks to Gianfranco tip, I used gbp buildpackage --git-debian-branch=experimental --git-ignore-new I used a docker sid image (which might not be the best, but was at hand on my machine)... and the packages were build. All the 441 post-build tests passed as well. I also updated the autopkgtest script, and it should work as well (although I could not run adt-run or puiparts in docker) Lintian still gives two types of warnings (repeated multiple times): 1) libcamitk4-data: package-contains-timestamped-gzip For these ones, I think the best is to redo the gzip upstream (and therefore wait for the next upstream to clean this) 2) debug-file-with-no-debug-symbols for all *-dbgsym package For this one, I am a bit puzzled. I am not sure at all what causes this error. Is it because the package is build using the "--builddirectory" option: dh $@ --builddirectory=camitk-build and all the .debug files end up in another (non default) directory? Note: I tried to use dh $@ with the --parallel option in d/r, but gbp buildpackage seemed oblivious to it. > I agree that the display bug, although a priority for upstream, > should not delay any debian cleaning up. everything started by wanting to remove libpng12. And then we noticed in how such a bad state unstable was wrt cruft. For some reason or the other, camitk is entangled in *all* of them; we have a pad where we are tracking everything, and camitk is on all the sections :\ Wooah... No pressure then! Your explanation has accelerated the process and put this packaging task on top of my urgent task list... Hope this will help remove camitk from the bad books... > Therefore, I hereby declare that what Gianfranco did is great and > blessed! Thanks you very much! > If Gianfranco and everyone else is ok with it (I did not have time to > check the packaging here), it would be great if it can be uploaded > directly in unstable. \o/ Great! One of us will get to it very soon :) (guess Gianfranco, as he did most/all of the work) OK. I will wait to Gianfranco agreement before I pull my commits to the experimental branch (I asked him if he was ok with it). > In the next few weeks, hopefully upstream 4.0.1 will solve the display > bug and I can polish the packaging. In the meantime I'll file a RC bug for it, so it'll stay out of testing, and all the involved parties can notice this version is partially not working. Great! Thanks. > Thanks you again all for your work, it is amazing how every time > there is something new to learn! There is still more ;) :-) smime.p7s Description: S/MIME Cryptographic Signature
Bug#798167: [Debian-med-packaging] Bug#798167: camitk and vtk/itk transitions
Dear all, I am just back from vacation and sorry for my silence during last week. On 20/04/16 23:21, Mattia Rizzolo wrote: On Wed, Apr 20, 2016 at 10:12:45PM +0200, Tobias Frost wrote: > (If you go for experimental, please reopen the RM bug for the binaries > in sid once it enters the archives) In the case this goes to experimental the right kind of thing to do is to completely remove it from unstable (sources included). This might seems harsh, but it's really not :) But I'm not sure what would be the problem of having it on experimental: if the only problem this thing has is that it misrenders images on some cards, then I'd say to upload this version to unstable, and block it there with another RC bug on it, and treat it as a separate bug. I know voluntarily introducing a bug is bad, but I'd weight it against *this* bug, and keeping in mind we're talking about debian *unstable*. Maintainers, what do you think? Can you prepare an upload, maybe based on Gianfranco's work? Or either say that what he did is "Great And Blessed" and confirm that you're cool with us uploading it? :) And tell us what you prefers between uploading the new in experimental and removing the current one from unstable or uploading this directly to unstable. I am only a beginner in packaging, and I completely trust Mattia, Tobias, Andreas and Gianfranco knowledge and experience. I checked Gianfranco's experimental branch and his work is great! There is few build-depend packages that can be removed (and I noticed the problem with the pixmaps), but this would be my pleasure to fix that very soon. I agree that the display bug, although a priority for upstream, should not delay any debian cleaning up. Unfortunately I will not be able to work on the package (not at least for another week and a half). Therefore, I hereby declare that what Gianfranco did is great and blessed! Thanks you very much! If Gianfranco and everyone else is ok with it (I did not have time to check the packaging here), it would be great if it can be uploaded directly in unstable. In the next few weeks, hopefully upstream 4.0.1 will solve the display bug and I can polish the packaging. Thanks you again all for your work, it is amazing how every time there is something new to learn! Emmanuel -- Emmanuel Promayon, Maitre de conférences Univ. Grenoble Alpes / Polytech Grenoble Laboratoire TIMC-IMAG / équipe GMCAO Tel. +33/0 456 52 00 03 smime.p7s Description: S/MIME Cryptographic Signature
Bug#798167: [Debian-med-packaging] Bug#798167: camitk: depends on vtk 5
Hi again, Thank you both for your inputs. Mattia is right, I think it is the same problem that occurred in #821091. The bug was "solved" by reverting back to Qt4. Thank you very much Gert for this tip about the vtk macro! We were wondering what the magic made gdcm-vtk package compile on sid with no error while we had a lot of problem with the macros (I checked d/patches and the vtk d/r files, but missed this). Now the mistery is explained, thank you! I also tried VTK 6.3 and QVTKWidget3 [1] as you suggested as well, but to no avail. I tried the upstream QVTKWidget2 version, and it works very well for the integrated card... but it does not working with the nvidia GPU! So I might be able to produce a mix between the 6.3 QVTKWidget version and the upstream QVTKWidget2 version that can work for both integrated and nvidia GPU. As I said to Gianfranco, on the #817163 thread, unfortunately, I will not be able to work on the packaging before the beginning of May. I don't want camitk to block any transition, so if it is ok with everyone, I agreed to his suggestion of temporarily removing camitk from sid. I pushed my last files on the git (not ready yet), for information. A working camitk 4 package should not be too long to be back. Thank you again for all your support and ideas! Emmanuel [1] http://stackoverflow.com/questions/26944831/using-qvtkwidget-and-qopenglwidget-in-the-same-ui On 17/04/16 12:57, Gert Wollny wrote: Hello, while moving to VTK 6 please take into account that we are preparing a transition to VTK 6.3. Compared to VTK 6.2 version 6.3 removes some deprecated macros and removes the module "vtkRenderingFreeTypeOpenGL". You should be able to catch most of the problems related to macros by compiling with VTK_LEGACY_REMOVE defined. VTK 6.3 is available from experimental. Best, Gert -- Emmanuel Promayon, Maitre de conférences Univ. Grenoble Alpes / Polytech Grenoble Laboratoire TIMC-IMAG / équipe GMCAO Tel. +33/0 456 52 00 03 smime.p7s Description: S/MIME Cryptographic Signature
Bug#817163: [sanv...@debian.org: Bug#817163: camitk: FTBFS when built with dpkg-buildpackage -A (191 tests failed out of 191)]
Dear Gianfranco, Thank you for your email and your files. I did some work on it as well, and you are right the 4.0.0 should not be too difficult to package. At the moment I am concentrating on removing a bug that makes camitk not usable on laptop (see #798167). I did not realize that camitk was blocking the update of insight-toolkit and/or vtk packages, sorry. I commited the first changes (not dissimilar to the one you send) on the git master branch, but did not finished to check everything. As I am new to packaging using git, I will probably need more time than usual to complete the package. Unfortunately, I will not be able to work on the packaging before the beginning of May. It this is too long to wait, and you want to move on with the decruft, please proceed with the temporary removal of camitk. Hopefully it won't be long after that to have the camitk package back on sid (and on testing!) Again, thank you for your work... Emmanuel On 17/04/16 10:17, Gianfranco Costamagna wrote: Hi, please note that this bug is blocking the decruft of the old itk. I did import the latest beta version, and tried to build it. (I'm attaching the packaging to this email) Except for some failures in dh_install everything was good so far. Can you please update to the beta at least and close all the RC bugs? otherwise since we want vtk to be removed I think we will be forced to ask a temporary removal of this package from unstable. thanks for understanding, Gianfranco On Wed, 23 Mar 2016 08:51:40 +0100 Andreas Tille <andr...@an3as.eu> wrote: Thanks for your bug housekeeping - that's really appreciated. :-) Kind regards Andreas. On Wed, Mar 23, 2016 at 07:36:56AM +0100, Emmanuel Promayon wrote: Thank you to Santiago for this bug report and thank you to Andreas for the fix! Here is the patch I applied to d/rules: 78c78 < override_dh_auto_test: --- override_dh_auto_test-arch: We are now waiting for the next upstream release (planned to be released soon) and will then apply this change to the next package version. I therefore will mark this bug pending for now. Kind regards, Emmanuel ___ Debian-med-packaging mailing list debian-med-packag...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging -- http://fam-tille.de smime.p7s Description: S/MIME Cryptographic Signature
Bug#798167: camitk: depends on vtk 5
Hello Mattia and all, I am currently working on fixing a blocking bug in CamiTK 4.0.0. The transition to Qt5 and VTK6 is finished, and everything seems to be working ok, apart from a complex OpenGL problem [1]. This is why I am cc-ing debian-med mailing list. Basically we noticed that: - QVTKWidget (a class that gives a way to have an VTK renderer in a Qt widget) has a problem with the z-buffer on integrated cards (i915 driver) - QVTKWidget2 (that seems to be the future, and use OpenGL directly), is not yet fully operational (OpenGL context does not seemed to be initialized properly) The consequence is that we end-up with display problems on Linux systems using an intel integrated cars (= a lot of configuration!). This was checked also with VTK 6.3.0 + Qt 5.3.2, as well as on sid (VTK 6.2.0 and Qt 5.5.1). A strange OpenGL behaviour was also observed on Mac. At the moment I am trying some last faint hope solution (basically patching QVTKWidget2 with upstream VTK code)... If anyone else has some insight about problem with integrated cards Qt 5 and VTK 6, I will be delighted! - Concerning your question Mattia, unfortunately, I won't be able to work on it too much in the next two weeks, but hopefully at the beginning of may I will be able to finish the packaging, even if it includes this bug. Just to let you know, on the positive side: the source code compile and all the tests pass using a sid docker and the upstream code. So the main difficulty will be to learn how to use git for the packaging! Cheers, Mahnu [1] https://bugzilla-timc.imag.fr/show_bug.cgi?id=181 (this contains a lot of reference to other people who seem to have this problem) On 15/04/16 19:28, Mattia Rizzolo wrote: On Tue, Mar 22, 2016 at 06:35:44PM +0100, Emmanuel Promayon wrote: > Just to add some updated information about this bug. > > We are currently working on camitk 4.0, that should be released hopefully > very soon (the target is before the end of March). > > CamiTK 4.0 has the exact same features as CamiTK 3.5 (released at the end of > January 2016) but updates the dependencies to Qt5, Vtk6, Itk4 and cmake 3, > and make sure it is compatible with gcc5/cxx-11. This is cool. I saw camitk 4.0 has been released, can you please also work on updating the debian package now? smime.p7s Description: S/MIME Cryptographic Signature
Bug#817163: [sanv...@debian.org: Bug#817163: camitk: FTBFS when built with dpkg-buildpackage -A (191 tests failed out of 191)]
Thank you to Santiago for this bug report and thank you to Andreas for the fix! Here is the patch I applied to d/rules: 78c78 < override_dh_auto_test: --- > override_dh_auto_test-arch: We are now waiting for the next upstream release (planned to be released soon) and will then apply this change to the next package version. I therefore will mark this bug pending for now. Kind regards, Emmanuel smime.p7s Description: S/MIME Cryptographic Signature
Bug#794740: camitk: please make the build reproducible (timestamps)
Thanks you very much for your bug and your fix! Sorry for the long silence. Your fix is going to be integrated directly in the next upstream version, that should be released very soon. Kind regards, Emmanuel smime.p7s Description: S/MIME Cryptographic Signature
Bug#816805: CamiTK moving to Qt5
Just to add some updated information about this bug. We are currently working on camitk 4.0, that should be released hopefully very soon (the target is before the end of March). CamiTK 4.0 has the exact same features as CamiTK 3.5 (released at the end of January 2016) but updates the dependencies to Qt5, Vtk6, Itk4 and cmake 3, and make sure it is compatible with gcc5/cxx-11. Code written with the 3.4 or 3.5 API would have to be alter a bit to take the dependency updates into account, but apart from few include differences, should work with 4.0 Therefore we hope to fix this bug very soon! Emmanuel smime.p7s Description: S/MIME Cryptographic Signature
Bug#798167: camitk: depends on vtk 5
Just to add some updated information about this bug. We are currently working on camitk 4.0, that should be released hopefully very soon (the target is before the end of March). CamiTK 4.0 has the exact same features as CamiTK 3.5 (released at the end of January 2016) but updates the dependencies to Qt5, Vtk6, Itk4 and cmake 3, and make sure it is compatible with gcc5/cxx-11. Code written with the 3.4 or 3.5 API would have to be alter a bit to take the dependency updates into account, but apart from few include differences, should work with 4.0 Therefore we hope to fix this bug very soon! Emmanuel smime.p7s Description: S/MIME Cryptographic Signature
Bug#747421: camitk: please enable parallel building
Dear Aurélien, did you have any time to consider my objections about activating the parallel build by default? If this is ok with you, I will tag this bug as 'wontfix' for now. Let me know quickly if you have a better idea... Best regards, EP smime.p7s Description: S/MIME Cryptographic Signature
Bug#758130: camitk: Fail of tests in debci (autopkgtest)
Dear Lucas and Andreas, thank you very much for your report and the patch! I am just back from holidays and I will consider it quickly. It is a good idea to simplify the test script using the different parts of the expectedConfigOutput argument. The number of extensions varies with the version (hopefully always increasing!), so I might leave the two if blocks. The best would be to use the if block only to test the number of extensions. Andreas, FYI, the script version on the svn include the correct test (for CamiTK 3.3.2). I will check everything is ok with the current sid and check if everything works for the next vtk version (considering auto-vtk transition [1]) I also have to close bug 747421 (I did not had any answer from the bug submitter) [2]. Regards, EP [1] https://release.debian.org/transitions/html/auto-vtk.html [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747421 -- Emmanuel Promayon UJF-Grenoble 1, CNRS, TIMC-IMAG UMR 5525 (équipe GMCAO) Institut de l'Ingénierie de l'Information de Santé Faculté de Médecine - 38706 La Tronche cedex - France Tel. +33/0 456 52 00 03 - Fax. +33/0 456 52 00 55 - B7 smime.p7s Description: S/MIME Cryptographic Signature
Bug#747421: camitk: please enable parallel building
Dear Aurélien, thank you very much for your bug report. I tried to enable the parallel build in a previous version (3.2.1-1, see changelog), but it failed to build on some plateforms with small amount of RAM. It generated an out of memory error when compiling the medical imaging feature of CamiTK, which is mainly based on ITK (Insight ToolKit) filters, which themselves are intensively based on C++ templates. For instance, on my machine, with -j=9, the compilation needs more than 8Gb of RAM. Since 3.2.2-1 the parallel build is disabled (see also the debian/rules, where I added some comments in the % rule). All plateforms seem to be able to end the build without an error now, although I completely agree with you: it takes a oooggg time. The only way to fix this would be to enable parallel build only when there is enough RAM. I am quite a novice, so here are my questions: * Do you know anyway to estimate the amount of memory needed by a compilation? * Do you know if it is possible to check the available memory in d/r and add some kind of test to enable or not parallel build depending on the answer? Best regards, EP smime.p7s Description: S/MIME Cryptographic Signature
Bug#714935: libvtk5-dev: VTKTargets.cmake adds dependency to other packages (tcl-vtk, python-vtk and libvtk-java)
Package: libvtk5-dev Version: 5.8.0-13+b1 Severity: normal Dear Maintainer, I have the following FTBFS when I try a building camitk packages using pbuilder (DIST=unstable, arch=amd64, using svn-buildpackage): CMake Error at /usr/lib/vtk-5.8/VTKTargets.cmake:308 (message): The imported target vtkWrapTcl references the file /usr/bin/vtkWrapTcl but this file does not exist. Possible reasons include: * The file was deleted, renamed, or moved to another location. * An install or uninstall procedure did not complete successfully. * The installation package was faulty and contained /usr/lib/vtk-5.8/VTKTargets.cmake but not all the files it references. Call Stack (most recent call first): /usr/lib/vtk-5.8/VTKConfig.cmake:200 (INCLUDE) /usr/share/cmake-2.8/Modules/FindVTK.cmake:73 (find_package) /usr/lib/gdcm-2.2/UseGDCM.cmake:23 (FIND_PACKAGE) /usr/lib/InsightToolkit/UseITK.cmake:100 (INCLUDE) sdk/cmake/modules/macros/CamiTKOpenSourcePackaging.cmake:108 (include) CMakeLists.txt:29 (camitk_opensource_packaging) -- Configuring incomplete, errors occurred! dh_auto_configure: cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_SKIP_RPATH:BOOL=ON -DCMAKE_INSTALL_RPATH SE_LINK_PATH:BOOL=OFF -DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo -DCEP_IMAGING:BOOL=TRUE -DCEP_MODELING:BOOL=TRUE -DAPIDOC_SDK:BOOL=TRUE -DCAMITK_DICOM_INCOMPLETE_SUPPO :BOOL=ON returned exit code 1 make[1]: *** [override_dh_auto_configure] Error 2 make[1]: Leaving directory `/tmp/buildd/camitk-3.2.0' make: *** [build] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 E: Failed autobuilding of package W: no hooks of type C found -- ignoring I: unmounting /var/cache/pbuilder/repo filesystem I: unmounting dev/pts filesystem I: unmounting proc filesystem I: cleaning the build env I: removing directory /var/cache/pbuilder/build//37371 and its subdirectories Command '/bin/sh -c pdebuild --buildresult /homelocal/gmcao/desktop/promayon /debian-med/trunk/../build-area ' failed in '/homelocal/gmcao/desktop/promayon /debian-med/ ild-area/camitk-3.2.0', how to continue now? [Qri?]: q This can be fixed by adding tcl-vtk as a dependency in camitk d/control Build- Depends list. But then it generates a similar error for missing /usr/bin/vtkWrapPython and /usr/bin/vtkParseJava, which in turn can be fixed by adding respectively python-vtk and libvtk-java in the Build-Depends list. Although this can be fixed, it also adds unnecessary dependencies to the package. Please let me know if you need more information about this bug, or if this seems completely normal. When I checked solved bugs, I found bug #663571. It might be linked (i.e., the fix to #663571 might lead to a similar solution to fix this). Best regards (and thanks for all your work on vtk packaging!) EP -- System Information: Debian Release: 7.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/6 CPU cores) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libvtk5-dev depends on: ii libavcodec-dev 6:0.8.6-1 ii libavformat-dev6:0.8.6-1 ii libavutil-dev 6:0.8.6-1 ii libc6-dev 2.13-38 ii libexpat1-dev [libexpat-dev] 2.1.0-1 ii libfreetype6-dev 2.4.9-1.1 ii libgl1-mesa-dev [libgl-dev]8.0.5-4 ii libgl2ps-dev 1.3.6-1 ii libglu1-mesa-dev [libglu-dev] 8.0.5-4 ii libjpeg8-dev [libjpeg-dev] 8d-1 ii libmysqlclient-dev 5.5.31+dfsg-0+wheezy1 ii libnetcdf-dev 1:4.1.3-6+b1 ii libpng12-dev [libpng-dev] 1.2.49-1 ii libpq-dev 9.1.9-1 ii libqt4-dev 4:4.8.2+dfsg-11 ii libswscale-dev 6:0.8.6-1 ii libtiff4-dev [libtiff-dev] 3.9.6-11 ii libvtk5.8 5.8.0-13+b1 ii libx11-dev 2:1.5.0-1 ii libxft-dev 2.3.1-1 ii libxml2-dev2.8.0+dfsg1-7+nmu1 ii libxss-dev 1:1.2.2-1 ii libxt-dev 1:1.1.3-1 ii mpi-default-dev1.0.1 ii tcl8.5-dev 8.5.11-2 ii tk8.5-dev 8.5.11-2 ii x11proto-core-dev 7.0.23-1 ii zlib1g-dev 1:1.2.7.dfsg-13 libvtk5-dev recommends no packages. Versions of packages libvtk5-dev suggests: ii vtk-doc 5.8.0-13 ii vtk-examples 5.8.0-13 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701250: [Debian-med-packaging] Bug#701250: Camitk Debian package needs some love [was: Candidates for removal from testing (2013-06-30)]
Dear Andreas, I commited changes on the debian-med svn to update the camitk package for the new upstream release (version 3.2 should fix this RC bug). Everything was ok compiling on stable, but when using an unstable pbuilder environment, I ran into a vtk dependency problem and submitted a bug [1] (or that what it seems to be from my perspective). I also had to override some lintian warnings (I tried to comment the litian override files as much as I could). Let me know if the changes (including the changelog modifications) seems ok to updload the new version. Thanks in advance, Emmanuel [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714935 On 01/07/13 14:11, Emmanuel Promayon wrote: Sounds like a reasonable plan. The only thing that would deserve some enhancement for the future is that it helps if you publish this plan straight to the bug report a bit earlier because this saves us from developing heart attacks in fearing to loose a package in testing. ;-) Duly noted. Sorry for wasting some of your time (and your heart!) by not writing my intention about bugs (especially this RC bugs). In fact I wanted to do that much earlier (before the 3.2 release) and publish a patch, which I see now might have been a better way. I am still learning a lot thanks to debian-med (and still in my MoM in fact!). Thank you again for your work and vigilance! Emmanuel ___ Debian-med-packaging mailing list debian-med-packag...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging -- Emmanuel Promayon UJF-Grenoble 1, CNRS, TIMC-IMAG UMR 5525 (équipe GMCAO) Institut de l'Ingénierie de l'Information de Santé Faculté de Médecine - 38706 La Tronche cedex - France Tel. +33/0 456 52 00 03 - Fax. +33/0 456 52 00 55 - B7 smime.p7s Description: S/MIME Cryptographic Signature
Bug#701250: Camitk Debian package needs some love [was: Candidates for removal from testing (2013-06-30)]
libavg Dmitry E. Oboukhov un...@debian.org avinfo (U) Emmanuel Promayon emmanuel.proma...@imag.fr camitk (U) Enrico Tassi gareuselesi...@debian.org freepops Eric Dorland e...@debian.org granule Fabrizio Regalli fab...@fabreg.it flush Filippo Rusconi lopi...@debian.org massxpert (U) Graziano Obertelli grazi...@eucalyptus.com dnsjava (U) Guy Coates g...@sanger.ac.uk dapl (U) sdpnetstat (U) Ian Beckwith i...@debian.org gnulib Janos Guljas ja...@resenje.org python-django-localeurl Javier Fernandez-Sanguino Pen~a j...@debian.org xorp (U) Jens Peter Secher j...@debian.org sml-mode Jo Shields direct...@apebox.org monodevelop-debugger-gdb (U) Joachim Wiedorn ad_deb...@joonet.de capi4hylafax Jon Ludlam jonathan.lud...@eu.citrix.com xcp-vncterm (U) Jonas Smedegaard d...@jones.dk sipwitch toonloop (U) Jose Calhariz jose.calha...@tagus.ist.utl.pt xorp Julian Gilbey j...@debian.org epix Julien Dutheil julien.duth...@univ-montp2.fr bppsuite (U) Julien Puydt julien.pu...@laposte.net pynac (U) Kartik Mistry kar...@debian.org falconpl Kilian Krause kil...@debian.org libccaudio2 (U) Kyo Lee kyo@eucalyptus.com dnsjava (U) Leo Iannacone l...@ubuntu.com ion Leonardo Robol l...@robol.it clinica (U) Loic Dachary l...@dachary.org bppsuite Loïc Minier l...@debian.org mach Luca Bruno lu...@debian.org gcc-msp430 Ludovic Brenta lbre...@debian.org ada-reference-manual Luis Rivas Vañó lui...@gmail.com sitplus (U) Luke Yelavich luke.yelav...@canonical.com qt-at-spi (U) Makoto Yamashita makoto.yamash...@is.titech.ac.jp sdpa Mario Lang ml...@debian.org dapl (U) emacs-chess sdpnetstat (U) Mark Purcell m...@debian.org libccaudio2 (U) Matej Vela v...@debian.org libhttp-daemon-ssl-perl Mathieu Malaterre ma...@debian.org pixelmed (U) Michael Banck mba...@debian.org cp2k (U) nwchem (U) Michael Fladischer fladischermich...@fladi.at django-celery (U) django-floppyforms (U) Michael Hanke michael.ha...@gmail.com psychtoolbox-3 (U) Michael Hanke m...@debian.org odin (U) Michael Janssen jamu...@debian.org player Michael Tautschnig m...@debian.org cbmc diagnostics Mickael Profeta prof...@debian.org prelude-lml (U) prelude-manager (U) Miguel Landaeta mig...@miguel.cc openjpa (U) Mike Gabriel mike.gabr...@das-netzwerkteam.de kiwix (U) Mirco Bauer mee...@debian.org monodevelop-debugger-gdb (U) Miriam Ruiz mir...@debian.org xmlcopyeditor NeuroDebian Team t...@neuro.debian.net odin psychtoolbox-3 Nicholas Bamber nicho...@periapt.co.uk libdevel-bt-perl (U) Nicolas Delvaux cont...@nicolas-delvaux.org totem-plugin-arte Nobuhiro Iwamatsu iwama...@debian.org openvrml (U) OFED and Debian Developement and Discussion pkg-ofed-de...@lists.alioth.debian.org dapl sdpnetstat OHURA Makoto oh...@debian.org oneliner-el Oleksandr Moskalenko ma...@debian.org bashdb Onkar Shinde onkarshi...@ubuntu.com cdk (U) OXullo Intersecans x...@brainrapers.org libavg (U) Peter Eisentraut pet...@debian.org orafce postgresql-pljava Peter Howard p...@northern-ridge.com.au zoneminder Peter Palfrader wea...@debian.org tiobench Peter S Galbraith p...@debian.org gri Petter Reinholdtsen p...@debian.org tetex-brev Pierre Chifflier pol...@debian.org prelude-lml prelude-manager sslsniff Pierre-Louis Bonicoli pierre-louis.bonic...@gmx.fr bip PKG-Xen Devel pkg-xen-de...@lists.alioth.debian.org xcp-vncterm Reinhard Tartler siret...@tauware.de aspectc++ Robert Lemmen rober...@semistable.com eukleides Roberto C. Sanchez robe...@connexer.com pion-net (U) Roberto Lumbreras ro...@debian.org geotranz Sam Hocevar (Debian packages) sam+...@zoy.org openvrml Samuel Thibault sthiba...@debian.org qt-at-spi (U) Stanislav Maslovski stanislav.maslov...@gmail.com avinfo Steffen Moeller moel...@debian.org libiscwt-java (U) Stig Sandbeck Mathisen s...@debian.org mod-gearman TANIGUCHI Takaki tak...@debian.org clam-chordata (U) The Debichem Group debichem-de...@lists.alioth.debian.org massxpert Thomas Bushnell, BSG t...@debian.org ifhp jacal Thomas Goirand z...@debian.org xcp-vncterm (U) Thomas Günther t...@toms-cafe.de vdr-plugin-xine (U) Thomas Schmidt tschm...@debian.org vdr-plugin-xine (U) Tiziano Zito opossumn...@gmail.com mdp Tobias Grimm et...@debian.org vdr-plugin-xine (U) Torsten Werner twer...@debian.org libavg (U) Ulises Vitulli der...@debian.org mailavenger Vagrant Cascadian vagr...@debian.org zoneminder (U) Vasudev Kamath kamathvasu...@gmail.com falconpl (U) kiwix (U) Yann Dirson dir...@debian.org fweb Yaroslav Halchenko deb...@onerussian.com mdp (U) odin (U) psychtoolbox-3 (U) remake Youhei SASAKI
Bug#701250: Camitk Debian package needs some love [was: Candidates for removal from testing (2013-06-30)]
Sounds like a reasonable plan. The only thing that would deserve some enhancement for the future is that it helps if you publish this plan straight to the bug report a bit earlier because this saves us from developing heart attacks in fearing to loose a package in testing. ;-) Duly noted. Sorry for wasting some of your time (and your heart!) by not writing my intention about bugs (especially this RC bugs). In fact I wanted to do that much earlier (before the 3.2 release) and publish a patch, which I see now might have been a better way. I am still learning a lot thanks to debian-med (and still in my MoM in fact!). Thank you again for your work and vigilance! Emmanuel -- Emmanuel Promayon UJF-Grenoble 1, CNRS, TIMC-IMAG UMR 5525 (équipe GMCAO) Institut de l'Ingénierie de l'Information de Santé Faculté de Médecine - 38706 La Tronche cedex - France Tel. +33/0 456 52 00 03 - Fax. +33/0 456 52 00 55 - B7 smime.p7s Description: S/MIME Cryptographic Signature
Bug#689951: Package appears to be non-free
Dear Andreas, I personally would be happy if you would decide for the later because in addition you get a lot of other information and how people might deal together with other problems. After my answer yesterday I subscribed to the CamiTK package only, but reading your answer, I just reconsidered and subscribed to debian-med mailing-list as it seems the best option to improve my learning curve. In this case would CamITK remain in *main*! Considering the fact that you know all these facts - would you volunteer to do the needed steps? I am on a tight schedule this week. Do you think it could be ok if: - I remove the licence offending part of the CamiTK source for the moment (the tetgen plugin) today - I do a better work at the beginning of next week where I could reintroduce the tetgen plugin but using the tetgen debian package instead and correct the two other bugs properly (#689021 and 690830) For #690830 there is a patch proposal and there is also a another way that I would like to try first (that will probably have better compiler specific/multi-arch support). Thanks again, all your help is really appreciated. -- Emmanuel Promayon UJF-Grenoble 1, CNRS, TIMC-IMAG UMR 5525 (équipe GMCAO) Institut de l'Ingénierie de l'Information de Santé Faculté de Médecine - 38706 La Tronche cedex - France Tel. +33/0 456 52 00 03 - Fax. +33/0 456 52 00 55 - B7 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690830: other suggestion?
Thank you very much Konstantinos for your bug report and patch! I think there is another way to fix the bug that seems (to me, but I am a beginner) more architecture independent, and I would like to know if anyone has an opinion about it. Instead of using Konstantinos suggested patch, which consist in modify debian/rules, an alternative way would be to add something like this directly in the corresponding CMakeLists.txt include(TestCXXAcceptsFlag) check_cxx_accepts_flag(-fPIC HAS_FPIC_FLAG) if(HAS_FPIC_FLAG) set_property(TARGET qtpropertybrowser APPEND PROPERTY COMPILE_FLAGS -fPIC) endif() It checks first if the fPIC flag is accepted by the compiler and then adds it. I am not sure it will make a difference for other architectures supported by debian. What do you think? -- Emmanuel Promayon UJF-Grenoble 1, CNRS, TIMC-IMAG UMR 5525 (équipe GMCAO) Institut de l'Ingénierie de l'Information de Santé Faculté de Médecine - 38706 La Tronche cedex - France Tel. +33/0 456 52 00 03 - Fax. +33/0 456 52 00 55 - B7 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689951: Package appears to be non-free
Hi Andreas, If you can remove it upstream this would probably the bes solution. Please note the following: The Debian Release team does not accept new upstream versions for Wheezy in general. So if the change should be successfull for propagation to Wheezy please make prfectly sure that this change is the only one compared to the tarball currently in testing. So you culd do something like camitk-3.0.2.1.tar.gz and mention in the upstream changelog something like - Just removed parts of code which are not DFSG free (no other code changes In the debian/changelog we could refer to the fact mentioned in your upstream changelog to convince the release team that we do not attempt to sneak in new upstream code. Otherwise we would need to backport the changes to the version inside Debian. (In case my advise was not clear enough feel free to ask for further clarification.) May be I was not fully clear. If we drop the tetgen dependency completely (and if I understood correctly the plugin in queston needs to be dropped / deactivated as well) then and only than camitk can remain in Debian main. If there is some dependency from any non-free component (be it tetgen or whatever) the package needs to be moved from main to contrib which is something I would like to avoid. So the action to let camitk remain in main is the following: 1. Remove tetgen fom the upstream tarball (may be also cut the plugin in question as well if it does not make any sense without tetgen). 2. Build a camitk package targeting at main from this source tarball. Would it not be possible/preferable/easier to convince the release team to remove the non-free code as a debian package patch? If not, as at the moment the upstream changelog is not very visible, should I add a specific news on the web page to explain what happened between camitk-3.0.2.1.tar.gz and camitk-3.0.2.tar.gz? To gain full functionality we could gain (for Wheezy+1) optionally with 3. Create another source tarball camitk-plugins (or camitk-plugins-non-dfsg or whatever name). 4. Build an according Debian package from this plugins tarball linking with Debian packaged tetgen targeting at contrib and recommending camitk from main 5. You can Suggests camitk-plugins in the camitk package (but not Recommends, which is only allowed inside main) That sounds like the perfect idea. For #690830 there is a patch proposal and there is also a another way that I would like to try first (that will probably have better compiler specific/multi-arch support). This could be done if you are pretty sure about this and the change is obviosely simple and straight to get accepted by the release team. While it is a really good thing to fix this bug we need to make pretty sure it will not introduce new problems (which is the sense of the freeze process). For the time line: I think doing step 1.+2. from above until end of October is fine. Everything else has time because it does not affect the current release. Is this doable for you? Yes, I think there is no problem to do that between now and the end of the month. -- Emmanuel Promayon UJF-Grenoble 1, CNRS, TIMC-IMAG UMR 5525 (équipe GMCAO) Institut de l'Ingénierie de l'Information de Santé Faculté de Médecine - 38706 La Tronche cedex - France Tel. +33/0 456 52 00 03 - Fax. +33/0 456 52 00 55 - B7 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690830: other suggestion?
Dear Andreas, do you think it is preferable if we target inclusion in Wheezy to: - use Konstantinos patch or - try my other suggestion or - do nothing as it is taking too much risks to break something else? Kind regards, On 24/10/12 09:55, Andreas Tille wrote: Hi Emmanuel, On Wed, Oct 24, 2012 at 08:59:52AM +0200, Emmanuel Promayon wrote: Thank you very much Konstantinos for your bug report and patch! I think there is another way to fix the bug that seems (to me, but I am a beginner) more architecture independent, and I would like to know if anyone has an opinion about it. Instead of using Konstantinos suggested patch, which consist in modify debian/rules, an alternative way would be to add something like this directly in the corresponding CMakeLists.txt include(TestCXXAcceptsFlag) check_cxx_accepts_flag(-fPIC HAS_FPIC_FLAG) if(HAS_FPIC_FLAG) set_property(TARGET qtpropertybrowser APPEND PROPERTY COMPILE_FLAGS -fPIC) endif() It checks first if the fPIC flag is accepted by the compiler and then adds it. I am not sure it will make a difference for other architectures supported by debian. What do you think? Just judging from your explanation (read: without deeper knowledge of cmake) this sounds to be a more reasonable fix for the problem. Any comment of a porter of the architectures in question to verify that it works as intended would be welcome. Kind regards Andreas. -- Emmanuel Promayon UJF-Grenoble 1, CNRS, TIMC-IMAG UMR 5525 (équipe GMCAO) Institut de l'Ingénierie de l'Information de Santé Faculté de Médecine - 38706 La Tronche cedex - France Tel. +33/0 456 52 00 03 - Fax. +33/0 456 52 00 55 - B7 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690830: other suggestion?
Dear Andreas, However, I just noticed that camitk is not yet in testing anyway so the release team is not involved at all (we just introduced it to late after the freeze date). So in one hand you can more or less forget my safety means to do only a minimum change inside the source code (see the other bug report) and even include new code if you have a new upstream version ready and you can also apply your change for this bug - in case it does not really work or break something else we have a couple of more shots at this target inside unstable. Sorry if I gave a bit picky advise under my wrong assumption that current camitk is a candidate for Wheezy release. This also means that you might feel free to relax the deadline a bit - but fixing bugs as quick as possible is always a good thing. That is in fact a good news: it means I will have a bit more time to to things properly upstream first, as described in your points #1 to #5 in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689951#50 (remove the incriminated code from the main tarball and build a specific camitk-plugins-non-free tarball and debian package), try the direct CMakeLists.txt modification to remove problem due to position independant code (see bug #690830), and use the latest upstream code. I will still try to start to work on it next week. Kind regards -- Emmanuel Promayon UJF-Grenoble 1, CNRS, TIMC-IMAG UMR 5525 (équipe GMCAO) Institut de l'Ingénierie de l'Information de Santé Faculté de Médecine - 38706 La Tronche cedex - France Tel. +33/0 456 52 00 03 - Fax. +33/0 456 52 00 55 - B7 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689951: Package appears to be non-free
Hello Andreas, First sorry for not commenting on the bug, I have to find a better way to interact with the process, and thank you for all the comments. The use of tetgen is not a fundamental feature of CamiTK (and anyway less important than being in contrib). Therefore the code depending on it can be either removed completely from the CamiTK package (this is an additional plugin). And the use of the debian packaged version is an even better solution, as you suggested. In this case will CamiTK remain in contrib? What is my deadline to do this without offending anyone? Kind regards, On 23/10/12 16:32, Andreas Tille wrote: Hi Emmanuel, the package camitk received a release critical bug[1] which you possibly did not noticed. It would be great if you would read the history of the bug log[1] and comment on the usage of Debian packaged tetgen which would enable us to move the package to contrib rather than non-free. Please note that the package will be removed from Debian if we do not find a reasonable solution. Kind regards Andreas. [1] http://bugs.debian.org/689951 On Mon, Oct 08, 2012 at 01:56:43PM +0200, Andreas Tille wrote: On Mon, Oct 08, 2012 at 12:12:35PM +0200, Mathieu Malaterre wrote: Actually all I did noticed is that tetgen is in non-free in debian already: http://packages.qa.debian.org/t/tetgen.html It might make sense to verify whether a removal of tetgen from camitk and rather use the Debian packaged version is possible which would make camitk rather contrib than non-free. Christophe are you in touch with upstream ? Even if Charles mentioned that there are other non-free pieces in the license contacting upstream about a DFSG free license might not harm in anyway. Kind regards Andreas. -- Emmanuel Promayon UJF-Grenoble 1, CNRS, TIMC-IMAG UMR 5525 (équipe GMCAO) Institut de l'Ingénierie de l'Information de Santé Faculté de Médecine - 38706 La Tronche cedex - France Tel. +33/0 456 52 00 03 - Fax. +33/0 456 52 00 55 - B7 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682107: ITP: libcamitk3 -- Computer Assisted Medical Intervention Tool Kit - runtime
Package: wnpp Severity: wishlist Owner: Emmanuel Promayon emmanuel.proma...@imag.fr * Package name: libcamitk3 Version : 3.0.2 Upstream Author : Emmanuel Promayon emmanuel.proma...@imag.fr, Celine Fouard celine.fou...@imag.fr * URL : http://camitk.imag.fr/ * License : LGPL Programming Lang: C++ Description : Computer Assisted Medical Intervention Tool Kit - runtime Helps researchers and clinicians to easily and rapidly collaborate in order to prototype CAMI applications, that feature medical images, surgical navigation and biomechanical simulations. . This package contains the shared libraries needed to run CamiTK applications. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682109: ITP: camitk-imp -- flagship application for the CamiTK library
Package: wnpp Severity: wishlist Owner: Emmanuel Promayon emmanuel.proma...@imag.fr * Package name: camitk-imp Version : 3.0.2 Upstream Author : Emmanuel Promayon emmanuel.proma...@imag.fr, Celine Fouard celine.fou...@imag.fr * URL : http://camitk.imag.fr * License : LGPL Programming Lang: C++ Description : flagship application for the CamiTK library CamiTK Helps researchers and clinicians to easily and rapidly collaborate in order to prototype CAMI applications, that feature medical images, surgical navigation and biomechanical simulations. . imp is the CamiTK flagship application. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682110: ITP: libcamitk3-dev -- Computer Assisted Medical Intervention Tool Kit - development
Package: wnpp Severity: wishlist Owner: Emmanuel Promayon emmanuel.proma...@imag.fr * Package name: libcamitk3-dev Version : 3.0.2 Upstream Author : Emmanuel Promayon emmanuel.proma...@imag.fr, Celine Fouard celine.fou...@imag.fr * URL : http://camitk.imag.fr/ * License : LGPL Programming Lang: C++ Description : Computer Assisted Medical Intervention Tool Kit - development Helps researchers and clinicians to easily and rapidly collaborate in order to prototype CAMI applications, that feature medical images, surgical navigation and biomechanical simulations. . This package contains development files needed to build CamiTK applications. This package also provides the CamiTK wizard to create new extensions. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682111: ITP: imp is the flagship application for the Computer Assisted Medical Intervention Tool Kit (libcamitk)
Package: camitk-imp Version: 3.0.2 Severity: wishlist Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these lines *** Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Emmanuel Promayon promayon@mannoni To: Debian Bug Tracking System sub...@bugs.debian.org Subject: ITP: camitk-imp -- Flagship application for the Computer Assisted Medical Intervention Tool Kit Message-ID: 20120719124205.6118.54445.reportbug@mannoni X-Mailer: reportbug 6.3.1ubuntu1 Date: Thu, 19 Jul 2012 14:42:05 +0200 X-Debbugs-Cc: debian-de...@lists.debian.org Package: wnpp Severity: wishlist Owner: Emmanuel Promayon emmanuel.proma...@imag.fr * Package name: camitk-imp Version : 3.0.2 Upstream Author : Emmanuel Promayon emmanuel.proma...@imag.fr, Celine Fouard celine.fou...@imag.fr * URL : http://camitk.imag.fr/ * License : LGPL Programming Lang: C++ Description : flagship application for the Computer Assisted Medical Intervention Tool Kit (libcamitk) CamiTK Helps researchers and clinicians to easily and rapidly collaborate in order to prototype CAMI applications, that feature medical images, surgical navigation and biomechanical simulations. . imp is the CamiTK flagship application. -- System Information: Debian Release: wheezy/sid APT prefers precise-updates APT policy: (500, 'precise-updates'), (500, 'precise-security'), (500, 'precise'), (100, 'precise-backports') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-26-generic (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682112: ITP: libcamitk3-data -- Computer Assisted Medical Intervention Tool Kit - data
Package: wnpp Severity: wishlist Owner: Emmanuel Promayon emmanuel.proma...@imag.fr * Package name: libcamitk3-data Version : 3.0.2 Upstream Author : Emmanuel Promayon emmanuel.proma...@imag.fr, Celine Fouard celine.fou...@imag.fr * URL : http://camitk.imag.fr/ * License : LGPL Programming Lang: C++ Description : Computer Assisted Medical Intervention Tool Kit - data Helps researchers and clinicians to easily and rapidly collaborate in order to prototype CAMI applications, that feature medical images, surgical navigation and biomechanical simulations. . This package contains the example and test data for CamiTK. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682113: ITP: libcamitk3-doc -- Computer Assisted Medical Intervention Tool Kit - documentation
Package: wnpp Severity: wishlist Owner: Emmanuel Promayon emmanuel.proma...@imag.fr * Package name: libcamitk3-doc Version : 3.0.2 Upstream Author : Emmanuel Promayon emmanuel.proma...@imag.fr, Celine Fouard celine.fou...@imag.fr * URL : http://camitk.imag.fr/ * License : LGPL Programming Lang: C++ Description : Computer Assisted Medical Intervention Tool Kit - documentation Helps researchers and clinicians to easily and rapidly collaborate in order to prototype CAMI applications, that feature medical images, surgical navigation and biomechanical simulations. . This package contains the documentation for CamiTK. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682111: thanks
You are completely right. Sorry for this submission and the waste of your time. The correct ITP submission corresponding is #682109 see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682109 -- Emmanuel Promayon UJF-Grenoble 1, CNRS, TIMC-IMAG UMR 5525 (équipe GMCAO) Institut de l'Ingénierie de l'Information de Santé Faculté de Médecine - 38706 La Tronche cedex - France Tel. +33/0 456 52 00 03 - Fax. +33/0 456 52 00 55 - B7 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
