Re: Mass bug filing: use and misuse of dbus-launch (dbus-x11)
On Sun, 04 Sep 2016 at 17:30:43 +0100, Jonathan de Boyne Pollard wrote:
> Simon McVittie:
> > To the best of my knowledge, the listenable address "unix:runtime=yes"
> > (as in "dbus-daemon --address=unix:runtime=yes") does work on generic
> > Unix, and should interoperate fine with the XDG_RUNTIME_DIR/bus fallback
> > used by clients with no DBUS_SESSION_BUS_ADDRESS. It is compiled and
> > tested whenever DBUS_UNIX is defined (i.e. everything except Windows),
> > and I haven't seen bug reports about that test failing.
> >
> There you go, then. New knowledge. (-: It doesn't work with your program
> as ported to FreeBSD/TrueOS/OpenBSD.
The D-Bus bug tracking system is over here:
<https://bugs.freedesktop.org/enter_bug.cgi?product=dbus&component=core>
Please follow the traditional bug-reporting template (steps to reproduce,
expected result, actual result). Tested patches are also welcome.
(As the commit message[1] says, unix:runtime=yes is intended to fail
if XDG_RUNTIME_DIR is unset; that's not considered to be a bug.)
If you want patches applied to dbus (the reference implementation of
D-Bus), please submit those patches for review in its bug tracking
system, in a bug report that describes the bug or missing feature that
those patches address. Links to your personal website, written in a form
that ensures that typical web browsers will reject the SSL certificate,
in a thread on the Debian mailing list for the development of Debian,
are not a recommended form of upstream patch submission - doubly so
for issues that specifically involve OSs that are not Debian and so
are off-topic for this mailing list.
Linking to other people's implementations of sd_listen_fds() is also
not a useful form of upstream patch submission. I am well aware that
it is possible to implement an API equivalent to sd_listen_fds() on
non-Linux OSs. I do not run those other OSs, and I am not going to test
dbus on those other OSs, so a link that effectively says "you could
do it something like this" is not particularly helpful: the proposed
change needs to be sufficiently specific that someone who *does* run
the relevant OS can easily test it. Until that testing is done, the
change won't be merged.
If you are more interested in those other OSs than I am, and want to
contribute tested improvements for them, please do so. If you want to
encourage others to contribute those improvements, or pay someone to do
so, that's also fine. However, debian-devel is not an appropriate
venue for any of those activities.
[1] https://cgit.freedesktop.org/dbus/dbus/commit/?h=dbus-1.10&id=e3f117e7610b0e0a91dfe5bff7bf2e217c129a86
> That's not the right way to look at it. You yourself have just said several
> times that this is stuff that is supposed to be on "supported Unix
> platforms". This isn't giving new things to anyone. This is making
> existing things, that you yourself think are existing, work.
As far as I'm aware, "the old way" - involving dbus-launch - works the
same on BSD as it does on Linux, and works the same on BSD in dbus 1.10
as it did in dbus 1.0.
The unix:runtime=yes listenable address is a new feature in 1.10.0
(actually 1.9.x, but that was an unstable development branch that led
to 1.10.x). As far as I'm aware, it works as intended on all Unix
platforms. Regardless of whether that is true or not, it does not
affect whether the previously-supported listenable addresses work on
those platforms.
unix:runtime=yes is not intended to work in the absence of an
XDG_RUNTIME_DIR; if your platform doesn't routinely set that variable
for user processes, and you have not taken any special steps to set it
in the dbus-daemon's environment, then attempting to listen on
unix:runtime=yes will fail. This is equally true on Linux and non-Linux.
> You're pushing your new way of per-user Desktop Bus brokers at the world.
This is the debian-devel mailing list, for the development of Debian.
I am one of Debian's dbus maintainers, and I would like Debian to default
to the user-bus model, at least for new installations on the Linux kernel.
Whether other operating systems do the same is up to the people with the
equivalent role in those other operating systems.
I don't find Debian's non-Linux ports particularly interesting, and
they are certainly not a majority configuration or one that I would
recommend to inexperienced users, so I don't consider changing the
default on those ports to be equally important. Some people consider
those ports to be important, and those people are invited to provide
tested patches. That bug tracker link again:
<https://bugs.freedesktop.org/enter_bug.cgi?product=dbus&component=core>
Non-Debian operating systems are not relevant to this mailing list, and
I regret getting drawn in to your discussion of them. Other operating
systems' dbus maintainers should make their own decision whether
their particular OS has a login-session bus or a user bus, and
contribute any patches that might be needed to make their chosen
interaction possible. The Arch Linux dbus maintainer did exactly that.
If *BSD dbus maintainers want to do the same, I've already mentioned
where the upstream bug tracker is.
> If you, the Desktop Bus people, can give us these
> mechanisms in your program actually working on these operating systems
> [...] you get less of the world still using
> your old way of doing things.
There are all sorts of contributions to Free Software that I could make
if my time, attention, skills and patience were unlimited, but since
there are limits to all of those, I have to prioritize. I work on D-Bus
partly because it's interesting, partly because it's an important part
of the OS I rely on (namely Debian GNU/Linux), and partly because my
employer considers it to be important to the projects I get paid for.
Porting to non-Linux is not a high priority for any of those reasons -
I don't find it fun, it doesn't benefit the Debian ports that I consider
to be most practically useful, and my employer doesn't pay me to support
alternative kernels. I'm willing to review tested patches, because that's
part of the job of being a maintainer, but I don't intend to write them.
If this is more important to you than it is to me, great - contribute
tested patches, or pay someone to do so.
S
Reply to: