[OE-core] [PATCH] rpcbind: Fix CVE-2017-8779

[Fan Xin]

This vulnerability is also called "rpcbomb".
Backport upstream patch to fix this vulnerability.

CVE: CVE-2017-8779

Signed-off-by: Fan Xin
---
 ...r-all-svc_getargs-calls-with-svc_freeargs.patch | 221 +
 meta/recipes-extended/rpcbind/rpcbind_0.2.4.bb |   1 +
 2 files changed, 222 insertions(+)
 create mode 100644 
meta/recipes-extended/rpcbind/rpcbind/0001-rpcbind-pair-all-svc_getargs-calls-with-svc_freeargs.patch

diff --git 
a/meta/recipes-extended/rpcbind/rpcbind/0001-rpcbind-pair-all-svc_getargs-calls-with-svc_freeargs.patch
 
b/meta/recipes-extended/rpcbind/rpcbind/0001-rpcbind-pair-all-svc_getargs-calls-with-svc_freeargs.patch
new file mode 100644
index 000..bf7aaef
--- /dev/null
+++ 
b/meta/recipes-extended/rpcbind/rpcbind/0001-rpcbind-pair-all-svc_getargs-calls-with-svc_freeargs.patch
@@ -0,0 +1,221 @@
+From 7ea36eeece56b59f98e469934e4c20b4da043346 Mon Sep 17 00:00:00 2001
+From: Doran Moppert 
+Date: Thu, 11 May 2017 11:42:54 -0400
+Subject: [PATCH] rpcbind: pair all svc_getargs() calls with svc_freeargs() to
+ avoid memory leak
+
+This patch is to address CVE-2017-8779 "rpcbomb" in rpcbind, discussed
+at [1], [2], [3].  The last link suggests this issue is actually a bug
+in rpcbind, which led me here.
+
+The leak caused by the reproducer at [4] appears to come from
+rpcb_service_4(), in the case where svc_getargs() returns false and the
+function had an early return, rather than passing through the cleanup
+path at done:, as would otherwise occur.
+
+It also addresses a couple of other locations where the same fault seems
+to exist, though I haven't been able to exercise those.  I hope someone
+more intimate with rpc(3) can confirm my understanding is correct, and
+that I haven't introduced any new bugs.
+
+Without this patch, using the reproducer (and variants) repeatedly
+against rpcbind with a numBytes argument of 1_000_000_000, /proc/$(pidof
+rpcbind)/status reports VmSize increase of 976564 kB each call, and
+VmRSS increase of around 260 kB every 33 calls - the specific numbers
+are probably an artifact of my rhel/glibc version.  With the patch,
+there is a small (~50 kB) VmSize increase with the first message, but
+thereafter both VmSize and VmRSS remain steady.
+
+[1]: http://seclists.org/oss-sec/2017/q2/209
+[2]: https://bugzilla.redhat.com/show_bug.cgi?id=1448124
+[3]: https://sourceware.org/ml/libc-alpha/2017-05/msg00129.html
+[4]: https://github.com/guidovranken/rpcbomb/
+
+
+CVE: CVE-2017-8779
+Upstream-Status: Backport
+
+Signed-off-by: Fan Xin 
+---
+ src/pmap_svc.c | 56 +-
+ src/rpcb_svc.c |  2 +-
+ src/rpcb_svc_4.c   |  2 +-
+ src/rpcb_svc_com.c |  8 
+ 4 files changed, 57 insertions(+), 11 deletions(-)
+
+diff --git a/src/pmap_svc.c b/src/pmap_svc.c
+index 4c744fe..e926cdc 100644
+--- a/src/pmap_svc.c
 b/src/pmap_svc.c
+@@ -175,6 +175,7 @@ pmapproc_change(struct svc_req *rqstp /*__unused*/, 
SVCXPRT *xprt, unsigned long
+   long ans;
+   uid_t uid;
+   char uidbuf[32];
++  int rc = TRUE;
+ 
+   /*
+* Can't use getpwnam here. We might end up calling ourselves
+@@ -194,7 +195,8 @@ pmapproc_change(struct svc_req *rqstp /*__unused*/, 
SVCXPRT *xprt, unsigned long
+ 
+   if (!svc_getargs(xprt, (xdrproc_t) xdr_pmap, (char *)®)) {
+   svcerr_decode(xprt);
+-  return (FALSE);
++  rc = FALSE;
++  goto done;
+   }
+ #ifdef RPCBIND_DEBUG
+   if (debugging)
+@@ -205,7 +207,8 @@ pmapproc_change(struct svc_req *rqstp /*__unused*/, 
SVCXPRT *xprt, unsigned long
+ 
+   if (!check_access(xprt, op, reg.pm_prog, PMAPVERS)) {
+   svcerr_weakauth(xprt);
+-  return (FALSE);
++  rc = (FALSE);
++  goto done;
+   }
+ 
+   rpcbreg.r_prog = reg.pm_prog;
+@@ -258,7 +261,16 @@ done_change:
+   rpcbs_set(RPCBVERS_2_STAT, ans);
+   else
+   rpcbs_unset(RPCBVERS_2_STAT, ans);
+-  return (TRUE);
++done:
++  if (!svc_freeargs(xprt, (xdrproc_t) xdr_pmap, (char *)®)) {
++  if (debugging) {
++  /*(void) xlog(LOG_DEBUG, "unable to free 
arguments\n");*/
++  if (doabort) {
++  rpcbind_abort();
++  }
++  }
++  }
++  return (rc);
+ }
+ 
+ /* ARGSUSED */
+@@ -272,15 +284,18 @@ pmapproc_getport(struct svc_req *rqstp /*__unused*/, 
SVCXPRT *xprt)
+ #ifdef RPCBIND_DEBUG
+   char *uaddr;
+ #endif
++  int rc = TRUE;
+ 
+   if (!svc_getargs(xprt, (xdrproc_t) xdr_pmap, (char *)®)) {
+   svcerr_decode(xprt);
+-  return (FALSE);
++  rc = FALSE;
++  goto done;
+   }
+ 
+   if (!check_access(xprt, PMAPPROC_GETPORT, reg.pm_prog, PMAPVERS)) {
+   svcerr_weakauth(xprt);
+-  return FALSE;
++  rc = FALSE;
++  goto done;
+   

[OE-core] [PATCH v2] mesa: 17.0.4 -> 17.0.6

[Huang Qiyu]

Upgrade mesa from 17.0.4 to 17.0.6.

Signed-off-by: Huang Qiyu 
---
 meta/recipes-graphics/mesa/{mesa-gl_17.0.4.bb => mesa-gl_17.0.6.bb} | 0
 meta/recipes-graphics/mesa/{mesa_17.0.4.bb => mesa_17.0.6.bb}   | 4 ++--
 2 files changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-graphics/mesa/{mesa-gl_17.0.4.bb => mesa-gl_17.0.6.bb} 
(100%)
 rename meta/recipes-graphics/mesa/{mesa_17.0.4.bb => mesa_17.0.6.bb} (83%)

diff --git a/meta/recipes-graphics/mesa/mesa-gl_17.0.4.bb 
b/meta/recipes-graphics/mesa/mesa-gl_17.0.6.bb
similarity index 100%
rename from meta/recipes-graphics/mesa/mesa-gl_17.0.4.bb
rename to meta/recipes-graphics/mesa/mesa-gl_17.0.6.bb
diff --git a/meta/recipes-graphics/mesa/mesa_17.0.4.bb 
b/meta/recipes-graphics/mesa/mesa_17.0.6.bb
similarity index 83%
rename from meta/recipes-graphics/mesa/mesa_17.0.4.bb
rename to meta/recipes-graphics/mesa/mesa_17.0.6.bb
index 396076d..3f98271 100644
--- a/meta/recipes-graphics/mesa/mesa_17.0.4.bb
+++ b/meta/recipes-graphics/mesa/mesa_17.0.6.bb
@@ -6,8 +6,8 @@ SRC_URI = "ftp://ftp.freedesktop.org/pub/mesa/mesa-${PV}.tar.xz 
\
file://0001-Use-wayland-scanner-in-the-path.patch \
 "
 
-SRC_URI[md5sum] = "4a16cfc1c6d034cc17314b866eada628"
-SRC_URI[sha256sum] = 
"1269dc8545a193932a0779b2db5bce9be4a5f6813b98c38b93b372be8362a346"
+SRC_URI[md5sum] = "77ea38dc0ab899864b06ea2941ac31a4"
+SRC_URI[sha256sum] = 
"89ecf3bcd0f18dcca5aaa42bf36bb52a2df33be89889f94d91f7a504a69d"
 
 #because we cannot rely on the fact that all apps will use pkgconfig,
 #make eglplatform.h independent of MESA_EGL_NO_X11_HEADER
-- 
2.7.4



-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/1] libpcap: add native package

[kai.kang]

From: Kai Kang 

Add package libcap-native required by recipe daq-native in layer
meta-networking. And daq-native is added to fix snort start error.

Signed-off-by: Kai Kang 
---
 meta/recipes-connectivity/libpcap/libpcap.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-connectivity/libpcap/libpcap.inc 
b/meta/recipes-connectivity/libpcap/libpcap.inc
index 6635779..e57ea87 100644
--- a/meta/recipes-connectivity/libpcap/libpcap.inc
+++ b/meta/recipes-connectivity/libpcap/libpcap.inc
@@ -38,3 +38,5 @@ CXXFLAGS_prepend = "-I${S} "
 do_configure_prepend () {
 sed -i -e's,^V_RPATH_OPT=.*$,V_RPATH_OPT=,' ${S}/pcap-config.in
 }
+
+BBCLASSEXTEND = "native"
-- 
2.10.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/1] libpcap: add native package

[kai.kang]

From: Kai Kang 

The following changes since commit a3d160f9e5826140cc8d6b2ed1b38bf022443b08:

  linux-yocto: Update genericx86* SRCREVs for linux-yocto 4.10 (2017-05-23 
17:46:14 +0100)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib kangkai/daq
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=kangkai/daq

Kai Kang (1):
  libpcap: add native package

 meta/recipes-connectivity/libpcap/libpcap.inc | 2 ++
 1 file changed, 2 insertions(+)

-- 
2.10.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH V2] binutils: fix CVE-2017-6969 in readelf

[Yuanjie Huang]

CVE: CVE-2017-6969
[BZ 21156] -- https://sourceware.org/bugzilla/show_bug.cgi?id=21156

PR binutils/21156: Fix illegal memory accesses in readelf when parsing a
corrupt binary.
PR binutils/21156: Fix another memory access error in
readelf when parsing a corrupt binary.

Signed-off-by: Yuanjie Huang 
---
 meta/recipes-devtools/binutils/binutils-2.28.inc   |   3 +
 .../binutils/binutils/CVE-2017-6969.patch  |  57 ++
 .../binutils/binutils/CVE-2017-6969_2.patch| 122 +
 .../binutils/binutils/CVE-2017-7209.patch  |  62 +++
 4 files changed, 244 insertions(+)
 create mode 100644 meta/recipes-devtools/binutils/binutils/CVE-2017-6969.patch
 create mode 100644 
meta/recipes-devtools/binutils/binutils/CVE-2017-6969_2.patch
 create mode 100644 meta/recipes-devtools/binutils/binutils/CVE-2017-7209.patch

diff --git a/meta/recipes-devtools/binutils/binutils-2.28.inc 
b/meta/recipes-devtools/binutils/binutils-2.28.inc
index 7585da1ca9..f5dca051c7 100644
--- a/meta/recipes-devtools/binutils/binutils-2.28.inc
+++ b/meta/recipes-devtools/binutils/binutils-2.28.inc
@@ -37,6 +37,9 @@ SRC_URI = "\
  file://0016-Detect-64-bit-MIPS-targets.patch \
  file://CVE-2017-6965.patch \
  file://CVE-2017-6966.patch \
+ file://CVE-2017-6969.patch \
+ file://CVE-2017-6969_2.patch \
+ file://CVE-2017-7209.patch \
 "
 S  = "${WORKDIR}/git"
 
diff --git a/meta/recipes-devtools/binutils/binutils/CVE-2017-6969.patch 
b/meta/recipes-devtools/binutils/binutils/CVE-2017-6969.patch
new file mode 100644
index 00..ed5403430c
--- /dev/null
+++ b/meta/recipes-devtools/binutils/binutils/CVE-2017-6969.patch
@@ -0,0 +1,57 @@
+From 1d9a2696903fc59d6a936f4ab4e4407ef329d066 Mon Sep 17 00:00:00 2001
+From: Nick Clifton 
+Date: Fri, 17 Feb 2017 15:59:45 +
+Subject: Fix illegal memory accesses in readelf when parsing
+ a corrupt binary.
+
+   PR binutils/21156
+   * readelf.c (find_section_in_set): Test for invalid section
+   indicies.
+
+CVE: CVE-2017-6969
+Upstream-Status: Backport [master]
+
+Signed-off-by: Yuanjie Huang 
+---
+ binutils/ChangeLog |  6 ++
+ binutils/readelf.c | 10 --
+ 2 files changed, 14 insertions(+), 2 deletions(-)
+
+diff --git a/binutils/ChangeLog b/binutils/ChangeLog
+index bd63c8a0d8..1d840b42f9 100644
+--- a/binutils/ChangeLog
 b/binutils/ChangeLog
+@@ -1,3 +1,9 @@
++2017-02-17  Nick Clifton  
++
++  PR binutils/21156
++  * readelf.c (find_section_in_set): Test for invalid section
++  indicies.
++
+ 2017-02-13  Nick Clifton  
+ 
+   PR binutils/21139
+diff --git a/binutils/readelf.c b/binutils/readelf.c
+index 7c158c6342..4960491c5c 100644
+--- a/binutils/readelf.c
 b/binutils/readelf.c
