This error just randomly started happening on or about April 6th. * Messages for package dev-python/setuptools-0.6.30-r1: * No Python implementation selected for the build. Please add one * of the following values to your PYTHON_TARGETS (in make.conf): * * python2_5 python2_6 python2_7 python3_1 python3_2 * ERROR: dev-python/setuptools-0.6.30-r1 failed (prepare phase): * No supported Python implementation in PYTHON_TARGETS. * * Call stack: * ebuild.sh, line 93: Called src_prepare * environment, line 3293: Called distutils-r1_src_prepare * environment, line 903: Called python_prepare_all * environment, line 3154: Called distutils-r1_python_prepare_all * environment, line 839: Called python_copy_sources * environment, line 2782: Called _python_obtain_impls * environment, line 560: Called _python_validate_useflags * environment, line 655: Called die * The specific snippet of code: * die "No supported Python implementation in PYTHON_TARGETS."
My section of the bug report is based on a custom profile which inherits from the hardened gentoo profile. Initially I thought that this issue was potentially my fault (or a member of my team), however, jmbsvicetto (in cc) says he is getting the same error (although on a different package) so I believe this is a gentoo issue. My last successful build appears to have occurred on : dev-python/setuptools-0.6.30-r1:20130406-214532
Here is a quick paste from jmbsvicetto's log. More when he comes around: >>> '/var/tmp/portage/dev-python/pyxattr-0.5.2/temp/build.log' * Package: dev-python/pyxattr-0.5.2 * Repository: gentoo * Maintainer: robbat2@gentoo.org python@gentoo.org * USE: amd64 elibc_glibc kernel_linux userland_GNU * FEATURES: sandbox * No Python implementation selected for the build. Please add one * of the following values to your PYTHON_TARGETS (in make.conf): * * python2_5 python2_6 python2_7 python3_1 python3_2 pypy1_9 pypy2_0 * ERROR: dev-python/pyxattr-0.5.2 failed (compile phase): * No supported Python implementation in PYTHON_TARGETS. * * Call stack: * ebuild.sh, line 93: Called src_compile * environment, line 3334: Called distutils-r1_src_compile * environment, line 928: Called _distutils-r1_run_foreach_impl 'distutils-r1_python_compile' * environment, line 258: Called python_parallel_foreach_impl 'distutils-r1_run_phase' 'distutils-r1_python_compile' * environment, line 3201: Called _python_obtain_impls * environment, line 618: Called _python_validate_useflags * environment, line 713: Called die * The specific snippet of code: * die "No supported Python implementation in PYTHON_TARGETS."
I went to add an emerge --info to catalyst and I found this: # Now, we install our packages [ -e /etc/portage/make.conf ] && \ echo "USE=\"-* build ${BOOTSTRAP_USE} ${clst_HOSTUSE}\"" \ >> /etc/portage/make.conf run_merge "--oneshot ${clst_buildpkgs}" sed -i "/USE=\"-* build ${BOOTSTRAP_USE} ${clst_HOSTUSE}\"/d" \ /etc/portage/make.conf This is part of the stage1 build for eternity, perhaps someone recently changed how PYTHON_TARGETS was defined and moved it under use?
Created attachment 345028 [details] emerge --info
I believe this problem was introduced by this change in profiles/hardened/linux/package.use.force: revision 1.2 date: 2013-03-17 23:18:19 -0400; author: blueness; state: Exp; lines: +6 -2; commitid: 11d85146877a4567; Force USE=xattr on sys-apps/portage for hardened for XATTR_PAX marking This pulls in pyxattr, which pulls in setuptools, both of which utilize distutils-r1. PYTHON_TARGETS or the equivalent use flags must be set for distutils-r1.eclass to function.
In any case, this is not something the python team can fix.
Thanks to floppym for providing a sane solution. Hence forth BOOTSTRAP_USE and PYTHON_TARGETS will need to be kept in sync, however, it seems the sanest of possible solutions. Index: make.defaults =================================================================== RCS file: /var/cvsroot/gentoo-x86/profiles/base/make.defaults,v retrieving revision 1.93 diff -u -r1.93 make.defaults --- make.defaults 23 Mar 2013 10:23:25 -0000 1.93 +++ make.defaults 10 Apr 2013 03:03:11 -0000 @@ -122,7 +122,9 @@ # Jorge Manuel B. S. Vicetto <jmbsvicetto@gentoo.org> (16 Nov 2011) # Add default USE value for bootstrap and rename it from STAGE1_USE to BOOTSTRAP_USE -BOOTSTRAP_USE="cxx unicode" +# Add in expanded PYTHON_TARGETS or stage1 builds break because of USE="-* ${BOOTSTRAP_USE}" +# This MUST be kept in sync with the PYTHON_TARGETS below +BOOTSTRAP_USE="cxx unicode python_targets_python3_2 python_targets_python2_7" # Mike Gilbert <floppym@gentoo.org> (15 May 2012) # Default target(s) for python-r1.eclass
I'd just like to tell 'haven't i told you so' to all the people which forced removing REQUIRED_USE because 'stage1 does not want python'...
(In reply to comment #8) > I'd just like to tell 'haven't i told you so' to all the people which forced > removing REQUIRED_USE because 'stage1 does not want python'... /me tosses a high five to mgorny Yeah, honestly though the error message wouldn't have been any more useful though. Now we know what we are looking for, and that's a good thing. I don't think it will be too hard to keep this in sync honestly, but if you come up with a way for the PYTHON_TARGETS to automatically end up in BOOTSTRAP_USE I'm all ears :-)
(In reply to comment #8) > I'd just like to tell 'haven't i told you so' to all the people which forced > removing REQUIRED_USE because 'stage1 does not want python'... Don't be too smug about it; it is still technically incorrect to enforce that for packages with *optional* python support. I'll work on bug 459178 later this week.
