You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Reser <be...@reser.org> on 2004/04/03 06:57:04 UTC
Re: Testing pax on platforms was Re: Using pax instead of cpio in dist.sh
On Tue, Mar 30, 2004 at 12:00:43AM +0200, Tobias Ringstrom wrote:
> What I was trying to say was that we don't need to test if the USTAR
> format works. We did that when we started to use cpio instead of GNU
> tar to create the tarballs. We will just use another tool to create the
> same thing -- hopefully a tool with no bugs.
*cough* I think you're a little too confident here... I tried pax
tonight:
$ gzip -dc subversion-1.0.1.tar.gz | tar xvf -
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Archive contains obsolescent base-64 headers
tar: Error exit delayed from previous errors
file doesn't even think it is a tar file:
$ file subversion-1.0.1.tar
subversion-1.0.1.tar: data
I'll try it on a different machine later. I tried this on amd64 and
it's possible pax doesn't work righ ton this platform for whatever
reason (i.e. a bug).
> The only reason to test pax would be to test for bugs in the one that
> will be used to produce the official tarball. If five different pax
> implementations and versions will be used, they should either all be
> tested, or none of them needs to be tested. Pax produces USTAR files.
> That is the purpose of pax. There is no reason to test the pax in RHL9
> if you will use OS X to produce the tarballs. That was all I meant.
> That said, I think we can trust pax to be correct, and we don't need to
> test it. I'm not against testing it, of course. I just wanted to
> explain why I though that it was unneccessary to test it.
Given that we've now tried 3 different tar implementations looking for
one that produces portable and correct tar archives and so far we
haven't found one... I'm not quite as confident of this as you are.
> The decision (or even discussion) that we shouldn't have a dedicated RM
> did not happen publicly, and the outcome is not publicly available
> except in the form of little hints, so who can be blamed for missing
> that point?
Well I don't think any decision has been made. Justin and I both have
that as a goal. If it can be attained remains to be seen.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Testing pax on platforms was Re: Using pax instead of cpio in
dist.sh
Posted by Tobias Ringstrom <to...@ringstrom.mine.nu>.
Ben Reser wrote:
>>The only reason to test pax would be to test for bugs in the one that
>>will be used to produce the official tarball. If five different pax
>>implementations and versions will be used, they should either all be
>>tested, or none of them needs to be tested. Pax produces USTAR files.
>>That is the purpose of pax. There is no reason to test the pax in RHL9
>>if you will use OS X to produce the tarballs. That was all I meant.
>>That said, I think we can trust pax to be correct, and we don't need to
>>test it. I'm not against testing it, of course. I just wanted to
>>explain why I though that it was unneccessary to test it.
>
> Given that we've now tried 3 different tar implementations looking for
> one that produces portable and correct tar archives and so far we
> haven't found one... I'm not quite as confident of this as you are.
The best thing would be to have one dedicated release build machine to
make sure that our releases are of a consistent (high) quality. So far
we've have new dist bugs with almost every release. :-(
Will you really send out new test tarballs each time you build the
release on a new machine? In case it's not possible to have a dedicated
release build machine, I was trying to suggest that the probablity of a
pax bug is low enough that we can risk a release, and if there is a pax
bug on that build machine, we can quickly release another release.
Release numbers are relatively cheap, and the probability is low.
/Tobias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Testing pax on platforms was Re: Using pax instead of cpio in dist.sh
Posted by Ben Reser <be...@reser.org>.
On Fri, Apr 02, 2004 at 10:57:04PM -0800, Ben Reser wrote:
> *cough* I think you're a little too confident here... I tried pax
> tonight:
>
> $ gzip -dc subversion-1.0.1.tar.gz | tar xvf -
> tar: This does not look like a tar archive
> tar: Skipping to next header
> tar: Archive contains obsolescent base-64 headers
> tar: Error exit delayed from previous errors
>
> file doesn't even think it is a tar file:
> $ file subversion-1.0.1.tar
> subversion-1.0.1.tar: data
>
> I'll try it on a different machine later. I tried this on amd64 and
> it's possible pax doesn't work righ ton this platform for whatever
> reason (i.e. a bug).
Okay found the issue. It was a minor error in the dist.sh script that
probably wouldn't show up in most peoples environments. It was
capturing the output of the cd command. Since I have $CDPATH set the cd
was ambiguous so bash spat out what dir it really changed to. Commit
to fix coming up on trunk soon.
I'll post a new thread with URLs to test tarballs.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org