+@@ -675,8 +675,14 @@ find_section_in_set (const char * name, unsigned int * 
set)
+   if (set != NULL)
+ {
+   while ((i = *set++) > 0)
+-  if (streq (SECTION_NAME (section_headers + i), name))
+-return section_headers + i;
++  {
++/* See PR 21156 for a reproducer.  */
++if (i >= elf_header.e_shnum)
++  continue; /* FIXME: Should we issue an error message ?  */
++
++if (streq (SECTION_NAME (section_headers + i), name))
++  return section_headers + i;
++  }
+ }
+ 
+   return find_section (name);
+-- 
+2.11.0
+
diff --git a/meta/recipes-devtools/binutils/binutils/CVE-2017-6969_2.patch 
b/meta/recipes-devtools/binutils/binutils/CVE-2017-6969_2.patch
new file mode 100644
index 00..59a5dec675
--- /dev/null
+++ b/meta/recipes-devtools/binutils/binutils/CVE-2017-6969_2.patch
@@ -0,0 +1,122 @@
+From ef81126314f67472a46db9581530fbf5ccb6b3f2 Mon Sep 17 00:00:00 2001
+From: Nick Clifton 
+Date: Mon, 20 Feb 2017 14:40:39 +
+Subject: Fix another memory access error in readelf when
+ parsing a corrupt binary.
+
+   PR binutils/21156
+   * dwarf.c (cu_tu_indexes_read): Move into...
+   (load_cu_tu_indexes): ... here.  Change the variable into
+   tri-state.  Change the function into boolean, returning
+   false if the indicies could not be loaded.
+   (find_cu_tu_set): Return NULL if the indicies could not be
+   loaded.
+
+CVE: CVE-2017-6969
+Upstream-Status: Backport [master]
+
+Signed-off-by: Yuanjie Huang 
+---
+ binutils/ChangeLog | 10 ++
+ binutils/dwarf.c   | 34 --
+ 2 files changed, 30 insertions(+), 14 deletions(-)
+
+diff --git a/binutils/ChangeLog b/binutils/ChangeLog
+index 1d840b42f9..53352c1801 100644
+--- a/binutils/ChangeLog
 b/binutils/ChangeLog
+@@ -1,3 +1,13 @@
++2017-02-20  Nick Clifton  
++
++  PR binutils/21156
++  * dwarf.c (cu_tu_indexes_read): Move into...
++  (load_cu_tu_indexes): ... here.  Change the variable into
++  tri-state.  Change the function into boolean, returning
++  false if the indicies could not be loaded.
++  (find_cu_tu_set): Return NULL if the indicies could not be
++  loaded.
++
+ 2017-02-17  Nick

[OE-core] [PATCH V3] binutils: fix CVE-2017-6969 in readelf

[Yuanjie Huang]

CVE: CVE-2017-6969
[BZ 21156] -- https://sourceware.org/bugzilla/show_bug.cgi?id=21156

PR binutils/21156: Fix illegal memory accesses in readelf when
ing a corrupt binary.
PR binutils/21156: Fix another memory access error in readelf when
parsing a corrupt binary.

Signed-off-by: Yuanjie Huang 
---
 meta/recipes-devtools/binutils/binutils-2.28.inc   |   2 +
 .../binutils/binutils/CVE-2017-6969.patch  |  57 ++
 .../binutils/binutils/CVE-2017-6969_2.patch| 122 +
 3 files changed, 181 insertions(+)
 create mode 100644 meta/recipes-devtools/binutils/binutils/CVE-2017-6969.patch
 create mode 100644 
meta/recipes-devtools/binutils/binutils/CVE-2017-6969_2.patch

diff --git a/meta/recipes-devtools/binutils/binutils-2.28.inc 
b/meta/recipes-devtools/binutils/binutils-2.28.inc
index 7585da1ca9..fd37484dca 100644
--- a/meta/recipes-devtools/binutils/binutils-2.28.inc
+++ b/meta/recipes-devtools/binutils/binutils-2.28.inc
@@ -37,6 +37,8 @@ SRC_URI = "\
  file://0016-Detect-64-bit-MIPS-targets.patch \
  file://CVE-2017-6965.patch \
  file://CVE-2017-6966.patch \
+ file://CVE-2017-6969.patch \
+ file://CVE-2017-6969_2.patch \
 "
 S  = "${WORKDIR}/git"
 
diff --git a/meta/recipes-devtools/binutils/binutils/CVE-2017-6969.patch 
b/meta/recipes-devtools/binutils/binutils/CVE-2017-6969.patch
new file mode 100644
index 00..ed5403430c
--- /dev/null
+++ b/meta/recipes-devtools/binutils/binutils/CVE-2017-6969.patch
@@ -0,0 +1,57 @@
+From 1d9a2696903fc59d6a936f4ab4e4407ef329d066 Mon Sep 17 00:00:00 2001
+From: Nick Clifton 
+Date: Fri, 17 Feb 2017 15:59:45 +
+Subject: Fix illegal memory accesses in readelf when parsing
+ a corrupt binary.
+
+   PR binutils/21156
+   * readelf.c (find_section_in_set): Test for invalid section
+   indicies.
+
+CVE: CVE-2017-6969
+Upstream-Status: Backport [master]
+
+Signed-off-by: Yuanjie Huang 
+---
+ binutils/ChangeLog |  6 ++
+ binutils/readelf.c | 10 --
+ 2 files changed, 14 insertions(+), 2 deletions(-)
+
+diff --git a/binutils/ChangeLog b/binutils/ChangeLog
+index bd63c8a0d8..1d840b42f9 100644
+--- a/binutils/ChangeLog
 b/binutils/ChangeLog
+@@ -1,3 +1,9 @@
++2017-02-17  Nick Clifton  
++
++  PR binutils/21156
++  * readelf.c (find_section_in_set): Test for invalid section
++  indicies.
++
+ 2017-02-13  Nick Clifton  
+ 
+   PR binutils/21139
+diff --git a/binutils/readelf.c b/binutils/readelf.c
+index 7c158c6342..4960491c5c 100644
+--- a/binutils/readelf.c
 b/binutils/readelf.c
+@@ -675,8 +675,14 @@ find_section_in_set (const char * name, unsigned int * 
set)
+   if (set != NULL)
+ {
+   while ((i = *set++) > 0)
+-  if (streq (SECTION_NAME (section_headers + i), name))
+-return section_headers + i;
++  {
++/* See PR 21156 for a reproducer.  */
++if (i >= elf_header.e_shnum)
++  continue; /* FIXME: Should we issue an error message ?  */
++
++if (streq (SECTION_NAME (section_headers + i), name))
++  return section_headers + i;
++  }
+ }
+ 
+   return find_section (name);
+-- 
+2.11.0
+
diff --git a/meta/recipes-devtools/binutils/binutils/CVE-2017-6969_2.patch 
b/meta/recipes-devtools/binutils/binutils/CVE-2017-6969_2.patch
new file mode 100644
index 00..59a5dec675
--- /dev/null
+++ b/meta/recipes-devtools/binutils/binutils/CVE-2017-6969_2.patch
@@ -0,0 +1,122 @@
+From ef81126314f67472a46db9581530fbf5ccb6b3f2 Mon Sep 17 00:00:00 2001
+From: Nick Clifton 
+Date: Mon, 20 Feb 2017 14:40:39 +
+Subject: Fix another memory access error in readelf when
+ parsing a corrupt binary.
+
+   PR binutils/21156
+   * dwarf.c (cu_tu_indexes_read): Move into...
+   (load_cu_tu_indexes): ... here.  Change the variable into
+   tri-state.  Change the function into boolean, returning
+   false if the indicies could not be loaded.
+   (find_cu_tu_set): Return NULL if the indicies could not be
+   loaded.
+
+CVE: CVE-2017-6969
+Upstream-Status: Backport [master]
+
+Signed-off-by: Yuanjie Huang 
+---
+ binutils/ChangeLog | 10 ++
+ binutils/dwarf.c   | 34 --
+ 2 files changed, 30 insertions(+), 14 deletions(-)
+
+diff --git a/binutils/ChangeLog b/binutils/ChangeLog
+index 1d840b42f9..53352c1801 100644
+--- a/binutils/ChangeLog
 b/binutils/ChangeLog
+@@ -1,3 +1,13 @@
++2017-02-20  Nick Clifton  
++
++  PR binutils/21156
++  * dwarf.c (cu_tu_indexes_read): Move into...
++  (load_cu_tu_indexes): ... here.  Change the variable into
++  tri-state.  Change the function into boolean, returning
++  false if the indicies could not be loaded.
++  (find_cu_tu_set): Return NULL if the indicies could not be
++  loaded.
++
+ 2017-02-17  Nick Clifton  
+ 
+   PR binutils/21156
+diff --git a/binutils/dwarf.c b/binutils/dwarf.c
+index 0184a7ab2e..6d879c9b61 100644
+--- a/binutils/dwarf.c
 b/binutils/dwarf.c
+@@ -76,7 +76,

Re: [OE-core] [PATCH] openssh: Atomically generate host keys

[Peter Kjellerstedt]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Joshua Watt
> Sent: den 23 maj 2017 21:57
> To: Randy Witt 
> Cc: OE-core 
> Subject: Re: [OE-core] [PATCH] openssh: Atomically generate host keys
> 
> On Tue, May 23, 2017 at 12:56 PM, Joshua Watt 
> wrote:
> > On Tue, May 23, 2017 at 12:23 PM, Randy Witt
> >  wrote:
> >> On 05/23/2017 08:29 AM, Joshua Watt wrote:
> >>>
> >>> On Tue, May 23, 2017 at 9:37 AM, Burton, Ross
> 
> >>> wrote:
> 
> 
>  On 7 May 2017 at 02:33, Joshua Watt  wrote:
> >
> >
> > +if [ ! -f "$NAME" ]; then
> > +echo "  generating ssh $TYPE key..."
> > +ssh-keygen -q -f "${NAME}.tmp" -N '' -t $TYPE
> > +
> > +# Sync to ensure data is written to temp file before
> renaming
> > +sync
> > +
> > +# Move (Atomically rename) files
> > +# Rename the .pub file first, since the check that triggers
> a
> > +# key generation is based on the private file.
> > +mv -f "${NAME}.tmp.pub" "${NAME}.pub"
> > +sync
> > +
> > +mv -f "${NAME}.tmp" "${NAME}"
> > +sync
> > +fi
> >
> 
>  All of these syncs seem quite enthusiastic, are they really
> needed?
>  Writing
>  the file to a temporary name and then mving it to the real name
> should
>  result in either no file or a complete file in the event of power
> loss,
>  surely?
> >>>
> >>>
> >>> My understanding (and observation) of most journal file systems is
> >>> that only metadata (i.e. directory entries and such) are journaled
> in
> >>> typical usage. The first sync is necessary in this case to ensure
> that
> >>> the actual file data gets put on the disk before we rename the
> files,
> >>> otherwise in the event of interruption journaled rename might get
> >>> replayed but have garbage data. The second one is more of a "force
> >>> operation order" sync to make sure the public file is written
> before
> >>> the private one, as a reordering would cause problems. The last
> sync
> >>> is the most optional, but I've seen it take minutes for disk to
> sync
> >>> contents if no one calls "sync", so it is very possible that all
> our
> >>> work of regenerating keys would be for naught if power is
> interrupted
> >>> in the meantime.
> >>>
> >>> I think some of these syncs can be removed. Namely, the first and
> >>> third one. The second one needs to be there, but can server double
> >>> duty of syncing data to disk and enforcing the order between the
> >>> public and private rename. It does mean we could get a state where
> the
> >>> public key exists but is garbage, but this should be OK because the
> >>> private key won't exist and it would be regenerated.
> >>>
> >>> The third sync can be removed and I can put one final sync at the
> end
> >>> after all keys are generated to ensure we won't go through all the
> >>> effort of regenerating the (last) key again in the event of
> >>> interruption shortly after, unless you would prefer I didn't.
> >>>
> >>
> >> The typical convention for this is,
> >>
> >> 1. Update file data.
> >> 2. sync file
> >> 3. sync containing directory
> >> 4. mv file to new location
> >> 5. sync directory containing new file (although I've seen this step
> left out
> >> before)
> >>
> >> https://lwn.net/Articles/457672/ is a good example which is linked
> from
> >> https://lwn.net/Articles/457667/
> >>
> >> But one of the important parts vs your code, is also that the
> example is
> >> only calling sync on the files/directory needed, vs calling "sync"
> with no
> >> arguments which is going to cause all data in all filesystem caches
> to be
> >> flushed.
> >
> > Ah, OK. That makes sense, I will update sync to specify the
> > files/directory explicitly.
> 
> FWIW, I did some tests on the sync behavior:
> 
> It appears that older versions of the sync command ignore any
> arguments and just call sync(). From Ubuntu 14.04:
> $ strace sync foo
> ...
> write(2, "sync: ", 6sync: )   = 6
> write(2, "ignoring all arguments", 22)  = 22
> write(2, "\n", 1)   = 1
> sync()  = 0
> ...
> 
> The same is true for the (default) busybox version of sync on master
> (again verified with strace), but it doesn't complain nosily about it.

Busybox has a separate fsync applet to do file synchronization, but it 
is not enabled in the default OE-core configuration...

> I looked at the coreutils code, and sync was changed to respect
> arguments in January of 2015
> (8b2bf5295f353016d4f5e6a2317d55b6a8e7fd00) and only call fsync() on
> the provided arguments (if any are provided).
> 
> Either way, adding the arguments to the sync call in my patch won't
> hurt because it is forward compatible, even though it won't be
> optimally efficient currently because the sync command currently
> simply calls sync()

//Peter

-- 
_

Re: [OE-core] [PATCH 3/3] apt-native: Remove USE_NLS = "yes"

[Burton, Ross]

On 24 May 2017 at 00:47, Khem Raj  wrote:

> USE_NLS is target specific, its redundant for native packages
>

I don't think you're right:

| In file included from
/data/poky-master/tmp/work/x86_64-linux/apt-native/1.2.12-r0/build/include/apt-private/private-cachefile.h:12:0,
|  from
/data/poky-master/tmp/work/x86_64-linux/apt-native/1.2.12-r0/apt-1.2.12/apt-private/private-output.cc:15:
| /usr/include/libintl.h:44:14: error: expected unqualified-id before ‘char’
|  extern char *dgettext (const char *__domainname, const char *__msgid)
|   ^
| /usr/include/libintl.h:44:14: error: expected initializer before ‘char’
| In file included from /usr/include/features.h:374:0,
|  from /usr/include/x86_64-linux-gnu/sys/types.h:25,
|  from /usr/include/regex.h:23,
|  from
/data/poky-master/tmp/work/x86_64-linux/apt-native/1.2.12-r0/build/include/apt-pkg/configuration.h:31,
|  from
/data/poky-master/tmp/work/x86_64-linux/apt-native/1.2.12-r0/apt-1.2.12/apt-private/private-output.cc:4:
| /usr/include/libintl.h:82:52: error: expected unqualified-id before
‘throw’
|  extern char *textdomain (const char *__domainname) __THROW;
| ^
| /usr/include/libintl.h:82:52: error: expected initializer before ‘throw’
| /usr/include/libintl.h:87:32: error: expected unqualified-id before
‘throw’
|  const char *__dirname) __THROW;
| ^
| ERROR: oe_runmake failed
| /usr/include/libintl.h:87:32: error: expected initializer before ‘throw’

