Bug#789931: tag this as wontfix/severity normal
Thanks, Gert I would recommend moving to itksnap 3.4 as soon as possible. This is a much "better" release. One caveat for 3.4 is that on Linux it should be built against qt4, not qt5. Thanks! Paul On Mon, Jan 11, 2016 at 5:48 AM, Gert Wollny wrote: > tags 789931 wontfix > severity 789931 severity > thanks > > The bug was reported against version 2.2.0 which is outdated, version > 3.2.0 now builds find on all architectures that are supported by the > insighttoolkit4. > > On the other hand, the bug reports build failure on arm64 - this is an > arch that is not (yet) supported by insighttoolkit4 and the arch > support depends on upstream. Hence the downgrade and tag. > > Bast, > Gert > > -- Paul A. Yushkevich, Ph.D. Associate Professor Penn Image Computing and Science Laboratory Department of Radiology University of Pennsylvania
Bug#789931: itksnap: FTBFS in unstable
It looks like the ITK-SNAP build does not find the ITK directory. This is a pretty outdated version, we are up to 3.2 now... Paul On Thu, Jun 25, 2015 at 12:38 PM, Edmund Grimley Evans < edmund.grimley.ev...@gmail.com> wrote: > Source: itksnap > Version: 2.2.0-1.1 > Severity: serious > > You can see the log from the recent build failure on arm64 here: > > https://buildd.debian.org/status/package.php?p=itksnap&suite=sid > > I got the same error on amd64. > > -- Paul A. Yushkevich, Ph.D. Associate Professor Penn Image Computing and Science Laboratory Department of Radiology University of Pennsylvania
Bug#698386: Is there a future for ITKSNAP?
I just pushed a commit in the dev32 branch that includes a CMAKE flag SNAP_PACKAGE_QT_PLUGINS. Setting this to off should disable the search for plugins. Thanks! Paul On Thu, Oct 23, 2014 at 12:27 PM, Paul Yushkevich wrote: > Oh... Weird. Could you try without the space after -D? > > Thanks! > > On Thu, Oct 23, 2014 at 12:05 PM, Michael Hanke wrote: > >> Hi, >> >> On Thu, Oct 23, 2014 at 11:57:19AM -0400, Paul Yushkevich wrote: >> > Hi Michael, >> > >> > I am confused :) >> > >> > You previously mentioned that the file >> > /usr/lib/x86_64-linux-gnu/cmake/Qt5/Qt5Config.cmake >> > exists on the system >> > >> > I was suggesting to set the prefix path to >> /usr/lib/x86_64-linux-gnu/cmake >> > - so that directory should exist >> >> Sorry, I was sloppy. The directory exists, but it doesn't have cmake >> files: >> >> % cmake .. -D CMAKE_PREFIX_PATH:STRING=/usr/lib/x86_64-linux-gnu/cmake >> CMake Error: The source directory "/usr/lib/x86_64-linux-gnu/cmake" does >> not appear to contain CMakeLists.txt. >> Specify --help for usage, or press the help button on the CMake GUI. >> >> % ll /usr/lib/x86_64-linux-gnu/cmake >> total 72K >> drwxr-xr-x 2 root root 4,0K Okt 12 10:06 PulseAudio/ >> drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5/ >> drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5Concurrent/ >> drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5Core/ >> drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5DBus/ >> drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5Gui/ >> drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5Network/ >> drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5OpenGL/ >> drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5OpenGLExtensions/ >> drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5PrintSupport/ >> drwxr-xr-x 2 root root 4,0K Okt 15 14:33 Qt5Qml/ >> drwxr-xr-x 2 root root 4,0K Okt 15 14:33 Qt5Quick/ >> drwxr-xr-x 2 root root 4,0K Okt 15 14:33 Qt5QuickTest/ >> drwxr-xr-x 2 root root 4,0K Okt 15 14:33 Qt5QuickWidgets/ >> drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5Sql/ >> drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5Test/ >> drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5Widgets/ >> drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5Xml/ >> >> > I am happy to add a CMake flag that will disable the search for the >> > plugins. We need the plugins when packaging ITK-SNAP binaries using make >> > package. Otherwise if a system does not already have Qt installed, the >> user >> > is hosed. >> >> That would be good. For the Debian package we can specify any runtime >> dependencies in the binary package (if they aren't already explicit from >> the linker output). It sounds like that would fulfil all requirements of >> itksnap. >> >> >> Michael >> >> > > > -- > Paul A. Yushkevich, Ph.D. > Associate Professor > Penn Image Computing and Science Laboratory > Department of Radiology > University of Pennsylvania > -- Paul A. Yushkevich, Ph.D. Associate Professor Penn Image Computing and Science Laboratory Department of Radiology University of Pennsylvania
Bug#698386: Is there a future for ITKSNAP?
Oh... Weird. Could you try without the space after -D? Thanks! On Thu, Oct 23, 2014 at 12:05 PM, Michael Hanke wrote: > Hi, > > On Thu, Oct 23, 2014 at 11:57:19AM -0400, Paul Yushkevich wrote: > > Hi Michael, > > > > I am confused :) > > > > You previously mentioned that the file > > /usr/lib/x86_64-linux-gnu/cmake/Qt5/Qt5Config.cmake > > exists on the system > > > > I was suggesting to set the prefix path to > /usr/lib/x86_64-linux-gnu/cmake > > - so that directory should exist > > Sorry, I was sloppy. The directory exists, but it doesn't have cmake > files: > > % cmake .. -D CMAKE_PREFIX_PATH:STRING=/usr/lib/x86_64-linux-gnu/cmake > CMake Error: The source directory "/usr/lib/x86_64-linux-gnu/cmake" does > not appear to contain CMakeLists.txt. > Specify --help for usage, or press the help button on the CMake GUI. > > % ll /usr/lib/x86_64-linux-gnu/cmake > total 72K > drwxr-xr-x 2 root root 4,0K Okt 12 10:06 PulseAudio/ > drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5/ > drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5Concurrent/ > drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5Core/ > drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5DBus/ > drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5Gui/ > drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5Network/ > drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5OpenGL/ > drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5OpenGLExtensions/ > drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5PrintSupport/ > drwxr-xr-x 2 root root 4,0K Okt 15 14:33 Qt5Qml/ > drwxr-xr-x 2 root root 4,0K Okt 15 14:33 Qt5Quick/ > drwxr-xr-x 2 root root 4,0K Okt 15 14:33 Qt5QuickTest/ > drwxr-xr-x 2 root root 4,0K Okt 15 14:33 Qt5QuickWidgets/ > drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5Sql/ > drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5Test/ > drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5Widgets/ > drwxr-xr-x 2 root root 4,0K Okt 15 14:30 Qt5Xml/ > > > I am happy to add a CMake flag that will disable the search for the > > plugins. We need the plugins when packaging ITK-SNAP binaries using make > > package. Otherwise if a system does not already have Qt installed, the > user > > is hosed. > > That would be good. For the Debian package we can specify any runtime > dependencies in the binary package (if they aren't already explicit from > the linker output). It sounds like that would fulfil all requirements of > itksnap. > > > Michael > > -- Paul A. Yushkevich, Ph.D. Associate Professor Penn Image Computing and Science Laboratory Department of Radiology University of Pennsylvania
Bug#698386: Is there a future for ITKSNAP?
Hi Michael, I am confused :) You previously mentioned that the file /usr/lib/x86_64-linux-gnu/cmake/Qt5/Qt5Config.cmake exists on the system I was suggesting to set the prefix path to /usr/lib/x86_64-linux-gnu/cmake - so that directory should exist I am happy to add a CMake flag that will disable the search for the plugins. We need the plugins when packaging ITK-SNAP binaries using make package. Otherwise if a system does not already have Qt installed, the user is hosed. Thanks! Paul On Thu, Oct 23, 2014 at 11:40 AM, Michael Hanke wrote: > On Thu, Oct 23, 2014 at 11:26:50AM -0400, Paul Yushkevich wrote: > > Please try cmake ... -D CMAKE_PREFIX_PATH:STRING=/usr/lib/ > > x86_64-linux-gnu/cmake > > > > And let me know if that works any better. > > No, it doesn't -- such a directory doesn't exist. > > I believe the CMake setup assumes a rigidity of a Qt5 installation that > does not match the actual installation of the Debian (Ubuntu, Mint,...) > system > Qt5. > > Michael > > > > -- > Michael Hanke > http://mih.voxindeserto.de > -- Paul A. Yushkevich, Ph.D. Associate Professor Penn Image Computing and Science Laboratory Department of Radiology University of Pennsylvania
Bug#698386: Is there a future for ITKSNAP?
Michael Please try cmake ... -D CMAKE_PREFIX_PATH:STRING=/usr/lib/ x86_64-linux-gnu/cmake And let me know if that works any better. Thanks! Paul On Thu, Oct 23, 2014 at 10:50 AM, Michael Hanke wrote: > On Thu, Oct 23, 2014 at 10:43:56AM -0400, Paul Yushkevich wrote: > > I am not quite sure where on the Debian system Qt cmake files are, but I > > think you should be able to find them using > > > > locate Qt5Config.cmake > > The file is here: > > /usr/lib/x86_64-linux-gnu/cmake/Qt5/Qt5Config.cmake > > > On Thu, Oct 23, 2014 at 10:43 AM, Paul Yushkevich < > pau...@mail.med.upenn.edu > > > Please try setting the CMAKE_PREFIX_PATH to > > > [PATH_TO_QT_INSTALLATION]/lib/cmake > > > > > > In my case that's /opt/Qt/5.3/gcc_64/lib/cmake > > I tried > > cmake .. -DCMAKE_PREFIX_PATH=/usr/lib/x86_64-linux-gnu/cmake/Qt5 > > and a bunch of other variants, but the problem persists. > > Michael > > > -- > Michael Hanke > http://mih.voxindeserto.de > -- Paul A. Yushkevich, Ph.D. Associate Professor Penn Image Computing and Science Laboratory Department of Radiology University of Pennsylvania
Bug#698386: Is there a future for ITKSNAP?
I am not quite sure where on the Debian system Qt cmake files are, but I think you should be able to find them using locate Qt5Config.cmake Thanks! Paul On Thu, Oct 23, 2014 at 10:43 AM, Paul Yushkevich wrote: > Hi Michael, > > Please try setting the CMAKE_PREFIX_PATH to > [PATH_TO_QT_INSTALLATION]/lib/cmake > > In my case that's /opt/Qt/5.3/gcc_64/lib/cmake > > This can be provided to Cmake with the -D command, or set in the > environment. > > Please let me know if that helps > > Thanks! > paul > > On Thu, Oct 23, 2014 at 10:22 AM, Michael Hanke wrote: > >> Hi, >> >> On Tue, Oct 21, 2014 at 08:42:50AM -0400, Paul Yushkevich wrote: >> > That's great to hear! As far as the CMAKE_PREFIX_PATH, I set it to >> > /opt/Qt/5.3/gcc_64/lib/cmake. In my case, Qt is installed to /opt/Qt. I >> am >> > not quite sure why the VTK and GDCM are becoming an issue in the debian >> > build, perhaps ITK and VTK are configured slightly differently from the >> way >> > I have them configured. >> >> I tried building today's dev32 branch, but the QT plugin issue remains. >> >> CMake Error at CMakeLists.txt:1135 (get_property): >> get_property could not find TARGET Qt5::QXcbIntegrationPlugin. Perhaps >> it >> has not yet been created. >> CMake Error at CMakeLists.txt:1136 (get_property): >> get_property could not find TARGET Qt5::QGifPlugin. Perhaps it has not >> yet >> been created. >> >> I do have the relevant package installed and the plugins are present: >> >> /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so >> /usr/lib/x86_64-linux-gnu/qt5/plugins/imageformats/libqgif.so >> >> Any idea what needs to be done to help cmake find them? >> >> Michael >> > > > > -- > Paul A. Yushkevich, Ph.D. > Associate Professor > Penn Image Computing and Science Laboratory > Department of Radiology > University of Pennsylvania > -- Paul A. Yushkevich, Ph.D. Associate Professor Penn Image Computing and Science Laboratory Department of Radiology University of Pennsylvania
Bug#698386: Is there a future for ITKSNAP?
Hi Michael, Please try setting the CMAKE_PREFIX_PATH to [PATH_TO_QT_INSTALLATION]/lib/cmake In my case that's /opt/Qt/5.3/gcc_64/lib/cmake This can be provided to Cmake with the -D command, or set in the environment. Please let me know if that helps Thanks! paul On Thu, Oct 23, 2014 at 10:22 AM, Michael Hanke wrote: > Hi, > > On Tue, Oct 21, 2014 at 08:42:50AM -0400, Paul Yushkevich wrote: > > That's great to hear! As far as the CMAKE_PREFIX_PATH, I set it to > > /opt/Qt/5.3/gcc_64/lib/cmake. In my case, Qt is installed to /opt/Qt. I > am > > not quite sure why the VTK and GDCM are becoming an issue in the debian > > build, perhaps ITK and VTK are configured slightly differently from the > way > > I have them configured. > > I tried building today's dev32 branch, but the QT plugin issue remains. > > CMake Error at CMakeLists.txt:1135 (get_property): > get_property could not find TARGET Qt5::QXcbIntegrationPlugin. Perhaps > it > has not yet been created. > CMake Error at CMakeLists.txt:1136 (get_property): > get_property could not find TARGET Qt5::QGifPlugin. Perhaps it has not > yet > been created. > > I do have the relevant package installed and the plugins are present: > > /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so > /usr/lib/x86_64-linux-gnu/qt5/plugins/imageformats/libqgif.so > > Any idea what needs to be done to help cmake find them? > > Michael > -- Paul A. Yushkevich, Ph.D. Associate Professor Penn Image Computing and Science Laboratory Department of Radiology University of Pennsylvania
Bug#698386: Is there a future for ITKSNAP?
Hi Gert, That's great to hear! As far as the CMAKE_PREFIX_PATH, I set it to /opt/Qt/5.3/gcc_64/lib/cmake. In my case, Qt is installed to /opt/Qt. I am not quite sure why the VTK and GDCM are becoming an issue in the debian build, perhaps ITK and VTK are configured slightly differently from the way I have them configured. I am going to bump the version to 3.2.0 today or tomorrow (making it an official release). It would be great if we could get this version into Debian instead of 3.2.0-rc2 Thanks! Paul On Tue, Oct 21, 2014 at 8:28 AM, Gert Wollny wrote: > On Tue, 2014-10-21 at 07:49 -0400, Paul Yushkevich wrote: > > Ok - it was an easy fix. I just checked it into dev32. Gert - could you > > please confirm that the code runs and builds now? > > Okay, when I can build it with the patches applied (disabling the search > for the plug-ins with cmake and added VTK/GDCM libraries). Then the > executable now starts properly, and I can load images and segmentation > etc. Looks great :) > > thanks > Gert > > -- Paul A. Yushkevich, Ph.D. Associate Professor Penn Image Computing and Science Laboratory Department of Radiology University of Pennsylvania
Bug#698386: Is there a future for ITKSNAP?
Ok - it was an easy fix. I just checked it into dev32. Gert - could you please confirm that the code runs and builds now? Thanks! Paul On Tue, Oct 21, 2014 at 6:58 AM, Paul Yushkevich wrote: > I'm getting the same error in QCoreApplication... Oddly, this happens in > Debian but not other OSs. > > Hope I can find a fix :) > > On Tue, Oct 21, 2014 at 6:38 AM, Gert Wollny wrote: > >> On Tue, 2014-10-21 at 06:31 -0400, Paul Yushkevich wrote: >> > A quick question about the plugins: when you build with Cmake, did you >> have >> > CMAKE_PREFIX_PATH set to point to the Qt5's lib/cmake directory? I think >> > this is the way the plugins get picked up. >> >> No, I didn't. >> >> >> > > > -- > Paul A. Yushkevich, Ph.D. > Associate Professor > Penn Image Computing and Science Laboratory > Department of Radiology > University of Pennsylvania > -- Paul A. Yushkevich, Ph.D. Associate Professor Penn Image Computing and Science Laboratory Department of Radiology University of Pennsylvania
Bug#698386: Is there a future for ITKSNAP?
I'm getting the same error in QCoreApplication... Oddly, this happens in Debian but not other OSs. Hope I can find a fix :) On Tue, Oct 21, 2014 at 6:38 AM, Gert Wollny wrote: > On Tue, 2014-10-21 at 06:31 -0400, Paul Yushkevich wrote: > > A quick question about the plugins: when you build with Cmake, did you > have > > CMAKE_PREFIX_PATH set to point to the Qt5's lib/cmake directory? I think > > this is the way the plugins get picked up. > > No, I didn't. > > > -- Paul A. Yushkevich, Ph.D. Associate Professor Penn Image Computing and Science Laboratory Department of Radiology University of Pennsylvania
Bug#698386: Is there a future for ITKSNAP?
Thanks, Gert, A quick question about the plugins: when you build with Cmake, did you have CMAKE_PREFIX_PATH set to point to the Qt5's lib/cmake directory? I think this is the way the plugins get picked up. I've set up a VM with Debian and am trying to build everything now. Paul On Tue, Oct 21, 2014 at 6:19 AM, Gert Wollny wrote: > Hello Paul, > > > > On Tue, 2014-10-21 at 04:45 -0400, Paul Yushkevich wrote: > > I am going to try looking into this problem this week. I have been > building > > on Centos, and there the Qt plugins are being picked up just fine. I > > suspect the crash is due to the missing plugin, but I am not sure. > The crash is within > > QCoreApplication::arguments () > > and it doesn't seem to crash reliable. Somehow I suspect that there is a > mixup in symbols resolution, i.e. I added code like: > > char *a = "lala"; > SNAPQApplication app(1, &a); > QStringList mylist = app.arguments(); > > and it crashes in this very call to app.arguments() without going > through the plug-in loading. I also call arguments() in the > SNAPQApplication() constructor to check it and there it doesn't cash. > > When I use valgrind*, then it reports "jump depends on un-initialized > values" within the final loop of QCoreApplication::arguments (), but > only outside the constructor. > > I can only guess that the upload of QT5 that came after the upload of > libvtk6-dev which depends on QT5 broke something and a binary upload of > vtk could help. > > > Could you tell me why including all VTK libs and GDCM libs was required? > I think not all VTK libs are required, but some symbols where missing, > and it was easier to add all libraries instead of finding out what is > really needed. There was also a symbol missing from GDCM. > > Note, that I worked with the dev32 branch. > > Best > Gert > > * valgrind reports a number of problems with the code. For some of them > I sent patches upstream, see > https://sourceforge.net/p/itk-snap/bugs/81/ > https://sourceforge.net/p/itk-snap/bugs/82/ > > > > -- Paul A. Yushkevich, Ph.D. Associate Professor Penn Image Computing and Science Laboratory Department of Radiology University of Pennsylvania
Bug#698386: Is there a future for ITKSNAP?
Hi Gert, I am going to try looking into this problem this week. I have been building on Centos, and there the Qt plugins are being picked up just fine. I suspect the crash is due to the missing plugin, but I am not sure. Could you tell me why including all VTK libs and GDCM libs was required? Thanks! Paul On Thu, Oct 16, 2014 at 7:33 AM, Gert Wollny wrote: > Hello Paul, > > in Debian we are currently at ITK 4.6 and VTK 6.1 and AFAICS this is > what will go into Jessie. Hence, if you could get a version released > that can be compiled with these two libraries, we could update it, > Note however, that the freeze for Jessie is only a few weeks away. > > > > Here is a table of version compatibility between versions of ITK-SNAP, > ITK, > > VTK and Qt. > > > http://www.itksnap.org/pmwiki/pmwiki.php?n=Documentation.BuildingITK-SNAP. > > With the latest dev32 branch I get > > get_property could not find TARGET Qt5::QXcbIntegrationPlugin. > Perhaps it has not yet been created. > > > CMake Error at CMakeLists.txt:1134 (get_property): > get_property could not find TARGET Qt5::QGifPlugin. Perhaps it has > not yet been created. > > and I just don't know whether this is a problem with itksnap not > properly searching or because the QT5 packages (>5.3) don't include > these plugins for some reason. I have > /usr/lib/x86_64-linux-gnu/qt5/plugins/imageformats/libqgif.so > and > /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so > > -- > > Well, after some fiddling I got the attached patch that makes it build. > > This patch does the following: > > * revert dd5b67 (this is where above plug-ins are searched for) > * Add a Find_package for gdcm and gdcmCommon to the link_libraries. > * Use all vtk libraries > > With this the software as of commit 32eaf0+patch builds with the warning > about libjpeg.so.62 and libjpeg.so.8 being pulled in at the same time > (The first is the fault of libtiff and should go away when a new > libtiff gets build against libjpeg.so.8 ) > > The resulting executable segfaults though: > > ./ITK-SNAP(_Z24SegmentationFaultHandleri+0x7b)[0x74b25b] > /lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0)[0x7f60494958d0] > /lib/x86_64-linux-gnu/libc.so.6(strlen+0x2a)[0x7f60272d4a3a] > > /usr/lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN16QCoreApplication9argumentsEv+0xb1)[0x7f6027df4b41] > > /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so(+0x3260f)[0x7f600caa160f] > > /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so(+0x32923)[0x7f600caa1923] > > /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so(+0x40f3c)[0x7f600caaff3c] > > /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so(+0x32061)[0x7f600caa1061] > /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5(_ZN14QWindowPrivate6createEb > +0x66)[0x7f602833a4b6] > > /usr/lib/x86_64-linux-gnu/libQt5OpenGL.so.5(_ZN10QGLContext13chooseContextEPKS_+0x133)[0x7f6029481423] > /usr/lib/x86_64-linux-gnu/libQt5OpenGL.so.5(_ZN10QGLContext6createEPKS_ > +0x26)[0x7f6029459c36] > > /usr/lib/x86_64-linux-gnu/libQt5OpenGL.so.5(_ZN9QGLWidget10setContextEP10QGLContextPKS0_b+0xaf)[0x7f6029480e8f] > > /usr/lib/x86_64-linux-gnu/libQt5OpenGL.so.5(_ZN16QGLWidgetPrivate11initContextEP10QGLContextPK9QGLWidget+0x7f)[0x7f602945e1cf] > > /usr/lib/x86_64-linux-gnu/libQt5OpenGL.so.5(_ZN9QGLWidgetC2EP7QWidgetPKS_6QFlagsIN2Qt10WindowTypeEE+0x10a)[0x7f602945df2a] > ./ITK-SNAP(_ZN19QtAbstractOpenGLBoxC1EP7QWidget+0xd)[0x7fa46d] > ./ITK-SNAP(_ZN16GenericSliceViewC2EP7QWidget+0x12)[0x7f4212] > ./ITK-SNAP(_ZN17Ui_SliceViewPanel7setupUiEP7QWidget+0x2154)[0x7ed1f4] > ./ITK-SNAP(_ZN14SliceViewPanelC1EP7QWidget+0x55)[0x7e6ad5] > ./ITK-SNAP(_ZN18Ui_MainImageWindow7setupUiEP11QMainWindow > +0x250b)[0x781c6b] > ./ITK-SNAP(_ZN15MainImageWindowC2EP7QWidget+0x64)[0x772f24] > ./ITK-SNAP(main+0x1c0)[0x744f00] > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f6027274b45] > ./ITK-SNAP[0x74b0f7] > > > > Best > Gert > > -- Paul A. Yushkevich, Ph.D. Associate Professor Penn Image Computing and Science Laboratory Department of Radiology University of Pennsylvania
Bug#698386: Is there a future for ITKSNAP?
Hi Michael Sorry that this is causing so much frustration. Unfortunately, ITK and VTK keep changing fairly rapidly, so code that compiles versus a certain version no longer compiles against older or later versions. Here is a table of version compatibility between versions of ITK-SNAP, ITK, VTK and Qt. http://www.itksnap.org/pmwiki/pmwiki.php?n=Documentation.BuildingITK-SNAP. Does this help? Thanks Paul On Wed, Oct 15, 2014 at 1:00 PM, Michael Hanke wrote: > Hi, > > I am reviving this old thread in order to bring it to an end. Everyone > who has expressed interest and/or frustration in the past is in CC > (incl. the relevant bug). > > Over the past month (or rather year) I have repeatedly tried to update > the itksnap package, and today I am giving up. ITK-SNAP has extremely > tight versioned dependencies on ITK and VTK. Making it work with any > current ITK version in Debian seems to require a lucky roll of the dice > (that would not come for me). As of today, neither the current stable > 3.2, nor the master branch head compiles in sid. At least for the first > I am pretty sure a version mismatch is the case (see e.g. [1]). > The actual reasons for FTBFS change over time, but the failure rate is > close to 100% for my attempts. > > My personal conclusion is that it makes no sense to maintain an itksnap > package independently of ITK. > > The package has a popcon score of 241 -- rather solid for a special > interest package of this kind (about half of what ITK3 had in its > prime). It would be a shame to see it go away. On the other hand > dragging an outdated version along forever is not an option. > > And to make it very clear: ITK-SNAP is a solid piece of software that I > have enjoyed using (and still do). The problem is solely a ridiculously > complex software interdependency problem, that makes long-term package > maintenance a nightmare. > > I have tagged the bug with "help". I see no reason to remove itksnap > from jessie, because this old version does what it was intended to do. > But for the next round we either need to find a better home, or we > should let it go. > > Cheers, > > Michael > > [1] https://groups.google.com/forum/#!topic/itksnap-users/2byPxMTS3Wo > > > > -- > Michael Hanke > http://mih.voxindeserto.de > > -- Paul A. Yushkevich, Ph.D. Associate Professor Penn Image Computing and Science Laboratory Department of Radiology University of Pennsylvania
