[ 4%] Built target compile_python_files [ 5%] Generating sip/kio/sipkiopart0.cpp, sip/kio/sipkiopart1.cpp, sip/kio/sipkiopart2.cpp, sip/kio/sipkiopart3.cpp, sip/kio/sipkiopart4.cpp, sip/kio/sipkiopart5.cpp, sip/kio/sipkiopart6.cpp, sip/kio/sipkiopart7.cpp sip: /var/tmp/portage/kde-base/pykde4-4.5.4/work/pykde4-4.5.4/python/pykde4/sip/kdecore/typedefs.sip:587: %MappedType template for this type has already been defined make[2]: *** [python/pykde4/sip/kdecore/sipkdecorepart0.cpp] Error 1 make[1]: *** [python/pykde4/CMakeFiles/python_module_PyKDE4_kdecore.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs.... sip: /var/tmp/portage/kde-base/pykde4-4.5.4/work/pykde4-4.5.4/python/pykde4/sip/kdecore/typedefs.sip:587: %MappedType template for this type has already been defined make[2]: *** [python/pykde4/sip/khtml/sipkhtmlpart0.cpp] Error 1 make[1]: *** [python/pykde4/CMakeFiles/python_module_PyKDE4_khtml.dir/all] Error 2 sip: /var/tmp/portage/kde-base/pykde4-4.5.4/work/pykde4-4.5.4/python/pykde4/sip/kdecore/typedefs.sip:587: %MappedType template for this type has already been defined make[2]: *** [python/pykde4/sip/kio/sipkiopart0.cpp] Error 1 make[1]: *** [python/pykde4/CMakeFiles/python_module_PyKDE4_kio.dir/all] Error 2 sip: /var/tmp/portage/kde-base/pykde4-4.5.4/work/pykde4-4.5.4/python/pykde4/sip/kdecore/typedefs.sip:587: %MappedType template for this type has already been defined make[2]: *** [python/pykde4/sip/dnssd/sipdnssdpart0.cpp] Error 1 make[1]: *** [python/pykde4/CMakeFiles/python_module_PyKDE4_dnssd.dir/all] Error 2 sip: /var/tmp/portage/kde-base/pykde4-4.5.4/work/pykde4-4.5.4/python/pykde4/sip/kdecore/typedefs.sip:587: %MappedType template for this type has already been defined make[2]: *** [python/pykde4/sip/kdeui/sipkdeuipart0.cpp] Error 1 make[1]: *** [python/pykde4/CMakeFiles/python_module_PyKDE4_kdeui.dir/all] Error 2
It looks awfully like bug 332503
Created attachment 258051 [details] build log
Created attachment 258053 [details] emerge --info
Building fails with =dev-python/sip-4.12, but works fine with =dev-python/sip-4.11.2.
Created attachment 258068 [details, diff] Makes pykde4-4.5.4 build I managed to get it building with this patch
(In reply to comment #5) > Created an attachment (id=258068) [details] > Makes pykde4-4.5.4 build > > I managed to get it building with this patch > Seems that this patch fixes this.
(In reply to comment #5) > Created an attachment (id=258068) [details] > Makes pykde4-4.5.4 build > > I managed to get it building with this patch > No result for me. Same error.
(In reply to comment #7) > (In reply to comment #5) > > Created an attachment (id=258068) [details] [details] > > Makes pykde4-4.5.4 build > > > > I managed to get it building with this patch > > > > No result for me. Same error. > In addition to adding the patch to the /usr/portage/kde-base/pykde4/files sub-directory, did you update the ebuild? /usr/portage/kde-base/pykde4/pykde4-4.5.4.ebuild needs to look like this: PATCHES=( "${FILESDIR}/${PN}-mapped-type-fix.patch" "${FILESDIR}/${PN}-typedefs-fix.patch" ) {all on one line} or equivalent. You then need to run: # ebuild /usr/portage/kde-base/pykde4-4.5.4.ebuild manifest # emerge pykde4 Patch has worked fine for me for 3 systems now.
*** Bug 349821 has been marked as a duplicate of this bug. ***
(In reply to comment #8) > Patch has worked fine for me for 3 systems now. The patch worked fine for me too.
(In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #5) > > > > > > I managed to get it building with this patch > > > > No result for me. Same error. > > In addition to adding the patch to the /usr/portage/kde-base/pykde4/files > sub-directory, did you update the ebuild? Easy Patching Hint: FWIW, I don't know exactly when this VERY USEFUL new portage feature was introduced, but all latest current versions (2.2/sets, 2.1.9.26 ~arch and 2.1.9.25 stable, at least) of portage appear to have this feature now.... Instead of worrying about updating the ebuild when you have "user" patches to apply like this one, in /most/ cases, you can simply drop the patch as a file in /etc/portage/patches/cat-egory/package(-version-optional)/*.patch and portage will automatically try to apply it for you. =:^) So for this one, I dropped the patch in: /etc/portage/patches/kde-base/pykde4-4.5.4/pykde4-typedefs-fix.patch Point: Make sure permissions on the directory chain are readable by the portage user (and for security reasons, probably owned and only writable by root, you don't want arbitrary users being able to apply whatever patches they want). Point: The package dir version number is optional. In this case, I decided the patch isn't likely to be needed (from my side) for more than a single version, so I used the version number in the patches dir, so it won't apply to the next one automatically. If it's your own patch to package functionality, you might want to omit the version, so it automatically applies whenever the package upgrades. I did that with one (kde3) package for awhile. Point: The name of the patch file itself was the same one it has in bugzilla. I saw no reason to change it, but I did change ownership (from the user I had downloaded it as) and permissions as appropriate. Here's what that the prepare phase of the the package build look like when it finds a user patch in /etc/portage/patches/* to apply (using this package and patch as an example): >>> Preparing source in /tmp/portage/kde-base/pykde4-4.5.4/work/pykde4-4.5.4 ... * Applying pykde4-mapped-type-fix.patch ... [ ok ] * Applying user patches from /etc/portage/patches//kde-base/pykde4-4.5.4 ... * pykde4-typedefs-fix.patch ... [ ok ] * Done with patching >>> Source prepared. Note the "applying user patches"... bit and that it's NOT just the usual ebuild listed patches applied! That's the new feature. =:^) Just drop that patch in the appropriate /etc/portage/patches/ subdir, change the ownership and permissions appropriately from what you happen to download the patch-file as, and re-emerge the package. As you can see, once it's in the proper location, portage automatically detects it and applies it for you. =:^) In MOST cases, that eliminates any need to copy the ebuild to an overlay, add the line applying the patch, and then re-digest the ebuild, since portage handles it all automatically now, without even changing the ebuild. All you have to do is have the patch in the right place and readable. =:^) Occasionally you might come across a complex case where the automatic method doesn't work and you have to do the ebuild-edit-and-redigest thing, but that doesn't happen very often. (I've been using an earlier version of this for years now, even using it when I was applying patches to help packages build with a still-masked gcc version, as I usually unmask those well ahead of when they hit ~arch, and have only had the automatic handling fail on me a couple of times.) As I said, even latest stable portage (well, I didn't test the old versions for the lagging archs, but 2.1.9.25 has it, anyway) has this feature now. My overlay gets WAY less use that it did before this feature, for sure, and where the only reason you're using the overlay is to apply a patch like the one attached to this bug, yours probably won't get as much use now either. =:^) Duncan
(In reply to comment #11) > (In reply to comment #8) > > (In reply to comment #7) > > > (In reply to comment #5) > > > > > > > > I managed to get it building with this patch > > > > > > No result for me. Same error. > > > > In addition to adding the patch to the /usr/portage/kde-base/pykde4/files > > sub-directory, did you update the ebuild? > > Easy Patching Hint: Thanks. Really good way to apply patches.
(In reply to comment #12) > (In reply to comment #11) > > (In reply to comment #8) > > > (In reply to comment #7) > > > > (In reply to comment #5) > > > > > > > > > > I managed to get it building with this patch > > > > > > > > No result for me. Same error. > > > > > > In addition to adding the patch to the /usr/portage/kde-base/pykde4/files > > > sub-directory, did you update the ebuild? > > > > Easy Patching Hint: > > Thanks. Really good way to apply patches. > Thanks as well. I had only one small issue. The patch file have to have the ".patch" suffix. I tried different patch with ".diff" suffix and it was ignored.
thanks for the patch, I emailed upstream about it. Also I applied it in pykde4 4.5.90, will do it for 4.5.4 tomorrow I want to test if it breaks sip 4.11 first
I contacted upstream, they said they will raise deps (at least for 4.5.90). I'm waiting for 4.5.5 tagging which will happen tomorrow and act accordingly
patch works for me too, amd64
kde-base/pykde4-4.5.4 failed to build for me on my ~86 laptop. Installed above patch as instructed in comment #11 into /etc/portage/patches/kde-base/pykde4/ then emerged with no problems. Devs is there some way this patch can get added to portage? TIA
Patch applied here just fine. I couldn't emerge pykde4-4.5.4 without it on my ~x86 laptop.
Thanks Duncan, for the very useful hint, this is really a great portage feature! And thank you Allesandro for the patch which works for me, too (x86).
Created attachment 258914 [details] the result of the attemp to patch on my x86_64 as you can see the patch failed on my machine and this's the result. My version of sip is 4.12 if this makes any diff(HIHIHI)
Patch works for me on ~amd64 when placed under /etc/portage/patches/kde-base/pykde4-4.5.4/pykde4-typedefs-fix.patch
Can those of you who the patch works for and those it doesn't work for, please list the PyQt4 and sip packages you used when you built pykde4? Thanks. At this point, I think the patch is working for those using PyQt4-4.7.7-r1 and failing for those with PyQt4-4.8*. I don't know if sip matters or not.
$ emerge -pv PyQt4 sip These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] dev-python/sip-4.12 [4.11.2] USE="-debug -doc" 691 kB [ebuild U ] dev-python/PyQt4-4.8.2 [4.8.1] USE="X dbus opengl svg -assistant -debug -declarative -doc -examples -kde -multimedia -phonon -sql -webkit -xmlpatterns" 9,380 kB Patch worked.
Calculating dependencies ... done! [ebuild R ] dev-python/sip-4.12 USE="-debug -doc" 691 kB [ebuild R ] dev-python/PyQt4-4.8.2 USE="X dbus kde multimedia opengl phonon sql svg webkit -assistant -debug -declarative -doc -examples -xmlpatterns" 9,380 kB Patch worked.
dev-python/sip-4.12 was built with the following: USE="-debug -doc" dev-python/PyQt4-4.8.2 was built with the following: USE="X dbus kde opengl sql svg webkit -assistant -debug -declarative -doc -examples -multimedia -phonon -xmlpatterns" Patch also worked.
Another one in the working corner here. sip-4.12 PyQt4-4.8.2
Patch also works here. kde-base/pykde4-4.5.4 dev-python/sip-4.12 Real cool about the patch trick, I would have never known. Beats the heck out of creating a custom ebuild.
Adding the patch under /etc/portage worked for me too, with qlist -ICv 'pykde4|sip' dev-python/sip-4.12 kde-base/pykde4-4.5.4
Whoops, and: dev-python/PyQt4-4.8.2
Patch worked for me; kde-base/pykde4-4.5.4 built successfully.
Patch worked fine here on ~amd64; pykde4-4.5.4.ebuild
Created attachment 259333 [details, diff] updated patch for pykde4-4.5.5 This is still a problem in kde-base/pykde4-4.5.5. The patch now needs to remove another typedef. Attached patch makes it build. $ emerge -qpv sip PyQt4 [ebuild R ] dev-python/sip-4.12 USE="-debug -doc" [ebuild R ] dev-python/PyQt4-4.8.2 USE="X dbus kde opengl phonon sql svg webkit -assistant -debug -declarative -doc -examples -multimedia -xmlpatterns"
Seems the PyQt4 and sip versions don't explain why it builds for some and not others. The patch requires PyQt4-4.8.2 and sip-4.12 to make pykde4 build - we'll have to ensure those deps. Let's look at a different issue. I'm getting the impression the difference is the python version. It seems that the patch might be failing for those with python-2.7 and building for those with python-2.6. Please let us know if this is the case for you or not.
(In reply to comment #33) > Let's look at a different issue. I'm getting the impression the difference is > the python version. It seems that the patch might be failing for those with > python-2.7 and building for those with python-2.6. $ equery list python * Searching for python ... [IP-] [ ] dev-lang/python-2.7.1:2.7 [IP-] [ ] dev-lang/python-3.1.3:3.1 I need to apply the patch, or pykde4 build fails.
Patch worked on ~x86 with: # eselect python list Available Python interpreters: [1] python2.5 [2] python2.6 * [3] python2.7 [4] python3.1 # equery list python * Searching for python ... [IP-] [ ] dev-lang/python-2.5.4-r4:2.5 [IP-] [ ] dev-lang/python-2.6.6-r1:2.6 [IP-] [ ] dev-lang/python-2.7.1:2.7 [IP-] [ ] dev-lang/python-3.1.3:3.1 #
(In reply to comment #35) > Patch worked on ~x86 with: > > # eselect python list > Available Python interpreters: > [1] python2.5 > [2] python2.6 * > [3] python2.7 > [4] python3.1 > # equery list python > * Searching for python ... > [IP-] [ ] dev-lang/python-2.5.4-r4:2.5 > [IP-] [ ] dev-lang/python-2.6.6-r1:2.6 > [IP-] [ ] dev-lang/python-2.7.1:2.7 > [IP-] [ ] dev-lang/python-3.1.3:3.1 > # Ah, sorry, scratch the above, wrong host. :( I had the issue on ~amd64 with this: # eselect python list Available Python interpreters: [1] python2.5 [2] python2.6 [3] python2.7 * [4] python3.1 # equery list python * Searching for python ... [IP-] [ ] dev-lang/python-2.5.4-r4:2.5 [IP-] [ ] dev-lang/python-2.6.6-r1:2.6 [IP-] [ ] dev-lang/python-2.7.1:2.7 [IP-] [ ] dev-lang/python-3.1.3:3.1 #
(In reply to comment #32) > Created an attachment (id=259333) [details] > updated patch for pykde4-4.5.5 > > This is still a problem in kde-base/pykde4-4.5.5. The patch now needs to remove another typedef. Attached patch makes it build. Thanks for the patch. I've pushed it into the overlay.
The patch applied successfully with python-2.7: leonid@looptop ~ % sudo eselect python list Available Python interpreters: [1] python2.7 * [2] python3.1
Please add the fix into portage tree.
Patch (the first one) applied fine here on ~amd64 : tuxstudio ~ # eselect python list Available Python interpreters: [1] python2.7 * [2] python3.1 tuxstudio ~ # equery list python * Searching for python ... [IP-] [ ] dev-lang/python-2.7.1:2.7 [IP-] [ ] dev-lang/python-3.1.3:3.1
Patch also worked for me Available Python interpreters: [1] python2.6 * [2] python3.1
As I couldn't get this sorted out for pykde4-4.5.4, have the fix committed for 4.5.5 in the overlay and plan to move 4.5.5 to the tree in a bit, I'd like to ask anyone hitting this issue to try 4.5.5.
as 4.5.5 is in tree now, the bug is fixed, thank you all for your help
This appears to be an ongoing problem and has reoccurred with the newer versions Using KDE-4.6 branch, SIP-4.12.1 and PyQt4.8.3 I get these errors: /usr/GIT/branches/KDE/4.6/kdebindings/pykde4/LINUX-ELF-46/sip/kdeui/sipkdeuipart2.cpp: In function ‘PyObject* meth_KTabWidget_label(PyObject*, PyObject*)’: /usr/GIT/branches/KDE/4.6/kdebindings/pykde4/LINUX-ELF-46/sip/kdeui/sipkdeuipart2.cpp:17474: error: ‘class KTabWidget’ has no member named ‘label’ /usr/GIT/branches/KDE/4.6/kdebindings/pykde4/LINUX-ELF-46/sip/kdeui/sipkdeuipart2.cpp: In function ‘PyObject* meth_KTabWidget_tabLabel(PyObject*, PyObject*)’: /usr/GIT/branches/KDE/4.6/kdebindings/pykde4/LINUX-ELF-46/sip/kdeui/sipkdeuipart2.cpp:17502: error: ‘class KTabWidget’ has no member named ‘tabLabel’ /usr/GIT/branches/KDE/4.6/kdebindings/pykde4/LINUX-ELF-46/sip/kdeui/sipkdeuipart2.cpp: In function ‘PyObject* meth_KTabWidget_setTabLabel(PyObject*, PyObject*)’: /usr/GIT/branches/KDE/4.6/kdebindings/pykde4/LINUX-ELF-46/sip/kdeui/sipkdeuipart2.cpp:17530: error: ‘class KTabWidget’ has no member named ‘setTabLabel’ And I note that the 4.5.5 patch will not apply. It appears that some or all of the changes have already been made.
