date:20200214

From: "Jeremy A. Puhlman" 

All of the .pc files contain the path to ${libdir} which fails
in a multilib rpm image.

Signed-off-by: Jeremy A. Puhlman 
---
 meta/recipes-devtools/subversion/subversion_1.13.0.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-devtools/subversion/subversion_1.13.0.bb 
b/meta/recipes-devtools/subversion/subversion_1.13.0.bb
index 9c1281a63e..6879f1249f 100644
--- a/meta/recipes-devtools/subversion/subversion_1.13.0.bb
+++ b/meta/recipes-devtools/subversion/subversion_1.13.0.bb
@@ -37,6 +37,8 @@ EXTRA_OECONF = " \
 ac_cv_path_RUBY=none \
 "
 
+EXTRA_OEMAKE += "pkgconfig_dir=${libdir}/pkgconfig"
+
 acpaths = "-I build/ -I build/ac-macros/"
 
 CPPFLAGS += "-P"
-- 
2.13.3

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

[OE-core] [PATCH 3/6] libsndfile1: mutlilibize sndfile.h

From: "Jeremy A. Puhlman" 

sndfile.h can differ depending on the combined architectures.

Signed-off-by: Jeremy A. Puhlman 
---
 meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb 
b/meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb
index 7855008f3d..b100108766 100644
--- a/meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb
+++ b/meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb
@@ -32,7 +32,11 @@ PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 
'alsa', d)}"
 PACKAGECONFIG[alsa] = "--enable-alsa,--disable-alsa,alsa-lib"
 PACKAGECONFIG[regtest] = "--enable-sqlite,--disable-sqlite,sqlite3"
 
-inherit autotools lib_package pkgconfig
+inherit autotools lib_package pkgconfig multilib_header
+
+do_install_append() {
+oe_multilib_header sndfile.h
+}
 
 # This can't be replicated and is just a memory leak.
 # https://github.com/erikd/libsndfile/issues/398
-- 
2.13.3

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

[OE-core] [PATCH 6/6] x11perf: make x11perfcomp a mulitlib script

From: "Jeremy A. Puhlman" 

x11perfcomp encodes the library paths in the script.

Signed-off-by: Jeremy A. Puhlman 
---
 meta/recipes-graphics/xorg-app/x11perf_1.6.1.bb | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/recipes-graphics/xorg-app/x11perf_1.6.1.bb 
b/meta/recipes-graphics/xorg-app/x11perf_1.6.1.bb
index 33c0c8a95c..c4d443bfb9 100644
--- a/meta/recipes-graphics/xorg-app/x11perf_1.6.1.bb
+++ b/meta/recipes-graphics/xorg-app/x11perf_1.6.1.bb
@@ -13,6 +13,10 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=428ca4d67a41fcd4fc3283dce9bbda7e \
 
 PE = "1"
 
+inherit multilib_script
+
+MULTILIB_SCRIPTS = "${PN}:${bindir}/x11perfcomp"
+
 do_install_append_class-target () {
 sed -i -e 's:${HOSTTOOLS_DIR}/::g' ${D}${bindir}/x11perfcomp
 }
-- 
2.13.3

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

[OE-core] [PATCH] tcf-agent: Mangle arch for armeb

From: "Jeremy A. Puhlman" 

Signed-off-by: Jeremy A. Puhlman 
---
 meta/recipes-devtools/tcf-agent/tcf-agent_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb 
b/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb
index e0a07a9375..ed14fe66b1 100644
--- a/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb
+++ b/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb
@@ -29,7 +29,7 @@ INITSCRIPT_NAME = "tcf-agent"
 INITSCRIPT_PARAMS = "start 99 3 5 . stop 20 0 1 2 6 ."
 
 # mangling needed for make
