D-Bus services not working on foreign distributions/non-user profiles

Hello,

On Guix System, the D-bus session service honors D-Bus service

definitions found under ~/.guix-profile/share. That is not the case on

foreign distributions, breaking applications such as Jami (where the

daemon is normally auto-launched via D-Bus at the time the client

attempts to use it).

The same problem occurs on Guix System when attempting to use D-Bus

services from a non-user profile (such as with 'guix environment

--ad-hoc').

We should try to find a way to make this work; either automatically

(seems a tough nut to crack) or through manual, documented steps.

Thanks,

Maxim

This can be verified on a system where the jami-daemon (libring) has not

yet been installed (commonly via propagation from one of the jami

clients):

$ guix environment --ad-hoc jami-gnome -- jami-gnome

Attempt to run it:

$ jami-gnome

It should fail with the following message: "Could not rec-connect to the

Jami daemon (dring). Jami will now quit."

as the currently running dbus session doesn't know about

the newly installed D-Bus service, as it only look under a few

hard-coded places.

For this particular instance, a workaround is to run jami via the

dbus-run-session utility, which launches the client in an ad-hoc d-bus

session which knows about the dring D-Bus service (through the

XDG_DATA_DIRS variable set by glib's search path).

$ guix environment --pure --ad-hoc jami-gnome dbus glib \

-- dbus-run-session jami-gnome

The glib package is added for its XDG_DATA_DIRS search path. It works

because the client doesn't really care about being able to talk to

anything else but its daemon over D-Bus.

Hi Maxim,

On Thu, 20 May 2021 at 13:18, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

On Debian, using 014421e, I get:

Well, it means I have some misconfigured about ALSA, right?

Cheers,

simon

On Thu, May 27, 2021 at 08:54:49PM +0200, zimoun wrote:

[...]

Did you install alsa-plugins and alsa-plugins:pulseaudio ?

If you do that, then it should "just work" on other distros.

Hi Leo,

On Thu, 27 May 2021 at 15:20, Leo Famulari <leo@famulari.name> wrote:

Do you mean

guix environment --pure --ad-hoc jami-gnome dbus glib \

alsa-plugins alsa-plugins:pulseaudio \

-- dbus-run-session jami-gnome

? If yes, there is still errors:

the ’--pure’ is not the issue. It is probably different but it rings a

bell with bug#47106.

Cheers,

simon

On Thu, May 27, 2021 at 09:59:19PM +0200, zimoun wrote:

Yes

Okay, but not from ALSA :) So, at least you have eliminated ALSA

problems from your test.

Am Donnerstag, den 27.05.2021, 21:59 +0200 schrieb zimoun:

It is different. The cause of your issue is probably, that you're

lacking gsettings-desktop-schemas or something similar to it inside

your environment. Perhaps we could try forming a "gnome-base"

metapackage, that propagates all of dbus, glib, gsettings-schemas etc.

for such purposes (maybe on wip-gnome first)?

Regards,

Leo

PS: Command just ran through

I'm sure you know about -E XAUTHORITY by now, but imo we should have a

switch similar to --networking for container operations.

PPS: Just adding gsettings-desktop-schemas didn't work. "jami-gnome

glib gnome" obviously works, but that's a little overkill (also it

appears that you'll have to get credentials into this thing, which I

haven't bothered worrying about).

Hi!

Leo Prikler <leo.prikler@student.tugraz.at> writes:

No credentials are needed; it asked to register your username by

default, but pressing the 'skip' button will, well, skip that step and

go straight to creating your account (which is just a private key on

your device, basically).

Maxim

Hi Leo & Simon,

Leo Prikler <leo.prikler@student.tugraz.at> writes:

We're drifting off topic for this issue (which is supposed to be about

D-Bus rather than Jami on foreign distributions :-)), but for the sake

of completion, the following works (tested on a Debian 10 i386 VM):

$ guix environment --ad-hoc jami-gnome dbus glib gtk+ openssl nss-certs \

-- dbus-run-session jami-gnome

Apparently the FileChooser schema is provided by gtk+. I also found out

that OpenSSL from Guix wants the SSL_* environment variable sets, so I

added the nss-certs and openssl packages to the mix (otherwise you

wouldn't have been able to search for contacts).

I think for gtk+/glib this can be improved by adding the

glib-or-gtk-build-system phases to the jami-gnome package definition.

HTH!

Maxim

Am Donnerstag, den 27.05.2021, 22:17 -0400 schrieb Maxim Cournoyer:

That's probably a difference in what data already exists. At the very

least, it tried accessing the SecretService on my machine, but I don't

know for which purpose and as you pointed out in your other mail, we

are drifting off-topic :)

Hi everyone,

I also ran into this issue, where I've put all my packages in various profiles, with the default one being empty (outside of short-lived packages for trying out). This is a setup is mentioned in the cookbook, on profiles and manifests.

Since the dbus files are not in the default profile, I was running into issues with dbus seeing them with the default system daemon (from %desktop-services). As suggested above, one workaround is to use dbus-run-session to launch a program (no problems).

I found a better one for me, which may be due to how I run my desktop session. I use the default gdm but just an .xsession file (which is just my .xinitrc, like a plain startx setup). If I modify my WM start in the final line from just `exec WM` to `dbus-launch --exit-with-session WM` that works for me. Seems to be an issue of how the dbus daemon is run. Could also be a side effect from not adding the xsession properly to gdm, but I haven't tried with .desktop files yet. (Another work around suggested on IRC was to start a user daemon from the login profile; this didn't work for me.) Also note that I did have glib in the profile, so that XDG_DATA_DIRS was properly in the profile, and all profiles loaded at login.

Hope this is helpful and that we can find a proper solution, as I think this is a tricky bug to encounter for a user.

John

It looks like dbus-daemon-wrapper tries to take care of this by finding the user's profile, but this would just be the default one: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/xorg.scm#n851

Not sure if it is easy for the service to find a non-standard profile, or if this should be exposed some other way.

forcemerge 48538 51439

quit

forcemerge 48538 51438

quit