I would really like to stabilize a bunch of the current rough edges in 2.5. We are likely to have enough instability with the PEP 353 changes, so it would be better to fix some of these issues sooner rather than later. There are a bunch of tests that are not stable. It would really help to get people knowledgeable about a particular subdomain to provide input into bugs/patches and produce patches too! The areas that are known to have problems are listed here: http://wiki.python.org/moin/BuildBot It would be nice to clean those issues up. Does anyone have some time to spend to resolve the issues with Berkeley DB? That's the one that annoys me most right now. I have a patch that fixes at least one of the problems, but no idea if it's the correct solution or not. http://python.org/sf/1407992 n -- PS. In case you are interested in all the problems: * BSD DB 4.1 and 3.2 fail * test_pty is brittle on solaris 10, sometimes it works, sometimes not * getaddrinfo() configure check sometimes fails on OS X 10.3
On Sun, Jan 22, 2006 at 11:01:36PM -0800, Neal Norwitz wrote:
* test_pty is brittle on solaris 10, sometimes it works, sometimes not
Do we have a Solaris 10 box to test on? I think I wrote most of test_pty,
and I can see if I can pin down the problem, but I don't have a Solaris 10
box myself.
--
Thomas Wouters
On Sun, Jan 22, 2006 at 11:01:36PM -0800, Neal Norwitz wrote:
* test_pty is brittle on solaris 10, sometimes it works, sometimes not
FWIW, it's brittle on Solaris 9, too, and the SF compilefarm has two of
those. I don't know if it's the same problem, but on Solaris 9, the slave
part of the tty/pty pair sometimes isn't a TTY (according to os.isatty.) The
buildbot's log doesn't list the solaris 10 test_pty failure though, just the
test_logging failure.
It looks like a timing issue; the first run succeeds, all subsequent runs
fail, for a while, anyway. I'll do some googling and browsing other
tty/pty-using code to see if there's anything we're not doing we should be
doing, but it looks like a platform bug that we can't fix... Not without
re-implementing os.isatty anyway ;P
--
Thomas Wouters
Thomas Wouters wrote:
FWIW, it's brittle on Solaris 9, too, and the SF compilefarm has two of those. I don't know if it's the same problem, but on Solaris 9, the slave part of the tty/pty pair sometimes isn't a TTY (according to os.isatty.) The buildbot's log doesn't list the solaris 10 test_pty failure though, just the test_logging failure.
It occasionally failed in test_pty, too, with the very same error message (that /dev/tty isn't a tty).
It looks like a timing issue; the first run succeeds, all subsequent runs fail, for a while, anyway. I'll do some googling and browsing other tty/pty-using code to see if there's anything we're not doing we should be doing, but it looks like a platform bug that we can't fix... Not without re-implementing os.isatty anyway ;P
Couldn't there be a bug in openpty instead? Perhaps it is trying to allocate the same device again, but fails to do so correctly, and fails to recognize that it should use a different one instead. Anyway, if you still think you need an OS 10 account, please let me know, and I can give you an account to the machine the buildbot runs on. Regards, Martin
On Tue, Jan 24, 2006 at 11:52:52PM +0100, "Martin v. Löwis" wrote:
It looks like a timing issue; the first run succeeds, all subsequent runs fail, for a while, anyway. I'll do some googling and browsing other tty/pty-using code to see if there's anything we're not doing we should be doing, but it looks like a platform bug that we can't fix... Not without re-implementing os.isatty anyway ;P
Couldn't there be a bug in openpty instead? Perhaps it is trying to allocate the same device again, but fails to do so correctly, and fails to recognize that it should use a different one instead.
Well, a bug in openpty is what I started with. Python's posix.openpty() that is, as Solaris doesn't have openpty. Openpty is emulated using code taken almost verbatim from Solaris' pts(7D) manpage: fdm = open("/dev/ptmx", O_RDWR); /* open master */ grantpt(fdm); /* change permission of slave */ unlockpt(fdm); /* unlock slave */ slavename = ptsname(fdm); /* get name of slave */ fds = open(slavename, O_RDWR); /* open slave */ ioctl(fds, I_PUSH, "ptem"); /* push ptem */ ioctl(fds, I_PUSH, "ldterm"); /* push ldterm*/ (That's the manpage code.) This is also what openssh does (as far as I can tell). Screen does it slightly differently; it does the ptsname() call before the grantpt/unlockpt calls, but the open(slavename) after. If I make posixmodule do that, it still fails on Solaris. Mucking with it more just breaks it more. The thing is, disabling the check that fails, whether the slave-tty returned by os.openpty() is a tty, shows that the later test for the same thing succeeds. The later test is done in a child created by pty.fork(). Disabling the ptmx code on Solaris is probably the most reliable way to fix the failing test; the pty module will fall back to old-style BSD pty code and that works fine. But it's a bit of a shame not to use /dev/ptmx just because the slave fd, when used directly (rather than in a child process) sometimes doesn't seem to be a tty. They're still connected, it still seems to work fine.
Anyway, if you still think you need an OS 10 account, please let me know, and I can give you an account to the machine the buildbot runs on.
I think I've seen enough confusing situations for a while... I'm sure the
bug is the same on Solaris 10 ;P
--
Thomas Wouters
On Wed, Jan 25, 2006 at 01:59:18AM +0100, Thomas Wouters wrote:
[ iffy isatty behaviour on Solaris ]
Considering that:
- the approach for opening pty's, while not the only one, is the preferred
way of doing it on Solaris,
- the actual pty's seem to be completely functional,
- the usual way to use pty's is not like the test does (inside a single
process), and I'd say using pty's like the test does is extremely
unlikely to happen in real life,
- testing inside the tty-creating process is quite possibly the reason for
the fickleness of the test, since its behaviour isn't guaranteed
anywhere,
- the test inside a subprocess, the normal way of using pty's, is not
failing (as far as I can tell),
I'd like to check in the attached patch. It doesn't fix anything, it just
removes this one test failure on Solaris. I don't want to skip the entire
test, because it still tests whether everything else works as expected, and
I don't want spurious failures as they can mask a real failure later in the
test.
I'd need developer access back to check it in, though. Unless anyone
objects, of course :)
--
Thomas Wouters
[Thomas Wouters]
... I'd need developer access back to check it in, though.
AFAICT, twouters has developer access to the Python project -- although maybe someone else re-enabled that w/o mentioning it here.
Unless anyone objects, of course :)
Of course I object! I bow to the group will, though.
On Thu, Jan 26, 2006 at 09:41:53PM -0500, Tim Peters wrote:
[Thomas Wouters]
... I'd need developer access back to check it in, though.
AFAICT, twouters has developer access to the Python project -- although maybe someone else re-enabled that w/o mentioning it here.
I meant svn-checkin-access (it got disabled for disuse a while back.) If I
weren't schizofrenic in sysadmin jobs I could add it myself, but I can't do
that. Can I? I guess I can't. Who am I again?
Someone-else'ly y'rs,
--
Thomas Wouters
[Thomas]
I'd need developer access back to check it in, though.
[Tim]
AFAICT, twouters has developer access to the Python project -- although maybe someone else re-enabled that w/o mentioning it here.
[Thomas]
I meant svn-checkin-access (it got disabled for disuse a while back.)
I know. AFAICT, you (twouters) already have it. There's a "Yes" in the twouters row under the "CVS Access" column on the Python project's Members admin page. Have you tried checking in? What happens when you do? If it "doesn't work", one possibility is that you did a read-only SVN _checkout_, and it's actually SVN griping at you.
If I weren't schizofrenic in sysadmin jobs I could add it myself, but I can't do that. Can I? I guess I can't.
You shouldn't be able to add yourself -- you're not listed as a godly Python project admin, just as a mortal Python developer. Many people who do checkins routinely (like Neal Norwitz) are in the same boat wrt that.
Who am I again?
Thomas Wouters ;-) Your SourceForge name in the Python project is twouters.
I suppose another possibility for why twouters couldn't check in is because someone added him to the project's cvs_acls script. If so, I don't know anything about how to get that changed.
[Tim] ...
AFAICT, you (twouters) already have it. There's a "Yes" in the twouters row under the "CVS Access" column on the Python project's Members admin page. Have you tried checking in? What happens when you do? ...
LOL -- what a bubblehead I am! Whether you can check in has nothing to do with SourceForge CVS access anymore -- never mind, and sorry. I don't have the power to admin svn.python.org either. Martin?
Thomas Wouters wrote:
I'd need developer access back to check it in, though. Unless anyone objects, of course :)
I copied ~/thomas/authorized_keys to ~pythondev/keys/thomas.wouters, changed ownership/permissions, and ran make_authorized_keys in the pythondev account. So you should have access now. Regards, Martin
On Sun, Jan 22, 2006 at 11:01:36PM -0800, Neal Norwitz wrote:
rather than later. There are a bunch of tests that are not stable. It would really help to get people knowledgeable about a particular subdomain to provide input into bugs/patches and produce patches too!
The areas that are known to have problems are listed here: http://wiki.python.org/moin/BuildBot
It would be nice to clean those issues up. Does anyone have some time to spend to resolve the issues with Berkeley DB? That's the one that annoys me most right now. I have a patch that fixes at least one of the problems, but no idea if it's the correct solution or not. http://python.org/sf/1407992
Nice! It does fix the associate test problem on BerkeleyDB 3.3-4.1 and 4.2-4.4 continue to pass. I committed it. Good to have tests passing again when using "old" but still common BerkeleyDBs.
* BSD DB 4.1 and 3.2 fail
Using BerkeleyDB 3.2 often segfaults for me; using 3.3 often hangs in the test suite. Both are so old I don't see much motivation to track the issues down.
"Gregory P. Smith"
Using BerkeleyDB 3.2 often segfaults for me; using 3.3 often hangs in the test suite. Both are so old I don't see much motivation to track the issues down.
My goal is to not have http://www.python.org/dev/buildbot/ go red randomly because of erratic bsddb tests, so I'd definitely prefer it if we didn't build bsddb3 when a not-supported bsddb is found. Things seem much better today after your recent changes though, so thanks for that :) Cheers, mwh -- at any rate, I'm satisfied that not only do they know which end of the pointy thing to hold, but where to poke it for maximum effect. -- Eric The Read, asr, on google.com
participants (6)
-
"Martin v. Löwis" -
Gregory P. Smith -
Michael Hudson -
Neal Norwitz -
Thomas Wouters -
Tim Peters