dbus supports also so called agent. at least the enviroment variable is set: dbus-launch manual mentions: Here is an example of how to use dbus-launch with an sh-compatible shell to start the per-session bus daemon: ## test for an existing bus daemon, just to be safe if test -z "$DBUS_SESSION_BUS_ADDRESS" ; then ## if not found, launch a new one eval `dbus-launch --sh-syntax --exit-with-session` echo "D-BUS per-session daemon address is: $DBUS_SESSION_BUS_ADDRESS" fi Reproducible: Always
This is started by the various DEs, is it really necessary in keychain?
why not :) my DE doesn't. i have copied script from manualpage, but that doesn't inherit, but starts new one. besides keychain has very nice feature of attaching to a dead session, regular DE's can't do that. they see if no agent is present in ENV, they start new one.
why did this got re-assigned to fdo, are we supposed to maintain keychain or what ?
This bug is a request to add keychain support to dbus package as far as I know. I re-assigned because dbus and keychain are not maintainer-needed stuff.
I read for, not to. I don't see how dbus could use keychain in anyway, really.
keychain could support dbus sessions inheritance, not vice versa.
Definitely not an fdo bug. If anything, keychain should probably provide an xinitrc.d file like seahorse-agent does. Thanks
Daniel, Please weigh in on this bug. Thx.
I won't be adding dbus support to keychain. keychain is focused specifically on authentication services. You could use a similar approach for dbus (probably a good starting point would be the keychain 1.0 source code) but this would be a separate project.
(In reply to comment #9) > I won't be adding dbus support to keychain. keychain is focused specifically on > authentication services. > > You could use a similar approach for dbus (probably a good starting point would > be the keychain 1.0 source code) but this would be a separate project. > I agree. thx for the comment, as upstream author.
