Re: Sources for 3.18-rc1 not uploaded

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:

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.

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.

                       Linus