[tahoe-lafs-trac-stream] [Tahoe-LAFS] #1009: -SUMO package doesn't build on XP

[Tahoe-LAFS]

#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