[PATCH 0/1] bluez5: Fix for --enable-btpclient

[PATCH 0/1] bluez5: Fix for --enable-btpclient

[Robert Yang]

The following changes since commit f963a51544a9a7b1abbaa87c95b3c0279847d697:

  kernel.fitimage.bbclass: remove ramdisk_ctype (2019-09-27 13:01:17 +0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib rbt/bluez
  http://cgit.openembedded.org/openembedded-core-contrib/log/?h=rbt/bluez

Robert Yang (1):
  bluez5: Fix for --enable-btpclient

 meta/recipes-connectivity/bluez5/bluez5.inc        |  1 +
 .../0001-tools-btpclient.c-include-signal.h.patch  | 30 ++++++++++++++++++++++
 2 files changed, 31 insertions(+)
 create mode 100644 meta/recipes-connectivity/bluez5/bluez5/0001-tools-btpclient.c-include-signal.h.patch

-- 
2.7.4

[PATCH 1/1] bluez5: Fix for --enable-btpclient

[Robert Yang]

Fixed:
PACKAGECONFIG_append_pn-bluez5 = ' btpclient'

$ bitbake bluez5
btpclient.c:2834:7: error: 'SIGINT' undeclared (first use in this function)

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
---
 meta/recipes-connectivity/bluez5/bluez5.inc        |  1 +
 .../0001-tools-btpclient.c-include-signal.h.patch  | 30 ++++++++++++++++++++++
 2 files changed, 31 insertions(+)
 create mode 100644 meta/recipes-connectivity/bluez5/bluez5/0001-tools-btpclient.c-include-signal.h.patch

diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc b/meta/recipes-connectivity/bluez5/bluez5.inc
index 6c79ed0..f2f03d0 100644
--- a/meta/recipes-connectivity/bluez5/bluez5.inc
+++ b/meta/recipes-connectivity/bluez5/bluez5.inc
@@ -58,6 +58,7 @@ SRC_URI = "\
     file://CVE-2018-10910.patch \
     file://gcc9-fixes.patch \
     file://0001-tools-Fix-build-after-y2038-changes-in-glibc.patch \
+    file://0001-tools-btpclient.c-include-signal.h.patch \
 "
 S = "${WORKDIR}/bluez-${PV}"
 
diff --git a/meta/recipes-connectivity/bluez5/bluez5/0001-tools-btpclient.c-include-signal.h.patch b/meta/recipes-connectivity/bluez5/bluez5/0001-tools-btpclient.c-include-signal.h.patch
new file mode 100644
index 0000000..6dd2e35
--- /dev/null
+++ b/meta/recipes-connectivity/bluez5/bluez5/0001-tools-btpclient.c-include-signal.h.patch
@@ -0,0 +1,30 @@
+From 0b1766514f6847c7367fce07f19a750ec74c11a6 Mon Sep 17 00:00:00 2001
+From: Robert Yang <liezhi.yang@windriver.com>
+Date: Thu, 26 Sep 2019 16:19:34 +0800
+Subject: [PATCH] tools/btpclient.c: include signal.h
+
+Fix compile failure when configure --enable-btpclient:
+btpclient.c:2834:7: error: 'SIGINT' undeclared (first use in this function)
+
+Upstream-Status: Inappropriate [Upstream already fixed]
+
+Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
+---
+ tools/btpclient.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/tools/btpclient.c b/tools/btpclient.c
+index b217df5..aece7fe 100644
+--- a/tools/btpclient.c
++++ b/tools/btpclient.c
+@@ -29,6 +29,7 @@
+ #include <stdlib.h>
+ #include <assert.h>
+ #include <getopt.h>
++#include <signal.h>
+ 
+ #include <ell/ell.h>
+ 
+-- 
+2.7.4
+
-- 
2.7.4

Re: [PATCH 1/1] bluez5: Fix for --enable-btpclient

[Ross Burton]

On 29/09/2019 04:44, Robert Yang wrote:
> +Upstream-Status: Inappropriate [Upstream already fixed]

So this is a backport then?

Ross

Re: [PATCH 1/1] bluez5: Fix for --enable-btpclient

[Robert Yang]

Hi Ross,

On 9/30/19 7:06 PM, Ross Burton wrote:
> On 29/09/2019 04:44, Robert Yang wrote:
>> +Upstream-Status: Inappropriate [Upstream already fixed]
> 
> So this is a backport then?

I just come back from the holiday, sorry for the late reply. Upstream
fixed it in a different way, I didn't backport it since the fix looks
risky for bluez5 5.50. Should we use Backport for such a case, please?

// Robert

> 
> Ross
> 

Re: [PATCH 1/1] bluez5: Fix for --enable-btpclient

[Ross Burton]

On 08/10/2019 04:12, Robert Yang wrote:
> 
> Hi Ross,
> 
> On 9/30/19 7:06 PM, Ross Burton wrote:
>> On 29/09/2019 04:44, Robert Yang wrote:
>>> +Upstream-Status: Inappropriate [Upstream already fixed]
>>
>> So this is a backport then?
> 
> I just come back from the holiday, sorry for the late reply. Upstream
> fixed it in a different way, I didn't backport it since the fix looks
> risky for bluez5 5.50. Should we use Backport for such a case, please?

I'd mark it as backport with an explanation that it's a subset of the 
full fix that went upstream.

Ross