Summary: | net-wireless/bluez: Change /etc/dbus-1/system.d/bluetooth.conf to allow users | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Markus Strobl <mstrobl2> |
Component: | Current packages | Assignee: | Tiziano Müller (RETIRED) <dev-zero> |
Status: | VERIFIED WONTFIX | ||
Severity: | normal | CC: | mobile+disabled, pda |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Corrected bluetooth.conf |
Description
Markus Strobl
2009-03-10 04:05:42 UTC
Created attachment 184522 [details]
Corrected bluetooth.conf
Here's my bluetooth.conf that allows bluetooth to work.
Reassigning to maintainer, CCing mobile and pda herds. great idea! and let a user own org.bluez, so any local user can setup a fake bluetoothd to sniff your pin and therefore your data. Sorry for the sarcasm but I spent more than two weekends figuring out how things work, convincing people that they work that way and fixing packages. To make it short: "at_console" does what's needed. The only thing you and/or the kde-team have to make sure is that ConsoleKit is installed, setup and ready. I now added pambase[consolekit] as RDEPEND to bluez to pull in the minimum required to have consolekit running. Therefore: try to reinstall bluez which should now pull in pambase[consolekit] and see whether it works. If it doesn't, reopen this bug but assign it to kde this time. In fact, kbluetooth4 needs to be fixed to not crash on the unavailability of the dbus interface. But that's another issue you should report upstream... Yep, consolekit indeed fixes it and let me revert bluetooth.conf back to its original content. |