After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 690523 - launchd support for finding the bus
launchd support for finding the bus
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: gdbus
2.34.x
Other Mac OS
: Normal normal
: ---
Assigned To: David Zeuthen (not reading bugmail)
gtkdev
Depends on:
Blocks:
 
 
Reported: 2012-12-19 19:52 UTC by Daniel Macks
Modified: 2018-05-24 14:54 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Daniel Macks 2012-12-19 19:52:17 UTC
gdbusconnection.c has a comment:

> Need to document other mechanisms/sources for determining the D-Bus address of a well-known bus.
> on OS X we need to look in launchd for the address
> https://bugs.freedesktop.org/show_bug.cgi?id=14259

I couldn't find a bugzilla item for that, so here we are (gives an easy place to direct downstream packagers/users). Conceptually, seems like the processing and platform features would go in gdbusaddress.c (rather than gdbusconnection.c) to figure that out, but until there's an implementation of something to do, that's moot.

libdbus is AFL2.1/GPL2 (reuser's choice). AFL sounds (and describes itself as) BSD/MIT-like, so is that compatible with being imported into glib? I can probably convince the main contributor to that bugzilla.fdo item to contribute it here directly under LGPL rather than someone having to do a cleanroom reimplementation, but would obviously be even better to use that project's current codebase (bugfixes and improvements) instead of the submitted original.
Comment 1 David Zeuthen (not reading bugmail) 2012-12-19 20:09:09 UTC
Thanks for filing the bug, that's definitely useful. 

As for making forward progress, I wouldn't worry so much about code right now because I think what I said in https://bugs.freedesktop.org/show_bug.cgi?id=14259#c87 pretty much still stands: the D-Bus spec does not explain how to find the session bus address. That said - especially since the bug is marked as fixed - I do believe that the code-parts are there. So I think it's mostly a matter of documenting it.

So what needs to happen? We need to get it into the spec in the "Well-known Message Bus Instances" chapter, this one

 http://dbus.freedesktop.org/doc/dbus-specification.html#message-bus-types

E.g. the same way there's an "X Windowing System" chapter explaining what atoms to look at (the stuff involving _DBUS_SESSION_BUS_SELECTION_), there needs to be a "Max OS X" chapter explaining exactly how to get the address.

Once it's in the spec, we can look at making GDBus follow the spec and check that we interoperate with libdbus-1.so / dbus-daemon(1) and so on.
Comment 2 Christian Persch 2012-12-19 22:05:24 UTC
(In reply to comment #0)
> libdbus is AFL2.1/GPL2 (reuser's choice). AFL sounds (and describes itself as)
> BSD/MIT-like, so is that compatible with being imported into glib? I can
> probably convince the main contributor to that bugzilla.fdo item to contribute
> it here directly under LGPL rather than someone having to do a cleanroom
> reimplementation, but would obviously be even better to use that project's
> current codebase (bugfixes and improvements) instead of the submitted original.

AFL is incompatible to GPL/LGPL, see https://www.gnu.org/licenses/license-list.html#AcademicFreeLicense .
Comment 3 Daniel Macks 2012-12-21 05:31:38 UTC
(In reply to comment #1)
> the D-Bus spec does not explain how to find the session bus address.
> That said - especially since the bug is marked as fixed - I do believe that the
> code-parts are there. So I think it's mostly a matter of documenting it.

Filed as https://bugs.freedesktop.org/show_bug.cgi?id=58601
Comment 4 GNOME Infrastructure Team 2018-05-24 14:54:49 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/647.