[OE-core] [OE-Core][PATCH] systemd: Add PACKAGECONFIG for openssl

2019-03-25 Thread Alex Kiernan 
Signed-off-by: Alex Kiernan 
---

 meta/recipes-core/systemd/systemd_241.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-core/systemd/systemd_241.bb 
b/meta/recipes-core/systemd/systemd_241.bb
index 6532a58cf8c5..a12b9abee8b8 100644
--- a/meta/recipes-core/systemd/systemd_241.bb
+++ b/meta/recipes-core/systemd/systemd_241.bb
@@ -149,6 +149,7 @@ PACKAGECONFIG[networkd] = "-Dnetworkd=true,-Dnetworkd=false"
 PACKAGECONFIG[nss] = "-Dnss-systemd=true,-Dnss-systemd=false"
 PACKAGECONFIG[nss-mymachines] = "-Dnss-mymachines=true,-Dnss-mymachines=false"
 PACKAGECONFIG[nss-resolve] = "-Dnss-resolve=true,-Dnss-resolve=false"
+PACKAGECONFIG[openssl] = "-Dopenssl=true,-Dopenssl=false,openssl"
 PACKAGECONFIG[pam] = "-Dpam=true,-Dpam=false,libpam,${PAM_PLUGINS}"
 PACKAGECONFIG[polkit] = "-Dpolkit=true,-Dpolkit=false"
 PACKAGECONFIG[portabled] = "-Dportabled=true,-Dportabled=false"
-- 
2.7.4

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

[OE-core] [OE-Core][PATCH v2 1/2] libpsl: Extend with native, nativesdk

2019-03-25 Thread Alex Kiernan 
To allow wget with libpsl to build native/nativesdk versions we need
those variants here.
Signed-off-by: Alex Kiernan 
---

Changes in v2:
- new

 meta/recipes-support/libpsl/libpsl_0.20.2.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-support/libpsl/libpsl_0.20.2.bb 
b/meta/recipes-support/libpsl/libpsl_0.20.2.bb
index 89a87b67c744..5cb20d46bc48 100644
--- a/meta/recipes-support/libpsl/libpsl_0.20.2.bb
+++ b/meta/recipes-support/libpsl/libpsl_0.20.2.bb
@@ -16,3 +16,5 @@ inherit autotools gettext gtk-doc manpages pkgconfig 
lib_package
 
 PACKAGECONFIG ??= ""
 PACKAGECONFIG[manpages] = "--enable-man,--disable-man,libxslt-native"
+
+BBCLASSEXTEND = "native nativesdk"
-- 
2.7.4

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

[OE-core] [OE-Core][PATCH v2 2/2] wget: Convert EXTRA_OECONF to PACKAGECONFIG, extend PACKAGECONFIG

2019-03-25 Thread Alex Kiernan 
Convert existing EXTRA_OECONF and DEPENDS to PACKAGECONFIG, fill out
remaining PACKAGECONFIG options. When building without libpsl we pass in
--without-libpsl, which we didn't previously, but all this actually ends
up doing is silencing a warning from the configure script, the code
still uses an internal implemention when using this option.

Signed-off-by: Alex Kiernan 
---

Changes in v2:
- drop ac_cv_header_uuid_uuid_h hack

 meta/recipes-extended/wget/wget.inc | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/meta/recipes-extended/wget/wget.inc 
b/meta/recipes-extended/wget/wget.inc
index 3cff656a68d9..2f63e2138595 100644
--- a/meta/recipes-extended/wget/wget.inc
+++ b/meta/recipes-extended/wget/wget.inc
@@ -3,12 +3,11 @@ HOMEPAGE = "https://www.gnu.org/software/wget/";
 SECTION = "console/network"
 LICENSE = "GPLv3"
 LIC_FILES_CHKSUM = "file://COPYING;md5=c678957b0c8e964aa6c70fd77641a71e"
-DEPENDS = "gnutls zlib libpcre"
 
 inherit autotools gettext texinfo update-alternatives pkgconfig
 
-EXTRA_OECONF = "--with-ssl=gnutls --disable-rpath --disable-iri \
---without-libgnutls-prefix ac_cv_header_uuid_uuid_h=no"
+EXTRA_OECONF = "--without-libgnutls-prefix --without-libssl-prefix \
+--disable-rpath"
 
 EXTRA_OEMAKE += 'TOOLCHAIN_OPTIONS="${TOOLCHAIN_OPTIONS}" \
  DEBUG_PREFIX_MAP="${DEBUG_PREFIX_MAP}"'
@@ -21,9 +20,17 @@ RRECOMMENDS_${PN} += "ca-certificates"
 
 BBCLASSEXTEND = "nativesdk"
 
-PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'ipv6', d)}"
-PACKAGECONFIG[libuuid] = "--with-libuuid, --without-libuuid,util-linux"
+PACKAGECONFIG ??= "gnutls pcre zlib \
+   ${@bb.utils.filter('DISTRO_FEATURES', 'ipv6', d)}"
+PACKAGECONFIG[ares] = "--with-cares,,c-ares"
+PACKAGECONFIG[gnutls] = "--with-ssl=gnutls,,gnutls"
 PACKAGECONFIG[ipv6] = "--enable-ipv6,--disable-ipv6,"
+PACKAGECONFIG[iri] = ",--disable-iri,libidn2"
+PACKAGECONFIG[libpsl] = ",--without-libpsl,libpsl"
+PACKAGECONFIG[libuuid] = "--with-libuuid,--without-libuuid,util-linux"
+PACKAGECONFIG[openssl] = "--with-ssl=openssl,,openssl"
+PACKAGECONFIG[pcre] = ",--disable-pcre,libpcre"
+PACKAGECONFIG[zlib] = ",--without-zlib,zlib"
 
 # Let aclocal use the relative path for the m4 file rather than
 # absolute, otherwise there might be an "Argument list too long" error
-- 
2.7.4

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

[OE-core] [PATCH] dropbear: update to 2019.77

2019-03-25 Thread Andrej Valek 
 - update dropbear to version 2019.77
 - drop obsolete patch

Signed-off-by: Andrej Valek 
---
 meta/recipes-core/dropbear/dropbear.inc|   1 -
 .../dropbear/dropbear/CVE-2018-15599.patch | 236 -
 meta/recipes-core/dropbear/dropbear_2018.76.bb |   5 -
 meta/recipes-core/dropbear/dropbear_2019.77.bb |   4 +
 4 files changed, 4 insertions(+), 242 deletions(-)
 delete mode 100644 meta/recipes-core/dropbear/dropbear/CVE-2018-15599.patch
 delete mode 100644 meta/recipes-core/dropbear/dropbear_2018.76.bb
 create mode 100644 meta/recipes-core/dropbear/dropbear_2019.77.bb

