Bug#544674: [Debian-med-packaging] Bug#579959: gdcm: FTBFS on mipsel and armel, unable to find java
I have added a block by to : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544674 Hopefully things should be sorted out quickly as I see 544674 is marked as 'pending'. Thanks for report On Sun, May 2, 2010 at 6:26 PM, Julien Cristau jcris...@debian.org wrote: Package: gdcm Version: 2.0.14-5 Severity: serious Justification: no longer builds from source See https://buildd.debian.org/fetch.cgi?pkg=gdcmver=2.0.14-5arch=armelstamp=1272631069file=log and https://buildd.debian.org/fetch.cgi?pkg=gdcmver=2.0.14-5arch=mipselstamp=1272626721file=log This is a blocker for the vtk transition, so would be nice to have fixed soon. Cheers, Julien -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJL3afFAAoJEDEBgAUJBeQMAgIP+wWPWr0razKsNicwRC0TMQEg zq5KchsDsGgzh14NyfXSRJMrRiwTDbSpdS0Q2Mqg+en9CczUpTjGtxFruAElCYzH vvQTBik0aEqs22WTMwYy7g/JK8sMwxc8AdpWE0gJC7uq5bCDEpv5XApfmSIR/RaJ x5QxoXOUhik2mSkDAss7LiyfrZUG3ANIJZRp6DVSGWbjc7VDau4728+hwlouWXdU 04DHS7KwVRp6HqCHnf6iyRebJFGseNOGjMtRvVr3oMjpvXZZeM3Fgm5JGGlfyRQq wb8AYg+fSMO0dUVONLevJML2FJX58MiGh+l0AvdgrUgguoZxgDue/NgZaShcjEyJ xfYl/UBMEwLZuYDjNxi7LrCqxrPKQOClIKPCQlNeeFmin7e9qkNbsAJW/02Puvm7 X1cn7KOLZY+sLcA8rjWC75QxusDGR4IBCKgaZRDtxkzCiPdRfgrAPszvAqCD8pEZ JbXK6hBR3AeJOtA0X6VW261ZuNWt2fPPBYFUL8hHf3HA78liAWizOnHpao8+KU70 eInKoKsjtQlAzbG+NpI404kJWsHQvy3ztPWdjjD2poboJLQL1hrsmwGMdSyqvHz6 vqWs1IvvcnXQky0X0WTEvti35v7shA1uyR7MUnst85DK/DjSXDn6tu2/3flW7KLs HTKg7wJGrqUE0qtNMojZ =xRfe -END PGP SIGNATURE- ___ Debian-med-packaging mailing list debian-med-packag...@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/debian-med-packaging -- Mathieu signature.asc Description: OpenPGP digital signature
Bug#579959: Bug#544674: [Debian-med-packaging] Bug#579959: gdcm: FTBFS on mipsel and armel, unable to find java
Hello, On pirmadienis 03 Gegužė 2010 13:50:04 Mathieu Malaterre wrote: I have added a block by to : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544674 Hopefully things should be sorted out quickly as I see 544674 is marked as 'pending'. Well, I presumably fixed the bug but currently KDE transition is in progress and I don't want to disturb slow weird arches with cmake upload. Therefore this will have to wait a bit (maybe a week). Sorry. -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part.
Bug#544674:
Same goes for armel: ref: https://buildd.debian.org/fetch.cgi?pkg=gdcmarch=armelver=2.0.14-5stamp=1272631069file=logas=raw gdcm/armel tail of last log: -- Searching 16 bit integer -- Looking for sys/types.h -- Looking for sys/types.h - found -- Looking for stdint.h -- Looking for stdint.h - found -- Looking for stddef.h -- Looking for stddef.h - found -- Check size of unsigned short -- Check size of unsigned short - done -- Using unsigned short -- Check if the system is big endian - little endian -- Found PythonLibs: /usr/lib/libpython2.5.so -- Java version 1.6.0.18 configured successfully! -- Found Java: /usr/lib/jvm/default-java/bin/java CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:70 (MESSAGE): Could NOT find JNI (missing: JAVA_AWT_LIBRARY JAVA_JVM_LIBRARY) Call Stack (most recent call first): /usr/share/cmake-2.8/Modules/FindJNI.cmake:211 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) Wrapping/Java/CMakeLists.txt:19 (FIND_PACKAGE) -- Configuring incomplete, errors occurred! make: *** [debian/configure-python2.5-stamp] Error 1 dpkg-buildpackage: error: debian/rules build gave error exit status 2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544674:
Hello, On šeštadienis 01 Gegužė 2010 10:37:30 Mathieu Malaterre wrote: Same goes for armel: ref: https://buildd.debian.org/fetch.cgi?pkg=gdcmarch=armelver=2.0.14-5stamp= 1272631069file=logas=raw gdcm/armel tail of last log: What makes you believe this is cmake bug? -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part.
Bug#544674:
On Sat, May 1, 2010 at 10:33 AM, Modestas Vainius modes...@vainius.eu wrote: Hello, On šeštadienis 01 Gegužė 2010 10:37:30 Mathieu Malaterre wrote: Same goes for armel: ref: https://buildd.debian.org/fetch.cgi?pkg=gdcmarch=armelver=2.0.14-5stamp= 1272631069file=logas=raw gdcm/armel tail of last log: What makes you believe this is cmake bug? FindJNI.cmake as shipped in cmake 2.8 (using a patch by you, if you remember) does not work on armel and mipsel. Please re-review your previously submitted patch, and double-check why your patch does not work for mipsel and armel. Here is your post that rejected my patch: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544674#49 Thanks -- Mathieu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544674:
Hello, On šeštadienis 01 Gegužė 2010 17:45:17 Mathieu Malaterre wrote: FindJNI.cmake as shipped in cmake 2.8 (using a patch by you, if you remember) does not work on armel and mipsel. Please re-review your previously submitted patch, and double-check why your patch does not work for mipsel and armel. Here is your post that rejected my patch: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544674#49 That was not my original question but nevermind. Apparently changes (not mine) in 2.8.1 broke things again. Sigh. -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part.
Bug#544674: (no subject)
For some reason there has been a regression. As can be seen on mipsel with GDCM: -- Found Java: /usr/lib/jvm/default-java/bin/java CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:70 (MESSAGE): Could NOT find JNI (missing: JAVA_AWT_LIBRARY JAVA_JVM_LIBRARY) Call Stack (most recent call first): /usr/share/cmake-2.8/Modules/FindJNI.cmake:211 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) Wrapping/Java/CMakeLists.txt:19 (FIND_PACKAGE) Ref: https://buildd.debian.org/fetch.cgi?pkg=gdcmarch=mipselver=2.0.14-5stamp=1272626721file=logas=raw signature.asc Description: OpenPGP digital signature
Bug#544674:
For reference: http://cmake.org/Bug/view.php?id=9611 -- Mathieu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544674:
Please apply upstream patch that should solve this grave issue. Link: http://public.kitware.com/cgi-bin/viewcvs.cgi/Modules/FindJNI.cmake?root=CMaker1=1.40r2=1.41 Thanks -- Mathieu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544674:
Modestats, On Thu, Sep 17, 2009 at 12:22 PM, Modestas Vainius modes...@vainius.eu wrote: affects 544674 - vtk severity 544674 important thanks Hello, On ketvirtadienis 17 Rugsėjis 2009 10:05:57 Mathieu Malaterre wrote: Please apply upstream patch that should solve this grave issue. Link: http://public.kitware.com/cgi-bin/viewcvs.cgi/Modules/FindJNI.cmake?root=CM aker1=1.40r2=1.41 Mathieu, my previous arguments about your patch being arch-dependent still hold true. I somehow missed that you reported upstream bug and I would say it is rather unfortunate upstream accepted your patch. So I'm not going to rush but talk with upstream about proper solution. I would think that DD cannot replace whatever choice is being done upstream. Secondly, fixing #544674 bug will NOT fix #545335. Current FindJNI.cmake refers to $JAVA_HOME/ppc in the search path as it is supposed to (according to openjdk-6-jre-headless package). There is no convention AFAIK. So unless you inspect all of them you will *not* find libjawt.so. The actual proper fix in debian would be to have all libjawt.so provider to install the symlinks properly. Don't you find it weird that vtk builds just *fine* with FindJNI.cmake on arches it supposedly does NOT support (according to this bug) but fails on powerpc which it supports properly? This bug obviously attracted too much false attention. No it does not build, see your own remark below. FWIW, from vtk debian/rules: echo JAVA_AWT_LIBRARY:FILEPATH=/usr/lib/jvm/default- java/jre/lib/$(DEB_HOST_ARCH_CPU)/libjawt.so Build/CMakeCache.txt That's just wrong. cmake is doing system inspection. This was written by someone not knowing the cmake enough. So that's where the powerpc FTBFS is coming from. It *overrides* proper value FindJNI sets on powerpc. It is also true that you cannot drop this workaround until #544674 is fixed. You will have to improve it. You missed earlier discussion, I do not know why Maitland push the issue over to you without the full discussion thread. If you look back in the history reverting the change will also break in other way. So in summary: you have to do system inspection because no DEB_*_ARCH / DEB_*_CPU will work on all combination of java package provider for libjawt.so I can understand that you would prefer another solution (I also personnaly do), but for the time being there is no convention for debian package providing libjawt.so and symlinks are not always provided. I'd really see VTK / ITK / Slicer / GDCM being considered for testing for such a small issue that is so deeply burried in cmake internals. cmake will soon be released so this patch will be integrated anyway. -- Mathieu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544674:
affects 544674 - vtk severity 544674 important thanks Hello, On ketvirtadienis 17 Rugsėjis 2009 10:05:57 Mathieu Malaterre wrote: Please apply upstream patch that should solve this grave issue. Link: http://public.kitware.com/cgi-bin/viewcvs.cgi/Modules/FindJNI.cmake?root=CM aker1=1.40r2=1.41 Mathieu, my previous arguments about your patch being arch-dependent still hold true. I somehow missed that you reported upstream bug and I would say it is rather unfortunate upstream accepted your patch. So I'm not going to rush but talk with upstream about proper solution. Secondly, fixing #544674 bug will NOT fix #545335. Current FindJNI.cmake refers to $JAVA_HOME/ppc in the search path as it is supposed to (according to openjdk-6-jre-headless package). Don't you find it weird that vtk builds just *fine* with FindJNI.cmake on arches it supposedly does NOT support (according to this bug) but fails on powerpc which it supports properly? This bug obviously attracted too much false attention. FWIW, from vtk debian/rules: echo JAVA_AWT_LIBRARY:FILEPATH=/usr/lib/jvm/default- java/jre/lib/$(DEB_HOST_ARCH_CPU)/libjawt.so Build/CMakeCache.txt So that's where the powerpc FTBFS is coming from. It *overrides* proper value FindJNI sets on powerpc. It is also true that you cannot drop this workaround until #544674 is fixed. You will have to improve it. -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part.
Bug#544674:
On Thu, Sep 17, 2009 at 12:33 PM, Mathieu Malaterre mathieu.malate...@gmail.com wrote: echo JAVA_AWT_LIBRARY:FILEPATH=/usr/lib/jvm/default- java/jre/lib/$(DEB_HOST_ARCH_CPU)/libjawt.so Build/CMakeCache.txt As a side note here is the output of what is happening without those two lines and using the old FindJNI.cmake: https://buildd.debian.org/~luk/status/package.php?p=gdcm Copied for later reference: gdcm/armel tail of last log: Scanning dependencies of target vtkgdcmJava make[3]: Leaving directory `/build/buildd-gdcm_2.0.12-11-armel-vYWMSv/gdcm-2.0.12/debian/build-python2.5' make[3]: Entering directory `/build/buildd-gdcm_2.0.12-11-armel-vYWMSv/gdcm-2.0.12/debian/build-python2.5' [ 86%] Building CXX object Utilities/VTK/CMakeFiles/vtkgdcmJava.dir/vtkGDCMTestingJava.cxx.o [ 86%] Building CXX object Utilities/VTK/CMakeFiles/vtkgdcmJava.dir/vtkGDCMImageReaderJava.cxx.o [ 86%] Building CXX object Utilities/VTK/CMakeFiles/vtkgdcmJava.dir/vtkGDCMImageWriterJava.cxx.o [ 86%] Building CXX object Utilities/VTK/CMakeFiles/vtkgdcmJava.dir/vtkGDCMMedicalImagePropertiesJava.cxx.o [ 86%] Building CXX object Utilities/VTK/CMakeFiles/vtkgdcmJava.dir/vtkGDCMThreadedImageReaderJava.cxx.o [ 87%] Building CXX object Utilities/VTK/CMakeFiles/vtkgdcmJava.dir/vtkImageColorViewerJava.cxx.o [ 87%] Building CXX object Utilities/VTK/CMakeFiles/vtkgdcmJava.dir/vtkImageMapToWindowLevelColors2Java.cxx.o [ 87%] Building CXX object Utilities/VTK/CMakeFiles/vtkgdcmJava.dir/vtkImageYBRToRGBJava.cxx.o [ 87%] Building CXX object Utilities/VTK/CMakeFiles/vtkgdcmJava.dir/vtkImageRGBToYBRJava.cxx.o [ 88%] Building CXX object Utilities/VTK/CMakeFiles/vtkgdcmJava.dir/vtkGDCMPolyDataReaderJava.cxx.o [ 88%] Building CXX object Utilities/VTK/CMakeFiles/vtkgdcmJava.dir/vtkLookupTable16Java.cxx.o [ 88%] Building CXX object Utilities/VTK/CMakeFiles/vtkgdcmJava.dir/vtkImageMapToColors16Java.cxx.o [ 88%] Building CXX object Utilities/VTK/CMakeFiles/vtkgdcmJava.dir/vtkGDCMThreadedImageReader2Java.cxx.o make[3]: *** No rule to make target `/usr/lib/jvm/default-java/lib/libjawt.so', needed by `bin/libvtkgdcmJava.so'. Stop. make[3]: Leaving directory `/build/buildd-gdcm_2.0.12-11-armel-vYWMSv/gdcm-2.0.12/debian/build-python2.5' make[2]: *** [Utilities/VTK/CMakeFiles/vtkgdcmJava.dir/all] Error 2 make[2]: Leaving directory `/build/buildd-gdcm_2.0.12-11-armel-vYWMSv/gdcm-2.0.12/debian/build-python2.5' make[1]: *** [all] Error 2 make: *** [debian/build-python2.5-stamp] Error 2 make[1]: Leaving directory `/build/buildd-gdcm_2.0.12-11-armel-vYWMSv/gdcm-2.0.12/debian/build-python2.5' dpkg-buildpackage: error: debian/rules build gave error exit status 2 Build finished at 20090907-1301 FAILED [dpkg-buildpackage died] gdcm/powerpc tail of last log: make[3]: Leaving directory `/build/buildd-gdcm_2.0.12-11-powerpc-i0ZkKj/gdcm-2.0.12/debian/build-python2.5' [ 96%] Building CXX object Utilities/VTK/CMakeFiles/vtkgdcmPythonD.dir/vtkGDCMImageWriterPython.cxx.o [ 96%] Building CXX object Utilities/VTK/CMakeFiles/vtkgdcmPythonD.dir/vtkGDCMMedicalImagePropertiesPython.cxx.o [ 97%] Building CXX object Utilities/VTK/CMakeFiles/vtkgdcmPythonD.dir/vtkGDCMThreadedImageReaderPython.cxx.o [ 97%] Building CXX object Utilities/VTK/CMakeFiles/vtkgdcmPythonD.dir/vtkImageColorViewerPython.cxx.o [ 97%] Building CXX object Utilities/VTK/CMakeFiles/vtkgdcmPythonD.dir/vtkImageMapToWindowLevelColors2Python.cxx.o [ 97%] Building CXX object Utilities/VTK/CMakeFiles/vtkgdcmPythonD.dir/vtkImageYBRToRGBPython.cxx.o [ 98%] Building CXX object Utilities/VTK/CMakeFiles/vtkgdcmPythonD.dir/vtkImageRGBToYBRPython.cxx.o [ 98%] Building CXX object Utilities/VTK/CMakeFiles/vtkgdcmPythonD.dir/vtkGDCMPolyDataReaderPython.cxx.o [ 98%] Building CXX object Utilities/VTK/CMakeFiles/vtkgdcmPythonD.dir/vtkLookupTable16Python.cxx.o [ 98%] Building CXX object Utilities/VTK/CMakeFiles/vtkgdcmPythonD.dir/vtkImageMapToColors16Python.cxx.o [ 98%] Building CXX object Utilities/VTK/CMakeFiles/vtkgdcmPythonD.dir/vtkGDCMThreadedImageReader2Python.cxx.o [ 99%] Building CXX object Utilities/VTK/CMakeFiles/vtkgdcmPythonD.dir/vtkgdcmPythonInit.cxx.o Linking CXX shared module ../../bin/libvtkgdcmsharpglue.so make[3]: Leaving directory `/build/buildd-gdcm_2.0.12-11-powerpc-i0ZkKj/gdcm-2.0.12/debian/build-python2.5' [ 99%] Built target vtkgdcmsharpglue Linking CXX shared library ../../bin/libvtkgdcmPythonD.so make[3]: Leaving directory `/build/buildd-gdcm_2.0.12-11-powerpc-i0ZkKj/gdcm-2.0.12/debian/build-python2.5' [ 99%] Built target vtkgdcmPythonD make[2]: Leaving directory `/build/buildd-gdcm_2.0.12-11-powerpc-i0ZkKj/gdcm-2.0.12/debian/build-python2.5' make[1]: *** [all] Error 2 make: *** [debian/build-python2.5-stamp] Error 2 make[1]: Leaving directory `/build/buildd-gdcm_2.0.12-11-powerpc-i0ZkKj/gdcm-2.0.12/debian/build-python2.5' dpkg-buildpackage: error: debian/rules build gave error exit status 2
Bug#544674:
Because gdcm is build with parallel option the output was garbaged from the 'more' page. Instead it should have read: On Thu, Sep 17, 2009 at 12:39 PM, Mathieu Malaterre mathieu.malate...@gmail.com wrote: gdcm/powerpc tail of last log: gdcm/powerpc tail of last log: make[3]: Entering directory `/build/buildd-gdcm_2.0.12-11-powerpc-i0ZkKj/gdcm-2.0.12/debian/build-python2.5' [ 93%] Python Wrapping - generating vtkgdcmPythonInit.cxx [ 93%] Python Wrapping - generating vtkGDCMTestingPython.cxx [ 93%] Python Wrapping - generating vtkGDCMImageReaderPython.cxx [ 93%] Python Wrapping - generating vtkGDCMImageWriterPython.cxx [ 94%] Python Wrapping - generating vtkGDCMMedicalImagePropertiesPython.cxx [ 94%] Python Wrapping - generating vtkGDCMThreadedImageReaderPython.cxx [ 94%] Python Wrapping - generating vtkImageColorViewerPython.cxx [ 94%] Python Wrapping - generating vtkImageMapToWindowLevelColors2Python.cxx [ 94%] Python Wrapping - generating vtkImageYBRToRGBPython.cxx [ 95%] Python Wrapping - generating vtkImageRGBToYBRPython.cxx [ 95%] Python Wrapping - generating vtkGDCMPolyDataReaderPython.cxx [ 95%] Python Wrapping - generating vtkLookupTable16Python.cxx [ 95%] Python Wrapping - generating vtkImageMapToColors16Python.cxx [ 96%] Python Wrapping - generating vtkGDCMThreadedImageReader2Python.cxx make[3]: *** No rule to make target `/usr/lib/jvm/default-java/jre/lib/powerpc/libjawt.so', needed by `bin/libvtkgdcmJava.so'. Stop. make[3]: *** Waiting for unfinished jobs [ 96%] [ 96%] Building CXX object Utilities/VTK/CMakeFiles/vtkgdcmJava.dir/vtkImageMapToColors16Java.cxx.o Scanning dependencies of target vtkgdcmPythonD Building CXX object Utilities/VTK/CMakeFiles/vtkgdcmJava.dir/vtkGDCMThreadedImageReader2Java.cxx.o make[3]: Leaving directory `/build/buildd-gdcm_2.0.12-11-powerpc-i0ZkKj/gdcm-2.0.12/debian/build-python2.5' Ref: https://buildd.debian.org/fetch.cgi?pkg=gdcmarch=powerpcver=2.0.12-11stamp=1252573316file=logas=raw -- Mathieu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545335: Bug#544674:
Hello, On ketvirtadienis 17 Rugsėjis 2009 13:39:46 Mathieu Malaterre wrote: On Thu, Sep 17, 2009 at 12:33 PM, Mathieu Malaterre mathieu.malate...@gmail.com wrote: echo JAVA_AWT_LIBRARY:FILEPATH=/usr/lib/jvm/default- java/jre/lib/$(DEB_HOST_ARCH_CPU)/libjawt.so Build/CMakeCache.txt As a side note here is the output of what is happening without those two lines and using the old FindJNI.cmake: https://buildd.debian.org/~luk/status/package.php?p=gdcm That's not true. Those failures are an example of cmake leaking link interface libraries from vtk (with the help of vtk cmake hackery of course). I grep'ed gcdm sources a bit and I'm 100% sure vtkgdcmJava did not request to be linked with libjawt.so, it probably does not need jawt at all. That jawt link dependency came from libvtk5-dev (/usr/lib/vtk-5.2/VTKLibraryDepends.cmake). So here you also have an explanation why it searches for a weird path on armel and where it came from... We faced this in KDE and rather successfully solved the issue. cmake 2.6 has proper means to fight this linking the whole world together problem with its LINK_INTERFACE_LIBRARIES property and support for IMPORTED targets. So it is time for vtk to properly use those. -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part.
Bug#544674:
Hello, On ketvirtadienis 17 Rugsėjis 2009 13:33:24 Mathieu Malaterre wrote: I would think that DD cannot replace whatever choice is being done upstream. I'm not going to replace anything, I'm going to talk with cmake upstream about this. Secondly, fixing #544674 bug will NOT fix #545335. Current FindJNI.cmake refers to $JAVA_HOME/ppc in the search path as it is supposed to (according to openjdk-6-jre-headless package). There is no convention AFAIK. So unless you inspect all of them you will *not* find libjawt.so. Well, I've found how openjdk determines its libarch dir and mostly have proper cmake code for it. The actual proper fix in debian would be to have all libjawt.so provider to install the symlinks properly. Don't you find it weird that vtk builds just *fine* with FindJNI.cmake on arches it supposedly does NOT support (according to this bug) but fails on powerpc which it supports properly? This bug obviously attracted too much false attention. No it does not build, see your own remark below. FWIW, from vtk debian/rules: echo JAVA_AWT_LIBRARY:FILEPATH=/usr/lib/jvm/default- java/jre/lib/$(DEB_HOST_ARCH_CPU)/libjawt.so Build/CMakeCache.txt That's just wrong. cmake is doing system inspection. This was written by someone not knowing the cmake enough. That's a workaround for broken FindJNI, it could be improved a bit to exclude i386,amd64,powerpc where FindJNI does its job well. So that's where the powerpc FTBFS is coming from. It *overrides* proper value FindJNI sets on powerpc. It is also true that you cannot drop this workaround until #544674 is fixed. You will have to improve it. You missed earlier discussion, I do not know why Maitland push the issue over to you without the full discussion thread. If you look back in the history reverting the change will also break in other way. So in summary: you have to do system inspection because no DEB_*_ARCH / DEB_*_CPU will work on all combination of java package provider for libjawt.so I know I have to do it. And I will. Just don't push this as critical bug which holds testing migration. It does not. All you have to do is to patch up vtk packaging a bit. It is broken anyway. I can understand that you would prefer another solution (I also personnaly do), but for the time being there is no convention for debian package providing libjawt.so and symlinks are not always provided. So you just added Debian arches. What about linux arches debian does not support? I'm trying to think about broader issue here. I'd really see VTK / ITK / Slicer / GDCM being considered for testing for such a small issue that is so deeply burried in cmake internals. cmake will soon be released so this patch will be integrated anyway. The point is vtk NEEDS sourceful upload even if I fix FindJNI. Please don't put it like cmake is blocking something here. Just exclude i386,amd64,powerpc in vtk debian/rules for the time being to get quick resolution. -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part.
Bug#544674:
On Thu, Sep 17, 2009 at 1:26 PM, Modestas Vainius modes...@vainius.eu wrote: Secondly, fixing #544674 bug will NOT fix #545335. Current FindJNI.cmake refers to $JAVA_HOME/ppc in the search path as it is supposed to (according to openjdk-6-jre-headless package). There is no convention AFAIK. So unless you inspect all of them you will *not* find libjawt.so. Well, I've found how openjdk determines its libarch dir and mostly have proper cmake code for it. Excellent. How about all the other ones ? http://packages.debian.org/search?suite=sidsearchon=contentskeywords=libjawt.so That's just wrong. cmake is doing system inspection. This was written by someone not knowing the cmake enough. That's a workaround for broken FindJNI, it could be improved a bit to exclude i386,amd64,powerpc where FindJNI does its job well. Well FindJNI is an interface, it should work regardless of CPU/ARCH. You missed earlier discussion, I do not know why Maitland push the issue over to you without the full discussion thread. If you look back in the history reverting the change will also break in other way. So in summary: you have to do system inspection because no DEB_*_ARCH / DEB_*_CPU will work on all combination of java package provider for libjawt.so I know I have to do it. And I will. Just don't push this as critical bug which holds testing migration. It does not. All you have to do is to patch up vtk packaging a bit. It is broken anyway. True. I can understand that you would prefer another solution (I also personnaly do), but for the time being there is no convention for debian package providing libjawt.so and symlinks are not always provided. So you just added Debian arches. What about linux arches debian does not support? I'm trying to think about broader issue here. Correct it will fails miserably. I just do not know how to deal with that in a portable manner. I haven't found any documentation that describe where libjawt.so should be located. I'd really see VTK / ITK / Slicer / GDCM being considered for testing for such a small issue that is so deeply burried in cmake internals. cmake will soon be released so this patch will be integrated anyway. The point is vtk NEEDS sourceful upload even if I fix FindJNI. Please don't put it like cmake is blocking something here. Just exclude i386,amd64,powerpc in vtk debian/rules for the time being to get quick resolution. Well the patch you describe in your other mail: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544674#68 has just been applied upstream (thanks to Denis Barbier), it took *several* round to get it right (Denis, Berk, Jeff, Brad and I did work on that patch). I doubt anyone will actually spent the time to integrate this large patch to VTK 5.2 since it is so old. VTK 5.4 is out and VTK 5.6 should come out soon. So I thought -again for the time being- that this modest patch was ok. -- Mathieu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544674:
Hello, On ketvirtadienis 17 Rugsėjis 2009 15:35:04 Mathieu Malaterre wrote: On Thu, Sep 17, 2009 at 1:26 PM, Modestas Vainius modes...@vainius.eu wrote: Secondly, fixing #544674 bug will NOT fix #545335. Current FindJNI.cmake refers to $JAVA_HOME/ppc in the search path as it is supposed to (according to openjdk-6-jre-headless package). There is no convention AFAIK. So unless you inspect all of them you will *not* find libjawt.so. Well, I've found how openjdk determines its libarch dir and mostly have proper cmake code for it. Excellent. How about all the other ones ? http://packages.debian.org/search?suite=sidsearchon=contentskeywords=libj awt.so openjdk libarch dir is the most complex one. Due to its proprietary nature, openjdk does some hardly explainable hacks with `uname -m`. Other JVMs are plain `uname -m` (kaffe) or no libarch subdir at all (gcj). Plain simple I would say. That's just wrong. cmake is doing system inspection. This was written by someone not knowing the cmake enough. That's a workaround for broken FindJNI, it could be improved a bit to exclude i386,amd64,powerpc where FindJNI does its job well. Well FindJNI is an interface, it should work regardless of CPU/ARCH. That's exactly the point. It SHOULD. That's the reason I don't like library path hardcoding like your patch does. I can understand that you would prefer another solution (I also personnaly do), but for the time being there is no convention for debian package providing libjawt.so and symlinks are not always provided. So you just added Debian arches. What about linux arches debian does not support? I'm trying to think about broader issue here. Correct it will fails miserably. I just do not know how to deal with that in a portable manner. I haven't found any documentation that describe where libjawt.so should be located. Because there are no docs about this. stuff is hidden deeply in java build system and *linux* specific hacks to discover that path at runtime. Java paths are a huge MESS. Well the patch you describe in your other mail: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544674#68 has just been applied upstream (thanks to Denis Barbier), it took *several* round to get it right (Denis, Berk, Jeff, Brad and I did work on that patch). Yeah, it is hard to get that right. I doubt anyone will actually spent the time to integrate this large patch to VTK 5.2 since it is so old. VTK 5.4 is out and VTK 5.6 should come out soon. Since it is fixed in 5.4, leave upstream stuff in 5.2 as it is (it would be pointless to waste time on fixing obsolete stuff). Just fix up VTK 5.2 packaging hack now (a single ifeq line in debian/rules) and good path to libjawt.so will propagate to all vtk rdeps as a result. This will solve FTBFSes and let everything migrate to testing. In the meantime, proper fix for FindJNI won't take ages and you will be able to get rid of the hack all together really soon. So I thought -again for the time being- that this modest patch was ok. Maybe for Debian, but definitely not upstream... -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part.
Bug#544674: Fwd: Bug#544674:
Dominique, Did you follow the discussion of bug #544674 ? Modestas suggest to ifdef each case to pass buildd step. Do you have time to fix the FTBS ? Here is the important part: -- Forwarded message -- From: Modestas Vainius Date: Thu, Sep 17, 2009 at 3:23 PM Subject: Re: Bug#544674: ... Since it is fixed in 5.4, leave upstream stuff in 5.2 as it is (it would be pointless to waste time on fixing obsolete stuff). Just fix up VTK 5.2 packaging hack now (a single ifeq line in debian/rules) and good path to libjawt.so will propagate to all vtk rdeps as a result. This will solve FTBFSes and let everything migrate to testing. In the meantime, proper fix for FindJNI won't take ages and you will be able to get rid of the hack all together really soon. ... Ref: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544674#83 Thanks, signature.asc Description: PGP signature
Bug#544674:
Only first result: $(shell find /usr/lib/jvm/default-java/ -print -quit -name libjawt.so) On Thu, Sep 17, 2009 at 3:52 PM, Mathieu Malaterre mathieu.malate...@gmail.com wrote: How about: libjawt=$(shell find /usr/lib/jvm/default-java/ -name libjawt.so) 2cts On Thu, Sep 17, 2009 at 3:45 PM, Mathieu Malaterre mathieu.malate...@gmail.com wrote: Dominique, Did you follow the discussion of bug #544674 ? Modestas suggest to ifdef each case to pass buildd step. Do you have time to fix the FTBS ? Here is the important part: -- Forwarded message -- From: Modestas Vainius Date: Thu, Sep 17, 2009 at 3:23 PM Subject: Re: Bug#544674: ... Since it is fixed in 5.4, leave upstream stuff in 5.2 as it is (it would be pointless to waste time on fixing obsolete stuff). Just fix up VTK 5.2 packaging hack now (a single ifeq line in debian/rules) and good path to libjawt.so will propagate to all vtk rdeps as a result. This will solve FTBFSes and let everything migrate to testing. In the meantime, proper fix for FindJNI won't take ages and you will be able to get rid of the hack all together really soon. ... Ref: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544674#83 Thanks, -- Mathieu -- Mathieu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544674:
How about: libjawt=$(shell find /usr/lib/jvm/default-java/ -name libjawt.so) 2cts On Thu, Sep 17, 2009 at 3:45 PM, Mathieu Malaterre mathieu.malate...@gmail.com wrote: Dominique, Did you follow the discussion of bug #544674 ? Modestas suggest to ifdef each case to pass buildd step. Do you have time to fix the FTBS ? Here is the important part: -- Forwarded message -- From: Modestas Vainius Date: Thu, Sep 17, 2009 at 3:23 PM Subject: Re: Bug#544674: ... Since it is fixed in 5.4, leave upstream stuff in 5.2 as it is (it would be pointless to waste time on fixing obsolete stuff). Just fix up VTK 5.2 packaging hack now (a single ifeq line in debian/rules) and good path to libjawt.so will propagate to all vtk rdeps as a result. This will solve FTBFSes and let everything migrate to testing. In the meantime, proper fix for FindJNI won't take ages and you will be able to get rid of the hack all together really soon. ... Ref: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544674#83 Thanks, -- Mathieu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544674: Fwd: Bug#544674:
I can put a patched FindJNI.cmake to VTK's source package ./vtk-5.2/CMake/FindJNI.cmake In this case CMake's /usr/share/cmake-2.6/Modules/FindJNI.cmake will not be used. The definiton of JAVA_AWT_LIBRARY can then be removed from debian/rules and debian/CMakeCache.txt.debian Cheers Dominique signature.asc Description: This is a digitally signed message part
Bug#544674: VTK #545335
Hello, On antradienis 08 Rugsėjis 2009 05:46:06 A. Maitland Bottoms wrote: It appears that fixing 544674 will fix the powerpc/ppc problem in bug 545335. It might be worth making a cmake 2.6.4-3 upload for this including the findjni2.cmake.patch. I'm currently searching for a better way how to fix the bug rather than hardcode numerous paths for each arch. In particular, I looking how java determines its jre/lib/arch dir. I will upload today or tomorrow. -- Modestas Vainius modes...@vainius.eu signature.asc Description: This is a digitally signed message part.
Bug#544674: VTK #545335
On Tue, Sep 8, 2009 at 9:39 AM, Modestas Vainiusmodes...@vainius.eu wrote: Hello, On antradienis 08 Rugsėjis 2009 05:46:06 A. Maitland Bottoms wrote: It appears that fixing 544674 will fix the powerpc/ppc problem in bug 545335. It might be worth making a cmake 2.6.4-3 upload for this including the findjni2.cmake.patch. I'm currently searching for a better way how to fix the bug rather than hardcode numerous paths for each arch. In particular, I looking how java determines its jre/lib/arch dir. I will upload today or tomorrow. Modestas, One thing I considered at some point is to use the symlinks provided by the java package. But it seems this is broken at least for armel https://buildd.debian.org/~luk/status/package.php?p=gdcm On my machine $ ls -al /usr/lib/jvm/default-java/lib/libjawt.so lrwxrwxrwx 1 root root 30 2009-07-15 16:05 /usr/lib/jvm/default-java/lib/libjawt.so - ../../../gcj-4.3-90/libjawt.so 2cts -- Mathieu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544674: VTK #545335
It appears that fixing 544674 will fix the powerpc/ppc problem in bug 545335. It might be worth making a cmake 2.6.4-3 upload for this including the findjni2.cmake.patch. -Maitland -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544674: FindJNI.cmake is missing archs/cpus
Package: cmake
Version: 2.6.4-1
Severity: normal
FindJNI.cmake is missing archs/cpus
See attached patch
Thanks !
-- System Information:
Debian Release: 5.0.2
APT prefers stable
APT policy: (500, 'stable'), (200, 'testing'), (100, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.30-bpo.1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages cmake depends on:
ii cmake-data 2.6.4-1 CMake data files (modules, templat
ii libc6 2.9-12GNU C Library: Shared libraries
ii libcurl3-gnutls7.18.2-8lenny2Multi-protocol file transfer libra
ii libexpat1 2.0.1-4 XML parsing C library - runtime li
ii libgcc11:4.4.0-5 GCC support library
ii libstdc++6 4.4.0-5 The GNU Standard C++ Library v3
ii libxmlrpc-c3 1.06.27-1 A lightweight RPC library based on
ii zlib1g 1:1.2.3.3.dfsg-15 compression library - runtime
cmake recommends no packages.
cmake suggests no packages.
-- no debconf information
Index: FindJNI.cmake
===
RCS file: /cvsroot/CMake/CMake/Modules/FindJNI.cmake,v
retrieving revision 1.40
diff -u -r1.40 FindJNI.cmake
--- FindJNI.cmake 21 Apr 2009 21:12:32 - 1.40
+++ FindJNI.cmake 2 Sep 2009 09:29:38 -
@@ -19,9 +19,16 @@
[HKEY_LOCAL_MACHINE\\SOFTWARE\\JavaSoft\\Java Development Kit\\1.4;JavaHome]/lib
[HKEY_LOCAL_MACHINE\\SOFTWARE\\JavaSoft\\Java Development Kit\\1.3;JavaHome]/lib
[HKEY_LOCAL_MACHINE\\SOFTWARE\\JavaSoft\\Java Development Kit\\${java_install_version};JavaHome]/lib
- $ENV{JAVA_HOME}/jre/lib/i386
+ $ENV{JAVA_HOME}/jre/lib/alpha
$ENV{JAVA_HOME}/jre/lib/amd64
+ $ENV{JAVA_HOME}/jre/lib/arm
+ $ENV{JAVA_HOME}/jre/lib/i386
+ $ENV{JAVA_HOME}/jre/lib/ia64
+ $ENV{JAVA_HOME}/jre/lib/mips
+ $ENV{JAVA_HOME}/jre/lib/mipsel
$ENV{JAVA_HOME}/jre/lib/ppc
+ $ENV{JAVA_HOME}/jre/lib/s390
+ $ENV{JAVA_HOME}/jre/lib/sparc
$ENV{JAVA_HOME}/lib
/usr/lib
/usr/local/lib
Bug#544674: updated patch
Forwarded upstream too: http://cmake.org/Bug/view.php?id=9476 -- Mathieu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544674: updated patch
Please use patch #2. -- Mathieu findjni2.cmake.patch Description: application/wine-extension-patch
