From Fedora Project Wiki
(Initial version)
 
(Add tracker bug)
 
(14 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= Migrate to Bluez 5 --> =
= Migrate to Bluez 5 =


== 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 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.
* Email: bnocera@redhat.com, kalevlember@gmail.com
This should link to your home wiki page so we know who you are.
-->
* Name: [[User:hadess| Bastien Nocera]]
* Email: bnocera@redhat.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> -->
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
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 27: Line 23:
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
-->
-->
* Tracker bug: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=998563 #998563]


== 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.
 
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/
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.


== 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 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?-->
This is a change affecting many parts of the distribution. The proposal owners, supported by the rest of the Desktop SIG, are going to take care of updating the BlueZ package to version 5 and porting over gnome-bluetooth, NetworkManager, and PulseAudio packages.
For GNOME 3.10 (due September 2013), Gustavo Padovan and Bastien Nocera are going to
 
be porting gnome-bluetooth, NetworkManager and PulseAudio to BlueZ 5.
* KDE SIG:
The bluetooth stack for KDE is BlueDevil. It has a git branch with BlueZ 5 support and the Fedora KDE SIG will handle updating the package to a git snapshot.
 
* Desktop SIG:
For GNOME 3.10, Gustavo Padovan and Bastien Nocera have been porting gnome-bluetooth, NetworkManager and PulseAudio to BlueZ 5, and the Fedora Desktop SIG will ensure these get updated to the BlueZ 5 versions in Fedora.
 
* NetworkManager team:
... will ensure the relevant NetworkManager changes land in Fedora 20.
 
* MATE team:
mate-bluetooth has not received much upstream attention recently and is likely to not get ported to BlueZ 5 in time for F20. However, the Fedora MATE maintainers are looking into switching back to using gnome-bluetooth, and creating a panel applet for MATE that uses gnome-bluetooth underneath. An initial prototype is available at https://github.com/NiceandGently/bluetooth-panel-applet


* Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Other developers:
<!-- What work do other developers 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?-->
Bluez4 and Bluez5 are not parallel-installable, and incompatible, so
Bluez4 and Bluez5 are not parallel-installable, and incompatible, so
other applications relying on Bluez4 will need to be ported by their
other applications relying on Bluez4 will need to be ported by their
respective maintainers.
respective maintainers.


* Release engineering: <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Release engineering:
No release engineering coordination required.
No release engineering coordination required.
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuid required?  If a rel-eng ticket exists, add a link here.  -->


* Policies and guidelines: <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Policies and guidelines:
No changes needed in the packaging guidelines.
No changes needed in the packaging guidelines.
<!-- Do the packaging guidelines or other documents need to be updated for this feature?  If so, does it need to happen before or after the implementation is done?  If a FPC ticket exists, add a link here. -->


== Upgrade/compatibility impact ==
== Upgrade/compatibility impact ==
<!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? -->
 
See the following mailing list post for details and discussion for affected packages: https://lists.fedoraproject.org/pipermail/devel/2013-June/184334.html


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


=== libbluetooth shared library ===
==== libbluetooth shared library ====


The library ABI hasn't changed and the soname in 5.x is still the same
The library ABI hasn't changed, so the upgrade/compatibility impact should be minimal. Applications using the libbluetooth library should be able to continue working without needing code changes or rebuilds.
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 ===
==== 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
The D-Bus API has had major changes. Most major consumers should be ported over during the Fedora 20 timeframe, with one exception:
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)
* blueman
* gnome-bluetooth  (Status: ported)
 
* libbluedevil    (Status: port available in a git branch, https://git.reviewboard.kde.org/r/108912/)
Blueman is abandoned upstream and is going to be dropped from Fedora 20. The following mailing list post includes the relevant details: https://lists.fedoraproject.org/pipermail/devel/2013-August/187223.html
* 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 ==
== How To Test ==
<!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this change implementation is expected to pass when it is done.  If it needs to be tested with different hardware or software configurations, indicate them.  The more specific you can be, the better the community testing can be.
Remember that you are writing this how to for interested testers to use to check out your change implementation - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your change.
A good "how to test" should answer these four questions:
0. What special hardware / data / etc. is needed (if any)?
1. How do I prepare my system to test this change? What packages
need to be installed, config files edited, etc.?
2. What specific actions do I perform to check that the change is
working like it's supposed to?
3. What are the expected results of those actions?
-->


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
Testing the change requires having Bluetooth capable hardware. Major functionality should keep working without regressions, compared to BlueZ 4 in Fedora 19.
N/A (not a System Wide Change)


== User Experience ==
== User Experience ==
<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice. -->
User experience should change minimally.
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A (not a System Wide Change)


== Dependencies ==
== Dependencies ==
<!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this change depends?  In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like the kernel (if this is not a kernel change)? -->
This requires coordination between the kernel team, the Desktop team, the KDE team, and various other package maintainers. The proposal owners will handle the coordination.
 
== Contingency Plan ==
If the release blocking desktops have major bluetooth related regressions by the time of the Fedora 20 Beta Change Deadline, then FESCo and the proposal owners may enact a contingency plan to revert the BlueZ 5 related changes and go back to BlueZ 4. In that case, we'll likely want to keep using BlueZ in the Rawhide branch and only revert the changes in Branched (F20).


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
In addition, the upstream GNOME release team is also keeping an eye open for regressions, and will revert back to BlueZ 4 for GNOME 3.10 (due in September) if there are major regressions in either GNOME, NetworkManager or PulseAudio.
N/A (not a System Wide Change)  


== Contingency Plan ==
1) Bump bluez package's epoch in both Branched and Rawhide branches
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
  2) Revert bluez back to version 4.101 in F20 and stick with 5.x in F21
* Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
  3) Switch NetworkManager, PulseAudio, gnome-bluetooth, BlueDevil back to using BlueZ 4 in the F20 branch
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
4) Send a notice to fedora-devel-announce, asking other package maintainers to switch back to BlueZ 4 in the F20 branch
* Contingency deadline: N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->


== Documentation ==
== Documentation ==
<!-- Is there upstream documentation on this change, or notes you have written yourself?  Link to that material here so other interested developers can get involved. -->
<!-- Is there upstream documentation on this change, or notes you have written yourself?  Link to that material here so other interested developers can get involved. -->


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
LWN introduction to BlueZ 5: http://lwn.net/Articles/531133/
N/A (not a System Wide Change)
 
BlueZ 5 porting guide: http://www.bluez.org/bluez-5-api-introduction-and-porting-guide/


== Release Notes ==
== Release Notes ==
<!-- The Fedora Release Notes inform end-users about what is new in the release.  Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ -->
Fedora 20 uses BlueZ version 5 for managing Bluetooth devices. The new BlueZ release includes significant API changes and all major desktops have been ported over.
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns.  If there are any such changes involved in this change, indicate them here.  A link to upstream documentation will often satisfy this need.  This information forms the basis of the release notes edited by the documentation team and shipped with the release.
[[Category:ChangeAcceptedF20]]
 
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze.  
-->
 
[[Category:ChangePageIncomplete]]
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->

Latest revision as of 12:55, 20 August 2013

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 version 5.

Owner

Current status

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.

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 need to be ported.

  • Proposal owners:

This is a change affecting many parts of the distribution. The proposal owners, supported by the rest of the Desktop SIG, are going to take care of updating the BlueZ package to version 5 and porting over gnome-bluetooth, NetworkManager, and PulseAudio packages.

  • KDE SIG:

The bluetooth stack for KDE is BlueDevil. It has a git branch with BlueZ 5 support and the Fedora KDE SIG will handle updating the package to a git snapshot.

  • Desktop SIG:

For GNOME 3.10, Gustavo Padovan and Bastien Nocera have been porting gnome-bluetooth, NetworkManager and PulseAudio to BlueZ 5, and the Fedora Desktop SIG will ensure these get updated to the BlueZ 5 versions in Fedora.

  • NetworkManager team:

... will ensure the relevant NetworkManager changes land in Fedora 20.

  • MATE team:

mate-bluetooth has not received much upstream attention recently and is likely to not get ported to BlueZ 5 in time for F20. However, the Fedora MATE maintainers are looking into switching back to using gnome-bluetooth, and creating a panel applet for MATE that uses gnome-bluetooth underneath. An initial prototype is available at https://github.com/NiceandGently/bluetooth-panel-applet

  • 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

See the following mailing list post for details and discussion for affected packages: https://lists.fedoraproject.org/pipermail/devel/2013-June/184334.html

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

libbluetooth shared library

The library ABI hasn't changed, so the upgrade/compatibility impact should be minimal. Applications using the libbluetooth library should be able to continue working without needing code changes or rebuilds.

BlueZ D-Bus API

The D-Bus API has had major changes. Most major consumers should be ported over during the Fedora 20 timeframe, with one exception:

  • blueman

Blueman is abandoned upstream and is going to be dropped from Fedora 20. The following mailing list post includes the relevant details: https://lists.fedoraproject.org/pipermail/devel/2013-August/187223.html

How To Test

Testing the change requires having Bluetooth capable hardware. Major functionality should keep working without regressions, compared to BlueZ 4 in Fedora 19.

User Experience

User experience should change minimally.

Dependencies

This requires coordination between the kernel team, the Desktop team, the KDE team, and various other package maintainers. The proposal owners will handle the coordination.

Contingency Plan

If the release blocking desktops have major bluetooth related regressions by the time of the Fedora 20 Beta Change Deadline, then FESCo and the proposal owners may enact a contingency plan to revert the BlueZ 5 related changes and go back to BlueZ 4. In that case, we'll likely want to keep using BlueZ in the Rawhide branch and only revert the changes in Branched (F20).

In addition, the upstream GNOME release team is also keeping an eye open for regressions, and will revert back to BlueZ 4 for GNOME 3.10 (due in September) if there are major regressions in either GNOME, NetworkManager or PulseAudio. 

1) Bump bluez package's epoch in both Branched and Rawhide branches
2) Revert bluez back to version 4.101 in F20 and stick with 5.x in F21
3) Switch NetworkManager, PulseAudio, gnome-bluetooth, BlueDevil back to using BlueZ 4 in the F20 branch
4) Send a notice to fedora-devel-announce, asking other package maintainers to switch back to BlueZ 4 in the F20 branch

Documentation

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/

Release Notes

Fedora 20 uses BlueZ version 5 for managing Bluetooth devices. The new BlueZ release includes significant API changes and all major desktops have been ported over.

Retrieved from "https://fedoraproject.org/w/index.php?title=Changes/Bluez5&oldid=349959"