Re: [OE-core] [PATCH] mdadm: fix gcc8 maybe-uninitialized/format-overflow warning

2019-03-19 Thread Adrian Bunk
On Tue, Mar 19, 2019 at 11:51:47PM -0400, Khem Raj wrote:
> On Fri, Mar 15, 2019 at 6:45 AM Adrian Bunk  wrote:
> >
> > On Tue, Mar 12, 2019 at 05:41:58PM +0800, changqing...@windriver.com wrote:
> > > From: Changqing Li 
> > >
> > > while compiled with -Werror=maybe-uninitialized/-Werror=format-overflow=,
> > > it failed
> > >
> > > [snip]
> > > | Incremental.c: In function 'Incremental_container':
> > > | Incremental.c:1593:3: error: 'mdfd' may be used uninitialized in this 
> > > function [-Werror=maybe-uninitialized]
> > > | close(mdfd);
> > > | ^~~
> > >
> > > [snip]
> > > super-intel.c: In function 'apply_takeover_update':
> > > | super-intel.c:9615:15: error: '%d' directive writing between 1 and 11 
> > > bytes into a region of size 7 [-Werror=format-overflow=]
> > > | " MISSING_%d", du->index);
> > > | ^~
> > >...
> >
> > I am seeing these warnings only with -Og, are you also seeing them with
> > -Og (DEBUG_OPTIMIZATION) only?
> >
> > If this is true, I would consider
> > https://sources.debian.org/src/mdadm/4.1-2/debian/patches/debian-no-Werror.diff/
> > a better workaround.
> >
> This seems a broader brush, I really dont like to relegate Werror if
> we dont have to, because it will force us
> to fix the code.

How are we getting such fixes properly reviewed?

What actually happens is that the easiest change that silences a warning 
gets applied.

And for such bogus -Og only warnings there was no problem in the code,
meaning regression risks by OE/Yocto-only patches without fixing anything.

> However, I am seeing it fail with clang now
> 
> https://errors.yoctoproject.org/Errors/Details/233618/

This is caused by the "fix" for the -Og gcc warning.

Which looks bogus, and might be harmful.

cu
Adrian

-- 

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

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


Re: [OE-core] [PATCH] mdadm: fix gcc8 maybe-uninitialized/format-overflow warning

2019-03-19 Thread Khem Raj
On Fri, Mar 15, 2019 at 6:45 AM Adrian Bunk  wrote:
>
> On Tue, Mar 12, 2019 at 05:41:58PM +0800, changqing...@windriver.com wrote:
> > From: Changqing Li 
> >
> > while compiled with -Werror=maybe-uninitialized/-Werror=format-overflow=,
> > it failed
> >
> > [snip]
> > | Incremental.c: In function 'Incremental_container':
> > | Incremental.c:1593:3: error: 'mdfd' may be used uninitialized in this 
> > function [-Werror=maybe-uninitialized]
> > | close(mdfd);
> > | ^~~
> >
> > [snip]
> > super-intel.c: In function 'apply_takeover_update':
> > | super-intel.c:9615:15: error: '%d' directive writing between 1 and 11 
> > bytes into a region of size 7 [-Werror=format-overflow=]
> > | " MISSING_%d", du->index);
> > | ^~
> >...
>
> I am seeing these warnings only with -Og, are you also seeing them with
> -Og (DEBUG_OPTIMIZATION) only?
>
> If this is true, I would consider
> https://sources.debian.org/src/mdadm/4.1-2/debian/patches/debian-no-Werror.diff/
> a better workaround.
>
This seems a broader brush, I really dont like to relegate Werror if
we dont have to, because it will force us
to fix the code. However, I am seeing it fail with clang now

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


Re: [OE-core] [PATCH 1/5] target-sdk-provides-dummy: Extend to -dev and -src packages

2019-03-19 Thread Ruslan Bilovol
On Fri, Feb 15, 2019 at 6:04 PM Richard Purdie
 wrote:
>
> This avoids errors when running populate_sdk under opkg:
>
>  * Problem 1/1:
>  *   - package busybox-dev-1.30.1-r0.core2-64 requires busybox = 1.30.1-r0, 
> but none of the providers can be installed
>  *
>  * Solution 1:
>  *   - allow deinstallation of 
> target-sdk-provides-dummy-1.0-r0.sdk-provides-dummy-target
>
>  * Solution 2:
>  *   - do not ask to install a package providing busybox-dev
>
> Signed-off-by: Richard Purdie 
> ---
>  meta/recipes-core/meta/target-sdk-provides-dummy.bb | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/meta/recipes-core/meta/target-sdk-provides-dummy.bb 
> b/meta/recipes-core/meta/target-sdk-provides-dummy.bb
> index 26716ace87b..60499f7b66a 100644
> --- a/meta/recipes-core/meta/target-sdk-provides-dummy.bb
> +++ b/meta/recipes-core/meta/target-sdk-provides-dummy.bb
> @@ -2,9 +2,17 @@ DUMMYARCH = "sdk-provides-dummy-target"
>
>  DUMMYPROVIDES = "\
>  busybox \
> +busybox-dev \
> +busybox-src \
>  coreutils \
> +coreutils-dev \
> +coreutils-src \

Does it mean coreutils can't be provided anymore in target part of SDK?

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


[OE-core] [oe-core][PATCH 0/1] qemumips64 - change tune

2019-03-19 Thread Joe Slater
If we make it mips64r2, lib32 multilib code could be the same tune as mipsqemu 
(mips32r2).
Frankly, I don't know if anybody cares, in which case, why not?

Joe Slater (1):
  qemumips64: change tune to mips64r2

 meta/conf/machine/qemumips64.conf | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

-- 
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/1] qemumips64: change tune to mips64r2

2019-03-19 Thread Joe Slater
Allows for mips32 multilib to be mips32r2, like qemumips.

Signed-off-by: Joe Slater 
---
 meta/conf/machine/qemumips64.conf | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/conf/machine/qemumips64.conf 
b/meta/conf/machine/qemumips64.conf
index a166a10..970c0ce 100644
--- a/meta/conf/machine/qemumips64.conf
+++ b/meta/conf/machine/qemumips64.conf
@@ -3,9 +3,11 @@
 #@DESCRIPTION: mti-malta64-be
 
 require conf/machine/include/qemu.inc
-require conf/machine/include/tune-mips64.inc
+require conf/machine/include/tune-mips64r2.inc
 require conf/machine/include/qemuboot-mips.inc
 
+QB_CPU = "-cpu MIPS64R2-generic"
+
 KERNEL_IMAGETYPE = "vmlinux"
 KERNEL_ALT_IMAGETYPE = "vmlinux.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 1/5] qemuarm: Swap for an arm7ve (A15) configuration

2019-03-19 Thread richard . purdie
On Tue, 2019-03-19 at 20:22 -0400, Denys Dmytriyenko wrote:
> On Mon, Mar 11, 2019 at 03:12:26AM +, Richard Purdie wrote:
> > From: Jon Mason 
> > 
> > Add new QEMU BSP for a Arm Cortex-A15 system and use this as
> > qemuarm,
> > moving the old armv5te Versatile PB based machine to qemuarmv5.
> > 
> > The new machine uses the QEMU virt machine type, which should be
> > faster to emulate and updates the qemuarm support to a modern
> > architecture.
> > 
> > Signed-off-by: Jon Mason 
> > Signed-off-by: Richard Purdie 
> > ---
> >  meta/conf/machine/qemuarm.conf| 34 +
> > --
> >  meta/conf/machine/qemuarmv5.conf  | 23 +
> >  .../linux/linux-yocto-rt_4.19.bb  |  2 +-
> >  .../linux/linux-yocto-rt_5.0.bb   |  2 +-
> >  .../linux/linux-yocto-tiny_4.19.bb|  2 +-
> >  .../linux/linux-yocto-tiny_5.0.bb |  2 +-
> >  meta/recipes-kernel/linux/linux-yocto_4.19.bb |  2 +-
> >  meta/recipes-kernel/linux/linux-yocto_5.0.bb  |  2 +-
> >  8 files changed, 52 insertions(+), 17 deletions(-)
> >  create mode 100644 meta/conf/machine/qemuarmv5.conf
> > 
> > diff --git a/meta/conf/machine/qemuarm.conf
> > b/meta/conf/machine/qemuarm.conf
> > index a5443126273..95550461899 100644
> > --- a/meta/conf/machine/qemuarm.conf
> > +++ b/meta/conf/machine/qemuarm.conf
> ...
> > +KMACHINE_qemuarmv5 = "qemuarm"
> > \ No newline at end of file
> > diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb
> > b/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb
> > index 07dc5b77a14..36761b99437 100644
> > --- a/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb
> > +++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb
> > @@ -31,7 +31,7 @@ KCONF_BSP_AUDIT_LEVEL = "2"
> >  
> >  LINUX_KERNEL_TYPE = "preempt-rt"
> >  
> > -COMPATIBLE_MACHINE = "(qemux86|qemux86-
> > 64|qemuarm|qemuarm64|qemuppc|qemumips)"
> > +COMPATIBLE_MACHINE = "(qemux86|qemux86-
> > 64|qemuarm|qemuarma15|qemuarm64|qemuppc|qemumips)"
> 
> Did you mean to list here "qemuarmv5" instead of "qemuarma15"?

Yes!

> > @@ -40,7 +40,7 @@ KCONF_BSP_AUDIT_LEVEL = "2"
> >  
> >  KERNEL_DEVICETREE_qemuarm = "versatile-pb.dtb"
> >  
> > -COMPATIBLE_MACHINE =
> > "qemuarm|qemuarm64|qemux86|qemuppc|qemumips|qemumips64|qemux86-64"
> > +COMPATIBLE_MACHINE =
> > "qemuarm|qemuarmv5|qemuarm64|qemux86|qemuppc|qemumips|qemumips64|qe
> > mux86-64"
> 
> Ok, "qemuarmv5" - I see a pattern here! Was it a challenge? :)

It definitely was a challenge, perhaps not the way you mean it though!
:)

Patches to fix up the mess I made of this gratefully received, or I'll
sort it out tomorrow, thanks for highlighting it.

Cheers,

Richard



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


Re: [OE-core] [PATCH 1/5] qemuarm: Swap for an arm7ve (A15) configuration

2019-03-19 Thread Denys Dmytriyenko
On Mon, Mar 11, 2019 at 03:12:26AM +, Richard Purdie wrote:
> From: Jon Mason 
> 
> Add new QEMU BSP for a Arm Cortex-A15 system and use this as qemuarm,
> moving the old armv5te Versatile PB based machine to qemuarmv5.
> 
> The new machine uses the QEMU virt machine type, which should be
> faster to emulate and updates the qemuarm support to a modern
> architecture.
> 
> Signed-off-by: Jon Mason 
> Signed-off-by: Richard Purdie 
> ---
>  meta/conf/machine/qemuarm.conf| 34 +--
>  meta/conf/machine/qemuarmv5.conf  | 23 +
>  .../linux/linux-yocto-rt_4.19.bb  |  2 +-
>  .../linux/linux-yocto-rt_5.0.bb   |  2 +-
>  .../linux/linux-yocto-tiny_4.19.bb|  2 +-
>  .../linux/linux-yocto-tiny_5.0.bb |  2 +-
>  meta/recipes-kernel/linux/linux-yocto_4.19.bb |  2 +-
>  meta/recipes-kernel/linux/linux-yocto_5.0.bb  |  2 +-
>  8 files changed, 52 insertions(+), 17 deletions(-)
>  create mode 100644 meta/conf/machine/qemuarmv5.conf
> 
> diff --git a/meta/conf/machine/qemuarm.conf b/meta/conf/machine/qemuarm.conf
> index a5443126273..95550461899 100644
> --- a/meta/conf/machine/qemuarm.conf
> +++ b/meta/conf/machine/qemuarm.conf
...
> +KMACHINE_qemuarmv5 = "qemuarm"
> \ No newline at end of file
> diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb 
> b/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb
> index 07dc5b77a14..36761b99437 100644
> --- a/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb
> @@ -31,7 +31,7 @@ KCONF_BSP_AUDIT_LEVEL = "2"
>  
>  LINUX_KERNEL_TYPE = "preempt-rt"
>  
> -COMPATIBLE_MACHINE = 
> "(qemux86|qemux86-64|qemuarm|qemuarm64|qemuppc|qemumips)"
> +COMPATIBLE_MACHINE = 
> "(qemux86|qemux86-64|qemuarm|qemuarma15|qemuarm64|qemuppc|qemumips)"

Did you mean to list here "qemuarmv5" instead of "qemuarma15"?

>  
>  KERNEL_DEVICETREE_qemuarm = "versatile-pb.dtb"
>  
> diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb 
> b/meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb
> index 2350973fef2..52c289903be 100644
> --- a/meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.0.bb
> @@ -31,7 +31,7 @@ KCONF_BSP_AUDIT_LEVEL = "2"
>  
>  LINUX_KERNEL_TYPE = "preempt-rt"
>  
> -COMPATIBLE_MACHINE = 
> "(qemux86|qemux86-64|qemuarm|qemuarm64|qemuppc|qemumips)"
> +COMPATIBLE_MACHINE = 
> "(qemux86|qemux86-64|qemuarm|qemuarmv5|qemuarm64|qemuppc|qemumips)"

This one uses the correct "qemuarmv5", though.


>  KERNEL_DEVICETREE_qemuarm = "versatile-pb.dtb"
>  
> diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_4.19.bb 
> b/meta/recipes-kernel/linux/linux-yocto-tiny_4.19.bb
> index c6d1594a828..52dbabd7a47 100644
> --- a/meta/recipes-kernel/linux/linux-yocto-tiny_4.19.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.19.bb
> @@ -24,7 +24,7 @@ PV = "${LINUX_VERSION}+git${SRCPV}"
>  SRC_URI = 
> "git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \
> 
> git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.19;destsuffix=${KMETA}"
>  
> -COMPATIBLE_MACHINE = "qemux86|qemux86-64|qemuarm"
> +COMPATIBLE_MACHINE = "qemux86|qemux86-64|qemuarm|qemuarma15"

Here again looks like a typo - "qemuarma15"


>  # Functionality flags
>  KERNEL_FEATURES = ""
> diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.0.bb 
> b/meta/recipes-kernel/linux/linux-yocto-tiny_5.0.bb
> index e0a68014461..b6401199a41 100644
> --- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.0.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.0.bb
> @@ -24,7 +24,7 @@ PV = "${LINUX_VERSION}+git${SRCPV}"
>  SRC_URI = 
> "git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \
> 
> git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.0;destsuffix=${KMETA}"
>  
> -COMPATIBLE_MACHINE = "qemux86|qemux86-64|qemuarm"
> +COMPATIBLE_MACHINE = "qemux86|qemux86-64|qemuarm|qemuarmv5"

Correct "qemuarmv5" here.


>  # Functionality flags
>  KERNEL_FEATURES = ""
> diff --git a/meta/recipes-kernel/linux/linux-yocto_4.19.bb 
> b/meta/recipes-kernel/linux/linux-yocto_4.19.bb
> index 8a4355ee833..3ef26a12baa 100644
> --- a/meta/recipes-kernel/linux/linux-yocto_4.19.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto_4.19.bb
> @@ -37,7 +37,7 @@ KCONF_BSP_AUDIT_LEVEL = "2"
>  
>  KERNEL_DEVICETREE_qemuarm = "versatile-pb.dtb"
>  
> -COMPATIBLE_MACHINE = 
> "qemuarm|qemuarm64|qemux86|qemuppc|qemumips|qemumips64|qemux86-64"
> +COMPATIBLE_MACHINE = 
> "qemuarm|qemuarma15|qemuarm64|qemux86|qemuppc|qemumips|qemumips64|qemux86-64"

"qemuarma15"?


>  # Functionality flags
>  KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc"
> diff --git a/meta/recipes-kernel/linux/linux-yocto_5.0.bb 
> b/meta/recipes-kernel/linux/linux-yocto_5.0.bb
> index f2c066a1503..ae6e80c0108 100644
> --- 

Re: [OE-core] [PATCH v5 2/3] openssl: Upgrade 1.1.1a -> 1.1.1b

2019-03-19 Thread Otavio Salvador
Hello Armin,

On Tue, Mar 19, 2019 at 7:18 PM akuster808  wrote:
> On 3/19/19 9:36 AM, Otavio Salvador wrote:
> > License-Update: copyright years updated
> > Signed-off-by: Otavio Salvador 
> > ---
> >
> > Changes in v5: None
> > Changes in v4:
> > - new patch
> I don't see a patch and V5 does not mention removing patch
> >
> > Changes in v3: None
> > Changes in v2: None
> If none why V listed?

