Bug#513119: murmur-user-wrapper: confused about dbus

[Jan Braun]

Patrick Matthäi schrob:
> Jan Braun schrieb:
> > 1. it requires dbus-x11 [...]
> Yeah, it is recommend by dbus, which is a depend of mumble-server.
> Explicit adding dbus-x11 as dependency to mumble-server would be a bit
> bloated, because not su much users use the user-wrapper, but there
> should be a better error handling of it in the script.

Good plan. I did what was necessary for debian (i.e. check for
dbus-launch when it is needed).
Upstream might want to reword the "install dbus-x11" error message and/or
check for dbus-send, but the patch now should still be an improvement
for them.

> > 2. it exits successfully on errors.
> 
> Your patch has been ACKed by upstream for merging.

Sweet :)

> > 3. it can't start dbus if you use the -d option to move the config
> >    directory from its default ~/murmur
> 
> Okay out of time today, I will try to look these days in it.

My original patch fixed that already (by simply moving the DBUSFILE=
line past the option processing).

After getting your mail, I remembered another issue:
The generated murmur.ini contains
---8<---
# Murmur defaults to not using D-Bus. If you wish to use dbus, please
# specify so here.
#
dbus=session
---8<---
and my first tries after getting the dbus error were commenting that
line out and changing to dbus=none or so. murmur-user-wrapper didn't
ever read that file and unconditionally did its dbus stuff, however, so
that had no effect. Thus I now added a grep for dbus=session to
murmur-user-wrapper, which means you can now comment that line out or
change to dbus=system [1] and the wrapper will do nothing dbus-related.
(And murmurd works for me then. But it also works for me when manually
started with dbus=session and no session dbus running, so what do I know?
Not much about dbus, obviously.)

So, here's v2 of the patch, please review.

regards,
    Jan

[1] http://mumble.sourceforge.net/DBus mentions dbus=session and
dbus=system. I have no idea if there are other values or how to properly
react to them, but "not at all" seems to be the safe choice.
-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments