All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/2] BlueZ 5.3 new package
@ 2013-03-11 13:56 Cristian Iorga
  2013-03-11 13:56 ` [PATCH 1/2] libical: add recipe back in oe-core Cristian Iorga
                   ` (2 more replies)
  0 siblings, 3 replies; 15+ messages in thread
From: Cristian Iorga @ 2013-03-11 13:56 UTC (permalink / raw)
  To: openembedded-core

- BlueZ 5 v5.3 experimental new package;
- bluez5 package does not replace bluez4 package,
  as a lot of components that interact with bluez
  are not prepared to work correctly with bluez5;
- libical is added back, as it is a requirement for
  bluez OBEX feature.

Cristian Iorga (2):
  libical: add recipe back in oe-core
  bluez5: new package for v5.3

 .../bluez5/bluez5-5.3/bluetooth.conf               |   16 ++++++
 .../bluez5/bluez5-5.3/fix-udev-paths.patch         |   35 +++++++++++++
 meta/recipes-connectivity/bluez5/bluez5.inc        |   45 +++++++++++++++++
 meta/recipes-connectivity/bluez5/bluez5_5.3.bb     |   35 +++++++++++++
 .../libical/files/pthread-fix.patch                |   52 ++++++++++++++++++++
 meta/recipes-support/libical/libical_0.48.bb       |   17 +++++++
 6 files changed, 200 insertions(+)
 create mode 100644 meta/recipes-connectivity/bluez5/bluez5-5.3/bluetooth.conf
 create mode 100644 meta/recipes-connectivity/bluez5/bluez5-5.3/fix-udev-paths.patch
 create mode 100644 meta/recipes-connectivity/bluez5/bluez5.inc
 create mode 100644 meta/recipes-connectivity/bluez5/bluez5_5.3.bb
 create mode 100644 meta/recipes-support/libical/files/pthread-fix.patch
 create mode 100644 meta/recipes-support/libical/libical_0.48.bb

-- 
1.7.10.4




^ permalink raw reply	[flat|nested] 15+ messages in thread

* [PATCH 1/2] libical: add recipe back in oe-core
  2013-03-11 13:56 [PATCH 0/2] BlueZ 5.3 new package Cristian Iorga
@ 2013-03-11 13:56 ` Cristian Iorga
  2013-03-11 13:56 ` [PATCH 2/2] bluez5: new package for v5.3 Cristian Iorga
  2013-03-11 14:06 ` [PATCH 0/2] BlueZ 5.3 new package Iorga, Cristian
  2 siblings, 0 replies; 15+ messages in thread
From: Cristian Iorga @ 2013-03-11 13:56 UTC (permalink / raw)
  To: openembedded-core

version: 0.48.
reason: libical is needed by bluez.

Signed-off-by: Cristian Iorga <cristian.iorga@intel.com>
---
 .../libical/files/pthread-fix.patch                |   52 ++++++++++++++++++++
 meta/recipes-support/libical/libical_0.48.bb       |   17 +++++++
 2 files changed, 69 insertions(+)
 create mode 100644 meta/recipes-support/libical/files/pthread-fix.patch
 create mode 100644 meta/recipes-support/libical/libical_0.48.bb

diff --git a/meta/recipes-support/libical/files/pthread-fix.patch b/meta/recipes-support/libical/files/pthread-fix.patch
new file mode 100644
index 0000000..877b808
--- /dev/null
+++ b/meta/recipes-support/libical/files/pthread-fix.patch
@@ -0,0 +1,52 @@
+New added pthread feature leads to some deadlock with some unlock code missing.
+This patch fix it.
+
+Signed-off-by: Zhai Edwin <edwin.zhai@intel.com>
+
+Upstream-Status: Pending
+
+Index: libical-0.47/src/libical/icaltimezone.c
+===================================================================
+--- libical-0.47.orig/src/libical/icaltimezone.c	2011-12-16 13:42:25.000000000 +0800
++++ libical-0.47/src/libical/icaltimezone.c	2011-12-16 14:16:25.000000000 +0800
+@@ -1773,7 +1773,7 @@
+     filename = (char*) malloc (filename_len);
+     if (!filename) {
+ 	icalerror_set_errno(ICAL_NEWFAILED_ERROR);
+-	return;
++	goto out;
+     }
+ 
+     snprintf (filename, filename_len, "%s/%s.ics", get_zone_directory(),
+@@ -1783,7 +1783,7 @@
+     free (filename);
+     if (!fp) {
+ 	icalerror_set_errno(ICAL_FILE_ERROR);
+-	return;
++	goto out;
+     }
+ 
+ 	
+@@ -1807,7 +1807,7 @@
+ 
+     if (!subcomp) {
+ 	icalerror_set_errno(ICAL_PARSE_ERROR);
+-	return;
++	goto out;
+     }
+ 
+     icaltimezone_get_vtimezone_properties (zone, subcomp);
+@@ -1817,10 +1817,12 @@
+     icalcomponent_free(comp);
+     }
+ #endif 
+-#ifdef HAVE_PTHREAD
++
+  out:
++#ifdef HAVE_PTHREAD
+     pthread_mutex_unlock(&builtin_mutex);
+ #endif
++    return;
+ }
+ 
+ 
diff --git a/meta/recipes-support/libical/libical_0.48.bb b/meta/recipes-support/libical/libical_0.48.bb
new file mode 100644
index 0000000..80f629c
--- /dev/null
+++ b/meta/recipes-support/libical/libical_0.48.bb
@@ -0,0 +1,17 @@
+DESCRIPTION = "iCal and scheduling (RFC 2445, 2446, 2447) library"
+HOMEPAGE = "http://sourceforge.net/projects/freeassociation/"
+BUGTRACKER = "http://sourceforge.net/tracker/?group_id=16077&atid=116077"
+LICENSE = "LGPLv2.1 | MPL-1"
+LIC_FILES_CHKSUM = "file://COPYING;md5=d4fc58309d8ed46587ac63bb449d82f8 \
+                    file://LICENSE;md5=d1a0891cd3e582b3e2ec8fe63badbbb6"
+SECTION = "libs"
+
+PR = "r0"
+
+SRC_URI = "${SOURCEFORGE_MIRROR}/project/freeassociation/${BPN}/${P}/${BPN}-${PV}.tar.gz\
+           file://pthread-fix.patch"
+
+SRC_URI[md5sum] = "e549f434d5fbf9cd156c60ed4943618f"
+SRC_URI[sha256sum] = "2ae78b0757f0dd13431acf42a9a8d038339fd4767fd5134e650bf60ee0b4dff0"
+
+inherit autotools
-- 
1.7.10.4




^ permalink raw reply related	[flat|nested] 15+ messages in thread

* [PATCH 2/2] bluez5: new package for v5.3
  2013-03-11 13:56 [PATCH 0/2] BlueZ 5.3 new package Cristian Iorga
  2013-03-11 13:56 ` [PATCH 1/2] libical: add recipe back in oe-core Cristian Iorga
