GeezerVison

🤖 New build scheduled with the buildbot fleet by @asvetlov for commit 4ba515d 🤖

If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again.

@asvetlov: Status check is done, and it's a success ✅ .

Sorry, I can't merge this PR. Reason: 2 of 4 required status checks are expected..

I just noticed this. I have a 1-2 hour(s) long meeting with my advisor that is scheduled to start in an hour. After that, I will install Gentoo in a VM to inspect what exactly is happening. Thank you for being patient.

@8vasu take your time.
The bots are green now, the investigation can be as long as needed.
Without this quick-fix I should apply our policy and revert #22962 entirely.

@asvetlov Thank you for being so kind. Also, thank you for preparing this quick-fix. My advisor has postponed the meeting because of thanksgiving preparation. I will look into this matter now.

@ethanfurman @asvetlov I created a Gentoo VM which is currently running emerge; it looks like it might take a lot more time for that to finish. I will let it run. I created a second Gentoo VM, and performed the tests using the live cd.

There are a few things to note. I realized that by default, the live cd does not include a C compiler; their "stage tarballs" include a C compiler. Since I already have one VM currently performing a full installation of Gentoo, I decided to avoid performing those steps again. As an initial phase of the investigation, I ran the tests using the python3.7 that was already available on the live cd.

To be able to run the tests using Python 3.7, I had to comment out the 2 import_module lines. Both of them ran as I had expected them to run: test_openpty() resulted in an OK (expected failures=1); test_master_read() passed. I do not exactly know how the bot was able to make test_openpty() pass.

I will try compiling Python 3.10 after Gentoo is fully installed in the first VM.

Edit: I ran the tests without applying this quick-fix.

FTR, I have serious doubts that this is a Gentoo-specific issue. Note that this bot is run using buildbot's usePTY option so that curses tests will run; see

https://github.com/python/buildmaster-config/blob/db57e24feb7c41c07a84b502838e7b849f251661/master/master.cfg#L143-L148

and

https://github.com/python/buildmaster-config/blob/db57e24feb7c41c07a84b502838e7b849f251661/master/custom/factories.py#L125-L132

In fact, running this test on both of my Gentoo machines (including the one running the buildbot worker in question) in an interactive SSH session, there is a failure with this change:

0:00:00 load avg: 9.92 [1/1] test_pty
test test_pty failed -- Traceback (most recent call last):
  File "/python/cpython/master/Lib/test/test_pty.py", line 201, in test_openpty
    self.assertEqual(_get_term_winsz(slave_fd), new_stdin_winsz,
AssertionError: b'\x00\x00\x00\x00\x00\x00\x00\x00' != b'\r\x006\x00\x00\x00\x00\x00' : openpty() failed to set slave window size

There is no such failure without this change, or when run in a non-interactive SSH session.

@zware I also have doubts about that. Thank you for the help. I can now reinforce your doubts. I just finished installing Gentoo; it took half a day for the process to complete.

Some details:

1. as suggested in the devguide, I compiled Python 3.10 WITHOUT including this quick-fix using ./configure --with-pydebug && make -j
2. I did not install X or Wayland; the commands were invoked on the terminal emulator provided by the kernel (/dev/tty1); $TERM was linux

Everything went as expected when I ran ./python -m test -j3: there was one expected failure, since stdin was a tty. Then, for further inspection,

1. I ran ./python Lib/test/test_pty.py PtyTest.test_openpty to obtain OK (expected failures=1); stdin was a tty in this case
2. I ran ./python Lib/test/test_pty.py PtyTest.test_openpty < /dev/null to obtain OK; stdin was not a tty in this case

Both the above results were as expected. Therefore, I am still not sure how the buildbot was able to make the test pass earlier.

Update: #23526