[tahoe-lafs-trac-stream] [Tahoe-LAFS] #1009: -SUMO package doesn't build on XP
Tahoe-LAFS
trac at tahoe-lafs.org
Sat Mar 26 23:35:56 UTC 2016
#1009: -SUMO package doesn't build on XP
---------------------------+-----------------------------
Reporter: zooko | Owner: warner
Type: defect | Status: closed
Priority: minor | Milestone: 1.11.0
Component: packaging | Version: 1.6.1
Resolution: invalid | Keywords: windows openssl
Launchpad Bug: |
---------------------------+-----------------------------
Changes (by warner):
* status: new => closed
* resolution: => invalid
* milestone: undecided => 1.11.0
Old description:
> According to NODA Kai's message of Jan 31: http://allmydata.org/pipermail
> /tahoe-dev/2010-January/003729.html
> {{{
> allmydata-tahoe-1.5.0-r4207-SUMO.tar.bz2 doesn't build on WinXP.
> As in the log below, ssleay32.a is required but there's no such file.
> A tarball without -SUMO happily builds, so there will be a difference
> between pyOpenSSL within -SUMO package and one which is DLed during
> building of non-SUMO package.
> The same problem is observed with allmydata-tahoe-1.5.0-SUMO.tar.bz2.
>
> > C:\allmydata-tahoe-1.5.0-r4207-SUMO>python.exe setup.py build
> [snip]
> > Searching for pyOpenSSL
> > Best match: pyOpenSSL 0.9
> > Processing pyopenssl-0.9.tar.gz
> > Running pyOpenSSL-0.9\setup.py -q bdist_egg --dist-dir
> c:\docume~1\nodakai\locals~1\temp\easy_install-ck1hd4\pyOpenSSL-0.9\egg-
> dist-tmp-94xmz9
> > error: Setup script exited with Cannot find ssleay32.a, aborting
> }}}
> The reason the non-SUMO build works is that setuptools detects the right
> binary pyOpenSSL package for the version of Python and Windows and
> downloads that. I don't immediately see how to make the SUMO build do the
> right thing, so I guess the solution is to document the SUMO build as
> requiring a pre-installed copy of OpenSSL and a compiler and include
> paths to build on Windows, or perhaps to document the SUMO build as
> requiring that you install pyOpenSSL yourself, or perhaps documenting the
> SUMO build as not supported on Windows.
>
> Personally, I would rather kill the entire idea of a SUMO build. It is a
> support burden (it complicates the "how to install" process by offering
> another option, and the SUMO option may or may not work) and I personally
> don't value the feature of installing on a Desert Island enough to
> allocate my limited time to it. It certainly doesn't have tests that get
> automatically executed on Windows, or we wouldn't have used Kai as a
> human buildslave to discover that this problem existed.
>
> I think part of what is going on is that our packaging needs are changing
> as Tahoe-LAFS is being integrated into distributions like Ubuntu, Debian,
> Fedora, NixOS, and Gentoo. If you are planning to be stranded on a Desert
> Island and you want Tahoe-LAFS there, just install one of those operating
> systems on your laptop before your trip.
>
> I'm assigning this to Brian since the SUMO build was his idea. Brian:
> please reply with either "fine, kill the SUMO build" or "no, don't".
> Thanks!
New description:
According to NODA Kai's message of Jan 31: http://allmydata.org/pipermail
/tahoe-dev/2010-January/003729.html
{{{
allmydata-tahoe-1.5.0-r4207-SUMO.tar.bz2 doesn't build on WinXP.
As in the log below, ssleay32.a is required but there's no such file.
A tarball without -SUMO happily builds, so there will be a difference
between pyOpenSSL within -SUMO package and one which is DLed during
building of non-SUMO package.
The same problem is observed with allmydata-tahoe-1.5.0-SUMO.tar.bz2.
> C:\allmydata-tahoe-1.5.0-r4207-SUMO>python.exe setup.py build
[snip]
> Searching for pyOpenSSL
> Best match: pyOpenSSL 0.9
> Processing pyopenssl-0.9.tar.gz
> Running pyOpenSSL-0.9\setup.py -q bdist_egg --dist-dir
c:\docume~1\nodakai\locals~1\temp\easy_install-ck1hd4\pyOpenSSL-0.9\egg-
dist-tmp-94xmz9
> error: Setup script exited with Cannot find ssleay32.a, aborting
}}}
The reason the non-SUMO build works is that setuptools detects the right
binary pyOpenSSL package for the version of Python and Windows and
downloads that. I don't immediately see how to make the SUMO build do the
right thing, so I guess the solution is to document the SUMO build as
requiring a pre-installed copy of OpenSSL and a compiler and include paths
to build on Windows, or perhaps to document the SUMO build as requiring
that you install pyOpenSSL yourself, or perhaps documenting the SUMO build
as not supported on Windows.
Personally, I would rather kill the entire idea of a SUMO build. It is a
support burden (it complicates the "how to install" process by offering
another option, and the SUMO option may or may not work) and I personally
don't value the feature of installing on a Desert Island enough to
allocate my limited time to it. It certainly doesn't have tests that get
automatically executed on Windows, or we wouldn't have used Kai as a human
buildslave to discover that this problem existed.
I think part of what is going on is that our packaging needs are changing
as Tahoe-LAFS is being integrated into distributions like Ubuntu, Debian,
Fedora, NixOS, and Gentoo. If you are planning to be stranded on a Desert
Island and you want Tahoe-LAFS there, just install one of those operating
systems on your laptop before your trip.
I'm assigning this to Brian since the SUMO build was his idea. Brian:
please reply with either "fine, kill the SUMO build" or "no, don't".
Thanks!
--
Comment:
We've removed the SUMO build entirely, and `docs/desert-island.rst` has
instructions for using pip's wheel cache to perform offline builds. So I'm
closing this one.
--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1009#comment:3>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage
More information about the tahoe-lafs-trac-stream
mailing list