Patchwork [2/2] bluez5: new package for v5.3

login
register
mail settings
Submitter Cristian Iorga
Date March 11, 2013, 1:56 p.m.
Message ID <1363010209-18220-3-git-send-email-cristian.iorga@intel.com>
Download mbox | patch
Permalink /patch/45925/
State New
Headers show

Comments

Cristian Iorga - March 11, 2013, 1:56 p.m.
- 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
Martin Jansa - March 12, 2013, 7 a.m.
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
Cristian Iorga - March 12, 2013, 7:19 a.m.
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 Jansa - March 12, 2013, 8:45 a.m.
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
Ross Burton - March 12, 2013, 9:24 a.m.
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
Martin Jansa - March 12, 2013, 10:07 a.m.
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.
Ross Burton - March 12, 2013, 3:13 p.m.
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
Koen Kooi - March 13, 2013, 9:14 a.m.
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 :)
Ross Burton - March 13, 2013, 4:20 p.m.
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
Cristian Iorga - March 13, 2013, 4:26 p.m.
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
Richard Purdie - March 13, 2013, 7:22 p.m.
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
Ross Burton - March 17, 2013, 2:07 a.m.
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

Patch

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 \
+  "