native.bbclass sets USE_NLS=no but I think apt requires it to be enabled,
thus the assignment.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] State of bitbake world, Failed tasks 2017-05-23

[Martin Jansa]

http://www.openembedded.org/wiki/Bitbake_World_Status

== Number of issues - stats ==
{| class='wikitable'
!|Date   !!colspan='3'|Failed tasks 
!!|Signatures !!colspan='14'|QA !!Comment
|-
||  ||qemuarm   ||qemux86   ||qemux86_64||all   
||already-stripped  ||libdir||textrel   ||build-deps
||file-rdeps||version-going-backwards   ||host-user-contaminated
||installed-vs-shipped  ||unknown-configure-option  ||symlink-to-sysroot
||invalid-pkgconfig ||pkgname   ||ldflags   ||compile-host-path 
||  
|-
||2017-05-23||8 ||10||0 ||0 ||0 ||0 
||0 ||0 ||0 ||31||0 
||0 ||0 ||0 ||0 ||0 
||0 ||0 ||  
|}

== Failed tasks 2017-05-23 ==

INFO: jenkins-job.sh-1.8.21 Complete log available at 
http://logs.nslu2-linux.org/buildlogs/oe/world/rocko/log.report.20170524_020326.log

=== common (0) ===

=== common-x86 (0) ===

=== qemuarm (8) ===
* meta-browser/recipes-mozilla/firefox/firefox_45.6.0esr.bb:do_compile
* meta-openembedded/meta-oe/recipes-devtools/meson/meson_0.40.1.bb:do_patch
* 
meta-openembedded/meta-oe/recipes-graphics/libsexy/libsexy_0.1.11.bb:do_compile
* 
meta-openembedded/meta-oe/recipes-multimedia/audiofile/audiofile_0.3.6.bb:do_configure
* meta-qt5/recipes-qt/qt5/qtdeclarative_git.bb:do_compile_ptest_base
* meta-qt5/recipes-qt/qt5/qtquick1_git.bb:do_compile_ptest_base
* meta-qt5/recipes-qt/qt5/qtxmlpatterns_git.bb:do_compile_ptest_base
* meta-smartphone/meta-shr/recipes-shr/3rdparty/libsensmon_git.bb:do_compile

=== qemux86 (2) ===
* 
meta-openembedded/meta-oe/recipes-support/espeak/espeak_1.48.04.bb:do_compile
* meta-openembedded/meta-oe/recipes-test/fwts/fwts_git.bb:do_compile

=== qemux86_64 (0) ===

=== Number of failed tasks (18) ===
{| class=wikitable
|-
|| qemuarm  || 8 || 
http://logs.nslu2-linux.org/buildlogs/oe/world/rocko/log.world.qemuarm.20170523_040523.log/
 || http://errors.yoctoproject.org/Errors/Build/37984/
|-
|| qemux86  || 10|| 
http://logs.nslu2-linux.org/buildlogs/oe/world/rocko/log.world.qemux86.20170523_040524.log/
 || http://errors.yoctoproject.org/Errors/Build/37985/
|-
|| qemux86_64   || 0 || 
http://logs.nslu2-linux.org/buildlogs/oe/world/rocko/log.world.qemux86-64.20170523_090558.log/
 || 
|}

=== PNBLACKLISTs (13) ===
=== QA issues (31) ===
{| class=wikitable
!| Count||Issue
|-
||0 ||already-stripped
|-
||0 ||build-deps
|-
||0 ||compile-host-path
|-
||0 ||file-rdeps
|-
||0 ||host-user-contaminated
|-
||0 ||installed-vs-shipped
|-
||0 ||invalid-pkgconfig
|-
||0 ||ldflags
|-
||0 ||libdir
|-
||0 ||pkgname
|-
||0 ||symlink-to-sysroot
|-
||0 ||textrel
|-
||0 ||unknown-configure-option
|-
||31||version-going-backwards
|}



=== Incorrect PACKAGE_ARCH or sstate signatures (0) ===

Complete log: 
http://logs.nslu2-linux.org/buildlogs/oe/world/rocko/log.signatures.20170523_080807.log/

No issues detected

PNBLACKLISTs:
openembedded-core/:
meta-browser:
recipes-browser/chromium/cef3_280796.bb:PNBLACKLIST[cef3] ?= "BROKEN: fails to 
build with gcc-6"
meta-openembedded:
meta-networking/recipes-support/lksctp-tools/lksctp-tools_1.0.17.bb:PNBLACKLIST[lksctp-tools]
 ?= "${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-gold', "BROKEN: fails to 
link against sctp_connectx symbol", '', d)}"
meta-oe/recipes-connectivity/bluez/bluez-hcidump_2.5.bb:PNBLACKLIST[bluez-hcidump]
 ?= "${@bb.utils.contains('DISTRO_FEATURES', 'bluez5', 'bluez5 conflicts with 
bluez4 and bluez5 is selected in DISTRO_FEATURES', '', d)}"
meta-oe/recipes-connectivity/bluez/bluez4_4.101.bb:PNBLACKLIST[bluez4] ?= 
"${@bb.utils.contains('DISTRO_FEATURES', 'bluez5', 'bluez5 conflicts with 
bluez4 and bluez5 is selected in DISTRO_FEATURES', '', d)}"
meta-oe/recipes-connectivity/bluez/gst-plugin-bluetooth_4.101.bb:PNBLACKLIST[gst-plugin-bluetooth]
 ?= "${@bb.utils.contains('DISTRO_FEATURES', 'bluez5', 'bluez5 conflicts with 
bluez4 and bluez5 is selected in DISTRO_FEATURES', '', d)}"
meta-oe/recipes-core/dbus/libdbus-c++_0.9.0.bb:PNBLACKLIST[libdbus-c++] ?= 
"Fails to build with RSS http://errors.yoctoproject.org/Errors/Details/130644/ 
- the recipe will be removed on 2017-09-01 unless the issue is fixed"
meta-oe/recipes-graphics/xorg-driver/xf86-video-geode_2.11.16.bb:PNBLACKLIST[xf86-video-geode]
 ?= "BROKEN, fails to build - the recipe will be removed on 2017-09-01 unless 
the issue is fixed"
meta-oe/recipes-navigation/foxtrotgps/foxtrotgps_1.1.1.bb:PNBLACKLIST[foxtrotgps]
 ?= "${@bb.utils.contains('DISTRO_FEATURES', 'bluez5', 'bluez5 conflicts with 
bluez4 and bluez5 is selected in DISTRO_FEATURES', '', d)}"
meta-oe/recipes-navigation/gypsy/gypsy.inc:PNBLACKLIST[gypsy] ?= 
"${@bb.

[OE-core] What's the "proper" way to start WiFi networking?

[Mike Looijmans]

For boards that offer WiFi, I'd want them to connect more or less 
automatically.

I was wondering if there were better ways than handcrafting shell scripts to 
do this on a headless embedded board?




If I put wpa-conf into /etc/network/interfaces it works, but blocks booting 
for a long time if the wifi isn't there.



I've been using ifplugd combined with wired ethernet, and this also works fine 
with wireless. Once wpa-supplicant connects to an access point, the link 
reports up and DCHP can start.



Starting wpa_supplicant from the commandline runs fine:

/usr/sbin/wpa_supplicant -B -P /var/run/wpa_supplicant.wlan0.pid -i wlan0 -c 
/etc/wpa_topic.conf -D


However, putting this line into a startup script (/etc/rc5.d/...) hangs. It 
doesn't matter whether I start early or late, the wpa_supplicant just hangs 
and waits and doesn't fork into daemon mode like it should. Tried setting PATH 
and redirecting input, invoking through start-stop-daemon, but that didn't help.


Appending an ampersand to the command makes the boot continue, but 
wpa_supplicant doesn't work, it won't connect to the access point.





Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail



Join our presentation at Electronics & Applications 2017:
FPGA for real-time data processing, subject “Hardware platform for industrial 
ultrasound steel plate Inspection” Topic Embedded Systems - Herman Kuster, 1st 
June 10 AM

Visit http://eabeurs.nl/author/612884/ for more information

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] What's the "proper" way to start WiFi networking?

[Nicolas Dechesne]

On Wed, May 24, 2017 at 2:58 PM, Mike Looijmans  wrote:
>
> I was wondering if there were better ways than handcrafting shell scripts to
> do this on a headless embedded board?
>
>
>
> If I put wpa-conf into /etc/network/interfaces it works, but blocks booting
> for a long time if the wifi isn't there.
>
>
> I've been using ifplugd combined with wired ethernet, and this also works
> fine with wireless. Once wpa-supplicant connects to an access point, the
> link reports up and DCHP can start.
>
>
> Starting wpa_supplicant from the commandline runs fine:
>
> /usr/sbin/wpa_supplicant -B -P /var/run/wpa_supplicant.wlan0.pid -i wlan0 -c
> /etc/wpa_topic.conf -D
>
> However, putting this line into a startup script (/etc/rc5.d/...) hangs. It
> doesn't matter whether I start early or late, the wpa_supplicant just hangs
> and waits and doesn't fork into daemon mode like it should. Tried setting
> PATH and redirecting input, invoking through start-stop-daemon, but that
> didn't help.
>
> Appending an ampersand to the command makes the boot continue, but
> wpa_supplicant doesn't work, it won't connect to the access point.

my 2 cents..

after going back and forth for some time, I am now always using
network-manager.. it has very handy command line utilities (nmcli and
nmtui) and is well integrated with systemd. that happens to work well
for me.

i want to believe that connman can do the same thing, but i have never
tried it much..
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] What's the "proper" way to start WiFi networking?

[Burton, Ross]

On 24 May 2017 at 14:12, Nicolas Dechesne 
wrote:

> after going back and forth for some time, I am now always using
> network-manager.. it has very handy command line utilities (nmcli and
> nmtui) and is well integrated with systemd. that happens to work well
> for me.
>
> i want to believe that connman can do the same thing, but i have never
> tried it much..
>

Yes, connman can do exactly the same thing.  The only gotcha is that
connman doesn't enable radios by default so you need to add a configuration
file to turn it on, but if you're going to be making it either autoconnect
out of the box or  be an AP then you'll be doing this anyway.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] libpcap: add native package

[Kang Kai]

On 2017年05月24日 17:33, kai.k...@windriver.com wrote:

From: Kai Kang 

Add package libcap-native required by recipe daq-native in layer
meta-networking. And daq-native is added to fix snort start error.


I just realize that it only needs daq-native provide a shell script, so 
libpcap-native may not be needed. I'll figure it out.

Please ignore this patch for now.

Thanks,
Kai



Signed-off-by: Kai Kang 
---
  meta/recipes-connectivity/libpcap/libpcap.inc | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/meta/recipes-connectivity/libpcap/libpcap.inc 
b/meta/recipes-connectivity/libpcap/libpcap.inc
index 6635779..e57ea87 100644
--- a/meta/recipes-connectivity/libpcap/libpcap.inc
+++ b/meta/recipes-connectivity/libpcap/libpcap.inc
@@ -38,3 +38,5 @@ CXXFLAGS_prepend = "-I${S} "
  do_configure_prepend () {
  sed -i -e's,^V_RPATH_OPT=.*$,V_RPATH_OPT=,' ${S}/pcap-config.in
  }
+
+BBCLASSEXTEND = "native"



--
Regards,
Neil | Kai Kang

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] libgcrypt: Revert to inheriting from binconfig

[Mike Crowe]

Commit 5870bd272b0b077d0826fb900b251884c1c05061 introduced
binconfig-disabled and enabled it for libgcrypt. This intentionally broke
the old-style libgcrypt-config binary since packages should be using the
pkg-config instead.

oe-core patches libgcrypt itself in order to generate a .pc file. This
patch was not accepted upstream because they do not wish to depend on
pkg-config. This means that upstream libgcrypt continues to ship with an
autoconf snippet that expects the libgcrypt-config binary so the configure
scripts shipped with other upstream projects (e.g. libmicrohttpd) also
expect to be able to find the libgcrypt-config binary.

If libgcrypt upstream doesn't generate a .pc file by default, then we
shouldn't expect other upstreams to make use of one. So, I think it makes
most sense to go back to installing a working libgcrypt-config binary until
that situation changes.

Signed-off-by: Mike Crowe 
---
 meta/recipes-support/libgcrypt/libgcrypt.inc | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/meta/recipes-support/libgcrypt/libgcrypt.inc 
b/meta/recipes-support/libgcrypt/libgcrypt.inc
index 84c1cc018b..569e102c01 100644
--- a/meta/recipes-support/libgcrypt/libgcrypt.inc
+++ b/meta/recipes-support/libgcrypt/libgcrypt.inc
@@ -22,9 +22,7 @@ SRC_URI = "${GNUPG_MIRROR}/libgcrypt/libgcrypt-${PV}.tar.gz \
file://fix-undefined-reference-to-pthread.patch \
 "
 
-BINCONFIG = "${bindir}/libgcrypt-config"
-
-inherit autotools texinfo binconfig-disabled pkgconfig
+inherit autotools texinfo binconfig pkgconfig
 
 EXTRA_OECONF = "--disable-asm"
 
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] libgcrypt: Revert to inheriting from binconfig

[Burton, Ross]

On 24 May 2017 at 14:23, Mike Crowe  wrote:

> If libgcrypt upstream doesn't generate a .pc file by default, then we
> shouldn't expect other upstreams to make use of one. So, I think it makes
> most sense to go back to installing a working libgcrypt-config binary until
> that situation changes.
>

The flip side of this being that we disabled the script because those sort
of scripts have terrible failure modes when cross-compiling...

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] openssh: Atomically generate host keys

[Joshua Watt]

On Wed, May 24, 2017 at 5:03 AM, Peter Kjellerstedt
 wrote:
>> -Original Message-
>> From: openembedded-core-boun...@lists.openembedded.org
>> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
>> Joshua Watt
>> Sent: den 23 maj 2017 21:57
>> To: Randy Witt 
>> Cc: OE-core 
>> Subject: Re: [OE-core] [PATCH] openssh: Atomically generate host keys
>>
>> On Tue, May 23, 2017 at 12:56 PM, Joshua Watt 
>> wrote:
>> > On Tue, May 23, 2017 at 12:23 PM, Randy Witt
>> >  wrote:
>> >> On 05/23/2017 08:29 AM, Joshua Watt wrote:
>> >>>
>> >>> On Tue, May 23, 2017 at 9:37 AM, Burton, Ross
>> 
>> >>> wrote:
>> 
>> 
>>  On 7 May 2017 at 02:33, Joshua Watt  wrote:
>> >
>> >
>> > +if [ ! -f "$NAME" ]; then
>> > +echo "  generating ssh $TYPE key..."
>> > +ssh-keygen -q -f "${NAME}.tmp" -N '' -t $TYPE
>> > +
>> > +# Sync to ensure data is written to temp file before
>> renaming
>> > +sync
>> > +
>> > +# Move (Atomically rename) files
>> > +# Rename the .pub file first, since the check that triggers
>> a
>> > +# key generation is based on the private file.
>> > +mv -f "${NAME}.tmp.pub" "${NAME}.pub"
>> > +sync
>> > +
>> > +mv -f "${NAME}.tmp" "${NAME}"
>> > +sync
>> > +fi
>> >
>> 
>>  All of these syncs seem quite enthusiastic, are they really
>> needed?
>>  Writing
>>  the file to a temporary name and then mving it to the real name
>> should
>>  result in either no file or a complete file in the event of power
>> loss,
>>  surely?
>> >>>
>> >>>
>> >>> My understanding (and observation) of most journal file systems is
>> >>> that only metadata (i.e. directory entries and such) are journaled
>> in
>> >>> typical usage. The first sync is necessary in this case to ensure
>> that
>> >>> the actual file data gets put on the disk before we rename the
>> files,
>> >>> otherwise in the event of interruption journaled rename might get
>> >>> replayed but have garbage data. The second one is more of a "force
>> >>> operation order" sync to make sure the public file is written
>> before
>> >>> the private one, as a reordering would cause problems. The last
>> sync
>> >>> is the most optional, but I've seen it take minutes for disk to
>> sync
>> >>> contents if no one calls "sync", so it is very possible that all
>> our
>> >>> work of regenerating keys would be for naught if power is
>> interrupted
>> >>> in the meantime.
>> >>>
>> >>> I think some of these syncs can be removed. Namely, the first and
>> >>> third one. The second one needs to be there, but can server double
>> >>> duty of syncing data to disk and enforcing the order between the
>> >>> public and private rename. It does mean we could get a state where
>> the
>> >>> public key exists but is garbage, but this should be OK because the
>> >>> private key won't exist and it would be regenerated.
>> >>>
>> >>> The third sync can be removed and I can put one final sync at the
>> end
>> >>> after all keys are generated to ensure we won't go through all the
>> >>> effort of regenerating the (last) key again in the event of
>> >>> interruption shortly after, unless you would prefer I didn't.
>> >>>
>> >>
>> >> The typical convention for this is,
>> >>
>> >> 1. Update file data.
>> >> 2. sync file
>> >> 3. sync containing directory
>> >> 4. mv file to new location
>> >> 5. sync directory containing new file (although I've seen this step
>> left out
>> >> before)
>> >>
>> >> https://lwn.net/Articles/457672/ is a good example which is linked
>> from
>> >> https://lwn.net/Articles/457667/
>> >>
>> >> But one of the important parts vs your code, is also that the
>> example is
>> >> only calling sync on the files/directory needed, vs calling "sync"
>> with no
>> >> arguments which is going to cause all data in all filesystem caches
>> to be
>> >> flushed.
>> >
>> > Ah, OK. That makes sense, I will update sync to specify the
>> > files/directory explicitly.
>>
>> FWIW, I did some tests on the sync behavior:
>>
>> It appears that older versions of the sync command ignore any
>> arguments and just call sync(). From Ubuntu 14.04:
>> $ strace sync foo
>> ...
>> write(2, "sync: ", 6sync: )   = 6
>> write(2, "ignoring all arguments", 22)  = 22
>> write(2, "\n", 1)   = 1
>> sync()  = 0
>> ...
>>
>> The same is true for the (default) busybox version of sync on master
>> (again verified with strace), but it doesn't complain nosily about it.
>
> Busybox has a separate fsync applet to do file synchronization, but it
> is not enabled in the default OE-core configuration...

Ok. I think for best compatibility I'll just use "sync", as that will
always be safe, just not always optimally efficient. I think this is
OK, since key generation either only occurs once (r/w rootfs), or once
per boot (r/o rootfs).

>
>> I looked at the coreutils code, and sync was c

Re: [OE-core] [PATCH] libgcrypt: Revert to inheriting from binconfig

[Mike Crowe]

On Wednesday 24 May 2017 at 14:28:11 +0100, Burton, Ross wrote:
> On 24 May 2017 at 14:23, Mike Crowe  wrote:
> 
> > If libgcrypt upstream doesn't generate a .pc file by default, then we
> > shouldn't expect other upstreams to make use of one. So, I think it makes
> > most sense to go back to installing a working libgcrypt-config binary until
> > that situation changes.
> >
> 
> The flip side of this being that we disabled the script because those sort
> of scripts have terrible failure modes when cross-compiling...

Oh, I thought that binconfig.bbclass swung through hoops in order to make
the scripts work well enough. Is that not true?

Many other recipes are still inheriting binconfig rather than
binconfig-disabled: apr, curl, gnutls, libtasn1.

Mike.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/3] [RFC] Add support for 'fastboot images'

[Nicolas Dechesne]

On Mon, May 22, 2017 at 7:13 PM, Khem Raj  wrote:
> its in meta-oe, what do we get if we bring it to OE-Core. ?
> how much prevalent is it ?

the android-tools recipe is in meta-oe, i believe that fastboot images
are widely used, and having a generic 'fastboot' image type in oe-core
would be helpful. Having image type outside of oe-core is possible but
cumbersome, since we need a custom class, which needs to be inherited
and creates additional dependencies to meta-oe.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] libgcrypt: Revert to inheriting from binconfig

[Burton, Ross]

On 24 May 2017 at 14:52, Mike Crowe  wrote:

> Oh, I thought that binconfig.bbclass swung through hoops in order to make
> the scripts work well enough. Is that not true?
>
> Many other recipes are still inheriting binconfig rather than
> binconfig-disabled: apr, curl, gnutls, libtasn1.
>

binconfig goes through hoops that are just not required with pkgconfig, and
the hoops are hacks which may not be reliable.  I can't remember the
details but I do remember that libgcrypt/gnupg was a worst offender here.

CCing Richard to see if he can remember why.

In the glorious future removing all binconfig scripts would be the ideal,
in my opinion.  Alternatively replacing them with glorified pkgconfig
wrappers.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [oe-core][PATCH 1/1] ghostscript: move to version 9.21

[Joe Slater]

Eliminate CVE patches that are now in source.  Add CVE-2017-7975
patch.

Signed-off-by: Joe Slater 
---
 .../ghostscript/ghostscript/CVE-2016-10219.patch   | 49 ---
 .../ghostscript/ghostscript/CVE-2016-10220.patch   | 55 --
 .../ghostscript/ghostscript/CVE-2016-8602.patch| 47 --
 .../ghostscript/ghostscript/CVE-2017-7975.patch| 23 -
 ...t-9.21-native-fix-disable-system-libtiff.patch} | 22 -
 ... => ghostscript-9.21-prevent_recompiling.patch} | 25 +-
 .../{ghostscript_9.20.bb => ghostscript_9.21.bb}   | 13 ++---
 7 files changed, 39 insertions(+), 195 deletions(-)
 delete mode 100644 
meta/recipes-extended/ghostscript/ghostscript/CVE-2016-10219.patch
 delete mode 100644 
meta/recipes-extended/ghostscript/ghostscript/CVE-2016-10220.patch
 delete mode 100644 
meta/recipes-extended/ghostscript/ghostscript/CVE-2016-8602.patch
 rename 
meta/recipes-extended/ghostscript/ghostscript/{ghostscript-native-fix-disable-system-libtiff.patch
 => ghostscript-9.21-native-fix-disable-system-libtiff.patch} (67%)
 rename 
meta/recipes-extended/ghostscript/ghostscript/{ghostscript-9.02-prevent_recompiling.patch
 => ghostscript-9.21-prevent_recompiling.patch} (81%)
 rename meta/recipes-extended/ghostscript/{ghostscript_9.20.bb => 
ghostscript_9.21.bb} (88%)

diff --git a/meta/recipes-extended/ghostscript/ghostscript/CVE-2016-10219.patch 
b/meta/recipes-extended/ghostscript/ghostscript/CVE-2016-10219.patch
deleted file mode 100644
index 574abe0..000
--- a/meta/recipes-extended/ghostscript/ghostscript/CVE-2016-10219.patch
+++ /dev/null
@@ -1,49 +0,0 @@
-From 4bef1a1d32e29b68855616020dbff574b9cda08f Mon Sep 17 00:00:00 2001
-From: Robin Watts 
-Date: Thu, 29 Dec 2016 15:57:43 +
-Subject: [PATCH] Bug 697453: Avoid divide by 0 in scan conversion code.
-
-Arithmetic overflow due to extreme values in the scan conversion
-code can cause a division by 0.
-
-Avoid this with a simple extra check.
-
-  dx_old=cf814d81
-  endp->x_next=b0e859b9
-  alp->x_next=8069a73a
-
-leads to dx_den = 0
-
-Upstream-Status: Backport
-CVE: CVE-2016-10219
-
-Signed-off-by: Catalin Enache 

- base/gxfill.c | 4 ++--
- 1 file changed, 2 insertions(+), 2 deletions(-)
-
-diff --git a/base/gxfill.c b/base/gxfill.c
-index 99196c0..2f81bb0 100644
 a/base/gxfill.c
-+++ b/base/gxfill.c
-@@ -1741,7 +1741,7 @@ intersect(active_line *endp, active_line *alp, fixed y, 
fixed y1, fixed *p_y_new
- fixed dx_old = alp->x_current - endp->x_current;
- fixed dx_den = dx_old + endp->x_next - alp->x_next;
- 
--if (dx_den <= dx_old)
-+if (dx_den <= dx_old || dx_den == 0)
- return false; /* Intersection isn't possible. */
- dy = y1 - y;
- if_debug3('F', "[F]cross: dy=%g, dx_old=%g, dx_new=%g\n",
-@@ -1750,7 +1750,7 @@ intersect(active_line *endp, active_line *alp, fixed y, 
fixed y1, fixed *p_y_new
- /* Do the computation in single precision */
- /* if the values are small enough. */
- y_new =
--((dy | dx_old) < 1L << (size_of(fixed) * 4 - 1) ?
-+(((ufixed)(dy | dx_old)) < (1L << (size_of(fixed) * 4 - 1)) ?
-  dy * dx_old / dx_den :
-  (INCR_EXPR(mq_cross), fixed_mult_quo(dy, dx_old, dx_den)))
- + y;
--- 
-2.10.2
-
diff --git a/meta/recipes-extended/ghostscript/ghostscript/CVE-2016-10220.patch 
b/meta/recipes-extended/ghostscript/ghostscript/CVE-2016-10220.patch
deleted file mode 100644
index 5e1e8ba..000
--- a/meta/recipes-extended/ghostscript/ghostscript/CVE-2016-10220.patch
+++ /dev/null
@@ -1,55 +0,0 @@
-From daf85701dab05f17e924a48a81edc9195b4a04e8 Mon Sep 17 00:00:00 2001
-From: Ken Sharp 
-Date: Wed, 21 Dec 2016 16:54:14 +
-Subject: [PATCH] fix crash with bad data supplied to makeimagedevice
-
-Bug #697450 "Null pointer dereference in gx_device_finalize()"
-
-The problem here is that the code to finalise a device unconditionally
-frees the icc_struct member of the device structure. However this
-particular (weird) device is not setup as a normal device, probably
-because its very, very ancient. Its possible for the initialisation
-of the device to abort with an error before calling gs_make_mem_device()
-which is where the icc_struct member gets allocated (or set to NULL).
-
-If that happens, then the cleanup code tries to free the device, which
-calls finalize() which tries to free a garbage pointer.
-
-Setting the device memory to 0x00 after we allocate it means that the
-icc_struct member will be NULL< and our memory manager allows for that
-happily enough, which avoids the problem.
-
-Upstream-Status: Backport
-CVE: CVE-2016-10220
-
-Signed-off-by: Catalin Enache 

- base/gsdevmem.c | 12 
- 1 file changed, 12 insertions(+)
-
-diff --git a/base/gsdevmem.c b/base/gsdevmem.c
-index 97b9cf4..fe75bcc 100644
 a/base/gsdevmem.c
-+++ b/base/gsdevmem.c
-@@ -225,6 +225,18 @@ gs_makewordimagedevice(gx_device ** pnew_dev, const 
gs_matrix * pmat,
- 
- if (pnew == 0)
-

[OE-core] [oe-core][PATCH 0/1] ghostscript: move to version 9.21

[Joe Slater]

Updated to apply over recent ghostscript recipe changes...

Joe Slater (1):
  ghostscript:   move to version 9.21

 .../ghostscript/ghostscript/CVE-2016-10219.patch   | 49 ---
 .../ghostscript/ghostscript/CVE-2016-10220.patch   | 55 --
 .../ghostscript/ghostscript/CVE-2016-8602.patch| 47 --
 .../ghostscript/ghostscript/CVE-2017-7975.patch| 23 -
 ...t-9.21-native-fix-disable-system-libtiff.patch} | 22 -
 ... => ghostscript-9.21-prevent_recompiling.patch} | 25 +-
 .../{ghostscript_9.20.bb => ghostscript_9.21.bb}   | 13 ++---
 7 files changed, 39 insertions(+), 195 deletions(-)
 delete mode 100644 
meta/recipes-extended/ghostscript/ghostscript/CVE-2016-10219.patch
 delete mode 100644 
meta/recipes-extended/ghostscript/ghostscript/CVE-2016-10220.patch
 delete mode 100644 
meta/recipes-extended/ghostscript/ghostscript/CVE-2016-8602.patch
 rename 
meta/recipes-extended/ghostscript/ghostscript/{ghostscript-native-fix-disable-system-libtiff.patch
 => ghostscript-9.21-native-fix-disable-system-libtiff.patch} (67%)
 rename 
meta/recipes-extended/ghostscript/ghostscript/{ghostscript-9.02-prevent_recompiling.patch
 => ghostscript-9.21-prevent_recompiling.patch} (81%)
 rename meta/recipes-extended/ghostscript/{ghostscript_9.20.bb => 
ghostscript_9.21.bb} (88%)

-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] package_ipk: correct ipk descriptions

[Burton, Ross]

On 22 May 2017 at 17:43,  wrote:

> Empty descriptions are set with a space following by a dot. For the
> non-empty ones,
> there is no need for formating the description with textwrap, so remove
> the logic
> for the latter.
>

Looks like opkg doesn't behave like this as building lzop fails (which has
lots of newlines embedded in the SUMMARY).

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] package_ipk: correct ipk descriptions

