Has anyone had a chance to test that 2.1.2 builds and works correctly on anything? I'm testing on the following systems. sourceforge compile farm boxes are marked as such, compaq testdrive boxes to arrive as well[1].
For each, a fresh cvs export, followed by ./configure ; make ; make test.
Are there additional useful tests that could be run?
Linux/x86 Redhat 6.2 PASSED Linux/x86 Redhat 7.1 PASSED Linux/x86 Redhat 7.2 PASSED Solaris/sparc 2.7 (gcc-2.95.2) PASSED Linux/x86 Debian 2.2 (cf.sf.net) PASSED Linux/PPC [RS/6000] Debian 2.2 (cf.sf.net) PASSED Linux/alpha Debian 2.2 (cf.sf.net) PASSED FreeBSD 4.4 (cf.sf.net) PASSED Solaris/sparc 2.8 (cf.sf.net) (gcc-2.95.2) PASSED Tru64/Alpha 4.0 (compaq) ... still building ... Tru64/Alpha 5.1 (compaq) ... to be done ...
Linux/sparc Debian 2.2 (cf.sf.net) FAILED This is scary. I don't know why this one alone fails - it fails the test_math test.
Running the test by hand: anthonybaxter@usf-cf-sparc-linux-1:~/python212_linxsparc$ PYTHONPATH= ./python ./Lib/test/test_math.py math module, testing with eps 1e-05 constants acos Traceback (most recent call last): File "./Lib/test/test_math.py", line 21, in ? testit('acos(-1)', math.acos(-1), math.pi) OverflowError: math range error
Running math.acos(-1) gives the correct answer. Anyone got any idea?
I couldn't get py212 to build on our remaining solaris/x86 box, but then I can't get 2.1.1 to build on it either, without a whole lot of manual hackery - so I don't care about that. It's just a stuffed machine. :)
I was hoping to test on MacOS X, but the cf.sf.net boxes aren't answering... anyone else want to give it a go?
Anthony
[1] sheesh. had to install telnet for the compaq boxes. first time I've not had ssh access somewhere for a while. . . (plus, they don't have cvs. sigh.)
Anthony> Has anyone had a chance to test that 2.1.2 builds and works Anthony> correctly on anything?
I will give it a quick try on my Mandrake 8.1 system. What's the relevant CVS branch? I didn't see anything obvious like "r212".
Skip
I tried it on IRIX 6.5.13m (SGI) using gcc, and I saw two problems in the test set. One was in test_locale and can be written off as a bug in the IRIX environment. The other was in test_pty for which there is a fix. Just get the latest version of test_pty (the bug is in the test).
One more problem I saw was that test_sundry was skipped with the message that there was an unresolvable symbol in bsddb.so by the name of dbopen. I don't quite understand why this is.
Anthony Baxter wrote:
Has anyone had a chance to test that 2.1.2 builds and works correctly on anything? I'm testing on the following systems. sourceforge compile farm boxes are marked as such, compaq testdrive boxes to arrive as well[1].
For each, a fresh cvs export, followed by ./configure ; make ; make test.
Are there additional useful tests that could be run?
Linux/x86 Redhat 6.2 PASSED Linux/x86 Redhat 7.1 PASSED Linux/x86 Redhat 7.2 PASSED Solaris/sparc 2.7 (gcc-2.95.2) PASSED Linux/x86 Debian 2.2 (cf.sf.net) PASSED Linux/PPC [RS/6000] Debian 2.2 (cf.sf.net) PASSED Linux/alpha Debian 2.2 (cf.sf.net) PASSED FreeBSD 4.4 (cf.sf.net) PASSED Solaris/sparc 2.8 (cf.sf.net) (gcc-2.95.2) PASSED Tru64/Alpha 4.0 (compaq) ... still building ... Tru64/Alpha 5.1 (compaq) ... to be done ...
Linux/sparc Debian 2.2 (cf.sf.net) FAILED This is scary. I don't know why this one alone fails - it fails the test_math test.
Running the test by hand: anthonybaxter@usf-cf-sparc-linux-1:~/python212_linxsparc$ PYTHONPATH= ./python ./Lib/test/test_math.py math module, testing with eps 1e-05 constants acos Traceback (most recent call last): File "./Lib/test/test_math.py", line 21, in ? testit('acos(-1)', math.acos(-1), math.pi) OverflowError: math range error
Running math.acos(-1) gives the correct answer. Anyone got any idea?
I couldn't get py212 to build on our remaining solaris/x86 box, but then I can't get 2.1.1 to build on it either, without a whole lot of manual hackery - so I don't care about that. It's just a stuffed machine. :)
I was hoping to test on MacOS X, but the cf.sf.net boxes aren't answering... anyone else want to give it a go?
Anthony
[1] sheesh. had to install telnet for the compaq boxes. first time I've not had ssh access somewhere for a while. . . (plus, they don't have cvs. sigh.)
Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev
"SM" == Sjoerd Mullender sjoerd@acm.org writes:
SM> One more problem I saw was that test_sundry was skipped with SM> the message that there was an unresolvable symbol in bsddb.so SM> by the name of dbopen. I don't quite understand why this is.
Hmm, if this was 2.2.1 I'd say it's the known brokenness of setup.py w.r.t. bsddbmodule on some systems. I think the setup.py is okay in 2.1.x but I'm doing a build on Mandrake 8.1 now...
-Barry
One more problem I saw was that test_sundry was skipped with the message that there was an unresolvable symbol in bsddb.so by the name of dbopen. I don't quite understand why this is.
test_sundry shouldn't import dbhash.
--Guido van Rossum (home page: http://www.python.org/~guido/)
All the tests pass on Mandrake 8.1, including LFS with the CC='...' configure instruction.
-Barry
[Anthony Baxter]
... Linux/sparc Debian 2.2 (cf.sf.net) FAILED This is scary. I don't know why this one alone fails - it fails the test_math test.
Running the test by hand: anthonybaxter@usf-cf-sparc-linux-1:~/python212_linxsparc$ PYTHONPATH= ./python ./Lib/test/test_math.py math module, testing with eps 1e-05 constants acos Traceback (most recent call last): File "./Lib/test/test_math.py", line 21, in ? testit('acos(-1)', math.acos(-1), math.pi) OverflowError: math range error
Running math.acos(-1) gives the correct answer. Anyone got any idea?
Sorry, not short of stepping into mathmodule.c under a debugger. The only interesting thing about that test is that math.acos(-1) is the very first call test_math.py makes to the platform libm. Perhaps if you commented it out, you'd get a bogus OverflowError from
testit('acos(0)', math.acos(0), math.pi/2)
on the following line.
Linux/sparc Debian 2.2 (cf.sf.net) FAILED This is scary. I don't know why this one alone fails - it fails the test_math test.
[...]
Sorry, not short of stepping into mathmodule.c under a debugger. The only interesting thing about that test is that math.acos(-1) is the very first call test_math.py makes to the platform libm. Perhaps if you commented it out, you'd get a bogus OverflowError from
testit('acos(0)', math.acos(0), math.pi/2)on the following line.
Seems to be a Sparclinux bug. If mathmodule is statically linked into python (via Modules/Setup), the test passes fine. Without further analysis, I'd say that assigning to errno does not work well when done in a shared library.
I'd say this is bug #459464. Last time, I incorrectly diagnosed this as a sparc64 gcc issue, which it isn't: Even though 'uname -m' reports 'sparc64', all userland code is 32-bit. I'm probably wrong with my current guess as well.
HTH, Martin
-
Anthony Baxter -
barry＠zope.com -
Guido van Rossum -
Martin v. Loewis -
Sjoerd Mullender -
Skip Montanaro -
Tim Peters