Happened during a world update. The complete error message is as * Using python3.8 in global scope * python3_8: running distutils-r1_run_phase python_compile_all Traceback (most recent call last): File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 567, in _build_master ws.require(__requires__) File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 884, in require needed = self.resolve(parse_requirements(requirements)) File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 775, in resolve raise VersionConflict(dist, req).with_context(dependent_req) pkg_resources.ContextualVersionConflict: (chardet 4.0.0 (/usr/lib/python3.8/site-packages), Requirement.parse('chardet<4,>=3.0.2'), {'requests'}) During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python-exec/python3.8/sphinx-build", line 33, in <module> sys.exit(load_entry_point('Sphinx==2.4.4', 'console_scripts', 'sphinx-build')()) File "/usr/lib/python-exec/python3.8/sphinx-build", line 25, in importlib_load_entry_point return next(matches).load() File "/usr/lib/python3.8/importlib/metadata.py", line 77, in load module = import_module(match.group('module')) File "/usr/lib/python3.8/importlib/__init__.py", line 127, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "<frozen importlib._bootstrap>", line 1014, in _gcd_import File "<frozen importlib._bootstrap>", line 991, in _find_and_load File "<frozen importlib._bootstrap>", line 975, in _find_and_load_unlocked File "<frozen importlib._bootstrap>", line 671, in _load_unlocked File "<frozen importlib._bootstrap_external>", line 783, in exec_module File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed File "/usr/lib/python3.8/site-packages/sphinx/cmd/build.py", line 23, in <module> from sphinx.application import Sphinx File "/usr/lib/python3.8/site-packages/sphinx/application.py", line 26, in <module> from docutils.parsers.rst import Directive, roles File "/usr/lib/python3.8/site-packages/docutils/parsers/rst/__init__.py", line 75, in <module> from docutils.parsers.rst import roles, states File "/usr/lib/python3.8/site-packages/docutils/parsers/rst/roles.py", line 78, in <module> from docutils.utils.code_analyzer import Lexer, LexerError File "/usr/lib/python3.8/site-packages/docutils/utils/code_analyzer.py", line 12, in <module> from pkg_resources import DistributionNotFound as ResourceError File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 3239, in <module> def _initialize_master_working_set(): File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 3222, in _call_aside f(*args, **kwargs) File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 3251, in _initialize_master_working_set working_set = WorkingSet._build_master() File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 569, in _build_master return cls._build_from_requirements(__requires__) File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 582, in _build_from_requirements dists = ws.resolve(reqs, Environment()) File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 770, in resolve raise DistributionNotFound(req, requirers) pkg_resources.DistributionNotFound: The 'chardet<4,>=3.0.2' distribution was not found and is required by requests * ERROR: dev-python/qtawesome-1.0.2::gentoo failed (compile phase): * (no error message) Reproducible: Always AFAICS this could actually be an issue with the portage dependency resolver. The still installed dev-python/requests-2.25.0 depends on <chardet-4 and >=chardet-3.0.2, while the still in-queue dev-python/requests-2.25.1 has dependencies on <chardet-5 and >=chardet-3.0.2. Qtawesome itself only depends indirectly on requests, through sphinx, and through requests there's an indirect dependecy on chardet given. The calculated emerge order shows as (partial but in order): artus /etc # nice -n 19 emerge -DaquvN @world [...] [ebuild U ] dev-python/chardet-4.0.0 [3.0.4-r1] USE="-test" PYTHON_TARGETS="python3_7 python3_8 python3_9 -pypy3 -python3_6" [...] [ebuild U ] dev-python/qtawesome-1.0.2 [1.0.1] USE="doc -test" PYTHON_TARGETS="python3_7 python3_8 python3_9" [...] [ebuild U ] dev-python/requests-2.25.1 [2.25.0] USE="ssl -socks5 -test" PYTHON_TARGETS="python3_7 python3_8 python3_9 -pypy3 -python3_6" [...] while the order of requests and qtawesome should possibly have been reversed. By first updating to requests-2.25.1, the build of qtawesome-1.0.2 is succesful. Build log and emerge --info as attachments.
Created attachment 678721 [details] qtawesome-1.0.2:20201218-093328.log build log
Created attachment 678724 [details] emerge-info-qtawesome-1.0.2.txt output of emerge --info qtawesome Done after manually updating requests and qtawesome.
The bug is in dev-python/requests not in dev-python/qtawesome, as can be seen here: pkg_resources.DistributionNotFound: The 'chardet<4,>=3.0.2' distribution was not found and is required by requests
It's probably not in requests. As I wrote in my initial comment, the qtawesome package came between chardet and requests updates and there was a change from <chardet-4 to <chardet-5 in the old and new requests package. Requests has correct dependencies, but qtawesome came inbetween the updates of chardet and requests, which is technically correct, as qtawesome doesn't depend on requests directly. Due to it's indirect dependency on requests it should have been updated after the requests update.
The problem is likely downwards in the dependency chain, qtawesome depends on requests as follows: qtawesome QtPy PyQt5 qtxml qtnetwork libproxy spidermonkey rust llvm recommmark sphinx requests I suspect that somewhere in the chain a dependency is set as PDEPEND, which tells emerge to allow the dependecny to be emerged after the package has been emerged.
Your dependency chain is correct. But if you look at it on the ebuild level it is just qtawesome -> distutils-r1 -> sphinx -> requests, so I doubt that it's a problem with someone down the chain has set a PDEPEND value. Having a rather complex setup with a huge amount of installed packages, a @world update doesn't give a single linear dependency chain. In the resulting dependency graph you will likely get several quasi-linear chains which could, at least partially, be executed in parallel (but I don't do parallel emerge execution). There might be packages for which there's no simple decision about where in the chain it needs to be installed. It might be possible that this issue cannot be resolved at all, as with several emerge runs of said complexity you can get different installation orders. I see this from time to time, that single packages have a different order on multiple emerge -p runs.
The package version is no longer in tree. Closing this as obsolete.