[Leonardo Sandoval]

On Wed, 2017-05-24 at 21:15 +0100, Burton, Ross wrote:
> 
> On 22 May 2017 at 17:43, 
> wrote:
> Empty descriptions are set with a space following by a dot.
> For the non-empty ones,
> there is no need for formating the description with textwrap,
> so remove the logic
> for the latter.
> 
> 
> Looks like opkg doesn't behave like this as building lzop fails (which
> has lots of newlines embedded in the SUMMARY).

I will check that particular recipe and bb world just so see if some
other recipe is broken with this change, then provide a v3.

Leo
> 
> 
> Ross


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] u-boot: Update to 2017.05 release

[Marek Vasut]

Upgrade U-Boot to the latest version.

Since the latest version has the default gcc patch in it, drop it.

Signed-off-by: Marek Vasut 
Cc: Denys Dmytriyenko 
Cc: Richard Purdie 
Cc: Ross Burton 
---
 meta/recipes-bsp/u-boot/files/default-gcc.patch| 39 --
 ...ommon_2017.01.inc => u-boot-common_2017.05.inc} |  2 +-
 ...utils_2017.01.bb => u-boot-fw-utils_2017.05.bb} |  2 --
 ...kimage_2017.01.bb => u-boot-mkimage_2017.05.bb} |  2 --
 .../{u-boot_2017.01.bb => u-boot_2017.05.bb}   |  0
 5 files changed, 1 insertion(+), 44 deletions(-)
 delete mode 100644 meta/recipes-bsp/u-boot/files/default-gcc.patch
 rename meta/recipes-bsp/u-boot/{u-boot-common_2017.01.inc => 
u-boot-common_2017.05.inc} (86%)
 rename meta/recipes-bsp/u-boot/{u-boot-fw-utils_2017.01.bb => 
u-boot-fw-utils_2017.05.bb} (96%)
 rename meta/recipes-bsp/u-boot/{u-boot-mkimage_2017.01.bb => 
u-boot-mkimage_2017.05.bb} (96%)
 rename meta/recipes-bsp/u-boot/{u-boot_2017.01.bb => u-boot_2017.05.bb} (100%)

diff --git a/meta/recipes-bsp/u-boot/files/default-gcc.patch 
b/meta/recipes-bsp/u-boot/files/default-gcc.patch
deleted file mode 100644
index 04184df8b3..00
--- a/meta/recipes-bsp/u-boot/files/default-gcc.patch
+++ /dev/null
@@ -1,39 +0,0 @@
-OE needs to be able to change the default compiler. If we pass in HOSTCC
-through the make command, it overwrites not only this setting but also the 
-setting in tools/Makefile wrapped in ifneq ($(CROSS_BUILD_TOOLS),) which 
-breaks the build.
-
-We therefore use override to ensure the value of HOSTCC is overwritten when
-needed.
-
-RP: Updated the patch to the version being submitted to upstream u-boot
-
-Upstream-Status: Submitted [emailed to Masahiro Yamada for discussion]
-RP 2017/3/11
-
-Index: git/tools/Makefile
-===
 git.orig/tools/Makefile
