Created attachment 331208 [details] pykde4-9.4.3 Build-log As it says, pykde4 fails to build. As there seem to be others running into this too, it might be a bug. I have the build.log attached to this report. If you need other information, I will supply it as soon I know what is needed
Created attachment 331210 [details] Emerge info Emerge info from my build that also fails with the same problem.
I have the same problem. I have tried rebuilding sip, PyQt4 and python both 2.7 and 3.2. eselect python shows both 2.7 and 3.2 with 2.7 being set as default.
are you sure your python stuff is ok? Try if it fix: emerge -1q python:2.7 python:3.2 python-updater emerge -1 pykde4
Tried your suggestion but no change. I can't seem to attach files any more but my build.log is is different than reporters as he seems to be using python 2.6 and 3.2 which is a bit odd. Looking through my log it looks like it is mixing in support for both 2.7 and 3.2 as there are a number of places where it does a configuration and detects either CPython 2.7 or CPython 3.2. If I change the ebuild to only consider 3.2 then everything builds ok. I will try to add the log in a separate message.
Created attachment 331220 [details] Build.log
Created attachment 331222 [details] emerge --info I have exactly the same problem and the exactly same error as in comment 5. I tried the procedure form comment 3, no change. I also updated to python 3.2.3-r1, did python-update and recompiled everything that has to do with python ("equery list *python*"), no change. I have to mention, that the system is a complete new system, the packages were taken over from another system (emerge were done with emerge -k), so it can't be something that an old package left on the file system. Find my attached emerge --info. I did not post the error log, because it is the same as in comment 5.
I had 2.6, 2.7 and 3.2 installed, using 2.6 as default. I have made 2.7 default and run python-updater right now. I will see if this makes a difference as soon as it has bee finished. The notebook is not the fastest under the sun.
Please change name of this bug to "kde-base/pykde4-4.9.3 ..." ;-)
Created attachment 331230 [details] emerge --info Here's my emerge --info. After making python 2.7 default
making python 2.7 default and running python-updater didn't make a difference
@original report: There might be a chance, that either pykde4 4.9.3 or dev-python/sip version it's using no longer supports python 2.6 - PyCapsule was new in python 2.7 (and python 3.1). @comment 2: completely different matter; might be a bug in the ebuild: it seems that sip generates code for python 3, while building for python 2. I.e.: /usr/bin/sip -t ALL -t WS_X11 -t Qt_4_8_0 -x VendorID -x PyQt_NoPrintRangeBug -g -x Py_v3 -j 8 -c /var/tmp/portage/kde-base/pykde4-4.9.3/work/pykde4-4.9.3_build-2.7/sip/khtml -I /usr/share/sip -I /var/tmp/portage/kde-base/pykde4-4.9.3/work/pykde4-4.9.3/sip /var/tmp/portage/kde-base/pykde4-4.9.3/work/pykde4-4.9.3/sip/khtml/khtmlmod.sip
Created attachment 331252 [details, diff] Change CMAKE_BUILD_DIR to BUILD_DIR I ran into this also today. From the build log one can notice, that during the configuration something unexpected happens. In the beginning of the configuration phase for python 2.7 this comes out: * Configuration of kde-base/pykde4-4.9.3 with CPython 2.7... >>> Working in BUILD_DIR: "/var/tmp/portage/kde-base/pykde4-4.9.3/work/pykde4-4.9.3_build-2.7" And then in the configuration for python 3.2 this: * Configuration of kde-base/pykde4-4.9.3 with CPython 3.2... >>> Working in BUILD_DIR: "/var/tmp/portage/kde-base/pykde4-4.9.3/work/pykde4-4.9.3_build-2.7" So the same BUILD_DIR for both. I also figured the probable cause being the change made to cmake-utils.eclass yesterday: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/cmake-utils.eclass?r1=1.85&r2=1.86 That caused the same folder to be used in both because the BUILD_DIR is read from the CMAKE_BUILD_DIR variable only if the BUILD_DIR variable isn't set. And it gets set after the configuration of python 2.7 and then it is not changed on the next run. The easy fix to the ebuild was to change the CMAKE_BUILD_DIR variable in configure and compile phases to BUILD_DIR as is done in the attached patch. However, this change in the eclass will probably affect other packages also.
Using the patch works for me. Thank you very much.
cmake-utils.eclass needs to be fixed to respect CMAKE_BUILD_DIR. Ebuilds of at least 10 packages set CMAKE_BUILD_DIR and call cmake-utils_*() functions multiple times per ebuild phase.
@mgorny: Please have a look.
(In reply to comment #12) > Created attachment 331252 [details, diff] [details, diff] > Change CMAKE_BUILD_DIR to BUILD_DIR That fixed it for me. I committed it in cvs before I saw comment #14.
These are all ebuilds in the tree which support multiple python abis and specify CMAKE_BUILD_DIR. I suspect all of these to be broken currently caused by the latest change to cmake-utils.eclass. I only tested pyside-1.1.2 of these and that was also broken. $ grep -l "SUPPORT_PYTHON_ABIS" $(grep -l "CMAKE_BUILD_DIR" /usr/portage/*/*/*.ebuild) /usr/portage/app-pda/libopensync/libopensync-0.36-r2.ebuild /usr/portage/app-pda/libopensync/libopensync-0.39-r1.ebuild /usr/portage/app-pda/libopensync/libopensync-9999.ebuild /usr/portage/dev-lang/gdl/gdl-0.9.2-r2.ebuild /usr/portage/dev-python/pyside/pyside-1.1.1.ebuild /usr/portage/dev-python/pyside/pyside-1.1.2.ebuild /usr/portage/dev-python/shiboken/shiboken-1.1.1.ebuild /usr/portage/dev-python/shiboken/shiboken-1.1.2.ebuild /usr/portage/kde-base/pykde4/pykde4-4.8.5.ebuild /usr/portage/kde-base/pykde4/pykde4-4.9.3.ebuild /usr/portage/media-libs/portmidi/portmidi-217.ebuild The cause in the _check_build_dir function in cmake-utils.eclass and specifically line 171 which is used when doing out of tree build to determine the build dir: : ${BUILD_DIR:=${CMAKE_BUILD_DIR:-${WORKDIR}/${P}_build}} On the first python implementation it sets the BUILD_DIR variable from the CMAKE_BUILD_DIR variable set in the ebuild. But on the second python implementation the BUILD_DIR variable is already set and the new path in CMAKE_BUILD_DIR is ignored. The previous version of cmake-utils.eclass always honored the CMAKE_BUILD_DIR variable.
(In reply to comment #17) Some packages set CMAKE_BUILD_DIR for reasons unrelated to Python. Examples: dev-games/mygui, dev-libs/libdbusmenu-qt, x11-misc/virtualgl
(In reply to comment #18) > (In reply to comment #17) > > Some packages set CMAKE_BUILD_DIR for reasons unrelated to Python. > Examples: dev-games/mygui, dev-libs/libdbusmenu-qt, x11-misc/virtualgl Ebuild needs to set the CMAKE_BUILD_DIR at least twice for this error to happen. If only one value of CMAKE_BUILD_DIR is used in ebuild it works fine. That was the reason I only searched for those ebuilds which support multiple python versions and use cmake as it was an easy check that this pykde4 is not the only one misbehaving. And those packages you posted also set CMAKE_BUILD_DIR to more than one value and are therefore also broken.
I've fixed the compatibility code in eclass and the issue should not happen anymore.
It works. Thank you. :-)
pykde4 is compiling right now. Seems to work. Thank you!
Works for me. Thanks.
