Hey, ISSUE ----- We switched to Debhelper 14 we end up that plasma-workspace breaks for several users (#1142512). The reason is that Debhleper 14 automatically restarts user sservices. After investigating the issue we end up, that it is a unhappy combination of dh_installsystemduser stanzas. And only users running a X11 session while trigger the update are affected. Three services have a [ install ] - section in their service file so dh_installsystemduser enables those services. So far so good, that was the default for Debhelper 13, too and never triggered an issue. plasma-kcminit.service plasma-ksmserver.service plasma-plasmashell.service With Debhelper 14 the automatic restart of all user services was added (if they are running or enabled). So because those three services are enabled in the first step, the service restart behaviour now starts those services. In the end you get a plasmashell on top of XFCE, not that expacted ;) Additionally for users running a KDE Plasma on X11 will break their session. A restart on wayland don't break anything, but never the less those three services get started. Maybe a unrelated issue I see is that the grep for a install section is too simple to trigger enable of a service. At least plasma-kcminit.service only has an alias in the install - section. From my understanding this alias does not need any file or symlink to be created, to be useful, so a enable stanza should not been added for this service. THOUGHTS --------- At least the start of unstarted services should not happen, if the target, they are part of, is not started. For me it looks unsafe to just restart any user service while upgrading without asking the admin (who execute the upgrade). At least on KDE Plasma uses a lot user services and restarting them may break the Desktop, as seen here. Restarting gpg or wireplumber service without consent is also not a good idea, as it breaks a working user. Wouldn't be the proper solution in extending the "service restart dpkg trigger" to care also about user services? This helper already knows about outdated user services, that needs a restart. Regards, hefee
Hefee: Hi, This feature was implemented by Luca in ea8e48c1bf82745c34e765d68b2bbc4e8f00970a (MR 57). Could you look at this, Luca? Best regards, Niels
Hello, Bug #1142730 in plasma-workspace reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/qt-kde-team/kde/plasma-workspace/-/commit/63bb91ea57632fe28559f4ca7bc350eb2a0828b8 This reverts commit 8b6d5f4527a1e2b371dcc298107f8843fb099d85. ------------------------------------------------------------------------ (this message was generated automatically) -- Greetings https://bugs.debian.org/1142730
Aurélien COUDERC: Hi Aurélien, I think we got a bug no. mixup here. As I understand it, #1142730 is the `debhelper` side. I presume #1142512 might be the plasma-workspace side of things, but I did not check. Best regards, Niels
Aurélien COUDERC: Hi Aurélien, I think we got a bug no. mixup here. As I understand it, #1142730 is the `debhelper` side. I presume #1142512 might be the plasma-workspace side of things, but I did not check. Best regards, Niels
Aurélien COUDERC: Hi Aurélien, I think we got a bug no. mixup here. As I understand it, #1142730 is the `debhelper` side. I presume #1142512 might be the plasma-workspace side of things, but I did not check. Best regards, Niels
We believe that the bug you reported is fixed in the latest version of
plasma-workspace, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 1142730@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Aurélien COUDERC <coucouf@debian.org> (supplier of updated plasma-workspace package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sat, 25 Jul 2026 10:24:31 +0200
Source: plasma-workspace
Architecture: source
Version: 4:6.7.2-5
Distribution: unstable
Urgency: medium
Maintainer: Debian Qt/KDE Maintainers <debian-qt-kde@lists.debian.org>
Changed-By: Aurélien COUDERC <coucouf@debian.org>
Closes: 1142730
Changes:
plasma-workspace (4:6.7.2-5) unstable; urgency=medium
.
[ Aurélien COUDERC ]
* Revert debhelper compatibility bump to 14, it causes unwanted restarts of
user services on upgrade which break various desktops. (Closes: #1142730)
* Manually pass CMAKE_BUILD_RPATH_USE_ORIGIN=ON until debhelper 14
fixes the issue with unwanted user service restarts on upgrade.
* Drop obsolete cmake configuration option PLASMA_X11_DEFAULT_SESSION.
Checksums-Sha1:
dd1ac35a832ee39265e11b4065b5017cfb8bde70 6776 plasma-workspace_6.7.2-5.dsc
892df20e8825b827fa3dc32289eb760e721881b5 63084 plasma-workspace_6.7.2-5.debian.tar.xz
3b23782f8fe588718f295aa06773d3344b59e6ec 40585 plasma-workspace_6.7.2-5_source.buildinfo
Checksums-Sha256:
a45854b3f6afe6247949bd00262f773f99c42f9668cb1b924cab278b60bb66cb 6776 plasma-workspace_6.7.2-5.dsc
ca41855a37c9cd83f9160df5a58a2cc005f859f3595a3ed6e7dee3498612ead7 63084 plasma-workspace_6.7.2-5.debian.tar.xz
78177530dc5b66832c666e5621051e71e36acef930a96f7e98274a9bd0255f3b 40585 plasma-workspace_6.7.2-5_source.buildinfo
Files:
a03dfd9e51e7cd777c6b25586ae958d7 6776 kde optional plasma-workspace_6.7.2-5.dsc
ec4ac7798b30ee5c081d4ed21335b2fb 63084 kde optional plasma-workspace_6.7.2-5.debian.tar.xz
0d6128aed1e5d8ace30f1023a2b26c6c 40585 kde optional plasma-workspace_6.7.2-5_source.buildinfo
-----BEGIN PGP SIGNATURE-----
wsG7BAEBCgBvBYJqZHLJCRBxp+Uz8pGjJEcUAAAAAAAeACBzYWx0QG5vdGF0aW9u
cy5zZXF1b2lhLXBncC5vcmf5NYSPGSV4PehkNcqfg5pvnhetNTogGOyGbr6zAJ8/
thYhBCFv/0AAGg4HDig7H3Gn5TPykaMkAADDTg/7BMsbQzA652YivsRCDrja5bzs
7EC5xn2kvKzIj9hP2fncbqqzJupyk+8wfr4yWtaOAV3BVORqF/IqjsWYppHcBX8C
XHbhTyHd9tAYPCxhRNSH/X3ymGqjqgcRcHBaMBp9JwzCBSMzUyUfpwhxiMCaLqe8
BgebIMo8bnC46egAtHvGrip18f3MIJOxkWRWXtYtHdfmY13nSEsRqJdg0tnaTakx
eExLuuu5Vg4Xy2JYv9MN3+ZJrhFNJ197zqLnyL+/RiYAJuLHKrzy8AlHhYSoLnre
ECTyHzPO4iT+Fju5ey5qvCwFVxX/M7U8AXfFktztBQ/ekAMiWJCfuPb+xtMqVO5a
mGrC3HqXqYqZxrC5zNUR5kIi+/RIXZvcV/ZmUiF9srudiAuBrW6R/NSgqrWNmjDG
+3yur18g4DsZEYWuGQvS6sWjsAl0nqt/hMT7cGgQ2U75akAPIbc8XCRQjJjRyAWD
C5NHrVXuE98oarr7/PMhC2l/HoZUL9LUzhDF8pqvhsrsnYqCgrY7hoRVnrr49wxZ
Du6K+OGzjSJCzL/dTarryZN3B7eaS8uvIlyTj3dUoiAFg7vakx8VwJHsCCcwMy3c
hro0IV0Tq3E8S+SU5prdqwRWbm3wYxIfavFy7jt5A1is8Hkn/Lz38derNbShABzO
x+R1uhjj7yVAM1+qARk=
=LZrX
-----END PGP SIGNATURE-----
Ah yes you're right. Sorry, will fix.
Ah yes you're right. Sorry, will fix.
Ah yes you're right. Sorry, will fix.
We've had a similar restart issue in gnome-terminal, where restarting
the user service terminates existing terminals (#1144676). The compat
level bump from 13 to 14 added this in the postinst:
│ │ │ │ +# 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 'gnome-terminal-server.service' >/dev/null || true
│ │ │ │ + fi
│ │ │ │ +fi
│ │ │ │ +# End automatically added section
and this in the prerm:
│ │ │ │ +# Automatically added by dh_installsystemduser/14.3
│ │ │ │ +if [ -z "$DPKG_ROOT" ] && [ "$1" = remove ] && [ -d /run/systemd/system ] ; then
│ │ │ │ + deb-systemd-invoke --user stop 'gnome-terminal-server.service' >/dev/null || true
│ │ │ │ +fi
│ │ │ │ +# End automatically added section
If dh_installsystemduser had an equivalent of dh_installsystemd
--no-stop-on-upgrade --no-restart-after-upgrade (see also #837528) then
we could probably use that, but at the moment there's no such option,
and the restart is unconditional (in compat level 14). This is suitable
for many user-services, but not all user-services: it would be
destructive to restart dbus.service, a terminal emulator, or a major
desktop environment component like org.gnome.Shell@user.service or
whatever is KDE Plasma's equivalent.
(Perhaps these units should have RefuseManualStop, and perhaps if they
did it would prevent the maintainer script from restarting them - but at
the moment that configuration is far from ubiquitous, and it isn't
obvious to me whether it would have undesired side-effects.)
For now, I'm going to roll gnome-terminal back to compat level 13.
Thanks,
smcv