Hi,
The way we upload the Linux kernel to kernel.org involves creating a tar
archive, signing the archive, and then just uploading the signature.
The server then checks out the repo based on the tag, generates the tar
archive and checks the signature to make sure they match.
A few days ago I released the 3.0.61 kernel, and it turned out that I
couldn't upload the kernel release because 'git archive' now creates a
binary file that differs from an older version of git.
I tracked this down to commit 22f0dcd9634a818a0c83f23ea1a48f2d620c0546
(archive-tar: split long paths more carefully). The diff of a hex dump
of the tar archives shows the following difference:
--- old_git_archive 2013-01-31 17:31:24.466343388 +0100
+++ new_git_archive 2013-01-31 17:32:21.509674417 +0100
@@ -19239998,8 +19239998,8 @@
125943d0:0000 0000 0000 0000 0000 0000 0000 0000 ................
125943e0:0000 0000 0000 0000 0000 0000 0000 0000 ................
125943f0:0000 0000 0000 0000 0000 0000 0000 0000 ................
-12594400:0000 0000 0000 0000 0000 0000 0000 0000 ................
-12594410:0000 0000 0000 0000 0000 0000 0000 0000 ................
+12594400:7765 7374 6272 6964 6765 2d6f 6d61 7033 westbridge-omap3
+12594410:2d70 6e61 6e64 2d68 616c 2f00 0000 0000 -pnand-hal/.....
12594420:0000 0000 0000 0000 0000 0000 0000 0000 ................
12594430:0000 0000 0000 0000 0000 0000 0000 0000 ................
12594440:0000 0000 0000 0000 0000 0000 0000 0000 ................
@@ -19240025,8 +19240025,8 @@
12594580:2f61 7374 6f72 6961 2f61 7263 682f 6172 /astoria/arch/ar
12594590:6d2f 706c 6174 2d6f 6d61 702f 696e 636c m/plat-omap/incl
125945a0:7564 652f 6d61 6368 2f77 6573 7462 7269 ude/mach/westbri
-125945b0:6467 652f 7765 7374 6272 6964 6765 2d6f dge/westbridge-o
-125945c0:6d61 7033 2d70 6e61 6e64 2d68 616c 0000 map3-pnand-hal..
+125945b0:6467 6500 0000 0000 0000 0000 0000 0000 dge.............
+125945c0:0000 0000 0000 0000 0000 0000 0000 0000 ................
125945d0:0000 0000 0000 0000 0000 0000 0000 0000 ................
125945e0:0000 0000 0000 0000 0000 0000 0000 0000 ................
125945f0:0000 0000 0000 0000 0000 0000 0000 0000 ................
Interestingly, the output of uncompressing the tar archives is
identical, so the data is correct, but the binary isn't.
Now keeping binary compatibility of tar archive files isn't really a big
deal, but, the commit to git that causes this seems a bit odd, is it
really needed? Or can we just fix the version of tar with NetBSD
instead? :)
Any ideas?
thanks,
greg k-h
Am 31.01.2013 18:28, schrieb Greg KH:
quoted hunk
I tracked this down to commit 22f0dcd9634a818a0c83f23ea1a48f2d620c0546
(archive-tar: split long paths more carefully). The diff of a hex dump
of the tar archives shows the following difference:
--- old_git_archive 2013-01-31 17:31:24.466343388 +0100
+++ new_git_archive 2013-01-31 17:32:21.509674417 +0100
@@ -19239998,8 +19239998,8 @@
125943d0:0000 0000 0000 0000 0000 0000 0000 0000 ................
125943e0:0000 0000 0000 0000 0000 0000 0000 0000 ................
125943f0:0000 0000 0000 0000 0000 0000 0000 0000 ................
-12594400:0000 0000 0000 0000 0000 0000 0000 0000 ................
-12594410:0000 0000 0000 0000 0000 0000 0000 0000 ................
+12594400:7765 7374 6272 6964 6765 2d6f 6d61 7033 westbridge-omap3
+12594410:2d70 6e61 6e64 2d68 616c 2f00 0000 0000 -pnand-hal/.....
12594420:0000 0000 0000 0000 0000 0000 0000 0000 ................
12594430:0000 0000 0000 0000 0000 0000 0000 0000 ................
12594440:0000 0000 0000 0000 0000 0000 0000 0000 ................
@@ -19240025,8 +19240025,8 @@
12594580:2f61 7374 6f72 6961 2f61 7263 682f 6172 /astoria/arch/ar
12594590:6d2f 706c 6174 2d6f 6d61 702f 696e 636c m/plat-omap/incl
125945a0:7564 652f 6d61 6368 2f77 6573 7462 7269 ude/mach/westbri
-125945b0:6467 652f 7765 7374 6272 6964 6765 2d6f dge/westbridge-o
-125945c0:6d61 7033 2d70 6e61 6e64 2d68 616c 0000 map3-pnand-hal..
+125945b0:6467 6500 0000 0000 0000 0000 0000 0000 dge.............
+125945c0:0000 0000 0000 0000 0000 0000 0000 0000 ................
125945d0:0000 0000 0000 0000 0000 0000 0000 0000 ................
125945e0:0000 0000 0000 0000 0000 0000 0000 0000 ................
125945f0:0000 0000 0000 0000 0000 0000 0000 0000 ................
This is the only directory in the repository whose path is long enough to
make a difference with the patch, 105 characters in total:
drivers/staging/westbridge/astoria/arch/arm/plat-omap/include/mach/westbridge/westbridge-omap3-pnand-hal/
Five characters less and you wouldn't notice a thing. It contains
"westbridge" thrice, so I think it's cheating just to reach that
length, though. ;-)
Interestingly, the output of uncompressing the tar archives is
identical, so the data is correct, but the binary isn't.
The path is split differently between two header fields, that's all.
Now keeping binary compatibility of tar archive files isn't really a big
deal, but, the commit to git that causes this seems a bit odd, is it
really needed? Or can we just fix the version of tar with NetBSD
instead? :)
Apart from Junio's suggestion, I can't think of a practical solution.
You could downgrade your git to a version before the fix. A downside is
that you won't be able to extract the archive on NetBSD without getting
an error message (but the contents would be intact, except perhaps for
permission bits of the directory above).
You could upgrade the kernel.org version of git, but that might cause the
same problem for other maintainers with long directory paths who in their
repositories who still use git without the fix.
You could make the path shorter. Won't help at all with the release you
just did, of course.
I don't know if other tar implementations freak out when they see an
empty name field. NetBSD's tar might seem a bit too strict here, but
overall I think it's right in complaining.
What makes the commit odd, by the way?
Thanks,
René
On Thu, Jan 31, 2013 at 07:33:52PM +0100, René Scharfe wrote:
Am 31.01.2013 18:28, schrieb Greg KH:
quoted
I tracked this down to commit 22f0dcd9634a818a0c83f23ea1a48f2d620c0546
(archive-tar: split long paths more carefully). The diff of a hex dump
of the tar archives shows the following difference:
--- old_git_archive 2013-01-31 17:31:24.466343388 +0100
+++ new_git_archive 2013-01-31 17:32:21.509674417 +0100
@@ -19239998,8 +19239998,8 @@
125943d0:0000 0000 0000 0000 0000 0000 0000 0000 ................
125943e0:0000 0000 0000 0000 0000 0000 0000 0000 ................
125943f0:0000 0000 0000 0000 0000 0000 0000 0000 ................
-12594400:0000 0000 0000 0000 0000 0000 0000 0000 ................
-12594410:0000 0000 0000 0000 0000 0000 0000 0000 ................
+12594400:7765 7374 6272 6964 6765 2d6f 6d61 7033 westbridge-omap3
+12594410:2d70 6e61 6e64 2d68 616c 2f00 0000 0000 -pnand-hal/.....
12594420:0000 0000 0000 0000 0000 0000 0000 0000 ................
12594430:0000 0000 0000 0000 0000 0000 0000 0000 ................
12594440:0000 0000 0000 0000 0000 0000 0000 0000 ................
@@ -19240025,8 +19240025,8 @@
12594580:2f61 7374 6f72 6961 2f61 7263 682f 6172 /astoria/arch/ar
12594590:6d2f 706c 6174 2d6f 6d61 702f 696e 636c m/plat-omap/incl
125945a0:7564 652f 6d61 6368 2f77 6573 7462 7269 ude/mach/westbri
-125945b0:6467 652f 7765 7374 6272 6964 6765 2d6f dge/westbridge-o
-125945c0:6d61 7033 2d70 6e61 6e64 2d68 616c 0000 map3-pnand-hal..
+125945b0:6467 6500 0000 0000 0000 0000 0000 0000 dge.............
+125945c0:0000 0000 0000 0000 0000 0000 0000 0000 ................
125945d0:0000 0000 0000 0000 0000 0000 0000 0000 ................
125945e0:0000 0000 0000 0000 0000 0000 0000 0000 ................
125945f0:0000 0000 0000 0000 0000 0000 0000 0000 ................
This is the only directory in the repository whose path is long enough to
make a difference with the patch, 105 characters in total:
drivers/staging/westbridge/astoria/arch/arm/plat-omap/include/mach/westbridge/westbridge-omap3-pnand-hal/
Five characters less and you wouldn't notice a thing. It contains
"westbridge" thrice, so I think it's cheating just to reach that
length, though. ;-)
Yeah, that file path was bad, which is just one reason why it was
deleted from the kernel in newer versions :)
quoted
Interestingly, the output of uncompressing the tar archives is
identical, so the data is correct, but the binary isn't.
The path is split differently between two header fields, that's all.
Ok, thanks for the explaination, I didn't realize that.
quoted
Now keeping binary compatibility of tar archive files isn't really a big
deal, but, the commit to git that causes this seems a bit odd, is it
really needed? Or can we just fix the version of tar with NetBSD
instead? :)
Apart from Junio's suggestion, I can't think of a practical solution.
You could downgrade your git to a version before the fix. A downside is
that you won't be able to extract the archive on NetBSD without getting
an error message (but the contents would be intact, except perhaps for
permission bits of the directory above).
You could upgrade the kernel.org version of git, but that might cause the
same problem for other maintainers with long directory paths who in their
repositories who still use git without the fix.
You could make the path shorter. Won't help at all with the release you
just did, of course.
What I ended up doing was just to revert your patch, generating a tar
archive that matches what the version on kernel.org.
And originally I now recall that this was something we were worried
about, but we put off dealing with it until it caused problems :)
I don't know if other tar implementations freak out when they see an
empty name field. NetBSD's tar might seem a bit too strict here, but
overall I think it's right in complaining.
Ok, thanks, I now agree.
What makes the commit odd, by the way?
Sorry, I was originally thinking that you were working around a bug in
the NetBSD version of tar, not making it "more correct", which is
arguably the right thing to do here.
So I'll work with Konstantine to ensure we both are using the same
version of git in the future, it's our kernel.org infrastructure issue
here, not a git one, sorry for the noise.
greg k-h