-+++ git/tools/Makefile
-@@ -262,7 +262,7 @@ $(LICENSE_H): $(obj)/bin2header $(srctre
- subdir- += env
- 
- ifneq ($(CROSS_BUILD_TOOLS),)
--HOSTCC = $(CC)
-+override HOSTCC = $(CC)
- 
- quiet_cmd_crosstools_strip = STRIP   $^
-   cmd_crosstools_strip = $(STRIP) $^; touch $@
-Index: git/tools/env/Makefile
-===
 git.orig/tools/env/Makefile
-+++ git/tools/env/Makefile
-@@ -8,7 +8,7 @@
- # fw_printenv is supposed to run on the target system, which means it should 
be
- # built with cross tools. Although it may look weird, we only replace "HOSTCC"
- # with "CC" here for the maximum code reuse of scripts/Makefile.host.
--HOSTCC = $(CC)
-+override HOSTCC = $(CC)
- 
- # Compile for a hosted environment on the target
- HOST_EXTRACFLAGS  = $(patsubst -I%,-idirafter%, $(filter -I%, 
$(UBOOTINCLUDE))) \
diff --git a/meta/recipes-bsp/u-boot/u-boot-common_2017.01.inc 
b/meta/recipes-bsp/u-boot/u-boot-common_2017.05.inc
similarity index 86%
rename from meta/recipes-bsp/u-boot/u-boot-common_2017.01.inc
rename to meta/recipes-bsp/u-boot/u-boot-common_2017.05.inc
index df24c853dd..3719aee52d 100644
--- a/meta/recipes-bsp/u-boot/u-boot-common_2017.01.inc
+++ b/meta/recipes-bsp/u-boot/u-boot-common_2017.05.inc
@@ -7,7 +7,7 @@ PE = "1"
 
 # We use the revision in order to avoid having to fetch it from the
 # repo during parse
-SRCREV = "a705ebc81b7f91bbd0ef7c634284208342901149"
+SRCREV = "64c4ffa9fa223f7ae8640f9c8f3044bfa0e3bfda"
 
 SRC_URI = "git://git.denx.de/u-boot.git"
 
diff --git a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2017.01.bb 
b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2017.05.bb
similarity index 96%
rename from meta/recipes-bsp/u-boot/u-boot-fw-utils_2017.01.bb
rename to meta/recipes-bsp/u-boot/u-boot-fw-utils_2017.05.bb
index 26314990b9..c2e8f0fb84 100644
--- a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2017.01.bb
+++ b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2017.05.bb
@@ -1,7 +1,5 @@
 require u-boot-common_${PV}.inc
 
-SRC_URI += "file://default-gcc.patch"
-
 SUMMARY = "U-Boot bootloader fw_printenv/setenv utilities"
 DEPENDS = "mtd-utils"
 
diff --git a/meta/recipes-bsp/u-boot/u-boot-mkimage_2017.01.bb 
b/meta/recipes-bsp/u-boot/u-boot-mkimage_2017.05.bb
similarity index 96%
rename from meta/recipes-bsp/u-boot/u-boot-mkimage_2017.01.bb
rename to meta/recipes-bsp/u-boot/u-boot-mkimage_2017.05.bb
index 1aa95e7c86..50e2acb9ea 100644
--- a/meta/recipes-bsp/u-boot/u-boot-mkimage_2017.01.bb
+++ b/meta/recipes-bsp/u-boot/u-boot-mkimage_2017.05.bb
@@ -1,7 +1,5 @@
 require u-boot-common_${PV}.inc
 
-SRC_URI += "file://default-gcc.patch"
-
 SUMMARY = "U-Boot bootloader image creation tool"
 DEPENDS = "openssl"
 
diff --git a/meta/recipes-bsp/u-boot/u-boot_2017.01.bb 
b/meta/recipes-bsp/u-boot/u-boot_2017.05.bb
similarity index 100%
rename from meta/recipes-bsp/u-boot/u-boot_2017.01.bb
rename to meta/recipes-bsp/u-boot/u-boot_2017.05.bb
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/list

[OE-core] [PATCH] qemu: Update to 2.9.0

[Marek Vasut]

Upgrade QEMU to the latest version.

Signed-off-by: Marek Vasut 
Cc: Richard Purdie 
Cc: Ross Burton 
---
 ...support-for-VM-suspend-resume-for-TPM-TIS.patch | 17 +---
 .../recipes-devtools/qemu/qemu/CVE-2016-9908.patch | 44 
 .../recipes-devtools/qemu/qemu/CVE-2016-9912.patch | 45 
 .../qemu/qemu/target-ppc-fix-user-mode.patch   | 48 --
 .../qemu/{qemu_2.8.0.bb => qemu_2.9.0.bb}  |  7 +---
 5 files changed, 13 insertions(+), 148 deletions(-)
 delete mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2016-9908.patch
 delete mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2016-9912.patch
 delete mode 100644 
meta/recipes-devtools/qemu/qemu/target-ppc-fix-user-mode.patch
 rename meta/recipes-devtools/qemu/{qemu_2.8.0.bb => qemu_2.9.0.bb} (87%)

diff --git 
a/meta/recipes-devtools/qemu/qemu/0004-Add-support-for-VM-suspend-resume-for-TPM-TIS.patch
 
b/meta/recipes-devtools/qemu/qemu/0004-Add-support-for-VM-suspend-resume-for-TPM-TIS.patch
index b8a783d4e9..8567684e90 100644
--- 
a/meta/recipes-devtools/qemu/qemu/0004-Add-support-for-VM-suspend-resume-for-TPM-TIS.patch
+++ 
b/meta/recipes-devtools/qemu/qemu/0004-Add-support-for-VM-suspend-resume-for-TPM-TIS.patch
@@ -142,13 +142,14 @@ index 44739ebad2..bc8072d0bc 100644
  qemu_mutex_lock(&tpm_pt->state_lock);
  tpm_pt->tpm_busy = true;
  qemu_mutex_unlock(&tpm_pt->state_lock);
-@@ -601,6 +640,25 @@ static int tpm_passthrough_open_sysfs_cancel(TPMBackend 
*tb)
+@@ -601,6 +640,30 @@ static int tpm_passthrough_open_sysfs_cancel(TPMBackend 
*tb)
  return fd;
  }
  
 +static void tpm_passthrough_block_migration(TPMPassthruState *tpm_pt)
 +{
 +ptm_cap caps;
++Error *local_err = NULL;
 +
 +if (TPM_PASSTHROUGH_USES_CUSE_TPM(tpm_pt)) {
 +caps = PTM_CAP_GET_STATEBLOB | PTM_CAP_SET_STATEBLOB |
@@ -156,12 +157,16 @@ index 44739ebad2..bc8072d0bc 100644
 +if (!TPM_CUSE_IMPLEMENTS_ALL(tpm_pt, caps)) {
 +error_setg(&tpm_pt->migration_blocker,
 +   "Migration disabled: CUSE TPM lacks necessary 
capabilities");
-+migrate_add_blocker(tpm_pt->migration_blocker);
++migrate_add_blocker(tpm_pt->migration_blocker, &local_err);
 +}
 +} else {
 +error_setg(&tpm_pt->migration_blocker,
 +   "Migration disabled: Passthrough TPM does not support 
migration");
-+migrate_add_blocker(tpm_pt->migration_blocker);
++migrate_add_blocker(tpm_pt->migration_blocker, &local_err);
++}
++if (local_err) {
++error_report_err(local_err);
++error_free(tpm_pt->migration_blocker);
 +}
 +}
 +
@@ -239,19 +244,19 @@ index 44739ebad2..bc8072d0bc 100644
 +VMSTATE_UINT32(tpm_blobs.permanent_flags, TPMPassthruState),
 +VMSTATE_UINT32(tpm_blobs.permanent.size, TPMPassthruState),
 +VMSTATE_VBUFFER_ALLOC_UINT32(tpm_blobs.permanent.buffer,
-+ TPMPassthruState, 1, NULL, 0,
++ TPMPassthruState, 1, NULL,
 + tpm_blobs.permanent.size),
 +
 +VMSTATE_UINT32(tpm_blobs.volatil_flags, TPMPassthruState),
 +VMSTATE_UINT32(tpm_blobs.volatil.size, TPMPassthruState),
 +VMSTATE_VBUFFER_ALLOC_UINT32(tpm_blobs.volatil.buffer,
-+ TPMPassthruState, 1, NULL, 0,
++ TPMPassthruState, 1, NULL,
 + tpm_blobs.volatil.size),
 +
 +VMSTATE_UINT32(tpm_blobs.savestate_flags, TPMPassthruState),
 +VMSTATE_UINT32(tpm_blobs.savestate.size, TPMPassthruState),
 +VMSTATE_VBUFFER_ALLOC_UINT32(tpm_blobs.savestate.buffer,
-+ TPMPassthruState, 1, NULL, 0,
++ TPMPassthruState, 1, NULL,
 + tpm_blobs.savestate.size),
 +VMSTATE_END_OF_LIST()
 +}
diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2016-9908.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2016-9908.patch
deleted file mode 100644
index e0f7a1a3fd..00
--- a/meta/recipes-devtools/qemu/qemu/CVE-2016-9908.patch
+++ /dev/null
@@ -1,44 +0,0 @@
-From 7139ccbc907441337b4b59cde2c5b5a54cb5b2cc Mon Sep 17 00:00:00 2001
-From: Sona Sarmadi 
-
-virtio-gpu: fix information leak in capset get dispatch
-
-In virgl_cmd_get_capset function, it uses g_malloc to allocate
-a response struct to the guest. As the 'resp'struct hasn't been full
-initialized it will lead the 'resp->padding' field to the guest.
-Use g_malloc0 to avoid this.
-
-Signed-off-by: Li Qiang 
-Reviewed-by: Marc-André Lureau 
-Message-id: 58188cae.4a6ec20a.3d2d1.a...@mx.google.com
-
-[Sona: backported from master to v2.8.0 and resolved conflict]
-
-Reference to upstream patch:
-http://git.qemu-project.org/?p=qemu.git;a=commit;h=85d9d044471f93c48c5c396f7e217b4ef12f69f8
-
-CVE: CVE-2016-9908
-Upstream-Stat

[OE-core] [PATCH] u-boot: Fix build with OpenSSL 1.1.x

[Marek Vasut]

Pick two patches from the U-Boot ML fixing build with OpenSSL 1.1.x .

Signed-off-by: Marek Vasut 
Cc: Denys Dmytriyenko 
Cc: Richard Purdie 
Cc: Ross Burton 
---
 .../0001-rsa-Fix-build-with-OpenSSL-1.1.x.patch| 158 +
 ...ols-kwbimage-fix-build-with-OpenSSL-1.1.x.patch | 101 +
 meta/recipes-bsp/u-boot/u-boot-common_2017.05.inc  |   6 +-
 3 files changed, 264 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-bsp/u-boot/files/0001-rsa-Fix-build-with-OpenSSL-1.1.x.patch
 create mode 100644 
meta/recipes-bsp/u-boot/files/0002-tools-kwbimage-fix-build-with-OpenSSL-1.1.x.patch

diff --git 
a/meta/recipes-bsp/u-boot/files/0001-rsa-Fix-build-with-OpenSSL-1.1.x.patch 
b/meta/recipes-bsp/u-boot/files/0001-rsa-Fix-build-with-OpenSSL-1.1.x.patch
new file mode 100644
index 00..309cbbbc05
--- /dev/null
+++ b/meta/recipes-bsp/u-boot/files/0001-rsa-Fix-build-with-OpenSSL-1.1.x.patch
@@ -0,0 +1,158 @@
+From 59be82ef7e7ec4be6e1597d8aef65dd3d8c3a0d9 Mon Sep 17 00:00:00 2001
+From: Jelle van der Waa 
+Date: Mon, 8 May 2017 21:31:19 +0200
+Subject: [PATCH 1/2] rsa: Fix build with OpenSSL 1.1.x
+
+The rsa_st struct has been made opaque in 1.1.x, add forward compatible
+code to access the n, e, d members of rsa_struct.
+
+EVP_MD_CTX_cleanup has been removed in 1.1.x and EVP_MD_CTX_reset should be
+called to reinitialise an already created structure.
+---
+ lib/rsa/rsa-sign.c | 44 ++--
+ 1 file changed, 38 insertions(+), 6 deletions(-)
+
+diff --git a/lib/rsa/rsa-sign.c b/lib/rsa/rsa-sign.c
+index 8c6637e328..1da4ef7fff 100644
+--- a/lib/rsa/rsa-sign.c
 b/lib/rsa/rsa-sign.c
+@@ -9,6 +9,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ #include 
+ #include 
+ #include 
+@@ -20,6 +21,19 @@
+ #define HAVE_ERR_REMOVE_THREAD_STATE
+ #endif
+ 
++#if OPENSSL_VERSION_NUMBER < 0x1010L
++static void RSA_get0_key(const RSA *r,
++ const BIGNUM **n, const BIGNUM **e, const BIGNUM **d)
++{
++   if (n != NULL)
++   *n = r->n;
++   if (e != NULL)
++   *e = r->e;
++   if (d != NULL)
++   *d = r->d;
++}
++#endif
++
+ static int rsa_err(const char *msg)
+ {
+   unsigned long sslErr = ERR_get_error();
+@@ -286,16 +300,22 @@ static int rsa_init(void)
+ {
+   int ret;
+ 
++#if OPENSSL_VERSION_NUMBER < 0x1010L
+   ret = SSL_library_init();
++#else
++  ret = OPENSSL_init_ssl(0, NULL);
++#endif
+   if (!ret) {
+   fprintf(stderr, "Failure to init SSL library\n");
+   return -1;
+   }
++#if OPENSSL_VERSION_NUMBER < 0x1010L
+   SSL_load_error_strings();
+ 
+   OpenSSL_add_all_algorithms();
+   OpenSSL_add_all_digests();
+   OpenSSL_add_all_ciphers();
++#endif
+ 
+   return 0;
+ }
+@@ -335,12 +355,15 @@ err_set_rsa:
+ err_engine_init:
+   ENGINE_free(e);
+ err_engine_by_id:
++#if OPENSSL_VERSION_NUMBER < 0x1010L
+   ENGINE_cleanup();
++#endif
+   return ret;
+ }
+ 
+ static void rsa_remove(void)
+ {
++#if OPENSSL_VERSION_NUMBER < 0x1010L
+   CRYPTO_cleanup_all_ex_data();
+   ERR_free_strings();
+ #ifdef HAVE_ERR_REMOVE_THREAD_STATE
+@@ -349,6 +372,7 @@ static void rsa_remove(void)
+   ERR_remove_state(0);
+ #endif
+   EVP_cleanup();
++#endif
+ }
+ 
+ static void rsa_engine_remove(ENGINE *e)
+@@ -409,7 +433,11 @@ static int rsa_sign_with_key(RSA *rsa, struct 
checksum_algo *checksum_algo,
+   ret = rsa_err("Could not obtain signature");
+   goto err_sign;
+   }
+-  EVP_MD_CTX_cleanup(context);
++  #if OPENSSL_VERSION_NUMBER < 0x1010L
++  EVP_MD_CTX_cleanup(context);
++  #else
++  EVP_MD_CTX_reset(context);
++  #endif
+   EVP_MD_CTX_destroy(context);
+   EVP_PKEY_free(key);
+ 
+@@ -479,6 +507,7 @@ static int rsa_get_exponent(RSA *key, uint64_t *e)
+ {
+   int ret;
+   BIGNUM *bn_te;
++  const BIGNUM *key_e;
+   uint64_t te;
+ 
+   ret = -EINVAL;
+@@ -487,17 +516,18 @@ static int rsa_get_exponent(RSA *key, uint64_t *e)
+   if (!e)
+   goto cleanup;
+ 
+-  if (BN_num_bits(key->e) > 64)
++  RSA_get0_key(key, NULL, &key_e, NULL);
++  if (BN_num_bits(key_e) > 64)
+   goto cleanup;
+ 
+-  *e = BN_get_word(key->e);
++  *e = BN_get_word(key_e);
+ 
+-  if (BN_num_bits(key->e) < 33) {
++  if (BN_num_bits(key_e) < 33) {
+   ret = 0;
+   goto cleanup;
+   }
+ 
+-  bn_te = BN_dup(key->e);
++  bn_te = BN_dup(key_e);
+   if (!bn_te)
+   goto cleanup;
+ 
+@@ -527,6 +557,7 @@ int rsa_get_params(RSA *key, uint64_t *exponent, uint32_t 
*n0_invp,
+ {
+   BIGNUM *big1, *big2, *big32, *big2_32;
+   BIGNUM *n, *r, *r_squared, *tmp;
++  const BIGNUM *key_n;
+   BN_CTX *bn_ctx = BN_CTX_new();
+   int ret = 0;
+ 
+@@ -548,7 +579,8 @@ int rsa_get_params(RSA *key, uint64_t *exponent, uint32_t 
*n0_invp,
+   if (0

[OE-core] [PATCH] qemu: Add nios2 target

[Marek Vasut]

Add nios2 qemu target since nios2 is now supported in mainline.

Signed-off-by: Marek Vasut 
Cc: Richard Purdie 
Cc: Ross Burton 
---
 meta-poky/conf/distro/poky.conf | 3 ++-
 meta/recipes-devtools/qemu/qemu.inc | 2 +-
 scripts/runqemu | 4 +++-
 3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/meta-poky/conf/distro/poky.conf b/meta-poky/conf/distro/poky.conf
index 57b7e71d5f..d262f572ad 100644
--- a/meta-poky/conf/distro/poky.conf
+++ b/meta-poky/conf/distro/poky.conf
@@ -39,13 +39,14 @@ POKYQEMUDEPS = 
"${@bb.utils.contains("INCOMPATIBLE_LICENSE", "GPL-3.0", "", "pac
 DISTRO_EXTRA_RDEPENDS_append_qemuarm = " ${POKYQEMUDEPS}"
 DISTRO_EXTRA_RDEPENDS_append_qemuarm64 = " ${POKYQEMUDEPS}"
 DISTRO_EXTRA_RDEPENDS_append_qemumips = " ${POKYQEMUDEPS}"
+DISTRO_EXTRA_RDEPENDS_append_qemunios2 = " ${POKYQEMUDEPS}"
 DISTRO_EXTRA_RDEPENDS_append_qemuppc = " ${POKYQEMUDEPS}"
 DISTRO_EXTRA_RDEPENDS_append_qemux86 = " ${POKYQEMUDEPS}"
 DISTRO_EXTRA_RDEPENDS_append_qemux86-64 = " ${POKYQEMUDEPS}"
 
 TCLIBCAPPEND = ""
 
-QEMU_TARGETS ?= "arm aarch64 i386 mips mipsel mips64 mips64el ppc x86_64"
+QEMU_TARGETS ?= "arm aarch64 i386 mips mipsel mips64 mips64el nios2 ppc x86_64"
 # Other QEMU_TARGETS "sh4"
 
 PREMIRRORS ??= "\
diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index 0e1411af64..c9ac56121f 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -9,7 +9,7 @@ inherit autotools pkgconfig bluetooth
 BBCLASSEXTEND = "native nativesdk"
 
 # QEMU_TARGETS is overridable variable
-QEMU_TARGETS ?= "arm aarch64 i386 mips mipsel mips64 mips64el ppc sh4 x86_64"
+QEMU_TARGETS ?= "arm aarch64 i386 mips mipsel mips64 mips64el nios2 ppc sh4 
x86_64"
 
 EXTRA_OECONF = " \
 --prefix=${prefix} \
diff --git a/scripts/runqemu b/scripts/runqemu
index f0ddeea1bf..f4f1bba17d 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -1018,7 +1018,7 @@ class BaseConfig(object):
 """attempt to determine the appropriate qemu-system binary"""
 mach = self.get('MACHINE')
 if not mach:
-search = 
'.*(qemux86-64|qemux86|qemuarm64|qemuarm|qemumips64|qemumips64el|qemumipsel|qemumips|qemuppc).*'
+search = 
'.*(qemux86-64|qemux86|qemuarm64|qemuarm|qemumips64|qemumips64el|qemumipsel|qemumips|qemunios2|qemuppc).*'
 if self.rootfs:
 match = re.match(search, self.rootfs)
 if match:
@@ -1049,6 +1049,8 @@ class BaseConfig(object):
 qbsys = 'mipsel'
 elif mach == 'qemumips64el':
 qbsys = 'mips64el'
+elif mach == 'qemunios2':
+qbsys = 'nios2'
 
 return 'qemu-system-%s' % qbsys
 
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] libdrm: Add etnaviv support

[Marek Vasut]

Since etnaviv is now in mainline libdrm and is becoming quite mature,
add support for generating libdrm_etnaviv package.

Signed-off-by: Marek Vasut 
Cc: Richard Purdie 
Cc: Ross Burton 
---
 meta/recipes-graphics/drm/libdrm_2.4.80.bb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-graphics/drm/libdrm_2.4.80.bb 
b/meta/recipes-graphics/drm/libdrm_2.4.80.bb
index 063381f178..4726aa2c79 100644
--- a/meta/recipes-graphics/drm/libdrm_2.4.80.bb
+++ b/meta/recipes-graphics/drm/libdrm_2.4.80.bb
@@ -27,7 +27,10 @@ EXTRA_OECONF += "--disable-cairo-tests \
  --enable-etnaviv-experimental-api \
  --enable-install-test-programs \
  --disable-valgrind \
+ --enable-libkms \
+ --enable-etnaviv-experimental-api \
 "
+
 PACKAGECONFIG[manpages] = "--enable-manpages, --disable-manpages, 
libxslt-native xmlto-native"
 
 ALLOW_EMPTY_${PN}-drivers = "1"
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] manpages.bbclass: avoid QA warning when "manpages" feature not supported

[Jose Lamego]

On 05/15/2017 08:06 AM, Burton, Ross wrote:
> Hi Jose,
> 
> On 15 May 2017 at 13:24, Patrick Ohly  > wrote:
> 
> Patchwork-Status: Rejected
> 
> 
> The patch in patchworks hasn't been updated
> (https://patchwork.openembedded.org/series/6723/), I thought patchworks
> was listening for these commands now?

Sorry is miss this message.

The command line is missing the squared brackets (the following should
do the work since I may have permissions):

[Patchwork-Status: Rejected]

Guys: Do you believe we should drop the brackets requirement?

> 
> Ross 
> 
> 


-- 
Jose Lamego | OTC Embedded Platforms & Tools | GDC



signature.asc
Description: OpenPGP digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] manpages.bbclass: avoid QA warning when "manpages" feature not supported

[Jose Lamego]

Evidently, I don't have the required permissions (you can see the
previous system-generated comment).

-- 
Jose Lamego | OTC Embedded Platforms & Tools | GDC



signature.asc
Description: OpenPGP digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] ✗ patchtest: failure for u-boot: Fix build with OpenSSL 1.1.x

[Patchwork]

== Series Details ==

Series: u-boot: Fix build with OpenSSL 1.1.x
Revision: 1
URL   : https://patchwork.openembedded.org/series/6890/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Issue Added patch file is missing Upstream-Status in the header 
[test_upstream_status_presence] 
  Suggested fixAdd Upstream-Status:  to the header of 
meta/recipes-bsp/u-boot/files/0001-rsa-Fix-build-with-OpenSSL-1.1.x.patch 
(possible values: Pending, Submitted, Accepted, Backport, Denied, Inappropriate)

* Issue Series does not apply on top of target branch 
[test_series_merge_on_head] 
  Suggested fixRebase your series on top of targeted branch
  Targeted branch  master (currently at 496a9dc179)

* Issue A patch file has been added, but does not have a 
Signed-off-by tag [test_signed_off_by_presence] 
  Suggested fixSign off the added patch file 
(meta/recipes-bsp/u-boot/files/0001-rsa-Fix-build-with-OpenSSL-1.1.x.patch)



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] ✗ patchtest: failure for qemu: Add nios2 target

[Patchwork]

== Series Details ==

Series: qemu: Add nios2 target
Revision: 1
URL   : https://patchwork.openembedded.org/series/6891/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Issue Series does not apply on top of target branch 
[test_series_merge_on_head] 
  Suggested fixRebase your series on top of targeted branch
  Targeted branch  master (currently at 496a9dc179)

* Issue Series sent to the wrong mailing list or some patches from 
the series correspond to different mailing lists [test_target_mailing_list] 
  Suggested fixSend the series again to the correct mailing list (ML)
  Suggested ML p...@yoctoproject.org 
[http://git.yoctoproject.org/cgit/cgit.cgi/poky/]
  Patch's path:meta-poky/conf/distro/poky.conf



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] package_ipk: correct ipk descriptions

[Burton, Ross]

On 24 May 2017 at 21:47, Leonardo Sandoval <
leonardo.sandoval.gonza...@linux.intel.com> wrote:

> I will check that particular recipe and bb world just so see if some
> other recipe is broken with this change, then provide a v3.
>

And double check what opkg expects :)

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] libdrm: Add etnaviv support

[Trevor Woerner]

On Wed, May 24, 2017 at 4:46 PM, Marek Vasut  wrote:
> @@ -27,7 +27,10 @@ EXTRA_OECONF += "--disable-cairo-tests \
>   --enable-etnaviv-experimental-api \
>   --enable-install-test-programs \
>   --disable-valgrind \
> + --enable-libkms \
> + --enable-etnaviv-experimental-api \


