https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: media-libs/gstreamer-editing-services-1.22.3 installs modules that are not byte-compiled. Discovered on: arm64 (internal ref: tinderbox_arm64) System: GCC-14-SYSTEM (https://wiki.gentoo.org/wiki/Project:Tinderbox/Common_Issues_Helper#GCC-14) Info about the issue: https://wiki.gentoo.org/wiki/Project:Tinderbox/Common_Issues_Helper#QA0004
Created attachment 885409 [details] build.log build log and emerge --info
Question is, why is it installing stuff to python3.12 site-packages in the first place when only 3.10 and 3.11 USE_EXPAND flags were enabled
(In reply to Mart Raudsepp from comment #2) > Question is, why is it installing stuff to python3.12 site-packages in the > first place when only 3.10 and 3.11 USE_EXPAND flags were enabled good catch, I didn't notice that.
Program python3 found: YES (/usr/bin/python3) Run-time dependency python-3.12-embed found: YES 3.12 Message: pylib_loc = /usr/lib64 Message: python_abi_flags = Message: pylib_loc = /usr/lib64 Message: pygobject overrides directory = /usr/lib/python3.12/site-packages/gi/overrides
I think fix for bug 848705 improves this as well - here the global interpreter was python3.12, while PYTHON_TARGETS only has python3.{10,11}, so the build systems own overrides dir installed to py3.12, while our manual handling installed to 3.10 and 3.11 and didn't know anything about there being stuff for 3.12 installed by upstream build system as well. But now the global interpreter version will be one of the USE enabled python versions, thus we'll have double installation of the override file (once by build system and then by our own per-python ebuild logic), but as it's covered by PYTHON_TARGETS iteration now, it'll be fine in practice. I THINK that is good enough to not do anything further, albeit technically we shouldn't let the build system install it. But it's a tiny file that goes in the right place, so I think it's fine now and nothing worth doing further. Eli, what do you think?
uh, digging at it a bit more I see that -Dpython=enabled is passed, which does a bunch of other things, including linking the library to libpython*.so*, so need to remind myself about this stuff a bit more. Though it feels fine now regardless, as the best enable python version is picked as the global one, which it uses for that part of things, and the deps are in place for that (and more for the overrides) too.
