Re: [OE-core] patch submission feedback

[Paul Eggleton]

On Wednesday, 19 September 2018 4:38:28 PM NZST Vignesh Rajendran (RBEI/ECF3) 
wrote:
> I have submitted a patch some months before and waiting for feedback after
> some discussion.
> https://patchwork.openembedded.org/patch/150819/
> 
> But after some long wait, there was no response from anyone.
> I personally feel there should be some support and motivation to
> contributors.

You are right, my sincere apologies for not being more communicative regarding 
your patch. This is a bug I would like to see fixed, and I will aim to do 
better in future.

However, taking a look at the original patch, my concerns are still the same - 
I don't think package.bbclass should have references to EXTERNALSRC added to 
it. My suggestion would be to try to generalise the solution - have 
package.bbclass detect the underlying problem, or look for S being outside of 
WORKDIR, or something similar.

Thanks
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre


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

[OE-core] patch submission feedback

[Vignesh Rajendran (RBEI/ECF3)]

Hello OE members,

I have submitted a patch some months before and waiting for feedback after some 
discussion.
https://patchwork.openembedded.org/patch/150819/

But after some long wait, there was no response from anyone.
I personally feel there should be some support and motivation to contributors.

Please do the needful.

Mit freundlichen Grüßen / Best regards

Rajendran Vignesh


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

Re: [OE-core] [PATCH 1/3] xserver-xorg: upgrade 1.19.6 -> 1.20.1

[Khem Raj]

On Mon, Sep 17, 2018 at 7:51 PM Mittal, Anuj  wrote:
>
>
>
> > -Original Message-
> > From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-
> > core-boun...@lists.openembedded.org] On Behalf Of Armin Kuster
> > Sent: Saturday, September 15, 2018 12:04 AM
> > To: akuster...@gmail.com; openembedded-core@lists.openembedded.org
> > Subject: [OE-core] [PATCH 1/3] xserver-xorg: upgrade 1.19.6 -> 1.20.1
> >
> > removed included patch
> >
> > Refresh 0001-configure.ac-Fix-check-for-CLOCK_MONOTONIC
> > Remove 0001-config-fix-NULL-value-detection-for-ID_INPUT-being-u.patch
> >
> > Signed-off-by: Armin Kuster 
> > ---
> >  ...NULL-value-detection-for-ID_INPUT-being-u.patch | 40 ---
> > ...onfigure.ac-Fix-check-for-CLOCK_MONOTONIC.patch | 19 +  ...003-
> > modesetting-Fix-16-bit-depth-bpp-mode.patch | 46 --
> >  .../xorg-xserver/xserver-xorg_1.19.6.bb| 33 
> >  .../xorg-xserver/xserver-xorg_1.20.1.bb| 31 +++
> >  5 files changed, 40 insertions(+), 129 deletions(-)  delete mode 100644 
> > meta/recipes-
> > graphics/xorg-xserver/xserver-xorg/0001-config-fix-NULL-value-detection-for-
> > ID_INPUT-being-u.patch
> >  delete mode 100644 meta/recipes-graphics/xorg-xserver/xserver-xorg/0003-
> > modesetting-Fix-16-bit-depth-bpp-mode.patch
> >  delete mode 100644 
> > meta/recipes-graphics/xorg-xserver/xserver-xorg_1.19.6.bb
> >  create mode 100644 
> > meta/recipes-graphics/xorg-xserver/xserver-xorg_1.20.1.bb
> >
> > diff --git 
> > a/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-config-fix-NULL-
> > value-detection-for-ID_INPUT-being-u.patch b/meta/recipes-graphics/xorg-
> > xserver/xserver-xorg/0001-config-fix-NULL-value-detection-for-ID_INPUT-being-
> > u.patch
> > deleted file mode 100644
> > index 964d5dd..000
> > --- 
> > a/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-config-fix-NULL-value-
> > detection-for-ID_INPUT-being-u.patch
> > +++ /dev/null
> > @@ -1,40 +0,0 @@
> > -From a309323328d9d6e0bf5d9ea1d75920e53b9beef3 Mon Sep 17 00:00:00 2001
> > -From: Peter Hutterer 
> > -Date: Fri, 5 Jan 2018 11:58:42 +1000
> > -Subject: [PATCH] config: fix NULL value detection for ID_INPUT being unset
> > -
> > -Erroneous condition caused us to keep going with all devices that didn't 
> > have -
> > ID_INPUT set.
> > -
> > -Fixes: 5aad81445c8c3d6
> > -Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104382
> > -Reviewed-by: Adam Jackson 
> > -Signed-off-by: Peter Hutterer 
> > -
> > -Upstream-status: Backport
> > -https://patchwork.freedesktop.org/patch/196090/
> > -Affects: < 1.20.0
> > -[Yocto # 12899]
> > -
> > -Signed-off-by: Armin Kuster 
> > -
> > 
> > - config/udev.c | 2 +-
> > - 1 file changed, 1 insertion(+), 1 deletion(-)
> > -
> > -diff --git a/config/udev.c b/config/udev.c -index e198e8609..3a73189e2 
> > 100644
> >  a/config/udev.c
> > -+++ b/config/udev.c
> > -@@ -135,7 +135,7 @@ device_added(struct udev_device *udev_device)
> > - #endif
> > -
> > - value = udev_device_get_property_value(udev_device, "ID_INPUT");
> > --if (value && !strcmp(value, "0")) {
> > -+if (!value || !strcmp(value, "0")) {
> > - LogMessageVerb(X_INFO, 10,
> > -"config/udev: ignoring device %s without "
> > -"property ID_INPUT set\n", path);
> > ---
> > -2.17.1
> > -
> > diff --git 
> > a/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-configure.ac-Fix-
> > check-for-CLOCK_MONOTONIC.patch b/meta/recipes-graphics/xorg-
> > xserver/xserver-xorg/0001-configure.ac-Fix-check-for-CLOCK_MONOTONIC.patch
> > index 16ec3ed..020a1cf 100644
> > --- 
> > a/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-configure.ac-Fix-check-
> > for-CLOCK_MONOTONIC.patch
> > +++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-configure.ac-
> > +++ Fix-check-for-CLOCK_MONOTONIC.patch
> > @@ -1,12 +1,13 @@
> > -Discover monotonic clock using compile-time check
> > +From 8a91316c4a38f20e7866289f3d779a037d27a129 Mon Sep 17 00:00:00 2001
> > +From: Jussi Kukkonen 
> > +Date: Mon, 12 Dec 2016 12:11:39 +0200
> > +Subject: [PATCH] Discover monotonic clock using compile-time check
> >
> >  monotonic clock check does not work when cross-compiling.
> >
> >  Upstream-Status: Denied [Does not work on OpenBSD]
> >  Signed-off-by: Jussi Kukkonen 
> >
> > -
> > -
> >  Original patch follows:
> >
> >  When xorg-xserver is being cross-compiled, there is currently no way @@ 
> > -21,15
> > +22,16 @@ monotonic clock is available. This check can run just fine when 
> > we are
> > cross-compiling.
> >
> >  Signed-off-by: David James 
> > +
> >  ---
> >   configure.ac | 17 +++--
> >   1 file changed, 7 insertions(+), 10 deletions(-)
> >
> >  diff --git a/configure.ac b/configure.ac -index f7ab48c..26e85cd 100644
> > +index 2b21667..786e002 100644
> >  --- a/configure.ac
> >  +++ b/configure.ac
> > -@@ -1048,19 +1048,16 @@ if ! test 

Re: [OE-core] [PATCH 3/3] glibc: fix build with -O

[Khem Raj]

please submit upstream as well
On Sun, Sep 16, 2018 at 10:49 PM Martin Jansa  wrote:
>
> * tested for qemuarm, qemux86 with -O, -O0, -Os, with gcc
> * to build with -O0 I had to remove restriction from systemtap first
>
> Signed-off-by: Martin Jansa 
> ---
>  meta/recipes-core/glibc/glibc.inc | 12 ---
>  ...4-prevent-maybe-uninitialized-errors.patch | 95 +++
>  ...2-soft-fp-ignore-maybe-uninitialized.patch | 72 ++
>  meta/recipes-core/glibc/glibc_2.28.bb |  2 +
>  4 files changed, 169 insertions(+), 12 deletions(-)
>  create mode 100644 
> meta/recipes-core/glibc/glibc/0031-sysdeps-ieee754-prevent-maybe-uninitialized-errors.patch
>  create mode 100644 
> meta/recipes-core/glibc/glibc/0032-soft-fp-ignore-maybe-uninitialized.patch
>
> diff --git a/meta/recipes-core/glibc/glibc.inc 
> b/meta/recipes-core/glibc/glibc.inc
> index 91491a35f0..e673707369 100644
> --- a/meta/recipes-core/glibc/glibc.inc
> +++ b/meta/recipes-core/glibc/glibc.inc
> @@ -6,18 +6,6 @@ STAGINGCC = "gcc-cross-initial-${TARGET_ARCH}"
>  STAGINGCC_class-nativesdk = "gcc-crosssdk-initial-${SDK_SYS}"
>  PATH_prepend = "${STAGING_BINDIR_TOOLCHAIN}.${STAGINGCC}:"
>
> -python () {
> -opt_effective = "-O"
> -for opt in d.getVar('SELECTED_OPTIMIZATION').split():
> -if opt in ("-O0", "-O", "-O1", "-O2", "-O3", "-Os"):
> -opt_effective = opt
> -if opt_effective == "-O0":
> -bb.fatal("%s can't be built with %s, try -O1 instead" % 
> (d.getVar('PN'), opt_effective))
> -if opt_effective in ("-O", "-O1", "-Os"):
> -bb.note("%s doesn't build cleanly with %s, adding -Wno-error to 
> SELECTED_OPTIMIZATION" % (d.getVar('PN'), opt_effective))
> -d.appendVar("SELECTED_OPTIMIZATION", " -Wno-error")
> -}
> -
>  # siteconfig.bbclass runs configure which needs a working compiler
>  # For the compiler to work we need a working libc yet libc isn't
>  # in the sysroots directory at this point. This means the libc.so
> diff --git 
> a/meta/recipes-core/glibc/glibc/0031-sysdeps-ieee754-prevent-maybe-uninitialized-errors.patch
>  
> b/meta/recipes-core/glibc/glibc/0031-sysdeps-ieee754-prevent-maybe-uninitialized-errors.patch
> new file mode 100644
> index 00..d9d36b8244
> --- /dev/null
> +++ 
> b/meta/recipes-core/glibc/glibc/0031-sysdeps-ieee754-prevent-maybe-uninitialized-errors.patch
> @@ -0,0 +1,95 @@
> +From c6cc5a6ef46837e341fe271b5ffa6def23810082 Mon Sep 17 00:00:00 2001
> +From: Martin Jansa 
> +Date: Fri, 14 Sep 2018 23:23:03 +
> +Subject: [PATCH] sysdeps/ieee754: prevent maybe-uninitialized errors
> +
> +* with -O included in BUILD_OPTIMIZATION when DEBUG_BUILD
> +  is used, nativesdk-glibc fails with:
> +../sysdeps/ieee754/ldbl-96/e_jnl.c: In function '__ieee754_jnl':
> +../sysdeps/ieee754/ldbl-96/e_jnl.c:146:20: error: 'temp' may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
> +  b = invsqrtpi * temp / sqrtl (x);
> +  ~~^~
> +../sysdeps/ieee754/ldbl-96/e_jnl.c: In function '__ieee754_ynl':
> +../sysdeps/ieee754/ldbl-96/e_jnl.c:375:16: error: 'temp' may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
> +  b = invsqrtpi * temp / sqrtl (x);
> +  ~~^~
> +
> +* work around the issue instead of removing -O like we do with
> +  SELECTED_OPTIMIZATION
> +
> +Upstream-Status: Pending
> +
> +Signed-off-by: Martin Jansa 
> +---
> + sysdeps/ieee754/dbl-64/e_jn.c| 2 ++
> + sysdeps/ieee754/ldbl-128/e_jnl.c | 4 
> + sysdeps/ieee754/ldbl-96/e_jnl.c  | 4 
> + 3 files changed, 10 insertions(+)
> +
> +diff --git a/sysdeps/ieee754/dbl-64/e_jn.c b/sysdeps/ieee754/dbl-64/e_jn.c
> +index 9181b22bb8..74a6b5f149 100644
> +--- a/sysdeps/ieee754/dbl-64/e_jn.c
>  b/sysdeps/ieee754/dbl-64/e_jn.c
> +@@ -108,6 +108,7 @@ __ieee754_jn (int n, double x)
> + case 1: temp = -c + s; break;
> + case 2: temp = -c - s; break;
> + case 3: temp = c - s; break;
> ++default: temp = 0; // just to prevent error: 'temp' may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
> + }
> +   b = invsqrtpi * temp / sqrt (x);
> + }
> +@@ -315,6 +316,7 @@ __ieee754_yn (int n, double x)
> + case 1: temp = -s - c; break;
> + case 2: temp = -s + c; break;
> + case 3: temp = s + c; break;
> ++default: temp = 0; // just to prevent error: 'temp' may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
> + }
> +   b = invsqrtpi * temp / sqrt (x);
> +   }
> +diff --git a/sysdeps/ieee754/ldbl-128/e_jnl.c 
> b/sysdeps/ieee754/ldbl-128/e_jnl.c
> +index 7739eec291..b6a1275464 100644
> +--- a/sysdeps/ieee754/ldbl-128/e_jnl.c
>  b/sysdeps/ieee754/ldbl-128/e_jnl.c
> +@@ -149,6 +149,8 @@ __ieee754_jnl (int n, _Float128 x)
> + case 3:
> +   temp = c - s;
> +   break;
> ++default:
> ++   

Re: [OE-core] [PATCH] openssh: upgrade 7.8p1 -> 7.8p2 to support openssl 1.1.x

[Khem Raj]

On Tue, Sep 18, 2018 at 8:12 PM Hongxu Jia  wrote:
>
> - Convert from tarball to git repository which support
>   openssl 1.1.x
>
> - There is no specific minor version that contains the
>   openssl fix (it was merged to master a few days agao),
>   but their next minor version will be p2.
>

I think we should test this patch and it would be good to get this in release

> Signed-off-by: Hongxu Jia 
> ---
>  .../openssh/{openssh_7.8p1.bb => openssh_7.8p2.bb} | 10 
> +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>  rename meta/recipes-connectivity/openssh/{openssh_7.8p1.bb => 
> openssh_7.8p2.bb} (94%)
>
> diff --git a/meta/recipes-connectivity/openssh/openssh_7.8p1.bb 
> b/meta/recipes-connectivity/openssh/openssh_7.8p2.bb
> similarity index 94%
> rename from meta/recipes-connectivity/openssh/openssh_7.8p1.bb
> rename to meta/recipes-connectivity/openssh/openssh_7.8p2.bb
> index f4b295f..b74461e 100644
> --- a/meta/recipes-connectivity/openssh/openssh_7.8p1.bb
> +++ b/meta/recipes-connectivity/openssh/openssh_7.8p2.bb
> @@ -8,11 +8,10 @@ SECTION = "console/network"
>  LICENSE = "BSD"
>  LIC_FILES_CHKSUM = "file://LICENCE;md5=429658c6612f3a9b1293782366ab29d8"
>
> -# openssl 1.1 patches are proposed at 
> https://github.com/openssh/openssh-portable/pull/48
> -DEPENDS = "zlib openssl10"
> +DEPENDS = "zlib openssl"
>  DEPENDS += "${@bb.utils.contains('DISTRO_FEATURES', 'pam', 'libpam', '', d)}"
>
> -SRC_URI = 
> "http://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-${PV}.tar.gz \
> +SRC_URI = "git://github.com/openssh/openssh-portable;branch=master \
> file://sshd_config \
> file://ssh_config \
> file://init \
> @@ -29,8 +28,9 @@ SRC_URI = 
> "http://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-${PV}.tar
>
>  PAM_SRC_URI = "file://sshd"
>
> -SRC_URI[md5sum] = "ce1d090fa6239fd38eb989d5e983b074"
> -SRC_URI[sha256sum] = 
> "1a484bb15152c183bb2514e112aa30dd34138c3cfb032eee5490a66c507144ca"
> +SRCREV = "cce8cbe0ed7d1ba3a575310e0b63c193326ae616"
> +
> +S = "${WORKDIR}/git"
>
>  inherit useradd update-rc.d update-alternatives systemd
>
> --
> 2.7.4
>
> --
> ___
> 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] mesa: enable virgl driver for qemux86/qemux86-64

[liu . ming50]

From: Ming Liu 

virgl driver should be enabled for qemux86/qemux86-64 machines, or else
it will cause runtime issue due to virtio_gpu driver missing.

Signed-off-by: Ming Liu 
---
 meta/recipes-graphics/mesa/mesa.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index 5afd0db..8d0e2cb 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -91,6 +91,8 @@ GALLIUMDRIVERS_LLVM33_ENABLED = 
"${@oe.utils.version_less_or_equal('MESA_LLVM_RE
 GALLIUMDRIVERS_LLVM = "r300,svga,nouveau${@',${GALLIUMDRIVERS_LLVM33}' if 
${GALLIUMDRIVERS_LLVM33_ENABLED} else ''}"
 GALLIUMDRIVERS_append_x86 = "${@bb.utils.contains('PACKAGECONFIG', 
'gallium-llvm', ',${GALLIUMDRIVERS_LLVM}', '', d)}"
 GALLIUMDRIVERS_append_x86-64 = "${@bb.utils.contains('PACKAGECONFIG', 
'gallium-llvm', ',${GALLIUMDRIVERS_LLVM}', '', d)}"
+GALLIUMDRIVERS_append_qemux86 = ",virgl"
+GALLIUMDRIVERS_append_qemux86-64 = ",virgl"
 # keep --with-gallium-drivers separate, because when only one of gallium 
versions is enabled, other 2 were adding --without-gallium-drivers
 PACKAGECONFIG[gallium]  = "--enable-texture-float 
--with-gallium-drivers=${GALLIUMDRIVERS}, --without-gallium-drivers"
 MESA_LLVM_RELEASE ?= "6.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] openssh: upgrade 7.8p1 -> 7.8p2 to support openssl 1.1.x

[Hongxu Jia]

There are 36 commits since 7.8p1, and 4 of them about openssl 1.1.x fix

git log --oneline V_7_8_P1..master | grep openssl
cce8cbe Fix openssl-1.1 fallout for --without-openssl.
a3fd807 upstream: missed a bit of openssl-1.0.x API in this unittest
86e0a9f upstream: use only openssl-1.1.x API here too
482d23b upstream: hold our collective noses and use the openssl-1.1.x API in

