[tahoe-dev] 1.9.0 tarball broken

[David-Sarah Hopwood]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 294 bytes
Desc: OpenPGP digital signature
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20111109/6e948669/attachment.asc>