Re: [OE-core] Yocto Project Status WW47’17

[Robert Yang]

On 11/21/2017 07:09 PM, Richard Purdie wrote:

On Mon, 2017-11-20 at 20:22 -0500, Randy MacLeod wrote:

On 2017-11-20 10:36 AM, Jolley, Stephen K wrote:

Current Dev Position: YP 2.5 Planning and M1 development
Next Deadline: YP 2.5 M1 cut off of 12/4/17
  
SWAT team rotation: Juro -> Paul on Nov.17, 2017.

SWAT team rotation: Paul -> Todor on Nov. 24, 2017.
https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team
  
Key Status/Updates:

·    There is no real change to the status from last week. We
continue to suffer intermittent build failures and are continuing
to attempt to debug these.
·    Currently open issues are:
  
Some US-based people may be on holiday later this week so I'm

offering
help from the frozen Northland and more importantly from the team in
Beijing. ;-)


o   qemuppc continues to demonstrate random hangs in boot  in
userspace
  
Is we can create a defect for this and point / copy the wiki notes

into it, that
would help.
    https://wiki.yoctoproject.org/wiki/Qemuppc_Boot_Hangs

I think I had asked Chi to see if he could reproduce this a week or
two ago.
When the lack of entropy problem was identified and fix, many people
thought
this hang went away as well. Chi can you read the wiki report and see
if you
can add anything to them?


Good news is that the qemuppc issue has been identified as a bug in
qemu ppc locking which breaks timer interrupt handling. I've posted on
the qemu mailing list asking for help in verifying what I think is
happening.

I have a patch ready to merge which should address this one, just
cleaning up my environment and doing some further stress testing.

[There is a defect somewhere for this btw, I created the wiki as it was
a better place to dump and update information as we learnt what it
is/is not without having to follow a train of thought updating in the
bugzilla].


o   Issues with 4.13.10 host kernels booting kvm x86 guests on
Tumbleweed (Suse) and Fedora 26 (attempting to see if 4.13.12
helps)
  
Robert, can you test Fedora 26. It would help to have a defect open

with steps to reproduce or
something about the typical workflow/ build time/ day of the week/
phase of the moon.


FWIW we have noticed that the choice of kernel timers seems to vary in
the x86_64 boots but not with a pattern that matches the hangs.


o   nfs inode count for the sstate/dldir share appears to break
periodically causing the disk monitor to halt the builds (bug
12267)
  
Likely specific to the AB server so no plans to do anything for this

bug.


Agreed, this one is our infrastructure somehow :(. We have a workaround
in -next for this at least.


o   a perf build race (bug 12302)

   I'll take a look to:
  - see if I can duplicate the bug on a fast build host
  - check upstream to see if the bug is known/fixed
  - see if I can spot a race in the build rules.


Sounds good, thanks!


o   An ext filesystem creation/sizing issue (bug 12304)
  
Saul, Are you around this week? Do you have any additional

information before
leaving for Thanksgiving?

Jackie,
Can you look at the code around the image creation and try to
reproduce this one?


Saul hasn't been able to reproduce. I've asked at the minimum we add
better logging so if/when this happens again, we can debug it properly
next time. I did also wonder about fuzzing the image size code, writing
some code which puts in all possible input values and checks the sanity
of the resulting image size. Its the kind of problem a computer can
probably brute force. Anyone interested in trying that?


I have interests on it, but I don't quite understand what did you mean.
Currently, the image size is from "du -sh " * factor, about
the bug 12304, it got 8192 which is the default value of core-image-minimal,
so maybe something is wrong with "du -sh", the normal value is larger than 8192.

// Robert



Cheers,

Richard




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

Re: [OE-core] backfill mechanism

[Huang, Jie (Jackie)]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Slater, Joseph
> Sent: Wednesday, November 22, 2017 03:11
> To: Andre McCurdy
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] backfill mechanism
> 
> The problem is that when backfilling is done, TUNE_FEATURES, etc, all have
> values associated with the base arch, not the current multilib.  The "generic"
> solution, below, should work, although I would still use overrides when 
> available.
> 
> Beyond what actually works, if the special backfill processing can be 
> eliminated
> and regular constructs used I think that would be desirable.
> 
> Joe
> 
> From: Andre McCurdy [armccu...@gmail.com]
> Sent: Monday, November 20, 2017 7:24 PM
> To: Slater, Joseph
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] backfill mechanism
> 
> On Fri, Nov 17, 2017 at 3:32 PM, Slater, Joseph
>  wrote:
> > The backfill mechanism is not compatible with multilib.
> 
> Did anyone ever explain why?

I think it should be a defect, so I just opened one:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=12373

Thanks,
Jackie

> 
> > This could possibly
> > be fixed, but the backfill_considered functionality is also obscure, so I
> > think in at least the machine related .inc files we should replace lines
> > like
> >
> > MACHINE_FEATURES_BACKFILL_CONSIDERED_append = "
> > ${@bb.utils.contains('TUNE_FEATURES', 'n32', 'qemu-usermode', '', d)}"
> >
> > with lines like
> >
> > MACHINE_FEATURES_remove_mipsarchn32 = " qemu-usermode"
> 
> That only works for TUNE_FEATURES which happen to have a corresponding
> over-ride, so may not be a generic solution. Does something like:
> 
>   MACHINE_FEATURES_remove = "${@bb.utils.contains('TUNE_FEATURES',
> 'n32', 'qemu-usermode', '', d)}"
> 
> work for multilib?
> 
> > There are two advantages:  the second line works for multilib, and it is far
> > more readable.
> >
> > Joe
> >
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/3] systemd: fix formatting IDE storage does not trigger "change" uevents

[Hongxu Jia]

On 2017年11月21日 19:31, Burton, Ross wrote:
On 21 November 2017 at 07:00, Hongxu Jia > wrote:


1. Tweak kernel-cache to remove CONFIG_IDE for all available bsp.
    It require necessary test to prove it is safe to remove it.
    If the test is OK, I will send patch to yocto mailing list.


I know you have your own huge autobuilder framework inside WR but I'll 
happily throw a patch against oe-core at the public autobuilders for 
extra testing.




No problem, I would like the public autobuilders.

But there several banners:

1. I do not have account on public autobuilder
    https://autobuilder.yocto.io/

    Maybe I should ask Michael or Joshua for help

2. The fix is on kernel-cache, not directly on oe-core,
    So it is difficult to use autobuilder

   Maybe I should ask Bruce for help

3. Most importantly, how to test, when find a way,
    the ideally is to add the test case to oe-core's
    meta-selftest

   I should do some investigation on the storage test.

So I think I should do 3 first, and then 1/2 later

//Hongxu


Ross



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

[OE-core] [PATCH v3 1/2] runqemu: Allow the user to override the Kernel option

[Alistair Francis]

Update the runqemu script to allow the user to specify a Kernel to boot
when calling runqemu.

Signed-off-by: Alistair Francis 
Cc: Ben Levinsky 
---
 scripts/runqemu | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/scripts/runqemu b/scripts/runqemu
index cd9443595b..44cf39f7f0 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -584,11 +584,15 @@ class BaseConfig(object):
 if self.fstype in self.vmtypes:
 return
 
+# See if the user supplied a KERNEL option
+if self.get('KERNEL'):
+self.kernel = self.get('KERNEL')
+
 # QB_DEFAULT_KERNEL is always a full file path
 kernel_name = os.path.basename(self.get('QB_DEFAULT_KERNEL'))
 
 # The user didn't want a kernel to be loaded
-if kernel_name == "none":
+if kernel_name == "none" and not self.kernel:
 return
 
 deploy_dir_image = self.get('DEPLOY_DIR_IMAGE')
-- 
2.14.1

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

Re: [OE-core] [PATCH] glibc: malloc: Add missing arena lock in malloc_info

[Andre McCurdy]

On Tue, Nov 21, 2017 at 3:05 PM, Burton, Ross  wrote:
> What glibc release is this in?  We've an upgrade patch pending that bumps it
> to 77f921dac17c5fa99bd9e926d926c327982895f7.

It's currently in the glibc master branch only (ie hasn't been
backported to the 2.26 release branch).
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2 2/2] runqemu: Allow the user to override the device tree option

[Alistair Francis]

On Tue, Nov 14, 2017 at 4:32 AM, Burton, Ross  wrote:
> Doesn't actually work if DEVICE_TREE is not set but QB_DTB is:
>
> Traceback (most recent call last):
>   File
> "/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-arm-lsb/build/scripts/runqemu",
> line 1277, in main
> config.check_and_set()
>   File
> "/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-arm-lsb/build/scripts/runqemu",
> line 692, in check_and_set
> self.check_dtb()
>   File
> "/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-arm-lsb/build/scripts/runqemu",
> line 624, in check_dtb
> cmd_match = "%s/%s" % (deploy_dir_image, dtb)
> NameError: name 'deploy_dir_image' is not defined

Ah! I don't know how that slipped through.

Fixed in v3. Thanks for looking at the patch.

Alistair

>
> Ross
>
> On 13 October 2017 at 00:32, Alistair Francis 
> wrote:
>>
>> Update the runqemu script to allow the user to specify a device tree
>> to boot when calling runqemu.
>>
>> This involves creating a seperate check_dtb() function incase the user
>> has specified 'none' for the kernel but still wants a device tree.
>>
>> Signed-off-by: Alistair Francis 
>> Reviewed-by: Ben Levinsky 
>> Cc: Ben Levinsky 
>> ---
>>  scripts/runqemu | 14 +-
>>  1 file changed, 13 insertions(+), 1 deletion(-)
>>
>> diff --git a/scripts/runqemu b/scripts/runqemu
>> index c3719a86f7..1be6db0eea 100755
>> --- a/scripts/runqemu
>> +++ b/scripts/runqemu
>> @@ -69,6 +69,7 @@ Usage: you can run this script with any valid
>> combination
>>  of the following environment variables (in any order):
>>KERNEL - the kernel image file to use
>>ROOTFS - the rootfs image file or nfsroot directory to use
>> +  DEVICE_TREE - the device tree blob to use
>>MACHINE - the machine name (optional, autodetected from KERNEL filename
>> if unspecified)
>>Simplified QEMU command-line options can be passed with:
>>  nographic - disable video console
>> @@ -178,6 +179,7 @@ class BaseConfig(object):
>>  self.env_vars = ('MACHINE',
>>  'ROOTFS',
>>  'KERNEL',
>> +'DEVICE_TREE',
>>  'DEPLOY_DIR_IMAGE',
>>  'OE_TMPDIR',
>>  'OECORE_NATIVE_SYSROOT',
>> @@ -579,7 +581,7 @@ class BaseConfig(object):
>>  raise RunQemuError("Can't find OVMF firmware: %s" % ovmf)
>>
>>  def check_kernel(self):
>> -"""Check and set kernel, dtb"""
>> +"""Check and set kernel"""
>>  # The vm image doesn't need a kernel
>>  if self.fstype in self.vmtypes:
>>  return
>> @@ -608,6 +610,15 @@ class BaseConfig(object):
>>  if not os.path.exists(self.kernel):
>>  raise RunQemuError("KERNEL %s not found" % self.kernel)
>>
>> +def check_dtb(self):
>> +"""Check and set dtb"""
>> +# Did the user specify a device tree?
>> +if self.get('DEVICE_TREE'):
>> +self.dtb = self.get('DEVICE_TREE')
>> +if not os.path.exists(self.dtb):
>> +raise RunQemuError('Specified DTB not found: %s' %
>> self.dtb)
>> +return
>> +
>>  dtb = self.get('QB_DTB')
>>  if dtb:
>>  cmd_match = "%s/%s" % (deploy_dir_image, dtb)
>> @@ -678,6 +689,7 @@ class BaseConfig(object):
>>  self.check_rootfs()
>>  self.check_ovmf()
>>  self.check_kernel()
>> +self.check_dtb()
>>  self.check_biosdir()
>>  self.check_mem()
>>  self.check_tcpserial()
>> --
>> 2.11.0
>>
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] bin_package: fail if ${S} doesn't actually contain anything

[Ross Burton]

If the user is trying to use bin_package but the SRC_URI hasn't extracted
anything into ${S}, which is easily done when writing a recipe by hand, instead
of silently shippping an empty package abort the build.

Signed-off-by: Ross Burton 
---
 meta/classes/bin_package.bbclass | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta/classes/bin_package.bbclass b/meta/classes/bin_package.bbclass
index a52b75be5c0..cbc9b1fa131 100644
--- a/meta/classes/bin_package.bbclass
+++ b/meta/classes/bin_package.bbclass
@@ -26,7 +26,10 @@ do_compile[noexec] = "1"
 bin_package_do_install () {
 # Do it carefully
 [ -d "${S}" ] || exit 1
-cd ${S} || exit 1
+if [ -z "$(ls -A ${S})" ]; then
+bbfatal bin_package has nothing to install. Be sure the SRC_URI 
unpacks into S.
+fi
+cd ${S}
 tar --no-same-owner --exclude='./patches' --exclude='./.pc' -cpf - . \
 | tar --no-same-owner -xpf - -C ${D}
 }
-- 
2.11.0

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

Re: [OE-core] [PATCH] glibc: malloc: Add missing arena lock in malloc_info

[Burton, Ross]

What glibc release is this in?  We've an upgrade patch pending that bumps
it to 77f921dac17c5fa99bd9e926d926c327982895f7.

Ross

On 20 November 2017 at 07:44, Zhixiong Chi 
wrote:

