[PATCH V3 0/2] BlueZ 5 experimental recipes

[PATCH V3 0/2] BlueZ 5 experimental recipes

[Cristian Iorga]

This sets of patches adds bluez5 recipes as experimental packages.
BlueZ 5.X is not an upgrade for Bluez 4.x, as such, no upgrade is
provided/possible.
The two versions of the BT stack also conflicts each other.

Observe my investigation below in order to decide if RREPLACES is needed.
Conclusion: BlueZ 5.x will be eventually an upgrade path for an already installed
embedded device. As such, RREPLACES is needed for a system-wide upgrade.

Case 1: bluez4 and bluez5: reciprocal RREPLACES and RCONFLICTS
root@qemux86:~# opkg update
Downloading http://192.168.7.1/upg-ipk/all/Packages.gz.
Inflating http://192.168.7.1/upg-ipk/all/Packages.gz.
Updated list of available packages in /var/lib/opkg/local_repo_all.
Downloading http://192.168.7.1/upg-ipk/i586/Packages.gz.
Inflating http://192.168.7.1/upg-ipk/i586/Packages.gz.
Updated list of available packages in /var/lib/opkg/local_repo_i586.
Downloading http://192.168.7.1/upg-ipk/qemux86/Packages.gz.
Inflating http://192.168.7.1/upg-ipk/qemux86/Packages.gz.
Updated list of available packages in /var/lib/opkg/local_repo_qemux86.
root@qemux86:~# opkg list-installed | grep bluez
bluez4 - 4.101-r6.0
libasound-module-bluez - 4.101-r6.0
root@qemux86:~# opkg list-upgradable | grep bluez
libasound-module-bluez - 4.101-r6.0 - 5.3-r0.0
bluez4 - 4.101-r6.0 - 5.3-r0.0
root@qemux86:~# opkg install bluez5
Multiple replacers for bluez5, using first one (bluez4).
Package bluez4 is already installed on root.
root@qemux86:~# opkg list-installed | grep bluez
bluez4 - 4.101-r6.0
libasound-module-bluez - 4.101-r6.0
root@qemux86:~# opkg upgrade
Upgrading libasound-module-bluez on root from 4.101-r6.0 to 5.3-r0.0...
Downloading http://192.168.7.1/upg-ipk/i586/libasound-module-bluez_5.3-r0.0_i586.ipk.
Removing obsolete file /usr/share/alsa/bluetooth.conf.
Removing obsolete file /usr/lib/alsa-lib/libasound_module_ctl_bluetooth.so.
Removing obsolete file /usr/lib/alsa-lib/libasound_module_pcm_bluetooth.so.
Upgrading bluez5 (5.3-r0.0) to root...
Downloading http://192.168.7.1/upg-ipk/i586/bluez5_5.3-r0.0_i586.ipk.
Installing libical (0.48-r0.0) to root...
Downloading http://192.168.7.1/upg-ipk/i586/libical_0.48-r0.0_i586.ipk.
Removing package bluez4 from root...
Configuring libical.
Configuring libasound-module-bluez.
Configuring bluez5.
root@qemux86:~# opkg list-installed | grep bluez
bluez5 - 5.3-r0.0
libasound-module-bluez - 5.3-r0.0
root@qemux86:~# 

Case 2: bluez4 and bluez5: reciprocal RCONFLICTS
root@qemux86:~# opkg list-upgradable
libasound-module-bluez - 4.101-r6.0 - 5.3-r0.0
root@qemux86:~# opkg install bluez5
Installing bluez5 (5.3-r0.0) to root...
Collected errors:
 * check_conflicts_for: The following packages conflict with bluez5:
 * check_conflicts_for: 	bluez4 * 
 * opkg_install_cmd: Cannot install package bluez5.
root@qemux86:~# opkg upgrade bluez5
Installing bluez5 (5.3-r0.0) to root...
Collected errors:
 * check_conflicts_for: The following packages conflict with bluez5:
 * check_conflicts_for: 	bluez4 * 
root@qemux86:~# opkg list-installed | grep bluez
bluez4 - 4.101-r6.0
libasound-module-bluez - 4.101-r6.0
root@qemux86:~# opkg remove bluez4
No packages removed.
Collected errors:
 * print_dependents_warning: Package bluez4 is depended upon by packages:
 * print_dependents_warning: 	ofono
 * print_dependents_warning: 	packagegroup-base-bluetooth
 * print_dependents_warning: 	connman
 * print_dependents_warning: These might cease to work if package bluez4 is removed.

 * print_dependents_warning: Force removal of this package with --force-depends.
 * print_dependents_warning: Force removal of this package and its dependents
 * print_dependents_warning: with --force-removal-of-dependent-packages.
