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
