[PATCH] Bluez5: Add gatttool to new package bluez5-tools

[PATCH] Bluez5: Add gatttool to new package bluez5-tools

[Qian Lei]

Gatttool in bluez5 is not installed into system any more. But in some cases
we do need this tool to debug some thing. So I add a new package named bluez5-tools
which includes some programs we may need but not installed.

Signed-off-by: Qian Lei <qianl.fnst@cn.fujitsu.com>
---
 meta/recipes-connectivity/bluez5/bluez5.inc | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc b/meta/recipes-connectivity/bluez5/bluez5.inc
index c3dd946..6c05f07 100644
--- a/meta/recipes-connectivity/bluez5/bluez5.inc
+++ b/meta/recipes-connectivity/bluez5/bluez5.inc
@@ -42,11 +42,12 @@ do_install_append() {
 	    install -m 0644 ${S}/profiles/input/input.conf ${D}/${sysconfdir}/bluetooth/
 	fi
 	# 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 0755 ${S}/attrib/gatttool ${D}/${bindir}/
 	install -m 0644 ${WORKDIR}/bluetooth.conf ${D}/${sysconfdir}/dbus-1/system.d/
 }
 
 ALLOW_EMPTY_libasound-module-bluez = "1"
-PACKAGES =+ "libasound-module-bluez ${PN}-testtools ${PN}-obex"
+PACKAGES =+ "libasound-module-bluez ${PN}-testtools ${PN}-obex ${PN}-tools"
 
 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"
@@ -63,6 +64,8 @@ SYSTEMD_SERVICE_${PN}-obex = "obex.service"
 
 FILES_${PN}-testtools = "${libdir}/bluez/test/*"
 
+FILES_${PN}-tools = "${bindir}/gatttool"
+
 FILES_${PN}-dbg += "\
   ${libdir}/${BPN}/bluetooth/.debug \
   ${libdir}/bluetooth/plugins/.debug \
-- 
1.8.4.2

Re: [PATCH] Bluez5: Add gatttool to new package bluez5-tools

[Burton, Ross]

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

On 4 November 2014 05:04, Qian Lei <qianl.fnst@cn.fujitsu.com> wrote:

>         # 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 0755 ${S}/attrib/gatttool ${D}/${bindir}/
>         install -m 0644 ${WORKDIR}/bluetooth.conf
> ${D}/${sysconfdir}/dbus-1/system.d/
>  }
>

Because of where you put the install, it looks like installing gatttool is
related to the DBus configuration.


>  ALLOW_EMPTY_libasound-module-bluez = "1"
> -PACKAGES =+ "libasound-module-bluez ${PN}-testtools ${PN}-obex"
> +PACKAGES =+ "libasound-module-bluez ${PN}-testtools ${PN}-obex
> ${PN}-tools"
>

Two questions:
1) If we're installing gatttool, why not the other tools that are noinst
(obex-client-tool, obexctl, etc).  Patching the makefile would install all
the tools that upstream build.
2) Do these deserve a separate package, or as they're for testing should
they go into PN-testtools?

Ross

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

Re: [PATCH] Bluez5: Add gatttool to new package bluez5-tools

[Qian Lei]

On Fri, 7 Nov 2014 12:42:14 +0000
"Burton, Ross" <ross.burton@intel.com> wrote:

> On 4 November 2014 05:04, Qian Lei <qianl.fnst@cn.fujitsu.com> wrote:
> 
> >         # 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 0755 ${S}/attrib/gatttool ${D}/${bindir}/
> >         install -m 0644 ${WORKDIR}/bluetooth.conf
> > ${D}/${sysconfdir}/dbus-1/system.d/
> >  }
> >
> 
> Because of where you put the install, it looks like installing gatttool is
> related to the DBus configuration.

Hi Ross, thank you for your review.

Sorry for making you confused, the install should be put before the comment. I
just want to install gatttool to bin directory and it is nothing related to
dbus. I'll correct it in the next version.