root@qemux86:~# opkg remove --force-depends bluez4
Removing package bluez4 from root...
root@qemux86:~# opkg list-installed | grep bluez
libasound-module-bluez - 4.101-r6.0
root@qemux86:~# opkg install bluez5
Installing bluez5 (5.3-r0.0) to root...
Downloading http://192.168.7.1/upg-ipk/i586/bluez5_5.3-r0.0_i586.ipk.
Installing libical (0.48-r0.0) to root...
Downloading http://192.168.7.1/upg-ipk/i586/libical_0.48-r0.0_i586.ipk.
Configuring libical.
Configuring bluez5.
root@qemux86:~# opkg list-installed | grep bluez
bluez5 - 5.3-r0.0
libasound-module-bluez - 4.101-r6.0
root@qemux86:~# 

Cristian Iorga (2):
  bluez5: new package for v5.7
  bluez4: conflicts with/replaces bluez5

 meta/recipes-connectivity/bluez/bluez4_4.101.bb    |    3 +
 .../bluez5/bluez5-5.7/bluetooth.conf               |   16 +++++
 meta/recipes-connectivity/bluez5/bluez5.inc        |   69 ++++++++++++++++++++
 meta/recipes-connectivity/bluez5/bluez5_5.7.bb     |    5 ++
 4 files changed, 93 insertions(+)
 create mode 100644 meta/recipes-connectivity/bluez5/bluez5-5.7/bluetooth.conf
 create mode 100644 meta/recipes-connectivity/bluez5/bluez5.inc
 create mode 100644 meta/recipes-connectivity/bluez5/bluez5_5.7.bb

-- 
1.7.10.4

[PATCH V3 1/2] bluez5: new package for v5.7

[Cristian Iorga]

- bluez5 does not replace bluez4
- bluez5 is integrated with systemd
- RCONFLICTS/RREPLACES bluez4
- add readline dependency

Signed-off-by: Cristian Iorga <cristian.iorga@intel.com>
---
 .../bluez5/bluez5-5.7/bluetooth.conf               |   16 +++++
 meta/recipes-connectivity/bluez5/bluez5.inc        |   69 ++++++++++++++++++++
 meta/recipes-connectivity/bluez5/bluez5_5.7.bb     |    5 ++
 3 files changed, 90 insertions(+)
 create mode 100644 meta/recipes-connectivity/bluez5/bluez5-5.7/bluetooth.conf
 create mode 100644 meta/recipes-connectivity/bluez5/bluez5.inc
 create mode 100644 meta/recipes-connectivity/bluez5/bluez5_5.7.bb

diff --git a/meta/recipes-connectivity/bluez5/bluez5-5.7/bluetooth.conf b/meta/recipes-connectivity/bluez5/bluez5-5.7/bluetooth.conf
new file mode 100644
index 0000000..ca5e9e4
--- /dev/null
+++ b/meta/recipes-connectivity/bluez5/bluez5-5.7/bluetooth.conf
@@ -0,0 +1,16 @@
+<!-- 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/bluez5/bluez5.inc b/meta/recipes-connectivity/bluez5/bluez5.inc
new file mode 100644
index 0000000..e2c0f82
--- /dev/null
+++ b/meta/recipes-connectivity/bluez5/bluez5.inc
@@ -0,0 +1,69 @@
+SUMMARY = "Linux Bluetooth Stack Userland V5"
+DESCRIPTION = "Linux Bluetooth stack V5 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"
+DEPENDS = "udev libusb dbus-glib glib-2.0 libcheck libical readline"
+
+RCONFLICTS_${PN} = "bluez4"
+RREPLACES_${PN} = "bluez4"
+
+PACKAGECONFIG ??= "${@base_contains('DISTRO_FEATURES', 'alsa', 'alsa', '', d)}"
+PACKAGECONFIG[alsa] = "--enable-alsa,--disable-alsa,alsa-lib"
+
+SRC_URI = "\
+    ${KERNELORG_MIRROR}/linux/bluetooth/bluez-${PV}.tar.gz \
+    file://bluetooth.conf \
+"
+S = "${WORKDIR}/bluez-${PV}"
+
+inherit autotools pkgconfig systemd
+
+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 \
+  ${@base_contains('DISTRO_FEATURES', 'systemd', '--with-systemdunitdir=${systemd_unitdir}/system/', '--disable-systemd', d)} \
+"
+
+do_install_append() {
+	install -d ${D}${sysconfdir}/bluetooth/
+	install -m 0644 ${S}/profiles/audio/audio.conf ${D}/${sysconfdir}/bluetooth/
+	install -m 0644 ${S}/profiles/network/network.conf ${D}/${sysconfdir}/bluetooth/
+	install -m 0644 ${S}/profiles/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/
+}
+
+ALLOW_EMPTY_libasound-module-bluez = "1"
+PACKAGES =+ "libasound-module-bluez ${PN}-test"
+
+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}-test = "${libdir}/bluez/test/*"
+
+FILES_${PN}-dbg += "\
+  ${libdir}/${PN}/bluetooth/.debug \
+  ${libdir}/bluetooth/plugins/.debug \
+  ${libdir}/*/.debug \
+  */udev/.debug \
+  "
+
+SYSTEMD_SERVICE_${PN} = "bluetooth.service"
diff --git a/meta/recipes-connectivity/bluez5/bluez5_5.7.bb b/meta/recipes-connectivity/bluez5/bluez5_5.7.bb
new file mode 100644
index 0000000..6e2850d
--- /dev/null
+++ b/meta/recipes-connectivity/bluez5/bluez5_5.7.bb
@@ -0,0 +1,5 @@
+require bluez5.inc
+
+SRC_URI[md5sum] = "ce0ef43938e8bfc230f3f06d6ad02d7e"
+SRC_URI[sha256sum] = "902299204b7139c913765603c7054a604570aea9e9fddb30454bd1b5e5997860"
+
-- 
1.7.10.4

