Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
bluez-libs and bluez-utils both emerge fine with a version bump. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created an attachment (id=37498) [details] bluez-utils-2.10.ebuild
Created an attachment (id=37499) [details] bluez-libs-2.10.ebuild
what still needs to be done: /etc/init.d/bluetooth should be redone, i am still experimenting with it
Created an attachment (id=37534) [details] bluez-utils-2.10.ebuild bluez-utils new version
Created an attachment (id=37535) [details] bluetooth.rc-2.10 this is the new init.d/bluetooth for bluez-utils-2.10.ebuild
Created an attachment (id=37897) [details] sdp-patch ...and, of course, the updated sdp-patch, as bluez 2.10 doesn't have lsdp anymore. And so we will compile the plugin without it. Bluetooth works though.
Oops, I forgot to mention, that this sdp-patch is intended for multisync-users and not for the bluez-packages. I have added the patch to this bug-description, because, multisync 0.82 doesn't compile with bluez 2.10 anymore and needs the above patch. The patch simply addresses people, who search for bluez 2.10-related bugs with multisync. :) This patch has to be applied to multisync!!!
qui gon, would you please attach the multisync sdp patch in another bug so it doesn't get lost? thanks florian for the new init scripts, i'm going to roll them into the next -r1 release. however, you forgot to include the /etc/conf.d/bluetooth file, but i'll make one up myself.
qui gon, don't worry about making a new bug, there already is one for bug 63743
Created an attachment (id=40070) [details] Enables bluez.org bluetooth config file Alastair, there is a suitable bluetooth config file included with bluez-utils-2.10. This ebuild will install it into /etc/conf.d.
I've made my bluetooth init script a mix of Florian's and the bluez.org one. The only real difference I have is that rfcomm is not started as a daemon. If RFCOMM_ENABLE is set to true it calls rfcomm bind all in start() and rfcomm release all in stop().
*** Bug 39464 has been marked as a duplicate of this bug. ***
committed to 2.10-r1 with some modifications, thanks for all your contributions!
i should close it, damn