dbus-run-session output.

[Simon Lees]

On 04/10/2017 09:07 PM, Simon McVittie wrote:
> On Fri, 07 Apr 2017 at 17:59:32 -0700, Thiago Macieira wrote:
>> Em sexta-feira, 7 de abril de 2017, às 04:49:37 PDT, Simon Lees escreveu:
>>> I am equally curious, I think in this case the user is doing something
>>> like using i3m and I have no idea how its been launched, gnome, kde and
>>> enlightenment all launch with a systemd user session and seem to be fine.
>>
>> We're not.
>>
>> $ echo $DBUS_SESSION_BUS_ADDRESS 
>> unix:path=/run/user/1000/bus
>> $ emacs
>> Activating service name='org.gnome.GConf'
>> Successfully activated service 'org.gnome.GConf'
> 
> So the issue here seems to be that the emacs launcher is second-guessing
> how dbus-launch works:
> https://build.opensuse.org/package/view_file/openSUSE:Factory/emacs/emacs.sh?expand=1
> and preferring to use dbus-run-session if both dbus-launch and
> dbus-run-session are available.
> 
> This is not the right thing to do. If dbus-launch is installed, libdbus
> will *already* do the right thing, without emacs needing to reimplement it.
> 
> Please raise this with the openSUSE maintainers of emacs. This
> appears to be a distro-specific issue in code introduced for a particular
> distribution.
> 
> If openSUSE's emacs packaging really needs to do these tricks, it could
> avoid this failure mode by looking for $XDG_RUNTIME_DIR/bus, and if it is
> present and owned by the right uid, using it. (dbus-launch --autolaunch
> already does that.)
> 
> The emacs wrapper says
> 
>     # Now check for valid dbus, e.g. after su/sudo/slogin
> 
> which suggests that this is an elaborate workaround for one or both of
> these situations:
> 
> * lacking a session bus and wanting to work around it by borrowing the
>   session bus from the "wrong" login session; under the strict login session
>   model (artificially separate login-sessions) this is just wrong, while
>   under the user-session model it is unnecessary
> 
> * escalating privileges without clearing the environment (su, not su -),
>   which can be fixed by clearing the environment correctly
> 
forwarding the above to the emacs maintainer.

>> It seems the problem is that the session bus launched by whatever the distro 
>> uses did not fill in ~/.dbus/session-bus/$MACHINEID-0.
> 
> Correct, the systemd user unit does not fill in ~/.dbus/session-bus.
> 
> I would really prefer not to keep that mechanism forever - we have already
> been asked to stop putting this "autolaunch crap" in the home directory
> <https://bugs.freedesktop.org/show_bug.cgi?id=35887>. I had hoped that
> the user-session service (which is already opt-in, so openSUSE's dbus
> maintainer should hopefully have evaluated its impact before opting in)
> was an opportunity to draw a line and get away from those historical
> oddities.
> 
I was lucky enough to recently inherit the dbus maintainership for
openSUSE, i'm still getting my head around everything though. What is it
exactly that your recommending we drop support from? Certainly its
pretty easy to remove things from the rolling distro if not much is
using it, the stable distro's will take some time though if its still there.

-- 

Simon Lees (Simotek)                            http://simotek.net

Emergency Update Team                           keybase.io/simotek
SUSE Linux                           Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dbus/attachments/20170410/f906e28d/attachment.sig>