Date: Sun, 4 Sep 2016 17:30:43 +0100 From: Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.com> To: Joe Marcus Clarke <marcus@FreeBSD.org> Cc: debian-devel@lists.debian.org, FreeBSD Hackers <freebsd-hackers@freebsd.org>, "supervision@list.skarnet.org" <supervision@list.skarnet.org>, Antoine Jacoutot <ajacoutot@openbsd.org> Subject: Mass bug filing: use and misuse of dbus-launch (dbus-x11) Message-ID: <c81b5955-7ef7-10df-03e3-e2807f99465d@NTLWorld.com> In-Reply-To: <20160831104556.mihpyoi3lodnikmw@perpetual.pseudorandom.co.uk> References: <20160831104556.mihpyoi3lodnikmw@perpetual.pseudorandom.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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. (-: Yes, down the road it would be marvellous if people included service bundles in their own projects. 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. 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. 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. Simon McVittie: > I am *not* going to go looking for patches on display at the bottom of > a locked filing cabinet stuck in a disused lavatory with a sign on the > door saying "beware of the leopard"; > Luckily, you didn't need to. The page that I hyperlinked before pointed directly to Pierre-Yves Ritschard's and Cameron T. Norman's actual code, even down to positioning the window around the first lines of the functions. Now if one *did* want to follow the Debian way of having mention of these things buried down in the depths, in a bug report from years ago, then this is a truly excellent example of the genre that one could enjoy. One should begin with Cameron T. Norman's post here, roughly one thousand eight hundred messages down, in a bug report from 3 years ago: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#1859 (-: 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. 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. I shouldn't dismiss PC-BSD so readily, if I were you, either. PC-BSD (now rebranded as TrueOS Desktop a few days ago -- I just got through changing a whole load of preset file and -run package names.) is the BSD that comes in the box with the desktop environments and with all of the desktop programs that use Desktop Bus. Yes, people can and do run all of this stuff on FreeBSD and OpenBSD from ports. But PC-BSD^H^H^H^H^H^H ... Gah! ... TrueOS Desktop is where it comes in the box and is run as standard in the default install. TrueOS Desktop is where one ends up choosing from running PCDMd, kdm, lxdm, or gdm; and where one gets lots of little Desktop Bus brokers all over the place in various ways from these different systems. TrueOS Desktop is where the people who are behind the operating system will be strongly motivated towards improving the desktop subsystems and the Desktop Bus. You're pushing your new way of per-user Desktop Bus brokers at the world. I can give the TrueOS Desktop people, and the the UbuntuBSD people, and the Debian FreeBSD people, a service management system that I know can run per-user Desktop Bus brokers on a FreeBSD kernel. It already does. I published it last year. If you, the Desktop Bus people, can give us these mechanisms in your program actually working on these operating systems, then the TrueOS people get the opportunity to simplify some of the scaffolding that they have had to erect (PCDM-session writing out nonce scripts that invoke dbus-launch, for example), and you get less of the world still using your old way of doing things.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c81b5955-7ef7-10df-03e3-e2807f99465d>