I first ran `emerge -a -uvDU @world` and it started running, but died with: ``` >>> Installing (5 of 34) app-portage/gentoolkit-0.5.0-r2::gentoo_prefix * checking 374 files for package collisions >>> Merging app-portage/gentoolkit-0.5.0-r2 to / /Users/sam/Gentoo/usr/lib/python-exec/python3.7/portageq: this Python implementation (python3.7) is not supported by the script. * ERROR: app-portage/gentoolkit-0.5.0-r2::gentoo_prefix failed (preinst phase): * has_version: unexpected portageq exit code: 127 * * Call stack: * ebuild.sh, line 125: Called __call-ebuildshell 'pkg_preinst' * ebuild.sh, line 526: Called pkg_preinst * environment, line 2436: Called has_version '<app-portage/gentoolkit-0.4.0' * phase-helpers.sh, line 940: Called ___best_version_and_has_version_common '<app-portage/gentoolkit-0.4.0' * phase-helpers.sh, line 927: Called die * The specific snippet of code: * die "${FUNCNAME[1]}: unexpected portageq exit code: ${retval}" * * If you need support, post the output of `emerge --info '=app-portage/gentoolkit-0.5.0-r2::gentoo_prefix'`, * the complete build log and the output of `emerge -pqv '=app-portage/gentoolkit-0.5.0-r2::gentoo_prefix'`. * The complete build log is located at '/Users/sam/Gentoo/var/tmp/portage/app-portage/gentoolkit-0.5.0-r2/temp/build.log'. * The ebuild environment file is located at '/Users/sam/Gentoo/var/tmp/portage/app-portage/gentoolkit-0.5.0-r2/temp/environment'. * Working directory: '/Users/sam/Gentoo/var/tmp/portage/app-portage/gentoolkit-0.5.0-r2/homedir' * S: '/Users/sam/Gentoo/var/tmp/portage/app-portage/gentoolkit-0.5.0-r2/work/gentoolkit-0.5.0' !!! FAILED preinst: 1 ``` I'm not sure if this is a merge order problem or not. Then, re-running the same command: ``` Traceback (most recent call last): File "/Users/sam/Gentoo/usr/lib/python-exec/python3.8/emerge", line 51, in <module> retval = emerge_main() File "/Users/sam/Gentoo/usr/lib/python3.8/site-packages/_emerge/main.py", line 1317, in emerge_main return run_action(emerge_config) File "/Users/sam/Gentoo/usr/lib/python3.8/site-packages/_emerge/actions.py", line 3245, in run_action emergelog(xterm_titles, "Started emerge on: %s" % time_str) File "/Users/sam/Gentoo/usr/lib/python3.8/site-packages/_emerge/emergelog.py", line 46, in emergelog mylock = portage.locks.lockfile(file_path) File "/Users/sam/Gentoo/usr/lib/python3.8/site-packages/portage/locks.py", line 131, in lockfile lock = _lockfile_iteration(mypath, wantnewlockfile=wantnewlockfile, File "/Users/sam/Gentoo/usr/lib/python3.8/site-packages/portage/locks.py", line 237, in _lockfile_iteration locking_method = portage._eintr_func_wrapper(_get_lock_fn()) File "/Users/sam/Gentoo/usr/lib/python3.8/site-packages/portage/locks.py", line 69, in _get_lock_fn proc.start() File "/Users/sam/Gentoo/usr/lib/python3.8/multiprocessing/process.py", line 121, in start self._popen = self._Popen(self) File "/Users/sam/Gentoo/usr/lib/python3.8/multiprocessing/context.py", line 224, in _Popen return _default_context.get_context().Process._Popen(process_obj) File "/Users/sam/Gentoo/usr/lib/python3.8/multiprocessing/context.py", line 284, in _Popen return Popen(process_obj) File "/Users/sam/Gentoo/usr/lib/python3.8/multiprocessing/popen_spawn_posix.py", line 32, in __init__ super().__init__(process_obj) File "/Users/sam/Gentoo/usr/lib/python3.8/multiprocessing/popen_fork.py", line 19, in __init__ self._launch(process_obj) File "/Users/sam/Gentoo/usr/lib/python3.8/multiprocessing/popen_spawn_posix.py", line 47, in _launch reduction.dump(process_obj, fp) File "/Users/sam/Gentoo/usr/lib/python3.8/multiprocessing/reduction.py", line 60, in dump ForkingPickler(file, protocol).dump(obj) AttributeError: Can't pickle local object '_get_lock_fn.<locals>._test_lock' ```
Created attachment 676408 [details] Output from `emerge -a -uvDU @world`
Created attachment 676411 [details] emerge --info
Recently (yesterday?) the default Python version was bumped from 3.7 to 3.8. It seems that you have 3.7 code and 3.8 running in a mix. what is eselect python show/list returning for you?
(In reply to Fabian Groffen from comment #3) > Recently (yesterday?) the default Python version was bumped from 3.7 to 3.8. > > It seems that you have 3.7 code and 3.8 running in a mix. > > what is eselect python show/list returning for you? $ eselect python list Available Python interpreters, in order of preference: [1] python3.7 [2] python3.8 (fallback) Swapping them around / invoking emerge with EPYTHON=python3.7 nor 3.8 didn't help as it's already been replaced with a 3.8 version.
I wonder if I should have upgraded Portage first. I guess I'll need to bootstrap it to get a working one again. Not sure if I want to risk a binpkg.
have you tried setting 3.8 as standard?
qlist -IUv sys-apps/portage what are your python_targets_python*?
(In reply to Fabian Groffen from comment #6) > have you tried setting 3.8 as standard? Yeah, no difference. During the upgrade, 3.8-only Portage replaced the 3.7 one. Didn't keep both enabled because I didn't think. (In reply to Fabian Groffen from comment #7) > qlist -IUv sys-apps/portage > what are your python_targets_python*? $ qlist -IUv sys-apps/portage sys-apps/portage-3.0.10.2 -apidoc -build -doc -gentoo-dev -ipc native-extensions -python_targets_pypy3 -python_targets_python3_6 -python_targets_python3_7 python_targets_python3_8 -python_targets_python3_9 -rsync-verify -selinux -xattr I haven't deviated from the defaults so python3_8 is what I'd expect it to be, as it is.
I hit this with a DARWIN_USE_GCC=1 prefix during emerge -e system. It installed python 3.8 and then when there was an error with portageq saying it didn't support 3.7, the emerge failed. Then I was unable to resume or restart because of this issue. I just modified my copy of bootstrap-prefix.sh to bootstrap with python-3.8.5. Maybe we should do that in the main prefix repo. If logs would help, I can upload them, as I haven't deleted my gcc-based prefix. I can retry gcc another day. (Right now, I'm now retrying my clang based bootstrap with features=KEEPWORK to try and figure things out.)
I just hit the same issue in stage2 when bootstrapping with python 3.8.5. Stage1 succeeded without issue, and then: Performing Global Updates (Could take a couple of minutes if you have a lot of binary packages.) .='update pass' *='binary update' #='/var/db update' @='/var/db move' s='/var/db SLOT move' %='binary move' S='binary SLOT move' p='update /etc/portage/package.*' /Users/jafloyd/Gentoo/var/db/repos/gentoo/profiles/updates/3Q-2015..................... [snip] /Users/jafloyd/Gentoo/var/db/repos/gentoo/profiles/updates/4Q-2020....... Traceback (most recent call last): File "/Users/jafloyd/Gentoo/tmp/usr/bin/emerge", line 51, in <module> retval = emerge_main() File "/Users/jafloyd/Gentoo/tmp/usr/lib/python3.8/_emerge/main.py", line 1317, in emerge_main return run_action(emerge_config) File "/Users/jafloyd/Gentoo/tmp/usr/lib/python3.8/_emerge/actions.py", line 3245, in run_action emergelog(xterm_titles, "Started emerge on: %s" % time_str) File "/Users/jafloyd/Gentoo/tmp/usr/lib/python3.8/_emerge/emergelog.py", line 46, in emergelog mylock = portage.locks.lockfile(file_path) File "/Users/jafloyd/Gentoo/tmp/usr/lib/python3.8/portage/locks.py", line 131, in lockfile lock = _lockfile_iteration(mypath, wantnewlockfile=wantnewlockfile, [snip] File "/Users/jafloyd/Gentoo/tmp/usr/lib/python3.8/multiprocessing/reduction.py", line 60, in dump ForkingPickler(file, protocol).dump(obj) AttributeError: Can't pickle local object '_get_lock_fn.<locals>._test_lock'
The issue is triggered by this change in Python 3.8: On macOS, the spawn start method is now the default. In order to support this, portage will have to ensure that all arguments to multiprocess.Process can be pickled. On Linux, I'm able to reproduce the problems if I patch portage programs like this: > From f093da4a3a457d539e5682ccecdf91f254addd8c Mon Sep 17 00:00:00 2001 > From: Zac Medico <zmedico@gentoo.org> > Date: Thu, 3 Dec 2020 21:37:39 -0800 > Subject: [PATCH] runTests.py: multiprocessing.set_start_method('spawn') for > debugging bug 758230 > > Bug: https://bugs.gentoo.org/758230 > Signed-off-by: Zac Medico <zmedico@gentoo.org> > --- > lib/portage/tests/runTests.py | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/lib/portage/tests/runTests.py b/lib/portage/tests/runTests.py > index 9514abebe..6e33077ae 100755 > --- a/lib/portage/tests/runTests.py > +++ b/lib/portage/tests/runTests.py > @@ -4,6 +4,7 @@ > # Distributed under the terms of the GNU General Public License v2 > > import grp > +import multiprocessing > import os > import os.path as osp > import platform > @@ -60,6 +61,7 @@ if insert_bin_path: > os.environ["PATH"] = ":".join(path) > > if __name__ == "__main__": > + multiprocessing.set_start_method('spawn') > try: > sys.exit(tests.main()) > finally: > -- > 2.26.2 >
ok, so what happened: - PYTHON_TARGETS was changed from python3_7 to python3_8 (only) - Python 3.8 has fork method set to 'spawn', instead of 'fork' in 3.7 - current Portage doesn't work with 'spawn' so it seems what we can do: 1. apply patch to Portage as Zac did in comment #c11 but instead of using spawn, to force 'fork' 2. patch Python 3.8's default to be 'fork' again on macOS 3. revert PYTHON_TARGETS back to 3.7 until we sorted this out
(In reply to Fabian Groffen from comment #12) > ok, so what happened: > - PYTHON_TARGETS was changed from python3_7 to python3_8 (only) > - Python 3.8 has fork method set to 'spawn', instead of 'fork' in 3.7 > - current Portage doesn't work with 'spawn' > > so it seems what we can do: > 1. apply patch to Portage as Zac did in comment #c11 but instead of using > spawn, to force 'fork' > 2. patch Python 3.8's default to be 'fork' again on macOS > 3. revert PYTHON_TARGETS back to 3.7 until we sorted this out I've done option 1) locally and it works fine here (although I did it before the multiprocessing call, this shouldn't matter at all). Shall we go for that for now, as the least disruptive option? 2 could be fine but more work to ensure it's done right, and 3 may be a pain in terms of keeping up with the tree if people start dropping Python 3.7 (prematurely).
I prefer not to mess with PYTHON_TARGETS (any more), e.g. prefer no 3. I think 2 will come too late for most, as is 1, but we'll just have to deal with it. I'll prepare a patched portage.
(In reply to Fabian Groffen from comment #14) > I prefer not to mess with PYTHON_TARGETS (any more), e.g. prefer no 3. I > think 2 will come too late for most, as is 1, but we'll just have to deal > with it. I'll prepare a patched portage. Yeah, no option really helps folks who have upgraded already. If emerge --sync works with a broken Portage, we could do a news item.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=c6672f91217e0b0ec7739faebbdfba76fd6e83e5 commit c6672f91217e0b0ec7739faebbdfba76fd6e83e5 Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2020-12-04 10:34:49 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2020-12-04 10:37:54 +0000 sys-apps/portage-3.0.10.3: fix Python 3.8 on macOS interaction - added patch to temp force fork mode, to ensure we can run Portage with Python 3.8 (the only configured target nowadays) on Darwin - this release includes a fix for Linux/Solaris users (ELF-targets) to silence invalid soname dependencies warnings about missing host-provided libs Bug: https://bugs.gentoo.org/758230 Package-Manager: Portage-3.0.10.3-prefix, Repoman-3.0.2 Signed-off-by: Fabian Groffen <grobian@gentoo.org> sys-apps/portage/Manifest | 3 +- .../portage-3.0.10-multiprocessing-no-spawn.patch | 32 +++ ...age-3.0.10.2.ebuild => portage-3.0.10.3.ebuild} | 3 + sys-apps/portage/portage-3.0.8.ebuild | 299 --------------------- 4 files changed, 36 insertions(+), 301 deletions(-)
I'm confused. How will https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=c6672f91217e0b0ec7739faebbdfba76fd6e83e5 affect portage itself? The patch adjusts lib/portage/tests/runTests.py - isn't that just for tests? Is there another entrypoint where we can add this to affect portage as a whole? I'll go test this change in a moment, but I don't think it will do what we want.
(In reply to Jacob Floyd from comment #17) > I'm confused. How will > https://gitweb.gentoo.org/repo/proj/prefix.git/commit/ > ?id=c6672f91217e0b0ec7739faebbdfba76fd6e83e5 affect portage itself? The > patch adjusts lib/portage/tests/runTests.py - isn't that just for tests? Is > there another entrypoint where we can add this to affect portage as a whole? > > I'll go test this change in a moment, but I don't think it will do what we > want. https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=a425220505c4e94abe9df6c7d7f64a9ee71764d3 ;)
I made a booboo, and I hoped noone would notice :) Ok, now I know people really pay attention to what I do :S
(In reply to Fabian Groffen from comment #19) > I made a booboo, and I hoped noone would notice :) Ok, now I know people > really pay attention to what I do :S LOL I make mistakes all the time :P
With this patch, emerge is happily chugging away in stage2. Thanks. (I switched to 3.0.10.3, and I manually applied it to EPREFIX/usr/lib/portage/bin/emerge).
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=fbc146fd7ec39c04da33cf85c507ec401748e57d commit fbc146fd7ec39c04da33cf85c507ec401748e57d Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2021-01-04 12:11:50 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2021-01-04 12:11:50 +0000 sys-apps/portage-3.0.12.0.2: more complete fix for Darwin spawn problems Bug: https://bugs.gentoo.org/758230 Package-Manager: Portage-3.0.12.0.2-prefix, Repoman-3.0.2 Signed-off-by: Fabian Groffen <grobian@gentoo.org> sys-apps/portage/Manifest | 1 + sys-apps/portage/portage-3.0.12.0.2.ebuild | 298 +++++++++++++++++++++++++++++ 2 files changed, 299 insertions(+)
(In reply to Larry the Git Cow from comment #16) > The bug has been referenced in the following commit(s): > > https://gitweb.gentoo.org/repo/proj/prefix.git/commit/ > ?id=c6672f91217e0b0ec7739faebbdfba76fd6e83e5 > > commit c6672f91217e0b0ec7739faebbdfba76fd6e83e5 > Author: Fabian Groffen <grobian@gentoo.org> > AuthorDate: 2020-12-04 10:34:49 +0000 > Commit: Fabian Groffen <grobian@gentoo.org> > CommitDate: 2020-12-04 10:37:54 +0000 > > sys-apps/portage-3.0.10.3: fix Python 3.8 on macOS interaction > > - added patch to temp force fork mode, to ensure we can run Portage with > Python 3.8 (the only configured target nowadays) on Darwin > - this release includes a fix for Linux/Solaris users (ELF-targets) to > silence invalid soname dependencies warnings about missing > host-provided libs > > Bug: https://bugs.gentoo.org/758230 > Package-Manager: Portage-3.0.10.3-prefix, Repoman-3.0.2 > Signed-off-by: Fabian Groffen <grobian@gentoo.org> > > sys-apps/portage/Manifest | 3 +- > .../portage-3.0.10-multiprocessing-no-spawn.patch | 32 +++ > ...age-3.0.10.2.ebuild => portage-3.0.10.3.ebuild} | 3 + > sys-apps/portage/portage-3.0.8.ebuild | 299 > --------------------- > 4 files changed, 36 insertions(+), 301 deletions(-) If you merge changes from portage-3.0.55 to the prefix branch, then it should be possible to use to the multiprocessing spawn start method now. Bug 916601 was the last known incompatibility. The biggest change is that bug 915896 implemented fd_pipes support via send_handle/recv_handle.
Thanks, I'll have to try this!