@ 2013-03-11 13:56 ` Cristian Iorga
  2013-03-12  7:00   ` Martin Jansa
  2013-03-11 14:06 ` [PATCH 0/2] BlueZ 5.3 new package Iorga, Cristian
  2 siblings, 1 reply; 15+ messages in thread
From: Cristian Iorga @ 2013-03-11 13:56 UTC (permalink / raw)
  To: openembedded-core

- bluez5 does not replace bluez4
- bluez5 is integrated with systemd

Signed-off-by: Cristian Iorga <cristian.iorga@intel.com>
---
 .../bluez5/bluez5-5.3/bluetooth.conf               |   16 +++++++
 .../bluez5/bluez5-5.3/fix-udev-paths.patch         |   35 +++++++++++++++
 meta/recipes-connectivity/bluez5/bluez5.inc        |   45 ++++++++++++++++++++
 meta/recipes-connectivity/bluez5/bluez5_5.3.bb     |   35 +++++++++++++++
 4 files changed, 131 insertions(+)
 create mode 100644 meta/recipes-connectivity/bluez5/bluez5-5.3/bluetooth.conf
 create mode 100644 meta/recipes-connectivity/bluez5/bluez5-5.3/fix-udev-paths.patch
 create mode 100644 meta/recipes-connectivity/bluez5/bluez5.inc
 create mode 100644 meta/recipes-connectivity/bluez5/bluez5_5.3.bb

diff --git a/meta/recipes-connectivity/bluez5/bluez5-5.3/bluetooth.conf b/meta/recipes-connectivity/bluez5/bluez5-5.3/bluetooth.conf
new file mode 100644
index 0000000..ca5e9e4
--- /dev/null
+++ b/meta/recipes-connectivity/bluez5/bluez5-5.3/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-5.3/fix-udev-paths.patch b/meta/recipes-connectivity/bluez5/bluez5-5.3/fix-udev-paths.patch
new file mode 100644
index 0000000..37362f5
--- /dev/null
+++ b/meta/recipes-connectivity/bluez5/bluez5-5.3/fix-udev-paths.patch
@@ -0,0 +1,35 @@
+Add udevdir/udevrulesdir options
+
+Upstream-Status: Inappropriate [configuration]
+Signed-off-by: Constantin Musca <constantinx.musca@intel.com>
+Signed-off-by: Cristian Iorga <cristian.iorga@intel.com>
+
+Index: bluez-5.0/Makefile.am
+===================================================================
+--- bluez-5.0.orig/Makefile.am	2012-12-24 19:46:54.000000000 +0200
++++ bluez-5.0/Makefile.am	2013-01-30 14:33:15.760615474 +0200
+@@ -175,7 +175,7 @@
+ include Makefile.obexd
+ 
+ if HID2HCI
+-rulesdir = @UDEV_DIR@/rules.d
++rulesdir = @UDEV_RULES_DIR@
+ 
+ rules_DATA = tools/97-hid2hci.rules
+ 
+Index: bluez-5.0/configure.ac
+===================================================================
+--- bluez-5.0.orig/configure.ac	2012-12-24 19:46:54.000000000 +0200
++++ bluez-5.0/configure.ac	2013-01-30 14:34:59.068613895 +0200
+@@ -160,6 +160,11 @@
+ 	AC_SUBST(UDEV_DIR, [${path_udevdir}])
+ fi
+ 
++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])
++
+ AM_CONDITIONAL(HID2HCI, test "${enable_tools}" != "no" &&
+ 		test "${enable_udev}" != "no" && test "${enable_usb}" != "no")
+ 
diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc b/meta/recipes-connectivity/bluez5/bluez5.inc
new file mode 100644
index 0000000..db9c766
--- /dev/null
+++ b/meta/recipes-connectivity/bluez5/bluez5.inc
@@ -0,0 +1,45 @@
+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"
+
+PACKAGECONFIG ??= "\
+    ${@base_contains('DISTRO_FEATURES', 'alsa', 'alsa', '', d)}\
+    ${@base_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 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 \
+  --with-udevdir=${base_libdir}/udev \
+  --with-udevrulesdir=${nonarch_base_libdir}/udev/rules.d \
+  ${@base_contains('DISTRO_FEATURES', 'systemd', '--with-systemdunitdir=${systemd_unitdir}/system/', '--disable-systemd', d)} \
+"
+
+SYSTEMD_SERVICE_${PN} = "bluetooth.service"
diff --git a/meta/recipes-connectivity/bluez5/bluez5_5.3.bb b/meta/recipes-connectivity/bluez5/bluez5_5.3.bb
new file mode 100644
index 0000000..311562f
--- /dev/null
+++ b/meta/recipes-connectivity/bluez5/bluez5_5.3.bb
@@ -0,0 +1,35 @@
+require bluez5.inc
+
+SRC_URI += "file://bluetooth.conf \
+            file://fix-udev-paths.patch"
+
+SRC_URI[md5sum] = "44de20f6422bf90a01b8df48e7dfe4ed"
+SRC_URI[sha256sum] = "828e2cd1109835c2fc1d731fb7fd7b46951044e451cc8556a37e1312d8c8c9a6"
+
+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 \
+  ${base_libdir}/udev/.debug \
+  "
-- 
1.7.10.4




^ permalink raw reply related	[flat|nested] 15+ messages in thread

* Re: [PATCH 0/2] BlueZ 5.3 new package
  2013-03-11 13:56 [PATCH 0/2] BlueZ 5.3 new package Cristian Iorga
  2013-03-11 13:56 ` [PATCH 1/2] libical: add recipe back in oe-core Cristian Iorga
  2013-03-11 13:56 ` [PATCH 2/2] bluez5: new package for v5.3 Cristian Iorga
@ 2013-03-11 14:06 ` Iorga, Cristian
  2 siblings, 0 replies; 15+ messages in thread
