SUMMARY For whatever reason, KDE applications which use kded5 in some fashion or another are always calling it from "/usr/bin/", rather than the kdesrc-build install prefix. kded-smart-helper is always called from "/usr/lib/" too, and when kded5 crashes, almost always instantly, so is drkonqi. Besides, I seem to have found a useful way to reproduce it ~ right-clicking files in Dolphin... The crashes I think to be linked to "/usr/bin/kded5" and friends being called, instead of the kdesrc-build prefix ones. STEPS TO REPRODUCE 1. Install KDE via kdesrc-build, and run 2. Start Dolphin and beside it, Ksysguard or something. Filter by "kded". 3. Right-click files, and observe "/usr/bin/kded5" to be running OBSERVED RESULT kded5 is called from "/usr/bin/kded5" and usually instantly crashes. EXPECTED RESULT kded5 is called from "<kdesrc-build-prefix>/bin/kded5" and doesn't crash. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.21.80 KDE Frameworks Version: 5.82.0 Qt Version: 5.15.2 Kernel Version: 5.12.1-arch1-1-custom (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 5600X 6-Core Processor Memory: 15.6 GiB of RAM Graphics Processor: Radeon RX 580 Series
Whoops ~ forgot to mention that right-clicking folders also triggers it.
In order for kded and other DBus-activated things to work correctly you need to configure DBus to take the custom location into account. See https://community.kde.org/Get_Involved/development#Plasma_Desktop for how to do that, in particular the "In order to make DBus and KAuth actions work properly..." part
(In reply to Nicolas Fella from comment #2) > In order for kded and other DBus-activated things to work correctly you need > to configure DBus to take the custom location into account. > > See https://community.kde.org/Get_Involved/development#Plasma_Desktop for > how to do that, in particular the "In order to make DBus and KAuth actions > work properly..." part Cheers. Didn't know about that. :)
Okay, creating the "/etc/dbus-1/session-local.conf" file with the necessary paths, and restarting the session, hasn't solved anything for me... Starting Ksysguard immediately on startup, kded5 does get started from the kdesrc-build prefix, but it crashes in short order, which starts drkonqi also from the kdesrc-build prefix, while /usr/lib/kauth/kded-smart-helper oddly gets called... Right-clicking files / folders from within Dolphin still ends up calling everything from /usr/{bin,lib}/ :|
Created attachment 138269 [details] kdesrc-build prefix build kded5 dying with correct paths
Created attachment 138270 [details] /usr/bin/kded5 and friends started with Dolphin file / folder right-click
Does this help? sudo cp -r ~/kde/usr/share/dbus-1/ /usr/share/ sudo cp -r ~/kde/usr/share/polkit-1/actions/* /usr/share/polkit-1/actions/
Created attachment 138309 [details] kded5 after copying files kded5 is now called from the kdesrc-build prefix after coping said files. Still crashes though, it seems. But, that'll be for a different bug report.
> sudo cp -r ~/kde/usr/share/dbus-1/ /usr/share/ > sudo cp -r ~/kde/usr/share/polkit-1/actions/* /usr/share/polkit-1/actions/ Would be nice to have this documented for future, or at least, made clearer, if it already is documented somewhere.
That's what I personally do, but I've resisted adding it to the wiki since it overwrites system files. This is fine... until it isn't. :) Sadly nobody has figured out the correct way to get dbus from the prefix set up properly. See Bug 425272. *** This bug has been marked as a duplicate of bug 425272 ***
(In reply to Nate Graham from comment #10) > That's what I personally do, but I've resisted adding it to the wiki since > it overwrites system files. This is fine... until it isn't. :) On Arch, at least, "paccheck --md5sum --quiet" lets you check whether what system files differ from their package checksums. So, in that sense, it's completely fine. The real trick is remembering to reinstall those system packages when you want to use your system's KDE install, heh.
Exactly. I live in a git master Plasma session 99% of the time, but doing this would be completely unacceptable for someone who does it 1% of the time. :) Ultimately I think we need to just get Bug 425272 fixed.