> There are the multiple process crashes seen while using malloc_info.
> Obtain the size information while the arena lock is acquired, and only
> print it later.
>
> Backport patch from https://sourceware.org/git/gitweb.cgi?p=glibc.git;
> h=7a9368a1174cb15b9f1d6342e0e10dd90dae238d
>
> Signed-off-by: Zhixiong Chi 
> ---
>  ...loc-add-missing-arena-lock-in-malloc-info.patch | 172
> +
>  meta/recipes-core/glibc/glibc_2.26.bb  |   1 +
>  2 files changed, 173 insertions(+)
>  create mode 100644 meta/recipes-core/glibc/glibc/
> 0029-malloc-add-missing-arena-lock-in-malloc-info.patch
>
> diff --git a/meta/recipes-core/glibc/glibc/0029-malloc-add-missing-
> arena-lock-in-malloc-info.patch b/meta/recipes-core/glibc/
> glibc/0029-malloc-add-missing-arena-lock-in-malloc-info.patch
> new file mode 100644
> index 000..e12400d
> --- /dev/null
> +++ b/meta/recipes-core/glibc/glibc/0029-malloc-add-missing-
> arena-lock-in-malloc-info.patch
> @@ -0,0 +1,172 @@
> +From: Florian Weimer 
> +Date: Wed, 15 Nov 2017 11:39:01 +0100
> +Subject: [PATCH] malloc: Add missing arena lock in malloc_info [BZ #22408]
> +
> +Obtain the size information while the arena lock is acquired, and only
> +print it later.
> +
> +Upstream-Status: Backport
> +
> +Signed-off-by: Zhixiong Chi 
> +
> +Index: git/malloc/Makefile
> +===
> +--- git.orig/malloc/Makefile   2017-09-04 17:34:06.758018978 +0800
>  git/malloc/Makefile2017-11-20 14:57:43.440337572 +0800
> +@@ -34,6 +34,7 @@
> +tst-interpose-nothread \
> +tst-interpose-thread \
> +tst-alloc_buffer \
> ++   tst-malloc_info \
> +
> + tests-static := \
> +tst-interpose-static-nothread \
> +@@ -242,3 +243,5 @@
> + $(objpfx)tst-dynarray-fail-mem.out: $(objpfx)tst-dynarray-fail.out
> +   $(common-objpfx)malloc/mtrace $(objpfx)tst-dynarray-fail.mtrace >
> $@; \
> +   $(evaluate-test)
> ++
> ++$(objpfx)tst-malloc_info: $(shared-thread-library)
> +Index: git/malloc/malloc.c
> +===
> +--- git.orig/malloc/malloc.c   2017-09-04 17:34:06.758018978 +0800
>  git/malloc/malloc.c2017-11-20 15:01:02.412338959 +0800
> +@@ -5547,6 +5547,15 @@
> + avail += sizes[NFASTBINS - 1 + i].total;
> +   }
> +
> ++  size_t heap_size = 0;
> ++  size_t heap_mprotect_size = 0;
> ++  if (ar_ptr != _arena)
> ++  {
> ++heap_info *heap = heap_for_ptr (top (ar_ptr));
> ++heap_size = heap->size;
> ++heap_mprotect_size = heap->mprotect_size;
> ++  }
> ++
> +   __libc_lock_unlock (ar_ptr->mutex);
> +
> +   total_nfastblocks += nfastblocks;
> +@@ -5580,13 +5589,12 @@
> +
> +   if (ar_ptr != _arena)
> +   {
> +-heap_info *heap = heap_for_ptr (top (ar_ptr));
> + fprintf (fp,
> +  "\n"
> +  "\n",
> +- heap->size, heap->mprotect_size);
> +-total_aspace += heap->size;
> +-total_aspace_mprotect += heap->mprotect_size;
> ++ heap_size, heap_mprotect_size);
> ++total_aspace += heap_size;
> ++total_aspace_mprotect += heap_mprotect_size;
> +   }
> +   else
> +   {
> +Index: git/malloc/tst-malloc_info.c
> +===
> +--- /dev/null  1970-01-01 00:00:00.0 +
>  git/malloc/tst-malloc_info.c   2017-11-20 15:02:03.208339383 +0800
> +@@ -0,0 +1,101 @@
> ++/* Smoke test for malloc_info.
> ++   Copyright (C) 2017 Free Software Foundation, Inc.
> ++   This file is part of the GNU C Library.
> ++
> ++   The GNU C Library is free software; you can redistribute it and/or
> ++   modify it under the terms of the GNU Lesser General Public
> ++   License as published by the Free Software Foundation; either
> ++   version 2.1 of the License, or (at your option) any later version.
> ++
> ++   The GNU C Library is distributed in the hope that it will be useful,
> ++   but WITHOUT ANY WARRANTY; without even the implied warranty of
> ++   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> ++   Lesser General Public License for more details.
> ++
> ++   You should have received a copy of the GNU Lesser General Public
> ++   License along with the GNU C Library; if not, see
> ++   .  */
> ++
> ++/* The purpose of this test is to provide a quick way to run
> ++   malloc_info in a multi-threaded process.  */
> ++
> ++#include 
> ++#include 
> ++#include 
> ++#include 
> ++#include 
> ++
> ++/* This barrier is used to have the main thread wait until the 

Re: [OE-core] [PATCH v2 2/2] install*.sh: add short sleep after parted commands

[Wold, Saul]

Much better!

Sau!

On Tue, 2017-11-21 at 15:02 -0800, California Sullivan wrote:
> I wasn't able to install to my Optane SSD due to the following error:
> 
> Formatting /dev/nvme0n1p1 to vfat...
> mkfs.fat 4.1 (2017-01-24)
> mkfs.vfat: unable to open /dev/nvme0n1p1: No such file or directory
> Target install-efi failed
> 
> A couple lines later I see:
> 
> [10.265401]  nvme0n1: p1 p2 p3
> 
> Then looking at the device itself after booting from a USB stick:
> 
> root@intel-corei7-64: ~# ls /dev/nvme0n1*
> /dev/nvme0n1 /dev/nvme0n1p1 /dev/nvme0n1p2 /dev/nvme0n1p3
> 
> So it looks like the parted commands return before the device node is
> actually created.
> 
> Work around this issue by waiting for device nodes for a short
> duration.
> 
> Signed-off-by: California Sullivan 
> ---
> v2: sleep conditionally for up to three seconds instead of one second
> unconditionally. This makes it so if the device nodes are available
> immediately, people don't have to wait, but a system has up to three
> seconds to create them before failing. 
> 
>  meta/recipes-core/initrdscripts/files/init-install-efi.sh | 7
> +++
>  meta/recipes-core/initrdscripts/files/init-install.sh | 7
> +++
>  2 files changed, 14 insertions(+)
> 
> diff --git a/meta/recipes-core/initrdscripts/files/init-install-
> efi.sh b/meta/recipes-core/initrdscripts/files/init-install-efi.sh
> index 5ad3a60..706418f 100644
> --- a/meta/recipes-core/initrdscripts/files/init-install-efi.sh
> +++ b/meta/recipes-core/initrdscripts/files/init-install-efi.sh
> @@ -186,6 +186,13 @@ parted ${device} mkpart swap linux-swap
> $swap_start 100%
>  
>  parted ${device} print
>  
> +echo "Waiting for device nodes..."
> +C=0
> +while [ $C -ne 3 ] && [ ! -e $bootfs  -o ! -e $rootfs -o ! -e $swap
> ]; do
> +C=$(( C + 1 ))
> +sleep 1
> +done
> +
>  echo "Formatting $bootfs to vfat..."
>  mkfs.vfat $bootfs
>  
> diff --git a/meta/recipes-core/initrdscripts/files/init-install.sh
> b/meta/recipes-core/initrdscripts/files/init-install.sh
> index 1cac806..dade059 100644
> --- a/meta/recipes-core/initrdscripts/files/init-install.sh
> +++ b/meta/recipes-core/initrdscripts/files/init-install.sh
> @@ -211,6 +211,13 @@ parted ${device} mkpart $pname linux-swap
> $swap_start 100%
>  
>  parted ${device} print
>  
> +echo "Waiting for device nodes..."
> +C=0
> +while [ $C -ne 3 ] && [ ! -e $bootfs  -o ! -e $rootfs -o ! -e $swap
> ]; do
> +C=$(( C + 1 ))
> +sleep 1
> +done
> +
>  echo "Formatting $bootfs to ext3..."
>  mkfs.ext3 $bootfs
>  
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2 2/2] install*.sh: add short sleep after parted commands

[California Sullivan]

I wasn't able to install to my Optane SSD due to the following error:

Formatting /dev/nvme0n1p1 to vfat...
mkfs.fat 4.1 (2017-01-24)
mkfs.vfat: unable to open /dev/nvme0n1p1: No such file or directory
Target install-efi failed

A couple lines later I see:

[10.265401]  nvme0n1: p1 p2 p3

Then looking at the device itself after booting from a USB stick:

root@intel-corei7-64: ~# ls /dev/nvme0n1*
/dev/nvme0n1 /dev/nvme0n1p1 /dev/nvme0n1p2 /dev/nvme0n1p3

So it looks like the parted commands return before the device node is
actually created.

Work around this issue by waiting for device nodes for a short duration.

Signed-off-by: California Sullivan 
---
v2: sleep conditionally for up to three seconds instead of one second
unconditionally. This makes it so if the device nodes are available
immediately, people don't have to wait, but a system has up to three
seconds to create them before failing. 

 meta/recipes-core/initrdscripts/files/init-install-efi.sh | 7 +++
 meta/recipes-core/initrdscripts/files/init-install.sh | 7 +++
 2 files changed, 14 insertions(+)

diff --git a/meta/recipes-core/initrdscripts/files/init-install-efi.sh 
b/meta/recipes-core/initrdscripts/files/init-install-efi.sh
index 5ad3a60..706418f 100644
--- a/meta/recipes-core/initrdscripts/files/init-install-efi.sh
+++ b/meta/recipes-core/initrdscripts/files/init-install-efi.sh
@@ -186,6 +186,13 @@ parted ${device} mkpart swap linux-swap $swap_start 100%
 
 parted ${device} print
 
+echo "Waiting for device nodes..."
+C=0
+while [ $C -ne 3 ] && [ ! -e $bootfs  -o ! -e $rootfs -o ! -e $swap ]; do
+C=$(( C + 1 ))
+sleep 1
+done
+
 echo "Formatting $bootfs to vfat..."
 mkfs.vfat $bootfs
 
diff --git a/meta/recipes-core/initrdscripts/files/init-install.sh 
b/meta/recipes-core/initrdscripts/files/init-install.sh
index 1cac806..dade059 100644
--- a/meta/recipes-core/initrdscripts/files/init-install.sh
+++ b/meta/recipes-core/initrdscripts/files/init-install.sh
@@ -211,6 +211,13 @@ parted ${device} mkpart $pname linux-swap $swap_start 100%
 
 parted ${device} print
 
+echo "Waiting for device nodes..."
+C=0
+while [ $C -ne 3 ] && [ ! -e $bootfs  -o ! -e $rootfs -o ! -e $swap ]; do
+C=$(( C + 1 ))
+sleep 1
+done
+
 echo "Formatting $bootfs to ext3..."
 mkfs.ext3 $bootfs
 
-- 
2.9.5

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

Re: [OE-core] [PATCH 2/2] install*.sh: add short sleep after parted commands

[Saul Wold]

On Tue, 2017-11-21 at 13:47 -0800, California Sullivan wrote:
> I wasn't able to install to my Optane SSD due to the following error:
> 
> Formatting /dev/nvme0n1p1 to vfat...
> mkfs.fat 4.1 (2017-01-24)
> mkfs.vfat: unable to open /dev/nvme0n1p1: No such file or directory
> Target install-efi failed
> 
> A couple lines later I see:
> 
> [10.265401]  nvme0n1: p1 p2 p3
> 
> Then looking at the device itself after booting from a USB stick:
> 
> root@intel-corei7-64: ~# ls /dev/nvme0n1*
> /dev/nvme0n1 /dev/nvme0n1p1 /dev/nvme0n1p2 /dev/nvme0n1p3
> 
> So it looks like the parted commands return before the device node is
> actually created.
> 
> Work around this issue by adding a short sleep before doing the mkfs
> commands.
> 
Not advisable to just add the sleep, maybe a check before to see if the
device exists and then sleep (or usleep, if we have it) and do this in
a while loop with a counter to actually timeout after some number of
sleeps.

Yes more work, but more appropriate if the settle time is not actually
needed or a longer settle time is required.

Thanks
Sau!

> Signed-off-by: California Sullivan 
> ---
>  meta/recipes-core/initrdscripts/files/init-install-efi.sh | 2 ++
>  meta/recipes-core/initrdscripts/files/init-install.sh | 2 ++
>  2 files changed, 4 insertions(+)
> 
> diff --git a/meta/recipes-core/initrdscripts/files/init-install-
> efi.sh b/meta/recipes-core/initrdscripts/files/init-install-efi.sh
> index 5ad3a60..118bf08 100644
> --- a/meta/recipes-core/initrdscripts/files/init-install-efi.sh
> +++ b/meta/recipes-core/initrdscripts/files/init-install-efi.sh
> @@ -186,6 +186,8 @@ parted ${device} mkpart swap linux-swap
> $swap_start 100%
>  
>  parted ${device} print
>  
> +sleep 1
> +
>  echo "Formatting $bootfs to vfat..."
>  mkfs.vfat $bootfs
>  
> diff --git a/meta/recipes-core/initrdscripts/files/init-install.sh
> b/meta/recipes-core/initrdscripts/files/init-install.sh
> index 1cac806..606317d 100644
> --- a/meta/recipes-core/initrdscripts/files/init-install.sh
> +++ b/meta/recipes-core/initrdscripts/files/init-install.sh
> @@ -211,6 +211,8 @@ parted ${device} mkpart $pname linux-swap
> $swap_start 100%
>  
>  parted ${device} print
>  
> +sleep 1
> +
>  echo "Formatting $bootfs to ext3..."
>  mkfs.ext3 $bootfs
>  
> -- 
> 2.9.5
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [morty][PATCH v3 2/2] glibc: Fix CVE-2017-1000366

[Khem Raj]

On Tue, Nov 21, 2017 at 12:01 PM, George McCollister
 wrote:
> Add backported patches from the upstream release/2.24/master branch to
> fix CVE-2017-1000366. Also add a backported patch that resolves SSE
> related build problems introduced by these patches.
>

these patches look ok. what arches has you tested it on

> Signed-off-by: George McCollister 
> ---
>
> Changes in v2:
>  - Fix commit message
>
> Changes in v3:
>  - Added upstream patch to fix SSE issue introduced by this patch
>series.
>
>  ...00366-Ignore-LD_LIBRARY_PATH-for-AT_SECUR.patch |  71 +++
>  ...ject-overly-long-LD_PRELOAD-path-elements.patch | 145 +
>  ...Reject-overly-long-LD_AUDIT-path-elements.patch | 231 
> +
>  ...ssing-IS_IN-libc-guards-to-vectorized-str.patch |  62 ++
>  meta/recipes-core/glibc/glibc_2.24.bb  |   4 +
>  5 files changed, 513 insertions(+)
>  create mode 100644 
> meta/recipes-core/glibc/glibc/0001-CVE-2017-1000366-Ignore-LD_LIBRARY_PATH-for-AT_SECUR.patch
>  create mode 100644 
> meta/recipes-core/glibc/glibc/0002-ld.so-Reject-overly-long-LD_PRELOAD-path-elements.patch
>  create mode 100644 
> meta/recipes-core/glibc/glibc/0003-ld.so-Reject-overly-long-LD_AUDIT-path-elements.patch
>  create mode 100644 
> meta/recipes-core/glibc/glibc/0004-i686-Add-missing-IS_IN-libc-guards-to-vectorized-str.patch
>
> diff --git 
> a/meta/recipes-core/glibc/glibc/0001-CVE-2017-1000366-Ignore-LD_LIBRARY_PATH-for-AT_SECUR.patch
>  
> b/meta/recipes-core/glibc/glibc/0001-CVE-2017-1000366-Ignore-LD_LIBRARY_PATH-for-AT_SECUR.patch
> new file mode 100644
> index 00..78e9ea9e65
> --- /dev/null
> +++ 
> b/meta/recipes-core/glibc/glibc/0001-CVE-2017-1000366-Ignore-LD_LIBRARY_PATH-for-AT_SECUR.patch
> @@ -0,0 +1,71 @@
> +From 400f170750a4b2c94a2670ca44de166cc5dd6e3b Mon Sep 17 00:00:00 2001
> +From: Florian Weimer 
> +Date: Mon, 19 Jun 2017 18:33:26 +0200
> +Subject: [PATCH] CVE-2017-1000366: Ignore LD_LIBRARY_PATH for AT_SECURE=1
> + programs [BZ #21624]
> +
> +LD_LIBRARY_PATH can only be used to reorder system search paths, which
> +is not useful functionality.
> +
> +This makes an exploitable unbounded alloca in _dl_init_paths unreachable
> +for AT_SECURE=1 programs.
> +
> +(cherry picked from commit f6110a8fee2ca36f8e2d2abecf3cba9fa7b8ea7d)
> +
> +Upstream-Status: Backport
> +https://sourceware.org/git/?p=glibc.git;a=commit;h=87bd4186da10371f46e2f1a7bf7c0a45bb04f1ac
> +https://anonscm.debian.org/cgit/pkg-glibc/glibc.git/commit/?h=stretch=2755c57269f24e9d59c22c49788f92515346c1bb
> +
> +CVE: CVE-2017-1000366
> +
> +Signed-off-by: George McCollister 
> +---
> + ChangeLog  | 7 +++
> + NEWS   | 1 +
> + elf/rtld.c | 3 ++-
> + 3 files changed, 10 insertions(+), 1 deletion(-)
> +
> +diff --git a/ChangeLog b/ChangeLog
> +index 2bdaf69e43..7a999802dd 100644
> +--- a/ChangeLog
>  b/ChangeLog
> +@@ -1,3 +1,10 @@
> ++2017-06-19  Florian Weimer  
> ++
> ++  [BZ #21624]
> ++  CVE-2017-1000366
> ++  * elf/rtld.c (process_envvars): Ignore LD_LIBRARY_PATH for
> ++  __libc_enable_secure.
> ++
> + 2016-12-31  Florian Weimer  
> +
> +   [BZ #18784]
> +diff --git a/NEWS b/NEWS
> +index 4b1ca3cb65..66b49dbbc0 100644
> +--- a/NEWS
>  b/NEWS
> +@@ -17,6 +17,7 @@ using `glibc' in the "product" field.
> +   question type which is outside the range of valid question type values.
> +   (CVE-2015-5180)
> +
> ++  [21624] Unsafe alloca allows local attackers to alias stack and heap 
> (CVE-2017-1000366)
> + Version 2.24
> +
> + * The minimum Linux kernel version that this version of the GNU C Library
> +diff --git a/elf/rtld.c b/elf/rtld.c
> +index 647661ca45..215a9aec8f 100644
> +--- a/elf/rtld.c
>  b/elf/rtld.c
> +@@ -2437,7 +2437,8 @@ process_envvars (enum mode *modep)
> +
> +   case 12:
> + /* The library search path.  */
> +-if (memcmp (envline, "LIBRARY_PATH", 12) == 0)
> ++if (!__libc_enable_secure
> ++&& memcmp (envline, "LIBRARY_PATH", 12) == 0)
> +   {
> + library_path = [13];
> + break;
> +--
> +2.15.0
> +
> diff --git 
> a/meta/recipes-core/glibc/glibc/0002-ld.so-Reject-overly-long-LD_PRELOAD-path-elements.patch
>  
> b/meta/recipes-core/glibc/glibc/0002-ld.so-Reject-overly-long-LD_PRELOAD-path-elements.patch
> new file mode 100644
> index 00..7f81ed1566
> --- /dev/null
> +++ 
> b/meta/recipes-core/glibc/glibc/0002-ld.so-Reject-overly-long-LD_PRELOAD-path-elements.patch
> @@ -0,0 +1,145 @@
> +From 6d49272e6d6741496e3456f2cc22ebc2b9f7f989 Mon Sep 17 00:00:00 2001
> +From: Florian Weimer 
> +Date: Mon, 19 Jun 2017 22:31:04 +0200
> +Subject: [PATCH] ld.so: Reject overly long LD_PRELOAD path elements
> +
> +(cherry picked from commit 6d0ba622891bed9d8394eef1935add53003b12e8)
> +
> +Upstream-Status: Backport
> 

[OE-core] [PATCH 1/2] init-install: fix grub-install command

[California Sullivan]

The grub_version variable was calling 'grub-install -v' (verbose) instead
of 'grub-install -V' (version) causing unexpected failures.

Fixes bug [YOCTO #12111].

Signed-off-by: California Sullivan 
---
 meta/recipes-core/initrdscripts/files/init-install.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/initrdscripts/files/init-install.sh 
b/meta/recipes-core/initrdscripts/files/init-install.sh
index 572613e..1cac806 100644
--- a/meta/recipes-core/initrdscripts/files/init-install.sh
+++ b/meta/recipes-core/initrdscripts/files/init-install.sh
@@ -132,7 +132,7 @@ fi
 
 disk_size=$(parted ${device} unit mb print | grep '^Disk .*: .*MB' | cut -d" " 
-f 3 | sed -e "s/MB//")
 
-grub_version=$(grub-install -v|sed 's/.* \([0-9]\).*/\1/')
+grub_version=$(grub-install -V|sed 's/.* \([0-9]\).*/\1/')
 
 if [ $grub_version -eq 0 ] ; then
 bios_boot_size=0
-- 
2.9.5

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

[OE-core] [PATCH 2/2] install*.sh: add short sleep after parted commands

[California Sullivan]

I wasn't able to install to my Optane SSD due to the following error:

Formatting /dev/nvme0n1p1 to vfat...
mkfs.fat 4.1 (2017-01-24)
mkfs.vfat: unable to open /dev/nvme0n1p1: No such file or directory
Target install-efi failed

A couple lines later I see:

[10.265401]  nvme0n1: p1 p2 p3

Then looking at the device itself after booting from a USB stick:

root@intel-corei7-64: ~# ls /dev/nvme0n1*
/dev/nvme0n1 /dev/nvme0n1p1 /dev/nvme0n1p2 /dev/nvme0n1p3

So it looks like the parted commands return before the device node is
actually created.

Work around this issue by adding a short sleep before doing the mkfs
commands.

Signed-off-by: California Sullivan 
---
 meta/recipes-core/initrdscripts/files/init-install-efi.sh | 2 ++
 meta/recipes-core/initrdscripts/files/init-install.sh | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/meta/recipes-core/initrdscripts/files/init-install-efi.sh 
b/meta/recipes-core/initrdscripts/files/init-install-efi.sh
index 5ad3a60..118bf08 100644
--- a/meta/recipes-core/initrdscripts/files/init-install-efi.sh
+++ b/meta/recipes-core/initrdscripts/files/init-install-efi.sh
@@ -186,6 +186,8 @@ parted ${device} mkpart swap linux-swap $swap_start 100%
 
 parted ${device} print
 
+sleep 1
+
 echo "Formatting $bootfs to vfat..."
 mkfs.vfat $bootfs
 
diff --git a/meta/recipes-core/initrdscripts/files/init-install.sh 
b/meta/recipes-core/initrdscripts/files/init-install.sh
index 1cac806..606317d 100644
--- a/meta/recipes-core/initrdscripts/files/init-install.sh
+++ b/meta/recipes-core/initrdscripts/files/init-install.sh
@@ -211,6 +211,8 @@ parted ${device} mkpart $pname linux-swap $swap_start 100%
 
 parted ${device} print
 
+sleep 1
+
 echo "Formatting $bootfs to ext3..."
 mkfs.ext3 $bootfs
 
-- 
2.9.5

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

Re: [OE-core] [PATCH] toolchain-scripts: Add PYTHONHOME in sdk env script

[Burton, Ross]

This fails all over the autobuilders:

==
ERROR: test_python_stdout (python.PythonTest)
--
Traceback (most recent call last):
  File
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-arm/build/meta/lib/oeqa/sdk/cases/python.py",
line 23, in test_python_stdout
output = self._run('python %s/test.py' % self.tc.sdk_dir)
  File
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-arm/build/meta/lib/oeqa/sdk/case.py",
line 12, in _run
stderr=subprocess.STDOUT, universal_newlines=True)
  File "/usr/lib64/python3.6/subprocess.py", line 336, in check_output
**kwargs).stdout
  File "/usr/lib64/python3.6/subprocess.py", line 418, in run
output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '.
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-arm/build/build/tmp/work/qemuarm-poky-linux-gnueabi/core-image-sato/1.0-r0/testimage-sdk/environment-setup-armv5e-poky-linux-gnueabi
> /dev/null; python
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-arm/build/build/tmp/work/qemuarm-poky-linux-gnueabi/core-image-sato/1.0-r0/testimage-sdk//test.py;'
returned non-zero exit status 1.

My guess is that its running host Python with PYTHONHOME set to the SDK,
which then fails massively as the binary parts won't be compatible.

Ross


On 13 November 2017 at 19:11, Thomas Perrot  wrote:
>
> Otherwise, the host Python environment is used instead of Python
environment
> provided by the SDK.
>
> Signed-off-by: Thomas Perrot 
> ---
>  meta/classes/toolchain-scripts.bbclass | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/meta/classes/toolchain-scripts.bbclass
b/meta/classes/toolchain-scripts.bbclass
> index 9bcfe708c7..03bc652cd7 100644
> --- a/meta/classes/toolchain-scripts.bbclass
> +++ b/meta/classes/toolchain-scripts.bbclass
> @@ -51,6 +51,7 @@ toolchain_create_sdk_env_script () {
> echo "export OECORE_NATIVE_SYSROOT=\"$sdkpathnative\"" >> $script
> echo 'export OECORE_TARGET_SYSROOT="$SDKTARGETSYSROOT"' >> $script
> echo "export OECORE_ACLOCAL_OPTS=\"-I
$sdkpathnative/usr/share/aclocal\"" >> $script
> +   echo "export PYTHONHOME=\"$sdkpathnative$libdir\"" >> $script
> echo 'unset command_not_found_handle' >> $script
>
> toolchain_shared_env_script
> --
> 2.13.6
>
> --
> ___
> 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] ✗ patchtest: failure for Master package updates (rev2)

[Patchwork]

== Series Details ==

Series: Master package updates (rev2)
Revision: 2
URL   : https://patchwork.openembedded.org/series/9884/
State : failure

== Summary ==


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



* Patch[5/5] curl: update to 7.56.1
 Issue Missing or incorrectly formatted CVE tag in included patch 
file [test_cve_tag_format] 
  Suggested fixCorrect or include the CVE tag on cve patch with format: 
"CVE: CVE--"



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

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

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

[OE-core] ✗ patchtest: failure for glibc: Fix CVE-2017-1000366

[Patchwork]

== Series Details ==

Series: glibc: Fix CVE-2017-1000366
Revision: 1
URL   : https://patchwork.openembedded.org/series/9907/
State : failure

== Summary ==


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



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



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

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

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

[OE-core] ✗ patchtest: failure for "[morty,v3] glibc: Fix CVE-2015..." and 1 more

[Patchwork]

== Series Details ==

Series: "[morty,v3] glibc: Fix CVE-2015..." and 1 more
Revision: 1
URL   : https://patchwork.openembedded.org/series/9906/
State : failure

== Summary ==


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



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



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

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

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

Re: [OE-core] [yocto] Contribute meta-installer to yocto

[akuster808]

Hello,



On 11/21/2017 12:55 AM, Hongxu Jia wrote:
> Hi all,
>
> Wind River has maintained meta-installer for several years,
> and now we want to contribute it to yocto community.
>
> This layer provides an installation program based on
> OE platform. The installation program is anaconda from
> fedora, which is the installer of distribution Fedora,
> RedHat and Centos.
>
> The version of anaconda in meta-installer is 26.21.11
> which is based on Fedora 26.
>
> The meta-insatller requires:
> - systemd as init manager
> - python3
> - dnf2/rpm4
> - gobject-introspection which requires qemu-usermode
>   in MACHINE_FEATURES
>
> The meta-installer provides:
> - graphic install and text install.
>
> - package based (dnf/rpm) install and image (copy)
>   based install.
>
> - package based (dnf/rpm) install from local and
>   remote rpm sources such as CDs and DVDs, images
>   stored on a hard drive, NFS, HTTP, and FTP.
>
> - kickstart install which provides a fully unattended
>   installation that can be duplicated on scores of machines.
>
> - install over VNC on headless machines.
>
> - timezone setting.
>
> - root password setting.
>
> - user account creation.
>
> - a variety of advanced storage devices including
>   LVM, Btrfs, Ext4, and filesystem encryption.
>
> The repository of meta-installer is temporary on the github
> for review:
> https://github.com/jiahongxujia/meta-installer
>
> In above github, the logo picture is undefined, if yocto
> could accept this layer, I will update the picture with
> "Yocto project Compatible".
>
> The attachments are the snapshots of a package based
> installation.
>
> Hopefully it is helpful for yocto, and any feedback is
> appreciated.

I believe it can go beyond helping Yocto and help the overall OE community.

CC'ing oe mailings lists

>
> If yocto is interested in this layer and will accept it,
> I could send pull request or some one directly fetch
> from above github master branch.
If Yocto isn't I am sure OE will be.

Thank you Wind River for contributing your hard work for the greater
good of the community.

kind regards,
Armin
>
> //Hongxu
>
>

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

[OE-core] [pyro][PATCH] glibc: Fix CVE-2017-1000366

[George McCollister]

Add backported patches from the upstream release/2.25/master branch to
fix CVE-2017-1000366. Also add a backported patch that resolves SSE
related build problems introduced by these patches.

Signed-off-by: George McCollister 
---
 ...00366-Ignore-LD_LIBRARY_PATH-for-AT_SECUR.patch |  70 +++
 ...ject-overly-long-LD_PRELOAD-path-elements.patch | 144 +
 ...Reject-overly-long-LD_AUDIT-path-elements.patch | 230 +
 ...ssing-IS_IN-libc-guards-to-vectorized-str.patch |  62 ++
 meta/recipes-core/glibc/glibc_2.25.bb  |   4 +
 5 files changed, 510 insertions(+)
 create mode 100644 
meta/recipes-core/glibc/glibc/0028-CVE-2017-1000366-Ignore-LD_LIBRARY_PATH-for-AT_SECUR.patch
 create mode 100644 
meta/recipes-core/glibc/glibc/0029-ld.so-Reject-overly-long-LD_PRELOAD-path-elements.patch
 create mode 100644 
meta/recipes-core/glibc/glibc/0030-ld.so-Reject-overly-long-LD_AUDIT-path-elements.patch
 create mode 100644 
meta/recipes-core/glibc/glibc/0031-i686-Add-missing-IS_IN-libc-guards-to-vectorized-str.patch

diff --git 
a/meta/recipes-core/glibc/glibc/0028-CVE-2017-1000366-Ignore-LD_LIBRARY_PATH-for-AT_SECUR.patch
 
b/meta/recipes-core/glibc/glibc/0028-CVE-2017-1000366-Ignore-LD_LIBRARY_PATH-for-AT_SECUR.patch
new file mode 100644
index 00..0178d50ff0
--- /dev/null
+++ 
b/meta/recipes-core/glibc/glibc/0028-CVE-2017-1000366-Ignore-LD_LIBRARY_PATH-for-AT_SECUR.patch
@@ -0,0 +1,70 @@
+From 4002021818bc31aec9b353c6e13ce9f82e84cd38 Mon Sep 17 00:00:00 2001
+From: Florian Weimer 
+Date: Mon, 19 Jun 2017 18:31:27 +0200
+Subject: [PATCH] CVE-2017-1000366: Ignore LD_LIBRARY_PATH for AT_SECURE=1
+ programs [BZ #21624]
+
+LD_LIBRARY_PATH can only be used to reorder system search paths, which
+is not useful functionality.
+
+This makes an exploitable unbounded alloca in _dl_init_paths unreachable
+for AT_SECURE=1 programs.
+
+(cherry picked from commit f6110a8fee2ca36f8e2d2abecf3cba9fa7b8ea7d)
+
+Upstream-Status: Backport
+https://sourceware.org/git/?p=glibc.git;a=commit;h=3c7cd21290cabdadd72984fb69bc51e64ff1002d
+
+CVE: CVE-2017-1000366
+
+Signed-off-by: George McCollister 
+---
+ ChangeLog  | 7 +++
+ NEWS   | 1 +
+ elf/rtld.c | 3 ++-
+ 3 files changed, 10 insertions(+), 1 deletion(-)
+
+diff --git a/ChangeLog b/ChangeLog
+index f140ee67de..7bfdf45bb5 100644
+--- a/ChangeLog
 b/ChangeLog
+@@ -1,3 +1,10 @@
++2017-06-19  Florian Weimer  
++
++  [BZ #21624]
++  CVE-2017-1000366
++  * elf/rtld.c (process_envvars): Ignore LD_LIBRARY_PATH for
++  __libc_enable_secure.
++
+ 2017-02-05  Siddhesh Poyarekar  
+ 
+   * version.h (RELEASE): Set to "stable"
+diff --git a/NEWS b/NEWS
+index ec15dde761..f7d38536d6 100644
+--- a/NEWS
 b/NEWS
+@@ -5,6 +5,7 @@ See the end for copying conditions.
+ Please send GNU C library bug reports via 
+ using `glibc' in the "product" field.
+ 
++  [21624] Unsafe alloca allows local attackers to alias stack and heap 
(CVE-2017-1000366)
+ Version 2.25
+ 
+ * The feature test macro __STDC_WANT_LIB_EXT2__, from ISO/IEC TR
+diff --git a/elf/rtld.c b/elf/rtld.c
+index a036ece956..2fc33a6178 100644
+--- a/elf/rtld.c
 b/elf/rtld.c
+@@ -2418,7 +2418,8 @@ process_envvars (enum mode *modep)
+ 
+   case 12:
+ /* The library search path.  */
+-if (memcmp (envline, "LIBRARY_PATH", 12) == 0)
++if (!__libc_enable_secure
++&& memcmp (envline, "LIBRARY_PATH", 12) == 0)
+   {
+ library_path = [13];
+ break;
+-- 
+2.15.0
+
diff --git 
a/meta/recipes-core/glibc/glibc/0029-ld.so-Reject-overly-long-LD_PRELOAD-path-elements.patch
 
b/meta/recipes-core/glibc/glibc/0029-ld.so-Reject-overly-long-LD_PRELOAD-path-elements.patch
new file mode 100644
index 00..142bd86d2f
--- /dev/null
+++ 
b/meta/recipes-core/glibc/glibc/0029-ld.so-Reject-overly-long-LD_PRELOAD-path-elements.patch
@@ -0,0 +1,144 @@
+From d4fe2023bb908b85d577ac3843acd44bada330ce Mon Sep 17 00:00:00 2001
+From: Florian Weimer 
+Date: Mon, 19 Jun 2017 22:31:04 +0200
+Subject: [PATCH] ld.so: Reject overly long LD_PRELOAD path elements
+
+(cherry picked from commit 6d0ba622891bed9d8394eef1935add53003b12e8)
+
+Upstream-Status: Backport
+https://sourceware.org/git/?p=glibc.git;a=commit;h=46703a3995aa3ca2b816814aa4ad05ed524194dd
+
+CVE: CVE-2017-1000366
+
+Signed-off-by: George McCollister 
+---
+ ChangeLog  |  7 ++
+ elf/rtld.c | 82 ++
+ 2 files changed, 73 insertions(+), 16 deletions(-)
+
+diff --git a/ChangeLog b/ChangeLog
+index 7bfdf45bb5..0aff2bd347 100644
+--- a/ChangeLog
 b/ChangeLog
+@@ -1,3 +1,10 @@
++2017-06-19  Florian Weimer  
++
++  * elf/rtld.c (SECURE_NAME_LIMIT, SECURE_PATH_LIMIT): Define.

[OE-core] [morty][PATCH v3 1/2] glibc: Fix CVE-2015-5180

[George McCollister]

Add backported patch to fix CVE-2015-5180 from the upstream
release/2.24/master branch.

Signed-off-by: George McCollister 
---

Changes in v2:
 - Fix commit message

Changes in v3:
 - None. Resending with other patch in the series.

 ...80-resolv-Fix-crash-with-internal-QTYPE-B.patch | 357 +
 meta/recipes-core/glibc/glibc_2.24.bb  |   1 +
 2 files changed, 358 insertions(+)
 create mode 100644 
meta/recipes-core/glibc/glibc/0001-CVE-2015-5180-resolv-Fix-crash-with-internal-QTYPE-B.patch

diff --git 
a/meta/recipes-core/glibc/glibc/0001-CVE-2015-5180-resolv-Fix-crash-with-internal-QTYPE-B.patch
 
b/meta/recipes-core/glibc/glibc/0001-CVE-2015-5180-resolv-Fix-crash-with-internal-QTYPE-B.patch
new file mode 100644
index 00..ba0bebe488
--- /dev/null
+++ 
b/meta/recipes-core/glibc/glibc/0001-CVE-2015-5180-resolv-Fix-crash-with-internal-QTYPE-B.patch
@@ -0,0 +1,357 @@
+From ff9b7c4fb73295cd2de2d2ccfbbf4f6d50883d47 Mon Sep 17 00:00:00 2001
+From: Florian Weimer 
+Date: Sat, 31 Dec 2016 20:22:09 +0100
+Subject: [PATCH] CVE-2015-5180: resolv: Fix crash with internal QTYPE [BZ
+ #18784]
+
+Also rename T_UNSPEC because an upcoming public header file
+update will use that name.
+
+(cherry picked from commit fc82b0a2dfe7dbd35671c10510a8da1043d746a5)
+
+Upstream-Status: Backport
+https://sourceware.org/git/?p=glibc.git;a=patch;h=b3b37f1a5559a7620e31c8053ed1b44f798f2b6d
+
+CVE: CVE-2015-5180
+
+Signed-off-by: George McCollister 
+---
+ ChangeLog |  14 
+ NEWS  |   6 ++
+ include/arpa/nameser_compat.h |   6 +-
+ resolv/Makefile   |   5 ++
+ resolv/nss_dns/dns-host.c |   2 +-
+ resolv/res_mkquery.c  |   4 +
+ resolv/res_query.c|   6 +-
+ resolv/tst-resolv-qtypes.c| 185 ++
+ 8 files changed, 221 insertions(+), 7 deletions(-)
+ create mode 100644 resolv/tst-resolv-qtypes.c
+
+diff --git a/ChangeLog b/ChangeLog
+index 893262de11..2bdaf69e43 100644
+--- a/ChangeLog
 b/ChangeLog
+@@ -1,3 +1,17 @@
++2016-12-31  Florian Weimer  
++
++  [BZ #18784]
++  CVE-2015-5180
++  * include/arpa/nameser_compat.h (T_QUERY_A_AND_): Rename from
++  T_UNSPEC.  Adjust value.
++  * resolv/nss_dns/dns-host.c (_nss_dns_gethostbyname4_r): Use it.
++  * resolv/res_query.c (__libc_res_nquery): Likewise.
++  * resolv/res_mkquery.c (res_nmkquery): Check for out-of-range
++  QTYPEs.
++  * resolv/tst-resolv-qtypes.c: New file.
++  * resolv/Makefile (xtests): Add tst-resolv-qtypes.
++  (tst-resolv-qtypes): Link against libresolv and libpthread.
++
+ 2016-10-26  Carlos O'Donell  
+ 
+   * include/atomic.h
+diff --git a/NEWS b/NEWS
+index 3002773c16..4b1ca3cb65 100644
+--- a/NEWS
 b/NEWS
+@@ -11,6 +11,12 @@ using `glibc' in the "product" field.
+   printers show various pthread variables in human-readable form when read
+   using the 'print' or 'display' commands in gdb.
+ 
++* The DNS stub resolver functions would crash due to a NULL pointer
++  dereference when processing a query with a valid DNS question type which
++  was used internally in the implementation.  The stub resolver now uses a
++  question type which is outside the range of valid question type values.
++  (CVE-2015-5180)
++
+ Version 2.24
+ 
+ * The minimum Linux kernel version that this version of the GNU C Library
+diff --git a/include/arpa/nameser_compat.h b/include/arpa/nameser_compat.h
+index 2e735ede4c..7c0deed9ae 100644
+--- a/include/arpa/nameser_compat.h
 b/include/arpa/nameser_compat.h
+@@ -1,8 +1,8 @@
+ #ifndef _ARPA_NAMESER_COMPAT_
+ #include 
+ 
+-/* Picksome unused number to represent lookups of IPv4 and IPv6 (i.e.,
+-   T_A and T_).  */
+-#define T_UNSPEC 62321
++/* The number is outside the 16-bit RR type range and is used
++   internally by the implementation.  */
++#define T_QUERY_A_AND_ 439963904
+ 
+ #endif
+diff --git a/resolv/Makefile b/resolv/Makefile
+index 8be41d3ae1..a4c86b9762 100644
+--- a/resolv/Makefile
 b/resolv/Makefile
+@@ -40,6 +40,9 @@ ifeq ($(have-thread-library),yes)
+ extra-libs += libanl
+ routines += gai_sigqueue
+ tests += tst-res_hconf_reorder
++
++# This test sends millions of packets and is rather slow.
++xtests += tst-resolv-qtypes
+ endif
+ extra-libs-others = $(extra-libs)
+ libresolv-routines := gethnamaddr res_comp res_debug  \
+@@ -117,3 +120,5 @@ tst-leaks2-ENV = MALLOC_TRACE=$(objpfx)tst-leaks2.mtrace
+ $(objpfx)mtrace-tst-leaks2.out: $(objpfx)tst-leaks2.out
+   $(common-objpfx)malloc/mtrace $(objpfx)tst-leaks2.mtrace > $@; \
+   $(evaluate-test)
++
++$(objpfx)tst-resolv-qtypes: $(objpfx)libresolv.so $(shared-thread-library)
+diff --git a/resolv/nss_dns/dns-host.c b/resolv/nss_dns/dns-host.c
+index 5f9e35701b..d16fa4b8ed 100644
+--- a/resolv/nss_dns/dns-host.c
 

[OE-core] [PATCH 4/5] libassuan: update to 2.4.4

[Armin Kuster]

From: Armin Kuster 

forward ported patch

assuan-def.h checksum changed do to "SPDX formating"
assuan.c checksum changes do to "SPDX formating"

Signed-off-by: Armin Kuster 
---
 .../libassuan-add-pkgconfig-support.patch  | 77 +++---
 .../{libassuan_2.4.3.bb => libassuan_2.4.4.bb} | 11 ++--
 2 files changed, 45 insertions(+), 43 deletions(-)
 rename meta/recipes-support/libassuan/{libassuan_2.4.3.bb => 
libassuan_2.4.4.bb} (67%)

diff --git 
a/meta/recipes-support/libassuan/libassuan/libassuan-add-pkgconfig-support.patch
 
b/meta/recipes-support/libassuan/libassuan/libassuan-add-pkgconfig-support.patch
index b6ccdda..525b076 100644
--- 
a/meta/recipes-support/libassuan/libassuan/libassuan-add-pkgconfig-support.patch
+++ 
b/meta/recipes-support/libassuan/libassuan/libassuan-add-pkgconfig-support.patch
@@ -6,32 +6,15 @@ Upstream-Status: Denied
 Signed-off-by: Chen Qi 
 Signed-off-by: Constantin Musca 
 
-Index: libassuan-2.1.2/Makefile.am
-===
 libassuan-2.1.2.orig/Makefile.am
-+++ libassuan-2.1.2/Makefile.am
-@@ -24,10 +24,13 @@ AUTOMAKE_OPTIONS = dist-bzip2 no-dist-gz
- # (A suitable gitlog-to-changelog script can be found in GnuPG master.)
- GITLOG_TO_CHANGELOG=gitlog-to-changelog
- 
-+pkgconfigdir = $(libdir)/pkgconfig
-+pkgconfig_DATA = libassuan.pc
-+
- EXTRA_DIST = autogen.sh autogen.rc README.GIT 
\
-  ChangeLog-2011 doc/ChangeLog-2011 src/ChangeLog-2011 \
-  tests/ChangeLog-2011 contrib/ChangeLog-2011  \
-- build-aux/git-log-footer build-aux/git-log-fix
-+ build-aux/git-log-footer build-aux/git-log-fix libassuan.pc.in
- 
- SUBDIRS = m4 src doc tests
- 
-Index: libassuan-2.1.2/libassuan.pc.in
+forward ported to 2.4.4
+Signed-off-by: Armin Kuster 
+
+Index: libassuan-2.4.4/libassuan.pc.in
 ===
 --- /dev/null
-+++ libassuan-2.1.2/libassuan.pc.in
-@@ -0,0 +1,14 @@
-+prefix=@prefix@
-+exec_prefix=@exec_prefix@
 libassuan-2.4.4/libassuan.pc.in
+@@ -0,0 +1,13 @@
++prefix=@exec_prefix@
 +libdir=@libdir@
 +includedir=@includedir@
 +api_version=@LIBASSUAN_CONFIG_API_VERSION@
@@ -44,24 +27,42 @@ Index: libassuan-2.1.2/libassuan.pc.in
 +Libs: -L${libdir} -lassuan
 +Libs.private: -lgpg-error
 +Cflags: -I${includedir}
-Index: libassuan-2.1.2/configure.ac
+Index: libassuan-2.4.4/Makefile.am
 ===
 libassuan-2.1.2.orig/configure.ac
-+++ libassuan-2.1.2/configure.ac
-@@ -439,7 +439,7 @@ AC_CONFIG_FILES([doc/Makefile])
+--- a/Makefile.am
 b/Makefile.am
+@@ -25,10 +25,13 @@ DISTCHECK_CONFIGURE_FLAGS = --enable-doc
+ # (A suitable gitlog-to-changelog script can be found in GnuPG master.)
+ GITLOG_TO_CHANGELOG=gitlog-to-changelog
+ 
++pkgconfigdir = $(libdir)/pkgconfig
++pkgconfig_DATA = libassuan.pc
++
+ EXTRA_DIST = autogen.sh autogen.rc README.GIT VERSION   \
+  ChangeLog-2011 doc/ChangeLog-2011 src/ChangeLog-2011 \
+  tests/ChangeLog-2011 contrib/ChangeLog-2011  \
+- build-aux/git-log-footer build-aux/git-log-fix
++ build-aux/git-log-footer build-aux/git-log-fix libassuan.pc.in
+ 
+ if BUILD_DOC
+ doc = doc
+Index: 2.4.4-r0/libassuan-2.4.4/configure.ac
+===
+--- a/configure.ac
 b/configure.ac
+@@ -485,6 +485,7 @@ AC_CONFIG_FILES([doc/Makefile])
  AC_CONFIG_FILES([tests/Makefile])
  AC_CONFIG_FILES([src/libassuan-config], [chmod +x src/libassuan-config])
  AC_CONFIG_FILES([src/versioninfo.rc])
--
 +AC_CONFIG_FILES([libassuan.pc])
+ 
  AC_OUTPUT
  
- echo "
-Index: libassuan-2.1.2/src/libassuan.m4
+Index: libassuan-2.4.4/src/libassuan.m4
 ===
 libassuan-2.1.2.orig/src/libassuan.m4
-+++ libassuan-2.1.2/src/libassuan.m4
-@@ -15,18 +15,6 @@ dnl Returns ok set to yes or no.
+--- a/src/libassuan.m4
 b/src/libassuan.m4
+@@ -16,18 +16,6 @@ dnl Returns ok set to yes or no.
  dnl
  AC_DEFUN([_AM_PATH_LIBASSUAN_COMMON],
  [ AC_REQUIRE([AC_CANONICAL_HOST])
@@ -80,7 +81,7 @@ Index: libassuan-2.1.2/src/libassuan.m4
  
tmp=ifelse([$1], ,1:0.9.2,$1)
if echo "$tmp" | grep ':' >/dev/null 2>/dev/null ; then
-@@ -37,51 +25,12 @@ AC_DEFUN([_AM_PATH_LIBASSUAN_COMMON],
+@@ -38,51 +26,12 @@ AC_DEFUN([_AM_PATH_LIBASSUAN_COMMON],
  min_libassuan_version="$tmp"
fi
  
@@ -105,7 +106,7 @@ Index: libassuan-2.1.2/src/libassuan.m4
 -
 -if test "$major" -gt "$req_major"; then
 -ok=yes
--else 
+-else
 -if test "$major" -eq "$req_major"; then
 -if test "$minor" -gt "$req_minor"; then
 -   ok=yes
@@ -134,7 +135,7 @@ Index: 

[OE-core] [PATCH 5/5] curl: update to 7.56.1

[Armin Kuster]

From: Armin Kuster 

v2] - remove inherit

curlbuild.h removed from sources

includes:
CVE-2017-1000257

removed patches for the following cve fixs:
CVE-2017-1000254
CVE-2017-1000101
CVE-2017-1000100
CVE-2017-199

Signed-off-by: Armin Kuster 
---
 .../curl/{curl_7.54.1.bb => curl_7.56.1.bb}| 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)
 rename meta/recipes-support/curl/{curl_7.54.1.bb => curl_7.56.1.bb} (87%)

diff --git a/meta/recipes-support/curl/curl_7.54.1.bb 
b/meta/recipes-support/curl/curl_7.56.1.bb
similarity index 87%
rename from meta/recipes-support/curl/curl_7.54.1.bb
rename to meta/recipes-support/curl/curl_7.56.1.bb
index 58f0531..830f350 100644
--- a/meta/recipes-support/curl/curl_7.54.1.bb
+++ b/meta/recipes-support/curl/curl_7.56.1.bb
@@ -7,10 +7,6 @@ LIC_FILES_CHKSUM = 
"file://COPYING;beginline=8;md5=3a34942f4ae3fbf1a303160714e66
 
 SRC_URI = "http://curl.haxx.se/download/curl-${PV}.tar.bz2 \
file://0001-replace-krb5-config-with-pkg-config.patch \
-   file://CVE-2017-199.patch \
-   file://CVE-2017-1000100.patch \
-   file://CVE-2017-1000101.patch \
-   file://CVE-2017-1000254.patch \
 "
 
 SRC_URI_append_class-target = " \
@@ -22,11 +18,11 @@ SRC_URI_append_class-target = " \
 #
 SRC_URI += " file://configure_ac.patch"
 
-SRC_URI[md5sum] = "6b6eb722f512e7a24855ff084f54fe55"
-SRC_URI[sha256sum] = 
"fdfc4df2d001ee0c44ec071186e770046249263c491fcae48df0e1a3ca8f25a0"
+SRC_URI[md5sum] = "428de25834ef8c04076906d6d5c0498e"
+SRC_URI[sha256sum] = 
"2594670367875e7d87b0f129b5e4690150780884d90244ba0fe3e74a778b5f90"
 
 CVE_PRODUCT = "libcurl"
-inherit autotools pkgconfig binconfig multilib_header
+inherit autotools pkgconfig binconfig
 
 PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'ipv6', d)} gnutls 
proxy threaded-resolver zlib"
 PACKAGECONFIG_class-native = "ipv6 proxy ssl threaded-resolver zlib"
@@ -64,10 +60,6 @@ EXTRA_OECONF = " \
 --without-libpsl \
 "
 
-do_install_append() {
-   oe_multilib_header curl/curlbuild.h
-}
-
 do_install_append_class-target() {
# cleanup buildpaths from curl-config
sed -i \
-- 
2.7.4

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

[OE-core] [morty][PATCH v3 2/2] glibc: Fix CVE-2017-1000366

[George McCollister]

Add backported patches from the upstream release/2.24/master branch to
fix CVE-2017-1000366. Also add a backported patch that resolves SSE
related build problems introduced by these patches.

Signed-off-by: George McCollister 
---

Changes in v2:
 - Fix commit message

Changes in v3:
 - Added upstream patch to fix SSE issue introduced by this patch
   series.

 ...00366-Ignore-LD_LIBRARY_PATH-for-AT_SECUR.patch |  71 +++
 ...ject-overly-long-LD_PRELOAD-path-elements.patch | 145 +
 ...Reject-overly-long-LD_AUDIT-path-elements.patch | 231 +
 ...ssing-IS_IN-libc-guards-to-vectorized-str.patch |  62 ++
 meta/recipes-core/glibc/glibc_2.24.bb  |   4 +
 5 files changed, 513 insertions(+)
 create mode 100644 
meta/recipes-core/glibc/glibc/0001-CVE-2017-1000366-Ignore-LD_LIBRARY_PATH-for-AT_SECUR.patch
 create mode 100644 
meta/recipes-core/glibc/glibc/0002-ld.so-Reject-overly-long-LD_PRELOAD-path-elements.patch
 create mode 100644 
meta/recipes-core/glibc/glibc/0003-ld.so-Reject-overly-long-LD_AUDIT-path-elements.patch
 create mode 100644 
meta/recipes-core/glibc/glibc/0004-i686-Add-missing-IS_IN-libc-guards-to-vectorized-str.patch

diff --git 
a/meta/recipes-core/glibc/glibc/0001-CVE-2017-1000366-Ignore-LD_LIBRARY_PATH-for-AT_SECUR.patch
 
b/meta/recipes-core/glibc/glibc/0001-CVE-2017-1000366-Ignore-LD_LIBRARY_PATH-for-AT_SECUR.patch
new file mode 100644
index 00..78e9ea9e65
--- /dev/null
+++ 
b/meta/recipes-core/glibc/glibc/0001-CVE-2017-1000366-Ignore-LD_LIBRARY_PATH-for-AT_SECUR.patch
@@ -0,0 +1,71 @@
+From 400f170750a4b2c94a2670ca44de166cc5dd6e3b Mon Sep 17 00:00:00 2001
+From: Florian Weimer 
+Date: Mon, 19 Jun 2017 18:33:26 +0200
+Subject: [PATCH] CVE-2017-1000366: Ignore LD_LIBRARY_PATH for AT_SECURE=1
+ programs [BZ #21624]
+
+LD_LIBRARY_PATH can only be used to reorder system search paths, which
+is not useful functionality.
+
+This makes an exploitable unbounded alloca in _dl_init_paths unreachable
+for AT_SECURE=1 programs.
+
+(cherry picked from commit f6110a8fee2ca36f8e2d2abecf3cba9fa7b8ea7d)
+
+Upstream-Status: Backport
+https://sourceware.org/git/?p=glibc.git;a=commit;h=87bd4186da10371f46e2f1a7bf7c0a45bb04f1ac
+https://anonscm.debian.org/cgit/pkg-glibc/glibc.git/commit/?h=stretch=2755c57269f24e9d59c22c49788f92515346c1bb
+
+CVE: CVE-2017-1000366
+
+Signed-off-by: George McCollister 
+---
+ ChangeLog  | 7 +++
+ NEWS   | 1 +
+ elf/rtld.c | 3 ++-
+ 3 files changed, 10 insertions(+), 1 deletion(-)
+
+diff --git a/ChangeLog b/ChangeLog
+index 2bdaf69e43..7a999802dd 100644
+--- a/ChangeLog
 b/ChangeLog
+@@ -1,3 +1,10 @@
++2017-06-19  Florian Weimer  
++
++  [BZ #21624]
++  CVE-2017-1000366
++  * elf/rtld.c (process_envvars): Ignore LD_LIBRARY_PATH for
++  __libc_enable_secure.
++
+ 2016-12-31  Florian Weimer  
+ 
+   [BZ #18784]
+diff --git a/NEWS b/NEWS
+index 4b1ca3cb65..66b49dbbc0 100644
+--- a/NEWS
 b/NEWS
+@@ -17,6 +17,7 @@ using `glibc' in the "product" field.
+   question type which is outside the range of valid question type values.
+   (CVE-2015-5180)
+ 
++  [21624] Unsafe alloca allows local attackers to alias stack and heap 
(CVE-2017-1000366)
+ Version 2.24
+ 
+ * The minimum Linux kernel version that this version of the GNU C Library
+diff --git a/elf/rtld.c b/elf/rtld.c
+index 647661ca45..215a9aec8f 100644
+--- a/elf/rtld.c
 b/elf/rtld.c
+@@ -2437,7 +2437,8 @@ process_envvars (enum mode *modep)
+ 
+   case 12:
+ /* The library search path.  */
+-if (memcmp (envline, "LIBRARY_PATH", 12) == 0)
++if (!__libc_enable_secure
++&& memcmp (envline, "LIBRARY_PATH", 12) == 0)
+   {
+ library_path = [13];
+ break;
+-- 
+2.15.0
+
diff --git 
a/meta/recipes-core/glibc/glibc/0002-ld.so-Reject-overly-long-LD_PRELOAD-path-elements.patch
 
b/meta/recipes-core/glibc/glibc/0002-ld.so-Reject-overly-long-LD_PRELOAD-path-elements.patch
new file mode 100644
index 00..7f81ed1566
--- /dev/null
+++ 
b/meta/recipes-core/glibc/glibc/0002-ld.so-Reject-overly-long-LD_PRELOAD-path-elements.patch
@@ -0,0 +1,145 @@
+From 6d49272e6d6741496e3456f2cc22ebc2b9f7f989 Mon Sep 17 00:00:00 2001
+From: Florian Weimer 
+Date: Mon, 19 Jun 2017 22:31:04 +0200
+Subject: [PATCH] ld.so: Reject overly long LD_PRELOAD path elements
+
+(cherry picked from commit 6d0ba622891bed9d8394eef1935add53003b12e8)
+
+Upstream-Status: Backport
+https://sourceware.org/git/?p=glibc.git;a=commit;h=aab04ca5d359150e17631e6a9b44b65e93bdc467
+https://anonscm.debian.org/cgit/pkg-glibc/glibc.git/commit/?h=stretch=2755c57269f24e9d59c22c49788f92515346c1bb
+
+CVE: CVE-2017-1000366
+
+Signed-off-by: George McCollister 
+---
+ ChangeLog  |  7 ++
+ elf/rtld.c | 82 

[OE-core] [PATCH 3/5] nss: update to 3.34

[Armin Kuster]

From: Armin Kuster 

for more info see:
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.34_release_notes

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

diff --git a/meta/recipes-support/nss/nss_3.33.bb 
b/meta/recipes-support/nss/nss_3.34.bb
similarity index 98%
rename from meta/recipes-support/nss/nss_3.33.bb
rename to meta/recipes-support/nss/nss_3.34.bb
index e3d4f96..f1fbbb0 100644
--- a/meta/recipes-support/nss/nss_3.33.bb
+++ b/meta/recipes-support/nss/nss_3.34.bb
@@ -28,8 +28,8 @@ SRC_URI = 
"http://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/${VERSIO
file://Fix-compilation-for-X32.patch \
"
 
-SRC_URI[md5sum] = "43663c850e2b2ed48ecb8910b055f5a9"
-SRC_URI[sha256sum] = 
"98f0dabd36408e83dd3a11727336cc3cdfee4cbdd9aede2b2831eb2389c284e4"
+SRC_URI[md5sum] = "1e30b8e5b13b5b08bbc489c265948d82"
+SRC_URI[sha256sum] = 
"0d45954181373023c7cfc33e77c8c636d394ec7e55b93e059149ed7888652af5"
 
 UPSTREAM_CHECK_URI = 
"https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_Releases;
 UPSTREAM_CHECK_REGEX = "NSS_(?P.+)_release_notes"
-- 
2.7.4

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

[OE-core] [PATCH 0/5][V2] Master package updates

[Armin Kuster]

I suspect curl may have conflicts if the changes in mut are applied.

The gnutls changes built with meta-oe world. boot tested on a few arm machines.

v2:
remove dangling patch
removed inherit
added checksum changes

The following changes since commit 33418ed064fe9cff5b4803f09135a81d9170c189:

  runqemu: Also specialcase resolution of '.' to the file's location 
(2017-11-21 17:58:36 +)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib akuster/master-updates
  http://cgit.openembedded.org//log/?h=akuster/master-updates

Armin Kuster (5):
  gnutls: update to 3.6.1
  nettle: update to 3.4 and cleanup
  nss: update to 3.34
  libassuan: update to 2.4.4
  curl: update to 7.56.1

 .../curl/{curl_7.54.1.bb => curl_7.56.1.bb}| 14 +---
 meta/recipes-support/gnutls/gnutls.inc |  3 +-
 .../gnutls/use-pkg-config-to-locate-zlib.patch | 75 -
 .../gnutls/{gnutls_3.5.16.bb => gnutls_3.6.1.bb}   |  5 +-
 .../libassuan-add-pkgconfig-support.patch  | 77 +++---
 .../{libassuan_2.4.3.bb => libassuan_2.4.4.bb} | 11 ++--
 ...d-target-to-only-build-tests-not-run-them.patch | 46 -
 ...d-target-to-only-build-tests-not-run-them.patch | 38 +++
 ...k-header-files-of-openssl-only-if-enable_.patch | 26 
 .../{nettle-3.3 => nettle-3.4}/dlopen-test.patch   |  0
 .../nettle/{files => nettle-3.4}/run-ptest |  0
 meta/recipes-support/nettle/nettle_3.3.bb  | 19 --
 .../nettle/{nettle.inc => nettle_3.4.bb}   | 14 
 .../nss/{nss_3.33.bb => nss_3.34.bb}   |  4 +-
 14 files changed, 117 insertions(+), 215 deletions(-)
 rename meta/recipes-support/curl/{curl_7.54.1.bb => curl_7.56.1.bb} (87%)
 delete mode 100644 
meta/recipes-support/gnutls/gnutls/use-pkg-config-to-locate-zlib.patch
 rename meta/recipes-support/gnutls/{gnutls_3.5.16.bb => gnutls_3.6.1.bb} (45%)
 rename meta/recipes-support/libassuan/{libassuan_2.4.3.bb => 
libassuan_2.4.4.bb} (67%)
 delete mode 100644 
meta/recipes-support/nettle/files/Add-target-to-only-build-tests-not-run-them.patch
 create mode 100644 
meta/recipes-support/nettle/nettle-3.4/Add-target-to-only-build-tests-not-run-them.patch
 rename meta/recipes-support/nettle/{nettle-3.3 => 
nettle-3.4}/check-header-files-of-openssl-only-if-enable_.patch (63%)
 rename meta/recipes-support/nettle/{nettle-3.3 => 
nettle-3.4}/dlopen-test.patch (100%)
 rename meta/recipes-support/nettle/{files => nettle-3.4}/run-ptest (100%)
 delete mode 100644 meta/recipes-support/nettle/nettle_3.3.bb
 rename meta/recipes-support/nettle/{nettle.inc => nettle_3.4.bb} (60%)
 rename meta/recipes-support/nss/{nss_3.33.bb => nss_3.34.bb} (98%)

-- 
2.7.4

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

[OE-core] [PATCH 1/5] gnutls: update to 3.6.1

[Armin Kuster]

zlib configure.ac support removed in  3.6.1
drop patch

v2: actually remove patch

Signed-off-by: Armin Kuster 
---
 meta/recipes-support/gnutls/gnutls.inc |  3 +-
 .../gnutls/use-pkg-config-to-locate-zlib.patch | 75 --
 .../gnutls/{gnutls_3.5.16.bb => gnutls_3.6.1.bb}   |  5 +-
 3 files changed, 3 insertions(+), 80 deletions(-)
 delete mode 100644 
meta/recipes-support/gnutls/gnutls/use-pkg-config-to-locate-zlib.patch
 rename meta/recipes-support/gnutls/{gnutls_3.5.16.bb => gnutls_3.6.1.bb} (45%)

diff --git a/meta/recipes-support/gnutls/gnutls.inc 
b/meta/recipes-support/gnutls/gnutls.inc
index 29b5dd6..7bcb913 100644
--- a/meta/recipes-support/gnutls/gnutls.inc
+++ b/meta/recipes-support/gnutls/gnutls.inc
@@ -21,7 +21,7 @@ SRC_URI = 
"ftp://ftp.gnutls.org/gcrypt/gnutls/v${SHRT_VER}/gnutls-${PV}.tar.xz;
 
 inherit autotools texinfo binconfig pkgconfig gettext lib_package gtk-doc
 
-PACKAGECONFIG ??= "libidn zlib"
+PACKAGECONFIG ??= "libidn"
 
 # You must also have CONFIG_SECCOMP enabled in the kernel for
 # seccomp to work.
@@ -32,7 +32,6 @@ PACKAGECONFIG[libidn] = "--with-idn,--without-idn,libidn"
 PACKAGECONFIG[libtasn1] = 
"--with-included-libtasn1=no,--with-included-libtasn1,libtasn1"
 PACKAGECONFIG[p11-kit] = "--with-p11-kit,--without-p11-kit,p11-kit"
 PACKAGECONFIG[tpm] = "--with-tpm,--without-tpm,trousers"
-PACKAGECONFIG[zlib] = "--with-zlib,--without-zlib,zlib"
 
 EXTRA_OECONF = " \
 --enable-doc \
diff --git 
a/meta/recipes-support/gnutls/gnutls/use-pkg-config-to-locate-zlib.patch 
b/meta/recipes-support/gnutls/gnutls/use-pkg-config-to-locate-zlib.patch
deleted file mode 100644
index ae141a5..000
--- a/meta/recipes-support/gnutls/gnutls/use-pkg-config-to-locate-zlib.patch
+++ /dev/null
@@ -1,75 +0,0 @@
-From 18081068a97c00015aabc5fa321664951458ea0d Mon Sep 17 00:00:00 2001
-From: Fan Xin 
-Date: Fri, 9 Jun 2017 15:20:31 +0900
-Subject: [PATCH] From cee80af1fe93f5b76765afeebfcc3b902768f5d6 Mon Sep 17
- 00:00:00 2001 From: Andre McCurdy  Date: Tue, 26 May
- 2015 21:41:24 -0700 Subject: [PATCH] use pkg-config to locate zlib
-
-AC_LIB_HAVE_LINKFLAGS can sometimes find host libs and is therefore not
-robust when cross-compiling. Remove it for zlib and use PKG_CHECK_MODULES
-instead.
-
-Removing AC_LIB_HAVE_LINKFLAGS for zlib also removes the --with-libz-prefix
-configure option. If zlib support is enabled, then failure to find zlib via
-pkg-config is now treated as a fatal error.
-
-Change based on ChromeOS gnutls 2.12.23 cross-compile fixes patch:
-
-  https://chromium-review.googlesource.com/#/c/271661/
-
-Upstream-Status: Inappropriate [configuration]
-
-Signed-off-by: Andre McCurdy 
-
-Rebase on gnutls 3.5.13
-
-Signed-off-by: Fan Xin 

- configure.ac | 25 +
- 1 file changed, 9 insertions(+), 16 deletions(-)
-
-diff --git a/configure.ac b/configure.ac
-index c65268e..f6a18aa 100644
 a/configure.ac
-+++ b/configure.ac
-@@ -735,28 +735,21 @@ AC_ARG_WITH(zlib, AS_HELP_STRING([--without-zlib],
- AC_MSG_CHECKING([whether to include zlib compression support])
- if test x$ac_zlib != xno; then
-  AC_MSG_RESULT(yes)
-- AC_LIB_HAVE_LINKFLAGS(z,, [#include ], [compress (0, 0, 0, 0);])
-- if test x$ac_cv_libz != xyes; then
--   AC_MSG_WARN(
--*** 
--*** ZLIB was not found. You will not be able to use ZLIB compression.)
-- fi
- else
-  AC_MSG_RESULT(no)
- fi
- 
--PKG_CHECK_EXISTS(zlib, ZLIB_HAS_PKGCONFIG=y, ZLIB_HAS_PKGCONFIG=n)
--
- if test x$ac_zlib != xno; then
--  if test "$ZLIB_HAS_PKGCONFIG" = "y" ; then
--if test "x$GNUTLS_REQUIRES_PRIVATE" = x; then
--  GNUTLS_REQUIRES_PRIVATE="Requires.private: zlib"
--else
--  GNUTLS_REQUIRES_PRIVATE="$GNUTLS_REQUIRES_PRIVATE, zlib"
--fi
--LIBZ_PC=""
-+  PKG_CHECK_MODULES(ZLIB, zlib)
-+  HAVE_LIBZ=yes
-+  AC_DEFINE([HAVE_LIBZ], [1], [zlib is enabled])
-+  AC_SUBST(HAVE_LIBZ)
-+  LTLIBZ=$ZLIB_LIBS
-+  AC_SUBST(LTLIBZ)
-+  if test "x$GNUTLS_REQUIRES_PRIVATE" = x; then
-+GNUTLS_REQUIRES_PRIVATE="Requires.private: zlib"
-   else
--LIBZ_PC=$LIBZ
-+GNUTLS_REQUIRES_PRIVATE="$GNUTLS_REQUIRES_PRIVATE, zlib"
-   fi
- fi
- AC_SUBST(LIBZ_PC)
--- 
-1.9.1
-
diff --git a/meta/recipes-support/gnutls/gnutls_3.5.16.bb 
b/meta/recipes-support/gnutls/gnutls_3.6.1.bb
similarity index 45%
rename from meta/recipes-support/gnutls/gnutls_3.5.16.bb
rename to meta/recipes-support/gnutls/gnutls_3.6.1.bb
index 635c519..7624a20 100644
--- a/meta/recipes-support/gnutls/gnutls_3.5.16.bb
+++ b/meta/recipes-support/gnutls/gnutls_3.6.1.bb
@@ -1,10 +1,9 @@
 require gnutls.inc
 
 SRC_URI += "file://0001-configure.ac-fix-sed-command.patch \
-file://use-pkg-config-to-locate-zlib.patch \
 file://arm_eabi.patch \
"
-SRC_URI[md5sum] = "4c39612f1ec3ef7ed79cfb8936fa8143"
-SRC_URI[sha256sum] = 

[OE-core] [PATCH 2/5] nettle: update to 3.4 and cleanup

[Armin Kuster]

From: Armin Kuster 

merge .inc
forward ported two patches to work with 3.4

for more info see:
http://lists.gnu.org/archive/html/info-gnu/2017-11/msg7.html

Signed-off-by: Armin Kuster 
---
 ...d-target-to-only-build-tests-not-run-them.patch | 46 --
 ...d-target-to-only-build-tests-not-run-them.patch | 38 ++
 ...k-header-files-of-openssl-only-if-enable_.patch | 26 ++--
 .../{nettle-3.3 => nettle-3.4}/dlopen-test.patch   |  0
 .../nettle/{files => nettle-3.4}/run-ptest |  0
 meta/recipes-support/nettle/nettle_3.3.bb  | 19 -
 .../nettle/{nettle.inc => nettle_3.4.bb}   | 14 +++
 7 files changed, 64 insertions(+), 79 deletions(-)
 delete mode 100644 
meta/recipes-support/nettle/files/Add-target-to-only-build-tests-not-run-them.patch
 create mode 100644 
meta/recipes-support/nettle/nettle-3.4/Add-target-to-only-build-tests-not-run-them.patch
 rename meta/recipes-support/nettle/{nettle-3.3 => 
nettle-3.4}/check-header-files-of-openssl-only-if-enable_.patch (63%)
 rename meta/recipes-support/nettle/{nettle-3.3 => 
nettle-3.4}/dlopen-test.patch (100%)
 rename meta/recipes-support/nettle/{files => nettle-3.4}/run-ptest (100%)
 delete mode 100644 meta/recipes-support/nettle/nettle_3.3.bb
 rename meta/recipes-support/nettle/{nettle.inc => nettle_3.4.bb} (60%)

diff --git 
a/meta/recipes-support/nettle/files/Add-target-to-only-build-tests-not-run-them.patch
 
b/meta/recipes-support/nettle/files/Add-target-to-only-build-tests-not-run-them.patch
deleted file mode 100644
index 23da777..000
--- 
a/meta/recipes-support/nettle/files/Add-target-to-only-build-tests-not-run-them.patch
+++ /dev/null
@@ -1,46 +0,0 @@
-From 46edf01cc98db9f9feec984897836dfdd26bdc8d Mon Sep 17 00:00:00 2001
-From: Jussi Kukkonen 
-Date: Wed, 12 Aug 2015 23:27:27 +0300
-Subject: [PATCH] Add target to only build tests (not run them)
-
-Not sending upstream as this is only a start of a solution to
-installable tests: It's useful for us already as is.
-
-Upstream-Status: Inappropriate [not a complete solution]
-
-Signed-off-by: Jussi Kukkonen 

- Makefile.in   | 3 +++
- testsuite/Makefile.in | 2 ++
- 2 files changed, 5 insertions(+)
-
-diff --git a/Makefile.in b/Makefile.in
-index 08efb7d..7909342 100644
 a/Makefile.in
-+++ b/Makefile.in
-@@ -55,6 +55,9 @@ clean distclean mostlyclean maintainer-clean tags:
- echo "Making $@ in $$d" ; (cd $$d && $(MAKE) $@); done
-   $(MAKE) $@-here
- 
-+buildtest:
-+  echo "Making $@ in testsuite" ; (cd testsuite && $(MAKE) $@)
-+
- check-here:
-   true
- 
-diff --git a/testsuite/Makefile.in b/testsuite/Makefile.in
-index 6bc1907..bb65bf0 100644
 a/testsuite/Makefile.in
-+++ b/testsuite/Makefile.in
-@@ -116,6 +116,8 @@ $(TARGETS) $(EXTRA_TARGETS): testutils.$(OBJEXT) 
../nettle-internal.$(OBJEXT) \
- # data.
- VALGRIND = valgrind --error-exitcode=1 --leak-check=full --show-reachable=yes 
@IF_ASM@ --partial-loads-ok=yes
- 
-+buildtest: $(TS_ALL)
-+
- # The PATH update is for locating dlls on w*ndows.
- check: $(TS_ALL)
-   LD_LIBRARY_PATH=../.lib PATH="../.lib:$$PATH" srcdir="$(srcdir)" \
--- 
-2.1.4
-
diff --git 
a/meta/recipes-support/nettle/nettle-3.4/Add-target-to-only-build-tests-not-run-them.patch
 
b/meta/recipes-support/nettle/nettle-3.4/Add-target-to-only-build-tests-not-run-them.patch
new file mode 100644
index 000..c007060
--- /dev/null
+++ 
b/meta/recipes-support/nettle/nettle-3.4/Add-target-to-only-build-tests-not-run-them.patch
@@ -0,0 +1,38 @@
+Add target to only build tests (not run them)
+
+Not sending upstream as this is only a start of a solution to
+installable tests: It's useful for us already as is.
+
+Upstream-Status: Inappropriate [not a complete solution]
+
+Signed-off-by: Jussi Kukkonen 
+Refactored for 3.4
+Signed-off-by: Armin Kuster 
+
+Index: nettle-3.4/Makefile.in
+===
+--- nettle-3.4.orig/Makefile.in
 nettle-3.4/Makefile.in
+@@ -55,6 +55,9 @@ clean distclean mostlyclean maintainer-c
+ echo "Making $@ in $$d" ; (cd $$d && $(MAKE) $@); done
+   $(MAKE) $@-here
+ 
++buildtest:
++  echo "Making $@ in testsuite" ; (cd testsuite && $(MAKE) $@)
++
+ check-here:
+   true
+ 
+Index: nettle-3.4/testsuite/Makefile.in
+===
+--- nettle-3.4.orig/testsuite/Makefile.in
 nettle-3.4/testsuite/Makefile.in
+@@ -131,6 +131,8 @@ $(TARGETS) $(EXTRA_TARGETS): testutils.$
+ # data.
+ VALGRIND = valgrind --error-exitcode=1 --leak-check=full --show-reachable=yes 
@IF_ASM@ --partial-loads-ok=yes
+ 
++buildtest: $(TS_ALL)
++
+ # The PATH update is for windows dlls, DYLD_LIBRARY_PATH is for OSX.
+ check: $(TS_ALL)
+   LD_LIBRARY_PATH=../.lib PATH="../.lib:$$PATH" DYLD_LIBRARY_PATH=../.lib 

Re: [OE-core] ✗ patchtest: failure for "[v2] openssl10: Upgrade 1.0.2l..." and 3 more

[Leonardo Sandoval]

On Mon, 20 Nov 2017 14:36:16 +0200
Alexander Kanavin  wrote:

> On 11/18/2017 11:03 AM, Stefan Agner wrote:
> 
> >> * Patch[v2,1/4] openssl10: Upgrade 1.0.2l -> 1.0.2m
> >>   Issue Missing or incorrectly formatted CVE tag in
> >> included patch file [test_cve_tag_format]
> >>Suggested fixCorrect or include the CVE tag on cve patch with
> >> format: "CVE: CVE--"  
> > 
> > I did not add any new patches which address CVE, hence I think this is a
> > false positive/not applicable.  
> 
> You mentioned CVEs in the commit message, I think it wants you to format 
> them in a standard way there.

Right. Currently test is kind of simple, in the sense that it parse the 
subject/description for a CVE and if found it, it then looks for the standard 
tag (CVE: ...). CC Daniela who is working on making this test a bit smarter.


> 
> Alex
> -- 
> ___
> 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] ✗ patchtest: failure for lib/oe/terminal.py: use an absolute path to execute oe-gnome-terminal-phonehome (rev5)

[Leonardo Sandoval]

On Mon, 20 Nov 2017 11:46:40 -0800
Andre McCurdy  wrote:

> On Mon, Nov 20, 2017 at 11:05 AM, Patchwork
>  wrote:
> > == Series Details ==
> >
> > Series: lib/oe/terminal.py: use an absolute path to execute 
> > oe-gnome-terminal-phonehome (rev5)
> > Revision: 5
> > URL   : https://patchwork.openembedded.org/series/1745/
> > State : failure
> >
> > == Summary ==
> >
> >
> > Thank you for submitting this patch series to OpenEmbedded Core. This is
> > an automated response. Several tests have been executed on the proposed
> > series by patchtest resulting in the following failures:
> >
> >
> >
> > * Issue Series does not apply on top of target branch 
> > [test_series_merge_on_head]
> >   Suggested fixRebase your series on top of targeted branch
> >   Targeted branch  master (currently at a17f3ec910)  
> 
> This is a backport request so target branch is morty, not master.
> Isn't that detected from the subject line?

this enhancement (take the target branch from subject line) was supposed to be 
working since last Friday but this was not the case. I have fixed the issue and 
this problem should not happen any more.

> 
> > If you believe any of these test results are incorrect, please reply to the
> > mailing list (openembedded-core@lists.openembedded.org) raising your 
> > concerns.
> > Otherwise we would appreciate you correcting the issues and submitting a new
> > version of the patchset if applicable. Please ensure you add/increment the
> > version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
> > [PATCH v3] -> ...).
> >
> > ---
> > Guidelines: 
> > https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
> > Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
> > Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe
> >
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core  
> -- 
> ___
> 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] ✗ patchtest: failure for glibc_2.25: fix building for x86 with -Os (or -fno-omit-frame-pointer)

[Leonardo Sandoval]

On Mon, 20 Nov 2017 20:02:56 -
Patchwork  wrote:

> == Series Details ==
> 
> Series: glibc_2.25: fix building for x86 with -Os (or -fno-omit-frame-pointer)
> Revision: 1
> URL   : https://patchwork.openembedded.org/series/9881/
> State : failure
> 
> == Summary ==
> 
> 
> Thank you for submitting this patch series to OpenEmbedded Core. This is
> an automated response. Several tests have been executed on the proposed
> series by patchtest resulting in the following failures:
> 
> 
> 
> * Issue Series does not apply on top of target branch 
> [test_series_merge_on_head] 
>   Suggested fixRebase your series on top of targeted branch
>   Targeted branch  master (currently at a17f3ec910)
> 

please ignore this request. I have fixed the root problem at patchtest-oe (pick 
up the correct branch from subject)

> 
> 
> If you believe any of these test results are incorrect, please reply to the
> mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
> Otherwise we would appreciate you correcting the issues and submitting a new
> version of the patchset if applicable. Please ensure you add/increment the
> version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
> [PATCH v3] -> ...).
> 
> ---
> Guidelines: 
> https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
> Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
> Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe
> 
> -- 
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] backfill mechanism

[Slater, Joseph]

The problem is that when backfilling is done, TUNE_FEATURES, etc, all have 
values associated with the base arch, not the current multilib.  The "generic" 
solution, below, should work, although I would still use overrides when 
available.

Beyond what actually works, if the special backfill processing can be 
eliminated and regular constructs used I think that would be desirable.

Joe

From: Andre McCurdy [armccu...@gmail.com]
Sent: Monday, November 20, 2017 7:24 PM
To: Slater, Joseph
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] backfill mechanism

On Fri, Nov 17, 2017 at 3:32 PM, Slater, Joseph
 wrote:
> The backfill mechanism is not compatible with multilib.

Did anyone ever explain why?

> This could possibly
> be fixed, but the backfill_considered functionality is also obscure, so I
> think in at least the machine related .inc files we should replace lines
> like
>
> MACHINE_FEATURES_BACKFILL_CONSIDERED_append = "
> ${@bb.utils.contains('TUNE_FEATURES', 'n32', 'qemu-usermode', '', d)}"
>
> with lines like
>
> MACHINE_FEATURES_remove_mipsarchn32 = " qemu-usermode"

That only works for TUNE_FEATURES which happen to have a corresponding
over-ride, so may not be a generic solution. Does something like:

  MACHINE_FEATURES_remove = "${@bb.utils.contains('TUNE_FEATURES',
'n32', 'qemu-usermode', '', d)}"

work for multilib?

> There are two advantages:  the second line works for multilib, and it is far
> more readable.
>
> Joe
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 4/5] libassuan: update to 2.4.4

[akuster808]

On 11/21/2017 07:56 AM, Alexander Kanavin wrote:
> On 11/21/2017 04:41 PM, Burton, Ross wrote:
>> License checksum changes but no explanation.
>
> Should we introduce a standard tag for the explanation, similar to cve
> tags?
>
> License-checksum-change: copyright years updated
seems reasonable.
>
> and then have the robot do the check, while we can spend time on more
> interesting things.
>
>
> Alex

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

Re: [OE-core] [PATCH 4/5] libassuan: update to 2.4.4

[Alexander Kanavin]

On 11/21/2017 04:41 PM, Burton, Ross wrote:

License checksum changes but no explanation.


Should we introduce a standard tag for the explanation, similar to cve tags?

License-checksum-change: copyright years updated

and then have the robot do the check, while we can spend time on more 
interesting things.



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

Re: [OE-core] Yocto Project Status WW47’17

[Wold, Saul]

On Tue, 2017-11-21 at 11:09 +, Richard Purdie wrote:
> On Mon, 2017-11-20 at 20:22 -0500, Randy MacLeod wrote:
> > On 2017-11-20 10:36 AM, Jolley, Stephen K wrote:
> > > Current Dev Position: YP 2.5 Planning and M1 development
> > > Next Deadline: YP 2.5 M1 cut off of 12/4/17
> > >  
> > > SWAT team rotation: Juro -> Paul on Nov.17, 2017.
> > > SWAT team rotation: Paul -> Todor on Nov. 24, 2017.
> > > https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team
> > >  
> > > Key Status/Updates:
> > > ·There is no real change to the status from last week. We
> > > continue to suffer intermittent build failures and are continuing
> > > to attempt to debug these.
> > > ·Currently open issues are:
> > 
> >  
> > Some US-based people may be on holiday later this week so I'm
> > offering 
> > help from the frozen Northland and more importantly from the team
> > in
> > Beijing. ;-)
> > 
> > > o   qemuppc continues to demonstrate random hangs in boot  in
> > > userspace
> > 
> >  
> > Is we can create a defect for this and point / copy the wiki notes
> > into it, that
> > would help.
> >https://wiki.yoctoproject.org/wiki/Qemuppc_Boot_Hangs
> > 
> > I think I had asked Chi to see if he could reproduce this a week or
> > two ago.
> > When the lack of entropy problem was identified and fix, many
> > people
> > thought
> > this hang went away as well. Chi can you read the wiki report and
> > see
> > if you
> > can add anything to them?
> 
> Good news is that the qemuppc issue has been identified as a bug in
> qemu ppc locking which breaks timer interrupt handling. I've posted
> on
> the qemu mailing list asking for help in verifying what I think is
> happening.
> 
> I have a patch ready to merge which should address this one, just
> cleaning up my environment and doing some further stress testing.
> 
This is great news hopefully you will hear back from the qemu ML
verifying your patch.

> [There is a defect somewhere for this btw, I created the wiki as it
> was
> a better place to dump and update information as we learnt what it
> is/is not without having to follow a train of thought updating in the
> bugzilla].
> 
> > > o   Issues with 4.13.10 host kernels booting kvm x86 guests on
> > > Tumbleweed (Suse) and Fedora 26 (attempting to see if 4.13.12
> > > helps)
> > 
> >  
> > Robert, can you test Fedora 26. It would help to have a defect open
> > with steps to reproduce or
> > something about the typical workflow/ build time/ day of the week/
> > phase of the moon. 
> 
> FWIW we have noticed that the choice of kernel timers seems to vary
> in
> the x86_64 boots but not with a pattern that matches the hangs.
> 
> > > o   nfs inode count for the sstate/dldir share appears to break
> > > periodically causing the disk monitor to halt the builds (bug
> > > 12267)
> > 
> >  
> > Likely specific to the AB server so no plans to do anything for
> > this
> > bug.
> 
> Agreed, this one is our infrastructure somehow :(. We have a
> workaround
> in -next for this at least.
> 
> > > o   a perf build race (bug 12302)
> > 
> >   I'll take a look to:
> >  - see if I can duplicate the bug on a fast build host
> >  - check upstream to see if the bug is known/fixed
> >  - see if I can spot a race in the build rules.
> 
> Sounds good, thanks!
> 
> > > o   An ext filesystem creation/sizing issue (bug 12304)
> > 
> >  
> > Saul, Are you around this week? Do you have any additional
> > information before
> > leaving for Thanksgiving?
> > 
> > Jackie, 
> > Can you look at the code around the image creation and try to
> > reproduce this one?
> 
> Saul hasn't been able to reproduce. I've asked at the minimum we add
> better logging so if/when this happens again, we can debug it
> properly

Patch sent which provides some additional debugging information to the
log files, ideally, this will be saved with the bug next time this
issue occurs.

Sau!

> next time. I did also wonder about fuzzing the image size code,
> writing
> some code which puts in all possible input values and checks the
> sanity
> of the resulting image size. Its the kind of problem a computer can
> probably brute force. Anyone interested in trying that?
> 
> Cheers,
> 
> Richard
> 
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] image_types: Add debugging code to ext4 fs creation

[Saul Wold]

We have seen a small number of issues with ROOTFS_SIZE not getting
computed correctly, resulting in a failure in the mke2fs processing
and populating the resulting new filesystem.

This information should help us to reproduce [YOCTO #12304]

Signed-off-by: Saul Wold 
---
 meta/classes/image_types.bbclass | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index b373b217145..cab2963756b 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -83,7 +83,11 @@ oe_mkext234fs () {
eval COUNT=\"$MIN_COUNT\"
fi
# Create a sparse image block
+   bbdebug 1 Executing "dd if=/dev/zero 
of=${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.$fstype seek=$ROOTFS_SIZE 
count=$COUNT bs=1024"
dd if=/dev/zero 
of=${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.$fstype seek=$ROOTFS_SIZE 
count=$COUNT bs=1024
+   bbdebug 1 "Actual Rootfs size:  `du -s ${IMAGE_ROOTFS}`"
+   bbdebug 1 "Actual Partion size: `ls -s 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.$fstype`"
+   bbdebug 1 Executing "mkfs.$fstype -F $extra_imagecmd 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.$fstype -d ${IMAGE_ROOTFS}"
mkfs.$fstype -F $extra_imagecmd 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.$fstype -d ${IMAGE_ROOTFS}
# Error codes 0-3 indicate successfull operation of fsck (no errors or 
errors corrected)
fsck.$fstype -pvfD 
${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.$fstype || [ $? -le 3 ]
-- 
2.13.5

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

Re: [OE-core] [PATCH 4/5] libassuan: update to 2.4.4

[Burton, Ross]

License checksum changes but no explanation.

Ross

On 21 November 2017 at 00:07, Armin Kuster  wrote:

> From: Armin Kuster 
>
> forward ported patch
>
> Signed-off-by: Armin Kuster 
> ---
>  .../libassuan-add-pkgconfig-support.patch  | 77
> +++---
>  .../{libassuan_2.4.3.bb => libassuan_2.4.4.bb} | 11 ++--
>  2 files changed, 45 insertions(+), 43 deletions(-)
>  rename meta/recipes-support/libassuan/{libassuan_2.4.3.bb =>
> libassuan_2.4.4.bb} (67%)
>
> diff --git 
> a/meta/recipes-support/libassuan/libassuan/libassuan-add-pkgconfig-support.patch
> b/meta/recipes-support/libassuan/libassuan/libassuan-
> add-pkgconfig-support.patch
> index b6ccdda..525b076 100644
> --- a/meta/recipes-support/libassuan/libassuan/libassuan-
> add-pkgconfig-support.patch
> +++ b/meta/recipes-support/libassuan/libassuan/libassuan-
> add-pkgconfig-support.patch
> @@ -6,32 +6,15 @@ Upstream-Status: Denied
>  Signed-off-by: Chen Qi 
>  Signed-off-by: Constantin Musca 
>
> -Index: libassuan-2.1.2/Makefile.am
> -===
>  libassuan-2.1.2.orig/Makefile.am
> -+++ libassuan-2.1.2/Makefile.am
> -@@ -24,10 +24,13 @@ AUTOMAKE_OPTIONS = dist-bzip2 no-dist-gz
> - # (A suitable gitlog-to-changelog script can be found in GnuPG master.)
> - GITLOG_TO_CHANGELOG=gitlog-to-changelog
> -
> -+pkgconfigdir = $(libdir)/pkgconfig
> -+pkgconfig_DATA = libassuan.pc
> -+
> - EXTRA_DIST = autogen.sh autogen.rc README.GIT
>  \
> -  ChangeLog-2011 doc/ChangeLog-2011 src/ChangeLog-2011 \
> -  tests/ChangeLog-2011 contrib/ChangeLog-2011  \
> -- build-aux/git-log-footer build-aux/git-log-fix
> -+ build-aux/git-log-footer build-aux/git-log-fix
> libassuan.pc.in
> -
> - SUBDIRS = m4 src doc tests
> -
> -Index: libassuan-2.1.2/libassuan.pc.in
> +forward ported to 2.4.4
> +Signed-off-by: Armin Kuster 
> +
> +Index: libassuan-2.4.4/libassuan.pc.in
>  ===
>  --- /dev/null
> -+++ libassuan-2.1.2/libassuan.pc.in
> -@@ -0,0 +1,14 @@
> -+prefix=@prefix@
> -+exec_prefix=@exec_prefix@
>  libassuan-2.4.4/libassuan.pc.in
> +@@ -0,0 +1,13 @@
> ++prefix=@exec_prefix@
>  +libdir=@libdir@
>  +includedir=@includedir@
>  +api_version=@LIBASSUAN_CONFIG_API_VERSION@
> @@ -44,24 +27,42 @@ Index: libassuan-2.1.2/libassuan.pc.in
>  +Libs: -L${libdir} -lassuan
>  +Libs.private: -lgpg-error
>  +Cflags: -I${includedir}
> -Index: libassuan-2.1.2/configure.ac
> +Index: libassuan-2.4.4/Makefile.am
>  ===
>  libassuan-2.1.2.orig/configure.ac
> -+++ libassuan-2.1.2/configure.ac
> -@@ -439,7 +439,7 @@ AC_CONFIG_FILES([doc/Makefile])
> +--- a/Makefile.am
>  b/Makefile.am
> +@@ -25,10 +25,13 @@ DISTCHECK_CONFIGURE_FLAGS = --enable-doc
> + # (A suitable gitlog-to-changelog script can be found in GnuPG master.)
> + GITLOG_TO_CHANGELOG=gitlog-to-changelog
> +
> ++pkgconfigdir = $(libdir)/pkgconfig
> ++pkgconfig_DATA = libassuan.pc
> ++
> + EXTRA_DIST = autogen.sh autogen.rc README.GIT VERSION   \
> +  ChangeLog-2011 doc/ChangeLog-2011 src/ChangeLog-2011 \
> +  tests/ChangeLog-2011 contrib/ChangeLog-2011  \
> +- build-aux/git-log-footer build-aux/git-log-fix
> ++ build-aux/git-log-footer build-aux/git-log-fix
> libassuan.pc.in
> +
> + if BUILD_DOC
> + doc = doc
> +Index: 2.4.4-r0/libassuan-2.4.4/configure.ac
> +===
> +--- a/configure.ac
>  b/configure.ac
> +@@ -485,6 +485,7 @@ AC_CONFIG_FILES([doc/Makefile])
>   AC_CONFIG_FILES([tests/Makefile])
>   AC_CONFIG_FILES([src/libassuan-config], [chmod +x src/libassuan-config])
>   AC_CONFIG_FILES([src/versioninfo.rc])
> --
>  +AC_CONFIG_FILES([libassuan.pc])
> +
>   AC_OUTPUT
>
> - echo "
> -Index: libassuan-2.1.2/src/libassuan.m4
> +Index: libassuan-2.4.4/src/libassuan.m4
>  ===
>  libassuan-2.1.2.orig/src/libassuan.m4
> -+++ libassuan-2.1.2/src/libassuan.m4
> -@@ -15,18 +15,6 @@ dnl Returns ok set to yes or no.
> +--- a/src/libassuan.m4
>  b/src/libassuan.m4
> +@@ -16,18 +16,6 @@ dnl Returns ok set to yes or no.
>   dnl
>   AC_DEFUN([_AM_PATH_LIBASSUAN_COMMON],
>   [ AC_REQUIRE([AC_CANONICAL_HOST])
> @@ -80,7 +81,7 @@ Index: libassuan-2.1.2/src/libassuan.m4
>
> tmp=ifelse([$1], ,1:0.9.2,$1)
> if echo "$tmp" | grep ':' >/dev/null 2>/dev/null ; then
> -@@ -37,51 +25,12 @@ AC_DEFUN([_AM_PATH_LIBASSUAN_COMMON],
> +@@ -38,51 +26,12 @@ AC_DEFUN([_AM_PATH_LIBASSUAN_COMMON],
>   min_libassuan_version="$tmp"
> fi
>
> @@ -105,7 +106,7 @@ Index: libassuan-2.1.2/src/libassuan.m4
>  -
>  -if test 

Re: [OE-core] [PATCH 5/5] curl: update to 7.56.1

[Burton, Ross]

As with the last time this upgrade was done, the multilib_header inherit
can be removed now.

Ross

On 21 November 2017 at 00:07, Armin Kuster  wrote:

> From: Armin Kuster 
>
> curlbuild.h removed from sources
>
> includes:
> CVE-2017-1000257
>
> removed patches for the following cve fixs:
> CVE-2017-1000254
> CVE-2017-1000101
> CVE-2017-1000100
> CVE-2017-199
>
> Signed-off-by: Armin Kuster 
> ---
>  meta/recipes-support/curl/{curl_7.54.1.bb => curl_7.56.1.bb} | 12
> ++--
>  1 file changed, 2 insertions(+), 10 deletions(-)
>  rename meta/recipes-support/curl/{curl_7.54.1.bb => curl_7.56.1.bb} (89%)
>
> diff --git a/meta/recipes-support/curl/curl_7.54.1.bb
> b/meta/recipes-support/curl/curl_7.56.1.bb
> similarity index 89%
> rename from meta/recipes-support/curl/curl_7.54.1.bb
> rename to meta/recipes-support/curl/curl_7.56.1.bb
> index 58f0531..2891a4b 100644
> --- a/meta/recipes-support/curl/curl_7.54.1.bb
> +++ b/meta/recipes-support/curl/curl_7.56.1.bb
> @@ -7,10 +7,6 @@ LIC_FILES_CHKSUM = "file://COPYING;beginline=8;md5=
> 3a34942f4ae3fbf1a303160714e66
>
>  SRC_URI = "http://curl.haxx.se/download/curl-${PV}.tar.bz2 \
> file://0001-replace-krb5-config-with-pkg-config.patch \
> -   file://CVE-2017-199.patch \
> -   file://CVE-2017-1000100.patch \
> -   file://CVE-2017-1000101.patch \
> -   file://CVE-2017-1000254.patch \
>  "
>
>  SRC_URI_append_class-target = " \
> @@ -22,8 +18,8 @@ SRC_URI_append_class-target = " \
>  #
>  SRC_URI += " file://configure_ac.patch"
>
> -SRC_URI[md5sum] = "6b6eb722f512e7a24855ff084f54fe55"
> -SRC_URI[sha256sum] = "fdfc4df2d001ee0c44ec071186e770
> 046249263c491fcae48df0e1a3ca8f25a0"
> +SRC_URI[md5sum] = "428de25834ef8c04076906d6d5c0498e"
> +SRC_URI[sha256sum] = "2594670367875e7d87b0f129b5e469
> 0150780884d90244ba0fe3e74a778b5f90"
>
>  CVE_PRODUCT = "libcurl"
>  inherit autotools pkgconfig binconfig multilib_header
> @@ -64,10 +60,6 @@ EXTRA_OECONF = " \
>  --without-libpsl \
>  "
>
> -do_install_append() {
> -   oe_multilib_header curl/curlbuild.h
> -}
> -
>  do_install_append_class-target() {
> # cleanup buildpaths from curl-config
> sed -i \
> --
> 2.7.4
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] verify-bashisms: use argparse, add verbose option

[Robert P. J. Day]

On Tue, 21 Nov 2017, Ross Burton wrote:

> Signed-off-by: Ross Burton 
> ---
>  scripts/verify-bashisms | 15 +++
>  1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/scripts/verify-bashisms b/scripts/verify-bashisms
> index dab64ef5019..a979bd29650 100755
> --- a/scripts/verify-bashisms
> +++ b/scripts/verify-bashisms
> @@ -89,7 +89,13 @@ def get_tinfoil():
>  return tinfoil
>
>  if __name__=='__main__':
> -import shutil
> +import argparse, shutil
> +
> +parser = argparse.ArgumentParser(description='Bashim detector for shell 
> fragments in recipes.')
 ^^ ???

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday

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

[OE-core] ✗ patchtest: failure for "runqemu: Ensure we process all..." and 5 more

[Patchwork]

== Series Details ==

Series: "runqemu: Ensure we process all..." and 5 more
Revision: 1
URL   : https://patchwork.openembedded.org/series/9898/
State : failure

== Summary ==


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



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

* Issue A patch file has been added, but does not have a 
Signed-off-by tag [test_signed_off_by_presence] 
  Suggested fixSign off the added patch file 
(meta/recipes-devtools/qemu/qemu/ppc_locking.patch)



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

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

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

[OE-core] [PATCH] verify-bashisms: use argparse, add verbose option

[Ross Burton]

Signed-off-by: Ross Burton 
---
 scripts/verify-bashisms | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/scripts/verify-bashisms b/scripts/verify-bashisms
index dab64ef5019..a979bd29650 100755
--- a/scripts/verify-bashisms
+++ b/scripts/verify-bashisms
@@ -89,7 +89,13 @@ def get_tinfoil():
 return tinfoil
 
 if __name__=='__main__':
-import shutil
+import argparse, shutil
+
+parser = argparse.ArgumentParser(description='Bashim detector for shell 
fragments in recipes.')
+parser.add_argument("recipes", metavar="RECIPE", nargs="*", help="recipes 
to check (if not specified, all will be checked)")
+parser.add_argument("--verbose", default=False, action="store_true")
+args = parser.parse_args()
+
 if shutil.which("checkbashisms.pl") is None:
 print("Cannot find checkbashisms.pl on $PATH, get it from 
https://anonscm.debian.org/cgit/collab-maint/devscripts.git/plain/scripts/checkbashisms.pl;)
 sys.exit(1)
@@ -99,6 +105,8 @@ if __name__=='__main__':
 # bitbake server is crucial, don't change it.
 def func(item):
 (filename, key, lineno), script = item
+if args.verbose:
+print("Scanning %s:%s" % (filename, key))
 return process(filename, key, lineno, script)
 
 import multiprocessing
@@ -110,9 +118,8 @@ if __name__=='__main__':
 # recipecaches to handle multiconfig environments
 pkg_pn = tinfoil.cooker.recipecaches[""].pkg_pn
 
-# TODO: use argparse and have --help
-if len(sys.argv) > 1:
-initial_pns = sys.argv[1:]
+if args.recipes:
+initial_pns = args.recipes
 else:
 initial_pns = sorted(pkg_pn)
 
-- 
2.11.0

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

[OE-core] [PATCH 4/6] runqemu: Improve relative path handling in qemuconf files

[Richard Purdie]

If a variable starts with "../", its likely its a path and we want to
set it to an absolute path relative to the qemuconf file.

This means we don't have to use bitbake as often to figure out variables.

Signed-off-by: Richard Purdie 
---
 scripts/runqemu | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/scripts/runqemu b/scripts/runqemu
index ad88da3..b09cf1c 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -726,6 +726,8 @@ class BaseConfig(object):
 cf.read(self.qemuboot)
 for k, v in cf.items('config_bsp'):
 k_upper = k.upper()
+if v.startswith("../"):
+v = os.path.abspath(os.path.dirname(self.qemuboot) + "/" + v)
 self.set(k_upper, v)
 
 def validate_paths(self):
-- 
2.7.4

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

[OE-core] [PATCH 2/6] qemu: Add patch to avoid qemuppc boot hangs

[Richard Purdie]

qemuppc boots are occasionally hanging on the autobuilder. This adds a
patch which fixes the issue in local testing. Its being discussed with
upstream qemu.

Signed-off-by: Richard Purdie 
---
 meta/recipes-devtools/qemu/qemu/ppc_locking.patch | 105 ++
 meta/recipes-devtools/qemu/qemu_2.10.1.bb |   1 +
 2 files changed, 106 insertions(+)
 create mode 100644 meta/recipes-devtools/qemu/qemu/ppc_locking.patch

diff --git a/meta/recipes-devtools/qemu/qemu/ppc_locking.patch 
b/meta/recipes-devtools/qemu/qemu/ppc_locking.patch
new file mode 100644
index 000..6f72243
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/ppc_locking.patch
@@ -0,0 +1,105 @@
+I've tracked down what I think is a problem causing qemu-system-ppc
+to hang whilst booting images.
+
+I believe the decrementer timer stops receiving interrupts so
+tasks in our images hang indefinitely as the timer stopped. 
+
+It can be summed up with this line of debug:
+
+ppc_set_irq: 0x55b4e0d562f0 n_IRQ 8 level 1 => pending 0100req 0004
+
+It should normally read:
+
+ppc_set_irq: 0x55b4e0d562f0 n_IRQ 8 level 1 => pending 0100req 0002
+
+The question is why CPU_INTERRUPT_EXITTB ends up being set when the
+lines above this log message clearly sets CPU_INTERRUPT_HARD (via 
+cpu_interrupt() ).
+
+I note in cpu.h:
+
+/* updates protected by BQL */
+uint32_t interrupt_request;
+
+(for struct CPUState)
+
+The ppc code does "cs->interrupt_request |= CPU_INTERRUPT_EXITTB" in 5
+places, 3 in excp_helper.c and 2 in helper_regs.h. In all cases,  
+g_assert(qemu_mutex_iothread_locked()); fails. If I do something like:
+
+if (!qemu_mutex_iothread_locked()) {
+qemu_mutex_lock_iothread();
+cpu_interrupt(cs, CPU_INTERRUPT_EXITTB);
+qemu_mutex_unlock_iothread();
+} else {
+cpu_interrupt(cs, CPU_INTERRUPT_EXITTB);
+}
+
+in these call sites then I can no longer lock qemu up with my test
+case.
+
+I suspect the _HARD setting gets overwritten which stops the 
+decrementer interrupts being delivered.
+
+Upstream-Status: Submitted [Issue discussed on qemu mailing list 2017/11/20]
+RP 2017/11/20
+
+Index: qemu-2.10.1/target/ppc/excp_helper.c
+===
+--- qemu-2.10.1.orig/target/ppc/excp_helper.c
 qemu-2.10.1/target/ppc/excp_helper.c
+@@ -207,7 +207,9 @@ static inline void powerpc_excp(PowerPCC
+ "Entering checkstop state\n");
+ }
+ cs->halted = 1;
+-cs->interrupt_request |= CPU_INTERRUPT_EXITTB;
++qemu_mutex_lock_iothread();
++cpu_interrupt(cs, CPU_INTERRUPT_EXITTB);
++qemu_mutex_unlock_iothread();
+ }
+ if (env->msr_mask & MSR_HVB) {
+ /* ISA specifies HV, but can be delivered to guest with HV clear
+@@ -940,7 +942,9 @@ void helper_store_msr(CPUPPCState *env,
+ 
+ if (excp != 0) {
+ CPUState *cs = CPU(ppc_env_get_cpu(env));
+-cs->interrupt_request |= CPU_INTERRUPT_EXITTB;
++qemu_mutex_lock_iothread();
++cpu_interrupt(cs, CPU_INTERRUPT_EXITTB);
++qemu_mutex_unlock_iothread();
+ raise_exception(env, excp);
+ }
+ }
+@@ -995,7 +999,9 @@ static inline void do_rfi(CPUPPCState *e
+ /* No need to raise an exception here,
+  * as rfi is always the last insn of a TB
+  */
+-cs->interrupt_request |= CPU_INTERRUPT_EXITTB;
++qemu_mutex_lock_iothread();
++cpu_interrupt(cs, CPU_INTERRUPT_EXITTB);
++qemu_mutex_unlock_iothread();
+ 
+ /* Reset the reservation */
+ env->reserve_addr = -1;
+Index: qemu-2.10.1/target/ppc/helper_regs.h
+===
+--- qemu-2.10.1.orig/target/ppc/helper_regs.h
 qemu-2.10.1/target/ppc/helper_regs.h
+@@ -114,11 +114,15 @@ static inline int hreg_store_msr(CPUPPCS
+ }
+ if (((value >> MSR_IR) & 1) != msr_ir ||
+ ((value >> MSR_DR) & 1) != msr_dr) {
+-cs->interrupt_request |= CPU_INTERRUPT_EXITTB;
++qemu_mutex_lock_iothread();
++cpu_interrupt(cs, CPU_INTERRUPT_EXITTB);
++qemu_mutex_unlock_iothread();
+ }
+ if ((env->mmu_model & POWERPC_MMU_BOOKE) &&
+ ((value >> MSR_GS) & 1) != msr_gs) {
+-cs->interrupt_request |= CPU_INTERRUPT_EXITTB;
++qemu_mutex_lock_iothread();
++cpu_interrupt(cs, CPU_INTERRUPT_EXITTB);
++qemu_mutex_unlock_iothread();
+ }
+ if (unlikely((env->flags & POWERPC_FLAG_TGPR) &&
+  ((value ^ env->msr) & (1 << MSR_TGPR {
diff --git a/meta/recipes-devtools/qemu/qemu_2.10.1.bb 
b/meta/recipes-devtools/qemu/qemu_2.10.1.bb
index 6e9b68b..8e3ca3c 100644
--- a/meta/recipes-devtools/qemu/qemu_2.10.1.bb
+++ b/meta/recipes-devtools/qemu/qemu_2.10.1.bb
@@ -24,6 +24,7 @@ SRC_URI = 
"http://wiki.qemu-project.org/download/${BP}.tar.bz2 \

[OE-core] [PATCH 5/6] qemuboot: Improve relative path handling

[Richard Purdie]

qemuconf files are currently written relative to TOPDIR. What
makes more sense is to write paths relative to the location of the
file. This makes moving them around and decoding the end paths in
runqemu much easier.

The effect of this should allow less use of bitbake to determine
variables and allow us to simplify runqemu.

Signed-off-by: Richard Purdie 
---
 meta/classes/qemuboot.bbclass | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/meta/classes/qemuboot.bbclass b/meta/classes/qemuboot.bbclass
index 7243cc5..15a9e63 100644
--- a/meta/classes/qemuboot.bbclass
+++ b/meta/classes/qemuboot.bbclass
@@ -85,7 +85,8 @@ python do_write_qemuboot_conf() {
 
 qemuboot = "%s/%s.qemuboot.conf" % (d.getVar('IMGDEPLOYDIR'), 
d.getVar('IMAGE_NAME'))
 qemuboot_link = "%s/%s.qemuboot.conf" % (d.getVar('IMGDEPLOYDIR'), 
d.getVar('IMAGE_LINK_NAME'))
-topdir="%s/"%(d.getVar('TOPDIR')).replace("//","/")
+finalpath = d.getVar("DEPLOY_DIR_IMAGE")
+topdir = d.getVar('TOPDIR')
 cf = configparser.ConfigParser()
 cf.add_section('config_bsp')
 for k in sorted(qemuboot_vars(d)):
@@ -98,7 +99,8 @@ python do_write_qemuboot_conf() {
 val = d.getVar(k)
 # we only want to write out relative paths so that we can relocate 
images
 # and still run them
-val=val.replace(topdir,"")
+if val.startswith(topdir):
+val = os.path.relpath(val, finalpath)
 cf.set('config_bsp', k, '%s' % val)
 
 # QB_DEFAULT_KERNEL's value of KERNEL_IMAGETYPE is the name of a symlink
@@ -108,7 +110,7 @@ python do_write_qemuboot_conf() {
 kernel = os.path.realpath(kernel_link)
 # we only want to write out relative paths so that we can relocate images
 # and still run them
-kernel=kernel.replace(topdir,"")
+kernel = os.path.relpath(kernel, finalpath)
 cf.set('config_bsp', 'QB_DEFAULT_KERNEL', kernel)
 
 bb.utils.mkdirhier(os.path.dirname(qemuboot))
-- 
2.7.4

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

[OE-core] [PATCH 6/6] qemurunner: Simplify binary data handling

[Richard Purdie]

I have concerns that bad timing of the flow of data from the logger
might corrupt the output due to the way binary strings are handled
in qemurunner.

This simplifies the code to do the same thing it did before but much
more safely.

Signed-off-by: Richard Purdie 
---
 meta/lib/oeqa/utils/qemurunner.py | 20 
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/meta/lib/oeqa/utils/qemurunner.py 
b/meta/lib/oeqa/utils/qemurunner.py
index 82335d8..0631d43 100644
--- a/meta/lib/oeqa/utils/qemurunner.py
+++ b/meta/lib/oeqa/utils/qemurunner.py
@@ -275,7 +275,7 @@ class QemuRunner:
 reachedlogin = False
 stopread = False
 qemusock = None
-bootlog = ''
+bootlog = b''
 data = b''
 while time.time() < endtime and not stopread:
 try:
@@ -292,17 +292,13 @@ class QemuRunner:
 else:
 data = data + sock.recv(1024)
 if data:
-try:
-data = data.decode("utf-8", 
errors="surrogateescape")
-bootlog += data
-data = b''
-if re.search(".* login:", bootlog):
-self.server_socket = qemusock
-stopread = True
-reachedlogin = True
-self.logger.debug("Reached login banner")
-except UnicodeDecodeError:
-continue
+bootlog += data
+data = b''
+if b' login:' in bootlog:
+self.server_socket = qemusock
+stopread = True
+reachedlogin = True
+self.logger.debug("Reached login banner")
 else:
 socklist.remove(sock)
 sock.close()
-- 
2.7.4

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

[OE-core] [PATCH 3/6] classes/cross: Add addto_recipe_sysroot task to cross recipes

[Richard Purdie]

This is particularly useful if you want to use gdb-cross as there
is no other good way to access it now with RSS.

Signed-off-by: Richard Purdie 
---
 meta/classes/cross.bbclass | 5 +
 1 file changed, 5 insertions(+)

diff --git a/meta/classes/cross.bbclass b/meta/classes/cross.bbclass
index d217717..e9fafed 100644
--- a/meta/classes/cross.bbclass
+++ b/meta/classes/cross.bbclass
@@ -92,3 +92,8 @@ export STRIP = "${BUILD_STRIP}"
 export NM = "${BUILD_NM}"
 
 inherit nopackages
+
+python do_addto_recipe_sysroot () {
+bb.build.exec_func("extend_recipe_sysroot", d)
+}
+addtask addto_recipe_sysroot after do_populate_sysroot
-- 
2.7.4

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

[OE-core] [PATCH 1/6] runqemu: Ensure we process all tap devices

[Richard Purdie]

The regexp in the script misses some tap devices, e.g. we see output like:

runqemu - INFO - Acquiring lockfile /tmp/qemu-tap-locks/tap25.lock failed: 
[Errno 11] Resource temporarily unavailable
runqemu - INFO - Acquiring lockfile /tmp/qemu-tap-locks/tap26.lock failed: 
[Errno 11] Resource temporarily unavailable
runqemu - INFO - Acquiring lockfile /tmp/qemu-tap-locks/tap27.lock failed: 
[Errno 11] Resource temporarily unavailable
runqemu - INFO - Acquiring lockfile /tmp/qemu-tap-locks/tap28.lock failed: 
[Errno 11] Resource temporarily unavailable
runqemu - INFO - Acquiring lockfile /tmp/qemu-tap-locks/tap40.lock failed: 
[Errno 11] Resource temporarily unavailable
runqemu - INFO - Acquiring lockfile /tmp/qemu-tap-locks/tap41.lock failed: 
[Errno 11] Resource temporarily unavailable

What happened to tap29 to tap39?

The issue is was we were missing devices with '0' in the number,
like "10:" and so on in the output from "ip link".

Signed-off-by: Richard Purdie 
---
 scripts/runqemu | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/runqemu b/scripts/runqemu
index fe4459d..ad88da3 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -923,7 +923,7 @@ class BaseConfig(object):
 logger.debug('Running %s...' % cmd)
 ip_link = subprocess.Popen(cmd, shell=True, 
stdout=subprocess.PIPE).stdout.read().decode('utf-8')
 # Matches line like: 6: tap0: 
-possibles = re.findall('^[1-9]+: +(tap[0-9]+): <.*', ip_link, re.M)
+possibles = re.findall('^[0-9]+: +(tap[0-9]+): <.*', ip_link, re.M)
 tap = ""
 for p in possibles:
 lockfile = os.path.join(lockdir, p)
-- 
2.7.4

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

Re: [OE-core] native CA cert bundles (was: Re: [PATCH 3/3] cve-check-tool: Use CA cert bundle in correct sysroot)

[Otavio Salvador]

On Tue, Nov 21, 2017 at 10:21 AM, Patrick Ohly  wrote:
> On Tue, 2017-11-21 at 10:06 -0200, Otavio Salvador wrote:
>> On Tue, Nov 21, 2017 at 6:04 AM, Patrick Ohly > > wrote:
>> > On Thu, 2017-02-09 at 21:38 +0200, Jussi Kukkonen wrote:
>> > There is https://bugzilla.yoctoproject.org/show_bug.cgi?id=9883
>> > open
>> > about some aspect of this, but it doesn't actually address the
>> > underlying question about what the right behavior should be. It's
>> > based
>> > on the assumption that libcurl-native should always use ca-
>> > certificates-native.
>> >
>> > Thoughts anyone?
>>
>> I agree it should use ca-certificates-native for all native; it
>> allows for self-signed internal certificates to be added for internal
>> development.
>
> But that's not what bitbake itself uses. Are you saying that bitbake
> fetchers etc. should also use whatever certificates are configured for
> ca-certificates-native? That leads to a chicken-and-egg problem.
>
> A solution where custom certificates need to be configured in two
> different places (system for bitbake, ca-certificates-native for some
> other tools) sounds sub-optimal to me.

I know and we could override it to a place.

We ended doing it ourselves:
https://github.com/updatehub/meta-updatehub/commit/e9c34faddb6a59d560147798b37ac6a0e3fa57bf

but this is not generic.

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

Re: [OE-core] native CA cert bundles (was: Re: [PATCH 3/3] cve-check-tool: Use CA cert bundle in correct sysroot)

[Patrick Ohly]

On Tue, 2017-11-21 at 10:06 -0200, Otavio Salvador wrote:
> On Tue, Nov 21, 2017 at 6:04 AM, Patrick Ohly  > wrote:
> > On Thu, 2017-02-09 at 21:38 +0200, Jussi Kukkonen wrote:
> > There is https://bugzilla.yoctoproject.org/show_bug.cgi?id=9883
> > open
> > about some aspect of this, but it doesn't actually address the
> > underlying question about what the right behavior should be. It's
> > based
> > on the assumption that libcurl-native should always use ca-
> > certificates-native.
> > 
> > Thoughts anyone?
> 
> I agree it should use ca-certificates-native for all native; it
> allows for self-signed internal certificates to be added for internal
> development.

But that's not what bitbake itself uses. Are you saying that bitbake
fetchers etc. should also use whatever certificates are configured for
ca-certificates-native? That leads to a chicken-and-egg problem.

A solution where custom certificates need to be configured in two
different places (system for bitbake, ca-certificates-native for some
other tools) sounds sub-optimal to me.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.


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

Re: [OE-core] native CA cert bundles (was: Re: [PATCH 3/3] cve-check-tool: Use CA cert bundle in correct sysroot)

[Otavio Salvador]

On Tue, Nov 21, 2017 at 6:04 AM, Patrick Ohly  wrote:
> On Thu, 2017-02-09 at 21:38 +0200, Jussi Kukkonen wrote:
> There is https://bugzilla.yoctoproject.org/show_bug.cgi?id=9883 open
> about some aspect of this, but it doesn't actually address the
> underlying question about what the right behavior should be. It's based
> on the assumption that libcurl-native should always use ca-
> certificates-native.
>
> Thoughts anyone?

I agree it should use ca-certificates-native for all native; it allows
for self-signed internal certificates to be added for internal
development.

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

Re: [OE-core] [RFC][PATCH 0/5] Kernel artifacts naming changes

[Otavio Salvador]

Hello Martin,

On Mon, Nov 20, 2017 at 6:11 PM, Martin Jansa  wrote:
...
> This RFC doesn't implement it all, but it makes naming all the artifacts in
> consistent way a bit easier. If there is an agreement that OE should support
> the naming scenario described above, I'll submit the rest of the changes.

I think it all makes sense and if we preserve current behavior as
default I see it as a very good addition :-)

I didn't test the patches myself and I'd like to do a more extensive
test once you send the full patchset.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +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 1/3] systemd: fix formatting IDE storage does not trigger "change" uevents

[Burton, Ross]

On 21 November 2017 at 07:00, Hongxu Jia  wrote:

> 1. Tweak kernel-cache to remove CONFIG_IDE for all available bsp.
> It require necessary test to prove it is safe to remove it.
> If the test is OK, I will send patch to yocto mailing list.
>

I know you have your own huge autobuilder framework inside WR but I'll
happily throw a patch against oe-core at the public autobuilders for extra
testing.

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

Re: [OE-core] Yocto Project Status WW47’17

[Burton, Ross]

On 21 November 2017 at 11:09, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> > > o   Issues with 4.13.10 host kernels booting kvm x86 guests on
> > > Tumbleweed (Suse) and Fedora 26 (attempting to see if 4.13.12
> > > helps)
> >
> > Robert, can you test Fedora 26. It would help to have a defect open
> > with steps to reproduce or
> > something about the typical workflow/ build time/ day of the week/
> > phase of the moon.
>
> FWIW we have noticed that the choice of kernel timers seems to vary in
> the x86_64 boots but not with a pattern that matches the hangs.



Also of note is that last week the cluster was hitting this once in every
nightly run, but after a complete reboot and kernel upgrade we haven't seen
it so far.  So either it's gone with the latest kernels, or it's a slow
accumulation of non-movable memory that eventually breaks kvm (my money is
on the latter).


> > > o   a perf build race (bug 12302)
> >   I'll take a look to:
> >  - see if I can duplicate the bug on a fast build host
> >  - check upstream to see if the bug is known/fixed
> >  - see if I can spot a race in the build rules.
>
> Sounds good, thanks!


It looks and sounds like a classic makefile dependency bug, should be
reproducible on demand with careful explicit target steps.  The perf
makefiles are not exactly easy to hack though...

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

Re: [OE-core] [PATCH 2/2] image.bbclass: improve reproducibility

[Maxin B. John]

Hi Ross,

On Tue, Nov 21, 2017 at 10:59:49AM +, Burton, Ross wrote:
>I think this is to blame for a slew of failures on the autobuilder:

Sorry for that. Please revert it.

>http://errors.yoctoproject.org/Errors/Latest/?filter=57ddf212e64207edfbd813d32ca3a15f6c1c8211=commit
>
>Such as:
>
>NOTE: FAIL [0.616s]: test_df (df.DfTest)
>NOTE: --
>NOTE: Traceback (most recent call last):
>File 
>"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-mips-lsb/build/meta/lib/oeqa/core/decorator/__init__.py",
> line 32, in wrapped_f
> return func(*args, **kwargs)
> File 
> "/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-mips-lsb/build/meta/lib/oeqa/core/decorator/__init__.py",
>  line 32, in wrapped_f
> return func(*args, **kwargs)
> File 
> "/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-mips-lsb/build/meta/lib/oeqa/runtime/cases/df.py",
>  line 13, in test_df
> self.assertTrue(int(output)>5120, msg=msg)
> AssertionError: False is not true : Not enough space on image. Current size 
> is 0
>
>Ross

I will check what went wrong there.

>On 16 November 2017 at 15:56, Maxin B. John  wrote:
>>
>> Improve reproducibility of builds by adding --apparent-size to du -ks in
>> get_rootfs_size
>>
>> [YOCTO #12235]

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

Re: [OE-core] Yocto Project Status WW47’17

[Richard Purdie]

On Mon, 2017-11-20 at 20:22 -0500, Randy MacLeod wrote:
> On 2017-11-20 10:36 AM, Jolley, Stephen K wrote:
> > Current Dev Position: YP 2.5 Planning and M1 development
> > Next Deadline: YP 2.5 M1 cut off of 12/4/17
> >  
> > SWAT team rotation: Juro -> Paul on Nov.17, 2017.
> > SWAT team rotation: Paul -> Todor on Nov. 24, 2017.
> > https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team
> >  
> > Key Status/Updates:
> > ·    There is no real change to the status from last week. We
> > continue to suffer intermittent build failures and are continuing
> > to attempt to debug these.
> > ·    Currently open issues are:
>  
> Some US-based people may be on holiday later this week so I'm
> offering 
> help from the frozen Northland and more importantly from the team in
> Beijing. ;-)
> 
> > o   qemuppc continues to demonstrate random hangs in boot  in
> > userspace
>  
> Is we can create a defect for this and point / copy the wiki notes
> into it, that
> would help.
>    https://wiki.yoctoproject.org/wiki/Qemuppc_Boot_Hangs
> 
> I think I had asked Chi to see if he could reproduce this a week or
> two ago.
> When the lack of entropy problem was identified and fix, many people
> thought
> this hang went away as well. Chi can you read the wiki report and see
> if you
> can add anything to them?

Good news is that the qemuppc issue has been identified as a bug in
qemu ppc locking which breaks timer interrupt handling. I've posted on
the qemu mailing list asking for help in verifying what I think is
happening.

I have a patch ready to merge which should address this one, just
cleaning up my environment and doing some further stress testing.

[There is a defect somewhere for this btw, I created the wiki as it was
a better place to dump and update information as we learnt what it
is/is not without having to follow a train of thought updating in the
bugzilla].

> > o   Issues with 4.13.10 host kernels booting kvm x86 guests on
> > Tumbleweed (Suse) and Fedora 26 (attempting to see if 4.13.12
> > helps)
>  
> Robert, can you test Fedora 26. It would help to have a defect open
> with steps to reproduce or
> something about the typical workflow/ build time/ day of the week/
> phase of the moon. 

FWIW we have noticed that the choice of kernel timers seems to vary in
the x86_64 boots but not with a pattern that matches the hangs.

> > o   nfs inode count for the sstate/dldir share appears to break
> > periodically causing the disk monitor to halt the builds (bug
> > 12267)
>  
> Likely specific to the AB server so no plans to do anything for this
> bug.

Agreed, this one is our infrastructure somehow :(. We have a workaround
in -next for this at least.

> > o   a perf build race (bug 12302)
>   I'll take a look to:
>  - see if I can duplicate the bug on a fast build host
>  - check upstream to see if the bug is known/fixed
>  - see if I can spot a race in the build rules.

Sounds good, thanks!

> > o   An ext filesystem creation/sizing issue (bug 12304)
>  
> Saul, Are you around this week? Do you have any additional
> information before
> leaving for Thanksgiving?
> 
> Jackie, 
> Can you look at the code around the image creation and try to
> reproduce this one?

Saul hasn't been able to reproduce. I've asked at the minimum we add
better logging so if/when this happens again, we can debug it properly
next time. I did also wonder about fuzzing the image size code, writing
some code which puts in all possible input values and checks the sanity
of the resulting image size. Its the kind of problem a computer can
probably brute force. Anyone interested in trying that?

Cheers,

Richard


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

Re: [OE-core] [PATCH 2/2] image.bbclass: improve reproducibility

[Burton, Ross]

I think this is to blame for a slew of failures on the autobuilder:

http://errors.yoctoproject.org/Errors/Latest/?filter=57ddf212e64207edfbd813d32ca3a15f6c1c8211=commit

Such as:

NOTE: FAIL [0.616s]: test_df (df.DfTest)
NOTE: --
NOTE: Traceback (most recent call last):
  File
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-mips-lsb/build/meta/lib/oeqa/core/decorator/__init__.py",
line 32, in wrapped_f
return func(*args, **kwargs)
  File
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-mips-lsb/build/meta/lib/oeqa/core/decorator/__init__.py",
line 32, in wrapped_f
return func(*args, **kwargs)
  File
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-mips-lsb/build/meta/lib/oeqa/runtime/cases/df.py",
line 13, in test_df
self.assertTrue(int(output)>5120, msg=msg)
AssertionError: False is not true : Not enough space on image. Current size
is 0

Ross

On 16 November 2017 at 15:56, Maxin B. John  wrote:
>
> Improve reproducibility of builds by adding --apparent-size to du -ks in
> get_rootfs_size
>
> [YOCTO #12235]
>
> Signed-off-by: Maxin B. John 
> ---
>  meta/classes/image.bbclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> index 0d14250..a24a561 100644
> --- a/meta/classes/image.bbclass
> +++ b/meta/classes/image.bbclass
> @@ -524,7 +524,7 @@ def get_rootfs_size(d):
>  initramfs_fstypes = d.getVar('INITRAMFS_FSTYPES') or ''
>  initramfs_maxsize = d.getVar('INITRAMFS_MAXSIZE')
>
> -output = subprocess.check_output(['du', '-ks',
> +output = subprocess.check_output(['du', '--apparent-size', '-ks',
>d.getVar('IMAGE_ROOTFS')])
>  size_kb = int(output.split()[0])
>  base_size = size_kb * overhead_factor
> --
> 2.4.0
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v7 00/15] support profile-optimized build for Python

[Markus Lehtonen]

Seventh version of the patchset making it possible to do
profile-guided-optimization for Python 3.

Changes since v6:
- fixed a typo (Utream-Status -> Upstream-Status) in openssh patch
- changes to python-3.5-manifest.inc now done properly by using
  scripts/contrib/python/generate-manifest-3.5.py


The following changes since commit a17f3ec910366e9e7551fa24fbc07929b9584341:

  dhcp: fix build issue with libxml2 support (2017-11-10 14:44:31 +)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib marquiz/fixes-9338
  
http://cgit.openembedded.org/openembedded-core-contrib/log/?h=marquiz/fixes-9338

Markus Lehtonen (15):
  python3-native: support profile optimized build
  python3: fix depends of python3-tests
  python3: add python3-profile-opt recipe
  python3-profile-opt: rename libpython3
  openssh: extend to -native
  libmnl: enable native
  iptables: enable native
  iproute2: enable native
  oeqa/targetcontrol: re-introduce get_target_controller()
  oeqa/targetcontrol: add missing arg to SimpleRemoteTarget.__init__
  devtools/images: add python-pgo-image
  python3: support profile optimized build
  python3: fix profile-optimized build of modules
  python3: add python3-tools subpackage
  python3: remove two setup.py cross-compile hacks

 meta/lib/oeqa/targetcontrol.py |  29 +-
 meta/recipes-connectivity/iproute2/iproute2.inc|   7 +-
 ...1-don-t-use-absolute-path-for-ssh-program.patch |  31 ++
 meta/recipes-connectivity/openssh/openssh_7.6p1.bb |   7 +-
 meta/recipes-devtools/images/python-pgo-image.bb   |  92 ++
 .../python/python-3.5-manifest.inc |  12 ++-
 .../python/python3-native_3.5.3.bb |   9 ++
 meta/recipes-devtools/python/python3-profile-opt   |   1 +
 .../python/python3-profile-opt_3.5.3.bb|  10 ++
 .../python3/0001-cross-compile-support.patch   |   9 --
 ...efile-add-install_generate_profile-target.patch |  25 +
 ...-CFLAGS-for-extensions-when-cross-compili.patch |  56 +++
 .../python3-setup.py-no-host-headers-libs.patch|  33 ---
 ...name-libpython3-to-libpython-profile-opt3.patch | 108 +
 .../setup.py-find-libraries-in-staging-dirs.patch  |  30 --
 meta/recipes-devtools/python/python3_3.5.3.bb  |  58 ---
 ...revent-absolute-path-in-installed-symlink.patch |  29 ++
 meta/recipes-extended/iptables/iptables_1.6.1.bb   |   3 +
 meta/recipes-extended/libmnl/libmnl_1.0.4.bb   |   2 +
 scripts/contrib/python/generate-manifest-3.5.py|   5 +-
 20 files changed, 459 insertions(+), 97 deletions(-)
 create mode 100644 
meta/recipes-connectivity/openssh/openssh/0001-don-t-use-absolute-path-for-ssh-program.patch
 create mode 100644 meta/recipes-devtools/images/python-pgo-image.bb
 create mode 12 meta/recipes-devtools/python/python3-profile-opt
 create mode 100644 meta/recipes-devtools/python/python3-profile-opt_3.5.3.bb
 create mode 100644 
meta/recipes-devtools/python/python3/Makefile-add-install_generate_profile-target.patch
 create mode 100644 
meta/recipes-devtools/python/python3/Use-correct-CFLAGS-for-extensions-when-cross-compili.patch
 delete mode 100644 
meta/recipes-devtools/python/python3/python3-setup.py-no-host-headers-libs.patch
 create mode 100644 
meta/recipes-devtools/python/python3/rename-libpython3-to-libpython-profile-opt3.patch
 delete mode 100644 
meta/recipes-devtools/python/python3/setup.py-find-libraries-in-staging-dirs.patch
 create mode 100644 
meta/recipes-extended/iptables/iptables/prevent-absolute-path-in-installed-symlink.patch

-- 
2.13.6

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

[OE-core] [PATCH] glibc/gcc/libgcc-initial: Reimplement "deltask do_build"

[mingli.yu]

From: Mingli Yu 

Previously, "deltask do_build" can result in the
dependency of do_build lost and can trigger a
race condition error as below when do_rm_work
is enabled.
=
NOTE: recipe glibc-initial-2.26-r0: task do_fetch: Failed
ERROR: glibc-initial-2.26-r0 do_fetch: Function failed: extend_recipe_sysroot
The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: 
 0001:
 *** 0002:extend_recipe_sysroot(d)
 0003:
File: '$Prj/layers/oe-core/meta/classes/staging.bbclass', lineno: 410, 
function: extend_recipe_sysroot
 0406:manifests = {}
 0407:# All files that we're going to be installing, to find conflicts.
 0408:fileset = {}
 0409:
 *** 0410:for f in os.listdir(depdir):
 0411:if not f.endswith(".complete"):
 0412:continue
 0413:f = depdir + "/" + f
 0414:if os.path.islink(f) and not os.path.exists(f):
Exception: FileNotFoundError: [Errno 2] No such file or directory: 
'$Prj/build/tmp-glibc/work/cortexa8hf-neon-wrs-linux-gnueabi/glibc-initial/2.26-r0/recipe-sysroot-native/installeddeps'
=

Rewrite the implementation of "deltask do_build" to save
the dependency before deleting do_build task to avoid the
race condition.

[YOCTO #12365]

Signed-off-by: Mingli Yu 
---
 meta/recipes-core/glibc/glibc-initial.inc   | 6 +-
 meta/recipes-devtools/gcc/gcc-cross-initial.inc | 6 +-
 meta/recipes-devtools/gcc/libgcc-initial.inc| 6 +-
 3 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-core/glibc/glibc-initial.inc 
b/meta/recipes-core/glibc/glibc-initial.inc
index b86e2fb2db..0dc32092a9 100644
--- a/meta/recipes-core/glibc/glibc-initial.inc
+++ b/meta/recipes-core/glibc/glibc-initial.inc
@@ -54,4 +54,8 @@ do_siteconfig () {
 inherit nopackages
 
 # We really only want this built by things that need it, not any recrdeptask
-deltask do_build
+python () {
+if bb.data.inherits_class('rm_work', d):
+bb.build.exec_func("inject_rm_work", d)
+bb.build.deltask('do_build', d)
+}
diff --git a/meta/recipes-devtools/gcc/gcc-cross-initial.inc 
b/meta/recipes-devtools/gcc/gcc-cross-initial.inc
index 892b1dbf2f..55e22f62d3 100644
--- a/meta/recipes-devtools/gcc/gcc-cross-initial.inc
+++ b/meta/recipes-devtools/gcc/gcc-cross-initial.inc
@@ -86,4 +86,8 @@ COMPILERINITIAL = "-initial"
 
 
 # We really only want this built by things that need it, not any recrdeptask
-deltask do_build
+python () {
+if bb.data.inherits_class('rm_work', d):
+bb.build.exec_func("inject_rm_work", d)
+bb.build.deltask('do_build', d)
+}
diff --git a/meta/recipes-devtools/gcc/libgcc-initial.inc 
b/meta/recipes-devtools/gcc/libgcc-initial.inc
index 950ad861e7..4c45b9a801 100644
--- a/meta/recipes-devtools/gcc/libgcc-initial.inc
+++ b/meta/recipes-devtools/gcc/libgcc-initial.inc
@@ -17,4 +17,8 @@ COMPILERINITIAL = "-initial"
 inherit nopackages
 
 # We really only want this built by things that need it, not any recrdeptask
-deltask do_build
+python () {
+if bb.data.inherits_class('rm_work', d):
+bb.build.exec_func("inject_rm_work", d)
+bb.build.deltask('do_build', d)
+}
-- 
2.13.3

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

Re: [OE-core] [PATCH] glibc/gcc/libgcc-initial: Reimplement "deltask do_build"

[Yu, Mingli]

Please ignore this patch as the indentation is TAB, will send V2 to use 
four space as indentation.


Thanks,
Mingli

On 2017年11月21日 16:00, mingli...@windriver.com wrote:

From: Mingli Yu 

Previously, "deltask do_build" can result in the
dependency of do_build lost and can trigger a
race condition error as below when do_rm_work
is enabled.
=
NOTE: recipe glibc-initial-2.26-r0: task do_fetch: Failed
ERROR: glibc-initial-2.26-r0 do_fetch: Function failed: extend_recipe_sysroot
The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: 
  0001:
  *** 0002:extend_recipe_sysroot(d)
  0003:
File: '$Prj/layers/oe-core/meta/classes/staging.bbclass', lineno: 410, 
function: extend_recipe_sysroot
  0406:manifests = {}
  0407:# All files that we're going to be installing, to find conflicts.
  0408:fileset = {}
  0409:
  *** 0410:for f in os.listdir(depdir):
  0411:if not f.endswith(".complete"):
  0412:continue
  0413:f = depdir + "/" + f
  0414:if os.path.islink(f) and not os.path.exists(f):
Exception: FileNotFoundError: [Errno 2] No such file or directory: 
'$Prj/build/tmp-glibc/work/cortexa8hf-neon-wrs-linux-gnueabi/glibc-initial/2.26-r0/recipe-sysroot-native/installeddeps'
=

Rewrite the implementation of "deltask do_build" to save
the dependency before deleting do_build task to avoid the
race condition.

[YOCTO #12365]

Signed-off-by: Mingli Yu 
---
  meta/recipes-core/glibc/glibc-initial.inc   | 6 +-
  meta/recipes-devtools/gcc/gcc-cross-initial.inc | 6 +-
  meta/recipes-devtools/gcc/libgcc-initial.inc| 6 +-
  3 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-core/glibc/glibc-initial.inc 
b/meta/recipes-core/glibc/glibc-initial.inc
index b86e2fb2db..4390b6dfca 100644
--- a/meta/recipes-core/glibc/glibc-initial.inc
+++ b/meta/recipes-core/glibc/glibc-initial.inc
@@ -54,4 +54,8 @@ do_siteconfig () {
  inherit nopackages

  # We really only want this built by things that need it, not any recrdeptask
-deltask do_build
+python () {
+   if bb.data.inherits_class('rm_work', d):
+   bb.build.exec_func("inject_rm_work", d)
+   bb.build.deltask('do_build', d)
+}
diff --git a/meta/recipes-devtools/gcc/gcc-cross-initial.inc 
b/meta/recipes-devtools/gcc/gcc-cross-initial.inc
index 892b1dbf2f..6c0b2eff86 100644
--- a/meta/recipes-devtools/gcc/gcc-cross-initial.inc
+++ b/meta/recipes-devtools/gcc/gcc-cross-initial.inc
@@ -86,4 +86,8 @@ COMPILERINITIAL = "-initial"


  # We really only want this built by things that need it, not any recrdeptask
-deltask do_build
+python () {
+   if bb.data.inherits_class('rm_work', d):
+   bb.build.exec_func("inject_rm_work", d)
+   bb.build.deltask('do_build', d)
+}
diff --git a/meta/recipes-devtools/gcc/libgcc-initial.inc 
b/meta/recipes-devtools/gcc/libgcc-initial.inc
index 950ad861e7..cef8257052 100644
--- a/meta/recipes-devtools/gcc/libgcc-initial.inc
+++ b/meta/recipes-devtools/gcc/libgcc-initial.inc
@@ -17,4 +17,8 @@ COMPILERINITIAL = "-initial"
  inherit nopackages

  # We really only want this built by things that need it, not any recrdeptask
-deltask do_build
+python () {
+   if bb.data.inherits_class('rm_work', d):
+   bb.build.exec_func("inject_rm_work", d)
+   bb.build.deltask('do_build', d)
+}


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

[OE-core] [PATCH] glibc/gcc/libgcc-initial: Reimplement "deltask do_build"

[mingli.yu]

From: Mingli Yu 

Previously, "deltask do_build" can result in the
dependency of do_build lost and can trigger a
race condition error as below when do_rm_work
is enabled.
=
NOTE: recipe glibc-initial-2.26-r0: task do_fetch: Failed
ERROR: glibc-initial-2.26-r0 do_fetch: Function failed: extend_recipe_sysroot
The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: 
 0001:
 *** 0002:extend_recipe_sysroot(d)
 0003:
File: '$Prj/layers/oe-core/meta/classes/staging.bbclass', lineno: 410, 
function: extend_recipe_sysroot
 0406:manifests = {}
 0407:# All files that we're going to be installing, to find conflicts.
 0408:fileset = {}
 0409:
 *** 0410:for f in os.listdir(depdir):
 0411:if not f.endswith(".complete"):
 0412:continue
 0413:f = depdir + "/" + f
 0414:if os.path.islink(f) and not os.path.exists(f):
Exception: FileNotFoundError: [Errno 2] No such file or directory: 
'$Prj/build/tmp-glibc/work/cortexa8hf-neon-wrs-linux-gnueabi/glibc-initial/2.26-r0/recipe-sysroot-native/installeddeps'
=

Rewrite the implementation of "deltask do_build" to save
the dependency before deleting do_build task to avoid the
race condition.

[YOCTO #12365]

Signed-off-by: Mingli Yu 
---
 meta/recipes-core/glibc/glibc-initial.inc   | 6 +-
 meta/recipes-devtools/gcc/gcc-cross-initial.inc | 6 +-
 meta/recipes-devtools/gcc/libgcc-initial.inc| 6 +-
 3 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-core/glibc/glibc-initial.inc 
b/meta/recipes-core/glibc/glibc-initial.inc
index b86e2fb2db..4390b6dfca 100644
--- a/meta/recipes-core/glibc/glibc-initial.inc
+++ b/meta/recipes-core/glibc/glibc-initial.inc
@@ -54,4 +54,8 @@ do_siteconfig () {
 inherit nopackages
 
 # We really only want this built by things that need it, not any recrdeptask
-deltask do_build
+python () {
+   if bb.data.inherits_class('rm_work', d):
+   bb.build.exec_func("inject_rm_work", d)
+   bb.build.deltask('do_build', d)
+}
diff --git a/meta/recipes-devtools/gcc/gcc-cross-initial.inc 
b/meta/recipes-devtools/gcc/gcc-cross-initial.inc
index 892b1dbf2f..6c0b2eff86 100644
--- a/meta/recipes-devtools/gcc/gcc-cross-initial.inc
+++ b/meta/recipes-devtools/gcc/gcc-cross-initial.inc
@@ -86,4 +86,8 @@ COMPILERINITIAL = "-initial"
 
 
 # We really only want this built by things that need it, not any recrdeptask
-deltask do_build
+python () {
+   if bb.data.inherits_class('rm_work', d):
+   bb.build.exec_func("inject_rm_work", d)
+   bb.build.deltask('do_build', d)
+}
diff --git a/meta/recipes-devtools/gcc/libgcc-initial.inc 
b/meta/recipes-devtools/gcc/libgcc-initial.inc
index 950ad861e7..cef8257052 100644
--- a/meta/recipes-devtools/gcc/libgcc-initial.inc
+++ b/meta/recipes-devtools/gcc/libgcc-initial.inc
@@ -17,4 +17,8 @@ COMPILERINITIAL = "-initial"
 inherit nopackages
 
 # We really only want this built by things that need it, not any recrdeptask
-deltask do_build
+python () {
+   if bb.data.inherits_class('rm_work', d):
+   bb.build.exec_func("inject_rm_work", d)
+   bb.build.deltask('do_build', d)
+}
-- 
2.13.3

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

[OE-core] native CA cert bundles (was: Re: [PATCH 3/3] cve-check-tool: Use CA cert bundle in correct sysroot)

[Patrick Ohly]

On Thu, 2017-02-09 at 21:38 +0200, Jussi Kukkonen wrote:
> Native libcurl looks for CA certs in the wrong place by
> default.
> * Add patch that allows overriding the default CA certificate
>   location. Patch is originally from meta-security-isafw.
> * Use the new --cacert to set the correct CA bundle path
> 
> Signed-off-by: Jussi Kukkonen 
> ---
>  .../cve-check-tool/cve-check-tool_5.6.4.bb |   4 +-
>  ...ow-overriding-default-CA-certificate-file.patch | 215
> +
>  2 files changed, 218 insertions(+), 1 deletion(-)
>  create mode 100644 meta/recipes-devtools/cve-check-tool/files/0001-
> curl-allow-overriding-default-CA-certificate-file.patch
> 
> diff --git a/meta/recipes-devtools/cve-check-tool/cve-check-
> tool_5.6.4.bb b/meta/recipes-devtools/cve-check-tool/cve-check-
> tool_5.6.4.bb
> index c78af67..fcd3182 100644
> --- a/meta/recipes-devtools/cve-check-tool/cve-check-tool_5.6.4.bb
> +++ b/meta/recipes-devtools/cve-check-tool/cve-check-tool_5.6.4.bb
> @@ -9,6 +9,7 @@ LIC_FILES_CHKSUM = "file://LICENSE;md5=e8c1458438ead3
> c34974bc0be3a03ed6"
>  SRC_URI = "https://github.com/ikeydoherty/${BPN}/releases/download/v
> ${PV}/${BP}.tar.xz \
> file://check-for-malloc_trim-before-using-it.patch \
> file://0001-print-progress-in-percent-when-downloading-
> CVE-db.patch \
> +   file://0001-curl-allow-overriding-default-CA-certificate-
> file.patch \
>    "
>  
>  SRC_URI[md5sum] = "c5f4247140fc9be3bf41491d31a34155"
> @@ -39,7 +40,8 @@ do_populate_cve_db() {
>  [ -z "${cve_file}" ] && cve_file="${TMPDIR}/cve_check"
>  
>  bbdebug 2 "Updating cve-check-tool database located in $cve_dir"
> -if cve-check-update -d "$cve_dir" ; then
> +# --cacert works around curl-native not finding the CA bundle
> +if cve-check-update --cacert ${sysconfdir}/ssl/certs/ca-
> certificates.crt -d "$cve_dir" ; then

I went back to this patch to see how the problem was solved, because I
am facing it again elsewhere. Now that I think about it again, I'm
starting to wonder which SSL certificates the native tools really
should trust. Tools like Python or  wget are taken from the host, which
means they use the host defaults for SSL. That native tools built with
bitbake then try to use ca-certificates-native looks inconsistent to
me.

There is https://bugzilla.yoctoproject.org/show_bug.cgi?id=9883 open
about some aspect of this, but it doesn't actually address the
underlying question about what the right behavior should be. It's based
on the assumption that libcurl-native should always use ca-
certificates-native.

Thoughts anyone?

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.


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