I'm running xfce4, but because I might want to change some day I also
have KDE and Gnome installed. Lately, I've noticed that when
plasma-workspace is updated, it will start a plasma session on top of
the xfce4 session and mess up my icon theme.

This has happened in the two most recent plasma-workspace updates I've
done. That should mean it happened in 4:6.7.2-3, but possibly not in
4:6.7.2-2? I have not verified that, though.

I can also reproduce that by reconfiguring the package. The output from
this is probably not helpful, since every line is about how it doesn't
start something:

# dpkg-reconfigure plasma-workspace
plasma-baloorunner.service is a disabled or a static unit not running,
not starting it.
plasma-core.target is a disabled or a static unit not running, not
starting it.
plasma-gmenudbusmenuproxy.service is a disabled or a static unit not
running, not starting it.
plasma-kcminit-phase1.service is a disabled or a static unit not
running, not starting it.
plasma-krunner.service is a disabled or a static unit not running, not
starting it.
plasma-ksplash.service is a disabled or a static unit not running, not
starting it.
plasma-restoresession.service is a disabled or a static unit not
running, not starting it.
plasma-startupsound.service is a disabled or a static unit not running,
not starting it.
plasma-workspace-wayland.target is a disabled or a static unit not
running, not starting it.
plasma-workspace-x11.target is a disabled or a static unit not running,
not starting it.
plasma-workspace.target is a disabled or a static unit not running, not
starting it.
plasma-xembedsniproxy.service is a disabled or a static unit not
running, not starting it.

Please let me know what additional information you need.

Regards,

Torbjörn Andersson

As this crashes the current Plasma session I don't think it's acceptable
(while we still allow upgrades in a GUI session anyway).

Hey,

I could update without any issue - but actually just luck ;)
Properly because I use a "su -" session to run the upgrade and cannot
interact with the user systemd and root has no plasma workspace running.
The upgrade from -2 -> -4:

plasma-workspace (4:6.7.2-4) wird eingerichtet ...
plasma-baloorunner.service is a disabled or a static unit not running, not starting it.
plasma-core.target is a disabled or a static unit not running, not starting it.                                                                                                                                                                plasma-gmenudbusmenuproxy.service is a disabled or a static unit not running, not starting it.
plasma-kcminit-phase1.service is a disabled or a static unit not running, not starting it.
plasma-krunner.service is a disabled or a static unit not running, not starting it.
plasma-ksplash.service is a disabled or a static unit not running, not starting it.
plasma-restoresession.service is a disabled or a static unit not running, not starting it.
plasma-startupsound.service is a disabled or a static unit not running, not starting it.
plasma-workspace-wayland.target is a disabled or a static unit not running, not starting it.
plasma-workspace-x11.target is a disabled or a static unit not running, not starting it.
plasma-workspace.target is a disabled or a static unit not running, not starting it.
plasma-xembedsniproxy.service is a disabled or a static unit not running, not starting it.
Could not execute systemctl:  at /usr/bin/deb-systemd-invoke line 148.

The underlying issue is that with Debhelper 14 all user sessions get restarted. The upgrade checklist actually tell this for v14:

The dh_installsystemduser tool will default to enabling systemd user units,
start them on installation, restart them on upgrades and stop them on uninstalling the package.

From the postinst script this got added:

# Automatically added by dh_installsystemduser/14.3
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
·       if [ -z "$DPKG_ROOT" ] && [ -d /run/systemd/system ]; then
·       ·       # Here we reload synchronously, as we really need to block in
·       ·       # order to ensure the following restart also works. Furthermore,
·       ·       # if there is no D-Bus user session, the restart won't work either,
·       ·       # so there's no point if falling back to signals - so either both
·       ·       # of these operations work, or both fail.
·       ·       deb-systemd-invoke --user daemon-reload >/dev/null || true
·       ·       deb-systemd-invoke --user restart 'plasma-baloorunner.service' 'plasma-core.target' 'plasma-gmenudbusmenuproxy.service' 'plasma-kcminit-phase1.service' 'plasma-kcminit.service' 'plasma-krunner.service' 'plasma-ksmserver.service' 'plasma-ksplash.service' 'plasma-plasmashell.service' 'plasma-restoresession.service' 'plasma-startupsound.service' 'plasma-workspace-wayland.target' 'plasma-workspace-x11.target' 'plasma-workspace.target' 'plasma-xembedsniproxy.service' >/dev/null || true
·       fi
fi

Regards,

hefee

fixed 1142512 plasma-workspace/4:6.7.2-5

I can confirm that the update to plasma-workspace 4:6.7.2-5 went without
a hitch for me. Thanks for the quick response! (I wasn't sure how well I
managed to describe the bug, since there are so many components here
that are just black magic to me.)

Regards,

Torbjörn Andesson

Hi,

Le 25 juillet 2026 21:57:47 GMT+02:00, "Torbjörn Andersson" <eriktorbjorn@telia.com> a écrit :

Thanks for your feedback.

We had an extensive discussion about it on IRC and with more analysis hefee was able to pinpoint it to a behaviour change in the recently released version 14 of our debhelper build system.

The debhelper issue is now tracked at [1]. In the meantime I reverted to debhelper 13 and manually changed the build parameter needed to build plasma-workspace reproducibly (that debhelper 14 was giving me for free).


[1] <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1142730>


Happy hacking,
--
Aurélien