All of lore.kernel.org
 help / color / mirror / Atom feed
* Systems with non-posix TAR implementations: How to handle
@ 2010-04-26 15:55 Tor Arntsen
  2010-04-26 17:50 ` René Scharfe
  0 siblings, 1 reply; 3+ messages in thread
From: Tor Arntsen @ 2010-04-26 15:55 UTC (permalink / raw)
  To: git

Ref. the testlog that I posted in the thread "[PATCH] Add Tru64/OSF1
support in Makefile"

*** t0024-crlf-archive.sh ***
*   ok 1: setup
* FAIL 2: tar archive


               git archive --format=tar HEAD |
               ( mkdir untarred && cd untarred && "$TAR" -xf - )

               test_cmp sample untarred/sample


 *   ok 3: zip 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?

-Tor

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Systems with non-posix TAR implementations: How to handle
  2010-04-26 15:55 Systems with non-posix TAR implementations: How to handle Tor Arntsen
@ 2010-04-26 17:50 ` René Scharfe
  2010-04-27 16:18   ` Tor Arntsen
  0 siblings, 1 reply; 3+ messages in thread
From: René Scharfe @ 2010-04-26 17:50 UTC (permalink / raw)
  To: Tor Arntsen; +Cc: git

Am 26.04.2010 17:55, schrieb Tor Arntsen:
> Ref. the testlog that I posted in the thread "[PATCH] Add Tru64/OSF1
> support in Makefile"
> 
> *** t0024-crlf-archive.sh ***
> *   ok 1: setup
> * FAIL 2: tar archive
> 
> 
>                git archive --format=tar HEAD |
>                ( mkdir untarred && cd untarred && "$TAR" -xf - )
> 
>                test_cmp sample untarred/sample
> 
> 
>  *   ok 3: zip 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.

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.

René

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Systems with non-posix TAR implementations: How to handle
  2010-04-26 17:50 ` René Scharfe
@ 2010-04-27 16:18   ` Tor Arntsen
  0 siblings, 0 replies; 3+ messages in thread
From: Tor Arntsen @ 2010-04-27 16:18 UTC (permalink / raw)
  To: René Scharfe; +Cc: git

On Mon, Apr 26, 2010 at 19:50, René Scharfe <rene.scharfe@lsrfire.ath.cx> 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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2010-04-27 16:19 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-04-26 15:55 Systems with non-posix TAR implementations: How to handle Tor Arntsen
2010-04-26 17:50 ` René Scharfe
2010-04-27 16:18   ` Tor Arntsen

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.