The update can be applied; the c_rehash I am not sure as even though
it is correct it changes the behavior so I'd wait for more time and if
someone complains we do that.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH v5 2/3] openssl: Upgrade 1.1.1a -> 1.1.1b

2019-03-19 Thread akuster808



On 3/19/19 9:36 AM, Otavio Salvador wrote:
> License-Update: copyright years updated
> Signed-off-by: Otavio Salvador 
> ---
>
> Changes in v5: None
> Changes in v4:
> - new patch
I don't see a patch and V5 does not mention removing patch
>
> Changes in v3: None
> Changes in v2: None
If none why V listed?

Is this update applicable to Thud?

- armin
>
>  .../openssl/{openssl_1.1.1a.bb => openssl_1.1.1b.bb}| 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>  rename meta/recipes-connectivity/openssl/{openssl_1.1.1a.bb => 
> openssl_1.1.1b.bb} (96%)
>
> diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb 
> b/meta/recipes-connectivity/openssl/openssl_1.1.1b.bb
> similarity index 96%
> rename from meta/recipes-connectivity/openssl/openssl_1.1.1a.bb
> rename to meta/recipes-connectivity/openssl/openssl_1.1.1b.bb
> index 506d6d378c..450ef930c5 100644
> --- a/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb
> +++ b/meta/recipes-connectivity/openssl/openssl_1.1.1b.bb
> @@ -7,7 +7,7 @@ SECTION = "libs/network"
>  # "openssl" here actually means both OpenSSL and SSLeay licenses apply
>  # (see meta/files/common-licenses/OpenSSL to which "openssl" is 
> SPDXLICENSEMAPped)
>  LICENSE = "openssl"
> -LIC_FILES_CHKSUM = "file://LICENSE;md5=d57d511030c9d66ef5f5966bee5a7eff"
> +LIC_FILES_CHKSUM = "file://LICENSE;md5=d343e62fc9c833710bbbed25f27364c8"
>  
>  DEPENDS = "hostperl-runtime-native"
>  
> @@ -22,8 +22,8 @@ SRC_URI_append_class-nativesdk = " \
> file://environment.d-openssl.sh \
> "
>  
> -SRC_URI[md5sum] = "963deb2272d6be7d4c2458afd2517b73"
> -SRC_URI[sha256sum] = 
> "fc20130f8b7cbd2fb918b2f14e2f429e109c31ddd0fb38fc5d71d9ffed3f9f41"
> +SRC_URI[md5sum] = "4532712e7bcc9414f5bce995e4e13930"
> +SRC_URI[sha256sum] = 
> "5c557b023230413dfb0756f3137a13e6d726838ccd1430888ad15bfb2b43ea4b"
>  
>  inherit lib_package multilib_header ptest
>  

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


[OE-core] [PATCH] goarch: Add riscv64

2019-03-19 Thread Alistair Francis
Although RISC-V 64-bit doesn't have official golang support there are
forks that now exist with at least some support and work is ongoing in
the upstream tree. In order to be able to use the goarch class add
support for RISC-V.

For more details see here:
https://github.com/golang/go/issues/27532

Signed-off-by: Alistair Francis 
---
 meta/classes/goarch.bbclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/classes/goarch.bbclass b/meta/classes/goarch.bbclass
index 39fea5e3d1..7aaf26aed1 100644
--- a/meta/classes/goarch.bbclass
+++ b/meta/classes/goarch.bbclass
@@ -68,6 +68,8 @@ def go_map_arch(a, d):
 return 'ppc64'
 elif re.match('p(pc|owerpc)(64el)', a):
 return 'ppc64le'
+elif a == 'riscv64':
+return 'riscv64'
 else:
 raise bb.parse.SkipRecipe("Unsupported CPU architecture: %s" % a)
 
-- 
2.21.0

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


Re: [OE-core] [PATCH 3/3] gdb: Do not disable lttng-ust on risc-v

2019-03-19 Thread Jonathan Rajotte-Julien
Hi Khem,

On Mon, Mar 18, 2019 at 01:11:19PM -0400, Jonathan Rajotte-Julien wrote:
> On Mon, Mar 18, 2019 at 09:58:03AM -0700, Khem Raj wrote:
> > Signed-off-by: Khem Raj 
> > ---
> >  meta/recipes-devtools/gdb/gdb-common.inc | 1 -
> >  1 file changed, 1 deletion(-)
> > 
> > diff --git a/meta/recipes-devtools/gdb/gdb-common.inc 
> > b/meta/recipes-devtools/gdb/gdb-common.inc
> > index 57bc0dc773..a07625bb8d 100644
> > --- a/meta/recipes-devtools/gdb/gdb-common.inc
> > +++ b/meta/recipes-devtools/gdb/gdb-common.inc
> > @@ -6,7 +6,6 @@ DEPENDS = "expat zlib ncurses virtual/libiconv ${LTTNGUST} 
> > bison-native"
> >  LTTNGUST = "lttng-ust"
> 
> I did not know that gdb depends on lttng-ust, I know gdb can depend on
> libbabeltrace*. I'll check that a bit more.

Gdb can indeed depend on lttng-ust for gdbserver for tracpoint.

This answer my question.

> 
> Cheers.
> 
> >  LTTNGUST_arc = ""
> >  LTTNGUST_aarch64 = ""
> > -LTTNGUST_riscv64 = ""
> >  LTTNGUST_mipsarch = ""
> >  LTTNGUST_sh4 = ""
> >  LTTNGUST_libc-musl = ""
> > -- 
> > 2.21.0
> > 
> > -- 
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> 
> -- 
> Jonathan Rajotte-Julien
> EfficiOS
> -- 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

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


[OE-core] [PATCH] u-boot: install dumpimage and fit_check_sign in u-boot-tools

2019-03-19 Thread luca . boccassi
From: Luca Boccassi 

Dumpimage and fit_check_sign can be used to extract kernel and ramdisk from
a FIT file, verify them and kexec for a faster reboot.

Signed-off-by: Luca Boccassi 
---
 meta/recipes-bsp/u-boot/u-boot-tools_2019.01.bb | 8 
 1 file changed, 8 insertions(+)

diff --git a/meta/recipes-bsp/u-boot/u-boot-tools_2019.01.bb 
b/meta/recipes-bsp/u-boot/u-boot-tools_2019.01.bb
index ff26e32482..c487849bb2 100644
--- a/meta/recipes-bsp/u-boot/u-boot-tools_2019.01.bb
+++ b/meta/recipes-bsp/u-boot/u-boot-tools_2019.01.bb
@@ -45,6 +45,14 @@ do_install () {
# mkenvimage
install -m 0755 tools/mkenvimage ${D}${bindir}/uboot-mkenvimage
ln -sf uboot-mkenvimage ${D}${bindir}/mkenvimage
+
+   # dumpimage
+   install -m 0755 tools/dumpimage ${D}${bindir}/uboot-dumpimage
+   ln -sf uboot-dumpimage ${D}${bindir}/dumpimage
+
+   # fit_check_sign
+   install -m 0755 tools/fit_check_sign ${D}${bindir}/uboot-fit_check_sign
+   ln -sf uboot-fit_check_sign ${D}${bindir}/fit_check_sign
 }
 
 ALLOW_EMPTY_${PN} = "1"
-- 
2.20.1

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


Re: [OE-core] [PATCH v4 1/2] openssl: Remove the c_rehash shell re-implementation

2019-03-19 Thread Andre McCurdy
On Tue, Mar 19, 2019 at 11:11 AM Otavio Salvador
 wrote:
>
> On Tue, Mar 19, 2019 at 2:38 PM Andre McCurdy  wrote:
> >
> > On Tue, Mar 19, 2019 at 6:57 AM Otavio Salvador  
> > wrote:
> > >
> > > We had a c_rehash shell re-implementation being used for the native
> > > package however the ca-certificates now uses the openssl rehash
> > > internal application so there is no use for the c_rehash anymore.
> > >
> > > Signed-off-by: Otavio Salvador 
> > > ---
> > >
> > > Changes in v4:
> > > - remove perlnative requirement
> >
> > You actually removed hostperl-runtime-native, not perl-native. It's
> > not really correct though - the hostperl-runtime-native dependency is
> > there to ensure we can run the openssl Configure script, not because
> > of c_rehash.
>
> Yes; this was fixed on v5.

Yes, I saw that right after posting :-) Sorry for the noise...

> --
> Otavio Salvador O.S. Systems
> http://www.ossystems.com.brhttp://code.ossystems.com.br
> Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH v4 1/2] openssl: Remove the c_rehash shell re-implementation

2019-03-19 Thread Otavio Salvador
On Tue, Mar 19, 2019 at 2:38 PM Andre McCurdy  wrote:
>
> On Tue, Mar 19, 2019 at 6:57 AM Otavio Salvador  
> wrote:
> >
> > We had a c_rehash shell re-implementation being used for the native
> > package however the ca-certificates now uses the openssl rehash
> > internal application so there is no use for the c_rehash anymore.
> >
> > Signed-off-by: Otavio Salvador 
> > ---
> >
> > Changes in v4:
> > - remove perlnative requirement
>
> You actually removed hostperl-runtime-native, not perl-native. It's
> not really correct though - the hostperl-runtime-native dependency is
> there to ensure we can run the openssl Configure script, not because
> of c_rehash.

Yes; this was fixed on v5.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH v4 1/2] openssl: Remove the c_rehash shell re-implementation

2019-03-19 Thread Andre McCurdy
On Tue, Mar 19, 2019 at 6:57 AM Otavio Salvador  wrote:
>
> We had a c_rehash shell re-implementation being used for the native
> package however the ca-certificates now uses the openssl rehash
> internal application so there is no use for the c_rehash anymore.
>
> Signed-off-by: Otavio Salvador 
> ---
>
> Changes in v4:
> - remove perlnative requirement

You actually removed hostperl-runtime-native, not perl-native. It's
not really correct though - the hostperl-runtime-native dependency is
there to ensure we can run the openssl Configure script, not because
of c_rehash.

In practice it makes no difference as hostperl-runtime-native is
mentioned in ASSUME_PROVIDED, but for correctness it shouldn't be
removed.

> Changes in v3:
> - remove c_rehash completely
> - fix ca-certificates recipe comment
>
> Changes in v2:
> - updated commit log
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 00/26] thud patch review

2019-03-19 Thread Martin Jansa
On Tue, Mar 19, 2019 at 05:31:52PM +0100, Alexander Kanavin wrote:
> For what it’s worth, OpenSSL is also being relicensed to Apache 2.0, so 
> backporting their fixes may not be an option either. 
> https://license.openssl.org/
> 
> Please be careful with your language: I’m sure you know that recipe 
> maintenance is a tedious, thankless task. Having it belittled doesn’t help.

I'm sorry, I don't want to belittle the recipe maintenance task.

I'm just saying that using OE to build commercial products is another
level of complexity and if we as a project ignore the issues companies
might have while upgrading to newer OE releases, then we shouldn't be
surprised that there are too many products built with really ancient and
unsupported OE releases.

I'm not recommending to anyone to use openssl10 forever, I've replied to
this thread mostly to warn other people (who might be in the same hole
with openssl10) that this is another pain point and suggested possible
way how to work around it.

More commercial users closer to master might also help with lack of
resources, upstreaming something from danny based build to master is
much less likely to happen than from e.g. thud. Having a bit easier
upgrade paths or at least a bit sympathy for people having troubles
persuading management that spending a lot of time and money to rebuild
all native apps, just to get newer build system (which no customer will
ever notice in the end product) might help as well.

With app store filled by native apps from 3rd party companies and
required backward compatibility with older products, the stable ABI
might be more important for some people than latest, greatest versions
and we shouldn't ignore such use-cases for OE (or at least not assume
that nobody needs openssl10 just because oe-core recipes can already
build without it).

Cheers,

> > On 19 Mar 2019, at 14.55, Martin Jansa  wrote:
> > 
> >> On Tue, Mar 19, 2019 at 12:35:59PM +0100, Alexander Kanavin wrote:
> >> Just to remind once more, all upstream support for OpenSSL 1.0.2 ceases in 
> >> 9 months, so shipping products with it may not be the best idea.
> > 
> > Just to remind once more, shipping products isn't as easy as building
> > the few recipes included in oe-core.
> > 
> > For example:
> > Believe it or not, some projects need to use old Qt 5.6 due to license
> > change in newer version and 5.6 doesn't support openssl 1.1,
> > backporting the necessary changes would violate the license as well.
> > Providing clean room re-implementation is also difficult, because there
> > aren't many other options how to implement this than how it was done in
> > newer qt already, see:
> > 
> > https://bugreports.qt.io/browse/QTBUG-71623
> > https://development.qt-project.narkive.com/RW4wxYXY/openssl-1-1-x-support-on-qt-5-6-5-9
> > 
> > Yes, it's not the best idea, but even backporting security fixes to old
> > openssl might be cheaper than buying commercial qt license...
> > 
> > Cheeers,

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


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


Re: [OE-core] [PATCH v4 1/2] openssl: Remove the c_rehash shell re-implementation

2019-03-19 Thread Otavio Salvador
On Tue, Mar 19, 2019 at 12:44 PM Peter Kjellerstedt
 wrote:
...
> You should remove the following line too:
>
> RDEPENDS_${PN}-misc = "perl"
>
> so we actually get rid of the perl dependency.

Fixed on v5; thanks for catching that.


-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH v5 2/3] openssl: Upgrade 1.1.1a -> 1.1.1b

2019-03-19 Thread Otavio Salvador
License-Update: copyright years updated
Signed-off-by: Otavio Salvador 
---

Changes in v5: None
Changes in v4:
- new patch

Changes in v3: None
Changes in v2: None

 .../openssl/{openssl_1.1.1a.bb => openssl_1.1.1b.bb}| 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
 rename meta/recipes-connectivity/openssl/{openssl_1.1.1a.bb => 
openssl_1.1.1b.bb} (96%)

diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb 
b/meta/recipes-connectivity/openssl/openssl_1.1.1b.bb
similarity index 96%
rename from meta/recipes-connectivity/openssl/openssl_1.1.1a.bb
rename to meta/recipes-connectivity/openssl/openssl_1.1.1b.bb
index 506d6d378c..450ef930c5 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.1b.bb
@@ -7,7 +7,7 @@ SECTION = "libs/network"
 # "openssl" here actually means both OpenSSL and SSLeay licenses apply
 # (see meta/files/common-licenses/OpenSSL to which "openssl" is 
SPDXLICENSEMAPped)
 LICENSE = "openssl"
-LIC_FILES_CHKSUM = "file://LICENSE;md5=d57d511030c9d66ef5f5966bee5a7eff"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=d343e62fc9c833710bbbed25f27364c8"
 
 DEPENDS = "hostperl-runtime-native"
 
@@ -22,8 +22,8 @@ SRC_URI_append_class-nativesdk = " \
file://environment.d-openssl.sh \
"
 
-SRC_URI[md5sum] = "963deb2272d6be7d4c2458afd2517b73"
-SRC_URI[sha256sum] = 
"fc20130f8b7cbd2fb918b2f14e2f429e109c31ddd0fb38fc5d71d9ffed3f9f41"
+SRC_URI[md5sum] = "4532712e7bcc9414f5bce995e4e13930"
+SRC_URI[sha256sum] = 
"5c557b023230413dfb0756f3137a13e6d726838ccd1430888ad15bfb2b43ea4b"
 
 inherit lib_package multilib_header ptest
 
-- 
2.21.0

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


[OE-core] [PATCH v5 3/3] openssl10: Upgrade 1.0.2q -> 1.0.2r

2019-03-19 Thread Otavio Salvador
Signed-off-by: Otavio Salvador 
---

Changes in v5:
- new patch

Changes in v4: None
Changes in v3: None
Changes in v2: None

 .../openssl/{openssl10_1.0.2q.bb => openssl10_1.0.2r.bb}  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-connectivity/openssl/{openssl10_1.0.2q.bb => 
openssl10_1.0.2r.bb} (98%)

diff --git a/meta/recipes-connectivity/openssl/openssl10_1.0.2q.bb 
b/meta/recipes-connectivity/openssl/openssl10_1.0.2r.bb
similarity index 98%
rename from meta/recipes-connectivity/openssl/openssl10_1.0.2q.bb
rename to meta/recipes-connectivity/openssl/openssl10_1.0.2r.bb
index eacdf8b86e..87df4f517a 100644
--- a/meta/recipes-connectivity/openssl/openssl10_1.0.2q.bb
+++ b/meta/recipes-connectivity/openssl/openssl10_1.0.2r.bb
@@ -53,8 +53,8 @@ SRC_URI_append_class-nativesdk = " \
file://environment.d-openssl.sh \
"
 