From: Iorga, Cristian @ 2013-03-11 14:06 UTC (permalink / raw)
  To: Iorga, Cristian, openembedded-core; +Cc: yocto

Hello all,

This is an EXPERIMENTAL bluez5 new package.
This will not replace bluez4 and it is not an upgrade path from bluez4.

Given the fact that not a lot of components has been updated to work with bluez5, this package is largely untested.
It has been provided in the hope that for YP 1.5 release, the entire Bluetooth stack and related/dependent components will get updated.

Most probably bugs related to this package and/or related/dependent components will be fixed in 1.5 release, not in 1.4 timeframe.

The scope with this PU is to provide developers the needed tools/technologies in order to upgrade software to BlueZ5 BT stack.
This stack has support for BT4.0 with the appropriate Linux kernel.

Feedback for this upgrade is much appreciated.

Regards,
Cristian


Cristian Iorga
Linux Software Engineer
Open Source Technology Center
Intel


-----Original Message-----
From: Iorga, Cristian 
Sent: Monday, March 11, 2013 3:57 PM
To: openembedded-core@lists.openembedded.org
Cc: Iorga, Cristian
Subject: [PATCH 0/2] BlueZ 5.3 new package

- BlueZ 5 v5.3 experimental new package;
- bluez5 package does not replace bluez4 package,
  as a lot of components that interact with bluez
  are not prepared to work correctly with bluez5;
- libical is added back, as it is a requirement for
  bluez OBEX feature.

Cristian Iorga (2):
  libical: add recipe back in oe-core
  bluez5: new package for v5.3

 .../bluez5/bluez5-5.3/bluetooth.conf               |   16 ++++++
 .../bluez5/bluez5-5.3/fix-udev-paths.patch         |   35 +++++++++++++
 meta/recipes-connectivity/bluez5/bluez5.inc        |   45 +++++++++++++++++
 meta/recipes-connectivity/bluez5/bluez5_5.3.bb     |   35 +++++++++++++
 .../libical/files/pthread-fix.patch                |   52 ++++++++++++++++++++
 meta/recipes-support/libical/libical_0.48.bb       |   17 +++++++
 6 files changed, 200 insertions(+)
 create mode 100644 meta/recipes-connectivity/bluez5/bluez5-5.3/bluetooth.conf
 create mode 100644 meta/recipes-connectivity/bluez5/bluez5-5.3/fix-udev-paths.patch
 create mode 100644 meta/recipes-connectivity/bluez5/bluez5.inc
 create mode 100644 meta/recipes-connectivity/bluez5/bluez5_5.3.bb
 create mode 100644 meta/recipes-support/libical/files/pthread-fix.patch
 create mode 100644 meta/recipes-support/libical/libical_0.48.bb

-- 
1.7.10.4



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 2/2] bluez5: new package for v5.3
  2013-03-11 13:56 ` [PATCH 2/2] bluez5: new package for v5.3 Cristian Iorga
@ 2013-03-12  7:00   ` Martin Jansa
  2013-03-12  7:19     ` Iorga, Cristian
  2013-03-12  9:24     ` Burton, Ross
  0 siblings, 2 replies; 15+ messages in thread
From: Martin Jansa @ 2013-03-12  7:00 UTC (permalink / raw)
  To: Cristian Iorga; +Cc: openembedded-core

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

On Mon, Mar 11, 2013 at 03:56:49PM +0200, Cristian Iorga wrote:
> - bluez5 does not replace bluez4

And is that correct? I guess some files on target will conflict between
bluez4 and bluez5, so how is user/distro supposed to upgrade from 4 to
5?

Why not move to bluez PN and set R* variables to do the switch on
target?