diff --git a/meta/recipes-core/dropbear/dropbear.inc 
b/meta/recipes-core/dropbear/dropbear.inc
index d92a2f3991..3fbdb5e825 100644
--- a/meta/recipes-core/dropbear/dropbear.inc
+++ b/meta/recipes-core/dropbear/dropbear.inc
@@ -13,7 +13,6 @@ RPROVIDES_${PN} = "ssh sshd"
 DEPENDS += "${@bb.utils.contains('DISTRO_FEATURES', 'pam', 'libpam', '', d)}"
 
 SRC_URI = "http://matt.ucc.asn.au/dropbear/releases/dropbear-${PV}.tar.bz2 \
-   file://CVE-2018-15599.patch \
file://0001-urandom-xauth-changes-to-options.h.patch \
file://init \
file://dropbearkey.service \
diff --git a/meta/recipes-core/dropbear/dropbear/CVE-2018-15599.patch 
b/meta/recipes-core/dropbear/dropbear/CVE-2018-15599.patch
deleted file mode 100644
index 912545c957..00
--- a/meta/recipes-core/dropbear/dropbear/CVE-2018-15599.patch
+++ /dev/null
@@ -1,236 +0,0 @@
-From 256e2abb8150f9fea33cd026597dbe70f0379296 Mon Sep 17 00:00:00 2001
-From: Matt Johnston 
-Date: Thu, 23 Aug 2018 23:43:12 +0800
-Subject: [PATCH] Wait to fail invalid usernames
-
-Wait to fail invalid usernames
-
-Upstream-Status: Backport 
[https://secure.ucc.asn.au/hg/dropbear/rev/5d2d1021ca00]
-CVE: CVE-2018-15599
-Signed-off-by: Mingli Yu 

- auth.h   |  6 +++---
- svr-auth.c   | 19 +--
- svr-authpam.c| 26 ++
- svr-authpasswd.c | 27 ++-
- svr-authpubkey.c | 11 ++-
- 5 files changed, 54 insertions(+), 35 deletions(-)
-
-diff --git a/auth.h b/auth.h
-index da498f5..98f5468 100644
 a/auth.h
-+++ b/auth.h
-@@ -37,9 +37,9 @@ void recv_msg_userauth_request(void);
- void send_msg_userauth_failure(int partial, int incrfail);
- void send_msg_userauth_success(void);
- void send_msg_userauth_banner(const buffer *msg);
--void svr_auth_password(void);
--void svr_auth_pubkey(void);
--void svr_auth_pam(void);
-+void svr_auth_password(int valid_user);
-+void svr_auth_pubkey(int valid_user);
-+void svr_auth_pam(int valid_user);
- 
- #if DROPBEAR_SVR_PUBKEY_OPTIONS_BUILT
- int svr_pubkey_allows_agentfwd(void);
-diff --git a/svr-auth.c b/svr-auth.c
-index 64d97aa..1f364ca 100644
 a/svr-auth.c
-+++ b/svr-auth.c
-@@ -149,10 +149,8 @@ void recv_msg_userauth_request() {
-   if (methodlen == AUTH_METHOD_PASSWORD_LEN &&
-   strncmp(methodname, AUTH_METHOD_PASSWORD,
-   AUTH_METHOD_PASSWORD_LEN) == 0) {
--  if (valid_user) {
--  svr_auth_password();
--  goto out;
--  }
-+  svr_auth_password(valid_user);
-+  goto out;
-   }
-   }
- #endif
-@@ -164,10 +162,8 @@ void recv_msg_userauth_request() {
-   if (methodlen == AUTH_METHOD_PASSWORD_LEN &&
-   strncmp(methodname, AUTH_METHOD_PASSWORD,
-   AUTH_METHOD_PASSWORD_LEN) == 0) {
--  if (valid_user) {
--  svr_auth_pam();
--  goto out;
--  }
-+  svr_auth_pam(valid_user);
-+  goto out;
-   }
-   }
- #endif
-@@ -177,12 +173,7 @@ void recv_msg_userauth_request() {
-   if (methodlen == AUTH_METHOD_PUBKEY_LEN &&
-   strncmp(methodname, AUTH_METHOD_PUBKEY,
-   AUTH_METHOD_PUBKEY_LEN) == 0) {
--  if (valid_user) {
--  svr_auth_pubkey();
--  } else {
--  /* pubkey has no failure delay */
--  send_msg_userauth_failure(0, 0);
--  }
-+  svr_auth_pubkey(valid_user);
-   goto out;
-   }
- #endif
-diff --git a/svr-authpam.c b/svr-authpam.c
-index 05e4f3e..d201bc9 100644
 a/svr-authpam.c
-+++ b/svr-authpam.c
-@@ -178,13 +178,14 @@ pamConvFunc(int num_msg,
-  * Keyboard interactive would be a lot nicer, but since PAM is synchronous, it
-  * gets very messy trying to send the interactive challenges, and read the
-  * interactive responses, over the network. */
--void svr_auth_pam() {
-+void svr_auth_pam(int valid_user) {
- 
-   struct UserDataS userData = {NULL, NULL};
-   struct pam_conv pam

Re: [OE-core] Unknown host error while building abiword

2019-03-25 Thread Richard Purdie 
On Mon, 2019-03-25 at 11:37 +0530, Hardik Padhariya wrote:
> We are using Yocto krogoth 2.1.1 for imx6ul evaluation kit
> "mx6ul_14x14_evk".

krogoth is quite elderly now and hadn't had security updates for a
while.
 
> While building the abiword tool using “bitbake abiword” command we
> are facing the following issue.
>  
> “
> ERROR: Fetcher failure: Fetch command failed with exit code 128,
> output:
> fatal: unable to connect to git.gnome.org:
> git.gnome.org[0: 209.132.180.168]: errno=No route to host
> git.gnome.org[1: 209.132.180.180]: errno=No route to host
>  

gnome migrated their git services to git lab so the urls changed. You
should ideally update to a newer release of yocto. Failing that,
configure a source mirror which has the needed sources from several
years ago.

Cheers,

Richard

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

Re: [OE-core] [OE-Core][PATCH v2 2/2] wget: Convert EXTRA_OECONF to PACKAGECONFIG, extend PACKAGECONFIG

2019-03-25 Thread Burton, Ross 
On Mon, 25 Mar 2019 at 09:38, Alex Kiernan  wrote:
> +PACKAGECONFIG[ares] = "--with-cares,,c-ares"
> +PACKAGECONFIG[gnutls] = "--with-ssl=gnutls,,gnutls"
>  PACKAGECONFIG[ipv6] = "--enable-ipv6,--disable-ipv6,"
> +PACKAGECONFIG[iri] = ",--disable-iri,libidn2"
> +PACKAGECONFIG[libpsl] = ",--without-libpsl,libpsl"
> +PACKAGECONFIG[libuuid] = "--with-libuuid,--without-libuuid,util-linux"
> +PACKAGECONFIG[openssl] = "--with-ssl=openssl,,openssl"
> +PACKAGECONFIG[pcre] = ",--disable-pcre,libpcre"
> +PACKAGECONFIG[zlib] = ",--without-zlib,zlib"

Defaults can and do change, so please be explicit here: always pass
---with-foo and --without-foo.

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

Re: [OE-core] [PATCH 2/8] mdadm: add udev rules to create by-partuuid for MD devices

2019-03-25 Thread Richard Purdie 
On Wed, 2019-03-20 at 23:19 -0400, Liwei Song wrote:
> installer use partuuid for boot and swap partition,
> But the udev rules for MD devices do not have rules to create
> by-partuuid under /dev/disk/, this will take 90s to wait until failed
> add the rules to create by-partuuid to support boot from raid
> disk with "root=PARTUUID=XXX"
> 
> Signed-off-by: Liwei Song 
> ---
>  ...ev.rules-create-by-partuuid-for-md-device.patch | 29
> ++
>  meta/recipes-extended/mdadm/mdadm_4.1.bb   |  1 +
>  2 files changed, 30 insertions(+)
>  create mode 100644 meta/recipes-extended/mdadm/files/0001-
> udev.rules-create-by-partuuid-for-md-device.patch
> 
> diff --git a/meta/recipes-extended/mdadm/files/0001-udev.rules-
> create-by-partuuid-for-md-device.patch b/meta/recipes-
> extended/mdadm/files/0001-udev.rules-create-by-partuuid-for-md-
> device.patch
> new file mode 100644
> index ..c1f7b1cf8736
> --- /dev/null
> +++ b/meta/recipes-extended/mdadm/files/0001-udev.rules-create-by-
> partuuid-for-md-device.patch
> @@ -0,0 +1,29 @@
> +From 7d1fa6afba936edb3e211f0ccdb58b1472b4bbf4 Mon Sep 17 00:00:00
> 2001
> +From: Liwei Song 
> +Date: Tue, 26 Feb 2019 07:05:42 +
> +Subject: [PATCH] udev.rules: create by-partuuid for md device
> +
> +Create by-partuuid for every md devices.
> +
> +Upstream-Status: sent to linux-r...@vger.kernel.org(
> https://www.spinics.net/lists/raid/msg62373.html)
> +
> +Signed-off-by: Liwei Song 
> +---
> + udev-md-raid-arrays.rules | 1 +
> + 1 file changed, 1 insertion(+)

It looks like upstream had concerns about this so I'd like to hold off
on this until those are resolved.

https://www.spinics.net/lists/raid/msg62376.html

Cheers,

Richard

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

[OE-core] [PATCH] oeqa/qemurunner: Dont mix binary and non-binary strings

2019-03-25 Thread Richard Purdie 
self.msg is a str(), bootlog is b'' so this code clearly doesn't work. Add
in a decode since its being used as a string.

Signed-off-by: Richard Purdie 
---
 meta/lib/oeqa/utils/qemurunner.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/lib/oeqa/utils/qemurunner.py 
b/meta/lib/oeqa/utils/qemurunner.py
index 7ef506b60a2..49020c1e636 100644
--- a/meta/lib/oeqa/utils/qemurunner.py
+++ b/meta/lib/oeqa/utils/qemurunner.py
@@ -329,6 +329,7 @@ class QemuRunner:
 self.logger.debug("Target didn't reach login banner in %d 
seconds (%s)" %
   (self.boottime, time.strftime("%D 
%H:%M:%S")))
 tail = lambda l: "\n".join(l.splitlines()[-25:])
+bootlog = boolog.decode("utf-8")
 # in case bootlog is empty, use tail qemu log store at self.msg
 lines = tail(bootlog if bootlog else self.msg)
 self.logger.debug("Last 25 lines of text:\n%s" % lines)
-- 
2.20.1

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

[OE-core] [OE-Core][PATCH v3 2/2] wget: Convert EXTRA_OECONF to PACKAGECONFIG, extend PACKAGECONFIG

2019-03-25 Thread Alex Kiernan 
Convert existing EXTRA_OECONF and DEPENDS to PACKAGECONFIG, fill out
remaining PACKAGECONFIG options. When building without libpsl we pass in
--without-libpsl, which we didn't previously, but all this actually ends
up doing is silencing a warning from the configure script, the code
still uses an internal implemention when using this option.

Signed-off-by: Alex Kiernan 
---

Changes in v3:
- add explicit with/without/enable/disable for all PACKAGECONFIGs

Changes in v2:
- drop ac_cv_header_uuid_uuid_h hack

 meta/recipes-extended/wget/wget.inc | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/meta/recipes-extended/wget/wget.inc 
b/meta/recipes-extended/wget/wget.inc
index 3cff656a68d9..07e8d8e8718f 100644
--- a/meta/recipes-extended/wget/wget.inc
+++ b/meta/recipes-extended/wget/wget.inc
@@ -3,12 +3,11 @@ HOMEPAGE = "https://www.gnu.org/software/wget/";
 SECTION = "console/network"
 LICENSE = "GPLv3"
 LIC_FILES_CHKSUM = "file://COPYING;md5=c678957b0c8e964aa6c70fd77641a71e"
-DEPENDS = "gnutls zlib libpcre"
 
 inherit autotools gettext texinfo update-alternatives pkgconfig
 
-EXTRA_OECONF = "--with-ssl=gnutls --disable-rpath --disable-iri \
---without-libgnutls-prefix ac_cv_header_uuid_uuid_h=no"
+EXTRA_OECONF = "--without-libgnutls-prefix --without-libssl-prefix \
+--disable-rpath"
 
 EXTRA_OEMAKE += 'TOOLCHAIN_OPTIONS="${TOOLCHAIN_OPTIONS}" \
  DEBUG_PREFIX_MAP="${DEBUG_PREFIX_MAP}"'
@@ -21,9 +20,17 @@ RRECOMMENDS_${PN} += "ca-certificates"
 
 BBCLASSEXTEND = "nativesdk"
 
-PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'ipv6', d)}"
-PACKAGECONFIG[libuuid] = "--with-libuuid, --without-libuuid,util-linux"
+PACKAGECONFIG ??= "gnutls pcre zlib \
+   ${@bb.utils.filter('DISTRO_FEATURES', 'ipv6', d)}"
+PACKAGECONFIG[ares] = "--with-cares,--without-cares,c-ares"
+PACKAGECONFIG[gnutls] = "--with-ssl=gnutls,,gnutls"
 PACKAGECONFIG[ipv6] = "--enable-ipv6,--disable-ipv6,"
+PACKAGECONFIG[iri] = "--enable-iri,--disable-iri,libidn2"
+PACKAGECONFIG[libpsl] = "--with-libpsl,--without-libpsl,libpsl"
+PACKAGECONFIG[libuuid] = "--with-libuuid,--without-libuuid,util-linux"
+PACKAGECONFIG[openssl] = "--with-ssl=openssl,,openssl"
+PACKAGECONFIG[pcre] = "--enable-pcre,--disable-pcre,libpcre"
+PACKAGECONFIG[zlib] = "--with-zlib,--without-zlib,zlib"
 
 # Let aclocal use the relative path for the m4 file rather than
 # absolute, otherwise there might be an "Argument list too long" error
-- 
2.7.4

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

[OE-core] [OE-Core][PATCH v3 1/2] libpsl: Extend with native, nativesdk

2019-03-25 Thread Alex Kiernan 
To allow wget with libpsl to build native/nativesdk versions we need
those variants here.
Signed-off-by: Alex Kiernan 
---

Changes in v3: None
Changes in v2:
- new

 meta/recipes-support/libpsl/libpsl_0.20.2.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-support/libpsl/libpsl_0.20.2.bb 
b/meta/recipes-support/libpsl/libpsl_0.20.2.bb
index 89a87b67c744..5cb20d46bc48 100644
--- a/meta/recipes-support/libpsl/libpsl_0.20.2.bb
+++ b/meta/recipes-support/libpsl/libpsl_0.20.2.bb
@@ -16,3 +16,5 @@ inherit autotools gettext gtk-doc manpages pkgconfig 
lib_package
 
 PACKAGECONFIG ??= ""
 PACKAGECONFIG[manpages] = "--enable-man,--disable-man,libxslt-native"
+
+BBCLASSEXTEND = "native nativesdk"
-- 
2.7.4

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

Re: [OE-core] musl thoughts

2019-03-25 Thread Andrea Adami 
On Sat, Mar 23, 2019 at 11:00 PM Andreas Müller  wrote:
>
> On Sat, Mar 23, 2019 at 10:53 PM Adrian Bunk  wrote:
> >
> > On Sat, Mar 23, 2019 at 10:22:15PM +0100, Andreas Müller wrote:
> > > On Sat, Mar 23, 2019 at 10:16 PM Adrian Bunk  wrote:
> > > >
> > > > On Fri, Mar 22, 2019 at 03:18:01PM -0700, Khem Raj wrote:
> > > > >...
> > > > > There are certain design aspects of musl which are actually turning
> > > > > out to be good
> > > > > e.g. there is no __MUSL__ define, so non-portable code can not be
> > > > > hidden which is a good thing,
> > > > >...
> > > >
> > > > Please take a closer look at some of the musl changes to NM that made
> > > > upgrading NM so hard for Andreas.
> > > >
> > > > +#if defined(__GLIBC__)
> > > >  #include 
> > > > +#else /* musl libc */
> > > > +#define ETH_ALEN   6   /* Octets in one ethernet addr  
> > > >  */
> > > > +#endif
> > > >
> > > > Using __GLIBC__ in workarounds for bugs in musl is wrong,
> > > > and cannot be upstreamed since it would do the wrong thing
> > > > on other non-broken C libraries.
> > > >
> > > > > While the eyes may hurt
> > > > > to see them, it does serve a
> > > > > good reminder of whats needed for a given package.
> > > > >...
> > > >
> > > > Who is responsible for fixing the root causes of such bugs in musl,
> > > > so that the workaround patches can be dropped from packages like NM?
> > > >
> > > > cu
> > > > Adrian
> > > If I am not mistaken nobody is responsible. It is recipe wise: Sending
> > > out a patch that fails for musl is rejected usually.
> >
> > As you have experienced, it does create a huge technical debt to ship
> > workaround patches in several recipes instead of fixing the bug in musl.
> >
> > > The last example could be fixed easily at musl shipping a ethernet.h 
> > > containing
> > > #define ETH_ALEN   6
> > >...
> >
> > That's already shipped by musl.
> >
> > But there seems to be some incompatibility between musl and the
> > kernel headers used by musl.
> >
> > This has to be sorted out in musl and/or the kernel headers.
> >
> Although I did not want to I'll start a musl build to create a cleanup
> for NM (and maybe) other musl patches.
>
> Andreas
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Hi,

I am jumping in a little late to take side with Khem :)

What happens now is that more 'bad' sources (written to suit glibc and
thus not portable) are discovered by the wider base of developers and
autobuilders.

I myself did struggle in the years to maintain a few packages deeply
bound to the kernel (mtd-utils, kexec tools) 'compatible' with klibc
so I know the pain.
As Khem said, this just needs time and efforts to clean up and
upstream the patches.

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

Re: [OE-core] musl thoughts

2019-03-25 Thread Mark Hatle 
On 3/21/19 8:11 PM, Andreas Müller wrote:
> Just prepared meta-networking/networkmanager update and spent hours to
> get musl patches applied. Have no idea if musl will build and
> currently all my machines are building.
> 
> For me - not using musl and looking forward to have a beer with Khem
> explaining me why I should want musl [1] - it is just useless effort
> and patches are rejected often due to failures on musl build.
> 
> So on my way home I though about the options I see to handle musl specifics:
> 
> 1. Continue as we do - patch recipe-wise: This is lots of efforts and
> requires resources we don't have. Most patches are created by Khem and
> it would be better for all of us to save his time for other tasks.
> 2. Sending musl related patches upstream: Surely the cleanest approach
> but even more effort because upstream maintainers all have different
> thoughts. Some of them might hear of musl for the first time and are
> possibly not keen on patches they do not see a need for.
> 3. Change our musl slightly: Many patches we currently have are
> trivial. Missing headers or #defines for missing functions... So if we
> add few headers
>   * Empty chunks for e.g 
>   * Add defines as #define strndupa(x,s) strncpy(alloca(strlen(x)+1),x,s)
>   * ...
> 
> As you might guess I'd prefer 3 because:
> + Many patches can go and don't need maintenance on upstream refactoring 
> anymore
> + Burden for people sending patches would be reduced
> + Recipes not building with musl currently might work without further
> modification
> + Just in case musl stops (we have seen this before with others e.g
> ulibc) the cleanup would be reduced
> 
> Of course there are disadvantages:
> - We turn musl into glibc direction. Posix-purists do not like that.
> - Configuration scripts already aware of musl and deciding upon the
> existence of headers missing in musl might do the wrong thing
> - ?
> 
> Some other ideas?

I'm late jumping into this.. but for things that may not build due to inherent
expectations from glibc...  you could just block the package if "not-glibc" is
enabled.

You could do this something like:

BLACKLISTMSG = "This package only works with glibc."
BLACKLISTMSG_libc-glibc = ""

PNBLACKLIST[${PN}] = "${BLACKLISTMSG}"

(I'm sure there is a cleaner way -- but the point is, if the package says sorry
-- I don't work with musl -- that is much more preferable to bitbake parses,
unpacks, patches, starts to build and explodes with no explanation...)

--Mark

> Andreas
> 
> [1] 
> http://lists.openembedded.org/pipermail/openembedded-devel/2018-March/193521.html
> 

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

Re: [OE-core] musl thoughts

2019-03-25 Thread Adrian Bunk 
On Mon, Mar 25, 2019 at 04:36:44PM +0100, Andrea Adami wrote:
> On Sat, Mar 23, 2019 at 11:00 PM Andreas Müller  
> wrote:
> >
> > On Sat, Mar 23, 2019 at 10:53 PM Adrian Bunk  wrote:
> > >
> > > On Sat, Mar 23, 2019 at 10:22:15PM +0100, Andreas Müller wrote:
> > > > On Sat, Mar 23, 2019 at 10:16 PM Adrian Bunk  wrote:
> > > > >
> > > > > On Fri, Mar 22, 2019 at 03:18:01PM -0700, Khem Raj wrote:
> > > > > >...
> > > > > > There are certain design aspects of musl which are actually turning
> > > > > > out to be good
> > > > > > e.g. there is no __MUSL__ define, so non-portable code can not be
> > > > > > hidden which is a good thing,
> > > > > >...
> > > > >
> > > > > Please take a closer look at some of the musl changes to NM that made
> > > > > upgrading NM so hard for Andreas.
> > > > >
> > > > > +#if defined(__GLIBC__)
> > > > >  #include 
> > > > > +#else /* musl libc */
> > > > > +#define ETH_ALEN   6   /* Octets in one ethernet 
> > > > > addr   */
> > > > > +#endif
>...
> 
> Hi,

Hi Andrea,

> I am jumping in a little late to take side with Khem :)
> 
> What happens now is that more 'bad' sources (written to suit glibc and
> thus not portable) are discovered by the wider base of developers and
> autobuilders.
>...

but this does not apply to this example, which is a problem between
musl itself and the kernel headers.

Code can expect #include  to work for any headers, and with any 
order of these headers. If it does not, the 'bad' sources are whatever
sources provide the headers in question.

musl does provide net/ethernet.h, but including it causes a compile
error here.

> As Khem said, this just needs time and efforts to clean up and
> upstream the patches.

Any sane upstream will refuse such patches that add musl-specific hacks
with the wrong define to work around problems in musl itself.

> Cheers
> Andrea

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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

Re: [OE-core] musl thoughts

2019-03-25 Thread Andreas Müller 
On Mon, Mar 25, 2019 at 5:10 PM Adrian Bunk  wrote:
>
> On Mon, Mar 25, 2019 at 04:36:44PM +0100, Andrea Adami wrote:
> > On Sat, Mar 23, 2019 at 11:00 PM Andreas Müller  
> > wrote:
> > >
> > > On Sat, Mar 23, 2019 at 10:53 PM Adrian Bunk  wrote:
> > > >
> > > > On Sat, Mar 23, 2019 at 10:22:15PM +0100, Andreas Müller wrote:
> > > > > On Sat, Mar 23, 2019 at 10:16 PM Adrian Bunk  wrote:
> > > > > >
> > > > > > On Fri, Mar 22, 2019 at 03:18:01PM -0700, Khem Raj wrote:
> > > > > > >...
> > > > > > > There are certain design aspects of musl which are actually 
> > > > > > > turning
> > > > > > > out to be good
> > > > > > > e.g. there is no __MUSL__ define, so non-portable code can not be
> > > > > > > hidden which is a good thing,
> > > > > > >...
> > > > > >
> > > > > > Please take a closer look at some of the musl changes to NM that 
> > > > > > made
> > > > > > upgrading NM so hard for Andreas.
> > > > > >
> > > > > > +#if defined(__GLIBC__)
> > > > > >  #include 
> > > > > > +#else /* musl libc */
> > > > > > +#define ETH_ALEN   6   /* Octets in one ethernet 
> > > > > > addr   */
> > > > > > +#endif
> >...
> >
> > Hi,
>
> Hi Andrea,
>
> > I am jumping in a little late to take side with Khem :)
> >
> > What happens now is that more 'bad' sources (written to suit glibc and
> > thus not portable) are discovered by the wider base of developers and
> > autobuilders.
> >...
>
> but this does not apply to this example, which is a problem between
> musl itself and the kernel headers.
>
> Code can expect #include  to work for any headers, and with any
> order of these headers. If it does not, the 'bad' sources are whatever
> sources provide the headers in question.
>
> musl does provide net/ethernet.h, but including it causes a compile
> error here.
Out of curiosity: you have some log?

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

Re: [OE-core] musl thoughts

2019-03-25 Thread Andrea Adami 
On Mon, Mar 25, 2019 at 5:10 PM Adrian Bunk  wrote:
>
> On Mon, Mar 25, 2019 at 04:36:44PM +0100, Andrea Adami wrote:
> > On Sat, Mar 23, 2019 at 11:00 PM Andreas Müller  
> > wrote:
> > >
> > > On Sat, Mar 23, 2019 at 10:53 PM Adrian Bunk  wrote:
> > > >
> > > > On Sat, Mar 23, 2019 at 10:22:15PM +0100, Andreas Müller wrote:
> > > > > On Sat, Mar 23, 2019 at 10:16 PM Adrian Bunk  wrote:
> > > > > >
> > > > > > On Fri, Mar 22, 2019 at 03:18:01PM -0700, Khem Raj wrote:
> > > > > > >...
> > > > > > > There are certain design aspects of musl which are actually 
> > > > > > > turning
> > > > > > > out to be good
> > > > > > > e.g. there is no __MUSL__ define, so non-portable code can not be
> > > > > > > hidden which is a good thing,
> > > > > > >...
> > > > > >
> > > > > > Please take a closer look at some of the musl changes to NM that 
> > > > > > made
> > > > > > upgrading NM so hard for Andreas.
> > > > > >
> > > > > > +#if defined(__GLIBC__)
> > > > > >  #include 
> > > > > > +#else /* musl libc */
> > > > > > +#define ETH_ALEN   6   /* Octets in one ethernet 
> > > > > > addr   */
> > > > > > +#endif
> >...
> >
> > Hi,
>
> Hi Andrea,
>
> > I am jumping in a little late to take side with Khem :)
> >
> > What happens now is that more 'bad' sources (written to suit glibc and
> > thus not portable) are discovered by the wider base of developers and
> > autobuilders.
> >...
>
> but this does not apply to this example, which is a problem between
> musl itself and the kernel headers.
>
> Code can expect #include  to work for any headers, and with any
> order of these headers. If it does not, the 'bad' sources are whatever
> sources provide the headers in question.
>
> musl does provide net/ethernet.h, but including it causes a compile
> error here.

Adrian,

I don't know in this specific case, you do surely know better about
kernel/headers than me :)
Strangely I remember one issue with net/if.h and netinet/in.h with
kexec-tools and musl: maybe there is really something too special with
those net headers.

Switching the order of the headers did solve back then
https://git.openembedded.org/meta-openembedded/commit/meta-initramfs/recipes-kernel/kexec?id=b97358d5a3568deb2a5e939019bb2acef053e53f

Sorry for the OT


Cheers
Andrea



>
> > As Khem said, this just needs time and efforts to clean up and
> > upstream the patches.
>
> Any sane upstream will refuse such patches that add musl-specific hacks
> with the wrong define to work around problems in musl itself.
>
> > Cheers
> > Andrea
>
> cu
> Adrian
>
> --
>
>"Is there not promise of rain?" Ling Tan asked suddenly out
> of the darkness. There had been need of rain for many days.
>"Only a promise," Lao Er said.
>Pearl S. Buck - Dragon Seed
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] Yocto Project Unassigned Bugs - Help Needed

2019-03-25 Thread sjolley.yp.pm 
All,

 

The triage team meets weekly and does its best to handle the bugs reported
into the Bugzilla. The number of people attending that meeting has fallen,
as have the number of people available to help fix bugs. One of the things
we hear users report is they don't know how to help. We (the triage team)
are therefore going to start reporting out the currently 296 unassigned
bugs.

 

We're hoping people may be able to spare some time now and again to help out
with these.

 

Bugs are split into two types, "true bugs" where things don't work as they
should and "enhancements" which are features we'd want to add to the system.

 

There are also roughly four different "priority" classes right now, "2.7",
"2.8", "2.9', "2.99" and "Future", the more pressing/urgent issues being in
"2.7" and then "2.8".

 

Please review this link and if a bug is something you would be able to help
with either take ownership of the bug, or send me
(stephen.k.jol...@intel.com  ) an e-mail
with the bug number you would like and I will assign it to you (please make
sure you have a Bugzilla account).

 

The list is at:
https://wiki.yoctoproject.org/wiki/Bug_Triage#Unassigned_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 

 

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

Re: [OE-core] musl thoughts

2019-03-25 Thread Adrian Bunk 
On Mon, Mar 25, 2019 at 05:31:47PM +0100, Andrea Adami wrote:
> On Mon, Mar 25, 2019 at 5:10 PM Adrian Bunk  wrote:
> >
> > On Mon, Mar 25, 2019 at 04:36:44PM +0100, Andrea Adami wrote:
> > > On Sat, Mar 23, 2019 at 11:00 PM Andreas Müller  
> > > wrote:
> > > >
> > > > On Sat, Mar 23, 2019 at 10:53 PM Adrian Bunk  wrote:
> > > > >
> > > > > On Sat, Mar 23, 2019 at 10:22:15PM +0100, Andreas Müller wrote:
> > > > > > On Sat, Mar 23, 2019 at 10:16 PM Adrian Bunk  wrote:
> > > > > > >
> > > > > > > On Fri, Mar 22, 2019 at 03:18:01PM -0700, Khem Raj wrote:
> > > > > > > >...
> > > > > > > > There are certain design aspects of musl which are actually 
> > > > > > > > turning
> > > > > > > > out to be good
> > > > > > > > e.g. there is no __MUSL__ define, so non-portable code can not 
> > > > > > > > be
> > > > > > > > hidden which is a good thing,
> > > > > > > >...
> > > > > > >
> > > > > > > Please take a closer look at some of the musl changes to NM that 
> > > > > > > made
> > > > > > > upgrading NM so hard for Andreas.
> > > > > > >
> > > > > > > +#if defined(__GLIBC__)
> > > > > > >  #include 
> > > > > > > +#else /* musl libc */
> > > > > > > +#define ETH_ALEN   6   /* Octets in one ethernet 
> > > > > > > addr   */
> > > > > > > +#endif
> > >...
> > >
> > > Hi,
> >
> > Hi Andrea,
> >
> > > I am jumping in a little late to take side with Khem :)
> > >
> > > What happens now is that more 'bad' sources (written to suit glibc and
> > > thus not portable) are discovered by the wider base of developers and
> > > autobuilders.
> > >...
> >
> > but this does not apply to this example, which is a problem between
> > musl itself and the kernel headers.
> >
> > Code can expect #include  to work for any headers, and with any
> > order of these headers. If it does not, the 'bad' sources are whatever
> > sources provide the headers in question.
> >
> > musl does provide net/ethernet.h, but including it causes a compile
> > error here.
> 
> Adrian,
> 
> I don't know in this specific case, you do surely know better about
> kernel/headers than me :)
> Strangely I remember one issue with net/if.h and netinet/in.h with
> kexec-tools and musl: maybe there is really something too special with
> those net headers.
> 
> Switching the order of the headers did solve back then
> https://git.openembedded.org/meta-openembedded/commit/meta-initramfs/recipes-kernel/kexec?id=b97358d5a3568deb2a5e939019bb2acef053e53f