-SRC_URI[md5sum] = "7563e1ce046cb21948eeb6ba1a0eb71c"
-SRC_URI[sha256sum] = 
"5744cfcbcec2b1b48629f7354203bc1e5e9b5466998bbccc5b5fcde3b18eb684"
+SRC_URI[md5sum] = "0d2baaf04c56d542f6cc757b9c2a2aac"
+SRC_URI[sha256sum] = 
"ae51d08bba8a83958e894946f15303ff894d75c2b8bbd44a852b64e3fe11d0d6"
 
 S = "${WORKDIR}/openssl-${PV}"
 
-- 
2.21.0

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


[OE-core] [PATCH v5 1/3] openssl: Remove the c_rehash shell re-implementation

2019-03-19 Thread Otavio Salvador
We had a c_rehash shell re-implementation being used for the native
package however the ca-certificates now uses the openssl rehash
internal application so there is no use for the c_rehash anymore.

Signed-off-by: Otavio Salvador 
---

Changes in v5:
- add perlnative and drop perl from rdepends on misc package

Changes in v4:
- remove perlnative requirement

Changes in v3:
- remove c_rehash completely
- fix ca-certificates recipe comment

Changes in v2:
- updated commit log

 .../openssl/openssl/openssl-c_rehash.sh   | 222 --
 .../openssl/openssl_1.1.1a.bb |  14 +-
 .../ca-certificates_20190110.bb   |   2 +-
 3 files changed, 2 insertions(+), 236 deletions(-)
 delete mode 100644 
meta/recipes-connectivity/openssl/openssl/openssl-c_rehash.sh