> - bluez5 is integrated with systemd
> 
> Signed-off-by: Cristian Iorga <cristian.iorga@intel.com>
> ---
>  .../bluez5/bluez5-5.3/bluetooth.conf               |   16 +++++++
>  .../bluez5/bluez5-5.3/fix-udev-paths.patch         |   35 +++++++++++++++
>  meta/recipes-connectivity/bluez5/bluez5.inc        |   45 ++++++++++++++++++++
>  meta/recipes-connectivity/bluez5/bluez5_5.3.bb     |   35 +++++++++++++++
>  4 files changed, 131 insertions(+)
>  create mode 100644 meta/recipes-connectivity/bluez5/bluez5-5.3/bluetooth.conf
>  create mode 100644 meta/recipes-connectivity/bluez5/bluez5-5.3/fix-udev-paths.patch
>  create mode 100644 meta/recipes-connectivity/bluez5/bluez5.inc
>  create mode 100644 meta/recipes-connectivity/bluez5/bluez5_5.3.bb
> 
> diff --git a/meta/recipes-connectivity/bluez5/bluez5-5.3/bluetooth.conf b/meta/recipes-connectivity/bluez5/bluez5-5.3/bluetooth.conf
> new file mode 100644
> index 0000000..ca5e9e4
> --- /dev/null
> +++ b/meta/recipes-connectivity/bluez5/bluez5-5.3/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-5.3/fix-udev-paths.patch b/meta/recipes-connectivity/bluez5/bluez5-5.3/fix-udev-paths.patch
> new file mode 100644
> index 0000000..37362f5
> --- /dev/null
> +++ b/meta/recipes-connectivity/bluez5/bluez5-5.3/fix-udev-paths.patch
> @@ -0,0 +1,35 @@
> +Add udevdir/udevrulesdir options
> +
> +Upstream-Status: Inappropriate [configuration]
> +Signed-off-by: Constantin Musca <constantinx.musca@intel.com>
> +Signed-off-by: Cristian Iorga <cristian.iorga@intel.com>
> +
> +Index: bluez-5.0/Makefile.am
> +===================================================================
> +--- bluez-5.0.orig/Makefile.am	2012-12-24 19:46:54.000000000 +0200
> ++++ bluez-5.0/Makefile.am	2013-01-30 14:33:15.760615474 +0200
> +@@ -175,7 +175,7 @@
> + include Makefile.obexd
> + 
> + if HID2HCI
> +-rulesdir = @UDEV_DIR@/rules.d
> ++rulesdir = @UDEV_RULES_DIR@
> + 
> + rules_DATA = tools/97-hid2hci.rules
> + 
> +Index: bluez-5.0/configure.ac
> +===================================================================
> +--- bluez-5.0.orig/configure.ac	2012-12-24 19:46:54.000000000 +0200
> ++++ bluez-5.0/configure.ac	2013-01-30 14:34:59.068613895 +0200
> +@@ -160,6 +160,11 @@
> + 	AC_SUBST(UDEV_DIR, [${path_udevdir}])
> + fi
> + 
> ++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])
> ++
> + AM_CONDITIONAL(HID2HCI, test "${enable_tools}" != "no" &&
> + 		test "${enable_udev}" != "no" && test "${enable_usb}" != "no")
> + 
> diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc b/meta/recipes-connectivity/bluez5/bluez5.inc
> new file mode 100644
> index 0000000..db9c766
> --- /dev/null
> +++ b/meta/recipes-connectivity/bluez5/bluez5.inc
> @@ -0,0 +1,45 @@
> +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"
> +
> +PACKAGECONFIG ??= "\
> +    ${@base_contains('DISTRO_FEATURES', 'alsa', 'alsa', '', d)}\
> +    ${@base_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 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 \
> +  --with-udevdir=${base_libdir}/udev \
> +  --with-udevrulesdir=${nonarch_base_libdir}/udev/rules.d \
> +  ${@base_contains('DISTRO_FEATURES', 'systemd', '--with-systemdunitdir=${systemd_unitdir}/system/', '--disable-systemd', d)} \
> +"
> +
> +SYSTEMD_SERVICE_${PN} = "bluetooth.service"
> diff --git a/meta/recipes-connectivity/bluez5/bluez5_5.3.bb b/meta/recipes-connectivity/bluez5/bluez5_5.3.bb
> new file mode 100644
> index 0000000..311562f
> --- /dev/null
> +++ b/meta/recipes-connectivity/bluez5/bluez5_5.3.bb
> @@ -0,0 +1,35 @@
> +require bluez5.inc
> +
> +SRC_URI += "file://bluetooth.conf \
> +            file://fix-udev-paths.patch"
> +
> +SRC_URI[md5sum] = "44de20f6422bf90a01b8df48e7dfe4ed"
> +SRC_URI[sha256sum] = "828e2cd1109835c2fc1d731fb7fd7b46951044e451cc8556a37e1312d8c8c9a6"
> +
> +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 \
> +  ${base_libdir}/udev/.debug \
> +  "
> -- 
> 1.7.10.4
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

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

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 2/2] bluez5: new package for v5.3
  2013-03-12  7:00   ` Martin Jansa
@ 2013-03-12  7:19     ` Iorga, Cristian
  2013-03-12  8:45       ` Martin Jansa
  2013-03-12  9:24     ` Burton, Ross
  1 sibling, 1 reply; 15+ messages in thread
From: Iorga, Cristian @ 2013-03-12  7:19 UTC (permalink / raw)
  To: Martin Jansa; +Cc: openembedded-core

Hi Martin,

By bluez5 does not replace bluez4, I meant: "in Yocto Project case".

At the moment, bluez5 is not a replacement for bluez4.
And it is not also an upgrade path at the moment.

An user having bluez5 is supposed to not include in the target bluez4.
That's why I said the recipe/package is experimental. It does not help the user make the switch.

Quote: " Why not move to bluez PN and set R* variables to do the switch on target?"

Can you please provide more details? I do not understand your proposal, sorry.

Regards,
Cristian

P.S.: A "Hi Cristian, " in the beginning would be nice, also. Thanks.

-----Original Message-----
From: Martin Jansa [mailto:martin.jansa@gmail.com] 
Sent: Tuesday, March 12, 2013 9:01 AM
To: Iorga, Cristian
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH 2/2] bluez5: new package for v5.3

On Mon, Mar 11, 2013 at 03:56:49PM +0200, Cristian Iorga wrote:
> - bluez5 does not replace bluez4

And is that correct? I guess some files on target will conflict between
bluez4 and bluez5, so how is user/distro supposed to upgrade from 4 to 5?

Why not move to bluez PN and set R* variables to do the switch on target?

