#802 closed defect (was already fixed)

MacOS X Test Failures

Reported by: bewst Owned by: zooko
Priority: major Milestone: eventually
Component: packaging Version: 1.5.0
Keywords: pycryptopp mac ubuntu Cc:
Launchpad Bug:

Description

Build looks good, but python setup.py test gives the following. It's still running but all the tests marked [ERROR] seem to be taking forever and then, perhaps, timing out. Partial log attached.

Attachments (1)

test.log (22.4 KB) - added by bewst at 2009-09-13T01:55:59Z.
log of python setup.py test

Download all attachments as: .zip

Change History (16)

Changed at 2009-09-13T01:55:59Z by bewst

log of python setup.py test

comment:1 Changed at 2009-09-13T02:00:28Z by bewst

Heh, interesting: I got past that first traceback by preceding the test by "sudo" (should that really be necessary?) but that doesn't seem to change what happens around test_download_abort_if_too_many_missing_shares, which is a bunch of errors and a big slowdown.

comment:2 follow-up: Changed at 2009-09-14T02:19:39Z by zooko

Thank you very much for the bug report.

Hmmm. Is this Mac OS 10.6? There is a known bug in pycryptopp on that platform. (The current trunk of pycryptopp has that bug fixed, so you could try installing the current trunk of pycryptopp and see if that fixes it.)

The permission error with "dropin.cache.new" is described here:

http://twistedmatrix.com/trac/wiki/FrequentlyAskedQuestions#WhydoIgetaPermissiondeniederrortryingtowrite...site-packagestwistedpluginsdropin.cache.newwhenIusetwistdortrialorsomeotherTwistedprogram

Running the whole test with "sudo" is definitely not right, and perhaps you ought to now do something to repair any damage, such as sudo chown -R `whoami` .. :-)

Could you please attach the _trial_temp/test.log file from the failing test?

comment:3 Changed at 2009-09-21T21:05:45Z by zooko

  • Owner changed from nobody to bewst

comment:4 in reply to: ↑ 2 Changed at 2009-09-22T02:29:52Z by bewst

  • Status changed from new to assigned

Replying to zooko:

Thank you very much for the bug report.

Hmmm. Is this Mac OS 10.6?

Yes, it is.

There is a known bug in pycryptopp on that platform. (The current trunk of pycryptopp has that bug fixed, so you could try installing the current trunk of pycryptopp and see if that fixes it.)

I'll do that.

Could you please attach the _trial_temp/test.log file from the failing test?

As soon as I install a fixed pycryptopp.

comment:5 Changed at 2009-10-27T03:09:48Z by zooko

The current release of pycryptopp -- v0.5.17 -- works on Mac OS 10.6.

comment:6 Changed at 2009-10-27T20:29:12Z by davidsarah

Should the version requirement in _auto_deps.py be updated to "pycryptopp >= 0.5.17"?

comment:7 Changed at 2009-10-29T04:20:34Z by zooko

  • Milestone changed from undecided to 0.3.0

Hm. I hate to impose that constraint on platforms where they don't need the newer pycryptopp. pycryptopp-0.5.17 is necessary for Mac OS 10.6 and for Fedora amd64, and it may or may not be needed for other Linux amd64. pycryptopp-0.5.15 is necessary for AthlonXP and old-style Celeron.

Also note that the latest pycryptopp-0.5.17 won't build properly with the brand new Ubuntu Karmic: https://bugs.launchpad.net/ubuntu/+bug/461303 .

Anyway, maybe we should increase that requirement, or do so on the known-to-be-affected platforms. I'd like to put it off and think about it for a bit first, though. For one thing, we have a recurring problem with people being unable to install Tahoe-LAFS because they can't install pycryptopp. One of the main ways that I intend to address that problem is for buildslaves to build binary libraries ("eggs") of pycryptopp and upload them to here: http://allmydata.org/source/tahoe/deps/tahoe-dep-eggs . The idea is that the Tahoe-LAFS build system (using setuptools) will automatically download the appropriate binary egg from that list for the platform on which it is building.

That mechanism basically works, but we haven't set up buildslaves for all the right platforms and all of the dependencies and tested it out.

comment:8 Changed at 2009-11-03T03:31:03Z by davidsarah

  • Component changed from unknown to packaging
  • Keywords pycryptopp added
  • Milestone changed from 0.3.0 to 1.6.0

comment:9 Changed at 2009-12-06T00:27:57Z by davidsarah

  • Keywords ubuntu added

comment:10 Changed at 2009-12-06T00:28:23Z by davidsarah

  • Keywords mac added

comment:11 Changed at 2009-12-23T23:14:41Z by zooko

I guess we should configure _auto_deps.py to require pycryptopp >= 0.5.17 if the platform is Mac OS X or is 64-bit Linux and to require pycryptopp >= 0.5.15 if not.

comment:12 Changed at 2010-01-26T15:38:49Z by zooko

  • Milestone changed from 1.6.0 to eventually

comment:13 Changed at 2010-09-04T17:17:46Z by zooko

  • Owner changed from bewst to zooko
  • Status changed from assigned to new

comment:14 Changed at 2010-09-04T17:18:07Z by zooko

  • Status changed from new to assigned

comment:15 Changed at 2014-09-08T16:39:23Z by daira

  • Resolution set to was already fixed
  • Status changed from assigned to closed

The current pycryptopp dependency is >= 0.6.0, so this is probably no longer an issue.

Note: See TracTickets for help on using tickets.