File "/usr/lib/python3.10/site-packages/setuptools/monkey.py", line 134, in patch_for_msvc_specialized_compiler msvc = import_module('setuptools.msvc') File "/usr/lib/python3.10/importlib/__init__.py", line 126, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "/usr/lib/python3.10/site-packages/setuptools/msvc.py", line 24, in <module> from packaging.version import LegacyVersion ImportError: cannot import name 'LegacyVersion' from 'packaging.version' (/usr/lib/python3.10/site-packages/packaging/version.py) * ERROR: dev-python/pygments-2.14.0::gentoo failed (compile phase): * (no error message) ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 23.0_desktop_gnome_systemd-j4-20230207-190021 ------------------------------------------------------------------- GNUMAKEFLAGS="$GNUMAKEFLAGS --jobserver-style=pipe" gcc-config -l: [1] x86_64-pc-linux-gnu-12 * clang/llvm (if any): Python 3.10.9 Available Rust versions: (none found) php cli (if any): HEAD of ::gentoo commit b615998ad1aedb83f0efbc79a7e0315768570c0c Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Tue Feb 7 18:17:06 2023 +0000 2023-02-07 18:17:05 UTC emerge -qpvO dev-python/pygments [ebuild N ] dev-python/pygments-2.14.0 USE="-test" PYTHON_TARGETS="python3_10 -pypy3 -python3_9 -python3_11"
Created attachment 850194 [details] emerge-info.txt
Created attachment 850196 [details] dev-python:pygments-2.14.0:20230207-213220.log
Created attachment 850198 [details] emerge-history.txt
Created attachment 850200 [details] environment
Created attachment 850202 [details] etc.portage.tar.bz2
Created attachment 850204 [details] temp.tar.bz2
*** Bug 893540 has been marked as a duplicate of this bug. ***
If you're hitting this, please run: emerge -v1 dev-python/setuptools. This was/is caused by some now-removed versions of setuptools in ~arch. Current stable and ~arch versions are OK. There's no easy way to force ~arch users to get the right version, as we can't just simply add a >= dep in the eclass, as we haven't stabled a new enough version yet, but stable users were also never affected by the bad versions. We may add a || ( ... ) dep in the eclass for now given this is such a pain.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=50546c3db84904399e5624eb8f163e3d2be284e3 commit 50546c3db84904399e5624eb8f163e3d2be284e3 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-02-09 18:19:38 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-02-09 18:22:36 +0000 distutils-r1.eclass: adjust setuptools dep to avoid known-bad versions 79071eb9f6f4a5725c1a89700bcfd7f120101179 tried to mitigate this but blockers don't affect dependency resolution (ordering), so let's add a || ( <dev-python/setuptools-... >=dev-python/setuptools-...) dep in the eclass to ensure that the bad in-between versions (which were in ~arch, not stable, for a period, and are no longer in tree) aren't considered good enough to install any distutils-r1 PEP517 packages. We can clean this up once newer setuptools is stable & then simplify (and tighten) the dep. (Worth keeping in mind that Portage (rightly) doesn't aggressively update things listed in RDEPEND in that order simply because they're in RDEPEND. It might update something listed in RDEPEND after the package listing it provided there's no >= or otherwise dep.) Bug: https://bugs.gentoo.org/892529 Bug: https://bugs.gentoo.org/892525 Bug: https://bugs.gentoo.org/893538 Bug: https://bugs.gentoo.org/893632 Bug: https://bugs.gentoo.org/893630 Bug: https://bugs.gentoo.org/893634 Signed-off-by: Sam James <sam@gentoo.org> eclass/distutils-r1.eclass | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)