[PATCH V3 2/2] bluez4: conflicts with/replaces bluez5

[Cristian Iorga]

- RCONFLICTS/RREPLACES bluez5

Signed-off-by: Cristian Iorga <cristian.iorga@intel.com>
---
 meta/recipes-connectivity/bluez/bluez4_4.101.bb |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-connectivity/bluez/bluez4_4.101.bb b/meta/recipes-connectivity/bluez/bluez4_4.101.bb
index f48adfd..b91c9c3 100644
--- a/meta/recipes-connectivity/bluez/bluez4_4.101.bb
+++ b/meta/recipes-connectivity/bluez/bluez4_4.101.bb
@@ -11,6 +11,9 @@ SRC_URI += "file://bluetooth.conf \
 SRC_URI[md5sum] = "fb42cb7038c380eb0e2fa208987c96ad"
 SRC_URI[sha256sum] = "59738410ade9f0e61a13c0f77d9aaffaafe49ba9418107e4ad75fe52846f7487"
 
+RCONFLICTS_${PN} = "bluez5"
+RREPLACES_${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/
-- 
1.7.10.4

Re: [PATCH V3 0/2] BlueZ 5 experimental recipes

[Phil Blundell]

On Tue, 2013-07-16 at 17:28 +0300, Cristian Iorga wrote:
> Observe my investigation below in order to decide if RREPLACES is needed.
> Conclusion: BlueZ 5.x will be eventually an upgrade path for an already installed
> embedded device. As such, RREPLACES is needed for a system-wide upgrade.

It wasn't very obvious to me that these results make a compelling case
for bluez4 needing to RREPLACE bluez5.  Indeed, this section:

root@qemux86:~# opkg install bluez5
Multiple replacers for bluez5, using first one (bluez4).
Package bluez4 is already installed on root.
root@qemux86:~# opkg list-installed | grep bluez
bluez4 - 4.101-r6.0
libasound-module-bluez - 4.101-r6.0

... seems to illustrate (modulo the usual amount of opkg craziness) why
having it be so is not a very good thing.

p.

Re: [PATCH V3 0/2] BlueZ 5 experimental recipes

[Iorga, Cristian]

" why having it be so is not a very good thing."

Sorry, I did not understood this part.

Judging by my investigation, is RREPLACES needed or not?

/Cristian

-----Original Message-----
From: Phil Blundell [mailto:pb@pbcl.net] 
Sent: Tuesday, July 16, 2013 5:34 PM
To: Iorga, Cristian
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH V3 0/2] BlueZ 5 experimental recipes

On Tue, 2013-07-16 at 17:28 +0300, Cristian Iorga wrote:
> Observe my investigation below in order to decide if RREPLACES is needed.
> Conclusion: BlueZ 5.x will be eventually an upgrade path for an 
> already installed embedded device. As such, RREPLACES is needed for a system-wide upgrade.

It wasn't very obvious to me that these results make a compelling case for bluez4 needing to RREPLACE bluez5.  Indeed, this section:

root@qemux86:~# opkg install bluez5
Multiple replacers for bluez5, using first one (bluez4).
Package bluez4 is already installed on root.
root@qemux86:~# opkg list-installed | grep bluez
bluez4 - 4.101-r6.0
libasound-module-bluez - 4.101-r6.0

