Nearly all python-3.x ebuilds, especially ALL stable 3.x ebuilds, set bad values for EPYTHON in the epython.py module. This is fatal for packages depending on python-exec including portage itself. While portage still runs fine with python2, this issue prevents programs from running that depend on python3 (e.g. some alembic database migration scripts). For python-3.4.3.ebuild (currently the latest stable) this was introduced with the following commit: https://gitweb.gentoo.org/repo/gentoo.git/commit/dev-lang/python/python-3.4.3.ebuild?id=bc46e49ff67cf1e5157ab95b41e780067f433685 python-3.4.3-r7 seems to be fixed but is keyworded. EPYTHON is set to "python" instead of "python3.4". This seems to happen due to not setting variable $PYVER in the ebuild (see diff between python-3.4.3.ebuild and python-3.4.3-r7.ebuild). python-2.x ebuilds work because they do not use $PYVER for setting EPYTHON but $SLOT. Reproducible: Always Actual Results: # python3.4 /usr/bin/emerge --version This Python implementation (python) is not supported by the script. Expected Results: # python2.7 /usr/bin/emerge --version Portage 2.2.24 (python 2.7.10-final-0, hardened/linux/amd64, gcc-4.9.3, glibc-2.21-r1, 4.1.6 x86_64)
Are you able to clarify on your steps to reproduce? eselect python list Available Python interpreters: [1] python2.7 [2] python3.3 [3] python3.4 * python3.4 /usr/bin/emerge --version Portage 2.2.25 (python 3.4.3-final-0, default/linux/amd64/13.0/developer, gcc-4.8.4, glibc-2.22-r1, 3.19.0-tuxonice x86_64) python2.7 /usr/bin/emerge --version Portage 2.2.25 (python 2.7.10-final-0, default/linux/amd64/13.0/developer, gcc-4.8.4, glibc-2.22-r1, 3.19.0-tuxonice x86_64 eselect python list Available Python interpreters: [1] python2.7 * [2] python3.3 [3] python3.4 python3.4 /usr/bin/emerge --version Portage 2.2.25 (python 3.4.3-final-0, default/linux/amd64/13.0/developer, gcc-4.8.4, glibc-2.22-r1, 3.19.0-tuxonice x86_64) python2.7 /usr/bin/emerge --version Portage 2.2.25 (python 2.7.10-final-0, default/linux/amd64/13.0/developer, gcc-4.8.4, glibc-2.22-r1, 3.19.0-tuxonice x86_64
Created attachment 421582 [details, diff] fix setting bad EPYTHON
Well, this is a flaw in the ebuilds and has nothing to do with the python version set for /usr/bin/python. So the output stays, of course, the same: # python3.4 /usr/bin/emerge --version This Python implementation (python) is not supported by the script. # python2.7 /usr/bin/emerge --version Portage 2.2.24 (python 2.7.10-final-0, hardened/linux/amd64, gcc-4.9.3, glibc-2.21-r1, 4.1.6 x86_64) I've attached a patch which fixes the issue: # python3.4 /usr/bin/emerge --version Portage 2.2.24 (python 3.4.3-final-0, hardened/linux/amd64, gcc-4.9.3, glibc-2.21-r1, 4.1.6 x86_64)
added mgorny to CC list because he did the commit that actually broke it
Indeed that's a bad copy-paste fail. I've got a fix staged, I'm going to test it and commit it afterwards.
commit f21ac182f8d6eed7b4dbc69cdbce40ca44776d17 Author: Michał Górny <mgorny@gentoo.org> Date: Mon Jan 4 17:47:23 2016 dev-lang/python: Fix invalid PYVER references, #570542 That's a start to prevent more people from getting this. Now, there's a question how to fix existing stable systems. I guess we'd need to revbump both stable and ~arch to get clear -r for stable.
And revbumped.
Great, thanks!
