Re: [CMake] Creating package
Am Samstag, 26. Mai 2012 um 22:02:19, schrieb Eric Noulard eric.noul...@gmail.com 2012/5/26 Kornel Benko kor...@lyx.org: Am Samstag, 26. Mai 2012 um 17:31:18, schrieb Kornel Benko kor...@lyx.org Am Samstag, 26. Mai 2012 um 16:41:45, schrieb Eric Noulard eric.noul...@gmail.com 2012/5/26 Kornel Benko kor...@lyx.org: Resending this, after being subscribed ... Hi list, this is my first mail to this list, so it may be the wrong list to report errors. This is the good one. When we are all sure that the bug is a real bug you may file a bug report in the tracker as well: http://public.kitware.com/Bug Recently I updated to ubuntu 12.04. Debian packages created with cmake (through make package) are now not handled gratuitously by dpkg. (The installation stops after extracting data from *.deb) - # sudo dpkg -i xyzzy.deb (Reading database ... 517983 files and directories currently installed.) Preparing to replace (using .../.deb) ... Unpacking replacement ... dpkg: error processing xyzzy.deb (--install): corrupted filesystem tarfile - corrupted package archive dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Errors were encountered while processing: xyzzy.deb Anyway, this looks as like data.tar.gz were not ok. The package will be corrected, if I do following: mkdir tmp cp xyzzy.deb tmp cd tmp ar xv xyzzy.deb data.tar.gz tar xzvf data.tar.gz tar zcvf data.tgz ./usr mv data.tgz data.tar.gz ar rv xyzzy.deb data.tar.gz Now dpkg -i xyzzy.deb is working. Ok then, could you try with cmake -E tar zcvf data.tgz ./usr instead. This one produces the same _bad_ tar file. The error output of #tar ztvf data.tgz /dev/null tar: Ignoring unknown extended header keyword `SCHILY.fflags' tar: Ignoring unknown extended header keyword `SCHILY.fflags' tar: Ignoring unknown extended header keyword `SCHILY.fflags' tar: Ignoring unknown extended header keyword `SCHILY.fflags' Googling I found http://www.redhat.com/archives/fedora-extras-list/2006-June/msg00734.html or this one http://public.kitware.com/Bug/view.php?id=11176 which looks more related. Following the last link to http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=22fb266d is interesting too. I think I've seen some bug like this in the past I'll check the mailing list archive and the CMake bug tracker. Found it: http://www.cmake.org/Bug/view.php?id=8790 not really the same issue but who knows... I'll try to get my hand on an Ubuntu 12.04 box to check whether if I can reproduce the problem. This deserve a bug report to Ubuntu https://launchpad.net/cmake and may be we will get one for CMake when the ubuntu package maintainer get your report. I feared, you could propose something like this :) Erk Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Creating package
2012/5/27 Kornel Benko kor...@lyx.org: Now dpkg -i xyzzy.deb is working. Ok then, could you try with cmake -E tar zcvf data.tgz ./usr instead. This one produces the same _bad_ tar file. The error output of #tar ztvf data.tgz /dev/null tar: Ignoring unknown extended header keyword `SCHILY.fflags' tar: Ignoring unknown extended header keyword `SCHILY.fflags' tar: Ignoring unknown extended header keyword `SCHILY.fflags' tar: Ignoring unknown extended header keyword `SCHILY.fflags' That's what I suspected. There is some conflicting default setup between system libarchive and system tar command. Googling I found http://www.redhat.com/archives/fedora-extras-list/2006-June/msg00734.html or this one http://public.kitware.com/Bug/view.php?id=11176 which looks more related. Following the last link to http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=22fb266d is interesting too. Thanks you for digging this up, I'll have a more close look at CPackDeb code because there should be some BSD tar code inside the cmCPackDebGenerator.cxx which is supposed to enhance tar portability issue. This code is NOT using libarchive but obviously some part of CPackDeb is using cmake -E tar / libarchive. I'll try to either always use libarchive with enforced options (which may not be the same as the one used by cmake -E tar) or always use the builtin BSD tar. I think I've seen some bug like this in the past I'll check the mailing list archive and the CMake bug tracker. Found it: http://www.cmake.org/Bug/view.php?id=8790 not really the same issue but who knows... I'll try to get my hand on an Ubuntu 12.04 box to check whether if I can reproduce the problem. This deserve a bug report to Ubuntu https://launchpad.net/cmake and may be we will get one for CMake when the ubuntu package maintainer get your report. I feared, you could propose something like this :) Don't be afraid :-] I don't want to push away the bug report but CMake source code convey inside its source tree some external libraries (libarchive, zlib etc...) in order to be able to: 1) have greater portability 2) have less 'external' dependencies (in fact there is almost none) 3) ease testing on various platform in a consistent way. I understand the will of distro packager to build cmake using SYSTEM lib but (I think that) this cannot be tested on all system combination so may be they should do some regression testing when doing that. May be we can suggest that distros packager run a CMake dashboard with their own configuration problem with this being that they may apply patches that may triggers red flags which may not be upstream concerns... May be we should add a test (in CMake test suite) that 1) create tar using cmake -E tar and untar it using system tar 2) create a tar using system tar and untar it using cmake -E tar That could help us (and packager if they run the CMake test suite) to catch this kind of issue. Currently there is a TarTest (see CMake-Source/Tests/TarTest but it's only testing whether if the cmake -E tar command is able to work with itself. -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Creating package
Am Sonntag, 27. Mai 2012 um 10:41:01, schrieb Eric Noulard
eric.noul...@gmail.com
[ snip ]
I understand the will of distro packager to build cmake using SYSTEM lib
but (I think that) this cannot be tested on all system combination so
may be they should do some regression testing when doing that.
May be we can suggest that distros packager run a CMake dashboard
with their own configuration problem with this being that they may
apply patches that may triggers red flags which may not be upstream
concerns...
I am now in the process of compiling myself. The first compilation was ok. It
works
but has CMAKE_USE_SYSTEM_LIBARCHIVE:BOOL=OFF
...
Setting to ON, I get the same behaviour as previously in the ubuntu version.
Since cpack is calling cmake -E tar ..., so we should change
Source/cmArchiveWrite.cxx I suppose.
But, cpack seems also to use libarchive.
So the patch looks ok (on ubuntu) for cmake but not for cpack.
Korneldiff --git a/Source/cmArchiveWrite.cxx b/Source/cmArchiveWrite.cxx
index dc6b749..74586ec 100644
--- a/Source/cmArchiveWrite.cxx
+++ b/Source/cmArchiveWrite.cxx
@@ -123,9 +123,9 @@ cmArchiveWrite::cmArchiveWrite(std::ostream os, Compress c, Type t):
}
break;
case TypeTAR:
- if(archive_write_set_format_pax_restricted(this-Archive) != ARCHIVE_OK)
+ if(archive_write_set_format_gnutar(this-Archive) != ARCHIVE_OK)
{
-this-Error = archive_write_set_format_pax_restricted: ;
+this-Error = archive_write_set_format_gnutar: ;
this-Error += archive_error_string(this-Archive);
return;
}
signature.asc
Description: This is a digitally signed message part.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Creating package
2012/5/27 Kornel Benko kor...@lyx.org: Am Sonntag, 27. Mai 2012 um 10:41:01, schrieb Eric Noulard eric.noul...@gmail.com [ snip ] I understand the will of distro packager to build cmake using SYSTEM lib but (I think that) this cannot be tested on all system combination so may be they should do some regression testing when doing that. May be we can suggest that distros packager run a CMake dashboard with their own configuration problem with this being that they may apply patches that may triggers red flags which may not be upstream concerns... I am now in the process of compiling myself. The first compilation was ok. It works but has CMAKE_USE_SYSTEM_LIBARCHIVE:BOOL=OFF ... Setting to ON, I get the same behaviour as previously in the ubuntu version. Which precisely shows that the libarchive from Ubuntu has something weird in it since the builtin version of libarchive which comes with CMake seems to work. Note that AFAIK, the libarchive in CMake source is a reduced (but unpatched) version of libarchive: /home/erk/workspace/CMake-gitted/Utilities/cmlibarchive/README-CMake.txt Since cpack is calling cmake -E tar ..., so we should change Source/cmArchiveWrite.cxx I suppose. No we can't do that, PAX format has been chosen on purpose because it was the most portable accross Linux, *BSD and other unices so we certainly don't wan't to default to gnutar since many system don't use gnutar as a default. But, cpack seems also to use libarchive. Like I said cpack uses libarchive but cpack DEB uses both libarchive and builtin BSD tar. So the patch looks ok (on ubuntu) for cmake but not for cpack. Like I said we certainly cannot accept that patch for upstream CMake. Nonetheless, do mean that with your patched Source/cmArchiveWrite.cxx version cmake -E tar is working but cpack DEB is not? If you are going to provide/discuss patch (I'm glad you do) may be we should switch to cmake-developers Mailing List (http://www.cmake.org/mailman/listinfo/cmake-developers) since many users may be afraid/annoyed by this kind of discussion. Another solution is to open a bug report on CMake bug tracker (I think that at this point you can do that) and we can discuss the issue and the solution there. Do not expect more answers from me today, I'll be off network until probably tomorrow. -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Creating package
Am Sonntag, 27. Mai 2012 um 13:50:37, schrieb Eric Noulard eric.noul...@gmail.com 2012/5/27 Kornel Benko kor...@lyx.org: Am Sonntag, 27. Mai 2012 um 10:41:01, schrieb Eric Noulard eric.noul...@gmail.com [ snip ] I understand the will of distro packager to build cmake using SYSTEM lib but (I think that) this cannot be tested on all system combination so may be they should do some regression testing when doing that. May be we can suggest that distros packager run a CMake dashboard with their own configuration problem with this being that they may apply patches that may triggers red flags which may not be upstream concerns... I am now in the process of compiling myself. The first compilation was ok. It works but has CMAKE_USE_SYSTEM_LIBARCHIVE:BOOL=OFF ... Setting to ON, I get the same behaviour as previously in the ubuntu version. Which precisely shows that the libarchive from Ubuntu has something weird in it since the builtin version of libarchive which comes with CMake seems to work. Note that AFAIK, the libarchive in CMake source is a reduced (but unpatched) version of libarchive: /home/erk/workspace/CMake-gitted/Utilities/cmlibarchive/README-CMake.txt Since cpack is calling cmake -E tar ..., so we should change Source/cmArchiveWrite.cxx I suppose. No we can't do that, PAX format has been chosen on purpose because it was the most portable accross Linux, *BSD and other unices so we certainly don't wan't to default to gnutar since many system don't use gnutar as a default. But, cpack seems also to use libarchive. Like I said cpack uses libarchive but cpack DEB uses both libarchive and builtin BSD tar. So the patch looks ok (on ubuntu) for cmake but not for cpack. Like I said we certainly cannot accept that patch for upstream CMake. Nonetheless, do mean that with your patched Source/cmArchiveWrite.cxx version cmake -E tar is working but cpack DEB is not? I should have to investigate further. With this patch I have _no_ problems on ubuntu. If you are going to provide/discuss patch (I'm glad you do) may be we should switch to cmake-developers Mailing List (http://www.cmake.org/mailman/listinfo/cmake-developers) since many users may be afraid/annoyed by this kind of discussion. OK, will do. Another solution is to open a bug report on CMake bug tracker (I think that at this point you can do that) and we can discuss the issue and the solution there. Do not expect more answers from me today, I'll be off network until probably tomorrow. Erk Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Creating package
Resending this, after being subscribed ... Hi list, this is my first mail to this list, so it may be the wrong list to report errors. Recently I updated to ubuntu 12.04. Debian packages created with cmake (through make package) are now not handled gratuitously by dpkg. (The installation stops after extracting data from *.deb) - # sudo dpkg -i xyzzy.deb (Reading database ... 517983 files and directories currently installed.) Preparing to replace (using .../.deb) ... Unpacking replacement ... dpkg: error processing xyzzy.deb (--install): corrupted filesystem tarfile - corrupted package archive dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Errors were encountered while processing: xyzzy.deb - The only way to overcome this was to downgrade cmake version 2.8.8 to 2.8.5. (I had to use following packages from ubuntu 11.10: cmake_2.8.5-1ubuntu1_amd64.deb cmake-data_2.8.5-1ubuntu1_all.deb cmake-qt-gui_2.8.5-1ubuntu1_amd64.deb libarchive1_2.8.4-1ubuntu0.11.10.1_amd64.deb liblzma2_5.0.0-2_amd64.deb libxmlrpc-c3-0_1.16.32-0ubuntu4_amd64.deb libxmlrpc-core-c3-0_1.16.32-0ubuntu3_amd64.deb ) With this version the now created packages are ok. Regards Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Creating package
2012/5/26 Kornel Benko kor...@lyx.org: Resending this, after being subscribed ... Hi list, this is my first mail to this list, so it may be the wrong list to report errors. This is the good one. When we are all sure that the bug is a real bug you may file a bug report in the tracker as well: http://public.kitware.com/Bug Recently I updated to ubuntu 12.04. Debian packages created with cmake (through make package) are now not handled gratuitously by dpkg. (The installation stops after extracting data from *.deb) - # sudo dpkg -i xyzzy.deb (Reading database ... 517983 files and directories currently installed.) Preparing to replace (using .../.deb) ... Unpacking replacement ... dpkg: error processing xyzzy.deb (--install): corrupted filesystem tarfile - corrupted package archive dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Errors were encountered while processing: xyzzy.deb - The only way to overcome this was to downgrade cmake version 2.8.8 to 2.8.5. (I had to use following packages from ubuntu 11.10: cmake_2.8.5-1ubuntu1_amd64.deb cmake-data_2.8.5-1ubuntu1_all.deb cmake-qt-gui_2.8.5-1ubuntu1_amd64.deb libarchive1_2.8.4-1ubuntu0.11.10.1_amd64.deb liblzma2_5.0.0-2_amd64.deb libxmlrpc-c3-0_1.16.32-0ubuntu4_amd64.deb libxmlrpc-core-c3-0_1.16.32-0ubuntu3_amd64.deb ) With this version the now created packages are ok. This is stange. There are not that many concerning CPackDeb between 2.8.5 and 2.8.8 beside the automatic fakeroot feature. Could you try to launch the following commands on the offending deb package. dpkg -I xyzzy.deb dpkg -c xyzzy.deb Would you be able to try with prebuilt cmake-2.8.8 from kitware: you can untar this archive http://www.cmake.org/files/v2.8/cmake-2.8.8-Linux-i386.tar.gz and use cmake with full path from there. (May be some ubuntu specific patch are playing behind our back??) Last but not least may be the automatic usage of fakeroot is the culprit, In order to check that could you 1) uninstall fakeroot (aptitude remove fakeroot) 2) re-run cmake 2.8.8 and check if the generated deb works or not. In the very end if all this fails you can provide us with a stripped down failing example. In any case if kitware pre-compiled binary failed you should file a bug report on the tracker. -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Creating package
Am Samstag, 26. Mai 2012 um 16:41:45, schrieb Eric Noulard eric.noul...@gmail.com 2012/5/26 Kornel Benko kor...@lyx.org: Resending this, after being subscribed ... Hi list, this is my first mail to this list, so it may be the wrong list to report errors. This is the good one. When we are all sure that the bug is a real bug you may file a bug report in the tracker as well: http://public.kitware.com/Bug Recently I updated to ubuntu 12.04. Debian packages created with cmake (through make package) are now not handled gratuitously by dpkg. (The installation stops after extracting data from *.deb) - # sudo dpkg -i xyzzy.deb (Reading database ... 517983 files and directories currently installed.) Preparing to replace (using .../.deb) ... Unpacking replacement ... dpkg: error processing xyzzy.deb (--install): corrupted filesystem tarfile - corrupted package archive dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Errors were encountered while processing: xyzzy.deb - The only way to overcome this was to downgrade cmake version 2.8.8 to 2.8.5. (I had to use following packages from ubuntu 11.10: cmake_2.8.5-1ubuntu1_amd64.deb cmake-data_2.8.5-1ubuntu1_all.deb cmake-qt-gui_2.8.5-1ubuntu1_amd64.deb libarchive1_2.8.4-1ubuntu0.11.10.1_amd64.deb liblzma2_5.0.0-2_amd64.deb libxmlrpc-c3-0_1.16.32-0ubuntu4_amd64.deb libxmlrpc-core-c3-0_1.16.32-0ubuntu3_amd64.deb ) With this version the now created packages are ok. This is stange. There are not that many concerning CPackDeb between 2.8.5 and 2.8.8 beside the automatic fakeroot feature. Could you try to launch the following commands on the offending deb package. dpkg -I xyzzy.deb Here it comes: #dpkg -I lyx20-2.0.1-Linux.deb neues Debian-Paket, Version 2.0. Größe 15864390 Byte: control-Archiv= 48242 Byte. 277 Byte,10 Zeilen control 136151 Byte, 1743 Zeilen md5sums Package: lyx20 Version: 2.0.1 Section: devel Priority: optional Architecture: amd64 Depends: libenchant1c2a (= 1.6.0-0),libqtgui4 (= 4.4.3-0) Installed-Size: 52663 Maintainer: lyx-de...@lists.lyx.org Description: A WYSIWYM (What You See Is What You Mean) document processor dpkg -c xyzzy.deb This gives the standard tar ztvf output from data.tar.gz, could not see anything special there. One thing though is the definition of owner/group of all listed files. In the working version, this is kornel/kornel, in the bad version it is root/root; Would you be able to try with prebuilt cmake-2.8.8 from kitware: you can untar this archive http://www.cmake.org/files/v2.8/cmake-2.8.8-Linux-i386.tar.gz Yes, but I fear, it is not cmake but cpack. ... As I expected, replacing the cpack binary cured everything. The BIG difference is #ldd /mnt/usr2/src/cmake/cmake-2.8.8-Linux-i386/bin/cpack linux-gate.so.1 = (0xf7761000) libdl.so.2 = /lib/i386-linux-gnu/libdl.so.2 (0xf771d000) libm.so.6 = /lib/i386-linux-gnu/libm.so.6 (0xf76f1000) libc.so.6 = /lib/i386-linux-gnu/libc.so.6 (0xf754b000) /lib/ld-linux.so.2 (0xf7762000) while #ldd /usr/bin/cpack display 45 different shared libraries, among them also libarchive.so.12 = /usr/lib/x86_64-linux-gnu/libarchive.so.12 (0x7fd16c52e000) which I suspect to be the one creating trouble ... and use cmake with full path from there. (May be some ubuntu specific patch are playing behind our back??) Last but not least may be the automatic usage of fakeroot is the culprit, In order to check that could you 1) uninstall fakeroot (aptitude remove fakeroot) Sorry, this one has tried to remove 468 other packages while leaving also next 126 packages with unresolved dependencies. So I prefer not to follow. 2) re-run cmake 2.8.8 and check if the generated deb works or not. In the very end if all this fails you can provide us with a stripped down failing example. In any case if kitware pre-compiled binary failed you should file a bug report on the tracker. As I wrote, this one works. Erk Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Creating package
Am Samstag, 26. Mai 2012 um 17:31:18, schrieb Kornel Benko kor...@lyx.org Am Samstag, 26. Mai 2012 um 16:41:45, schrieb Eric Noulard eric.noul...@gmail.com 2012/5/26 Kornel Benko kor...@lyx.org: Resending this, after being subscribed ... Hi list, this is my first mail to this list, so it may be the wrong list to report errors. This is the good one. When we are all sure that the bug is a real bug you may file a bug report in the tracker as well: http://public.kitware.com/Bug Recently I updated to ubuntu 12.04. Debian packages created with cmake (through make package) are now not handled gratuitously by dpkg. (The installation stops after extracting data from *.deb) - # sudo dpkg -i xyzzy.deb (Reading database ... 517983 files and directories currently installed.) Preparing to replace (using .../.deb) ... Unpacking replacement ... dpkg: error processing xyzzy.deb (--install): corrupted filesystem tarfile - corrupted package archive dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Errors were encountered while processing: xyzzy.deb Anyway, this looks as like data.tar.gz were not ok. The package will be corrected, if I do following: mkdir tmp cp xyzzy.deb tmp cd tmp ar xv xyzzy.deb data.tar.gz tar xzvf data.tar.gz tar zcvf data.tgz ./usr mv data.tgz data.tar.gz ar rv xyzzy.deb data.tar.gz Now dpkg -i xyzzy.deb is working. Kornel signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Creating package
2012/5/26 Kornel Benko kor...@lyx.org: Am Samstag, 26. Mai 2012 um 16:41:45, schrieb Eric Noulard eric.noul...@gmail.com dpkg -c xyzzy.deb This gives the standard tar ztvf output from data.tar.gz, could not see anything special there. One thing though is the definition of owner/group of all listed files. In the working version, this is kornel/kornel, in the bad version it is root/root; Ok, this is the 'automatic' fakeroot effect. I don't think it's the cause of the problem anyway. Would you be able to try with prebuilt cmake-2.8.8 from kitware: you can untar this archive http://www.cmake.org/files/v2.8/cmake-2.8.8-Linux-i386.tar.gz Yes, but I fear, it is not cmake but cpack. Yes right off course. But since you said you use make package I guessed you'll used cmake + cpack for the whhole build+package process. ... As I expected, replacing the cpack binary cured everything. The BIG difference is #ldd /mnt/usr2/src/cmake/cmake-2.8.8-Linux-i386/bin/cpack linux-gate.so.1 = (0xf7761000) libdl.so.2 = /lib/i386-linux-gnu/libdl.so.2 (0xf771d000) libm.so.6 = /lib/i386-linux-gnu/libm.so.6 (0xf76f1000) libc.so.6 = /lib/i386-linux-gnu/libc.so.6 (0xf754b000) /lib/ld-linux.so.2 (0xf7762000) while #ldd /usr/bin/cpack display 45 different shared libraries, among them also libarchive.so.12 = /usr/lib/x86_64-linux-gnu/libarchive.so.12 (0x7fd16c52e000) It could be they must have ticked CMAKE_USE_SYSTEM_LIBARCHIVE and may be other CMAKE_USE_SYSTEM_. It should be harmless but who knows. which I suspect to be the one creating trouble ... and use cmake with full path from there. (May be some ubuntu specific patch are playing behind our back??) Last but not least may be the automatic usage of fakeroot is the culprit, In order to check that could you 1) uninstall fakeroot (aptitude remove fakeroot) Sorry, this one has tried to remove 468 other packages while leaving also next 126 packages with unresolved dependencies. So I prefer not to follow. Yes no problem like I said this one shouldn't be the source of the problem. I'll try to add something in order to be able to disable this in the future. In any case if kitware pre-compiled binary failed you should file a bug report on the tracker. As I wrote, this one works. Then I guess you should file a bug to ubuntu package maintainer. -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Creating package
2012/5/26 Kornel Benko kor...@lyx.org: Am Samstag, 26. Mai 2012 um 17:31:18, schrieb Kornel Benko kor...@lyx.org Am Samstag, 26. Mai 2012 um 16:41:45, schrieb Eric Noulard eric.noul...@gmail.com 2012/5/26 Kornel Benko kor...@lyx.org: Resending this, after being subscribed ... Hi list, this is my first mail to this list, so it may be the wrong list to report errors. This is the good one. When we are all sure that the bug is a real bug you may file a bug report in the tracker as well: http://public.kitware.com/Bug Recently I updated to ubuntu 12.04. Debian packages created with cmake (through make package) are now not handled gratuitously by dpkg. (The installation stops after extracting data from *.deb) - # sudo dpkg -i xyzzy.deb (Reading database ... 517983 files and directories currently installed.) Preparing to replace (using .../.deb) ... Unpacking replacement ... dpkg: error processing xyzzy.deb (--install): corrupted filesystem tarfile - corrupted package archive dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Errors were encountered while processing: xyzzy.deb Anyway, this looks as like data.tar.gz were not ok. The package will be corrected, if I do following: mkdir tmp cp xyzzy.deb tmp cd tmp ar xv xyzzy.deb data.tar.gz tar xzvf data.tar.gz tar zcvf data.tgz ./usr mv data.tgz data.tar.gz ar rv xyzzy.deb data.tar.gz Now dpkg -i xyzzy.deb is working. Ok then, could you try with cmake -E tar zcvf data.tgz ./usr instead. I think I've seen some bug like this in the past I'll check the mailing list archive and the CMake bug tracker. Found it: http://www.cmake.org/Bug/view.php?id=8790 not really the same issue but who knows... I'll try to get my hand on an Ubuntu 12.04 box to check whether if I can reproduce the problem. This deserve a bug report to Ubuntu https://launchpad.net/cmake and may be we will get one for CMake when the ubuntu package maintainer get your report. -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
