Changes/Bluez5

From FedoraProject

< Changes(Difference between revisions)
Jump to: navigation, search
m (Owner: List me as an owner)
(Expand on the description)
Line 2: Line 2:
  
 
== Summary ==
 
== Summary ==
Fedora currently ships with Bluez version 4. In Fedora 20, we are going to switch to Bluez 5.
+
BlueZ is the Linux Bluetooth stack for managing wireless Bluetooth devices. In Fedora 20, we are going to switch from BlueZ version 4 to BlueZ version 5.
  
 
== Owner ==
 
== Owner ==
<!--
+
* Name: [[User:hadess| Bastien Nocera]], [[User:kalev| Kalev Lember]], and the desktop SIG
For change proposals to quality as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages.
+
This should link to your home wiki page so we know who you are.
+
-->
+
* Name: [[User:hadess| Bastien Nocera]], [[User:kalev| Kalev Lember]]
+
 
* Email: bnocera@redhat.com, kalevlember@gmail.com
 
* Email: bnocera@redhat.com, kalevlember@gmail.com
 
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> -->
 
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> -->
Line 18: Line 14:
 
== Current status ==
 
== Current status ==
 
* Targeted release: [[Releases/20 | Fedora 20 ]]  
 
* Targeted release: [[Releases/20 | Fedora 20 ]]  
* Last updated:  2013-07-02
+
* Last updated:  2013-08-12
 
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
 
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
 
Bugzilla states meaning as usual:
 
Bugzilla states meaning as usual:
Line 30: Line 26:
  
 
== Detailed Description ==
 
== Detailed Description ==
<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
 
In Fedora 20, we'll be using BlueZ 5.x to manage Bluetooth devices.
 
  
Bluez5 uses a D-Bus API that's not compatible with Bluez4 and as
+
The BlueZ project recently released BlueZ version 5. Compared to BlueZ version 4, the new release brings new features and improvements, however it is also accompanied by a significant API change. The BlueZ versions 4 and 5 are not parallel installable, and we need coordination between various parts of Fedora to switch over at the same time.
such, management applications and a number of libraries and daemons will
+
 
need to be ported.
+
This is coming late after the Change Proposals Submission Deadline. As this affects various critical parts of the distribution (KDE, GNOME, NetworkManager, pulseaudio), we wanted to be sure it is feasible to switch everything over at the same time, and were considering postponing it to Fedora 21. However, upstreams have made good progress with porting over to BlueZ 5 and we feel it would be beneficial for Fedora to switch over during the Fedora 20 timeframe.
  
 
LWN introduction to BlueZ 5: http://lwn.net/Articles/531133/
 
LWN introduction to BlueZ 5: http://lwn.net/Articles/531133/
Line 42: Line 36:
  
 
== Benefit to Fedora ==
 
== Benefit to Fedora ==
This keeps the Bluetooth stack in Fedora up to date. Bluez 4 is no longer maintained upstream; switching to Bluez 5 ensures we can get all the latest upstream bug fixes and enhancements.
+
This keeps the Bluetooth stack in Fedora up to date. BlueZ 4 is no longer maintained upstream; switching to BlueZ 5 ensures we can get all the latest upstream bug fixes and enhancements.
  
 
== Scope ==
 
== Scope ==
 +
 +
BlueZ 5 uses a D-Bus API that's not compatible with BlueZ 4 and as such, management applications and a number of libraries and daemons will need to be ported.
  
 
* Proposal owners:
 
* Proposal owners:
 
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
 
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
For GNOME 3.10 (due September 2013), Gustavo Padovan and Bastien Nocera are going to
+
Gustavo Padovan and Bastien Nocera have been porting gnome-bluetooth, NetworkManager and PulseAudio to BlueZ 5.
be porting gnome-bluetooth, NetworkManager and PulseAudio to BlueZ 5.
+
  
 
* Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 
* Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->

Revision as of 22:10, 12 August 2013

Contents

Migrate to Bluez 5

Summary

BlueZ is the Linux Bluetooth stack for managing wireless Bluetooth devices. In Fedora 20, we are going to switch from BlueZ version 4 to BlueZ version 5.

Owner

Current status

  • Targeted release: Fedora 20
  • Last updated: 2013-08-12
  • Tracker bug: <will be assigned by the Wrangler>

Detailed Description

The BlueZ project recently released BlueZ version 5. Compared to BlueZ version 4, the new release brings new features and improvements, however it is also accompanied by a significant API change. The BlueZ versions 4 and 5 are not parallel installable, and we need coordination between various parts of Fedora to switch over at the same time.

This is coming late after the Change Proposals Submission Deadline. As this affects various critical parts of the distribution (KDE, GNOME, NetworkManager, pulseaudio), we wanted to be sure it is feasible to switch everything over at the same time, and were considering postponing it to Fedora 21. However, upstreams have made good progress with porting over to BlueZ 5 and we feel it would be beneficial for Fedora to switch over during the Fedora 20 timeframe.

LWN introduction to BlueZ 5: http://lwn.net/Articles/531133/

BlueZ 5 porting guide: http://www.bluez.org/bluez-5-api-introduction-and-porting-guide/

Benefit to Fedora

This keeps the Bluetooth stack in Fedora up to date. BlueZ 4 is no longer maintained upstream; switching to BlueZ 5 ensures we can get all the latest upstream bug fixes and enhancements.

Scope

BlueZ 5 uses a D-Bus API that's not compatible with BlueZ 4 and as such, management applications and a number of libraries and daemons will need to be ported.

  • Proposal owners:

Gustavo Padovan and Bastien Nocera have been porting gnome-bluetooth, NetworkManager and PulseAudio to BlueZ 5.

  • Other developers:

Bluez4 and Bluez5 are not parallel-installable, and incompatible, so other applications relying on Bluez4 will need to be ported by their respective maintainers.

  • Release engineering:

No release engineering coordination required.

  • Policies and guidelines:

No changes needed in the packaging guidelines.

Upgrade/compatibility impact

BlueZ ships a daemon and provides two main interfaces for applications to use it:

libbluetooth shared library

The library ABI hasn't changed and the soname in 5.x is still the same as was in 4.x: libbluetooth.so.3, so the impact should be minimal. Everything should be able to continue working without needing even a simple rebuild.

org.bluez D-Bus API

Not all packages that use the org.bluez D-Bus service have a dependency on the bluez package. This makes it hard to find all the consumers; there's probably a number of applications that use bluez via D-Bus without requiring it as a dependency if the functionality isn't the main one, so there's likely going to be other impacted packages.

  • blueman (Status: needs porting to BlueZ 5)
  • gnome-bluetooth (Status: ported)
  • libbluedevil (Status: port available in a git branch, https://git.reviewboard.kde.org/r/108912/)
  • NetworkManager (Status: in progress)
  • pulseaudio (Status: in progress)
  • obex-data-server (Status: obsoleted and not ported to BlueZ 5)
  • gvfs-obexftp (Status: won't be ported)

How To Test

N/A (not a System Wide Change)

User Experience

N/A (not a System Wide Change)

Dependencies

N/A (not a System Wide Change)

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change), Yes/No

Documentation

N/A (not a System Wide Change)

Release Notes