> - bluez5 is integrated with systemd
> 
> Signed-off-by: Cristian Iorga <cristian.iorga@intel.com>
> ---
>  .../bluez5/bluez5-5.3/bluetooth.conf               |   16 +++++++
>  .../bluez5/bluez5-5.3/fix-udev-paths.patch         |   35 +++++++++++++++
>  meta/recipes-connectivity/bluez5/bluez5.inc        |   45 ++++++++++++++++++++
>  meta/recipes-connectivity/bluez5/bluez5_5.3.bb     |   35 +++++++++++++++
>  4 files changed, 131 insertions(+)
>  create mode 100644 
> meta/recipes-connectivity/bluez5/bluez5-5.3/bluetooth.conf
>  create mode 100644 
> meta/recipes-connectivity/bluez5/bluez5-5.3/fix-udev-paths.patch
>  create mode 100644 meta/recipes-connectivity/bluez5/bluez5.inc
>  create mode 100644 meta/recipes-connectivity/bluez5/bluez5_5.3.bb
> 
> diff --git 
> a/meta/recipes-connectivity/bluez5/bluez5-5.3/bluetooth.conf 
> b/meta/recipes-connectivity/bluez5/bluez5-5.3/bluetooth.conf
> new file mode 100644
> index 0000000..ca5e9e4
> --- /dev/null
> +++ b/meta/recipes-connectivity/bluez5/bluez5-5.3/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-5.3/fix-udev-paths.patch 
> b/meta/recipes-connectivity/bluez5/bluez5-5.3/fix-udev-paths.patch
> new file mode 100644
> index 0000000..37362f5
> --- /dev/null
> +++ b/meta/recipes-connectivity/bluez5/bluez5-5.3/fix-udev-paths.patch
> @@ -0,0 +1,35 @@
> +Add udevdir/udevrulesdir options
> +
> +Upstream-Status: Inappropriate [configuration]
> +Signed-off-by: Constantin Musca <constantinx.musca@intel.com>
> +Signed-off-by: Cristian Iorga <cristian.iorga@intel.com>
> +
> +Index: bluez-5.0/Makefile.am
> +===================================================================
> +--- bluez-5.0.orig/Makefile.am	2012-12-24 19:46:54.000000000 +0200
> ++++ bluez-5.0/Makefile.am	2013-01-30 14:33:15.760615474 +0200
> +@@ -175,7 +175,7 @@
> + include Makefile.obexd
> + 
> + if HID2HCI
> +-rulesdir = @UDEV_DIR@/rules.d
> ++rulesdir = @UDEV_RULES_DIR@
> + 
> + rules_DATA = tools/97-hid2hci.rules
> + 
> +Index: bluez-5.0/configure.ac
> +===================================================================
> +--- bluez-5.0.orig/configure.ac	2012-12-24 19:46:54.000000000 +0200
> ++++ bluez-5.0/configure.ac	2013-01-30 14:34:59.068613895 +0200
> +@@ -160,6 +160,11 @@
> + 	AC_SUBST(UDEV_DIR, [${path_udevdir}])  fi
> + 
> ++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])
> ++
> + AM_CONDITIONAL(HID2HCI, test "${enable_tools}" != "no" &&
> + 		test "${enable_udev}" != "no" && test "${enable_usb}" != "no")
> + 
> diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc 
> b/meta/recipes-connectivity/bluez5/bluez5.inc
> new file mode 100644
> index 0000000..db9c766
> --- /dev/null
> +++ b/meta/recipes-connectivity/bluez5/bluez5.inc
> @@ -0,0 +1,45 @@
> +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"
> +
> +PACKAGECONFIG ??= "\
> +    ${@base_contains('DISTRO_FEATURES', 'alsa', 'alsa', '', d)}\
> +    ${@base_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 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 \
> +  --with-udevdir=${base_libdir}/udev \
> +  --with-udevrulesdir=${nonarch_base_libdir}/udev/rules.d \
> +  ${@base_contains('DISTRO_FEATURES', 'systemd', 
> +'--with-systemdunitdir=${systemd_unitdir}/system/', '--disable-systemd', d)} \ "
> +
> +SYSTEMD_SERVICE_${PN} = "bluetooth.service"
> diff --git a/meta/recipes-connectivity/bluez5/bluez5_5.3.bb 
> b/meta/recipes-connectivity/bluez5/bluez5_5.3.bb
> new file mode 100644
> index 0000000..311562f
> --- /dev/null
> +++ b/meta/recipes-connectivity/bluez5/bluez5_5.3.bb
> @@ -0,0 +1,35 @@
> +require bluez5.inc
> +
> +SRC_URI += "file://bluetooth.conf \
> +            file://fix-udev-paths.patch"
> +
> +SRC_URI[md5sum] = "44de20f6422bf90a01b8df48e7dfe4ed"
> +SRC_URI[sha256sum] = "828e2cd1109835c2fc1d731fb7fd7b46951044e451cc8556a37e1312d8c8c9a6"
> +
> +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 \
> +  ${base_libdir}/udev/.debug \
> +  "
> --
> 1.7.10.4
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

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



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 2/2] bluez5: new package for v5.3
  2013-03-12  7:19     ` Iorga, Cristian
@ 2013-03-12  8:45       ` Martin Jansa
  0 siblings, 0 replies; 15+ messages in thread
From: Martin Jansa @ 2013-03-12  8:45 UTC (permalink / raw)
  To: Iorga, Cristian; +Cc: openembedded-core

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

On Tue, Mar 12, 2013 at 07:19:14AM +0000, Iorga, Cristian wrote:
> Hi Martin,

Hi Cristian,

> By bluez5 does not replace bluez4, I meant: "in Yocto Project case".
> 
> At the moment, bluez5 is not a replacement for bluez4.
> And it is not also an upgrade path at the moment.
> 
> An user having bluez5 is supposed to not include in the target bluez4.
> That's why I said the recipe/package is experimental. It does not help the user make the switch.
> 
> Quote: " Why not move to bluez PN and set R* variables to do the switch on target?"
> 
> Can you please provide more details? I do not understand your proposal, sorry.

I meant that with bluez3 gone completely it would be easier for upgrade
path to rename current bluez4 to just bluez (and set
RREPLACES/RCONFLICTS/RPROVIDES combo to change it on target) and then
add bluez5 as bluez_5.3 with negative D_P (so it won't be upgraded
unless asked for it with P_V).

If bluez4/bluez5 cannot be installed at the same time on target and
shouldn't be installed in the same sysroot, then having different PN
imho makes things only more difficult.