diff --git a/meta/recipes-connectivity/openssl/openssl/openssl-c_rehash.sh 
b/meta/recipes-connectivity/openssl/openssl/openssl-c_rehash.sh
deleted file mode 100644
index 6620fdcb53..00
--- a/meta/recipes-connectivity/openssl/openssl/openssl-c_rehash.sh
+++ /dev/null
@@ -1,222 +0,0 @@
-#!/bin/sh
-#
-# Ben Secrest 
-#
-# sh c_rehash script, scan all files in a directory
-# and add symbolic links to their hash values.
-#
-# based on the c_rehash perl script distributed with openssl
-#
-# LICENSE: See OpenSSL license
-# ^^acceptable?^^
-#
-
-# default certificate location
-DIR=/etc/openssl
-
-# for filetype bitfield
-IS_CERT=$(( 1 << 0 ))
-IS_CRL=$(( 1 << 1 ))
-
-
-# check to see if a file is a certificate file or a CRL file
-# arguments:
-#   1. the filename to be scanned
-# returns:
-#   bitfield of file type; uses ${IS_CERT} and ${IS_CRL}
-#
-check_file()
-{
-local IS_TYPE=0
-
-# make IFS a newline so we can process grep output line by line
-local OLDIFS=${IFS}
-IFS=$( printf "\n" )
-
-# XXX: could be more efficient to have two 'grep -m' but is -m portable?
-for LINE in $( grep '^-BEGIN .*-' ${1} )
-do
-   if echo ${LINE} \
-   | grep -q -E '^-BEGIN (X509 |TRUSTED )?CERTIFICATE-'
-   then
-   IS_TYPE=$(( ${IS_TYPE} | ${IS_CERT} ))
-
-   if [ $(( ${IS_TYPE} & ${IS_CRL} )) -ne 0 ]
-   then
-   break
-   fi
-   elif echo ${LINE} | grep -q '^-BEGIN X509 CRL-'
-   then
-   IS_TYPE=$(( ${IS_TYPE} | ${IS_CRL} ))
-
-   if [ $(( ${IS_TYPE} & ${IS_CERT} )) -ne 0 ]
-   then
-   break
-   fi
-   fi
-done
-
-# restore IFS
-IFS=${OLDIFS}
-
-return ${IS_TYPE}
-}
-
-
-#
-# use openssl to fingerprint a file
-#arguments:
-#  1. the filename to fingerprint
-#  2. the method to use (x509, crl)
-#returns:
-#  none
-#assumptions:
-#  user will capture output from last stage of pipeline
-#
-fingerprint()
-{
-${SSL_CMD} ${2} -fingerprint -noout -in ${1} | sed 's/^.*=//' | tr -d ':'
-}
-
-
-#
-# link_hash - create links to certificate files
-#arguments:
-#   1. the filename to create a link for
-#  2. the type of certificate being linked (x509, crl)
-#returns:
-#  0 on success, 1 otherwise
-#
-link_hash()
-{
-local FINGERPRINT=$( fingerprint ${1} ${2} )
-local HASH=$( ${SSL_CMD} ${2} -hash -noout -in ${1} )
-local SUFFIX=0
-local LINKFILE=''
-local TAG=''
-
-if [ ${2} = "crl" ]
-then
-   TAG='r'
-fi
-
-LINKFILE=${HASH}.${TAG}${SUFFIX}
-
-while [ -f ${LINKFILE} ]
-do
-   if [ ${FINGERPRINT} = $( fingerprint ${LINKFILE} ${2} ) ]
-   then
-   echo "NOTE: Skipping duplicate file ${1}" >&2
-   return 1
-   fi  
-
-   SUFFIX=$(( ${SUFFIX} + 1 ))
-   LINKFILE=${HASH}.${TAG}${SUFFIX}
-done
-
-echo "${3} => ${LINKFILE}"
-
-# assume any system with a POSIX shell will either support symlinks or
-# do something to handle this gracefully
-ln -s ${3} ${LINKFILE}
-
-return 0
-}
-
-
-# hash_dir create hash links in a given directory
-hash_dir()
-{
-echo "Doing ${1}"
-
-cd ${1}
-
-ls -1 * 2>/dev/null | while read FILE
-do
-if echo ${FILE} | grep -q -E '^[[:xdigit:]]{8}\.r?[[:digit:]]+$' \
-   && [ -h "${FILE}" ]
-then
-rm ${FILE}
-fi
-done
-
-ls -1 *.pem *.cer *.crt *.crl 2>/dev/null | while read FILE
-do
-   REAL_FILE=${FILE}
-   # if we run on build host then get to the real files in rootfs
-   if [ -n "${SYSROOT}" -a -h ${FILE} ]
-   then
-   FILE=$( readlink ${FILE} )
-   # check the symlink is absolute (or dangling in other word)
-   if [ "x/" = "x$( echo ${FILE} | cut -c1 -)" ]
-   then
-   REAL_FILE=${SYSROOT}/${FILE}
-   fi
-   fi
-
-   check_file ${REAL_FILE}
-local FILE_TYPE=${?}
-   local TYPE_STR=''
-
-if [ $(( ${FILE_TYPE} & ${IS_CERT} )) -ne 0 ]
-then
-TYPE_STR='x509'
-elif [ $(( ${FILE_TYPE} & 

Re: [OE-core] [PATCH 00/26] thud patch review

2019-03-19 Thread Alexander Kanavin
For what it’s worth, OpenSSL is also being relicensed to Apache 2.0, so 
backporting their fixes may not be an option either. 
https://license.openssl.org/

Please be careful with your language: I’m sure you know that recipe maintenance 
is a tedious, thankless task. Having it belittled doesn’t help.

Alex

> On 19 Mar 2019, at 14.55, Martin Jansa  wrote:
> 
>> On Tue, Mar 19, 2019 at 12:35:59PM +0100, Alexander Kanavin wrote:
>> Just to remind once more, all upstream support for OpenSSL 1.0.2 ceases in 9 
>> months, so shipping products with it may not be the best idea.
> 
> Just to remind once more, shipping products isn't as easy as building
> the few recipes included in oe-core.
> 
> For example:
> Believe it or not, some projects need to use old Qt 5.6 due to license
> change in newer version and 5.6 doesn't support openssl 1.1,
> backporting the necessary changes would violate the license as well.
> Providing clean room re-implementation is also difficult, because there
> aren't many other options how to implement this than how it was done in
> newer qt already, see:
> 
> https://bugreports.qt.io/browse/QTBUG-71623
> https://development.qt-project.narkive.com/RW4wxYXY/openssl-1-1-x-support-on-qt-5-6-5-9
> 
> Yes, it's not the best idea, but even backporting security fixes to old
> openssl might be cheaper than buying commercial qt license...
> 
> Cheeers,
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] Yocto Project Status WW12'19

2019-03-19 Thread Scott Rifenbark
Hi,

Here is a "start" at publicly documenting QA... I started on this a while
back and got content from Richard only.  It would be good to have eyes on
this so it could be completed.  There are holes and stuff may have
changed.  If you want, please look it over and send me feedback.

See https://yoctoproject.org/docs/scott_temp/test-manual/test-manual.html

Thanks,
Scott

On Tue, Mar 19, 2019 at 8:53 AM  wrote:

> Current Dev Position: YP 2.7 M3 (New feature Freeze has begun.)
>
> Next Deadline: YP 2.7 M3 Cutoff was Feb. 25, 2019
>
>
>
> SWAT Team Rotation:
>
>- SWAT lead is currently: Armin
>- SWAT team rotation: Armin -> Paul on Mar. 23, 2019
>- SWAT team rotation: Paul -> Ross on Mar. 30, 2019
>- https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team
>
>
>
> Key Status/Updates:
>
>- M3 has not built yet however most major pieces are in place,
>including now, agreement on the new QA process. The delay is partly due to
>RP travel with others able to cover being unavailable for other reasons,
>combined with infrastructure issues.
>- The remaining questions for M3 are:
>   - Public documentation of the new QA process
>   - Upgrade for uninative for glibc 2.29
>   - Mesa upgrade? (unlikely given failures in testing)
>- The Yocto Project has updated to its new governance model which
>includes establishing a Technical Steering Committee (TSC) for Yocto
>Project. This is designed to complement  and work alongside the
>OpenEmbedded TSC. Three members of the YP TSC are selected by the Yocto
>Project governing board and those people are Ross Burton, Khem Raj and
>Richard Purdie. The remaining two seats will be elected by OpenEmbedded. It
>is intended the TSC will take over the release process, SWAT team, bug
>triage and feature planning/development for 2.8.
>- YP 2.5.3 continues to be blocked on autobuilder-helper changes for
>the stable branches and the resulttool changes in master to move to the new
>QA process.
>- There is discussion on the openembedded-architecture list about
>changes to the stable branch patch criteria to bring us more into line with
>current industry best practices and thinking.
>
>
>
> Planned Releases for YP 2.7:
>
>- YP 2.7 M3 Cutoff was Feb. 25, 2019
>- YP 2.7 M3 Release Target was Mar. 8, 2019
>- YP 2.7 M4 Cutoff is Apr. 1, 2019
>- YP 2.7 M4 Release Target is Apr. 26, 2019
>
>
>
> Planned upcoming dot releases:
>
>- YP 2.5.3 (Sumo) will be targeted after YP 2.7 M2 is done.
>- YP 2.5.4 (Sumo) will be targeted after YP 2.7 M4 is done.
>- YP 2.6.2 (Thud) will be targeted after YP 2.5.4 is done.
>
>
>
> Tracking Metrics:
>
>- WDD 2432 (last week 2439) (
>https://wiki.yoctoproject.org/charts/combo.html)
>- Poky Patch Metrics
>   - Total patches found: 1526 (last week 1523)
>   - Patches in the Pending State: 656 (43%) [last week 657 (43%)]
>
>
>
> Key Status Links for YP:
>
> https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.7_Status
>
> https://wiki.yoctoproject.org/wiki/Yocto_2.7_Schedule
>
> https://wiki.yoctoproject.org/wiki/Yocto_2.7_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 Project Manager*
>
> (*Cell*:(208) 244-4460
>
> * *Email*:  *sjolley.yp...@gmail.com
> *
>
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] openssl10: Upgrade 1.0.2q -> 1.0.2r

2019-03-19 Thread Otavio Salvador
Signed-off-by: Otavio Salvador 
---

 .../openssl/{openssl10_1.0.2q.bb => openssl10_1.0.2r.bb}  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-connectivity/openssl/{openssl10_1.0.2q.bb => 
openssl10_1.0.2r.bb} (98%)

diff --git a/meta/recipes-connectivity/openssl/openssl10_1.0.2q.bb 
b/meta/recipes-connectivity/openssl/openssl10_1.0.2r.bb
similarity index 98%
rename from meta/recipes-connectivity/openssl/openssl10_1.0.2q.bb
rename to meta/recipes-connectivity/openssl/openssl10_1.0.2r.bb
index eacdf8b86e..87df4f517a 100644
--- a/meta/recipes-connectivity/openssl/openssl10_1.0.2q.bb
+++ b/meta/recipes-connectivity/openssl/openssl10_1.0.2r.bb
@@ -53,8 +53,8 @@ SRC_URI_append_class-nativesdk = " \
file://environment.d-openssl.sh \
"
 
-SRC_URI[md5sum] = "7563e1ce046cb21948eeb6ba1a0eb71c"
-SRC_URI[sha256sum] = 
"5744cfcbcec2b1b48629f7354203bc1e5e9b5466998bbccc5b5fcde3b18eb684"
+SRC_URI[md5sum] = "0d2baaf04c56d542f6cc757b9c2a2aac"
+SRC_URI[sha256sum] = 
"ae51d08bba8a83958e894946f15303ff894d75c2b8bbd44a852b64e3fe11d0d6"
 
 S = "${WORKDIR}/openssl-${PV}"
 
-- 
2.21.0

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


Re: [OE-core] [PATCH] openssl: Upgrade 1.1.1a -> 1.1.1b

2019-03-19 Thread Otavio Salvador
On Tue, Mar 19, 2019 at 12:48 PM Alexander Kanavin
 wrote:
> Openssl10 needs a similar update, can you do it please?

Sent.


-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [oe-core 2/2] glib-networking:enable glib-networking complie as native package

2019-03-19 Thread Burton, Ross
On Tue, 19 Mar 2019 at 15:37, Peter Kjellerstedt
 wrote:
> > +do_install_append_class-native () {
> > +for _pc in ${D}${libdir}/pkgconfig/*.pc; do
> > +case $_pc in
> > +*'*.pc') rm -fr ${D}${libdir}/pkgconfig;;
> > +*.pc)break;;
> > +esac
> > +done
>
> Why complicate things? Just remove the directory if it exists
> and is empty:
>
> rmdir ${D}${libdir}/pkgconfig 2>/dev/null || :

Bikeshed!  Or

rmdir --ignore-fail-on-non-empty ${D}${libdir}/pkgconfig

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


Re: [OE-core] [PATCH] openssl: Upgrade 1.1.1a -> 1.1.1b

2019-03-19 Thread Alexander Kanavin
Openssl10 needs a similar update, can you do it please?

Alex

> On 19 Mar 2019, at 14.53, Otavio Salvador  wrote:
> 
> License-Update: copyright years updated
> Signed-off-by: Otavio Salvador 
> ---
> 
> .../openssl/{openssl_1.1.1a.bb => openssl_1.1.1b.bb}| 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
> rename meta/recipes-connectivity/openssl/{openssl_1.1.1a.bb => 
> openssl_1.1.1b.bb} (96%)
> 
> diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb 
> b/meta/recipes-connectivity/openssl/openssl_1.1.1b.bb
> similarity index 96%
> rename from meta/recipes-connectivity/openssl/openssl_1.1.1a.bb
> rename to meta/recipes-connectivity/openssl/openssl_1.1.1b.bb
> index d03a225df8..57026596fa 100644
> --- a/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb
> +++ b/meta/recipes-connectivity/openssl/openssl_1.1.1b.bb
> @@ -7,7 +7,7 @@ SECTION = "libs/network"
> # "openssl" here actually means both OpenSSL and SSLeay licenses apply
> # (see meta/files/common-licenses/OpenSSL to which "openssl" is 
> SPDXLICENSEMAPped)
> LICENSE = "openssl"
> -LIC_FILES_CHKSUM = "file://LICENSE;md5=d57d511030c9d66ef5f5966bee5a7eff"
> +LIC_FILES_CHKSUM = "file://LICENSE;md5=d343e62fc9c833710bbbed25f27364c8"
> 
> DEPENDS = "hostperl-runtime-native"
> 
> @@ -22,8 +22,8 @@ SRC_URI_append_class-nativesdk = " \
>file://environment.d-openssl.sh \
>"
> 
> -SRC_URI[md5sum] = "963deb2272d6be7d4c2458afd2517b73"
> -SRC_URI[sha256sum] = 
> "fc20130f8b7cbd2fb918b2f14e2f429e109c31ddd0fb38fc5d71d9ffed3f9f41"
> +SRC_URI[md5sum] = "4532712e7bcc9414f5bce995e4e13930"
> +SRC_URI[sha256sum] = 
> "5c557b023230413dfb0756f3137a13e6d726838ccd1430888ad15bfb2b43ea4b"
> 
> inherit lib_package multilib_header ptest
> 
> -- 
> 2.21.0
> 
> -- 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH v4 1/2] openssl: Remove the c_rehash shell re-implementation

2019-03-19 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org  core-boun...@lists.openembedded.org> On Behalf Of Otavio Salvador
> Sent: den 19 mars 2019 14:57
> To: OpenEmbedded Core Mailing List  c...@lists.openembedded.org>
> Cc: Otavio Salvador 
> Subject: [OE-core] [PATCH v4 1/2] openssl: Remove the c_rehash shell
> re-implementation
> 
> We had a c_rehash shell re-implementation being used for the native
> package however the ca-certificates now uses the openssl rehash
> internal application so there is no use for the c_rehash anymore.
> 
> Signed-off-by: Otavio Salvador 
> ---
> 
> Changes in v4:
> - remove perlnative requirement
> 
> Changes in v3:
> - remove c_rehash completely
> - fix ca-certificates recipe comment
> 
> Changes in v2:
> - updated commit log
> 
>  .../openssl/openssl/openssl-c_rehash.sh   | 222 --
>  .../openssl/openssl_1.1.1a.bb |  15 +-
>  .../ca-certificates_20190110.bb   |   2 +-
>  3 files changed, 2 insertions(+), 237 deletions(-)
>  delete mode 100644 
> meta/recipes-connectivity/openssl/openssl/openssl-c_rehash.sh
> 
> diff --git a/meta/recipes-connectivity/openssl/openssl/openssl-c_rehash.sh 
> b/meta/recipes-connectivity/openssl/openssl/openssl-c_rehash.sh
> deleted file mode 100644
> index 6620fdcb53..00
> --- a/meta/recipes-connectivity/openssl/openssl/openssl-c_rehash.sh
> +++ /dev/null
> @@ -1,222 +0,0 @@

[cut]

> diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb 
> b/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb
> index 4a626a4fcd..c5900ad536 100644
> --- a/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb
> +++ b/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb
> @@ -9,11 +9,8 @@ SECTION = "libs/network"
>  LICENSE = "openssl"
>  LIC_FILES_CHKSUM = "file://LICENSE;md5=d57d511030c9d66ef5f5966bee5a7eff"
> 
> -DEPENDS = "hostperl-runtime-native"
> -
>  SRC_URI = "http://www.openssl.org/source/openssl-${PV}.tar.gz \
> file://run-ptest \
> -   file://openssl-c_rehash.sh \
> file://0001-skip-test_symbol_presence.patch \
> 
> file://0001-buildinfo-strip-sysroot-and-debug-prefix-map-from-co.patch \
> file://afalg.patch \
> @@ -149,12 +146,6 @@ do_install_append_class-native () {
>   SSL_CERT_DIR=${libdir}/ssl-1.1/certs \
>   SSL_CERT_FILE=${libdir}/ssl-1.1/cert.pem \
>   OPENSSL_ENGINES=${libdir}/ssl-1.1/engines
> -
> - # Install a custom version of c_rehash that can handle sysroots 
> properly.
> - # This version is used for example when installing ca-certificates 
> during
> - # image creation.
> - install -Dm 0755 ${WORKDIR}/openssl-c_rehash.sh ${D}${bindir}/c_rehash
> - sed -i -e 's,/etc/openssl,${sysconfdir}/ssl,g' ${D}${bindir}/c_rehash
>  }
> 
>  do_install_append_class-nativesdk () {
> @@ -196,7 +187,7 @@ FILES_libcrypto = "${libdir}/libcrypto${SOLIBS}"
>  FILES_libssl = "${libdir}/libssl${SOLIBS}"
>  FILES_openssl-conf = "${sysconfdir}/ssl/openssl.cnf"
>  FILES_${PN}-engines = "${libdir}/engines-1.1"
> -FILES_${PN}-misc = "${libdir}/ssl-1.1/misc ${bindir}/c_rehash"
> +FILES_${PN}-misc = "${libdir}/ssl-1.1/misc"
>  FILES_${PN} =+ "${libdir}/ssl-1.1/*"
>  FILES_${PN}_append_class-nativesdk = " 
> ${SDKPATHNATIVE}/environment-setup.d/openssl.sh"
> 

You should remove the following line too:

RDEPENDS_${PN}-misc = "perl"

so we actually get rid of the perl dependency.

> @@ -211,7 +202,3 @@ RREPLACES_openssl-conf = "openssl10-conf"
>  RCONFLICTS_openssl-conf = "openssl10-conf"
> 
>  BBCLASSEXTEND = "native nativesdk"
> -
> -inherit multilib_script
> -
> -MULTILIB_SCRIPTS = "${PN}-bin:${bindir}/c_rehash"
> diff --git a/meta/recipes-support/ca-certificates/ca-certificates_20190110.bb 
> b/meta/recipes-support/ca-certificates/ca-certificates_20190110.bb
> index b9f57900c8..4c0425302f 100644
> --- a/meta/recipes-support/ca-certificates/ca-certificates_20190110.bb
> +++ b/meta/recipes-support/ca-certificates/ca-certificates_20190110.bb
> @@ -11,7 +11,7 @@ LIC_FILES_CHKSUM = 
> "file://debian/copyright;md5=aeb420429b1659507e0a5a1b123e8308
>  DEPENDS = ""
>  DEPENDS_class-native = "openssl-native"
>  DEPENDS_class-nativesdk = "openssl-native"
> -# Need c_rehash from openssl and run-parts from debianutils
> +# Need rehash from openssl and run-parts from debianutils
>  PACKAGE_WRITE_DEPS += "openssl-native debianutils-native"
> 
>  SRCREV = "c28799b138b044c963d24c4a69659b6e5486e3be"
> --
> 2.21.0

//Peter

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


Re: [OE-core] [PATCH 00/26] thud patch review

2019-03-19 Thread Alexander Kanavin
Nope, we determined that it’s actually ok.

Alex

> On 19 Mar 2019, at 15.52, akuster808  wrote:
> 
> 
> 
>> On 3/19/19 1:55 AM, Martin Jansa wrote:
>>> On Mon, Mar 18, 2019 at 07:36:29PM -0700, Armin Kuster wrote:
>>> Responses should be made by Wed March 20th 22:00:00 UTC 2019
>>> 
>>> The following changes since commit f5a57e939e626a5b7c6de5b51799ca602ed355ed:
>>> 
>>>  mesa: ship /etc/drirc in mesa-megadriver (2019-03-05 22:24:13 +)
>>> 
>>> are available in the git repository at:
>>> 
>>>  git://git.yoctoproject.org/poky-contrib stable/thud-next
>>>  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=stable/thud-next
>>> 
>>> Alexander Kanavin (1):
>>>  ca-certificates: upgrade 20180409 -> 20190110
> then this gets dropped
>> This depends on openssl >= 1.1.1 since:
>> https://salsa.debian.org/debian/ca-certificates/commit/d5e425c8405448e5034d1e16ca52be6a10cb3334
>> some people might not use new openssl with thud.
>> 
>> More detail in:
>> http://lists.openembedded.org/pipermail/openembedded-core/2019-March/280234.html
>> 
>> Cheers,
> 
> 
> -- 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [oe-core 2/2] glib-networking:enable glib-networking complie as native package

2019-03-19 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org  core-boun...@lists.openembedded.org> On Behalf Of Jiang Lu
> Sent: den 19 mars 2019 08:55
> To: lu.ji...@windriver.com; openembedded-core@lists.openembedded.org
> Subject: [OE-core] [oe-core 2/2] glib-networking:enable glib-networking
> complie as native package
> 
> Enable glib-networking compile as a native package, for it is depended
> by
> libsoup.
> 
> Signed-off-by: Jiang Lu 
> ---
>  .../glib-networking/glib-networking_2.58.0.bb | 31 +++
>  1 file changed, 31 insertions(+)
> 
> diff --git a/meta/recipes-core/glib-networking/glib-
> networking_2.58.0.bb b/meta/recipes-core/glib-networking/glib-
> networking_2.58.0.bb
> index f3190e1cae..35b4a3fa76 100644
> --- a/meta/recipes-core/glib-networking/glib-networking_2.58.0.bb
> +++ b/meta/recipes-core/glib-networking/glib-networking_2.58.0.bb
> @@ -29,3 +29,34 @@ FILES_${PN} += "\
>  "
>  FILES_${PN}-dev += "${libdir}/gio/modules/libgio*.la"
>  FILES_${PN}-staticdev += "${libdir}/gio/modules/libgio*.a"
> +
> +# Make sure we compile with ca-certificates support enabled.
> +PACKAGECONFIG_append = " ca-certificates"
> +
> +DEPENDS += "ca-certificates"
> +RDEPENDS_${PN} += "ca-certificates"
> +
> +# We need native version for ostree-/flatpak-native.
> +BBCLASSEXTEND = "native"
> +# OE-core's relocatable.bbclass assumes that every package which
> +# ends up creating a ${libdir}/pkgconfig directory in its sysroot
> +# will always also install .pc-files there and tries to uncondi-
> +# tionally update paths in those files using globbing that fails
> +# if no such files are present. This presumption is not true for
> +# glib-networking which happens to create a directory by dereferencing
> +# a GIO pkgconfig variable which in turn is defined relative to
> +# the pkgconfig directory (${pcfiledir}/../...), causing pkgconfig
> +# to get created.

How about fixing relocatable_native_pcfiles() in relocatable.bbclass 
instead so that it ignores empty pkgconfig directories?

> +#
> +# Could be worked around in the upatream recipe but since that
> +# does not provide/create native versions of the package and since
> +# this problem is related to native packages, we work around it here.
> +#
> +do_install_append_class-native () {
> +for _pc in ${D}${libdir}/pkgconfig/*.pc; do
> +case $_pc in
> +*'*.pc') rm -fr ${D}${libdir}/pkgconfig;;
> +*.pc)break;;
> +esac
> +done

Why complicate things? Just remove the directory if it exists 
and is empty:

rmdir ${D}${libdir}/pkgconfig 2>/dev/null || :

> +}
> --
> 2.17.1

//Peter

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


Re: [OE-core] [sumo][PATCH] coreutils: 8.29: fix native build

2019-03-19 Thread akuster808


On 3/14/19 8:43 AM, Stefan Müller-Klieser wrote:
> This fixes the native build on glibc 2.28 hosts, by backporting two
> gnulib patches from master.
This will need to be done for Thud too.
- armin
>
> Signed-off-by: Stefan Müller-Klieser 
> ---
>  ...adjust-to-glibc-2.28-libio.h-removal.patch | 193 ++
>  ...e-more-paranoid-about-libio.h-change.patch | 187 +
>  meta/recipes-core/coreutils/coreutils_8.29.bb |   2 +
>  3 files changed, 382 insertions(+)
>  create mode 100644 
> meta/recipes-core/coreutils/coreutils/0001-fflush-adjust-to-glibc-2.28-libio.h-removal.patch
>  create mode 100644 
> meta/recipes-core/coreutils/coreutils/0002-fflush-be-more-paranoid-about-libio.h-change.patch
>
> diff --git 
> a/meta/recipes-core/coreutils/coreutils/0001-fflush-adjust-to-glibc-2.28-libio.h-removal.patch
>  
> b/meta/recipes-core/coreutils/coreutils/0001-fflush-adjust-to-glibc-2.28-libio.h-removal.patch
> new file mode 100644
> index ..110b34372db1
> --- /dev/null
> +++ 
> b/meta/recipes-core/coreutils/coreutils/0001-fflush-adjust-to-glibc-2.28-libio.h-removal.patch
> @@ -0,0 +1,193 @@
> +From 269a8987224ec62b7a9aa6202772b07d5be424d2 Mon Sep 17 00:00:00 2001
> +From: =?UTF-8?q?Stefan=20M=C3=BCller-Klieser?= 
> +Date: Mon, 11 Mar 2019 16:00:33 +0100
> +Subject: [PATCH 1/2] fflush: adjust to glibc 2.28 libio.h removal
> +MIME-Version: 1.0
> +Content-Type: text/plain; charset=UTF-8
> +Content-Transfer-Encoding: 8bit
> +
> +Backport of patch:
> +4af4a4a71827c0bc5e0ec67af23edef4f15cee8e
> +Paul Eggert 
> +fflush: adjust to glibc 2.28 libio.h removal
> +
> +Upstream-Status: Backport [master]
> +
> +Signed-off-by: Stefan Müller-Klieser 
> +---
> + lib/fflush.c | 6 +++---
> + lib/fpending.c   | 2 +-
> + lib/fpurge.c | 2 +-
> + lib/freadahead.c | 2 +-
> + lib/freading.c   | 2 +-
> + lib/freadptr.c   | 2 +-
> + lib/freadseek.c  | 2 +-
> + lib/fseeko.c | 4 ++--
> + lib/fseterr.c| 2 +-
> + lib/stdio-impl.h | 6 ++
> + 10 files changed, 18 insertions(+), 12 deletions(-)
> +
> +diff --git a/lib/fflush.c b/lib/fflush.c
> +index 4e65692644b1..c16da5fdcf23 100644
> +--- a/lib/fflush.c
>  b/lib/fflush.c
> +@@ -33,7 +33,7 @@
> + #undef fflush
> + 
> + 
> +-#if defined _IO_ftrylockfile || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, 
> Haiku, Linux libc5 */
> ++#if defined _IO_EOF_SEEN || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, 
> Linux libc5 */
> + 
> + /* Clear the stream's ungetc buffer, preserving the value of ftello (fp).  
> */
> + static void
> +@@ -72,7 +72,7 @@ clear_ungetc_buffer (FILE *fp)
> + 
> + #endif
> + 
> +-#if ! (defined _IO_ftrylockfile || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, 
> Haiku, Linux libc5 */)
> ++#if ! (defined _IO_EOF_SEEN || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, 
> Haiku, Linux libc5 */)
> + 
> + # if (defined __sferror || defined __DragonFly__ || defined __ANDROID__) && 
> defined __SNPT
> + /* FreeBSD, NetBSD, OpenBSD, DragonFly, Mac OS X, Cygwin, Minix 3, Android 
> */
> +@@ -148,7 +148,7 @@ rpl_fflush (FILE *stream)
> +   if (stream == NULL || ! freading (stream))
> + return fflush (stream);
> + 
> +-#if defined _IO_ftrylockfile || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, 
> Haiku, Linux libc5 */
> ++#if defined _IO_EOF_SEEN || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, 
> Linux libc5 */
> + 
> +   clear_ungetc_buffer_preserving_position (stream);
> + 
> +diff --git a/lib/fpending.c b/lib/fpending.c
> +index 5811a4a74750..9e21a165e220 100644
> +--- a/lib/fpending.c
>  b/lib/fpending.c
> +@@ -32,7 +32,7 @@ __fpending (FILE *fp)
> +   /* Most systems provide FILE as a struct and the necessary bitmask in
> +  , because they need it for implementing getc() and putc() as
> +  fast macros.  */
> +-#if defined _IO_ftrylockfile || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, 
> Haiku, Linux libc5 */
> ++#if defined _IO_EOF_SEEN || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, 
> Linux libc5 */
> +   return fp->_IO_write_ptr - fp->_IO_write_base;
> + #elif defined __sferror || defined __DragonFly__ || defined __ANDROID__
> +   /* FreeBSD, NetBSD, OpenBSD, DragonFly, Mac OS X, Cygwin, Minix 3, 
> Android */
> +diff --git a/lib/fpurge.c b/lib/fpurge.c
> +index 408b8fcbb3b8..3a160004d49d 100644
> +--- a/lib/fpurge.c
>  b/lib/fpurge.c
> +@@ -62,7 +62,7 @@ fpurge (FILE *fp)
> +   /* Most systems provide FILE as a struct and the necessary bitmask in
> +  , because they need it for implementing getc() and putc() as
> +  fast macros.  */
> +-# if defined _IO_ftrylockfile || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, 
> Haiku, Linux libc5 */
> ++# if defined _IO_EOF_SEEN || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, 
> Linux libc5 */
> +   fp->_IO_read_end = fp->_IO_read_ptr;
> +   fp->_IO_write_ptr = fp->_IO_write_base;
> +   /* Avoid memory leak when there is an active ungetc buffer.  */
> +diff --git a/lib/freadahead.c b/lib/freadahead.c
> +index f335f041ee5e..e7cb77b6722b 100644
> +--- a/lib/freadahead.c
>  

[OE-core] Yocto Project Status WW12'19

2019-03-19 Thread sjolley.yp.pm
Current Dev Position: YP 2.7 M3 (New feature Freeze has begun.)

Next Deadline: YP 2.7 M3 Cutoff was Feb. 25, 2019

 

SWAT Team Rotation:

*   SWAT lead is currently: Armin 
*   SWAT team rotation: Armin -> Paul on Mar. 23, 2019
*   SWAT team rotation: Paul -> Ross on Mar. 30, 2019
*
https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team

 

Key Status/Updates:

*   M3 has not built yet however most major pieces are in place,
including now, agreement on the new QA process. The delay is partly due to
RP travel with others able to cover being unavailable for other reasons,
combined with infrastructure issues.
*   The remaining questions for M3 are:

*   Public documentation of the new QA process
*   Upgrade for uninative for glibc 2.29
*   Mesa upgrade? (unlikely given failures in testing)

*   The Yocto Project has updated to its new governance model which
includes establishing a Technical Steering Committee (TSC) for Yocto
Project. This is designed to complement  and work alongside the OpenEmbedded
TSC. Three members of the YP TSC are selected by the Yocto Project governing
board and those people are Ross Burton, Khem Raj and Richard Purdie. The
remaining two seats will be elected by OpenEmbedded. It is intended the TSC
will take over the release process, SWAT team, bug triage and feature
planning/development for 2.8.
*   YP 2.5.3 continues to be blocked on autobuilder-helper changes for
the stable branches and the resulttool changes in master to move to the new
QA process.
*   There is discussion on the openembedded-architecture list about
changes to the stable branch patch criteria to bring us more into line with
current industry best practices and thinking.

 

Planned Releases for YP 2.7:

*   YP 2.7 M3 Cutoff was Feb. 25, 2019
*   YP 2.7 M3 Release Target was Mar. 8, 2019
*   YP 2.7 M4 Cutoff is Apr. 1, 2019
*   YP 2.7 M4 Release Target is Apr. 26, 2019

 

Planned upcoming dot releases:

*   YP 2.5.3 (Sumo) will be targeted after YP 2.7 M2 is done.
*   YP 2.5.4 (Sumo) will be targeted after YP 2.7 M4 is done.
*   YP 2.6.2 (Thud) will be targeted after YP 2.5.4 is done.

 

Tracking Metrics:

*   WDD 2432 (last week 2439) (

https://wiki.yoctoproject.org/charts/combo.html)
*   Poky Patch Metrics  

*   Total patches found: 1526 (last week 1523)
*   Patches in the Pending State: 656 (43%) [last week 657 (43%)]

 

Key Status Links for YP:

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

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

 
https://wiki.yoctoproject.org/wiki/Yocto_2.7_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 Project Manager

*Cell:(208) 244-4460

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

 

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


Re: [OE-core] [PATCH 00/26] thud patch review

2019-03-19 Thread akuster808


On 3/19/19 1:55 AM, Martin Jansa wrote:
> On Mon, Mar 18, 2019 at 07:36:29PM -0700, Armin Kuster wrote:
>> Responses should be made by Wed March 20th 22:00:00 UTC 2019
>>
>> The following changes since commit f5a57e939e626a5b7c6de5b51799ca602ed355ed:
>>
>>   mesa: ship /etc/drirc in mesa-megadriver (2019-03-05 22:24:13 +)
>>
>> are available in the git repository at:
>>
>>   git://git.yoctoproject.org/poky-contrib stable/thud-next
>>   http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=stable/thud-next
>>
>> Alexander Kanavin (1):
>>   ca-certificates: upgrade 20180409 -> 20190110
then this gets dropped
> This depends on openssl >= 1.1.1 since:
> https://salsa.debian.org/debian/ca-certificates/commit/d5e425c8405448e5034d1e16ca52be6a10cb3334
> some people might not use new openssl with thud.
>
> More detail in:
> http://lists.openembedded.org/pipermail/openembedded-core/2019-March/280234.html
>
> Cheers,




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


Re: [OE-core] [thud][PATCH] target-sdk-provides-dummy: Extend to -dev and -src packages

2019-03-19 Thread Sean Nyekjaer

kind ping

BR
/Sean

On 09/03/2019 19.50, Max Krummenacher wrote:

From: Richard Purdie 

This avoids errors when running populate_sdk under opkg:

  * Problem 1/1:
  *   - package busybox-dev-1.30.1-r0.core2-64 requires busybox = 1.30.1-r0, 
but none of the providers can be installed
  *
  * Solution 1:
  *   - allow deinstallation of 
target-sdk-provides-dummy-1.0-r0.sdk-provides-dummy-target

  * Solution 2:
  *   - do not ask to install a package providing busybox-dev

Signed-off-by: Richard Purdie 
(cherry picked from commit 33d2cde3be4d25389cbea07064ffbc7b2f74273e)
---
  meta/recipes-core/meta/target-sdk-provides-dummy.bb | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/meta/recipes-core/meta/target-sdk-provides-dummy.bb 
b/meta/recipes-core/meta/target-sdk-provides-dummy.bb
index edf07c4a23..e7bf2ac632 100644
--- a/meta/recipes-core/meta/target-sdk-provides-dummy.bb
+++ b/meta/recipes-core/meta/target-sdk-provides-dummy.bb
@@ -2,9 +2,17 @@ DUMMYARCH = "sdk-provides-dummy-target"
  
  DUMMYPROVIDES = "\

  busybox \
+busybox-dev \
+busybox-src \
  coreutils \
+coreutils-dev \
+coreutils-src \
  bash \
+bash-dev \
+bash-src \
  perl \
+perl-dev \
+perl-src \
  perl-module-re \
  perl-module-strict \
  perl-module-vars \
@@ -33,6 +41,8 @@ DUMMYPROVIDES = "\
  /usr/bin/env \
  /usr/bin/perl \
  pkgconfig \
+pkgconfig-dev \
+pkgconfig-src \
  "
  
  require dummy-sdk-package.inc




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


[OE-core] [PATCH v4 2/2] openssl: Upgrade 1.1.1a -> 1.1.1b

2019-03-19 Thread Otavio Salvador
License-Update: copyright years updated
Signed-off-by: Otavio Salvador 
---

Changes in v4:
- new patch

Changes in v3: None
Changes in v2: None

 .../openssl/{openssl_1.1.1a.bb => openssl_1.1.1b.bb}| 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
 rename meta/recipes-connectivity/openssl/{openssl_1.1.1a.bb => 
openssl_1.1.1b.bb} (96%)

diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb 
b/meta/recipes-connectivity/openssl/openssl_1.1.1b.bb
similarity index 96%
rename from meta/recipes-connectivity/openssl/openssl_1.1.1a.bb
rename to meta/recipes-connectivity/openssl/openssl_1.1.1b.bb
index c5900ad536..08f8253156 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.1b.bb
@@ -7,7 +7,7 @@ SECTION = "libs/network"
 # "openssl" here actually means both OpenSSL and SSLeay licenses apply
 # (see meta/files/common-licenses/OpenSSL to which "openssl" is 
SPDXLICENSEMAPped)
 LICENSE = "openssl"
-LIC_FILES_CHKSUM = "file://LICENSE;md5=d57d511030c9d66ef5f5966bee5a7eff"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=d343e62fc9c833710bbbed25f27364c8"
 
 SRC_URI = "http://www.openssl.org/source/openssl-${PV}.tar.gz \
file://run-ptest \
@@ -20,8 +20,8 @@ SRC_URI_append_class-nativesdk = " \
file://environment.d-openssl.sh \
"
 
-SRC_URI[md5sum] = "963deb2272d6be7d4c2458afd2517b73"
-SRC_URI[sha256sum] = 
"fc20130f8b7cbd2fb918b2f14e2f429e109c31ddd0fb38fc5d71d9ffed3f9f41"
+SRC_URI[md5sum] = "4532712e7bcc9414f5bce995e4e13930"
+SRC_URI[sha256sum] = 
"5c557b023230413dfb0756f3137a13e6d726838ccd1430888ad15bfb2b43ea4b"
 
 inherit lib_package multilib_header ptest
 
-- 
2.21.0

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


[OE-core] [PATCH v4 1/2] openssl: Remove the c_rehash shell re-implementation

2019-03-19 Thread Otavio Salvador
We had a c_rehash shell re-implementation being used for the native
package however the ca-certificates now uses the openssl rehash
internal application so there is no use for the c_rehash anymore.

Signed-off-by: Otavio Salvador 
---

Changes in v4:
- remove perlnative requirement

Changes in v3:
- remove c_rehash completely
- fix ca-certificates recipe comment

Changes in v2:
- updated commit log

 .../openssl/openssl/openssl-c_rehash.sh   | 222 --
 .../openssl/openssl_1.1.1a.bb |  15 +-
 .../ca-certificates_20190110.bb   |   2 +-
 3 files changed, 2 insertions(+), 237 deletions(-)
 delete mode 100644 
meta/recipes-connectivity/openssl/openssl/openssl-c_rehash.sh

diff --git a/meta/recipes-connectivity/openssl/openssl/openssl-c_rehash.sh 
b/meta/recipes-connectivity/openssl/openssl/openssl-c_rehash.sh
deleted file mode 100644
index 6620fdcb53..00
--- a/meta/recipes-connectivity/openssl/openssl/openssl-c_rehash.sh
+++ /dev/null
@@ -1,222 +0,0 @@
-#!/bin/sh
-#
-# Ben Secrest 
-#
-# sh c_rehash script, scan all files in a directory
-# and add symbolic links to their hash values.
-#
-# based on the c_rehash perl script distributed with openssl
-#
-# LICENSE: See OpenSSL license
-# ^^acceptable?^^
-#
-
-# default certificate location
-DIR=/etc/openssl
-
-# for filetype bitfield
-IS_CERT=$(( 1 << 0 ))
-IS_CRL=$(( 1 << 1 ))
-
-
-# check to see if a file is a certificate file or a CRL file
-# arguments:
-#   1. the filename to be scanned
-# returns:
-#   bitfield of file type; uses ${IS_CERT} and ${IS_CRL}
-#
-check_file()
-{
-local IS_TYPE=0
-
-# make IFS a newline so we can process grep output line by line
-local OLDIFS=${IFS}
-IFS=$( printf "\n" )
-
-# XXX: could be more efficient to have two 'grep -m' but is -m portable?
-for LINE in $( grep '^-BEGIN .*-' ${1} )
-do
-   if echo ${LINE} \
-   | grep -q -E '^-BEGIN (X509 |TRUSTED )?CERTIFICATE-'
-   then
-   IS_TYPE=$(( ${IS_TYPE} | ${IS_CERT} ))
-
-   if [ $(( ${IS_TYPE} & ${IS_CRL} )) -ne 0 ]
-   then
-   break
-   fi
-   elif echo ${LINE} | grep -q '^-BEGIN X509 CRL-'
-   then
-   IS_TYPE=$(( ${IS_TYPE} | ${IS_CRL} ))
-
-   if [ $(( ${IS_TYPE} & ${IS_CERT} )) -ne 0 ]
-   then
-   break
-   fi
-   fi
-done
-
-# restore IFS
-IFS=${OLDIFS}
-
-return ${IS_TYPE}
-}
-
-
-#
-# use openssl to fingerprint a file
-#arguments:
-#  1. the filename to fingerprint
-#  2. the method to use (x509, crl)
-#returns:
-#  none
-#assumptions:
-#  user will capture output from last stage of pipeline
-#
-fingerprint()
-{
-${SSL_CMD} ${2} -fingerprint -noout -in ${1} | sed 's/^.*=//' | tr -d ':'
-}
-
-
-#
-# link_hash - create links to certificate files
-#arguments:
-#   1. the filename to create a link for
-#  2. the type of certificate being linked (x509, crl)
-#returns:
-#  0 on success, 1 otherwise
-#
-link_hash()
-{
-local FINGERPRINT=$( fingerprint ${1} ${2} )
-local HASH=$( ${SSL_CMD} ${2} -hash -noout -in ${1} )
-local SUFFIX=0
-local LINKFILE=''
-local TAG=''
-
-if [ ${2} = "crl" ]
-then
-   TAG='r'
-fi
-
-LINKFILE=${HASH}.${TAG}${SUFFIX}
-
-while [ -f ${LINKFILE} ]
-do
-   if [ ${FINGERPRINT} = $( fingerprint ${LINKFILE} ${2} ) ]
-   then
-   echo "NOTE: Skipping duplicate file ${1}" >&2
-   return 1
-   fi  
-
-   SUFFIX=$(( ${SUFFIX} + 1 ))
-   LINKFILE=${HASH}.${TAG}${SUFFIX}
-done
-
-echo "${3} => ${LINKFILE}"
-
-# assume any system with a POSIX shell will either support symlinks or
-# do something to handle this gracefully
-ln -s ${3} ${LINKFILE}
-
-return 0
-}
-
-
-# hash_dir create hash links in a given directory
-hash_dir()
-{
-echo "Doing ${1}"
-
-cd ${1}
-
-ls -1 * 2>/dev/null | while read FILE
-do
-if echo ${FILE} | grep -q -E '^[[:xdigit:]]{8}\.r?[[:digit:]]+$' \
-   && [ -h "${FILE}" ]
-then
-rm ${FILE}
-fi
-done
-
-ls -1 *.pem *.cer *.crt *.crl 2>/dev/null | while read FILE
-do
-   REAL_FILE=${FILE}
-   # if we run on build host then get to the real files in rootfs
-   if [ -n "${SYSROOT}" -a -h ${FILE} ]
-   then
-   FILE=$( readlink ${FILE} )
-   # check the symlink is absolute (or dangling in other word)
-   if [ "x/" = "x$( echo ${FILE} | cut -c1 -)" ]
-   then
-   REAL_FILE=${SYSROOT}/${FILE}
-   fi
-   fi
-
-   check_file ${REAL_FILE}
-local FILE_TYPE=${?}
-   local TYPE_STR=''
-
-if [ $(( ${FILE_TYPE} & ${IS_CERT} )) -ne 0 ]
-then
-TYPE_STR='x509'
-elif [ $(( ${FILE_TYPE} & ${IS_CRL} )) -ne 0 ]
-then
-TYPE_STR='crl'
-else

Re: [OE-core] [PATCH 00/26] thud patch review

2019-03-19 Thread Martin Jansa
On Tue, Mar 19, 2019 at 12:35:59PM +0100, Alexander Kanavin wrote:
> Just to remind once more, all upstream support for OpenSSL 1.0.2 ceases in 9 
> months, so shipping products with it may not be the best idea.

Just to remind once more, shipping products isn't as easy as building
the few recipes included in oe-core.

For example:
Believe it or not, some projects need to use old Qt 5.6 due to license
change in newer version and 5.6 doesn't support openssl 1.1,
backporting the necessary changes would violate the license as well.
Providing clean room re-implementation is also difficult, because there
aren't many other options how to implement this than how it was done in
newer qt already, see:

https://bugreports.qt.io/browse/QTBUG-71623
https://development.qt-project.narkive.com/RW4wxYXY/openssl-1-1-x-support-on-qt-5-6-5-9

Yes, it's not the best idea, but even backporting security fixes to old
openssl might be cheaper than buying commercial qt license...

Cheeers,


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


[OE-core] [PATCH] openssl: Upgrade 1.1.1a -> 1.1.1b

2019-03-19 Thread Otavio Salvador
License-Update: copyright years updated
Signed-off-by: Otavio Salvador 
---

 .../openssl/{openssl_1.1.1a.bb => openssl_1.1.1b.bb}| 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
 rename meta/recipes-connectivity/openssl/{openssl_1.1.1a.bb => 
openssl_1.1.1b.bb} (96%)

diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb 
b/meta/recipes-connectivity/openssl/openssl_1.1.1b.bb
similarity index 96%
rename from meta/recipes-connectivity/openssl/openssl_1.1.1a.bb
rename to meta/recipes-connectivity/openssl/openssl_1.1.1b.bb
index d03a225df8..57026596fa 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.1b.bb
@@ -7,7 +7,7 @@ SECTION = "libs/network"
 # "openssl" here actually means both OpenSSL and SSLeay licenses apply
 # (see meta/files/common-licenses/OpenSSL to which "openssl" is 
SPDXLICENSEMAPped)
 LICENSE = "openssl"
-LIC_FILES_CHKSUM = "file://LICENSE;md5=d57d511030c9d66ef5f5966bee5a7eff"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=d343e62fc9c833710bbbed25f27364c8"
 
 DEPENDS = "hostperl-runtime-native"
 
@@ -22,8 +22,8 @@ SRC_URI_append_class-nativesdk = " \
file://environment.d-openssl.sh \
"
 
-SRC_URI[md5sum] = "963deb2272d6be7d4c2458afd2517b73"
-SRC_URI[sha256sum] = 
"fc20130f8b7cbd2fb918b2f14e2f429e109c31ddd0fb38fc5d71d9ffed3f9f41"
+SRC_URI[md5sum] = "4532712e7bcc9414f5bce995e4e13930"
+SRC_URI[sha256sum] = 
"5c557b023230413dfb0756f3137a13e6d726838ccd1430888ad15bfb2b43ea4b"
 
 inherit lib_package multilib_header ptest
 
-- 
2.21.0

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


Re: [OE-core] [PATCH v3] openssl: Remove the c_rehash shell re-implementation

2019-03-19 Thread Otavio Salvador
Hello Martin,

On Mon, Mar 18, 2019 at 9:56 PM Martin Jansa  wrote:
> This won't work if someone uses only openssl10 in the image (a bit difficult 
> to do with current master, but still some people have to do it), in case 
> someone needs it as well, here is how Gentoo makes ca-certificate backwards 
> compatible with old openssl:
> https://github.com/gentoo/gentoo/commit/03f9b674ca3315198c72849e8dd77583974759c2#diff-1801ddca78e57240592ef16b1c5262e7
> more details in:
> https://bugs.gentoo.org/653382

On OE-Core case, even if someone uses openssl10 as the library
provider, it will still use the openssl 1.1 binaries under target.
See:

+PACKAGE_PREPROCESS_FUNCS += "openssl_package_preprocess"
+
+# openssl 1.0 development files and executable binaries clash with openssl 1.1
+# files when installed into target rootfs. So we don't put them into
+# packages, but they continue to be provided via target sysroot for
+# cross-compilation on the host, if some software still depends on openssl 1.0.
+openssl_package_preprocess () {
+for file in `find ${PKGD} -name *.h -o -name *.pc -o -name *.so`; do
+rm $file
+done
+rm ${PKGD}${bindir}/openssl
+rm ${PKGD}${bindir}/c_rehash
+rmdir ${PKGD}${bindir}
+
+}

So for OE-Core, it is not supported. The rootfs generation will still
work, it seems.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH v3 1/2] mesa: Update 18.3.4 -> 19.0.0

2019-03-19 Thread Fabio Berton
  - Patch 0005-egl-add-missing-include-stddef.h-in-egldevice.h.patch
was applied on commit e68777c87ceed02ab199b32f941778c3cf97c794.
  - Refresh all patches
  - mesa 19.0.0 deprecated the use of autotools and we need to add
--enable-autotools flag. For details see mesa commit:
e68777c87ceed02ab199b32f941778c3cf97c794

  The complete change log can be found here:
https://www.mesa3d.org/relnotes/19.0.0.html

Signed-off-by: Fabio Berton 
---
 ...0001-Simplify-wayland-scanner-lookup.patch | 20 
 ...-winsys-svga-drm-Include-sys-types.h.patch |  7 +--
 ...M-version-when-using-LLVM-Git-releas.patch | 13 ++---
 ...R-for-defining-WAYLAND_PROTOCOLS_DAT.patch | 11 +++--
 ...sing-include-stddef.h-in-egldevice.h.patch | 49 ---
 .../{mesa-gl_18.3.4.bb => mesa-gl_19.0.0.bb}  |  0
 meta/recipes-graphics/mesa/mesa.inc   |  4 +-
 .../mesa/{mesa_18.3.4.bb => mesa_19.0.0.bb}   |  5 +-
 8 files changed, 34 insertions(+), 75 deletions(-)
 delete mode 100644 
meta/recipes-graphics/mesa/files/0005-egl-add-missing-include-stddef.h-in-egldevice.h.patch
 rename meta/recipes-graphics/mesa/{mesa-gl_18.3.4.bb => mesa-gl_19.0.0.bb} 
(100%)
 rename meta/recipes-graphics/mesa/{mesa_18.3.4.bb => mesa_19.0.0.bb} (78%)

diff --git 
a/meta/recipes-graphics/mesa/files/0001-Simplify-wayland-scanner-lookup.patch 
b/meta/recipes-graphics/mesa/files/0001-Simplify-wayland-scanner-lookup.patch
index 1c2ded0e60..d065e2285c 100644
--- 
a/meta/recipes-graphics/mesa/files/0001-Simplify-wayland-scanner-lookup.patch
+++ 
b/meta/recipes-graphics/mesa/files/0001-Simplify-wayland-scanner-lookup.patch
@@ -1,7 +1,7 @@
-From 81bcaa1aeecf1e66b4d94181e9a827d68e970b03 Mon Sep 17 00:00:00 2001
+From e53837ad7b01364f34a533b95f4817c1795789de Mon Sep 17 00:00:00 2001
 From: Fabio Berton 
 Date: Wed, 20 Feb 2019 16:17:00 -0300
-Subject: [PATCH 1/5] Simplify wayland-scanner lookup
+Subject: [PATCH 1/4] Simplify wayland-scanner lookup
 Organization: O.S. Systems Software LTDA.
 
 Don't use pkg-config to lookup the path of a binary that's in the path.
@@ -12,31 +12,33 @@ PKG_CONFIG_SYSROOT_DIR.
 Upstream-Status: Pending
 Signed-off-by: Jussi Kukkonen 
 Signed-off-by: Otavio Salvador 
+Signed-off-by: Fabio Berton 
 ---
  configure.ac | 7 +--
  1 file changed, 1 insertion(+), 6 deletions(-)
 
 diff --git a/configure.ac b/configure.ac
-index cd9ff259fad..402b4a91946 100644
+index 1ef68fe68e6..1816a4cd475 100644
 --- a/configure.ac
 +++ b/configure.ac
-@@ -1841,16 +1841,11 @@ for plat in $platforms; do
+@@ -1854,16 +1854,11 @@ for plat in $platforms; do
  fi
  WAYLAND_PROTOCOLS_DATADIR=`$PKG_CONFIG --variable=pkgdatadir 
wayland-protocols`
-
+ 
 -PKG_CHECK_MODULES([WAYLAND_SCANNER], [wayland-scanner],
 -  WAYLAND_SCANNER=`$PKG_CONFIG 
--variable=wayland_scanner wayland-scanner`,
 -  WAYLAND_SCANNER='')
  PKG_CHECK_EXISTS([wayland-scanner >= 1.15],
AC_SUBST(SCANNER_ARG, 'private-code'),
AC_SUBST(SCANNER_ARG, 'code'))
-
+ 
 -if test "x$WAYLAND_SCANNER" = x; then
 -AC_PATH_PROG([WAYLAND_SCANNER], [wayland-scanner], [:])
 -fi
 +AC_PATH_PROG([WAYLAND_SCANNER], [wayland-scanner], [:])
-
+ 
  if test "x$WAYLAND_SCANNER" = "x:"; then
  AC_MSG_ERROR([wayland-scanner is needed to compile the 
wayland platform])
---
-2.20.1
+-- 
+2.21.0
+
diff --git 
a/meta/recipes-graphics/mesa/files/0002-winsys-svga-drm-Include-sys-types.h.patch
 
b/meta/recipes-graphics/mesa/files/0002-winsys-svga-drm-Include-sys-types.h.patch
index 12dca61e19..aaeb0f11ba 100644
--- 
a/meta/recipes-graphics/mesa/files/0002-winsys-svga-drm-Include-sys-types.h.patch
+++ 
b/meta/recipes-graphics/mesa/files/0002-winsys-svga-drm-Include-sys-types.h.patch
@@ -1,7 +1,7 @@
-From 34c3d07b67e6c08f555473a86ff158951abb6000 Mon Sep 17 00:00:00 2001
+From f212b6bed4bf265aec069c21cdc4b7c2d9cb32df Mon Sep 17 00:00:00 2001
 From: Khem Raj 
 Date: Wed, 16 Aug 2017 18:58:20 -0700
-Subject: [PATCH 2/5] winsys/svga/drm: Include sys/types.h
+Subject: [PATCH 2/4] winsys/svga/drm: Include sys/types.h
 Organization: O.S. Systems Software LTDA.
 
 vmw_screen.h uses dev_t which is defines in sys/types.h
@@ -13,6 +13,7 @@ system headers
 Signed-off-by: Khem Raj 
 Upstream-Status: Backport [7dfdfbf8c37e52e7b9b09f7d1d434edad3ebc864]
 Signed-off-by: Otavio Salvador 
+Signed-off-by: Fabio Berton 
 ---
  src/gallium/winsys/svga/drm/vmw_screen.h | 1 +
  1 file changed, 1 insertion(+)
@@ -30,5 +31,5 @@ index a87c087d9c5..cb34fec48e7 100644
  #define VMW_GMR_POOL_SIZE (16*1024*1024)
  #define VMW_QUERY_POOL_SIZE (8192)
 -- 
-2.20.1
+2.21.0
 
diff --git 
a/meta/recipes-graphics/mesa/files/0003-Properly-get-LLVM-version-when-using-LLVM-Git-releas.patch
 
b/meta/recipes-graphics/mesa/files/0003-Properly-get-LLVM-version-when-using-LLVM-Git-releas.patch
index 59b118d9f4..96edc2172b 100644
--- 

[OE-core] [PATCH v3 2/2] mesa: Convert recipe to use meson build system

2019-03-19 Thread Fabio Berton
  - Remove all non related meson patches
  - Change radeon driver to r100
  - Add python3-mako-native and gettext-native to DEPENDS

Based on https://patchwork.openembedded.org/patch/158748/

Signed-off-by: Fabio Berton 
---
 ...0001-Simplify-wayland-scanner-lookup.patch | 44 --
 ...k-for-all-linux-host_os-combinations.patch | 41 +
 ...-winsys-svga-drm-Include-sys-types.h.patch | 35 ---
 ...M-version-when-using-LLVM-Git-releas.patch | 45 --
 ...R-for-defining-WAYLAND_PROTOCOLS_DAT.patch | 38 
 meta/recipes-graphics/mesa/mesa.inc   | 59 +--
 meta/recipes-graphics/mesa/mesa_19.0.0.bb |  5 +-
 7 files changed, 69 insertions(+), 198 deletions(-)
 delete mode 100644 
meta/recipes-graphics/mesa/files/0001-Simplify-wayland-scanner-lookup.patch
 create mode 100644 
meta/recipes-graphics/mesa/files/0001-meson.build-check-for-all-linux-host_os-combinations.patch
 delete mode 100644 
meta/recipes-graphics/mesa/files/0002-winsys-svga-drm-Include-sys-types.h.patch
 delete mode 100644 
meta/recipes-graphics/mesa/files/0003-Properly-get-LLVM-version-when-using-LLVM-Git-releas.patch
 delete mode 100644 
meta/recipes-graphics/mesa/files/0004-use-PKG_CHECK_VAR-for-defining-WAYLAND_PROTOCOLS_DAT.patch

diff --git 
a/meta/recipes-graphics/mesa/files/0001-Simplify-wayland-scanner-lookup.patch 
b/meta/recipes-graphics/mesa/files/0001-Simplify-wayland-scanner-lookup.patch
deleted file mode 100644
index d065e2285c..00
--- 
a/meta/recipes-graphics/mesa/files/0001-Simplify-wayland-scanner-lookup.patch
+++ /dev/null
@@ -1,44 +0,0 @@
-From e53837ad7b01364f34a533b95f4817c1795789de Mon Sep 17 00:00:00 2001
-From: Fabio Berton 
-Date: Wed, 20 Feb 2019 16:17:00 -0300
-Subject: [PATCH 1/4] Simplify wayland-scanner lookup
-Organization: O.S. Systems Software LTDA.
-
-Don't use pkg-config to lookup the path of a binary that's in the path.
-
-Alternatively we'd have to prefix the path returned by pkg-config with
-PKG_CONFIG_SYSROOT_DIR.
-
-Upstream-Status: Pending
-Signed-off-by: Jussi Kukkonen 
-Signed-off-by: Otavio Salvador 
-Signed-off-by: Fabio Berton 

- configure.ac | 7 +--
- 1 file changed, 1 insertion(+), 6 deletions(-)
-
-diff --git a/configure.ac b/configure.ac
-index 1ef68fe68e6..1816a4cd475 100644
 a/configure.ac
-+++ b/configure.ac
-@@ -1854,16 +1854,11 @@ for plat in $platforms; do
- fi
- WAYLAND_PROTOCOLS_DATADIR=`$PKG_CONFIG --variable=pkgdatadir 
wayland-protocols`
- 
--PKG_CHECK_MODULES([WAYLAND_SCANNER], [wayland-scanner],
--  WAYLAND_SCANNER=`$PKG_CONFIG 
--variable=wayland_scanner wayland-scanner`,
--  WAYLAND_SCANNER='')
- PKG_CHECK_EXISTS([wayland-scanner >= 1.15],
-   AC_SUBST(SCANNER_ARG, 'private-code'),
-   AC_SUBST(SCANNER_ARG, 'code'))
- 
--if test "x$WAYLAND_SCANNER" = x; then
--AC_PATH_PROG([WAYLAND_SCANNER], [wayland-scanner], [:])
--fi
-+AC_PATH_PROG([WAYLAND_SCANNER], [wayland-scanner], [:])
- 
- if test "x$WAYLAND_SCANNER" = "x:"; then
- AC_MSG_ERROR([wayland-scanner is needed to compile the 
wayland platform])
--- 
-2.21.0
-
diff --git 
a/meta/recipes-graphics/mesa/files/0001-meson.build-check-for-all-linux-host_os-combinations.patch
 
b/meta/recipes-graphics/mesa/files/0001-meson.build-check-for-all-linux-host_os-combinations.patch
new file mode 100644
index 00..23e207aebf
--- /dev/null
+++ 
b/meta/recipes-graphics/mesa/files/0001-meson.build-check-for-all-linux-host_os-combinations.patch
@@ -0,0 +1,41 @@
+From 021c24931367c83b62c550d1a296b0e9676726c0 Mon Sep 17 00:00:00 2001
+From: Fabio Berton 
+Date: Fri, 15 Mar 2019 17:42:50 -0300
+Subject: [PATCH] meson.build: check for all linux host_os combinations
+Organization: O.S. Systems Software LTDA.
+
+Make sure that we are also looking for our host_os combinations like
+linux-musl etc. when assuming support for DRM/KMS.
+
+Also delete a duplicate line.
+
+Signed-off-by: Anuj Mittal 
+---
+ meson.build | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/meson.build b/meson.build
+index 9272590201d..56465513da9 100644
+--- a/meson.build
 b/meson.build
+@@ -89,7 +89,7 @@ if (with_gles1 or with_gles2) and not with_opengl
+   error('building OpenGL ES without OpenGL is not supported.')
+ endif
+ 
+-system_has_kms_drm = ['openbsd', 'netbsd', 'freebsd', 'dragonfly', 
'linux'].contains(host_machine.system())
++system_has_kms_drm = ['openbsd', 'netbsd', 'freebsd', 
'dragonfly'].contains(host_machine.system()) or 
host_machine.system().startswith('linux')
+ 
+ _drivers = get_option('dri-drivers')
+ if _drivers.contains('auto')
+@@ -792,7 +792,7 @@ if cc.compiles('int foo(void) 
__attribute__((__noreturn__));',
+ endif
+ 
+ # TODO: this is very incomplete
+-if ['linux', 'cygwin', 'gnu'].contains(host_machine.system())
++if ['cygwin', 

[OE-core] [PATCH] Remove the simd tune for armv8a

2019-03-19 Thread Adrian Bunk
SIMD instructions are a mandatory part of armv8a
(they were optional in armv7a), and the gcc docs
also say that they are always enabled.

Signed-off-by: Adrian Bunk 
---
 meta/conf/machine/include/arm/arch-armv8a.inc | 6 ++
 meta/conf/machine/include/tune-cortexa32.inc  | 4 ++--
 meta/conf/machine/include/tune-cortexa35.inc  | 4 ++--
 meta/conf/machine/include/tune-cortexa53.inc  | 4 ++--
 meta/conf/machine/include/tune-cortexa72.inc  | 2 +-
 5 files changed, 9 insertions(+), 11 deletions(-)

diff --git a/meta/conf/machine/include/arm/arch-armv8a.inc 
b/meta/conf/machine/include/arm/arch-armv8a.inc
index 22064559be..44d0ca4557 100644
--- a/meta/conf/machine/include/arm/arch-armv8a.inc
+++ b/meta/conf/machine/include/arm/arch-armv8a.inc
@@ -2,8 +2,6 @@ DEFAULTTUNE ?= "armv8a-crc"
 
 TUNEVALID[armv8a] = "Enable instructions for ARMv8-a"
 TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv8a', ' 
-march=armv8-a', '', d)}"
-TUNEVALID[simd] = "Enable instructions for ARMv8-a Advanced SIMD and 
floating-point"
-TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'simd', '+simd', '', d)}"
 TUNEVALID[crc] = "Enable instructions for ARMv8-a Cyclic Redundancy Check 
(CRC)"
 TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'crc', '+crc', '', d)}"
 TUNEVALID[crypto] = "Enable instructions for ARMv8-a cryptographic"
