* [PATCH 0/5] Switch to BlueZ 5.x as default Bluetooth stack @ 2015-04-03 14:13 Cristian Iorga 2015-04-03 14:13 ` [PATCH 1/5] bluez5: upgrade to 5.29 Cristian Iorga ` (4 more replies) 0 siblings, 5 replies; 30+ messages in thread From: Cristian Iorga @ 2015-04-03 14:13 UTC (permalink / raw) To: openembedded-core 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH 1/5] bluez5: upgrade to 5.29 2015-04-03 14:13 [PATCH 0/5] Switch to BlueZ 5.x as default Bluetooth stack Cristian Iorga @ 2015-04-03 14:13 ` Cristian Iorga 2015-04-03 19:01 ` Jack Mitchell 2015-04-03 14:13 ` [PATCH 2/5] bluez: remove recipes collection Cristian Iorga ` (3 subsequent siblings) 4 siblings, 1 reply; 30+ messages in thread From: Cristian Iorga @ 2015-04-03 14:13 UTC (permalink / raw) To: openembedded-core - 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 ^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [PATCH 1/5] bluez5: upgrade to 5.29 2015-04-03 14:13 ` [PATCH 1/5] bluez5: upgrade to 5.29 Cristian Iorga @ 2015-04-03 19:01 ` Jack Mitchell 0 siblings, 0 replies; 30+ messages in thread From: Jack Mitchell @ 2015-04-03 19:01 UTC (permalink / raw) To: openembedded-core 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH 2/5] bluez: remove recipes collection 2015-04-03 14:13 [PATCH 0/5] Switch to BlueZ 5.x as default Bluetooth stack Cristian Iorga 2015-04-03 14:13 ` [PATCH 1/5] bluez5: upgrade to 5.29 Cristian Iorga @ 2015-04-03 14:13 ` Cristian Iorga 2015-04-03 14:13 ` [PATCH 3/5] maintainers.inc: remove info related to bluez4 Cristian Iorga ` (2 subsequent siblings) 4 siblings, 0 replies; 30+ messages in thread From: Cristian Iorga @ 2015-04-03 14:13 UTC (permalink / raw) To: openembedded-core 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 ^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH 3/5] maintainers.inc: remove info related to bluez4 2015-04-03 14:13 [PATCH 0/5] Switch to BlueZ 5.x as default Bluetooth stack Cristian Iorga 2015-04-03 14:13 ` [PATCH 1/5] bluez5: upgrade to 5.29 Cristian Iorga 2015-04-03 14:13 ` [PATCH 2/5] bluez: remove recipes collection Cristian Iorga @ 2015-04-03 14:13 ` Cristian Iorga 2015-04-03 14:13 ` [PATCH 4/5] upstream_tracking.inc: bluez4 removed from oe-core Cristian Iorga 2015-04-03 14:13 ` [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack Cristian Iorga 4 siblings, 0 replies; 30+ messages in thread From: Cristian Iorga @ 2015-04-03 14:13 UTC (permalink / raw) To: openembedded-core 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 ^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH 4/5] upstream_tracking.inc: bluez4 removed from oe-core 2015-04-03 14:13 [PATCH 0/5] Switch to BlueZ 5.x as default Bluetooth stack Cristian Iorga ` (2 preceding siblings ...) 2015-04-03 14:13 ` [PATCH 3/5] maintainers.inc: remove info related to bluez4 Cristian Iorga @ 2015-04-03 14:13 ` Cristian Iorga 2015-04-03 14:13 ` [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack Cristian Iorga 4 siblings, 0 replies; 30+ messages in thread From: Cristian Iorga @ 2015-04-03 14:13 UTC (permalink / raw) To: openembedded-core 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 ^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack 2015-04-03 14:13 [PATCH 0/5] Switch to BlueZ 5.x as default Bluetooth stack Cristian Iorga ` (3 preceding siblings ...) 2015-04-03 14:13 ` [PATCH 4/5] upstream_tracking.inc: bluez4 removed from oe-core Cristian Iorga @ 2015-04-03 14:13 ` Cristian Iorga 2015-04-05 21:40 ` Burton, Ross 2015-04-07 10:27 ` Tanu Kaskinen 4 siblings, 2 replies; 30+ messages in thread From: Cristian Iorga @ 2015-04-03 14:13 UTC (permalink / raw) To: openembedded-core 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 ^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack 2015-04-03 14:13 ` [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack Cristian Iorga @ 2015-04-05 21:40 ` Burton, Ross 2015-04-06 7:31 ` Iorga, Cristian 2015-04-07 10:27 ` Tanu Kaskinen 1 sibling, 1 reply; 30+ messages in thread From: Burton, Ross @ 2015-04-05 21:40 UTC (permalink / raw) To: Cristian Iorga; +Cc: OE-core [-- 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 --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack 2015-04-05 21:40 ` Burton, Ross @ 2015-04-06 7:31 ` Iorga, Cristian 2015-04-06 12:57 ` Peter A. Bigot 0 siblings, 1 reply; 30+ messages in thread From: Iorga, Cristian @ 2015-04-06 7:31 UTC (permalink / raw) To: Burton, Ross; +Cc: OE-core [-- 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 --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack 2015-04-06 7:31 ` Iorga, Cristian @ 2015-04-06 12:57 ` Peter A. Bigot 2015-04-06 13:18 ` Otavio Salvador 0 siblings, 1 reply; 30+ messages in thread From: Peter A. Bigot @ 2015-04-06 12:57 UTC (permalink / raw) To: openembedded-core [-- 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 --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack 2015-04-06 12:57 ` Peter A. Bigot @ 2015-04-06 13:18 ` Otavio Salvador 2015-04-06 14:32 ` Iorga, Cristian 0 siblings, 1 reply; 30+ messages in thread From: Otavio Salvador @ 2015-04-06 13:18 UTC (permalink / raw) To: Peter A. Bigot; +Cc: Patches and discussions about the oe-core layer 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack 2015-04-06 13:18 ` Otavio Salvador @ 2015-04-06 14:32 ` Iorga, Cristian 2015-04-06 21:21 ` Peter A. Bigot 2015-04-07 10:55 ` Martin Jansa 0 siblings, 2 replies; 30+ messages in thread From: Iorga, Cristian @ 2015-04-06 14:32 UTC (permalink / raw) To: Otavio Salvador, Peter A. Bigot Cc: Patches and discussions about the oe-core layer 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack 2015-04-06 14:32 ` Iorga, Cristian @ 2015-04-06 21:21 ` Peter A. Bigot 2015-04-06 21:39 ` Christopher Larson 2015-04-07 10:55 ` Martin Jansa 1 sibling, 1 reply; 30+ messages in thread From: Peter A. Bigot @ 2015-04-06 21:21 UTC (permalink / raw) To: Iorga, Cristian, Otavio Salvador Cc: Patches and discussions about the oe-core layer 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. > ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack 2015-04-06 21:21 ` Peter A. Bigot @ 2015-04-06 21:39 ` Christopher Larson 2015-04-06 23:41 ` Peter A. Bigot 0 siblings, 1 reply; 30+ messages in thread From: Christopher Larson @ 2015-04-06 21:39 UTC (permalink / raw) To: Peter A. Bigot Cc: Otavio Salvador, Patches and discussions about the oe-core layer [-- 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 --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack 2015-04-06 21:39 ` Christopher Larson @ 2015-04-06 23:41 ` Peter A. Bigot 2015-04-14 13:28 ` Burton, Ross 0 siblings, 1 reply; 30+ messages in thread From: Peter A. Bigot @ 2015-04-06 23:41 UTC (permalink / raw) To: Christopher Larson Cc: Otavio Salvador, Patches and discussions about the oe-core layer [-- 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 --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack 2015-04-06 23:41 ` Peter A. Bigot @ 2015-04-14 13:28 ` Burton, Ross 2015-04-14 15:38 ` Christopher Larson 0 siblings, 1 reply; 30+ messages in thread From: Burton, Ross @ 2015-04-14 13:28 UTC (permalink / raw) To: Peter A. Bigot Cc: Christopher Larson, Otavio Salvador, Patches and discussions about the oe-core layer [-- 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 --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack 2015-04-14 13:28 ` Burton, Ross @ 2015-04-14 15:38 ` Christopher Larson 2015-04-15 15:05 ` Burton, Ross 0 siblings, 1 reply; 30+ messages in thread From: Christopher Larson @ 2015-04-14 15:38 UTC (permalink / raw) To: Burton, Ross Cc: Otavio Salvador, Patches and discussions about the oe-core layer [-- 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 --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack 2015-04-14 15:38 ` Christopher Larson @ 2015-04-15 15:05 ` Burton, Ross 0 siblings, 0 replies; 30+ messages in thread From: Burton, Ross @ 2015-04-15 15:05 UTC (permalink / raw) To: Christopher Larson Cc: Otavio Salvador, Patches and discussions about the oe-core layer [-- 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 --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack 2015-04-06 14:32 ` Iorga, Cristian 2015-04-06 21:21 ` Peter A. Bigot @ 2015-04-07 10:55 ` Martin Jansa 2015-04-07 11:21 ` Iorga, Cristian 1 sibling, 1 reply; 30+ messages in thread From: Martin Jansa @ 2015-04-07 10:55 UTC (permalink / raw) To: Iorga, Cristian Cc: Otavio Salvador, Patches and discussions about the oe-core layer [-- 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 --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack 2015-04-07 10:55 ` Martin Jansa @ 2015-04-07 11:21 ` Iorga, Cristian 2015-04-07 12:35 ` Martin Jansa 0 siblings, 1 reply; 30+ messages in thread From: Iorga, Cristian @ 2015-04-07 11:21 UTC (permalink / raw) To: Martin Jansa Cc: Otavio Salvador, Patches and discussions about the oe-core layer 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack 2015-04-07 11:21 ` Iorga, Cristian @ 2015-04-07 12:35 ` Martin Jansa 0 siblings, 0 replies; 30+ messages in thread From: Martin Jansa @ 2015-04-07 12:35 UTC (permalink / raw) To: Iorga, Cristian Cc: Otavio Salvador, Patches and discussions about the oe-core layer [-- 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 --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack 2015-04-03 14:13 ` [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack Cristian Iorga 2015-04-05 21:40 ` Burton, Ross @ 2015-04-07 10:27 ` Tanu Kaskinen 2015-04-07 11:23 ` Iorga, Cristian 1 sibling, 1 reply; 30+ messages in thread From: Tanu Kaskinen @ 2015-04-07 10:27 UTC (permalink / raw) To: Cristian Iorga; +Cc: openembedded-core 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack 2015-04-07 10:27 ` Tanu Kaskinen @ 2015-04-07 11:23 ` Iorga, Cristian 2015-04-07 11:41 ` Tanu Kaskinen 0 siblings, 1 reply; 30+ messages in thread From: Iorga, Cristian @ 2015-04-07 11:23 UTC (permalink / raw) To: Tanu Kaskinen; +Cc: openembedded-core 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack 2015-04-07 11:23 ` Iorga, Cristian @ 2015-04-07 11:41 ` Tanu Kaskinen 2015-04-07 11:51 ` Iorga, Cristian 0 siblings, 1 reply; 30+ messages in thread From: Tanu Kaskinen @ 2015-04-07 11:41 UTC (permalink / raw) To: Iorga, Cristian; +Cc: openembedded-core 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack 2015-04-07 11:41 ` Tanu Kaskinen @ 2015-04-07 11:51 ` Iorga, Cristian 2015-04-07 12:36 ` Tanu Kaskinen 0 siblings, 1 reply; 30+ messages in thread From: Iorga, Cristian @ 2015-04-07 11:51 UTC (permalink / raw) To: Tanu Kaskinen; +Cc: openembedded-core 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack 2015-04-07 11:51 ` Iorga, Cristian @ 2015-04-07 12:36 ` Tanu Kaskinen 2015-04-07 12:44 ` Martin Jansa 0 siblings, 1 reply; 30+ messages in thread From: Tanu Kaskinen @ 2015-04-07 12:36 UTC (permalink / raw) To: Iorga, Cristian; +Cc: openembedded-core (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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack 2015-04-07 12:36 ` Tanu Kaskinen @ 2015-04-07 12:44 ` Martin Jansa 2015-04-07 12:46 ` Tanu Kaskinen 0 siblings, 1 reply; 30+ messages in thread From: Martin Jansa @ 2015-04-07 12:44 UTC (permalink / raw) To: Tanu Kaskinen; +Cc: openembedded-core [-- 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 --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack 2015-04-07 12:44 ` Martin Jansa @ 2015-04-07 12:46 ` Tanu Kaskinen 2015-04-07 13:02 ` Martin Jansa 0 siblings, 1 reply; 30+ messages in thread From: Tanu Kaskinen @ 2015-04-07 12:46 UTC (permalink / raw) To: Martin Jansa; +Cc: openembedded-core 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack 2015-04-07 12:46 ` Tanu Kaskinen @ 2015-04-07 13:02 ` Martin Jansa 2015-04-07 20:16 ` Tanu Kaskinen 0 siblings, 1 reply; 30+ messages in thread From: Martin Jansa @ 2015-04-07 13:02 UTC (permalink / raw) To: Tanu Kaskinen; +Cc: openembedded-core [-- 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 --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack 2015-04-07 13:02 ` Martin Jansa @ 2015-04-07 20:16 ` Tanu Kaskinen 0 siblings, 0 replies; 30+ messages in thread From: Tanu Kaskinen @ 2015-04-07 20:16 UTC (permalink / raw) To: Martin Jansa; +Cc: openembedded-core 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 ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2015-04-15 15:05 UTC | newest] Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-04-03 14:13 [PATCH 0/5] Switch to BlueZ 5.x as default Bluetooth stack Cristian Iorga 2015-04-03 14:13 ` [PATCH 1/5] bluez5: upgrade to 5.29 Cristian Iorga 2015-04-03 19:01 ` Jack Mitchell 2015-04-03 14:13 ` [PATCH 2/5] bluez: remove recipes collection Cristian Iorga 2015-04-03 14:13 ` [PATCH 3/5] maintainers.inc: remove info related to bluez4 Cristian Iorga 2015-04-03 14:13 ` [PATCH 4/5] upstream_tracking.inc: bluez4 removed from oe-core Cristian Iorga 2015-04-03 14:13 ` [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack Cristian Iorga 2015-04-05 21:40 ` Burton, Ross 2015-04-06 7:31 ` Iorga, Cristian 2015-04-06 12:57 ` Peter A. Bigot 2015-04-06 13:18 ` Otavio Salvador 2015-04-06 14:32 ` Iorga, Cristian 2015-04-06 21:21 ` Peter A. Bigot 2015-04-06 21:39 ` Christopher Larson 2015-04-06 23:41 ` Peter A. Bigot 2015-04-14 13:28 ` Burton, Ross 2015-04-14 15:38 ` Christopher Larson 2015-04-15 15:05 ` Burton, Ross 2015-04-07 10:55 ` Martin Jansa 2015-04-07 11:21 ` Iorga, Cristian 2015-04-07 12:35 ` Martin Jansa 2015-04-07 10:27 ` Tanu Kaskinen 2015-04-07 11:23 ` Iorga, Cristian 2015-04-07 11:41 ` Tanu Kaskinen 2015-04-07 11:51 ` Iorga, Cristian 2015-04-07 12:36 ` Tanu Kaskinen 2015-04-07 12:44 ` Martin Jansa 2015-04-07 12:46 ` Tanu Kaskinen 2015-04-07 13:02 ` Martin Jansa 2015-04-07 20:16 ` Tanu Kaskinen
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.