viability of bluez5 in next OE development cycle?

viability of bluez5 in next OE development cycle?

[Peter A. Bigot]

There's this bugzilla entry: 
https://bugzilla.yoctoproject.org/show_bug.cgi?id=5031

I see a NAKd patch set from about 26 Mar 2014 which tried to add 
virtual/bluez.  The outcome was that a rework would be done and tested 
and resubmitted latter. In the related discussion there was some concern 
that dependent packages were still not ready to move even though the 
last bluez4 release was in June 2012.

With a little local hacking I can get bluez5 working well enough for my 
BTLE needs on beaglebone (mostly s/bluez4/bluez5/g and a PROVIDER for 
bluez-hcidump).  Does anybody have plans to work this during the early 
1.8 development cycle?  It looks pretty straightforward, but Idon't use 
BT in enough variants and packages to be able to test the full set of 
required patches.

Peter

Re: viability of bluez5 in next OE development cycle?

[Burton, Ross]

On 20 October 2014 15:50, Peter A. Bigot <pab@pabigot.com> wrote:
> There's this bugzilla entry:
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=5031
>
> I see a NAKd patch set from about 26 Mar 2014 which tried to add
> virtual/bluez.  The outcome was that a rework would be done and tested and
> resubmitted latter. In the related discussion there was some concern that
> dependent packages were still not ready to move even though the last bluez4
> release was in June 2012.
>
> With a little local hacking I can get bluez5 working well enough for my BTLE
> needs on beaglebone (mostly s/bluez4/bluez5/g and a PROVIDER for
> bluez-hcidump).  Does anybody have plans to work this during the early 1.8
> development cycle?  It looks pretty straightforward, but Idon't use BT in
> enough variants and packages to be able to test the full set of required
> patches.

At the time the blocker was that some use cases (bluetooth headset, I
think) was non-functional with BlueZ 5, because functionality needed
to be added to PulseAudio and oFono.  Yes, this needs to be revisited
in 1.8.

Ross

Re: viability of bluez5 in next OE development cycle?

[Peter A. Bigot]

On 10/20/2014 09:58 AM, Burton, Ross wrote:
> On 20 October 2014 15:50, Peter A. Bigot <pab@pabigot.com> wrote:
>> There's this bugzilla entry:
>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=5031
>>
>> I see a NAKd patch set from about 26 Mar 2014 which tried to add
>> virtual/bluez.  The outcome was that a rework would be done and tested and
>> resubmitted latter. In the related discussion there was some concern that
>> dependent packages were still not ready to move even though the last bluez4
>> release was in June 2012.
>>
>> With a little local hacking I can get bluez5 working well enough for my BTLE
>> needs on beaglebone (mostly s/bluez4/bluez5/g and a PROVIDER for
>> bluez-hcidump).  Does anybody have plans to work this during the early 1.8
>> development cycle?  It looks pretty straightforward, but Idon't use BT in
>> enough variants and packages to be able to test the full set of required
>> patches.
> At the time the blocker was that some use cases (bluetooth headset, I
> think) was non-functional with BlueZ 5, because functionality needed
> to be added to PulseAudio and oFono.  Yes, this needs to be revisited
> in 1.8.

In case it's related: the bluez plugin in gst-plugins-bad_1.4.1 does not 
support bluez5, and gst-plugin-bluetooth was removed from bluez before 
bluez5 was released.  It's not clear to me how to disable the 
gst-plugin-bluetooth recipe when bluez5 is selected other than a local 
PNBLACKLIST.

Excepting that issue, the changes for virtual/bluez support are pretty 
straightforward, but since I have no ability to test bluetooth headsets 
I'll continue to leave virtual/bluez alone.

I have a couple small bluez5 patches that are not coupled to 
virtual/bluez which I'll submit once dizzy's out and the backlog for 
master starts draining.

Peter