Bug#510644: [Pkg-bluetooth-maintainers] Bug#510644: bluetooth.conf needs alterations for new D-Bus

2009-01-07 Thread Colin Walters
On Wed, Jan 7, 2009 at 2:17 PM, Simon McVittie simon.mcvit...@collabora.co.uk wrote: Unfortunately they don't a well known service name nor object path, agents are user-registered Never mind. We have a lot of these rules in the archive anyway

Bug#510644: [Pkg-bluetooth-maintainers] Bug#510644: bluetooth.conf needs alterations for new D-Bus

2009-01-07 Thread Colin Walters
On Wed, Jan 7, 2009 at 3:09 PM, Simon McVittie simon.mcvit...@collabora.co.uk wrote: As far as I can tell, BlueZ agents work like this: * the agent (a UI process run by a user) calls a method on the hci daemon (run by root) and passes in its unique name and its (arbitrary) object path *

Bug#510644: [Pkg-bluetooth-maintainers] Bug#510644: bluetooth.conf needs alterations for new D-Bus

2009-01-07 Thread Colin Walters
On Wed, Jan 7, 2009 at 6:25 PM, Simon McVittie simon.mcvit...@collabora.co.uk wrote: As a solution for the current release of BlueZ, assuming that rethinking the Agent API completely is not an option, does the proposed policy at

Bug#510644: [Pkg-bluetooth-maintainers] Bug#510644: bluetooth.conf needs alterations for new D-Bus

2009-01-07 Thread Colin Walters
On Wed, Jan 7, 2009 at 6:41 PM, Marcel Holtmann mar...@holtmann.org wrote: that is exactly how it works and we can't use signal. Even directed signal are not working since the method call into the agent has to return the result or an error. What problem do you guys actually have with this?