... seems to illustrate (modulo the usual amount of opkg craziness) why having it be so is not a very good thing.

p.

Re: [PATCH V3 0/2] BlueZ 5 experimental recipes

[Saul Wold]

On 07/16/2013 07:36 AM, Iorga, Cristian wrote:
> " why having it be so is not a very good thing."
>
> Sorry, I did not understood this part.
>
> Judging by my investigation, is RREPLACES needed or not?
>
I believe that RREPLACES is not needed, it could cause problems if a 
feed builds the bluez5 packages but does not want to use them, without 
the RREPLACES it requires a conscious effort on the target to get the 
update.

The upgrade case is exactly why we should not have RREPLACES.

Sau!

> /Cristian
>
> -----Original Message-----
> From: Phil Blundell [mailto:pb@pbcl.net]
> Sent: Tuesday, July 16, 2013 5:34 PM
> To: Iorga, Cristian
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH V3 0/2] BlueZ 5 experimental recipes
>
> On Tue, 2013-07-16 at 17:28 +0300, Cristian Iorga wrote:
>> Observe my investigation below in order to decide if RREPLACES is needed.
>> Conclusion: BlueZ 5.x will be eventually an upgrade path for an
>> already installed embedded device. As such, RREPLACES is needed for a system-wide upgrade.
>
> It wasn't very obvious to me that these results make a compelling case for bluez4 needing to RREPLACE bluez5.  Indeed, this section:
>
> root@qemux86:~# opkg install bluez5
> Multiple replacers for bluez5, using first one (bluez4).
> Package bluez4 is already installed on root.
> root@qemux86:~# opkg list-installed | grep bluez
> bluez4 - 4.101-r6.0
> libasound-module-bluez - 4.101-r6.0
>
> ... seems to illustrate (modulo the usual amount of opkg craziness) why having it be so is not a very good thing.
>
> p.
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>

Re: [PATCH V3 0/2] BlueZ 5 experimental recipes

[Iorga, Cristian]

This will happen only when bluez5 will be a replacement for bluez4, which is not the case now, but it will be when everything else is ready for bluez5.

-----Original Message-----
From: Saul Wold [mailto:sgw@linux.intel.com] 
Sent: Tuesday, July 16, 2013 5:48 PM
To: Iorga, Cristian
Cc: Phil Blundell; openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH V3 0/2] BlueZ 5 experimental recipes

On 07/16/2013 07:36 AM, Iorga, Cristian wrote:
> " why having it be so is not a very good thing."
>
> Sorry, I did not understood this part.
>
> Judging by my investigation, is RREPLACES needed or not?
>
I believe that RREPLACES is not needed, it could cause problems if a feed builds the bluez5 packages but does not want to use them, without the RREPLACES it requires a conscious effort on the target to get the update.

The upgrade case is exactly why we should not have RREPLACES.

Sau!

> /Cristian
>
> -----Original Message-----
> From: Phil Blundell [mailto:pb@pbcl.net]
> Sent: Tuesday, July 16, 2013 5:34 PM
> To: Iorga, Cristian
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH V3 0/2] BlueZ 5 experimental recipes
>
> On Tue, 2013-07-16 at 17:28 +0300, Cristian Iorga wrote:
>> Observe my investigation below in order to decide if RREPLACES is needed.
>> Conclusion: BlueZ 5.x will be eventually an upgrade path for an 
>> already installed embedded device. As such, RREPLACES is needed for a system-wide upgrade.
>
> It wasn't very obvious to me that these results make a compelling case for bluez4 needing to RREPLACE bluez5.  Indeed, this section:
>
> root@qemux86:~# opkg install bluez5
> Multiple replacers for bluez5, using first one (bluez4).
> Package bluez4 is already installed on root.
> root@qemux86:~# opkg list-installed | grep bluez
> bluez4 - 4.101-r6.0
> libasound-module-bluez - 4.101-r6.0
>
> ... seems to illustrate (modulo the usual amount of opkg craziness) why having it be so is not a very good thing.
>
> p.
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>

Re: [PATCH V3 0/2] BlueZ 5 experimental recipes

[Phil Blundell]

On Tue, 2013-07-16 at 14:36 +0000, Iorga, Cristian wrote:
> " why having it be so is not a very good thing."
> 
> Sorry, I did not understood this part.
> 
> Judging by my investigation, is RREPLACES needed or not?

I don't believe there is any justification for making bluez4 Replace:
bluez5.

I think you could possibly make an argument that having bluez5 Replace:
bluez4 might be a good thing, although given the way opkg behaves with
them I'm not entirely convinced.  Personally I would say that there
should be no replacing here.

p.