> >  ALLOW_EMPTY_libasound-module-bluez = "1"
> > -PACKAGES =+ "libasound-module-bluez ${PN}-testtools ${PN}-obex"
> > +PACKAGES =+ "libasound-module-bluez ${PN}-testtools ${PN}-obex
> > ${PN}-tools"
> >
> 
> Two questions:
> 1) If we're installing gatttool, why not the other tools that are noinst
> (obex-client-tool, obexctl, etc).  Patching the makefile would install all
> the tools that upstream build.

Because in bluez4, gatttool was installed by default but obex-client-tool,
obexctl were not. 

> 2) Do these deserve a separate package, or as they're for testing should
> they go into PN-testtools?

gatttool is not a test tool, but a develop tool. In bluez4 it is in package
bluez4(not in bluez4-testtools). I don't think it's good to put it to any
existed package.


Qian Lei.

Re: [PATCH] Bluez5: Add gatttool to new package bluez5-tools

[Qian Lei]

> gatttool is not a test tool, but a develop tool. In bluez4 it is in package
> bluez4(not in bluez4-testtools). I don't think it's good to put it to any
> existed package.

How about put it in bluez5, just the same as bluez4? It seems make sense to
put it there.

Re: [PATCH] Bluez5: Add gatttool to new package bluez5-tools

[Peter A. Bigot]

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

On 11/07/2014 06:42 AM, Burton, Ross wrote:
>
> On 4 November 2014 05:04, Qian Lei <qianl.fnst@cn.fujitsu.com 
> <mailto:qianl.fnst@cn.fujitsu.com>> wrote:
>
>     # 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 0755 ${S}/attrib/gatttool ${D}/${bindir}/
>             install -m 0644 ${WORKDIR}/bluetooth.conf
>     ${D}/${sysconfdir}/dbus-1/system.d/
>      }
>
>
> Because of where you put the install, it looks like installing 
> gatttool is related to the DBus configuration.
>
>      ALLOW_EMPTY_libasound-module-bluez = "1"
>     -PACKAGES =+ "libasound-module-bluez ${PN}-testtools ${PN}-obex"
>     +PACKAGES =+ "libasound-module-bluez ${PN}-testtools ${PN}-obex
>     ${PN}-tools"
>
>
> Two questions:
> 1) If we're installing gatttool, why not the other tools that are 
> noinst (obex-client-tool, obexctl, etc). Patching the makefile would 
> install all the tools that upstream build.
> 2) Do these deserve a separate package, or as they're for testing 
> should they go into PN-testtools?
>

I do think the extra tools deserve an extra package, because they may or 
may not be for testing, and in any case don't get installed in a 
distinct test area as the current contents of ${PN}-testtools do.

In fact, they don't get installed at all.  If EXPERIMENTAL is enabled 
via PACKAGECONFIG (as it is in one of my WIP virtual/bluez patches) 
there are a lot of those tools, some of which have opaque names that 
don't appear related to bluetooth.  However, as I use bluez5 more of 
them are things I want available on the target.

At this time I'm inclined to add a ${PN}-noinst-tools package for them.  
I'm debating whether it's better to manually install them from the build 
area, to highlight that upstream doesn't install them, or to modify the 
Makefile to remove "noinst_" and then explicitly list each one in a 
separate FILES_${PN}-noinst-tools variable.  The latter seems a higher 
risk for unwittingly adding non-standard executables to ${PN}.

Is there any precedent for a package to have its own subdirectory off 
${bindir}?  It'd be easy enough to patch the Makefile to put them all in 
${bindir}/bluez5.

I'm sympathetic with Qian Lei and also assumed that gattool, which used 
to be installed in bluez4, might be an exception and just belongs as an 
OE addition to bluez5 rather than being put in ${PN}-noinst-tools.  But 
that's a slippery slope and new things like btgatt-client might be just 
as important to the folks who want to use GATT with bluez5.  Now I'm 
inclined to keep it separate too.

Peter

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