[tahoe-dev] 1.9.0 tarball broken

[Greg Troxel]

Brian Warner <warner at lothar.com> writes:

> On 11/9/11 5:02 AM, Greg Troxel wrote:
>
>> 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

My workaround is just 3 lines in a makefile to chmod it, and the package
builds fine, so I'm actually 100% fine with it indefinitely.  I don't
know if it's bothering other packagers, but random fixups are the norm
at some rate.

> 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.

I guess that's another reason to move to git, besides #1226 :-)


>> 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

That makes sense to me, but I don't really understand the details.

> 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).

But isn't that shell only for that make target?
And it seems there is no need to unwind within the tarball creation
process.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20111109/220df07e/attachment.pgp>