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 _______________________________________________ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