> -----Original Message-----
> From: Martin Jansa [mailto:martin.jansa@gmail.com] 
> Sent: Tuesday, March 12, 2013 9:01 AM
> To: Iorga, Cristian
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 2/2] bluez5: new package for v5.3
> 
> On Mon, Mar 11, 2013 at 03:56:49PM +0200, Cristian Iorga wrote:
> > - bluez5 does not replace bluez4
> 
> And is that correct? I guess some files on target will conflict between
> bluez4 and bluez5, so how is user/distro supposed to upgrade from 4 to 5?
> 
> Why not move to bluez PN and set R* variables to do the switch on target?
> 
> > - bluez5 is integrated with systemd
> > 
> > Signed-off-by: Cristian Iorga <cristian.iorga@intel.com>
> > ---
> >  .../bluez5/bluez5-5.3/bluetooth.conf               |   16 +++++++
> >  .../bluez5/bluez5-5.3/fix-udev-paths.patch         |   35 +++++++++++++++
> >  meta/recipes-connectivity/bluez5/bluez5.inc        |   45 ++++++++++++++++++++
> >  meta/recipes-connectivity/bluez5/bluez5_5.3.bb     |   35 +++++++++++++++
> >  4 files changed, 131 insertions(+)
> >  create mode 100644 
> > meta/recipes-connectivity/bluez5/bluez5-5.3/bluetooth.conf
> >  create mode 100644 
> > meta/recipes-connectivity/bluez5/bluez5-5.3/fix-udev-paths.patch
> >  create mode 100644 meta/recipes-connectivity/bluez5/bluez5.inc
> >  create mode 100644 meta/recipes-connectivity/bluez5/bluez5_5.3.bb
> > 
> > diff --git 
> > a/meta/recipes-connectivity/bluez5/bluez5-5.3/bluetooth.conf 
> > b/meta/recipes-connectivity/bluez5/bluez5-5.3/bluetooth.conf
> > new file mode 100644
> > index 0000000..ca5e9e4
> > --- /dev/null
> > +++ b/meta/recipes-connectivity/bluez5/bluez5-5.3/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-5.3/fix-udev-paths.patch 
> > b/meta/recipes-connectivity/bluez5/bluez5-5.3/fix-udev-paths.patch
> > new file mode 100644
> > index 0000000..37362f5
> > --- /dev/null
> > +++ b/meta/recipes-connectivity/bluez5/bluez5-5.3/fix-udev-paths.patch
> > @@ -0,0 +1,35 @@
> > +Add udevdir/udevrulesdir options
> > +
> > +Upstream-Status: Inappropriate [configuration]
> > +Signed-off-by: Constantin Musca <constantinx.musca@intel.com>
> > +Signed-off-by: Cristian Iorga <cristian.iorga@intel.com>
> > +
> > +Index: bluez-5.0/Makefile.am
> > +===================================================================
> > +--- bluez-5.0.orig/Makefile.am	2012-12-24 19:46:54.000000000 +0200
> > ++++ bluez-5.0/Makefile.am	2013-01-30 14:33:15.760615474 +0200
> > +@@ -175,7 +175,7 @@
> > + include Makefile.obexd
> > + 
> > + if HID2HCI
> > +-rulesdir = @UDEV_DIR@/rules.d
> > ++rulesdir = @UDEV_RULES_DIR@
> > + 
> > + rules_DATA = tools/97-hid2hci.rules
> > + 
> > +Index: bluez-5.0/configure.ac
> > +===================================================================
> > +--- bluez-5.0.orig/configure.ac	2012-12-24 19:46:54.000000000 +0200
> > ++++ bluez-5.0/configure.ac	2013-01-30 14:34:59.068613895 +0200
> > +@@ -160,6 +160,11 @@
> > + 	AC_SUBST(UDEV_DIR, [${path_udevdir}])  fi
> > + 
> > ++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])
> > ++
> > + AM_CONDITIONAL(HID2HCI, test "${enable_tools}" != "no" &&
> > + 		test "${enable_udev}" != "no" && test "${enable_usb}" != "no")
> > + 
> > diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc 
> > b/meta/recipes-connectivity/bluez5/bluez5.inc
> > new file mode 100644
> > index 0000000..db9c766
> > --- /dev/null
> > +++ b/meta/recipes-connectivity/bluez5/bluez5.inc
> > @@ -0,0 +1,45 @@
> > +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"
> > +
> > +PACKAGECONFIG ??= "\
> > +    ${@base_contains('DISTRO_FEATURES', 'alsa', 'alsa', '', d)}\
> > +    ${@base_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 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 \
> > +  --with-udevdir=${base_libdir}/udev \
> > +  --with-udevrulesdir=${nonarch_base_libdir}/udev/rules.d \
> > +  ${@base_contains('DISTRO_FEATURES', 'systemd', 
> > +'--with-systemdunitdir=${systemd_unitdir}/system/', '--disable-systemd', d)} \ "
> > +
> > +SYSTEMD_SERVICE_${PN} = "bluetooth.service"
> > diff --git a/meta/recipes-connectivity/bluez5/bluez5_5.3.bb 
> > b/meta/recipes-connectivity/bluez5/bluez5_5.3.bb
> > new file mode 100644
> > index 0000000..311562f
> > --- /dev/null
> > +++ b/meta/recipes-connectivity/bluez5/bluez5_5.3.bb
> > @@ -0,0 +1,35 @@
> > +require bluez5.inc
> > +
> > +SRC_URI += "file://bluetooth.conf \
> > +            file://fix-udev-paths.patch"
> > +
> > +SRC_URI[md5sum] = "44de20f6422bf90a01b8df48e7dfe4ed"
> > +SRC_URI[sha256sum] = "828e2cd1109835c2fc1d731fb7fd7b46951044e451cc8556a37e1312d8c8c9a6"
> > +
> > +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 \
> > +  ${base_libdir}/udev/.debug \
> > +  "
> > --
> > 1.7.10.4
> > 
> > 
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/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: 205 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 2/2] bluez5: new package for v5.3
  2013-03-12  7:00   ` Martin Jansa
  2013-03-12  7:19     ` Iorga, Cristian
@ 2013-03-12  9:24     ` Burton, Ross
  2013-03-12 10:07       ` Martin Jansa
  1 sibling, 1 reply; 15+ messages in thread
From: Burton, Ross @ 2013-03-12  9:24 UTC (permalink / raw)
  To: Martin Jansa; +Cc: openembedded-core

Hi Martin,

On 12 March 2013 00:00, Martin Jansa <martin.jansa@gmail.com> wrote:
> And is that correct? I guess some files on target will conflict between
> bluez4 and bluez5, so how is user/distro supposed to upgrade from 4 to
> 5?

You can't just upgrade from bluez4 to bluez5 like you'd upgrade from
glib 2.10 to glib 2.12 - the API was totally rewritten and the reason
that we're maintaining both is because removing bluez4 would mean
removing bluetooth support is most of the integration points (connman
being the notable exception).

