[PATCH 0/5] Switch to BlueZ 5.x as default Bluetooth stack

[PATCH 0/5] Switch to BlueZ 5.x as default Bluetooth stack

[Cristian Iorga]

BlueZ 5.x is now the default Bluetooth stack.
BlueZ 4.x is moved to meta-oe networking collection
and still supported in oe-core.

The following changes since commit d6d2dd5c9e06c54ff336b44d54f01b4fe24903ed:

  tools: A real fix for thos mega-manual.sed file for Toaster. (2015-04-02 20:30:46 +0100)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib ciorga/YB7479_refinement
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=ciorga/YB7479_refinement

Cristian Iorga (5):
  bluez5: upgrade to 5.29
  bluez: remove recipes collection
  maintainers.inc: remove info related to bluez4
  upstream_tracking.inc: bluez4 removed from oe-core
  bluetooth.bbclass: set bluez5 as the default BT stack

 meta-yocto/conf/distro/include/maintainers.inc     |  3 --
 .../conf/distro/include/upstream_tracking.inc      |  1 -
 meta/classes/bluetooth.bbclass                     | 16 +++++---
 .../obsolete_automake_macros.patch                 | 14 -------
 .../bluez/bluez-hcidump_2.5.bb                     | 22 -----------
 .../bluez/bluez4-4.101/bluetooth.conf              | 16 --------
 .../bluez/bluez4-4.101/fix-udev-paths.patch        | 37 -----------------
 .../bluez/bluez4-4.101/install-test-script.patch   | 26 ------------
 ...ork-fix-network-Connect-method-parameters.patch | 30 --------------
 .../bluez4-4.101/obsolete_automake_macros.patch    | 14 -------
 .../bluez/bluez4-4.101/sbc_mmx.patch               | 24 -----------
 ...pygobject-instead-ofgobject-introspection.patch | 27 -------------
 meta/recipes-connectivity/bluez/bluez4.inc         | 46 ----------------------
 meta/recipes-connectivity/bluez/bluez4_4.101.bb    | 46 ----------------------
 .../bluez/gst-plugin-bluetooth_4.101.bb            | 39 ------------------
 .../bluez5/{bluez5_5.28.bb => bluez5_5.29.bb}      |  4 +-
 16 files changed, 13 insertions(+), 352 deletions(-)
 delete mode 100644 meta/recipes-connectivity/bluez/bluez-hcidump-2.5/obsolete_automake_macros.patch
 delete mode 100644 meta/recipes-connectivity/bluez/bluez-hcidump_2.5.bb
 delete mode 100644 meta/recipes-connectivity/bluez/bluez4-4.101/bluetooth.conf
 delete mode 100644 meta/recipes-connectivity/bluez/bluez4-4.101/fix-udev-paths.patch
 delete mode 100644 meta/recipes-connectivity/bluez/bluez4-4.101/install-test-script.patch
 delete mode 100644 meta/recipes-connectivity/bluez/bluez4-4.101/network-fix-network-Connect-method-parameters.patch
 delete mode 100644 meta/recipes-connectivity/bluez/bluez4-4.101/obsolete_automake_macros.patch
 delete mode 100644 meta/recipes-connectivity/bluez/bluez4-4.101/sbc_mmx.patch
 delete mode 100644 meta/recipes-connectivity/bluez/bluez4-4.101/use-legacy-pygobject-instead-ofgobject-introspection.patch
 delete mode 100644 meta/recipes-connectivity/bluez/bluez4.inc
 delete mode 100644 meta/recipes-connectivity/bluez/bluez4_4.101.bb
 delete mode 100644 meta/recipes-connectivity/bluez/gst-plugin-bluetooth_4.101.bb
 rename meta/recipes-connectivity/bluez5/{bluez5_5.28.bb => bluez5_5.29.bb} (88%)

-- 
2.1.0

[PATCH 1/5] bluez5: upgrade to 5.29

[Cristian Iorga]

- Large release with over a month and 475 commits since 5.28;
- Internal GATT library received lots of updates;
- Fix for AVCTP key repeat timeout;
- Added support for the Multi Profile Specification (MPS).

