[Python-3000] Solaris support in 3.0?

[Nicholas Bastin]

On 9/5/07, Guido van Rossum <guido at python.org> wrote:
> On 9/5/07, "Martin v. Löwis" <martin at v.loewis.de> wrote:
> > > This is a combination question-and-status-report email.  The question
> > > would be, what does the "somewhat" tag mean on Solaris support in the
> > > release notes for 3.0a1, and does someone have a list of things that
> > > don't work, or does that just mean it hasn't been tested?
> >
> > Not sure what "somewhat" means, but you can take a look at the build
> > failures in the Solaris buildbot - this is what is "officially" known
> > not to work.
>
> The "somewhat" was my word -- I meant that when I last looked at the
> Solaris buildbot, I saw a few failures; and also that I don't have
> access to Sun hardware. And also what Martin says below. I'd be happy
> though to replace "somewhat" with specific indications of h/w and s/w
> versions if you are willing to commit to supporting these throughout
> the 3.0 life cycle.

I have access to Solaris 8 and 9 on Sparc, and Solaris 10 on x86.  My
Solaris 10 x86 installation is currently in a VM, and it's unpleasant
to work with (performance is terrible for some reason), but I can at
least make a passing attempt to build and run unit tests in that
environment.  I have to have Python on Sparc for my application, so
I'm going to continue to work on Python 3.0 on Solaris 8/9 for Sparc
throughout the entire cycle to make sure that we have a usable product
there.

> > As always with Solaris, there are several dimensions to be considered:
> > - version (2.5,2.6,7,8,9,10,11); not sure what the oldest Solaris
> >   version is that we still want to support.
> > - compiler: gcc vs. SunPRO/Forte
> > - 32 vs. 64 bits
> > - SPARC vs. x86

I will at least build and test the following configurations.  I will
also attempt to fix any platform specific bugs, but I suspect the
Unicode failures are going to create some interesting discussions
around here.  :-)

Solaris 8, 32-bit, 64-bit, Sparc, gcc and SunPro 11
Solaris 9, 32-bit, 64-bit, Sparc, gcc and SunPro 11

I will try to get to:

Solaris 10, 32-bit, x86, gcc

Because there's no reason not to since I have an x86 machine and VMWare.  :-)

> > > If anyone wants more data on any of these particular failures, let me
> > > know, otherwise I'm going to start working through the ones that fail
> > > in 3.0 that don't fail in 2.6.  All of the _md5 failures are because
> > > of the lack of SSL, so I'm not sure that the tests should be 'failing'
> > > in this configuration.
> >
> > I think that's a serious issue to consider. As so much code now depends
> > on OpenSSL, setup.py should try harder to find it. E.g. on the build
> > slave, it can be found in /usr/sfw - not sure whether that is normal
> > on a Solaris 10 installation, and not sure whether there is a
> > Sun-provided OpenSSL on Solaris 8.
> >
> > Notice that the tests don't 'fail', they are skipped. There are also
> > failing test cases, something that is more worrisome than a skipped
> > test case.
>
> Yes, this is a serious issue -- we are totally dependent on openssl
> for computing MD5 checksums. Several modules use MD5 checksums
> casually, and it's not good that these fail when openssl isn't
> available (or if it's too old, like what happened on an ancient Red
> Hat 7.3 system I have at home). I'm tempted to put the old
> RSA-copyrighted md5.c back in as a fallback, even though its license
> is impopular. Or perhaps we could make a copy of a small fraction of
> openssl and use that? I think MD5 is the only one that's popular
> enough to warrant this treatment; I think SHA1 is a distant second.

MD5 is defined in RFC 1321, there's no reason to have to use any
particular code with a bad license - there's plenty of LGPL MD5
implementations out there (although you could probably argue that if
they'd ever looked at 1321, which they almost certainly did, then
they've been tainted by the RSA code).

Also, the NIST SHA-1/256/384/512 code is freely available, there's
also no reason to rely on OpenSSL for it (although it looks like the
PKI reference implementation links that I can find are dead, so we
might have to hunt a little bit).

In either case, we could probably copy the relevant pieces out of OpenSSL.

--
Nick