[Python-3000] Solaris support in 3.0? (original) (raw)

Guido van Rossum guido at python.org
Wed Sep 5 17:02:14 CEST 2007

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.

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

(not all combinations exist, but plenty) > 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.

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-3000 mailing list