Signed-off-by: Cristian Iorga <cristian.iorga@intel.com>
---
 meta/recipes-connectivity/bluez5/{bluez5_5.28.bb => bluez5_5.29.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-connectivity/bluez5/{bluez5_5.28.bb => bluez5_5.29.bb} (88%)

diff --git a/meta/recipes-connectivity/bluez5/bluez5_5.28.bb b/meta/recipes-connectivity/bluez5/bluez5_5.29.bb
similarity index 88%
rename from meta/recipes-connectivity/bluez5/bluez5_5.28.bb
rename to meta/recipes-connectivity/bluez5/bluez5_5.29.bb
index e816998..0fe8e7f 100644
--- a/meta/recipes-connectivity/bluez5/bluez5_5.28.bb
+++ b/meta/recipes-connectivity/bluez5/bluez5_5.29.bb
@@ -1,6 +1,6 @@
 require bluez5.inc
-SRC_URI[md5sum] = "bc20a8285530758c68f6a60e4ca62a15"
-SRC_URI[sha256sum] = "85bab48f4b47a158739028682c1e09cf30099c8ea9dfe63360055f8e06fc18a9"
+SRC_URI[md5sum] = "aa9dc91689695a486c78c131cd68673e"
+SRC_URI[sha256sum] = "df216a6d5ec6133355e5d4ed6b5e7a188a940940d337374e166758513246f0e4"
 
 # noinst programs in Makefile.tools that are conditional on READLINE
 # support
-- 
2.1.0

[PATCH 2/5] bluez: remove recipes collection

[Cristian Iorga]

BlueZ 4.x and associated recipes are now obsolete
(bluez4, bluez-hcidump, gst-plugin-bluetooth).
Will be moved into networking collection of meta-oe.
BlueZ 4.x is still usable in oe-core as alternative Bluetooth stack.

Signed-off-by: Cristian Iorga <cristian.iorga@intel.com>
---
 .../obsolete_automake_macros.patch                 | 14 -------
 .../bluez/bluez-hcidump_2.5.bb                     | 22 -----------
 .../bluez/bluez4-4.101/bluetooth.conf              | 16 --------
 .../bluez/bluez4-4.101/fix-udev-paths.patch        | 37 -----------------
 .../bluez/bluez4-4.101/install-test-script.patch   | 26 ------------
 ...ork-fix-network-Connect-method-parameters.patch | 30 --------------
 .../bluez4-4.101/obsolete_automake_macros.patch    | 14 -------
 .../bluez/bluez4-4.101/sbc_mmx.patch               | 24 -----------
 ...pygobject-instead-ofgobject-introspection.patch | 27 -------------
 meta/recipes-connectivity/bluez/bluez4.inc         | 46 ----------------------
 meta/recipes-connectivity/bluez/bluez4_4.101.bb    | 46 ----------------------
 .../bluez/gst-plugin-bluetooth_4.101.bb            | 39 ------------------
 12 files changed, 341 deletions(-)
 delete mode 100644 meta/recipes-connectivity/bluez/bluez-hcidump-2.5/obsolete_automake_macros.patch
 delete mode 100644 meta/recipes-connectivity/bluez/bluez-hcidump_2.5.bb
 delete mode 100644 meta/recipes-connectivity/bluez/bluez4-4.101/bluetooth.conf
 delete mode 100644 meta/recipes-connectivity/bluez/bluez4-4.101/fix-udev-paths.patch
 delete mode 100644 meta/recipes-connectivity/bluez/bluez4-4.101/install-test-script.patch
 delete mode 100644 meta/recipes-connectivity/bluez/bluez4-4.101/network-fix-network-Connect-method-parameters.patch
 delete mode 100644 meta/recipes-connectivity/bluez/bluez4-4.101/obsolete_automake_macros.patch
 delete mode 100644 meta/recipes-connectivity/bluez/bluez4-4.101/sbc_mmx.patch
 delete mode 100644 meta/recipes-connectivity/bluez/bluez4-4.101/use-legacy-pygobject-instead-ofgobject-introspection.patch
 delete mode 100644 meta/recipes-connectivity/bluez/bluez4.inc
 delete mode 100644 meta/recipes-connectivity/bluez/bluez4_4.101.bb
 delete mode 100644 meta/recipes-connectivity/bluez/gst-plugin-bluetooth_4.101.bb

diff --git a/meta/recipes-connectivity/bluez/bluez-hcidump-2.5/obsolete_automake_macros.patch b/meta/recipes-connectivity/bluez/bluez-hcidump-2.5/obsolete_automake_macros.patch
deleted file mode 100644
index 0c77f1a..0000000
--- a/meta/recipes-connectivity/bluez/bluez-hcidump-2.5/obsolete_automake_macros.patch
+++ /dev/null
@@ -1,14 +0,0 @@
-Upstream-Status: Pending [package obsolete/not maintained by upstream]
-
-Signed-off-by: Marko Lindqvist <cazfi74@gmail.com>
-diff -Nurd bluez-hcidump-2.5/configure.ac bluez-hcidump-2.5/configure.ac
---- bluez-hcidump-2.5/configure.ac	2012-11-30 10:29:41.000000000 +0200
-+++ bluez-hcidump-2.5/configure.ac	2013-01-12 10:02:10.609511463 +0200
-@@ -2,7 +2,7 @@
- AC_INIT(bluez-hcidump, 2.5)
-
- AM_INIT_AUTOMAKE([foreign subdir-objects])
--AM_CONFIG_HEADER(config.h)
-+AC_CONFIG_HEADERS(config.h)
-
- m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])])
diff --git a/meta/recipes-connectivity/bluez/bluez-hcidump_2.5.bb b/meta/recipes-connectivity/bluez/bluez-hcidump_2.5.bb
deleted file mode 100644
index 3950630..0000000
--- a/meta/recipes-connectivity/bluez/bluez-hcidump_2.5.bb
+++ /dev/null
@@ -1,22 +0,0 @@
-SUMMARY = "Linux Bluetooth Stack HCI Debugger Tool"
-DESCRIPTION = "The hcidump tool reads raw HCI data coming from and going to a Bluetooth device \
-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"
-PR = "r1"
-
-SRC_URI = "http://www.kernel.org/pub/linux/bluetooth/bluez-hcidump-${PV}.tar.gz \
-           file://obsolete_automake_macros.patch \
-"
-
-SRC_URI[md5sum] = "2eab54bbd2b59a2ed4274ebb9390cf18"
-SRC_URI[sha256sum] = "9b7c52b375081883738cf049ecabc103b97d094b19c6544fb241267905d88881"
-S = "${WORKDIR}/bluez-hcidump-${PV}"
-
-inherit autotools
diff --git a/meta/recipes-connectivity/bluez/bluez4-4.101/bluetooth.conf b/meta/recipes-connectivity/bluez/bluez4-4.101/bluetooth.conf
deleted file mode 100644
index ca5e9e4..0000000
--- a/meta/recipes-connectivity/bluez/bluez4-4.101/bluetooth.conf
+++ /dev/null
@@ -1,16 +0,0 @@
-<!-- This configuration file specifies the required security policies
-     for Bluetooth core daemon to work. -->
-
-<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
- "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
-<busconfig>
-
-  <!-- ../system.conf have denied everything, so we just punch some holes -->
-
-  <policy context="default">
-    <allow own="org.bluez"/>
-    <allow send_destination="org.bluez"/>
-    <allow send_interface="org.bluez.Agent"/>
-  </policy>
-
-</busconfig>
diff --git a/meta/recipes-connectivity/bluez/bluez4-4.101/fix-udev-paths.patch b/meta/recipes-connectivity/bluez/bluez4-4.101/fix-udev-paths.patch
deleted file mode 100644
index 8089914..0000000
--- a/meta/recipes-connectivity/bluez/bluez4-4.101/fix-udev-paths.patch
+++ /dev/null
@@ -1,37 +0,0 @@
-Add udevdir/udevrulesdir options
-
-Upstream-Status: Inappropriate [configuration]
-Signed-off-by: Constantin Musca <constantinx.musca@intel.com>
-
-Index: bluez-4.101/Makefile.am
-===================================================================
---- bluez-4.101.orig/Makefile.am
-+++ bluez-4.101/Makefile.am
-@@ -395,7 +395,7 @@ EXTRA_DIST += audio/bluetooth.conf
- include Makefile.tools
- 
- if DATAFILES
--rulesdir = @UDEV_DIR@/rules.d
-+rulesdir = @UDEV_RULES_DIR@
- 
- udev_files =
- 
-Index: bluez-4.101/configure.ac
-===================================================================
---- bluez-4.101.orig/configure.ac
-+++ bluez-4.101/configure.ac
-@@ -61,4 +61,14 @@ if (test -n "${path_systemdunit}"); then
- fi
- AM_CONDITIONAL(SYSTEMD, test -n "${path_systemdunit}")
- 
-+AC_ARG_WITH([udevdir],
-+    AS_HELP_STRING([--with-udevdir=DIR], [udev directory]),
-+    [], [with_udevdir=/lib/udev/])
-+AC_SUBST([UDEV_DIR], [$with_udevdir])
-+
-+AC_ARG_WITH([udevrulesdir],
-+    AS_HELP_STRING([--with-udevrulesdir=DIR], [udev rules directory]),
-+    [], [with_udevrulesdir=/lib/udev/rules.d])
-+AC_SUBST([UDEV_RULES_DIR], [$with_udevrulesdir])
-+
- AC_OUTPUT(Makefile doc/version.xml src/bluetoothd.8 src/bluetooth.service bluez.pc)
diff --git a/meta/recipes-connectivity/bluez/bluez4-4.101/install-test-script.patch b/meta/recipes-connectivity/bluez/bluez4-4.101/install-test-script.patch
deleted file mode 100644
index 23f7d99..0000000
--- a/meta/recipes-connectivity/bluez/bluez4-4.101/install-test-script.patch
+++ /dev/null
@@ -1,26 +0,0 @@
-Upstream-Status: Inappropriate
-
-Install the bluez's test scripts
-
-Signed-off-by: Zhong Hongbo <hongbo.zhong@windriver.com>
-diff -Nurd bluez-4.101.orig/Makefile.tools bluez-4.101/Makefile.tools
---- bluez-4.101.orig/Makefile.tools	2013-11-19 15:49:07.688838000 +0800
-+++ bluez-4.101/Makefile.tools	2013-11-19 15:50:09.256837848 +0800
-@@ -227,6 +227,17 @@
- 		test/service-spp.xml test/service-opp.xml test/service-ftp.xml \
- 		test/simple-player test/test-nap
- 
-+bluez4_testdir = $(libdir)/bluez4/test/
-+dist_bluez4_test_SCRIPTS = test/sap-client test/hsplay test/hsmicro \
-+		test/monitor-bluetooth test/list-devices \
-+		test/test-discovery test/test-manager test/test-adapter \
-+		test/test-device test/test-service test/test-serial \
-+		test/test-telephony test/test-network test/simple-agent \
-+		test/simple-service test/simple-endpoint test/test-audio \
-+		test/test-input test/test-sap-server test/test-oob \
-+		test/test-attrib test/test-proximity test/test-thermometer \
-+		test/test-serial-proxy test/test-health test/test-health-sink \
-+		test/simple-player test/test-nap
- if HIDD
- bin_PROGRAMS += compat/hidd
- 
diff --git a/meta/recipes-connectivity/bluez/bluez4-4.101/network-fix-network-Connect-method-parameters.patch b/meta/recipes-connectivity/bluez/bluez4-4.101/network-fix-network-Connect-method-parameters.patch
deleted file mode 100644
index 37f9199..0000000
--- a/meta/recipes-connectivity/bluez/bluez4-4.101/network-fix-network-Connect-method-parameters.patch
+++ /dev/null
@@ -1,30 +0,0 @@
-Upstream-Status: Backport
-Signed-off-by: Peter A. Bigot <pab@pabigot.com>
-
-From 57170b311f1468330f4a9961dc0b3ac45f97bc13 Mon Sep 17 00:00:00 2001
-From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
-Date: Sat, 30 Jun 2012 00:39:05 -0300
-Subject: [PATCH] network: fix network Connect() method parameters
-
----
- network/connection.c |    4 +++-
- 1 file changed, 3 insertions(+), 1 deletion(-)
-
-diff --git a/network/connection.c b/network/connection.c
-index 544ec3a..59423a9 100644
---- a/network/connection.c
-+++ b/network/connection.c
-@@ -554,7 +554,9 @@ static void path_unregister(void *data)
- 
- static const GDBusMethodTable connection_methods[] = {
- 	{ GDBUS_ASYNC_METHOD("Connect",
--			NULL, NULL, connection_connect) },
-+				GDBUS_ARGS({"uuid", "s"}),
-+				GDBUS_ARGS({"interface", "s"}),
-+				connection_connect) },
- 	{ GDBUS_METHOD("Disconnect",
- 			NULL, NULL, connection_disconnect) },
- 	{ GDBUS_METHOD("GetProperties",
--- 
-1.7.9.5
-
diff --git a/meta/recipes-connectivity/bluez/bluez4-4.101/obsolete_automake_macros.patch b/meta/recipes-connectivity/bluez/bluez4-4.101/obsolete_automake_macros.patch
deleted file mode 100644
index 1068f24..0000000
--- a/meta/recipes-connectivity/bluez/bluez4-4.101/obsolete_automake_macros.patch
+++ /dev/null
@@ -1,14 +0,0 @@
-Upstream-Status: Backport
-
-Signed-off-by: Marko Lindqvist <cazfi74@gmail.com>
-diff -Nurd bluez-4.101/configure.ac bluez-4.101/configure.ac
---- bluez-4.101/configure.ac	2012-06-22 19:36:49.000000000 +0300
-+++ bluez-4.101/configure.ac	2013-01-07 06:13:18.385888966 +0200
-@@ -2,7 +2,7 @@
- AC_INIT(bluez, 4.101)
-
- AM_INIT_AUTOMAKE([foreign subdir-objects color-tests])
--AM_CONFIG_HEADER(config.h)
-+AC_CONFIG_HEADERS(config.h)
-
- m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])])
diff --git a/meta/recipes-connectivity/bluez/bluez4-4.101/sbc_mmx.patch b/meta/recipes-connectivity/bluez/bluez4-4.101/sbc_mmx.patch
deleted file mode 100644
index 98fab45..0000000
--- a/meta/recipes-connectivity/bluez/bluez4-4.101/sbc_mmx.patch
+++ /dev/null
@@ -1,24 +0,0 @@
-on x86 and x86_64 gcc 4.7 complains
-
-sbc/sbc_primitives_mmx.c: In function 'sbc_calc_scalefactors_mmx':
-sbc/sbc_primitives_mmx.c:294:4: warning: asm operand 2 probably doesn't match constraints [enabled by default]
-sbc/sbc_primitives_mmx.c:294:4: error: impossible constraint in 'asm'
-
-This patch is taken from https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/911871
-
-Signed-off-by: Khem Raj <raj.khem@gmail.com>
-
-Upstream-Status: Pending
-Index: bluez-4.98/sbc/sbc_primitives_mmx.c
-===================================================================
---- bluez-4.98.orig/sbc/sbc_primitives_mmx.c	2011-12-21 14:53:54.000000000 -0800
-+++ bluez-4.98/sbc/sbc_primitives_mmx.c	2012-02-24 10:07:03.422073800 -0800
-@@ -318,7 +318,7 @@
- 				"movl          %k0, 4(%3)\n"
- 			: "+r" (blk)
- 			: "r" (&sb_sample_f[0][ch][sb]),
--				"i" ((char *) &sb_sample_f[1][0][0] -
-+				"r" ((char *) &sb_sample_f[1][0][0] -
- 					(char *) &sb_sample_f[0][0][0]),
- 				"r" (&scale_factor[ch][sb]),
- 				"r" (&consts),
diff --git a/meta/recipes-connectivity/bluez/bluez4-4.101/use-legacy-pygobject-instead-ofgobject-introspection.patch b/meta/recipes-connectivity/bluez/bluez4-4.101/use-legacy-pygobject-instead-ofgobject-introspection.patch
deleted file mode 100644
index 37037f5..0000000
--- a/meta/recipes-connectivity/bluez/bluez4-4.101/use-legacy-pygobject-instead-ofgobject-introspection.patch
+++ /dev/null
@@ -1,27 +0,0 @@
-Upstream-Status: Inappropriate
-
-use legacy pygobject instead of gobject-introspection
-
-Signed-off-by: Zhong Hongbo <hongbo.zhong@windriver.com>
----
-diff -Nurd bluez-4.101.orig/test/simple-agent bluez-4.101/test/simple-agent
---- bluez-4.101.orig/test/simple-agent	2013-11-13 17:14:08.138118159 +0800
-+++ bluez-4.101/test/simple-agent	2013-11-13 17:14:29.034118107 +0800
-@@ -2,7 +2,7 @@
- 
- from __future__ import absolute_import, print_function, unicode_literals
- 
--from gi.repository import GObject
-+import gobject
- 
- import sys
- import dbus
-@@ -122,7 +122,7 @@
- 	path = "/test/agent"
- 	agent = Agent(bus, path)
- 
--	mainloop = GObject.MainLoop()
-+	mainloop = gobject.MainLoop()
- 
- 	if len(args) > 1:
- 		if len(args) > 2:
diff --git a/meta/recipes-connectivity/bluez/bluez4.inc b/meta/recipes-connectivity/bluez/bluez4.inc
deleted file mode 100644
index 11c9616..0000000
--- a/meta/recipes-connectivity/bluez/bluez4.inc
+++ /dev/null
@@ -1,46 +0,0 @@
-SUMMARY = "Linux Bluetooth Stack Userland V4"
-DESCRIPTION = "Linux Bluetooth stack V4 userland components.  These include a system configurations, daemons, tools and system libraries."
-HOMEPAGE = "http://www.bluez.org"
-SECTION = "libs"
-LICENSE = "GPLv2+ & LGPLv2.1+"
-LIC_FILES_CHKSUM = "file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e \
-                    file://COPYING.LIB;md5=fb504b67c50331fc78734fed90fb0e09 \
-                    file://src/main.c;beginline=1;endline=24;md5=9bc54b93cd7e17bf03f52513f39f926e \
-                    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"
-
-PACKAGECONFIG ??= "\
-    ${@bb.utils.contains('DISTRO_FEATURES', 'alsa', 'alsa', '', d)}\
-    ${@bb.utils.contains('DISTRO_FEATURES', 'pie', 'pie', '', d)}\
-"
-PACKAGECONFIG[alsa] = "--enable-alsa,--disable-alsa,alsa-lib"
-PACKAGECONFIG[pie] = "--enable-pie,--disable-pie,"
-
-ASNEEDED = ""
-
-SRC_URI = "\
-  ${KERNELORG_MIRROR}/linux/bluetooth/bluez-${PV}.tar.gz \
-"
-S = "${WORKDIR}/bluez-${PV}"
-
-inherit autotools-brokensep pkgconfig
-
-EXTRA_OECONF = "\
-  --disable-gstreamer \
-  --enable-usb \
-  --enable-tools \
-  --enable-bccmd \
-  --enable-hid2hci \
-  --enable-dfutool \
-  --disable-hidd \
-  --disable-pand \
-  --disable-dund \
-  --disable-cups \
-  --enable-test \
-  --enable-datafiles \
-  --with-udevdir=`pkg-config --variable=udevdir udev` \
-  --with-udevrulesdir=`pkg-config --variable=udevdir udev`/rules.d \
-"
-
-EXCLUDE_FROM_WORLD = "1"
diff --git a/meta/recipes-connectivity/bluez/bluez4_4.101.bb b/meta/recipes-connectivity/bluez/bluez4_4.101.bb
deleted file mode 100644
index 28a94ed..0000000
--- a/meta/recipes-connectivity/bluez/bluez4_4.101.bb
+++ /dev/null
@@ -1,46 +0,0 @@
-require bluez4.inc
-
-PR = "r11"
-
-SRC_URI += "file://bluetooth.conf \
-            file://sbc_mmx.patch \
-            file://fix-udev-paths.patch \
-            file://obsolete_automake_macros.patch \
-            file://network-fix-network-Connect-method-parameters.patch \
-            file://install-test-script.patch \
-            file://use-legacy-pygobject-instead-ofgobject-introspection.patch \
-"
-
-SRC_URI[md5sum] = "fb42cb7038c380eb0e2fa208987c96ad"
-SRC_URI[sha256sum] = "59738410ade9f0e61a13c0f77d9aaffaafe49ba9418107e4ad75fe52846f7487"
-
-RCONFLICTS_${PN} = "bluez5"
-
-do_install_append() {
-	install -m 0644 ${S}/audio/audio.conf ${D}/${sysconfdir}/bluetooth/
-	install -m 0644 ${S}/network/network.conf ${D}/${sysconfdir}/bluetooth/
-	install -m 0644 ${S}/input/input.conf ${D}/${sysconfdir}/bluetooth/
-	# 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/
-}
-
-RDEPENDS_${PN}-dev = "bluez-hcidump"
-RDEPENDS_${PN}-testtools += "python python-dbus python-pygobject"
-
-ALLOW_EMPTY_libasound-module-bluez = "1"
-PACKAGES =+ "libasound-module-bluez ${PN}-testtools"
-
-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"
-FILES_${PN}-dev += "\
-  ${libdir}/bluetooth/plugins/*.la \
-  ${libdir}/alsa-lib/*.la \
-"
-
-FILES_${PN}-testtools = "${libdir}/bluez4/test/*"
-
-FILES_${PN}-dbg += "\
-  ${libdir}/bluetooth/plugins/.debug \
-  ${libdir}/*/.debug \
-  */udev/.debug \
-  "
diff --git a/meta/recipes-connectivity/bluez/gst-plugin-bluetooth_4.101.bb b/meta/recipes-connectivity/bluez/gst-plugin-bluetooth_4.101.bb
deleted file mode 100644
index c71d612..0000000
--- a/meta/recipes-connectivity/bluez/gst-plugin-bluetooth_4.101.bb
+++ /dev/null
@@ -1,39 +0,0 @@
-require bluez4.inc
-require recipes-multimedia/gstreamer/gst-plugins-package.inc
-
-PR = "r1"
-
-SRC_URI[md5sum] = "fb42cb7038c380eb0e2fa208987c96ad"
-SRC_URI[sha256sum] = "59738410ade9f0e61a13c0f77d9aaffaafe49ba9418107e4ad75fe52846f7487"
-
-DEPENDS = "bluez4 gst-plugins-base"
-
-EXTRA_OECONF = "\
-  --enable-gstreamer \
-"
-
-# clean unwanted files
-do_install_append() {
-	rm -rf ${D}${bindir}
-	rm -rf ${D}${sbindir}
-	rm -f  ${D}${libdir}/lib*
-	rm -rf ${D}${libdir}/pkgconfig
-	rm -rf ${D}${sysconfdir}
-	rm -rf ${D}${base_libdir}
-	rm -rf ${D}${libdir}/bluetooth
-	rm -rf ${D}${localstatedir}
-  	rm -rf ${D}${libdir}/alsa-lib
-  	rm -rf ${D}${datadir}
-	rm -rf ${D}${includedir}
-	rm -rf ${D}${nonarch_base_libdir}
-}
-
-FILES_${PN} = "${libdir}/gstreamer-0.10/lib*.so"
-FILES_${PN}-dev += "\
-  ${libdir}/gstreamer-0.10/*.la \
-"
-
-FILES_${PN}-dbg += "\
-  ${libdir}/*/.debug \
-"
-
-- 
2.1.0

[PATCH 3/5] maintainers.inc: remove info related to bluez4

[Cristian Iorga]

bluez4, bluez-hcidump, gst-plugin-bluetooth recipes
will be removed from oe-core, maintainers removed.

Signed-off-by: Cristian Iorga <cristian.iorga@intel.com>
---
 meta-yocto/conf/distro/include/maintainers.inc | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/meta-yocto/conf/distro/include/maintainers.inc b/meta-yocto/conf/distro/include/maintainers.inc
index c4e281e..e1b2f0d 100644
--- a/meta-yocto/conf/distro/include/maintainers.inc
+++ b/meta-yocto/conf/distro/include/maintainers.inc
@@ -64,9 +64,7 @@ RECIPE_MAINTAINER_pn-binutils = "Robert Yang <liezhi.yang@windriver.com>"
 RECIPE_MAINTAINER_pn-bison = "Chong Lu <Chong.Lu@windriver.com>"
 RECIPE_MAINTAINER_pn-blktool = "Paul Eggleton <paul.eggleton@linux.intel.com>"
 RECIPE_MAINTAINER_pn-blktrace = "Tom Zanussi <tom.zanussi@intel.com>"
-RECIPE_MAINTAINER_pn-bluez4 = "Cristian Iorga <cristian.iorga@intel.com>"
 RECIPE_MAINTAINER_pn-bluez5 = "Cristian Iorga <cristian.iorga@intel.com>"
-RECIPE_MAINTAINER_pn-bluez-hcidump = "Cristian Iorga <cristian.iorga@intel.com>"
 RECIPE_MAINTAINER_pn-boost = "Saul Wold <sgw@linux.intel.com>"
 RECIPE_MAINTAINER_pn-btrfs-tools = "Richard Purdie <richard.purdie@linuxfoundation.org>"
 RECIPE_MAINTAINER_pn-build-appliance-image = "Saul Wold <sgw@linux.intel.com>"
@@ -216,7 +214,6 @@ RECIPE_MAINTAINER_pn-gst-fluendo-mp3 = "Cristian Iorga <cristian.iorga@intel.com
 RECIPE_MAINTAINER_pn-gst-fluendo-mpegdemux = "Cristian Iorga <cristian.iorga@intel.com>"
 RECIPE_MAINTAINER_pn-gst-meta-base = "Cristian Iorga <cristian.iorga@intel.com>"
 RECIPE_MAINTAINER_pn-gst-openmax = "Cristian Iorga <cristian.iorga@intel.com>"
-RECIPE_MAINTAINER_pn-gst-plugin-bluetooth = "Cristian Iorga <cristian.iorga@intel.com>"
 RECIPE_MAINTAINER_pn-gst-plugins-bad = "Cristian Iorga <cristian.iorga@intel.com>"
 RECIPE_MAINTAINER_pn-gst-plugins-base = "Cristian Iorga <cristian.iorga@intel.com>"
 RECIPE_MAINTAINER_pn-gst-plugins-good = "Cristian Iorga <cristian.iorga@intel.com>"
-- 
2.1.0

[PATCH 4/5] upstream_tracking.inc: bluez4 removed from oe-core

[Cristian Iorga]

info updated accordingly.

Signed-off-by: Cristian Iorga <cristian.iorga@intel.com>
---
 meta-yocto/conf/distro/include/upstream_tracking.inc | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta-yocto/conf/distro/include/upstream_tracking.inc b/meta-yocto/conf/distro/include/upstream_tracking.inc
index 15f6a18..2c6a074 100644
--- a/meta-yocto/conf/distro/include/upstream_tracking.inc
+++ b/meta-yocto/conf/distro/include/upstream_tracking.inc
@@ -50,7 +50,6 @@ RECIPE_UPSTREAM_DATE_pn-pseudo = "Jan 23, 2015"
 CHECK_DATE_pseudo = "Feb 12, 2015"
 
 # NO UPDATE REASONS
-RECIPE_NO_UPDATE_REASON_pn-bluez4 = "BlueZ 5.x is not backward-compatible; components that interact with bluez not updated"
 RECIPE_NO_UPDATE_REASON_pn-build-appliance = "Always reports behind"
 RECIPE_NO_UPDATE_REASON_pn-cdrtools = "v3.x uses incompatible CDDL license"
 RECIPE_NO_UPDATE_REASON_pn-createrepo = "Versions after 0.9.* use YUM, so we hold at 0.4.11"
-- 
2.1.0

[PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack

[Cristian Iorga]

For a distro that contains bluetooth feature, set bluez5
as the default Bluetooth stack, while still allowing the
use of bluez4 as an alternative Bluetooth stack.

Signed-off-by: Cristian Iorga <cristian.iorga@intel.com>
---
 meta/classes/bluetooth.bbclass | 16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/meta/classes/bluetooth.bbclass b/meta/classes/bluetooth.bbclass
index f88b4ae..3816e7d 100644
--- a/meta/classes/bluetooth.bbclass
+++ b/meta/classes/bluetooth.bbclass
@@ -1,14 +1,20 @@
 # Avoid code duplication in bluetooth-dependent recipes.
 
-# Define a variable that expands to the recipe (package) providing core
-# bluetooth support on the platform:
+# Define a variable that expands to the recipe (package) providing
+# core bluetooth support on the platform:
 # "" if bluetooth is not in DISTRO_FEATURES
-# else "bluez5" if bluez5 is in DISTRO_FEATURES
-# else "bluez4"
+# else "bluez4" if bluez4 is in DISTRO_FEATURES
+# else "bluez5"
 
 # Use this with:
 #  inherit bluetooth
 #  PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', '${BLUEZ}', '', d)}
 #  PACKAGECONFIG[bluez4] = "--enable-bluez4,--disable-bluez4,bluez4"
+# if the obsolete, but still supported bluez4 BT stack is used
+# or
+#  inherit bluetooth
+#  PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', '${BLUEZ}', '', d)}
+#  PACKAGECONFIG[bluez5] = "--enable-bluez5,--disable-bluez5,bluez5"
+# if the default bluez5 BT stack is used
 
-BLUEZ ?= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', bb.utils.contains('DISTRO_FEATURES', 'bluez5', 'bluez5', 'bluez4', d), '', d)}"
+BLUEZ ?= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', bb.utils.contains('DISTRO_FEATURES', 'bluez4', 'bluez4', 'bluez5', d), '', d)}"
-- 
2.1.0

Re: [PATCH 1/5] bluez5: upgrade to 5.29

[Jack Mitchell]

On 03/04/2015 15:13, Cristian Iorga wrote:
> - Large release with over a month and 475 commits since 5.28;
> - Internal GATT library received lots of updates;
> - Fix for AVCTP key repeat timeout;
> - Added support for the Multi Profile Specification (MPS).
>
> Signed-off-by: Cristian Iorga <cristian.iorga@intel.com>
> ---
>   meta/recipes-connectivity/bluez5/{bluez5_5.28.bb => bluez5_5.29.bb} | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
>   rename meta/recipes-connectivity/bluez5/{bluez5_5.28.bb => bluez5_5.29.bb} (88%)
>
> diff --git a/meta/recipes-connectivity/bluez5/bluez5_5.28.bb b/meta/recipes-connectivity/bluez5/bluez5_5.29.bb
> similarity index 88%
> rename from meta/recipes-connectivity/bluez5/bluez5_5.28.bb
> rename to meta/recipes-connectivity/bluez5/bluez5_5.29.bb
> index e816998..0fe8e7f 100644
> --- a/meta/recipes-connectivity/bluez5/bluez5_5.28.bb
> +++ b/meta/recipes-connectivity/bluez5/bluez5_5.29.bb
> @@ -1,6 +1,6 @@
>   require bluez5.inc
> -SRC_URI[md5sum] = "bc20a8285530758c68f6a60e4ca62a15"
> -SRC_URI[sha256sum] = "85bab48f4b47a158739028682c1e09cf30099c8ea9dfe63360055f8e06fc18a9"
> +SRC_URI[md5sum] = "aa9dc91689695a486c78c131cd68673e"
> +SRC_URI[sha256sum] = "df216a6d5ec6133355e5d4ed6b5e7a188a940940d337374e166758513246f0e4"
>
>   # noinst programs in Makefile.tools that are conditional on READLINE
>   # support
>

5.30 is available now I think

Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack

[Burton, Ross]

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

On 3 April 2015 at 15:13, Cristian Iorga <cristian.iorga@intel.com> wrote:

> -# Define a variable that expands to the recipe (package) providing core
> -# bluetooth support on the platform:
> +# Define a variable that expands to the recipe (package) providing
> +# core bluetooth support on the platform:
>  # "" if bluetooth is not in DISTRO_FEATURES
> -# else "bluez5" if bluez5 is in DISTRO_FEATURES
> -# else "bluez4"
> +# else "bluez4" if bluez4 is in DISTRO_FEATURES
> +# else "bluez5"
>

That wasn't the behaviour that 1.8 sets.  We think we should continue to
respect the bluez5 DISTRO_FEATURE and add it to DISTRO_FEATURES_BACKFILL.

Ross

[-- Attachment #2: Type: text/html, Size: 1143 bytes --]

Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack

[Iorga, Cristian]

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

I thought of 1.9 as the preparatory stage for complete removal of bluez4, so that in 2.0 it would be very easy to remove the support for bluez4. Continuing to have bluez5 added to DISTRO_FEATURES create the impression that BlueZ5 is still a second class citizen compared to BlueZ4, and it is not my intention to sustain this opinion via code.
I hereby standup for my solution. At the moment, we are 1to1. “We think” – Who are the others persons, Ross?
/Cristian

From: Burton, Ross [mailto:ross.burton@intel.com]
Sent: Monday, April 6, 2015 12:41 AM
To: Iorga, Cristian
Cc: OE-core
Subject: Re: [OE-core] [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack


On 3 April 2015 at 15:13, Cristian Iorga <cristian.iorga@intel.com<mailto:cristian.iorga@intel.com>> wrote:
-# Define a variable that expands to the recipe (package) providing core
-# bluetooth support on the platform:
+# Define a variable that expands to the recipe (package) providing
+# core bluetooth support on the platform:
 # "" if bluetooth is not in DISTRO_FEATURES
-# else "bluez5" if bluez5 is in DISTRO_FEATURES
-# else "bluez4"
+# else "bluez4" if bluez4 is in DISTRO_FEATURES
+# else "bluez5"

That wasn't the behaviour that 1.8 sets.  We think we should continue to respect the bluez5 DISTRO_FEATURE and add it to DISTRO_FEATURES_BACKFILL.

Ross

[-- Attachment #2: Type: text/html, Size: 4637 bytes --]

Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack

[Peter A. Bigot]

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

On 04/06/2015 02:31 AM, Iorga, Cristian wrote:
>
> I thought of 1.9 as the preparatory stage for complete removal of 
> bluez4, so that in 2.0 it would be very easy to remove the support for 
> bluez4. Continuing to have bluez5 added to DISTRO_FEATURES create the 
> impression that BlueZ5 is still a second class citizen compared to 
> BlueZ4, and it is not my intention to sustain this opinion via code.
>
> I hereby standup for my solution. At the moment, we are 1to1. “We 
> think” – Who are the others persons, Ross?
>
> /Cristian
>

While I fully support moving to bluez5 and use it in all my images, I do 
think it's a bit abrupt to make it the default in the first stable 
release that provides a usable bluez5.  On the other hand, Yocto's late 
to the bluez5 party and it's going to be harder to support bluez4 now.

Six of one; sign me up as weak support for delaying the move to default 
bluez5 until 1.10.

Just an opinion.

Peter
>
> *From:*Burton, Ross [mailto:ross.burton@intel.com]
> *Sent:* Monday, April 6, 2015 12:41 AM
> *To:* Iorga, Cristian
> *Cc:* OE-core
> *Subject:* Re: [OE-core] [PATCH 5/5] bluetooth.bbclass: set bluez5 as 
> the default BT stack
>
> On 3 April 2015 at 15:13, Cristian Iorga <cristian.iorga@intel.com 
> <mailto:cristian.iorga@intel.com>> wrote:
>
>     -# Define a variable that expands to the recipe (package)
>     providing core
>     -# bluetooth support on the platform:
>     +# Define a variable that expands to the recipe (package) providing
>     +# core bluetooth support on the platform:
>      # "" if bluetooth is not in DISTRO_FEATURES
>     -# else "bluez5" if bluez5 is in DISTRO_FEATURES
>     -# else "bluez4"
>     +# else "bluez4" if bluez4 is in DISTRO_FEATURES
>     +# else "bluez5"
>
>
> That wasn't the behaviour that 1.8 sets.  We think we should continue 
> to respect the bluez5 DISTRO_FEATURE and add it to 
> DISTRO_FEATURES_BACKFILL.
>
> Ross
>
>
>


[-- Attachment #2: Type: text/html, Size: 6586 bytes --]

Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack

[Otavio Salvador]

On Mon, Apr 6, 2015 at 9:57 AM, Peter A. Bigot <pab@pabigot.com> wrote:
> On 04/06/2015 02:31 AM, Iorga, Cristian wrote:
>
> I thought of 1.9 as the preparatory stage for complete removal of bluez4, so
> that in 2.0 it would be very easy to remove the support for bluez4.
> Continuing to have bluez5 added to DISTRO_FEATURES create the impression
> that BlueZ5 is still a second class citizen compared to BlueZ4, and it is
> not my intention to sustain this opinion via code.
>
> I hereby standup for my solution. At the moment, we are 1to1. “We think” –
> Who are the others persons, Ross?
>
> /Cristian
>
>
> While I fully support moving to bluez5 and use it in all my images, I do
> think it's a bit abrupt to make it the default in the first stable release
> that provides a usable bluez5.  On the other hand, Yocto's late to the
> bluez5 party and it's going to be harder to support bluez4 now.
>
> Six of one; sign me up as weak support for delaying the move to default
> bluez5 until 1.10.
>
> Just an opinion.

I prefer bluez5 default in 1.9 and removal in 2.0 (or 1.10). We
shouldn't be support legacy without a very strong reason and if any
member shows up to officially support bluez4 for longer we may drop
its removal but bluez5 default should be done as soon as possible so
we iron out regressions.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack

[Iorga, Cristian]

Well,

1. Peter, Otavio: There is not a single doubt about moving to BlueZ 5 as default in 1.9;
2. The requested feedback was about the actual implementation;
3. Peter: " I do think it's a bit abrupt to make it the default in the first stable release that provides a usable bluez5."; The change is intended for 1.9,the release that will come in October 2015. Do you think that it is still abrupt? BlueZ5 is present in YP as an alternative BT stack from 1.7, it will still be a fully supported alternative in the (unreleased) 1.8 (as far as upstream goes as "fully supported", of course), it will the default BT stack in 1.9 (coming October 2015), while BlueZ 4 will still be supported as an obsolete, but still functional alternative; for 2.0 (why 1.10??), if that will be the name, all mechanisms for having BlueZ alternatives will be removed, and BlueZ 5 will be the only official supported BT stack. That's more than two years for a transition, is that too soon??

/Cristian

-----Original Message-----
From: openembedded-core-bounces@lists.openembedded.org [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of Otavio Salvador
Sent: Monday, April 6, 2015 4:18 PM
To: Peter A. Bigot
Cc: Patches and discussions about the oe-core layer
Subject: Re: [OE-core] [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack

On Mon, Apr 6, 2015 at 9:57 AM, Peter A. Bigot <pab@pabigot.com> wrote:
> On 04/06/2015 02:31 AM, Iorga, Cristian wrote:
>
> I thought of 1.9 as the preparatory stage for complete removal of 
> bluez4, so that in 2.0 it would be very easy to remove the support for bluez4.
> Continuing to have bluez5 added to DISTRO_FEATURES create the 
> impression that BlueZ5 is still a second class citizen compared to 
> BlueZ4, and it is not my intention to sustain this opinion via code.
>
> I hereby standup for my solution. At the moment, we are 1to1. “We 
> think” – Who are the others persons, Ross?
>
> /Cristian
>
>
> While I fully support moving to bluez5 and use it in all my images, I 
> do think it's a bit abrupt to make it the default in the first stable 
> release that provides a usable bluez5.  On the other hand, Yocto's 
> late to the
> bluez5 party and it's going to be harder to support bluez4 now.
>
> Six of one; sign me up as weak support for delaying the move to 
> default
> bluez5 until 1.10.
>
> Just an opinion.

I prefer bluez5 default in 1.9 and removal in 2.0 (or 1.10). We shouldn't be support legacy without a very strong reason and if any member shows up to officially support bluez4 for longer we may drop its removal but bluez5 default should be done as soon as possible so we iron out regressions.

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

Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack

[Peter A. Bigot]

On 04/06/2015 09:32 AM, Iorga, Cristian wrote:
> Well,
>
> 1. Peter, Otavio: There is not a single doubt about moving to BlueZ 5 as default in 1.9;
> 2. The requested feedback was about the actual implementation;
> 3. Peter: " I do think it's a bit abrupt to make it the default in the first stable release that provides a usable bluez5."; The change is intended for 1.9,the release that will come in October 2015. Do you think that it is still abrupt? BlueZ5 is present in YP as an alternative BT stack from 1.7, it will still be a fully supported alternative in the (unreleased) 1.8 (as far as upstream goes as "fully supported", of course), it will the default BT stack in 1.9 (coming October 2015), while BlueZ 4 will still be supported as an obsolete, but still functional alternative; for 2.0 (why 1.10??), if that will be the name, all mechanisms for having BlueZ alternatives will be removed, and BlueZ 5 will be the only official supported BT stack. That's more than two years for a transition, is that too soon??

Sorry; I got confused about which numbers were which and where things 
are in the release cycle.  I didn't consider bluez5 to be generally 
usable until the patches that were merged in February for what will be 
1.8.  Since both bluez4 and bluez5 will be available in 1.8, making the 
default bluez5 in 1.9 is fine, and removing bluez4 in what follows is 
fine.  (I have no idea what version is intended to follow 1.9, but if it 
isn't some huge backwards-incompatible change I would expect it to be 
1.10 rather than 2.0.  That's just from the way I normally manage 
versioning myself.)

I have no objections to the technical approach in the patch (it's 
consistent with what I had in mind when I created that bbclass) but I'm 
not familiar with how DISTRO_FEATURES_BACKFILL is supposed to work so 
abstain from further comment.

Peter

>
> /Cristian
>
> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of Otavio Salvador
> Sent: Monday, April 6, 2015 4:18 PM
> To: Peter A. Bigot
> Cc: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack
>
> On Mon, Apr 6, 2015 at 9:57 AM, Peter A. Bigot <pab@pabigot.com> wrote:
>> On 04/06/2015 02:31 AM, Iorga, Cristian wrote:
>>
>> I thought of 1.9 as the preparatory stage for complete removal of
>> bluez4, so that in 2.0 it would be very easy to remove the support for bluez4.
>> Continuing to have bluez5 added to DISTRO_FEATURES create the
>> impression that BlueZ5 is still a second class citizen compared to
>> BlueZ4, and it is not my intention to sustain this opinion via code.
>>
>> I hereby standup for my solution. At the moment, we are 1to1. “We
>> think” – Who are the others persons, Ross?
>>
>> /Cristian
>>
>>
>> While I fully support moving to bluez5 and use it in all my images, I
>> do think it's a bit abrupt to make it the default in the first stable
>> release that provides a usable bluez5.  On the other hand, Yocto's
>> late to the
>> bluez5 party and it's going to be harder to support bluez4 now.
>>
>> Six of one; sign me up as weak support for delaying the move to
>> default
>> bluez5 until 1.10.
>>
>> Just an opinion.
> I prefer bluez5 default in 1.9 and removal in 2.0 (or 1.10). We shouldn't be support legacy without a very strong reason and if any member shows up to officially support bluez4 for longer we may drop its removal but bluez5 default should be done as soon as possible so we iron out regressions.
>

Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack

[Christopher Larson]

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

On Mon, Apr 6, 2015 at 2:21 PM, Peter A. Bigot <pab@pabigot.com> wrote:

> On 04/06/2015 09:32 AM, Iorga, Cristian wrote:
>
>> Well,
>>
>> 1. Peter, Otavio: There is not a single doubt about moving to BlueZ 5 as
>> default in 1.9;
>> 2. The requested feedback was about the actual implementation;
>> 3. Peter: " I do think it's a bit abrupt to make it the default in the
>> first stable release that provides a usable bluez5."; The change is
>> intended for 1.9,the release that will come in October 2015. Do you think
>> that it is still abrupt? BlueZ5 is present in YP as an alternative BT stack
>> from 1.7, it will still be a fully supported alternative in the
>> (unreleased) 1.8 (as far as upstream goes as "fully supported", of course),
>> it will the default BT stack in 1.9 (coming October 2015), while BlueZ 4
>> will still be supported as an obsolete, but still functional alternative;
>> for 2.0 (why 1.10??), if that will be the name, all mechanisms for having
>> BlueZ alternatives will be removed, and BlueZ 5 will be the only official
>> supported BT stack. That's more than two years for a transition, is that
>> too soon??
>>
>
> Sorry; I got confused about which numbers were which and where things are
> in the release cycle.  I didn't consider bluez5 to be generally usable
> until the patches that were merged in February for what will be 1.8.  Since
> both bluez4 and bluez5 will be available in 1.8, making the default bluez5
> in 1.9 is fine, and removing bluez4 in what follows is fine.  (I have no
> idea what version is intended to follow 1.9, but if it isn't some huge
> backwards-incompatible change I would expect it to be 1.10 rather than
> 2.0.  That's just from the way I normally manage versioning myself.)
>
> I have no objections to the technical approach in the patch (it's
> consistent with what I had in mind when I created that bbclass) but I'm not
> familiar with how DISTRO_FEATURES_BACKFILL is supposed to work so abstain
> from further comment.


Backfill lets you add features which become default in DISTRO_FEATURES even
when a distro overrides DISTRO_FEATURES, unless they explicitly add them to
DISTRO_FEATURES_BACKFILL_CONSIDERED.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

[-- Attachment #2: Type: text/html, Size: 2834 bytes --]

Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack

[Peter A. Bigot]

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

On 04/06/2015 04:39 PM, Christopher Larson wrote:
>
> On Mon, Apr 6, 2015 at 2:21 PM, Peter A. Bigot <pab@pabigot.com 
> <mailto:pab@pabigot.com>> wrote:
>
>     On 04/06/2015 09:32 AM, Iorga, Cristian wrote:
>
>         Well,
>
>         1. Peter, Otavio: There is not a single doubt about moving to
>         BlueZ 5 as default in 1.9;
>         2. The requested feedback was about the actual implementation;
>         3. Peter: " I do think it's a bit abrupt to make it the
>         default in the first stable release that provides a usable
>         bluez5."; The change is intended for 1.9,the release that will
>         come in October 2015. Do you think that it is still abrupt?
>         BlueZ5 is present in YP as an alternative BT stack from 1.7,
>         it will still be a fully supported alternative in the
>         (unreleased) 1.8 (as far as upstream goes as "fully
>         supported", of course), it will the default BT stack in 1.9
>         (coming October 2015), while BlueZ 4 will still be supported
>         as an obsolete, but still functional alternative; for 2.0 (why
>         1.10??), if that will be the name, all mechanisms for having
>         BlueZ alternatives will be removed, and BlueZ 5 will be the
>         only official supported BT stack. That's more than two years
>         for a transition, is that too soon??
>
>
>     Sorry; I got confused about which numbers were which and where
>     things are in the release cycle.  I didn't consider bluez5 to be
>     generally usable until the patches that were merged in February
>     for what will be 1.8.  Since both bluez4 and bluez5 will be
>     available in 1.8, making the default bluez5 in 1.9 is fine, and
>     removing bluez4 in what follows is fine.  (I have no idea what
>     version is intended to follow 1.9, but if it isn't some huge
>     backwards-incompatible change I would expect it to be 1.10 rather
>     than 2.0.  That's just from the way I normally manage versioning
>     myself.)
>
>     I have no objections to the technical approach in the patch (it's
>     consistent with what I had in mind when I created that bbclass)
>     but I'm not familiar with how DISTRO_FEATURES_BACKFILL is supposed
>     to work so abstain from further comment.
>
>
> Backfill lets you add features which become default in DISTRO_FEATURES 
> even when a distro overrides DISTRO_FEATURES, unless they explicitly 
> add them to DISTRO_FEATURES_BACKFILL_CONSIDERED.

Thank you.  So, if I understand correctly, the effect of adding bluez5 
to DISTRO_FEATURES_BACKFILL while keeping the current logic:

# bluetooth support on the platform:
# "" if bluetooth is not in DISTRO_FEATURES
# else "bluez5" if bluez5 is in DISTRO_FEATURES
# else "bluez4"

is that bluez5 becomes the default and is in DISTRO_FEATURES 
automatically, and it stays the default even if bluez4 is also in 
DISTRO_FEATURES unless somebody adds bluez5 to 
DISTRO_FEATURES_BACKFILL_CONSIDERED at which point bluez4 takes precedence.

If that understanding is correct, and reviewing 
http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#ref-features-backfill, 
it's not clear to me that it's the right approach.  We're not 
backfilling "bluetooth", which remains optional and continues to control 
whether either "bluez4" or "bluez5" is relevant.  We're changing the 
default provider of bluetooth services, something that I think can 
reasonably be changed between releases, and something that 1.8 already 
controls (via explicit specification of bluez4 or bluez5 in 
DISTRO_FEATURES).

In the absence of more detail on why using DISTRO_FEATURES_BACKFILL is a 
better solution I prefer Cristian's original approach.

Peter


[-- Attachment #2: Type: text/html, Size: 5538 bytes --]

Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack

[Tanu Kaskinen]

On Fri, 2015-04-03 at 17:13 +0300, Cristian Iorga wrote:
>  # Use this with:
>  #  inherit bluetooth
>  #  PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', '${BLUEZ}', '', d)}
>  #  PACKAGECONFIG[bluez4] = "--enable-bluez4,--disable-bluez4,bluez4"
> +# if the obsolete, but still supported bluez4 BT stack is used
> +# or
> +#  inherit bluetooth
> +#  PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', '${BLUEZ}', '', d)}
> +#  PACKAGECONFIG[bluez5] = "--enable-bluez5,--disable-bluez5,bluez5"
> +# if the default bluez5 BT stack is used

I don't think this documentation is correct. It makes it sound like a
recipe should only have

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

or

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

, while in reality the recipe should have both lines.

So, I think the documentation should be written like this:

# Use this with:
#  inherit bluetooth
#  PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', '${BLUEZ}', '', d)}
#  PACKAGECONFIG[bluez4] = "--enable-bluez4,--disable-bluez4,bluez4"
#  PACKAGECONFIG[bluez5] = "--enable-bluez5,--disable-bluez5,bluez5"

-- 
Tanu

Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack

[Martin Jansa]

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

On Mon, Apr 06, 2015 at 02:32:13PM +0000, Iorga, Cristian wrote:
> for 2.0 (why 1.10??), if that will be the name, all mechanisms for
> having BlueZ alternatives will be removed, and BlueZ 5 will be the
> only official supported BT stack.

why would you remove mechanisms for having BlueZ alternatives?

Some projects are still using different bluetooth implementations and
having the possibility to disable/replace bluez* is still useful.

Cheers,

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of Otavio Salvador
> Sent: Monday, April 6, 2015 4:18 PM
> To: Peter A. Bigot
> Cc: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack
> 
> On Mon, Apr 6, 2015 at 9:57 AM, Peter A. Bigot <pab@pabigot.com> wrote:
> > On 04/06/2015 02:31 AM, Iorga, Cristian wrote:
> >
> > I thought of 1.9 as the preparatory stage for complete removal of 
> > bluez4, so that in 2.0 it would be very easy to remove the support for bluez4.
> > Continuing to have bluez5 added to DISTRO_FEATURES create the 
> > impression that BlueZ5 is still a second class citizen compared to 
> > BlueZ4, and it is not my intention to sustain this opinion via code.
> >
> > I hereby standup for my solution. At the moment, we are 1to1. “We 
> > think” – Who are the others persons, Ross?
> >
> > /Cristian
> >
> >
> > While I fully support moving to bluez5 and use it in all my images, I 
> > do think it's a bit abrupt to make it the default in the first stable 
> > release that provides a usable bluez5.  On the other hand, Yocto's 
> > late to the
> > bluez5 party and it's going to be harder to support bluez4 now.
> >
> > Six of one; sign me up as weak support for delaying the move to 
> > default
> > bluez5 until 1.10.
> >
> > Just an opinion.
> 
> I prefer bluez5 default in 1.9 and removal in 2.0 (or 1.10). We shouldn't be support legacy without a very strong reason and if any member shows up to officially support bluez4 for longer we may drop its removal but bluez5 default should be done as soon as possible so we iron out regressions.
> 
> -- 
> Otavio Salvador                             O.S. Systems
> http://www.ossystems.com.br        http://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> -- 
> _______________________________________________
> 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: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack

[Iorga, Cristian]

Well:
1. That's a thing for the future
2. Who will maintain support for bugs reported to BlueZ 4.x? It's a matter of resources.
3. "Projects using different Bluetooth implementations" is something different from switching from BZ4 to BZ5 and vice versa. We don’t support multiple Bluetooth stacks, but (incompatible!) variants of BlueZ. That's different. In the future, we will no longer support both, why complicate the code?

/Cristian Iorga
Yocto Project
Intel Corporation

-----Original Message-----
From: Martin Jansa [mailto:martin.jansa@gmail.com] 
Sent: Tuesday, April 7, 2015 1:55 PM
To: Iorga, Cristian
Cc: Otavio Salvador; Peter A. Bigot; Patches and discussions about the oe-core layer
Subject: Re: [OE-core] [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack

On Mon, Apr 06, 2015 at 02:32:13PM +0000, Iorga, Cristian wrote:
> for 2.0 (why 1.10??), if that will be the name, all mechanisms for 
> having BlueZ alternatives will be removed, and BlueZ 5 will be the 
> only official supported BT stack.

why would you remove mechanisms for having BlueZ alternatives?

Some projects are still using different bluetooth implementations and having the possibility to disable/replace bluez* is still useful.

Cheers,

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org 
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of 
> Otavio Salvador
> Sent: Monday, April 6, 2015 4:18 PM
> To: Peter A. Bigot
> Cc: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 5/5] bluetooth.bbclass: set bluez5 as 
> the default BT stack
> 
> On Mon, Apr 6, 2015 at 9:57 AM, Peter A. Bigot <pab@pabigot.com> wrote:
> > On 04/06/2015 02:31 AM, Iorga, Cristian wrote:
> >
> > I thought of 1.9 as the preparatory stage for complete removal of 
> > bluez4, so that in 2.0 it would be very easy to remove the support for bluez4.
> > Continuing to have bluez5 added to DISTRO_FEATURES create the 
> > impression that BlueZ5 is still a second class citizen compared to 
> > BlueZ4, and it is not my intention to sustain this opinion via code.
> >
> > I hereby standup for my solution. At the moment, we are 1to1. “We 
> > think” – Who are the others persons, Ross?
> >
> > /Cristian
> >
> >
> > While I fully support moving to bluez5 and use it in all my images, 
> > I do think it's a bit abrupt to make it the default in the first 
> > stable release that provides a usable bluez5.  On the other hand, 
> > Yocto's late to the
> > bluez5 party and it's going to be harder to support bluez4 now.
> >
> > Six of one; sign me up as weak support for delaying the move to 
> > default
> > bluez5 until 1.10.
> >
> > Just an opinion.
> 
> I prefer bluez5 default in 1.9 and removal in 2.0 (or 1.10). We shouldn't be support legacy without a very strong reason and if any member shows up to officially support bluez4 for longer we may drop its removal but bluez5 default should be done as soon as possible so we iron out regressions.
> 
> -- 
> Otavio Salvador                             O.S. Systems
> http://www.ossystems.com.br        http://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> --
> _______________________________________________
> 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

Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack

[Iorga, Cristian]

The aforementioned packageconfigs are just examples/guidelines, we added code for diverse recipes on a case by case scenario.

-----Original Message-----
From: Tanu Kaskinen [mailto:tanu.kaskinen@linux.intel.com] 
Sent: Tuesday, April 7, 2015 1:27 PM
To: Iorga, Cristian
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack

On Fri, 2015-04-03 at 17:13 +0300, Cristian Iorga wrote:
>  # Use this with:
>  #  inherit bluetooth
>  #  PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 
> 'bluetooth', '${BLUEZ}', '', d)}  #  PACKAGECONFIG[bluez4] = "--enable-bluez4,--disable-bluez4,bluez4"
> +# if the obsolete, but still supported bluez4 BT stack is used # or #  
> +inherit bluetooth #  PACKAGECONFIG ??= 
> +"${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', '${BLUEZ}', '', 
> +d)} #  PACKAGECONFIG[bluez5] = "--enable-bluez5,--disable-bluez5,bluez5"
> +# if the default bluez5 BT stack is used

I don't think this documentation is correct. It makes it sound like a recipe should only have

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

or

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

, while in reality the recipe should have both lines.

So, I think the documentation should be written like this:

# Use this with:
#  inherit bluetooth
#  PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', '${BLUEZ}', '', d)} #  PACKAGECONFIG[bluez4] = "--enable-bluez4,--disable-bluez4,bluez4"
#  PACKAGECONFIG[bluez5] = "--enable-bluez5,--disable-bluez5,bluez5"

--
Tanu

Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack

[Tanu Kaskinen]

On Tue, 2015-04-07 at 11:23 +0000, Iorga, Cristian wrote:
> The aforementioned packageconfigs are just examples/guidelines, we
> added code for diverse recipes on a case by case scenario.

My point was that the examples/guidelines are misleading, and should be
fixed.

-- 
Tanu

Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack

[Iorga, Cristian]

The only way this could be fixed is to remove the aforementioned guidelines..
Like I said, there are plenty of examples in the code.
Those packageconfigs where elaborated based on:
1. if a package has support for both BlueZ versions;
2. If not, usually only BlueZ 4 is supported;

Care to elaborate how I can fix them otherwise? I am open to suggestions.
Thanks,
Cristian

-----Original Message-----
From: Tanu Kaskinen [mailto:tanu.kaskinen@linux.intel.com] 
Sent: Tuesday, April 7, 2015 2:41 PM
To: Iorga, Cristian
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack

On Tue, 2015-04-07 at 11:23 +0000, Iorga, Cristian wrote:
> The aforementioned packageconfigs are just examples/guidelines, we 
> added code for diverse recipes on a case by case scenario.

My point was that the examples/guidelines are misleading, and should be fixed.

--
Tanu

Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack

[Martin Jansa]

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

On Tue, Apr 07, 2015 at 11:21:09AM +0000, Iorga, Cristian wrote:
> Well:
> 1. That's a thing for the future
> 2. Who will maintain support for bugs reported to BlueZ 4.x? It's a matter of resources.
> 3. "Projects using different Bluetooth implementations" is something different from switching from BZ4 to BZ5 and vice versa. We don’t support multiple Bluetooth stacks, but (incompatible!) variants of BlueZ. That's different. In the future, we will no longer support both, why complicate the code?

Because OE is supposed to be flexible build system?

"switching from BZ4 to BZ5 and vice versa" is something different from
"all mechanisms for having BlueZ alternatives will be removed"

> /Cristian Iorga
> Yocto Project
> Intel Corporation
> 
> -----Original Message-----
> From: Martin Jansa [mailto:martin.jansa@gmail.com] 
> Sent: Tuesday, April 7, 2015 1:55 PM
> To: Iorga, Cristian
> Cc: Otavio Salvador; Peter A. Bigot; Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack
> 
> On Mon, Apr 06, 2015 at 02:32:13PM +0000, Iorga, Cristian wrote:
> > for 2.0 (why 1.10??), if that will be the name, all mechanisms for 
> > having BlueZ alternatives will be removed, and BlueZ 5 will be the 
> > only official supported BT stack.
> 
> why would you remove mechanisms for having BlueZ alternatives?
> 
> Some projects are still using different bluetooth implementations and having the possibility to disable/replace bluez* is still useful.
> 
> Cheers,
> 
> > -----Original Message-----
> > From: openembedded-core-bounces@lists.openembedded.org 
> > [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of 
> > Otavio Salvador
> > Sent: Monday, April 6, 2015 4:18 PM
> > To: Peter A. Bigot
> > Cc: Patches and discussions about the oe-core layer
> > Subject: Re: [OE-core] [PATCH 5/5] bluetooth.bbclass: set bluez5 as 
> > the default BT stack
> > 
> > On Mon, Apr 6, 2015 at 9:57 AM, Peter A. Bigot <pab@pabigot.com> wrote:
> > > On 04/06/2015 02:31 AM, Iorga, Cristian wrote:
> > >
> > > I thought of 1.9 as the preparatory stage for complete removal of 
> > > bluez4, so that in 2.0 it would be very easy to remove the support for bluez4.
> > > Continuing to have bluez5 added to DISTRO_FEATURES create the 
> > > impression that BlueZ5 is still a second class citizen compared to 
> > > BlueZ4, and it is not my intention to sustain this opinion via code.
> > >
> > > I hereby standup for my solution. At the moment, we are 1to1. “We 
> > > think” – Who are the others persons, Ross?
> > >
> > > /Cristian
> > >
> > >
> > > While I fully support moving to bluez5 and use it in all my images, 
> > > I do think it's a bit abrupt to make it the default in the first 
> > > stable release that provides a usable bluez5.  On the other hand, 
> > > Yocto's late to the
> > > bluez5 party and it's going to be harder to support bluez4 now.
> > >
> > > Six of one; sign me up as weak support for delaying the move to 
> > > default
> > > bluez5 until 1.10.
> > >
> > > Just an opinion.
> > 
> > I prefer bluez5 default in 1.9 and removal in 2.0 (or 1.10). We shouldn't be support legacy without a very strong reason and if any member shows up to officially support bluez4 for longer we may drop its removal but bluez5 default should be done as soon as possible so we iron out regressions.
> > 
> > -- 
> > Otavio Salvador                             O.S. Systems
> > http://www.ossystems.com.br        http://code.ossystems.com.br
> > Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
> > --
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> > --
> > _______________________________________________
> > 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

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

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

Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack

[Tanu Kaskinen]

(A friendly request: could you use interleaved posting style as
described in the mailing list guidelines here:
https://wiki.yoctoproject.org/wiki/Community_Guidelines )

On Tue, 2015-04-07 at 11:51 +0000, Iorga, Cristian wrote:
> The only way this could be fixed is to remove the aforementioned guidelines..
> Like I said, there are plenty of examples in the code.
> Those packageconfigs where elaborated based on:
> 1. if a package has support for both BlueZ versions;
> 2. If not, usually only BlueZ 4 is supported;
> 
> Care to elaborate how I can fix them otherwise? I am open to suggestions.

Sure, I can give concrete suggestions. This one I already gave in my
first mail:

# Use this with:
#  inherit bluetooth
#  PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', '${BLUEZ}', '', d)}"
#  PACKAGECONFIG[bluez4] = "--enable-bluez4,--disable-bluez4,bluez4"
#  PACKAGECONFIG[bluez5] = "--enable-bluez5,--disable-bluez5,bluez5"

When someone applies that example to a recipe that only supports one
bluetooth implementation, then the example of course needs some
adaptation, but that's ok. I think the example gives a clear enough idea
how the BLUEZ variable is supposed to be used.

Note that if you anyway want to also give an example of how to deal with
recipes that only support one bluetooth implmementation, I think this
line should be changed:

  PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', '${BLUEZ}', '', d)}"

The reason is that if the recipe only supports bluez4, for example, then
PACKAGECONFIG should never include bluez5, but that line will put bluez5
to PACKAGECONFIG if the distro's chosen bluetooth implementation is
bluez5. I suppose that doesn't actually break anything, but I don't
think it's a good idea to recommend adding garbage to PACKAGECONFIG.

This would be more appropriate for recipes that only support bluez4:

#  inherit bluetooth
#  PACKAGECONFIG ??= "${@bb.utils.contains('BLUEZ', 'bluez4', 'bluez4, '', d}"
#  PACKAGECONFIG[bluez4] = "--enable-bluez4,--disable-bluez4,bluez4"

-- 
Tanu

Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack

[Martin Jansa]

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

On Tue, Apr 07, 2015 at 03:36:31PM +0300, Tanu Kaskinen wrote:
> (A friendly request: could you use interleaved posting style as
> described in the mailing list guidelines here:
> https://wiki.yoctoproject.org/wiki/Community_Guidelines )
> 
> On Tue, 2015-04-07 at 11:51 +0000, Iorga, Cristian wrote:
> > The only way this could be fixed is to remove the aforementioned guidelines..
> > Like I said, there are plenty of examples in the code.
> > Those packageconfigs where elaborated based on:
> > 1. if a package has support for both BlueZ versions;
> > 2. If not, usually only BlueZ 4 is supported;
> > 
> > Care to elaborate how I can fix them otherwise? I am open to suggestions.
> 
> Sure, I can give concrete suggestions. This one I already gave in my
> first mail:
> 
> # Use this with:
> #  inherit bluetooth
> #  PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', '${BLUEZ}', '', d)}"
> #  PACKAGECONFIG[bluez4] = "--enable-bluez4,--disable-bluez4,bluez4"
> #  PACKAGECONFIG[bluez5] = "--enable-bluez5,--disable-bluez5,bluez5"
> 
> When someone applies that example to a recipe that only supports one
> bluetooth implementation, then the example of course needs some
> adaptation, but that's ok. I think the example gives a clear enough idea
> how the BLUEZ variable is supposed to be used.
> 
> Note that if you anyway want to also give an example of how to deal with
> recipes that only support one bluetooth implmementation, I think this
> line should be changed:
> 
>   PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', '${BLUEZ}', '', d)}"
> 
> The reason is that if the recipe only supports bluez4, for example, then
> PACKAGECONFIG should never include bluez5, but that line will put bluez5
> to PACKAGECONFIG if the distro's chosen bluetooth implementation is
> bluez5. I suppose that doesn't actually break anything, but I don't
> think it's a good idea to recommend adding garbage to PACKAGECONFIG.
> 
> This would be more appropriate for recipes that only support bluez4:
> 
> #  inherit bluetooth
> #  PACKAGECONFIG ??= "${@bb.utils.contains('BLUEZ', 'bluez4', 'bluez4, '', d}"
> #  PACKAGECONFIG[bluez4] = "--enable-bluez4,--disable-bluez4,bluez4"

The last example isn't correct, because you still need to respect
'bluetooth' in 'DISTRO_FEATURES' before enabling whatever is in BLUEZ
variable.

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

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

Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack

[Tanu Kaskinen]

On Tue, 2015-04-07 at 14:44 +0200, Martin Jansa wrote:
> On Tue, Apr 07, 2015 at 03:36:31PM +0300, Tanu Kaskinen wrote:
> > This would be more appropriate for recipes that only support bluez4:
> > 
> > #  inherit bluetooth
> > #  PACKAGECONFIG ??= "${@bb.utils.contains('BLUEZ', 'bluez4', 'bluez4, '', d}"
> > #  PACKAGECONFIG[bluez4] = "--enable-bluez4,--disable-bluez4,bluez4"
> 
> The last example isn't correct, because you still need to respect
> 'bluetooth' in 'DISTRO_FEATURES' before enabling whatever is in BLUEZ
> variable.

BLUEZ is empty if 'bluetooth' is not in DISTRO_FEATURES, so my example
should work fine.

-- 
Tanu

Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack

[Martin Jansa]

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

On Tue, Apr 07, 2015 at 03:46:06PM +0300, Tanu Kaskinen wrote:
> On Tue, 2015-04-07 at 14:44 +0200, Martin Jansa wrote:
> > On Tue, Apr 07, 2015 at 03:36:31PM +0300, Tanu Kaskinen wrote:
> > > This would be more appropriate for recipes that only support bluez4:
> > > 
> > > #  inherit bluetooth
> > > #  PACKAGECONFIG ??= "${@bb.utils.contains('BLUEZ', 'bluez4', 'bluez4, '', d}"
> > > #  PACKAGECONFIG[bluez4] = "--enable-bluez4,--disable-bluez4,bluez4"
> > 
> > The last example isn't correct, because you still need to respect
> > 'bluetooth' in 'DISTRO_FEATURES' before enabling whatever is in BLUEZ
> > variable.
> 
> BLUEZ is empty if 'bluetooth' is not in DISTRO_FEATURES, so my example
> should work fine.

The default value is, but that doesn't ensure that user has different
value set in local.conf and suddenly his bluetooth-less distro
configuration is trying to enable bluez* support in some component.

So for consistency sake you should respect bluetooth in DISTRO_FEATURES
(like in the previous example).

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

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

Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack

[Tanu Kaskinen]

On Tue, 2015-04-07 at 15:02 +0200, Martin Jansa wrote:
> On Tue, Apr 07, 2015 at 03:46:06PM +0300, Tanu Kaskinen wrote:
> > On Tue, 2015-04-07 at 14:44 +0200, Martin Jansa wrote:
> > > On Tue, Apr 07, 2015 at 03:36:31PM +0300, Tanu Kaskinen wrote:
> > > > This would be more appropriate for recipes that only support bluez4:
> > > > 
> > > > #  inherit bluetooth
> > > > #  PACKAGECONFIG ??= "${@bb.utils.contains('BLUEZ', 'bluez4', 'bluez4, '', d}"
> > > > #  PACKAGECONFIG[bluez4] = "--enable-bluez4,--disable-bluez4,bluez4"
> > > 
> > > The last example isn't correct, because you still need to respect
> > > 'bluetooth' in 'DISTRO_FEATURES' before enabling whatever is in BLUEZ
> > > variable.
> > 
> > BLUEZ is empty if 'bluetooth' is not in DISTRO_FEATURES, so my example
> > should work fine.
> 
> The default value is, but that doesn't ensure that user has different
> value set in local.conf and suddenly his bluetooth-less distro
> configuration is trying to enable bluez* support in some component.
> 
> So for consistency sake you should respect bluetooth in DISTRO_FEATURES
> (like in the previous example).

I don't see any use case where it would make sense to set BLUEZ outside
bluetooth.bbclass. Do you? For simplicity reasons, my preference would
be to treat the BLUEZ variable as read-only outside bluetooth.bbclass
(and document it as such).

You're definitely right about being consistent, though - if we can
assume BLUEZ to be empty when 'bluetooth' is not in DISTRO_FEATURES,
then there's no point in checking DISTRO_FEATURES in the first example
either.

-- 
Tanu

Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack

[Burton, Ross]

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

On 7 April 2015 at 00:41, Peter A. Bigot <pab@pabigot.com> wrote:

> Thank you.  So, if I understand correctly, the effect of adding bluez5 to
> DISTRO_FEATURES_BACKFILL while keeping the current logic:
>
> # bluetooth support on the platform:
> # "" if bluetooth is not in DISTRO_FEATURES
> # else "bluez5" if bluez5 is in DISTRO_FEATURES
> # else "bluez4"
>
> is that bluez5 becomes the default and is in DISTRO_FEATURES
> automatically, and it stays the default even if bluez4 is also in
> DISTRO_FEATURES unless somebody adds bluez5 to
> DISTRO_FEATURES_BACKFILL_CONSIDERED at which point bluez4 takes precedence.
>
> If that understanding is correct, and reviewing
> http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#ref-features-backfill,
> it's not clear to me that it's the right approach.  We're not backfilling
> "bluetooth", which remains optional and continues to control whether either
> "bluez4" or "bluez5" is relevant.  We're changing the default provider of
> bluetooth services, something that I think can reasonably be changed
> between releases, and something that 1.8 already controls (via explicit
> specification of bluez4 or bluez5 in DISTRO_FEATURES).
>

My reasoning for backfilling bluez5 is that bluetooth.bbclass has a defined
behaviour in 1.8:

if bluetooth in DF:
  if bluez5 in DF:
   return "bluez5"
  else:
    return "bluez4"
else:
  return ""

There's no mention of a bluez4 DISTRO_FEATURE, just a "bluetooth" value to
enable/disable Bluetooth in general, and the toggle between BlueZ 4 and 5
is the presence of a "bluez5" DISTRO_FEATURE.

We don't need to change the algorithm or create new DISTRO_FEATURE entries,
as we have all the logic and items needed: by backfilling bluez5 into
DISTRO_FEATURES we get the default switched, and distributions can flip
back to bluez4 when upgrading to 1.9 by adding in meta-connectivity and
wiping out bluez5 from DISTRO_FEATURES.

Or am I alone in thinking this is the best approach going forward?

Ross

[-- Attachment #2: Type: text/html, Size: 3242 bytes --]

Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack

[Christopher Larson]

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

On Tue, Apr 14, 2015 at 6:28 AM, Burton, Ross <ross.burton@intel.com> wrote:

> On 7 April 2015 at 00:41, Peter A. Bigot <pab@pabigot.com> wrote:
>
>> Thank you.  So, if I understand correctly, the effect of adding bluez5 to
>> DISTRO_FEATURES_BACKFILL while keeping the current logic:
>>
>> # bluetooth support on the platform:
>> # "" if bluetooth is not in DISTRO_FEATURES
>> # else "bluez5" if bluez5 is in DISTRO_FEATURES
>> # else "bluez4"
>>
>> is that bluez5 becomes the default and is in DISTRO_FEATURES
>> automatically, and it stays the default even if bluez4 is also in
>> DISTRO_FEATURES unless somebody adds bluez5 to
>> DISTRO_FEATURES_BACKFILL_CONSIDERED at which point bluez4 takes precedence.
>>
>> If that understanding is correct, and reviewing
>> http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#ref-features-backfill,
>> it's not clear to me that it's the right approach.  We're not backfilling
>> "bluetooth", which remains optional and continues to control whether either
>> "bluez4" or "bluez5" is relevant.  We're changing the default provider of
>> bluetooth services, something that I think can reasonably be changed
>> between releases, and something that 1.8 already controls (via explicit
>> specification of bluez4 or bluez5 in DISTRO_FEATURES).
>>
>
> My reasoning for backfilling bluez5 is that bluetooth.bbclass has a
> defined behaviour in 1.8:
>
> if bluetooth in DF:
>   if bluez5 in DF:
>    return "bluez5"
>   else:
>     return "bluez4"
> else:
>   return ""
>
> There's no mention of a bluez4 DISTRO_FEATURE, just a "bluetooth" value to
> enable/disable Bluetooth in general, and the toggle between BlueZ 4 and 5
> is the presence of a "bluez5" DISTRO_FEATURE.
>
> We don't need to change the algorithm or create new DISTRO_FEATURE
> entries, as we have all the logic and items needed: by backfilling bluez5
> into DISTRO_FEATURES we get the default switched, and distributions can
> flip back to bluez4 when upgrading to 1.9 by adding in meta-connectivity
> and wiping out bluez5 from DISTRO_FEATURES.
>
> Or am I alone in thinking this is the best approach going forward?
>

For what it's worth, I'd agree with that. There's no need to change the
logic.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

[-- Attachment #2: Type: text/html, Size: 3849 bytes --]

Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack

[Burton, Ross]

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

On 14 April 2015 at 16:38, Christopher Larson <clarson@kergoth.com> wrote:

> For what it's worth, I'd agree with that. There's no need to change the
> logic.
>

Where do you stand on backfilling verses just setting
DEFAULT_DISTRO_FEATURES?

Ross

[-- Attachment #2: Type: text/html, Size: 612 bytes --]