[issue12669] test_curses skipped on buildbots

[Nadeem Vawda]

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()

     def test_main():
    -    if not sys.__stdout__.isatty():
    -        raise unittest.SkipTest("sys.__stdout__ is not a tty")
         # testing setupterm() inside initscr/endwin
         # causes terminal breakage
    -    curses.setupterm(fd=sys.__stdout__.fileno())
    +    #curses.setupterm(fd=sys.__stdout__.fileno())
    +    import pty
    +    _, pty = pty.openpty()
    +    curses.setupterm(fd=pty)
         try:
             stdscr = curses.initscr()
             main(stdscr)

(I've never used openpty, either in Python or in C, so I can't vouch for
the correctness of this usage.)


> 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 a tty at all. Using pty.openpty it would be possible to ensure that there is a pty that can be used for the test.

Looking at the actual buildbot results, most of the *nix bots I checked
are actually skipping this test; the only one I could find that wasn't is
the "x86 Ubuntu Shared" bot:
ttp://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/6640/steps/test/logs/stdio

So it looks like on most of the bots, buildbot is running without a tty.
Then, test_main() sees that sys.__stdout__ isn't suitable to run the
test, and bails out.

It'd be great if you can come up with a fix that gets the test running
in this environment, but it'll probably be more complicated than just
slotting in a call to openpty().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12669>
_______________________________________