When I uploaded the 1.0.1 Debian packages the Debian Queue daemon
rejected the package:
Rejected: libsvn-core-perl_1.0.1-1_powerpc.deb: has 5 file(s) with a
time stamp too ancient (e.g. usr/lib/perl5/SVN/Client.pm [Mon Jan 5
23:06:34 1970]).
A bad clock on my build machine? That was my first thought. It turns
out cpio created a tarball for us with bogus timestamps:
$ tar -xjf subversion-1.0.1.tar.bz2 subversion-1.0.1/CHANGES
$ ls -l subversion-1.0.1/CHANGES
-rw-r--r-- 1 dwhedon dwhedon 67157 Mar 4 1970
$
Does anyone not see bad timestamps for any file modified after
January 11, 2004 in the subversion 1.0.1 tarballs?
I posted the details on the problem with cpio along with a patch:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=238177
This isn't that serious an issue, but it is sort of odd to be creating
tarballs with incorrect dates. I put fixed (I fixed the mtime
overflow assuming any file with a date before about 1978 had
overflowed and repackaged them with a fix cpio) tarballs up at:
http://people.debian.org/~dwhedon/cpio/subversion-1.0.1.tar.bz2
http://people.debian.org/~dwhedon/cpio/subversion-1.0.1.tar.gz
a328e05d1423f1bc3cf83980b4660b23 subversion-1.0.1.tar.bz2
3bda0519c7de61b2a112fd1b9fe6e4e1 subversion-1.0.1.tar.gz
I'm interested if anyone has a tar that has a problem with these
tarballs, and if when extracted the dates look correct.
-David
On Mon, Mar 08, 2004 at 04:47:22PM -0800, Ben Reser wrote:
> Subversion current ships a tarball created by GNU tar. However there
> are problems with this. In particular GNU tar does not follow the
> POSIX.1 standard when dealing with filenames longer than 100 characters.
> This means our tarballs can't be extracted (without getting GNU tar) on
> platforms such as Solaris that have their own POSIX compatable tar
> command.
>
> Currently subversion has several of these:
> $ find subversion-1.0.0 | perl -ne 'if (length($_) > 100) { print $_; }'
> subversion-1.0.0/subversion/bindings/java/javahl/src/org/tigris/subversion/javahl/PromptUserPassword2.java
> subversion-1.0.0/subversion/bindings/java/javahl/src/org/tigris/subversion/javahl/PromptUserPassword3.java
> subversion-1.0.0/subversion/bindings/java/javahl/src/org/tigris/subversion/javahl/SVNClientSynchronized.java
> subversion-1.0.0/subversion/bindings/java/javahl/src/org/tigris/subversion/javahl/SVNClientInterface.java
> subversion-1.0.0/subversion/bindings/java/javahl/src/org/tigris/subversion/javahl/ClientException.java
> subversion-1.0.0/subversion/bindings/java/javahl/src/org/tigris/subversion/javahl/PromptUserPassword.java
> subversion-1.0.0/subversion/bindings/java/javahl/src/org/tigris/subversion/javahl/BlameCallback.java
> subversion-1.0.0/tools/cvs2svn/test-data/default-branches-cvsrepos/proj/deleted-on-vendor-branch.txt,v
>
> You can read the details of the problems with GNU tar and the POSIX
> standard at:
> http://www.gnu.org/software/tar/manual/html_chapter/tar_8.html#SEC108
> and
> http://gd.tuwien.ac.at/utils/archivers/star/README.otherbugs
>
> As you can see above the places where we have filenames longer than 100
> chars in our tarball are in the javahl bindings and cvs2svn's test
> suite.
>
> Obviously, the cvs2svn problem is going away. So we don't need to worry
> about it. But the javahl bindings will continue to be a problem.
>
> The GNU tar suggests using the --old-archive option. But this does not
> solve our problem. As GNU tar always uses an incompatable extension
> when filenames are longer than 100 chars.
>
> So here are the possible solutions:
>
> * Move the bindings out of the subversion dir. And into the top level
> directory. This would be similar to the tools directory. Our longest
> filename is currently 108 chars long. Making that change would save us
> 11 characters keep us under the 100 char limit. However, this would
> require build system changes, documentation changes, and would not solve
> the problem if the javahl bindings end up with a filename that's only 3
> characters longer than the existing ones.
>
> * Stop using GNU tar for creating the tar archives and start using GNU
> cpio. GNU cpio supports creating tar formats in the ustar format (i.e.
> POSIX.1 format). This gives a maximum filename of 255 characters.
> Which is more than twice as long as what we are using. Does not require
> changes to anything other than dist.sh. The following command can
> replace our usage of tar and produce a POSIX.1 compatable tar file:
> find subversion-1.0.0 -print | cpio -H ustar -o > subversion-1.0.0.tar
>
> I recommend using GNU cpio. I've tested the output with Solaris and GNU
> tar and it works perfectly. If everyone is okay with this I'll post a
> patch to effect this change.
>
> --
> Ben Reser <ben@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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 15 22:27:49 2004