I use pypy3 for emerge and during the upgrade from 7.3.11 to 7.3.12 it broke the interpreter for emerge. Presumably due to the move from py3.9 to py3.10, while portage was built against pypy3.9. $ cat /etc/python-exec/emerge.conf pypy3 Reproducible: Didn't try Steps to Reproduce: 1. Have pypy3 as the interpreter for portage. 2. Update pypy3 from 7.3.11 to 7.3.12 Actual Results: Pypy3 is inoperable for portage/emerge. Expected Results: emerge continues working seamlessly. Workaround is to use an alternative implementation which isn't pypy. This of course hinges on if you didn't put all your eggs in one pypy3 basket.
Created attachment 864193 [details] build.log where portage breaks during post_rm after the update
Created attachment 864194 [details] emerge --info (WITH EPYTHON="python3.12")
Order of emerges from qlop from the operation. Didnt use --jobs 2023-06-19T08:33:28 >>> net-wireless/wireless-regdb: 25s 2023-06-19T08:33:53 >>> acct-group/tss: 10s 2023-06-19T08:34:03 >>> acct-user/portage: 12s 2023-06-19T08:34:15 >>> acct-user/tss: 22s 2023-06-19T08:34:37 >>> app-shells/fzf: 34s 2023-06-19T08:35:11 >>> dev-lisp/sbcl: 2′39″ 2023-06-19T08:37:50 >>> dev-python/pypy-exe-bin: 11s 2023-06-19T08:38:01 >>> dev-python/pypy: 16s 2023-06-19T08:38:18 >>> dev-python/pypy3_10-exe: 21′12″ 2023-06-19T08:59:30 >>> dev-python/pypy3_10: 52s 2023-06-19T09:00:22 >>> dev-python/pypy3: 12s Its also plausible that its PEBKAC, posting the bug early without going too much into investigating the cause.
ask@bigglane /home/ask $ EPYTHON="python3.12" emerge > /dev/null ask@bigglane /home/ask $ EPYTHON="pypy3" emerge > /dev/null Traceback (most recent call last): File "/usr/lib/python-exec/pypy3/emerge", line 47, in <module> import portage ModuleNotFoundError: No module named 'portage'
================================================================= Package Settings ================================================================= sys-apps/portage-3.0.48.1-r1::gentoo was built with the following: USE="gentoo-dev (ipc) native-extensions rsync-verify xattr -apidoc -build -debug -doc (-selinux) -test" ABI_X86="(64)" PYTHON_TARGETS="pypy3 python3_11 python3_12 -python3_10"
Created attachment 864195 [details] qlist sys-apps/portage List of files for portage.
Other than that, forced rebuild appears to have catched every pypy3 package to rebuild them against pypy3.10. Meaning that the switch is otherwise smooth.
Unfortunately, we're really going to need to be able to reproduce this in a chroot or something (and to have emerge -p -uvDU @world or so to get the merge list). Could you try?
I will try. Interestingly portage is able to complete to continue after downgrading. Like portage does not work while im waiting on portage to rebuild, but the process still has it working so it can actually finish. Was expecting it to fail similarly like with the downgrade.
(In reply to Alfred Wingate from comment #9) > I will try. Interestingly portage is able to complete to continue after > downgrading. Like portage does not work while im waiting on portage to > rebuild, but the process still has it working so it can actually finish. > > Was expecting it to fail similarly like with the downgrade. My *complete* guess is that it's not an incomplete dep and that it's actually like e.g. the Perl bug, but I might be wrong (and I hope I am).
Im doing the chroot. But in the meanwhile I did downgrade + second upgrade attempt to see if it happens again. It happened. Ill post the merge list for that. The build failure is the exact same.
Created attachment 864241 [details] emerge -p -uvDU --ignore-default-opts @world
So 7.3.11 -> 7.3.12 failure but 7.3.12 -> 7.3.11 success.
Oh, I see! >>> Original instance of package unmerged safely. ModuleNotFoundError: No module named 'encodings' debug: OperationError: debug: operror-type: ModuleNotFoundError debug: operror-value: No module named 'encodings' [31;01m*[0m ERROR: dev-python/pypy3-7.3.12::gentoo failed (postinst phase): [31;01m*[0m filter-bash-environment.py failed [31;01m*[0m [31;01m*[0m Call stack: [31;01m*[0m ebuild.sh, line 780: Called __ebuild_main 'postinst' [31;01m*[0m phase-functions.sh, line 1017: Called __filter_readonly_variables '--filter-path' '--filter-sandbox' '--allow-extra-vars' [31;01m*[0m phase-functions.sh, line 149: Called die [31;01m*[0m The specific snippet of code: [31;01m*[0m "${PORTAGE_PYTHON:-/usr/bin/python}" "${PORTAGE_BIN_PATH}"/filter-bash-environment.py "${filtered_vars}" || die "filter-bash-environment.py failed" [31;01m*[0m [31;01m*[0m If you need support, post the output of `emerge --info '=dev-python/pypy3-7.3.12::gentoo'`, [31;01m*[0m the complete build log and the output of `emerge -pqv '=dev-python/pypy3-7.3.12::gentoo'`. [31;01m*[0m The complete build log is located at '/var/log/portage/build/dev-python/pypy3-7.3.12:20230619-060021.log.gz'. [31;01m*[0m For convenience, a symlink to the build log is located at '/var/tmp/portage/dev-python/pypy3-7.3.12/temp/build.log.gz'. [31;01m*[0m The ebuild environment file is located at '/var/tmp/portage/dev-python/pypy3-7.3.12/temp/environment'. [31;01m*[0m Working directory: '/var/tmp/portage/._portage_reinstall_.x3yyhm2c/lib' [31;01m*[0m S: '/var/tmp/portage/dev-python/pypy3-7.3.12/work' ModuleNotFoundError: No module named 'encodings' debug: OperationError: okay, I don't think it's an ordering issue actually then?
(That doesn't make the stage3 thing useless by the way, there's still an interesting interaction here)
It's probably because pypy3.10 is replacing pypy3.9, so PyPy3.9 used by Portage is suddenly left without stdlib. Unfortunately, I can't think of a good way of handling this.
Reproduced in the chroot (used Docker but still). https://hub.docker.com/layers/gentoo/stage3/latest/images/sha256-e6179bfc7ab8962d4ec6386e61fa48a6175206d658d44eeaea3afe4c289080d9 Synced repos: Timestamp of repository gentoo: Tue, 20 Jun 2023 02:30:01 +0000 Head commit of repository gentoo: 36f5caf1166ce6a279c1e3abe4e8cb30cb7b6ed3 So I went with these steps: 1. emerge pypy3-7.3.11 2. Accept unstable keywords but not for pypy3 (could also just accept keywords just for portage and its dependencies, would save time) 3. Update 4. Enable pypy3 targets for portage and dependencies (enabled them manually) 5. Set pypy3 as preferred interpreter in /etc/python-exec/emerge.conf 6. Unmask unstable pypy3-7.3.12 7. Update world Then it should fail.
Created attachment 864297 [details] emerge -p -uDU @world at step 7 from stage3
Created attachment 864298 [details] emerge --info from stage3
Created attachment 864299 [details] Post removal log from 7.3.11_p1 from stage3. Same as issue as previously, failure occurs after 7.3.12 is installed and when 7.3.11 is being removed.
