When launching lib/portage/tests/ebuild/test_doebuild_fd_pipes.py via this script that runs pytest with the multiprocessing spawn start method, it fails and I'm not sure why: > import multiprocessing > import sys > import pytest > if __name__ == "__main__": > multiprocessing.set_start_method("spawn", force=True) > sys.exit(pytest.console_main()) > lib/portage/tests/ebuild/test_doebuild_fd_pipes.py Exception in callback PipeLogger._io_loop_done(<Task finishe...id argument')>) > handle: <Handle PipeLogger._io_loop_done(<Task finishe...id argument')>)> > Traceback (most recent call last): > File "/usr/lib/python3.12/asyncio/events.py", line 84, in _run > self._context.run(self._callback, *self._args) > File "portage/lib/portage/util/_async/PipeLogger.py", line 162, in _io_loop_done > future.result() > File "portage/lib/portage/util/_async/PipeLogger.py", line 119, in _io_loop > stdout_buf = stdout_buf[os.write(stdout_fd, stdout_buf) :] > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > OSError: [Errno 22] Invalid argument
DoebuildFdPipesTestCase attempts to pass a file descriptor (output_fd = 200) down to an ebuild process descended from ForkProcess, which only works with the multiprocessing fork start method. I realized this after I added some debug messages to AbstractEbuildProcess and noticed this odd fd_pipes value where output_fd and stdin both refer to file descriptor 10: {1: 5, 2: 5, 200: 10, 0: 10}
If I remove the top-level fd_pipes then the test case basically works, until it fails like this: > Exception in callback _PostPhaseCommands._commands_exit.<locals>.<lambda>(<Task finishe...mp0cht39td/')>) at portage/lib/_emerge/EbuildPhase.py:592 > handle: <Handle _PostPhaseCommands._commands_exit.<locals>.<lambda>(<Task finishe...mp0cht39td/')>) at portage/lib/_emerge/EbuildPhase.py:592> > Traceback (most recent call last): > File "/usr/lib/python3.12/asyncio/events.py", line 84, in _run > self._context.run(self._callback, *self._args) > File "portage/lib/_emerge/EbuildPhase.py", line 592, in <lambda> > lambda future: future.cancelled() or future.result() > ^^^^^^^^^^^^^^^ > File "portage/lib/_emerge/EbuildPhase.py", line 603, in _soname_deps_qa > vardb = QueryCommand.get_db()[self.settings["EROOT"]]["vartree"].dbapi > ~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^ > KeyError: '/tmp/tmp0cht39td/' > !!! post install failed; exiting.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=6a7297abca88c5d86ac299e51a52547baac791f1 commit 6a7297abca88c5d86ac299e51a52547baac791f1 Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2023-10-30 04:43:42 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2023-10-30 04:47:55 +0000 test_doebuild_fd_pipes.py: multiprocessing spawn compat Use multiprocessing.Pipe for compatibility with the spawn start method. Also pass QueryCommand._db to the child process, like MergeProcess does. Bug: https://bugs.gentoo.org/916247 Signed-off-by: Zac Medico <zmedico@gentoo.org> lib/portage/tests/ebuild/test_doebuild_fd_pipes.py | 30 ++++++++++++++-------- 1 file changed, 20 insertions(+), 10 deletions(-)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0baf5e0bd0879f55a87111ced2140262dbec689b commit 0baf5e0bd0879f55a87111ced2140262dbec689b Author: Sam James <sam@gentoo.org> AuthorDate: 2023-11-06 21:41:33 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-11-06 21:41:33 +0000 sys-apps/portage: add 3.0.55 Closes: https://bugs.gentoo.org/916256 Closes: https://bugs.gentoo.org/915842 Closes: https://bugs.gentoo.org/916247 Closes: https://bugs.gentoo.org/916336 Closes: https://bugs.gentoo.org/916601 Closes: https://bugs.gentoo.org/916614 Signed-off-by: Sam James <sam@gentoo.org> sys-apps/portage/Manifest | 1 + sys-apps/portage/portage-3.0.55.ebuild | 238 +++++++++++++++++++++++++++++++++ 2 files changed, 239 insertions(+)