--enable-etnaviv-experimental-api is already enabled a couple lines up
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/2] Allow oe-pkgdata-util package-info to display more info

[Richard Purdie]

On Tue, 2017-05-16 at 16:29 +, Peter Kjellerstedt wrote:
> > 
> > -Original Message-
> > From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
> > Sent: den 16 maj 2017 15:15
> > To: Peter Kjellerstedt ; openembedded-
> > c...@lists.openembedded.org
> > Subject: Re: [OE-core] [PATCH 0/2] Allow oe-pkgdata-util package-
> > info
> > to display more info
> > 
> > On Tue, 2017-05-16 at 12:56 +0200, Peter Kjellerstedt wrote:
> > > 
> > > After a build in our autobuilder, we use `oe-pkgdata-util
> > > package-
> > > info
> > > -f package.manifest` to store a file with information about each
> > > installed package. This is typically used to compare builds later
> > > on. Since not every difference to a package is explained by its
> > > version, we have found it beneficial to also include the SRC_URI
> > > in
> > > the generated file.
> > > 
> > > This patch set adds SRC_URI to the pkgdata that is stored for
> > > each
> > > package, and adds a new option to oe-pkgdata-util package-info,
> > > -e , that can be used to display extra variables from the
> > > pkgdata.
> > I'm going to say no to this.
> > 
> > The reason is that pkgdata is not really about collecting up all
> > build
> > information. If you want to know how two different builds differ,
> > you'd
> > use the sigdata files. If I take this patch, more will follow where
> > you
> > find some new difference you want to track and there are other
> > mechanisms I'd suggest (buildhistory and siginfo for starters). I
> > don't
> > want to turn the pkgdata files into something they're not.
> > 
> As you may have expected, that was not the response I had hoped for.
> However, I will see if we can come to a working solution that you can
> accept.
> 
> Since I hope that the change to oe-pkgdata-util is acceptable to you,
> I will focus on the change in package.bbclass.

That change is ok in principle but I don't like the usage of SRC_URI in
the help text or src_uri as a variable name in the code. I could read
that as you're not even making an effort to think bout the bigger
picture or generic patches with a variable name like that :(.

> Regarding siginfo: I assume it has the information in there
> somewhere. However, I have been working with OE for five years now,
> and it is still basically a black hole to me. I have no idea how to
> do anything useful with it.

The siginfo files are pickled python data. You can look at the code in
siggen.py (called from bitbake-dumpsig) so an example of how to view
it. They contain all the information about what went into a given task.

If two siginfo files differ, they'll have different checksums. You can
then see from bitbake-diffsigs exactly what those differences were. On
a per variable basis. They therefore offer the ultimate in build
different analysis.

> Regarding buildhistory: AFAICT there is nothing in there about
> neither recipe names nor SRC_URI. I guess that can be added, though,
> if really needed.

buildhistory is about output comparison so it probably doesn't make
sense there. I do believe it would offer more generic mechanisms than
we can afford with pkgdata though. Your best bet for generic build
comparison is still the siginfo files.

> On the other hand, we have a tool, oe-pkgdata-util, that provides a 
> simple interface to access the package information, and can produce a
> simple information file (oe-pkgdata-util package-info) with one line 
> per package. This file is simple enough that I can give it to our 
> maintenance team and they can look at it to see if there are any 
> differences they need to know about. An additional benefit here is
> that we can run oe-pkgdata-util from within a bitbake task to
> generate the file together with the other artefacts we produce for a
> release.

SRC_URI is not a piece of metadata associated with a package, its
associated with a recipe. Yes, there is recipe metadata that feeds into
packages but we really do need to have data in the right places. We
could list every possible recipe variable in that list, for the reasons
you argue. For example, perhaps S should be listed (and B) since we
might want to locate the source or the built artefacts (and so on). I
believe pkgdata should be limited to package variables though. I
appreciate that isn't what you want to hear.

> That said, I can understand that you do not want to add information
> to the pkgdata that is not really needed to build. However, would you
> accept a way to add to this data, e.g., by specifying a BitBake
> variable such as EXTRA_PKGDATA_VARS with the names of the extra
> variables that should be stored in pkgdata? That way it would not
> affect anyone unless they actually need this extra data, and I would
> not have the burden of carrying a backported version of
> package.bbclass forever in our layers with all the extra maintenance
> that incurs.

The data from pkgdata is really meant to be used by the package_write_*
tasks as a mechanism to transfer data from the do_package t

Re: [OE-core] [PATCH] libgcrypt: Revert to inheriting from binconfig

[Richard Purdie]

On Wed, 2017-05-24 at 17:25 +0100, Burton, Ross wrote:
> 
> On 24 May 2017 at 14:52, Mike Crowe  wrote:
> > Oh, I thought that binconfig.bbclass swung through hoops in order
> > to make
> > the scripts work well enough. Is that not true?
> > 
> > Many other recipes are still inheriting binconfig rather than
> > binconfig-disabled: apr, curl, gnutls, libtasn1.
> > 
> binconfig goes through hoops that are just not required with
> pkgconfig, and the hoops are hacks which may not be reliable.  I
> can't remember the details but I do remember that libgcrypt/gnupg was
> a worst offender here.
> 
> CCing Richard to see if he can remember why.
> 
> In the glorious future removing all binconfig scripts would be the
> ideal, in my opinion.  Alternatively replacing them with glorified
> pkgconfig wrappers.

We made a choice back then to go ahead and migrate these pieces to pkg-
config regardless of upstream's views since its so much cleaner and
less error prone than -config shell scripts which need hacking. We do
also patch the autoconf macros those pieces of software ship so that
pkg-config is used by the standard macros which covers most users
(since we reautoconf software).

Yes, binconfig.bbclass does have code which goes through hoops but I
don't think anyone would argue that code is pleasant or even scalable.
You can't easily change any of the sed expressions since you can't
easily know what set of file content they operate on and what side
effects any given change might have. The upstreams do change the
contents of the files over time and we can't really know if any given
replacements are still needed or if a new replacement may break other
files. Its also bad in that the on target versions need to differ to
the version used during cross building so you can't even have one
version of the file. I've seen these problems happen, my patches in the
past were after being burnt by that code.

For those reasons I believe we should be removing usage of
binconfig.bbclass from the system where we can if at all possible and
replacing it, even if it increases our custom patch load a little. I
know its used in a few places and I never did completely get rid of all
the config files but I still believe doing so would in fact be a
worthwhile effort.

I appreciate that does cause some pain as we're doing something
differently but I also believe it is justified. I would suggest
reminding these upstreams who won't at least allow pkg-config in
parallel that this does cause pain in the hope that if multiple people
report it, they may rethink things.

Cheers,

Richard


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [meta-oe][PATCH v3] openssh: Atomically generate host keys

[Joshua Watt]

Generating the host keys atomically prevents power interruptions during
the first boot from leaving the key files incomplete, which often
prevents users from being able to ssh into the device.
---
 meta/recipes-connectivity/openssh/openssh/init | 21 +++--
 .../openssh/openssh/sshd-check-key | 36 ++
 .../openssh/openssh/sshdgenkeys.service| 24 +++
 meta/recipes-connectivity/openssh/openssh_7.5p1.bb |  8 +
 4 files changed, 60 insertions(+), 29 deletions(-)
 create mode 100644 meta/recipes-connectivity/openssh/openssh/sshd-check-key

diff --git a/meta/recipes-connectivity/openssh/openssh/init 
b/meta/recipes-connectivity/openssh/openssh/init
index 1f63725..22124a9 100644
--- a/meta/recipes-connectivity/openssh/openssh/init
+++ b/meta/recipes-connectivity/openssh/openssh/init
@@ -45,23 +45,10 @@ check_config() {
 }
 
 check_keys() {
-   # create keys if necessary
-   if [ ! -f $HOST_KEY_RSA ]; then
-   echo "  generating ssh RSA key..."
-   ssh-keygen -q -f $HOST_KEY_RSA -N '' -t rsa
-   fi
-   if [ ! -f $HOST_KEY_ECDSA ]; then
-   echo "  generating ssh ECDSA key..."
-   ssh-keygen -q -f $HOST_KEY_ECDSA -N '' -t ecdsa
-   fi
-   if [ ! -f $HOST_KEY_DSA ]; then
-   echo "  generating ssh DSA key..."
-   ssh-keygen -q -f $HOST_KEY_DSA -N '' -t dsa
-   fi
-   if [ ! -f $HOST_KEY_ED25519 ]; then
-   echo "  generating ssh ED25519 key..."
-   ssh-keygen -q -f $HOST_KEY_ED25519 -N '' -t ed25519
-   fi
+@LIBEXECDIR@/sshd-check-key $HOST_KEY_RSA rsa
+@LIBEXECDIR@/sshd-check-key $HOST_KEY_ECDSA ecdsa
+@LIBEXECDIR@/sshd-check-key $HOST_KEY_DSA dsa
+@LIBEXECDIR@/sshd-check-key $HOST_KEY_ED25519 ed25519
 }
 
 export PATH="${PATH:+$PATH:}/usr/sbin:/sbin"
diff --git a/meta/recipes-connectivity/openssh/openssh/sshd-check-key 
b/meta/recipes-connectivity/openssh/openssh/sshd-check-key
new file mode 100644
index 000..d2613af
--- /dev/null
+++ b/meta/recipes-connectivity/openssh/openssh/sshd-check-key
@@ -0,0 +1,36 @@
+#! /bin/sh
+set -e
+
+NAME="$1"
+TYPE="$2"
+
+if [ -z "$NAME" ] || [ -z "$TYPE" ]; then
+echo "Usage: $0 NAME TYPE"
+exit 1;
+fi
+
+DIR="$(dirname "$NAME")"
+
+if [ ! -f "$NAME" ]; then
+echo "  generating ssh $TYPE key..."
+ssh-keygen -q -f "${NAME}.tmp" -N '' -t $TYPE
+
+# Move (Atomically rename) files
+mv -f "${NAME}.tmp.pub" "${NAME}.pub"
+
+# This sync does double duty: Ensuring that the data in the temporary
+# private key file is on disk before the rename, and ensuring that the
+# public key rename is completed before the private key rename, since we
+# switch on the existence of the private key to trigger key generation.
+# This does mean it is possible for the public key to exist, but be garbage
+# but this is OK because in that case the private key won't exist and the
+# keys will be regenerated.
+#
+# In the event that sync understands arguments that limit what it tries to
+# fsync(), we provided them. If it does not, it will simply call sync()
+# which is just as well
+sync "${NAME}.pub" "$DIR" "${NAME}.tmp"
+
+mv -f "${NAME}.tmp" "${NAME}"
+fi
+
diff --git a/meta/recipes-connectivity/openssh/openssh/sshdgenkeys.service 
b/meta/recipes-connectivity/openssh/openssh/sshdgenkeys.service
index 148e6ad..5d08b53 100644
--- a/meta/recipes-connectivity/openssh/openssh/sshdgenkeys.service
+++ b/meta/recipes-connectivity/openssh/openssh/sshdgenkeys.service
@@ -1,22 +1,22 @@
 [Unit]
 Description=OpenSSH Key Generation
 RequiresMountsFor=/var /run
-ConditionPathExists=!/var/run/ssh/ssh_host_rsa_key
-ConditionPathExists=!/var/run/ssh/ssh_host_dsa_key
-ConditionPathExists=!/var/run/ssh/ssh_host_ecdsa_key
-ConditionPathExists=!/var/run/ssh/ssh_host_ed25519_key
-ConditionPathExists=!/etc/ssh/ssh_host_rsa_key
-ConditionPathExists=!/etc/ssh/ssh_host_dsa_key
-ConditionPathExists=!/etc/ssh/ssh_host_ecdsa_key
-ConditionPathExists=!/etc/ssh/ssh_host_ed25519_key
+ConditionPathExists=|!/var/run/ssh/ssh_host_rsa_key
+ConditionPathExists=|!/var/run/ssh/ssh_host_dsa_key
+ConditionPathExists=|!/var/run/ssh/ssh_host_ecdsa_key
+ConditionPathExists=|!/var/run/ssh/ssh_host_ed25519_key
+ConditionPathExists=|!/etc/ssh/ssh_host_rsa_key
+ConditionPathExists=|!/etc/ssh/ssh_host_dsa_key
+ConditionPathExists=|!/etc/ssh/ssh_host_ecdsa_key
+ConditionPathExists=|!/etc/ssh/ssh_host_ed25519_key
 
 [Service]
 Environment="SYSCONFDIR=/etc/ssh"
 EnvironmentFile=-/etc/default/ssh
 ExecStart=@BASE_BINDIR@/mkdir -p $SYSCONFDIR
-ExecStart=@BINDIR@/ssh-keygen -q -f ${SYSCONFDIR}/ssh_host_rsa_key -N '' -t rsa
-ExecStart=@BINDIR@/ssh-keygen -q -f ${SYSCONFDIR}/ssh_host_dsa_key -N '' -t dsa
-ExecStart=@BINDIR@/ssh-keygen -q -f ${SYSCONFDIR}/ssh_host_ecdsa_key -N '' -t 
ecdsa
-ExecStart=@BINDIR@/ssh-keygen -q -f ${SYSCONFDIR}/ssh_host_ed25519_key -N '' 
-

[OE-core] [PATCH v2] curl: fix libssl error for ARMv8

[Huang Qiyu]

curl + gnutls can not work on ARMv8 32BE, so change it to curl + ssl when the 
target is aarch64.

The error is as follow:
curl: (35) gnutls_handshake() failed: Bad record MAC

When set machine to qemuarm64 in local.conf, this patch will work.

Signed-off-by: Huang Qiyu 
---
 meta/recipes-support/curl/curl_7.54.0.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-support/curl/curl_7.54.0.bb 
b/meta/recipes-support/curl/curl_7.54.0.bb
index ce5ca37..7421617 100644
--- a/meta/recipes-support/curl/curl_7.54.0.bb
+++ b/meta/recipes-support/curl/curl_7.54.0.bb
@@ -21,6 +21,7 @@ CVE_PRODUCT = "libcurl"
 inherit autotools pkgconfig binconfig multilib_header
 
 PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'ipv6', d)} gnutls 
proxy zlib"
+PACKAGECONFIG_aarch64 ??= "${@bb.utils.contains("DISTRO_FEATURES", "ipv6", 
"ipv6", "", d)} ssl proxy zlib"
 PACKAGECONFIG_class-native = "ipv6 proxy ssl zlib"
 PACKAGECONFIG_class-nativesdk = "ipv6 proxy ssl zlib"
 
