[RFC 00/14] add virtual/bluez

[RFC 00/14] add virtual/bluez

[Peter A. Bigot]

I'm a bit out of my comfort zone here but I needed to do a lot of this
for myself, so figured I'd see how close this is to being mergeable.

This series is a proposed fix for Yocto 5031, providing virtual/bluez to
select between bluez4 and bluez5.  The intent is to continue using
bluez4 as the default, but to allow distros to switch to bluez5 if the
packages they need support the new interface.

There are conflicts.

bluez-hcidump got integrated into bluez5, so there's now virtual build
and runtime support to select the right one.

gst-plugin-bluetooth was removed from bluez5 and AFAICT has no
replacement.

obexd also got integrated into bluez5.  That's harder, because it
crosses the oe-core/meta-oe boundary so the virtual selectors can't be
done solely on oe-core.  I'm proposing an in-recipe conditional on
PREFERRED_PROVIDER-virtual/bluez to select the correct provider for
gnome-bluetooth.

I get my bluez5 builds with the following settings:

PREFERRED_PROVIDER_virtual/bluez = "bluez5"
VIRTUAL-RUNTIME_bluez = "bluez5"
PREFERRED_PROVIDER_bluez-hcidump = "bluez5"
PNBLACKLIST[bluez-hcidump] = "superseded by bluez5"
PNBLACKLIST[gst-plugin-bluetooth] = "dropped from bluez5"
PNBLACKLIST[bluez4] = "superseded by bluez5"

If there's a way to infer the required blacklists from the setting for
virtual/bluez that'd probably be a better approach.

I'm aware that gstreamer1.0-plugins-bad doesn't currently support
bluez5, and I've noted that in the commit message (bluetooth support
will be silently disabled by configure).

There are other packages and other features that don't fully support
bluez5; for example I don't think the issue with headsets is fully
resolved.  I don't feel that this should block merging bluez5 support,
as not everybody who wants bluez5 is going to care about those missing
features, and bluez4 support remains available for those who do.

I've done what I can to make sure all recipes I touched build with both
bluez4 and bluez5 but can't test whether their bluetooth support is
complete.

There's a corresponding set of patches to meta-openembedded for
virtual/bluez support at:

  git://git.openembedded.org/meta-openembedded-contrib pabigot/wip/virtual-bluez

The following changes since commit 3c741a8d33acbf4b3d5eecc04533bc76e2f37253:

  oprofile: 0.9.9 -> 1.0.0 (2014-11-09 10:21:24 +0000)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib pabigot/wip/virtual-bluez
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=pabigot/wip/virtual-bluez

Peter A. Bigot (14):
  bluez5: upgrade to 5.25
  bluez5: fix QA error from configure option
  default-providers: support virtual/bluez
  bluez-hcidump: select provider for bluez4/bluez5
  packagegroup-base: switch to VIRTUAL-RUNTIME_bluez
  pulseaudio: switch to virtual/bluez
  qt-mobility: switch to virtual/bluez
  gstreamer1.0-plugins-bad: switch to virtual/bluez
  ofono: switch to virtual/bluez
  neard: switch to VIRTUAL-RUNTIME_bluez
  libpcap: switch to virtual/bluez
  connman: switch to virtual/bluez
  bluez5: support experimental through PACKAGECONFIG
  bluez5: add a package for tools left in the build area

 meta/conf/distro/include/default-providers.inc     |  3 ++
 .../bluez/bluez-hcidump_2.5.bb                     |  2 +
 meta/recipes-connectivity/bluez/bluez4.inc         |  1 +
 meta/recipes-connectivity/bluez5/bluez5.inc        | 31 +++++++++++++-
 meta/recipes-connectivity/bluez5/bluez5_5.22.bb    |  3 --
 meta/recipes-connectivity/bluez5/bluez5_5.25.bb    | 50 ++++++++++++++++++++++
 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         |  4 +-
 .../gstreamer/gstreamer1.0-plugins-bad_git.bb      |  2 +-
 meta/recipes-multimedia/pulseaudio/pulseaudio.inc  |  2 +-
 meta/recipes-qt/qt4/qt-mobility_1.2.0.inc          |  2 +-
 15 files changed, 96 insertions(+), 16 deletions(-)
 delete mode 100644 meta/recipes-connectivity/bluez5/bluez5_5.22.bb
 create mode 100644 meta/recipes-connectivity/bluez5/bluez5_5.25.bb

-- 
1.8.5.5

[RFC 01/14] bluez5: upgrade to 5.25

[Peter A. Bigot]

See: http://www.bluez.org/release-of-bluez-5-23/
See: http://www.bluez.org/release-of-bluez-5-24/
See: http://www.bluez.org/release-of-bluez-5-25/
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
---
 meta/recipes-connectivity/bluez5/bluez5_5.22.bb | 3 ---
 meta/recipes-connectivity/bluez5/bluez5_5.25.bb | 3 +++
 2 files changed, 3 insertions(+), 3 deletions(-)
 delete mode 100644 meta/recipes-connectivity/bluez5/bluez5_5.22.bb
 create mode 100644 meta/recipes-connectivity/bluez5/bluez5_5.25.bb

diff --git a/meta/recipes-connectivity/bluez5/bluez5_5.22.bb b/meta/recipes-connectivity/bluez5/bluez5_5.22.bb
deleted file mode 100644
index 04116ed..0000000
--- a/meta/recipes-connectivity/bluez5/bluez5_5.22.bb
+++ /dev/null
@@ -1,3 +0,0 @@
-require bluez5.inc
-SRC_URI[md5sum] = "fd0783c8bc524bc9b26514aad1f85814"
-SRC_URI[sha256sum] = "e8b866515a18116c7048a55081be9238a51447c9448ed20997b0432b13ba0882"
diff --git a/meta/recipes-connectivity/bluez5/bluez5_5.25.bb b/meta/recipes-connectivity/bluez5/bluez5_5.25.bb
new file mode 100644
index 0000000..8cb32ec
--- /dev/null
+++ b/meta/recipes-connectivity/bluez5/bluez5_5.25.bb
@@ -0,0 +1,3 @@
+require bluez5.inc
+SRC_URI[md5sum] = "41bd0c915abde255622150ce6dcae67b"
+SRC_URI[sha256sum] = "5ca62f3f45e2638a0f7a81658d6c8813ee01487436ae8e53e9fe395e23d1fd30"
-- 
1.8.5.5

[RFC 02/14] bluez5: fix QA error from configure option

[Peter A. Bigot]

The systemdunitdir option was split into systemdsystemunitdir and
systemduserunitdir before bluez5 was ever released, so this produced a
QA error and was ignored.  There appears to be no reason to override the
inferred default, so replace it with an explicit --enable-systemd.

Signed-off-by: Peter A. Bigot <pab@pabigot.com>
---
 meta/recipes-connectivity/bluez5/bluez5.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc b/meta/recipes-connectivity/bluez5/bluez5.inc
index c3dd946..28c014f 100644
--- a/meta/recipes-connectivity/bluez5/bluez5.inc
+++ b/meta/recipes-connectivity/bluez5/bluez5.inc
@@ -26,7 +26,7 @@ EXTRA_OECONF = "\
   --disable-cups \
   --enable-test \
   --enable-datafiles \
-  ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', '--with-systemdunitdir=${systemd_unitdir}/system/', '--disable-systemd', d)} \
+  ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', '--enable-systemd', '--disable-systemd', d)} \
   --enable-library \
 "
 
-- 
1.8.5.5

[RFC 03/14] default-providers: support virtual/bluez

[Peter A. Bigot]

Select between bluez4 and bluez5 by setting the PREFERRED_PROVIDER for
virtual/bluez to one or the other, and VIRTUAL-RUNTIME for bluez to
match.