@@ -18,11 +16,11 @@ ARMPKGARCH_tune-armv8a?= "armv8a"
 ARMPKGARCH_tune-armv8a-crc?= "armv8a"
 ARMPKGARCH_tune-armv8a-crypto ?= "armv8a"
 ARMPKGARCH_tune-armv8a-crc-crypto ?= "armv8a"
-TUNE_FEATURES_tune-armv8a  = "aarch64 armv8a simd"
+TUNE_FEATURES_tune-armv8a  = "aarch64 armv8a"
 TUNE_FEATURES_tune-armv8a-crc  = "${TUNE_FEATURES_tune-armv8a} crc"
 TUNE_FEATURES_tune-armv8a-crypto   = "${TUNE_FEATURES_tune-armv8a} 
crypto"
 TUNE_FEATURES_tune-armv8a-crc-crypto   = "${TUNE_FEATURES_tune-armv8a-crc} 
crypto"
-PACKAGE_EXTRA_ARCHS_tune-armv8a= "aarch64 armv8a simd"
+PACKAGE_EXTRA_ARCHS_tune-armv8a= "aarch64 armv8a"
 PACKAGE_EXTRA_ARCHS_tune-armv8a-crc= 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a} crc"
 PACKAGE_EXTRA_ARCHS_tune-armv8a-crypto = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a} crypto"
 PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} crypto"
