Custom Query (72 matches)

When using the prebuilt pycryptopp-0.5.29-py2.7-win32.egg hosted at tahoe-lafs.org, the start_up_self_test for SHA-256 would hang at the first call to digest() here. Rebuilding the egg using Visual Studio 2008 Express (with Windows updates applied) caused this problem to go away. The new egg has now been copied to ​http://tahoe-lafs.org/source/tahoe-lafs/deps/tahoe-dep-eggs/pycryptopp-0.5.29-py2.7-win32.egg , and the broken one is at ​http://tahoe-lafs.org/source/tahoe-lafs/deps/tahoe-dep-eggs/pycryptopp-0.5.29-py2.7-win32.egg.broken .

I don't know whether any of the other pycryptopp eggs are similarly broken.

Note that the symptoms are very similar to the binutils-related bug ​http://tahoe-lafs.org/trac/tahoe-lafs/ticket/853 (caused by ​https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/461303 ). It is possible that the broken pycryptopp-0.5.29-py2.7-win32.egg was built with a broken version of gas, but I don't know how to confirm that.

If there were pycryptopp buildslaves building the eggs for Windows, they would automatically run the unit tests, which would have found this build problem. Building the eggs manually is very error-prone, and information about the build environment is lost. (Four buildslaves are needed: Python 2.6 and 2.7 for 32-bit and 64-bit Windows.)

Wanted in order to take advantage of any fix to ​http://twistedmatrix.com/trac/ticket/4633 , and eliminate Tahoe-LAFS' dependency on PyCrypto.

Wanted in order to take advantage of any fix to ​http://twistedmatrix.com/trac/ticket/4633 , and eliminate Tahoe-LAFS' dependency on PyCrypto?.