Simon, I can swap dbus-launch for dbus-run-session.
Either "exec=dbus-launch nm-applet" or "exec=dbus-run-session nm-applet" in /etc/xdg/autostart/budgie-desktop-nm-applet.desktop is needed for the network manager applet to appear in the budgie-panel. If you just have "exec=nm-applet", then network manager will work but the user will not have a visible applet to interact with. I've tested this with with dbus-x11 installed or with both dbus-x11 and dbus-user-session installed Happy to swap to dbus-run-session and add a dependency on dbus. Please advise if this is the route to go through and I'll upload a revised budgie-desktop package. David On 30 August 2016 at 14:53, Simon McVittie <s...@debian.org> wrote: > Source: budgie-desktop > Version: 10.2.6-1 > Severity: normal > User: d...@packages.debian.org > Usertags: dbus-launch default-dbus-session-bus > > As described in <https://lists.debian.org/debian-devel/2016/08/msg00554. > html> > I'm part way through a mass-bug-filing to reduce how much dbus-launch is > used > in Debian. > > As a result of debian/patches/nm-applet.diff, budgie-desktop currently > wraps nm-applet in dbus-launch, which (if successful) results in a new, > private session dbus-daemon being run by nm-applet, for as long as > nm-applet is running. This is incorrect in a number of ways. > > * There is no dependency on dbus-x11, which is the package containing the > dbus-launch executable. If dbus-launch is not present, the desktop file > will just fail to launch. > > * dbus-launch is X11-specific legacy code, which does several things, > all of them badly. If you genuinely want a private session dbus-daemon > for the nm-applet, dbus-run-session is the right tool for the job. > > * Having a private dbus-daemon for the nm-applet is very likely to be > entirely the wrong thing to do. The purpose of the session dbus-daemon > is to let processes communicate. Starting a new, private one of those > creates "its own little world", with processes inside that world > failing to communicate with processes outside it. If a process uses > a D-Bus bus name as a mutex to prevent concurrent modification of > its data files, this could potentially even lead to data loss. > > * Your use of dbus-launch prevents nm-applet from picking up a > pre-created "user bus" on systems that have the dbus-user-session > package installed. This takes precedence over dbus-x11, if both > are installed. > > * If dbus-x11 is installed, then one of its responsibilities is to > start a session bus for each X11 login session (via an Xsession.d > snippet). A sysadmin can disable this, but if they do so, they cannot > validly complain that D-Bus is broken. > > * I think I can confidently say that nm-applet is run with a valid > $DISPLAY, and uses either libdbus or GDBus for its D-Bus > communications. This means that if dbus-x11 is installed, *and* > there is no running session bus (for example because the sysadmin > explicitly disabled it), *and* nm-applet uses the session bus, > then nm-applet will automatically start a session bus via the > "autolaunch" mechanism that it *will* share with the rest of > the desktop environment. > > In summary, whatever problem you are solving, debian/patches/nm-applet.diff > is the wrong answer. Please describe the problem that it is intended to > solve. > > I am 95% confident that the correct answer is to remove that patch without > replacement. If I am wrong about that, then the binary package that > contains budgie-desktop-nm-applet.desktop should depend on dbus (>= 1.8), > and the patch should replace dbus-launch with dbus-run-session. > > S >