That's the reason to upgrade rather than backport

//Hongxu

On 2018年09月19日 11:22, Hongxu Jia wrote:

- Convert from tarball to git repository which support
   openssl 1.1.x

- There is no specific minor version that contains the
   openssl fix (it was merged to master a few days agao),
   but their next minor version will be p2.

Signed-off-by: Hongxu Jia 
---
  .../openssh/{openssh_7.8p1.bb => openssh_7.8p2.bb} | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)
  rename meta/recipes-connectivity/openssh/{openssh_7.8p1.bb => 
openssh_7.8p2.bb} (94%)

diff --git a/meta/recipes-connectivity/openssh/openssh_7.8p1.bb 
b/meta/recipes-connectivity/openssh/openssh_7.8p2.bb
similarity index 94%
rename from meta/recipes-connectivity/openssh/openssh_7.8p1.bb
rename to meta/recipes-connectivity/openssh/openssh_7.8p2.bb
index f4b295f..b74461e 100644
--- a/meta/recipes-connectivity/openssh/openssh_7.8p1.bb
+++ b/meta/recipes-connectivity/openssh/openssh_7.8p2.bb
@@ -8,11 +8,10 @@ SECTION = "console/network"
  LICENSE = "BSD"
  LIC_FILES_CHKSUM = "file://LICENCE;md5=429658c6612f3a9b1293782366ab29d8"
  
-# openssl 1.1 patches are proposed at https://github.com/openssh/openssh-portable/pull/48

-DEPENDS = "zlib openssl10"
+DEPENDS = "zlib openssl"
  DEPENDS += "${@bb.utils.contains('DISTRO_FEATURES', 'pam', 'libpam', '', d)}"
  
-SRC_URI = "http://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-${PV}.tar.gz \

+SRC_URI = "git://github.com/openssh/openssh-portable;branch=master \
 file://sshd_config \
 file://ssh_config \
 file://init \
@@ -29,8 +28,9 @@ SRC_URI = 
"http://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-${PV}.tar
  
  PAM_SRC_URI = "file://sshd"
  
-SRC_URI[md5sum] = "ce1d090fa6239fd38eb989d5e983b074"

-SRC_URI[sha256sum] = 
"1a484bb15152c183bb2514e112aa30dd34138c3cfb032eee5490a66c507144ca"
+SRCREV = "cce8cbe0ed7d1ba3a575310e0b63c193326ae616"
+
+S = "${WORKDIR}/git"
  
  inherit useradd update-rc.d update-alternatives systemd
  



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

[OE-core] [PATCH] openssh: upgrade 7.8p1 -> 7.8p2 to support openssl 1.1.x

[Hongxu Jia]

- Convert from tarball to git repository which support
  openssl 1.1.x

- There is no specific minor version that contains the
  openssl fix (it was merged to master a few days agao),
  but their next minor version will be p2.

Signed-off-by: Hongxu Jia 
---
 .../openssh/{openssh_7.8p1.bb => openssh_7.8p2.bb} | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)
 rename meta/recipes-connectivity/openssh/{openssh_7.8p1.bb => 
openssh_7.8p2.bb} (94%)

diff --git a/meta/recipes-connectivity/openssh/openssh_7.8p1.bb 
b/meta/recipes-connectivity/openssh/openssh_7.8p2.bb
similarity index 94%
rename from meta/recipes-connectivity/openssh/openssh_7.8p1.bb
rename to meta/recipes-connectivity/openssh/openssh_7.8p2.bb
index f4b295f..b74461e 100644
--- a/meta/recipes-connectivity/openssh/openssh_7.8p1.bb
+++ b/meta/recipes-connectivity/openssh/openssh_7.8p2.bb
@@ -8,11 +8,10 @@ SECTION = "console/network"
 LICENSE = "BSD"
 LIC_FILES_CHKSUM = "file://LICENCE;md5=429658c6612f3a9b1293782366ab29d8"
 
-# openssl 1.1 patches are proposed at 
https://github.com/openssh/openssh-portable/pull/48
-DEPENDS = "zlib openssl10"
+DEPENDS = "zlib openssl"
 DEPENDS += "${@bb.utils.contains('DISTRO_FEATURES', 'pam', 'libpam', '', d)}"
 
-SRC_URI = 
"http://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-${PV}.tar.gz \
+SRC_URI = "git://github.com/openssh/openssh-portable;branch=master \
file://sshd_config \
file://ssh_config \
file://init \
@@ -29,8 +28,9 @@ SRC_URI = 
"http://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-${PV}.tar
 
 PAM_SRC_URI = "file://sshd"
 
-SRC_URI[md5sum] = "ce1d090fa6239fd38eb989d5e983b074"
-SRC_URI[sha256sum] = 
"1a484bb15152c183bb2514e112aa30dd34138c3cfb032eee5490a66c507144ca"
+SRCREV = "cce8cbe0ed7d1ba3a575310e0b63c193326ae616"
+
+S = "${WORKDIR}/git"
 
 inherit useradd update-rc.d update-alternatives systemd
 
-- 
2.7.4

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

[OE-core] [PATCH V3] gdb: gdbserver: update ctrl-c handling

[Zhixiong Chi]

A) gdbserver sends SIGINT not to the process, but to the process
group (-signal_pid). But the attached process is not always a
process group leader. If not, "kill (-signal_pid, SIGINT)" returns
error and fails to interrupt the attached process. We cannot interrupt
the process attached with gdbserver who is not a process group leader.

This problem was created by the gdb upstream commit 78708b7c8c
The commit fixed the following case B) bug.
B) We cannot interrupt the process attached with gdbserver whose
main thread exits (pthread_exit()).

Now this patch can solve both A) and B).

Signed-off-by: Zhixiong Chi 
---
 meta/recipes-devtools/gdb/gdb-8.2.inc |  1 +
 .../gdb/gdb/gdbserver-ctrl-c-handling.patch   | 26 +++
 2 files changed, 27 insertions(+)
 create mode 100644 
meta/recipes-devtools/gdb/gdb/gdbserver-ctrl-c-handling.patch

diff --git a/meta/recipes-devtools/gdb/gdb-8.2.inc 
b/meta/recipes-devtools/gdb/gdb-8.2.inc
index 999fdde031..dfb0059123 100644
--- a/meta/recipes-devtools/gdb/gdb-8.2.inc
+++ b/meta/recipes-devtools/gdb/gdb-8.2.inc
@@ -16,6 +16,7 @@ SRC_URI = "http://ftp.gnu.org/gnu/gdb/gdb-${PV}.tar.xz \
file://0009-Change-order-of-CFLAGS.patch \
file://0010-resolve-restrict-keyword-conflict.patch \
file://0011-Fix-invalid-sigprocmask-call.patch \
+   file://gdbserver-ctrl-c-handling.patch \
 "
 SRC_URI[md5sum] = "b5a49dbff00d9a87fbe114d14b3101c0"
 SRC_URI[sha256sum] = 
"c3a441a29c7c89720b734e5a9c6289c0a06be7e0c76ef538f7bbcef389347c39"
diff --git a/meta/recipes-devtools/gdb/gdb/gdbserver-ctrl-c-handling.patch 
b/meta/recipes-devtools/gdb/gdb/gdbserver-ctrl-c-handling.patch
new file mode 100644
index 00..d1ff5a5d75
--- /dev/null
+++ b/meta/recipes-devtools/gdb/gdb/gdbserver-ctrl-c-handling.patch
@@ -0,0 +1,25 @@
++This problem was created by the upstream commit 78708b7c8c
++After applying the commit, it will send SIGINT to the process 
group(-signal_pid).
++But if we use gdbserver send SIGINT, and the attached process is not a process
++group leader, then the "kill (-signal_pid, SIGINT)" returns error and fails  
to
++interrupt the attached process.
++
++Upstream-Status: Submitted 
[https://sourceware.org/bugzilla/show_bug.cgi?id=18945]
++
++Author: Josh Gao
++Signed-off-by: Zhixiong Chi 
+Index: gdb-8.2/gdb/gdbserver/linux-low.c
+===
+--- gdb-8.2.orig/gdb/gdbserver/linux-low.c
 gdb-8.2/gdb/gdbserver/linux-low.c
+@@ -5940,9 +5940,7 @@ linux_look_up_symbols (void)
+ static void
+ linux_request_interrupt (void)
+ {
+-  /* Send a SIGINT to the process group.  This acts just like the user
+- typed a ^C on the controlling terminal.  */
+-  kill (-signal_pid, SIGINT);
++  kill (signal_pid, SIGINT);
+ }
+ 
+ /* Copy LEN bytes from inferior's auxiliary vector starting at OFFSET
-- 
2.17.1

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

[OE-core] ✗ patchtest: failure for gdb: gdbserver: update ctrl-c handling (rev2)

[Patchwork]

== Series Details ==

Series: gdb: gdbserver: update ctrl-c handling (rev2)
Revision: 2
URL   : https://patchwork.openembedded.org/series/14110/
State : failure

== Summary ==


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



* Issue Upstream-Status is Submitted, but it is not mentioned where 
[test_upstream_status_presence_format] 
  Suggested fixInclude where gdbserver-ctrl-c-handling.patch was submitted
  Current  Upstream-Status: Submitted
  Standard format  Upstream-Status: Submitted [where]



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

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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

Re: [OE-core] [PATCH] gdb: gdbserver: update ctrl-c handling

[Zhixiong Chi]

On 2018年09月18日 18:10, Burton, Ross wrote:

On Tue, 18 Sep 2018 at 10:01, Zhixiong Chi  wrote:

++Upstream-Status: Pending
++cherry-picked patch from https://sourceware.org/bugzilla/show_bug.cgi?id=18945

Sounds like the status should be:

Upstream-Status: Submitted
[https://sourceware.org/bugzilla/show_bug.cgi?id=18945]

Thanks for your reminder, I will send the V2.

Zhixiong.


Ross

Ross


--
-
Thanks,
Zhixiong Chi
Tel: +86-10-8477-7036

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

[OE-core] [PATCH V2] gdb: gdbserver: update ctrl-c handling

[Zhixiong Chi]

A) gdbserver sends SIGINT not to the process, but to the process
group (-signal_pid). But the attached process is not always a
process group leader. If not, "kill (-signal_pid, SIGINT)" returns
error and fails to interrupt the attached process. We cannot interrupt
the process attached with gdbserver who is not a process group leader.

This problem was created by the gdb upstream commit 78708b7c8c
The commit fixed the following case B) bug.
B) We cannot interrupt the process attached with gdbserver whose
main thread exits (pthread_exit()).

Now this patch can solve both A) and B).

Signed-off-by: Zhixiong Chi 
---
 meta/recipes-devtools/gdb/gdb-8.2.inc |  1 +
 .../gdb/gdb/gdbserver-ctrl-c-handling.patch   | 26 +++
 2 files changed, 27 insertions(+)
 create mode 100644 
meta/recipes-devtools/gdb/gdb/gdbserver-ctrl-c-handling.patch

diff --git a/meta/recipes-devtools/gdb/gdb-8.2.inc 
b/meta/recipes-devtools/gdb/gdb-8.2.inc
index 999fdde031..dfb0059123 100644
--- a/meta/recipes-devtools/gdb/gdb-8.2.inc
+++ b/meta/recipes-devtools/gdb/gdb-8.2.inc
@@ -16,6 +16,7 @@ SRC_URI = "http://ftp.gnu.org/gnu/gdb/gdb-${PV}.tar.xz \
file://0009-Change-order-of-CFLAGS.patch \
file://0010-resolve-restrict-keyword-conflict.patch \
file://0011-Fix-invalid-sigprocmask-call.patch \
+   file://gdbserver-ctrl-c-handling.patch \
 "
 SRC_URI[md5sum] = "b5a49dbff00d9a87fbe114d14b3101c0"
 SRC_URI[sha256sum] = 
"c3a441a29c7c89720b734e5a9c6289c0a06be7e0c76ef538f7bbcef389347c39"
diff --git a/meta/recipes-devtools/gdb/gdb/gdbserver-ctrl-c-handling.patch 
b/meta/recipes-devtools/gdb/gdb/gdbserver-ctrl-c-handling.patch
new file mode 100644
index 00..d1ff5a5d75
--- /dev/null
+++ b/meta/recipes-devtools/gdb/gdb/gdbserver-ctrl-c-handling.patch
@@ -0,0 +1,26 @@
++This problem was created by the upstream commit 78708b7c8c
++After applying the commit, it will send SIGINT to the process 
group(-signal_pid).
++But if we use gdbserver send SIGINT, and the attached process is not a process
++group leader, then the "kill (-signal_pid, SIGINT)" returns error and fails  
to
++interrupt the attached process.
++
++Upstream-Status: Submitted
++[https://sourceware.org/bugzilla/show_bug.cgi?id=18945]
++
++Author: Josh Gao
++Signed-off-by: Zhixiong Chi 
+Index: gdb-8.2/gdb/gdbserver/linux-low.c
+===
+--- gdb-8.2.orig/gdb/gdbserver/linux-low.c
 gdb-8.2/gdb/gdbserver/linux-low.c
+@@ -5940,9 +5940,7 @@ linux_look_up_symbols (void)
+ static void
+ linux_request_interrupt (void)
+ {
+-  /* Send a SIGINT to the process group.  This acts just like the user
+- typed a ^C on the controlling terminal.  */
+-  kill (-signal_pid, SIGINT);
++  kill (signal_pid, SIGINT);
+ }
+ 
+ /* Copy LEN bytes from inferior's auxiliary vector starting at OFFSET
-- 
2.17.1

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

Re: [OE-core] [PATCH 00/10] Introduce ARC port of OpenEmbedded

[Khem Raj]

On Mon, Sep 17, 2018 at 2:29 PM Alexey Brodkin 
wrote:

> DesignWare ARC Processors are a family of 32-bit CPUs from Synopsys.
> This series introduces basic support for ARC architecture in
> OpenEmbedded.


Thanks for the contributions

>
>
> As of today latest upstream GCC and Binutils are perfectly usable
> for building packages for ARC so we just need a couple of fixes.


These fixes look primarily ok you might have to
Address the little tweaks I asked

>
>
> Glibc for ARC is under review and we're working hard to get it
> accepted in the next upstream release. For now we'll use latest
> code-base back-ported on top of 2.28 release via meta-synopsys.
>
> Its fine once it’s upstreamed we can then get the support into core via
normal recipe updates


More platform and architecture specific bits could be found in
> meta-synopsys layer here (please refer to the "master" branch):
> https://github.com/foss-for-synopsys-dwc-arc-processors/meta-synopsys
>
> Alexey Brodkin (8):
>   siteinfo: Define data for ARC
>   site: Add ARC linux
>   kernel-arch.bbclass: Add ARC to kernel arch map
>   openssl: Add support for ARC
>   icu: Add ARC support
>   gcc: Disable libitm for ARC
>   binutils: Fix Glibc building for ARC
>   gcc: Fix specs generation for ARC
>
> Antoine Tenart (1):
>   nspr: Add ARC support
>
> Mylene Josserand (1):
>   libgpg-error: Add ARC support
>
>  meta/classes/kernel-arch.bbclass   |   1 +
>  meta/classes/siteinfo.bbclass  |   2 +
>  .../openssl/openssl10_1.0.2p.bb|   2 +-
>  .../openssl/openssl_1.1.1-pre9.bb  |   2 +-
>  meta/recipes-devtools/binutils/binutils-2.31.inc   |   4 +
>  ...location-where-GOT-information-is-collect.patch | 198
> +
>  ...bustness.-Return-FALSE-in-case-of-NULL-po.patch |  35 
>  ...lobal-symbol-is-not-an-indirect-or-warnin.patch |  43 +
>  ...tion-was-still-being-generated-when-symbo.patch |  37 
>  meta/recipes-devtools/gcc/gcc-8.2.inc  |   1 +
>  .../gcc/gcc-8.2/0041-ARC-fix-spec-gen.patch|  40 +
>  meta/recipes-devtools/gcc/gcc-runtime.inc  |   1 +
>  .../icu/icu/0002-Add-ARC-support.patch |  25 +++
>  meta/recipes-support/icu/icu_62.1.bb   |   1 +
>  .../0001-syscfg-Add-an-arc-architecture.patch  |  75 
>  .../libgpg-error/libgpg-error_1.32.bb  |   1 +
>  .../nspr/nspr/0004-Add-ARC-support.patch   |  86 +
>  meta/recipes-support/nspr/nspr_4.19.bb |   1 +
>  meta/site/arc-linux|  11 ++
>  19 files changed, 564 insertions(+), 2 deletions(-)
>  create mode 100644
> meta/recipes-devtools/binutils/binutils/0018-Refactored-location-where-GOT-information-is-collect.patch
>  create mode 100644
> meta/recipes-devtools/binutils/binutils/0019-Improved-robustness.-Return-FALSE-in-case-of-NULL-po.patch
>  create mode 100644
> meta/recipes-devtools/binutils/binutils/0020-Make-sure-global-symbol-is-not-an-indirect-or-warnin.patch
>  create mode 100644
> meta/recipes-devtools/binutils/binutils/0021-PLT-information-was-still-being-generated-when-symbo.patch
>  create mode 100644
> meta/recipes-devtools/gcc/gcc-8.2/0041-ARC-fix-spec-gen.patch
>  create mode 100644 meta/recipes-support/icu/icu/0002-Add-ARC-support.patch
>  create mode 100644
> meta/recipes-support/libgpg-error/libgpg-error/0001-syscfg-Add-an-arc-architecture.patch
>  create mode 100644
> meta/recipes-support/nspr/nspr/0004-Add-ARC-support.patch
>  create mode 100644 meta/site/arc-linux
>
> --
> 1.8.3.1
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 01/10] siteinfo: Define data for ARC

[Khem Raj]

On Mon, Sep 17, 2018 at 2:29 PM Alexey Brodkin 
wrote:

> Signed-off-by: Alexey Brodkin 
> ---
>  meta/classes/siteinfo.bbclass | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/meta/classes/siteinfo.bbclass b/meta/classes/siteinfo.bbclass
> index 86bb853b..dccf122 100644
> --- a/meta/classes/siteinfo.bbclass
> +++ b/meta/classes/siteinfo.bbclass
> @@ -20,6 +20,8 @@ def siteinfo_data(d):
>  "allarch": "endian-little bit-32", # bogus, but better than
> special-casing the checks below for allarch
>  "aarch64": "endian-little bit-64 arm-common arm-64",
>  "aarch64_be": "endian-big bit-64 arm-common arm-64",
> +"arc": "endian-little bit-32 arc-common",
> +"arceb": "endian-big bit-32 arc-common",


Probably need to add arc-common file as well
Since it’s used here

>
>  "arm": "endian-little bit-32 arm-common arm-32",
>  "armeb": "endian-big bit-32 arm-common arm-32",
>  "avr32": "endian-big bit-32 avr32-common",
> --
> 1.8.3.1
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 10/10] gcc: Fix specs generation for ARC

[Khem Raj]

On Mon, Sep 17, 2018 at 2:30 PM Alexey Brodkin 
wrote:

> GCC's built-in spec for LD is missing a space after
> "--eh-frame-hdr" thus with the next option merged together they
> are not understood by LD and so LD fails.
>
> Back-port from upstream GCC, see:
>
> https://github.com/gcc-mirror/gcc/commit/892142379c6b99fe8c3ebdfe0b79e2a435228c1d
>

Can you add this to
Upstream-Status tag in patch file itself

>
> Signed-off-by: Alexey Brodkin 
> ---
>  meta/recipes-devtools/gcc/gcc-8.2.inc  |  1 +
>  .../gcc/gcc-8.2/0041-ARC-fix-spec-gen.patch| 40
> ++
>  2 files changed, 41 insertions(+)
>  create mode 100644
> meta/recipes-devtools/gcc/gcc-8.2/0041-ARC-fix-spec-gen.patch
>
> diff --git a/meta/recipes-devtools/gcc/gcc-8.2.inc
> b/meta/recipes-devtools/gcc/gcc-8.2.inc
> index 889187e..866a775 100644
> --- a/meta/recipes-devtools/gcc/gcc-8.2.inc
> +++ b/meta/recipes-devtools/gcc/gcc-8.2.inc
> @@ -69,6 +69,7 @@ SRC_URI = "\
>
> file://0038-fix-segmentation-fault-in-precompiled-header-generat.patch \
> file://0039-Fix-for-testsuite-failure.patch \
> file://0040-Re-introduce-spe-commandline-options.patch \
> +   file://0041-ARC-fix-spec-gen.patch \
> ${BACKPORTS} \
>  "
>  BACKPORTS = "\
> diff --git a/meta/recipes-devtools/gcc/gcc-8.2/0041-ARC-fix-spec-gen.patch
> b/meta/recipes-devtools/gcc/gcc-8.2/0041-ARC-fix-spec-gen.patch
> new file mode 100644
> index 000..d746d79
> --- /dev/null
> +++ b/meta/recipes-devtools/gcc/gcc-8.2/0041-ARC-fix-spec-gen.patch
> @@ -0,0 +1,40 @@
> +From 892142379c6b99fe8c3ebdfe0b79e2a435228c1d Mon Sep 17 00:00:00 2001
> +From: claziss 
> +Date: Mon, 17 Sep 2018 08:52:10 +
> +Subject: [PATCH] [ARC] Update LINK_EH_SPEC linker spec.
> +
> +With no trailing space in LINK_EH_SPEC linker spec gets generated as:
> +>8-
> +%{!r:--build-id} --eh-frame-hdr%{h*} ...
> +>8-
> +
> +or even worse if hash style is added:
> +>8-
> +%{!r:--build-id} --eh-frame-hdr--hash-style=sysv %{h*} ...
> +>8-
> +
> +Now if that spec is really used by LD then it fails inevitably
> +saying that it doesn't know option "--eh-frame-hdr--hash-style=sysv".
> +
> +2018-09-17  Alexey Brodkin  
> +
> +   * config/arc/linux.h (LINK_EH_SPEC): Add missing space.
> +
> +git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@264361
> 138bc75d-0d04-0410-961f-82ee72b054a4
> +---
> + gcc/config/arc/linux.h | 2 +-
> + 1 files changed, 1 insertions(+), 1 deletion(-)
> +
> +diff --git a/gcc/config/arc/linux.h b/gcc/config/arc/linux.h
> +index 96d548eae341..62ebe4de0fc7 100644
> +--- a/gcc/config/arc/linux.h
>  b/gcc/config/arc/linux.h
> +@@ -98,7 +98,7 @@ along with GCC; see the file COPYING3.  If not see
> +Signalize that because we have fde-glibc, we don't need all C shared
> libs
> +linked against -lgcc_s.  */
> + #undef LINK_EH_SPEC
> +-#define LINK_EH_SPEC "--eh-frame-hdr"
> ++#define LINK_EH_SPEC "--eh-frame-hdr "
> + #endif
> +
> + #undef SUBTARGET_CPP_SPEC
> --
> 1.8.3.1
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] kernel-uimage.bbclass: Dependency on u-boot-mkimage-native for all uImages