[YOCTO #5031]

Signed-off-by: Peter A. Bigot <pab@pabigot.com>
---
 meta/conf/distro/include/default-providers.inc | 2 ++
 meta/recipes-connectivity/bluez/bluez4.inc     | 1 +
 meta/recipes-connectivity/bluez5/bluez5.inc    | 1 +
 3 files changed, 4 insertions(+)

diff --git a/meta/conf/distro/include/default-providers.inc b/meta/conf/distro/include/default-providers.inc
index a1167fd..e357870 100644
--- a/meta/conf/distro/include/default-providers.inc
+++ b/meta/conf/distro/include/default-providers.inc
@@ -14,6 +14,7 @@ PREFERRED_PROVIDER_virtual/update-alternatives ?= "opkg-utils"
 PREFERRED_PROVIDER_virtual/update-alternatives-native ?= "opkg-utils-native"
 PREFERRED_PROVIDER_virtual/libx11 ?= "libx11"
 PREFERRED_PROVIDER_xf86-video-intel ?= "xf86-video-intel"
+PREFERRED_PROVIDER_virtual/bluez ?= "bluez4"
 
 #
 # Default virtual runtime providers
@@ -21,6 +22,7 @@ PREFERRED_PROVIDER_xf86-video-intel ?= "xf86-video-intel"
 VIRTUAL-RUNTIME_update-alternatives ?= "update-alternatives-opkg"
 VIRTUAL-RUNTIME_apm ?= "apm"
 VIRTUAL-RUNTIME_alsa-state ?= "alsa-state"
+VIRTUAL-RUNTIME_bluez ?= "bluez4"
 
 #
 # Default recipe providers
diff --git a/meta/recipes-connectivity/bluez/bluez4.inc b/meta/recipes-connectivity/bluez/bluez4.inc
index 11c9616..088473d 100644
--- a/meta/recipes-connectivity/bluez/bluez4.inc
+++ b/meta/recipes-connectivity/bluez/bluez4.inc
@@ -9,6 +9,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e \
                     file://sbc/sbc.c;beginline=1;endline=25;md5=1a40781ed30d50d8639323a184aeb191"
 DEPENDS = "udev libusb dbus-glib glib-2.0 libcheck readline libsndfile1"
 RDEPENDS_${PN}-dev = "bluez-hcidump"
+PROVIDES += "virtual/bluez"
 
 PACKAGECONFIG ??= "\
     ${@bb.utils.contains('DISTRO_FEATURES', 'alsa', 'alsa', '', d)}\
diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc b/meta/recipes-connectivity/bluez5/bluez5.inc
index 28c014f..97a28e3 100644
--- a/meta/recipes-connectivity/bluez5/bluez5.inc
+++ b/meta/recipes-connectivity/bluez5/bluez5.inc
@@ -7,6 +7,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e \
                     file://COPYING.LIB;md5=fb504b67c50331fc78734fed90fb0e09 \
                     file://src/main.c;beginline=1;endline=24;md5=9bc54b93cd7e17bf03f52513f39f926e"
 DEPENDS = "udev libusb dbus-glib glib-2.0 libcheck readline"
+PROVIDES += "virtual/bluez"
 
 RCONFLICTS_${PN} = "bluez4"
 
-- 
1.8.5.5

[RFC 04/14] bluez-hcidump: select provider for bluez4/bluez5

[Peter A. Bigot]

bluez-hcidump was a separate package in bluez4, but was integrated into
bluez5.

Signed-off-by: Peter A. Bigot <pab@pabigot.com>
---
 meta/conf/distro/include/default-providers.inc       | 1 +
 meta/recipes-connectivity/bluez/bluez-hcidump_2.5.bb | 2 ++
 meta/recipes-connectivity/bluez5/bluez5.inc          | 3 ++-
 3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/conf/distro/include/default-providers.inc b/meta/conf/distro/include/default-providers.inc
index e357870..55633ba 100644
--- a/meta/conf/distro/include/default-providers.inc
+++ b/meta/conf/distro/include/default-providers.inc
@@ -45,5 +45,6 @@ PREFERRED_PROVIDER_udev ?= "${@bb.utils.contains('DISTRO_FEATURES','systemd','sy
 # There are issues with runtime packages and PREFERRED_PROVIDER, see YOCTO #5044 for details
 # on this rather strange entry.
 PREFERRED_PROVIDER_bluez4 ?= "bluez4"
+PREFERRED_PROVIDER_bluez-hcidump ?= "bluez-hcidump"
 # Alternative is ltp-ddt in meta-oe: meta-oe/recipes-devtools/ltp-ddt/ltp-ddt_0.0.4.bb
 PREFERRED_PROVIDER_ltp ?= "ltp"
diff --git a/meta/recipes-connectivity/bluez/bluez-hcidump_2.5.bb b/meta/recipes-connectivity/bluez/bluez-hcidump_2.5.bb
index 5c1f476..3950630 100644
--- a/meta/recipes-connectivity/bluez/bluez-hcidump_2.5.bb
+++ b/meta/recipes-connectivity/bluez/bluez-hcidump_2.5.bb
@@ -3,7 +3,9 @@ DESCRIPTION = "The hcidump tool reads raw HCI data coming from and going to a Bl
 and displays the commands, events and data in a human-readable form."
 
 SECTION = "console"
+# hcidump was integrated into bluez5
 DEPENDS = "bluez4"
+RCONFLICTS_${PN} = "bluez5"
 LICENSE = "GPLv2+"
 LIC_FILES_CHKSUM = "file://COPYING;md5=eb723b61539feef013de476e68b5c50a \
                     file://src/hcidump.c;beginline=1;endline=23;md5=3bee3a162dff43a5be7470710b99fbcf"
diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc b/meta/recipes-connectivity/bluez5/bluez5.inc
index 97a28e3..241b16f 100644
--- a/meta/recipes-connectivity/bluez5/bluez5.inc
+++ b/meta/recipes-connectivity/bluez5/bluez5.inc
@@ -7,7 +7,8 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e \
                     file://COPYING.LIB;md5=fb504b67c50331fc78734fed90fb0e09 \
                     file://src/main.c;beginline=1;endline=24;md5=9bc54b93cd7e17bf03f52513f39f926e"
 DEPENDS = "udev libusb dbus-glib glib-2.0 libcheck readline"
-PROVIDES += "virtual/bluez"
+PROVIDES += "virtual/bluez bluez-hcidump"
+RPROVIDES_${PN} += "bluez-hcidump"
 
 RCONFLICTS_${PN} = "bluez4"
 
-- 
1.8.5.5

[RFC 05/14] packagegroup-base: switch to VIRTUAL-RUNTIME_bluez

[Peter A. Bigot]

Signed-off-by: Peter A. Bigot <pab@pabigot.com>
---
 meta/recipes-core/packagegroups/packagegroup-base.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/packagegroups/packagegroup-base.bb b/meta/recipes-core/packagegroups/packagegroup-base.bb
index f4b2cd5..7c24849 100644
--- a/meta/recipes-core/packagegroups/packagegroup-base.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-base.bb
@@ -203,7 +203,7 @@ RRECOMMENDS_packagegroup-base-pcmcia = "\
 
 SUMMARY_packagegroup-base-bluetooth = "Bluetooth support"
 RDEPENDS_packagegroup-base-bluetooth = "\
-    bluez4 \
+    ${VIRTUAL-RUNTIME_bluez} \
     ${@bb.utils.contains('COMBINED_FEATURES', 'alsa', 'libasound-module-bluez', '',d)} \
     "
 
-- 
1.8.5.5

[RFC 06/14] pulseaudio: switch to virtual/bluez

[Peter A. Bigot]

Signed-off-by: Peter A. Bigot <pab@pabigot.com>
---
 meta/recipes-multimedia/pulseaudio/pulseaudio.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
index db144a9..f06b15c 100644
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
@@ -31,7 +31,7 @@ EXTRA_OECONF = "\
                 ac_cv_header_valgrind_memcheck_h=no \
 "
 
-PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 'bluez4', '', d)} \
+PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 'virtual/bluez', '', d)} \
                    ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'systemd', '', d)} \
                    ${@bb.utils.contains('DISTRO_FEATURES', 'zeroconf', 'avahi', '', d)} \
                    ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', '', d)}"
