Heya,
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[1] and as such, management applications and a number of libraries and daemons will need to be ported.
For GNOME 3.10 (due September 2013), Gustavo Padovan and I are going to be porting gnome-bluetooth, NetworkManager and PulseAudio to BlueZ5. Packages for BlueZ5 will be available as soon as we figure out how to integrate a few downstream features that were in the Fedora packages.
Bluez4 and Bluez5 are not parallel-installable, and incompatible, so other applications relying on Bluez4 will need to be ported by their respective maintainers.
Cheers
[1]: http://www.bluez.org/bluez-5-api-introduction-and-porting-guide/ and http://lwn.net/Articles/531133/
On Mon, May 6, 2013 at 8:35 AM, Bastien Nocera bnocera@redhat.com wrote:
Heya,
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[1] and as such, management applications and a number of libraries and daemons will need to be ported.
For GNOME 3.10 (due September 2013), Gustavo Padovan and I are going to be porting gnome-bluetooth, NetworkManager and PulseAudio to BlueZ5. Packages for BlueZ5 will be available as soon as we figure out how to integrate a few downstream features that were in the Fedora packages.
Bluez4 and Bluez5 are not parallel-installable, and incompatible, so other applications relying on Bluez4 will need to be ported by their respective maintainers.
Any analysis to what packages are affected, how many are yet to support the new API and how hard it will be for them to be ported over.
Peter
On 05/06/2013 11:13 AM, Peter Robinson wrote:
On Mon, May 6, 2013 at 8:35 AM, Bastien Nocera bnocera@redhat.com wrote:
For GNOME 3.10 (due September 2013), Gustavo Padovan and I are going to be porting gnome-bluetooth, NetworkManager and PulseAudio to BlueZ5. Packages for BlueZ5 will be available as soon as we figure out how to integrate a few downstream features that were in the Fedora packages.
Bluez4 and Bluez5 are not parallel-installable, and incompatible, so other applications relying on Bluez4 will need to be ported by their respective maintainers.
Any analysis to what packages are affected, how many are yet to support the new API and how hard it will be for them to be ported over.
Impact on KDE?
On Mon, May 6, 2013 at 11:38 AM, Roberto Ragusa mail@robertoragusa.it wrote:
Bluez4 and Bluez5 are not parallel-installable, and incompatible, so other applications relying on Bluez4 will need to be ported by their respective maintainers.
Impact on KDE?
Probably not much as the upstream developers are already planning Bluez5 integration.
--
On Mon, May 6, 2013 at 10:38 AM, Roberto Ragusa mail@robertoragusa.it wrote:
On 05/06/2013 11:13 AM, Peter Robinson wrote:
On Mon, May 6, 2013 at 8:35 AM, Bastien Nocera bnocera@redhat.com wrote:
For GNOME 3.10 (due September 2013), Gustavo Padovan and I are going to be porting gnome-bluetooth, NetworkManager and PulseAudio to BlueZ5. Packages for BlueZ5 will be available as soon as we figure out how to integrate a few downstream features that were in the Fedora packages.
Bluez4 and Bluez5 are not parallel-installable, and incompatible, so other applications relying on Bluez4 will need to be ported by their respective maintainers.
Any analysis to what packages are affected, how many are yet to support the new API and how hard it will be for them to be ported over.
Impact on KDE?
No all packages that depend on bluez. It's usual for large potential breakages for the person pushing for the changes to give some overview etc.
Peter
On Mon, 2013-05-06 at 10:13 +0100, Peter Robinson wrote:
On Mon, May 6, 2013 at 8:35 AM, Bastien Nocera bnocera@redhat.com wrote:
Heya,
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[1] and as such, management applications and a number of libraries and daemons will need to be ported.
For GNOME 3.10 (due September 2013), Gustavo Padovan and I are going to be porting gnome-bluetooth, NetworkManager and PulseAudio to BlueZ5. Packages for BlueZ5 will be available as soon as we figure out how to integrate a few downstream features that were in the Fedora packages.
Bluez4 and Bluez5 are not parallel-installable, and incompatible, so other applications relying on Bluez4 will need to be ported by their respective maintainers.
Any analysis to what packages are affected,
The ones I care about are: - gnome-user-share, gvfsd-obexftp, obex-data-server (ObexFTP/Obex PUSH will use a new obexd implementation) - gnome-bluetooth - PulseAudio (already ported to BlueZ 5) - NetworkManager
blueman, and KDE will need to rework their Bluetooth support. Other applications that chose to poke at Bluetooth's D-Bus API directly will also need to be ported.
Applications that use libbluetooth will most likely just need a rebuild against the library with the updated soname.
how many are yet to support the new API and how hard it will be for them to be ported over.
Cheers
2013-05-06 11:13, Peter Robinson skrev:
On Mon, May 6, 2013 at 8:35 AM, Bastien Nocera bnocera@redhat.com wrote:
Heya,
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[1] and as such, management applications and a number of libraries and daemons will need to be ported.
For GNOME 3.10 (due September 2013), Gustavo Padovan and I are going to be porting gnome-bluetooth, NetworkManager and PulseAudio to BlueZ5. Packages for BlueZ5 will be available as soon as we figure out how to integrate a few downstream features that were in the Fedora packages.
Bluez4 and Bluez5 are not parallel-installable, and incompatible, so other applications relying on Bluez4 will need to be ported by their respective maintainers.
Any analysis to what packages are affected, how many are yet to support the new API and how hard it will be for them to be ported over.
I took a look to see what the impact would be. I am not a BlueZ expert, so Bastien, please correct me if I am wrong somewhere.
BlueZ ships a daemon and provides two main interfaces for applications to use it:
1) libbluetooth shared library
2) org.bluez DBus API
The TL;DL version is that in my findings, the only package that still needs porting to bluez 5 is blueman. Others should either just continue working, or need new versions packaged up.
Applications that use the 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.
Affected packages:
$ repoquery -q --whatrequires bluez-libs -s | sort | uniq amora-1.1-10.fc19.src.rpm anyremote-6.3.1-1.fc20.src.rpm asterisk-11.4.0-2.fc20.src.rpm bluecove-2.1.1-0.5.20101024snap63.fc19.src.rpm blueman-1.23-6.fc19.src.rpm bluemodem-0.7-9.fc19.src.rpm bluez-4.101-6.fc19.src.rpm bluez-hcidump-2.5-2.fc19.src.rpm btkbdd-1.3-2.fc19.src.rpm cwiid-0.6.00-21.20100505gitfadf11e.fc19.src.rpm dolphin-emu-3.0-12.fc19.src.rpm fawkes-0.5.0-7.fc20.src.rpm foxtrotgps-1.1.1-5.fc19.src.rpm gammu-1.26.1-10.fc19.src.rpm gnokii-0.6.31-6.fc20.src.rpm gnome-phone-manager-0.68-10.fc19.src.rpm gpsd-3.9-1.fc20.src.rpm gvfs-1.17.2-1.fc20.src.rpm gypsy-0.9-1.fc20.src.rpm kismet-0.0.2013.03.R1-1.fc20.src.rpm libbtctl-0.11.1-13.fc20.src.rpm libopensync-plugin-irmc-0.22-6.fc19.src.rpm nxtrc-2.3-7.fc19.src.rpm obexd-0.46-5.fc20.src.rpm obex-data-server-0.4.6-5.fc19.src.rpm obexfs-0.12-6.fc19.src.rpm obexftp-0.23-13.fc20.src.rpm openobex-1.5-8.fc19.src.rpm pilot-link-0.12.5-16.fc20.src.rpm pulseaudio-4.0-1.fc20.src.rpm pybluez-0.18-6.fc19.src.rpm qemu-1.5.0-9.fc20.src.rpm syncevolution-1.3.99.3-2.fc20.src.rpm vfrnav-20130510-1.fc20.src.rpm wiiuse-0.12-8.fc19.src.rpm xbmc-12.2-3.fc20.src.rpm
Applications that use the org.bluez dbus API --------------------------------------------
The DBus service is shipped in the 'bluez' package and I assume all the DBus API consumers have a dep on the 'bluez' package for that:
$ repoquery -q --whatrequires bluez -s | sort | uniq blueman-1.23-6.fc19.src.rpm bluemodem-0.7-9.fc19.src.rpm bluez-4.101-6.fc19.src.rpm gammu-1.26.1-10.fc19.src.rpm ganyremote-6.2-1.fc20.src.rpm gnome-bluetooth-3.8.1-1.fc20.src.rpm kanyremote-6.2-1.fc20.src.rpm libbluedevil-1.9.2-4.fc20.src.rpm pulseaudio-4.0-1.fc20.src.rpm
I took a quick look at all the packages above and the following don't seem to use the dbus API and have a dep on the 'bluez' package for other reasons (use command line utilities etc.):
bluemodem gammu ganyremote kanyremote
The following use the DBus API:
blueman [Status: needs porting to 5.x] gnome-bluetooth [Status: ported] libbluedevil [Status: port available in a git branch, https://git.reviewboard.kde.org/r/108912/] pulseaudio [Status: ported]
On Fri, 2013-06-21 at 17:16 +0200, Kalev Lember wrote:
2013-05-06 11:13, Peter Robinson skrev:
On Mon, May 6, 2013 at 8:35 AM, Bastien Nocera bnocera@redhat.com wrote:
Heya,
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[1] and as such, management applications and a number of libraries and daemons will need to be ported.
For GNOME 3.10 (due September 2013), Gustavo Padovan and I are going to be porting gnome-bluetooth, NetworkManager and PulseAudio to BlueZ5. Packages for BlueZ5 will be available as soon as we figure out how to integrate a few downstream features that were in the Fedora packages.
Bluez4 and Bluez5 are not parallel-installable, and incompatible, so other applications relying on Bluez4 will need to be ported by their respective maintainers.
Any analysis to what packages are affected, how many are yet to support the new API and how hard it will be for them to be ported over.
I took a look to see what the impact would be. I am not a BlueZ expert, so Bastien, please correct me if I am wrong somewhere.
BlueZ ships a daemon and provides two main interfaces for applications to use it:
libbluetooth shared library
org.bluez DBus API
The TL;DL version is that in my findings, the only package that still needs porting to bluez 5 is blueman. Others should either just continue working, or need new versions packaged up.
<snip>
The following use the DBus API:
blueman [Status: needs porting to 5.x] gnome-bluetooth [Status: ported] libbluedevil [Status: port available in a git branch, https://git.reviewboard.kde.org/r/108912/] pulseaudio [Status: ported]
And NetworkManager. 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.
NetworkManager is in the process of being ported.
You're also missing obex-data-server, obsoleted and not ported to BlueZ 5, which is used by gnome-user-share (patches are upstream to be ported) and gvfs-obexftp (won't be ported).
Cheers
On Fri, Jun 21, 2013 at 5:29 PM, Bastien Nocera bnocera@redhat.com wrote:
On Fri, 2013-06-21 at 17:16 +0200, Kalev Lember wrote:
2013-05-06 11:13, Peter Robinson skrev:
On Mon, May 6, 2013 at 8:35 AM, Bastien Nocera bnocera@redhat.com wrote:
Heya,
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[1] and as such, management applications and a number of libraries and daemons will need to be ported.
For GNOME 3.10 (due September 2013), Gustavo Padovan and I are going to be porting gnome-bluetooth, NetworkManager and PulseAudio to BlueZ5. Packages for BlueZ5 will be available as soon as we figure out how to integrate a few downstream features that were in the Fedora packages.
Bluez4 and Bluez5 are not parallel-installable, and incompatible, so other applications relying on Bluez4 will need to be ported by their respective maintainers.
Any analysis to what packages are affected, how many are yet to support the new API and how hard it will be for them to be ported over.
I took a look to see what the impact would be. I am not a BlueZ expert, so Bastien, please correct me if I am wrong somewhere.
BlueZ ships a daemon and provides two main interfaces for applications to use it:
libbluetooth shared library
org.bluez DBus API
The TL;DL version is that in my findings, the only package that still needs porting to bluez 5 is blueman. Others should either just continue working, or need new versions packaged up.
<snip> > The following use the DBus API: > > blueman [Status: needs porting to 5.x] > gnome-bluetooth [Status: ported] > libbluedevil [Status: port available in a git branch, > https://git.reviewboard.kde.org/r/108912/] > pulseaudio [Status: ported]
And NetworkManager. 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.
NetworkManager is in the process of being ported.
You're also missing obex-data-server, obsoleted and not ported to BlueZ 5, which is used by gnome-user-share (patches are upstream to be ported) and gvfs-obexftp (won't be ported).
Why?
Am Freitag, 21. Juni 2013, 17:16:09 schrieben Sie:
2013-05-06 11:13, Peter Robinson skrev:
On Mon, May 6, 2013 at 8:35 AM, Bastien Nocera bnocera@redhat.com wrote:
Heya,
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[1] and as such, management applications and a number of libraries and daemons will need to be ported.
For GNOME 3.10 (due September 2013), Gustavo Padovan and I are going to be porting gnome-bluetooth, NetworkManager and PulseAudio to BlueZ5. Packages for BlueZ5 will be available as soon as we figure out how to integrate a few downstream features that were in the Fedora packages.
Bluez4 and Bluez5 are not parallel-installable, and incompatible, so other applications relying on Bluez4 will need to be ported by their respective maintainers.
Any analysis to what packages are affected, how many are yet to support the new API and how hard it will be for them to be ported over.
I took a look to see what the impact would be. I am not a BlueZ expert, so Bastien, please correct me if I am wrong somewhere.
BlueZ ships a daemon and provides two main interfaces for applications to use it:
libbluetooth shared library
org.bluez DBus API
The TL;DL version is that in my findings, the only package that still needs porting to bluez 5 is blueman. Others should either just continue working, or need new versions packaged up.
Applications that use the 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.
Affected packages:
$ repoquery -q --whatrequires bluez-libs -s | sort | uniq amora-1.1-10.fc19.src.rpm anyremote-6.3.1-1.fc20.src.rpm asterisk-11.4.0-2.fc20.src.rpm bluecove-2.1.1-0.5.20101024snap63.fc19.src.rpm blueman-1.23-6.fc19.src.rpm bluemodem-0.7-9.fc19.src.rpm bluez-4.101-6.fc19.src.rpm bluez-hcidump-2.5-2.fc19.src.rpm btkbdd-1.3-2.fc19.src.rpm cwiid-0.6.00-21.20100505gitfadf11e.fc19.src.rpm dolphin-emu-3.0-12.fc19.src.rpm fawkes-0.5.0-7.fc20.src.rpm foxtrotgps-1.1.1-5.fc19.src.rpm gammu-1.26.1-10.fc19.src.rpm gnokii-0.6.31-6.fc20.src.rpm gnome-phone-manager-0.68-10.fc19.src.rpm gpsd-3.9-1.fc20.src.rpm gvfs-1.17.2-1.fc20.src.rpm gypsy-0.9-1.fc20.src.rpm kismet-0.0.2013.03.R1-1.fc20.src.rpm libbtctl-0.11.1-13.fc20.src.rpm libopensync-plugin-irmc-0.22-6.fc19.src.rpm nxtrc-2.3-7.fc19.src.rpm obexd-0.46-5.fc20.src.rpm obex-data-server-0.4.6-5.fc19.src.rpm obexfs-0.12-6.fc19.src.rpm obexftp-0.23-13.fc20.src.rpm openobex-1.5-8.fc19.src.rpm pilot-link-0.12.5-16.fc20.src.rpm pulseaudio-4.0-1.fc20.src.rpm pybluez-0.18-6.fc19.src.rpm qemu-1.5.0-9.fc20.src.rpm syncevolution-1.3.99.3-2.fc20.src.rpm vfrnav-20130510-1.fc20.src.rpm
On 08/14/2013 06:29 PM, Than Ngo wrote:
it's effected in KDE (libbluedevil). someone is working on this, but it's not expected the bluez5 support will be ready for F20!
So f21 is Ok as goal, but f20 is definitely to early for KDE!
I brought this up at a KDE meeting [1] last month and Kevin Kofler and other people who were there said it should be possible to ship a git snapshot of BlueDevil. And Kevin repeated the same in the bluez5 ticket [2] as well.
Can you bring this up at a KDE meeting again? Currently it looks like all the KDE maintainers aren't on the same page with this.
[1] http://meetbot.fedoraproject.org/fedora-meeting/2013-07-09/kde-sig.2013-07-0... [2] https://bugzilla.redhat.com/show_bug.cgi?id=974145#c10
On Mon, May 6, 2013 at 3:35 AM, Bastien Nocera bnocera@redhat.com wrote:
Heya,
In Fedora 20, we'll be using BlueZ 5.x to manage Bluetooth devices.
So your Subject says this is a Feature, yet there's no link to a Feature page. I can't find one in the wiki either, and I know this hasn't gone through FESCo.
Can you create one and get it submitted please?
josh
On Mon, 2013-05-06 at 10:08 -0400, Josh Boyer wrote:
On Mon, May 6, 2013 at 3:35 AM, Bastien Nocera bnocera@redhat.com wrote:
Heya,
In Fedora 20, we'll be using BlueZ 5.x to manage Bluetooth devices.
So your Subject says this is a Feature, yet there's no link to a Feature page. I can't find one in the wiki either, and I know this hasn't gone through FESCo.
Can you create one and get it submitted please?
The F20 feature pages seem to be lacking (or the curating of the Wiki is).
----- Original Message -----
On Mon, 2013-05-06 at 10:08 -0400, Josh Boyer wrote:
On Mon, May 6, 2013 at 3:35 AM, Bastien Nocera bnocera@redhat.com wrote:
Heya,
In Fedora 20, we'll be using BlueZ 5.x to manage Bluetooth devices.
So your Subject says this is a Feature, yet there's no link to a Feature page. I can't find one in the wiki either, and I know this hasn't gone through FESCo.
Can you create one and get it submitted please?
The F20 feature pages seem to be lacking (or the curating of the Wiki is).
I hope to start the new process next week as with docs and marketing we were working on details. So stay tuned and sorry for delays but I really wanted to have the new process widespread and usable for both planning and marketing (and not to forget - docs guys too).
Jarolav
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Mon, 2013-05-06 at 09:35 +0200, Bastien Nocera wrote:
Heya,
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[1] and as such, management applications and a number of libraries and daemons will need to be ported.
For GNOME 3.10 (due September 2013), Gustavo Padovan and I are going to be porting gnome-bluetooth, NetworkManager and PulseAudio to BlueZ5. Packages for BlueZ5 will be available as soon as we figure out how to integrate a few downstream features that were in the Fedora packages.
Well fun... poke me so we can discuss approaches before starting on the NM parts; I hope we can actually collapse some of the abstractions in NM's Bluez manager since the code is trying to be somewhat defensive.
Dan
Bluez4 and Bluez5 are not parallel-installable, and incompatible, so other applications relying on Bluez4 will need to be ported by their respective maintainers.
Cheers
devel@lists.stg.fedoraproject.org
-
Bastien Nocera -
Dan Williams -
drago01 -
Jaroslav Reznik -
Josh Boyer -
Kalev Lember -
Peter Robinson -
Rajeesh K V -
Roberto Ragusa -
than