diff --git a/meta/conf/machine/include/tune-cortexa32.inc 
b/meta/conf/machine/include/tune-cortexa32.inc
index 4bf7f774e1..9c948f1766 100644
--- a/meta/conf/machine/include/tune-cortexa32.inc
+++ b/meta/conf/machine/include/tune-cortexa32.inc
@@ -10,8 +10,8 @@ require conf/machine/include/arm/arch-armv8a.inc
 AVAILTUNES += "cortexa32 cortexa32-crypto"
 ARMPKGARCH_tune-cortexa32 = "cortexa32"
 ARMPKGARCH_tune-cortexa32-crypto  = "cortexa32"
-TUNE_FEATURES_tune-cortexa32  = "aarch64 cortexa32 simd crc"
-TUNE_FEATURES_tune-cortexa32-crypto   = "aarch64 cortexa32 simd crc crypto"
+TUNE_FEATURES_tune-cortexa32  = "aarch64 cortexa32 crc"
+TUNE_FEATURES_tune-cortexa32-crypto   = "aarch64 cortexa32 crc crypto"
 PACKAGE_EXTRA_ARCHS_tune-cortexa32 = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa32"
 PACKAGE_EXTRA_ARCHS_tune-cortexa32-crypto  = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa32 cortexa32-crypto"
 BASE_LIB_tune-cortexa32   = "lib64"
