3

What I'm trying to do : I'm trying to build my own full KDE from source and run it as my regular user, without changing the one from the system. The problem : I can't seem to run the software I built without changing my whole system to always run only that.

From what I understand from documentation section 2.5.1, this is well supported. kdesrc-build will install a login driver so that the login manager will find an appropriate setting to run a plasma session running the software built in my install prefix. I couldn't make this work out of the box – SDDM would not see the installed script, but I could have it work easily by linking the plasma.desktop file installed by kdesrc-build into my /usr/share/xsession folders. This lets SDDM see my session.

Unfortunately this still would not run the KDE I built from source. The reason for this is, while this would start the init sequence from the software I built, the startup sequence (as in plasma/plasma-workspace/startkde/plasma-session/startup.cpp and its friends) will only prepend the install prefix for some commands at the start, so it would run my built startkde but very soon it would revert to the ones from $PATH and nobody seems to set that variable. It looks to me like some environment script was supposed to do it (kde-env-master.sh looks like a good candidate)

So I cheated and arranged for the login script to set $PATH to contain the bin directory of the software I built. But this is still not enough – the binaries I built will now try to load with libraries from the system, which are not the ones they built against. There are some references in the init files to setting $LD_LIBRARY_PATH to contain the directory where the libs I built live, but for security reasons $LD_LIBRARY_PATH is reset very often (in practice this happens as soon as the init sequence drops privileges), so the values set in the environment script are, in effect, ignored.

I can set my ldconfig to find these libraries I built – but this is system-wide, so if I did this the normal session running with stable software installed by my distro would try and use the libraries I built, which is at best a dangerous idea.

All of this suggests to me I'm doing something wrong, but I can't figure out what. After all, the doc says running a session is the right way to do it, kdesrc-build installs a login driver, there are files to set the environment built in my built prefix to the right directories, all of this seems to be well integrated but when I try to do it I find issue after issue, so I can only suppose I didn't do it right.

How am I supposed to set a session that runs my custom-built KDE, without affecting the regular session installed by my distribution ?

Note : running this on Debian Testing and kdesrc-build 20.06

1 Answer 1

1

You have to run
~/kde/build/plasma-workspace/login-sessions/install-sessions.sh
to install your kde built session:
https://community.kde.org/Get_Involved/development#Plasma_Desktop

It might be a problems, still (as for me). Please report to kde bugtracker if you encount them.

5
  • Thanks, it does look like this is exactly what I had missed. Unfortunately it hits the exact same problem I describe above : by default the env doesn't override LD_LIBRARY_PATH, which prevents KDE software from running (conflicting Qt lib versions between my system and my built ones), and if I do override by uncommenting it in the env script... well it doesn't help because it's reset before it's used. I'll investigate a bit more, and possibly report to the bug tracker. Thanks for the help.
    – Jean
    Commented May 1, 2022 at 9:25
  • Any luck? In my case I had to wipe system-wide installed KDE stuff to make it work, but now I have no chance to investigate for a proper solution. Maybe you could help us to understand what is a bug exactly and/or improve the documentation.
    – bam
    Commented May 5, 2022 at 12:53
  • Also, please note you can start entire Plasma session from within container. I'm going to use it for development, too: distrobox.privatedns.org/posts/…
    – bam
    Commented May 5, 2022 at 13:03
  • 1
    Sorry it took so long, but yes I finally managed to come back to this task and make it work. I had to wipe the entire build directory – maybe in the intervening 4 months something was fixed too. But building completely from scratch and using the script you pointed to did the trick : the session thus installed works, and I did not have to remove the system-wide installed KDE (both can coexist and I can run either from SDDM). So essentially, the thing I was missing was exactly the script you pointed to. Thanks !
    – Jean
    Commented Aug 5, 2022 at 1:09
  • One thing that didn't work easily was : while the session puts the path for the custom-built KDE binaries in $PATH, it doesn't do the same for the custom-built QT, leading to some issues. Fixing that manually helped.
    – Jean
    Commented Aug 5, 2022 at 1:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .