On Mon, Apr 26, 2010 at 19:50, René Scharfe <rene.scharfe@xxxxxxxxxxxxxx> wrote: > Am 26.04.2010 17:55, schrieb Tor Arntsen: [..] >> *** t0024-crlf-archive.sh *** >> * ok 1: setup >> * FAIL 2: tar archive [..] >> The problem with that test is that the Tru64 V5.1 'tar' says 'This >> doesn't look like a tar archive' on the generated file. However, it >> turns out that the tar file generated by 'git archive --format=tar' is >> fine, it's just that it's a POSIX tar archive and the Tru64 'tar' >> program isn't POSIX tar format compatible. >> How should we handle this? Just ignore errors in this test on Tru64, >> or is there some other way that I missed? > > That depends: if you just want to make sure that the test works fine, > you could install GNU tar, perhaps as gtar, and let TAR in Makefile (or > config.mak) point to it. If the test fails with a tar that understands > the format then you've found a bug. Done. Everything's fine with gtar. As far as the OSF1 'make test' is concerned I've re-run it with gtar, native compiler and SHELL_PATH=<self-compiled-bash>, and everything looks fine except some UTF8 conversion tests which may be caused by some iconv lib issues on this platform. > It could get a bit more complicated if you want to use git archive to > create tar files that the native tar can understand. For most repos it > should be sufficient to specify a tree instead of a commit, e.g. with an > added colon: > > git archive -o archive-without-comment.tar HEAD: > > This makes git archive leave out the comment entry, which might upset > some tar implementations. I don't know if that's sufficient to make > Tru64 tar happy, though. It indeed is happy with that, this will be very useful to know when working on OSF1 and only having the native tar application. Thanks, -Tor -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html