[tahoe-lafs-trac-stream] [tahoe-lafs] #1418: "cannot convert float NaN to integer" in next_power_of_k, during upload via helper

[tahoe-lafs]

#1418: "cannot convert float NaN to integer" in next_power_of_k, during upload via
helper
-------------------------+-------------------------------------------------
     Reporter:  rycee    |      Owner:  rycee
         Type:  defect   |     Status:  new
     Priority:  major    |  Milestone:  undecided
    Component:  code     |    Version:  1.8.2
   Resolution:           |   Keywords:  helper upload heisenbug
Launchpad Bug:           |  floatingpoint debian pycryptopp
-------------------------+-------------------------------------------------

Comment (by rycee):

 I added 0.5.17 as an upper bound in _auto_deps.py and running setup.py
 build now prints
 {{{
 …
 Searching for pycryptopp>=0.5.14,<=0.5.17
 Reading http://tahoe-lafs.org/source/tahoe-lafs/deps/tahoe-dep-sdists/
 Reading http://tahoe-lafs.org/source/tahoe-lafs/deps/tahoe-lafs-dep-eggs/
 Reading http://pypi.python.org/simple/pycryptopp/
 Reading http://allmydata.org/source/pycryptopp
 Reading http://allmydata.org/trac/pycryptopp
 Reading http://tahoe-lafs.org/trac/pycryptopp
 Reading http://allmydata.org/source/zfec
 Best match: pycryptopp 0.5.17
 Downloading
 http://pypi.python.org/packages/source/p/pycryptopp/pycryptopp-0.5.17.tar.gz#md5=b3d19e7203531f8bd241ae58062f99e4
 Processing pycryptopp-0.5.17.tar.gz
 Running pycryptopp-0.5.17/setup.py -q bdist_egg --dist-dir /tmp
 /easy_install-SlyAet/pycryptopp-0.5.17/egg-dist-tmp-2wdZ7B
 …
 }}}
 and it goes on to spend quite some time building the crypto++ library.
 After finishing, this build successfully runs the the previously failing
 test even though it's Tahoe version 1.8.2. If I then replace the
 `_pycryptopp.so` file from inside this Tahoe tree with the corresponding
 file from the Debian package the error comes back. The Debian version of
 pycryptopp is dynamically linked against
 [http://packages.debian.org/squeeze/libcrypto++8 crypto++ version
 5.6.0-6].

 So, finally, leaving Debian's `_pycryptopp.so` in place, I tried
 downloading and building a dynamic library from upstream crypto++ 5.6.0
 and 5.6.1 and substituting Debian's copy. Curiously the test failed with
 5.6.0 and worked with 5.6.1…

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1418#comment:44>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage