[OE-core] [PATCH 00/11] Change all bluez4 references to virtual/bluez

2014-03-26 Thread Lauren Post
This group of patches support the change of hardcoded bluez4 to
virtual/bluez so that the upgrade to bluez5 is easier.

This group of patches must be applied together.  Bluez4 is still
default provider but it will be easier to override and provide bluez5
support in future.

Note there is one related patch for openobex in meta-oe.

Lauren Post (11):
  bluez4:  Add virtual/bluez as provider
  conman:  Change RDEPENDS on bluez4 to virtual/bluez
  libpcap:  Change PACKAGECONFIG from bluez4 to virutal/bluez
  neard:  Change RRECOMMENDS from bluez4 to virtual/bluez
  ofono:  Change DEPENDS from bluez4 to virtual/bluez
  pulseaudio:  Change PACKAGECONFIG from bluez4 to virtual/bluez
  gst-plugin-bluetooth:  Change DEPENDS from bluez4 to virtual/bluez
  gstreamer1.0-plugins-bad:  Change PACKAGECONFIG from bluez4 to
virtual/bluez
  bluez-hcidump:  Change depends from bluez4 to virtual/bluez
  default-providers:  Add virtual/bluez PROVIDER support to bluez4
  package-group:  Change bluez4 to virtual/bluez

 meta/conf/distro/include/default-providers.inc |2 +-
 .../bluez/bluez-hcidump_2.5.bb |2 +-
 meta/recipes-connectivity/bluez/bluez4.inc |4 
 .../bluez/gst-plugin-bluetooth_4.101.bb|2 +-
 meta/recipes-connectivity/connman/connman.inc  |4 ++--
 meta/recipes-connectivity/libpcap/libpcap.inc  |2 +-
 meta/recipes-connectivity/neard/neard.inc  |2 +-
 meta/recipes-connectivity/ofono/ofono.inc  |2 +-
 .../packagegroups/packagegroup-base.bb |2 +-
 .../gstreamer/gstreamer1.0-plugins-bad.inc |2 +-
 .../gstreamer/gstreamer1.0-plugins-bad_git.bb  |2 +-
 meta/recipes-multimedia/pulseaudio/pulseaudio.inc  |4 +++-
 12 files changed, 18 insertions(+), 12 deletions(-)

-- 
1.7.9.5


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 00/11] Change all bluez4 references to virtual/bluez

2014-03-26 Thread Martin Jansa
On Wed, Mar 26, 2014 at 09:27:54AM -0500, Lauren Post wrote:
 This group of patches support the change of hardcoded bluez4 to
 virtual/bluez so that the upgrade to bluez5 is easier.
 
 This group of patches must be applied together.  Bluez4 is still
 default provider but it will be easier to override and provide bluez5
 support in future.
 
 Note there is one related patch for openobex in meta-oe.

