Le 02/02/2014 12:12, Christopher Schramm a écrit :
> I'd suggest checking /etc/dbus-1/system.d/bluetooth.conf for the
> following lines:
>
> <policy at_console="true">
> <allow send_destination="org.bluez"/>
> </policy>
>
> This allows users with the at_console right access to the org.bluez bus.
> The at_console right should be set by consolekit for local users by
> default. You could try to remove the at_console requirement to check if
> your user is lacking it. That would be a consolekit issue then. (Or
> maybe you are just not logged in locally? Then it would be the expected
> behavior.)
I have that chunk of configuration, and:
jpuydt@newton:~$ ck-list-sessions
Session2:
unix-user = '1000'
realname = 'Julien Puydt'
seat = 'Seat1'
session-type = ''
active = TRUE
x11-display = ':0'
x11-display-device = '/dev/tty7'
display-device = ''
remote-host-name = ''
is-local = TRUE
on-since = '2014-01-26T12:42:19.777255Z'
login-session-id = '1'
I changed the configuration to at_console='false', restarted dbus and
bluetooth, and blueman-browse accepted to run!
So for some reason is-local from consolekit and at_console from dbus
don't match. It indeed looks like blueman isn't the real problem here...
it's further up.
It reminds me of another bug I opened:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729134
where I must admit I don't know what the conclusion exactly is!
Can this bluetooth issue also be related to bad interactions between
lightdm/systemd/dbus/consolekit (and who knows what else...) ?
Snark on #debian-science
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
