Re: Sources for 3.18-rc1 not uploaded

Linus Torvalds [off-list ref] writes:

Junio, Brian,

  it seems that the stability of the "git tar" output is broken.

On Mon, Oct 20, 2014 at 4:59 AM, Konstantin Ryabitsev
[off-list ref] wrote:

quoted

Looks like 3.18-rc1 upload didn't work:

This is why the front page still lists 3.17 as the latest mainline. Want
to try again?

Ok, tried again, and failed again.

quoted

If that still doesn't work, you may have to use version 1.7 of git when
generating the tarball and signature -- I recall Greg having a similar
problem in the past.

Ugh, yes, that seems to be it. Current git generates different
tar-files than older releases do:

   tar-1.7.9.7 tar-cur differ: byte 107, line 1

and a quick bisection shows that it is due to commit 10f343ea814f
("archive: honor tar.umask even for pax headers") in the current git
development version.

Junio, quite frankly, I don't think that that fix was a good idea. I'd
suggest having a *separate* umask for the pax headers, so that we do
not  break this long-lasting stability of "git archive" output in ways
that are unfixable and not compatible. kernel.org has relied (for a
*long* time) on being able to just upload the signature of the
resulting tar-file, because both sides can generate the same tar-fiel
bit-for-bit.

So instead of using "tar_umask", please make it use "tar_pax_umask",
and have that default to 000. Ok?

Something like the attached patch.

Or just revert 10f343ea814f entirely.

My preference for this particular one however is to simply revert
it.  I do not see much point in bending backwards to treat older
implementations of tar that do not understand extended pax headers
very specially by adding a separate option or configuration, even
though I wouldn't have minded if the original implementation were to
apply the same umask for these entries that look like "dummy files"
to them.

I have to wonder why 10f343ea (archive: honor tar.umask even for pax
headers, 2014-08-03) is a problem but an earlier change v1.8.1.1~8^2
(archive-tar: split long paths more carefully, 2013-01-05), which
also should have broken bit-for-bit compatibility, went unnoticed,
though.  What I am getting at is that correcting past mistakes in
the output should not be forbidden unconditionally with a complaint
like this.

If 10f343ea were an important fix, then my preference would have
been to instead add "tar_ignore_umask_in_pax_header" to allow those
who care more about bit-for-bit compatibility with older broken
versions than correctness to conditionally disable its code.  But I
do not think it is, so my preference isn't.

Thanks.

On 20/10/14 02:28 PM, Junio C Hamano wrote:

I have to wonder why 10f343ea (archive: honor tar.umask even for pax
headers, 2014-08-03) is a problem but an earlier change v1.8.1.1~8^2
(archive-tar: split long paths more carefully, 2013-01-05), which
also should have broken bit-for-bit compatibility, went unnoticed,
though.  What I am getting at is that correcting past mistakes in
the output should not be forbidden unconditionally with a complaint
like this.

I think Greg actually ran into that one, and uses a separate 1.7 git
tree for this reason.

I can update our servers to git 2.1 (which most of them already have),
which should help with previous incompatibilities -- but not the future
ones obviously. :)

-K

On Mon, Oct 20, 2014 at 02:37:09PM -0400, Konstantin Ryabitsev wrote:

On 20/10/14 02:28 PM, Junio C Hamano wrote:

quoted

I have to wonder why 10f343ea (archive: honor tar.umask even for pax
headers, 2014-08-03) is a problem but an earlier change v1.8.1.1~8^2
(archive-tar: split long paths more carefully, 2013-01-05), which
also should have broken bit-for-bit compatibility, went unnoticed,
though.  What I am getting at is that correcting past mistakes in
the output should not be forbidden unconditionally with a complaint
like this.

I think Greg actually ran into that one, and uses a separate 1.7 git
tree for this reason.

I used to have to do this for the 3.0-stable kernel as one of the files
in it ran into the "very long path" problem.  I just ran the latest
version of git with that one commit reverted and all was fine.

After 3.0 was done, I just dropped that patch from my local version and
have been running with the latest git version of git with no problems.

I can update our servers to git 2.1 (which most of them already have),
which should help with previous incompatibilities -- but not the future
ones obviously. :)

I thought you already did this.  Or was that only the public facing git
servers?

thanks,

greg k-h