Change:
<del> Index: kinit-5.32.0/src/kdeinit/kinit.cpp =================================================================== --- kinit-5.32.0.orig/src/kdeinit/kinit.cpp +++ kinit-5.32.0/src/kdeinit/kinit.cpp @@ -623,19 +623,15 @@ static pid_t launch(int argc, const char if (!libpath.isEmpty()) { if (libpath_relative) { -                // NB: Because Qt makes the actual dlopen() call, the -                //     RUNPATH of kdeinit is *not* respected - see -                //     https://sourceware.org/bugzilla/show_bug.cgi?id=13945 -                //     - so we try hacking it in ourselves -                QString install_lib_dir = QFile::decodeName( -                        CMAKE_INSTALL_PREFIX "/" LIB_INSTALL_DIR "/"); -                QString orig_libpath = libpath; -                libpath = install_lib_dir + libpath; -                l.setFileName(libpath); -                if (!l.load()) { -                    libpath = orig_libpath; -                    l.setFileName(libpath); -                    l.load(); +                // Try to load the library relative to the active profiles. +                QByteArrayList profiles = qgetenv("NIX_PROFILES").split(' '); +                // Reverse the profile list. +                std::reverse(profiles.begin(), profiles.end()); +                for (const QByteArray &profile: profiles) { +                    if (!profile.isEmpty()) { +                        l.setFileName(QFile::decodeName(profile) + QStringLiteral("/lib/") + libpath); +                        if (l.load()) break; +                    } } } else { l.load(); </del>

Discussion:
Describe the bug When I launch using a keyboard shortcut, it didn't get any context, resulting in it displaying strangely: ! If I launch it using the menu it displays correctly. For other applications, depending on what they requires, they sometime just don't open. EDIT : I have the feeling that the reason that is not opening when using the keybinding is the same reason. To Reproduce Steps to reproduce the behavior: a shortcut to Konsole konsole with the shortcut Additional information While starting with the shortcut, this inputs is visible in : Expected behavior The program should behave the same way as when launched using menu. Metadata Maintainer information:
Woah, it doesn't seem to even have a PATH environment.
New way to reproduce the issue : when the feature to restore previous window after a logout/login is active, it restarts the application with the same issue.
Applying the fix from fixed this issue.
I cherry-picked and it fixed this issue for me; however my KDE windows are all still borderless.
Hmm, that sounds like kwin died.

Describe the bug Support for several protocols are missing in KIO after upgrading to plasma desktop 5.17.5 To Reproduce Steps to reproduce the behavior: with the latest nixos-unstable channel, sure the desktop is configured with the folder view logging in, an error message is displayed at the center of the screen: ! Expected behavior A folder view of the desktop icons should be displayed correctly. Additional context I think one can reproduce the error with kioclient5: This will give the same error message: Metadata
cc
Thanks for reporting this! I don't see any error message on the desktop in a VM, but I will try the reproduction next.
I cannot reproduce this in a clean VM. does this happen after upgrading an existing installation? If so, then I suspect this is a (known) issue with not performing cache invalidation correctly.
Hi , yes, I noticed the regression right after I upgraded my system with followed by followed by (I have network issues and I found this workaround somewhere on GitHub). Before the upgrade I was running plasma 5.16.5 where it worked well. Might be stupid but how can I clear the cache of ? I tried things like with no luck. I also tried with a new user but had the same issue.
will rebuild the current cache, but you have to actually remove all the existing caches: . Basically, this is because every KDE program runs in its own environment, so there may be multiple caches. However, the old caches wouldn't affect a new user, so if you are seeing the same with a new user, it must be something else.
Have the same issue. Just upgraded to 5.17.5, restarted PC and desktop shows the same error as originally reported. ! Removing cache with didn't help.
I have the same issue in an vm after upgrading, but I will try to reproduce it in an new VM.
Beside 'desktop', some other protocols are not working either. By checking I found similar error messages in other programs:
Can anyone share a configuration I can use to reproduce this?
Below is my configuration:
Also getting the same problem, ktorrent and yakuake are also reporting the same issue where they cannot find the desktop component (i.e. yakuake cannot find konsole).

Also ktorrent is unable to find the plasma theme Clearing the cache had zero effect, here is my configuration
Also the firefox plasma integration seems to be failing, it has the error "Failed to connect to the native host" even though the package was installed.
Firefox plasma integration works fine for me despite I have the same problem with 'desktop' protocol.
I can reproduce this issue on first-time install of . Firefox plasma integration works fine while the protocol error is still there. EDIT : I have issue with also, it seems its does not want to launch correctly at start (keybinding is not opening it). If I launch in the terminal, it works but hang on first keystrokes to shows the following output : I have the feeling that this is not only the protocol that is impacted
I am (finally) able to reproduce this issue with the following configuration in a QEMU VM: I have checked that exists; missing this file is the most obvious way this could go wrong.
Using socket-activated D-Bus fixes this issue: I suspect that if the D-Bus session is started too early, the environment is not set up correctly.
Maybe related: Upstream changes to cause to run in an empty environment.
Switching the handling of D-Bus from X11-activated to socket-activated fixed the issue for me as well - didn't touch the ksycoca cache so far.
Thank you , it works! Saved my life!
I can also confirm that it works, is the change from going to X11 to socket activated d-bus likely to be merged into nixos-stable or is this an upstream issue that needs to be resolved and hence the current fix is just a workaround?
This fixes plasma for me, (including latte-dock not auto-starting). For some reason, plasma-browser-integration still is not working for me despite the extension being installed.
I can confirm it fixes the issue also for me.
Such a change in nixos 20.03 would be out of the question IMHO. It's a regression that it doesn't work properly in the first place.
It's neither: it is a workaround and it's not an upstream issue. The issue is that something in the "improved" unsets the environment for some processes during startup. Then those processes can't find D-Bus. I think with socket activation, the affected processes will start their own message bus.

If you look at the log (), the Plasma session isn't properly started, but is just limping along. I agree with that this shouldn't be merged into NixOS 20.03, or into any other branch. If a proper solution is not forthcoming, then the Plasma 5.17 update should be reverted.
Okay thanks, I have commented this as a workaround in my . Hopefully we can solve the underlying issue.
I have narrowed this down somewhat. Some background: is a setuid binary that starts the Plasma session server; because it is setuid, its environment is reset at startup. reads the environment, runs , and passes the environment through a pipe. reads the environment from the pipe and sets the environment before calling . I have verified that truncates the environment, and I think that causes the problems we are seeing. I don't know why yet, but I have a suspect: has some sanity checks for the environment that it reads (for security) and one of those checks is on the length of each individual environment entry. I suspect that the new dependencies in Plasma 5.17 cause the limit to be exceeded.
I have confirmed that this is, indeed, the case. I believe I can have a patch ready in a day.