[issue12669] test_curses skipped on buildbots

Change by Serhiy Storchaka : -- resolution: -> out of date stage: needs patch -> resolved status: open -> closed ___ Python tracker ___

[issue12669] test_curses skipped on buildbots

Serhiy Storchaka added the comment: It was fixed in other way in issue42789. If __stdout__ is not a terminal, the code falls back to __stderr__, and it is not terminal either, it tries to open /dev/tty. If neither works, it uses a regular temporary file as terminal, but savetty()/resetty()

[issue12669] test_curses skipped on buildbots

Martin Panter added the comment: FYI I just added a reasonably generic function pty_run(script, input) -> output to Lib/test/test_readline.py:120 for Issue 26870. It runs a Python script string in a child process under a pseudo-terminal. If you need to drive the curses tests with a

[issue12669] test_curses skipped on buildbots

Changes by Mark Lawrence breamore...@yahoo.co.uk: -- versions: +Python 3.5 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12669 ___ ___

[issue12669] test_curses skipped on buildbots

Changes by Ronald Oussoren ronaldousso...@mac.com: -- versions: +Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12669 ___ ___

[issue12669] test_curses skipped on buildbots

Ronald Oussoren added the comment: As noted in Issue15664 this issue also affects make test. -- nosy: +ronaldoussoren ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12669 ___

[issue12669] test_curses skipped on buildbots

Ronald Oussoren added the comment: Nadeem: is the failure you show in msg141798 with a version of test_curses that uses pty.openpty? If it isn't: I'd expect more test failures on buildbot machines where the buildbot agent is started as a system daemon, in which case the process doesn't have

[issue12669] test_curses skipped on buildbots

Ronald Oussoren added the comment: BTW. the documentation for curses.setupterm says: curses.setupterm([termstr, fd]) The first argument is actually named term in the C code. -- ___ Python tracker rep...@bugs.python.org

[issue12669] test_curses skipped on buildbots

Nadeem Vawda added the comment: Nadeem: is the failure you show in msg141798 with a version of test_curses that uses pty.openpty? Yes, I tried the following change: --- a/Lib/test/test_curses.py +++ b/Lib/test/test_curses.py @@ -328,11 +328,12 @@ curses.resetty()

[issue12669] test_curses skipped on buildbots

Changes by Nadeem Vawda nadeem.va...@gmail.com: -- stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12669 ___ ___

[issue12669] test_curses skipped on buildbots

Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 4358909ee221 by Nadeem Vawda in branch 'default': Issue #12669: Fix test_curses so that it can run on the buildbots. http://hg.python.org/cpython/rev/4358909ee221 -- nosy: +python-dev

[issue12669] test_curses skipped on buildbots

STINNER Victor victor.stin...@haypocalc.com added the comment: Correction: the offending options are -j and *-W* I changed regrtest -W recently to only run the tests once using StringIO as stdout. So it's a regression in Python 3.3. Can't we create a dummy/temporary TTY for the curses tests

[issue12669] test_curses skipped on buildbots

Nadeem Vawda nadeem.va...@gmail.com added the comment: Can't we create a dummy/temporary TTY for the curses tests using pty.openpty()? I would have thought so, but it seems that savetty() and endwin() both fail when running under '-j0': test test_curses crashed -- Traceback (most recent

[issue12669] test_curses skipped on buildbots

New submission from Nadeem Vawda nadeem.va...@gmail.com: When running regrtest with the -j and/or -w options, test_curses gets skipped, complaining that stdout is not a tty. This means that the buildbots never run this test, which is obviously a Bad Thing. For the -w case (which applies to the

[issue12669] test_curses skipped on buildbots

Nadeem Vawda nadeem.va...@gmail.com added the comment: Correction: the offending options are -j and *-W* (display test output on failure), not -w (re-run failed tests in verbose mode). -- ___ Python tracker rep...@bugs.python.org