Traceback (most recent call last): File "/var/tmp/portage/app-text/gnome-doc-utils-0.20.10-r2/work/gnome-doc-utils-0.20.10-python3_8/xml2po/xml2po/xml2po", line 191, in <module> main(sys.argv[1:]) File "/var/tmp/portage/app-text/gnome-doc-utils-0.20.10-r2/work/gnome-doc-utils-0.20.10-python3_8/xml2po/xml2po/xml2po", line 88, in main from xml2po import Main File "/var/tmp/portage/app-text/gnome-doc-utils-0.20.10-r2/work/gnome-doc-utils-0.20.10/xml2po/xml2po/__init__.py", line 27, in <module> import libxml2 ModuleNotFoundError: No module named 'libxml2' make[2]: *** [Makefile:684: de/gnome-doc-make.xml] Error 1 make[2]: Leaving directory '/var/tmp/portage/app-text/gnome-doc-utils-0.20.10-r2/work/gnome-doc-utils-0.20.10-python Reproducible: Always Steps to Reproduce: 1. emerge --sync 2. emerge -auvDN world Actual Results: app-text/gnome-doc-utils-0.20.10-r2 failed to build Expected Results: It should not fail.
Created attachment 598504 [details] build.log
Created attachment 598506 [details] emerge -pqv '=app-text/gnome-doc-utils-0.20.10-r2::gentoo'
Created attachment 598508 [details] emerge --info '=app-text/gnome-doc-utils-0.20.10-r2::gentoo'
The same thing happens here with both gnome-doc-utils and dev-util/itstool and I believe it boils down to dev-libs/libxml2 installing its Python 3.8 modules in a strange place. Newer Pythons (3.7, 3.8) seemingly switched to only using /usr/lib/python${version} for module search paths, and while libxml2 correctly installs the 3.7 module files in /usr/lib/ it, for some reason, installs the Python 3.8 module files in /usr/lib64/, which won't be looked in by default. I have a large amount of python 3.7 and 3.8 packages and almost everything is in /usr/lib/python3.{7,8}. This is what I get for `find /usr/lib64/python3.8`: /usr/lib64/python3.8 /usr/lib64/python3.8/site-packages /usr/lib64/python3.8/site-packages/snack.py /usr/lib64/python3.8/site-packages/libxml2.py /usr/lib64/python3.8/site-packages/libxml2mod.so /usr/lib64/python3.8/site-packages/drv_libxml2.py And for `find /usr/lib64/python3.7`: /usr/lib64/python3.7 /usr/lib64/python3.7/site-packages /usr/lib64/python3.7/site-packages/snack.py (So, dev-libs/newt, a different non-multilib package appears to be misbehaving as well). On a side note, this appears to have a side effect of causing the bytecode files to not get compiled as well?
Aaron, do you have an idea what might be happening there with these python-r1 packages?
I'm investigating this. Updating the title to reflect broken packages correctly.
Well, it is as I've suspected. 1. dev-libs/newt is definitely broken and installs its Python modules to the incorrect directory. 2. dev-libs/libxml2 normally installs it fine but if /usr/lib64/python3.8/site-packages exists already, it uses that directory instead.
In case of newt, the issue is pretty clear -- the install path is hardcoded in Makefile.in: [ -n "$(PYTHONVERS)" ] && for ver in $(PYTHONVERS) ; do \ [ -d $(instroot)/$(libdir)/$$ver/site-packages ] || install -m 755 -d $(instroot)/$(libdir)/$$ver/site-packages ;\ install -m 755 $$ver/_snack.$(SOEXT) $(instroot)/$(libdir)/$$ver/site-packages ;\ install -m 644 snack.py $(instroot)/$(libdir)/$$ver/site-packages ;\ done || :
libxml2 also uses home-made code to detect Python, and it guesses site-packages directory based on directories that exist: if test "$with_python_install_dir" != "" then PYTHON_SITE_PACKAGES="$with_python_install_dir" fi if test "$PYTHON_VERSION" != "" -a "$PYTHON_SITE_PACKAGES" = "" then if test -d $libdir/python$PYTHON_VERSION/site-packages then PYTHON_SITE_PACKAGES=$libdir/python$PYTHON_VERSION/site-packages else if test -d $with_python/lib/site-packages then PYTHON_SITE_PACKAGES=$with_python/lib/site-packages else PYTHON_SITE_PACKAGES=`$PYTHON -c "from distutils import sysconfig; print(sysconfig.get_python_lib())"` fi fi fi Apparently upstream decides to do the correct thing only if all else fails. However, here it can be easily worked around via passing --with-python-install-dir, I think.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cbadb28169dcfdf182f721fba55ac2d51dbc4f1b commit cbadb28169dcfdf182f721fba55ac2d51dbc4f1b Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2019-12-07 16:45:37 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2019-12-07 16:58:53 +0000 dev-libs/newt: Remove py3.7&3.8 as they're broken The module is installed into incorrect directory when using Python 3.7 and 3.8, which in turn exposes breakage in other packages. Bug: https://bugs.gentoo.org/702016 Signed-off-by: Michał Górny <mgorny@gentoo.org> dev-libs/newt/newt-0.52.21.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3ac390cc82d42c6d50dcff61b9884dbf19b03e7d commit 3ac390cc82d42c6d50dcff61b9884dbf19b03e7d Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2019-12-07 19:52:39 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2019-12-07 20:31:29 +0000 dev-libs/libxml2: Ensure using correct Python sitedir Closes: https://bugs.gentoo.org/702016 Signed-off-by: Michał Górny <mgorny@gentoo.org> .../libxml2/{libxml2-2.9.9-r1.ebuild => libxml2-2.9.9-r2.ebuild} | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6f05bc88c81a42943e5784736d2eb15f63c5ef40 commit 6f05bc88c81a42943e5784736d2eb15f63c5ef40 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2024-01-05 15:52:16 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2024-01-08 14:48:19 +0000 install-qa-check.d/60python-site: Add check for wrong libdir Bug: https://bugs.gentoo.org/702016 Bug: https://bugs.gentoo.org/770961 Signed-off-by: Michał Górny <mgorny@gentoo.org> metadata/install-qa-check.d/60python-site | 12 ++++++++++++ 1 file changed, 12 insertions(+)
