The packages are stuck on py3.6 which means they will be pain once we switch to 3.7. Please test them on 3.7 *and* 3.8 (so we don't to revisit this in a few months), and update PYTHON_COMPAT appropriately. If it doesn't work, please either fix it, remove Python or issue last rites. Please consider this urgent.
I've just tested the tweaking of PYTHON_COMPAT to support 7 & 8. All seems to work, the significant path seems to be entirely in compton-convgen which seems rarely used. Tests pass too.
This bug is currently blocking upgrades on stable systems.
(In reply to Kent Fredric (IRC: kent\n) from comment #1) > I've just tested the tweaking of PYTHON_COMPAT to support 7 & 8. > > All seems to work, the significant path seems to be entirely in > compton-convgen which seems rarely used. > > Tests pass too. I can confirm this works here as well. It isn't clear to me why there is a python restriction, as this is not a python package and the only use of python is during the install phase.
I confirm that compton works fine with python 3.7 too. I'm using it on my desktop currently with python 3.7.
Also conformed here that the pull request, when applied to the ebuild, results in compton building and running properly when built with: PYTHON_TARGETS="python3_8 -python3_6 -python3_7" This is on ~arch system.
(In reply to Paul Jewell from comment #3) > (In reply to Kent Fredric (IRC: kent\n) from comment #1) > > I've just tested the tweaking of PYTHON_COMPAT to support 7 & 8. > > > > All seems to work, the significant path seems to be entirely in > > compton-convgen which seems rarely used. > > > > Tests pass too. > > I can confirm this works here as well. It isn't clear to me why there is a > python restriction, as this is not a python package and the only use of > python is during the install phase. Well, because it has to run python code, it needs to ensure that the version of python it uses is one the code works with. Like, if the code only worked on Python 2.7, then somebody would need to make sure python 2.7 is installed, and all the relevant python build time deps were built for python 2.7 And its *not* just a build time code, compton-compgen is a python script which gets installed. And the glue needs to be in place so that when a user runs that, it automatically runs on the right python, and that python is installed. This can't be handled by simply stating "max and min versions" for Python. You'll note that with PYTHON_COMPAT=( python3_6 ) and PYTHON_TARGETS="python3_6 python2_7", this gets installed: > /usr/lib/python-exec/python3.6/compton-convgen And it needs both these variables to be simply *able* to do this. So naturally, PYTHON_COMPAT can only be extended after: - The applicable python exists - And the code can be demonstrated to work properly on the applicable python So the real "blocker" here is maintainership not being aggressive enough to make the changes needed when they become available.
It is probably better to mask compton for removal in favor of picom since upstream seems to have died 3 years ago.
(In reply to Aaron W. Swenson from comment #7) > It is probably better to mask compton for removal in favor of picom since > upstream seems to have died 3 years ago. That seems grossly excessive, given that it still works just fine, and the only "fix" needed is a one line PYTHON_COMPAT tweak, and the *only* reason that hasn't been fixed already, to the best of my knowledge is: - The maintainer hasn't actioned it themselves yet - I've not pushed my fix I made in the PR myself yet, because I want to politely give that maintainer the opportunity to fix it themselves. I could literally fix this myself today if I wanted to, somebody might complain, that's the worst I can imagine at this point. > upstream seems to have died 3 years ago. We have perl packages in tree that continue to work, and upstream hasn't been seen this side of Y2K .... that's a terrible argument.
You can claim maintainer timeout already, and push it.
Due to maintainer timeout, I'm gonna push this today. I've also added python 3.9 support, which is also tested to work, which will save us having this problem 2 years from now if this is still in tree.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2c8546f4f9ea0a3cf7fab3daf73534e2db117592 commit 2c8546f4f9ea0a3cf7fab3daf73534e2db117592 Author: Kent Fredric <kentnl@gentoo.org> AuthorDate: 2020-04-22 14:38:20 +0000 Commit: Kent Fredric <kentnl@gentoo.org> CommitDate: 2020-06-17 08:58:02 +0000 x11-misc/compton: Add python 3.7, 3.8 & 3.9 support re bug #718546 Bug: https://bugs.gentoo.org/718546 Package-Manager: Portage-2.3.97, Repoman-2.3.22 Signed-off-by: Kent Fredric <kentnl@gentoo.org> x11-misc/compton/compton-0.1_beta2-r1.ebuild | 69 ++++++++++++++++++++++++++++ 1 file changed, 69 insertions(+)