Bug#836083: budgie-desktop: debian/patches/nm-applet.diff makes very little sense

[Simon McVittie]

On Tue, 30 Aug 2016 at 19:38:54 +0100, foss.freedom wrote:
>   I can swap dbus-launch for dbus-run-session.

I think that's still wrong, but it's a good start, and would take this off
the radar for this mass-bug-filing.

> 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.

As far as I'm aware, this is not the case in any other desktop environment
that uses nm-applet. I suggest looking into why, and perhaps comparing
what budgie-desktop does with GNOME Flashback, MATE or Cinnamon on a
similarly configured system.

If you test with dbus-user-session, log messages should go to the systemd
Journal where you can look at them.

S

Bug#836083: budgie-desktop: debian/patches/nm-applet.diff makes very little sense

[foss.freedom]

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  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  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
>

Bug#836083: budgie-desktop: debian/patches/nm-applet.diff makes very little sense

[Simon McVittie]

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 
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