virtual/* still doesn't work correctly in runtime variables, use
VIRTUAL-RUNTIME_bluez variable.

Last time I've asked for bluez4-bluez5 upgrade path fix on target I was
told that it's not supported and bluez5 isn't drop-in replacement for
bluez4 (yet), did that change already?

 Lauren Post (11):
   bluez4:  Add virtual/bluez as provider
   conman:  Change RDEPENDS on bluez4 to virtual/bluez
   libpcap:  Change PACKAGECONFIG from bluez4 to virutal/bluez
   neard:  Change RRECOMMENDS from bluez4 to virtual/bluez
   ofono:  Change DEPENDS from bluez4 to virtual/bluez
   pulseaudio:  Change PACKAGECONFIG from bluez4 to virtual/bluez
   gst-plugin-bluetooth:  Change DEPENDS from bluez4 to virtual/bluez
   gstreamer1.0-plugins-bad:  Change PACKAGECONFIG from bluez4 to
 virtual/bluez
   bluez-hcidump:  Change depends from bluez4 to virtual/bluez
   default-providers:  Add virtual/bluez PROVIDER support to bluez4
   package-group:  Change bluez4 to virtual/bluez
 
  meta/conf/distro/include/default-providers.inc |2 +-
  .../bluez/bluez-hcidump_2.5.bb |2 +-
  meta/recipes-connectivity/bluez/bluez4.inc |4 
  .../bluez/gst-plugin-bluetooth_4.101.bb|2 +-
  meta/recipes-connectivity/connman/connman.inc  |4 ++--
  meta/recipes-connectivity/libpcap/libpcap.inc  |2 +-
  meta/recipes-connectivity/neard/neard.inc  |2 +-
  meta/recipes-connectivity/ofono/ofono.inc  |2 +-
  .../packagegroups/packagegroup-base.bb |2 +-
  .../gstreamer/gstreamer1.0-plugins-bad.inc |2 +-
  .../gstreamer/gstreamer1.0-plugins-bad_git.bb  |2 +-
  meta/recipes-multimedia/pulseaudio/pulseaudio.inc  |4 +++-
  12 files changed, 18 insertions(+), 12 deletions(-)
 
 -- 
 1.7.9.5
 
 
 -- 
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 00/11] Change all bluez4 references to virtual/bluez

2014-03-26 Thread Lauren Post
On Wed, Mar 26, 2014 at 09:27:54AM -0500, Lauren Post wrote:
 This group of patches support the change of hardcoded bluez4 to 
 virtual/bluez so that the upgrade to bluez5 is easier.
 
 This group of patches must be applied together.  Bluez4 is still 
 default provider but it will be easier to override and provide bluez5 
 support in future.
 

 virtual/* still doesn't work correctly in runtime variables, use 
 VIRTUAL-RUNTIME_bluez variable.

 Last time I've asked for bluez4-bluez5 upgrade path fix on target I was told 
 that it's not supported and
 uez5 isn't drop-in replacement for
 bluez4 (yet), did that change already?

We are using bluez5.8 and have bbappends for all these components I patched.  I 
just thought it would be easier to upstream rather than maintain all these 
bbappends.  

I missed the bluez5 change to virtual/bluez so will submit that once I rebuild 
with bluez5 as preferred provider on master. 

Lauren
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 00/11] Change all bluez4 references to virtual/bluez

2014-03-26 Thread Otavio Salvador
Hello Martin,

On Wed, Mar 26, 2014 at 11:51 AM, Martin Jansa martin.ja...@gmail.com wrote:
 On Wed, Mar 26, 2014 at 09:27:54AM -0500, Lauren Post wrote:
 This group of patches support the change of hardcoded bluez4 to
 virtual/bluez so that the upgrade to bluez5 is easier.

 This group of patches must be applied together.  Bluez4 is still
 default provider but it will be easier to override and provide bluez5
 support in future.

 Note there is one related patch for openobex in meta-oe.

 virtual/* still doesn't work correctly in runtime variables, use
 VIRTUAL-RUNTIME_bluez variable.
...

Those patches are for /depends/. Did I miss any runtime dependency here?

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 00/11] Change all bluez4 references to virtual/bluez

2014-03-26 Thread Chris Larson
On Wed, Mar 26, 2014 at 7:51 AM, Martin Jansa martin.ja...@gmail.comwrote:

 On Wed, Mar 26, 2014 at 09:27:54AM -0500, Lauren Post wrote:
  This group of patches support the change of hardcoded bluez4 to
  virtual/bluez so that the upgrade to bluez5 is easier.
 
  This group of patches must be applied together.  Bluez4 is still
  default provider but it will be easier to override and provide bluez5
  support in future.
 
  Note there is one related patch for openobex in meta-oe.

 virtual/* still doesn't work correctly in runtime variables, use
 VIRTUAL-RUNTIME_bluez variable.

 Last time I've asked for bluez4-bluez5 upgrade path fix on target I was
 told that it's not supported and bluez5 isn't drop-in replacement for
 bluez4 (yet), did that change already?


Afaik libbluetooth is API compatible, but the dbus api isn't. I haven't
done much runtime testing, though. So I don't think virtual/bluez is an
appropriate name given they aren't 100% compatible bluetooth implmentations
across the board. In meta-mentor, we moved to a combination of two
virtual-runtimes (for flexibility, to facilitate replacement not just with
bluez5, but also potentially with a third party implementation, two
virtual-runtimes, one for hardware support, one for the userland bluetooth
stack, (and potentially others in the future)) with a virtual/libbluetooth
build virtual, and then you need to ensure obexd/hcidump are left out of
the build, since they were merged into bluez5.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 00/11] Change all bluez4 references to virtual/bluez

2014-03-26 Thread Otavio Salvador
Hello Martin,

On Wed, Mar 26, 2014 at 12:35 PM, Martin Jansa martin.ja...@gmail.com wrote:
 On Wed, Mar 26, 2014 at 12:07:13PM -0300, Otavio Salvador wrote:
 On Wed, Mar 26, 2014 at 11:51 AM, Martin Jansa martin.ja...@gmail.com 
 wrote:
  On Wed, Mar 26, 2014 at 09:27:54AM -0500, Lauren Post wrote:
  This group of patches support the change of hardcoded bluez4 to
  virtual/bluez so that the upgrade to bluez5 is easier.
 
  This group of patches must be applied together.  Bluez4 is still
  default provider but it will be easier to override and provide bluez5
  support in future.
 
  Note there is one related patch for openobex in meta-oe.
 
  virtual/* still doesn't work correctly in runtime variables, use
  VIRTUAL-RUNTIME_bluez variable.
 ...

 Those patches are for /depends/. Did I miss any runtime dependency here?

 yes, in 11/11 4/11 2/11 and 1/11

Oh; I missed those indeed.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 00/11] Change all bluez4 references to virtual/bluez

2014-03-26 Thread Otavio Salvador
Hello Chris,

On Wed, Mar 26, 2014 at 12:40 PM, Chris Larson clar...@kergoth.com wrote:
 Last time I've asked for bluez4-bluez5 upgrade path fix on target I was
 told that it's not supported and bluez5 isn't drop-in replacement for
 bluez4 (yet), did that change already?

 Afaik libbluetooth is API compatible, but the dbus api isn't. I haven't done
 much runtime testing, though. So I don't think virtual/bluez is an
 appropriate name given they aren't 100% compatible bluetooth implmentations
 across the board. In meta-mentor, we moved to a combination of two
 virtual-runtimes (for flexibility, to facilitate replacement not just with
 bluez5, but also potentially with a third party implementation, two
 virtual-runtimes, one for hardware support, one for the userland bluetooth
 stack, (and potentially others in the future)) with a virtual/libbluetooth
 build virtual, and then you need to ensure obexd/hcidump are left out of the
 build, since they were merged into bluez5.

I did a look in meta-mentor and I think the interesting commit is:

http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/commit/?id=1444d8b0d3617bea503e498150e558abe5b20114

and a blog post about the API changes:

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

and an issue in Fedora, which might help in the migration:

https://fedoraproject.org/wiki/Changes/Bluez5

I don't know if someone is tracking the packages which uses the D-Bus
API of BlueZ to be check if there are available patches for it.


-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 00/11] Change all bluez4 references to virtual/bluez

2014-03-26 Thread Burton, Ross
On 26 March 2014 16:33, Otavio Salvador ota...@ossystems.com.br wrote:
 I don't know if someone is tracking the packages which uses the D-Bus
 API of BlueZ to be check if there are available patches for it.

So the big problem is PulseAudio.  It finally supports Bluez5 with the
latest release but migrating to Bluez5 right now means a regression in
bluetooth headset support, IIRC.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core