Dear Mark.

Thanks for looking at this!

Mark Hindley - 06.03.23, 12:52:08 CET:
> On Sun, Mar 05, 2023 at 09:59:35AM +0100, Martin Steigerwald wrote:
> > Package: dbus-x11
> > Version: 1.14.6-1devuan1
> > Severity: normal
> > X-Debbugs-Cc: Martin@???
> >
> > Dear Maintainer,
> >
> > I also reported this to Debian as
>
> Simon McVittie's is, of course, correct that src:dbus being forked in
> Devuan means this should be dealt with in Devuan. Notwithstanding
> that, I am very grateful for his thorough, considered and
> illuminating reply. The same behaviour is evident in a non-systemd
> Debian installation.

Yeah. Lorenzo confirmed this as well. He was able to replicate the issue
on a Debian installation.

> Like Simon, I have no experience of KDE or krunner. I also agree that
> legacy DBus activation appears to be working here as intended and
> documented, with no guarantee on the cwd given.

Again: it is a kind of quick application starter. You press Alt-Space,
enter something, it offers a variety of matches, you select one and press
enter or just press enter to use the first match and that's it. If
krunner's pwd is "/" then the application it started usually also has
"/". Which means any file dialog started from it will have "/".

Additionally meanwhile I found that when I print a web site to PDF in
Firefox the file dialog also starts with "/". This could be due to

export GTK_USE_PORTAL=1

in order to use KDE based file dialog with Firefox and other apps that
use GTK.

None of this breaks the system. It just makes it more cumbersome to use.

I also wonder whether only Plasma desktop is affected.

> My gut reaction is that this issue is should really be resolved
> elsewhere. If it is crucial that krunner uses a particular working
> directory, then it needs to chdir() explicitly itself.

I understand. I add this this suggestion to the KDE bug report. However
as noted above: Besides KRunner some other processes appear to be
affected. So it would be required to file an upstream report with any of
those affected components. Might be the cleanest approach still.
Especially as long as there are no guarantees.

I always thought that anything within a user session is using $HOME as
pwd, but apparently that does not seem to be guaranteed or documented.
And it may have been like that back in the days where almost everything
related to a user desktop session was started from one place that
started out from $HOME and all the child processes inherited pwd from
that place.

It appears that for systems with other init systems there does not seem
to be a consistent approach to handle this.

> I also quite understand his concern that changing the behaviour of
> DBus may have unintended consequences and I am certain that changing
> the behaviour of DBus during the freeze will not happen. I suppose
> early in the next cycle is possible. […]

Sure.

As I think that Simon is right and it is indeed is "/etc/X11/Xsession.d/
75dbus_dbus-launch" that started the session dbus. I mismatched the
arguments and while I saw a third DBUS running under the user
"messagebus" I did not make the connection that this is the one that is
started by the runit service dir.

So my next approach would be to play around with "/etc/X11/Xsession.d/
75dbus_dbus-launch". First step would be to figure out whether "$HOME" is
set to the session user home directory in that script. If yes, I'd try
changing working directory to $HOME. If not… I am not sure, I may still
go for changing pwd to the home directory of the main user of my system
to actually verify whether this would be working as a work-around.

Will report back once I know more.

> Simon, might the implications of that be reviewed again upstream? I
> found an upstream issue with patch to implement such behaviour that
> has not been merged[1].

Interesting. That is from 4 years ago already.

> [1] https://gitlab.freedesktop.org/dbus/dbus/-/issues/214

Thanks,
--
Martin