On 08/01/18 07:54, Danny Milosavljevic wrote: > 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 I've always had gvfs installed and it hasn't made any difference as far as I can tell > > 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?
Previously there was no $DBUS_SESSION_BUS_ADDRESS. After I modified slim to add dbus-launch, I have DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-Rc7AP3Xnzz,guid=97d26aba11773a9ce755829b5b611375 but it didn't fix the issue, and caused those weird errors. Actually I'm not getting those errors anymore, maybe due to reconfiguring and rebooting. When I run `dbus-launch bash` , it overwrites that value with a new value in the current environment: unix:abstract=/tmp/dbus-1vzMgxAURi,guid=98eb63bd2e22340a0c1d3bd85b6116d5 and then running pcmanfm/evince only from that bash shell works fine, running outside it or from dmenu doesn't.
