[tahoe-dev] 1.9.0 tarball broken

[Brian Warner]

On 11/9/11 5:02 AM, Greg Troxel wrote:
>
>    I'll repack the existing 1.9.0 tarballs tomorrow and put them back
>    at the same URLs, and republish the hashes.
>
> A new version number please - packaging systems expect tarballs once
> published to be invariant (since they store their own hashes), and the
> same file name with different contents looks like an attack.

Sure thing. If you're ok with your workaround, I'll probably wait until
the weekend (and after the Summit) to spin 1.9.1. It won't be as trivial
as I'd like, since it'll involve figuring out some branching issues (the
changes that landed on trunk since 1.9.0 was tagged are too new for
release, so we'll need to make a 1.9.1 that's only a few (documentation)
lines different than 1.9.0, and that means a branch, and darcs does not
make branching easy.

> Why doesn't the setup code force the umask?
> It seems like this should not depend on the environment.

It'd be great if it behaved that way. Tarballs are generated by a
script, in the "make tarballs" target of the source tree's top-level
Makefile. The execution that created the 1.9.0 tarballs was logged here:

 
https://tahoe-lafs.org/buildbot-tahoe-lafs/builders/tarballs/builds/871/steps/tarballs/logs/stdio

It uses the standard Distutils "setup.py sdist" command, which
apparently doesn't set the umask and just inherits it from the
environment.

What I think I'll do is add a "umask 002" setting in the Makefile
target. (it's non-ideal, because changing the umask is harder to unwind
than, say, setting an environment variable, so running 'make tarballs'
will have a subtle lingering side-effect on the shell in which it is
run).

cheers,
  -Brian