kde-base/kdelibs-4.4.5 fails to build with x11-libs/qt-dbus-4.7.1: [ 50%] Building CXX object kded/CMakeFiles/kdeinit_kbuildsycoca4.dir/kbuildservicetypefactory.o /var/tmp/portage/kde-base/kdelibs-4.4.5/work/kdelibs-4.4.5/kded/kded.cpp:75: error: expected initializer before 'void' /var/tmp/portage/kde-base/kdelibs-4.4.5/work/kdelibs-4.4.5/kded/kded.cpp: In constructor 'Kded::Kded()': /var/tmp/portage/kde-base/kdelibs-4.4.5/work/kdelibs-4.4.5/kded/kded.cpp:127: error: 'qDBusAddSpyHook' was not declared in this scope /var/tmp/portage/kde-base/kdelibs-4.4.5/work/kdelibs-4.4.5/kded/kded.cpp: In member function 'KDEDModule* Kded::loadModule(const KSharedPtr<KService>&, bool)': /var/tmp/portage/kde-base/kdelibs-4.4.5/work/kdelibs-4.4.5/kded/kded.cpp:363: warning: 'static KLibLoader* KLibLoader::self()' is deprecated (declared at /var/tmp/portage/kde-base/kdelibs-4.4.5/work/kdelibs-4.4.5/kdecore/util/klibloader.h:142) make[2]: *** [kded/CMakeFiles/kdeinit_kded4.dir/kded.o] Błąd 1 make[1]: *** [kded/CMakeFiles/kdeinit_kded4.dir/all] Błąd 2 make[1]: *** Oczekiwanie na niezakończone zadania.... A simple fix: sed -i -e 's,QDBUS_EXPORT,,g' "${S}/kded/kded.cpp"
Created attachment 254119 [details, diff] kdelibs-4.4.5-qt471.patch I can confirm both, the error and the sed line fixing the error. Nevertheless I think a patch is more appropriate in this case so here is it :)
I also confirm both, the problem and the fix. Thanks.
Created attachment 255781 [details] Updated ebuild I have attached a revision-bumped ebuild that incorporates the patch. Please put it into the Portage tree to fix this issue.
No need for a revision bump when it's just a build error...
This fix has been in upstream's SVN for four months, and fixes the build issue here. Could we get that integrated into the tree, please?
Even the most conservative gentoo kde devs run 4.5.4 by now, so there's noone here who can really test this. Therefore I've made an ~arch kdelibs-4.4.5-r1. Please keyword yourself and test, and it will become stable after some time.
(In reply to comment #6) > Even the most conservative gentoo kde devs run 4.5.4 by now, so there's noone > here who can really test this. I do: nelchael@s-lappy ~$ emerge -pv --nodeps kdelibs These are the packages that would be merged, in order: ... done! [ebuild R ] kde-base/kdelibs-4.4.5 USE="alsa bzip2 lzma mmx nls opengl sse sse2 ssl -3dnow -acl (-altivec) (-aqua) -bindist -debug -doc -fam -handbook -jpeg2k (-kdeenablefinal) (-kdeprefix) -kerberos -openexr -policykit -semantic-desktop -spell -test -zeroconf" 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB
Like I said, I can confirm that the fix works. I already gave it a test on my ~amd64 systems as well as my two stable x86 VMs. No regressions visible...
Krzysztof, Lars: you are not by any chance interested in joining the kde team? :) We could definitely need testing help on the stable maintenance side... Most of the guys are busy keeping the -9999 live ebuilds working, which is good since this is the basis for all the other ebuilds. Some are running ~arch as me, but afaik nobody in the kde team is running stable...
I'm running ~arch, but I'm keeping with 4.4.x until 4.6.x comes out because I plainly don't like 4.5.x (kept crashing some time ago, other minor issues).
(In reply to comment #10) > I'm running ~arch, but I'm keeping with 4.4.x until 4.6.x comes out because I > plainly don't like 4.5.x (kept crashing some time ago, other minor issues). > Please bump this to a stable ebuild ... quite a few people runing stable boxes will not have the skill/time to tweak their keyword/mask combinations to select the -r1 ~arch ebuild. Plus if they do edit /etc/portage/package.xxx to get this fix, they will need to reverse the entries when the next stable version of kde hits the tree .. otherwise this may trigger a whole raft of extra bugs from a newer kde interacting with kdelibs-4.4.5 that has accidently been left in the system by the edits to /etc/portage/package.xxxx As this bug is all about the stable tree ... it is not really resolved/fixed until the ebuild is in the stable arch. IE The fix is understood and tested, but we need to push it into stable before it is actually resolved/fixed. I woudld suggest that it be reopened it as a bug at the moment ... the stable tree is still broken by this. I dont know what the etiquette is for marking the ebuild stable, but it is needed in this case. -r2 anyone?
Ron, I completely fail to see your concern here... qt-4.7.1 still isn't stable so why should we stabilize kdelibs-4.4.5-r1 when it only fixes a problem with a library version still being unstable? (In reply to comment #9) > Krzysztof, Lars: you are not by any chance interested in joining the kde team? > :) > > We could definitely need testing help on the stable maintenance side... > > Most of the guys are busy keeping the -9999 live ebuilds working, which is good > since this is the basis for all the other ebuilds. Some are running ~arch as > me, but afaik nobody in the kde team is running stable... > Sorry to comment so late on your request. I see two problems with joining the kde team. First I don't know much about how kde ebuilds have to be maintained properly and second I only have two stable virtualbox VMs (amd64 and x86) where I can reliably test kde packages and these suffer from other problems (like freezing everytime I use >=kernel-2.6.33). All my other stable machines using kde cannot be "abused" as testing victims.