[Reto Schneider]

From: Reto Schneider 

u-boot-mkimage-native is needed to build any type of uImages, be it
the uImage target itself or for example uImage.lzma. The dependency
however gets only added when at least one of KERNEL_IMAGETYPE and
KERNEL_ALT_IMAGETYPE is exactly uImage. Building uImage.bin and uImage.lzma is
not possible this way.

This patch adds a dependency to u-boot-mkimage-native for all imagetypes which
contains the string uImage.

Signed-off-by: Reto Schneider 
---
 meta/classes/kernel-uimage.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/kernel-uimage.bbclass 
b/meta/classes/kernel-uimage.bbclass
index 1d8656e76e..c2de6bb40d 100644
--- a/meta/classes/kernel-uimage.bbclass
+++ b/meta/classes/kernel-uimage.bbclass
@@ -1,7 +1,7 @@
 inherit kernel-uboot
 
 python __anonymous () {
-if "uImage" in (d.getVar('KERNEL_IMAGETYPES') or "").split():
+if "uImage" in d.getVar('KERNEL_IMAGETYPES'):
 depends = d.getVar("DEPENDS")
 depends = "%s u-boot-mkimage-native" % depends
 d.setVar("DEPENDS", depends)
-- 
2.11.0

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

Re: [OE-core] [PATCH] connman: update to 1.36

[Oleksandr Kravchuk]

Sorry for the delay. This patch hasn't really been changed much: it was
simply rebased, renamed and converted into git format. Would it be
enough to keep it the way it is and describe the changes in the commit
message?

On 13/09/2018 23:38, Alexander Kanavin wrote:
> This one:
> rename meta/recipes-connectivity/connman/connman/{includes.patch =>
> 0001-Use-AC_USE_SYSTEM_EXTENSIONS.patch} (68%)
>
> I think you should make two commits: one that splits this patch in
> three, and another which actually does the version update.
>
> Alex
>
> 2018-09-13 23:08 GMT+02:00 Oleksandr Kravchuk
> :
>> Sure, will do.
>>
 Also, one patch is changed in a way that makes it lose significant amount
 of information (it's an amalgamation of three patches)
>> Could you please clarify which one do you mean? Thank you.
>>
>>
>> On 9/13/18 9:46 PM, Alexander Kanavin wrote:
>>> Please explain the changes to patches (not as a reply to me, but in
>>> the commit message itself).
>>> If they are deleted because upstream already has them, it should be
>>> mentioned explicitly.
>>>
>>> Also, one patch is changed in a way that makes it lose significant
>>> amount of information
>>> (it's an amalgamation of three patches). Perhaps we should just split
>>> it in three?
>>>
>>> Alex
>>>
>>> 2018-09-13 21:04 GMT+02:00 Oleksandr Kravchuk
>>> :
 Signed-off-by: Oleksandr Kravchuk 
 ---
   meta/recipes-connectivity/connman/connman.inc |   2 +-
   ...> 0001-Use-AC_USE_SYSTEM_EXTENSIONS.patch} | 446 --
   ...tls-Fix-a-crash-using-wispr-over-TLS.patch |  41 --
   ...refixlen-to-iproute_default_function.patch |  63 ---
   ...eep-track-of-addr-in-fw_snat-session.patch | 112 -
   ...ubnet-route-creation-deletion-in-ipr.patch |  69 ---
   ...PIs-for-creating-and-deleting-subnet.patch |  68 ---
   ...net-route-creation-and-deletion-APIs.patch |  77 ---
   .../connman/connman_1.35.bb   |  22 -
   .../connman/connman_1.36.bb   |  17 +
   10 files changed, 212 insertions(+), 705 deletions(-)
   rename meta/recipes-connectivity/connman/connman/{includes.patch =>
 0001-Use-AC_USE_SYSTEM_EXTENSIONS.patch} (68%)
   delete mode 100644
 meta/recipes-connectivity/connman/connman/0001-giognutls-Fix-a-crash-using-wispr-over-TLS.patch
   delete mode 100644
 meta/recipes-connectivity/connman/connman/0001-inet-Add-prefixlen-to-iproute_default_function.patch
   delete mode 100644
 meta/recipes-connectivity/connman/connman/0001-session-Keep-track-of-addr-in-fw_snat-session.patch
   delete mode 100644
 meta/recipes-connectivity/connman/connman/0002-inet-Implement-subnet-route-creation-deletion-in-ipr.patch
   delete mode 100644
 meta/recipes-connectivity/connman/connman/0003-inet-Implement-APIs-for-creating-and-deleting-subnet.patch
   delete mode 100644
 meta/recipes-connectivity/connman/connman/0004-session-Use-subnet-route-creation-and-deletion-APIs.patch
   delete mode 100644 meta/recipes-connectivity/connman/connman_1.35.bb
   create mode 100644 meta/recipes-connectivity/connman/connman_1.36.bb

 diff --git a/meta/recipes-connectivity/connman/connman.inc
 b/meta/recipes-connectivity/connman/connman.inc
 index 2b03f9cb06..0ba375137d 100644
 --- a/meta/recipes-connectivity/connman/connman.inc
 +++ b/meta/recipes-connectivity/connman/connman.inc
 @@ -156,7 +156,7 @@ RDEPENDS_${PN}-client ="${PN}"

   FILES_${PN} = "${bindir}/* ${sbindir}/* ${libexecdir}/*
 ${libdir}/lib*.so.* \
   ${libdir}/connman/plugins \
 -${sysconfdir} ${sharedstatedir} ${localstatedir} \
 +${sysconfdir} ${sharedstatedir} ${localstatedir} ${datadir}
 \
   ${base_bindir}/* ${base_sbindir}/* ${base_libdir}/*.so*
 ${datadir}/${PN} \
   ${datadir}/dbus-1/system-services/* \
   ${sysconfdir}/tmpfiles.d/connman_resolvconf.conf"
 diff --git a/meta/recipes-connectivity/connman/connman/includes.patch
 b/meta/recipes-connectivity/connman/connman/0001-Use-AC_USE_SYSTEM_EXTENSIONS.patch
 similarity index 68%
 rename from meta/recipes-connectivity/connman/connman/includes.patch
 rename to
 meta/recipes-connectivity/connman/connman/0001-Use-AC_USE_SYSTEM_EXTENSIONS.patch
 index 55cb187931..e826bf002d 100644
 --- a/meta/recipes-connectivity/connman/connman/includes.patch
 +++
 b/meta/recipes-connectivity/connman/connman/0001-Use-AC_USE_SYSTEM_EXTENSIONS.patch
 @@ -1,36 +1,40 @@
 -Fix various issues which cause problems under musl.
 -
 -Upstream-Status: Submitted
 -Signed-off-by: Ross Burton 
 -
 -From 630516bcc0233b047f65665c003201ba6e77453d Mon Sep 17 00:00:00 2001
 +From 56fc228eebadc546d969a7073caf14d465ef3e5a Mon Sep 17 00:00:00 2001
   From: Ross Burton 
 -Date: Tue, 9 Aug 2016 16:22:36 +0100
 -Subject: [PATCH 

Re: [OE-core] [PATCH] openssh: build support openssl 1.1

[Randy MacLeod]

On 09/13/2018 08:27 AM, Alexander Kanavin wrote:
...


Good news everyone! Upstream openssh has finally gave into user
pressure, and added 1.1 support in the master branch. So the issue is
moot; we just need to wait for them to tag a release (no backports
please).
https://github.com/openssh/openssh-portable/commits/master

This will make oe-core entirely free of openssl10 dependencies.


Excellent.

Is there a planned release of openssh in the next day or
does someone need to switch to git or backport some/all of
the 36 post 7.8p1 commits for M3?

../Randy


$ git log --oneline V_7_8_P1...
cce8cbe0 Fix openssl-1.1 fallout for --without-openssl.
149519b9 add futex(2) syscall to seccomp sandbox
4488ae1a really add source for authopt_fuzz this time
9201784b remove accidentally checked-in authopt_fuzz binary
beb9e522 upstream:
   second try, deals properly with missing and private-only
6bc5a24a fuzzer harness for authorized_keys option parsing
6c8b82fc upstream: revert following; deals badly with agent keys
6da046f9 upstream: garbage-collect moribund ssh_new_private() API.
1f24ac5f upstream: Use consistent format in debug log for keys readied,
488c9325 upstream: Fix warnings caused by
user_from_uid() and group_from_gid()
0aa1f230 allow SIGUSR1 as synonym for SIGINFO
d64e7852 add compat header
a3fd8074 upstream: missed a bit of openssl-1.0.x API in this unittest
86e0a9f3 upstream: use only openssl-1.1.x API here too
48f54b9d adapt -portable to OpenSSL 1.1x API
86112951 forgot to stage these test files in commit d70d061
482d23bc upstream: hold our collective noses and
use the openssl-1.1.x API in
d70d0618 upstream: Include certs with multiple RSA signature variants in
f803b268 upstream: test revocation by explicit hash and by fingerprint
2de78bc7 upstream: s/sshkey_demote/sshkey_from_private/g
41c115a5 delete the correct thing; kexfuzz binary
f0fcd7e6 upstream: fix edit mistake; spotted by jmc@
4cc259ba upstream: add SSH_ALLOWED_CA_SIGALGS - the default list of
ba9e7883 upstream: add sshkey_check_cert_sigtype() that checks a
a70fd4ad upstream: add cert->signature_type field and
keep it in sync with
357128ac upstream: Add "ssh -Q sig" to allow listing supported signature
9405c621 upstream: allow key revocation by SHA256 hash and
allow ssh-keygen
50e2687e upstream: log certificate fingerprint in authentication
de37ca90 upstream: Add FALLTHROUGH comments where appropriate.
  Patch from
247766cd upstream: ssh -MM requires confirmation for all operations that
db8bb80e upstream: fix misplaced parenthesis inside if-clause.
  it's harmless
086cc614 upstream: fix build with DEBUG_PK enabled
26788330 Handle ngroups>_SC_NGROUPS_MAX.
039bf2a8 Initial len for the fmt=NULL case.
ea9c06e1 Include stdlib.h.
9617816d document some more regress control env variables

../Randy



Alex




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

[OE-core] [PATCH v2] isoimage-isohybrid: don't include cpio in cpio image

[Ioan-Adrian Ratiu]

Because the find | cpio processes execute in parallel connected via
the pipe, and the cpio outputs in the same dir find searches for
source files, the cpio will be included in itself partially, depending
on how fast the build machine creates the cpio file before cpio
gobbles it up.

This bloats the ISO image, though compression reduces the .iso file size,
once the kernel decompresses the cpio image and boots it live, it uses
up to double the RAM memory.

Fix this by creating the initrd.cpio file directly inside cr_workdir.

Signed-off-by: Ioan-Adrian Ratiu 
---
 scripts/lib/wic/plugins/source/isoimage-isohybrid.py | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/scripts/lib/wic/plugins/source/isoimage-isohybrid.py 
b/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
index 25a695da17..170077c22c 100644
--- a/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
+++ b/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
@@ -191,10 +191,9 @@ class IsoImagePlugin(SourcePlugin):
 else:
 raise WicError("Couldn't find or build initrd, exiting.")
 
-exec_cmd("cd %s && find . | cpio -o -H newc -R root:root 
>./initrd.cpio " \
-% initrd_dir, as_shell=True)
-exec_cmd("gzip -f -9 -c %s/initrd.cpio > %s" \
-% (initrd_dir, initrd), as_shell=True)
+exec_cmd("cd %s && find . | cpio -o -H newc -R root:root 
>%s/initrd.cpio " \
+ % (initrd_dir, cr_workdir), as_shell=True)
+exec_cmd("gzip -f -9 %s/initrd.cpio" % cr_workdir, as_shell=True)
 shutil.rmtree(initrd_dir)
 
 return initrd
-- 
2.19.0

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

[OE-core] [PATCH] isoimage-isohybrid: don't include cpio in cpio image

[Ioan-Adrian Ratiu]

Because the find | cpio processes execute in parallel connected via
the pipe, and the cpio outputs in the same dir find searches for
source files, the cpio will be included in itself partially, depending
on how fast the build machine creates the cpio file before cpio
gobbles it up.

This bloats the ISO image, though compression reduces the .iso file size,
once the kernel decompresses the cpio image and boots it live, it uses
up to double the RAM memory.

Fix this by creating the initrd.cpio file directly inside cr_workdir.

Signed-off-by: Ioan-Adrian Ratiu 
---
 scripts/lib/wic/plugins/source/isoimage-isohybrid.py | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/scripts/lib/wic/plugins/source/isoimage-isohybrid.py 
b/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
index 25a695da17..3006223cda 100644
--- a/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
+++ b/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
@@ -172,7 +172,6 @@ class IsoImagePlugin(SourcePlugin):
 
 if not initrd or not os.path.exists(initrd):
 # Create initrd from rootfs directory
-initrd = "%s/initrd.cpio.gz" % cr_workdir
 initrd_dir = "%s/INITRD" % cr_workdir
 shutil.copytree("%s" % rootfs_dir, \
 "%s" % initrd_dir, symlinks=True)
@@ -191,10 +190,9 @@ class IsoImagePlugin(SourcePlugin):
 else:
 raise WicError("Couldn't find or build initrd, exiting.")
 
-exec_cmd("cd %s && find . | cpio -o -H newc -R root:root 
>./initrd.cpio " \
-% initrd_dir, as_shell=True)
-exec_cmd("gzip -f -9 -c %s/initrd.cpio > %s" \
-% (initrd_dir, initrd), as_shell=True)
+exec_cmd("cd %s && find . | cpio -o -H newc -R root:root 
>%s/initrd.cpio " \
+ % (initrd_dir, cr_workdir), as_shell=True)
+exec_cmd("gzip -f -9 %s/initrd.cpio" % cr_workdir, as_shell=True)
 shutil.rmtree(initrd_dir)
 
 return initrd
-- 
2.19.0

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

[OE-core] [OE-Core][PATCH 4/4] kernel.bbclass: Avoid iterating over KERNEL_IMAGETYPES twice

[Alex Kiernan]

During deploy we iterate over KERNEL_IMAGETYPES twice, with no consumer
of our changes in the interim. Collapse these two loops into one.

Signed-off-by: Alex Kiernan 
---

 meta/classes/kernel.bbclass | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 396627e7efa1..d0fbbd19899b 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -669,20 +669,17 @@ kernel_do_deploy() {
for imageType in ${KERNEL_IMAGETYPES} ; do
base_name=${imageType}-${KERNEL_IMAGE_NAME}
install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType} 
$deployDir/${base_name}.bin
+   symlink_name=${imageType}-${KERNEL_IMAGE_LINK_NAME}
+   ln -sf ${base_name}.bin $deployDir/${symlink_name}.bin
+   ln -sf ${base_name}.bin $deployDir/${imageType}
done
+
if [ ${MODULE_TARBALL_DEPLOY} = "1" ] && (grep -q -i -e 
'^CONFIG_MODULES=y$' .config); then
mkdir -p ${D}${root_prefix}/lib
tar -cvzf $deployDir/modules-${MODULE_TARBALL_NAME}.tgz -C 
${D}${root_prefix} lib
ln -sf modules-${MODULE_TARBALL_NAME}.tgz 
$deployDir/modules-${MODULE_TARBALL_LINK_NAME}.tgz
fi
 
-   for imageType in ${KERNEL_IMAGETYPES} ; do
-   base_name=${imageType}-${KERNEL_IMAGE_NAME}
-   symlink_name=${imageType}-${KERNEL_IMAGE_LINK_NAME}
-   ln -sf ${base_name}.bin $deployDir/${symlink_name}.bin
-   ln -sf ${base_name}.bin $deployDir/${imageType}
-   done
-
if [ ! -z "${INITRAMFS_IMAGE}" -a x"${INITRAMFS_IMAGE_BUNDLE}" = x1 ]; 
then
for imageType in ${KERNEL_IMAGETYPES} ; do
initramfs_base_name=${imageType}-${INITRAMFS_NAME}
-- 
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 1/4] Revert "kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that."

[Alex Kiernan]

This reverts commit 65cded55fa96b1ba72149a31689c081ac27af7f7.

The fitImage deployed here is the one generated in kernel-fitimage.bbclass,
whereas the one deployed by kernel-fitimage.bbclass is a raw image, so we
need the one deployed here keeping.

Signed-off-by: Alex Kiernan 
---

 meta/classes/kernel.bbclass | 18 ++
 1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index bfb424396949..6b734be2b675 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -667,11 +667,8 @@ kernel_do_deploy() {
fi
 
for imageType in ${KERNEL_IMAGETYPES} ; do
-   # kernel-fitimage class deploys fitImages, skip here
-   if [ "$imageType" != "fitImage" ]; then
-   base_name=${imageType}-${KERNEL_IMAGE_NAME}
-   install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType} 
$deployDir/${base_name}.bin
-   fi
+   base_name=${imageType}-${KERNEL_IMAGE_NAME}
+   install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType} 
$deployDir/${base_name}.bin
done
if [ ${MODULE_TARBALL_DEPLOY} = "1" ] && (grep -q -i -e 
'^CONFIG_MODULES=y$' .config); then
mkdir -p ${D}/lib
@@ -688,13 +685,10 @@ kernel_do_deploy() {
 
if [ ! -z "${INITRAMFS_IMAGE}" -a x"${INITRAMFS_IMAGE_BUNDLE}" = x1 ]; 
then
for imageType in ${KERNEL_IMAGETYPES} ; do
-   # kernel-fitimage class deploys fitImages, skip here
-   if [ "$imageType" != "fitImage" ]; then
-   
initramfs_base_name=${imageType}-${INITRAMFS_NAME}
-   
initramfs_symlink_name=${imageType}-${INITRAMFS_LINK_NAME}
-   install -m 0644 
${KERNEL_OUTPUT_DIR}/${imageType}.initramfs 
$deployDir/${initramfs_base_name}.bin
-   ln -sf ${initramfs_base_name}.bin 
$deployDir/${initramfs_symlink_name}.bin
-   fi
+   initramfs_base_name=${imageType}-${INITRAMFS_NAME}
+   
initramfs_symlink_name=${imageType}-${INITRAMFS_LINK_NAME}
+   install -m 0644 
${KERNEL_OUTPUT_DIR}/${imageType}.initramfs 
$deployDir/${initramfs_base_name}.bin
+   ln -sf ${initramfs_base_name}.bin 
$deployDir/${initramfs_symlink_name}.bin
done
fi
 }
-- 
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 3/4] kernel: Fix modules tarball generation with usrmerge

[Alex Kiernan]

When usrmerge is enabled the kernel modules aren't under /lib, but /usr/lib;
ensure we fetch the modules from the correct location so we don't have a
tarball which consists of a single symlink.

Signed-off-by: Alex Kiernan 
---

 meta/classes/kernel.bbclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 6b734be2b675..396627e7efa1 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -671,8 +671,8 @@ kernel_do_deploy() {
install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType} 
$deployDir/${base_name}.bin
done
if [ ${MODULE_TARBALL_DEPLOY} = "1" ] && (grep -q -i -e 
'^CONFIG_MODULES=y$' .config); then
-   mkdir -p ${D}/lib
-   tar -cvzf $deployDir/modules-${MODULE_TARBALL_NAME}.tgz -C ${D} 
lib
+   mkdir -p ${D}${root_prefix}/lib
+   tar -cvzf $deployDir/modules-${MODULE_TARBALL_NAME}.tgz -C 
${D}${root_prefix} lib
ln -sf modules-${MODULE_TARBALL_NAME}.tgz 
$deployDir/modules-${MODULE_TARBALL_LINK_NAME}.tgz
fi
 
-- 
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 2/4] kernel-fitimage: Fix dangling symlink to image tree source

[Alex Kiernan]

When deploying the its file, the target of the symlink is missing the its
extension, add it here.

Signed-off-by: Alex Kiernan 
---

 meta/classes/kernel-fitimage.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/kernel-fitimage.bbclass 
b/meta/classes/kernel-fitimage.bbclass
index a4d7acae40ba..4c4fd99ff4ac 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -490,7 +490,7 @@ kernel_do_deploy_append() {
if echo ${KERNEL_IMAGETYPES} | grep -wq "fitImage"; then
echo "Copying fit-image.its source file..."
install -m 0644 ${B}/fit-image.its 
${DEPLOYDIR}/fitImage-its-${KERNEL_FIT_NAME}.its
-   ln -snf fitImage-its-${KERNEL_FIT_NAME} 
${DEPLOYDIR}/fitImage-its-${KERNEL_FIT_LINK_NAME}
+   ln -snf fitImage-its-${KERNEL_FIT_NAME}.its 
${DEPLOYDIR}/fitImage-its-${KERNEL_FIT_LINK_NAME}
 
echo "Copying linux.bin file..."
install -m 0644 ${B}/linux.bin 
${DEPLOYDIR}/fitImage-linux.bin-${KERNEL_FIT_NAME}.bin
-- 
2.7.4

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

Re: [OE-core] [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that.

[Alex Kiernan]

On Tue, Sep 18, 2018 at 12:23 PM Leon Woestenberg  wrote:
>
> Hi Marek, Alex,
>
> On Tue, Sep 18, 2018 at 1:19 PM Marek Vasut  wrote:
> > On 09/18/2018 12:59 PM, Leon Woestenberg wrote:
> > > On Tue, Sep 18, 2018 at 12:38 PM Marek Vasut  wrote:
> > >> On 09/18/2018 12:22 PM, Leon Woestenberg wrote:
> > >>>
> > >>> There is no exception for INITRAMFS_IMAGE_BUNDLE in
> > >>> kernel-fitimage.bbclass. The initramfs will be packed inside the FIT,
> > >>> in addition of also being packed inside the kernel.
> > >>
> > >> So why would you use initramfs_image_bundle with fitImage when you can
> > >> pack the initrd into the fitImage instead ?
> > >>
> > > To be honest, I do not know that use-case anymore but it's a valid
> > > configuration that shouldn't give an unexpected outcome.
> >
> > True
> >
> > > We also found a use-case for non-compressed kernels in the FIT image;
> > > that was for very small delta-upgrades even when kernels are FIT
> > > packed. Currently kernel-fitimage.bbclass hard-selects a compressed
> > > kernel (such as zImage).
> >
> > Patches are welcome
> >
> Thanks for explaining the rationale behind the deploy stage, it
> confirms Alex's suspicion I was solving the problem at the wrong
> place.
>
> Alex, if you are still reading this: the answer is yes, please revert.
>

I am :)

Thanks for the discussion... I'll send the series I've got - whilst I
was about it I cleaned up a bunch of other small things in the same
area.

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

Re: [OE-core] ✗ patchtest: failure for python3{,-native}: update to 3.7.0 (rev3)

[richard . purdie]

On Tue, 2018-09-18 at 16:22 +0200, Jens Rehsack wrote:
>   Error verifying signature: Failed to execute gpg.
> 
> 
> > Am 17.09.2018 um 21:03 schrieb Patchwork  > mbedded.org>:
> > 
> > == Series Details ==
> > 
> > Series: python3{,-native}: update to 3.7.0 (rev3)
> > Revision: 3
> > URL   : https://patchwork.openembedded.org/series/13851/
> > State : failure
> > 
> > == Summary ==
> > 
> > 
> > Thank you for submitting this patch series to OpenEmbedded Core.
> > This is
> > an automated response. Several tests have been executed on the
> > proposed
> > series by patchtest resulting in the following failures:
> > 
> > 
> > 
> > * Issue Added patch file is missing Upstream-Status in
> > the header [test_upstream_status_presence_format] 
> >  Suggested fixAdd Upstream-Status:  to the header
> > of meta/recipes-
> > devtools/python/python3/uuid_when_cross_compiling.patch
> >  Standard format  Upstream-Status: 
> >  Valid status Pending, Accepted, Backport, Denied,
> > Inappropriate [reason], Submitted [where]
> > 
> > 
> > 
> > If you believe any of these test results are incorrect, please
> > reply to the
> > mailing list (openembedded-core@lists.openembedded.org) raising
> > your concerns.
> > Otherwise we would appreciate you correcting the issues and
> > submitting a new
> > version of the patchset if applicable. Please ensure you
> > add/increment the
> > version number when sending the new version (i.e. [PATCH] -> [PATCH
> > v2] ->
> > [PATCH v3] -> ...).
> > 
> > ---
> > Guidelines: https://www.openembedded.org/wiki/Commit_Patch_Mess
> > age_Guidelines
> > Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
> > Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
> > -oe
> 
> I understand this policy. I have an issue wrt. this particular one.
> Why? Well - the patch seems to be reasonable submitted to upstream,
> since it's a
> quirk and likely an error. OTOH - supporting Yocto and OpenEmbedded
> in getting
> software up-to-date is one thing - having my name in the Python
> contributors is
> something complete different.
> 
> Please find someone else doing that.

Nobody is saying it has to be submitted upstream, although we obviously
do appreciate anyone doing that a lot. We do ask any patches which get
added have a status though so we have some idea what is happening to
them.

So in this case the status would be "Pending".

Cheers,

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

Re: [OE-core] ✗ patchtest: failure for python3{,-native}: update to 3.7.0 (rev3)

[Burton, Ross]

In this case set the status to Pending.

Ross
On Tue, 18 Sep 2018 at 15:26, Jens Rehsack  wrote:
>
>
>
> Am 17.09.2018 um 21:03 schrieb Patchwork 
> :
>
> == Series Details ==
>
> Series: python3{,-native}: update to 3.7.0 (rev3)
> Revision: 3
> URL   : https://patchwork.openembedded.org/series/13851/
> State : failure
>
> == Summary ==
>
>
> Thank you for submitting this patch series to OpenEmbedded Core. This is
> an automated response. Several tests have been executed on the proposed
> series by patchtest resulting in the following failures:
>
>
>
> * Issue Added patch file is missing Upstream-Status in the header 
> [test_upstream_status_presence_format]
>  Suggested fixAdd Upstream-Status:  to the header of 
> meta/recipes-devtools/python/python3/uuid_when_cross_compiling.patch
>  Standard format  Upstream-Status: 
>  Valid status Pending, Accepted, Backport, Denied, Inappropriate 
> [reason], Submitted [where]
>
>
>
> If you believe any of these test results are incorrect, please reply to the
> mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
> Otherwise we would appreciate you correcting the issues and submitting a new
> version of the patchset if applicable. Please ensure you add/increment the
> version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
> [PATCH v3] -> ...).
>
> ---
> Guidelines: 
> https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
> Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
> Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe
>
>
> I understand this policy. I have an issue wrt. this particular one.
> Why? Well - the patch seems to be reasonable submitted to upstream, since 
> it's a
> quirk and likely an error. OTOH - supporting Yocto and OpenEmbedded in getting
> software up-to-date is one thing - having my name in the Python contributors 
> is
> something complete different.
>
> Please find someone else doing that.
>
> Thanks in advance,
> Jens
> --
> Jens Rehsack - rehs...@gmail.com
>
> --
> ___
> 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] Yocto Project Status WW38’18

[Jolley, Stephen K]

Current Dev Position: YP 2.6 M3. - This is feature freeze for YP 2.6!

Next Deadline: YP 2.6 M3 Build Target is Aug. 27, 2018


SWAT Team Rotation:

· SWAT lead is currently: Tracy

· SWAT team rotation: Tracy-> Armin on Sept. 21, 2018

· SWAT team rotation: Armin -> Chen on Sept. 28, 2018

· https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team


Key Status/Updates:

· We’re now well into M3 feature freeze so new feature patches, 
particularly for unplanned changes will be deferred until 2.7.

· M3 has still not been built yet however we have:

oupgraded to openssl 1.1 final

omerged the allarch multilib changes we were waiting for.

oresolved the xserver upgrade issues and merged the fixes/upgrades

othe python3 openssl issues were resolved, thanks Anuj!

· The main remaining question is what, if anything to do with openssh 
for 2.6. Upstream have now reluctantly merged openssl 1.1 support. Any new 
release date containing that work is unknown but its tempting to upgrade to the 
latest from revision control and then take the new released version into 2.6 
when it does happen., thereby unifying openssl support in OE-Core.

· There is a bug that has been identified in relocating gnupg-native 
causing oe-selftest failures.

· An issue with the buildbot autobuilder UI plugin code was debugged 
and a fix sent and accepted upstream.


Planned Releases for YP 2.6:

· YP 2.6 M3 Build Target is Aug. 27, 2018

· YP 2.6 M3 Release Target is Sept. 7, 2018

· YP 2.6 M4 Build Target is Oct. 1, 2018

· YP 2.6 M4 Release Target is Oct. 26, 2018


Planned upcoming dot releases:

· YP 2.4.4 (Rocko) will be targeted after YP 2.6 M4 is done.

· YP 2.5.2 (Sumo) will be targeted after YP 2.4.4 is done.


Tracking Metrics:

· WDD 2589 (last week 2580) 
(https://wiki.yoctoproject.org/charts/combo.html)

· Poky Patch Metrics

oTotal patches found: 1646 (last week 1646)

oPercentage of patches in the Pending State: 736 (45%) [last week 736 (45%)]


Key Status Links for YP:

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.6_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.6_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.6_Features


The Status reports are now stored on the wiki at: 
https://wiki.yoctoproject.org/wiki/Weekly_Status


[If anyone has suggestions for other information you’d like to see on this 
weekly status update, let us know!]

Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
•Cell:(208) 244-4460
• Email: stephen.k.jol...@intel.com

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

Re: [OE-core] ✗ patchtest: failure for python3{,-native}: update to 3.7.0 (rev3)

[Jens Rehsack]

> Am 17.09.2018 um 21:03 schrieb Patchwork 
> :
> 
> == Series Details ==
> 
> Series: python3{,-native}: update to 3.7.0 (rev3)
> Revision: 3
> URL   : https://patchwork.openembedded.org/series/13851/
> State : failure
> 
> == Summary ==
> 
> 
> Thank you for submitting this patch series to OpenEmbedded Core. This is
> an automated response. Several tests have been executed on the proposed
> series by patchtest resulting in the following failures:
> 
> 
> 
> * Issue Added patch file is missing Upstream-Status in the header 
> [test_upstream_status_presence_format]
>  Suggested fixAdd Upstream-Status:  to the header of 
> meta/recipes-devtools/python/python3/uuid_when_cross_compiling.patch
>  Standard format  Upstream-Status: 
>  Valid status Pending, Accepted, Backport, Denied, Inappropriate 
> [reason], Submitted [where]
> 
> 
> 
> If you believe any of these test results are incorrect, please reply to the
> mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
> Otherwise we would appreciate you correcting the issues and submitting a new
> version of the patchset if applicable. Please ensure you add/increment the
> version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
> [PATCH v3] -> ...).
> 
> ---
> Guidelines: 
> https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
> Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
> Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe 
> 


I understand this policy. I have an issue wrt. this particular one.
Why? Well - the patch seems to be reasonable submitted to upstream, since it's a
quirk and likely an error. OTOH - supporting Yocto and OpenEmbedded in getting
software up-to-date is one thing - having my name in the Python contributors is
something complete different.

Please find someone else doing that.

Thanks in advance,
Jens
--
Jens Rehsack - rehs...@gmail.com



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

[OE-core] Demos for the Yocto Project booth at ELCE in Edinburgh

[Nicolas Dechesne]

Dear all,

As usual, the Yocto Project will have a booth at the ELCE conference
in Edinburgh next month. While the booth is a great opportunity for
everyone to get a new sticker of your favorite project ;-) we are also
very excited when developers from our community get a chance to show
off the fun and cool things they build thanks to the Yocto Project!

If you want to bring any of your cool demo on the YP booth, please
send me an email so that we can plan and discuss any of the logistics!

Also, don't forget the YP Dev Day Europe, which is right after ELCE,
in Edinburgh, more information can be found here:
https://www.yoctoproject.org/yocto-project-dev-day-europe-2018/

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

Re: [OE-core] [PATCH] staging: remove hard-coded values from _FIXMEs

[Richard Purdie]

On Mon, 2018-09-17 at 15:41 +0200, Andrej Valek wrote:
> Let users to override these values in their layers and could match
> them
> with values in EXTRA_STAGING_FIXMES.
> 
> Signed-off-by: Andrej Valek 
> ---
>  meta/classes/staging.bbclass | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/classes/staging.bbclass
> b/meta/classes/staging.bbclass
> index 84e13bab59..6db501dac1 100644
> --- a/meta/classes/staging.bbclass
> +++ b/meta/classes/staging.bbclass
> @@ -127,6 +127,8 @@ python do_populate_sysroot_setscene () {
>  }
>  addtask do_populate_sysroot_setscene
>  
> +SYSROOT_STAGING_FIXMES ?= "COMPONENTS_DIR HOSTTOOLS_DIR PKGDATA_DIR
> PSEUDO_LOCALSTATEDIR LOGFIFO"
> +
>  def staging_copyfile(c, target, dest, postinsts, seendirs):
>  import errno
>  
> @@ -167,7 +169,7 @@ def staging_processfixme(fixme, target,
> recipesysroot, recipesysrootnative, d):
>  if not fixme:
>  return
>  cmd = "sed -e 's:^[^/]*/:%s/:g' %s | xargs sed -i -e
> 's:FIXMESTAGINGDIRTARGET:%s:g; s:FIXMESTAGINGDIRHOST:%s:g'" %
> (target, " ".join(fixme), recipesysroot, recipesysrootnative)
> -for fixmevar in ['COMPONENTS_DIR', 'HOSTTOOLS_DIR',
> 'PKGDATA_DIR', 'PSEUDO_LOCALSTATEDIR', 'LOGFIFO']:
> +for fixmevar in d.getVar("SYSROOT_STAGING_FIXMES").split():
>  fixme_path = d.getVar(fixmevar)
>  cmd += " -e 's:FIXME_%s:%s:g'" % (fixmevar, fixme_path)
>  bb.debug(2, cmd)

I think this was deliberately left this way rather than letting users
override it as the scope issues around this are not obvious and making
it a variable gives users expectations which may not be met.

I'm going from memory with jetlag but I think that this variable would
not work from recipe context, you'd have to do it in global scope and
changing this in global scope for everything is a pretty serious
change.

The reason is that it can get called when building any recipe sysroot
so the datastore isn't to context of the original creator.

Cheers,

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

Re: [OE-core] [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that.

[Leon Woestenberg]

Hi Marek, Alex,

On Tue, Sep 18, 2018 at 1:19 PM Marek Vasut  wrote:
> On 09/18/2018 12:59 PM, Leon Woestenberg wrote:
> > On Tue, Sep 18, 2018 at 12:38 PM Marek Vasut  wrote:
> >> On 09/18/2018 12:22 PM, Leon Woestenberg wrote:
> >>>
> >>> There is no exception for INITRAMFS_IMAGE_BUNDLE in
> >>> kernel-fitimage.bbclass. The initramfs will be packed inside the FIT,
> >>> in addition of also being packed inside the kernel.
> >>
> >> So why would you use initramfs_image_bundle with fitImage when you can
> >> pack the initrd into the fitImage instead ?
> >>
> > To be honest, I do not know that use-case anymore but it's a valid
> > configuration that shouldn't give an unexpected outcome.
>
> True
>
> > We also found a use-case for non-compressed kernels in the FIT image;
> > that was for very small delta-upgrades even when kernels are FIT
> > packed. Currently kernel-fitimage.bbclass hard-selects a compressed
> > kernel (such as zImage).
>
> Patches are welcome
>
Thanks for explaining the rationale behind the deploy stage, it
confirms Alex's suspicion I was solving the problem at the wrong
place.

Alex, if you are still reading this: the answer is yes, please revert.

Regards,

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

Re: [OE-core] [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that.

[Marek Vasut]

On 09/18/2018 12:59 PM, Leon Woestenberg wrote:
> Hi Marek,

Hi,

> On Tue, Sep 18, 2018 at 12:38 PM Marek Vasut  wrote:
>> On 09/18/2018 12:22 PM, Leon Woestenberg wrote:
>>>
>>> There is no exception for INITRAMFS_IMAGE_BUNDLE in
>>> kernel-fitimage.bbclass. The initramfs will be packed inside the FIT,
>>> in addition of also being packed inside the kernel.
>>
>> So why would you use initramfs_image_bundle with fitImage when you can
>> pack the initrd into the fitImage instead ?
>>
> To be honest, I do not know that use-case anymore but it's a valid
> configuration that shouldn't give an unexpected outcome.

True

> We also found a use-case for non-compressed kernels in the FIT image;
> that was for very small delta-upgrades even when kernels are FIT
> packed. Currently kernel-fitimage.bbclass hard-selects a compressed
> kernel (such as zImage).

Patches are welcome

-- 
Best regards,
Marek Vasut
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] ✗ patchtest: failure for glibc-package.inc: correct intention for deleting /usr/lib as needed

[Patchwork]

== Series Details ==

Series: glibc-package.inc: correct intention for deleting /usr/lib as needed
Revision: 1
URL   : https://patchwork.openembedded.org/series/14118/
State : failure

== Summary ==


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



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



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

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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

Re: [OE-core] [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that.

[Leon Woestenberg]

Hi Marek,

On Tue, Sep 18, 2018 at 12:38 PM Marek Vasut  wrote:
> On 09/18/2018 12:22 PM, Leon Woestenberg wrote:
> >
> > There is no exception for INITRAMFS_IMAGE_BUNDLE in
> > kernel-fitimage.bbclass. The initramfs will be packed inside the FIT,
> > in addition of also being packed inside the kernel.
>
> So why would you use initramfs_image_bundle with fitImage when you can
> pack the initrd into the fitImage instead ?
>
To be honest, I do not know that use-case anymore but it's a valid
configuration that shouldn't give an unexpected outcome.

We also found a use-case for non-compressed kernels in the FIT image;
that was for very small delta-upgrades even when kernels are FIT
packed. Currently kernel-fitimage.bbclass hard-selects a compressed
kernel (such as zImage).

Regards,

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

[OE-core] [PATCH] glibc-package.inc: correct intention for deleting /usr/lib as needed

[Belal, Awais]

In case the baselib is lib64 we would want to delete /usr/lib
after removing the /usr/lib/locale dir and the implementation
wanted to do that earlier as well but the fault was checking
an already removed dir (/usr/lib/locale) before trying to
remove /usr/lib as that check would always fail.
Now we simply try to delete /usr/lib after deleting
/usr/lib/locale to make sure it deletes cleanly and is empty
at the time of deletion.

Signed-off-by: Awais Belal 
---
 meta/recipes-core/glibc/glibc-package.inc | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/meta/recipes-core/glibc/glibc-package.inc 
b/meta/recipes-core/glibc/glibc-package.inc
index 9ea41b7..22a59d2 100644
--- a/meta/recipes-core/glibc/glibc-package.inc
+++ b/meta/recipes-core/glibc/glibc-package.inc
@@ -207,11 +207,10 @@ do_poststash_install_cleanup () {
 rm -rf ${D}/${localedir}
 rm -rf ${D}${datadir}/locale
 if [ "${libdir}" != "${exec_prefix}/lib" ]; then
-if [ -d ${D}${exec_prefix}/lib/locale ] ; then
-rm -rf ${D}${exec_prefix}/lib/locale
-# error out if directory isn't empty
-rm -f ${D}${exec_prefix}/lib
-fi
+# error out if directory isn't empty
+# this dir should only contain locale dir
+# which has been deleted in the previous step
+rmdir ${D}${exec_prefix}/lib
 fi
 }
 addtask do_poststash_install_cleanup after do_stash_locale do_install before 
do_populate_sysroot do_package
--
2.7.4

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

Re: [OE-core] [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that.

[Marek Vasut]

On 09/18/2018 12:22 PM, Leon Woestenberg wrote:
> Hi Marek,

Hi,

> On Tue, Sep 18, 2018 at 12:12 PM Marek Vasut  wrote:
>>
>> On 09/18/2018 12:01 PM, Leon Woestenberg wrote:
>>> Hi Marek,
>> Could you _please_ stop top-posting ?
> 
>  Yes.
> 
>>
>>> one of the issues I saw was that both kernel.bbclass and
>>> kernel-fitImage.bbclass deployed the FIT image into the deploy/images/
>>> subfolder.
>>>
>>> My fix was to make the kernel.bbclass ignore "fitImage" during
>>> deployment. This is also the fix I saw from Xilinx.
>>
>> If I recall correctly, meta-xilinx had their own horribly hacked
>> fitImage bbclass, are you sure it's not interfering here ?
>>
> Yes I am sure it's not.
> 
>>
>>> (Another fix I have pending is that bundled initramfs images (i.e that
>>> go inside the kernel binary) where also seperately packed inside the FIT
>>> image.)
>>
>> Separate initrd is already supported.
> 
> 
> There is no exception for INITRAMFS_IMAGE_BUNDLE in
> kernel-fitimage.bbclass. The initramfs will be packed inside the FIT,
> in addition of also being packed inside the kernel.

So why would you use initramfs_image_bundle with fitImage when you can
pack the initrd into the fitImage instead ?

> My local fix has this:
> 
> diff --git a/meta/classes/kernel-fitimage.bbclass
> b/meta/classes/kernel-fitimage.bbclass
> index a4d7aca..17addab 100644
> --- a/meta/classes/kernel-fitimage.bbclass
> +++ b/meta/classes/kernel-fitimage.bbclass
> @@ -475,7 +475,9 @@ addtask assemble_fitimage before do_install after 
> do_compile
> 
>  do_assemble_fitimage_initramfs() {
> if echo ${KERNEL_IMAGETYPES} | grep -wq "fitImage" && \
> -   test -n "${INITRAMFS_IMAGE}" ; then
> +   test -n "${INITRAMFS_IMAGE}" && \
> +   test ! -n "${INITRAMFS_IMAGE_BUNDLE}"; then
> +
> cd ${B}
> fitimage_assemble fit-image-${INITRAMFS_IMAGE}.its
> fitImage-${INITRAMFS_IMAGE} 1
> fi
> @@ -483,6 +485,18 @@ do_assemble_fitimage_initramfs() {
> 
>  addtask assemble_fitimage_initramfs before do_deploy after do_install
> 
> +do_assemble_fitimage_bundled_initramfs() {
> +   if echo ${KERNEL_IMAGETYPES} | grep -wq "fitImage" && \
> +   test -n "${INITRAMFS_IMAGE}" && \
> +   test -n "${INITRAMFS_IMAGE_BUNDLE}"; then
> +
> +   cd ${B}
> +   fitimage_assemble fit-image-${INITRAMFS_IMAGE}.its
> fitImage-${INITRAMFS_IMAGE}
> +   fi
> +}
> +
> +addtask assemble_fitimage_bundled_initramfs before do_deploy after
> do_bundle_initramfs
> +
> 
> 
> Regards,
> 
> Leon.
> 


-- 
Best regards,
Marek Vasut
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that.

[Marek Vasut]

On 09/18/2018 12:21 PM, Leon Woestenberg wrote:
> Hello Marek,

Hi,

> On Tue, Sep 18, 2018 at 12:01 PM Leon Woestenberg  wrote:
>> On Tue, Sep 18, 2018 at 11:44 AM Marek Vasut  wrote:
>>> On 09/18/2018 11:40 AM, Leon Woestenberg wrote:
>>> What bug is it that you're seeing ?
>>>
 Whilst cleaning things up, my understanding was that
 kernel_do_deploy_append() in kernel-fitimage.bbclass deploys the
 fitImages, along with the .its file etc.
 Maybe I was mistaken.
>>>
>>> That's the case, yes.
> 
> Am I mistaken or is my assumption correct that kernel-fitimage.bbclass
> should deploy the fitImages?

Nope, the fitImages should be deployed by the generic mechanism. The
fitImage bbclass only deploys the artifacts from which the fitImage is
constructed (its, initrd, linux.bin, dtb etc)

-- 
Best regards,
Marek Vasut
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that.

[Leon Woestenberg]

Hi Marek,

On Tue, Sep 18, 2018 at 12:12 PM Marek Vasut  wrote:
>
> On 09/18/2018 12:01 PM, Leon Woestenberg wrote:
> > Hi Marek,
> Could you _please_ stop top-posting ?

 Yes.

>
> > one of the issues I saw was that both kernel.bbclass and
> > kernel-fitImage.bbclass deployed the FIT image into the deploy/images/
> > subfolder.
> >
> > My fix was to make the kernel.bbclass ignore "fitImage" during
> > deployment. This is also the fix I saw from Xilinx.
>
> If I recall correctly, meta-xilinx had their own horribly hacked
> fitImage bbclass, are you sure it's not interfering here ?
>
Yes I am sure it's not.

>
> > (Another fix I have pending is that bundled initramfs images (i.e that
> > go inside the kernel binary) where also seperately packed inside the FIT
> > image.)
>
> Separate initrd is already supported.


There is no exception for INITRAMFS_IMAGE_BUNDLE in
kernel-fitimage.bbclass. The initramfs will be packed inside the FIT,
in addition of also being packed inside the kernel.

My local fix has this:

diff --git a/meta/classes/kernel-fitimage.bbclass
b/meta/classes/kernel-fitimage.bbclass
index a4d7aca..17addab 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -475,7 +475,9 @@ addtask assemble_fitimage before do_install after do_compile

 do_assemble_fitimage_initramfs() {
if echo ${KERNEL_IMAGETYPES} | grep -wq "fitImage" && \
-   test -n "${INITRAMFS_IMAGE}" ; then
+   test -n "${INITRAMFS_IMAGE}" && \
+   test ! -n "${INITRAMFS_IMAGE_BUNDLE}"; then
+
cd ${B}
fitimage_assemble fit-image-${INITRAMFS_IMAGE}.its
fitImage-${INITRAMFS_IMAGE} 1
fi
@@ -483,6 +485,18 @@ do_assemble_fitimage_initramfs() {

 addtask assemble_fitimage_initramfs before do_deploy after do_install

+do_assemble_fitimage_bundled_initramfs() {
+   if echo ${KERNEL_IMAGETYPES} | grep -wq "fitImage" && \
+   test -n "${INITRAMFS_IMAGE}" && \
+   test -n "${INITRAMFS_IMAGE_BUNDLE}"; then
+
+   cd ${B}
+   fitimage_assemble fit-image-${INITRAMFS_IMAGE}.its
fitImage-${INITRAMFS_IMAGE}
+   fi
+}
+
+addtask assemble_fitimage_bundled_initramfs before do_deploy after
do_bundle_initramfs
+


Regards,

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

Re: [OE-core] [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that.

[Leon Woestenberg]

Hello Marek,

On Tue, Sep 18, 2018 at 12:01 PM Leon Woestenberg  wrote:
> On Tue, Sep 18, 2018 at 11:44 AM Marek Vasut  wrote:
>> On 09/18/2018 11:40 AM, Leon Woestenberg wrote:
>> What bug is it that you're seeing ?
>>
>> > Whilst cleaning things up, my understanding was that
>> > kernel_do_deploy_append() in kernel-fitimage.bbclass deploys the
>> > fitImages, along with the .its file etc.
>> > Maybe I was mistaken.
>>
>> That's the case, yes.

Am I mistaken or is my assumption correct that kernel-fitimage.bbclass
should deploy the fitImages?

Regards,

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

Re: [OE-core] [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that.

[Marek Vasut]

On 09/18/2018 12:01 PM, Leon Woestenberg wrote:
> Hi Marek,

Could you _please_ stop top-posting ?

> one of the issues I saw was that both kernel.bbclass and
> kernel-fitImage.bbclass deployed the FIT image into the deploy/images/
> subfolder.
> 
> My fix was to make the kernel.bbclass ignore "fitImage" during
> deployment. This is also the fix I saw from Xilinx.

If I recall correctly, meta-xilinx had their own horribly hacked
fitImage bbclass, are you sure it's not interfering here ?

> (Another fix I have pending is that bundled initramfs images (i.e that
> go inside the kernel binary) where also seperately packed inside the FIT
> image.)

Separate initrd is already supported.

> In general, I am trying to fix all bugs and issues that match
> "kernel-fitimage.bbclass" on the mailing list.
> 
> Regards,
> 
> Leon.
> 
> 
> On Tue, Sep 18, 2018 at 11:44 AM Marek Vasut  > wrote:
> 
> On 09/18/2018 11:40 AM, Leon Woestenberg wrote:
> > Hi Alex,
> 
> Hi,
> 
> > Adding Marek Vasut, original author of kernel-fitimage.bbclass.
> >
> >> I guess the reason that the deployment happens in kernel.bbclass
> is so
> >> you only have all the symlinking logic in one place
> >
> > The deployment happens in both kernel.bbclass and
> > kernel-fitimage.bbclass. That was exactly one of the bugs I wanted to
> > solve. I am not sure what the intention was, though.
> >
> > Marek: can you comment of the exact purpose of the deploy task in
> > kernel-fitimage.bbclass?
> > Which class should deploy the FIT images themselves?
> 
> It seems to have to do with deploying of the ITS files and the symlinks
> for then .
> 
> It's hard to make any sense from the discussion below due to the
> constant top-posting and mixing of email history, so I'll just not do
> that, sorry.
> 
> What bug is it that you're seeing ?
> 
> > Whilst cleaning things up, my understanding was that
> > kernel_do_deploy_append() in kernel-fitimage.bbclass deploys the
> > fitImages, along with the .its file etc.
> > Maybe I was mistaken.
> 
> That's the case, yes.
> 
> > I have several other fixed piled up; for example initramfs's
> supposed to
> > get bundled inside the kernel get also packed into the FIT; this takes
> > double the amount of space in the FIT image...
> >
> > Regards,
> >
> > Leon.
> >
> >
> >
> >
> > On Tue, Sep 18, 2018 at 8:10 AM Alex Kiernan
> mailto:alex.kier...@gmail.com>
> > >>
> wrote:
> >
> >     Thanks Leon
> >
> >     I guess the reason that the deployment happens in
> kernel.bbclass is so
> >     you only have all the symlinking logic in one place.
> >
> >     Are in agreement that this change should be reverted and the
> >     "fitImage" deployed here:
> >
> >   
>  
> http://git.openembedded.org/openembedded-core/tree/meta/classes/kernel-fitimage.bbclass#n495
> >
> >     is the one which we should remove?
> >     On Mon, Sep 17, 2018 at 7:05 PM Leon Woestenberg
> >     mailto:l...@sidebranch.com>
> >> wrote:
> >     >
> >     > Hi Alex,
> >     >
> >     > I expected it to be kernel-fitimage.bbclass’s responsibility to
> >     deploy the fitImage.
> >     >
> >     > Regards, Leon
> >     >
> >     >
> >     >
> >     >
> >     > On 16 Sep 2018, at 16:22, Alex Kiernan
> mailto:alex.kier...@gmail.com>
> >      >> wrote:
> >     >
> >     > On Sun, Sep 16, 2018 at 11:41 AM Alex Kiernan
> >     mailto:alex.kier...@gmail.com>
> >> wrote:
> >     >
> >     >
> >     > Hi Leon
> >     >
> >     >
> >     > On Sun, Sep 16, 2018 at 10:18 AM Leon Woestenberg
> >     mailto:l...@sidebranch.com>
> >> wrote:
> >     >
> >     >
> >     > Hi Alex,
> >     >
> >     >
> >     > On 15 Sep 2018, at 19:45, Alex Kiernan
> mailto:alex.kier...@gmail.com>
> >      >> wrote:
> >     >
> >     >
> >     > On Mon, Sep 10, 2018 at 10:57 PM Leon Woestenberg
> >     mailto:l...@sidebranch.com>
> >> wrote:
> >     >
> >     >
> >     > kernel-fitimage.bbclass replaces an occurance of "fitImage" in
> >     >
> >     > KERNEL_IMAGETYPE_FOR_MAKE by an image type that is buildable
> for the
> >     >
> >     > architecture (such as zImage). The kernel-fitimage.bbclass
> packs that
> >     >
> > 

Re: [OE-core] [PATCH] gdb: gdbserver: update ctrl-c handling

[Burton, Ross]

On Tue, 18 Sep 2018 at 10:01, Zhixiong Chi  wrote:
> ++Upstream-Status: Pending
> ++cherry-picked patch from 
> https://sourceware.org/bugzilla/show_bug.cgi?id=18945

Sounds like the status should be:

Upstream-Status: Submitted
[https://sourceware.org/bugzilla/show_bug.cgi?id=18945]

Ross

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

Re: [OE-core] [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that.

[Leon Woestenberg]

Hi Marek,

one of the issues I saw was that both kernel.bbclass and
kernel-fitImage.bbclass deployed the FIT image into the deploy/images/
subfolder.

My fix was to make the kernel.bbclass ignore "fitImage" during deployment.
This is also the fix I saw from Xilinx.

(Another fix I have pending is that bundled initramfs images (i.e that go
inside the kernel binary) where also seperately packed inside the FIT
image.)

In general, I am trying to fix all bugs and issues that match
"kernel-fitimage.bbclass" on the mailing list.

Regards,

Leon.


On Tue, Sep 18, 2018 at 11:44 AM Marek Vasut  wrote:

> On 09/18/2018 11:40 AM, Leon Woestenberg wrote:
> > Hi Alex,
>
> Hi,
>
> > Adding Marek Vasut, original author of kernel-fitimage.bbclass.
> >
> >> I guess the reason that the deployment happens in kernel.bbclass is so
> >> you only have all the symlinking logic in one place
> >
> > The deployment happens in both kernel.bbclass and
> > kernel-fitimage.bbclass. That was exactly one of the bugs I wanted to
> > solve. I am not sure what the intention was, though.
> >
> > Marek: can you comment of the exact purpose of the deploy task in
> > kernel-fitimage.bbclass?
> > Which class should deploy the FIT images themselves?
>
> It seems to have to do with deploying of the ITS files and the symlinks
> for then .
>
> It's hard to make any sense from the discussion below due to the
> constant top-posting and mixing of email history, so I'll just not do
> that, sorry.
>
> What bug is it that you're seeing ?
>
> > Whilst cleaning things up, my understanding was that
> > kernel_do_deploy_append() in kernel-fitimage.bbclass deploys the
> > fitImages, along with the .its file etc.
> > Maybe I was mistaken.
>
> That's the case, yes.
>
> > I have several other fixed piled up; for example initramfs's supposed to
> > get bundled inside the kernel get also packed into the FIT; this takes
> > double the amount of space in the FIT image...
> >
> > Regards,
> >
> > Leon.
> >
> >
> >
> >
> > On Tue, Sep 18, 2018 at 8:10 AM Alex Kiernan  > > wrote:
> >
> > Thanks Leon
> >
> > I guess the reason that the deployment happens in kernel.bbclass is
> so
> > you only have all the symlinking logic in one place.
> >
> > Are in agreement that this change should be reverted and the
> > "fitImage" deployed here:
> >
> >
> http://git.openembedded.org/openembedded-core/tree/meta/classes/kernel-fitimage.bbclass#n495
> >
> > is the one which we should remove?
> > On Mon, Sep 17, 2018 at 7:05 PM Leon Woestenberg
> > mailto:l...@sidebranch.com>> wrote:
> > >
> > > Hi Alex,
> > >
> > > I expected it to be kernel-fitimage.bbclass’s responsibility to
> > deploy the fitImage.
> > >
> > > Regards, Leon
> > >
> > >
> > >
> > >
> > > On 16 Sep 2018, at 16:22, Alex Kiernan  > > wrote:
> > >
> > > On Sun, Sep 16, 2018 at 11:41 AM Alex Kiernan
> > mailto:alex.kier...@gmail.com>> wrote:
> > >
> > >
> > > Hi Leon
> > >
> > >
> > > On Sun, Sep 16, 2018 at 10:18 AM Leon Woestenberg
> > mailto:l...@sidebranch.com>> wrote:
> > >
> > >
> > > Hi Alex,
> > >
> > >
> > > On 15 Sep 2018, at 19:45, Alex Kiernan  > > wrote:
> > >
> > >
> > > On Mon, Sep 10, 2018 at 10:57 PM Leon Woestenberg
> > mailto:l...@sidebranch.com>> wrote:
> > >
> > >
> > > kernel-fitimage.bbclass replaces an occurance of "fitImage" in
> > >
> > > KERNEL_IMAGETYPE_FOR_MAKE by an image type that is buildable for
> the
> > >
> > > architecture (such as zImage). The kernel-fitimage.bbclass packs
> that
> > >
> > > image as sub-image in a flattened image tree image (fitImage) and
> > >
> > > deploys this fitImage along with the image tree source file (.its).
> > >
> > >
> > > kernel-fitimage.bbclass does not alter KERNEL_IMAGETYPES, which
> thus
> > >
> > > also contains "fitImage", which kernel.bbclass will also deploy
> > >
> > > redundantly with different naming.
> > >
> > >
> > > The result is a dual deployment with slightly different naming,
> > >
> > > each with a set of symlinks.
> > >
> > >
> > > The solution chosen is to have fitImage deployment be handled by
> > >
> > > kernel-fitimage.bbclass, and have kernel.bbclass ignore fitImage
> > >
> > > types during deployment.
> > >
> > >
> > > Signed-off-by: Leon Woestenberg  > >
> > >
> > >
> > > This looks completely plausible, but the two "FIT" images that are
> > >
> > > installed aren't identical... after this I end up with no FIT image
> > >
> > > and only a bare image in the deploy dir.
> > >
> > >
> > > What was in your KERNEL_IMAGETYPES? Did it at least contain
> > “fitImage”??
> > 

[OE-core] [PATCH v2] glibc: fix Segmentation fault in gethostid.c

[mingli.yu]

From: Mingli Yu 

When run test program hostid, it encounters
Segmentation fault as hp is NULL.

 # cat /mybuild/hostid.c
 #include 
 #include 

 int
 main(int argc, char *argv[])
 {
long hostid;
hostid = gethostid();
printf("the hostid is %ld\n", hostid);

 }

 # gcc -o /mybuild/hostid /mybuild/hostid.c
 # /mybuild/hostid
 Segmentation fault
 # gdb /mybuild/hostid
 GNU gdb (GDB) 8.2
 Copyright (C) 2018 Free Software Foundation, Inc.
 License GPLv3+: GNU GPL version 3 or later 
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.
 Type "show copying" and "show warranty" for details.
 This GDB was configured as "x86_64-wrs-linux".
 Type "show configuration" for configuration details.
 For bug reporting instructions, please see:
 .
 Find the GDB manual and other documentation resources online at:
.

 For help, type "help".
 Type "apropos word" to search for commands related to "word"...
 Reading symbols from /mybuild/hostid...done.
 (gdb) r
 Starting program: /mybuild/hostid

 Program received signal SIGSEGV, Segmentation fault.
 0x77f0330e in gethostid () at 
../sysdeps/unix/sysv/linux/gethostid.c:125
 125  memcpy (, hp->h_addr,
 (gdb) bt
 #0  0x77f0330e in gethostid () at 
../sysdeps/unix/sysv/linux/gethostid.c:125
 #1  0x5159 in main ()

Signed-off-by: Mingli Yu 
---
 .../0001-gethostid.c-check-the-value-of-hp.patch   | 75 ++
 meta/recipes-core/glibc/glibc_2.28.bb  |  1 +
 2 files changed, 76 insertions(+)
 create mode 100644 
meta/recipes-core/glibc/glibc/0001-gethostid.c-check-the-value-of-hp.patch

diff --git 
a/meta/recipes-core/glibc/glibc/0001-gethostid.c-check-the-value-of-hp.patch 
b/meta/recipes-core/glibc/glibc/0001-gethostid.c-check-the-value-of-hp.patch
new file mode 100644
index 00..04d1662361
--- /dev/null
+++ b/meta/recipes-core/glibc/glibc/0001-gethostid.c-check-the-value-of-hp.patch
@@ -0,0 +1,75 @@
+From 84cc79a003cf1a29e0a45ee76b67a3800d9e412e Mon Sep 17 00:00:00 2001
+From: Mingli Yu 
+Date: Tue, 18 Sep 2018 07:29:27 +
+Subject: [PATCH] gethostid.c: check the value of hp
+
+Fix Segmentation fault in gethostid.c
+
+When run test program hostid, it encounters
+Segmentation fault as hp is NULL.
+
+  # cat /mybuild/hostid.c
+  #include 
+  #include 
+
+  int
+  main(int argc, char *argv[])
+  {
+long hostid;
+hostid = gethostid();
+printf("the hostid is %ld\n", hostid);
+  }
+ 
+  # gcc -o /mybuild/hostid /mybuild/hostid.c
+  # /mybuild/hostid
+  Segmentation fault
+  # gdb /mybuild/hostid
+  GNU gdb (GDB) 8.2
+  Copyright (C) 2018 Free Software Foundation, Inc.
+  License GPLv3+: GNU GPL version 3 or later 
+  This is free software: you are free to change and redistribute it.
+  There is NO WARRANTY, to the extent permitted by law.
+  Type "show copying" and "show warranty" for details.
+  This GDB was configured as "x86_64-wrs-linux".
+  Type "show configuration" for configuration details.
+  For bug reporting instructions, please see:
+  .
+  Find the GDB manual and other documentation resources online at:
+  .
+ 
+   For help, type "help".
+   Type "apropos word" to search for commands related to "word"...
+   Reading symbols from /mybuild/hostid...done.
+   (gdb) r
+   Starting program: /mybuild/hostid
+ 
+   Program received signal SIGSEGV, Segmentation fault.
+   0x77f0330e in gethostid () at 
../sysdeps/unix/sysv/linux/gethostid.c:125
+   125  memcpy (, hp->h_addr,
+   (gdb) bt
+#0  0x77f0330e in gethostid () at 
../sysdeps/unix/sysv/linux/gethostid.c:125
+#1  0x5159 in main ()
+
+Upstream-Status: 
Submitted[https://sourceware.org/bugzilla/show_bug.cgi?id=23679]
+
+Signed-off-by: Mingli Yu 
+---
+ sysdeps/unix/sysv/linux/gethostid.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/sysdeps/unix/sysv/linux/gethostid.c 
b/sysdeps/unix/sysv/linux/gethostid.c
+index 2e20f034dc..5904b61c40 100644
+--- a/sysdeps/unix/sysv/linux/gethostid.c
 b/sysdeps/unix/sysv/linux/gethostid.c
+@@ -102,7 +102,7 @@ gethostid (void)
+ {
+   int ret = __gethostbyname_r (hostname, ,
+  tmpbuf.data, tmpbuf.length, , );
+-  if (ret == 0)
++  if (ret == 0 && hp != NULL)
+   break;
+   else
+   {
+-- 
+2.13.3
+
diff --git a/meta/recipes-core/glibc/glibc_2.28.bb 
b/meta/recipes-core/glibc/glibc_2.28.bb
index 0ebbaf9610..0a8fa0c25f 100644
--- a/meta/recipes-core/glibc/glibc_2.28.bb
+++ b/meta/recipes-core/glibc/glibc_2.28.bb
@@ -45,6 +45,7 @@ SRC_URI = "${GLIBC_GIT_URI};branch=${SRCBRANCH};name=glibc \

Re: [OE-core] [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that.

[Marek Vasut]

On 09/18/2018 11:40 AM, Leon Woestenberg wrote:
> Hi Alex,

Hi,

> Adding Marek Vasut, original author of kernel-fitimage.bbclass.
> 
>> I guess the reason that the deployment happens in kernel.bbclass is so
>> you only have all the symlinking logic in one place
> 
> The deployment happens in both kernel.bbclass and
> kernel-fitimage.bbclass. That was exactly one of the bugs I wanted to
> solve. I am not sure what the intention was, though.
> 
> Marek: can you comment of the exact purpose of the deploy task in
> kernel-fitimage.bbclass?
> Which class should deploy the FIT images themselves?

It seems to have to do with deploying of the ITS files and the symlinks
for then .

It's hard to make any sense from the discussion below due to the
constant top-posting and mixing of email history, so I'll just not do
that, sorry.

What bug is it that you're seeing ?

> Whilst cleaning things up, my understanding was that
> kernel_do_deploy_append() in kernel-fitimage.bbclass deploys the
> fitImages, along with the .its file etc.
> Maybe I was mistaken.

That's the case, yes.

> I have several other fixed piled up; for example initramfs's supposed to
> get bundled inside the kernel get also packed into the FIT; this takes
> double the amount of space in the FIT image...
> 
> Regards,
> 
> Leon.
> 
> 
> 
> 
> On Tue, Sep 18, 2018 at 8:10 AM Alex Kiernan  > wrote:
> 
> Thanks Leon
> 
> I guess the reason that the deployment happens in kernel.bbclass is so
> you only have all the symlinking logic in one place.
> 
> Are in agreement that this change should be reverted and the
> "fitImage" deployed here:
> 
> 
> http://git.openembedded.org/openembedded-core/tree/meta/classes/kernel-fitimage.bbclass#n495
> 
> is the one which we should remove?
> On Mon, Sep 17, 2018 at 7:05 PM Leon Woestenberg
> mailto:l...@sidebranch.com>> wrote:
> >
> > Hi Alex,
> >
> > I expected it to be kernel-fitimage.bbclass’s responsibility to
> deploy the fitImage.
> >
> > Regards, Leon
> >
> >
> >
> >
> > On 16 Sep 2018, at 16:22, Alex Kiernan  > wrote:
> >
> > On Sun, Sep 16, 2018 at 11:41 AM Alex Kiernan
> mailto:alex.kier...@gmail.com>> wrote:
> >
> >
> > Hi Leon
> >
> >
> > On Sun, Sep 16, 2018 at 10:18 AM Leon Woestenberg
> mailto:l...@sidebranch.com>> wrote:
> >
> >
> > Hi Alex,
> >
> >
> > On 15 Sep 2018, at 19:45, Alex Kiernan  > wrote:
> >
> >
> > On Mon, Sep 10, 2018 at 10:57 PM Leon Woestenberg
> mailto:l...@sidebranch.com>> wrote:
> >
> >
> > kernel-fitimage.bbclass replaces an occurance of "fitImage" in
> >
> > KERNEL_IMAGETYPE_FOR_MAKE by an image type that is buildable for the
> >
> > architecture (such as zImage). The kernel-fitimage.bbclass packs that
> >
> > image as sub-image in a flattened image tree image (fitImage) and
> >
> > deploys this fitImage along with the image tree source file (.its).
> >
> >
> > kernel-fitimage.bbclass does not alter KERNEL_IMAGETYPES, which thus
> >
> > also contains "fitImage", which kernel.bbclass will also deploy
> >
> > redundantly with different naming.
> >
> >
> > The result is a dual deployment with slightly different naming,
> >
> > each with a set of symlinks.
> >
> >
> > The solution chosen is to have fitImage deployment be handled by
> >
> > kernel-fitimage.bbclass, and have kernel.bbclass ignore fitImage
> >
> > types during deployment.
> >
> >
> > Signed-off-by: Leon Woestenberg  >
> >
> >
> > This looks completely plausible, but the two "FIT" images that are
> >
> > installed aren't identical... after this I end up with no FIT image
> >
> > and only a bare image in the deploy dir.
> >
> >
> > What was in your KERNEL_IMAGETYPES? Did it at least contain
> “fitImage”??
> >
> >
> >
> > Yes, in fact only fitImage (and no initramfs).
> >
> >
> > Digging into it, the logic between the two classes is a bit odd... in
> >
> > the case of a non initramfs build, the fitImage is actually installed
> >
> > here.
> >
> >
> > If ‘here’ means kernel-fitimage, then I’ld say ALL versions of a
> FIT image containing AT LEAST a Linux kernel are installed by
> kernel-fitimage.
> >
> >
> > The one that's installed in kernel-fitimage is the bare
> >
> > linux.bin, but named fitImage-...
> >
> >
> > which is totally broken. If you want the bare kernel binary (which
> naming depends on architecture, so it should NOT be hard-coded to
> linux.bin anyway), you would need to specify that type *also* in
> KERNEL_IMAGETYPES, next to “fitImage”.

[OE-core] [PATCH] glibc: fix Segmentation fault in gethostid.c

[mingli.yu]

From: Mingli Yu 

When run test program hostid, it encounters
Segmentation fault as hp is NULL.

 # cat /mybuild/hostid.c
 #include 
 #include 

 int
 main(int argc, char *argv[])
 {
long hostid;
hostid = gethostid();
printf("the hostid is %ld\n", hostid);

 }

 # gcc -o /mybuild/hostid /mybuild/hostid.c
 # /mybuild/hostid
 Segmentation fault
 # gdb /mybuild/hostid
 GNU gdb (GDB) 8.2
 Copyright (C) 2018 Free Software Foundation, Inc.
 License GPLv3+: GNU GPL version 3 or later 
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.
 Type "show copying" and "show warranty" for details.
 This GDB was configured as "x86_64-wrs-linux".
 Type "show configuration" for configuration details.
 For bug reporting instructions, please see:
 .
 Find the GDB manual and other documentation resources online at:
.

 For help, type "help".
 Type "apropos word" to search for commands related to "word"...
 Reading symbols from /root/hostid...done.
 (gdb) r
 Starting program: /root/hostid

 Program received signal SIGSEGV, Segmentation fault.
 0x77f0330e in gethostid () at 
../sysdeps/unix/sysv/linux/gethostid.c:125
 125  memcpy (, hp->h_addr,
 (gdb) bt
 #0  0x77f0330e in gethostid () at 
../sysdeps/unix/sysv/linux/gethostid.c:125
 #1  0x5159 in main ()

Signed-off-by: Mingli Yu 
---
 .../0001-gethostid.c-check-the-value-of-hp.patch   | 75 ++
 meta/recipes-core/glibc/glibc_2.28.bb  |  1 +
 2 files changed, 76 insertions(+)
 create mode 100644 
meta/recipes-core/glibc/glibc/0001-gethostid.c-check-the-value-of-hp.patch

diff --git 
a/meta/recipes-core/glibc/glibc/0001-gethostid.c-check-the-value-of-hp.patch 
b/meta/recipes-core/glibc/glibc/0001-gethostid.c-check-the-value-of-hp.patch
new file mode 100644
index 00..c0cd003330
--- /dev/null
+++ b/meta/recipes-core/glibc/glibc/0001-gethostid.c-check-the-value-of-hp.patch
@@ -0,0 +1,75 @@
+From 84cc79a003cf1a29e0a45ee76b67a3800d9e412e Mon Sep 17 00:00:00 2001
+From: Mingli Yu 
+Date: Tue, 18 Sep 2018 07:29:27 +
+Subject: [PATCH] gethostid.c: check the value of hp
+
+Fix Segmentation fault in gethostid.c
+
+When run test program hostid, it encounters
+Segmentation fault as hp is NULL.
+
+  # cat /mybuild/hostid.c
+  #include 
+  #include 
+
+  int
+  main(int argc, char *argv[])
+  {
+long hostid;
+hostid = gethostid();
+printf("the hostid is %ld\n", hostid);
+  }
+ 
+  # gcc -o /mybuild/hostid /mybuild/hostid.c
+  # /mybuild/hostid
+  Segmentation fault
+  # gdb /mybuild/hostid
+  GNU gdb (GDB) 8.2
+  Copyright (C) 2018 Free Software Foundation, Inc.
+  License GPLv3+: GNU GPL version 3 or later 
+  This is free software: you are free to change and redistribute it.
+  There is NO WARRANTY, to the extent permitted by law.
+  Type "show copying" and "show warranty" for details.
+  This GDB was configured as "x86_64-wrs-linux".
+  Type "show configuration" for configuration details.
+  For bug reporting instructions, please see:
+  .
+  Find the GDB manual and other documentation resources online at:
+  .
+ 
+   For help, type "help".
+   Type "apropos word" to search for commands related to "word"...
+   Reading symbols from /root/hostid...done.
+   (gdb) r
+   Starting program: /root/hostid
+ 
+   Program received signal SIGSEGV, Segmentation fault.
+   0x77f0330e in gethostid () at 
../sysdeps/unix/sysv/linux/gethostid.c:125
+   125  memcpy (, hp->h_addr,
+   (gdb) bt
+#0  0x77f0330e in gethostid () at 
../sysdeps/unix/sysv/linux/gethostid.c:125
+#1  0x5159 in main ()
+
+Upstream-Status: 
Submitted[https://sourceware.org/bugzilla/show_bug.cgi?id=23679]
+
+Signed-off-by: Mingli Yu 
+---
+ sysdeps/unix/sysv/linux/gethostid.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/sysdeps/unix/sysv/linux/gethostid.c 
b/sysdeps/unix/sysv/linux/gethostid.c
+index 2e20f034dc..5904b61c40 100644
+--- a/sysdeps/unix/sysv/linux/gethostid.c
 b/sysdeps/unix/sysv/linux/gethostid.c
+@@ -102,7 +102,7 @@ gethostid (void)
+ {
+   int ret = __gethostbyname_r (hostname, ,
+  tmpbuf.data, tmpbuf.length, , );
+-  if (ret == 0)
++  if (ret == 0 && hp != NULL)
+   break;
+   else
+   {
+-- 
+2.13.3
+
diff --git a/meta/recipes-core/glibc/glibc_2.28.bb 
b/meta/recipes-core/glibc/glibc_2.28.bb
index 0ebbaf9610..0a8fa0c25f 100644
--- a/meta/recipes-core/glibc/glibc_2.28.bb
+++ b/meta/recipes-core/glibc/glibc_2.28.bb
@@ -45,6 +45,7 @@ SRC_URI = "${GLIBC_GIT_URI};branch=${SRCBRANCH};name=glibc \

file://0028-bits-siginfo-consts.h-enum-definition-for-TRAP_HWBKP.patch \
   

Re: [OE-core] [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that.

[Leon Woestenberg]

Hi Alex,

Adding Marek Vasut, original author of kernel-fitimage.bbclass.

> I guess the reason that the deployment happens in kernel.bbclass is so
> you only have all the symlinking logic in one place

The deployment happens in both kernel.bbclass and kernel-fitimage.bbclass.
That was exactly one of the bugs I wanted to solve. I am not sure what the
intention was, though.

Marek: can you comment of the exact purpose of the deploy task in
kernel-fitimage.bbclass?
Which class should deploy the FIT images themselves?

Whilst cleaning things up, my understanding was that
kernel_do_deploy_append() in kernel-fitimage.bbclass deploys the fitImages,
along with the .its file etc.
Maybe I was mistaken.

I have several other fixed piled up; for example initramfs's supposed to
get bundled inside the kernel get also packed into the FIT; this takes
double the amount of space in the FIT image...

Regards,

Leon.




On Tue, Sep 18, 2018 at 8:10 AM Alex Kiernan  wrote:

> Thanks Leon
>
> I guess the reason that the deployment happens in kernel.bbclass is so
> you only have all the symlinking logic in one place.
>
> Are in agreement that this change should be reverted and the
> "fitImage" deployed here:
>
>
> http://git.openembedded.org/openembedded-core/tree/meta/classes/kernel-fitimage.bbclass#n495
>
> is the one which we should remove?
> On Mon, Sep 17, 2018 at 7:05 PM Leon Woestenberg 
> wrote:
> >
> > Hi Alex,
> >
> > I expected it to be kernel-fitimage.bbclass’s responsibility to deploy
> the fitImage.
> >
> > Regards, Leon
> >
> >
> >
> >
> > On 16 Sep 2018, at 16:22, Alex Kiernan  wrote:
> >
> > On Sun, Sep 16, 2018 at 11:41 AM Alex Kiernan 
> wrote:
> >
> >
> > Hi Leon
> >
> >
> > On Sun, Sep 16, 2018 at 10:18 AM Leon Woestenberg 
> wrote:
> >
> >
> > Hi Alex,
> >
> >
> > On 15 Sep 2018, at 19:45, Alex Kiernan  wrote:
> >
> >
> > On Mon, Sep 10, 2018 at 10:57 PM Leon Woestenberg 
> wrote:
> >
> >
> > kernel-fitimage.bbclass replaces an occurance of "fitImage" in
> >
> > KERNEL_IMAGETYPE_FOR_MAKE by an image type that is buildable for the
> >
> > architecture (such as zImage). The kernel-fitimage.bbclass packs that
> >
> > image as sub-image in a flattened image tree image (fitImage) and
> >
> > deploys this fitImage along with the image tree source file (.its).
> >
> >
> > kernel-fitimage.bbclass does not alter KERNEL_IMAGETYPES, which thus
> >
> > also contains "fitImage", which kernel.bbclass will also deploy
> >
> > redundantly with different naming.
> >
> >
> > The result is a dual deployment with slightly different naming,
> >
> > each with a set of symlinks.
> >
> >
> > The solution chosen is to have fitImage deployment be handled by
> >
> > kernel-fitimage.bbclass, and have kernel.bbclass ignore fitImage
> >
> > types during deployment.
> >
> >
> > Signed-off-by: Leon Woestenberg 
> >
> >
> > This looks completely plausible, but the two "FIT" images that are
> >
> > installed aren't identical... after this I end up with no FIT image
> >
> > and only a bare image in the deploy dir.
> >
> >
> > What was in your KERNEL_IMAGETYPES? Did it at least contain “fitImage”??
> >
> >
> >
> > Yes, in fact only fitImage (and no initramfs).
> >
> >
> > Digging into it, the logic between the two classes is a bit odd... in
> >
> > the case of a non initramfs build, the fitImage is actually installed
> >
> > here.
> >
> >
> > If ‘here’ means kernel-fitimage, then I’ld say ALL versions of a FIT
> image containing AT LEAST a Linux kernel are installed by kernel-fitimage.
> >
> >
> > The one that's installed in kernel-fitimage is the bare
> >
> > linux.bin, but named fitImage-...
> >
> >
> > which is totally broken. If you want the bare kernel binary (which
> naming depends on architecture, so it should NOT be hard-coded to linux.bin
> anyway), you would need to specify that type *also* in KERNEL_IMAGETYPES,
> next to “fitImage”.
> >
> >
> > Totally agree...
> >
> >
> >
> > I'll send a patch reverting this and removing the other one as I'd
> >
> > agree that it appears to have no purpose (and if you did want it, I
> >
> > guess you could list it in KERNEL_IMAGETYPES).
> >
> >
> > I’m sorry I cannot follow what this and the other one is, and it. Let’s
> first understand all cases correctly.
> >
> >
> >
> > Sorry I've not described it well... the code in
> >
> > kernel-fitimage.bbclass that inserts the kernel into the its happens
> >
> > here
> http://git.openembedded.org/openembedded-core/tree/meta/classes/kernel-fitimage.bbclass#n371
> >
> >
> > fitimage_emit_section_kernel ${1} "${kernelcount}" linux.bin
> "${linux_comp}"
> >
> >
> > inside fitimage_emit_section_kernel we create a kernel section which
> >
> > has `data = /incbin/("${3}");` so linux.bin is our bare image.
> >
> >
> > Then we have the installation of fitImage-linux-bin that happens here
> >
> >
> http://git.openembedded.org/openembedded-core/tree/meta/classes/kernel-fitimage.bbclass#n495
> >
> >
> > echo "Copying linux.bin file..."
> >
> > install -m 0644 

[OE-core] [PATCHv2] testexport: Add support for testcase utils

[Erik Botö]

Add the possibility to ship a lib/oeqa/runtime/cases/utils directory
that will be included in the generated testexport tarball.

This makes it easier to split common functionality from test suites
into modules that can be imported from multiple test suites.

Signed-off-by: Erik Botö 
---
 meta/classes/testexport.bbclass | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/meta/classes/testexport.bbclass b/meta/classes/testexport.bbclass
index d070f07afa..790ca3aff0 100644
--- a/meta/classes/testexport.bbclass
+++ b/meta/classes/testexport.bbclass
@@ -74,6 +74,21 @@ def testexport_main(d):
 
 copy_needed_files(d, tc)
 
+def get_runtime_cases_utils_paths(d):
+"""
+Returns a list of paths where testcase utils must reside. Utils can be e.g.
+common functionality used by multiple test cases.
+
+Testcase utils are expected in /lib/oeqa/runtime/cases/utils/
+"""
+paths = []
+
+for layer in d.getVar('BBLAYERS').split():
+path = os.path.join(layer, 'lib/oeqa/runtime/cases/utils')
+if os.path.isdir(path):
+paths.append(path)
+return paths
+
 def copy_needed_files(d, tc):
 import shutil
 import oe.path
@@ -121,6 +136,14 @@ def copy_needed_files(d, tc):
 if json_file:
 shutil.copy2(json_file, cases_path)
 
+# Copy cases/utils provided by layers
+utils_dest_path = os.path.join(export_path, 'lib', 'oeqa', 'runtime', 
'cases', 'utils')
+utils_source_paths = get_runtime_cases_utils_paths(d)
+
+for f in utils_source_paths:
+if os.path.isdir(f):
+oe.path.copytree(f, utils_dest_path)
+
 # Copy test data
 image_name = ("%s/%s" % (d.getVar('DEPLOY_DIR_IMAGE'),
 d.getVar('IMAGE_LINK_NAME')))
-- 
2.19.0.rc1

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

[OE-core] ✗ patchtest: failure for testexport: Add support for testcase utils

[Patchwork]

== Series Details ==

Series: testexport: Add support for testcase utils
Revision: 1
URL   : https://patchwork.openembedded.org/series/14113/
State : failure

== Summary ==


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



* Patchtestexport: Add support for testcase utils
 Issue Patch is missing Signed-off-by [test_signed_off_by_presence] 
  Suggested fixSign off the patch (either manually or with "git commit 
--amend -s")



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

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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

[OE-core] [PATCH] testexport: Add support for testcase utils

[Erik Botö]

Add the possibility to ship a lib/oeqa/runtime/cases/utils directory
that will be included in the generated testexport tarball.

This makes it easier to split common functionality from test suites
into modules that can be imported from multiple test suites.
---
 meta/classes/testexport.bbclass | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/meta/classes/testexport.bbclass b/meta/classes/testexport.bbclass
index d070f07afa..e67e5842d6 100644
--- a/meta/classes/testexport.bbclass
+++ b/meta/classes/testexport.bbclass
@@ -74,6 +74,21 @@ def testexport_main(d):
 
 copy_needed_files(d, tc)
 
+def get_runtime_cases_utils_paths(d):
+"""
+Returns a list of paths where testcase utils must reside. Utils can be e.g.
+common functionality used by multiple test cases.
+
+Testcase utils are expected in /lib/oeqa/runtime/cases/utils/
+"""
+paths = []
+
+for layer in d.getVar('BBLAYERS').split():
+path = os.path.join(layer, 'lib/oeqa/runtime/cases/utils')
+if os.path.isdir(path):
+paths.append(path)
+return paths
+
 def copy_needed_files(d, tc):
 import shutil
 import oe.path
@@ -108,6 +123,8 @@ def copy_needed_files(d, tc):
 else:
 shutil.copy2(src, dst)
 
+
+
 # Remove cases and just copy the ones specified
 cases_path = os.path.join(export_path, 'lib', 'oeqa', 'runtime', 'cases')
 oe.path.remove(cases_path)
@@ -121,6 +138,15 @@ def copy_needed_files(d, tc):
 if json_file:
 shutil.copy2(json_file, cases_path)
 
+
+# Copy cases/utils provided by layers
+utils_dest_path = os.path.join(export_path, 'lib', 'oeqa', 'runtime', 
'cases', 'utils')
+utils_source_paths = get_runtime_cases_utils_paths(d)
+
+for f in utils_source_paths:
+if os.path.isdir(f):
+oe.path.copytree(f, utils_dest_path)
+
 # Copy test data
 image_name = ("%s/%s" % (d.getVar('DEPLOY_DIR_IMAGE'),
 d.getVar('IMAGE_LINK_NAME')))
-- 
2.19.0.rc1

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

[OE-core] [PATCH] gdb: gdbserver: update ctrl-c handling

[Zhixiong Chi]

A) gdbserver sends SIGINT not to the process, but to the process
group (-signal_pid). But the attached process is not always a
process group leader. If not, "kill (-signal_pid, SIGINT)" returns
error and fails to interrupt the attached process. We cannot interrupt
the process attached with gdbserver who is not a process group leader.

This problem was created by the gdb upstream commit 78708b7c8c
The commit fixed the following case B) bug.
B) We cannot interrupt the process attached with gdbserver whose
main thread exits (pthread_exit()).

Now this patch can solve both A) and B).

Signed-off-by: Zhixiong Chi 
---
 meta/recipes-devtools/gdb/gdb-8.2.inc |  1 +
 .../gdb/gdb/gdbserver-ctrl-c-handling.patch   | 26 +++
 2 files changed, 27 insertions(+)
 create mode 100644 
meta/recipes-devtools/gdb/gdb/gdbserver-ctrl-c-handling.patch

diff --git a/meta/recipes-devtools/gdb/gdb-8.2.inc 
b/meta/recipes-devtools/gdb/gdb-8.2.inc
index 999fdde031..dfb0059123 100644
--- a/meta/recipes-devtools/gdb/gdb-8.2.inc
+++ b/meta/recipes-devtools/gdb/gdb-8.2.inc
@@ -16,6 +16,7 @@ SRC_URI = "http://ftp.gnu.org/gnu/gdb/gdb-${PV}.tar.xz \
file://0009-Change-order-of-CFLAGS.patch \
file://0010-resolve-restrict-keyword-conflict.patch \
file://0011-Fix-invalid-sigprocmask-call.patch \
+   file://gdbserver-ctrl-c-handling.patch \
 "
 SRC_URI[md5sum] = "b5a49dbff00d9a87fbe114d14b3101c0"
 SRC_URI[sha256sum] = 
"c3a441a29c7c89720b734e5a9c6289c0a06be7e0c76ef538f7bbcef389347c39"
diff --git a/meta/recipes-devtools/gdb/gdb/gdbserver-ctrl-c-handling.patch 
b/meta/recipes-devtools/gdb/gdb/gdbserver-ctrl-c-handling.patch
new file mode 100644
index 00..d1ff5a5d75
--- /dev/null
+++ b/meta/recipes-devtools/gdb/gdb/gdbserver-ctrl-c-handling.patch
@@ -0,0 +1,26 @@
++This problem was created by the upstream commit 78708b7c8c
++After applying the commit, it will send SIGINT to the process 
group(-signal_pid).
++But if we use gdbserver send SIGINT, and the attached process is not a process
++group leader, then the "kill (-signal_pid, SIGINT)" returns error and fails  
to
++interrupt the attached process.
++
++Upstream-Status: Pending
++
++Author: Josh Gao
++cherry-picked patch from https://sourceware.org/bugzilla/show_bug.cgi?id=18945
++Signed-off-by: Zhixiong Chi 
+Index: gdb-8.2/gdb/gdbserver/linux-low.c
+===
+--- gdb-8.2.orig/gdb/gdbserver/linux-low.c
 gdb-8.2/gdb/gdbserver/linux-low.c
+@@ -5940,9 +5940,7 @@ linux_look_up_symbols (void)
+ static void
+ linux_request_interrupt (void)
+ {
+-  /* Send a SIGINT to the process group.  This acts just like the user
+- typed a ^C on the controlling terminal.  */
+-  kill (-signal_pid, SIGINT);
++  kill (signal_pid, SIGINT);
+ }
+ 
+ /* Copy LEN bytes from inferior's auxiliary vector starting at OFFSET
-- 
2.17.1

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

[OE-core] [PATCH] maintainers.inc: Update package owners

[Maxin B. John]

update Intel owners

Signed-off-by: Maxin B. John 
---
 meta/conf/distro/include/maintainers.inc | 248 +++
 1 file changed, 124 insertions(+), 124 deletions(-)

diff --git a/meta/conf/distro/include/maintainers.inc 
b/meta/conf/distro/include/maintainers.inc
index 0c65e8f..c32a441 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -29,27 +29,27 @@
 #
 RECIPE_MAINTAINER_pn-acl = "Chen Qi "
 RECIPE_MAINTAINER_pn-acpica = "Fathi Boudra "
-RECIPE_MAINTAINER_pn-acpid = "Maxin B. John "
-RECIPE_MAINTAINER_pn-adwaita-icon-theme = "Maxin B. John 
"
+RECIPE_MAINTAINER_pn-acpid = "Ross Burton "
+RECIPE_MAINTAINER_pn-adwaita-icon-theme = "Ross Burton "
 RECIPE_MAINTAINER_pn-alsa-lib = "Tanu Kaskinen "
 RECIPE_MAINTAINER_pn-alsa-plugins = "Tanu Kaskinen "
 RECIPE_MAINTAINER_pn-alsa-state = "Tanu Kaskinen "
 RECIPE_MAINTAINER_pn-alsa-tools = "Tanu Kaskinen "
 RECIPE_MAINTAINER_pn-alsa-utils = "Tanu Kaskinen "
 RECIPE_MAINTAINER_pn-alsa-utils-scripts = "Tanu Kaskinen "
-RECIPE_MAINTAINER_pn-apmd = "Maxin B. John "
+RECIPE_MAINTAINER_pn-apmd = "Ross Burton "
 RECIPE_MAINTAINER_pn-apr = "Hongxu Jia "
 RECIPE_MAINTAINER_pn-apr-util = "Hongxu Jia "
 RECIPE_MAINTAINER_pn-apt = "Aníbal Limón "
 RECIPE_MAINTAINER_pn-apt-native = "Aníbal Limón "
 RECIPE_MAINTAINER_pn-argp-standalone = "Khem Raj "
 RECIPE_MAINTAINER_pn-asciidoc = "Yi Zhao "
-RECIPE_MAINTAINER_pn-aspell = "Maxin B. John "
-RECIPE_MAINTAINER_pn-assimp = "Maxin B. John "
+RECIPE_MAINTAINER_pn-aspell = "Ross Burton "
+RECIPE_MAINTAINER_pn-assimp = "Ross Burton "
 RECIPE_MAINTAINER_pn-at = "Chen Qi "
-RECIPE_MAINTAINER_pn-at-spi2-atk = "Maxin B. John "
-RECIPE_MAINTAINER_pn-at-spi2-core = "Maxin B. John "
-RECIPE_MAINTAINER_pn-atk = "Maxin B. John "
+RECIPE_MAINTAINER_pn-at-spi2-atk = "Ross Burton "
+RECIPE_MAINTAINER_pn-at-spi2-core = "Ross Burton "
+RECIPE_MAINTAINER_pn-atk = "Ross Burton "
 RECIPE_MAINTAINER_pn-attr = "Chen Qi "
 RECIPE_MAINTAINER_pn-autoconf = "Robert Yang "
 RECIPE_MAINTAINER_pn-autoconf-archive = "Robert Yang 
"
@@ -71,7 +71,7 @@ RECIPE_MAINTAINER_pn-bison = "Chen Qi "
 RECIPE_MAINTAINER_pn-bjam-native = "Alexander Kanavin "
 RECIPE_MAINTAINER_pn-blktool = "Yi Zhao "
 RECIPE_MAINTAINER_pn-blktrace = "Alexander Kanavin "
-RECIPE_MAINTAINER_pn-bluez5 = "Maxin B. John "
+RECIPE_MAINTAINER_pn-bluez5 = "Ross Burton "
 RECIPE_MAINTAINER_pn-bmap-tools = "Ross Burton "
 RECIPE_MAINTAINER_pn-boost = "Alexander Kanavin "
 RECIPE_MAINTAINER_pn-bootchart2 = "Alexander Kanavin "
@@ -86,29 +86,29 @@ RECIPE_MAINTAINER_pn-busybox = "Andrej Valek 
"
 RECIPE_MAINTAINER_pn-busybox-inittab = "Denys Dmytriyenko "
 RECIPE_MAINTAINER_pn-bzip2 = "Denys Dmytriyenko "
 RECIPE_MAINTAINER_pn-ca-certificates = "Alexander Kanavin 
"
-RECIPE_MAINTAINER_pn-cairo = "Maxin B. John "
+RECIPE_MAINTAINER_pn-cairo = "Ross Burton "
 RECIPE_MAINTAINER_pn-cantarell-fonts = "Alexander Kanavin 
"
 RECIPE_MAINTAINER_pn-ccache = "Robert Yang "
 RECIPE_MAINTAINER_pn-cdrtools-native = "Yi Zhao "
 RECIPE_MAINTAINER_pn-chkconfig = "Yi Zhao "
 RECIPE_MAINTAINER_pn-chkconfig-alternatives-native = "Yi Zhao 
"
 RECIPE_MAINTAINER_pn-chrpath = "Yi Zhao "
-RECIPE_MAINTAINER_pn-clutter-1.0 = "Maxin B. John "
-RECIPE_MAINTAINER_pn-clutter-gst-3.0 = "Maxin B. John "
-RECIPE_MAINTAINER_pn-clutter-gtk-1.0 = "Maxin B. John "
+RECIPE_MAINTAINER_pn-clutter-1.0 = "Ross Burton "
+RECIPE_MAINTAINER_pn-clutter-gst-3.0 = "Ross Burton "
+RECIPE_MAINTAINER_pn-clutter-gtk-1.0 = "Ross Burton "
 RECIPE_MAINTAINER_pn-cmake = "Otavio Salvador 
"
 RECIPE_MAINTAINER_pn-cmake-native = "Otavio Salvador 
"
-RECIPE_MAINTAINER_pn-cogl-1.0 = "Maxin B. John "
+RECIPE_MAINTAINER_pn-cogl-1.0 = "Ross Burton "
 RECIPE_MAINTAINER_pn-connman = "Changhyeok Bae "
-RECIPE_MAINTAINER_pn-connman-conf = "Maxin B. John "
-RECIPE_MAINTAINER_pn-connman-gnome = "Maxin B. John "
+RECIPE_MAINTAINER_pn-connman-conf = "Ross Burton "
+RECIPE_MAINTAINER_pn-connman-gnome = "Ross Burton "
 RECIPE_MAINTAINER_pn-console-tools = "Chen Qi "
 RECIPE_MAINTAINER_pn-consolekit = "Chen Qi "
 RECIPE_MAINTAINER_pn-coreutils = "Chen Qi "
 RECIPE_MAINTAINER_pn-cpio = "Denys Dmytriyenko "
 RECIPE_MAINTAINER_pn-cracklib = "Armin Kuster "
 RECIPE_MAINTAINER_pn-createrepo-c = "Alexander Kanavin 
"
-RECIPE_MAINTAINER_pn-cronie = "Maxin B. John "
+RECIPE_MAINTAINER_pn-cronie = "Ross Burton "
 RECIPE_MAINTAINER_pn-cross-localedef-native = "Khem Raj "
 RECIPE_MAINTAINER_pn-cryptodev-linux = "Robert Yang 
"
 RECIPE_MAINTAINER_pn-cryptodev-module = "Robert Yang 
"
@@ -116,7 +116,7 @@ RECIPE_MAINTAINER_pn-cryptodev-tests = "Robert Yang 
"
 RECIPE_MAINTAINER_pn-cups = "Chen Qi "
 RECIPE_MAINTAINER_pn-curl = "Armin Kuster "
 RECIPE_MAINTAINER_pn-cve-check-tool = "Ross Burton "
-RECIPE_MAINTAINER_pn-cwautomacros = "Maxin B. John "
+RECIPE_MAINTAINER_pn-cwautomacros = "Ross Burton "
 RECIPE_MAINTAINER_pn-db = "Mark Hatle "
 RECIPE_MAINTAINER_pn-dbus = "Chen Qi "
 RECIPE_MAINTAINER_pn-dbus-glib = 

[OE-core] [PATCH] curl: CVE-2018-14618

[Zhixiong Chi]

Backport the CVE patch from the upstream
https://github.com/curl/curl/commit/57d299a499155d4b327e341c6024e293b0418243.patch
https://curl.haxx.se/docs/CVE-2018-14618.html
https://nvd.nist.gov/vuln/detail/CVE-2018-14618

Signed-off-by: Zhixiong Chi 
---
 .../curl/curl/CVE-2018-14618.patch| 37 +++
 meta/recipes-support/curl/curl_7.61.0.bb  |  1 +
 2 files changed, 38 insertions(+)
 create mode 100644 meta/recipes-support/curl/curl/CVE-2018-14618.patch

diff --git a/meta/recipes-support/curl/curl/CVE-2018-14618.patch 
b/meta/recipes-support/curl/curl/CVE-2018-14618.patch
new file mode 100644
index 00..db07b436d3
--- /dev/null
+++ b/meta/recipes-support/curl/curl/CVE-2018-14618.patch
@@ -0,0 +1,37 @@
+From 57d299a499155d4b327e341c6024e293b0418243 Mon Sep 17 00:00:00 2001
+From: Daniel Stenberg 
+Date: Mon, 13 Aug 2018 10:35:52 +0200
+Subject: [PATCH] Curl_ntlm_core_mk_nt_hash: return error on too long password
+
+... since it would cause an integer overflow if longer than (max size_t
+/ 2).
+
+This is CVE-2018-14618
+
+Bug: https://curl.haxx.se/docs/CVE-2018-14618.html
+Closes #2756
+Reported-by: Zhaoyang Wu
+
+CVE: CVE-2018-14618
+Upstream-Status: Backport
+Signed-off-by: Zhixiong Chi 
+---
+ lib/curl_ntlm_core.c | 5 -
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/lib/curl_ntlm_core.c b/lib/curl_ntlm_core.c
+index e27cab353c..922e85a926 100644
+--- a/lib/curl_ntlm_core.c
 b/lib/curl_ntlm_core.c
+@@ -557,8 +557,11 @@ CURLcode Curl_ntlm_core_mk_nt_hash(struct Curl_easy *data,
+unsigned char *ntbuffer /* 21 bytes */)
+ {
+   size_t len = strlen(password);
+-  unsigned char *pw = len ? malloc(len * 2) : strdup("");
++  unsigned char *pw;
+   CURLcode result;
++  if(len > SIZE_T_MAX/2) /* avoid integer overflow */
++return CURLE_OUT_OF_MEMORY;
++  pw = len ? malloc(len * 2) : strdup("");
+   if(!pw)
+ return CURLE_OUT_OF_MEMORY;
diff --git a/meta/recipes-support/curl/curl_7.61.0.bb 
b/meta/recipes-support/curl/curl_7.61.0.bb
index cabfcffc62..4f408d2aaa 100644
--- a/meta/recipes-support/curl/curl_7.61.0.bb
+++ b/meta/recipes-support/curl/curl_7.61.0.bb
@@ -7,6 +7,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;beginline=8;md5=3a34942f4ae3fbf1a303160714e66
 
 SRC_URI = "http://curl.haxx.se/download/curl-${PV}.tar.bz2 \
file://0001-replace-krb5-config-with-pkg-config.patch \
+   file://CVE-2018-14618.patch \
 "
 
 SRC_URI[md5sum] = "31d0a9f48dc796a7db351898a1e5058a"
-- 
2.17.1

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

[OE-core] [PATCH v2] unzip: add nativesdk support

[Andrej Valek]

Signed-off-by: Andrej Valek 
---
 meta/recipes-extended/unzip/unzip_6.0.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-extended/unzip/unzip_6.0.bb 
b/meta/recipes-extended/unzip/unzip_6.0.bb
index a47491ea4a..b9d87dd639 100644
--- a/meta/recipes-extended/unzip/unzip_6.0.bb
+++ b/meta/recipes-extended/unzip/unzip_6.0.bb
@@ -60,4 +60,4 @@ ALTERNATIVE_PRIORITY = "100"
 ALTERNATIVE_${PN} = "unzip"
 ALTERNATIVE_LINK_NAME[unzip] = "${bindir}/unzip"
 
-BBCLASSEXTEND = "native"
+BBCLASSEXTEND = "native nativesdk"
-- 
2.11.0

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

Re: [OE-core] [PATCH v3] kernel.bbclass: do not deploy fitImage; kernel-fitimage.bbclass does that.

[Alex Kiernan]

Thanks Leon

I guess the reason that the deployment happens in kernel.bbclass is so
you only have all the symlinking logic in one place.

Are in agreement that this change should be reverted and the
"fitImage" deployed here:

http://git.openembedded.org/openembedded-core/tree/meta/classes/kernel-fitimage.bbclass#n495

is the one which we should remove?
On Mon, Sep 17, 2018 at 7:05 PM Leon Woestenberg  wrote:
>
> Hi Alex,
>
> I expected it to be kernel-fitimage.bbclass’s responsibility to deploy the 
> fitImage.
>
> Regards, Leon
>
>
>
>
> On 16 Sep 2018, at 16:22, Alex Kiernan  wrote:
>
> On Sun, Sep 16, 2018 at 11:41 AM Alex Kiernan  wrote:
>
>
> Hi Leon
>
>
> On Sun, Sep 16, 2018 at 10:18 AM Leon Woestenberg  wrote:
>
>
> Hi Alex,
>
>
> On 15 Sep 2018, at 19:45, Alex Kiernan  wrote:
>
>
> On Mon, Sep 10, 2018 at 10:57 PM Leon Woestenberg  wrote:
>
>
> kernel-fitimage.bbclass replaces an occurance of "fitImage" in
>
> KERNEL_IMAGETYPE_FOR_MAKE by an image type that is buildable for the
>
> architecture (such as zImage). The kernel-fitimage.bbclass packs that
>
> image as sub-image in a flattened image tree image (fitImage) and
>
> deploys this fitImage along with the image tree source file (.its).
>
>
> kernel-fitimage.bbclass does not alter KERNEL_IMAGETYPES, which thus
>
> also contains "fitImage", which kernel.bbclass will also deploy
>
> redundantly with different naming.
>
>
> The result is a dual deployment with slightly different naming,
>
> each with a set of symlinks.
>
>
> The solution chosen is to have fitImage deployment be handled by
>
> kernel-fitimage.bbclass, and have kernel.bbclass ignore fitImage
>
> types during deployment.
>
>
> Signed-off-by: Leon Woestenberg 
>
>
> This looks completely plausible, but the two "FIT" images that are
>
> installed aren't identical... after this I end up with no FIT image
>
> and only a bare image in the deploy dir.
>
>
> What was in your KERNEL_IMAGETYPES? Did it at least contain “fitImage”??
>
>
>
> Yes, in fact only fitImage (and no initramfs).
>
>
> Digging into it, the logic between the two classes is a bit odd... in
>
> the case of a non initramfs build, the fitImage is actually installed
>
> here.
>
>
> If ‘here’ means kernel-fitimage, then I’ld say ALL versions of a FIT image 
> containing AT LEAST a Linux kernel are installed by kernel-fitimage.
>
>
> The one that's installed in kernel-fitimage is the bare
>
> linux.bin, but named fitImage-...
>
>
> which is totally broken. If you want the bare kernel binary (which naming 
> depends on architecture, so it should NOT be hard-coded to linux.bin anyway), 
> you would need to specify that type *also* in KERNEL_IMAGETYPES, next to 
> “fitImage”.
>
>
> Totally agree...
>
>
>
> I'll send a patch reverting this and removing the other one as I'd
>
> agree that it appears to have no purpose (and if you did want it, I
>
> guess you could list it in KERNEL_IMAGETYPES).
>
>
> I’m sorry I cannot follow what this and the other one is, and it. Let’s first 
> understand all cases correctly.
>
>
>
> Sorry I've not described it well... the code in
>
> kernel-fitimage.bbclass that inserts the kernel into the its happens
>
> here 
> http://git.openembedded.org/openembedded-core/tree/meta/classes/kernel-fitimage.bbclass#n371
>
>
> fitimage_emit_section_kernel ${1} "${kernelcount}" linux.bin "${linux_comp}"
>
>
> inside fitimage_emit_section_kernel we create a kernel section which
>
> has `data = /incbin/("${3}");` so linux.bin is our bare image.
>
>
> Then we have the installation of fitImage-linux-bin that happens here
>
> http://git.openembedded.org/openembedded-core/tree/meta/classes/kernel-fitimage.bbclass#n495
>
>
> echo "Copying linux.bin file..."
>
> install -m 0644 ${B}/linux.bin
>
> ${DEPLOYDIR}/fitImage-linux.bin-${KERNEL_FIT_NAME}.bin
>
> ln -snf fitImage-linux.bin-${KERNEL_FIT_NAME}.bin
>
> ${DEPLOYDIR}/fitImage-linux.bin-${KERNEL_FIT_LINK_NAME}
>
>
> i.e. the bare linux.bin file which we used to pack into the FIT image,
>
> not a fitImage.
>
>
> The output FIT image from kernel-fitimage.bbclass is created here
>
> http://git.openembedded.org/openembedded-core/tree/meta/classes/kernel-fitimage.bbclass#n450
>
>
> uboot-mkimage \
>
> ${@'-D "${UBOOT_MKIMAGE_DTCOPTS}"' if len('${UBOOT_MKIMAGE_DTCOPTS}') else 
> ''} \
>
>  -f ${1} \
>
>  arch/${ARCH}/boot/${2}
>
>
> i.e. in arch/${ARCH}/boot/${2}
>
>
> It's that image which is then picked up by kernel.bbclass to install
>
> into deploydir (because KERNEL_OUTPUT_DIR ?= "arch/${ARCH}/boot"):
>
>
> for imageType in ${KERNEL_IMAGETYPES} ; do
>
>  # kernel-fitimage class deploys fitImages, skip here
>
>  if [ "$imageType" != "fitImage" ]; then
>
>base_name=${imageType}-${KERNEL_IMAGE_NAME}
>
>install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType}
>
> $deployDir/${base_name}.bin
>
>  fi
>
> done
>
>
> Only it's doesn't because of the filter against fitImage.
>
>
>
> To check I'm not seeing some strange artefact of our BSP or
> linux-ti-staging (or any other