I've changed the subject line back to the one from the bug - I get a *lot* of bugmail, which I usually see out-of-context, so "Investigating" doesn't really work as a reminder of what bug and what package you're talking about. I hope that's compatible with your workflow.
On Fri, 02 Feb 2024 at 12:11:13 +0000, Nicholas Bamber wrote: > So far in order to investigate I have: > > 1. installed discord on a lwm desktop via flatpak. This works but is pretty > ugly and the whole filesystem is exposed. Large proprietary apps containing an entire web browser engine tend not to be feasible to sandbox meaningfully, unfortunately, especially if their packagers want them to have full functionality for users who are unaware of the existence of sandboxing and want everything to "just work". My usual go-to test apps are GNOME Recipes https://flathub.org/apps/org.gnome.Recipes, ASHPD demo https://flathub.org/apps/com.belmoussaoui.ashpd.demo, or the portal tests built by src:libportal (install libportal-tests-gtk3 and libportal-tests-gtk4 and run with "GTK_USE_PORTAL=1 GDK_DEBUG=portals" in the environment, or you can build them into Flatpak apps from the source package). Those are a lot more meaningfully sandboxed. > 2. Looking into ways to get the XDG_CURRENT_DESKTOP into the systemd user > environment. In the original bug report, part of the solution I suggested was this: Add a sequence of semicolon-separated desktop environment names to /usr/share/xsessions/lwm.desktop, most likely just "Lwm": DesktopNames=Lwm; (For example, icewm and windowmaker use "ICEWM" and "WindowMaker" in their equivalent xsessions file.) Most display managers take this into account and will convert it into setting the XDG_CURRENT_DESKTOP setting (for example, I know that gdm3, lightdm and sddm do this). This won't work for xdm, but at some point I think we have to start treating that sort of thing as an xdm limitation, rather than something that individual desktop environments are expected to address? > Putting a script into the 55 priority in /etc/X11/Xsession.d. This works > (and does not pollute other desktop environments since we can check at that > point). However it depends on the the package dbus-x11 and I have concerns > about the long term support for this package. Doesn't the combination of these two files dbus-user-session: /etc/X11/Xsession.d/20dbus_xdg-runtime dbus-x11: /etc/X11/Xsession.d/95dbus_update-activation-env already do what's needed here? Those two packages represent the only two implementations of the dbus-session-bus virtual package that currently exist in Debian. xdg-desktop-portal already depends on default-dbus-session-bus | dbus-session-bus, so whenever xdg-desktop-portal is installed, so is at least one of those two packages; and they both pull in dbus-bin, which provides /usr/bin/dbus-update-activation-environment. If someone adds a third implementation of dbus-session-bus, I think it would be entirely reasonable for us to expect it to have similar handling of at least the most basic variables like DBUS_SESSION_BUS_ADDRESS, DISPLAY, XAUTHORITY and XDG_CURRENT_DESKTOP. The other possible way to do this, which *would* work even for xdm, is to do like gnome-session does, and upload at least those few basic environment variables to the D-Bus activation environment during GUI session startup, either from the main executable (using libdbus or a similar library) or from a shell script wrapper (using dbus-update-activation-environment or equivalent). This wouldn't necessarily have to imply a hard dependency on d-u-a-e, it could be done conditionally. I realise that this is unappealing for a specifically lightweight desktop environment, so I'd be fine with the answer to this particular part being "wontfix, use a better display manager if you want this functionality". smcv
