Re: [CMake] Creating package
2012/5/26 Kornel Benko : > 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 > 2012/5/26 Kornel Benko : > > 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 > Am Samstag, 26. Mai 2012 um 16:41:45, schrieb Eric Noulard > > > 2012/5/26 Kornel Benko : > > > 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 : > Am Samstag, 26. Mai 2012 um 16:41:45, schrieb Eric Noulard > >> 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 : > Am Samstag, 26. Mai 2012 um 17:31:18, schrieb Kornel Benko >> Am Samstag, 26. Mai 2012 um 16:41:45, schrieb Eric Noulard >> >> > 2012/5/26 Kornel Benko : >> > > 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
Re: [CMake] Creating package
Am Samstag, 26. Mai 2012 um 22:02:19, schrieb Eric Noulard > 2012/5/26 Kornel Benko : > > Am Samstag, 26. Mai 2012 um 17:31:18, schrieb Kornel Benko > >> Am Samstag, 26. Mai 2012 um 16:41:45, schrieb Eric Noulard > >> > >> > 2012/5/26 Kornel Benko : > >> > > 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 : > >> > 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 /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 [ 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 : > Am Sonntag, 27. Mai 2012 um 10:41:01, schrieb Eric Noulard > > [ 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 > 2012/5/27 Kornel Benko : > > Am Sonntag, 27. Mai 2012 um 10:41:01, schrieb Eric Noulard > > > > [ 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