-MAKE_ARCH = "`echo ${TARGET_ARCH} | sed s,i.86,i686, | sed s,aarch64.*,a64,`"
+MAKE_ARCH = "`echo ${TARGET_ARCH} | sed s,i.86,i686, | sed s,aarch64.*,a64, | 
sed s,armeb,arm,`"
 MAKE_OS = "`echo ${TARGET_OS} | sed s,^linux.*,GNU/Linux,`"
 
 EXTRA_OEMAKE = "MACHINE=${MAKE_ARCH} OPSYS=${MAKE_OS} 'CC=${CC}' 'AR=${AR}'"
-- 
2.13.3

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

[OE-core] [PATCH 4/6] libassuan: multilib header for assuan.h

From: "Jeremy A. Puhlman" 

assuan.h is generated and can differ between mutlilibs.

Signed-off-by: Jeremy Puhlman 
---
 meta/recipes-support/libassuan/libassuan_2.5.3.bb | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-support/libassuan/libassuan_2.5.3.bb 
b/meta/recipes-support/libassuan/libassuan_2.5.3.bb
index 6fb3d2f3a4..52b4c0f1b9 100644
--- a/meta/recipes-support/libassuan/libassuan_2.5.3.bb
+++ b/meta/recipes-support/libassuan/libassuan_2.5.3.bb
@@ -22,11 +22,15 @@ SRC_URI[sha256sum] = 
"91bcb0403866b4e7c4bc1cc52ed4c364a9b5414b3994f718c70303f7f7
 
 BINCONFIG = "${bindir}/libassuan-config"
 
-inherit autotools texinfo binconfig-disabled pkgconfig
+inherit autotools texinfo binconfig-disabled pkgconfig multilib_header
 
 do_configure_prepend () {
# Else these could be used in preference to those in aclocal-copy
rm -f ${S}/m4/*.m4
 }
 
+do_install_append () {
+oe_multilib_header assuan.h
+}
+
 BBCLASSEXTEND = "native nativesdk"
-- 
2.13.3

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

[OE-core] [PATCH 1/6] bind: add mulitlib_header for platform.h

From: "Jeremy A. Puhlman" 

Signed-off-by: Jeremy A. Puhlman 
---
 meta/recipes-connectivity/bind/bind_9.11.13.bb | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-connectivity/bind/bind_9.11.13.bb 
b/meta/recipes-connectivity/bind/bind_9.11.13.bb
index 338d6c717a..4e64171cc1 100644
--- a/meta/recipes-connectivity/bind/bind_9.11.13.bb
+++ b/meta/recipes-connectivity/bind/bind_9.11.13.bb
@@ -31,7 +31,7 @@ UPSTREAM_CHECK_REGEX = 
"(?P9.(11|16|20|24|28)(\.\d+)+(-P\d+)*)/"
 # don't report it here since dhcpd is already recent enough.
 CVE_CHECK_WHITELIST += "CVE-2019-6470"
 
-inherit autotools update-rc.d systemd useradd pkgconfig multilib_script
+inherit autotools update-rc.d systemd useradd pkgconfig multilib_script 
multilib_header
 
 MULTILIB_SCRIPTS = "${PN}:${bindir}/bind9-config ${PN}:${bindir}/isc-config.sh"
 
@@ -105,6 +105,8 @@ do_install_append() {
install -d ${D}${sysconfdir}/tmpfiles.d
echo "d /run/named 0755 bind bind - -" > 
${D}${sysconfdir}/tmpfiles.d/bind.conf
fi
+
+oe_multilib_header isc/platform.h
 }
 
 CONFFILES_${PN} = " \
-- 
2.13.3

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

[OE-core] [PATCH 2/6] libxslt: multilib_header xsltconfig.h

From: "Jeremy A. Puhlman" 

xsltconfig.h is generated and can be different between multilibs

Signed-off-by: Jeremy Puhlman 
---
 meta/recipes-support/libxslt/libxslt_1.1.34.bb | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-support/libxslt/libxslt_1.1.34.bb 
b/meta/recipes-support/libxslt/libxslt_1.1.34.bb
index ad37b5a44a..1961bb5b31 100644
--- a/meta/recipes-support/libxslt/libxslt_1.1.34.bb
+++ b/meta/recipes-support/libxslt/libxslt_1.1.34.bb
@@ -20,7 +20,7 @@ S = "${WORKDIR}/libxslt-${PV}"
 
 BINCONFIG = "${bindir}/xslt-config"
 
-inherit autotools pkgconfig binconfig-disabled lib_package
+inherit autotools pkgconfig binconfig-disabled lib_package multilib_header
 
 do_configure_prepend () {
# We don't DEPEND on binutils for ansidecl.h so ensure we don't use the 
header.
@@ -43,6 +43,10 @@ do_install_append_class-native () {
 create_wrapper ${D}/${bindir}/xsltproc 
XML_CATALOG_FILES=${sysconfdir}/xml/catalog
 }
 
+do_install_append () {
+   oe_multilib_header libxslt/xsltconfig.h
+}
+
 FILES_${PN} += "${libdir}/libxslt-plugins"
 FILES_${PN}-dev += "${libdir}/xsltConf.sh"
 
-- 
2.13.3

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

Re: [OE-core] [PATCH] db: Fix timespec length assumptions

2020-02-14 Thread Bruce Ashfield

On Fri, Feb 14, 2020 at 5:33 PM Khem Raj  wrote:
>
> This should fix the vdso crashes seen with kernel 5.0+

cool. I'll test this locally and follow up over the weekend.

Bruce

>
> python3[11312] general protection fault ip:b7e966b0 sp:bf8175cc error:0 in 
> libc.so[b7e8b000+6b000]
>
> Signed-off-by: Khem Raj 
> Cc: Bruce Ashfield 
> ---
>  ...001-clock-Do-not-define-own-timespec.patch | 45 +++
>  meta/recipes-support/db/db_5.3.28.bb  |  1 +
>  2 files changed, 46 insertions(+)
>  create mode 100644 
> meta/recipes-support/db/db/0001-clock-Do-not-define-own-timespec.patch
>
> diff --git 
> a/meta/recipes-support/db/db/0001-clock-Do-not-define-own-timespec.patch 
> b/meta/recipes-support/db/db/0001-clock-Do-not-define-own-timespec.patch
> new file mode 100644
> index 00..9d51a44a26
> --- /dev/null
> +++ b/meta/recipes-support/db/db/0001-clock-Do-not-define-own-timespec.patch
> @@ -0,0 +1,45 @@
> +From 96b303caf70a7635953c36e5bfb9ad6e75cb7637 Mon Sep 17 00:00:00 2001
> +From: Khem Raj 
> +Date: Fri, 14 Feb 2020 14:12:59 -0800
> +Subject: [PATCH] clock: Do not define own timespec
> +
> +timespec is provided by libc and its best left to libc
> +os_gettime takes a db_timespec and passed its address to clock_gettime
> +which assumes that db_timespec and timespec are same but actually
> +its 12-bytes here and libc has 16-bytes
> +
> +This can cause problems especially with 64bit time_t
> +
> +Upstream-Status: Pending
> +Signed-off-by: Khem Raj 
> +---
> + src/dbinc/clock.h | 17 +
> + 1 file changed, 1 insertion(+), 16 deletions(-)
> +
> +--- a/src/dbinc/clock.h
>  b/src/dbinc/clock.h
> +@@ -44,22 +44,8 @@
> + extern "C" {
> + #endif
> +
> +-/*
> +- * This declaration is POSIX-compatible.  Because there are lots of 
> different
> +- * time.h include file patterns out there, it's easier to declare our own 
> name
> +- * in all cases than to try and discover if a system has a struct timespec.
> +- * For the same reason, and because we'd have to #include  in 
> db.h,
> +- * we don't export any timespec structures in the DB API, even in places 
> where
> +- * it would make sense, like the replication statistics information.
> +- */
> +-typedef struct {
> +-  time_t  tv_sec; /* seconds */
> +-#ifdef HAVE_MIXED_SIZE_ADDRESSING
> +-  int32_t tv_nsec;
> +-#else
> +-  longtv_nsec;/* nanoseconds */
> +-#endif
> +-} db_timespec;
> ++#include 
> ++#define db_timespec struct timespec
> +
> + /* Operations on timespecs */
> + #undeftimespecclear
> diff --git a/meta/recipes-support/db/db_5.3.28.bb 
> b/meta/recipes-support/db/db_5.3.28.bb
> index a2969055a6..badb79f9ea 100644
> --- a/meta/recipes-support/db/db_5.3.28.bb
> +++ b/meta/recipes-support/db/db_5.3.28.bb
> @@ -26,6 +26,7 @@ SRC_URI += "file://fix-parallel-build.patch \
>  
> file://0001-configure-Add-explicit-tag-options-to-libtool-invoca.patch \
>  file://sequence-type.patch \
>  
> file://0001-Fix-libc-compatibility-by-renaming-atomic_init-API.patch \
> +file://0001-clock-Do-not-define-own-timespec.patch \
> "
>  # We are not interested in official latest 6.x versions;
>  # let's track what debian is using.
> --
> 2.25.0
>


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

Re: [OE-core] [PATCH 1/3] musl: Update to latest tip

On Fri, Feb 14, 2020 at 5:02 PM Andre McCurdy  wrote:
>
> On Fri, Feb 14, 2020 at 7:42 AM Khem Raj  wrote:
> >
> > Detailed changelog is here [1]
> >
> > [1] 
> > https://git.musl-libc.org/cgit/musl/log/?qt=range=e6093b5a870a38ebfb3e54382acd48c698bde15d..a662220df547e5c2446518e74440a7d834f9ebe6
>
> Up to now, musl version updates have basically always just made things
> better and there's never been a good reason not to switch to a new
> musl release (in my own forks of oe-core I've updated both OE 2.7 and
> OE 3.0 to the musl 1.1.24 release, etc).
>
> However, after 1.1.24, musl switches 32bit targets to a 64bit time_t
> (in preparation for 2038) and from my initial testing that seems to be
> a change which is going to cause a lot of problems (both build time
> and run time) for proprietary components and BSPs etc which are only
> ever used on a 32bit target. Anything open source is likely to have
> been well tested on a 64bit target and so any assumptions about the
> size of time_t will have been fixed long ago, but even then there's a
> chance of problems (see recent fixes in oe-core for build time issues
> in strace, systemd, busybox, etc. I guess that run time issues are
> likely to emerge too as the latest musl snapshot gets more testing on
> 32bit targets).
>
> Updating musl beyond 1.1.24 in oe-core probably needs some careful
> consideration, especially just before OE 3.1 LTS.
>

yes I am well aware of 64bit time_t changes, 1.25 should release well before
3.1 cut-off, musl maintainers are aware of it
and we have been fixing buggy apps which have assumptions about
the length of time_t, we would like to ship with 1.25 for 3.1
so please report isssues if you find and we can work along with them

> (Note that the version of musl in oe-core master is already beyond
> 1.1.24, so these comments don't apply specifically to this commit).
>
>
> > Signed-off-by: Khem Raj > Signed-off-by: Richard Purdie 
> > 
> > ---
> >  meta/recipes-core/musl/musl_git.bb | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-core/musl/musl_git.bb 
> > b/meta/recipes-core/musl/musl_git.bb
> > index f4853b4f2e..b6ec6fe9af 100644
> > --- a/meta/recipes-core/musl/musl_git.bb
> > +++ b/meta/recipes-core/musl/musl_git.bb
> > @@ -4,7 +4,7 @@
> >  require musl.inc
> >  inherit linuxloader
> >
> > -SRCREV = "e6093b5a870a38ebfb3e54382acd48c698bde15d"
> > +SRCREV = "a662220df547e5c2446518e74440a7d834f9ebe6"
> >
> >  BASEVER = "1.1.24"
> >
> > --
> > 2.25.0
> >
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/3] musl: Update to latest tip

2020-02-14 Thread Andre McCurdy

On Fri, Feb 14, 2020 at 7:42 AM Khem Raj  wrote:
>
> Detailed changelog is here [1]
>
> [1] 
> https://git.musl-libc.org/cgit/musl/log/?qt=range=e6093b5a870a38ebfb3e54382acd48c698bde15d..a662220df547e5c2446518e74440a7d834f9ebe6

Up to now, musl version updates have basically always just made things
better and there's never been a good reason not to switch to a new
musl release (in my own forks of oe-core I've updated both OE 2.7 and
OE 3.0 to the musl 1.1.24 release, etc).

However, after 1.1.24, musl switches 32bit targets to a 64bit time_t
(in preparation for 2038) and from my initial testing that seems to be
a change which is going to cause a lot of problems (both build time
and run time) for proprietary components and BSPs etc which are only
ever used on a 32bit target. Anything open source is likely to have
been well tested on a 64bit target and so any assumptions about the
size of time_t will have been fixed long ago, but even then there's a
chance of problems (see recent fixes in oe-core for build time issues
in strace, systemd, busybox, etc. I guess that run time issues are
likely to emerge too as the latest musl snapshot gets more testing on
32bit targets).

Updating musl beyond 1.1.24 in oe-core probably needs some careful
consideration, especially just before OE 3.1 LTS.

(Note that the version of musl in oe-core master is already beyond
1.1.24, so these comments don't apply specifically to this commit).

> Signed-off-by: Khem Raj > Signed-off-by: Richard Purdie 
> 
> ---
>  meta/recipes-core/musl/musl_git.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-core/musl/musl_git.bb 
> b/meta/recipes-core/musl/musl_git.bb
> index f4853b4f2e..b6ec6fe9af 100644
> --- a/meta/recipes-core/musl/musl_git.bb
> +++ b/meta/recipes-core/musl/musl_git.bb
> @@ -4,7 +4,7 @@
>  require musl.inc
>  inherit linuxloader
>
> -SRCREV = "e6093b5a870a38ebfb3e54382acd48c698bde15d"
> +SRCREV = "a662220df547e5c2446518e74440a7d834f9ebe6"
>
>  BASEVER = "1.1.24"
>
> --
> 2.25.0
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v3] libxml2: Fix CVE-2019-20388

From: Lee Chee Yang 

see:
https://gitlab.gnome.org/GNOME/libxml2/merge_requests/68

Signed-off-by: Lee Chee Yang 
---
 .../libxml/libxml2/CVE-2019-20388.patch| 37 ++
 meta/recipes-core/libxml/libxml2_2.9.10.bb |  1 +
 2 files changed, 38 insertions(+)
 create mode 100644 meta/recipes-core/libxml/libxml2/CVE-2019-20388.patch

diff --git a/meta/recipes-core/libxml/libxml2/CVE-2019-20388.patch 
b/meta/recipes-core/libxml/libxml2/CVE-2019-20388.patch
new file mode 100644
index 000..88eb65a
--- /dev/null
+++ b/meta/recipes-core/libxml/libxml2/CVE-2019-20388.patch
@@ -0,0 +1,37 @@
+From 7ffcd44d7e6c46704f8af0321d9314cd26e0e18a Mon Sep 17 00:00:00 2001
+From: Zhipeng Xie 
+Date: Tue, 20 Aug 2019 16:33:06 +0800
+Subject: [PATCH] Fix memory leak in xmlSchemaValidateStream
+
+When ctxt->schema is NULL, xmlSchemaSAXPlug->xmlSchemaPreRun
+alloc a new schema for ctxt->schema and set vctxt->xsiAssemble
+to 1. Then xmlSchemaVStart->xmlSchemaPreRun initialize
+vctxt->xsiAssemble to 0 again which cause the alloced schema
+can not be freed anymore.
+
+Found with libFuzzer.
+
+Upstream-Status: Backport 
[https://gitlab.gnome.org/GNOME/libxml2/commit/7ffcd44d7e6c46704f8af0321d9314cd26e0e18a]
+CVE: CVE-2019-20388
+
+Signed-off-by: Zhipeng Xie 
+Signed-off-by: Lee Chee Yang 
+---
+ xmlschemas.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/xmlschemas.c b/xmlschemas.c
+index 301c8449..39d92182 100644
+--- a/xmlschemas.c
 b/xmlschemas.c
+@@ -28090,7 +28090,6 @@ xmlSchemaPreRun(xmlSchemaValidCtxtPtr vctxt) {
+ vctxt->nberrors = 0;
+ vctxt->depth = -1;
+ vctxt->skipDepth = -1;
+-vctxt->xsiAssemble = 0;
+ vctxt->hasKeyrefs = 0;
+ #ifdef ENABLE_IDC_NODE_TABLES_TEST
+ vctxt->createIDCNodeTables = 1;
+-- 
+2.24.1
+
diff --git a/meta/recipes-core/libxml/libxml2_2.9.10.bb 
b/meta/recipes-core/libxml/libxml2_2.9.10.bb
index 6a4097c..097aceb 100644
--- a/meta/recipes-core/libxml/libxml2_2.9.10.bb
+++ b/meta/recipes-core/libxml/libxml2_2.9.10.bb
@@ -21,6 +21,7 @@ SRC_URI = 
"http://www.xmlsoft.org/sources/libxml2-${PV}.tar.gz;name=libtar \

file://0001-Make-ptest-run-the-python-tests-if-python-is-enabled.patch \
file://fix-execution-of-ptests.patch \
file://CVE-2020-7595.patch \
+   file://CVE-2019-20388.patch \
"
 
 SRC_URI[libtar.md5sum] = "10942a1dc23137a8aa07f0639cbfece5"
-- 
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 1/1] gnupg: Read GNUPG_BINDIR from environment variables for nativesdk

2020-02-14 Thread Randy MacLeod


On 1/6/20 5:30 AM, Robert Yang wrote:

There is already a relocate.patch for native which is used for reading
GNUPG_BINDIR from environment variables, now also enable it for nativesdk.
Otherwise, command like the following one doesn't work for nativesdk:

$ gpg-connect-agent --homedir ../keys/ reloadagent /bye
gpg-connect-agent: no running gpg-agent - starting 
'/opt/path/to/sysroots/x86_64-wrlinuxsdk-linux/usr/bin/gpg-agent'
gpg-connect-agent: failed to start agent 
'/opt/path/sysroots/x86_64-wrlinuxsdk-linux/usr/bin/gpg-agent': No such file or 
directory

Signed-off-by: Robert Yang 



This seems to have been missed.
Are there any comments?

Robert,
Please rebase and resend

../Randy


---
  meta/recipes-support/gnupg/gnupg_2.2.17.bb | 17 +
  1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-support/gnupg/gnupg_2.2.17.bb 
b/meta/recipes-support/gnupg/gnupg_2.2.17.bb
index bb8885f..0a939cf 100644
--- a/meta/recipes-support/gnupg/gnupg_2.2.17.bb
+++ b/meta/recipes-support/gnupg/gnupg_2.2.17.bb
@@ -19,6 +19,8 @@ SRC_URI = "${GNUPG_MIRROR}/${BPN}/${BPN}-${PV}.tar.bz2 \
  SRC_URI_append_class-native = " 
file://0001-configure.ac-use-a-custom-value-for-the-location-of-.patch \
  file://relocate.patch"
  
+SRC_URI_append_class-nativesdk = " file://relocate.patch"

+
  SRC_URI[md5sum] = "1ba2d9b70c377f8e967742064c27a19c"
  SRC_URI[sha256sum] = 
"afa262868e39b651a2db4c071fba90415154243e83a830ca00516f9a807fd514"
  
@@ -60,10 +62,17 @@ do_install_append() {

  }
  
  do_install_append_class-native() {

-   create_wrapper ${D}${bindir}/gpg2 GNUPG_BINDIR=${STAGING_BINDIR_NATIVE}
-   create_wrapper ${D}${bindir}/gpgconf 
GNUPG_BINDIR=${STAGING_BINDIR_NATIVE}
-   create_wrapper ${D}${bindir}/gpg-agent 
GNUPG_BINDIR=${STAGING_BINDIR_NATIVE}
-   create_wrapper ${D}${bindir}/gpg-connect-agent 
GNUPG_BINDIR=${STAGING_BINDIR_NATIVE}
+   create_wrappers ${STAGING_BINDIR_NATIVE}
+}
+
+do_install_append_class-nativesdk() {
+   create_wrappers ${SDKPATHNATIVE}${bindir_nativesdk}
+}
+
+create_wrappers() {
+   for i in gpg2 gpgconf gpg-agent gpg-connect-agent; do
+   create_wrapper ${D}${bindir}/$i GNUPG_BINDIR=$1
+   done
  }
  
  PACKAGECONFIG ??= "gnutls"





--
# Randy MacLeod
# Wind River Linux
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] image.bbclass, package-index.bb: Delete do_populate_lic task

These are meta packages

Signed-off-by: Khem Raj 
---
 meta/classes/image.bbclass  | 1 +
 meta/recipes-core/meta/package-index.bb | 1 +
 2 files changed, 2 insertions(+)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index c2824395c9..07aa1f1fa5 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -609,6 +609,7 @@ do_patch[noexec] = "1"
 do_configure[noexec] = "1"
 do_compile[noexec] = "1"
 do_install[noexec] = "1"
+deltask do_populate_lic
 deltask do_populate_sysroot
 do_package[noexec] = "1"
 deltask do_package_qa
diff --git a/meta/recipes-core/meta/package-index.bb 
b/meta/recipes-core/meta/package-index.bb
index a4123b7622..98c5bcb372 100644
--- a/meta/recipes-core/meta/package-index.bb
+++ b/meta/recipes-core/meta/package-index.bb
@@ -12,6 +12,7 @@ deltask do_patch
 deltask do_configure
 deltask do_compile
 deltask do_install
+deltask do_populate_lic
 deltask do_populate_sysroot
 
 do_package_index[nostamp] = "1"
-- 
2.25.0

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

[OE-core] [PATCH] db: Fix timespec length assumptions

This should fix the vdso crashes seen with kernel 5.0+

python3[11312] general protection fault ip:b7e966b0 sp:bf8175cc error:0 in 
libc.so[b7e8b000+6b000]

Signed-off-by: Khem Raj 
Cc: Bruce Ashfield 
---
 ...001-clock-Do-not-define-own-timespec.patch | 45 +++
 meta/recipes-support/db/db_5.3.28.bb  |  1 +
 2 files changed, 46 insertions(+)
 create mode 100644 
meta/recipes-support/db/db/0001-clock-Do-not-define-own-timespec.patch

diff --git 
a/meta/recipes-support/db/db/0001-clock-Do-not-define-own-timespec.patch 
b/meta/recipes-support/db/db/0001-clock-Do-not-define-own-timespec.patch
new file mode 100644
index 00..9d51a44a26
--- /dev/null
+++ b/meta/recipes-support/db/db/0001-clock-Do-not-define-own-timespec.patch
@@ -0,0 +1,45 @@
+From 96b303caf70a7635953c36e5bfb9ad6e75cb7637 Mon Sep 17 00:00:00 2001
+From: Khem Raj 
+Date: Fri, 14 Feb 2020 14:12:59 -0800
+Subject: [PATCH] clock: Do not define own timespec
+
+timespec is provided by libc and its best left to libc
+os_gettime takes a db_timespec and passed its address to clock_gettime
+which assumes that db_timespec and timespec are same but actually
+its 12-bytes here and libc has 16-bytes
+
+This can cause problems especially with 64bit time_t
+
+Upstream-Status: Pending
+Signed-off-by: Khem Raj 
+---
+ src/dbinc/clock.h | 17 +
+ 1 file changed, 1 insertion(+), 16 deletions(-)
+
+--- a/src/dbinc/clock.h
 b/src/dbinc/clock.h
+@@ -44,22 +44,8 @@
+ extern "C" {
+ #endif
+ 
+-/*
+- * This declaration is POSIX-compatible.  Because there are lots of different
+- * time.h include file patterns out there, it's easier to declare our own name
+- * in all cases than to try and discover if a system has a struct timespec.
+- * For the same reason, and because we'd have to #include  in 
db.h,
+- * we don't export any timespec structures in the DB API, even in places where
+- * it would make sense, like the replication statistics information.
+- */
+-typedef struct {
+-  time_t  tv_sec; /* seconds */
+-#ifdef HAVE_MIXED_SIZE_ADDRESSING
+-  int32_t tv_nsec;
+-#else
+-  longtv_nsec;/* nanoseconds */
+-#endif
+-} db_timespec;
++#include 
++#define db_timespec struct timespec
+ 
+ /* Operations on timespecs */
+ #undeftimespecclear
diff --git a/meta/recipes-support/db/db_5.3.28.bb 
b/meta/recipes-support/db/db_5.3.28.bb
index a2969055a6..badb79f9ea 100644
--- a/meta/recipes-support/db/db_5.3.28.bb
+++ b/meta/recipes-support/db/db_5.3.28.bb
@@ -26,6 +26,7 @@ SRC_URI += "file://fix-parallel-build.patch \
 
file://0001-configure-Add-explicit-tag-options-to-libtool-invoca.patch \
 file://sequence-type.patch \
 
file://0001-Fix-libc-compatibility-by-renaming-atomic_init-API.patch \
+file://0001-clock-Do-not-define-own-timespec.patch \
"
 # We are not interested in official latest 6.x versions;
 # let's track what debian is using.
-- 
2.25.0

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

Re: [OE-core] Unknown Postinstall Scriptlet Failing to Defer Boot

2020-02-14 Thread Jeremy A. Puhlman

If you look at the log.do_rootfs it will give you more or less the exact
failure(using the message below as a guide), the error message below is
basically
the final catchall that says "at least one of them failed, please go fix
it" kind of message.

On 2/14/2020 10:30 AM, Andrew Boos wrote:
Thanks Jeremy for the hint about update-alternatives. It turns out
that lmbench was installing a binary called "stream" that conflicts
with ImageMagick's own stream. All we had to do was remove lmbench
from our IMAGE_INSTALL and the problem went away. I'm posting the
original error for anyone that is having the same issue.

ERROR: imx8-image-3.0b3-r0 do_rootfs: Postinstall scriptlets of
['imagemagick'] have failed. If the intention is to defer them to
first boot,

then please place them into pkg_postinst_ontarget_${PN} ().
Deferring to first boot via 'exit 1' is no longer supported.

Andrew

On Thu, Feb 13, 2020 at 8:02 PM Jeremy A. Puhlman > wrote:

In these kind of cases, by providing the actual error message,
people can provide more help.

The recipe inherits update-alternatives and sets a large number of
alternatives. The alternatives are done in the automatically added
post install scripts. In all likelihood one of the listed links is
wrong, or already a symlink or something similar.
On 2/13/2020 4:49 PM, Andrew Boos wrote:

Hi,

I am working on a bitbake build and I am running into an issue
where a postinst scriptlet is failing via "exit 1" to defer to
first boot and I cannot figure out which recipe is causing the
issue. Does anybody have any tips on identifying which recipe is
actually exiting with a failure? The error log says that it is in
imagemagick but the recipe does not have any postinst scripts
defined. Also, there are no imagemagick .bbappend files in my
layers.

(https://github.com/openembedded/meta-openembedded/blob/sumo/meta-oe/recipes-support/imagemagick/imagemagick_7.0.7.bb)

Thanks,
Andrew

Virus-free. www.avg.com

<#m_-7702559278781328841_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

--
Jeremy A. Puhlman

jpuhl...@mvista.com

--
*Andrew Boos* | Avilution, LLC
(c) 251-895-5509

--
Jeremy A. Puhlman
jpuhl...@mvista.com

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

[OE-core] [PATCH] qemuriscv64: Set the Xvisor platform

2020-02-14 Thread Alistair Francis

Set the platform information required to build Xvisor.
https://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/tree/recipes-extended/xvisor

Signed-off-by: Alistair Francis 
---
 meta/conf/machine/qemuriscv64.conf | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/conf/machine/qemuriscv64.conf 
b/meta/conf/machine/qemuriscv64.conf
index b45fdd556d..a753af0576 100644
--- a/meta/conf/machine/qemuriscv64.conf
+++ b/meta/conf/machine/qemuriscv64.conf
@@ -4,6 +4,8 @@
 
 require conf/machine/include/riscv/qemuriscv.inc
 
+XVISOR_PLAT = "riscv/virt64"
+
 EXTRA_IMAGEDEPENDS += "u-boot"
 UBOOT_MACHINE = "qemu-riscv64_smode_defconfig"
 UBOOT_ELF = "u-boot"
-- 
2.25.0

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

Re: [OE-core] [PATCH 0/9] recipe updates, testing fixes

On Fri, Feb 14, 2020 at 11:21 AM Alexander Kanavin 
wrote:

> I got to it finally. Normally /var/lib/rpm is absent when opkg is in use,
> but when /usr/bin/rpm is present, python3's ptest involves distutils test
> creating rpm packages (and presumably installing them too), which creates a
> database in /var/lib/rpm, which then triggers rpm tests to run and fail. So
> a check for /var/lib/rpm in rpm tests isn't always sufficient to determine
> which packaging system is in use, and there should be a stronger one.
>
> I'm fine with adjusting libsolv to not pull in rpm, but please use
> EXCLUDE_FROM_WORLD instead of PNBLACKLIST, so that just that specific
> problem is solved, rather than banning libdnf/dnf altogether from builds.
>

Blacklisting is superior since this will also catch accidental inclusion of
these packages when not using rpm backend where as EXCLUDE_FROM_WORLD will
only be effective on word target


> Making libdnf to not require rpm-enabled libsolv is not feasible sadly,
> it's basically built around that assumption.
>

Exactly


>
> Alex
>
> On Fri, 14 Feb 2020 at 13:19, Alexander Kanavin 
> wrote:
>
>> On Fri, 14 Feb 2020 at 08:15, Khem Raj  wrote:
>>
>>> local.conf I have
>>>
>>> DISTRO_FEATURES_append = " largefile opengl ptest multiarch wayland pam
>>> polkit "
>>> IMAGE_CLASSES += "testimage testsdk"
>>>
>>
>> Right, I'm running this now, it's a bit tricky because I have to do it on
>> the Yocto AB. Big company's bureaucracy is causing delays in getting me a
>> build machine :(
>>
>> Alex
>>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] kernel-devsrc: support 4.4+ ARM/ARM64 kernels

2020-02-14 Thread Ruslan Bilovol via Openembedded-core

Linux Kernel 4.4 is an LTS kernel so people may still
build it with OE.

Thus make copying of some files optional:
 - arm64 module.lds file first appeared with kernel v4.6 commit
   fd045f6cd98e arm64: add support for module PLTs"
 - arm32 *.tbl files first appeared in kernel v4.10 in
   commit 96a8fae0fe09 "ARM: convert to generated
   system call tables"

Signed-off-by: Ruslan Bilovol 
---
 meta/recipes-kernel/linux/kernel-devsrc.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb 
b/meta/recipes-kernel/linux/kernel-devsrc.bb
index 2fa4be67cc..2ac679e204 100644
--- a/meta/recipes-kernel/linux/kernel-devsrc.bb
+++ b/meta/recipes-kernel/linux/kernel-devsrc.bb
@@ -147,7 +147,7 @@ do_install() {
 cp -a --parents arch/arm64/kernel/vdso/note.S $kerneldir/build/
 cp -a --parents arch/arm64/kernel/vdso/gen_vdso_offsets.sh 
$kerneldir/build/
 
-cp -a --parents arch/arm64/kernel/module.lds $kerneldir/build/
+cp -a --parents arch/arm64/kernel/module.lds $kerneldir/build/ 
2>/dev/null || :
fi
 
if [ "${ARCH}" = "powerpc" ]; then
@@ -187,7 +187,7 @@ do_install() {
 
# required for generate missing syscalls prepare phase
cp -a --parents $(find arch/x86 -type f -name "syscall_32.tbl") 
$kerneldir/build
-   cp -a --parents $(find arch/arm -type f -name "*.tbl") $kerneldir/build
+   cp -a --parents $(find arch/arm -type f -name "*.tbl") $kerneldir/build 
2>/dev/null || :
 
if [ "${ARCH}" = "x86" ]; then
# files for 'make prepare' to succeed with kernel-devel
-- 
2.17.1

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

Re: [OE-core] [PATCH 0/9] recipe updates, testing fixes

2020-02-14 Thread Alexander Kanavin

I got to it finally. Normally /var/lib/rpm is absent when opkg is in use,
but when /usr/bin/rpm is present, python3's ptest involves distutils test
creating rpm packages (and presumably installing them too), which creates a
database in /var/lib/rpm, which then triggers rpm tests to run and fail. So
a check for /var/lib/rpm in rpm tests isn't always sufficient to determine
which packaging system is in use, and there should be a stronger one.

I'm fine with adjusting libsolv to not pull in rpm, but please use
EXCLUDE_FROM_WORLD instead of PNBLACKLIST, so that just that specific
problem is solved, rather than banning libdnf/dnf altogether from builds.

Making libdnf to not require rpm-enabled libsolv is not feasible sadly,
it's basically built around that assumption.

Alex

On Fri, 14 Feb 2020 at 13:19, Alexander Kanavin 
wrote:

> On Fri, 14 Feb 2020 at 08:15, Khem Raj  wrote:
>
>> local.conf I have
>>
>> DISTRO_FEATURES_append = " largefile opengl ptest multiarch wayland pam
>> polkit "
>> IMAGE_CLASSES += "testimage testsdk"
>>
>
> Right, I'm running this now, it's a bit tricky because I have to do it on
> the Yocto AB. Big company's bureaucracy is causing delays in getting me a
> build machine :(
>
> Alex
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] ✗ patchtest: failure for busybox: Fix typo in patch

2020-02-14 Thread Patchwork

== Series Details ==

Series: busybox: Fix typo in patch
Revision: 1
URL   : https://patchwork.openembedded.org/series/22636/
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 7331062f82)



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] -> ...).

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
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] [PATCH] busybox: Fix typo in patch

Signed-off-by: Khem Raj 
---
 ...1-Remove-syscall-wrappers-around-clock_gettime-closes-.patch | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/meta/recipes-core/busybox/busybox/0001-Remove-syscall-wrappers-around-clock_gettime-closes-.patch
 
b/meta/recipes-core/busybox/busybox/0001-Remove-syscall-wrappers-around-clock_gettime-closes-.patch
index 1217daa108..0c7f9b8132 100644
--- 
a/meta/recipes-core/busybox/busybox/0001-Remove-syscall-wrappers-around-clock_gettime-closes-.patch
+++ 
b/meta/recipes-core/busybox/busybox/0001-Remove-syscall-wrappers-around-clock_gettime-closes-.patch
@@ -63,7 +63,7 @@ Signed-off-by: Denys Vlasenko 
 -   * typically requiring -lrt. We just skip all this mess */
 -  syscall(__NR_clock_gettime, CLOCK_REALTIME, );
 -#elif ENABLE_FEATURE_DATE_NANO && __TIMESIZE == 64
--  /* Let's only suppor the 64 suffix syscalls for 64-bit time_t.
+-  /* Let's only support the 64 suffix syscalls for 64-bit time_t.
 -   * This simplifies the code for us as we don't need to convert
 -   * between 64-bit and 32-bit. We also don't have a way to
 -   * report overflow errors here.
-- 
2.25.0

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

[OE-core] [RFC PATCH 1/1] newlib: Move syscalls from newlib to libgloss

2020-02-14 Thread Mark Hatle

By passing --disabled-newlib-supplied-syscalls, newlib will disable the
generation of builtin syscalls and move this to libgloss.  (This also
affects the generation of crt0.o.)

libgloss SHOULD then provide the syscalls, crt0.o and other functions that
are no longer part of newlib itself.  This now means that you must link
with both newlib and libgloss, whereas before newlib would run in many
configurations by itself.

Signed-off-by: Mark Hatle 
---
 meta/recipes-core/newlib/newlib.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-core/newlib/newlib.inc 
b/meta/recipes-core/newlib/newlib.inc
index d7ac8bff17..5edea8aba1 100644
--- a/meta/recipes-core/newlib/newlib.inc
+++ b/meta/recipes-core/newlib/newlib.inc
@@ -42,6 +42,7 @@ EXTRA_OECONF = " \
--with-gnu-as \
--with-gnu-ld \
--disable-multilib \
+   --disable-newlib-supplied-syscalls \
"
 
 do_configure[cleandirs] = "${B}"
-- 
2.17.1

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

[OE-core] [RFC PATCH 0/1] Change newlib configuration to require libgloss

2020-02-14 Thread Mark Hatle

This is an RFC, because I only know of my particular use-case.  So I'm not
sure how generic of a change this really is.

In my own use-case, we want to build a generic newlib and then customize
our equivalent to libgloss when linking baremetal applications.

I found that if we don't pass --disable-newlib-supplied-syscalls, even if
libgloss was linked in, the syscalls -always- came from newlib (on 32-bit
arm) and would not permit my implementations to override the built-in
newlib versions.

By setting the disable in BOTH newlib an libgloss, newlib syscalls are
disabled, while libgloss syscalls are enabled.  This results in a newlib
that will now require to be linked against a 'BSP' implementation, such
as libgloss, in order to build baremetal applications.

Alternatively to this I'd suggest we add pkgconfigs (or even distro
flags) to be able to change this behavior as well as flip some other
newlib switches if desired.

Mark Hatle (1):
  newlib: Move syscalls from newlib to libgloss

 meta/recipes-core/newlib/newlib.inc | 1 +
 1 file changed, 1 insertion(+)

-- 
2.17.1

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

Re: [OE-core] Unknown Postinstall Scriptlet Failing to Defer Boot

2020-02-14 Thread Andrew Boos

Thanks Jeremy for the hint about update-alternatives. It turns out that
lmbench was installing a binary called "stream" that conflicts with
ImageMagick's own stream. All we had to do was remove lmbench from our
IMAGE_INSTALL and the problem went away. I'm posting the original error for
anyone that is having the same issue.

ERROR: imx8-image-3.0b3-r0 do_rootfs: Postinstall scriptlets of
['imagemagick'] have failed. If the intention is to defer them to first
boot,
then please place them into pkg_postinst_ontarget_${PN} ().
Deferring to first boot via 'exit 1' is no longer supported.

Andrew


On Thu, Feb 13, 2020 at 8:02 PM Jeremy A. Puhlman 
wrote:

> In these kind of cases, by providing the actual error message, people can
> provide more help.
>
> The recipe inherits update-alternatives and sets a large number of
> alternatives. The alternatives are done in the automatically added post
> install scripts. In all likelihood one of the listed links is wrong, or
> already a symlink or something similar.
> On 2/13/2020 4:49 PM, Andrew Boos wrote:
>
> Hi,
>
> I am working on a bitbake build and I am running into an issue where a
> postinst scriptlet is failing via "exit 1" to defer to first boot and I
> cannot figure out which recipe is causing the issue. Does anybody have any
> tips on identifying which recipe is actually exiting with a failure? The
> error log says that it is in imagemagick but the recipe does not have any
> postinst scripts defined. Also, there are no imagemagick .bbappend files in
> my layers. (
> https://github.com/openembedded/meta-openembedded/blob/sumo/meta-oe/recipes-support/imagemagick/imagemagick_7.0.7.bb
> )
>
> Thanks,
> Andrew
>
>
> 
>  Virus-free.
> www.avg.com
> 
> <#m_-7702559278781328841_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
>
> --
> Jeremy A. puhlmanjpuhl...@mvista.com
>
>

-- 
*Andrew Boos* | Avilution, LLC
(c) 251-895-5509
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/2] tclibc-baremetal: Include qemu on the SDK

2020-02-14 Thread Alejandro Enedino Hernandez Samaniego

Since we now have an example recipe on meta-skeleton to
build baremetal applications using OpenEmbedded, a user
produced SDK should be able to run such application.

Include nativesdk-qemu on TOOLCHAIN_HOST_TASK so its
built inside the baremetal based SDK.

Signed-off-by: Alejandro Enedino Hernandez Samaniego 
---
 meta/conf/distro/include/tclibc-baremetal.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/distro/include/tclibc-baremetal.inc 
b/meta/conf/distro/include/tclibc-baremetal.inc
index e04f8c8..31d132e 100644
--- a/meta/conf/distro/include/tclibc-baremetal.inc
+++ b/meta/conf/distro/include/tclibc-baremetal.inc
@@ -27,7 +27,7 @@ BASEDEPENDS_remove_class-target = 
"virtual/${TARGET_PREFIX}compilerlibs"
 TARGET_OS = "elf"
 TARGET_OS_arm = "eabi"
 
-TOOLCHAIN_HOST_TASK ?= "packagegroup-cross-canadian-${MACHINE}"
+TOOLCHAIN_HOST_TASK ?= "packagegroup-cross-canadian-${MACHINE} nativesdk-qemu"
 TOOLCHAIN_HOST_TASK_ATTEMPTONLY ?= ""
 TOOLCHAIN_TARGET_TASK ?= "libgcc-dev"
 TOOLCHAIN_NEED_CONFIGSITE_CACHE_remove = "virtual/${MLPREFIX}libc zlib ncurses"
-- 
2.7.4

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

[OE-core] [PATCH 2/2] tclibc-newlib: Include qemu on the SDK

2020-02-14 Thread Alejandro Enedino Hernandez Samaniego

Since we now have an example recipe on meta-skeleton to
build baremetal applications using OpenEmbedded, a user
produced SDK should be able to run such application.

Include nativesdk-qemu on TOOLCHAIN_HOST_TASK so its
built inside the newlib based SDK.

Signed-off-by: Alejandro Enedino Hernandez Samaniego 
---
 meta/conf/distro/include/tclibc-newlib.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/distro/include/tclibc-newlib.inc 
b/meta/conf/distro/include/tclibc-newlib.inc
index 8338003..bf89b11 100644
--- a/meta/conf/distro/include/tclibc-newlib.inc
+++ b/meta/conf/distro/include/tclibc-newlib.inc
@@ -38,7 +38,7 @@ BASE_DEFAULT_DEPS_append_class-target = " ${NEWLIB_EXTENDED}"
 TARGET_OS = "elf"
 TARGET_OS_arm = "eabi"
 
-TOOLCHAIN_HOST_TASK ?= "packagegroup-cross-canadian-${MACHINE}"
+TOOLCHAIN_HOST_TASK ?= "packagegroup-cross-canadian-${MACHINE} nativesdk-qemu"
 TOOLCHAIN_TARGET_TASK ?= "${LIBC_DEPENDENCIES}"
 TOOLCHAIN_NEED_CONFIGSITE_CACHE_remove = "zlib ncurses"
 
-- 
2.7.4

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

Re: [OE-core] [PATCH v3] perf: Correct the substitution of python shebangs

On Fri, 2020-02-14 at 08:18 -0500, Bruce Ashfield wrote:
> On Thu, Feb 13, 2020 at 10:58 PM  wrote:
> > From: He Zhe 
> > 
> > To make the native python3 is always used,
> > 
> > - Use sed one-liner instead
> > - Add substitution for ${S}/scripts/bpf_helpers_doc.py to fix the
> >   following warning.
> > 
> > File "/usr/lib/python3.6/sysconfig.py", line 421, in _init_posix
> > _temp = __import__(name, globals(), locals(), ['build_time_vars'],
> > 0)
> > ModuleNotFoundError: No module named '_sysconfigdata'
> > 
> > This issue is first reported by Joel Stanley 
> > The sed one-liner is credited to Anuj Mittal  > >
> 
> Thanks!
> 
> This looks good to me.

I'm not sure how but with this applied we see breaking kernel module
tests:

https://autobuilder.yoctoproject.org/typhoon/#/builders/60/builds/1555
https://autobuilder.yoctoproject.org/typhoon/#/builders/102/builds/275
https://autobuilder.yoctoproject.org/typhoon/#/builders/74/builds/1559
(mips/sysvinit, mips/systemd and mips64)

I'll remove this patch from -next and retest see if I can confirm it is
this change somehow.

Cheers,

Richard

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

[OE-core] [PATCH v2] busybox: Backport patches to support removal of __NR_clock_gettime

This helps compiling with musl on 32bit arches now that musl has
switched to 64bit time_t

Signed-off-by: Khem Raj 
---
v2: backport another similar patch for runsv
refresh without meta-riscv patches

 ...rappers-around-clock_gettime-closes-.patch | 120 ++
 ...-Use-64-prefix-syscall-if-we-have-to.patch |  53 
 ...-Use-64-prefix-syscall-if-we-have-to.patch |  43 +++
 ...-Use-64-prefix-syscall-if-we-have-to.patch |  46 +++
 meta/recipes-core/busybox/busybox_1.31.1.bb   |   4 +
 5 files changed, 266 insertions(+)
 create mode 100644 
meta/recipes-core/busybox/busybox/0001-Remove-syscall-wrappers-around-clock_gettime-closes-.patch
 create mode 100644 
meta/recipes-core/busybox/busybox/0001-date-Use-64-prefix-syscall-if-we-have-to.patch
 create mode 100644 
meta/recipes-core/busybox/busybox/0001-time-Use-64-prefix-syscall-if-we-have-to.patch
 create mode 100644 
meta/recipes-core/busybox/busybox/0003-runsv-Use-64-prefix-syscall-if-we-have-to.patch

diff --git 
a/meta/recipes-core/busybox/busybox/0001-Remove-syscall-wrappers-around-clock_gettime-closes-.patch
 
b/meta/recipes-core/busybox/busybox/0001-Remove-syscall-wrappers-around-clock_gettime-closes-.patch
new file mode 100644
index 00..1217daa108
--- /dev/null
+++ 
b/meta/recipes-core/busybox/busybox/0001-Remove-syscall-wrappers-around-clock_gettime-closes-.patch
@@ -0,0 +1,120 @@
+From be5a505d771a77c640acc35ceaa470c80e62f954 Mon Sep 17 00:00:00 2001
+From: Denys Vlasenko 
+Date: Thu, 24 Oct 2019 16:26:55 +0200
+Subject: [PATCH] Remove syscall wrappers around clock_gettime, closes 12091
+
+12091 "Direct use of __NR_clock_gettime is not time64-safe".
+
+function old new   delta
+runsv_main  16981712 +14
+startservice 378 383  +5
+get_mono  31  25  -6
+date_main932 926  -6
+gettimeofday_ns   17   - -17
+--
+(add/remove: 0/1 grow/shrink: 2/2 up/down: 19/-29)Total: -10 bytes
+
+Upstream-Status: Backport 
[https://git.busybox.net/busybox/commit/?id=be5a505d771a77c640acc35ceaa470c80e62f954]
+Signed-off-by: Denys Vlasenko 
+---
+ Makefile.flags   |  6 --
+ coreutils/date.c | 16 +++-
+ libbb/time.c | 11 +--
+ runit/runsv.c| 11 +--
+ 4 files changed, 9 insertions(+), 35 deletions(-)
+
+--- a/Makefile.flags
 b/Makefile.flags
+@@ -129,10 +129,12 @@ endif
+ # fall back to using a temp file:
+ CRYPT_AVAILABLE := $(shell echo 'int main(void){return 0;}' >crypttest.c; 
$(CC) $(CFLAGS) -lcrypt -o /dev/null crypttest.c >/dev/null 2>&1 && echo "y"; 
rm crypttest.c)
+ ifeq ($(CRYPT_AVAILABLE),y)
+-LDLIBS += m crypt
++LDLIBS += m rt crypt
+ else
+-LDLIBS += m
++LDLIBS += m rt
+ endif
++# libm may be needed for dc, awk, ntpd
++# librt may be needed for clock_gettime()
+ 
+ # libpam may use libpthread, libdl and/or libaudit.
+ # On some platforms that requires an explicit -lpthread, -ldl, -laudit.
+--- a/coreutils/date.c
 b/coreutils/date.c
+@@ -33,10 +33,9 @@
+ //config: Enable option (-I) to output an ISO-8601 compliant
+ //config: date/time string.
+ //config:
+-//config:# defaults to "no": stat's nanosecond field is a bit non-portable
+ //config:config FEATURE_DATE_NANO
+ //config: bool "Support %[num]N nanosecond format specifier"
+-//config: default n  # syscall(__NR_clock_gettime) or 
syscall(__NR_clock_gettime64)
++//config: default n # stat's nanosecond field is a bit non-portable
+ //config: depends on DATE
+ //config: select PLATFORM_LINUX
+ //config: help
+@@ -271,17 +270,8 @@ int date_main(int argc UNUSED_PARAM, cha
+*/
+ #endif
+   } else {
+-#if ENABLE_FEATURE_DATE_NANO && defined(__NR_clock_gettime)
+-  /* libc has incredibly messy way of doing this,
+-   * typically requiring -lrt. We just skip all this mess */
+-  syscall(__NR_clock_gettime, CLOCK_REALTIME, );
+-#elif ENABLE_FEATURE_DATE_NANO && __TIMESIZE == 64
+-  /* Let's only suppor the 64 suffix syscalls for 64-bit time_t.
+-   * This simplifies the code for us as we don't need to convert
+-   * between 64-bit and 32-bit. We also don't have a way to
+-   * report overflow errors here.
+-   */
+-  syscall(__NR_clock_gettime64, CLOCK_REALTIME, );
++#if ENABLE_FEATURE_DATE_NANO
++  clock_gettime(CLOCK_REALTIME, );
+ #else
+   time(_sec);
+ #endif
+--- a/libbb/time.c
 b/libbb/time.c
+@@ -253,18 +253,9 @@ char* FAST_FUNC strftime_MMDDHHMMSS(
+ #define CLOCK_MONOTONIC 1
+ #endif
+ 
+-/* libc has incredibly messy way of doing this,
+- * typically requiring

Re: [OE-core] [PATCH] python3-pycairo: upgrade 1.18.2 -> 1.19.0

2020-02-14 Thread Alexander Kanavin

Thanks Wang, the recipe upgrade work is very appreciated, particularly
because it doesn't fit very well into commercial product development and
its typical incentives.

Do you want to be the official maintainer for any of the oe-core recipes?
In the sense that you would be listed for them in
meta/conf/distro/include/maintainers.inc

The benefits are - you can place the 'official' bit into your CV; you will
also get monthly upgrade patches by email from AUH, so you don't have to
create them yourself.

Alex


On Fri, 14 Feb 2020 at 17:12, Wang Mingyu  wrote:

> -License-Update: "PDX-License-Identifier: LGPL-2.1-only OR MPL-1.1"
> is added
>
> Signed-off-by: Wang Mingyu 
> ---
>  ...{python3-pycairo_1.18.2.bb => python3-pycairo_1.19.0.bb} | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>  rename meta/recipes-devtools/python/{python3-pycairo_1.18.2.bb =>
> python3-pycairo_1.19.0.bb} (77%)
>
> diff --git a/meta/recipes-devtools/python/python3-pycairo_1.18.2.bb
> b/meta/recipes-devtools/python/python3-pycairo_1.19.0.bb
> similarity index 77%
> rename from meta/recipes-devtools/python/python3-pycairo_1.18.2.bb
> rename to meta/recipes-devtools/python/python3-pycairo_1.19.0.bb
> index 3aedf3d142..8f60834c17 100644
> --- a/meta/recipes-devtools/python/python3-pycairo_1.18.2.bb
> +++ b/meta/recipes-devtools/python/python3-pycairo_1.19.0.bb
> @@ -3,7 +3,7 @@ HOMEPAGE = "http://cairographics.org/pycairo;
>  BUGTRACKER = "http://bugs.freedesktop.org;
>  SECTION = "python-devel"
>  LICENSE = "LGPLv2.1 & MPLv1.1"
> -LIC_FILES_CHKSUM = "file://COPYING;md5=f2e071ab72978431b294a0d696327421 \
> +LIC_FILES_CHKSUM = "file://COPYING;md5=f3713ca2c28d9312ad718520b6dc3eee \
>
>  file://COPYING-LGPL-2.1;md5=fad9b3332be894bab9bc501572864b29 \
>
>  file://COPYING-MPL-1.1;md5=bfe1f75d606912a4111c90743d6c7325"
>
> @@ -13,8 +13,8 @@ DEPENDS = "cairo python3"
>  SRC_URI = "
> https://github.com/pygobject/pycairo/releases/download/v${PV}/pycairo-${PV}.tar.gz
> "
>  UPSTREAM_CHECK_URI = "https://github.com/pygobject/pycairo/releases/;
>
> -SRC_URI[md5sum] = "be2ba51f234270dec340f28f1695a95e"
> -SRC_URI[sha256sum] =
> "dcb853fd020729516e8828ad364084e752327d4cff8505d20b13504b32b16531"
> +SRC_URI[md5sum] = "38b84416021640b01250c8f8ec4c52d4"
> +SRC_URI[sha256sum] =
> "4f5ba9374a46c98729dd3727d993f5e17ed0286fd6738ed464fe4efa0612d19c"
>
>  S = "${WORKDIR}/pycairo-${PV}"
>
> --
> 2.17.1
>
>
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] staging: Handle races between binaries and their libs

On Fri, 2020-02-14 at 17:01 +, Peter Kjellerstedt wrote:
> Shouldn't /sbin/ be treated the same way as /bin/?

I guess so, yes. I've done that.

Cheers,

Richard

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

Re: [OE-core] [PATCH] staging: Handle races between binaries and their libs

2020-02-14 Thread Peter Kjellerstedt

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org  boun...@lists.openembedded.org> On Behalf Of Richard Purdie
> Sent: den 14 februari 2020 14:03
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH] staging: Handle races between binaries and
> their libs
> 
> There is a long standing issue where a binary could be installed into the
> sysroot before its library dependencies. We've always argued nothing should
> use the binary until its been installed by a dependency but there are issues

Change "its" to "it has".

> around binaries which conflict with the host system, for example patch,
> python3, gzip and more.
> 
> With the recent patch changes we've see issues like:

Change "see" to "seen".

> ERROR: gdb-cross-canadian-powerpc-8.3.1-r0 do_patch: Command Error: 'quilt 
> --quiltrc 
> /home/pokybuild/yocto-worker/qemuppc/build/build/tmp/work/x86_64-nativesdk-pokysdk-linux/gdb-cross-canadian-powerpc/8.3.1-r0/recipe-sysroot-native/etc/quiltrc
>  push' exited with 0  Output:
> Applying patch 0009-Change-order-of-CFLAGS.patch
> patch: /lib64/libattr.so.1: version `ATTR_1.3' not found (required by patch)
> Patch 0009-Change-order-of-CFLAGS.patch does not apply (enforce with -f)
> 
> which is a symptom of this issue (libattr-native is a dependency of 
> patch-native).
> 
> There are other ways to fix this such as disabling libattr in patch, 
> installing
> patch to a subdirectory and requiring PATH manipulation and so on.
> 
> We can simply fix the staging code to handle /bin/ after everything else so 
> lets