-- 
1.8.5.5

Re: [RFC 06/14] pulseaudio: switch to virtual/bluez

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1405 bytes --]

On Mon, Nov 10, 2014 at 03:13:03PM -0600, Peter A. Bigot wrote:
> Signed-off-by: Peter A. Bigot <pab@pabigot.com>
> ---
>  meta/recipes-multimedia/pulseaudio/pulseaudio.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
> index db144a9..f06b15c 100644
> --- a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
> +++ b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
> @@ -31,7 +31,7 @@ EXTRA_OECONF = "\
>                  ac_cv_header_valgrind_memcheck_h=no \
>  "
>  
> -PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 'bluez4', '', d)} \
> +PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 'virtual/bluez', '', d)} \

This has to be wrong.

>                     ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'systemd', '', d)} \
>                     ${@bb.utils.contains('DISTRO_FEATURES', 'zeroconf', 'avahi', '', d)} \
>                     ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', '', d)}"
> -- 
> 1.8.5.5
> 
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

Re: [RFC 06/14] pulseaudio: switch to virtual/bluez

[Peter A. Bigot]

On 11/10/2014 05:20 PM, Martin Jansa wrote:
> On Mon, Nov 10, 2014 at 03:13:03PM -0600, Peter A. Bigot wrote:
>> Signed-off-by: Peter A. Bigot <pab@pabigot.com>
>> ---
>>   meta/recipes-multimedia/pulseaudio/pulseaudio.inc | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
>> index db144a9..f06b15c 100644
>> --- a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
>> +++ b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
>> @@ -31,7 +31,7 @@ EXTRA_OECONF = "\
>>                   ac_cv_header_valgrind_memcheck_h=no \
>>   "
>>   
>> -PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 'bluez4', '', d)} \
>> +PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 'virtual/bluez', '', d)} \
> This has to be wrong.

Indeed.  Make that:

-PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 
'bluez4', '', d)} \
+BLUEZ = "${@oe.utils.conditional('PREFERRED_PROVIDER_virtual/bluez', 
'bluez5', 'bluez5', 'bluez4', d)}"
+PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 
'${BLUEZ}', '', d)} \

Branch updated.  Thanks.

Peter
>
>>                      ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'systemd', '', d)} \
>>                      ${@bb.utils.contains('DISTRO_FEATURES', 'zeroconf', 'avahi', '', d)} \
>>                      ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', '', d)}"
>> -- 
>> 1.8.5.5
>>
>> -- 
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

[RFC 07/14] qt-mobility: switch to virtual/bluez

[Peter A. Bigot]

Signed-off-by: Peter A. Bigot <pab@pabigot.com>
---
 meta/recipes-qt/qt4/qt-mobility_1.2.0.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-qt/qt4/qt-mobility_1.2.0.inc b/meta/recipes-qt/qt4/qt-mobility_1.2.0.inc
index ae1769d..61b5281 100644
--- a/meta/recipes-qt/qt4/qt-mobility_1.2.0.inc
+++ b/meta/recipes-qt/qt4/qt-mobility_1.2.0.inc
@@ -3,7 +3,7 @@ DEPENDS = "gstreamer util-linux"
 
 PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'pulseaudio', 'pulseaudio', '', d)} \
                    ${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 'bluetooth', '', d)}"
-PACKAGECONFIG[bluetooth] = ",,bluez4"
+PACKAGECONFIG[bluetooth] = ",,virtual/bluez"
 PACKAGECONFIG[pulseaudio] = ",,pulseaudio"
 
 LICENSE = "LGPLv2.1"
-- 
1.8.5.5

Re: [RFC 07/14] qt-mobility: switch to virtual/bluez

[Richard Purdie]

On Mon, 2014-11-10 at 15:13 -0600, Peter A. Bigot wrote:
> Signed-off-by: Peter A. Bigot <pab@pabigot.com>
> ---
>  meta/recipes-qt/qt4/qt-mobility_1.2.0.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-qt/qt4/qt-mobility_1.2.0.inc b/meta/recipes-qt/qt4/qt-mobility_1.2.0.inc
> index ae1769d..61b5281 100644
> --- a/meta/recipes-qt/qt4/qt-mobility_1.2.0.inc
> +++ b/meta/recipes-qt/qt4/qt-mobility_1.2.0.inc
> @@ -3,7 +3,7 @@ DEPENDS = "gstreamer util-linux"
>  
>  PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'pulseaudio', 'pulseaudio', '', d)} \
>                     ${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 'bluetooth', '', d)}"
> -PACKAGECONFIG[bluetooth] = ",,bluez4"
> +PACKAGECONFIG[bluetooth] = ",,virtual/bluez"
>  PACKAGECONFIG[pulseaudio] = ",,pulseaudio"
>  
>  LICENSE = "LGPLv2.1"

