https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: x11-misc/polybar-3.5.7 fails to compile. Discovered on: amd64 (internal ref: ci) NOTE: If you think this is a GCC-11 related issue, please block bug 732706.
Created attachment 763932 [details] build.log build log and emerge --info
So apparently the problem lies in setuptools' pkg_resources.extern hack. The 'Version' objects created before pkg_resources.extern import apparently are incompatible with these created after it. I suspect the import is done indirectly through Sphinx. Trivial reproducer: ``` import packaging.version v1 = packaging.version.parse('1.2.3') import pkg_resources.extern.packaging.version v2 = packaging.version.parse('2.3.4') v1 < v2 ```
Apparently the problem is known for almost 4 years now.
Possible cheap hacks: 1. `import pkg_resources` early -- this will make sure the override is in place before first Version is created. However, this is ugly-ish since polybar doesn't use pkg_resources itself, and a future version of Sphinx may drop the dep. 2. Store version_txt as the original string and parse it just before using. I can make a patch for 2. if you need me to.
Just wanted to add what I found out so far. I'm the maintainer of polybar and ajak pointed me to this issue. Sphinx 4.4.0 drops setuptools (and with it pkg_resources), so any indirect import likely comes from a 3rd party library imported by sphinx (or by us in the big if-block at the end of conf.py). The minimal reproducer may not be universal. At least on arch, it runs without issue inside a clean pyenv (python 3.9.9). I already told ajak this. Technically, for release builds, the whole version checking stuff isn't necessary. We only use it to tag some stuff with '(Unreleased)' in non-release builds (e.g. for readthedocs), but for a release, no such thing should exist. So, you could also just remove the entire big if-block at the end. But, if you want to be more fine-grained, 2. should work just as well :)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f96824b97f7f27ed91e880df1b779a625460de28 commit f96824b97f7f27ed91e880df1b779a625460de28 Author: John Helmert III <ajak@gentoo.org> AuthorDate: 2022-03-03 05:23:05 +0000 Commit: John Helmert III <ajak@gentoo.org> CommitDate: 2022-03-03 05:23:34 +0000 x11-misc/polybar: respect LDFLAGS Closes: https://bugs.gentoo.org/832357 Signed-off-by: John Helmert III <ajak@gentoo.org> x11-misc/polybar/polybar-3.6.0.ebuild | 5 +++++ 1 file changed, 5 insertions(+)
Er, sorry, wrong bug. This is fixed in 3.6.0 (thanks, mgorny!) so this bug will be fixed once that is stabled.
Marked the wrong bug here: commit af6670f21a3576a76f93cc73c05f72d97c673920 Author: John Helmert III <ajak@gentoo.org> Date: Tue Jul 19 11:44:27 2022 -0500 x11-misc/polybar: drop 3.5.7, 3.6.1, 3.6.2 Closes: https://bugs.gentoo.org/856619 Signed-off-by: John Helmert III <ajak@gentoo.org>