diff --git a/meta/conf/machine/include/tune-cortexa35.inc 
b/meta/conf/machine/include/tune-cortexa35.inc
index 6ece810753..d6df6cd6bd 100644
--- a/meta/conf/machine/include/tune-cortexa35.inc
+++ b/meta/conf/machine/include/tune-cortexa35.inc
@@ -9,8 +9,8 @@ require conf/machine/include/arm/arch-armv8a.inc
 AVAILTUNES += "cortexa35 cortexa35-crypto"
 ARMPKGARCH_tune-cortexa35 = "cortexa35"
 ARMPKGARCH_tune-cortexa35-crypto  = "cortexa35"
-TUNE_FEATURES_tune-cortexa35  = "aarch64 cortexa35 simd crc"
-TUNE_FEATURES_tune-cortexa35-crypto   = "aarch64 cortexa35 simd crc crypto"
+TUNE_FEATURES_tune-cortexa35  = "aarch64 cortexa35 crc"
+TUNE_FEATURES_tune-cortexa35-crypto   = "aarch64 cortexa35 crc crypto"
 PACKAGE_EXTRA_ARCHS_tune-cortexa35 = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa35"
 PACKAGE_EXTRA_ARCHS_tune-cortexa35-crypto  = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa35 cortexa35-crypto"
 BASE_LIB_tune-cortexa35   = "lib64"
diff --git a/meta/conf/machine/include/tune-cortexa53.inc 
b/meta/conf/machine/include/tune-cortexa53.inc
index 9fb37ff639..6c0b443eaf 100644
--- a/meta/conf/machine/include/tune-cortexa53.inc
+++ b/meta/conf/machine/include/tune-cortexa53.inc
@@ -9,8 +9,8 @@ require conf/machine/include/arm/arch-armv8a.inc
 AVAILTUNES += "cortexa53 cortexa53-crypto"
 ARMPKGARCH_tune-cortexa53 = "cortexa53"
 ARMPKGARCH_tune-cortexa53-crypto  = "cortexa53"
-TUNE_FEATURES_tune-cortexa53  = "aarch64 cortexa53 simd crc"
-TUNE_FEATURES_tune-cortexa53-crypto   = "aarch64 

Re: [OE-core] [PATCH 00/26] thud patch review

2019-03-19 Thread Alexander Kanavin
Just to remind once more, all upstream support for OpenSSL 1.0.2 ceases in 9 
months, so shipping products with it may not be the best idea.

Alex

> On 19 Mar 2019, at 11.40, Martin Jansa  wrote:
> 
>> On Tue, Mar 19, 2019 at 11:22:11AM +0100, Alexander Kanavin wrote:
>> The commit you refer to changes the dependency from 1.1.0 to 1.1.1, so 
>> ca-certificates currently in thud already needs 1.1.
>> 
>> Alex
>> 
 On 19 Mar 2019, at 9.55, Martin Jansa  wrote:
 
 On Mon, Mar 18, 2019 at 07:36:29PM -0700, Armin Kuster wrote:
 Responses should be made by Wed March 20th 22:00:00 UTC 2019
 
 The following changes since commit 
 f5a57e939e626a5b7c6de5b51799ca602ed355ed:
 
 mesa: ship /etc/drirc in mesa-megadriver (2019-03-05 22:24:13 +)
 
 are available in the git repository at:
 
 git://git.yoctoproject.org/poky-contrib stable/thud-next
 http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=stable/thud-next
 
 Alexander Kanavin (1):
 ca-certificates: upgrade 20180409 -> 20190110
>>> 
>>> This depends on openssl >= 1.1.1 since:
>>> https://salsa.debian.org/debian/ca-certificates/commit/d5e425c8405448e5034d1e16ca52be6a10cb3334
>>> some people might not use new openssl with thud.
>>> 
>>> More detail in:
>>> http://lists.openembedded.org/pipermail/openembedded-core/2019-March/280234.html
> 
> hmm right
> https://salsa.debian.org/debian/ca-certificates/commit/1bc87e0b41a04551a93d4e784e158b044c18792a
> was already included in 20180409, another thing to work around when
> upgrading to thud.
> 
> Cheers,
> 
> -- 
> Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [oe-core 2/2] glib-networking:enable glib-networking complie as native package

