Feature changed by: Antoine Ginies (aginies)
Feature #315090, revision 58
Title: Upgrade to Bluez 5
Requested by: Jeffrey Cheung (jeffreycheung)
Partner organization: openSUSE.org
BlueZ 5 come with numerous new features, API simplifications and other
improvements. With this release BlueZ only supports the new Bluetooth
Management kernel interface that was introduced in Linux 3.4, so
essentially this is the minimum kernel requirement for BlueZ 5. For Low
Energy support at least kernel version 3.5 is needed. 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. The BlueZ internal test scripts and tools have naturally
already been updated to support the new API.
The BlueZ version in SLE11 SP3 is BlueZ 4.99 which mean that regardless
of new features, and improvements, we have to upgrade definitely.
- Documentation Impact:
#1: Frederic Crozat (fcrozat) (2013-06-25 16:26:22)
Bluez 5 can be installed in parallel with Bluez4, allowing applications
not ported to BlueZ 5 API to work properly
#2: Frederic Crozat (fcrozat) (2013-07-02 16:53:42) (reply to #1)
it looks like I was a bit optimistic. You can only have one BlueZ
installed (4 or 5) and they aren't API compatible, which requires
having all BT applications moved to BlueZ 5..
#3: Jeffrey Cheung (jeffreycheung) (2013-08-05 12:06:33)
So, can this fate proceed ?
#4: Ludwig Nussel (lnussel) (2013-08-07 10:34:47) (reply to #3)
We are past feature freeze with Milestone 4 now. I suppose this will
affect the desktops so please evaluate the potential fallout and
discuss on the Factory mailinglist whether it's still possible to fix
the affected packages.
#5: Jeffrey Cheung (jeffreycheung) (2013-08-07 11:15:59) (reply to #4)
Hi Ludwig Nussel,
Thanks of reminder. I already send email to factory mailing list. The
current status is that RD finished the x86-64 part but i386 not yet.
#6: Stefan Seyfried (seife) (2013-08-07 17:00:41)
Also note that the bluez library is deprecated with bluez5, so if we
want to do it "right", we should not pass --enable-library to
configure. The consequence if this is that almost everything that uses
bluez will break, though :-)
#7: Jeffrey Cheung (jeffreycheung) (2013-08-08 15:39:18) (reply to #6)
Thanks and RD acknowledged your comment. We may miss upgrade at
openSUSE 13.1 and wait for 13.2 next year.
However, we will keep working for SLE12.
#12: Petr Tesařík (ptesarik) (2013-08-20 14:03:06)
FWIW the Bluetooth stack is currently broken in Factory. At least I
cannot get my BT headset to work. We would have to make our own patch
to fix this bug (backporting from upstream is hard because of API
I'm afraid the maintenance cost in SLE12 lifetime is prohibitively
high, not even daring to think about security monitoring.
#16: Al Cho (acho-novell) (2013-08-21 15:02:41) (reply to #12)
Hi Petr, Thanks for your comment. and Would you file a bug to me about
your headset doesn't work ? ( or the bug is already there? ) I would
#20: Petr Tesařík (ptesarik) (2013-08-23 12:46:13) (reply to #16)
The failure seems to be somewhat related to the HCI hardware, not to
the bluez version. I only wanted to mention it as an example, but it
wasn't a good one after all.
Nevertheless, I still believe that providing L3 support for an outdated
bluez version for years is too much effort. Moreover, this would be
wasted effort, while helping to update dependent packages (in upstream)
#13: Ondrej Holecek (oholecek) (2013-08-20 15:05:24)
Note that current PulseAudio (4.0) does not support Bluez5. PulseAudio
5.0 with initial Bluez5 support was planned to release around upcoming
GNOME 3.10 (end of September AFAIK) but freeze was postponed so this
target was missed.
#14: Petr Tesařík (ptesarik) (2013-08-21 11:50:56) (reply to #13)
This is sweet. So, the same Lennart who repeatedly introduced
incompatible changes in the infrastructure and asked everybody to
adapt, has been unable for over a year to adapt his fine software to a
similar change in the infrastructure he's using... Why am I surprized?
#18: Joey Lee (joeyli) (2013-08-23 07:06:48)
Thanks for the comments from Petr, Ondrej and Scott. Per Scott's
comment, looks Gnome will move to support BlueZ 5. If there doesn't
have KDE in SLE-12, then I think move to BlueZ 5 in SLE-12 is make
This FATE highly dependent to the development progress of desktop UI(e.
g. Gname, KDE) but not just replace the BlueZ package and take care the
bluetooth driver in kernel. So, I suggest add desktop engineering
leader and Gnome experts to this FATE to collaborative work.
#19: Jeffrey Cheung (jeffreycheung) (2013-08-23 15:42:17)
Very well, AL, please watch closely the gnome development. Hi Scott,
can you provide your member which AL can cowork with.
#25: Scott Reeves (sreeves1) (2013-08-30 17:26:23) (reply to #19)
For now just directly to me.
#21: Jeffrey Cheung (jeffreycheung) (2013-08-25 23:28:54)
Add Some current mail thread from openSUSE factory mailing list
(1) From Dimstar / Dominique Leuenberger <dimstar(a)opensuse.org>
looking at where GNOME 3.10 is heading, we discuss as much as there is
need for: but in the end, GNOME 3.10 will depend on BlueZ5;
As such, it's much better for us to switch sooner than later; and
Raymond is doing the best job there is to get KDE in line with these
requirements as well.
So, I would really recommend that we bite the bullet and push BlueZ5 to
The good thing: we won't be alone with this: Fedora 20 will have the
same setup. So we can surely profit from each other there.
If we stay with Bluez4, then we have to be aware that for GNOME this
might or might not work; surely, upstream support will not be given in
this case. If you're planning to such tricks for SLE, I urge you to
rethink such a plan.
Again, for openSUSE: BlueZ5 is mainly ready, the 'legacy API' needs to
be enabled (which is done by Seife) and the stuff relying on the DBUS
interface needs to be made aware of the new interface (not backwards
compatible). It's a one-time pain we have to take now; or we split the
pain over two releases.
Cheers, Dominique -- Dimstar / Dominique Leuenberger
(2) From Stefan Seyfried <stefan.seyfried(a)googlemail.com>
I was the one objecting the update. But then I did not know that there
is already software using (even depending on) bluez5. My impression was
that there is "no need to rush" for 13.1. And when I had looked last,
there was no sign of fedora using bluez5 "soon".
Now that these things have changed (GNOME 3.10 depends on bluez5, KDE
will most likely be able to use it) and we won't be the first and only
users of bluez5, I agree with Dominique's assessment that it probably
is best to switch to the newer version and not mess around with the old
If only GNOME would have kept the standalone bluetooth-applet, this
would be a total non-brainer since everyone could use it, but they are
really trying to create vendor lock-in to their platform :-(
For SLES12 anything less than bluez5 is probably a bad ide :-)
Best regards, and sorry for any confusion I might have caused with my
Stefan -- Stefan Seyfried Linux Consultant & Developer -- GPG Key:
#22: Al Cho (acho-novell) (2013-08-28 10:26:11)
Hi All, we also need a new package "ofono" (https://ofono.org/about
we choose move to bluez 5. Because bluez remove internal support for
telephony (HFP and HSP) profiles. They should be implemented using the
new Profile interface preferably by the telephony subsystem of choice (
oFono which already supports this).
#23: Jeffrey Cheung (jeffreycheung) (2013-08-29 11:14:27) (reply to
Hi Stefan, per Al, we need the new package "ofono", can we just add the
package directly ?
#24: Stefan Behlert (sbehlert) (2013-08-29 08:48:19) (reply to #23)
Sure, if the license is ok (seems to be GPL2 if I did not misread) and
there's a maintainer. I assume it will be in Factory soon? Iexpect we
will notice it is required due to dependencies when we start with the
SLE 12 images?
#34: Al Cho (acho-novell) (2014-01-24 10:26:47)
Done. Already supported on Factory.
Release Notes: Bluetooth Implementation BlueZ 5
BlueZ 4 is no longer maintained upstream. Thus upgrading to BlueZ 5
ensures that you will get all the latest upstream bug fixes and
BlueZ 5 comes with numerous new features, API simplification and other
improvements such as Low Energy support. It is new major version of the
Bluetooth handling daemon and utilities.
Note: The new major version indicates that the API is not backwards
compatible with BlueZ 4, which means that all applications, agents,
etc. must be updated.