Hi, dbus is an object-oriented inter-process-communication mechanism.
On a typical single-user system there's one user bus, at least one session bus and one system bus. On a typical multi-user system there's multiple user buses, at least as many session buses and one system bus. From your messages I suspect that the dbus session bus for your session is not running. Try invoking echo $DBUS_SESSION_BUS_ADDRESS . If it's empty, no session bus is running. Many many GNOME parts try to use dbus for everything (also arguably for things which would work perfectly well without dbus, but whatever). dbus-launch is used to start a message bus from a shell script. It's usually chained together like this (that's how I use it for real): $ exec dbus-launch ssh-agent fluxbox This means that dbus-launch will set up some environment variables, invoke the daemon and then invoke dbus-daemon and then invoke the child (here, ssh-agent, passing it "fluxbox"), passing it the environment. If you invoke "dbus-launch evince" it's starting a mini-session bus and in there invokes evince. Evince then cannot connect to the other services in your session (because there are no other such services in this mini-session). I think modifying the slim service to use dbus-launch when starting the session should have worked just fine. >> I tried modifying the slim service to launch the session with > dbus-launch, but that only served to create some new errors when running > pcmanfm: Yes, but what does echo $DBUS_SESSION_BUS_ADDRESS say now? > invoking IsSupported() failed for remote volume monitor with dbus name ^^^^^^ ??? Also, here, it's not finding lots of service files. Something needs to make sure that the dbus daemon finds the service files. Usually we have an environment variable for that (see further below). There are system services in /etc/dbus-1/system-services which should be found in all cases. Among those is org.freedesktop.UDisks2 which is not org.gtk.vfs.UDisks2VolumeMonitor . org.gtk.vfs.UDisks2VolumeMonitor is not in the directory /etc/dbus-1/system-services . Then there's the ~/.guix-profile/share/dbus-1/services directory. ~/.guix-profile/share is one of the XDG_DATA_DIRS. dbus-specification.xml specifies that $XDG_DATA_DIRS/dbus-1/services is to be searched by the user bus. But this directory only contains files of packages that I personally installed into my profile - not of the dependencies. In this case I didn't install the package of org.gtk.vfs.UDisks2VolumeMonitor - so the service file resides in /gnu/store/85ih21qjgqcicjkqkw5v96wjvh9hq9g3-gvfs-1.32.1/share/dbus-1/services/org.gtk.vfs.UDisks2VolumeMonitor.service . I wonder why it works with the GNOME desktop. Does it really? Possible workaround: youruser$ guix package -i gvfs Possible fix: Make nautilus and other Guix packages using gvfs propagate gvfs. Possible different fix: Add profile hook which also automatically provides service files of dependencies without installing the packages into the profile. I'm not sure how useful that it since dbus will prefer a running service to service files anyway (I think). But at least we would notice a conflict. Also, is it able to statically determine what these dependencies are?
pgpC9tVOTb2g7.pgp
Description: OpenPGP digital signature