2019-03-19 Thread Richard Purdie
On Tue, 2019-03-19 at 15:54 +0800, Jiang Lu wrote:
> Enable glib-networking compile as a native package, for it is
> depended by
> libsoup.
> 
> Signed-off-by: Jiang Lu 
> ---
>  .../glib-networking/glib-networking_2.58.0.bb | 31
> +++
>  1 file changed, 31 insertions(+)
> 
> diff --git a/meta/recipes-core/glib-networking/glib-
> networking_2.58.0.bb b/meta/recipes-core/glib-networking/glib-
> networking_2.58.0.bb
> index f3190e1cae..35b4a3fa76 100644
> --- a/meta/recipes-core/glib-networking/glib-networking_2.58.0.bb
> +++ b/meta/recipes-core/glib-networking/glib-networking_2.58.0.bb
> @@ -29,3 +29,34 @@ FILES_${PN} += "\
>  "
>  FILES_${PN}-dev += "${libdir}/gio/modules/libgio*.la"
>  FILES_${PN}-staticdev += "${libdir}/gio/modules/libgio*.a"
> +
> +# Make sure we compile with ca-certificates support enabled.
> +PACKAGECONFIG_append = " ca-certificates"
> +
> +DEPENDS += "ca-certificates"
> +RDEPENDS_${PN} += "ca-certificates"
> +
> +# We need native version for ostree-/flatpak-native.
> +BBCLASSEXTEND = "native"
> +# OE-core's relocatable.bbclass assumes that every package which
> +# ends up creating a ${libdir}/pkgconfig directory in its sysroot
> +# will always also install .pc-files there and tries to uncondi-
> +# tionally update paths in those files using globbing that fails
> +# if no such files are present. This presumption is not true for
> +# glib-networking which happens to create a directory by
> dereferencing
> +# a GIO pkgconfig variable which in turn is defined relative to
> +# the pkgconfig directory (${pcfiledir}/../...), causing pkgconfig
> +# to get created.
> +#
> +# Could be worked around in the upatream recipe but since that
> +# does not provide/create native versions of the package and since
> +# this problem is related to native packages, we work around it
> here.
> +#
> +do_install_append_class-native () {
> +for _pc in ${D}${libdir}/pkgconfig/*.pc; do
> +case $_pc in
> +*'*.pc') rm -fr ${D}${libdir}/pkgconfig;;
> +*.pc)break;;
> +esac
> +done
> +}

This reads as if there is a bbappend in some layer which is now being
dumped verbatim into the upstream recipe with no thought as to what
makes sense.

We don't do PACKAGECONFIG_append in recipes and we don't hack .pc files
like this. The dependencies suggest we should also fix the
PACKAGECONFIG DEPENDS/RDEPENDS too.

This needs more work.

Also, for the first patch, its unclear why we need/want the patch
present there and the commit shortlog doesn't really describe the
multiple things the patch is doing.

Cheers,

Richard


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


Re: [OE-core] [PATCH 00/26] thud patch review

2019-03-19 Thread Martin Jansa
On Tue, Mar 19, 2019 at 11:22:11AM +0100, Alexander Kanavin wrote:
> The commit you refer to changes the dependency from 1.1.0 to 1.1.1, so 
> ca-certificates currently in thud already needs 1.1.
> 
> Alex
> 
> > On 19 Mar 2019, at 9.55, Martin Jansa  wrote:
> > 
> >> On Mon, Mar 18, 2019 at 07:36:29PM -0700, Armin Kuster wrote:
> >> Responses should be made by Wed March 20th 22:00:00 UTC 2019
> >> 
> >> The following changes since commit 
> >> f5a57e939e626a5b7c6de5b51799ca602ed355ed:
> >> 
> >>  mesa: ship /etc/drirc in mesa-megadriver (2019-03-05 22:24:13 +)
> >> 
> >> are available in the git repository at:
> >> 
> >>  git://git.yoctoproject.org/poky-contrib stable/thud-next
> >>  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=stable/thud-next
> >> 
> >> Alexander Kanavin (1):
> >>  ca-certificates: upgrade 20180409 -> 20190110
> > 
> > This depends on openssl >= 1.1.1 since:
> > https://salsa.debian.org/debian/ca-certificates/commit/d5e425c8405448e5034d1e16ca52be6a10cb3334
> > some people might not use new openssl with thud.
> > 
> > More detail in:
> > http://lists.openembedded.org/pipermail/openembedded-core/2019-March/280234.html

hmm right
https://salsa.debian.org/debian/ca-certificates/commit/1bc87e0b41a04551a93d4e784e158b044c18792a
was already included in 20180409, another thing to work around when
upgrading to thud.

Cheers,

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


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


Re: [OE-core] [PATCH v2 1/2] mesa: Update 18.3.4 -> 19.0.0

2019-03-19 Thread Richard Purdie
On Mon, 2019-03-18 at 18:13 -0300, Fabio Berton wrote:
>   - Patch 0005-egl-add-missing-include-stddef.h-in-egldevice.h.patch
> was applied on commit e68777c87ceed02ab199b32f941778c3cf97c794.
>   - Refresh all patches
>   - mesa 19.0.0 deprecated the use of autotools and we need to add
> --enable-autotools flag. For details see mesa commit:
> e68777c87ceed02ab199b32f941778c3cf97c794
> 
>   The complete change log can be found here:
> https://www.mesa3d.org/relnotes/19.0.0.html
> 
> Signed-off-by: Fabio Berton 

mesa-native fails to build and qemu seems to be struggling with this
change:

https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/93

I appreciate that wider testing on the autobuilder is helpful but
these mesa upgrades don't seem to have even the basics right :(

There were other issues in this build as one of the workers seems to
have been failing to clean up old files which complicates the output.

Cheers,

Richard



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


Re: [OE-core] [thud][PATCH] yocto-uninative: Correct sha256sum for aarch64

2019-03-19 Thread Manjukumar Harthikote Matha
Hi,

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Robert Joslyn
> Sent: Tuesday, March 12, 2019 9:04 PM
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [thud][PATCH] yocto-uninative: Correct sha256sum for 
> aarch64
> 
> From: Michael Halstead 
> 
> Avoid uninative checksum warnings when building on aarch64 hardware.
> 

On what machines does it fail? Should be backport this to thud v2.6.1?

Thanks,
Manju


> Signed-off-by: Michael Halstead 
> Signed-off-by: Richard Purdie 
> ---
>  meta/conf/distro/include/yocto-uninative.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/conf/distro/include/yocto-uninative.inc
> b/meta/conf/distro/include/yocto-uninative.inc
> index c9d502ba4f..0d484f6c3c 100644
> --- a/meta/conf/distro/include/yocto-uninative.inc
> +++ b/meta/conf/distro/include/yocto-uninative.inc
> @@ -9,7 +9,7 @@
>  UNINATIVE_MAXGLIBCVERSION = "2.28"
> 
>  UNINATIVE_URL ?= "http://downloads.yoctoproject.org/releases/uninative/2.3/;
> -UNINATIVE_CHECKSUM[aarch64] ?=
> "b7fbbaad1ec86d76eca84d83098f50525b8a4124cc8685eaed"
> +UNINATIVE_CHECKSUM[aarch64] ?=
> "e495046969c796b7fbbaad1ec86d76eca84d83098f50525b8a4124cc8685eaed"
>  UNINATIVE_CHECKSUM[i686] ?=
> "44253cddbf629082568cea4fff59419106871a0cf81b4845b5d34e7014887b20"
>  UNINATIVE_CHECKSUM[x86_64] ?=
> "c6954563dad3c95608117c6fc328099036c832bbd924ebf5fdccb622fc0a8684"
> 
> --
> 2.19.2
> 
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 00/26] thud patch review

2019-03-19 Thread Alexander Kanavin
The commit you refer to changes the dependency from 1.1.0 to 1.1.1, so 
ca-certificates currently in thud already needs 1.1.

Alex

> On 19 Mar 2019, at 9.55, Martin Jansa  wrote:
> 
>> On Mon, Mar 18, 2019 at 07:36:29PM -0700, Armin Kuster wrote:
>> Responses should be made by Wed March 20th 22:00:00 UTC 2019
>> 
>> The following changes since commit f5a57e939e626a5b7c6de5b51799ca602ed355ed:
>> 
>>  mesa: ship /etc/drirc in mesa-megadriver (2019-03-05 22:24:13 +)
>> 
>> are available in the git repository at:
>> 
>>  git://git.yoctoproject.org/poky-contrib stable/thud-next
>>  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=stable/thud-next
>> 
>> Alexander Kanavin (1):
>>  ca-certificates: upgrade 20180409 -> 20190110
> 
> This depends on openssl >= 1.1.1 since:
> https://salsa.debian.org/debian/ca-certificates/commit/d5e425c8405448e5034d1e16ca52be6a10cb3334
> some people might not use new openssl with thud.
> 
> More detail in:
> http://lists.openembedded.org/pipermail/openembedded-core/2019-March/280234.html
> 
> Cheers,
> -- 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 00/26] thud patch review

2019-03-19 Thread Vincent Prince
Hi Armin,

Regarding target-sdk-provides-dummy: add more perl modules to avoid
populate_sdk failure patch, I had to complete it with following bbappend:

DUMMYPROVIDES_append = "\
perl-module-warnings-register \
perl-module-config \
perl-module-overloading \
perl-module-warnings \
perl-module-file-temp \
"

Don't know if we should rework Chen Qi patch or create a new one.
By the way, can't we add every empty perl packages in dummy automatically?

Best regards,
Vincent

Le mar. 19 mars 2019 à 03:37, Armin Kuster  a écrit :

> Responses should be made by Wed March 20th 22:00:00 UTC 2019
>
> The following changes since commit
> f5a57e939e626a5b7c6de5b51799ca602ed355ed:
>
>   mesa: ship /etc/drirc in mesa-megadriver (2019-03-05 22:24:13 +)
>
> are available in the git repository at:
>
>   git://git.yoctoproject.org/poky-contrib stable/thud-next
>
> http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=stable/thud-next
>
> Alexander Kanavin (1):
>   ca-certificates: upgrade 20180409 -> 20190110
>
> André Draszik (1):
>   systemd: RDEPENDS on util-linux-umount
>
> Changqing Li (1):
>   libsndfile1: Security fix CVE-2018-19432
>
> Chen Qi (1):
>   target-sdk-provides-dummy: add more perl modules to avoid populate_sdk
> failure
>
> Douglas Royds (1):
>   libpam: libpamc is licensed under its own BSD-style licence
>
> George McCollister (1):
>   systemd: fix CVE-2019-6454
>
> Jonathan Rajotte-Julien (3):
>   lttng-ust: update to 2.10.3
>   lttng-modules: update to 2.10.9
>   lttng-tools: update to 2.9.11
>
> Mark Hatle (10):
>   gitsm.py: Fix when a submodule is defined, but not initialized
>   gitsm.py: Add support for alternative URL formats from submodule files
>   tests/fetch.py: Add alternative gitsm test case
>   gitsm.py: Optimize code and attempt to resolve locking issue
>   gitsm.py: revise unpack
>   gitsm.py: Rework the shallow fetcher and test case
>   gitsm.py: Refactor the functions and simplify the class
>   gitsm.py: Fix relative URLs
>   gitsmy.py: Fix unpack of submodules of submodules
>   gitsm: The fetcher did not process some recursive submodules properly.
>
> Ming Liu (1):
>   rm_work: sort the value of do_build dependencies
>
> Oleksandr Kravchuk (1):
>   target-sdk-provides-dummy: add perl-module-overload
>
> Richard Purdie (3):
>   target-sdk-provides-dummy: Extend to -dev and -src packages
>   systemd: Update recent CVE patches
>   kernel: Ensure an initramfs is added if configured
>
> Robert Yang (1):
>   send-error-report: Add --no-ssl to use http protocol
>
> Ross Burton (1):
>   libpng: fix CVE-2019-7317
>
>  bitbake/lib/bb/fetch2/gitsm.py | 253
> +
>  bitbake/lib/bb/tests/fetch.py  |  70 +-
>  meta/classes/kernel.bbclass|   4 +-
>  meta/classes/rm_work.bbclass   |   3 +-
>  .../recipes-core/meta/target-sdk-provides-dummy.bb |  14 ++
>  ...-not-store-the-iovec-entry-for-process-co.patch |   6 +-
>  ...ld-set-a-limit-on-the-number-of-fields-1k.patch |  56 -
>  ...nald-set-a-limit-on-the-number-of-fields.patch} |  93 ++--
>  ...nal-fix-out-of-bounds-read-CVE-2018-16866.patch |  49 
>  .../0027-journal-fix-syslog_parse_identifier.patch |  77 ---
>  ...not-remove-multiple-spaces-after-identifi.patch |  84 ---
>  .../systemd/systemd/CVE-2019-6454.patch| 210 +
>  ...e-receive-an-invalid-dbus-message-ignore-.patch |  61 +
>  meta/recipes-core/systemd/systemd_239.bb   |  10 +-
>  meta/recipes-extended/pam/libpam_1.3.0.bb  |   4 +-
>  ...ose-sk-wmem-in-sock_exceed_buf_limit-trac.patch |  67 --
>  ...g-modules_2.10.7.bb => lttng-modules_2.10.9.bb} |   5 +-
>  ...ow-multiple-attempts-to-connect-to-relayd.patch |  17 +-
>  ...{lttng-tools_2.9.5.bb => lttng-tools_2.9.11.bb} |   4 +-
>  .../{lttng-ust_2.10.1.bb => lttng-ust_2.10.3.bb}   |   4 +-
>  .../libpng/libpng/CVE-2019-7317.patch  |  20 ++
>  meta/recipes-multimedia/libpng/libpng_1.6.36.bb|   3 +-
>  .../libsndfile/libsndfile1/CVE-2018-19432.patch| 115 ++
>  .../libsndfile/libsndfile1_1.0.28.bb   |   1 +
>  ...tes_20180409.bb => ca-certificates_20190110.bb} |   2 +-
>  scripts/send-error-report  |  11 +-
>  26 files changed, 758 insertions(+), 485 deletions(-)
>  delete mode 100644
> meta/recipes-core/systemd/systemd/0025-journald-set-a-limit-on-the-number-of-fields-1k.patch
>  rename
> meta/recipes-core/systemd/systemd/{0026-journal-remote-set-a-limit-on-the-number-of-fields-i.patch
> => 0025-journald-set-a-limit-on-the-number-of-fields.patch} (47%)
>  create mode 100644
> meta/recipes-core/systemd/systemd/0026-journal-fix-out-of-bounds-read-CVE-2018-16866.patch
>  delete mode 100644
> meta/recipes-core/systemd/systemd/0027-journal-fix-syslog_parse_identifier.patch
>  delete mode 100644
> 

Re: [OE-core] [PATCH 00/26] thud patch review

2019-03-19 Thread Martin Jansa
On Mon, Mar 18, 2019 at 07:36:29PM -0700, Armin Kuster wrote:
> Responses should be made by Wed March 20th 22:00:00 UTC 2019
> 
> The following changes since commit f5a57e939e626a5b7c6de5b51799ca602ed355ed:
> 
>   mesa: ship /etc/drirc in mesa-megadriver (2019-03-05 22:24:13 +)
> 
> are available in the git repository at:
> 
>   git://git.yoctoproject.org/poky-contrib stable/thud-next
>   http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=stable/thud-next
> 
> Alexander Kanavin (1):
>   ca-certificates: upgrade 20180409 -> 20190110

This depends on openssl >= 1.1.1 since:
https://salsa.debian.org/debian/ca-certificates/commit/d5e425c8405448e5034d1e16ca52be6a10cb3334
some people might not use new openssl with thud.

More detail in:
http://lists.openembedded.org/pipermail/openembedded-core/2019-March/280234.html

Cheers,


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


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

2019-03-19 Thread mingli.yu
From: Mingli Yu 

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

Initialize st_mode member to fix the above issue.

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

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

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


Re: [OE-core] [thud][PATCH] Revert "boost: update to 1.69.0"

2019-03-19 Thread Mikko.Rapeli
On Mon, Mar 18, 2019 at 06:03:05PM +0100, Andreas Müller wrote:
> On Mon, Mar 18, 2019 at 5:45 PM Armin Kuster  wrote:
> >
> > This reverts commit a384248938ea9db096866bf4ec8678d35ca62a12.
> >
> > This package update slipped in doing the maint process. Removing it.

> Just my opinion - don't consider this as NAK.
> 
> * I already fixed the recipes that failed for me. For at least one the
> change is no more compatible to 1.68.0.
> * This makes PV going backwards
> 
> Thanks for addressing - what do others think?

I'm not using thud yet, but updating boost in stable branch would break
too many things and I would have to revert that change in our trees. Some boost
updates are in the end quite trivial and just require recompiling
everything but still, I would prefer that boost is not updated in stable
branches unless there is a huge security/stability issue with the old version.

Hope this helps,

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


[OE-core] [oe-core 1/2] libsoup:add soup_uri_to_string_with_password

2019-03-19 Thread Jiang Lu
The existed soup_uri_to_string does not have password, add a
function to support it.

Besides, allow libsoup compiled as a native package and add
glib-networking into dependency list.

Signed-off-by: Hongxu Jia 
Signed-off-by: Jiang Lu 
---
 ...add-soup_uri_to_string_with_password.patch | 67 +++
 .../libsoup/libsoup-2.4_2.64.2.bb |  5 +-
 2 files changed, 71 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-support/libsoup/libsoup-2.4/0001-add-soup_uri_to_string_with_password.patch

diff --git 
a/meta/recipes-support/libsoup/libsoup-2.4/0001-add-soup_uri_to_string_with_password.patch
 
b/meta/recipes-support/libsoup/libsoup-2.4/0001-add-soup_uri_to_string_with_password.patch
new file mode 100644
index 00..c679d6b9e5
--- /dev/null
+++ 
b/meta/recipes-support/libsoup/libsoup-2.4/0001-add-soup_uri_to_string_with_password.patch
@@ -0,0 +1,67 @@
+From 82c2f059bc7c491c8c4c728408eb913bfc4a6f0a Mon Sep 17 00:00:00 2001
+From: Hongxu Jia 
+Date: Wed, 6 Jun 2018 22:37:30 +0800
+Subject: [PATCH] add soup_uri_to_string_with_password
+
+The existed soup_uri_to_string does not have password, add a
+function to support it.
+
+Upstream-Status: Pending
+
+Signed-off-by: Hongxu Jia 
+---
+ libsoup/soup-uri.c | 21 +
+ libsoup/soup-uri.h |  5 +
+ 2 files changed, 26 insertions(+)
+
+diff --git a/libsoup/soup-uri.c b/libsoup/soup-uri.c
+index 3eafd87..8421f1c 100644
+--- a/libsoup/soup-uri.c
 b/libsoup/soup-uri.c
+@@ -619,6 +619,27 @@ soup_uri_to_string (SoupURI *uri, gboolean 
just_path_and_query)
+ }
+ 
+ /**
++ * soup_uri_to_string_with_password:
++ * @uri: a #SoupURI
++ * @just_path_and_query: if %TRUE, output just the path and query portions
++ *
++ * Returns a string representing @uri.
++ *
++ * If @just_path_and_query is %TRUE, this concatenates the path and query
++ * together. That is, it constructs the string that would be needed in
++ * the Request-Line of an HTTP request for @uri.
++ *
++ * Note that the output will contain a password, if @uri does.
++ *
++ * Return value: a string representing @uri, which the caller must free.
++ **/
++char *
++soup_uri_to_string_with_password (SoupURI *uri, gboolean just_path_and_query)
++{
++  return soup_uri_to_string_internal (uri, just_path_and_query, TRUE, 
FALSE);
++}
++
++/**
+  * soup_uri_copy:
+  * @uri: a #SoupURI
+  *
+diff --git a/libsoup/soup-uri.h b/libsoup/soup-uri.h
+index b9360c6..af702d3 100644
+--- a/libsoup/soup-uri.h
 b/libsoup/soup-uri.h
+@@ -57,6 +57,11 @@ char   *soup_uri_to_string (SoupURI
*uri,
+   gbooleanjust_path_and_query);
+ 
+ SOUP_AVAILABLE_IN_2_4
++char *soup_uri_to_string_with_password (SoupURI
*uri,
++  gbooleanjust_path_and_query);
++
++
++SOUP_AVAILABLE_IN_2_4
+ SoupURI  *soup_uri_copy  (SoupURI*uri);
+ 
+ SOUP_AVAILABLE_IN_2_4
+-- 
+2.7.4
+
diff --git a/meta/recipes-support/libsoup/libsoup-2.4_2.64.2.bb 
b/meta/recipes-support/libsoup/libsoup-2.4_2.64.2.bb
index ae7c1a6863..c2284c0458 100644
--- a/meta/recipes-support/libsoup/libsoup-2.4_2.64.2.bb
+++ b/meta/recipes-support/libsoup/libsoup-2.4_2.64.2.bb
@@ -11,6 +11,7 @@ SHRT_VER = 
"${@d.getVar('PV').split('.')[0]}.${@d.getVar('PV').split('.')[1]}"
 
 SRC_URI = "${GNOME_MIRROR}/libsoup/${SHRT_VER}/libsoup-${PV}.tar.xz \

file://0001-Do-not-enforce-no-introspection-when-cross-building.patch \
+   file://0001-add-soup_uri_to_string_with_password.patch \
"
 SRC_URI[md5sum] = "cac755dc6c6acd6e0c70007f547548f5"
 SRC_URI[sha256sum] = 
"75ddc194a5b1d6f25033bb9d355f04bfe5c03e0e1c71ed0774104457b3a786c6"
@@ -48,4 +49,6 @@ EXTRA_OEMESON_append_class-target = " 
${@bb.utils.contains('GTKDOC_ENABLED', 'Tr
 DEBIAN_NOAUTONAME_${PN} = "1"
 
 # glib-networking is needed for SSL, proxies, etc.
-RRECOMMENDS_${PN} = "glib-networking"
+DEPENDS += "glib-networking"
+
+BBCLASSEXTEND = "native"
-- 
2.17.1

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


[OE-core] [oe-core 2/2] glib-networking:enable glib-networking complie as native package

2019-03-19 Thread Jiang Lu
Enable glib-networking compile as a native package, for it is depended by
libsoup.

Signed-off-by: Jiang Lu 
---
 .../glib-networking/glib-networking_2.58.0.bb | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/meta/recipes-core/glib-networking/glib-networking_2.58.0.bb 
b/meta/recipes-core/glib-networking/glib-networking_2.58.0.bb
index f3190e1cae..35b4a3fa76 100644
--- a/meta/recipes-core/glib-networking/glib-networking_2.58.0.bb
+++ b/meta/recipes-core/glib-networking/glib-networking_2.58.0.bb
@@ -29,3 +29,34 @@ FILES_${PN} += "\
 "
 FILES_${PN}-dev += "${libdir}/gio/modules/libgio*.la"
 FILES_${PN}-staticdev += "${libdir}/gio/modules/libgio*.a"
+
+# Make sure we compile with ca-certificates support enabled.
+PACKAGECONFIG_append = " ca-certificates"
+
+DEPENDS += "ca-certificates"
+RDEPENDS_${PN} += "ca-certificates"
+
+# We need native version for ostree-/flatpak-native.
+BBCLASSEXTEND = "native"
+# OE-core's relocatable.bbclass assumes that every package which
+# ends up creating a ${libdir}/pkgconfig directory in its sysroot
+# will always also install .pc-files there and tries to uncondi-
+# tionally update paths in those files using globbing that fails
+# if no such files are present. This presumption is not true for
+# glib-networking which happens to create a directory by dereferencing
+# a GIO pkgconfig variable which in turn is defined relative to
+# the pkgconfig directory (${pcfiledir}/../...), causing pkgconfig
+# to get created.
+#
+# Could be worked around in the upatream recipe but since that
+# does not provide/create native versions of the package and since
+# this problem is related to native packages, we work around it here.
+#
+do_install_append_class-native () {
+for _pc in ${D}${libdir}/pkgconfig/*.pc; do
+case $_pc in
+*'*.pc') rm -fr ${D}${libdir}/pkgconfig;;
+*.pc)break;;
+esac
+done
+}
-- 
2.17.1

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


[OE-core] libsoup:add a new routine & build as native package

2019-03-19 Thread Jiang Lu


Hi all,

This rr including 2 patch:
1.add a new routine for libsoup with name soup_uri_to_string_with_password()
and make libsoup compiled as a native package.
2.make glib-networking compiled as a native package.

Make this change for ostree utilies, which needs libsoup when building ostree 
image
on host.

Thanks
Jiang Lu

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


[OE-core] [PATCH] [PATCH] nss:upgrade to 3.43

2019-03-19 Thread Hong Liu
1.Upgrade nss from 3.42.1 to 3.43.

Signed-off-by: Hong Liu 
---
 meta/recipes-support/nss/{nss_3.42.1.bb => nss_3.43.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-support/nss/{nss_3.42.1.bb => nss_3.43.bb} (98%)

diff --git a/meta/recipes-support/nss/nss_3.42.1.bb 
b/meta/recipes-support/nss/nss_3.43.bb
similarity index 98%
rename from meta/recipes-support/nss/nss_3.42.1.bb
rename to meta/recipes-support/nss/nss_3.43.bb
index b6bbd800fc..14a17335a2 100644
--- a/meta/recipes-support/nss/nss_3.42.1.bb
+++ b/meta/recipes-support/nss/nss_3.43.bb
@@ -30,8 +30,8 @@ SRC_URI = 
"http://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/${VERSIO
file://system-pkcs11.txt \
"
 
-SRC_URI[md5sum] = "1f6cc6c702379478a3a72298caaef0a7"
-SRC_URI[sha256sum] = 
"087db37d38fd49dfd584dd2a8b5baa7fc88de7c9bd97c0c2d5be4abcafc61fc6"
+SRC_URI[md5sum] = "67c8fa282c32cb56117fdd530dd77001"
+SRC_URI[sha256sum] = 
"f30bc1b7330887b75de9fec37dbc173001758dc43fb095ffbc45dac4093fe2ca"
 
 UPSTREAM_CHECK_URI = 
"https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_Releases;
 UPSTREAM_CHECK_REGEX = "NSS_(?P.+)_release_notes"
-- 
2.20.1



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