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