Bug 828604 – dev-python/eyeD3: eyed3 0.9.6 has requirement coverage[toml]==5.*,>=5.3.1, but you have coverage 6.2 (was: www-client/firefox-95.0: According to "pip check", the current Python environment has package-compatibility issues.)

• Status: CONFIRMED
• Product: Gentoo Linux

[Description Andrey Grozin 2021-12-09 11:21:39 UTC]

Created attachment 757796 [details]
build log

Traceback (most recent call last):
  File "/var/tmp/portage/www-client/firefox-95.0/work/firefox-95.0/./mach", line 167, in <module>
    main(sys.argv[1:])
  File "/var/tmp/portage/www-client/firefox-95.0/work/firefox-95.0/./mach", line 159, in main
    mach = check_and_get_mach(os.path.dirname(os.path.realpath(__file__)))
  File "/var/tmp/portage/www-client/firefox-95.0/work/firefox-95.0/./mach", line 146, in check_and_get_mach
    return load_mach(dir_path, mach_path)
  File "/var/tmp/portage/www-client/firefox-95.0/work/firefox-95.0/./mach", line 134, in load_mach
    return mach_initialize.initialize(dir_path)
  File "/var/tmp/portage/www-client/firefox-95.0/work/firefox-95.0/build/mach_initialize.py", line 291, in initialize
    _activate_python_environment(topsrcdir)
  File "/var/tmp/portage/www-client/firefox-95.0/work/firefox-95.0/build/mach_initialize.py", line 233, in _activate_python_environment
    raise Exception(
Exception: According to "pip check", the current Python environment has package-compatibility issues.

[Comment 1 Thomas Deutschmann (RETIRED) 2021-12-10 00:03:44 UTC]

Not a problem in firefox itself, >=firefox-95 is just calling "pip check" which is revealing broken packages. Assigning to eyeD3 maintainers.

[Comment 2 Andrey Grozin 2021-12-10 14:20:03 UTC]

I'd agree to install coverage-5.x, but it is no longer in the tree. What's the most reasonable solution? Put coverage-5.x back to the tree? Something should be done quickly. This but makes it impossible to buils the newest firefox.

[Comment 3 Sam James 2021-12-10 14:26:45 UTC]

(In reply to Andrey Grozin from comment #2)
> I'd agree to install coverage-5.x, but it is no longer in the tree. What's
> the most reasonable solution? Put coverage-5.x back to the tree? Something
> should be done quickly. This but makes it impossible to buils the newest
> firefox.

The Firefox maintainers should consider just dropping the check like Exherbo has. I don't see the value in it crashing the build for Firefox given it's been fine until now.

Should we fix pip check failures? Absolutely. But this is a bit like -Werror: there's not really much that crashing the build achieves here. We should see about adding pip check to the tinderboxes or a QA check instead

Anyway, this failure is "unique" to you - it completely depends on what packages you have installed. In this case, the fix is to strip out the dep in eyeD3 - not install coverage (we don't care about coverage for running tests in Gentoo).

[Comment 4 Piotr Karbowski (RETIRED) 2021-12-10 18:37:02 UTC]

I agree that this is to be fixed on firefox side. Before it was failing because optideps of yt-dlp.

@whissi: A sloppy firefox build system that crashes when *unrelated* python packages are missing is, by all means, a firefox bug.

[Comment 5 Piotr Karbowski (RETIRED) 2021-12-10 18:44:02 UTC]

All right, so I looked into the code, and firefox run this check only if pip is present, and just continue if dev-python/pip is not, since it is not a dependency of firefox.

So we have situation where firefox crashes on misconfiguration of not related package if it has tool to check it, and just continues anyway if it's not around.

@whissi, this really needs a fix on firefox side, this is just wrong. It's on the same foot as ebuilds that have different behavior depending on what files are present on build system during building.

[Comment 6 John Bytheway 2021-12-18 13:41:15 UTC]

Created attachment 759588 [details, diff]
Patch to disable pip check

I used the attached patch to disable the pip check and the build worked fine for me.