Summary: | =net-wireless/bluez-5.13 version bump request | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Manuel Rüger (RETIRED) <mrueg> |
Component: | Current packages | Assignee: | Pacho Ramos <pacho> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | CC: | account-removed-VCfTXVM1f239G8aIp11yGcPFPt72ytuW, alexander, bj.rn, bugs-gentoo, candrews, dlan, dschridde+gentoobugs, ford_prefect, leho, mail, naota, nikoli, nrndda, teidakankan, ville.aakko |
Priority: | Normal | Keywords: | InVCS, PMASKED |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 431488, 486484 | ||
Attachments: |
bluez-5.0.ebuild
Initial ebuild for bluez 5.9, made by a rookie net-wireless/bluez-5.9.ebuild Updated metadata.xml for bluez-5.9.ebuild net-wireless/bluez-5.10.ebuild OpenRC initscript for bluez-5.x net-wireless/bluez-5.11.ebuild |
Description
Manuel Rüger (RETIRED)
![]() http://www.bluez.org/bluez-5-api-introduction-and-porting-guide/ app-mobilephone/obexd net-wireless/bluez-hcidump were merged into bluez-5 Created attachment 335754 [details]
bluez-5.0.ebuild
I was working on this weeks ago but finally didn't had enough time to check new /etc installed files and where should they be placed
Release of BlueZ 5.2 2nd February 2013, 07:43 pm by Johan Hedberg This release fixes some issues with LE pairing and re-connections and also enables the possibility of connecting LE through the Device1.Connect D-Bus method. There is also a fix to the Profile interface where bluetoothd now waits for reverse SDP to complete before accepting a connection and calling the NewConnection D-Bus method (important so that the right profile version and features can be included in the method call). Besides the bug fixes there’s also more AVRCP 1.5 support related to volume control and browsing. Just updating bluez doesn't work. Bluedevil and other packages will need changes too because with 5.x the api changed quiet a bit. Here is a porting guide: http://www.bluez.org/bluez-5-api-introduction-and-porting-guide/ Note that, from 5.0 release notes: The new major version indicates that the API is not backwards compatible with BlueZ 4, which means that any applications, agents, etc will need to be updated so bluez may need version 4.x 5.x coexist in tree, a few ebuilds may still depend on old version, either using slot? or USE flag (bluez4, bluez5?) (In reply to comment #5) > Note that, from 5.0 release notes: > The new major version indicates that the API is not backwards compatible > with BlueZ 4, which means that any applications, agents, etc will need to be > updated > > so bluez may need version 4.x 5.x coexist in tree, a few ebuilds may still > depend on old version, either using slot? or USE flag (bluez4, bluez5?) The ebuild should use slots and consumers who have not yet upgraded should depend on bluez:4. "Release of BlueZ 5.3 23rd February 2013, 12:57 pm by Johan Hedberg This is mostly a bug fix release with several fixes and improvements to A2DP and AVRCP. There’s also a fix to the local adapter name setting, some fixes to SDP processing (thanks to newly implemented unit tests for the SDP library) as well as an update to the latest neard API to support NFC based pairing." Release of BlueZ 5.4 12th April 2013, 08:26 am by Johan Hedberg It has been a fairly quiet period since BlueZ 5.3 (hopefully meaning the current tree is in a pretty good shape and doesn’t have any major issues) but the amount of fixes and minor feature additions has now grown big enough to justify a new release. So here we go with BlueZ 5.4! It consists mostly of bug fixes but some new features have also crept in: Improved AVRCP 1.5 feature support (mostly player handling related) New key mappings for AVRCP Target role (for systems that need more than traditional playback control) Improved MAP client features, including Message Notification Service (MNS) Improved command line client (client/bluetoothctl) agent callback support Release of BlueZ 5.5 14th May 2013, 11:33 am by Johan Hedberg Again, mostly a bug fix release with fixes to SDP, AVRCP, NFC and name resolving during discovery. There are also some new features: New passthrough operations for AVRCP Auto-pairing (PIN lookup) support Proper HID reconnection support Besides these externally visible changes there was also a rather big refactoring patch-set that went in to establish a new “service” concept internally within bluetoothd and its plugins. This paves the way to have each remote service represented as a separate object through D-Bus, something which may already appear in the next BlueZ release. Release of BlueZ 5.7 27th June 2013, 07:25 am by Johan Hedberg We had unfortunately a couple of pretty severe regressions that had crept into 5.6 so we’ve released 5.7 earlier than planned. If you’ve started using 5.6 please switch to 5.7 as soon as possible, and if you haven’t yet picked 5.6 just ignore that release The regressions in question were related to remote service discovery for newly paired devices as well as the failure to parse some SDP responses (this happened with one Nokia headset). These issues are now fixed and since the last release we also managed to get in patches adding support for a MAP notification dispatcher. You can't have 4 and 5 coexist, so slotting isn't an option. Release of BlueZ 5.8 8th August 2013, 10:32 am by Johan Hedberg Here’s a new BlueZ release with mostly bug fixes to audio and OBEX related profiles. One notable feature addition is a low-priority SDP based service discovery that’s always done after connecting known profiles. The intention of this feature is to allow refreshing the list of remote services as there doesn’t exist any kind of explicit way to do this through the D-Bus API. Hello, I'm having trouble with my Bluetooth headset, and a Bluez dev. advised me to upgrade to bluez 5. Is there a way to have it instead of bluez 4 ? I tried the 'palmer' overlay which has bluez 5.7 ebuild, but I'd much prefer a stock solution. Thanks. (In reply to F. Delente from comment #13) > Hello, > > I'm having trouble with my Bluetooth headset, and a Bluez dev. advised me to > upgrade to bluez 5. Is there a way to have it instead of bluez 4 ? I tried > the 'palmer' overlay which has bluez 5.7 ebuild, but I'd much prefer a stock > solution. > > Thanks. Be warned that bluez-5 is incompatable with bluez-4 and that a lot of applications don't seem to work with version 5. Essentially I don't test that ebuild at all (aside from that it compiled once), so you're on your own :) Good luck! (In reply to F. Delente from comment #13) > Hello, > > I'm having trouble with my Bluetooth headset Try to comment this line in ebuild. Does it help? epatch -R "${FILESDIR}"/${P}-mgmt-update.patch I abandonned the 5.7/5.8 bluez idea after testing with a Live USB of Xubuntu, in which bluez is 4.98 and my headset was perfectly recognized instantly, even though I can't get it to work in Gentoo bluez 4.101-r6. Bluetoothd doesn't even want to start anymore, it bails with dbus[1059]: [system] Activating service name='org.bluez' (using servicehelper) dbus[1059]: [system] Activated service 'org.bluez' failed: Launch helper exited with unknown return code 1 "[...] One notable build related change in 5.9 is the removal of the libusb dependency. USB support in BlueZ is now fully self-contained and packages can drop any libusb dependency they might have had." http://www.bluez.org/release-of-bluez-5-9/ I really would like to have a recent bluez version on my gentoo box, for better wii support. Also see: http://dvdhrm.github.io/xwiimote/ (official gentoo portage tree has kernel 3.11 ebuild available) I have an initial ebuild for bluez-5.9, which compiles and installs, but is having its bugs. E.g. it doesn't start bluetoothd properly: htpc / # /usr/libexec/bluetooth/bluetoothd -n -E bluetoothd[558]: Bluetooth daemon 5.9 bluetoothd[558]: Starting SDP server bluetoothd[558]: Failed to open control socket: Protocol not supported (93) bluetoothd[558]: Can't init bnep module bluetoothd[558]: Failed to init network plugin bluetoothd[558]: Failed to open RFKILL control device bluetoothd[558]: Bluetooth management interface 1.3 initialized bluetoothd[558]: Can't listen at channel 8. bluetoothd[558]: sap-server: Operation not permitted (1) I am facing a couple of challenges: this is my first ebuild, bluez isn't perfectly documented at all, I'm not experienced with packaging for a distro/gentoo, I don't have much knowledge about dbus... and maybe more. Who can help me? (I'll attach the ebuild) Created attachment 360432 [details]
Initial ebuild for bluez 5.9, made by a rookie
My first ebuild for bluez 5.9, hopefully someone can help to get it to usable quality.
Created attachment 360442 [details] net-wireless/bluez-5.9.ebuild (In reply to Martin Herrman from comment #19) > Created attachment 360432 [details] > Initial ebuild for bluez 5.9, made by a rookie > > My first ebuild for bluez 5.9, hopefully someone can help to get it to > usable quality. Thanks a lot for this initial ebuild. I cleaned it up a bit and it works fine here using BlueDevil-9999 (bluez5 branch) as frontend. For those who want to give the bluez5 branch of BlueDevil a try, do this: export libbluedevil_LIVE_BRANCH=bluez5 export bluedevil_LIVE_BRANCH=bluez5 emerge -av '=net-wireless/bluedevil-9999' The -9999 ebuilds are available in the 'kde' overlay. Created attachment 360444 [details]
Updated metadata.xml for bluez-5.9.ebuild
(In reply to Elias Probst from comment #20) > > For those who want to give the bluez5 branch of BlueDevil a try, do this: > > export libbluedevil_LIVE_BRANCH=bluez5 > export bluedevil_LIVE_BRANCH=bluez5 > emerge -av '=net-wireless/bluedevil-9999' > > The -9999 ebuilds are available in the 'kde' overlay. Those who want to use PulseAudio + BlueZ 5.x, use =media-sound/pulseaudio-9999[bluetooth] Thanks for using my input! I reviewed the changes you made, I am learning :) Something that gave me a headache tonight: the ebuild is now depending on virtual/udev-204, while virtual/udev-200 is the current stable ebuild. I propose to change the dependency to virtual/udev-200, this will prevent update issues on systems running only stable ebuilds. I assume that the ebuild also has to be improved on the udev use flag: when not selected, no udev files can be installed and udev cannot be reloaded. Right? (In reply to Martin Herrman from comment #23) > Thanks for using my input! > > I reviewed the changes you made, I am learning :) A good start is to use "repoman" which points out very much one could do wrong when writing an ebuild. > Something that gave me a headache tonight: the ebuild is now depending on > virtual/udev-204, while virtual/udev-200 is the current stable ebuild. I > propose to change the dependency to virtual/udev-200, this will prevent > update issues on systems running only stable ebuilds. According to the BlueZ 5.9 sources, the minimum requirement is libudev >= 143, so this should work - feel free to give it a try. > I assume that the ebuild also has to be improved on the udev use flag: when > not selected, no udev files can be installed and udev cannot be reloaded. > Right? There are IMHO 2 reasons not to do this: - such small files are usually always installed (e.g. systemd units are also installed for OpenRC systems) - I don't think it is really possible to properly run a Gentoo system nowadays completely without udev (eudev/systemd-udev), so the udev files should be always installed. Created attachment 362158 [details]
net-wireless/bluez-5.10.ebuild
Tried installing this, it seems to work, however there is no "bluetooth-init.d" file. It seems to have been replaced by "bluetooth-init.d-r2". I changed the ebuild to use this new file, however the path for bluetoothd changed as well. I've updated /etc/init.d/bluetooth for the new path (/usr/libexec/bluetooth/bluetoothd), but the daemon doesn't want to detach from the command line. Running "/etc/init.d/bluetooth start" correctly starts the daemon, but it doesn't return to the command line. Same with just running "/usr/libexec/bluetooth/bluetoothd", it won't detach. The daemon itself seems to work correctly though, I've paired a bluetooth mouse using bluetoothctl. Created attachment 364732 [details]
OpenRC initscript for bluez-5.x
Created attachment 364734 [details] net-wireless/bluez-5.11.ebuild Updated the ebuild a bit: - don't install a systemd unit into the dbus services directory - use the -r3 initscript (attachment#364732 [details]) - bumped from 5.10 to 5.11 Upstream release notes: Release of BlueZ 5.11 17th November 2013, 11:10 pm by Johan Hedberg This release contains numerous fixes in many places of the stack, including SDP, AVRCP and OBEX. The btmon HCI analyzer tool also received updates to fully encode a few missing HCI commands. This is also the first release where have some basic parts of the Android Bluetooth HAL implemented. Things like GAP (device discovery, pairing, etc) should work as well as connecting and using HID devices. All of the Android code lives independently in the android subdirectory of the source tree, though it does share several parts of the “normal” BlueZ source code, such as the SDP handling and mgmt library. (In reply to Dirk Best from comment #26) > Tried installing this, it seems to work, however there is no > "bluetooth-init.d" file. It seems to have been replaced by > "bluetooth-init.d-r2". I changed the ebuild to use this new file, however > the path for bluetoothd changed as well. I addressed this in the latest update. > […] but the daemon doesn't want to detach from the command line. I can reproduce this, but wonder at the same time, whether OpenRC can't deal with this somehow? Non-detaching is the expected behaviour in the systemd-world, but then 'bluetoothd' has a '-n' parameter which would indicate, that its default behaviour is detaching. I don't run OpenRC anymore, but could someone still running it probably have a look at the OpenRC related issues reported here? I'm running openrc and can confirm that: start-stop-daemon --start --background bluetoothd will not detach the daemon from the command line (and thus the boot process is blocked). Gilles added an updated ebuild to gnome-overlay :) http://git.overlays.gentoo.org/gitweb/?p=proj/gnome.git;a=commit;h=e850ce0ebd14055c7299dd8a5d41d6b660257801 Release of BlueZ 5.12 10th December 2013, 12:18 pm by Johan Hedberg This is mostly a bug-fix release, but also contains several notable additions: PS3 (sixaxis) controller support smp-tester for LE Security Manager Protocol testing AVDTP qualification test cases (unit/test-avdtp) LE Connection Oriented Channel test support with l2test (LE CoC is a feature of the newly released Bluetooth 4.1 specification) btmon decoding support for LE CoC signaling commands, CSA4 and Core spec 4.1 HCI commands As with the previous release, simply from a statistical perspective the majority of the changes are on the still work-in-progress Android support side (android/* in the source tree), where we should now have mostly working core, PAN and HID HALs, as well as the socket HAL which enables several higher level profiles like OPP and PBAP. I noticed that Sabayon is working on an ebuild for net-wireless/bluez 5.x too: https://bugs.sabayon.org/show_bug.cgi?id=4515 Perhaps some collaboration is in order? +*bluez-5.12 (23 Dec 2013) + + 23 Dec 2013; Gilles Dartiguelongue <eva@gentoo.org> +bluez-5.12.ebuild, + +files/bluetooth-init.d-r3, files/rfcomm-init.d, metadata.xml: + Version bump. Major ebuild update, see bug #452162. + it is currently under package mask but feel free to report any error. I crafted it based on work done here so it should mostly work fine. As technically this bug isn't closed yet, I'd like to mention, that this *really* needs to be '$(use_enable obex)', cause while something obex related seems to be built regardless (which might or might not be an upstream bug), with '--enable-obex', build dies upon configure check for libical, if it's not installed. Also net-wireless/bluez-5.13 was released on 2013-12-27. Release of BlueZ 5.13 27th December 2013, 07:29 pm by Johan Hedberg This release consists mostly of further features added to the various Android HALs (Core, Socket, PAN and HID), but a few non-Android changes have crept in too: Fix issue with PS3 controller detection HCI event decoding improvements to btmon I am closing this bug now because the ebuild for bluez-5 is in tree and I know need people to file individual bugs for anything that my be broken with it and have a better picture of things left to do before unmasking. |