I think its examples like this where I start to get concerned. I don't
think the problem we're trying to solve here (bluez4 verses bluez5) maps
well to the way virtual/* is meant to work.

virtual/* things are meant to be equivalent, it doesn't matter which
ones the recipe builds against, it works. A compiler or a kernel are
good examples. That isn't the case for v4 verses v5 since some software
works with 4, some with 5 and some with both.

So what do we need to do?

I think this needs a:

PACKAGECONFIG[bluetooth5] = ",,bluez5"

and then we add a bluetooth5 DiSTRO_FEATURE and a:

                    ${@bb.utils.contains('DISTRO_FEATURES',
'bluetooth5', 'bluetooth5', '', d)}"

We could probably use a mechanism to flag two options as conflicting,
e.g. both bluetooth and bluetooth5 in DISTRO_FEATURES or in
PACKAGECONFIG however that is a separate issue.

We'll of course still need VIRTUAL-RUNTIME_bluez but that isn't a new
problem.

Does that approach work for people?

Cheers,

Richard

Re: [RFC 07/14] qt-mobility: switch to virtual/bluez

[Peter A. Bigot]

On 11/12/2014 05:06 AM, Richard Purdie wrote:
> On Mon, 2014-11-10 at 15:13 -0600, Peter A. Bigot wrote:
>> Signed-off-by: Peter A. Bigot <pab@pabigot.com>
>> ---
>>   meta/recipes-qt/qt4/qt-mobility_1.2.0.inc | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/meta/recipes-qt/qt4/qt-mobility_1.2.0.inc b/meta/recipes-qt/qt4/qt-mobility_1.2.0.inc
>> index ae1769d..61b5281 100644
>> --- a/meta/recipes-qt/qt4/qt-mobility_1.2.0.inc
>> +++ b/meta/recipes-qt/qt4/qt-mobility_1.2.0.inc
>> @@ -3,7 +3,7 @@ DEPENDS = "gstreamer util-linux"
>>   
>>   PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'pulseaudio', 'pulseaudio', '', d)} \
>>                      ${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 'bluetooth', '', d)}"
>> -PACKAGECONFIG[bluetooth] = ",,bluez4"
>> +PACKAGECONFIG[bluetooth] = ",,virtual/bluez"
>>   PACKAGECONFIG[pulseaudio] = ",,pulseaudio"
>>   
>>   LICENSE = "LGPLv2.1"
> I think its examples like this where I start to get concerned. I don't
> think the problem we're trying to solve here (bluez4 verses bluez5) maps
> well to the way virtual/* is meant to work.
>
> virtual/* things are meant to be equivalent, it doesn't matter which
> ones the recipe builds against, it works. A compiler or a kernel are
> good examples. That isn't the case for v4 verses v5 since some software
> works with 4, some with 5 and some with both.

You raise some good questions.  I'll come back to whether the name for 
"whatever provides build-time support for bluetooth" should be spelled 
"virtual/bluez" or something else.

I think using bluez5 (bluetooth5) and bluez4 (bluetooth) as distinct 
PACKAGECONFIG options would be a mistake, because it propagates the 
assumption that "bluetooth" in Linux is a multivalent concept. Bluetooth 
in Linux is bluez.  Bluez is bluez5.  Work stopped on bluez4 over two 
years ago, and nobody's come up with third alternative.  IMO, the 
packageconfig option should be "bluetooth", not "bluez*".  I did see 
what Chris Larson wrote in 
http://lists.openembedded.org/pipermail/openembedded-core/2014-March/091008.html 
but I just don't see the value in adding extra infrastructure for a 
bunch of options that either don't exist now or won't exist in the near 
future.

Of the roughly 16 recipes I had to touch, only one (pulseaudio) clearly 
distinguishes between bluez4 and bluez5 when being configured, and I 
suspect that's just to simplify transition.  The others either figure 
out which version they were given and use it, or will only work with one 
or the other.  They all at least build with virtual/bluez, though they 
might internally disable bluetooth support or fail at runtime if bluez5 
is what's available.  (Qt 5.4 will support bluez5; it's unclear to me 
whether it still supports bluez4.)

There are and will continue to be certain recipes that will never move 
beyond bluez4, because they're no longer maintained or nobody has found 
it worthwhile (obex stuff) or a priority (headset stuff) to re-implement 
the functionality they depend on under the new API. So we do need to 
support using bluez4 and bluez5 as alternatives. But most recipes don't 
seem to care who provides "bluetooth", and if it's currently bluez4 and 
the package is maintained it'll eventually become bluez5.  Thus 
"virtual/bluez".  AFAIK the libbluetooth API is unchanged; it's the dbus 
API that's different.  If consensus is to substitute something like 
"distro/bluez" instead of "virtual/bluez" to remove the implication it's 
completely API-equivalent that'd be fine, but I think we do need some 
name to serve that role without putting the conditional in every recipe 
that might reference the selected bluetooth solution.

> So what do we need to do?
>
> I think this needs a:
>
> PACKAGECONFIG[bluetooth5] = ",,bluez5"
>
> and then we add a bluetooth5 DiSTRO_FEATURE and a:
>
>                      ${@bb.utils.contains('DISTRO_FEATURES',
> 'bluetooth5', 'bluetooth5', '', d)}"
>
> We could probably use a mechanism to flag two options as conflicting,
> e.g. both bluetooth and bluetooth5 in DISTRO_FEATURES or in
> PACKAGECONFIG however that is a separate issue.

Using bluez4 and bluez5 in DISTRO_FEATURES makes some sense, as a 
parallel to systemd vs sysvinit.  (I don't like "bluetooth5" because 
there's no such thing; since we already have "bluetooth" I'd suggest 
making "bluez4" the canonical spelling and interpreting "bluetooth" in 
the absence of "bluez5" as being an alias for "bluez4".)  This provides 
a way to set the PREFERRED_PROVIDER for "distro/bluez" and possibly to 
set the PNBLACKLISTs to exclude the recipes that are not appropriate 
under bluez4.

Then we just use "distro/bluez" instead of "virtual/bluez" in all the 
recipes.

Is that any closer to acceptable?

Peter

>
> We'll of course still need VIRTUAL-RUNTIME_bluez but that isn't a new
> problem.
>
> Does that approach work for people?
>
> Cheers,
>
> Richard
>

Re: [RFC 07/14] qt-mobility: switch to virtual/bluez

[Richard Purdie]

On Wed, 2014-11-12 at 07:48 -0600, Peter A. Bigot wrote:
> You raise some good questions.  I'll come back to whether the name for 
> "whatever provides build-time support for bluetooth" should be spelled 
> "virtual/bluez" or something else.

Naming is probably the least of the worries here. I will say that
virtual/* has a very specific meaning in DEPENDS space though.

> I think using bluez5 (bluetooth5) and bluez4 (bluetooth) as distinct 
> PACKAGECONFIG options would be a mistake, because it propagates the 
> assumption that "bluetooth" in Linux is a multivalent concept. Bluetooth 
> in Linux is bluez.  Bluez is bluez5.  Work stopped on bluez4 over two 
> years ago, and nobody's come up with third alternative.  IMO, the 
> packageconfig option should be "bluetooth", not "bluez*".  I did see 
> what Chris Larson wrote in 
> http://lists.openembedded.org/pipermail/openembedded-core/2014-March/091008.html 
> but I just don't see the value in adding extra infrastructure for a 
> bunch of options that either don't exist now or won't exist in the near 
> future.

This kind of misses the problem though. Personally, I'd love to just
switch to bluez5 and be done with it. Our userbase expects something
with a little more thought though, there are people who will be
transitioning at different times and we can't really force them into a
flag day.

The issue is that if we just have a single "blue*" option, you basically
have no idea what you're going to get out of the build, it fails on the
determinism tests. You say qt5 may or may not work with 4, I suspect
there are several packages with this issue. My concern is that as we
update software, we basically have no idea what we're enabling or
disabling. This is exactly the kind of thing PACKAGECONFIG is meant to
spell out though.

This is why I suggested a 4 and 5 PACKAGECONFIG option since it then
clearly states what its building.

FWIW I do agree bluez4 is a dead end so calling the options "bluez4" and
"bluez" (for v5) would be ideal. We have some issues with legacy
namespace though and I'm not sure how we handle that.

> Of the roughly 16 recipes I had to touch, only one (pulseaudio) clearly 
> distinguishes between bluez4 and bluez5 when being configured, and I 
> suspect that's just to simplify transition.  The others either figure 
> out which version they were given and use it, or will only work with one 
> or the other.  They all at least build with virtual/bluez, though they 
> might internally disable bluetooth support or fail at runtime if bluez5 
> is what's available.  (Qt 5.4 will support bluez5; it's unclear to me 
> whether it still supports bluez4.)
> 
> There are and will continue to be certain recipes that will never move 
> beyond bluez4, because they're no longer maintained or nobody has found 
> it worthwhile (obex stuff) or a priority (headset stuff) to re-implement 
> the functionality they depend on under the new API. So we do need to 
> support using bluez4 and bluez5 as alternatives. But most recipes don't 
> seem to care who provides "bluetooth", and if it's currently bluez4 and 
> the package is maintained it'll eventually become bluez5.  Thus 
> "virtual/bluez".  AFAIK the libbluetooth API is unchanged; it's the dbus 
> API that's different.  If consensus is to substitute something like 
> "distro/bluez" instead of "virtual/bluez" to remove the implication it's 
> completely API-equivalent that'd be fine, but I think we do need some 
> name to serve that role without putting the conditional in every recipe 
> that might reference the selected bluetooth solution.

My reasoning is that if we need to provide specific PACKAGECONFIG for
determinism, we may as well then depend specifically on the recipe
namespaces.

"virtual/*" does not map to this usage as Chris mentions. I've been
around long enough to see what misuse of the provider namespace does and
I don't want to go there again. Introducing a "distro/bluez" would
probably just confuse things since its a new convention without well
defined meaning and we don't have a common case of this to deal with in
general.

> Using bluez4 and bluez5 in DISTRO_FEATURES makes some sense, as a 
> parallel to systemd vs sysvinit.  (I don't like "bluetooth5" because 
> there's no such thing; since we already have "bluetooth" I'd suggest 
> making "bluez4" the canonical spelling and interpreting "bluetooth" in 
> the absence of "bluez5" as being an alias for "bluez4".)

That alias support means more anonymous code we can likely never get rid
of so it makes me nervous. The DISTRO_FEATURES part is actually the part
I like least about my proposal as it happens, but I'm failing to see a
good way of presenting this to users in a way which lets them choose the
time of their upgrade clearly and ensures that builds are deterministic.

>   This provides 
> a way to set the PREFERRED_PROVIDER for "distro/bluez" and possibly to 
> set the PNBLACKLISTs to exclude the recipes that are not appropriate 
> under bluez4.
> 
> Then we just use "distro/bluez" instead of "virtual/bluez" in all the 
> recipes.
> 
> Is that any closer to acceptable?

I remain sceptical I'm afraid, I certainly don't see distro/ as having
any value over virtual/ :(.

Cheers,

Richard

Re: [RFC 07/14] qt-mobility: switch to virtual/bluez

[Peter A. Bigot]

On 11/13/2014 04:06 AM, Richard Purdie wrote:
> On Wed, 2014-11-12 at 07:48 -0600, Peter A. Bigot wrote:
>> You raise some good questions.  I'll come back to whether the name for
>> "whatever provides build-time support for bluetooth" should be spelled
>> "virtual/bluez" or something else.
> Naming is probably the least of the worries here. I will say that
> virtual/* has a very specific meaning in DEPENDS space though.

So let me step back and explain what I'm doing.

I don't use *any* of these packages with bluetooth (as I think I stated 
originally).  I need bluez5 on the system because that's the only 
solution that has an evolving BT-LE with GATT API that I can use for 
custom applications.  bluez4 is useless to me.

Because bluez5 and bluez4 cannot be co-resident, I can't use bluez5 
unless I can tell everything that hard-codes a dependency on bluez4 to 
suck it up and try bluez5 instead, or de-couple them from bluez entirely.

I could decouple by explicitly excluding some recipes and overriding 
default PACKAGECONFIG settings for others in local.conf, but that 
doesn't provide a solution anybody else can leverage.  Yocto 5031's been 
open for way too long.  I believe we all agree this needs to be fixed.


>
>> I think using bluez5 (bluetooth5) and bluez4 (bluetooth) as distinct
>> PACKAGECONFIG options would be a mistake, because it propagates the
>> assumption that "bluetooth" in Linux is a multivalent concept. Bluetooth
>> in Linux is bluez.  Bluez is bluez5.  Work stopped on bluez4 over two
>> years ago, and nobody's come up with third alternative.  IMO, the
>> packageconfig option should be "bluetooth", not "bluez*".  I did see
>> what Chris Larson wrote in
>> http://lists.openembedded.org/pipermail/openembedded-core/2014-March/091008.html
>> but I just don't see the value in adding extra infrastructure for a
>> bunch of options that either don't exist now or won't exist in the near
>> future.
> This kind of misses the problem though. Personally, I'd love to just
> switch to bluez5 and be done with it. Our userbase expects something
> with a little more thought though, there are people who will be
> transitioning at different times and we can't really force them into a
> flag day.

I don't like the "flag day" idea either, so I think there should be a 
way for whoever's putting together a system to select between bluez4 and 
bluez5 as the provider of bluetooth capability.  It should also be a 
single point of variation that informs the rest of the system.  I 
actually prefer your DISTRO_FEATURES solution over the 
PREFERRED_PROVIDER I used because whether a distro chooses to be based 
on bluez4 or bluez5 seems comparable to whether they choose to be based 
on systemd or sysvinit.

> The issue is that if we just have a single "blue*" option, you basically
> have no idea what you're going to get out of the build, it fails on the
> determinism tests. You say qt5 may or may not work with 4, I suspect
> there are several packages with this issue. My concern is that as we
> update software, we basically have no idea what we're enabling or
> disabling. This is exactly the kind of thing PACKAGECONFIG is meant to
> spell out though.
>
> This is why I suggested a 4 and 5 PACKAGECONFIG option since it then
> clearly states what its building.

There are two problems with doing it at the PACKAGECONFIG level with 
distinct bluez4 and bluez5 options.  First, how does the distro provide 
a mechanism for selecting between bluez4 and bluez5 being set in 
PACKAGECONFIG_foo for all the recipes in all layers that are affected by 
the distro-level decision?  I can't see any solution that doesn't 
involve a well-defined conditional expression used in the recipe or in 
the layer.conf, whether it's testing the value of 
PREFERRED_PROVIDER_virtual/bluez or the presence of a specific key in 
DISTRO_FEATURES.

Once you go there, you get the second problem.  Only one of the sixteen 
packages distinguishes bluez4 from bluez5 in a meaningful way during 
configuration.  For the others, you just ask for bluetooth.  
Deterministically selecting either bluez4 or bluez5 to be present via 
DEPENDS doesn't change whether it'll work with your selection, it just 
makes it explicit which one you're using---though it's not explicit if 
the choice is controlled by an externally-customizable variable like 
PACKAGECONFIG.

Each recipe will work completely with both bluez4 and bluez5, or will 
work at build time but fail at runtime with one or both, or will fail at 
build time with one or both.  From my experience I expect most bluez4 
packages fall into the "bluez5 builds fine but maybe doesn't work".  
There's simply no way to detect that without actually using the package 
in a context where bluetooth is tested, which may require specific 
hardware like headsets.

> FWIW I do agree bluez4 is a dead end so calling the options "bluez4" and
> "bluez" (for v5) would be ideal. We have some issues with legacy
> namespace though and I'm not sure how we handle that.
>
>> Of the roughly 16 recipes I had to touch, only one (pulseaudio) clearly
>> distinguishes between bluez4 and bluez5 when being configured, and I
>> suspect that's just to simplify transition.  The others either figure
>> out which version they were given and use it, or will only work with one
>> or the other.  They all at least build with virtual/bluez, though they
>> might internally disable bluetooth support or fail at runtime if bluez5
>> is what's available.  (Qt 5.4 will support bluez5; it's unclear to me
>> whether it still supports bluez4.)
>>
>> There are and will continue to be certain recipes that will never move
>> beyond bluez4, because they're no longer maintained or nobody has found
>> it worthwhile (obex stuff) or a priority (headset stuff) to re-implement
>> the functionality they depend on under the new API. So we do need to
>> support using bluez4 and bluez5 as alternatives. But most recipes don't
>> seem to care who provides "bluetooth", and if it's currently bluez4 and
>> the package is maintained it'll eventually become bluez5.  Thus
>> "virtual/bluez".  AFAIK the libbluetooth API is unchanged; it's the dbus
>> API that's different.  If consensus is to substitute something like
>> "distro/bluez" instead of "virtual/bluez" to remove the implication it's
>> completely API-equivalent that'd be fine, but I think we do need some
>> name to serve that role without putting the conditional in every recipe
>> that might reference the selected bluetooth solution.
> My reasoning is that if we need to provide specific PACKAGECONFIG for
> determinism, we may as well then depend specifically on the recipe
> namespaces.
>
> "virtual/*" does not map to this usage as Chris mentions. I've been
> around long enough to see what misuse of the provider namespace does and
> I don't want to go there again. Introducing a "distro/bluez" would
> probably just confuse things since its a new convention without well
> defined meaning and we don't have a common case of this to deal with in
> general.
>
>> Using bluez4 and bluez5 in DISTRO_FEATURES makes some sense, as a
>> parallel to systemd vs sysvinit.  (I don't like "bluetooth5" because
>> there's no such thing; since we already have "bluetooth" I'd suggest
>> making "bluez4" the canonical spelling and interpreting "bluetooth" in
>> the absence of "bluez5" as being an alias for "bluez4".)
> That alias support means more anonymous code we can likely never get rid
> of so it makes me nervous. The DISTRO_FEATURES part is actually the part
> I like least about my proposal as it happens, but I'm failing to see a
> good way of presenting this to users in a way which lets them choose the
> time of their upgrade clearly and ensures that builds are deterministic.
>
>>    This provides
>> a way to set the PREFERRED_PROVIDER for "distro/bluez" and possibly to
>> set the PNBLACKLISTs to exclude the recipes that are not appropriate
>> under bluez4.
>>
>> Then we just use "distro/bluez" instead of "virtual/bluez" in all the
>> recipes.
>>
>> Is that any closer to acceptable?
> I remain sceptical I'm afraid, I certainly don't see distro/ as having
> any value over virtual/ :(.

OK.  So how about this:

Eliminate "bluetooth" as a DISTRO_FEATURE and switch to "bluez4", 
"bluez5", or nothing.  Add diagnostics if the system detects a violation 
of this, so existing users are notified of the change. Treat this 
distinction as parallel to systemd vs sysvinit.

For recipes that depend on bluetooth:

1) add one or both of PACKAGECONFIG[bluez4] and PACKAGECONFIG[bluez5] 
settings that explicitly add the dependency on the specific version.  
For the recipes that don't make their needs clear, we could add both or 
just bluez4.  If we do both, most will probably look something like:

PACKAGECONFIG[bluez4] = "--enable-bluetooth,--disable-bluetooth,bluez4"
PACKAGECONFIG[bluez5] = "--enable-bluetooth,--disable-bluetooth,bluez5"

2) If the existing default PACKAGECONFIG for these includes "bluetooth" 
or "bluez", select the appropriate default based on the DISTRO_FEATURE 
setting.  There should be a system-level variable DISTRO_BLUEZ to be "", 
"bluez4", or "bluez5" so each recipe doesn't replicate the really ugly 
oe.utils.contains code to extract the desired substring from 
DISTRO_FEATURES in every recipe.

At this point, we have an OE-Core that allows the user to select which 
system provides bluetooth support, recipes in oe-core and meta-oe that 
build correctly to the best of our knowledge with either one, and a way 
of explicitly selecting the provider on a per-recipe basis.  What we 
don't have is knowledge of whether packages that are now enabled for 
bluez5 actually work with bluez5. But we can't get that knowledge at the 
root of the development community where we're sitting; it's gotta come 
from the users.

Since we're at the very beginning of a new development cycle there will 
be no better time to introduce this level of breakage and tell everybody 
"Hey, test your systems with bluez4 and bluez5 and tell us what doesn't 
work", unless you want to announce it now and do it in 1.9 which I don't 
think would help much.

If we can't make any progress at all on enabling bluez5 out of concern 
for breaking existing bluez4 users who aren't actively engaged there's 
more and more kinds of goodness that's unavailable to our users, and 
more and more packages that will end up supporting only bluez5 so 
wouldn't be upgradable.  This problem is only going to get worse.

Peter


>
> Cheers,
>
> Richard
>

[RFC 08/14] gstreamer1.0-plugins-bad: switch to virtual/bluez

[Peter A. Bigot]

Be aware that current versions of gstreamer1.0-plugins-bad (through
1.4.3) do not currently support bluez5, and will silently disable
bluetooth support until that has been addressed upstream.

Signed-off-by: Peter A. Bigot <pab@pabigot.com>
---
 meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc    | 4 ++--
 meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_git.bb | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
index dab0bf5..913a338 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
@@ -18,7 +18,7 @@ PACKAGECONFIG_GL ?= "${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'gles2',
 PACKAGECONFIG ??= " \
     ${PACKAGECONFIG_GL} \
     ${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 'wayland', '', d)} \
-    ${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 'bluez', '', d)} \
+    ${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 'virtual/bluez', '', d)} \
     ${@bb.utils.contains('DISTRO_FEATURES', 'directfb', 'directfb', '', d)} \
     orc curl uvch264 neon sndfile \
     hls sbc dash bz2 smoothstreaming \
@@ -49,7 +49,7 @@ PACKAGECONFIG[bz2]             = "--enable-bz2,--disable-bz2,bzip2"
 PACKAGECONFIG[fluidsynth]      = "--enable-fluidsynth,--disable-fluidsynth,fluidsynth"
 PACKAGECONFIG[schroedinger]    = "--enable-schro,--disable-schro,schroedinger"
 PACKAGECONFIG[smoothstreaming] = "--enable-smoothstreaming,--disable-smoothstreaming,libxml2"
-PACKAGECONFIG[bluez]           = "--enable-bluez,--disable-bluez,bluez4"
+PACKAGECONFIG[bluez]           = "--enable-bluez,--disable-bluez,virtual/bluez"
 PACKAGECONFIG[rsvg]            = "--enable-rsvg,--disable-rsvg,librsvg"
 PACKAGECONFIG[sndfile]         = "--enable-sndfile,--disable-sndfile,libsndfile1"
 PACKAGECONFIG[webp]            = "--enable-webp,--disable-webp,libwebp"
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_git.bb b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_git.bb
index e1a5904..8f37be8 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_git.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_git.bb
@@ -11,7 +11,7 @@ S = "${WORKDIR}/git"
 
 SRCREV = "6e5db57d2446a753aaa76bee268e1f95600b14ce"
 
-PACKAGECONFIG[bluez] = "--enable-bluez,--disable-bluez,bluez4"
+PACKAGECONFIG[bluez] = "--enable-bluez,--disable-bluez,virtual/bluez"
 PACKAGECONFIG[sbc] = "--enable-sbc,--disable-sbc,sbc"
 PACKAGECONFIG[hls] = "--enable-hls,--disable-hls,gnutls"
 
-- 
1.8.5.5

Re: [RFC 08/14] gstreamer1.0-plugins-bad: switch to virtual/bluez

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 3236 bytes --]

On Mon, Nov 10, 2014 at 03:13:05PM -0600, Peter A. Bigot wrote:
> Be aware that current versions of gstreamer1.0-plugins-bad (through
> 1.4.3) do not currently support bluez5, and will silently disable
> bluetooth support until that has been addressed upstream.
> 
> Signed-off-by: Peter A. Bigot <pab@pabigot.com>
> ---
>  meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc    | 4 ++--
>  meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_git.bb | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
> index dab0bf5..913a338 100644
> --- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
> +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
> @@ -18,7 +18,7 @@ PACKAGECONFIG_GL ?= "${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'gles2',
>  PACKAGECONFIG ??= " \
>      ${PACKAGECONFIG_GL} \
>      ${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 'wayland', '', d)} \
> -    ${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 'bluez', '', d)} \
> +    ${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 'virtual/bluez', '', d)} \

There isn't any virtual/bluez PACKAGECONFIG

>      ${@bb.utils.contains('DISTRO_FEATURES', 'directfb', 'directfb', '', d)} \
>      orc curl uvch264 neon sndfile \
>      hls sbc dash bz2 smoothstreaming \
> @@ -49,7 +49,7 @@ PACKAGECONFIG[bz2]             = "--enable-bz2,--disable-bz2,bzip2"
>  PACKAGECONFIG[fluidsynth]      = "--enable-fluidsynth,--disable-fluidsynth,fluidsynth"
>  PACKAGECONFIG[schroedinger]    = "--enable-schro,--disable-schro,schroedinger"
>  PACKAGECONFIG[smoothstreaming] = "--enable-smoothstreaming,--disable-smoothstreaming,libxml2"
> -PACKAGECONFIG[bluez]           = "--enable-bluez,--disable-bluez,bluez4"
> +PACKAGECONFIG[bluez]           = "--enable-bluez,--disable-bluez,virtual/bluez"
>  PACKAGECONFIG[rsvg]            = "--enable-rsvg,--disable-rsvg,librsvg"
>  PACKAGECONFIG[sndfile]         = "--enable-sndfile,--disable-sndfile,libsndfile1"
>  PACKAGECONFIG[webp]            = "--enable-webp,--disable-webp,libwebp"
> diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_git.bb b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_git.bb
> index e1a5904..8f37be8 100644
> --- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_git.bb
> +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_git.bb
> @@ -11,7 +11,7 @@ S = "${WORKDIR}/git"
>  
>  SRCREV = "6e5db57d2446a753aaa76bee268e1f95600b14ce"
>  
> -PACKAGECONFIG[bluez] = "--enable-bluez,--disable-bluez,bluez4"
> +PACKAGECONFIG[bluez] = "--enable-bluez,--disable-bluez,virtual/bluez"
>  PACKAGECONFIG[sbc] = "--enable-sbc,--disable-sbc,sbc"
>  PACKAGECONFIG[hls] = "--enable-hls,--disable-hls,gnutls"
>  
> -- 
> 1.8.5.5
> 
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

Re: [RFC 08/14] gstreamer1.0-plugins-bad: switch to virtual/bluez

[Peter A. Bigot]

On 11/10/2014 05:20 PM, Martin Jansa wrote:
> On Mon, Nov 10, 2014 at 03:13:05PM -0600, Peter A. Bigot wrote:
>> Be aware that current versions of gstreamer1.0-plugins-bad (through
>> 1.4.3) do not currently support bluez5, and will silently disable
>> bluetooth support until that has been addressed upstream.
>>
>> Signed-off-by: Peter A. Bigot <pab@pabigot.com>
>> ---
>>   meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc    | 4 ++--
>>   meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_git.bb | 2 +-
>>   2 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
>> index dab0bf5..913a338 100644
>> --- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
>> +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
>> @@ -18,7 +18,7 @@ PACKAGECONFIG_GL ?= "${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'gles2',
>>   PACKAGECONFIG ??= " \
>>       ${PACKAGECONFIG_GL} \
>>       ${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 'wayland', '', d)} \
>> -    ${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 'bluez', '', d)} \
>> +    ${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 'virtual/bluez', '', d)} \
> There isn't any virtual/bluez PACKAGECONFIG

True; reverted this piece in the branch.  Thanks.

Peter

>
>>       ${@bb.utils.contains('DISTRO_FEATURES', 'directfb', 'directfb', '', d)} \
>>       orc curl uvch264 neon sndfile \
>>       hls sbc dash bz2 smoothstreaming \
>> @@ -49,7 +49,7 @@ PACKAGECONFIG[bz2]             = "--enable-bz2,--disable-bz2,bzip2"
>>   PACKAGECONFIG[fluidsynth]      = "--enable-fluidsynth,--disable-fluidsynth,fluidsynth"
>>   PACKAGECONFIG[schroedinger]    = "--enable-schro,--disable-schro,schroedinger"
>>   PACKAGECONFIG[smoothstreaming] = "--enable-smoothstreaming,--disable-smoothstreaming,libxml2"
>> -PACKAGECONFIG[bluez]           = "--enable-bluez,--disable-bluez,bluez4"
>> +PACKAGECONFIG[bluez]           = "--enable-bluez,--disable-bluez,virtual/bluez"
>>   PACKAGECONFIG[rsvg]            = "--enable-rsvg,--disable-rsvg,librsvg"
>>   PACKAGECONFIG[sndfile]         = "--enable-sndfile,--disable-sndfile,libsndfile1"
>>   PACKAGECONFIG[webp]            = "--enable-webp,--disable-webp,libwebp"
>> diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_git.bb b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_git.bb
>> index e1a5904..8f37be8 100644
>> --- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_git.bb
>> +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_git.bb
>> @@ -11,7 +11,7 @@ S = "${WORKDIR}/git"
>>   
>>   SRCREV = "6e5db57d2446a753aaa76bee268e1f95600b14ce"
>>   
>> -PACKAGECONFIG[bluez] = "--enable-bluez,--disable-bluez,bluez4"
>> +PACKAGECONFIG[bluez] = "--enable-bluez,--disable-bluez,virtual/bluez"
>>   PACKAGECONFIG[sbc] = "--enable-sbc,--disable-sbc,sbc"
>>   PACKAGECONFIG[hls] = "--enable-hls,--disable-hls,gnutls"
>>   
>> -- 
>> 1.8.5.5
>>
>> -- 
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core

[RFC 09/14] ofono: switch to virtual/bluez

[Peter A. Bigot]

Signed-off-by: Peter A. Bigot <pab@pabigot.com>
---
 meta/recipes-connectivity/ofono/ofono.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-connectivity/ofono/ofono.inc b/meta/recipes-connectivity/ofono/ofono.inc
index 9f65f4f..aa02ac7 100644
--- a/meta/recipes-connectivity/ofono/ofono.inc
+++ b/meta/recipes-connectivity/ofono/ofono.inc
@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=eb723b61539feef013de476e68b5c50a \
 
 inherit autotools pkgconfig update-rc.d systemd
 
-DEPENDS  = "dbus glib-2.0 udev mobile-broadband-provider-info ${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth','bluez4', '', d)}"
+DEPENDS  = "dbus glib-2.0 udev mobile-broadband-provider-info ${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth','virtual/bluez', '', d)}"
 
 INITSCRIPT_NAME = "ofono"
 INITSCRIPT_PARAMS = "defaults 22"
-- 
1.8.5.5

[RFC 10/14] neard: switch to VIRTUAL-RUNTIME_bluez

[Peter A. Bigot]

Signed-off-by: Peter A. Bigot <pab@pabigot.com>
---
 meta/recipes-connectivity/neard/neard.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-connectivity/neard/neard.inc b/meta/recipes-connectivity/neard/neard.inc
index e714cad..f3e684c3 100644
--- a/meta/recipes-connectivity/neard/neard.inc
+++ b/meta/recipes-connectivity/neard/neard.inc
@@ -47,7 +47,7 @@ RDEPENDS_${PN} = "dbus python python-dbus python-pygobject"
 
 # Bluez & Wifi are not mandatory except for handover
 RRECOMMENDS_${PN} = "\
-                     ${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 'bluez4', '', d)} \
+                     ${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', '${VIRTUAL-RUNTIME_bluez}', '', d)} \
                      ${@bb.utils.contains('DISTRO_FEATURES', 'wifi','wpa-supplicant', '', d)} \
                     "
 
-- 
1.8.5.5

[RFC 11/14] libpcap: switch to virtual/bluez

[Peter A. Bigot]

Signed-off-by: Peter A. Bigot <pab@pabigot.com>
---
 meta/recipes-connectivity/libpcap/libpcap.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-connectivity/libpcap/libpcap.inc b/meta/recipes-connectivity/libpcap/libpcap.inc
index a12eb16..5d34c4b 100644
--- a/meta/recipes-connectivity/libpcap/libpcap.inc
+++ b/meta/recipes-connectivity/libpcap/libpcap.inc
@@ -11,7 +11,7 @@ LIC_FILES_CHKSUM = "file://LICENSE;md5=1d4b0366557951c84a94fabe3529f867 \
 DEPENDS = "flex-native bison-native"
 
 PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 'bluetooth', '', d)}"
-PACKAGECONFIG[bluetooth] = "--enable-bluetooth,--disable-bluetooth,bluez4"
+PACKAGECONFIG[bluetooth] = "--enable-bluetooth,--disable-bluetooth,virtual/bluez"
 PACKAGECONFIG[canusb] = "--enable-canusb,--enable-canusb=no,libusb"
 PACKAGECONFIG[libnl] = "--with-libnl,--without-libnl,libnl"
 
-- 
1.8.5.5

[RFC 12/14] connman: switch to virtual/bluez

[Peter A. Bigot]

Signed-off-by: Peter A. Bigot <pab@pabigot.com>
---
 meta/recipes-connectivity/connman/connman.inc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-connectivity/connman/connman.inc b/meta/recipes-connectivity/connman/connman.inc
index f121a81..9af7d87 100644
--- a/meta/recipes-connectivity/connman/connman.inc
+++ b/meta/recipes-connectivity/connman/connman.inc
@@ -41,7 +41,7 @@ PACKAGECONFIG ??= "wispr \
 # PACKAGECONFIG_append_pn-connman = " openvpn vpnc l2tp pptp"
 
 PACKAGECONFIG[wifi] = "--enable-wifi, --disable-wifi, wpa-supplicant"
-PACKAGECONFIG[bluetooth] = "--enable-bluetooth, --disable-bluetooth, bluez4"
+PACKAGECONFIG[bluetooth] = "--enable-bluetooth, --disable-bluetooth, virtual/bluez"
 PACKAGECONFIG[3g] = "--enable-ofono, --disable-ofono, ofono"
 PACKAGECONFIG[tist] = "--enable-tist,--disable-tist,"
 PACKAGECONFIG[openvpn] = "--enable-openvpn --with-openvpn=${sbindir}/openvpn,--disable-openvpn,,openvpn"
@@ -113,7 +113,7 @@ RPROVIDES_${PN} = "\
 
 RDEPENDS_${PN} = "\
 	dbus \
-	${@bb.utils.contains('PACKAGECONFIG', 'bluetooth', 'bluez4', '', d)} \
+	${@bb.utils.contains('PACKAGECONFIG', 'bluetooth', '${VIRTUAL-RUNTIME_bluez}', '', d)} \
 	${@bb.utils.contains('PACKAGECONFIG', 'wifi','wpa-supplicant', '', d)} \
 	${@bb.utils.contains('PACKAGECONFIG', '3g','ofono', '', d)} \
 	xuser-account \
-- 
1.8.5.5

[RFC 13/14] bluez5: support experimental through PACKAGECONFIG

[Peter A. Bigot]

Make it simple to enable the experimental plugins and tools.

Signed-off-by: Peter A. Bigot <pab@pabigot.com>
---
 meta/recipes-connectivity/bluez5/bluez5.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc b/meta/recipes-connectivity/bluez5/bluez5.inc
index 241b16f..97c8cf9 100644
--- a/meta/recipes-connectivity/bluez5/bluez5.inc
+++ b/meta/recipes-connectivity/bluez5/bluez5.inc
@@ -14,6 +14,7 @@ RCONFLICTS_${PN} = "bluez4"
 
 PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'alsa', 'alsa', '', d)} obex-profiles"
 PACKAGECONFIG[obex-profiles] = "--enable-obex,--disable-obex,libical"
+PACKAGECONFIG[experimental] = "--enable-experimental,--disable-experimental,"
 
 SRC_URI = "\
     ${KERNELORG_MIRROR}/linux/bluetooth/bluez-${PV}.tar.xz \
-- 
1.8.5.5

[RFC 14/14] bluez5: add a package for tools left in the build area

[Peter A. Bigot]

In bluez4 gatttool was provided as a command-line interface to the
Generic Attribute Profile.  In bluez5 this tool is still built but is no
longer installed.  It is still necessary for those wishing to use GATT
since the programmatic API is not yet mature.  A variety of other useful
tools are treated similarly by bluez5.

Make these tools available in the bluez5-noinst-tools package, in a way
that allows control over which tools are packaged, with the default
being all that are provided in a particular release of bluez.

Signed-off-by: Peter A. Bigot <pab@pabigot.com>
---
 meta/recipes-connectivity/bluez5/bluez5.inc     | 26 +++++++++++++-
 meta/recipes-connectivity/bluez5/bluez5_5.25.bb | 47 +++++++++++++++++++++++++
 2 files changed, 72 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc b/meta/recipes-connectivity/bluez5/bluez5.inc
index 97c8cf9..7022343 100644
--- a/meta/recipes-connectivity/bluez5/bluez5.inc
+++ b/meta/recipes-connectivity/bluez5/bluez5.inc
@@ -33,6 +33,15 @@ EXTRA_OECONF = "\
   --enable-library \
 "
 
+# bluez5 builds a large number of useful utilities but does not
+# install them.  Specify which ones we want put into ${PN}-noinst-tools.
+NOINST_TOOLS_READLINE ??= ""
+NOINST_TOOLS_EXPERIMENTAL ??= ""
+NOINST_TOOLS = " \
+    ${NOINST_TOOLS_READLINE} \
+    ${@bb.utils.contains('PACKAGECONFIG', 'experimental', '${NOINST_TOOLS_EXPERIMENTAL}', '', d)} \
+"
+
 do_install_append() {
 	install -d ${D}${sysconfdir}/bluetooth/
 	if [ -f ${S}/profiles/audio/audio.conf ]; then
@@ -46,10 +55,15 @@ do_install_append() {
 	fi
 	# at_console doesn't really work with the current state of OE, so punch some more holes so people can actually use BT
 	install -m 0644 ${WORKDIR}/bluetooth.conf ${D}/${sysconfdir}/dbus-1/system.d/
+
+	# Install desired tools that upstream leaves in build area
+        for f in ${NOINST_TOOLS} ; do
+	    install -m 755 ${B}/$f ${D}/${bindir}
+	done
 }
 
 ALLOW_EMPTY_libasound-module-bluez = "1"
-PACKAGES =+ "libasound-module-bluez ${PN}-testtools ${PN}-obex"
+PACKAGES =+ "libasound-module-bluez ${PN}-testtools ${PN}-obex ${PN}-noinst-tools"
 
 FILES_libasound-module-bluez = "${libdir}/alsa-lib/lib*.so ${datadir}/alsa"
 FILES_${PN} += "${libdir}/bluetooth/plugins ${libdir}/bluetooth/plugins/*.so ${base_libdir}/udev/ ${nonarch_base_libdir}/udev/ ${systemd_unitdir}/ ${datadir}/dbus-1"
@@ -66,6 +80,16 @@ SYSTEMD_SERVICE_${PN}-obex = "obex.service"
 
 FILES_${PN}-testtools = "${libdir}/bluez/test/*"
 
+def get_noinst_tools_paths (d, bb, tools):
+    s = list()
+    bindir = d.getVar("bindir", True)
+    for bdp in tools.split():
+        f = os.path.basename(bdp)
+        s.append("%s/%s" % (bindir, f))
+    return "\n".join(s)
+
+FILES_${PN}-noinst-tools = "${@get_noinst_tools_paths(d, bb, d.getVar('NOINST_TOOLS', True))}"
+
 FILES_${PN}-dbg += "\
   ${libdir}/${BPN}/bluetooth/.debug \
   ${libdir}/bluetooth/plugins/.debug \
diff --git a/meta/recipes-connectivity/bluez5/bluez5_5.25.bb b/meta/recipes-connectivity/bluez5/bluez5_5.25.bb
index 8cb32ec..7d06b16 100644
--- a/meta/recipes-connectivity/bluez5/bluez5_5.25.bb
+++ b/meta/recipes-connectivity/bluez5/bluez5_5.25.bb
@@ -1,3 +1,50 @@
 require bluez5.inc
 SRC_URI[md5sum] = "41bd0c915abde255622150ce6dcae67b"
 SRC_URI[sha256sum] = "5ca62f3f45e2638a0f7a81658d6c8813ee01487436ae8e53e9fe395e23d1fd30"
+
+# noinst programs in Makefile.tools that are conditional on READLINE
+# support
+NOINST_TOOLS_READLINE ?= " \
+    attrib/gatttool \
+    tools/obex-client-tool \
+    tools/obex-server-tool \
+    tools/bluetooth-player \
+    tools/obexctl \
+"
+
+# noinst programs in Makefile.tools that are conditional on EXPERIMENTAL
+# support
+NOINST_TOOLS_EXPERIMENTAL ?= " \
+    emulator/btvirt \
+    emulator/b1ee \
+    emulator/hfp \
+    tools/3dsp \
+    tools/mgmt-tester \
+    tools/gap-tester \
+    tools/l2cap-tester \
+    tools/sco-tester \
+    tools/smp-tester \
+    tools/hci-tester \
+    tools/rfcomm-tester \
+    tools/bdaddr \
+    tools/avinfo \
+    tools/avtest \
+    tools/scotest \
+    tools/amptest \
+    tools/hwdb \
+    tools/hcieventmask \
+    tools/hcisecfilter \
+    tools/btmgmt \
+    tools/btinfo \
+    tools/btattach \
+    tools/btsnoop \
+    tools/btproxy \
+    tools/btiotest \
+    tools/cltest \
+    tools/seq2bseq \
+    tools/hex2hcd \
+    tools/ibeacon \
+    tools/btgatt-client \
+    tools/gatt-service \
+    profiles/iap/iapd \
+"
-- 
1.8.5.5