Created attachment 273225 [details, diff] pycairo-1.10.0-waf-multilib.patch Checking for program python-config-2.6 : /usr/bin/python-config-2.6 command ['/usr/bin/python', '/usr/bin/python-config-2.6', '--includes'] returned 1 * ERROR: dev-python/pycairo-1.10.0-r1 failed (configure phase): * configure failed waflib thinks that python-config should be a python script. On portage-multilib systems, python-config actually points to abi-wrapper which is a POSIX shell script. This wrapper in turn invokes python-config-${ABI} (or in this case python-config-2.6-${ABI}) such as python-config-2.6-amd64. I have filed a bug and the patch which fixes the problem upstream, see URL. It would be nice if this could be patched in pycairo-1.10.0-r* to support portage-multilib users. I have attached the patch to waflib which must be applied in the manner described in bug 367291 and will attach an ebuild patch which assumes that bug 367291 is fixed.
Created attachment 273227 [details] build.log
Created attachment 273229 [details] emerge --info
pycairo uses build system from: http://code.google.com/p/waf/ You need to send the patch to upstream.
*** Bug 378989 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > pycairo uses build system from: > http://code.google.com/p/waf/ > > You need to send the patch to upstream. http://code.google.com/p/waf/issues/detail?id=951#c3 . It has been upstream for a while, but the version of waflib embedded into pycairo-1.10.0 still breaks on portage-multilib because we can't patch waflib until bug #367291 is fixed. Thus, even though there's no possible current fix for this bug, it's still a bug. A hacky stopgap measure has been committed to http://git.overlays.gentoo.org/gitweb/?p=proj/multilib-portage.git;a=commitdiff;h=16e3674d231ae99cf389246384659f28c0b19b21 for portage-multilib users in the meantime.
*** Bug 414445 has been marked as a duplicate of this bug. ***
Is there some development? pycairo-1.10* does _still_ not compile with amd64 and portage-multilib despite this fact -r2 and -r4 are stable for amd64.
I can confirm that it is still the same situation. It is actually a little weirder because you can either emerge with python3.2 if python3.2 is selected with eselect or you can emerge with python2.7 if python2.7 was selected by eselect.
(In reply to salamanderrake from comment #8) > I can confirm that it is still the same situation. It is actually a little > weirder because you can either emerge with python3.2 if python3.2 is > selected with eselect or you can emerge with python2.7 if python2.7 was > selected by eselect. Indeed, I was able to finally 'emerge pycairo' by first doing: emerge python:3.2 eselect python set [number corresponding to python 3.2 from 'eselect python list']