[tahoe-dev] [tahoe-lafs] #1014: provide binary .egg's for pyOpenSSL for linux-{i386, amd64}-py2.{5, 6}-ucs4
tahoe-lafs
trac at tahoe-lafs.org
Sun Oct 31 06:14:14 UTC 2010
#1014: provide binary .egg's for pyOpenSSL for linux-{i386,amd64}-py2.{5,6}-ucs4
---------------------------+------------------------------------------------
Reporter: nejucomo | Owner: nejucomo
Type: defect | Status: new
Priority: major | Milestone: 1.8.1
Component: packaging | Version: 1.6.1
Resolution: | Keywords: binaries openssl debian install docs
Launchpad Bug: |
---------------------------+------------------------------------------------
Changes (by zooko):
* keywords: openssl debian install docs => binaries openssl debian
install docs
* milestone: undecided => 1.8.1
Comment:
Since the newest version of pyOpenSSL listed on
http://launchpad.net/pyopenssl at the moment is 0.11a2, then we need to
build bdist_egg's of pyOpenSSL 0.11a2 for all platforms which we intend
for people to be able to install Tahoe-LAFS v1.8.1 without having a C
compiler and Python headers installed. (Note that the upstream maintainers
of pyOpenSSL ''might'' be willing to provide binaries if we ask nicely:
https://bugs.launchpad.net/pyopenssl/+bug/238658 .)
Sadly, if we do all the work to build and host such binary eggs, and then
a new version of pyOpenSSL gets uploaded to !PyPI or launchpad or in
source form only, then our build scripts will immediately start refusing
to use the pyOpenSSL 0.11a2 binaries that we built. Fixing this so that
our build scripts would continue to use the pyOpenSSL 0.11a2 binaries (or
even good old pyOpenSSL 0.10 binaries) even if a newer version of
pyOpenSSL is known to them is the subject of #1233.
--
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1014#comment:4>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage
More information about the tahoe-dev
mailing list