Re: [DNG] Mass bug filing: use and misuse of dbus-launch (dbus-x11)
Hi! I read this great Devuan ML whenever I have time, and am still so excited to be using Devuan some day, but am slow to learn things (am almost 60 and started less then 20 ys ago, before that I was not a computer user at all... and I work slow like a turtle.) The original that I was able to find: [ same title as this Steve Litt's message I'm replying to ] https://lists.debian.org/debian-devel/2016/09/msg00056.html (and a backup for future reference, just in case: http://osdir.com/ml/debian-devel/2016-09/msg00056.html ) I'd need more time to understand the full details of this message (reported in its entirety below, I believe): On 160905-12:47-0400, Steve Litt wrote: > On Sun, 4 Sep 2016 17:30:43 +0100 > Jonathan de Boyne Pollard > wrote: > > > Simon McVittie: > > > > > This can already work. If you put XDG_RUNTIME_DIR in user programs' > > > environment, and arrange for your favourite service manager to make > > > a dbus-daemon (or something else that speaks the same protocol) > > > listen on $XDG_RUNTIME_DIR/bus before any user process would try to > > > connect to it, then modern versions of at least libdbus, GDBus and > > > sd-bus will connect to it by default with no additional effort on > > > your part. This client-side code path does not depend on systemd, > > > does not depend on libsystemd (except obviously sd-bus which is > > > part of libsystemd), and is compiled in for all supported Unix > > > platforms. > > That's the problem. No the whole unix:runtime=yes mechanism is not. > > As I said, this is something that you and Joe Marcus Clarke and > > whomever else have to sort out with each other. I'm unfortunately > > stuck in the middle, here. Please do whatever it is that you need to > > do with each other to make your program understand address=systemd: > > and address=unix:runtime=yes on FreeBSD/TrueOS/OpenBSD. It does not > > do so. > > > > Simon McVittie: > > > > > Meanwhile, if you want the relevant integration files (your > > > favourite service manager's equivalent of systemd units) to be part > > > of dbus (the reference implementation of D-Bus), please propose > > > tested patches; if they follow the "user session" model[1], they > > > could eventually go in dbus-user-session.deb, with its dependencies > > > changed from the current systemd-sysv to "systemd-sysv | > > > your-service-manager". > > Kudos for being the first project to offer integration, ever. (-: > > Danger Will Robinson. > > "Integration" in cases of systemd and its venus fly trap, dbus, is more > Embrace, Extend, Extinguish than integration. The Rube Goldbergesque > system described in the preceding quoted context exquisitely highlights > that fact. I like the statement above so much. That's what I felt it was pretty soon, really more like felt than understood, and I was so right... Well: I vaguely but impressively understood, as user. > > Do not cooperate with systemd. The systemd proponents don't cooperate > with anyone else. So right! And the other Steve's remarks below... > > > > Yes, down the road it would be marvellous if people included service > > bundles in their own projects. > > What would be marvellous is if people would simply ignore systemd, > opting for a real init system (not a conglomeration of welded krap > trying to supercede what we've had for years). > > > Yes, I'd like to see the day when the > > number of service bundles in the nosh-bundles package actually starts > > going down, because people are taking on shipping their own service > > bundles for their own services, instead of going up. So yes, > > eventually you'll be taken up on that offer I hope. But one step at a > > time. > > Ooo, "service bundles." My runit run scripts average about 6 lines > long. Any fool can make them. Behold the power of a real init: An init > that knows it's an init, and does only what inits are designed to do. I > highlight runit out of familiarity, but my use of s6 and Epoch indicate > that both are equally as simple, when defining service startup, runit. > > > > > Simon McVittie: > > > > >> As for what I would like, I'd like you (where that's plural, > > >> including Joe Marcus Clarke or whomever else) to please make > > >> either address=systemd: or address=unix:runtime=yes work in your > > >> program on FreeBSD/PC-BSD/OpenBSD. > > >> > > > 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. Joe Marcus Clarke is > > the porter for FreeBSD, according to the por
Re: [DNG] Mass bug filing: use and misuse of dbus-launch (dbus-x11)
On Sun, 4 Sep 2016 17:30:43 +0100 Jonathan de Boyne Pollard wrote: > Simon McVittie: > > > This can already work. If you put XDG_RUNTIME_DIR in user programs' > > environment, and arrange for your favourite service manager to make > > a dbus-daemon (or something else that speaks the same protocol) > > listen on $XDG_RUNTIME_DIR/bus before any user process would try to > > connect to it, then modern versions of at least libdbus, GDBus and > > sd-bus will connect to it by default with no additional effort on > > your part. This client-side code path does not depend on systemd, > > does not depend on libsystemd (except obviously sd-bus which is > > part of libsystemd), and is compiled in for all supported Unix > > platforms. > That's the problem. No the whole unix:runtime=yes mechanism is not. > As I said, this is something that you and Joe Marcus Clarke and > whomever else have to sort out with each other. I'm unfortunately > stuck in the middle, here. Please do whatever it is that you need to > do with each other to make your program understand address=systemd: > and address=unix:runtime=yes on FreeBSD/TrueOS/OpenBSD. It does not > do so. > > Simon McVittie: > > > Meanwhile, if you want the relevant integration files (your > > favourite service manager's equivalent of systemd units) to be part > > of dbus (the reference implementation of D-Bus), please propose > > tested patches; if they follow the "user session" model[1], they > > could eventually go in dbus-user-session.deb, with its dependencies > > changed from the current systemd-sysv to "systemd-sysv | > > your-service-manager". > Kudos for being the first project to offer integration, ever. (-: Danger Will Robinson. "Integration" in cases of systemd and its venus fly trap, dbus, is more Embrace, Extend, Extinguish than integration. The Rube Goldbergesque system described in the preceding quoted context exquisitely highlights that fact. Do not cooperate with systemd. The systemd proponents don't cooperate with anyone else. > Yes, down the road it would be marvellous if people included service > bundles in their own projects. What would be marvellous is if people would simply ignore systemd, opting for a real init system (not a conglomeration of welded krap trying to supercede what we've had for years). > Yes, I'd like to see the day when the > number of service bundles in the nosh-bundles package actually starts > going down, because people are taking on shipping their own service > bundles for their own services, instead of going up. So yes, > eventually you'll be taken up on that offer I hope. But one step at a > time. Ooo, "service bundles." My runit run scripts average about 6 lines long. Any fool can make them. Behold the power of a real init: An init that knows it's an init, and does only what inits are designed to do. I highlight runit out of familiarity, but my use of s6 and Epoch indicate that both are equally as simple, when defining service startup, runit. > > Simon McVittie: > > >> As for what I would like, I'd like you (where that's plural, > >> including Joe Marcus Clarke or whomever else) to please make > >> either address=systemd: or address=unix:runtime=yes work in your > >> program on FreeBSD/PC-BSD/OpenBSD. > >> > > 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. Joe Marcus Clarke is > the porter for FreeBSD, according to the port information, and > Antoine Jacoutot the porter for OpenBSD. To the *BSD communities: Please do not let the systemd camel get his nose in your tent. Systemd is a repudiation of everything Unix, created by a guy who makes no bones of his hate for Posix. > This is why I am saying > that it's something that you (plural, remember) need to sort out > amongst yourselves. We users stuck in the middle cannot use > address=systemd: and address=unix:runtime=yes with your program on > these systems. As I said, it's something that I had to fix in > November 2015, to stop trying to use address=systemd: on > FreeBSD/TrueOS because it turned out that it didn't actually work. I > thought that address=unix:runtime=yes might, but that did not either. > [snip] > > Simon McVittie: > > > To be brutally honest, there is a fairly low limit to how much > > benefit I can create by giving new things to PC-BSD users, [...] > > > That's not the right way to look at it. This is precisely the right way to look at it, when it pertains to systemd. > You yourself have just said > several tim