Change "lets" to "let's".

> do that and avoid all these other complications.

Shouldn't /sbin/ be treated the same way as /bin/?

//Peter

> Signed-off-by: Richard Purdie 
> ---
>  meta/classes/staging.bbclass | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/classes/staging.bbclass b/meta/classes/staging.bbclass
> index 4dd2ed01010..530e23b1853 100644
> --- a/meta/classes/staging.bbclass
> +++ b/meta/classes/staging.bbclass
> @@ -470,6 +470,7 @@ python extend_recipe_sysroot() {
>  elif os.path.lexists(depdir + "/" + c):
>  os.unlink(depdir + "/" + c)
> 
> +binfiles = {}
>  # Now handle installs
>  for dep in configuredeps:
>  c = setscenedeps[dep][0]
> @@ -562,7 +563,16 @@ python extend_recipe_sysroot() {
>  if l.endswith("/"):
>  staging_copydir(l, targetdir, dest, seendirs)
>  continue
> -staging_copyfile(l, targetdir, dest, postinsts, seendirs)
> +if "/bin/" in l:
> +# defer /bin/* files until last in case they need 
> libs
> +binfiles[l] = (targetdir, dest)
> +else:
> +staging_copyfile(l, targetdir, dest, postinsts, 
> seendirs)
> +
> +# Handle deferred binfiles
> +for l in binfiles:
> +(targetdir, dest) = binfiles[l]
> +staging_copyfile(l, targetdir, dest, postinsts, seendirs)
> 
>  bb.note("Installed into sysroot: %s" % str(msg_adding))
>  bb.note("Skipping as already exists in sysroot: %s" % str(msg_exists))
> --
> 2.20.1

//Peter

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

[OE-core] [PATCH] icu: upgrade 64.2 -> 65.1

Signed-off-by: Wang Mingyu 
---
 meta/recipes-support/icu/{icu_64.2.bb => icu_65.1.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-support/icu/{icu_64.2.bb => icu_65.1.bb} (88%)

diff --git a/meta/recipes-support/icu/icu_64.2.bb 
b/meta/recipes-support/icu/icu_65.1.bb
similarity index 88%
rename from meta/recipes-support/icu/icu_64.2.bb
rename to meta/recipes-support/icu/icu_65.1.bb
index 44caa43..bd932d7 100644
--- a/meta/recipes-support/icu/icu_64.2.bb
+++ b/meta/recipes-support/icu/icu_65.1.bb
@@ -28,8 +28,8 @@ SRC_URI = "${BASE_SRC_URI} \
 SRC_URI_append_class-target = "\
file://0001-Disable-LDFLAGSICUDT-for-Linux.patch \
   "
-SRC_URI[md5sum] = "a3d18213beec454e3cdec9a3116d6b05"
-SRC_URI[sha256sum] = 
"627d5d8478e6d96fc8c90fed4851239079a561a6a8b9e48b0892f24e82d31d6c"
+SRC_URI[md5sum] = "d1ff436e26cabcb28e6cb383d32d1339"
+SRC_URI[sha256sum] = 
"53e37466b3d6d6d01ead029e3567d873a43a5d1c668ed2278e253b683136d948"
 
 UPSTREAM_CHECK_REGEX = "icu4c-(?P\d+(_\d+)+)-src"
 UPSTREAM_CHECK_URI = "https://github.com/unicode-org/icu/releases;
-- 
2.7.4



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

[OE-core] [PATCH] python3-pycairo: upgrade 1.18.2 -> 1.19.0

-License-Update: "PDX-License-Identifier: LGPL-2.1-only OR MPL-1.1"
is added

Signed-off-by: Wang Mingyu 
---
 ...{python3-pycairo_1.18.2.bb => python3-pycairo_1.19.0.bb} | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
 rename meta/recipes-devtools/python/{python3-pycairo_1.18.2.bb => 
python3-pycairo_1.19.0.bb} (77%)

diff --git a/meta/recipes-devtools/python/python3-pycairo_1.18.2.bb 
b/meta/recipes-devtools/python/python3-pycairo_1.19.0.bb
similarity index 77%
rename from meta/recipes-devtools/python/python3-pycairo_1.18.2.bb
rename to meta/recipes-devtools/python/python3-pycairo_1.19.0.bb
index 3aedf3d142..8f60834c17 100644
--- a/meta/recipes-devtools/python/python3-pycairo_1.18.2.bb
+++ b/meta/recipes-devtools/python/python3-pycairo_1.19.0.bb
@@ -3,7 +3,7 @@ HOMEPAGE = "http://cairographics.org/pycairo;
 BUGTRACKER = "http://bugs.freedesktop.org;
 SECTION = "python-devel"
 LICENSE = "LGPLv2.1 & MPLv1.1"
-LIC_FILES_CHKSUM = "file://COPYING;md5=f2e071ab72978431b294a0d696327421 \
+LIC_FILES_CHKSUM = "file://COPYING;md5=f3713ca2c28d9312ad718520b6dc3eee \
 
file://COPYING-LGPL-2.1;md5=fad9b3332be894bab9bc501572864b29 \
 
file://COPYING-MPL-1.1;md5=bfe1f75d606912a4111c90743d6c7325"
 
@@ -13,8 +13,8 @@ DEPENDS = "cairo python3"
 SRC_URI = 
"https://github.com/pygobject/pycairo/releases/download/v${PV}/pycairo-${PV}.tar.gz;
 UPSTREAM_CHECK_URI = "https://github.com/pygobject/pycairo/releases/;
 
-SRC_URI[md5sum] = "be2ba51f234270dec340f28f1695a95e"
-SRC_URI[sha256sum] = 
"dcb853fd020729516e8828ad364084e752327d4cff8505d20b13504b32b16531"
+SRC_URI[md5sum] = "38b84416021640b01250c8f8ec4c52d4"
+SRC_URI[sha256sum] = 
"4f5ba9374a46c98729dd3727d993f5e17ed0286fd6738ed464fe4efa0612d19c"
 
 S = "${WORKDIR}/pycairo-${PV}"
 
-- 
2.17.1



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

[OE-core] [PATCH] ell: upgrade 0.27 -> 0.28

Signed-off-by: Wang Mingyu 
---
 meta/recipes-core/ell/{ell_0.27.bb => ell_0.28.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-core/ell/{ell_0.27.bb => ell_0.28.bb} (83%)

diff --git a/meta/recipes-core/ell/ell_0.27.bb 
b/meta/recipes-core/ell/ell_0.28.bb
similarity index 83%
rename from meta/recipes-core/ell/ell_0.27.bb
rename to meta/recipes-core/ell/ell_0.28.bb
index 503f1e22a3..464bf631e3 100644
--- a/meta/recipes-core/ell/ell_0.27.bb
+++ b/meta/recipes-core/ell/ell_0.28.bb
@@ -14,8 +14,8 @@ DEPENDS = "dbus"
 inherit autotools pkgconfig
 
 SRC_URI = 
"https://mirrors.edge.kernel.org/pub/linux/libs/${BPN}/${BPN}-${PV}.tar.xz;
-SRC_URI[md5sum] = "e090d6a910a43c2a32114ba1cdc9f1f2"
-SRC_URI[sha256sum] = 
"afc5441d6f6ece512a188b1e6aeabd7153de4f38989c897a2197ae50fc46da96"
+SRC_URI[md5sum] = "e38089e54d4b41e508bbb7f37a4a59d9"
+SRC_URI[sha256sum] = 
"6254fcb98d681cb2c3078dde462ba20bf90e6c10919204c6878a4381adcdb74b"
 
 do_configure_prepend () {
 mkdir -p ${S}/build-aux
-- 
2.17.1



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

[OE-core] [PATCH] libgpg-error: upgrade 1.36 -> 1.37

libgpg-error-1.36-gawk5-support.patch
Removed since it is included in 1.37.

Signed-off-by: Wang Mingyu 
---
 .../libgpg-error-1.36-gawk5-support.patch  | 144 -
 .../{libgpg-error_1.36.bb => libgpg-error_1.37.bb} |   5 +-
 2 files changed, 2 insertions(+), 147 deletions(-)
 delete mode 100644 
meta/recipes-support/libgpg-error/libgpg-error/libgpg-error-1.36-gawk5-support.patch
 rename meta/recipes-support/libgpg-error/{libgpg-error_1.36.bb => 
libgpg-error_1.37.bb} (92%)

diff --git 
a/meta/recipes-support/libgpg-error/libgpg-error/libgpg-error-1.36-gawk5-support.patch
 
b/meta/recipes-support/libgpg-error/libgpg-error/libgpg-error-1.36-gawk5-support.patch
deleted file mode 100644
index b936d11..000
--- 
a/meta/recipes-support/libgpg-error/libgpg-error/libgpg-error-1.36-gawk5-support.patch
+++ /dev/null
@@ -1,144 +0,0 @@
-Upstream-Status: Backport [https://dev.gnupg.org/T4459]
-Signed-off-by: Khem Raj 
-
-From 7865041c77f4f7005282f10f9bb19072fbdf Mon Sep 17 00:00:00 2001
-From: NIIBE Yutaka 
-Date: Mon, 15 Apr 2019 15:10:44 +0900
-Subject: [PATCH] awk: Prepare for Gawk 5.0.
-
-* src/Makefile.am: Use pkg_namespace (instead of namespace).
-* src/mkerrnos.awk: Likewise.
-* lang/cl/mkerrcodes.awk: Don't escape # in regexp.
-* src/mkerrcodes.awk, src/mkerrcodes1.awk, src/mkerrcodes2.awk: Ditto.
-
---
-
-In Gawk 5.0, regexp routines are replaced by Gnulib implementation,
-which only allows escaping specific characters.
-
-GnuPG-bug-id: 4459
-Reported-by: Marius Schamschula
-Signed-off-by: NIIBE Yutaka 

- lang/cl/mkerrcodes.awk |  2 +-
- src/Makefile.am|  2 +-
- src/mkerrcodes.awk |  2 +-
- src/mkerrcodes1.awk|  2 +-
- src/mkerrcodes2.awk|  2 +-
- src/mkerrnos.awk   |  2 +-
- src/mkstrtable.awk | 10 +-
- 7 files changed, 11 insertions(+), 11 deletions(-)
-
 a/lang/cl/mkerrcodes.awk
-+++ b/lang/cl/mkerrcodes.awk
-@@ -122,7 +122,7 @@ header {
- }
- 
- !header {
--  sub (/\#.+/, "");
-+  sub (/#.+/, "");
-   sub (/[ ]+$/, ""); # Strip trailing space and tab characters.
- 
-   if (/^$/)
 a/src/Makefile.am
-+++ b/src/Makefile.am
-@@ -293,7 +293,7 @@ code-from-errno.h: mkerrcodes$(EXEEXT_FO
- 
- errnos-sym.h: Makefile mkstrtable.awk errnos.in
-   $(AWK) -f $(srcdir)/mkstrtable.awk -v textidx=2 -v nogettext=1 \
--  -v prefix=GPG_ERR_ -v namespace=errnos_ \
-+  -v prefix=GPG_ERR_ -v pkg_namespace=errnos_ \
-   $(srcdir)/errnos.in >$@
- 
- 
 a/src/mkerrcodes.awk
-+++ b/src/mkerrcodes.awk
-@@ -85,7 +85,7 @@ header {
- }
- 
- !header {
--  sub (/\#.+/, "");
-+  sub (/#.+/, "");
-   sub (/[ ]+$/, ""); # Strip trailing space and tab characters.
- 
-   if (/^$/)
 a/src/mkerrcodes1.awk
-+++ b/src/mkerrcodes1.awk
-@@ -81,7 +81,7 @@ header {
- }
- 
- !header {
--  sub (/\#.+/, "");
-+  sub (/#.+/, "");
-   sub (/[ ]+$/, ""); # Strip trailing space and tab characters.
- 
-   if (/^$/)
 a/src/mkerrcodes2.awk
-+++ b/src/mkerrcodes2.awk
-@@ -91,7 +91,7 @@ header {
- }
- 
- !header {
--  sub (/\#.+/, "");
-+  sub (/#.+/, "");
-   sub (/[ ]+$/, ""); # Strip trailing space and tab characters.
- 
-   if (/^$/)
 a/src/mkerrnos.awk
-+++ b/src/mkerrnos.awk
-@@ -83,7 +83,7 @@ header {
- }
- 
- !header {
--  sub (/\#.+/, "");
-+  sub (/#.+/, "");
-   sub (/[ ]+$/, ""); # Strip trailing space and tab characters.
- 
-   if (/^$/)
 a/src/mkstrtable.awk
-+++ b/src/mkstrtable.awk
-@@ -77,7 +77,7 @@
- #
- # The variable prefix can be used to prepend a string to each message.
- #
--# The variable namespace can be used to prepend a string to each
-+# The variable pkg_namespace can be used to prepend a string to each
- # variable and macro name.
- 
- BEGIN {
-@@ -102,7 +102,7 @@ header {
-   print "/* The purpose of this complex string table is to produce";
-   print "   optimal code with a minimum of relocations.  */";
-   print "";
--  print "static const char " namespace "msgstr[] = ";
-+  print "static const char " pkg_namespace "msgstr[] = ";
-   header = 0;
- }
-   else
-@@ -110,7 +110,7 @@ header {
- }
- 
- !header {
--  sub (/\#.+/, "");
-+  sub (/#.+/, "");
-   sub (/[ ]+$/, ""); # Strip trailing space and tab characters.
- 
-   if (/^$/)
-@@ -150,7 +150,7 @@ END {
-   else
- print "  gettext_noop (\"" last_msgstr "\");";
-   print "";
--  print "static const int " namespace "msgidx[] =";
-+  print "static const int " pkg_namespace "msgidx[] =";
-   print "  {";
-   for (i = 0; i < coded_msgs; i++)
- print "" pos[i] ",";
-@@ -158,7 +158,7 @@ END {
-   print "  };";
-   print "";
-   print "static GPG_ERR_INLINE int";
--  print namespace "msgidxof (int code)";
-+  print pkg_namespace "msgidxof (int code)";
-   print "{";
-   print "  return (0 ? 0";
- 
diff --git a/meta/recipes-support/libgpg-error/libgpg-error_1.36.bb 
b/meta/recipes-support/libgpg-error/libgpg-error_1.37.bb
similarity index 92%
rename from

[OE-core] ✗ patchtest: failure for "musl: Update to latest tip..." and 2 more (rev2)

2020-02-14 Thread Patchwork

== Series Details ==

Series: "musl: Update to latest tip..." and 2 more (rev2)
Revision: 2
URL   : https://patchwork.openembedded.org/series/19281/
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 Upstream-Status is Submitted, but it is not mentioned where 
[test_upstream_status_presence_format] 
  Suggested fixInclude where 0011-gdbserver-ctrl-c-handling.patch was 
submitted
  Current  Upstream-Status: Submitted
  Standard format  Upstream-Status: Submitted [where]



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] -> ...).

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
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 2/2] libxml2: Fix CVE-2019-20388

2020-02-14 Thread Mittal, Anuj

On Fri, 2020-02-14 at 19:28 +0800, chee.yang@intel.com wrote:
> From: Lee Chee Yang 
> 
> see:
> https://gitlab.gnome.org/GNOME/libxml2/merge_requests/68
> 
> Signed-off-by: Lee Chee Yang 
> ---
>  .../libxml/libxml2/CVE-2019-20388.patch| 37
> ++
>  meta/recipes-core/libxml/libxml2_2.9.10.bb |  1 +
>  2 files changed, 38 insertions(+)
>  create mode 100644 meta/recipes-core/libxml/libxml2/CVE-2019-
> 20388.patch
> 
> diff --git a/meta/recipes-core/libxml/libxml2/CVE-2019-20388.patch
> b/meta/recipes-core/libxml/libxml2/CVE-2019-20388.patch
> new file mode 100644
> index 000..4ee2d4f
> --- /dev/null
> +++ b/meta/recipes-core/libxml/libxml2/CVE-2019-20388.patch
> @@ -0,0 +1,37 @@
> +From 7ffcd44d7e6c46704f8af0321d9314cd26e0e18a Mon Sep 17 00:00:00
> 2001
> +From: Zhipeng Xie 
> +Date: Tue, 20 Aug 2019 16:33:06 +0800
> +Subject: [PATCH] Fix memory leak in xmlSchemaValidateStream
> +
> +When ctxt->schema is NULL, xmlSchemaSAXPlug->xmlSchemaPreRun
> +alloc a new schema for ctxt->schema and set vctxt->xsiAssemble
> +to 1. Then xmlSchemaVStart->xmlSchemaPreRun initialize
> +vctxt->xsiAssemble to 0 again which cause the alloced schema
> +can not be freed anymore.
> +
> +Found with libFuzzer.
> +
> +Upstream-Status: Accepted [
> https://gitlab.gnome.org/GNOME/libxml2/commit/7ffcd44d7e6c46704f8af0321d9314cd26e0e18a
> ]

The status here should be Backport.

Thanks,

Anuj

> +CVE: CVE-2019-20388
> +
> +Signed-off-by: Zhipeng Xie 
> +Signed-off-by: Lee Chee Yang 
> +---
> + xmlschemas.c | 1 -
> + 1 file changed, 1 deletion(-)
> +
> +diff --git a/xmlschemas.c b/xmlschemas.c
> +index 301c8449..39d92182 100644
> +--- a/xmlschemas.c
>  b/xmlschemas.c
> +@@ -28090,7 +28090,6 @@ xmlSchemaPreRun(xmlSchemaValidCtxtPtr vctxt)
> {
> + vctxt->nberrors = 0;
> + vctxt->depth = -1;
> + vctxt->skipDepth = -1;
> +-vctxt->xsiAssemble = 0;
> + vctxt->hasKeyrefs = 0;
> + #ifdef ENABLE_IDC_NODE_TABLES_TEST
> + vctxt->createIDCNodeTables = 1;
> +-- 
> +2.24.1
> +
> diff --git a/meta/recipes-core/libxml/libxml2_2.9.10.bb
> b/meta/recipes-core/libxml/libxml2_2.9.10.bb
> index 6a4097c..097aceb 100644
> --- a/meta/recipes-core/libxml/libxml2_2.9.10.bb
> +++ b/meta/recipes-core/libxml/libxml2_2.9.10.bb
> @@ -21,6 +21,7 @@ SRC_URI = "
> http://www.xmlsoft.org/sources/libxml2-${PV}.tar.gz;name=libtar \
> file://0001-Make-ptest-run-the-python-tests-if-python-is-
> enabled.patch \
> file://fix-execution-of-ptests.patch \
> file://CVE-2020-7595.patch \
> +   file://CVE-2019-20388.patch \
> "
>  
>  SRC_URI[libtar.md5sum] = "10942a1dc23137a8aa07f0639cbfece5"
> -- 
> 2.7.4
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] swuashfs-tools: Enable on musl

2020-02-14 Thread Adrian Bunk

On Fri, Feb 14, 2020 at 06:42:12AM -0800, Khem Raj wrote:
> On Fri, Feb 14, 2020 at 6:35 AM Adrian Bunk  wrote:
> >
> > On Thu, Feb 13, 2020 at 11:03:52PM -0800, Khem Raj wrote:
> > > Upstream has a patch [1] to fix musl builds, Prior to this it would not
> > > build on musl due to missing GNU extentions for fnmatch
> > >
> > > [1] 
> > > https://github.com/plougher/squashfs-tools/commit/4280e74de14070869787a9166242f9ce2dafd82e
> > >...
> >
> > I did already remove a similar bogus squashfs-tools change from OE,
> > with similar FNM_EXTMATCH "fixes" in ifupdown and elfutils
> > also resulting in the expected runtime misbehaviour.
> 
> I think it would be better to use gnulib implementation for these
> packages you point out
> and those patches will be upstream worthy and make them portable
> as well.

Yes, this would be better since the resulting code would be working.

But looking at the gnulib sources someone made gl_FUNC_FNMATCH_GNU do 
the wrong thing by "guessing yes" when cross-compiling for musl...

> At least it is calling out bad elements.

The only bad element is code that builds but silently does the wrong 
thing. Everything else is visible for users early during product
development and can be mitigated.

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

Re: [OE-core] [PATCH] staging: Handle races between binaries and their libs

On Fri, Feb 14, 2020 at 6:51 AM Richard Purdie
 wrote:
>
> On Fri, 2020-02-14 at 06:46 -0800, Khem Raj wrote:
> > On Fri, Feb 14, 2020 at 5:03 AM Richard Purdie
> >  wrote:
> > > There is a long standing issue where a binary could be installed
> > > into the
> > > sysroot before its library dependencies. We've always argued
> > > nothing should
> > > use the binary until its been installed by a dependency but there
> > > are issues
> > > around binaries which conflict with the host system, for example
> > > patch,
> > > python3, gzip and more.
> > >
> > > With the recent patch changes we've see issues like:
> > > ERROR: gdb-cross-canadian-powerpc-8.3.1-r0 do_patch: Command Error:
> > > 'quilt --quiltrc /home/pokybuild/yocto-
> > > worker/qemuppc/build/build/tmp/work/x86_64-nativesdk-pokysdk-
> > > linux/gdb-cross-canadian-powerpc/8.3.1-r0/recipe-sysroot-
> > > native/etc/quiltrc push' exited with 0  Output:
> > > Applying patch 0009-Change-order-of-CFLAGS.patch
> > > patch: /lib64/libattr.so.1: version `ATTR_1.3' not found (required
> > > by patch)
> > > Patch 0009-Change-order-of-CFLAGS.patch does not apply (enforce
> > > with -f)
> > >
> > > which is a symptom of this issue (libattr-native is a dependency of
> > > patch-native).
> > >
> >
> > ah so this was the problem I wondered
>
> Its one problem we're seeing, I'm still not sure those two other
> patches of yours apply cleanly though... :/
>

I have resent the patches for musl upgrade using git send-mail instead
of ./scripts/send-pull-request, can you try these from mailing list ?

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

[OE-core] [PATCH 2/3] gdb: Upgrade to 9.1 release

Drop security patches which are now in 9.1 already
Forward port rest of patches to 9.1
Detailed changes [1]

[1] https://lists.gnu.org/archive/html/info-gnu/2020-02/msg8.html

Signed-off-by: Khem Raj 
Signed-off-by: Richard Purdie 
---
 meta/conf/distro/include/tcmode-default.inc   |   2 +-
 meta/recipes-devtools/gdb/gdb-8.3.1.inc   |  22 ---
 meta/recipes-devtools/gdb/gdb-9.1.inc |  21 +++
 ...ian_8.3.1.bb => gdb-cross-canadian_9.1.bb} |   0
 .../{gdb-cross_8.3.1.bb => gdb-cross_9.1.bb}  |   0
 .../gdb/0001-gdbserver-ctrl-c-handling.patch  |  26 
 ...ake-man-install-relative-to-DESTDIR.patch} |   9 +-
 ...x-nat-Define-_ABIO32-if-not-defined.patch} |   9 +-
 ...-pt_regs-uapi_pt_regs-on-GLIBC-syst.patch} |   7 +-
 ...ort-for-Renesas-SH-sh4-architecture.patch} |  41 +++---
 ...eadline.a-when-using-disable-static.patch} |  13 +-
 ...s.h.patch => 0006-use-asm-sgidefs.h.patch} |   9 +-
 ...Use-exorted-definitions-of-SIGRTMIN.patch} |  11 +-
 ...atch => 0008-Change-order-of-CFLAGS.patch} |  13 +-
 ...9-resolve-restrict-keyword-conflict.patch} |  17 +--
 ...> 0010-Fix-invalid-sigprocmask-call.patch} |  23 ++-
 .../gdb/0011-gdbserver-ctrl-c-handling.patch  |  39 ++
 .../gdb/gdb/CVE-2019-1010180.patch| 132 --
 .../gdb/{gdb_8.3.1.bb => gdb_9.1.bb}  |   0
 19 files changed, 124 insertions(+), 270 deletions(-)
 delete mode 100644 meta/recipes-devtools/gdb/gdb-8.3.1.inc
 create mode 100644 meta/recipes-devtools/gdb/gdb-9.1.inc
 rename meta/recipes-devtools/gdb/{gdb-cross-canadian_8.3.1.bb => 
gdb-cross-canadian_9.1.bb} (100%)
 rename meta/recipes-devtools/gdb/{gdb-cross_8.3.1.bb => gdb-cross_9.1.bb} 
(100%)
 delete mode 100644 
meta/recipes-devtools/gdb/gdb/0001-gdbserver-ctrl-c-handling.patch
 rename 
meta/recipes-devtools/gdb/gdb/{0002-make-man-install-relative-to-DESTDIR.patch 
=> 0001-make-man-install-relative-to-DESTDIR.patch} (77%)
 rename 
meta/recipes-devtools/gdb/gdb/{0003-mips-linux-nat-Define-_ABIO32-if-not-defined.patch
 => 0002-mips-linux-nat-Define-_ABIO32-if-not-defined.patch} (82%)
 rename 
meta/recipes-devtools/gdb/gdb/{0004-ppc-ptrace-Define-pt_regs-uapi_pt_regs-on-GLIBC-syst.patch
 => 0003-ppc-ptrace-Define-pt_regs-uapi_pt_regs-on-GLIBC-syst.patch} (89%)
 rename 
meta/recipes-devtools/gdb/gdb/{0005-Add-support-for-Renesas-SH-sh4-architecture.patch
 => 0004-Add-support-for-Renesas-SH-sh4-architecture.patch} (96%)
 rename 
meta/recipes-devtools/gdb/gdb/{0006-Dont-disable-libreadline.a-when-using-disable-static.patch
 => 0005-Dont-disable-libreadline.a-when-using-disable-static.patch} (83%)
 rename meta/recipes-devtools/gdb/gdb/{0007-use-asm-sgidefs.h.patch => 
0006-use-asm-sgidefs.h.patch} (84%)
 rename 
meta/recipes-devtools/gdb/gdb/{0008-Use-exorted-definitions-of-SIGRTMIN.patch 
=> 0007-Use-exorted-definitions-of-SIGRTMIN.patch} (81%)
 rename meta/recipes-devtools/gdb/gdb/{0009-Change-order-of-CFLAGS.patch => 
0008-Change-order-of-CFLAGS.patch} (75%)
 rename 
meta/recipes-devtools/gdb/gdb/{0010-resolve-restrict-keyword-conflict.patch => 
0009-resolve-restrict-keyword-conflict.patch} (80%)
 rename meta/recipes-devtools/gdb/gdb/{0011-Fix-invalid-sigprocmask-call.patch 
=> 0010-Fix-invalid-sigprocmask-call.patch} (65%)
 create mode 100644 
meta/recipes-devtools/gdb/gdb/0011-gdbserver-ctrl-c-handling.patch
 delete mode 100644 meta/recipes-devtools/gdb/gdb/CVE-2019-1010180.patch
 rename meta/recipes-devtools/gdb/{gdb_8.3.1.bb => gdb_9.1.bb} (100%)

diff --git a/meta/conf/distro/include/tcmode-default.inc 
b/meta/conf/distro/include/tcmode-default.inc
index 23f2ce97c3..82530f5e7b 100644
--- a/meta/conf/distro/include/tcmode-default.inc
+++ b/meta/conf/distro/include/tcmode-default.inc
@@ -19,7 +19,7 @@ PREFERRED_PROVIDER_virtual/gettext ??= "gettext"
 GCCVERSION ?= "9.%"
 SDKGCCVERSION ?= "${GCCVERSION}"
 BINUVERSION ?= "2.33%"
-GDBVERSION ?= "8.3%"
+GDBVERSION ?= "9.%"
 GLIBCVERSION ?= "2.31"
 LINUXLIBCVERSION ?= "5.4%"
 QEMUVERSION ?= "4.2%"
diff --git a/meta/recipes-devtools/gdb/gdb-8.3.1.inc 
b/meta/recipes-devtools/gdb/gdb-8.3.1.inc
deleted file mode 100644
index aec913f3ce..00
--- a/meta/recipes-devtools/gdb/gdb-8.3.1.inc
+++ /dev/null
@@ -1,22 +0,0 @@
-LICENSE = "GPLv2 & GPLv3 & LGPLv2 & LGPLv3"
-LIC_FILES_CHKSUM = "file://COPYING;md5=59530bdf33659b29e73d4adb9f9f6552 \
-   file://COPYING3;md5=d32239bcb673463ab874e80d47fae504 \
-   file://COPYING3.LIB;md5=6a6a8e020838b23406c81b19c1d46df6 \
-   file://COPYING.LIB;md5=9f604d8a4f8e74f4f5140845a21b6674"
-
-SRC_URI = "${GNU_MIRROR}/gdb/gdb-${PV}.tar.xz \
-   file://0001-gdbserver-ctrl-c-handling.patch \
-   file://0002-make-man-install-relative-to-DESTDIR.patch \
-   file://0003-mips-linux-nat-Define-_ABIO32-if-not-defined.patch \
-   
file://0004-ppc-ptrace-Define-pt_regs-uapi_pt_regs-on-GLIBC-syst.patch \
-   file://0005-Add-support-for-Renesas-SH-sh4-architecture.patch \
-

[OE-core] [PATCH 3/3] busybox: Backport patches to support removal of __NR_clock_gettime

This helps compiling with musl on 32bit arches now that musl has
switched to 64bit time_t

Signed-off-by: Khem Raj 
---
 ...rappers-around-clock_gettime-closes-.patch | 113 ++
 ...-Use-64-prefix-syscall-if-we-have-to.patch |  53 
 ...-Use-64-prefix-syscall-if-we-have-to.patch |  43 +++
 meta/recipes-core/busybox/busybox_1.31.1.bb   |   3 +
 4 files changed, 212 insertions(+)
 create mode 100644 
meta/recipes-core/busybox/busybox/0001-Remove-syscall-wrappers-around-clock_gettime-closes-.patch
 create mode 100644 
meta/recipes-core/busybox/busybox/0001-date-Use-64-prefix-syscall-if-we-have-to.patch
 create mode 100644 
meta/recipes-core/busybox/busybox/0001-time-Use-64-prefix-syscall-if-we-have-to.patch

diff --git 
a/meta/recipes-core/busybox/busybox/0001-Remove-syscall-wrappers-around-clock_gettime-closes-.patch
 
b/meta/recipes-core/busybox/busybox/0001-Remove-syscall-wrappers-around-clock_gettime-closes-.patch
new file mode 100644
index 00..f6fbed338a
--- /dev/null
+++ 
b/meta/recipes-core/busybox/busybox/0001-Remove-syscall-wrappers-around-clock_gettime-closes-.patch
@@ -0,0 +1,113 @@
+From be5a505d771a77c640acc35ceaa470c80e62f954 Mon Sep 17 00:00:00 2001
+From: Denys Vlasenko 
+Date: Thu, 24 Oct 2019 16:26:55 +0200
+Subject: [PATCH] Remove syscall wrappers around clock_gettime, closes 12091
+
+12091 "Direct use of __NR_clock_gettime is not time64-safe".
+
+function old new   delta
+runsv_main  16981712 +14
+startservice 378 383  +5
+get_mono  31  25  -6
+date_main932 926  -6
+gettimeofday_ns   17   - -17
+--
+(add/remove: 0/1 grow/shrink: 2/2 up/down: 19/-29)Total: -10 bytes
+
+Signed-off-by: Denys Vlasenko 
+---
+Upstream-Status: Backport 
[https://git.busybox.net/busybox/commit/?id=be5a505d771a77c640acc35ceaa470c80e62f954]
+ Makefile.flags   |  6 --
+ coreutils/date.c | 16 +++-
+ libbb/time.c | 11 +--
+ runit/runsv.c| 11 +--
+ 4 files changed, 9 insertions(+), 35 deletions(-)
+
+--- a/Makefile.flags
 b/Makefile.flags
+@@ -129,10 +129,12 @@ endif
+ # fall back to using a temp file:
+ CRYPT_AVAILABLE := $(shell echo 'int main(void){return 0;}' >crypttest.c; 
$(CC) $(CFLAGS) -lcrypt -o /dev/null crypttest.c >/dev/null 2>&1 && echo "y"; 
rm crypttest.c)
+ ifeq ($(CRYPT_AVAILABLE),y)
+-LDLIBS += m crypt
++LDLIBS += m rt crypt
+ else
+-LDLIBS += m
++LDLIBS += m rt
+ endif
++# libm may be needed for dc, awk, ntpd
++# librt may be needed for clock_gettime()
+ 
+ # libpam may use libpthread, libdl and/or libaudit.
+ # On some platforms that requires an explicit -lpthread, -ldl, -laudit.
+--- a/coreutils/date.c
 b/coreutils/date.c
+@@ -33,10 +33,9 @@
+ //config: Enable option (-I) to output an ISO-8601 compliant
+ //config: date/time string.
+ //config:
+-//config:# defaults to "no": stat's nanosecond field is a bit non-portable
+ //config:config FEATURE_DATE_NANO
+ //config: bool "Support %[num]N nanosecond format specifier"
+-//config: default n  # syscall(__NR_clock_gettime) or 
syscall(__NR_clock_gettime64)
++//config: default n # stat's nanosecond field is a bit non-portable
+ //config: depends on DATE
+ //config: select PLATFORM_LINUX
+ //config: help
+@@ -271,17 +270,8 @@ int date_main(int argc UNUSED_PARAM, cha
+*/
+ #endif
+   } else {
+-#if ENABLE_FEATURE_DATE_NANO && defined(__NR_clock_gettime)
+-  /* libc has incredibly messy way of doing this,
+-   * typically requiring -lrt. We just skip all this mess */
+-  syscall(__NR_clock_gettime, CLOCK_REALTIME, );
+-#elif ENABLE_FEATURE_DATE_NANO && __TIMESIZE == 64
+-  /* Let's only suppor the 64 suffix syscalls for 64-bit time_t.
+-   * This simplifies the code for us as we don't need to convert
+-   * between 64-bit and 32-bit. We also don't have a way to
+-   * report overflow errors here.
+-   */
+-  syscall(__NR_clock_gettime64, CLOCK_REALTIME, );
++#if ENABLE_FEATURE_DATE_NANO
++  clock_gettime(CLOCK_REALTIME, );
+ #else
+   time(_sec);
+ #endif
+--- a/libbb/time.c
 b/libbb/time.c
+@@ -253,18 +253,9 @@ char* FAST_FUNC strftime_MMDDHHMMSS(
+ #define CLOCK_MONOTONIC 1
+ #endif
+ 
+-/* libc has incredibly messy way of doing this,
+- * typically requiring -lrt. We just skip all this mess */
+ static void get_mono(struct timespec *ts)
+ {
+-#if defined(__NR_clock_gettime)
+-  if (syscall(__NR_clock_gettime, CLOCK_MONOTONIC, ts))
+-#elif __TIMESIZE == 64
+-  if (syscall(__NR_clock_gettime64,

[OE-core] [PATCH 1/3] musl: Update to latest tip

Detailed changelog is here [1]

[1] 
https://git.musl-libc.org/cgit/musl/log/?qt=range=e6093b5a870a38ebfb3e54382acd48c698bde15d..a662220df547e5c2446518e74440a7d834f9ebe6

Signed-off-by: Khem Raj 
Signed-off-by: Richard Purdie 
---
 meta/recipes-core/musl/musl_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/musl/musl_git.bb 
b/meta/recipes-core/musl/musl_git.bb
index f4853b4f2e..b6ec6fe9af 100644
--- a/meta/recipes-core/musl/musl_git.bb
+++ b/meta/recipes-core/musl/musl_git.bb
@@ -4,7 +4,7 @@
 require musl.inc
 inherit linuxloader
 
-SRCREV = "e6093b5a870a38ebfb3e54382acd48c698bde15d"
+SRCREV = "a662220df547e5c2446518e74440a7d834f9ebe6"
 
 BASEVER = "1.1.24"
 
-- 
2.25.0

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

Re: [OE-core] [PATCH] swuashfs-tools: Enable on musl

On Fri, Feb 14, 2020 at 6:49 AM Robert P. J. Day  wrote:
>
>
>   "swuashfs"?
>

I think I sent a v2

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

Re: [OE-core] [PATCH] staging: Handle races between binaries and their libs

On Fri, 2020-02-14 at 06:46 -0800, Khem Raj wrote:
> On Fri, Feb 14, 2020 at 5:03 AM Richard Purdie
>  wrote:
> > There is a long standing issue where a binary could be installed
> > into the
> > sysroot before its library dependencies. We've always argued
> > nothing should
> > use the binary until its been installed by a dependency but there
> > are issues
> > around binaries which conflict with the host system, for example
> > patch,
> > python3, gzip and more.
> > 
> > With the recent patch changes we've see issues like:
> > ERROR: gdb-cross-canadian-powerpc-8.3.1-r0 do_patch: Command Error:
> > 'quilt --quiltrc /home/pokybuild/yocto-
> > worker/qemuppc/build/build/tmp/work/x86_64-nativesdk-pokysdk-
> > linux/gdb-cross-canadian-powerpc/8.3.1-r0/recipe-sysroot-
> > native/etc/quiltrc push' exited with 0  Output:
> > Applying patch 0009-Change-order-of-CFLAGS.patch
> > patch: /lib64/libattr.so.1: version `ATTR_1.3' not found (required
> > by patch)
> > Patch 0009-Change-order-of-CFLAGS.patch does not apply (enforce
> > with -f)
> > 
> > which is a symptom of this issue (libattr-native is a dependency of
> > patch-native).
> > 
> 
> ah so this was the problem I wondered

Its one problem we're seeing, I'm still not sure those two other
patches of yours apply cleanly though... :/

Cheers,

Richard

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

Re: [OE-core] [PATCH] swuashfs-tools: Enable on musl

2020-02-14 Thread Robert P. J. Day



  "swuashfs"?

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

Re: [OE-core] [PATCH] staging: Handle races between binaries and their libs

On Fri, Feb 14, 2020 at 5:03 AM Richard Purdie
 wrote:
>
> There is a long standing issue where a binary could be installed into the
> sysroot before its library dependencies. We've always argued nothing should
> use the binary until its been installed by a dependency but there are issues
> around binaries which conflict with the host system, for example patch,
> python3, gzip and more.
>
> With the recent patch changes we've see issues like:
> ERROR: gdb-cross-canadian-powerpc-8.3.1-r0 do_patch: Command Error: 'quilt 
> --quiltrc 
> /home/pokybuild/yocto-worker/qemuppc/build/build/tmp/work/x86_64-nativesdk-pokysdk-linux/gdb-cross-canadian-powerpc/8.3.1-r0/recipe-sysroot-native/etc/quiltrc
>  push' exited with 0  Output:
> Applying patch 0009-Change-order-of-CFLAGS.patch
> patch: /lib64/libattr.so.1: version `ATTR_1.3' not found (required by patch)
> Patch 0009-Change-order-of-CFLAGS.patch does not apply (enforce with -f)
>
> which is a symptom of this issue (libattr-native is a dependency of 
> patch-native).
>

ah so this was the problem I wondered

> There are other ways to fix this such as disabling libattr in patch, 
> installing
> patch to a subdirectory and requiring PATH manipulation and so on.
>
> We can simply fix the staging code to handle /bin/ after everything else so 
> lets
> do that and avoid all these other complications.
>
> Signed-off-by: Richard Purdie 
> ---
>  meta/classes/staging.bbclass | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/meta/classes/staging.bbclass b/meta/classes/staging.bbclass
> index 4dd2ed01010..530e23b1853 100644
> --- a/meta/classes/staging.bbclass
> +++ b/meta/classes/staging.bbclass
> @@ -470,6 +470,7 @@ python extend_recipe_sysroot() {
>  elif os.path.lexists(depdir + "/" + c):
>  os.unlink(depdir + "/" + c)
>
> +binfiles = {}
>  # Now handle installs
>  for dep in configuredeps:
>  c = setscenedeps[dep][0]
> @@ -562,7 +563,16 @@ python extend_recipe_sysroot() {
>  if l.endswith("/"):
>  staging_copydir(l, targetdir, dest, seendirs)
>  continue
> -staging_copyfile(l, targetdir, dest, postinsts, seendirs)
> +if "/bin/" in l:
> +# defer /bin/* files until last in case they need 
> libs
> +binfiles[l] = (targetdir, dest)
> +else:
> +staging_copyfile(l, targetdir, dest, postinsts, 
> seendirs)
> +
> +# Handle deferred binfiles
> +for l in binfiles:
> +(targetdir, dest) = binfiles[l]
> +staging_copyfile(l, targetdir, dest, postinsts, seendirs)
>
>  bb.note("Installed into sysroot: %s" % str(msg_adding))
>  bb.note("Skipping as already exists in sysroot: %s" % str(msg_exists))
> --
> 2.20.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [OE-Core][PATCH v2] systemd: upgrade v244.1 -> v244.3

2020-02-14 Thread Alex Kiernan

On Fri, Feb 14, 2020 at 7:25 AM Alex Kiernan  wrote:
>
> On Fri, Feb 14, 2020 at 7:17 AM Khem Raj  wrote:
> >
> > On Thu, Feb 13, 2020 at 3:40 PM Richard Purdie
> >  wrote:
> > >
> > > On Thu, 2020-02-13 at 06:16 +, Alex Kiernan wrote:
> > > > Commits from v244-stable:
> > >
> > > I think this causes:
> > >
> > > https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/1557
> > >
> > > (systemd-boot patch failures)
> >
> > right
> > http://errors.yoctoproject.org/Errors/Details/390912/
> >
>
> Yeah... just trying to work out if there's a better way to handle the
> efi-cc stuff w/o having an even larger set of reverts against
> meson.build :|
>

It looks like by making meson.cross configurable I can drop all the
reverts, which should get us to a better place for future upgrades.
I've run the obvious pieces of oe-selftest, but I'll clean up the
hacky mess I've got and send up a full patchset if we can push it
through the autobuilders.

Or reverting the latest commit on meson.build does fix it, but that
feels like we're just digging an even deeper hole!

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

Re: [OE-core] [PATCH] swuashfs-tools: Enable on musl

On Fri, Feb 14, 2020 at 6:35 AM Adrian Bunk  wrote:
>
> On Thu, Feb 13, 2020 at 11:03:52PM -0800, Khem Raj wrote:
> > Upstream has a patch [1] to fix musl builds, Prior to this it would not
> > build on musl due to missing GNU extentions for fnmatch
> >
> > [1] 
> > https://github.com/plougher/squashfs-tools/commit/4280e74de14070869787a9166242f9ce2dafd82e
> >...
>
> I did already remove a similar bogus squashfs-tools change from OE,
> with similar FNM_EXTMATCH "fixes" in ifupdown and elfutils
> also resulting in the expected runtime misbehaviour.
>

I think it would be better to use gnulib implementation for these
packages you point out
and those patches will be upstream worthy and make them portable
as well.
At least it is calling out bad elements.

> I am not a fan of this musl way of fixing build failures by turning them
> into runtime breakages.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] swuashfs-tools: Enable on musl

2020-02-14 Thread Adrian Bunk

On Thu, Feb 13, 2020 at 11:03:52PM -0800, Khem Raj wrote:
> Upstream has a patch [1] to fix musl builds, Prior to this it would not
> build on musl due to missing GNU extentions for fnmatch
> 
> [1] 
> https://github.com/plougher/squashfs-tools/commit/4280e74de14070869787a9166242f9ce2dafd82e
>...

I did already remove a similar bogus squashfs-tools change from OE,
with similar FNM_EXTMATCH "fixes" in ifupdown and elfutils
also resulting in the expected runtime misbehaviour.

I am not a fan of this musl way of fixing build failures by turning them
into runtime breakages.

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

Re: [OE-core] [PATCH 3/4] recipes-support: Add diffoscope recipe

On Fri, Feb 14, 2020 at 6:18 AM Richard Purdie
 wrote:
>
> On Fri, 2020-02-14 at 07:15 -0600, Joshua Watt wrote:
> >
> >
> > On Fri, Feb 14, 2020, 12:34 AM Khem Raj  wrote:
> > > Hi Joshua
> > >
> > > I think it needs to be ignored on musl
> > >
> > > 15:37:23 ERROR: Nothing RPROVIDES 'squashfs-tools' (but
> > > /mnt/jenkins/workspace/Yocto-world-musl/sources/openembedded-
> > > core/meta/recipes-support/diffoscope/diffoscope_136.bb
> > > RDEPENDS on or otherwise requires it)
> > > 15:37:23 squashfs-tools was skipped: incompatible with host
> > > aarch64-yoe-linux-musl (not in COMPATIBLE_HOST
> >
> > Would an RRECOMMENDS fix it?
>
> I merged your patch and one of mine to follow it adding a
> COMPATIBLE_HOST entry.
>
> I see Khem is fixing some other software so we may end up not needing
> it but we can remove later.
>

right, we were unnecessarily masking squashfs-tools for musl

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

Re: [OE-core] [PATCH 3/4] recipes-support: Add diffoscope recipe

On Fri, 2020-02-14 at 07:15 -0600, Joshua Watt wrote:
> 
> 
> On Fri, Feb 14, 2020, 12:34 AM Khem Raj  wrote:
> > Hi Joshua
> > 
> > I think it needs to be ignored on musl
> > 
> > 15:37:23 ERROR: Nothing RPROVIDES 'squashfs-tools' (but
> > /mnt/jenkins/workspace/Yocto-world-musl/sources/openembedded-
> > core/meta/recipes-support/diffoscope/diffoscope_136.bb
> > RDEPENDS on or otherwise requires it)
> > 15:37:23 squashfs-tools was skipped: incompatible with host
> > aarch64-yoe-linux-musl (not in COMPATIBLE_HOST
> 
> Would an RRECOMMENDS fix it?

I merged your patch and one of mine to follow it adding a
COMPATIBLE_HOST entry.

I see Khem is fixing some other software so we may end up not needing
it but we can remove later.

Cheers,

Richard

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

Re: [OE-core] [RESEND PATCH v2] make: 4.2.1 -> 4.3

On Thu, 2020-02-13 at 14:36 +0100, Jens Rehsack wrote:
> Announcement: 
> https://lists.gnu.org/archive/html/bug-make/2020-01/msg00057.html
> 
> 1) Remove upstream provided patches 0001-glob-Do-not-assume-glibc-
> glob-internals.patch
>and 0002-glob-Do-not-assume-glibc-glob-internals.patch.
> 
> 2) License has been changed to GPLv3 only
> 
> 3) Important bug-fix is
>* 
> https://lists.gnu.org/archive/html/bug-make/2018-09/msg6.html
> 
> 4) Backward-incompatibilities:
>* Number signs (#) appearing inside a macro reference or function
> invocation
>  no longer introduce comments and should not be escaped with
> backslashes
>* Previously appending using '+=' to an empty variable would
> result in a value
>  starting with a space.  Now the initial space is only added if
> the variable
>  already contains some value.  Similarly, appending an empty
> string does not
>  add a trailing space.
> 
> Signed-off-by: Jens Rehsack 

It breaks nativesdk-make with meta-mingw:

https://autobuilder.yoctoproject.org/typhoon/#/builders/89/builds/1562

Cheers,

Richard

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

Re: [OE-core] [PATCH v3] perf: Correct the substitution of python shebangs

2020-02-14 Thread Bruce Ashfield

On Thu, Feb 13, 2020 at 10:58 PM  wrote:
>
> From: He Zhe 
>
> To make the native python3 is always used,
>
> - Use sed one-liner instead
> - Add substitution for ${S}/scripts/bpf_helpers_doc.py to fix the
>   following warning.
>
> File "/usr/lib/python3.6/sysconfig.py", line 421, in _init_posix
> _temp = __import__(name, globals(), locals(), ['build_time_vars'], 0)
> ModuleNotFoundError: No module named '_sysconfigdata'
>
> This issue is first reported by Joel Stanley 
> The sed one-liner is credited to Anuj Mittal 

Thanks!

This looks good to me.

Cheers,

Bruce

>
> Signed-off-by: He Zhe 
> ---
>  meta/recipes-kernel/perf/perf.bb | 7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/meta/recipes-kernel/perf/perf.bb 
> b/meta/recipes-kernel/perf/perf.bb
> index 6d1b06693d..a6fb51d3db 100644
> --- a/meta/recipes-kernel/perf/perf.bb
> +++ b/meta/recipes-kernel/perf/perf.bb
> @@ -239,11 +239,8 @@ do_configure_prepend () {
>  fi
>
>  # use /usr/bin/env instead of version specific python
> -for s in `find ${S}/tools/perf/ -name '*.py'`; do
> -sed -i 's,/usr/bin/python,/usr/bin/env python3,' "${s}"
> -sed -i 's,/usr/bin/python2,/usr/bin/env python3,' "${s}"
> -sed -i 's,/usr/bin/env python2,/usr/bin/env python3,' "${s}"
> -sed -i 's,/usr/bin/python3,/usr/bin/env python3,' "${s}"
> +for s in `find ${S}/tools/perf/ -name '*.py'` 
> ${S}/scripts/bpf_helpers_doc.py; do
> +sed -i -e "s,#!.*python.*,#!${USRBINPATH}/env python3," ${s}
>  done
>
>  # unistd.h can be out of sync between libc-headers and the captured 
> version in the perf source
> --
> 2.24.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



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

Re: [OE-core] [PATCH 3/4] recipes-support: Add diffoscope recipe

2020-02-14 Thread Joshua Watt

On Fri, Feb 14, 2020, 12:34 AM Khem Raj  wrote:

> Hi Joshua
>
> I think it needs to be ignored on musl
>
> 15:37:23 ERROR: Nothing RPROVIDES 'squashfs-tools' (but
>
> /mnt/jenkins/workspace/Yocto-world-musl/sources/openembedded-core/meta/recipes-support/diffoscope/
> diffoscope_136.bb
> RDEPENDS on or otherwise requires it)
> 15:37:23 squashfs-tools was skipped: incompatible with host
> aarch64-yoe-linux-musl (not in COMPATIBLE_HOST
>

Would an RRECOMMENDS fix it?


> On Tue, Feb 11, 2020 at 7:15 PM Joshua Watt  wrote:
> >
> > Diffoscope is the universal diff tool, capable of comparing many
> > different formats.
> >
> > Signed-off-by: Joshua Watt 
> > ---
> >  meta/conf/distro/include/maintainers.inc  |  1 +
> >  meta/recipes-support/diffoscope/diffoscope_136.bb | 15 +++
> >  2 files changed, 16 insertions(+)
> >  create mode 100644 meta/recipes-support/diffoscope/diffoscope_136.bb
> >
> > diff --git a/meta/conf/distro/include/maintainers.inc
> b/meta/conf/distro/include/maintainers.inc
> > index 171a43615e3..4a267faabce 100644
> > --- a/meta/conf/distro/include/maintainers.inc
> > +++ b/meta/conf/distro/include/maintainers.inc
> > @@ -146,6 +146,7 @@ RECIPE_MAINTAINER_pn-dejagnu = "Nathan Rossi <
> nat...@nathanrossi.com>"
> >  RECIPE_MAINTAINER_pn-depmodwrapper-cross = "Mark Hatle <
> mark.ha...@windriver.com>"
> >  RECIPE_MAINTAINER_pn-desktop-file-utils = "Alexander Kanavin <
> alex.kana...@gmail.com>"
> >  RECIPE_MAINTAINER_pn-dhcp = "Hongxu Jia "
> > +RECIPE_MAINTAINER_pn-diffoscope = "Joshua Watt "
> >  RECIPE_MAINTAINER_pn-diffstat = "Chen Qi "
> >  RECIPE_MAINTAINER_pn-diffutils = "Chen Qi "
> >  RECIPE_MAINTAINER_pn-distcc = "Hongxu Jia "
> > diff --git a/meta/recipes-support/diffoscope/diffoscope_136.bb
> b/meta/recipes-support/diffoscope/diffoscope_136.bb
> > new file mode 100644
> > index 000..a00f281deb0
> > --- /dev/null
> > +++ b/meta/recipes-support/diffoscope/diffoscope_136.bb
> > @@ -0,0 +1,15 @@
> > +SUMMARY = "in-depth comparison of files, archives, and directories"
> > +HOMEPAGE = "https://diffoscope.org/;
> > +LICENSE = "GPL-3.0+"
> > +LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
> > +
> > +PYPI_PACKAGE = "diffoscope"
> > +
> > +inherit pypi setuptools3
> > +
> > +SRC_URI[md5sum] = "c84d8d308a40176ba2f5dc4abdbf6f73"
> > +SRC_URI[sha256sum] =
> "0d6486d6eb6e0445ba21fee2e8bdd3a366ce786bfac98e00e5a95038b7815f15"
> > +
> > +RDEPENDS_${PN} += "binutils vim squashfs-tools python3-libarchive-c
> python3-magic"
> > +
> > +BBCLASSEXTEND = "native"
> > --
> > 2.23.0
> >
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] what is MACHINE_HWCODECS used for these days?

2020-02-14 Thread Robert P. J. Day



  was documenting the use of [EXTRA_]IMAGE_FEATURES, and noticed that
while the oe-core layer defines a related feature:

  core-image.bbclass:FEATURE_PACKAGES_hwcodecs = "${MACHINE_HWCODECS}"
  core-image.bbclass:MACHINE_HWCODECS ??= ""

i see no actual usage of that variable in oe-core (the git log goes
way back to 2013:

  commit 1cb370587fd72e3f0f69678748108cc4116767fb
  Author: Richard Purdie 
  Date:   Wed Jan 23 21:56:11 2013 -0800

core-image: Add hwcodecs IMAGE_FEATURE

Currently hardware codecs are being injected in rather ugly ways and end up
either in no or all images. This adds a dedicated IMAGE_FEATURE for them 
based
on the MACHINE_HWCODECS variable. We may need to refine this in due course
but this patch at least illustrates the concept.

i looked through other layers on my system, and found some references
in meta-intel:

conf/machine/intel-core2-32.conf:MACHINE_HWCODECS ?= "intel-vaapi-driver 
gstreamer1.0-vaapi"
conf/machine/intel-corei7-64.conf:MACHINE_HWCODECS ?= 
"${@bb.utils.contains('TUNE_FEATURES', 'mx32', '', 'intel-media-driver
intel-mediasdk', d)} intel-vaapi-driver gstreamer1.0-vaapi"
conf/machine/intel-skylake-64.conf:MACHINE_HWCODECS ?= "intel-media-driver 
intel-mediasdk intel-vaapi-driver
gstreamer1.0-vaapi"

but i see nothing in *that* layer that actually does anything with
that variable after setting it. what is it used for? and how is it
processed?

rday

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

[OE-core] [PATCH] staging: Handle races between binaries and their libs

There is a long standing issue where a binary could be installed into the
sysroot before its library dependencies. We've always argued nothing should
use the binary until its been installed by a dependency but there are issues
around binaries which conflict with the host system, for example patch,
python3, gzip and more.

With the recent patch changes we've see issues like:
ERROR: gdb-cross-canadian-powerpc-8.3.1-r0 do_patch: Command Error: 'quilt 
--quiltrc 
/home/pokybuild/yocto-worker/qemuppc/build/build/tmp/work/x86_64-nativesdk-pokysdk-linux/gdb-cross-canadian-powerpc/8.3.1-r0/recipe-sysroot-native/etc/quiltrc
 push' exited with 0  Output:
Applying patch 0009-Change-order-of-CFLAGS.patch
patch: /lib64/libattr.so.1: version `ATTR_1.3' not found (required by patch)
Patch 0009-Change-order-of-CFLAGS.patch does not apply (enforce with -f)

which is a symptom of this issue (libattr-native is a dependency of 
patch-native).

There are other ways to fix this such as disabling libattr in patch, installing
patch to a subdirectory and requiring PATH manipulation and so on.

We can simply fix the staging code to handle /bin/ after everything else so lets
do that and avoid all these other complications.

Signed-off-by: Richard Purdie 
---
 meta/classes/staging.bbclass | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/meta/classes/staging.bbclass b/meta/classes/staging.bbclass
index 4dd2ed01010..530e23b1853 100644
--- a/meta/classes/staging.bbclass
+++ b/meta/classes/staging.bbclass
@@ -470,6 +470,7 @@ python extend_recipe_sysroot() {
 elif os.path.lexists(depdir + "/" + c):
 os.unlink(depdir + "/" + c)
 
+binfiles = {}
 # Now handle installs
 for dep in configuredeps:
 c = setscenedeps[dep][0]
@@ -562,7 +563,16 @@ python extend_recipe_sysroot() {
 if l.endswith("/"):
 staging_copydir(l, targetdir, dest, seendirs)
 continue
-staging_copyfile(l, targetdir, dest, postinsts, seendirs)
+if "/bin/" in l:
+# defer /bin/* files until last in case they need libs
+binfiles[l] = (targetdir, dest)
+else:
+staging_copyfile(l, targetdir, dest, postinsts, 
seendirs)
+
+# Handle deferred binfiles
+for l in binfiles:
+(targetdir, dest) = binfiles[l]
+staging_copyfile(l, targetdir, dest, postinsts, seendirs)
 
 bb.note("Installed into sysroot: %s" % str(msg_adding))
 bb.note("Skipping as already exists in sysroot: %s" % str(msg_exists))
-- 
2.20.1

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

Re: [OE-core] [PATCH 0/9] recipe updates, testing fixes

2020-02-14 Thread Alexander Kanavin

On Fri, 14 Feb 2020 at 08:15, Khem Raj  wrote:

> local.conf I have
>
> DISTRO_FEATURES_append = " largefile opengl ptest multiarch wayland pam
> polkit "
> IMAGE_CLASSES += "testimage testsdk"
>

Right, I'm running this now, it's a bit tricky because I have to do it on
the Yocto AB. Big company's bureaucracy is causing delays in getting me a
build machine :(

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

[OE-core] [PATCH v2 2/2] libxml2: Fix CVE-2019-20388

From: Lee Chee Yang 

see:
https://gitlab.gnome.org/GNOME/libxml2/merge_requests/68

Signed-off-by: Lee Chee Yang 
---
 .../libxml/libxml2/CVE-2019-20388.patch| 37 ++
 meta/recipes-core/libxml/libxml2_2.9.10.bb |  1 +
 2 files changed, 38 insertions(+)
 create mode 100644 meta/recipes-core/libxml/libxml2/CVE-2019-20388.patch

diff --git a/meta/recipes-core/libxml/libxml2/CVE-2019-20388.patch 
b/meta/recipes-core/libxml/libxml2/CVE-2019-20388.patch
new file mode 100644
index 000..4ee2d4f
--- /dev/null
+++ b/meta/recipes-core/libxml/libxml2/CVE-2019-20388.patch
@@ -0,0 +1,37 @@
+From 7ffcd44d7e6c46704f8af0321d9314cd26e0e18a Mon Sep 17 00:00:00 2001
+From: Zhipeng Xie 
+Date: Tue, 20 Aug 2019 16:33:06 +0800
+Subject: [PATCH] Fix memory leak in xmlSchemaValidateStream
+
+When ctxt->schema is NULL, xmlSchemaSAXPlug->xmlSchemaPreRun
+alloc a new schema for ctxt->schema and set vctxt->xsiAssemble
+to 1. Then xmlSchemaVStart->xmlSchemaPreRun initialize
+vctxt->xsiAssemble to 0 again which cause the alloced schema
+can not be freed anymore.
+
+Found with libFuzzer.
+
+Upstream-Status: Accepted 
[https://gitlab.gnome.org/GNOME/libxml2/commit/7ffcd44d7e6c46704f8af0321d9314cd26e0e18a]
+CVE: CVE-2019-20388
+
+Signed-off-by: Zhipeng Xie 
+Signed-off-by: Lee Chee Yang 
+---
+ xmlschemas.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/xmlschemas.c b/xmlschemas.c
+index 301c8449..39d92182 100644
+--- a/xmlschemas.c
 b/xmlschemas.c
+@@ -28090,7 +28090,6 @@ xmlSchemaPreRun(xmlSchemaValidCtxtPtr vctxt) {
+ vctxt->nberrors = 0;
+ vctxt->depth = -1;
+ vctxt->skipDepth = -1;
+-vctxt->xsiAssemble = 0;
+ vctxt->hasKeyrefs = 0;
+ #ifdef ENABLE_IDC_NODE_TABLES_TEST
+ vctxt->createIDCNodeTables = 1;
+-- 
+2.24.1
+
diff --git a/meta/recipes-core/libxml/libxml2_2.9.10.bb 
b/meta/recipes-core/libxml/libxml2_2.9.10.bb
index 6a4097c..097aceb 100644
--- a/meta/recipes-core/libxml/libxml2_2.9.10.bb
+++ b/meta/recipes-core/libxml/libxml2_2.9.10.bb
@@ -21,6 +21,7 @@ SRC_URI = 
"http://www.xmlsoft.org/sources/libxml2-${PV}.tar.gz;name=libtar \

file://0001-Make-ptest-run-the-python-tests-if-python-is-enabled.patch \
file://fix-execution-of-ptests.patch \
file://CVE-2020-7595.patch \
+   file://CVE-2019-20388.patch \
"
 
 SRC_URI[libtar.md5sum] = "10942a1dc23137a8aa07f0639cbfece5"
-- 
2.7.4

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

[OE-core] [PATCH v2 1/2] bash: include patch 12-16

From: Lee Chee Yang 

Signed-off-by: Lee Chee Yang 
---
 meta/recipes-extended/bash/bash_5.0.bb | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/meta/recipes-extended/bash/bash_5.0.bb 
b/meta/recipes-extended/bash/bash_5.0.bb
index 0c7b234..8ff9e6e 100644
--- a/meta/recipes-extended/bash/bash_5.0.bb
+++ b/meta/recipes-extended/bash/bash_5.0.bb
@@ -16,6 +16,11 @@ SRC_URI = "${GNU_MIRROR}/bash/${BP}.tar.gz;name=tarball \

${GNU_MIRROR}/bash/bash-${PV}-patches/bash50-009;apply=yes;striplevel=0;name=patch009
 \

${GNU_MIRROR}/bash/bash-${PV}-patches/bash50-010;apply=yes;striplevel=0;name=patch010
 \

${GNU_MIRROR}/bash/bash-${PV}-patches/bash50-011;apply=yes;striplevel=0;name=patch011
 \
+   
${GNU_MIRROR}/bash/bash-${PV}-patches/bash50-012;apply=yes;striplevel=0;name=patch012
 \
+   
${GNU_MIRROR}/bash/bash-${PV}-patches/bash50-013;apply=yes;striplevel=0;name=patch013
 \
+   
${GNU_MIRROR}/bash/bash-${PV}-patches/bash50-014;apply=yes;striplevel=0;name=patch014
 \
+   
${GNU_MIRROR}/bash/bash-${PV}-patches/bash50-015;apply=yes;striplevel=0;name=patch015
 \
+   
${GNU_MIRROR}/bash/bash-${PV}-patches/bash50-016;apply=yes;striplevel=0;name=patch016
 \
file://execute_cmd.patch \
file://mkbuiltins_have_stringize.patch \
file://build-tests.patch \
@@ -50,6 +55,16 @@ SRC_URI[patch010.md5sum] = "19b41e73b03602d0e261c471b53e670c"
 SRC_URI[patch010.sha256sum] = 
"d6fbc325f0b5dc54ddbe8ee43020bced8bd589ddffea59d128db14b2e52a8a11"
 SRC_URI[patch011.md5sum] = "414339330a3634137081a97f2c8615a8"
 SRC_URI[patch011.sha256sum] = 
"2c4de332b91eaf797abbbd6c79709690b5cbd48b12e8dfe748096dbd7bf474ea"
+SRC_URI[patch012.md5sum] = "1870268f62b907221b078ad109e1fa94"
+SRC_URI[patch012.sha256sum] = 
"2943ee19688018296f2a04dbfe30b7138b889700efa8ff1c0524af271e0ee233"
+SRC_URI[patch013.md5sum] = "40d923af4b952b01983ed4c889ae2653"
+SRC_URI[patch013.sha256sum] = 
"f5d7178d8da30799e01b83a0802018d913d6aa972dd2ddad3b927f3f3eb7099a"
+SRC_URI[patch014.md5sum] = "57857b22053c8167677e5e5ac5c6669b"
+SRC_URI[patch014.sha256sum] = 
"5d6eee6514ee6e22a87bba8d22be0a8621a0ae119246f1c5a9a35db1f72af589"
+SRC_URI[patch015.md5sum] = "c4c6ea23d09a74eaa9385438e48fdf02"
+SRC_URI[patch015.sha256sum] = 
"a517df2dda93b26d5cbf00effefea93e3a4ccd6652f152f4109170544ebfa05e"
+SRC_URI[patch016.md5sum] = "a682ed6fa2c2e7a7c3ba6bdeada07fb5"
+SRC_URI[patch016.sha256sum] = 
"ffd1d7a54a99fa7f5b1825e4f7e95d8c8876bc2ca151f150e751d429c650b06d"
 
 DEBUG_OPTIMIZATION_append_armv4 = " ${@bb.utils.contains('TUNE_CCARGS', 
'-mthumb', '-fomit-frame-pointer', '', d)}"
 DEBUG_OPTIMIZATION_append_armv5 = " ${@bb.utils.contains('TUNE_CCARGS', 
'-mthumb', '-fomit-frame-pointer', '', d)}"
-- 
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 "bash: include patch 12-16..." and 1 more

2020-02-14 Thread Patchwork

== Series Details ==

Series: "bash: include patch 12-16..." and 1 more
Revision: 1
URL   : https://patchwork.openembedded.org/series/22618/
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[2/2] libxml2: Fix CVE-2019-20388
 Issue Missing or incorrectly formatted CVE tag in included patch 
file [test_cve_tag_format] 
  Suggested fixCorrect or include the CVE tag on cve patch with format: 
"CVE: CVE--"

* Issue Added patch file is missing Upstream-Status in the header 
[test_upstream_status_presence_format] 
  Suggested fixAdd Upstream-Status:  to the header of 
meta/recipes-core/libxml/libxml2/CVE-2019-20388.patch
  Standard format  Upstream-Status: 
  Valid status Pending, Accepted, Backport, Denied, Inappropriate [reason], 
Submitted [where]



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] -> ...).

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
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] xkeyboard-config: upgrade 2.28 -> 2.29

On Mon, 2020-02-10 at 09:38 -0800, Wang Mingyu wrote:
> Signed-off-by: Wang Mingyu 
> ---
>  .../{xkeyboard-config_2.28.bb => xkeyboard-config_2.29.bb}| 4
> ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>  rename meta/recipes-graphics/xorg-lib/{xkeyboard-config_2.28.bb =>
> xkeyboard-config_2.29.bb} (87%)

This caused a build failure:

https://autobuilder.yoctoproject.org/typhoon/#/builders/69/builds/1558


ERROR: xkeyboard-config-2.29-r0 do_compile: oe_runmake failed
ERROR: xkeyboard-config-2.29-r0 do_compile: Execution of 
'/home/pokybuild/yocto-worker/qa-extras/build/build/tmp/work/core2-64-poky-linux/xkeyboard-config/2.29-r0/temp/run.do_compile.17426'
 failed with exit code 1:
Making all in compat
make[1]: Entering directory 
'/home/pokybuild/yocto-worker/qa-extras/build/build/tmp/work/core2-64-poky-linux/xkeyboard-config/2.29-r0/build/compat'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory 
'/home/pokybuild/yocto-worker/qa-extras/build/build/tmp/work/core2-64-poky-linux/xkeyboard-config/2.29-r0/build/compat'
Making all in geometry
make[1]: Entering directory 
'/home/pokybuild/yocto-worker/qa-extras/build/build/tmp/work/core2-64-poky-linux/xkeyboard-config/2.29-r0/build/geometry'
Making all in digital_vndr
make[2]: Entering directory 
'/home/pokybuild/yocto-worker/qa-extras/build/build/tmp/work/core2-64-poky-linux/xkeyboard-config/2.29-r0/build/geometry/digital_vndr'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory 
'/home/pokybuild/yocto-worker/qa-extras/build/build/tmp/work/core2-64-poky-linux/xkeyboard-config/2.29-r0/build/geometry/digital_vndr'
Making all in sgi_vndr
make[2]: Entering directory 
'/home/pokybuild/yocto-worker/qa-extras/build/build/tmp/work/core2-64-poky-linux/xkeyboard-config/2.29-r0/build/geometry/sgi_vndr'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory 
'/home/pokybuild/yocto-worker/qa-extras/build/build/tmp/work/core2-64-poky-linux/xkeyboard-config/2.29-r0/build/geometry/sgi_vndr'
make[2]: Entering directory 
'/home/pokybuild/yocto-worker/qa-extras/build/build/tmp/work/core2-64-poky-linux/xkeyboard-config/2.29-r0/build/geometry'
make[2]: Nothing to be done for 'all-am'.
make[2]: Leaving directory 
'/home/pokybuild/yocto-worker/qa-extras/build/build/tmp/work/core2-64-poky-linux/xkeyboard-config/2.29-r0/build/geometry'
make[1]: Leaving directory 
'/home/pokybuild/yocto-worker/qa-extras/build/build/tmp/work/core2-64-poky-linux/xkeyboard-config/2.29-r0/build/geometry'
Making all in keycodes
make[1]: Entering directory 
'/home/pokybuild/yocto-worker/qa-extras/build/build/tmp/work/core2-64-poky-linux/xkeyboard-config/2.29-r0/build/keycodes'
Making all in digital_vndr
make[2]: Entering directory 
'/home/pokybuild/yocto-worker/qa-extras/build/build/tmp/work/core2-64-poky-linux/xkeyboard-config/2.29-r0/build/keycodes/digital_vndr'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory 
'/home/pokybuild/yocto-worker/qa-extras/build/build/tmp/work/core2-64-poky-linux/xkeyboard-config/2.29-r0/build/keycodes/digital_vndr'
Making all in sgi_vndr
make[2]: Entering directory 
'/home/pokybuild/yocto-worker/qa-extras/build/build/tmp/work/core2-64-poky-linux/xkeyboard-config/2.29-r0/build/keycodes/sgi_vndr'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory 
'/home/pokybuild/yocto-worker/qa-extras/build/build/tmp/work/core2-64-poky-linux/xkeyboard-config/2.29-r0/build/keycodes/sgi_vndr'
make[2]: Entering directory 
'/home/pokybuild/yocto-worker/qa-extras/build/build/tmp/work/core2-64-poky-linux/xkeyboard-config/2.29-r0/build/keycodes'
make[2]: Nothing to be done for 'all-am'.
make[2]: Leaving directory 
'/home/pokybuild/yocto-worker/qa-extras/build/build/tmp/work/core2-64-poky-linux/xkeyboard-config/2.29-r0/build/keycodes'
make[1]: Leaving directory 
'/home/pokybuild/yocto-worker/qa-extras/build/build/tmp/work/core2-64-poky-linux/xkeyboard-config/2.29-r0/build/keycodes'
Making all in po
make[1]: Entering directory 
'/home/pokybuild/yocto-worker/qa-extras/build/build/tmp/work/core2-64-poky-linux/xkeyboard-config/2.29-r0/build/po'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory 
'/home/pokybuild/yocto-worker/qa-extras/build/build/tmp/work/core2-64-poky-linux/xkeyboard-config/2.29-r0/build/po'
Making all in rules
make[1]: Entering directory 
'/home/pokybuild/yocto-worker/qa-extras/build/build/tmp/work/core2-64-poky-linux/xkeyboard-config/2.29-r0/build/rules'
Making all in compat
make[2]: Entering directory 
'/home/pokybuild/yocto-worker/qa-extras/build/build/tmp/work/core2-64-poky-linux/xkeyboard-config/2.29-r0/build/rules/compat'
../../../xkeyboard-config-2.29/rules/compat/map-variants.py --want=mls 
--number=2 base.ml2_s.part 
../../../xkeyboard-config-2.29/rules/compat/layoutsMapping.lst 
../../../xkeyboard-config-2.29/rules/compat/variantsMapping.lst
../../../xkeyboard-config-2.29/rules/compat/map-variants.py --want=mls 
--number=3 base.ml3_s.part

[OE-core] [PATCH 2/2] libxml2: Fix CVE-2019-20388

From: Lee Chee Yang 

see:
https://gitlab.gnome.org/GNOME/libxml2/merge_requests/68

Signed-off-by: Lee Chee Yang 
---
 .../libxml/libxml2/CVE-2019-20388.patch| 33 ++
 meta/recipes-core/libxml/libxml2_2.9.10.bb |  1 +
 2 files changed, 34 insertions(+)
 create mode 100644 meta/recipes-core/libxml/libxml2/CVE-2019-20388.patch

diff --git a/meta/recipes-core/libxml/libxml2/CVE-2019-20388.patch 
b/meta/recipes-core/libxml/libxml2/CVE-2019-20388.patch
new file mode 100644
index 000..49ff6fb
--- /dev/null
+++ b/meta/recipes-core/libxml/libxml2/CVE-2019-20388.patch
@@ -0,0 +1,33 @@
+From 7ffcd44d7e6c46704f8af0321d9314cd26e0e18a Mon Sep 17 00:00:00 2001
+From: Zhipeng Xie 
+Date: Tue, 20 Aug 2019 16:33:06 +0800
+Subject: [PATCH] Fix memory leak in xmlSchemaValidateStream
+
+When ctxt->schema is NULL, xmlSchemaSAXPlug->xmlSchemaPreRun
+alloc a new schema for ctxt->schema and set vctxt->xsiAssemble
+to 1. Then xmlSchemaVStart->xmlSchemaPreRun initialize
+vctxt->xsiAssemble to 0 again which cause the alloced schema
+can not be freed anymore.
+
+Found with libFuzzer.
+
+Signed-off-by: Zhipeng Xie 
+---
+ xmlschemas.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/xmlschemas.c b/xmlschemas.c
+index 301c8449..39d92182 100644
+--- a/xmlschemas.c
 b/xmlschemas.c
+@@ -28090,7 +28090,6 @@ xmlSchemaPreRun(xmlSchemaValidCtxtPtr vctxt) {
+ vctxt->nberrors = 0;
+ vctxt->depth = -1;
+ vctxt->skipDepth = -1;
+-vctxt->xsiAssemble = 0;
+ vctxt->hasKeyrefs = 0;
+ #ifdef ENABLE_IDC_NODE_TABLES_TEST
+ vctxt->createIDCNodeTables = 1;
+-- 
+2.24.1
+
diff --git a/meta/recipes-core/libxml/libxml2_2.9.10.bb 
b/meta/recipes-core/libxml/libxml2_2.9.10.bb
index 6a4097c..097aceb 100644
--- a/meta/recipes-core/libxml/libxml2_2.9.10.bb
+++ b/meta/recipes-core/libxml/libxml2_2.9.10.bb
@@ -21,6 +21,7 @@ SRC_URI = 
"http://www.xmlsoft.org/sources/libxml2-${PV}.tar.gz;name=libtar \

file://0001-Make-ptest-run-the-python-tests-if-python-is-enabled.patch \
file://fix-execution-of-ptests.patch \
file://CVE-2020-7595.patch \
+   file://CVE-2019-20388.patch \
"
 
 SRC_URI[libtar.md5sum] = "10942a1dc23137a8aa07f0639cbfece5"
-- 
2.7.4

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

[OE-core] [PATCH 1/2] bash: include patch 12-16