The updated python-2.6.2-r1.ebuild (cvs revision 1.6) contained several changes that were not documented in the ChangeLog. These changes result in USE="build" build failures of python. The changes that cause this issue are found here: http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-lang/python/python-2.6.2-r1.ebuild?r1=1.5&r2=1.6 This results in Metro build failures, and will likely result in catalyst build failures as well. I will be attaching a build log in the next few minutes. Reproducible: Always Steps to Reproduce: ROOT=/tmp/foo USE="-* build" emerge --nodeps python ^^ CVS revision 1.6 consistently fails. CVS revision 1.5 consistently works. This appears to be independent of arch or other installed packages.
Created attachment 201907 [details] typescript of build failure
assigning to maintainers
(In reply to comment #0) > The updated python-2.6.2-r1.ebuild (cvs revision 1.6) contained several > changes that were not documented in the ChangeLog. These trivial changes didn't cause your problem.
FYI: autobuild stages have succeeded in the time since Jul 30, when it was marked stable for amd64. This is a non-issue for catalyst.
Please post the output of `emerge --info`. Please attach build log with -j1. (Your problem is a minor side effect of fix for bug #281968.)
At a glance (but can't confirm without a -j1 log), we need to disable the elementree and multiprocessing extensions when USE=build is active. Adding myself, since I was the one that asked for Python to explicitly error out when an extension failed to build (before it was just not installed).
(In reply to comment #3) > (In reply to comment #0) > > The updated python-2.6.2-r1.ebuild (cvs revision 1.6) contained several > > changes that were not documented in the ChangeLog. > > These trivial changes didn't cause your problem. Yes they did. I tested and they indeed caused the problem. Using the "Steps to reproduce," you should be able to generate a build failure just like I did.
(In reply to comment #5) > Please post the output of `emerge --info`. > Please attach build log with -j1. > > (Your problem is a minor side effect of fix for bug #281968.) You should be able to easily generate this log by using the "Steps to reproduce" that I posted in the original report. Are you able to reproduce this bug? I can do so consistently using the steps I posted.
(In reply to comment #7 and comment #8) Installing dev-lang/python with --nodeps option isn't supported. If you are able to reproduce this bug without --nodeps option and with all build-time dependencies of dev-lang/python installed, then please attach build log with -j1.
Arfrever, all build time deps are already satisfied if you have merged python-2.6.2-r1 to /, which I assume you have. So you should be able to replicate it using the command I provided -- all build deps should already be satisfied. Remember when ROOT!=/, that this affects where the built files are merged to, but all build deps get installed to /. Regards, Daniel
Also note that I am not trying to be difficult, a key first step in resolving this bug is for you to test whether you can replicate it. Please post information as to whether you are able to replicate this bug. Thanks! :)
I can reproduce it fine with this: # ROOT=/tmp/buildroot USE="-* build" MAKEOPTS='-j1' emerge --nodeps =python-2.6* elementtree requires expat, which is disabled with USE=build. Ergo elementtree should be disabled for that configuration as well: *** WARNING: renaming "_elementtree" since importing it failed: No module named pyexpat multiprocessing is more interesting: In file included from /dev/shm/portage/dev-lang/python-2.6.2-r1/work/Python-2.6.2/Modules/_multiprocessing/socket_connection.c:202: /dev/shm/portage/dev-lang/python-2.6.2-r1/work/Python-2.6.2/Modules/_multiprocessing/connection.h: In function 'connection_poll': /dev/shm/portage/dev-lang/python-2.6.2-r1/work/Python-2.6.2/Modules/_multiprocessing/connection.h:357: error: '_save' undeclared (first use in this function) /dev/shm/portage/dev-lang/python-2.6.2-r1/work/Python-2.6.2/Modules/_multiprocessing/connection.h:357: error: (Each undeclared identifier is reported only once /dev/shm/portage/dev-lang/python-2.6.2-r1/work/Python-2.6.2/Modules/_multiprocessing/connection.h:357: error: for each function it appears in.) The function definition takes 3 arguments: Python-2.6.2/Modules/_multiprocessing/socket_connection.c:conn_poll(ConnectionObject *conn, double timeout, PyThreadState *_save) So the actual call to it is missing defining _save.
*** Bug 282522 has been marked as a duplicate of this bug. ***
Arferver/drobbins: Bug 282518 has the patch from upstream Python for the multiprocessing compile failure. It was just latent in Gentoo, our build changes simply exposed it.
This bug will be used only for problem related to pyexpat/_elementtree.
Fixed. (In reply to comment #7) Additional analysis has confirmed that eventual build failure was caused exclusively by the following changes: https://overlays.gentoo.org/proj/python/changeset/208 https://overlays.gentoo.org/proj/python/browser/patches/2.6.2/16_all_non-zero_exit_status_on_failure.patch?rev=208 http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-lang/python/python-2.6.2-r1.ebuild?r1=1.6&r2=1.7
Thanks very much for looking into this, Arfrever. I forgot that the patchset got bumped on the 1.6->1.7 commit. -Daniel
*** Bug 282699 has been marked as a duplicate of this bug. ***
