On 10/14/11 8:04 AM, Greg Troxel wrote: > Thanks for 1) making the unpacked dir match the version in the file and
Glad that helps.. it's part of the tarball-generation automation, so it should always work that way. > I am assuming while a new foolscap release is pending, 1.9.0 will not > require it. Correct. The dependency is actually going to be driven by Twisted. Tahoe (both current 1.8.3 and upcoming 1.9.0) is happy with both current Foolscap-0.6.1 and upcoming Foolscap-0.6.2 . Both current Foolscap-0.6.1 and upcoming Foolscap-0.6.2 are happy with current Twisted-11.0.0 . But current Foolscap-0.6.1 is not compatible with Twisted trunk, which means that as soon as they make their next release, 0.6.1 won't be compatible with that. So Foolscap-0.6.2 will be a pre-emptive compatibility strike. I'm not sure how Tahoe is most likely to express this, or if it's even possible to do something on the Tahoe side to help users get compatible versions of the dependencies. The worry is that someone will either a) have a working installation, update Twisted (but not Foolscap), and then things will break, or b) will have Foolscap-0.6.1 already installed, install Tahoe from scratch, wind up with a later Twisted version, and things will break. We've addressed this in the past by articifically raising the dependency on the troubled library (in this case it'd be by declaring Tahoe to require Foolscap-0.6.2, even though it doesn't really). But I don't think we'll do that until the new Twisted comes out, if at all. (their current release was made last January, so they're kinda due, but I haven't seen any schedules). > I did get the following complaints when building: allmydata/test/check_grid.py allmydata/test/check_load.py allmydata/test/check_memory.py allmydata/test/check_speed.py allmydata/test/test_base62.py allmydata/util/base62.py The last two are a clear mistake: those libraries don't need interpreter shbang lines. The other four are occasionally run as developer testing tools: check_memory.py and check_speed.py are run by our buildbot on each commit, check_grid.py was run to make sure the old AllMyData production grid was still working, and check_load.py is a manually-triggered traffic-generator for load testing. I think we can just remove the shbang lines from them.. to get the Tahoe dependencies right, they're all run from our Makefile with a funky "@" invocation that winds up running "python .../check_speed.py", so the interpreter line isn't really necessary. I'll land a patch to fix that shortly. Thanks for the catch! cheers, -Brian _______________________________________________ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev