[MacPorts] #17950: dbus patched with launchd support and version dump

[MacPorts]

#17950: dbus patched with launchd support and version dump
---------------------------------+------------------------------------------
  Reporter:  jonas.baehr@…       |       Owner:  macports-tickets@…                   
      Type:  enhancement         |      Status:  reopened                             
  Priority:  Normal              |   Milestone:  Port Enhancements                    
 Component:  ports               |     Version:  1.7.0                                
Resolution:                      |    Keywords:  launchd kde4 x11                     
      Port:  dbus                |  
---------------------------------+------------------------------------------

Comment(by jonas.baehr@…):

 Replying to [comment:35 mta@…]:
 > Is the log snippet you quote from a case where dbus launched gconfd-2 or
 was it already running?  I presume it was already running.

 Sorry, I messed up server and client here. gconfd-2 was not running, but
 the log snipped is from gconf-editor, not gfoncd-2.

 > If dbus launches it, then gconfd-2 gets the service address from the
 environment variable DBUS_SESSION_BUS_ADDRESS.  This is set in
 add_bus_environment which is called from bus_activation_activate_service
 before it launches gconfd-2.  The value for DBUS_SESSION_BUS_ADDRESS is
 taken from activation->server_address from the activation struct passed to
 bus_activation_activate_service.  This is a "launchd:..." type address.
 The real question is should it be this type of address or should it be a
 "unix:..." style address.  I.e., is the bug in the creation of the
 activation struct or is it that there needs to be a handler added to
 open_funcs in dbus-transport.c for the "launchd:..." address that's in it.

 Now we're comming nearer! In fact, the DBUS_SESSION_BUS_ADDRESS evn-var is
 treated with priority, to that one can always override launchd. However,
 if it's not present, then launchd is asked. That's why it works when
 starting gconfd-2 manually (assuming there is ''no'' env-var). If the
 client has such an env-var set, it's the correct behaviour to pass it to
 the newly starting service.

 I think the solution is to ask launchd for the address if
 DBUS_SESSION_BUS_ADDRESS is not set, ''or it contains a launchd:
 address''. The latter is currently not the case. I'll fix that.

 Thanks a lot for your analysis!

-- 
Ticket URL: <http://trac.macports.org/ticket/17950#comment:36>
MacPorts <http://www.macports.org/>
Ports system for Mac OS