On Thu, Jun 28, 2018 at 12:01:12AM +0100, Stuart Henderson wrote: > On 2018/06/27 22:22, Landry Breuil wrote: > > >> dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NotSupported: > > >> Using X11 for dbus-daemon autolaunch was disabled at compile time, set > > >> your DBUS_SESSION_BUS_ADDRESS instead > > > > > > This is unlikely to be new with the update - autolaunch was disabled > > > because firefox. > > > > > > > I feel like I did see this before updating and I think fixed it previously > > because firefox. > > > > Are we just adding a pkg-readme for all such ports? > > tracking down all ports that might use dbus and adding a readme (and > keeping on top of this for future ports) seems pretty ridiculous..
I agree. But there is a difference between ports: some are *requiring* dbus (like gpodder, I dunno why, but it will not run without dbus and have code to check that) ; whereas some others doesn't bother if dbus session isn't started. > the firefox problem is that it's autolaunching dbus from a process which > has pledged that it won't start processes. so people that were relying > on firefox autolaunching dbus (rather than starting it themselves e.g. > from .xsession) were getting crashes. > > the workaround that was made was to change dbus to disable autolaunch, > but (as seen here) this causes problems for other ports. for firefox, the problem was a bit more complex than expected. with aja@, we look at dbus code, and disable autolaunch code. but several libraries were involved in the case of firefox: if libddbus.so had code for fork+exec "dbus-launch", libglib.so has too... so the configure option on dbus ./configure script was only a partial fix, and glib hasn't such possibility. but except the pledge problem with fork+exec, firefox is able to work well without dbus session. > landry, I know you hate wrapper scripts, but adding one for Firefox to > start dbus if needed and moving the dbus port back to autolaunch would > really seem a simple way to unbreak things (and I think probably a bit > more widely acceptable than "change /etc/X11/xenodm/Xsession to launch > dbus if present" would be ...) I think last patch on firefox workarounded efficiently fork+exec problem (setting DBUS_SESSION_BUS_ADDRESS if not present). so no wrapper script should be needed. So reenabling autolaunch on dbus port is possible and should not impact firefox. On the other side, it only hides the underline problem of dbus session. If I correctly understood have dbus-launch works, When a program starts it at program level (opposite to Xsession level), the session is only "local" to the program: only this particular program will speak with this dbus daemon. And it could result on starting a dbus session per program that could need it. I have already seen several dbus deamon running because starting several firefox -no-remote. The proper fix would be changing /etc/X11/xenodm/Xsession. But it should be done in proper way. Personally I would be in favor of generic code to load (shell sourcing) files in /etc/X11/xenodm/Xsession.d directory, with mecanism a-la "rcctl enable" to know which files are explicitly asked for inclusion. So dbus port would provide a /etc/X11/xenodm/Xsession/dbus.script file, and administrator would have to enable the inclusion of the file for make it sourced by /etc/X11/xenodm/Xsession.d thanks. -- Sebastien Marie
