please add python3 versions to PYTHON_COMPAT. example: PYTHON_COMPAT=( python2_7 python3_6 ) It work here. Making a "python2 free" installation possible. If it's not deemed possible, please add a comment to ebuilds stating the reasons. Thanks in advance
Created attachment 521236 [details] test-suite.log using Python 3.6 (In reply to Francesco Riosa from comment #0) > please add python3 versions to PYTHON_COMPAT. > example: > PYTHON_COMPAT=( python2_7 python3_6 ) > > Making a "python2 free" installation possible. Just to be clear: Installation without Python 2.7 _is_ possible without FEATURES=test. > It work here. Can you prove that please? I removed Python 3 support by intention because the test suite is failing for me with Python 3 (and please note that upstream doesn't officially support Python 3). See the following fallout with Python 3.6 and automake-1.16-r1 for example (these tests are passing with Python 2.7): > FAIL: t/nobase-python.sh > FAIL: t/py-compile-basic.sh > FAIL: t/py-compile-basedir.sh > FAIL: t/py-compile-destdir.sh > FAIL: t/py-compile-option-terminate.sh > FAIL: t/python3.sh > FAIL: t/python10.sh > FAIL: t/python12.sh > FAIL: t/python-virtualenv.sh > ============================================================================ > Testsuite summary for GNU Automake 1.16 > ============================================================================ > # TOTAL: 2957 > # PASS: 2789 > # SKIP: 120 > # XFAIL: 39 > # FAIL: 9 > # XPASS: 0 > # ERROR: 0
(In reply to Thomas Deutschmann from comment #1) ... > > > It work here. > Can you prove that please? I removed Python 3 support by intention because > the test suite is failing for me with Python 3 (and please note that > upstream doesn't officially support Python 3). See the following fallout > with Python 3.6 and automake-1.16-r1 for example (these tests are passing > with Python 2.7): Confirmed, if python3 is used the tests will fail. But at this point I'd say that python support in automake should depend on a USE flag or be fixed. There is a very important point to make: If python3.x is the default python installation it will be used at runtime. So basically forcing python2 is only _masking_ failures that will appear later. Notice also that the tools seem to work with python3, correctly handling most cases (all?) > > FAIL: t/nobase-python.sh This test work until it call make clean, it leave behind inst/my/sub/__pycache__/nobase.cpython-36.py{c,o} This is strange because "Uninstalling." section in am/python.am seem to take care using this: ?FIRST?am__pep3147_tweak = \ ?FIRST? sed -e 's|\.py$$||' -e 's|[^/]*$$|&.*.pyc\n&.*.pyo|' which tested on command line give correct results. the "Cleaning." section in the same file is debatable since it should take care of __pycache__ directory, instead it state: ## There is nothing to clean here since files are ## byte-compiled when (and where) they are installed. > > FAIL: t/py-compile-basic.sh > > FAIL: t/py-compile-basedir.sh > > FAIL: t/py-compile-destdir.sh > > FAIL: t/py-compile-option-terminate.sh > > FAIL: t/python3.sh > > FAIL: t/python10.sh > > FAIL: t/python12.sh > > FAIL: t/python-virtualenv.sh Many of these seem to fail with 3.6 because PEP 488 -- Elimination of PYO files
(In reply to Francesco Riosa from comment #2) > Confirmed, if python3 is used the tests will fail. But at this point I'd say > that python support in automake should depend on a USE flag or be fixed. No... it sounds like you don't understand the purpose of PYTHON_COMPAT. To quote documentation: > PYTHON_COMPAT (REQUIRED) > This variable contains a list of Python implementations the package supports. [...] > There is a very important point to make: > If python3.x is the default python installation it will be used at runtime. > So basically forcing python2 is only _masking_ failures that will appear > later. No?! Please read about python-any-r1 eclass. Your PM has to ensure that before it starts building of sys-devel/automake, that *one* Python version listed in PYTHON_COMPAT is installed. "python_setup" function in src_test will then ensure that *one* version listed in PYTHON_COMPAT is active for this phase. In other words: The PM/ebuild ensures that tests are being called using Python 2.7, even if you system's default Python is normally set to Python 3.x. > Notice also that the tools seem to work with python3, correctly handling > most cases (all?) Sorry, I am not going into your analysis at this point. The point is, that automake project doesn't support Python 3. That's what our PYTHON_COMPAT reflects. Feel free to contribute Python 3 patches to automake project (see https://www.gnu.org/software/automake/#TOCmailinglists). But until automake test suite gained Python 3 support we won't add any Python 3 version to PYTHON_COMPAT because this would be wrong. I am closing this bug as INVALID for now. Feel free to keep commenting if you think I am wrong. I'll be notified and read your comment.
But Automake is used to build other packages and it WILL use whatever python version it found in /usr/bin/python. This has nothing to do with python-any-r1 eclass or automake build time but for any _other_ package build time please consider removing the INVALID status
or skip the tests, they are not relevant, to reinforce what I've said look at installed usr/share/automake-1.16/py-compile it uses has this: if [ -z "$PYTHON" ]; then PYTHON=python fi tests here have passed but If I call it it return this: # python --version Python 3.6.4
No, you don't understand: It is only automake's own test suite which depends on Python 2.7. The ability to build other packages which depend or use Python 3 are not affected by this. Please read about src_test and FEATURES=test. Looks like you don't understand what this is doing. If you don't want to test automake _before_ merging on your system, don't enable FEATURES=test for this package. Nitpicking: Closing as INVALID because you requested to mark this package compatible with Python 3.x but the package isn't compatible. Therefore your request is invalid. :)
yes, I've missed this DEPEND="${RDEPEND} sys-apps/help2man test? ( ${PYTHON_DEPS} )" in detail the dependancy from "test" use flag
(In reply to Francesco Riosa from https://archives.gentoo.org/gentoo-dev/message/d08aff26b757c0f14144618532410d2c) > Result is that with no python:2.7 installed ebuild will fail, always > both with test enabled or disabled. Why haven't you said this here?! You were only complaining that test suite didn't use Python 3 but you never said that your problem was actually that the ebuild was always requiring Python even if FEATURES=-test is set. Incoming fixes.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cfaa5ec192519a74951fd57f05c483984e408e4b commit cfaa5ec192519a74951fd57f05c483984e408e4b Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2018-03-01 01:01:22 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2018-03-01 01:02:07 +0000 sys-devel/automake: Rev bump to remove Python 2.7 dependency for FEATURES=-test Reported-by: Francesco Riosa <vivo75@gmail.com> Closes: https://bugs.gentoo.org/648940 Package-Manager: Portage-2.3.24, Repoman-2.3.6 .../{automake-1.10.3-r3.ebuild => automake-1.10.3-r4.ebuild} | 10 ++++------ .../{automake-1.11.6-r3.ebuild => automake-1.11.6-r4.ebuild} | 6 ++++-- .../{automake-1.12.6-r2.ebuild => automake-1.12.6-r3.ebuild} | 10 ++++------ .../{automake-1.13.4-r2.ebuild => automake-1.13.4-r3.ebuild} | 10 ++++------ .../{automake-1.14.1-r2.ebuild => automake-1.14.1-r3.ebuild} | 10 ++++------ .../{automake-1.15.1-r2.ebuild => automake-1.15.1-r3.ebuild} | 10 ++++------ .../{automake-1.16-r1.ebuild => automake-1.16-r2.ebuild} | 10 ++++------ .../{automake-1.9.6-r5.ebuild => automake-1.9.6-r6.ebuild} | 10 ++++------ sys-devel/automake/automake-9999.ebuild | 10 ++++------ 9 files changed, 36 insertions(+), 50 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d8f87d7389569af3520b9ca2dfc68e7a82059ccf commit d8f87d7389569af3520b9ca2dfc68e7a82059ccf Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2018-03-01 01:31:30 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2018-03-01 01:31:30 +0000 sys-devel/automake: Provide pkg_setup to call python_setup only when FEATURES=test is set Previous attempt cfaa5ec192519a74951fd57f05c483984e408e4b was reverted in commit cd0e6915f3f7a02915bc7029026bfe2f53dc7f68 to avoid unnecessary mass rebuild for "--changed-deps=y" users which was possible because dependencies were fine. Package was only failing at build time in pkg_setup when Python 2.7 wasn't available because eclass exports pkg_setup. Bug: https://bugs.gentoo.org/648940 Package-Manager: Portage-2.3.24, Repoman-2.3.6 sys-devel/automake/automake-1.10.3-r3.ebuild | 10 ++++------ sys-devel/automake/automake-1.11.6-r3.ebuild | 6 ++++-- sys-devel/automake/automake-1.12.6-r2.ebuild | 10 ++++------ sys-devel/automake/automake-1.13.4-r2.ebuild | 10 ++++------ sys-devel/automake/automake-1.14.1-r2.ebuild | 10 ++++------ sys-devel/automake/automake-1.15.1-r2.ebuild | 10 ++++------ sys-devel/automake/automake-1.16-r1.ebuild | 10 ++++------ sys-devel/automake/automake-1.9.6-r5.ebuild | 10 ++++------ sys-devel/automake/automake-9999.ebuild | 10 ++++------ 9 files changed, 36 insertions(+), 50 deletions(-)}
This fix an emerge failure when bootstraping prefix systems where no python installed before automake emerged.