-- 
2.7.4



-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] ✗ patchtest: failure for openssh: Atomically generate host keys (rev3)

[Patchwork]

== Series Details ==

Series: openssh: Atomically generate host keys (rev3)
Revision: 3
URL   : https://patchwork.openembedded.org/series/6626/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Patch[meta-oe,v3] openssh: Atomically generate host keys
 Issue Patch is missing Signed-off-by [test_signed_off_by_presence] 
  Suggested fixSign off the patch (either manually or with "git commit 
--amend -s")



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 11/15] linux-yocto: Enable drm by default

[Bruce Ashfield]

On Tue, May 23, 2017 at 3:36 PM, Bruce Ashfield 
wrote:

>
>
> On Mon, May 22, 2017 at 1:06 PM, Khem Raj  wrote:
>
>> >> +SRC_URI += "file://drm.cfg"
>> >
>> >
>> >
>> > If anything gets added to the default configurations, they need to go
>> into
>> > the kernel-cache
>> > and then be included by the relevant kernel types there.
>> >
>> > If you want, I can take care of switching things to that format.
>> >
>>
>> yes please.
>>
>
> Will do. I'll make it available to all active kernel versions + future
> ones.
>

As it turns out, we already have a similar fragment for vmware guests:

cfg/vmware-guest.cfg



CONFIG_VMWARE_BALLOON=m

CONFIG_VMWARE_PVSCSI=y

CONFIG_VMWARE_VMCI=m

CONFIG_VSOCKETS=m

CONFIG_VMWARE_VMCI_VSOCKETS=m

CONFIG_VMXNET3=y

CONFIG_DRM_VMWGFX=m

CONFIG_DRM_VMWGFX_FBCON=y

CONFIG_FUSION=y

CONFIG_FUSION_SPI=y

CONFIG_FUSION_FC=y

CONFIG_FUSION_SAS=y

CONFIG_FUSION_MAX_SGE=128

CONFIG_FUSION_CTL=y

CONFIG_FUSION_LAN=y

CONFIG_FUSION_LOGGING=y

CONFIG_SCSI_MPT2SAS=y

CONFIG_SCSI_MPT2SAS_MAX_SGE=128

CONFIG_SCSI_MPT2SAS_LOGGING=y

CONFIG_SCSI_MPT3SAS=y

CONFIG_SCSI_MPT3SAS_MAX_SGE=128

CONFIG_SCSI_MPT3SAS_LOGGING=y
-

To stay consistent with that naming, I'll call this virtual-box-guest.cfg,
and it can be enabled
via KERNEL_FEATURES when needed.

I'm hesitant to globally enable it, since we don't need those modules on
all linux-yocto
kernels, just ones that are going to run on virtual box.

I could enable them for qemux86*, since those already have virtio configs
enabled by
default and these have a similar goal.

Thoughts ? I'd like to make sure that sounds reasonable, before spending
the time to
make the changes and test.

Bruce


> Cheers,
>
> Bruce
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await thee
> at its end"
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 11/15] linux-yocto: Enable drm by default

[Khem Raj]

On Wed, May 24, 2017 at 7:40 PM, Bruce Ashfield
 wrote:
>
>
> On Tue, May 23, 2017 at 3:36 PM, Bruce Ashfield 
> wrote:
>>
>>
>>
>> On Mon, May 22, 2017 at 1:06 PM, Khem Raj  wrote:
>>>
>>> >> +SRC_URI += "file://drm.cfg"
>>> >
>>> >
>>> >
>>> > If anything gets added to the default configurations, they need to go
>>> > into
>>> > the kernel-cache
>>> > and then be included by the relevant kernel types there.
>>> >
>>> > If you want, I can take care of switching things to that format.
>>> >
>>>
>>> yes please.
>>
>>
>> Will do. I'll make it available to all active kernel versions + future
>> ones.
>
>
> As it turns out, we already have a similar fragment for vmware guests:
>
> cfg/vmware-guest.cfg
>
> 
>
> CONFIG_VMWARE_BALLOON=m
>
> CONFIG_VMWARE_PVSCSI=y
>
> CONFIG_VMWARE_VMCI=m
>
> CONFIG_VSOCKETS=m
>
> CONFIG_VMWARE_VMCI_VSOCKETS=m
>
> CONFIG_VMXNET3=y
>
> CONFIG_DRM_VMWGFX=m
>
> CONFIG_DRM_VMWGFX_FBCON=y
>
> CONFIG_FUSION=y
>
> CONFIG_FUSION_SPI=y
>
> CONFIG_FUSION_FC=y
>
> CONFIG_FUSION_SAS=y
>
> CONFIG_FUSION_MAX_SGE=128
>
> CONFIG_FUSION_CTL=y
>
> CONFIG_FUSION_LAN=y
>
> CONFIG_FUSION_LOGGING=y
>
> CONFIG_SCSI_MPT2SAS=y
>
> CONFIG_SCSI_MPT2SAS_MAX_SGE=128
>
> CONFIG_SCSI_MPT2SAS_LOGGING=y
>
> CONFIG_SCSI_MPT3SAS=y
>
> CONFIG_SCSI_MPT3SAS_MAX_SGE=128
>
> CONFIG_SCSI_MPT3SAS_LOGGING=y
>
> -
>
> To stay consistent with that naming, I'll call this virtual-box-guest.cfg,
> and it can be enabled
> via KERNEL_FEATURES when needed.
>
> I'm hesitant to globally enable it, since we don't need those modules on all
> linux-yocto
> kernels, just ones that are going to run on virtual box.
>
> I could enable them for qemux86*, since those already have virtio configs
> enabled by
> default and these have a similar goal.
>
> Thoughts ? I'd like to make sure that sounds reasonable, before spending the
> time to
> make the changes and test.
>

I would suggest to enable them by default since these are modules they
dont impact the size of kernel itself. Then we can use recommends to
choose them in machine configs.

> Bruce
>
>>
>> Cheers,
>>
>> Bruce
>>
>>
>>
>> --
>> "Thou shalt not follow the NULL pointer, for chaos and madness await thee
>> at its end"
>
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at
> its end"
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] nss: Upgrade 3.29.1 to 3.30.2

[Fan Xin]

Network Security Services (NSS) 3.30.2 is a patch release for NSS 3.30.

The bug fixes in NSS 3.30.2 are as follows:

Bug 1350859 - March 2017 batch of root CA changes
Bug 1349705 - Implemented domain name constraints for CA

Signed-off-by: Fan Xin 
---
 meta/recipes-support/nss/nss_3.29.1.bb | 246 -
 meta/recipes-support/nss/nss_3.30.2.bb | 246 +
 2 files changed, 246 insertions(+), 246 deletions(-)
 delete mode 100644 meta/recipes-support/nss/nss_3.29.1.bb
 create mode 100644 meta/recipes-support/nss/nss_3.30.2.bb

diff --git a/meta/recipes-support/nss/nss_3.29.1.bb 
b/meta/recipes-support/nss/nss_3.29.1.bb
deleted file mode 100644
index 48db031..000
--- a/meta/recipes-support/nss/nss_3.29.1.bb
+++ /dev/null
@@ -1,246 +0,0 @@
-SUMMARY = "Mozilla's SSL and TLS implementation"
-DESCRIPTION = "Network Security Services (NSS) is a set of libraries \
-designed to support cross-platform development of \
-security-enabled client and server applications. \
-Applications built with NSS can support SSL v2 and v3, \
-TLS, PKCS 5, PKCS 7, PKCS 11, PKCS 12, S/MIME, X.509 \
-v3 certificates, and other security standards."
-HOMEPAGE = "http://www.mozilla.org/projects/security/pki/nss/";
-SECTION = "libs"
-
-LICENSE = "MPL-2.0 | (MPL-2.0 & GPL-2.0+) | (MPL-2.0 & LGPL-2.1+)"
-
-LIC_FILES_CHKSUM = "file://nss/COPYING;md5=3b1e88e1b9c0b5a4b2881d46cce06a18 \
-
file://nss/lib/freebl/mpi/doc/LICENSE;md5=491f158d09d948466afce85d6f1fe18f \
-
file://nss/lib/freebl/mpi/doc/LICENSE-MPL;md5=5d425c8f3157dbf212db2ec53d9e5132"
-
-SRC_URI = 
"http://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_29_1_RTM/src/${BP}.tar.gz
 \
-   file://nss.pc.in \
-   file://signlibs.sh \
-   file://0001-nss-fix-support-cross-compiling.patch \
-   file://nss-no-rpath-for-cross-compiling.patch \
-   file://nss-fix-incorrect-shebang-of-perl.patch \
-   file://nss-fix-nsinstall-build.patch \
-   file://disable-Wvarargs-with-clang.patch \
-   file://pqg.c-ULL_addend.patch \
-   file://Fix-compilation-for-X32.patch \
-   file://0001-Fix-warnings-found-with-gcc7.patch \
-   "
-SRC_URI[md5sum] = "0525d1a45931892daa0f368d379d4aa4"
-SRC_URI[sha256sum] = 
"47259bc5c4439d8228d7c577ea652ed140588f27eae8ebb39cc91057aea37366"
-
-UPSTREAM_CHECK_URI = 
"https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_Releases";
-UPSTREAM_CHECK_REGEX = "NSS_(?P.+)_release_notes"
-
-inherit siteinfo
-
-DEPENDS = "sqlite3 nspr zlib nss-native"
-DEPENDS_class-native = "sqlite3-native nspr-native zlib-native"
-RDEPENDS_${PN}-smime = "perl"
-
-TD = "${S}/tentative-dist"
-TDS = "${S}/tentative-dist-staging"
-
-TARGET_CC_ARCH += "${LDFLAGS}"
-
-do_configure_prepend_libc-musl () {
-sed -i -e '/-DHAVE_SYS_CDEFS_H/d' ${S}/nss/lib/dbm/config/config.mk
-}
-
-do_compile_prepend_class-native() {
-export NSPR_INCLUDE_DIR=${STAGING_INCDIR_NATIVE}
-export NSPR_LIB_DIR=${STAGING_LIBDIR_NATIVE}
-export NSS_ENABLE_WERROR=0
-}
-
-do_compile_prepend_class-nativesdk() {
-export LDFLAGS=""
-}
-
-do_compile_prepend_class-native() {
-# Need to set RPATH so that chrpath will do its job correctly
-RPATH="-Wl,-rpath-link,${STAGING_LIBDIR_NATIVE} 
-Wl,-rpath-link,${STAGING_BASE_LIBDIR_NATIVE} 
-Wl,-rpath,${STAGING_LIBDIR_NATIVE} -Wl,-rpath,${STAGING_BASE_LIBDIR_NATIVE}"
-}
-
-do_compile() {
-export CROSS_COMPILE=1
-export NATIVE_CC="gcc"
-export NATIVE_FLAGS="${HOST_CFLAGS}"
-export BUILD_OPT=1
-
-export FREEBL_NO_DEPEND=1
-export FREEBL_LOWHASH=1
-
-export LIBDIR=${libdir}
-export MOZILLA_CLIENT=1
-export NS_USE_GCC=1
-export NSS_USE_SYSTEM_SQLITE=1
-export NSS_ENABLE_ECC=1
-
-export OS_RELEASE=3.4
-export OS_TARGET=Linux
-export OS_ARCH=Linux
-
-if [ "${TARGET_ARCH}" = "powerpc" ]; then
-OS_TEST=ppc
-elif [ "${TARGET_ARCH}" = "powerpc64" ]; then
-OS_TEST=ppc64
-elif [ "${TARGET_ARCH}" = "mips" -o "${TARGET_ARCH}" = "mipsel" -o 
"${TARGET_ARCH}" = "mips64" -o "${TARGET_ARCH}" = "mips64el" ]; then
-OS_TEST=mips
-else
-OS_TEST="${TARGET_ARCH}"
-fi
-
-if [ "${SITEINFO_BITS}" = "64" ]; then
-export USE_64=1
-elif [ "${TARGET_ARCH}" = "x86_64" -a "${SITEINFO_BITS}" = "32" ]; then
-export USE_X32=1
-fi
-
-export NSS_DISABLE_GTESTS=1
-
-# We can modify CC in the environment, but if we set it via an
-# argument to make, nsinstall, a host program, will also build with it!
-#
-export CC="${CC} -g"
-make -C ./nss CCC="${CXX} -g" \
-OS_TEST=${OS_TEST} \
-RPATH="${RPATH}"
-}
-do_compile[vardepsexclude] += "SITEINFO_BITS"
-
-
-do_install_prepend_class-nativesdk() {
-export LDFLAGS=""
-}
-
-do_install() {
-export CROSS_COMPILE=1
-export NATIVE_CC="gcc"
-export BUILD_OPT=1
-
-export

Re: [OE-core] [PATCH 1/1] libpcap: add native package

[Kang Kai]

On 2017年05月24日 21:19, Kang Kai wrote:

On 2017年05月24日 17:33, kai.k...@windriver.com wrote:

From: Kai Kang 

Add package libcap-native required by recipe daq-native in layer
meta-networking. And daq-native is added to fix snort start error.


I just realize that it only needs daq-native provide a shell script, 
so libpcap-native may not be needed. I'll figure it out.

Please ignore this patch for now.


Unfortunately there is a var STATIC_LIBS in the shell script 
daq-modules-config from package daq-native which depends on configure 
options.
If doesn't build with libpcap for daq-native, then no '-lpcap' in the 
output of the shell script daq-modules-config and build snort will fail.


So libpcap-native is needed indeed, and please help the review the 
patch, thanks.


BTW, the typo 'libcap-native' in commit message has been updated in 
poky-contrib git repo.


Thanks,
Kai




Thanks,
Kai



Signed-off-by: Kai Kang 
---
  meta/recipes-connectivity/libpcap/libpcap.inc | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/meta/recipes-connectivity/libpcap/libpcap.inc 
b/meta/recipes-connectivity/libpcap/libpcap.inc

index 6635779..e57ea87 100644
--- a/meta/recipes-connectivity/libpcap/libpcap.inc
+++ b/meta/recipes-connectivity/libpcap/libpcap.inc
@@ -38,3 +38,5 @@ CXXFLAGS_prepend = "-I${S} "
  do_configure_prepend () {
  sed -i -e's,^V_RPATH_OPT=.*$,V_RPATH_OPT=,' ${S}/pcap-config.in
  }
+
+BBCLASSEXTEND = "native"





--
Regards,
Neil | Kai Kang

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core