A distro upgrades from 4 to 5 when they've made the explicit decision
to do so, and changes all of their dependencies to reflect this.

Ross



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 2/2] bluez5: new package for v5.3
  2013-03-12  9:24     ` Burton, Ross
@ 2013-03-12 10:07       ` Martin Jansa
  2013-03-12 15:13         ` Burton, Ross
  0 siblings, 1 reply; 15+ messages in thread
From: Martin Jansa @ 2013-03-12 10:07 UTC (permalink / raw)
  To: Burton, Ross; +Cc: openembedded-core

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

On Tue, Mar 12, 2013 at 02:24:30AM -0700, Burton, Ross wrote:
> Hi Martin,

Hi Ross,

> On 12 March 2013 00:00, Martin Jansa <martin.jansa@gmail.com> wrote:
> > And is that correct? I guess some files on target will conflict between
> > bluez4 and bluez5, so how is user/distro supposed to upgrade from 4 to
> > 5?
> 
> You can't just upgrade from bluez4 to bluez5 like you'd upgrade from
> glib 2.10 to glib 2.12 - the API was totally rewritten and the reason
> that we're maintaining both is because removing bluez4 would mean
> removing bluetooth support is most of the integration points (connman
> being the notable exception).
> 
> A distro upgrades from 4 to 5 when they've made the explicit decision
> to do so, and changes all of their dependencies to reflect this.

That would work with bluez_5.3 with negative D_P too, wouldn't it?

Now they need to refine RREPLACES/RCONFLICTS/RPROVIDES combo in distro
config too when they do explicit decision to change bluez version.

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

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 2/2] bluez5: new package for v5.3
  2013-03-12 10:07       ` Martin Jansa
@ 2013-03-12 15:13         ` Burton, Ross
  2013-03-13  9:14           ` Koen Kooi
  2013-03-17  2:07           ` Burton, Ross
  0 siblings, 2 replies; 15+ messages in thread
From: Burton, Ross @ 2013-03-12 15:13 UTC (permalink / raw)
  To: Martin Jansa; +Cc: openembedded-core

On 12 March 2013 03:07, Martin Jansa <martin.jansa@gmail.com> wrote:
>> You can't just upgrade from bluez4 to bluez5 like you'd upgrade from
>> glib 2.10 to glib 2.12 - the API was totally rewritten and the reason
>> that we're maintaining both is because removing bluez4 would mean
>> removing bluetooth support is most of the integration points (connman
>> being the notable exception).
>>
>> A distro upgrades from 4 to 5 when they've made the explicit decision
>> to do so, and changes all of their dependencies to reflect this.
>
> That would work with bluez_5.3 with negative D_P too, wouldn't it?
>
> Now they need to refine RREPLACES/RCONFLICTS/RPROVIDES combo in distro
> config too when they do explicit decision to change bluez version.

Yes, so bluez4 and bluez5 should explicitly conflict each other.  This
should be be done.

Obviously both approaches are valid.  the approach of major-in-name
was taken so that packages could depend on the version that they need
for clarity.  As the linkage is over DBus there won't be any shlib
dependencies, so it would be simple to build an image which contained
bluezN but was using the bluezM APIs.

Ross



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 2/2] bluez5: new package for v5.3
  2013-03-12 15:13         ` Burton, Ross
@ 2013-03-13  9:14           ` Koen Kooi
  2013-03-13 16:20             ` Burton, Ross
  2013-03-13 19:22             ` Richard Purdie
  2013-03-17  2:07           ` Burton, Ross
  1 sibling, 2 replies; 15+ messages in thread
From: Koen Kooi @ 2013-03-13  9:14 UTC (permalink / raw)
  To: Burton, Ross; +Cc: Martin Jansa, openembedded-core


Op 12 mrt. 2013, om 16:13 heeft "Burton, Ross" <ross.burton@intel.com> het volgende geschreven:

> On 12 March 2013 03:07, Martin Jansa <martin.jansa@gmail.com> wrote:
>>> You can't just upgrade from bluez4 to bluez5 like you'd upgrade from
>>> glib 2.10 to glib 2.12 - the API was totally rewritten and the reason
>>> that we're maintaining both is because removing bluez4 would mean
>>> removing bluetooth support is most of the integration points (connman
>>> being the notable exception).
>>> 
>>> A distro upgrades from 4 to 5 when they've made the explicit decision
>>> to do so, and changes all of their dependencies to reflect this.
>> 
>> That would work with bluez_5.3 with negative D_P too, wouldn't it?
>> 
>> Now they need to refine RREPLACES/RCONFLICTS/RPROVIDES combo in distro
>> config too when they do explicit decision to change bluez version.
> 
> Yes, so bluez4 and bluez5 should explicitly conflict each other.  This
> should be be done.
> 
> Obviously both approaches are valid.  the approach of major-in-name
> was taken so that packages could depend on the version that they need
> for clarity.  As the linkage is over DBus there won't be any shlib
> dependencies, so it would be simple to build an image which contained
> bluezN but was using the bluezM APIs.

And I remember the pain and churn when bluez4 was renamed to bluez. I don't want to go through that again. 

At the risk of sounding snarky while making a real recommendation: Why not do it oe-core style and completely remove bluez 4.x at the start of the 1.5 cycle and work through the breakage?  I guess that means I volunteer to help with that :)


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 2/2] bluez5: new package for v5.3
  2013-03-13  9:14           ` Koen Kooi
@ 2013-03-13 16:20             ` Burton, Ross
  2013-03-13 16:26               ` Iorga, Cristian
  2013-03-13 19:22             ` Richard Purdie
  1 sibling, 1 reply; 15+ messages in thread
From: Burton, Ross @ 2013-03-13 16:20 UTC (permalink / raw)
  To: Koen Kooi; +Cc: Martin Jansa, openembedded-core

On 13 March 2013 02:14, Koen Kooi <koen@dominion.thruhere.net> wrote:
> At the risk of sounding snarky while making a real recommendation: Why not do it oe-core > style and completely remove bluez 4.x at the start of the 1.5 cycle and work through the
> breakage?  I guess that means I volunteer to help with that :)

