On 09/11/11 09:49, Brian Warner wrote: > 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.
-1 on releasing a 1.9.1 for this issue. A mistake in generating the tarball doesn't justify a new release. We've had such mistakes before and have not made a new release. If the code had already been packaged in OS distributions, that would be a different case, but it hasn't (and such distributions have a convention for changing the package version without requiring an upstream release). >> Why doesn't the setup code force the umask? >> It seems like this should not depend on the environment. Yes, this is a bug in setuptools. We need to stop using setuptools. > 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). Can you use a subshell to avoid that (something like /bin/sh -c 'umask 022 && ...')? -- David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
