Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 760621 - =dev-python/qtawesome-1.0.2: pkg_resources.ContextualVersionConflict: (chardet 4.0.0 (/usr/lib/python3.8/site-packages), Requirement.parse('chardet<4,>=3.0.2') , {'requests'})
Summary: =dev-python/qtawesome-1.0.2: pkg_resources.ContextualVersionConflict: (charde...
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal minor (vote)
Assignee: Andrey Grozin
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-12-18 11:03 UTC by Bernd
Modified: 2020-12-19 17:39 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
qtawesome-1.0.2:20201218-093328.log (qtawesome-1.0.2:20201218-093328.log,16.39 KB, text/plain)
2020-12-18 11:03 UTC, Bernd
Details
emerge-info-qtawesome-1.0.2.txt (emerge-info-qtawesome-1.0.2.txt,14.85 KB, text/plain)
2020-12-18 11:04 UTC, Bernd
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bernd 2020-12-18 11:03:08 UTC
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.
Comment 1 Bernd 2020-12-18 11:03:40 UTC
Created attachment 678721 [details]
qtawesome-1.0.2:20201218-093328.log

build log
Comment 2 Bernd 2020-12-18 11:04:42 UTC
Created attachment 678724 [details]
emerge-info-qtawesome-1.0.2.txt

output of emerge --info qtawesome

Done after manually updating requests and qtawesome.
Comment 3 Andrew Ammerlaan gentoo-dev 2020-12-19 15:47:11 UTC
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
Comment 4 Bernd 2020-12-19 16:17:49 UTC
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.
Comment 5 Andrew Ammerlaan gentoo-dev 2020-12-19 16:36:31 UTC
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.
Comment 6 Bernd 2020-12-19 17:39:56 UTC
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.