Is the world going to migrate to the bluez5 API in six months?  I was
expecting to have to carry bluez4 and 5 for at least one or two
cycles.  We have a similar issue with GStreamer 0.10 and 1.0 - we
could drop 0.10 and port what ships in oe-core, but the subsequent
breakage would cause a riot.

Ross



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 2/2] bluez5: new package for v5.3
  2013-03-13 16:20             ` Burton, Ross
@ 2013-03-13 16:26               ` Iorga, Cristian
  0 siblings, 0 replies; 15+ messages in thread
From: Iorga, Cristian @ 2013-03-13 16:26 UTC (permalink / raw)
  To: Burton, Ross, Koen Kooi; +Cc: Martin Jansa, openembedded-core

Hello all,

Judging from what I have read on mailing lists, there is a good chance a lot of components will be ready to switch to bluez5 in 6 months timeframe.

Regards,
Cristian

-----Original Message-----
From: openembedded-core-bounces@lists.openembedded.org [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of Burton, Ross
Sent: Wednesday, March 13, 2013 6:20 PM
To: Koen Kooi
Cc: Martin Jansa; openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH 2/2] bluez5: new package for v5.3

On 13 March 2013 02:14, Koen Kooi <koen@dominion.thruhere.net> wrote:
> At the risk of sounding snarky while making a real recommendation: Why 
> not do it oe-core > style and completely remove bluez 4.x at the start 
> of the 1.5 cycle and work through the breakage?  I guess that means I 
> volunteer to help with that :)

Is the world going to migrate to the bluez5 API in six months?  I was expecting to have to carry bluez4 and 5 for at least one or two cycles.  We have a similar issue with GStreamer 0.10 and 1.0 - we could drop 0.10 and port what ships in oe-core, but the subsequent breakage would cause a riot.

Ross

_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 2/2] bluez5: new package for v5.3
  2013-03-13  9:14           ` Koen Kooi
  2013-03-13 16:20             ` Burton, Ross
@ 2013-03-13 19:22             ` Richard Purdie
  1 sibling, 0 replies; 15+ messages in thread
From: Richard Purdie @ 2013-03-13 19:22 UTC (permalink / raw)
  To: Koen Kooi; +Cc: openembedded-core, Martin Jansa

On Wed, 2013-03-13 at 10:14 +0100, Koen Kooi wrote:
> Op 12 mrt. 2013, om 16:13 heeft "Burton, Ross" <ross.burton@intel.com> het volgende geschreven:
> 
> > On 12 March 2013 03:07, Martin Jansa <martin.jansa@gmail.com> wrote:
> >>> You can't just upgrade from bluez4 to bluez5 like you'd upgrade from
> >>> glib 2.10 to glib 2.12 - the API was totally rewritten and the reason
> >>> that we're maintaining both is because removing bluez4 would mean
> >>> removing bluetooth support is most of the integration points (connman
> >>> being the notable exception).
> >>> 
> >>> A distro upgrades from 4 to 5 when they've made the explicit decision
> >>> to do so, and changes all of their dependencies to reflect this.
> >> 
> >> That would work with bluez_5.3 with negative D_P too, wouldn't it?
> >> 
> >> Now they need to refine RREPLACES/RCONFLICTS/RPROVIDES combo in distro
> >> config too when they do explicit decision to change bluez version.
> > 
> > Yes, so bluez4 and bluez5 should explicitly conflict each other.  This
> > should be be done.
> > 
> > Obviously both approaches are valid.  the approach of major-in-name
> > was taken so that packages could depend on the version that they need
> > for clarity.  As the linkage is over DBus there won't be any shlib
> > dependencies, so it would be simple to build an image which contained
> > bluezN but was using the bluezM APIs.
> 
> And I remember the pain and churn when bluez4 was renamed to bluez. I
> don't want to go through that again.

For reference we still have "bluez4" in OE-Core as nobody wanted the
pain from a rename...

Cheers,

Richard




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH 2/2] bluez5: new package for v5.3
  2013-03-12 15:13         ` Burton, Ross
  2013-03-13  9:14           ` Koen Kooi
@ 2013-03-17  2:07           ` Burton, Ross
  1 sibling, 0 replies; 15+ messages in thread
From: Burton, Ross @ 2013-03-17  2:07 UTC (permalink / raw)
  To: Martin Jansa; +Cc: openembedded-core

On 12 March 2013 08:13, Burton, Ross <ross.burton@intel.com> wrote:
>> Now they need to refine RREPLACES/RCONFLICTS/RPROVIDES combo in distro
>> config too when they do explicit decision to change bluez version.
>
> Yes, so bluez4 and bluez5 should explicitly conflict each other.  This
> should be be done.

Chatted with Saul and we concluded that the correct dependencies here
are RCONFLICTS and RREPLACES.  No PROVIDES as they are not
interchangeable, but without the replaces we expect that the package
manager will error out instead of removing bluez4 when the rest of the
system moves from bluez4 to bluez5.

Ross



^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2013-03-17  2:24 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-03-11 13:56 [PATCH 0/2] BlueZ 5.3 new package Cristian Iorga
2013-03-11 13:56 ` [PATCH 1/2] libical: add recipe back in oe-core Cristian Iorga
2013-03-11 13:56 ` [PATCH 2/2] bluez5: new package for v5.3 Cristian Iorga
2013-03-12  7:00   ` Martin Jansa
2013-03-12  7:19     ` Iorga, Cristian
2013-03-12  8:45       ` Martin Jansa
2013-03-12  9:24     ` Burton, Ross
2013-03-12 10:07       ` Martin Jansa
2013-03-12 15:13         ` Burton, Ross
2013-03-13  9:14           ` Koen Kooi
2013-03-13 16:20             ` Burton, Ross
2013-03-13 16:26               ` Iorga, Cristian
2013-03-13 19:22             ` Richard Purdie
2013-03-17  2:07           ` Burton, Ross
2013-03-11 14:06 ` [PATCH 0/2] BlueZ 5.3 new package Iorga, Cristian

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.