This changed the order between two headers that are both provided by musl.

> Sorry for the OT

This is not OT, this is a good example for a patch that is a workaround
for some problem in musl (and not a generic portability fix).

> Cheers
> Andrea

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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

Re: [OE-core] musl thoughts

2019-03-25 Thread Andreas Müller 
On Mon, Mar 25, 2019 at 5:26 PM Andreas Müller  wrote:
>
> On Mon, Mar 25, 2019 at 5:10 PM Adrian Bunk  wrote:
> >
> > On Mon, Mar 25, 2019 at 04:36:44PM +0100, Andrea Adami wrote:
> > > On Sat, Mar 23, 2019 at 11:00 PM Andreas Müller  
> > > wrote:
> > > >
> > > > On Sat, Mar 23, 2019 at 10:53 PM Adrian Bunk  wrote:
> > > > >
> > > > > On Sat, Mar 23, 2019 at 10:22:15PM +0100, Andreas Müller wrote:
> > > > > > On Sat, Mar 23, 2019 at 10:16 PM Adrian Bunk  wrote:
> > > > > > >
> > > > > > > On Fri, Mar 22, 2019 at 03:18:01PM -0700, Khem Raj wrote:
> > > > > > > >...
> > > > > > > > There are certain design aspects of musl which are actually 
> > > > > > > > turning
> > > > > > > > out to be good
> > > > > > > > e.g. there is no __MUSL__ define, so non-portable code can not 
> > > > > > > > be
> > > > > > > > hidden which is a good thing,
> > > > > > > >...
> > > > > > >
> > > > > > > Please take a closer look at some of the musl changes to NM that 
> > > > > > > made
> > > > > > > upgrading NM so hard for Andreas.
> > > > > > >
> > > > > > > +#if defined(__GLIBC__)
> > > > > > >  #include 
> > > > > > > +#else /* musl libc */
> > > > > > > +#define ETH_ALEN   6   /* Octets in one ethernet 
> > > > > > > addr   */
> > > > > > > +#endif
> > >...
> > >
> > > Hi,
> >
> > Hi Andrea,
> >
> > > I am jumping in a little late to take side with Khem :)
> > >
> > > What happens now is that more 'bad' sources (written to suit glibc and
> > > thus not portable) are discovered by the wider base of developers and
> > > autobuilders.
> > >...
> >
> > but this does not apply to this example, which is a problem between
> > musl itself and the kernel headers.
> >
> > Code can expect #include  to work for any headers, and with any
> > order of these headers. If it does not, the 'bad' sources are whatever
> > sources provide the headers in question.
> >
> > musl does provide net/ethernet.h, but including it causes a compile
> > error here.
> Out of curiosity: you have some log?
>
Looked into this. Found an old musl build failure of networkmanager
[1] but I think the issue has not changed:

| In file included from
TOPDIR/build/tmp/work/mips32r2-yoe-linux-musl/networkmanager/1.14.4-r0/recipe-sysroot/usr/include/net/ethernet.h:10,
|  from ../NetworkManager-1.14.4/shared/n-acd/src/n-acd.c:28:
| 
TOPDIR/build/tmp/work/mips32r2-yoe-linux-musl/networkmanager/1.14.4-r0/recipe-sysroot/usr/include/netinet/if_ether.h:111:8:
error: redefinition of 'struct ethhdr'
|  struct ethhdr {
| ^~
| In file included from ../NetworkManager-1.14.4/shared/n-acd/src/n-acd.c:26:
| 
TOPDIR/build/tmp/work/mips32r2-yoe-linux-musl/networkmanager/1.14.4-r0/recipe-sysroot/usr/include/linux/if_ether.h:167:8:
note: originally defined here
| struct ethhdr {
| ^~

glibc does not fail because it does include linux header
| /* Get definitions from kernel header file.  */
| #include 
and does not define struct ethhdr

linux/if_ether.h says:
/* allow libcs like musl to deactivate this, glibc does not implement this. */
#ifndef __UAPI_DEF_ETHHDR
#define __UAPI_DEF_ETHHDR1
#endif

#if __UAPI_DEF_ETHHDR
struct ethhdr {
unsigned charh_dest[ETH_ALEN];/* destination eth addr*/
unsigned charh_source[ETH_ALEN];/* source ether addr*/
__be16h_proto;/* packet type ID field*/
} __attribute__((packed));
#endif

musl does not include linux header but defines which is differen from
what linux does:
struct ethhdr {
uint8_t h_dest[ETH_ALEN];
uint8_t h_source[ETH_ALEN];
uint16_t h_proto;
};
and later
#define __UAPI_DEF_ETHHDR   0

So for networkmanager there is either some wrong sequence or it
includes linux headers.

And I am still not confident that it is our job to teach umpteen
projects written for linux how to write portable code (oe-core has 147
musl related patches and meta-openembedded has 140)...

[1] http://errors.yoctoproject.org/Errors/Details/198239/

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

Re: [OE-core] musl thoughts

2019-03-25 Thread Andreas Müller 
On Mon, Mar 25, 2019 at 6:15 PM Andreas Müller  wrote:
>
> On Mon, Mar 25, 2019 at 5:26 PM Andreas Müller  
> wrote:
> >
> > On Mon, Mar 25, 2019 at 5:10 PM Adrian Bunk  wrote:
> > >
> > > On Mon, Mar 25, 2019 at 04:36:44PM +0100, Andrea Adami wrote:
> > > > On Sat, Mar 23, 2019 at 11:00 PM Andreas Müller 
> > > >  wrote:
> > > > >
> > > > > On Sat, Mar 23, 2019 at 10:53 PM Adrian Bunk  wrote:
> > > > > >
> > > > > > On Sat, Mar 23, 2019 at 10:22:15PM +0100, Andreas Müller wrote:
> > > > > > > On Sat, Mar 23, 2019 at 10:16 PM Adrian Bunk  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Fri, Mar 22, 2019 at 03:18:01PM -0700, Khem Raj wrote:
> > > > > > > > >...
> > > > > > > > > There are certain design aspects of musl which are actually 
> > > > > > > > > turning
> > > > > > > > > out to be good
> > > > > > > > > e.g. there is no __MUSL__ define, so non-portable code can 
> > > > > > > > > not be
> > > > > > > > > hidden which is a good thing,
> > > > > > > > >...
> > > > > > > >
> > > > > > > > Please take a closer look at some of the musl changes to NM 
> > > > > > > > that made
> > > > > > > > upgrading NM so hard for Andreas.
> > > > > > > >
> > > > > > > > +#if defined(__GLIBC__)
> > > > > > > >  #include 
> > > > > > > > +#else /* musl libc */
> > > > > > > > +#define ETH_ALEN   6   /* Octets in one 
> > > > > > > > ethernet addr   */
> > > > > > > > +#endif
> > > >...
> > > >
> > > > Hi,
> > >
> > > Hi Andrea,
> > >
> > > > I am jumping in a little late to take side with Khem :)
> > > >
> > > > What happens now is that more 'bad' sources (written to suit glibc and
> > > > thus not portable) are discovered by the wider base of developers and
> > > > autobuilders.
> > > >...
> > >
> > > but this does not apply to this example, which is a problem between
> > > musl itself and the kernel headers.
> > >
> > > Code can expect #include  to work for any headers, and with any
> > > order of these headers. If it does not, the 'bad' sources are whatever
> > > sources provide the headers in question.
> > >
> > > musl does provide net/ethernet.h, but including it causes a compile
> > > error here.
> > Out of curiosity: you have some log?
> >
> Looked into this. Found an old musl build failure of networkmanager
> [1] but I think the issue has not changed:
>
> | In file included from
> TOPDIR/build/tmp/work/mips32r2-yoe-linux-musl/networkmanager/1.14.4-r0/recipe-sysroot/usr/include/net/ethernet.h:10,
> |  from ../NetworkManager-1.14.4/shared/n-acd/src/n-acd.c:28:
> | 
> TOPDIR/build/tmp/work/mips32r2-yoe-linux-musl/networkmanager/1.14.4-r0/recipe-sysroot/usr/include/netinet/if_ether.h:111:8:
> error: redefinition of 'struct ethhdr'
> |  struct ethhdr {
> | ^~
> | In file included from ../NetworkManager-1.14.4/shared/n-acd/src/n-acd.c:26:
> | 
> TOPDIR/build/tmp/work/mips32r2-yoe-linux-musl/networkmanager/1.14.4-r0/recipe-sysroot/usr/include/linux/if_ether.h:167:8:
> note: originally defined here
> | struct ethhdr {
> | ^~
>
> glibc does not fail because it does include linux header
> | /* Get definitions from kernel header file.  */
> | #include 
> and does not define struct ethhdr
>
> linux/if_ether.h says:
> /* allow libcs like musl to deactivate this, glibc does not implement this. */
> #ifndef __UAPI_DEF_ETHHDR
> #define __UAPI_DEF_ETHHDR1
> #endif
>
> #if __UAPI_DEF_ETHHDR
> struct ethhdr {
> unsigned charh_dest[ETH_ALEN];/* destination eth addr*/
> unsigned charh_source[ETH_ALEN];/* source ether addr*/
> __be16h_proto;/* packet type ID field*/
> } __attribute__((packed));
> #endif
>
> musl does not include linux header but defines which is differen from
> what linux does:
> struct ethhdr {
> uint8_t h_dest[ETH_ALEN];
> uint8_t h_source[ETH_ALEN];
> uint16_t h_proto;
> };
> and later
> #define __UAPI_DEF_ETHHDR   0
>
> So for networkmanager there is either some wrong sequence or it
> includes linux headers.
>
> And I am still not confident that it is our job to teach umpteen
> projects written for linux how to write portable code (oe-core has 147
> musl related patches and meta-openembedded has 140)...
>
> [1] http://errors.yoctoproject.org/Errors/Details/198239/
>
Something to add - haven't yet looked into networkmanger:

Do we have the chance to change the sequence of paths headers are searched for

1. musl
2. linux

That might fix some issues

Andreas

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

Re: [OE-core] musl thoughts

2019-03-25 Thread Khem Raj 
On Sat, Mar 23, 2019 at 2:16 PM Adrian Bunk  wrote:
>
> On Fri, Mar 22, 2019 at 03:18:01PM -0700, Khem Raj wrote:
> >...
> > There are certain design aspects of musl which are actually turning
> > out to be good
> > e.g. there is no __MUSL__ define, so non-portable code can not be
> > hidden which is a good thing,
> >...
>
> Please take a closer look at some of the musl changes to NM that made
> upgrading NM so hard for Andreas.
>
> +#if defined(__GLIBC__)
>  #include 
> +#else /* musl libc */
> +#define ETH_ALEN   6   /* Octets in one ethernet addr   */
> +#endif
>
> Using __GLIBC__ in workarounds for bugs in musl is wrong,
> and cannot be upstreamed since it would do the wrong thing
> on other non-broken C libraries.

yes, not everything that fixed builds for musl are golden, and some
are workarounds
as above which obviously can't be upstreamed, my comments were from
overall perspective
not specific to network manager patches

>
> > While the eyes may hurt
> > to see them, it does serve a
> > good reminder of whats needed for a given package.
> >...
>
> Who is responsible for fixing the root causes of such bugs in musl,

your concluded its a bug in musl, probably based on the patch but its
one sided view
musl is calling out namespace collisions etc. see

https://www.openwall.com/lists/musl/2012/10/11/4

so obviously, we need to make sure that kernel headers are not written
with an assumption
that glibc is only options when it comes to C libraries, but there are
such assumptions as well unfortunately

> so that the workaround patches can be dropped from packages like NM?

I think the right approach is to fix the problem where it belongs, and
generally making changes to headers
is a long term approach but is right one until then live with
temporary solutions. there has been changes in
kernel headers which fixes such assumptions broken by musl e.g. see

https://patchwork.kernel.org/cover/10724549/

We have to take more portable approach and I think its better for everyone.
>
> cu
> Adrian
>
> --
>
>"Is there not promise of rain?" Ling Tan asked suddenly out
> of the darkness. There had been need of rain for many days.
>"Only a promise," Lao Er said.
>Pearl S. Buck - Dragon Seed
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] musl thoughts

2019-03-25 Thread Adrian Bunk 
On Mon, Mar 25, 2019 at 06:15:40PM +0100, Andreas Müller wrote:
>...
> Looked into this. Found an old musl build failure of networkmanager
> [1] but I think the issue has not changed:
> 
> | In file included from
> TOPDIR/build/tmp/work/mips32r2-yoe-linux-musl/networkmanager/1.14.4-r0/recipe-sysroot/usr/include/net/ethernet.h:10,
> |  from ../NetworkManager-1.14.4/shared/n-acd/src/n-acd.c:28:
> | 
> TOPDIR/build/tmp/work/mips32r2-yoe-linux-musl/networkmanager/1.14.4-r0/recipe-sysroot/usr/include/netinet/if_ether.h:111:8:
> error: redefinition of 'struct ethhdr'
> |  struct ethhdr {
> | ^~
> | In file included from ../NetworkManager-1.14.4/shared/n-acd/src/n-acd.c:26:
> | 
> TOPDIR/build/tmp/work/mips32r2-yoe-linux-musl/networkmanager/1.14.4-r0/recipe-sysroot/usr/include/linux/if_ether.h:167:8:
> note: originally defined here
> | struct ethhdr {
> | ^~
> 
> glibc does not fail because it does include linux header
> | /* Get definitions from kernel header file.  */
> | #include 
> and does not define struct ethhdr
> 
> linux/if_ether.h says:
> /* allow libcs like musl to deactivate this, glibc does not implement this. */
> #ifndef __UAPI_DEF_ETHHDR
> #define __UAPI_DEF_ETHHDR1
> #endif
> 
> #if __UAPI_DEF_ETHHDR
> struct ethhdr {
> unsigned charh_dest[ETH_ALEN];/* destination eth addr*/
> unsigned charh_source[ETH_ALEN];/* source ether addr*/
> __be16h_proto;/* packet type ID field*/
> } __attribute__((packed));
> #endif
> 
> musl does not include linux header but defines which is differen from
> what linux does:
> struct ethhdr {
> uint8_t h_dest[ETH_ALEN];
> uint8_t h_source[ETH_ALEN];
> uint16_t h_proto;
> };
> and later
> #define __UAPI_DEF_ETHHDR   0
> 
> So for networkmanager there is either some wrong sequence or it
> includes linux headers.

musl headers providing own different definitions of kernel interfaces
is a problem in musl.

After reading [1] I think that this is musl upstream having made the 
decision of not even trying to work properly with the kernel headers.

OE adding a not upstreamable patch that removes one of the two 
definitions in musl builds might be the best available solution.

> And I am still not confident that it is our job to teach umpteen
> projects written for linux how to write portable code (oe-core has 147
> musl related patches and meta-openembedded has 140)...
>...

This is not about writing portable code, this is about problems with musl.

Using the Linux userspace headers is obviously not portable to non-Linux,
but many packages like NetworkManager are anyways Linux-only no matter 
what you do.

> Andreas

cu
Adrian

[1] https://wiki.musl-libc.org/faq.html#Q:-Why-am-I-getting-

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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

Re: [OE-core] musl thoughts

2019-03-25 Thread Adrian Bunk 
On Mon, Mar 25, 2019 at 06:36:19PM +0100, Andreas Müller wrote:
>...
> Something to add - haven't yet looked into networkmanger:
> 
> Do we have the chance to change the sequence of paths headers are searched for
> 
> 1. musl
> 2. linux
> 
> That might fix some issues

It would not.

The headers are in different namespaces, order is defined solely
by the order of #include statements in source and header files.

> Andreas

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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

Re: [OE-core] musl thoughts

2019-03-25 Thread Adrian Bunk 
On Mon, Mar 25, 2019 at 10:44:28AM -0700, Khem Raj wrote:
> On Sat, Mar 23, 2019 at 2:16 PM Adrian Bunk  wrote:
>...
> > so that the workaround patches can be dropped from packages like NM?
> 
> I think the right approach is to fix the problem where it belongs, and
> generally making changes to headers
> is a long term approach but is right one until then live with
> temporary solutions.
>...

Many of the musl-specific header ordering restrictions could 
alternatively be resolved if there would be an #if defined(__MUSL__)
in the linux/libc-compat.h kernel header to reliably disable conflicting 
declarations in the kernel headers.

I wonder whether there is a better temporary solution by doing something
like that in OE instead of having workaround hacks in various packages
like NetworkManager.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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

Re: [OE-core] musl thoughts

2019-03-25 Thread Andreas Müller 
On Mon, Mar 25, 2019 at 7:03 PM Adrian Bunk  wrote:
>
> On Mon, Mar 25, 2019 at 06:36:19PM +0100, Andreas Müller wrote:
> >...
> > Something to add - haven't yet looked into networkmanger:
> >
> > Do we have the chance to change the sequence of paths headers are searched 
> > for
> >
> > 1. musl
> > 2. linux
> >
> > That might fix some issues
>
> It would not.
>
> The headers are in different namespaces, order is defined solely
> by the order of #include statements in source and header files.

Yes I should have skipped that:

* I missed my bus for writing it
* it does not make sense

Andreas
>
> > Andreas
>
> cu
> Adrian
>
> --
>
>"Is there not promise of rain?" Ling Tan asked suddenly out
> of the darkness. There had been need of rain for many days.
>"Only a promise," Lao Er said.
>Pearl S. Buck - Dragon Seed
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] musl thoughts

2019-03-25 Thread Andreas Müller 
On Mon, Mar 25, 2019 at 6:46 PM Adrian Bunk  wrote:
>
> On Mon, Mar 25, 2019 at 06:15:40PM +0100, Andreas Müller wrote:
> >...
> > Looked into this. Found an old musl build failure of networkmanager
> > [1] but I think the issue has not changed:
> >
> > | In file included from
> > TOPDIR/build/tmp/work/mips32r2-yoe-linux-musl/networkmanager/1.14.4-r0/recipe-sysroot/usr/include/net/ethernet.h:10,
> > |  from 
> > ../NetworkManager-1.14.4/shared/n-acd/src/n-acd.c:28:
> > | 
> > TOPDIR/build/tmp/work/mips32r2-yoe-linux-musl/networkmanager/1.14.4-r0/recipe-sysroot/usr/include/netinet/if_ether.h:111:8:
> > error: redefinition of 'struct ethhdr'
> > |  struct ethhdr {
> > | ^~
> > | In file included from 
> > ../NetworkManager-1.14.4/shared/n-acd/src/n-acd.c:26:
> > | 
> > TOPDIR/build/tmp/work/mips32r2-yoe-linux-musl/networkmanager/1.14.4-r0/recipe-sysroot/usr/include/linux/if_ether.h:167:8:
> > note: originally defined here
> > | struct ethhdr {
> > | ^~
> >
> > glibc does not fail because it does include linux header
> > | /* Get definitions from kernel header file.  */
> > | #include 
> > and does not define struct ethhdr
> >
> > linux/if_ether.h says:
> > /* allow libcs like musl to deactivate this, glibc does not implement this. 
> > */
> > #ifndef __UAPI_DEF_ETHHDR
> > #define __UAPI_DEF_ETHHDR1
> > #endif
> >
> > #if __UAPI_DEF_ETHHDR
> > struct ethhdr {
> > unsigned charh_dest[ETH_ALEN];/* destination eth addr*/
> > unsigned charh_source[ETH_ALEN];/* source ether addr*/
> > __be16h_proto;/* packet type ID field*/
> > } __attribute__((packed));
> > #endif
> >
> > musl does not include linux header but defines which is differen from
> > what linux does:
> > struct ethhdr {
> > uint8_t h_dest[ETH_ALEN];
> > uint8_t h_source[ETH_ALEN];
> > uint16_t h_proto;
> > };
> > and later
> > #define __UAPI_DEF_ETHHDR   0
> >
> > So for networkmanager there is either some wrong sequence or it
> > includes linux headers.
>
> musl headers providing own different definitions of kernel interfaces
> is a problem in musl.
>
> After reading [1] I think that this is musl upstream having made the
> decision of not even trying to work properly with the kernel headers.
>
> OE adding a not upstreamable patch that removes one of the two
> definitions in musl builds might be the best available solution.
>
> > And I am still not confident that it is our job to teach umpteen
> > projects written for linux how to write portable code (oe-core has 147
> > musl related patches and meta-openembedded has 140)...
> >...
>
> This is not about writing portable code, this is about problems with musl.
>
> Using the Linux userspace headers is obviously not portable to non-Linux,
> but many packages like NetworkManager are anyways Linux-only no matter
> what you do.
>
> > Andreas
>
> cu
> Adrian
>
> [1] https://wiki.musl-libc.org/faq.html#Q:-Why-am-I-getting-
>
Have looked into some papers at musl page and the link above: The more
I read from them the less I am interested in wasting my time on it.
There is too often this 'the world is full of idiots - and it is just
us doing the right thing' between the lines. Starts that they call
musl 'correct' - while their own performance charts are - for my use
case - unacceptable (ok outdated - maybe things changed). One could
say: Go and give it a try but there is just a little problem: I think
it'll take weeks to get images with contents I interested in.

Looked into networkmanager: There are dozen places where linux headers
are used - I don't see a clean solution we could offer upstream.

What bugs me most: Silently a rule was introduced that patches failing
for musl are not accepted - or did I miss something. A project
considering itself as center of the world blocks resources here in
times these are limited.

Just to add that I spent past three weekends to wipe after patches
being removed / 'bit-rottened' stuff was removed from a layer I
maintain right before next release. Ahh maintainer means take care /
answer user questions take / complaints when something does not work -
but when it comes to decisions: Please keep you mouth shut.

it is enough

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

[OE-core] [meta][PATCH] run-ptest: use error handling for useradd and userdel

2019-03-25 Thread Aditya Tayade 
Error handling in shell scripts is too easy to forget and
get wrong. It is possible to check every external command
for return values but it is better to use a generic setting
which halts execution of the script on any failures.

Upstream-Status: Pending
Signed-off-by: Aditya Tayade 
---
 meta/recipes-core/glib-2.0/glib-2.0/run-ptest | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-core/glib-2.0/glib-2.0/run-ptest 
b/meta/recipes-core/glib-2.0/glib-2.0/run-ptest
index 5b85e8f..8f082d3 100644
--- a/meta/recipes-core/glib-2.0/glib-2.0/run-ptest
+++ b/meta/recipes-core/glib-2.0/glib-2.0/run-ptest
@@ -1,5 +1,6 @@
 #! /bin/sh

+set -eux
 useradd glib2-test
 su glib2-test -c gnome-desktop-testing-runner glib
 userdel glib2-test
--
2.7.4

This message contains information that may be privileged or confidential and is 
the property of the KPIT Technologies Ltd. It is intended only for the person 
to whom it is addressed. If you are not the intended recipient, you are not 
authorized to read, print, retain copy, disseminate, distribute, or use this 
message or any part thereof. If you receive this message in error, please 
notify the sender immediately and delete all copies of this message. KPIT 
Technologies Ltd. does not accept any liability for virus infected mails.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] musl thoughts

2019-03-25 Thread Khem Raj 
On Mon, Mar 25, 2019 at 2:12 PM Andreas Müller 
wrote:

> On Mon, Mar 25, 2019 at 6:46 PM Adrian Bunk  wrote:
> >
> > On Mon, Mar 25, 2019 at 06:15:40PM +0100, Andreas Müller wrote:
> > >...
> > > Looked into this. Found an old musl build failure of networkmanager
> > > [1] but I think the issue has not changed:
> > >
> > > | In file included from
> > >
> TOPDIR/build/tmp/work/mips32r2-yoe-linux-musl/networkmanager/1.14.4-r0/recipe-sysroot/usr/include/net/ethernet.h:10,
> > > |  from
> ../NetworkManager-1.14.4/shared/n-acd/src/n-acd.c:28:
> > > |
> TOPDIR/build/tmp/work/mips32r2-yoe-linux-musl/networkmanager/1.14.4-r0/recipe-sysroot/usr/include/netinet/if_ether.h:111:8:
> > > error: redefinition of 'struct ethhdr'
> > > |  struct ethhdr {
> > > | ^~
> > > | In file included from
> ../NetworkManager-1.14.4/shared/n-acd/src/n-acd.c:26:
> > > |
> TOPDIR/build/tmp/work/mips32r2-yoe-linux-musl/networkmanager/1.14.4-r0/recipe-sysroot/usr/include/linux/if_ether.h:167:8:
> > > note: originally defined here
> > > | struct ethhdr {
> > > | ^~
> > >
> > > glibc does not fail because it does include linux header
> > > | /* Get definitions from kernel header file.  */
> > > | #include 
> > > and does not define struct ethhdr
> > >
> > > linux/if_ether.h says:
> > > /* allow libcs like musl to deactivate this, glibc does not implement
> this. */
> > > #ifndef __UAPI_DEF_ETHHDR
> > > #define __UAPI_DEF_ETHHDR1
> > > #endif
> > >
> > > #if __UAPI_DEF_ETHHDR
> > > struct ethhdr {
> > > unsigned charh_dest[ETH_ALEN];/* destination eth addr*/
> > > unsigned charh_source[ETH_ALEN];/* source ether addr*/
> > > __be16h_proto;/* packet type ID field*/
> > > } __attribute__((packed));
> > > #endif
> > >
> > > musl does not include linux header but defines which is differen from
> > > what linux does:
> > > struct ethhdr {
> > > uint8_t h_dest[ETH_ALEN];
> > > uint8_t h_source[ETH_ALEN];
> > > uint16_t h_proto;
> > > };
> > > and later
> > > #define __UAPI_DEF_ETHHDR   0
> > >
> > > So for networkmanager there is either some wrong sequence or it
> > > includes linux headers.
> >
> > musl headers providing own different definitions of kernel interfaces
> > is a problem in musl.
> >
> > After reading [1] I think that this is musl upstream having made the
> > decision of not even trying to work properly with the kernel headers.
> >
> > OE adding a not upstreamable patch that removes one of the two
> > definitions in musl builds might be the best available solution.
> >
> > > And I am still not confident that it is our job to teach umpteen
> > > projects written for linux how to write portable code (oe-core has 147
> > > musl related patches and meta-openembedded has 140)...
> > >...
> >
> > This is not about writing portable code, this is about problems with
> musl.
> >
> > Using the Linux userspace headers is obviously not portable to non-Linux,
> > but many packages like NetworkManager are anyways Linux-only no matter
> > what you do.
> >
> > > Andreas
> >
> > cu
> > Adrian
> >
> > [1] https://wiki.musl-libc.org/faq.html#Q:-Why-am-I-getting-
> >
> Have looked into some papers at musl page and the link above: The more
> I read from them the less I am interested in wasting my time on it.
> There is too often this 'the world is full of idiots - and it is just
> us doing the right thing' between the lines. Starts that they call
> musl 'correct' - while their own performance charts are - for my use
> case - unacceptable (ok outdated - maybe things changed). One could
> say: Go and give it a try but there is just a little problem: I think
> it'll take weeks to get images with contents I interested in.
>
> Looked into networkmanager: There are dozen places where linux headers
> are used - I don't see a clean solution we could offer upstream.
>
> What bugs me most: Silently a rule was introduced that patches failing
> for musl are not accepted - or did I miss something. A project
> considering itself as center of the world blocks resources here in
> times these are limited.


No there is no rule like that it’s who shows up with interest and reports
problems I understand your usecase might not involve musl and that’s how
everyone is they have interest in some parts of project but they cooperate
with the things which don’t interest them so when I ask it’s breaking musl
I am trying to nudge them to help fixing it since I do the same when
someone approaches my patches and reports issues that could be fixed in
that and sometimes I express my helplessness and sometimes I do help if I
have knleoledge and time so I expect others to do same

>
>
> Just to add that I spent past three weekends to wipe after patches
> being removed / 'bit-rottened' stuff was removed from a layer I
> maintain right before next release. Ahh maintainer means take care /
> answer user questions take / complaints when something does not work -
> but when

[OE-core] thud][Pull request]

2019-03-25 Thread akuster808 
Please consider these for the next thud release.


The following changes since commit b79bd7c77635ed45509dfc288c2ca7a2dcf1cc67:

  libpam: libpamc is licensed under its own BSD-style licence
(2019-03-22 14:40:46 -0700)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core thud-next

for you to fetch changes up to c48c37a436b3ebfe4d8ca5d12e97a0cdff0e20a1:

  scripts/wic: Be consistent about how we call bitbake (2019-03-24
22:49:54 +)


Mazliana (2):
  scripts/resulttool: enable manual execution and result creation
  resulttool/manualexecution: To output right test case id

Richard Purdie (9):
  resulttool: Improvements to allow integration to the autobuilder
  resulttool/resultutils: Avoids tracebacks for missing logs
  resulttool/store: Handle results files for multiple revisions
  resulttool/report: Handle missing metadata sections more cleanly
  resulttool/report: Ensure test suites with no results show up on
the report
  resulttool/report: Ensure ptest results are sorted
  resulttool/store: Fix missing variable causing testresult corruption
  oeqa/utils/gitarchive: Handle case where parent is only on origin
  scripts/wic: Be consistent about how we call bitbake

Yeoh Ee Peng (4):
  resulttool: enable merge, store, report and regression analysis
  resulttool/regression: Ensure regressoin results are sorted
  scripts/resulttool: Enable manual result store and regression
  resulttool/report: Enable roll-up report for a commit

 meta/lib/oeqa/files/testresults/testresults.json   |  40 +
 meta/lib/oeqa/selftest/cases/resulttooltests.py    |  94 ++
 meta/lib/oeqa/utils/gitarchive.py  |   4 +-
 scripts/lib/resulttool/__init__.py |   0
 scripts/lib/resulttool/manualexecution.py  | 142 +++
 scripts/lib/resulttool/merge.py    |  42 +
 scripts/lib/resulttool/regression.py   | 192
+
 scripts/lib/resulttool/report.py   | 150 
 scripts/lib/resulttool/resultutils.py  | 131 ++
 scripts/lib/resulttool/store.py    |  99 +++
 .../resulttool/template/test_report_full_text.txt  |  44 +
 scripts/resulttool |  93 ++
 scripts/wic    |  16 +-
 13 files changed, 1034 insertions(+), 13 deletions(-)
 create mode 100644 meta/lib/oeqa/files/testresults/testresults.json
 create mode 100644 meta/lib/oeqa/selftest/cases/resulttooltests.py
 create mode 100644 scripts/lib/resulttool/__init__.py
 create mode 100755 scripts/lib/resulttool/manualexecution.py
 create mode 100644 scripts/lib/resulttool/merge.py
 create mode 100644 scripts/lib/resulttool/regression.py
 create mode 100644 scripts/lib/resulttool/report.py
 create mode 100644 scripts/lib/resulttool/resultutils.py
 create mode 100644 scripts/lib/resulttool/store.py
 create mode 100644
scripts/lib/resulttool/template/test_report_full_text.txt
 create mode 100755 scripts/resulttool

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

[OE-core] [PATCH 2/2] libsndfile1: fix CVE-2019-3832

2019-03-25 Thread Ross Burton 
The previous fix for CVE-2018-19758 wasn't complete, so backport another patch
to solve it properly.

Signed-off-by: Ross Burton 
---
 .../libsndfile/libsndfile1/CVE-2019-3832.patch | 37 ++
 .../libsndfile/libsndfile1_1.0.28.bb   |  1 +
 2 files changed, 38 insertions(+)
 create mode 100644 
meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2019-3832.patch

diff --git a/meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2019-3832.patch 
b/meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2019-3832.patch
new file mode 100644
index 000..ab37211399f
--- /dev/null
+++ b/meta/recipes-multimedia/libsndfile/libsndfile1/CVE-2019-3832.patch
@@ -0,0 +1,37 @@
+From 43886efc408c21e1e329086ef70c88860310f25b Mon Sep 17 00:00:00 2001
+From: Emilio Pozuelo Monfort 
+Date: Tue, 5 Mar 2019 11:27:17 +0100
+Subject: [PATCH] wav_write_header: don't read past the array end
+
+CVE-2018-19758 wasn't entirely fixed in the fix, so fix it harder.
+
+CVE: CVE-2019-3832
+Upstream-Status: Backport [7408c4c788ce047d4e652b60a04e7796bcd7267e]
+Signed-off-by: Ross Burton 
+
+If loop_count is bigger than the array, truncate it to the array
+length (and not to 32k).
+
+CVE-2019-3832
+
+---
+ src/wav.c | 6 --
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/src/wav.c b/src/wav.c
+index daae3cc..8851549 100644
+--- a/src/wav.c
 b/src/wav.c
+@@ -1094,8 +1094,10 @@ wav_write_header (SF_PRIVATE *psf, int calc_length)
+   psf_binheader_writef (psf, "44", 0, 0) ; /* SMTPE format */
+   psf_binheader_writef (psf, "44", psf->instrument->loop_count, 
0) ;
+ 
+-  /* Loop count is signed 16 bit number so we limit it range to 
something sensible. */
+-  psf->instrument->loop_count &= 0x7fff ;
++  /* Make sure we don't read past the loops array end. */
++  if (psf->instrument->loop_count > ARRAY_LEN 
(psf->instrument->loops))
++  psf->instrument->loop_count = ARRAY_LEN 
(psf->instrument->loops) ;
++
+   for (tmp = 0 ; tmp < psf->instrument->loop_count ; tmp++)
+   {   int type ;
+ 
diff --git a/meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb 
b/meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb
index eb2c719d8da..77393db8470 100644
--- a/meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb
+++ b/meta/recipes-multimedia/libsndfile/libsndfile1_1.0.28.bb
@@ -16,6 +16,7 @@ SRC_URI = 
"http://www.mega-nerd.com/libsndfile/files/libsndfile-${PV}.tar.gz \
file://CVE-2018-19432.patch \
file://CVE-2017-12562.patch \
file://CVE-2018-19758.patch \
+   file://CVE-2019-3832.patch \
   "
 
 SRC_URI[md5sum] = "646b5f98ce89ac60cdb060fcd398247c"
-- 
2.11.0

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

[OE-core] [PATCH 1/2] bluez5: fix CVE-2018-10910

2019-03-25 Thread Ross Burton 
Fix this CVE (Bluetooth discoverability may be enabled with no agents to handle
requests) by backporting a number of patches from upstream.

Signed-off-by: Ross Burton 
---
 meta/recipes-connectivity/bluez5/bluez5.inc|   1 +
 .../bluez5/bluez5/CVE-2018-10910.patch | 705 +
 2 files changed, 706 insertions(+)
 create mode 100644 meta/recipes-connectivity/bluez5/bluez5/CVE-2018-10910.patch

diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc 
b/meta/recipes-connectivity/bluez5/bluez5.inc
index 6d62f524591..aaf2af975d0 100644
--- a/meta/recipes-connectivity/bluez5/bluez5.inc
+++ b/meta/recipes-connectivity/bluez5/bluez5.inc
@@ -53,6 +53,7 @@ SRC_URI = "\
 file://0001-tests-add-a-target-for-building-tests-without-runnin.patch \
 file://0001-test-gatt-Fix-hung-issue.patch \
 file://0001-Makefile.am-Fix-a-race-issue-for-tools.patch \
+file://CVE-2018-10910.patch \
 "
 S = "${WORKDIR}/bluez-${PV}"
 
diff --git a/meta/recipes-connectivity/bluez5/bluez5/CVE-2018-10910.patch 
b/meta/recipes-connectivity/bluez5/bluez5/CVE-2018-10910.patch
new file mode 100644
index 000..b4b1846c45b
--- /dev/null
+++ b/meta/recipes-connectivity/bluez5/bluez5/CVE-2018-10910.patch
@@ -0,0 +1,705 @@
+A bug in Bluez may allow for the Bluetooth Discoverable state being set to on
+when no Bluetooth agent is registered with the system. This situation could
+lead to the unauthorized pairing of certain Bluetooth devices without any
+form of authentication.
+
+CVE: CVE-2018-10910
+Upstream-Status: Backport
+Signed-off-by: Ross Burton 
+
+Subject:[PATCH BlueZ 1/4] client: Add discoverable-timeout command
+From:   Luiz Augusto von Dentz 
+Date:   2018-07-25 10:20:32
+Message-ID: 20180725102035.19439-1-luiz.dentz () gmail ! com
+[Download RAW message or body]
+
+From: Luiz Augusto von Dentz 
+
+This adds discoverable-timeout command which can be used to get/set
+DiscoverableTimeout property:
+
+[bluetooth]# discoverable-timeout 180
+Changing discoverable-timeout 180 succeeded
+---
+ client/main.c | 43 +++
+ 1 file changed, 43 insertions(+)
+
+diff --git a/client/main.c b/client/main.c
+index 87323d8f7..59820c6d9 100644
+--- a/client/main.c
 b/client/main.c
+@@ -1061,6 +1061,47 @@ static void cmd_discoverable(int argc, char *argv[])
+   return bt_shell_noninteractive_quit(EXIT_FAILURE);
+ }
+ 
++static void cmd_discoverable_timeout(int argc, char *argv[])
++{
++  uint32_t value;
++  char *endptr = NULL;
++  char *str;
++
++  if (argc < 2) {
++  DBusMessageIter iter;
++
++  if (!g_dbus_proxy_get_property(default_ctrl->proxy,
++  "DiscoverableTimeout", &iter)) {
++  bt_shell_printf("Unable to get DiscoverableTimeout\n");
++  return bt_shell_noninteractive_quit(EXIT_FAILURE);
++  }
++
++  dbus_message_iter_get_basic(&iter, &value);
++
++  bt_shell_printf("DiscoverableTimeout: %d seconds\n", value);
++
++  return;
++  }
++
++  value = strtol(argv[1], &endptr, 0);
++  if (!endptr || *endptr != '\0' || value > UINT32_MAX) {
++  bt_shell_printf("Invalid argument\n");
++  return bt_shell_noninteractive_quit(EXIT_FAILURE);
++  }
++
++  str = g_strdup_printf("discoverable-timeout %d", value);
++
++  if (g_dbus_proxy_set_property_basic(default_ctrl->proxy,
++  "DiscoverableTimeout",
++  DBUS_TYPE_UINT32, &value,
++  generic_callback, str, g_free))
++  return;
++
++  g_free(str);
++
++  return bt_shell_noninteractive_quit(EXIT_FAILURE);
++}
++
+ static void cmd_agent(int argc, char *argv[])
+ {
+   dbus_bool_t enable;
+@@ -2549,6 +2590,8 @@ static const struct bt_shell_menu main_menu = {
+   { "discoverable", "", cmd_discoverable,
+   "Set controller discoverable mode",
+   NULL },
++  { "discoverable-timeout", "[value]", cmd_discoverable_timeout,
++  "Set discoverable timeout", NULL },
+   { "agent","", cmd_agent,
+   "Enable/disable agent with given capability",
+   capability_generator},
+-- 
+2.17.1
+
+Subject:[PATCH BlueZ 2/4] client: Make show command print 
DiscoverableTimeout
+From:   Luiz Augusto von Dentz 
+Date:   2018-07-25 10:20:33
+Message-ID: 20180725102035.19439-2-luiz.dentz () gmail ! com
+[Download RAW message or body]
+
+From: Luiz Augusto von Dentz 
+
+Controller XX:XX:XX:XX:XX:XX (public)
+   Name: Vudentz's T460s
+   Alias: Intel-1
+   Class: 0x004c010c
+   Powered: yes
+   Discoverable: no
+   DiscoverableTimeout: 0x000

[OE-core] sumo][Pull request

2019-03-25 Thread akuster808 
Please consider these changes for the next sumo release.


The following changes since commit 4af5a794497746629a35726ce515556b53d40da9:

  lttng-tools: update to 2.9.11 (2019-03-24 18:39:35 -0700)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core sumo-next

for you to fetch changes up to 94a3ca85d30fc957f8f01a216a75342be49f9143:

  oe-build-perf-report/gitarchive: Move common useful functions to
library (2019-03-25 23:12:08 +)


Mazliana (2):
  scripts/resulttool: enable manual execution and result creation
  resulttool/manualexecution: To output right test case id

Richard Purdie (13):
  resulttool: Improvements to allow integration to the autobuilder
  resulttool/resultutils: Avoids tracebacks for missing logs
  resulttool/store: Handle results files for multiple revisions
  resulttool/report: Handle missing metadata sections more cleanly
  resulttool/report: Ensure test suites with no results show up on
the report
  resulttool/report: Ensure ptest results are sorted
  resulttool/store: Fix missing variable causing testresult corruption
  oe-build-perf-report: Allow branch without hostname
  oe-build-perf-report: Allow commits from different branches
  oe-build-perf-report: Improve branch comparision handling
  oe-build-perf-report: Fix missing buildstats comparisions
  scripts/oe-git-archive: Separate out functionality to library function
  oe-build-perf-report/gitarchive: Move common useful functions to
library

Yeoh Ee Peng (4):
  resulttool: enable merge, store, report and regression analysis
  resulttool/regression: Ensure regressoin results are sorted
  scripts/resulttool: Enable manual result store and regression
  resulttool/report: Enable roll-up report for a commit

 meta/lib/oeqa/files/testresults/testresults.json   |  40 
 meta/lib/oeqa/selftest/cases/resulttooltests.py    |  94 
 meta/lib/oeqa/utils/gitarchive.py  | 244
+
 scripts/lib/resulttool/__init__.py |   0
 scripts/lib/resulttool/manualexecution.py  | 142 
 scripts/lib/resulttool/merge.py    |  42 
 scripts/lib/resulttool/regression.py   | 192 
 scripts/lib/resulttool/report.py   | 150 +
 scripts/lib/resulttool/resultutils.py  | 131 +++
 scripts/lib/resulttool/store.py    |  99 +
 .../resulttool/template/test_report_full_text.txt  |  44 
 scripts/oe-build-perf-report   | 124 ---
 scripts/oe-git-archive | 166 +-
 scripts/resulttool |  93 
 14 files changed, 1314 insertions(+), 247 deletions(-)
 create mode 100644 meta/lib/oeqa/files/testresults/testresults.json
 create mode 100644 meta/lib/oeqa/selftest/cases/resulttooltests.py
 create mode 100644 meta/lib/oeqa/utils/gitarchive.py
 create mode 100644 scripts/lib/resulttool/__init__.py
 create mode 100755 scripts/lib/resulttool/manualexecution.py
 create mode 100644 scripts/lib/resulttool/merge.py
 create mode 100644 scripts/lib/resulttool/regression.py
 create mode 100644 scripts/lib/resulttool/report.py
 create mode 100644 scripts/lib/resulttool/resultutils.py
 create mode 100644 scripts/lib/resulttool/store.py
 create mode 100644
scripts/lib/resulttool/template/test_report_full_text.txt
 create mode 100755 scripts/resulttool

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

[OE-core] [thud][PATCH 2/2] yocto-uninative: Update to 2.4

2019-03-25 Thread Armin Kuster 
From: Richard Purdie 

This supports glibc 2.29 which is appearing in distros like Ubuntu 19.04

Signed-off-by: Richard Purdie 
Signed-off-by: Armin Kuster 
---
 meta/conf/distro/include/yocto-uninative.inc | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/meta/conf/distro/include/yocto-uninative.inc 
b/meta/conf/distro/include/yocto-uninative.inc
index 0d484f6..59ccd69 100644
--- a/meta/conf/distro/include/yocto-uninative.inc
+++ b/meta/conf/distro/include/yocto-uninative.inc
@@ -6,10 +6,9 @@
 # to the distro running on the build machine.
 #
 
-UNINATIVE_MAXGLIBCVERSION = "2.28"
-
-UNINATIVE_URL ?= "http://downloads.yoctoproject.org/releases/uninative/2.3/";
-UNINATIVE_CHECKSUM[aarch64] ?= 
"e495046969c796b7fbbaad1ec86d76eca84d83098f50525b8a4124cc8685eaed"
-UNINATIVE_CHECKSUM[i686] ?= 
"44253cddbf629082568cea4fff59419106871a0cf81b4845b5d34e7014887b20"
-UNINATIVE_CHECKSUM[x86_64] ?= 
"c6954563dad3c95608117c6fc328099036c832bbd924ebf5fdccb622fc0a8684"
+UNINATIVE_MAXGLIBCVERSION = "2.29"
 
+UNINATIVE_URL ?= "http://downloads.yoctoproject.org/releases/uninative/2.4/";
+UNINATIVE_CHECKSUM[aarch64] ?= 
"af2e2faf6cf00ff45cc1bcd5e3fb00cee7f79b3ec7c3be15917ad4ff8c154cfe"
+UNINATIVE_CHECKSUM[i686] ?= 
"fafacfc537a6ce2bd122bd16c146881ab5ac69bd575abf6cb68a0dd33fa70ea2"
+UNINATIVE_CHECKSUM[x86_64] ?= 
"06f91685b782f2ccfedf3070b3ba0fe4a5ba2f0766dad5c9d1642dccf95accd0"
-- 
2.7.4

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

[OE-core] [PATCH] libcomps: put PV in filename

2019-03-25 Thread Ross Burton 
This isn't a git snapshot recipe but a release that is fetched over it.  For
clarity, put the PV in the filename.

Signed-off-by: Ross Burton 
---
 meta/recipes-devtools/libcomps/{libcomps_git.bb => libcomps_0.1.10.bb} | 1 -
 1 file changed, 1 deletion(-)
 rename meta/recipes-devtools/libcomps/{libcomps_git.bb => libcomps_0.1.10.bb} 
(98%)

diff --git a/meta/recipes-devtools/libcomps/libcomps_git.bb 
b/meta/recipes-devtools/libcomps/libcomps_0.1.10.bb
similarity index 98%
rename from meta/recipes-devtools/libcomps/libcomps_git.bb
rename to meta/recipes-devtools/libcomps/libcomps_0.1.10.bb
index ff6820851fe..1c4f3bde65e 100644
--- a/meta/recipes-devtools/libcomps/libcomps_git.bb
+++ b/meta/recipes-devtools/libcomps/libcomps_0.1.10.bb
@@ -9,7 +9,6 @@ SRC_URI = 
"git://github.com/rpm-software-management/libcomps.git \
file://0001-Add-crc32.c-to-sources-list.patch \
"
 
-PV = "0.1.10"
 SRCREV = "86a82fcd155c27092340d15a34f5c75c4da88243"
 
 S = "${WORKDIR}/git"
-- 
2.11.0

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

[OE-core] [thud][PATCH 1/2] yocto-uninative: Correct sha256sum for aarch64

2019-03-25 Thread Armin Kuster 
From: Michael Halstead 

Avoid uninative checksum warnings when building on aarch64 hardware.

Signed-off-by: Michael Halstead 
Signed-off-by: Richard Purdie 
Signed-off-by: Armin Kuster 
---
 meta/conf/distro/include/yocto-uninative.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/distro/include/yocto-uninative.inc 
b/meta/conf/distro/include/yocto-uninative.inc
index c9d502b..0d484f6 100644
--- a/meta/conf/distro/include/yocto-uninative.inc
+++ b/meta/conf/distro/include/yocto-uninative.inc
@@ -9,7 +9,7 @@
 UNINATIVE_MAXGLIBCVERSION = "2.28"
 
 UNINATIVE_URL ?= "http://downloads.yoctoproject.org/releases/uninative/2.3/";
-UNINATIVE_CHECKSUM[aarch64] ?= 
"b7fbbaad1ec86d76eca84d83098f50525b8a4124cc8685eaed"
+UNINATIVE_CHECKSUM[aarch64] ?= 
"e495046969c796b7fbbaad1ec86d76eca84d83098f50525b8a4124cc8685eaed"
 UNINATIVE_CHECKSUM[i686] ?= 
"44253cddbf629082568cea4fff59419106871a0cf81b4845b5d34e7014887b20"
 UNINATIVE_CHECKSUM[x86_64] ?= 
"c6954563dad3c95608117c6fc328099036c832bbd924ebf5fdccb622fc0a8684"
 
-- 
2.7.4

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

[OE-core] [sumo][PATCH] yocto-uninative: Update to 2.4

2019-03-25 Thread Armin Kuster 
From: Richard Purdie 

This supports glibc 2.29 which is appearing in distros like Ubuntu 19.04

Signed-off-by: Richard Purdie 
[Fixed up for Sumo context; no aarch64]
Signed-off-by: Armin Kuster 
---
 meta/conf/distro/include/yocto-uninative.inc | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/meta/conf/distro/include/yocto-uninative.inc 
b/meta/conf/distro/include/yocto-uninative.inc
index c5b0556..64e71d9 100644
--- a/meta/conf/distro/include/yocto-uninative.inc
+++ b/meta/conf/distro/include/yocto-uninative.inc
@@ -6,9 +6,8 @@
 # to the distro running on the build machine.
 #
 
-UNINATIVE_MAXGLIBCVERSION = "2.28"
-
-UNINATIVE_URL ?= "http://downloads.yoctoproject.org/releases/uninative/2.3/";
-UNINATIVE_CHECKSUM[i686] ?= 
"44253cddbf629082568cea4fff59419106871a0cf81b4845b5d34e7014887b20"
-UNINATIVE_CHECKSUM[x86_64] ?= 
"c6954563dad3c95608117c6fc328099036c832bbd924ebf5fdccb622fc0a8684"
+UNINATIVE_MAXGLIBCVERSION = "2.29"
 
+UNINATIVE_URL ?= "http://downloads.yoctoproject.org/releases/uninative/2.4/";
+UNINATIVE_CHECKSUM[i686] ?= 
"fafacfc537a6ce2bd122bd16c146881ab5ac69bd575abf6cb68a0dd33fa70ea2"
+UNINATIVE_CHECKSUM[x86_64] ?= 
"06f91685b782f2ccfedf3070b3ba0fe4a5ba2f0766dad5c9d1642dccf95accd0"
-- 
2.7.4

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

Re: [OE-core] [PATCH] gcc-sanitizers: fix -Werror=maybe-uninitialized issue

2019-03-25 Thread Yu, Mingli 

Ping.

Thanks,

On 2019年03月19日 16:44, mingli...@windriver.com wrote:

From: Mingli Yu 

When DEBUG_BUILD = "1" added in local.conf, there
comes below build error when "bitbake gcc-sanitizers":
| 
./../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:
 In function 'elf_is_symlink':
| 
../../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:772:21:
 error: 'st.st_mode' may be used uninitialized in this function 
[-Werror=maybe-uninitialized]
|   return S_ISLNK (st.st_mode);

Initialize st_mode member to fix the above issue.

Signed-off-by: Mingli Yu 
---
  meta/recipes-devtools/gcc/gcc-8.3.inc  |  1 +
  .../0041-elf.c-initialize-st_mode-member.patch | 33 ++
  2 files changed, 34 insertions(+)
  create mode 100644 
meta/recipes-devtools/gcc/gcc-8.3/0041-elf.c-initialize-st_mode-member.patch

diff --git a/meta/recipes-devtools/gcc/gcc-8.3.inc 
b/meta/recipes-devtools/gcc/gcc-8.3.inc
index f7bf257..3501325 100644
--- a/meta/recipes-devtools/gcc/gcc-8.3.inc
+++ b/meta/recipes-devtools/gcc/gcc-8.3.inc
@@ -71,6 +71,7 @@ SRC_URI = "\
 file://0038-Re-introduce-spe-commandline-options.patch \
 file://0039-riscv-Disable-multilib-for-OE.patch \
 file://0040-powerpc-powerpc64-Add-support-for-musl-ldso.patch \
+   file://0041-elf.c-initialize-st_mode-member.patch \
  "
  SRC_URI[md5sum] = "65b210b4bfe7e060051f799e0f994896"
  SRC_URI[sha256sum] = 
"64baadfe6cc0f4947a84cb12d7f0dfaf45bb58b7e92461639596c21e02d97d2c"
diff --git 
a/meta/recipes-devtools/gcc/gcc-8.3/0041-elf.c-initialize-st_mode-member.patch 
b/meta/recipes-devtools/gcc/gcc-8.3/0041-elf.c-initialize-st_mode-member.patch
new file mode 100644
index 000..8e80c4e
--- /dev/null
+++ 
b/meta/recipes-devtools/gcc/gcc-8.3/0041-elf.c-initialize-st_mode-member.patch
@@ -0,0 +1,33 @@
+From 960f3e1f104192ceb80a97e665fadffda5285aab Mon Sep 17 00:00:00 2001
+From: Mingli Yu 
+Date: Tue, 19 Mar 2019 16:23:04 +0800
+Subject: [PATCH] elf.c: initialize st_mode member
+
+Initialize st_mode member to fix the below
+build failure when -Og included in compiler flag.
+| 
./../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:
 In function 'elf_is_symlink':
+| 
../../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:772:21:
 error: 'st.st_mode' may be used uninitialized in this function 
[-Werror=maybe-uninitialized]
+   return S_ISLNK (st.st_mode);
+
+Upstream-Status: 
Submitted[https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00900.html]
+
+Signed-off-by: Mingli Yu 
+---
+ libbacktrace/elf.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/libbacktrace/elf.c b/libbacktrace/elf.c
+index f4863f0..561bdc2 100644
+--- a/libbacktrace/elf.c
 b/libbacktrace/elf.c
+@@ -766,6 +766,7 @@ static int
+ elf_is_symlink (const char *filename)
+ {
+   struct stat st;
++  st.st_mode = 0;
+
+   if (lstat (filename, &st) < 0)
+ return 0;
+--
+2.7.4
+


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

Re: [OE-core] [PATCH] libcomps: put PV in filename

2019-03-25 Thread Khem Raj 
On Mon, Mar 25, 2019 at 4:44 PM Ross Burton  wrote:
>
> This isn't a git snapshot recipe but a release that is fetched over it.  For
> clarity, put the PV in the filename.

I think its better to keep it as it is. since its easy to trace git log history.

>
> Signed-off-by: Ross Burton 
> ---
>  meta/recipes-devtools/libcomps/{libcomps_git.bb => libcomps_0.1.10.bb} | 1 -
>  1 file changed, 1 deletion(-)
>  rename meta/recipes-devtools/libcomps/{libcomps_git.bb => 
> libcomps_0.1.10.bb} (98%)
>
> diff --git a/meta/recipes-devtools/libcomps/libcomps_git.bb 
> b/meta/recipes-devtools/libcomps/libcomps_0.1.10.bb
> similarity index 98%
> rename from meta/recipes-devtools/libcomps/libcomps_git.bb
> rename to meta/recipes-devtools/libcomps/libcomps_0.1.10.bb
> index ff6820851fe..1c4f3bde65e 100644
> --- a/meta/recipes-devtools/libcomps/libcomps_git.bb
> +++ b/meta/recipes-devtools/libcomps/libcomps_0.1.10.bb
> @@ -9,7 +9,6 @@ SRC_URI = 
> "git://github.com/rpm-software-management/libcomps.git \
> file://0001-Add-crc32.c-to-sources-list.patch \
> "
>
> -PV = "0.1.10"
>  SRCREV = "86a82fcd155c27092340d15a34f5c75c4da88243"
>
>  S = "${WORKDIR}/git"
> --
> 2.11.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] resulttool/merge: Enable merge results to one file

2019-03-25 Thread Yeoh Ee Peng 
QA team execute extra testing that create multiple test result files,
where these test result files need to be merged into a single file
under certain use case.

Enable merge to allow merging results into a single test result file.

Signed-off-by: Yeoh Ee Peng 
---
 scripts/lib/resulttool/merge.py   | 29 -
 scripts/lib/resulttool/resultutils.py | 76 +--
 2 files changed, 82 insertions(+), 23 deletions(-)

diff --git a/scripts/lib/resulttool/merge.py b/scripts/lib/resulttool/merge.py
index 3e4b7a3..90b3cb3 100644
--- a/scripts/lib/resulttool/merge.py
+++ b/scripts/lib/resulttool/merge.py
@@ -17,6 +17,26 @@ import json
 import resulttool.resultutils as resultutils
 
 def merge(args, logger):
+if args.merge_to_one:
+if os.path.isdir(args.target_results):
+target_results = resultutils.load_results(args.target_results)
+else:
+target_results = resultutils.append_results({}, 
args.target_results)
+if os.path.isdir(args.base_results):
+base_results = resultutils.load_results(args.base_results)
+results = resultutils.append_results(target_results, base_results)
+else:
+results = resultutils.append_results(target_results, 
args.base_results)
+
+target_file_dir = os.path.join(os.path.dirname(args.target_results), 
'merged_results/testresults.json')
+if os.path.isdir(args.target_results):
+target_file_dir = os.path.join(args.target_results, 
'merged_results/testresults.json')
+if args.merge_to_one_dir:
+target_file_dir = os.path.join(args.merge_to_one_dir, 
'testresults.json')
+resultutils.make_directory_and_write_json_file(target_file_dir, 
results)
+logger.info('Merged results to %s' % target_file_dir)
+return 0
+
 if os.path.isdir(args.target_results):
 results = resultutils.load_resultsdata(args.target_results, 
configmap=resultutils.store_map)
 resultutils.append_resultsdata(results, args.base_results, 
configmap=resultutils.store_map)
@@ -26,7 +46,7 @@ def merge(args, logger):
 if os.path.exists(args.target_results):
 resultutils.append_resultsdata(results, args.target_results, 
configmap=resultutils.flatten_map)
 resultutils.save_resultsdata(results, 
os.path.dirname(args.target_results), fn=os.path.basename(args.target_results))
-
+logger.info('Merged results to %s' % os.path.dirname(args.target_results))
 return 0
 
 def register_commands(subparsers):
@@ -39,4 +59,9 @@ def register_commands(subparsers):
   help='the results file/directory to import')
 parser_build.add_argument('target_results',
   help='the target file or directory to merge the 
base_results with')
-
+parser_build.add_argument('-o', '--merge-to-one', action='store_true',
+  help='merge results into one file only, does not 
add any new configurations to results '
+   'and does not create additional directory 
structure which based on configurations')
+parser_build.add_argument('-d', '--merge-to-one-dir', default='',
+  help='target directory to merge results into one 
file, default directory was based on '
+   'target_results directory')
diff --git a/scripts/lib/resulttool/resultutils.py 
b/scripts/lib/resulttool/resultutils.py
index 153f2b8..e76045b 100644
--- a/scripts/lib/resulttool/resultutils.py
+++ b/scripts/lib/resulttool/resultutils.py
@@ -39,18 +39,47 @@ store_map = {
 "manual": ['TEST_TYPE', 'TEST_MODULE', 'MACHINE', 'IMAGE_BASENAME']
 }
 
+def load_json_data(f):
+if type(f) is str:
+with open(f, "r") as filedata:
+return json.load(filedata)
+else:
+return f
+
+def validate_result(result):
+if "configuration" not in result or "result" not in result:
+raise ValueError("Test results data without configuration or result 
section?")
+
+def delete_extra_ptest_data(result):
+if 'ptestresult.rawlogs' in result['result']:
+del result['result']['ptestresult.rawlogs']
+if 'ptestresult.sections' in result['result']:
+for i in result['result']['ptestresult.sections']:
+if 'log' in result['result']['ptestresult.sections'][i]:
+del result['result']['ptestresult.sections'][i]['log']
+
+def get_testresults_files(source):
+testresults_files = []
+for root, dirs, files in os.walk(source):
+for name in files:
+f = os.path.join(root, name)
+if name == "testresults.json":
+testresults_files.append(f)
+return testresults_files
+
+def make_directory_and_write_json_file(dst, results):
+os.makedirs(os.path.dirname(dst), exist_ok=True)
+with open(dst, 'w') as f:
+f.write(json.dumps(results, sort_keys=True, indent=4))
+
 #
 # Load

Re: [OE-core] [PATCH 2/8] mdadm: add udev rules to create by-partuuid for MD devices

2019-03-25 Thread Liwei Song 



On 03/25/2019 07:55 PM, Richard Purdie wrote:
> On Wed, 2019-03-20 at 23:19 -0400, Liwei Song wrote:
>> installer use partuuid for boot and swap partition,
>> But the udev rules for MD devices do not have rules to create
>> by-partuuid under /dev/disk/, this will take 90s to wait until failed
>> add the rules to create by-partuuid to support boot from raid
>> disk with "root=PARTUUID=XXX"
>>
>> Signed-off-by: Liwei Song 
>> ---
>>  ...ev.rules-create-by-partuuid-for-md-device.patch | 29
>> ++
>>  meta/recipes-extended/mdadm/mdadm_4.1.bb   |  1 +
>>  2 files changed, 30 insertions(+)
>>  create mode 100644 meta/recipes-extended/mdadm/files/0001-
>> udev.rules-create-by-partuuid-for-md-device.patch
>>
>> diff --git a/meta/recipes-extended/mdadm/files/0001-udev.rules-
>> create-by-partuuid-for-md-device.patch b/meta/recipes-
>> extended/mdadm/files/0001-udev.rules-create-by-partuuid-for-md-
>> device.patch
>> new file mode 100644
>> index ..c1f7b1cf8736
>> --- /dev/null
>> +++ b/meta/recipes-extended/mdadm/files/0001-udev.rules-create-by-
>> partuuid-for-md-device.patch
>> @@ -0,0 +1,29 @@
>> +From 7d1fa6afba936edb3e211f0ccdb58b1472b4bbf4 Mon Sep 17 00:00:00
>> 2001
>> +From: Liwei Song 
>> +Date: Tue, 26 Feb 2019 07:05:42 +
>> +Subject: [PATCH] udev.rules: create by-partuuid for md device
>> +
>> +Create by-partuuid for every md devices.
>> +
>> +Upstream-Status: sent to linux-r...@vger.kernel.org(
>> https://www.spinics.net/lists/raid/msg62373.html)
>> +
>> +Signed-off-by: Liwei Song 
>> +---
>> + udev-md-raid-arrays.rules | 1 +
>> + 1 file changed, 1 insertion(+)
> 
> It looks like upstream had concerns about this so I'd like to hold off
> on this until those are resolved.

No problem, let's wait if other folks have more concern before it is applied.

https://www.spinics.net/lists/raid/msg62379.html

Thanks,
Liwei.


> 
> https://www.spinics.net/lists/raid/msg62376.html
> 
> Cheers,
> 
> Richard
> 
> 
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core