Re: [OE-core] [PATCH 1/1] runqemu: fix handling of SIGTERM and the problem of line wrapping

[ChenQi]

On 09/21/2018 11:05 PM, Burton, Ross wrote:

Is there a good reason why shell=True is used in the first place?
Just change the cmd to a list, stop passing shell=True, and you don't
need to dance around process groups.


Thanks for your suggestion. I'll send out V2 if all things go well with 
my local testings.


Best Regards,
Chen Qi


Ross
On Fri, 21 Sep 2018 at 03:30, Chen Qi  wrote:

The current handling of SIGTERM is incorrect as the process pid returned
by Popen call with shell setting to True is actualy the shell instead of
the qemu binary. So fix to send SIGTERM to the process group of runqemu.
This ensures that all processes in the same process group, including the
shell and the qemu process, will receive SIGTERM.

Also, as we install a SIGTERM handler, we need handle the situation of
qemu terminated by SIGTERM, otherwise we will get ERROR message in such
case.

Besides, we have a problem that after running qemu, the terminal's behavior
is incorrect regarding long lines or long commands. Long commands or long
outputs should appear in multiple lines, but they appear in the same line,
overriding previous output. Use `tput smam' to fix this problem.

Signed-off-by: Chen Qi 
---
  scripts/runqemu | 14 ++
  1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/scripts/runqemu b/scripts/runqemu
index 409d17c..bc2aba5 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -1213,9 +1213,12 @@ class BaseConfig(object):
  cmd = "%s %s" % (self.qemu_opt, kernel_opts)
  logger.info('Running %s\n' % cmd)
  process = subprocess.Popen(cmd, shell=True, stderr=subprocess.PIPE)
-self.qemupid = process.pid
-if process.wait():
-logger.error("Failed to run qemu: %s", 
process.stderr.read().decode())
+retcode = process.wait()
+if retcode:
+if retcode == -signal.SIGTERM:
+logger.info("Qemu terminated by SIGTERM")
+else:
+logger.error("Failed to run qemu: %s", 
process.stderr.read().decode())

  def cleanup(self):
  if self.cleaned:
@@ -1308,8 +1311,10 @@ def main():

  def sigterm_handler(signum, frame):
  logger.info("SIGTERM received")
-os.kill(config.qemupid, signal.SIGTERM)
+signal.signal(signal.SIGTERM, signal.SIG_IGN)
+os.kill(0, signal.SIGTERM)
  config.cleanup()
+subprocess.run(["tput", "smam"])
  signal.signal(signal.SIGTERM, sigterm_handler)

  config.check_args()
@@ -1331,6 +1336,7 @@ def main():
  return 1
  finally:
  config.cleanup()
+subprocess.run(["tput", "smam"])

  if __name__ == "__main__":
  sys.exit(main())
--
1.9.1

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



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

Re: [OE-core] [PATCH] wic:mkefidisk:add use-uuid for all partitions

[Lu.Jiang]

Hi Richard,
The patch is revied by Tom, can you help merge this patch?

Thanks
Jiang Lu

在 2018年09月07日 19:56, Tom Rini 写道:

On Fri, Sep 07, 2018 at 11:32:11AM +0800, Jiang Lu wrote:


Add use-uuid for all partitions on mkefidisk.wks.

Signed-off-by: Jiang Lu 

Reviewed-by: Tom Rini 



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

[OE-core] [PATCH] bash: 4.4.18 -> 4.4.23

[Jeroen Hofstee]

Signed-off-by: Jeroen Hofstee 
---
 meta/recipes-extended/bash/bash_4.4.18.bb | 16 
 1 file changed, 16 insertions(+)

diff --git a/meta/recipes-extended/bash/bash_4.4.18.bb 
b/meta/recipes-extended/bash/bash_4.4.18.bb
index b338acd..8fa0978 100644
--- a/meta/recipes-extended/bash/bash_4.4.18.bb
+++ b/meta/recipes-extended/bash/bash_4.4.18.bb
@@ -5,6 +5,11 @@ LICENSE = "GPLv3+"
 LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
 
 SRC_URI = "${GNU_MIRROR}/bash/${BP}.tar.gz;name=tarball \
+   
${GNU_MIRROR}/bash/bash-4.4-patches/bash44-019;apply=yes;striplevel=0;name=patch019
 \
+   
${GNU_MIRROR}/bash/bash-4.4-patches/bash44-020;apply=yes;striplevel=0;name=patch020
 \
+   
${GNU_MIRROR}/bash/bash-4.4-patches/bash44-021;apply=yes;striplevel=0;name=patch021
 \
+   
${GNU_MIRROR}/bash/bash-4.4-patches/bash44-022;apply=yes;striplevel=0;name=patch022
 \
+   
${GNU_MIRROR}/bash/bash-4.4-patches/bash44-023;apply=yes;striplevel=0;name=patch023
 \
file://execute_cmd.patch;striplevel=0 \
file://mkbuiltins_have_stringize.patch \
file://build-tests.patch \
@@ -19,6 +24,17 @@ SRC_URI = "${GNU_MIRROR}/bash/${BP}.tar.gz;name=tarball \
 SRC_URI[tarball.md5sum] = "518e2c187cc11a17040f0915dddce54e"
 SRC_URI[tarball.sha256sum] = 
"604d9eec5e4ed5fd2180ee44dd756ddca92e0b6aa4217bbab2b6227380317f23"
 
+SRC_URI[patch019.md5sum] = "8f43e1d277b02f3319a34c1cd4a4ff3e"
+SRC_URI[patch019.sha256sum] = 
"27170d6edfe8819835407fdc08b401d2e161b1400fe9d0c5317a51104c89c11e"
+SRC_URI[patch020.md5sum] = "5217ff08c46ec306dce60437c288"
+SRC_URI[patch020.sha256sum] = 
"1840e2cbf26ba822913662f74037594ed562361485390c52813b38156c99522c"
+SRC_URI[patch021.md5sum] = "282c7d9b38da8005d25b4f816328a2f4"
+SRC_URI[patch021.sha256sum] = 
"bd8f59054a763ec1c64179ad5cb607f558708a317c2bdb22b814e3da456374c1"
+SRC_URI[patch022.md5sum] = "0b709c9d7f8e6cf267a8b863efb899f7"
+SRC_URI[patch022.sha256sum] = 
"45331f0936e36ab91bfe44b936e33ed8a1b1848fa896e8a1d0f2ef74f297cb79"
+SRC_URI[patch023.md5sum] = "fe2e0ca4cf9409ff0e9428e1236f983e"
+SRC_URI[patch023.sha256sum] = 
"4fec236f3fbd3d0c47b893fdfa9122142a474f6ef66c20ffb6c0f4864dd591b6"
+
 DEBUG_OPTIMIZATION_append_armv4 = " ${@bb.utils.contains('TUNE_CCARGS', 
'-mthumb', '-fomit-frame-pointer', '', d)}"
 DEBUG_OPTIMIZATION_append_armv5 = " ${@bb.utils.contains('TUNE_CCARGS', 
'-mthumb', '-fomit-frame-pointer', '', d)}"
 
-- 
2.7.4

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

[OE-core] [PATCH] scripts/autobuilder-worker-prereq-tests: Add to todo list

[Richard Purdie]

Note further tests needed after encountering issues.

Signed-off-by: Richard Purdie 
---
 scripts/autobuilder-worker-prereq-tests | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/scripts/autobuilder-worker-prereq-tests 
b/scripts/autobuilder-worker-prereq-tests
index e65071b227f..c0148fbce88 100755
--- a/scripts/autobuilder-worker-prereq-tests
+++ b/scripts/autobuilder-worker-prereq-tests
@@ -10,6 +10,9 @@
 # Add python3-git test
 # Add pigz test
 # vnc tests/checkvnc?
+# test sendmail works (for QA email notification)
+# test error report submission works
+# test buildistory git repo works?
 #
 
 . ./oe-init-build-env > /dev/null
-- 
2.17.1

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

[OE-core] python-sqlite3 packaging

[Jeroen Hofstee]

Hello,

Not sure where to report this, so trying here. It seems the
/usr/lib/python2.7/sqlite3 ends up in the python-misc and not
in python-sqlite3.

This causes statements like:

import sqlite3

To error with ImportError: No module named sqlite3, when
python-misc is not installed.

It looks like the python2-manifest should at least include the
__init__.py, but the logs suggest the manifest is generated.

Perhaps it is easier if someone who knows more about this
looks into it..

Regards,

Jeroen

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

Re: [OE-core] [oe-commits] [openembedded-core] 02/45: fribidi: use Meson instead of autotools

[Khem Raj]

Ross

I am seeing some extra fails which could be related to your proposed changes

http://errors.yoctoproject.org/Errors/Build/68805/

see the first three
On Mon, Sep 24, 2018 at 12:28 PM Burton, Ross  wrote:
>
> Turns out that fix promptly breaks something else...
>
> Digging into Meson today and trying to fix some target/host confusion.
>
> Ross
> On Mon, 24 Sep 2018 at 19:58, Khem Raj  wrote:
> >
> > On Mon, Sep 24, 2018 at 4:10 AM Burton, Ross  wrote:
> > >
> > > I can't seem to replicate this on our centos7 box:
> > >
> > > [ross@centos7 build]$ gcc --version
> > > gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28)
> > > [ross@centos7 build]$ gcc -ffdjsj
> > > gcc: error: unrecognized command line option ‘-ffdjsj’
> > > gcc: fatal error: no input files
> > > compilation terminated.
> > > [ross@centos7 build]$ gcc -fstack-protector-strong
> > > gcc: fatal error: no input files
> > > compilation terminated.
> > >
> > > Presumably we've upgraded gcc at some point...
> > >
> > > However I did replicate the same sort of problem outside of OE.  Can
> > > one of you test
> > > http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=ross/mut=1e32317ad77457d2a026eaa67ea7c6eebe58b127
> > > for me please?
> > >
> >
> > this solves the issue, thanks for prompt turnaround for fixing it
> >
> > > Cheers,
> > > Ross
> > > On Mon, 24 Sep 2018 at 11:08, Burton, Ross  wrote:
> > > >
> > > > Looks like Meson is using the target link flags for linking even when
> > > > it knows its doing a native build.  Talking to Meson upstream now and
> > > > have a workaround.
> > > >
> > > > Ross
> > > > On Sun, 23 Sep 2018 at 15:51, Khem Raj  wrote:
> > > > >
> > > > > On Sun, Sep 23, 2018 at 2:20 AM Martin Jansa  
> > > > > wrote:
> > > > > >
> > > > > > Was this one ever sent to ML? I haven't found it in the archives.
> > > > > >
> > > > > > With security flags enabled it fails on older hosts (e.g. Ubuntu 
> > > > > > 14.04 with gcc-4.8) now with:
> > > > >
> > > > > I am seeing same failure on ubuntu 14.04 and centos7 boxes
> > > > > this definitely is regression, its being not to right about using
> > > > > TARGET_CFLAGS where it should not be using them
> > > > >
> > > > > >
> > > > > > DEBUG: Executing shell function do_compile
> > > > > > [1/63] gcc -Igen.tab/gen.tab@@gen-unicode-version@exe -Igen.tab 
> > > > > > -I../fribidi-1.0.5/gen.tab -I. -I../fribidi-1.0.5/ -Ilib 
> > > > > > -I../fribidi-1.0.5/lib -pipe -D_FILE_OFFSET_BITS=64 -ansi 
> > > > > > -fvisibility=hidden -O2 -g -feliminate-unused-debug-types 
> > > > > > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0=/usr/src/debug/fribidi/1.0.5-r0
> > > > > >  
> > > > > > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0/recipe-sysroot=
> > > > > >  
> > > > > > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0/recipe-sysroot-native=
> > > > > >  -UHAVE_CONFIG_H -DHAVE_STRINGIZE -DDONT_HAVE_FRIBIDI_CONFIG_H 
> > > > > > -DHAVE_STDLIB_H -DHAVE_STRING_H -DHAVE_STRINGS_H -DSTDC_HEADERS=1  
> > > > > > -MD -MQ 
> > > > > > 'gen.tab/gen.tab@@gen-unicode-version@exe/gen-unicode-version.c.o' 
> > > > > > -MF 
> > > > > > 'gen.tab/gen.tab@@gen-unicode-version@exe/gen-unicode-version.c.o.d'
> > > > > >  -o 
> > > > > > 'gen.tab/gen.tab@@gen-unicode-version@exe/gen-unicode-version.c.o' 
> > > > > > -c ../fribidi-1.0.5/gen.tab/gen-unicode-version.c
> > > > > > [2/63] gcc   -o gen.tab/gen-unicode-version 
> > > > > > 'gen.tab/gen.tab@@gen-unicode-version@exe/gen-unicode-version.c.o' 
> > > > > > -Wl,--no-undefined -Wl,--as-needed -O2 -pipe -g 
> > > > > > -feliminate-unused-debug-types 
> > > > > > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0=/usr/src/debug/fribidi/1.0.5-r0
> > > > > >  
> > > > > > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0/recipe-sysroot=
> > > > > >  
> > > > > > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0/recipe-sysroot-native=
> > > > > >  -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed 
> > > > > > -fstack-protector-strong -Wl,-z,relro,-z,now
> > > > > > FAILED: gen.tab/gen-unicode-version
> > > > > > gcc   -o gen.tab/gen-unicode-version 
> > > > > > 'gen.tab/gen.tab@@gen-unicode-version@exe/gen-unicode-version.c.o' 
> > > > > > -Wl,--no-undefined -Wl,--as-needed -O2 -pipe -g 
> > > > > > -feliminate-unused-debug-types 
> > > > > > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0=/usr/src/debug/fribidi/1.0.5-r0
> > > > > >  
> > > > > > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0/recipe-sysroot=
> > > > > >  
> > > > > > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0/recipe-sysroot-native=
> > > > > >  -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed 
> > > > > > -fstack-protector-strong -Wl,-z,relro,-z,now

Re: [OE-core] [PATCH v3] python3{,-native}: update to 3.7.0

[Jens Rehsack]

Beside of that, what is your proposal?
Am Mi., 19. Sep. 2018 um 20:08 Uhr schrieb Alejandro Hernandez
:
>
> I am aware dnf needs an update, but in the meantime you can't break
> functionality of other components of the build system when upgrading a
> certain component, we either need a patch to dnf to fix compatibility or
> the upgrade to dnf as well.
>
>
> Alejandro
>
> On 9/19/2018 1:44 AM, Jens Rehsack wrote:
> > That has already been discussed, dnf needs an update.
> > Am Mi., 19. Sep. 2018 um 08:50 Uhr schrieb Alejandro Hernandez
> > :
> >> Hey Jens,
> >>
> >> Apart from the python3-native incomplete build which we discussed before
> >> and is still there, this is still breaking dnf, hence producing an error
> >> when executing do_rootfs for an image.
> >>
> >> The following error is shown:
> >>
> >> NOTE: ## Generate rootfs ###
> >> NOTE: Executing 'RSN/usr/bin/createrepo_c --update -q
> >> wrkdir/qemux86-poky-linux/core-image-minimal/1.0-r0/oe-rootfs-repo' ...
> >> NOTE: Running RSN/usr/bin/dnf -v --rpmverbosity=debug -y -c
> >> wrkdir/qemux86-poky-linux/core-image-minimal/1.0-r0/rootfs/etc/dnf/dnf.conf
> >> --setoh
> >> ERROR: Could not invoke dnf. Command 'RSN/usr/bin/dnf -v
> >> --rpmverbosity=debug -y -c
> >> wrkdir/qemux86-poky-linux/core-image-minimal/1.0-r0/rootfs:
> >> Traceback (most recent call last):
> >> File "RSN/usr/lib/python3.7/site-packages/dnf/util.py", line 121, in
> >> ensure_dir
> >>   os.makedirs(dname, mode=0o755)
> >> File "RSN/usr/lib/python3.7/os.py", line 221, in makedirs
> >>   mkdir(name, mode)
> >> FileExistsError: [Errno 17] File exists:
> >> 'wrkdir/qemux86-poky-linux/core-image-minimal/1.0-r0/temp'
> >>
> >> Traceback (most recent call last):
> >> File "RSN/usr/bin/dnf.real", line 58, in 
> >>   main.user_main(sys.argv[1:], exit_code=True)
> >> File "RSN/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 179,
> >> in user_main
> >>
> >> ...
> >>
> >> File "RSN/usr/lib/python3.7/site-packages/dnf/util.py", line 123, in
> >> ensure_dir
> >>   if e.errno != os.errno.EEXIST or not os.path.isdir(dname):
> >> AttributeError: module 'os' has no attribute 'errno'
> >>
> >>
> >> This means either the python3 build needs to be fixed (unlikely) or that
> >> the dnf build needs to be fixed to be compatible with python 3.7, and if
> >> that's the case the patch to dnf still needs to be provided (even if
> >> it's not part of the upgrade), since we need to ensure that we don't
> >> break other component's functionality in between patches.
> >>
> >> This also means that you probably haven't tested running python3.7
> >> inside an image, otherwise its likely you would've seen this same issue,
> >> while I see no reason why the python3.7 build wouldn't work at runtime,
> >> it still needs to be tested, the fact that a package builds successfully
> >> doesn't mean it will necessarily run properly.
> >>
> >> Alejandro
> >>
> >> On 9/17/2018 11:49 AM, Jens Rehsack wrote:
> >>> Update python3 to recent 3.7.0 release.
> >>>
> >>> Details about new features and bug-fixes can be taken from
> >>> * https://docs.python.org/3/whatsnew/3.7.html
> >>> * https://docs.python.org/3/whatsnew/3.6.html
> >>>
> >>> Remove patches when they were fixed upstream and rebase the
> >>> remaining ones. If necessary, the patches are adopted to
> >>> keep the idea when upstream code was changed. Also remove
> >>> backports from 3.6 and 3.7 into 3.5.6 codebase for TLS
> >>> and multiprocessing.
> >>>
> >>> Open TODO: track patches in a -STABLE rebased git branch for
> >>> easier rebasing or upstream submitting.
> >>>
> >>> Enhancement requests for Yocto project
> >>> * https://bugzilla.yoctoproject.org/show_bug.cgi?id=12375
> >>> * https://bugzilla.yoctoproject.org/show_bug.cgi?id=12901
> >>> are solved by this.
> >>>
> >>> Signed-off-by: Jens Rehsack 
> >>> ---
> >>>meta/classes/python3-dir.bbclass  |   6 +-
> >>>.../python/python3-native_3.5.6.bb| 100 --
> >>>.../python/python3-native_3.7.0.bb|  73 
> >>>meta/recipes-devtools/python/python3.inc  |  65 +++-
> >>>...hell-version-of-python-config-that-w.patch |  21 +-
> >>>..._sysconfigdata.py-to-initialize-dist.patch |  66 
> >>>...ontext-has-improved-default-settings.patch | 272 ---
> >>>...d-target-to-split-profile-generation.patch |  40 ---
> >>>...S-1.3-cipher-suites-and-OP_NO_TLSv1_.patch | 227 
> >>>...for-TLS-1.3-and-OpenSSL-1.1.1-GH-876.patch | 173 -
> >>>3-ciphers-for-OpenSSL-1.1.1-GH-6976.patch | 110 --
> >>>...ALPN-changes-for-OpenSSL-1.1.0f-2305.patch |  68 
> >>>.../python3/03-fix-tkinter-detection.patch|  12 +-
> >>>.../python3/030-fixup-include-dirs.patch  |   9 -
> >>>.../080-distutils-dont_adjust_files.patch |   4 +-
> >>>.../python/python3/150-fix-setupterm.patch|  17 -
> >>>...GS-for-extensions-when-cross-compili.patch |  

Re: [OE-core] [PATCH v4] python3{,-native}: update to 3.7.0

[Jens Rehsack]

Hi Alejandro,

on my system it builds without any problem. And I run the create_manifest task.

Cheers,
Jens
Am Mi., 19. Sep. 2018 um 21:19 Uhr schrieb Alejandro Hernandez
:
>
> Hello Jens,
>
> I appreciate the effort of submitting a v4,  this version has (mostly
> all) the required manifest changes, and at the same time it proves the
> point I've been trying to make since the beginning:
>
> Again, the native build isn't complete and shows:
>
> Python build finished successfully!
> The necessary bits to build these optional modules were not found:
> _uuid
>
>
> Which causes _uuid.*.so to be on the python3-misc package because it
> wasn't on the native build and it couldn't be found when creating the
> manifest (there is simply no reference to it on the manifest, so
> python3-misc gets it):
>
> * python3-misc (dir)
>  * usr (dir)
>  * lib (dir)
>  * python3.7 (dir)
>  * lib-dynload(dir)
>  * _uuid.cpython-37m-i386-linux-gnu.so
>
>
> This will eventually cause a runtime error if a user tries to install
> python3-netclient, which is exactly the reason why the create_manifest
> task exists:
>
> Traceback (most recent call last):
>File "", line 1, in 
> ModuleNotFoundError: No module named '_uuid'
>
>
> This can easily be prevented, as the note on the recipe says, we need to
> ensure we have a complete python3-native build to create the manifest on
> every new release. If you fix the native build with the instructions I
> gave you and re-run the create_manifest task you will realize that the
> python3-netclient package should be the one to get the _uuid.*.so
> library, since it depends on it to work properly.
>
> +++ b/meta/recipes-devtools/python/python3/python3-manifest.json
> @@ -743,6 +743,7 @@
>   "${libdir}/python${PYTHON_MAJMIN}/hmac.py",
>   "${libdir}/python${PYTHON_MAJMIN}/http",
>   "${libdir}/python${PYTHON_MAJMIN}/http/__pycache__",
> + "${libdir}/python${PYTHON_MAJMIN}/lib-dynload/_uuid.*.so",
>
>
> And that is the reason why this upgrade still needs a one line patch to
> setup.py to build _uuid on python3-native, I cannot make it any more
> clearly.
>
> Please fix the native build before submitting a new version of this patch.
>
>
> Alejandro
>
>
> On 9/19/2018 2:24 AM, Jens Rehsack wrote:
> > Update python3 to recent 3.7.0 release.
> >
> > Details about new features and bug-fixes can be taken from
> > * https://docs.python.org/3/whatsnew/3.7.html
> > * https://docs.python.org/3/whatsnew/3.6.html
> >
> > Remove patches when they were fixed upstream and rebase the
> > remaining ones. If necessary, the patches are adopted to
> > keep the idea when upstream code was changed. Also remove
> > backports from 3.6 and 3.7 into 3.5.6 codebase for TLS
> > and multiprocessing.
> >
> > Open TODO: track patches in a -STABLE rebased git branch for
> > easier rebasing or upstream submitting.
> >
> > Enhancement requests for Yocto project
> > * https://bugzilla.yoctoproject.org/show_bug.cgi?id=12375
> > * https://bugzilla.yoctoproject.org/show_bug.cgi?id=12901
> > are solved by this.
> >
> > Signed-off-by: Jens Rehsack 
> > ---
> >   meta/classes/python3-dir.bbclass  |   6 +-
> >   .../python/python3-native_3.5.6.bb| 100 --
> >   .../python/python3-native_3.7.0.bb|  73 
> >   meta/recipes-devtools/python/python3.inc  |  65 +++-
> >   ...hell-version-of-python-config-that-w.patch |  21 +-
> >   ..._sysconfigdata.py-to-initialize-dist.patch |  66 
> >   ...ontext-has-improved-default-settings.patch | 272 ---
> >   ...d-target-to-split-profile-generation.patch |  40 ---
> >   ...S-1.3-cipher-suites-and-OP_NO_TLSv1_.patch | 227 
> >   ...for-TLS-1.3-and-OpenSSL-1.1.1-GH-876.patch | 173 -
> >   3-ciphers-for-OpenSSL-1.1.1-GH-6976.patch | 110 --
> >   ...ALPN-changes-for-OpenSSL-1.1.0f-2305.patch |  68 
> >   .../python3/03-fix-tkinter-detection.patch|  12 +-
> >   .../python3/030-fixup-include-dirs.patch  |   9 -
> >   .../080-distutils-dont_adjust_files.patch |   4 +-
> >   .../python/python3/150-fix-setupterm.patch|  17 -
> >   ...GS-for-extensions-when-cross-compili.patch |  53 ++-
> >   .../python3/avoid-ncursesw-include-path.patch |  18 +-
> >   .../python3/avoid_warning_about_tkinter.patch |  18 +-
> >   .../python3/configure.ac-fix-LIBPL.patch  |  21 +-
> >   .../python/python3/float-endian.patch |   9 +-
> >   ...ssing-libraries-to-Extension-for-mul.patch |  26 +-
> >   .../python/python3/python-3.3-multilib.patch  | 241 +++--
> >   .../python/python3/python3-manifest.json  |  35 +-
> >   ...CROSSPYTHONPATH-for-PYTHON_FOR_BUILD.patch |  17 +-
> >   .../python/python3/regen-all.patch|  25 --
> >   .../python/python3/signal.patch   |  56 ---
> >   ...port_SOURCE_DATE_EPOCH_in_py_compile.patch |  36 +-
> >   

Re: [OE-core] [PATCH] openssh: resolve install conflict with openssh-sftp-server-dev

[Urs Fässler]

On Wed, 2018-09-19 at 09:01 -0700, Richard Purdie wrote:
> On Wed, 2018-09-19 at 17:11 +0200, Andreas Oberritter wrote:
> > On Wed, 19 Sep 2018 08:41:35 +0200
> > Urs Fässler  wrote:
> > 
> > > Image generation fails with the configuration:
> > >   EXTRA_IMAGE_FEATURES = "ssh-server-dropbear eclipse-debug dev-
> > > pkgs"
> > > This is due the dependency eclipse-debug -> openssh-sftp-server ->
> > > openssh-dev -> openssh. openssh can not be installed since it
> > > conflicts
> > > with dropbear.
> > 
> > That's odd. Why does openssh-sftp-server depend on openssh-dev?
> > Does
> > openssh-dev contain a file which it shouldn't, e.g. a dynamically
> > loaded module/plug-in?
> 
> It doesn't, its the fact that "dev-pkgs" are requested in
> IMAGE_FEATURES. "openssh-dev" would be the default for openssh
> packages
> and dropbear-dev would be the default for dropbear packages. 
> 
> The patch here doesn't sound correct. I'm wondering if the correct
> fix
> is for ${PN}-dev should not depend on ${PN} and whether that
> would fix
> the problem?

The dependency from ${PN}-dev to ${PN} seems to be the default behavior
in Yocto. I don't know the consequences when we change this for
openssh. But it helps in my case.
(I added RDEPENDS_${PN}-dev = "", didn't found a better way)

Another workaround is, when I don't allow the generation of an empty
${PN}-dev package. I have the same considerations as with the previous
idea.

I see the problem that dev-pkgs automatically installs openssh-dev if I
select the openssh-sftp-server.
The nice solution would be to tell Yocto not to install openssh-dev
when openssh-sftp-server and dev-pkgs is configured. But I have no idea
if or how this is possible.

Unfortunately I didn't found a recipe where this problem is also
solved.

Kind Regards
Urs

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

Re: [OE-core] [RFC PATCH] package.bbclass: improve -dbg and -src package ordering

[Joshua Watt]

This bug also affect sumo.

Armin, would you be able to you backport it please?

Thanks.

On Wed, 2018-07-11 at 13:38 +0200, Rasmus Villemoes wrote:
> nativesdk-gpgme fails package_qa when setting
> PACKAGE_DEBUG_SPLIT_STYLE
> = "debug-with-srcpkg".
> 
> ERROR: nativesdk-gpgme-1.10.0-r0 do_package_qa: QA Issue: non debug
> package contains .debug directory: nativesdk-python3-gpg path
> /work/x86_64-nativesdk-oesdk-linux/nativesdk-gpgme/1.10.0-
> r0/packages-split/nativesdk-python3-gpg/usr/local/oecore-
> x86_64/sysroots/x86_64-oesdk-linux/usr/lib/python3.5/site-
> packages/gpg/.debug/_gpgme.cpython-35m-x86_64-linux-gnu.so [debug-
> files]
> 
> This turns out to be because the automatic moving of the -dbg package
> to
> the beginning of the package list is disabled in that case, so the
> python3-gpg packages that the recipe prepends to PACKAGES ends up
> before
> the -dbg package.
> 
> It's not clear why the "and not split_source_package" was added when
> debug-with-srcpkg was introduced. Presumably the intention was to
> prevent the -dbg package to end up before the -src package, which we
> of
> course need to. But at the same time, we still need -dbg packages to
> end
> up before all other packages.
> 
> Using list.insert(0, ...) also means that if there happens to more
> than
> one -dbg package, their relative ordering gets inverted in the new
> list.
> 
> This tries to fix these issues by sorting the packages by (priority,
> original position), where priority is 10 for -src, 30 for -dbg and 50
> for everything else. That guarantees that packages of the same "type"
> preserve their relative ordering, while also ensuring that -dbg
> always
> preceed other packages. This scheme is also quite extensible, and,
> should the need arise, one could even expose the priorities as a knob
> the recipe author could use to ensure specific orderings of packages
> instead of the somewhat fragile and coarse-grained method of "prepend
> or
> append, and ensure you do that in a proper order".
> 
> Probably the autodebug condition needs to stay, but I think the
> split_source_package condition in the preceding elif should be
> removed,
> so that that logic applies to all packages called -src, not just the
> one
> we might have created a few lines above.
> 
> Signed-off-by: Rasmus Villemoes 
> ---
>  meta/classes/package.bbclass | 15 ---
>  1 file changed, 8 insertions(+), 7 deletions(-)
> 
> diff --git a/meta/classes/package.bbclass
> b/meta/classes/package.bbclass
> index 8276046369..72b9c66c3b 100644
> --- a/meta/classes/package.bbclass
> +++ b/meta/classes/package.bbclass
> @@ -1151,21 +1151,22 @@ python populate_packages () {
>  
>  # Sanity check PACKAGES for duplicates
>  # Sanity should be moved to sanity.bbclass once we have the
> infrastructure
> -package_list = []
> +package_dict = {}
>  
> -for pkg in packages.split():
> -if pkg in package_list:
> +for i, pkg in enumerate(packages.split()):
> +if pkg in package_dict:
>  msg = "%s is listed in PACKAGES multiple times, this
> leads to packaging errors." % pkg
>  package_qa_handle_error("packages-list", msg, d)
>  # If debug-with-srcpkg mode is enabled then the src package
> will have
>  # priority over dbg package when assigning the files.
>  # This allows src package to include source files and remove
> them from dbg.
>  elif split_source_package and pkg.endswith("-src"):
> -package_list.insert(0, pkg)
> -elif autodebug and pkg.endswith("-dbg") and not
> split_source_package:
> -package_list.insert(0, pkg)
> +package_dict[pkg] = (10, i)
> +elif autodebug and pkg.endswith("-dbg"):
> +package_dict[pkg] = (30, i)
>  else:
> -package_list.append(pkg)
> +package_dict[pkg] = (50, i)
> +package_list = sorted(package_dict.keys(), key=package_dict.get)
>  d.setVar('PACKAGES', ' '.join(package_list))
>  pkgdest = d.getVar('PKGDEST')
>  
> -- 
> 2.16.4
> 
-- 
Joshua Watt 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-commits] [openembedded-core] 02/45: fribidi: use Meson instead of autotools

[Burton, Ross]

Turns out that fix promptly breaks something else...

Digging into Meson today and trying to fix some target/host confusion.

Ross
On Mon, 24 Sep 2018 at 19:58, Khem Raj  wrote:
>
> On Mon, Sep 24, 2018 at 4:10 AM Burton, Ross  wrote:
> >
> > I can't seem to replicate this on our centos7 box:
> >
> > [ross@centos7 build]$ gcc --version
> > gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28)
> > [ross@centos7 build]$ gcc -ffdjsj
> > gcc: error: unrecognized command line option ‘-ffdjsj’
> > gcc: fatal error: no input files
> > compilation terminated.
> > [ross@centos7 build]$ gcc -fstack-protector-strong
> > gcc: fatal error: no input files
> > compilation terminated.
> >
> > Presumably we've upgraded gcc at some point...
> >
> > However I did replicate the same sort of problem outside of OE.  Can
> > one of you test
> > http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=ross/mut=1e32317ad77457d2a026eaa67ea7c6eebe58b127
> > for me please?
> >
>
> this solves the issue, thanks for prompt turnaround for fixing it
>
> > Cheers,
> > Ross
> > On Mon, 24 Sep 2018 at 11:08, Burton, Ross  wrote:
> > >
> > > Looks like Meson is using the target link flags for linking even when
> > > it knows its doing a native build.  Talking to Meson upstream now and
> > > have a workaround.
> > >
> > > Ross
> > > On Sun, 23 Sep 2018 at 15:51, Khem Raj  wrote:
> > > >
> > > > On Sun, Sep 23, 2018 at 2:20 AM Martin Jansa  
> > > > wrote:
> > > > >
> > > > > Was this one ever sent to ML? I haven't found it in the archives.
> > > > >
> > > > > With security flags enabled it fails on older hosts (e.g. Ubuntu 
> > > > > 14.04 with gcc-4.8) now with:
> > > >
> > > > I am seeing same failure on ubuntu 14.04 and centos7 boxes
> > > > this definitely is regression, its being not to right about using
> > > > TARGET_CFLAGS where it should not be using them
> > > >
> > > > >
> > > > > DEBUG: Executing shell function do_compile
> > > > > [1/63] gcc -Igen.tab/gen.tab@@gen-unicode-version@exe -Igen.tab 
> > > > > -I../fribidi-1.0.5/gen.tab -I. -I../fribidi-1.0.5/ -Ilib 
> > > > > -I../fribidi-1.0.5/lib -pipe -D_FILE_OFFSET_BITS=64 -ansi 
> > > > > -fvisibility=hidden -O2 -g -feliminate-unused-debug-types 
> > > > > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0=/usr/src/debug/fribidi/1.0.5-r0
> > > > >  
> > > > > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0/recipe-sysroot=
> > > > >  
> > > > > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0/recipe-sysroot-native=
> > > > >  -UHAVE_CONFIG_H -DHAVE_STRINGIZE -DDONT_HAVE_FRIBIDI_CONFIG_H 
> > > > > -DHAVE_STDLIB_H -DHAVE_STRING_H -DHAVE_STRINGS_H -DSTDC_HEADERS=1  
> > > > > -MD -MQ 
> > > > > 'gen.tab/gen.tab@@gen-unicode-version@exe/gen-unicode-version.c.o' 
> > > > > -MF 
> > > > > 'gen.tab/gen.tab@@gen-unicode-version@exe/gen-unicode-version.c.o.d' 
> > > > > -o 'gen.tab/gen.tab@@gen-unicode-version@exe/gen-unicode-version.c.o' 
> > > > > -c ../fribidi-1.0.5/gen.tab/gen-unicode-version.c
> > > > > [2/63] gcc   -o gen.tab/gen-unicode-version 
> > > > > 'gen.tab/gen.tab@@gen-unicode-version@exe/gen-unicode-version.c.o' 
> > > > > -Wl,--no-undefined -Wl,--as-needed -O2 -pipe -g 
> > > > > -feliminate-unused-debug-types 
> > > > > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0=/usr/src/debug/fribidi/1.0.5-r0
> > > > >  
> > > > > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0/recipe-sysroot=
> > > > >  
> > > > > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0/recipe-sysroot-native=
> > > > >  -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed 
> > > > > -fstack-protector-strong -Wl,-z,relro,-z,now
> > > > > FAILED: gen.tab/gen-unicode-version
> > > > > gcc   -o gen.tab/gen-unicode-version 
> > > > > 'gen.tab/gen.tab@@gen-unicode-version@exe/gen-unicode-version.c.o' 
> > > > > -Wl,--no-undefined -Wl,--as-needed -O2 -pipe -g 
> > > > > -feliminate-unused-debug-types 
> > > > > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0=/usr/src/debug/fribidi/1.0.5-r0
> > > > >  
> > > > > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0/recipe-sysroot=
> > > > >  
> > > > > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0/recipe-sysroot-native=
> > > > >  -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed 
> > > > > -fstack-protector-strong -Wl,-z,relro,-z,now
> > > > > gcc: error: unrecognized command line option 
> > > > > ‘-fstack-protector-strong’
> > > > > ninja: build stopped: subcommand failed.
> > > > > WARNING: exit code 1 from a shell command.
> > > > >
> > > > > Is meson too active in adding SECURITY_FLAGS even to native part of 
> > > > > the build or should we just just remove -fstack-protector-strong 
> > > > > completely for fribidi?
> > > > >
> > > > 

[OE-core] ✗ patchtest: failure for dnsmasq: CVE-2017-15107

[Patchwork]

== Series Details ==

Series: dnsmasq: CVE-2017-15107
Revision: 1
URL   : https://patchwork.openembedded.org/series/14200/
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 sent to the wrong mailing list or some patches from 
the series correspond to different mailing lists [test_target_mailing_list] 
  Suggested fixSend the series again to the correct mailing list (ML)
  Suggested ML openembedded-de...@lists.openembedded.org 
[http://git.openembedded.org/meta-openembedded/]
  Patch's path:meta-networking/recipes-support/dnsmasq/dnsmasq_2.78.bb

* 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  sumo (currently at 82b0189567)



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 1/3] acl: Make it compatible with externalsrc

[Peter Kjellerstedt]

Make the subdir fetch path for configure.ac relative. This avoids the
following error after having done `devtool modify acl`:

ERROR: acl-2.2.52-r0 do_unpack: Unpack failure for URL:
'file://configure.ac;subdir=.../builds/qemux86-64/workspace/sources/acl'.
subdir argument isn't a subdirectory of unpack root
.../builds/qemux86-64/tmp/work/core2-64-poky-linux/acl/2.2.52-r0

Signed-off-by: Peter Kjellerstedt 
---
 meta/recipes-support/attr/acl_2.2.52.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-support/attr/acl_2.2.52.bb 
b/meta/recipes-support/attr/acl_2.2.52.bb
index 8f3dc45cf7..8b89de9b42 100644
--- a/meta/recipes-support/attr/acl_2.2.52.bb
+++ b/meta/recipes-support/attr/acl_2.2.52.bb
@@ -11,7 +11,7 @@ LIC_FILES_CHKSUM = 
"file://doc/COPYING;md5=c781d70ed2b4d48995b790403217a249 \
 DEPENDS = "attr"
 
 SRC_URI = "${SAVANNAH_GNU_MIRROR}/acl/${BP}.src.tar.gz \
-   file://configure.ac;subdir=${S} \
+   file://configure.ac;subdir=${BP} \
file://run-ptest \
file://acl-fix-the-order-of-expected-output-of-getfacl.patch \
file://test-fix-insufficient-quoting-of.patch \
-- 
2.12.0

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

[OE-core] [PATCH 3/3] libxml2: Make it compatible with externalsrc

[Peter Kjellerstedt]

Fetch the test tar ball to a subdirectory in ${S}. This avoids the
following error after having done `devtool modify libxml2`:

| DEBUG: Executing shell function do_configure
| find: 
‘.../build/tmp/work/mips32r2el-nf-poky-linux/libxml2/2.9.4-r0/xmlconf/’: No 
such file or directory

Signed-off-by: Peter Kjellerstedt 
---
 meta/recipes-core/libxml/libxml2_2.9.8.bb | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-core/libxml/libxml2_2.9.8.bb 
b/meta/recipes-core/libxml/libxml2_2.9.8.bb
index f01cb2cd34..4ec03c6d15 100644
--- a/meta/recipes-core/libxml/libxml2_2.9.8.bb
+++ b/meta/recipes-core/libxml/libxml2_2.9.8.bb
@@ -12,7 +12,7 @@ LIC_FILES_CHKSUM = 
"file://Copyright;md5=2044417e2e5006b65a8b9067b683fcf1 \
 DEPENDS = "zlib virtual/libiconv"
 
 SRC_URI = "http://www.xmlsoft.org/sources/libxml2-${PV}.tar.gz;name=libtar \
-   http://www.w3.org/XML/Test/xmlts20080827.tar.gz;name=testtar \
+   
http://www.w3.org/XML/Test/xmlts20080827.tar.gz;subdir=${BP};name=testtar \
file://libxml-64bit.patch \
file://runtest.patch \
file://run-ptest \
@@ -76,7 +76,7 @@ FILES_${PN}-python += "${PYTHON_SITEPACKAGES_DIR}"
 
 do_configure_prepend () {
# executables take longer to package: these should not be executable
-   find ${WORKDIR}/xmlconf/ -type f -exec chmod -x {} \+
+   find ${S}/xmlconf/ -type f -exec chmod -x {} \+
 }
 
 do_compile_ptest() {
@@ -84,7 +84,7 @@ do_compile_ptest() {
 }
 
 do_install_ptest () {
-   cp -r ${WORKDIR}/xmlconf ${D}${PTEST_PATH}
+   cp -r ${S}/xmlconf ${D}${PTEST_PATH}
if [ "${@bb.utils.filter('PACKAGECONFIG', 'python', d)}" ]; then
sed -i -e 's|^\(PYTHON = \).*|\1${USRBINPATH}/${PYTHON_PN}|' \
${D}${PTEST_PATH}/python/tests/Makefile
-- 
2.12.0

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

[OE-core] [PATCH 2/3] lsof: Make it compatible with externalsrc

[Peter Kjellerstedt]

Make the unpack task do nothing if externalsrc is in use. This avoids
the following error after having done `devtool modify lsof`:

ERROR: lsof-4.91-r0 do_unpack: Unpack failure for URL:
'file://.../builds/qemux86-64/tmp/work/core2-64-poky-linux/lsof/4.91-r0/lsof_4.91/lsof_4.91_src.tar'.
Unpack command PATH="..." tar x --no-same-owner -f
.../builds/qemux86-64/tmp/work/core2-64-poky-linux/lsof/4.91-r0/lsof_4.91/lsof_4.91_src.tar
failed with return value 2

Signed-off-by: Peter Kjellerstedt 
---
 meta/recipes-extended/lsof/lsof_4.91.bb | 23 +++
 1 file changed, 11 insertions(+), 12 deletions(-)

diff --git a/meta/recipes-extended/lsof/lsof_4.91.bb 
b/meta/recipes-extended/lsof/lsof_4.91.bb
index 0128de4a6e..b3adfd57af 100644
--- a/meta/recipes-extended/lsof/lsof_4.91.bb
+++ b/meta/recipes-extended/lsof/lsof_4.91.bb
@@ -23,18 +23,17 @@ LOCALSRC = "file://${WORKDIR}/lsof_${PV}/lsof_${PV}_src.tar"
 S = "${WORKDIR}/lsof_${PV}_src"
 
 python do_unpack () {
-# temporarily change S for unpack
-# of lsof_${PV}
-s = d.getVar('S', False)
-d.setVar('S', '${WORKDIR}/lsof_${PV}')
-bb.build.exec_func('base_do_unpack', d)
-# temporarily change SRC_URI for unpack
-# of lsof_${PV}_src
-src_uri = d.getVar('SRC_URI', False)
-d.setVar('SRC_URI', '${LOCALSRC}')
-d.setVar('S', s)
-bb.build.exec_func('base_do_unpack', d)
-d.setVar('SRC_URI', src_uri)
+if not bb.data.inherits_class('externalsrc', d) or not 
d.getVar('EXTERNALSRC'):
+# temporarily change S for unpack of lsof_${PV}
+s = d.getVar('S', False)
+d.setVar('S', '${WORKDIR}/lsof_${PV}')
+bb.build.exec_func('base_do_unpack', d)
+# temporarily change SRC_URI for unpack of lsof_${PV}_src
+src_uri = d.getVar('SRC_URI', False)
+d.setVar('SRC_URI', '${LOCALSRC}')
+d.setVar('S', s)
+bb.build.exec_func('base_do_unpack', d)
+d.setVar('SRC_URI', src_uri)
 }
 
 export LSOF_INCLUDE = "${STAGING_INCDIR}"
-- 
2.12.0

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

[OE-core] [PATCH v2] bash: 4.4.18 -> 4.4.23

[Jeroen Hofstee]

Signed-off-by: Jeroen Hofstee 
---
v2: add patch subject prefix
---
 meta/recipes-extended/bash/bash_4.4.18.bb | 16 
 1 file changed, 16 insertions(+)

diff --git a/meta/recipes-extended/bash/bash_4.4.18.bb 
b/meta/recipes-extended/bash/bash_4.4.18.bb
index b338acd..8fa0978 100644
--- a/meta/recipes-extended/bash/bash_4.4.18.bb
+++ b/meta/recipes-extended/bash/bash_4.4.18.bb
@@ -5,6 +5,11 @@ LICENSE = "GPLv3+"
 LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
 
 SRC_URI = "${GNU_MIRROR}/bash/${BP}.tar.gz;name=tarball \
+   
${GNU_MIRROR}/bash/bash-4.4-patches/bash44-019;apply=yes;striplevel=0;name=patch019
 \
+   
${GNU_MIRROR}/bash/bash-4.4-patches/bash44-020;apply=yes;striplevel=0;name=patch020
 \
+   
${GNU_MIRROR}/bash/bash-4.4-patches/bash44-021;apply=yes;striplevel=0;name=patch021
 \
+   
${GNU_MIRROR}/bash/bash-4.4-patches/bash44-022;apply=yes;striplevel=0;name=patch022
 \
+   
${GNU_MIRROR}/bash/bash-4.4-patches/bash44-023;apply=yes;striplevel=0;name=patch023
 \
file://execute_cmd.patch;striplevel=0 \
file://mkbuiltins_have_stringize.patch \
file://build-tests.patch \
@@ -19,6 +24,17 @@ SRC_URI = "${GNU_MIRROR}/bash/${BP}.tar.gz;name=tarball \
 SRC_URI[tarball.md5sum] = "518e2c187cc11a17040f0915dddce54e"
 SRC_URI[tarball.sha256sum] = 
"604d9eec5e4ed5fd2180ee44dd756ddca92e0b6aa4217bbab2b6227380317f23"
 
+SRC_URI[patch019.md5sum] = "8f43e1d277b02f3319a34c1cd4a4ff3e"
+SRC_URI[patch019.sha256sum] = 
"27170d6edfe8819835407fdc08b401d2e161b1400fe9d0c5317a51104c89c11e"
+SRC_URI[patch020.md5sum] = "5217ff08c46ec306dce60437c288"
+SRC_URI[patch020.sha256sum] = 
"1840e2cbf26ba822913662f74037594ed562361485390c52813b38156c99522c"
+SRC_URI[patch021.md5sum] = "282c7d9b38da8005d25b4f816328a2f4"
+SRC_URI[patch021.sha256sum] = 
"bd8f59054a763ec1c64179ad5cb607f558708a317c2bdb22b814e3da456374c1"
+SRC_URI[patch022.md5sum] = "0b709c9d7f8e6cf267a8b863efb899f7"
+SRC_URI[patch022.sha256sum] = 
"45331f0936e36ab91bfe44b936e33ed8a1b1848fa896e8a1d0f2ef74f297cb79"
+SRC_URI[patch023.md5sum] = "fe2e0ca4cf9409ff0e9428e1236f983e"
+SRC_URI[patch023.sha256sum] = 
"4fec236f3fbd3d0c47b893fdfa9122142a474f6ef66c20ffb6c0f4864dd591b6"
+
 DEBUG_OPTIMIZATION_append_armv4 = " ${@bb.utils.contains('TUNE_CCARGS', 
'-mthumb', '-fomit-frame-pointer', '', d)}"
 DEBUG_OPTIMIZATION_append_armv5 = " ${@bb.utils.contains('TUNE_CCARGS', 
'-mthumb', '-fomit-frame-pointer', '', d)}"
 
-- 
2.7.4

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

Re: [OE-core] [oe-commits] [openembedded-core] 02/45: fribidi: use Meson instead of autotools

[Khem Raj]

On Mon, Sep 24, 2018 at 4:10 AM Burton, Ross  wrote:
>
> I can't seem to replicate this on our centos7 box:
>
> [ross@centos7 build]$ gcc --version
> gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28)
> [ross@centos7 build]$ gcc -ffdjsj
> gcc: error: unrecognized command line option ‘-ffdjsj’
> gcc: fatal error: no input files
> compilation terminated.
> [ross@centos7 build]$ gcc -fstack-protector-strong
> gcc: fatal error: no input files
> compilation terminated.
>
> Presumably we've upgraded gcc at some point...
>
> However I did replicate the same sort of problem outside of OE.  Can
> one of you test
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=ross/mut=1e32317ad77457d2a026eaa67ea7c6eebe58b127
> for me please?
>

this solves the issue, thanks for prompt turnaround for fixing it

> Cheers,
> Ross
> On Mon, 24 Sep 2018 at 11:08, Burton, Ross  wrote:
> >
> > Looks like Meson is using the target link flags for linking even when
> > it knows its doing a native build.  Talking to Meson upstream now and
> > have a workaround.
> >
> > Ross
> > On Sun, 23 Sep 2018 at 15:51, Khem Raj  wrote:
> > >
> > > On Sun, Sep 23, 2018 at 2:20 AM Martin Jansa  
> > > wrote:
> > > >
> > > > Was this one ever sent to ML? I haven't found it in the archives.
> > > >
> > > > With security flags enabled it fails on older hosts (e.g. Ubuntu 14.04 
> > > > with gcc-4.8) now with:
> > >
> > > I am seeing same failure on ubuntu 14.04 and centos7 boxes
> > > this definitely is regression, its being not to right about using
> > > TARGET_CFLAGS where it should not be using them
> > >
> > > >
> > > > DEBUG: Executing shell function do_compile
> > > > [1/63] gcc -Igen.tab/gen.tab@@gen-unicode-version@exe -Igen.tab 
> > > > -I../fribidi-1.0.5/gen.tab -I. -I../fribidi-1.0.5/ -Ilib 
> > > > -I../fribidi-1.0.5/lib -pipe -D_FILE_OFFSET_BITS=64 -ansi 
> > > > -fvisibility=hidden -O2 -g -feliminate-unused-debug-types 
> > > > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0=/usr/src/debug/fribidi/1.0.5-r0
> > > >  
> > > > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0/recipe-sysroot=
> > > >  
> > > > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0/recipe-sysroot-native=
> > > >  -UHAVE_CONFIG_H -DHAVE_STRINGIZE -DDONT_HAVE_FRIBIDI_CONFIG_H 
> > > > -DHAVE_STDLIB_H -DHAVE_STRING_H -DHAVE_STRINGS_H -DSTDC_HEADERS=1  -MD 
> > > > -MQ 'gen.tab/gen.tab@@gen-unicode-version@exe/gen-unicode-version.c.o' 
> > > > -MF 
> > > > 'gen.tab/gen.tab@@gen-unicode-version@exe/gen-unicode-version.c.o.d' -o 
> > > > 'gen.tab/gen.tab@@gen-unicode-version@exe/gen-unicode-version.c.o' -c 
> > > > ../fribidi-1.0.5/gen.tab/gen-unicode-version.c
> > > > [2/63] gcc   -o gen.tab/gen-unicode-version 
> > > > 'gen.tab/gen.tab@@gen-unicode-version@exe/gen-unicode-version.c.o' 
> > > > -Wl,--no-undefined -Wl,--as-needed -O2 -pipe -g 
> > > > -feliminate-unused-debug-types 
> > > > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0=/usr/src/debug/fribidi/1.0.5-r0
> > > >  
> > > > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0/recipe-sysroot=
> > > >  
> > > > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0/recipe-sysroot-native=
> > > >  -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -fstack-protector-strong 
> > > > -Wl,-z,relro,-z,now
> > > > FAILED: gen.tab/gen-unicode-version
> > > > gcc   -o gen.tab/gen-unicode-version 
> > > > 'gen.tab/gen.tab@@gen-unicode-version@exe/gen-unicode-version.c.o' 
> > > > -Wl,--no-undefined -Wl,--as-needed -O2 -pipe -g 
> > > > -feliminate-unused-debug-types 
> > > > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0=/usr/src/debug/fribidi/1.0.5-r0
> > > >  
> > > > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0/recipe-sysroot=
> > > >  
> > > > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0/recipe-sysroot-native=
> > > >  -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -fstack-protector-strong 
> > > > -Wl,-z,relro,-z,now
> > > > gcc: error: unrecognized command line option ‘-fstack-protector-strong’
> > > > ninja: build stopped: subcommand failed.
> > > > WARNING: exit code 1 from a shell command.
> > > >
> > > > Is meson too active in adding SECURITY_FLAGS even to native part of the 
> > > > build or should we just just remove -fstack-protector-strong completely 
> > > > for fribidi?
> > > >
> > > >
> > > >
> > > > On Fri, Sep 21, 2018 at 5:24 PM  wrote:
> > > >>
> > > >> This is an automated email from the git hooks/post-receive script.
> > > >>
> > > >> rpurdie pushed a commit to branch master-next
> > > >> in repository openembedded-core.
> > > >>
> > > >> commit d297f7ebf3f62528d055e1938a9693d6f3a61935
> > > >> Author: Ross Burton 
> > > >> AuthorDate: Fri Sep 14 00:28:39 2018 

[OE-core] [sumo] [meta-networking] [PATCH v1] dnsmasq: CVE-2017-15107

[Sinan Kaya]

* CVE-2017-15107
A vulnerability was found in Dnsmasq's implementation of DNSSEC.
Wildcard synthesized NSEC records could be improperly interpreted
to prove the non-existence of hostnames that actually exist.

Affects dnsmasq <= 2.78

CVE: CVE-2017-15107
Ref: https://access.redhat.com/security/cve/cve-2017-15107
Signed-off-by: Sinan Kaya 
---
 .../recipes-support/dnsmasq/dnsmasq_2.78.bb   |   1 +
 .../dnsmasq/files/CVE-2017-15107.patch| 262 ++
 2 files changed, 263 insertions(+)
 create mode 100644 
meta-networking/recipes-support/dnsmasq/files/CVE-2017-15107.patch

diff --git a/meta-networking/recipes-support/dnsmasq/dnsmasq_2.78.bb 
b/meta-networking/recipes-support/dnsmasq/dnsmasq_2.78.bb
index 4d1dc6e69..d2465f82d 100644
--- a/meta-networking/recipes-support/dnsmasq/dnsmasq_2.78.bb
+++ b/meta-networking/recipes-support/dnsmasq/dnsmasq_2.78.bb
@@ -2,6 +2,7 @@ require dnsmasq.inc
 
 SRC_URI += "\
 file://lua.patch \
+file://CVE-2017-15107.patch \
 "
 
 SRC_URI[dnsmasq-2.78.md5sum] = "3bb97f264c73853f802bf70610150788"
diff --git a/meta-networking/recipes-support/dnsmasq/files/CVE-2017-15107.patch 
b/meta-networking/recipes-support/dnsmasq/files/CVE-2017-15107.patch
new file mode 100644
index 0..da2af56cf
--- /dev/null
+++ b/meta-networking/recipes-support/dnsmasq/files/CVE-2017-15107.patch
@@ -0,0 +1,262 @@
+From 5a56e1b78a753d3295564daddc9ce389cc69fd68 Mon Sep 17 00:00:00 2001
+From: Simon Kelley 
+Date: Fri, 19 Jan 2018 12:26:08 +
+Subject: [PATCH] DNSSEC fix for wildcard NSEC records. CVE-2017-15107 applies.
+
+It's OK for NSEC records to be expanded from wildcards,
+but in that case, the proof of non-existence is only valid
+starting at the wildcard name, *. NOT the name expanded
+from the wildcard. Without this check it's possible for an
+attacker to craft an NSEC which wrongly proves non-existence
+in a domain which includes a wildcard for NSEC.
+
+Upstream-Status: Backport 
[http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=4fe6744a220eddd3f1749b40cac3dfc510787de6]
+Signed-off-by: Sinan Kaya 
+---
+ CHANGELOG|  44 +++
+ src/dnssec.c | 117 +--
+ 2 files changed, 147 insertions(+), 14 deletions(-)
+
+diff --git a/CHANGELOG b/CHANGELOG
+index 075fe1a6..5226dce8 100644
+--- a/CHANGELOG
 b/CHANGELOG
+@@ -1,3 +1,47 @@
++version 2.79
++  Fix parsing of CNAME arguments, which are confused by extra spaces.
++  Thanks to Diego Aguirre for spotting the bug.
++
++  Where available, use IP_UNICAST_IF or IPV6_UNICAST_IF to bind
++  upstream servers to an interface, rather than SO_BINDTODEVICE.
++  Thanks to Beniamino Galvani for the patch.
++
++  Always return a SERVFAIL answer to DNS queries without the
++  recursion desired bit set, UNLESS acting as an authoritative
++  DNS server. This avoids a potential route to cache snooping.
++
++  Add support for Ed25519 signatures in DNSSEC validation.
++
++  No longer support RSA/MD5 signatures in DNSSEC validation,
++  since these are not secure. This behaviour is mandated in
++  RFC-6944.
++
++  Fix incorrect error exit code from dhcp_release6 utility.
++  Thanks Gaudenz Steinlin for the bug report.
++
++  Use SIGINT (instead of overloading SIGHUP) to turn on DNSSEC
++  time validation when --dnssec-no-timecheck is in use.
++  Note that this is an incompatible change from earlier releases.
++
++  Allow more than one --bridge-interface option to refer to an
++  interface, so that we can use
++  --bridge-interface=int1,alias1
++  --bridge-interface=int1,alias2
++  as an alternative to
++  --bridge-interface=int1,alias1,alias2
++  Thanks to Neil Jerram for work on this.
++
++  Fix for DNSSEC with wildcard-derived NSEC records.
++  It's OK for NSEC records to be expanded from wildcards,
++  but in that case, the proof of non-existence is only valid
++  starting at the wildcard name, *. NOT the name expanded
++  from the wildcard. Without this check it's possible for an
++  attacker to craft an NSEC which wrongly proves non-existence.
++  Thanks to Ralph Dolmans for finding this, and co-ordinating 
++  the vulnerability tracking and fix release.
++  CVE-2017-15107 applies.
++
++
+ version 2.78
+ Fix logic of appending "." to PXE basename. Thanks to Chris
+   Novakovic for the patch.
+diff --git a/src/dnssec.c b/src/dnssec.c
+index a74d01ab..1417be56 100644
+--- a/src/dnssec.c
 b/src/dnssec.c
+@@ -424,15 +424,17 @@ static void from_wire(char *name)
+ static int count_labels(char *name)
+ {
+   int i;
+-
++  char *p;
++  
+   if (*name == 0)
+ return 0;
+ 
+-  for (i = 0; *name; name++)
+-if (*name == '.')
++  for (p = name, i = 0; *p; p++)
++if (*p == '.')
+   i++;
+ 
+-  return i+1;
++  /* Don't count empty first label. */
++  return *name == '.' ? i : i+1;
+ }
+ 
+ /* Implement RFC1982 

Re: [OE-core] [PATCH] rootfs: always update the opkg index

[richard . purdie]

On Mon, 2018-09-24 at 18:00 +0300, Ioan-Adrian Ratiu wrote:
> > With master, a copy of the feed is constructed under WORKDIR which
> > is
> > then indexed since other image generation or package writes could
> > occur
> > and the index isn't static. I'm guessing it doesn't do this for
> > external feeds and assumes those feeds are static.
> 
> My description of the problem mirrors my understanding of the feed
> construction process which might be limited especially if it changed
> on master post-Sumo, but the answer is yes, external feeds are
> assumed static.

Ok.

> > I am wondering what happens if you put a remote (http://) url into
> > this
> > though? Does that still work or does it break?
> 
> It still works, we're using http paths all the time in our distro
> (public feed server is at http://download.ni.com/ni-linux-rt/)

That is good to know and worth mentioning in the commit message as that
isn't clear.

> > 
> > I'm also worried about what happens if the file:// path you point
> > at is
> > owned by another user and isn't writable.
> 
> Thanks for pointing this out. Looks like it enters an infinite loop:
> the
> do_rootfs task is stuck at 3% and a worker process pegs a core to
> 100%.
> 
> Without this change, do_rootfs gets stuck at 12%, worker pegging a
> core
> if the feed is owned by another user with no write permissions.
> 
> This was unexpected :) I'll roll up my sleeves and start digging.
> 
> Do you have any pointers about what might be happening?

I was expecting it to error, not hang. If I had to totally guess, I'd
guess at the bb.utils.lockfile() hanging.

Cheers,

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

[OE-core] [sumo] [PATCH v2] gnupg: CVE-2018-9234

[Sinan Kaya]

* CVE-2018-9234
GnuPG 2.2.4 and 2.2.5 does not enforce a configuration in which key
certification requires an offline master Certify key, which results
in apparently valid certifications that occurred only with access to
a signing subkey.

Affects gnupg <= 2.2.5

CVE: CVE-2018-9234
Ref: https://access.redhat.com/security/cve/cve-2018-9234
Signed-off-by: Sinan Kaya 
---
 .../gnupg/gnupg/CVE-2018-9234.patch   | 27 +++
 meta/recipes-support/gnupg/gnupg_2.2.4.bb |  1 +
 2 files changed, 28 insertions(+)
 create mode 100644 meta/recipes-support/gnupg/gnupg/CVE-2018-9234.patch

diff --git a/meta/recipes-support/gnupg/gnupg/CVE-2018-9234.patch 
b/meta/recipes-support/gnupg/gnupg/CVE-2018-9234.patch
new file mode 100644
index 00..450dc35212
--- /dev/null
+++ b/meta/recipes-support/gnupg/gnupg/CVE-2018-9234.patch
@@ -0,0 +1,27 @@
+From ce055269c80f6e7c1393c0deec7bc5f0d37895ea Mon Sep 17 00:00:00 2001
+From: Sinan Kaya 
+Date: Sun, 23 Sep 2018 04:05:47 +
+Subject: [PATCH] g10: Fix filtering by PK->REQ_USAGE
+
+Upstream-Status: Backport 
[https://dev.gnupg.org/rGa17d2d1f690ebe5d005b4589a5fe378b6487c657]
+Signed-off-by: Sinan Kaya 
+---
+ g10/getkey.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/g10/getkey.c b/g10/getkey.c
+index e31e023..ca2500c 100644
+--- a/g10/getkey.c
 b/g10/getkey.c
+@@ -1810,6 +1810,8 @@ get_pubkey_byfprint (ctrl_t ctrl, PKT_public_key *pk, 
kbnode_t *r_keyblock,
+   ctx.items[0].mode = fprint_len == 16 ? KEYDB_SEARCH_MODE_FPR16
+   : KEYDB_SEARCH_MODE_FPR20;
+   memcpy (ctx.items[0].u.fpr, fprint, fprint_len);
++  if (pk)
++ctx.req_usage = pk->req_usage;
+   rc = lookup (ctrl, , 0, , _key);
+   if (!rc && pk)
+   pk_from_block (pk, kb, found_key);
+-- 
+2.19.0
+
diff --git a/meta/recipes-support/gnupg/gnupg_2.2.4.bb 
b/meta/recipes-support/gnupg/gnupg_2.2.4.bb
index d6bfaff377..d777fcb122 100644
--- a/meta/recipes-support/gnupg/gnupg_2.2.4.bb
+++ b/meta/recipes-support/gnupg/gnupg_2.2.4.bb
@@ -15,6 +15,7 @@ SRC_URI = "${GNUPG_MIRROR}/${BPN}/${BPN}-${PV}.tar.bz2 \
file://0003-dirmngr-uses-libgpg-error.patch \
file://0004-autogen.sh-fix-find-version-for-beta-checking.patch \
file://CVE-2018-12020.patch \
+   file://CVE-2018-9234.patch \
   "
 SRC_URI_append_class-native = " 
file://0001-configure.ac-use-a-custom-value-for-the-location-of-.patch"
 
-- 
2.19.0

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

Re: [OE-core] [PATCH] layer.conf: Add thud to LAYERSERIES_CORENAMES

[Scott Rifenbark]

Hi,

Manual updated for LAYERSERIES_COMPAT variable.  All examples use ENTITY
variables so as releases change the examples do not go stale.

Scott

On Mon, Sep 24, 2018 at 4:30 AM Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> With the release approaching, add thud to LAYERSERIES_CORENAMES and update
> oe-core to use this release series. "sumo" will be removed during M4 in
> the next couple of weeks so people need to start updating their master
> layers in preperation for release.
>
> Signed-off-by: Richard Purdie 
> ---
>  meta/conf/layer.conf | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf
> index 2cbe952801f..0728c51e5fd 100644
> --- a/meta/conf/layer.conf
> +++ b/meta/conf/layer.conf
> @@ -7,12 +7,12 @@ BBFILE_COLLECTIONS += "core"
>  BBFILE_PATTERN_core = "^${LAYERDIR}/"
>  BBFILE_PRIORITY_core = "5"
>
> -LAYERSERIES_CORENAMES = "sumo"
> +LAYERSERIES_CORENAMES = "sumo thud"
>
>  # This should only be incremented on significant changes that will
>  # cause compatibility issues with other layers
>  LAYERVERSION_core = "11"
> -LAYERSERIES_COMPAT_core = "sumo"
> +LAYERSERIES_COMPAT_core = "thud"
>
>  BBLAYERS_LAYERINDEX_NAME_core = "openembedded-core"
>
> --
> 2.17.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] ✗ patchtest: failure for gnupg: CVE-2018-9234

[Patchwork]

== Series Details ==

Series: gnupg: CVE-2018-9234
Revision: 1
URL   : https://patchwork.openembedded.org/series/14197/
State : failure

== Summary ==


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



* Issue Upstream-Status is in incorrect format 
[test_upstream_status_presence_format] 
  Suggested fixFix Upstream-Status format in CVE-2018-9234.patch
  Current  Upstream-Status: backport 
[https://dev.gnupg.org/rGa17d2d1f690ebe5d005b4589a5fe378b6487c657]
  Standard format  Upstream-Status: 
  Valid status Pending, Accepted, Backport, Denied, Inappropriate [reason], 
Submitted [where]



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

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

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

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

[Jolley, Stephen K]

All,



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



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



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



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



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



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


Thanks,


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

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

[OE-core] [PATCH] checklayer: avoid recursive loop in add_layer_dependencies

[Nicolas Dechesne]

When Layer A and Layer B depend on each other, then we will end up in a
recursive loop in function recurse_dependencies(). To avoid such situation
before making the recursive function call we check whether or not we have
already processed this layer.

e.g. without this patch, running this script on layers with dependency loops, 
we are seeing:

$ yocto-check-layer -d  /srv/work/oe/meta-openembedded/
INFO: Detected layers:
INFO: meta-python: LayerType.SOFTWARE, 
/srv/work/oe/meta-openembedded/meta-python
INFO: meta-filesystems: LayerType.SOFTWARE, 
/srv/work/oe/meta-openembedded/meta-filesystems
INFO: meta-gnome: LayerType.SOFTWARE, /srv/work/oe/meta-openembedded/meta-gnome
INFO: meta-xfce: LayerType.SOFTWARE, /srv/work/oe/meta-openembedded/meta-xfce
INFO: meta-networking: LayerType.SOFTWARE, 
/srv/work/oe/meta-openembedded/meta-networking
INFO: meta-initramfs: LayerType.SOFTWARE, 
/srv/work/oe/meta-openembedded/meta-initramfs
INFO: meta-oe: LayerType.SOFTWARE, /srv/work/oe/meta-openembedded/meta-oe
INFO: meta-multimedia: LayerType.SOFTWARE, 
/srv/work/oe/meta-openembedded/meta-multimedia
INFO: meta-perl: LayerType.SOFTWARE, /srv/work/oe/meta-openembedded/meta-perl
INFO: meta-webserver: LayerType.SOFTWARE, 
/srv/work/oe/meta-openembedded/meta-webserver
INFO:
INFO: Setting up for meta-python(LayerType.SOFTWARE), 
/srv/work/oe/meta-openembedded/meta-python
DEBUG: Processing dependencies core openembedded-layer for layer meta-python.
DEBUG: Processing dependencies core networking-layer for layer meta-oe.
DEBUG: Processing dependencies core openembedded-layer meta-python for layer 
meta-networking.
DEBUG: Processing dependencies core networking-layer for layer meta-oe.
DEBUG: Processing dependencies core openembedded-layer meta-python for layer 
meta-networking.
DEBUG: Processing dependencies core networking-layer for layer meta-oe.
DEBUG: Processing dependencies core openembedded-layer meta-python for layer 
meta-networking.
DEBUG: Processing dependencies core networking-layer for layer meta-oe.
DEBUG: Processing dependencies core openembedded-layer meta-python for layer 
meta-networking.
DEBUG: Processing dependencies core networking-layer for layer meta-oe.
DEBUG: Processing dependencies core openembedded-layer meta-python for layer 
meta-networking.
DEBUG: Processing dependencies core networking-layer for layer meta-oe.
DEBUG: Processing dependencies core openembedded-layer meta-python for layer 
meta-networking.
DEBUG: Processing dependencies core networking-layer for layer meta-oe.
DEBUG: Processing dependencies core openembedded-layer meta-python for layer 
meta-networking.
DEBUG: Processing dependencies core networking-layer for layer meta-oe.
DEBUG: Processing dependencies core openembedded-layer meta-python for layer 
meta-networking.
DEBUG: Processing dependencies core networking-layer for layer meta-oe.
DEBUG: Processing dependencies core openembedded-layer meta-python for layer 
meta-networking.
DEBUG: Processing dependencies core networking-layer for layer meta-oe.
DEBUG: Processing dependencies core openembedded-layer meta-python for layer 
meta-networking.
DEBUG: Processing dependencies core networking-layer for layer meta-oe.
DEBUG: Processing dependencies core openembedded-layer meta-python for layer 
meta-networking.
...
...
...
[keep repeating]

This patch fixes this situation.

Signed-off-by: Nicolas Dechesne 
---
 scripts/lib/checklayer/__init__.py | 4 
 1 file changed, 4 insertions(+)

diff --git a/scripts/lib/checklayer/__init__.py 
b/scripts/lib/checklayer/__init__.py
index 2618416fab..7788041843 100644
--- a/scripts/lib/checklayer/__init__.py
+++ b/scripts/lib/checklayer/__init__.py
@@ -167,6 +167,10 @@ def add_layer_dependencies(bblayersconf, layer, layers, 
logger):
 # multiple errors at once
 if ret is not None and layer_depend not in ret:
 ret.append(layer_depend)
+else:
+# we might have processed this dependency already, in which 
case
+# we should not do it again (avoid recursive loop)
+continue
 
 # Recursively process...
 if 'collections' not in layer_depend:
-- 
2.18.0

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

[OE-core] [sumo] [PATCH v1] gnupg: CVE-2018-9234

[Sinan Kaya]

* CVE-2018-9234
GnuPG 2.2.4 and 2.2.5 does not enforce a configuration in which key
certification requires an offline master Certify key, which results
in apparently valid certifications that occurred only with access to
a signing subkey.

Affects gnupg <= 2.2.5

CVE: CVE-2018-9234
Ref: https://access.redhat.com/security/cve/cve-2018-9234
Signed-off-by: Sinan Kaya 
---
 .../gnupg/gnupg/CVE-2018-9234.patch   | 27 +++
 meta/recipes-support/gnupg/gnupg_2.2.4.bb |  1 +
 2 files changed, 28 insertions(+)
 create mode 100644 meta/recipes-support/gnupg/gnupg/CVE-2018-9234.patch

diff --git a/meta/recipes-support/gnupg/gnupg/CVE-2018-9234.patch 
b/meta/recipes-support/gnupg/gnupg/CVE-2018-9234.patch
new file mode 100644
index 00..458616ee1d
--- /dev/null
+++ b/meta/recipes-support/gnupg/gnupg/CVE-2018-9234.patch
@@ -0,0 +1,27 @@
+From ce055269c80f6e7c1393c0deec7bc5f0d37895ea Mon Sep 17 00:00:00 2001
+From: Sinan Kaya 
+Date: Sun, 23 Sep 2018 04:05:47 +
+Subject: [PATCH] g10: Fix filtering by PK->REQ_USAGE
+
+Upstream-Status: backport 
[https://dev.gnupg.org/rGa17d2d1f690ebe5d005b4589a5fe378b6487c657]
+Signed-off-by: Sinan Kaya 
+---
+ g10/getkey.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/g10/getkey.c b/g10/getkey.c
+index e31e023..ca2500c 100644
+--- a/g10/getkey.c
 b/g10/getkey.c
+@@ -1810,6 +1810,8 @@ get_pubkey_byfprint (ctrl_t ctrl, PKT_public_key *pk, 
kbnode_t *r_keyblock,
+   ctx.items[0].mode = fprint_len == 16 ? KEYDB_SEARCH_MODE_FPR16
+   : KEYDB_SEARCH_MODE_FPR20;
+   memcpy (ctx.items[0].u.fpr, fprint, fprint_len);
++  if (pk)
++ctx.req_usage = pk->req_usage;
+   rc = lookup (ctrl, , 0, , _key);
+   if (!rc && pk)
+   pk_from_block (pk, kb, found_key);
+-- 
+2.19.0
+
diff --git a/meta/recipes-support/gnupg/gnupg_2.2.4.bb 
b/meta/recipes-support/gnupg/gnupg_2.2.4.bb
index d6bfaff377..d777fcb122 100644
--- a/meta/recipes-support/gnupg/gnupg_2.2.4.bb
+++ b/meta/recipes-support/gnupg/gnupg_2.2.4.bb
@@ -15,6 +15,7 @@ SRC_URI = "${GNUPG_MIRROR}/${BPN}/${BPN}-${PV}.tar.bz2 \
file://0003-dirmngr-uses-libgpg-error.patch \
file://0004-autogen.sh-fix-find-version-for-beta-checking.patch \
file://CVE-2018-12020.patch \
+   file://CVE-2018-9234.patch \
   "
 SRC_URI_append_class-native = " 
file://0001-configure.ac-use-a-custom-value-for-the-location-of-.patch"
 
-- 
2.19.0

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

Re: [OE-core] [PATCH] rootfs: always update the opkg index

[Ioan-Adrian Ratiu]

On Mon, 24 Sep 2018, Richard Purdie  wrote:
> On Mon, 2018-09-24 at 16:25 +0300, Ioan-Adrian Ratiu wrote:
>> The previous logic assumed that if $BUILD_IMAGES_FROM_FEEDS=1 then a
>> complete set of ipk feeds from which to build the image is already
>> present under $IPK_FEED_URIS at do_rootfs runtime.
>> 
>> $IPK_FEED_URIS usually contains "file://${DEPLOY_DIR_IPK}" which
>> renders the above assumption bad because some recipes in the current
>> build can contain code like do_install[nostamp] = "1" which will
>> cause
>> rebuilds bumping $PR and invalidating the index.
>> 
>> Even when the index is manually re-created before an image build
>> ("bitbake package-index"), the nostamp will cause failures because
>> the
>> dependency gets rebuilt before do_rootfs in the "bitbake "
>> call.
>> 
>> So make the opkg rootfs index logic the same as for rpm/deb, to
>> always
>> update the index in $DEPLOY_DIR_IPK to fix the above nostamp failure.
>> 
>> Feeds outside $DEPLOY_DIR_IPK continue to work as usual.
>
> Is this with master or an older branch?

I've extensively tested this with Sumo, on master I could only verify
the build passes and a minimal image boots.

>
> With master, a copy of the feed is constructed under WORKDIR which is
> then indexed since other image generation or package writes could occur
> and the index isn't static. I'm guessing it doesn't do this for
> external feeds and assumes those feeds are static.

My description of the problem mirrors my understanding of the feed
construction process which might be limited especially if it changed on
master post-Sumo, but the answer is yes, external feeds are assumed
static.

>
> I am wondering what happens if you put a remote (http://) url into this
> though? Does that still work or does it break?

It still works, we're using http paths all the time in our distro
(public feed server is at http://download.ni.com/ni-linux-rt/)

>
> I'm also worried about what happens if the file:// path you point at is
> owned by another user and isn't writable.

Thanks for pointing this out. Looks like it enters an infinite loop: the
do_rootfs task is stuck at 3% and a worker process pegs a core to 100%.

Without this change, do_rootfs gets stuck at 12%, worker pegging a core
if the feed is owned by another user with no write permissions.

This was unexpected :) I'll roll up my sleeves and start digging.

Do you have any pointers about what might be happening?

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

Re: [OE-core] [PATCH] kernel.bbclass: allow exporting files from kernel recipes to sysroot

[richard . purdie]

On Mon, 2018-09-24 at 14:19 +, mikko.rap...@bmw.de wrote:
> My only complaint is that it's not obvious in a kernel recipe that
> more than do_install() is needed to export files to sysroot.
> It's easy to miss the sysroot_stage_all_append() step.

I think that becomes a documentation problem. The bbclass helper may
also help?

> Overwriting files from kernel recipe fails when they are used to
> prepare sysroots for user recipes, but not when the kernel recipe is
> build:
> 
> ERROR: linux-image-1.0.0-r21 do_prepare_recipe_sysroot: The file
> /usr/include/scsi/scsi_bsg_fc.h is installed by both linux-libc-
> headers and linux, aborting
> ERROR: linux-image-1.0.0-r21 do_prepare_recipe_sysroot: Function
> failed: extend_recipe_sysroot
> 
> In this case linux recipe added kernel specific headers to
> /usr/include which conflict with linux-libc-headers and this was only
> cought when building the kernel image.

That is true, not sure how exactly we'd detect that earlier either (in
a way which doesn't kill performance or involve special cases). I'm
open to ideas, documentation is the main tool I think we have here.

Cheers,

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

Re: [OE-core] [PATCH] kernel.bbclass: allow exporting files from kernel recipes to sysroot

[Mikko.Rapeli]

On Mon, Sep 24, 2018 at 02:56:49PM +0100, richard.pur...@linuxfoundation.org 
wrote:
> On Mon, 2018-09-24 at 09:43 -0400, Bruce Ashfield wrote:
> > > On Mon, 2018-09-24 at 13:20 +, mikko.rap...@bmw.de wrote:
> > > > On Mon, Sep 24, 2018 at 02:11:13PM +0100, Richard Purdie wrote:
> > > > > On Mon, 2018-09-24 at 12:19 +, mikko.rap...@bmw.de wrote:
> > > > > > > That was one old way, but not the only. And not for
> > > > > > > exposing
> > > > > > > non
> > > > > > > uapi
> > > > > > > headers.
> > > > > > 
> > > > > > What other ways exist?
> > > > > > 
> > > > > > I don't care how, but I must export custom kernel specific
> > > > > > headers
> > > > > > and
> > > > > > other files to other recipes in a build in ways which are
> > > > > > compatible
> > > > > > with
> > > > > > yocto upstream.
> > > > > > 
> > > > > > I have not seen any documented ways for this.
> > > > > 
> > > > > It may not be documented, perhaps because its actually very
> > > > > simple.
> > > > > 
> > > > > Any recipe can expose headers into the recipe sysroot, they
> > > > > simply
> > > > > install them where needed in do_install as normal.
> > > > > 
> > > > > So all you need is a recipe which installs the right headers
> > > > > and
> > > > > then
> > > > > you DEPEND on that recipe. Where that recipe gets the headers
> > > > > isn't
> > > > > relevant.
> > > > 
> > > > No, this does not work on sumo. My patch is needed for this to
> > > > work.
> > > > 
> > > > Without my patch, users of kernel.bbclass have zero files in
> > > > tmp/sysroot-components even if they install extra files and extra
> > > > header only binary packages.
> > > > 
> > > > A generated image or SDK will have the files if the binary
> > > > package is
> > > > installed but sysroot not.
> > > 
> > > I was replying from the perspective of how this should work in
> > > general.
> > > I agree that for this to work with a kernel recipe we do need the
> > > change that started this thread and that is probably a reasonable
> > > thing
> > > to do.
> > 
> > We have a Yocto bugzilla that can be closed if you are ok with the
> > approach.
> > 
> > To answer the other question about what I've done (and proposed
> > before) was
> > to maintain the kernel.bbclass protections, all call the staging
> > routines myself.
> > 
> > i.e.
> > 
> > do_install_append() {
> > make headers_install
> > INSTALL_HDR_PATH=${D}${KERNEL_ALT_HEADER_DIR}
> > 
> > # remove export artifacts
> > find ${D}${KERNEL_ALT_HEADER_DIR} -name .install -exec rm {}
> > \;
> > find ${D}${KERNEL_ALT_HEADER_DIR} -name ..install.cmd -exec
> > rm {} \;
> > }
> > 
> > sysroot_stage_all_append() {
> > sysroot_stage_dir ${D}${KERNEL_ALT_HEADER_DIR}
> > ${SYSROOT_DESTDIR}${KERNEL_ALT_HEADER_DIR}
> > }
> > 
> > And that works to get things exported.
> 
> I'm fine with this approach, I'm kind of surprised anyone thinks
> otherwise as I've always assumed this was what people were doing!
> 
> I'd propose that:
> 
> a) We document the above approach. I prefer it to Mikko's patch since
> it doesn't mess with the blacklist and installs exactly what the recipe
> wants to install which is how we normally write recipes.
> b) To document it, I suggest a comment/reference in kernel.bbclass and
> we add something somewhere in the manual. Adding Scott Rifenbark to cc
> so he can help us sort this out.
> c) Close out the bug Bruce mentions with this documentation as a
> reference.
> 
> I think this means we probably don't need Mikko's patch and it is
> mainly a documentation issue?

My only complaint is that it's not obvious in a kernel recipe that
more than do_install() is needed to export files to sysroot.
It's easy to miss the sysroot_stage_all_append() step.

Overwriting files from kernel recipe fails when they are used to prepare
sysroots for user recipes, but not when the kernel recipe is build:

ERROR: linux-image-1.0.0-r21 do_prepare_recipe_sysroot: The file 
/usr/include/scsi/scsi_bsg_fc.h is installed by both linux-libc-headers and 
linux, aborting
ERROR: linux-image-1.0.0-r21 do_prepare_recipe_sysroot: Function failed: 
extend_recipe_sysroot

In this case linux recipe added kernel specific headers to /usr/include
which conflict with linux-libc-headers and this was only cought when building
the kernel image.

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

Re: [OE-core] [PATCH] kernel.bbclass: allow exporting files from kernel recipes to sysroot

[richard . purdie]

On Mon, 2018-09-24 at 13:55 +, mikko.rap...@bmw.de wrote:
> It would be nice for kernel.bbclass to help creating the custom
> kernel specific -dev package with headers, and it would be nice to
> have a kernel-headers.bbclass to help users to find them by adding
> the path to default include paths for the recipe. And while writing
> wishlists, would be nice to support multiple kernel recipes per
> machine. We forced a second recipe by cloning the kernel and other
> bbclasses and added a different prefix...

FWIW multiple kernels is a long desired feature and I'd be happy to see
a patch which allows the kernel classes to be configured to build a
second kernel with a different package namespace.

The kernel-headers class may be ok too and simplify the documentation
process, particularly if the subdir to put the headers in was
configurable.

Cheers,

Richard

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

Re: [OE-core] [PATCH] rootfs: always update the opkg index

[Richard Purdie]

On Mon, 2018-09-24 at 16:25 +0300, Ioan-Adrian Ratiu wrote:
> The previous logic assumed that if $BUILD_IMAGES_FROM_FEEDS=1 then a
> complete set of ipk feeds from which to build the image is already
> present under $IPK_FEED_URIS at do_rootfs runtime.
> 
> $IPK_FEED_URIS usually contains "file://${DEPLOY_DIR_IPK}" which
> renders the above assumption bad because some recipes in the current
> build can contain code like do_install[nostamp] = "1" which will
> cause
> rebuilds bumping $PR and invalidating the index.
> 
> Even when the index is manually re-created before an image build
> ("bitbake package-index"), the nostamp will cause failures because
> the
> dependency gets rebuilt before do_rootfs in the "bitbake "
> call.
> 
> So make the opkg rootfs index logic the same as for rpm/deb, to
> always
> update the index in $DEPLOY_DIR_IPK to fix the above nostamp failure.
> 
> Feeds outside $DEPLOY_DIR_IPK continue to work as usual.

Is this with master or an older branch?

With master, a copy of the feed is constructed under WORKDIR which is
then indexed since other image generation or package writes could occur
and the index isn't static. I'm guessing it doesn't do this for
external feeds and assumes those feeds are static. 

I am wondering what happens if you put a remote (http://) url into this
though? Does that still work or does it break?

I'm also worried about what happens if the file:// path you point at is
owned by another user and isn't writable.

Cheers,

Richard




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

Re: [OE-core] [PATCH] kernel.bbclass: allow exporting files from kernel recipes to sysroot

[richard . purdie]

On Mon, 2018-09-24 at 09:43 -0400, Bruce Ashfield wrote:
> > On Mon, 2018-09-24 at 13:20 +, mikko.rap...@bmw.de wrote:
> > > On Mon, Sep 24, 2018 at 02:11:13PM +0100, Richard Purdie wrote:
> > > > On Mon, 2018-09-24 at 12:19 +, mikko.rap...@bmw.de wrote:
> > > > > > That was one old way, but not the only. And not for
> > > > > > exposing
> > > > > > non
> > > > > > uapi
> > > > > > headers.
> > > > > 
> > > > > What other ways exist?
> > > > > 
> > > > > I don't care how, but I must export custom kernel specific
> > > > > headers
> > > > > and
> > > > > other files to other recipes in a build in ways which are
> > > > > compatible
> > > > > with
> > > > > yocto upstream.
> > > > > 
> > > > > I have not seen any documented ways for this.
> > > > 
> > > > It may not be documented, perhaps because its actually very
> > > > simple.
> > > > 
> > > > Any recipe can expose headers into the recipe sysroot, they
> > > > simply
> > > > install them where needed in do_install as normal.
> > > > 
> > > > So all you need is a recipe which installs the right headers
> > > > and
> > > > then
> > > > you DEPEND on that recipe. Where that recipe gets the headers
> > > > isn't
> > > > relevant.
> > > 
> > > No, this does not work on sumo. My patch is needed for this to
> > > work.
> > > 
> > > Without my patch, users of kernel.bbclass have zero files in
> > > tmp/sysroot-components even if they install extra files and extra
> > > header only binary packages.
> > > 
> > > A generated image or SDK will have the files if the binary
> > > package is
> > > installed but sysroot not.
> > 
> > I was replying from the perspective of how this should work in
> > general.
> > I agree that for this to work with a kernel recipe we do need the
> > change that started this thread and that is probably a reasonable
> > thing
> > to do.
> 
> We have a Yocto bugzilla that can be closed if you are ok with the
> approach.
> 
> To answer the other question about what I've done (and proposed
> before) was
> to maintain the kernel.bbclass protections, all call the staging
> routines myself.
> 
> i.e.
> 
> do_install_append() {
> make headers_install
> INSTALL_HDR_PATH=${D}${KERNEL_ALT_HEADER_DIR}
> 
> # remove export artifacts
> find ${D}${KERNEL_ALT_HEADER_DIR} -name .install -exec rm {}
> \;
> find ${D}${KERNEL_ALT_HEADER_DIR} -name ..install.cmd -exec
> rm {} \;
> }
> 
> sysroot_stage_all_append() {
> sysroot_stage_dir ${D}${KERNEL_ALT_HEADER_DIR}
> ${SYSROOT_DESTDIR}${KERNEL_ALT_HEADER_DIR}
> }
> 
> And that works to get things exported.

I'm fine with this approach, I'm kind of surprised anyone thinks
otherwise as I've always assumed this was what people were doing!

I'd propose that:

a) We document the above approach. I prefer it to Mikko's patch since
it doesn't mess with the blacklist and installs exactly what the recipe
wants to install which is how we normally write recipes.
b) To document it, I suggest a comment/reference in kernel.bbclass and
we add something somewhere in the manual. Adding Scott Rifenbark to cc
so he can help us sort this out.
c) Close out the bug Bruce mentions with this documentation as a
reference.

I think this means we probably don't need Mikko's patch and it is
mainly a documentation issue?

In case people wonder, the thing I really care about in this is people
are not patching linux-libc-headers. That warning still very much
applies.

I did also check and the code in question was introduced by Bruce:
http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/classes/kernel.bb
class?id=46cdaf1c7bc597735d926af6a46f9483f7e57ce5 3.5 years ago, there
were not reasons we were not installing headers there afaict, we have
just been assuming people append to sysroot_stage_all.

Cheers,

Richard

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

Re: [OE-core] [PATCH] kernel.bbclass: allow exporting files from kernel recipes to sysroot

[Mikko.Rapeli]

On Mon, Sep 24, 2018 at 09:48:26AM -0400, Bruce Ashfield wrote:
> On Mon, Sep 24, 2018 at 9:46 AM, Bruce Ashfield
>  wrote:
> > On Mon, Sep 24, 2018 at 9:44 AM,   
> > wrote:
> >> On Mon, 2018-09-24 at 13:42 +, mikko.rap...@bmw.de wrote:
> >>> On Mon, Sep 24, 2018 at 02:38:36PM +0100, richard.purdie@linuxfoundat
> >>> ion.org wrote:
> >>> > I was replying from the perspective of how this should work in
> >>> > general.
> >>> > I agree that for this to work with a kernel recipe we do need the
> >>> > change that started this thread and that is probably a reasonable
> >>> > thing
> >>> > to do.
> >>>
> >>> Good, then my patch is not going in the wrong direction.
> >>>
> >>> Remaining problem is if file overwrites will be detected or not so
> >>> that
> >>> accidental overrides of files in linux-libc-headers from kernel
> >>> recipes
> >>> should not be possible...
> >>
> >> That is a general problem and the core sstate code shouldn't let that
> >> happen these days so I think that is already covered?
> >
> > Yep, it should be covered. I was just looking for confirmation.
> >
> > Can everyone have a look at:
> >
> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=5305
> >
> > And confirm that it can be closed by this .. ? I suggested my approach
> > in that bug, but it
> > never went anywhere at the time.
> 
> Sorry for all the email, I hit send a bit too soon.
> 
> The only issue that would remain for that bug is that there's no
> standard/default location for those exported extra headers, and it
> is up to the kernel recipe packager to make sure that their recipes
> know where to look for them.
> 
> I'm not convinced there has to be a standard location for them, so
> I'll all for closing that old bug.

It would be nice for kernel.bbclass to help creating the custom kernel specific
-dev package with headers, and it would be nice to have a kernel-headers.bbclass
to help users to find them by adding the path to default include paths for
the recipe. And while writing wishlists, would be nice to support multiple
kernel recipes per machine. We forced a second recipe by cloning the
kernel and other bbclasses and added a different prefix...

But I'm ok with my patch and doing other things per recipe for now.

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

Re: [OE-core] [PATCH] kernel.bbclass: allow exporting files from kernel recipes to sysroot

[Bruce Ashfield]

On Mon, Sep 24, 2018 at 9:46 AM, Bruce Ashfield
 wrote:
> On Mon, Sep 24, 2018 at 9:44 AM,   wrote:
>> On Mon, 2018-09-24 at 13:42 +, mikko.rap...@bmw.de wrote:
>>> On Mon, Sep 24, 2018 at 02:38:36PM +0100, richard.purdie@linuxfoundat
>>> ion.org wrote:
>>> > I was replying from the perspective of how this should work in
>>> > general.
>>> > I agree that for this to work with a kernel recipe we do need the
>>> > change that started this thread and that is probably a reasonable
>>> > thing
>>> > to do.
>>>
>>> Good, then my patch is not going in the wrong direction.
>>>
>>> Remaining problem is if file overwrites will be detected or not so
>>> that
>>> accidental overrides of files in linux-libc-headers from kernel
>>> recipes
>>> should not be possible...
>>
>> That is a general problem and the core sstate code shouldn't let that
>> happen these days so I think that is already covered?
>
> Yep, it should be covered. I was just looking for confirmation.
>
> Can everyone have a look at:
>
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=5305
>
> And confirm that it can be closed by this .. ? I suggested my approach
> in that bug, but it
> never went anywhere at the time.

Sorry for all the email, I hit send a bit too soon.

The only issue that would remain for that bug is that there's no
standard/default location for those exported extra headers, and it
is up to the kernel recipe packager to make sure that their recipes
know where to look for them.

I'm not convinced there has to be a standard location for them, so
I'll all for closing that old bug.

Bruce

>
> Bruce
>
>>
>> Cheers,
>>
>> Richard
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end"



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

Re: [OE-core] [PATCH] kernel.bbclass: allow exporting files from kernel recipes to sysroot

[Bruce Ashfield]

On Mon, Sep 24, 2018 at 9:44 AM,   wrote:
> On Mon, 2018-09-24 at 13:42 +, mikko.rap...@bmw.de wrote:
>> On Mon, Sep 24, 2018 at 02:38:36PM +0100, richard.purdie@linuxfoundat
>> ion.org wrote:
>> > I was replying from the perspective of how this should work in
>> > general.
>> > I agree that for this to work with a kernel recipe we do need the
>> > change that started this thread and that is probably a reasonable
>> > thing
>> > to do.
>>
>> Good, then my patch is not going in the wrong direction.
>>
>> Remaining problem is if file overwrites will be detected or not so
>> that
>> accidental overrides of files in linux-libc-headers from kernel
>> recipes
>> should not be possible...
>
> That is a general problem and the core sstate code shouldn't let that
> happen these days so I think that is already covered?

Yep, it should be covered. I was just looking for confirmation.

Can everyone have a look at:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=5305

And confirm that it can be closed by this .. ? I suggested my approach
in that bug, but it
never went anywhere at the time.

Bruce

>
> Cheers,
>
> Richard



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

Re: [OE-core] [PATCH] kernel.bbclass: allow exporting files from kernel recipes to sysroot

[richard . purdie]

On Mon, 2018-09-24 at 13:42 +, mikko.rap...@bmw.de wrote:
> On Mon, Sep 24, 2018 at 02:38:36PM +0100, richard.purdie@linuxfoundat
> ion.org wrote:
> > I was replying from the perspective of how this should work in
> > general.
> > I agree that for this to work with a kernel recipe we do need the
> > change that started this thread and that is probably a reasonable
> > thing
> > to do.
> 
> Good, then my patch is not going in the wrong direction.
> 
> Remaining problem is if file overwrites will be detected or not so
> that
> accidental overrides of files in linux-libc-headers from kernel
> recipes
> should not be possible...

That is a general problem and the core sstate code shouldn't let that
happen these days so I think that is already covered?

Cheers,

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

Re: [OE-core] [PATCH] kernel.bbclass: allow exporting files from kernel recipes to sysroot

[Bruce Ashfield]

On Mon, Sep 24, 2018 at 9:38 AM,   wrote:
> On Mon, 2018-09-24 at 13:20 +, mikko.rap...@bmw.de wrote:
>> On Mon, Sep 24, 2018 at 02:11:13PM +0100, Richard Purdie wrote:
>> > On Mon, 2018-09-24 at 12:19 +, mikko.rap...@bmw.de wrote:
>> > > > That was one old way, but not the only. And not for exposing
>> > > > non
>> > > > uapi
>> > > > headers.
>> > >
>> > > What other ways exist?
>> > >
>> > > I don't care how, but I must export custom kernel specific
>> > > headers
>> > > and
>> > > other files to other recipes in a build in ways which are
>> > > compatible
>> > > with
>> > > yocto upstream.
>> > >
>> > > I have not seen any documented ways for this.
>> >
>> > It may not be documented, perhaps because its actually very simple.
>> >
>> > Any recipe can expose headers into the recipe sysroot, they simply
>> > install them where needed in do_install as normal.
>> >
>> > So all you need is a recipe which installs the right headers and
>> > then
>> > you DEPEND on that recipe. Where that recipe gets the headers isn't
>> > relevant.
>>
>> No, this does not work on sumo. My patch is needed for this to work.
>>
>> Without my patch, users of kernel.bbclass have zero files in
>> tmp/sysroot-components even if they install extra files and extra
>> header only binary packages.
>>
>> A generated image or SDK will have the files if the binary package is
>> installed but sysroot not.
>
> I was replying from the perspective of how this should work in general.
> I agree that for this to work with a kernel recipe we do need the
> change that started this thread and that is probably a reasonable thing
> to do.

We have a Yocto bugzilla that can be closed if you are ok with the approach.

To answer the other question about what I've done (and proposed before) was
to maintain the kernel.bbclass protections, all call the staging
routines myself.

i.e.

do_install_append() {
make headers_install INSTALL_HDR_PATH=${D}${KERNEL_ALT_HEADER_DIR}

# remove export artifacts
find ${D}${KERNEL_ALT_HEADER_DIR} -name .install -exec rm {} \;
find ${D}${KERNEL_ALT_HEADER_DIR} -name ..install.cmd -exec rm {} \;
}

sysroot_stage_all_append() {
sysroot_stage_dir ${D}${KERNEL_ALT_HEADER_DIR}
${SYSROOT_DESTDIR}${KERNEL_ALT_HEADER_DIR}
}

And that works to get things exported.

Bruce

>
> Cheers,
>
> Richard
>
>
>



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

Re: [OE-core] [PATCH] kernel.bbclass: allow exporting files from kernel recipes to sysroot

[Mikko.Rapeli]

On Mon, Sep 24, 2018 at 02:38:36PM +0100, richard.pur...@linuxfoundation.org 
wrote:
> On Mon, 2018-09-24 at 13:20 +, mikko.rap...@bmw.de wrote:
> > On Mon, Sep 24, 2018 at 02:11:13PM +0100, Richard Purdie wrote:
> > > On Mon, 2018-09-24 at 12:19 +, mikko.rap...@bmw.de wrote:
> > > > > That was one old way, but not the only. And not for exposing
> > > > > non
> > > > > uapi
> > > > > headers.
> > > > 
> > > > What other ways exist?
> > > > 
> > > > I don't care how, but I must export custom kernel specific
> > > > headers
> > > > and
> > > > other files to other recipes in a build in ways which are
> > > > compatible
> > > > with
> > > > yocto upstream.
> > > > 
> > > > I have not seen any documented ways for this.
> > > 
> > > It may not be documented, perhaps because its actually very simple.
> > > 
> > > Any recipe can expose headers into the recipe sysroot, they simply
> > > install them where needed in do_install as normal.
> > > 
> > > So all you need is a recipe which installs the right headers and
> > > then
> > > you DEPEND on that recipe. Where that recipe gets the headers isn't
> > > relevant.
> > 
> > No, this does not work on sumo. My patch is needed for this to work.
> > 
> > Without my patch, users of kernel.bbclass have zero files in
> > tmp/sysroot-components even if they install extra files and extra
> > header only binary packages.
> > 
> > A generated image or SDK will have the files if the binary package is
> > installed but sysroot not.
> 
> I was replying from the perspective of how this should work in general.
> I agree that for this to work with a kernel recipe we do need the
> change that started this thread and that is probably a reasonable thing
> to do.

Good, then my patch is not going in the wrong direction.

Remaining problem is if file overwrites will be detected or not so that
accidental overrides of files in linux-libc-headers from kernel recipes
should not be possible...

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

Re: [OE-core] [PATCH] kernel.bbclass: allow exporting files from kernel recipes to sysroot

[richard . purdie]

On Mon, 2018-09-24 at 13:20 +, mikko.rap...@bmw.de wrote:
> On Mon, Sep 24, 2018 at 02:11:13PM +0100, Richard Purdie wrote:
> > On Mon, 2018-09-24 at 12:19 +, mikko.rap...@bmw.de wrote:
> > > > That was one old way, but not the only. And not for exposing
> > > > non
> > > > uapi
> > > > headers.
> > > 
> > > What other ways exist?
> > > 
> > > I don't care how, but I must export custom kernel specific
> > > headers
> > > and
> > > other files to other recipes in a build in ways which are
> > > compatible
> > > with
> > > yocto upstream.
> > > 
> > > I have not seen any documented ways for this.
> > 
> > It may not be documented, perhaps because its actually very simple.
> > 
> > Any recipe can expose headers into the recipe sysroot, they simply
> > install them where needed in do_install as normal.
> > 
> > So all you need is a recipe which installs the right headers and
> > then
> > you DEPEND on that recipe. Where that recipe gets the headers isn't
> > relevant.
> 
> No, this does not work on sumo. My patch is needed for this to work.
> 
> Without my patch, users of kernel.bbclass have zero files in
> tmp/sysroot-components even if they install extra files and extra
> header only binary packages.
> 
> A generated image or SDK will have the files if the binary package is
> installed but sysroot not.

I was replying from the perspective of how this should work in general.
I agree that for this to work with a kernel recipe we do need the
change that started this thread and that is probably a reasonable thing
to do.

Cheers,

Richard



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

[OE-core] [PATCH] rootfs: always update the opkg index

[Ioan-Adrian Ratiu]

The previous logic assumed that if $BUILD_IMAGES_FROM_FEEDS=1 then a
complete set of ipk feeds from which to build the image is already
present under $IPK_FEED_URIS at do_rootfs runtime.

$IPK_FEED_URIS usually contains "file://${DEPLOY_DIR_IPK}" which
renders the above assumption bad because some recipes in the current
build can contain code like do_install[nostamp] = "1" which will cause
rebuilds bumping $PR and invalidating the index.

Even when the index is manually re-created before an image build
("bitbake package-index"), the nostamp will cause failures because the
dependency gets rebuilt before do_rootfs in the "bitbake " call.

So make the opkg rootfs index logic the same as for rpm/deb, to always
update the index in $DEPLOY_DIR_IPK to fix the above nostamp failure.

Feeds outside $DEPLOY_DIR_IPK continue to work as usual.

Signed-off-by: Ioan-Adrian Ratiu 
---
 meta/lib/oe/rootfs.py | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py
index cdb86f7715..67ae281e47 100644
--- a/meta/lib/oe/rootfs.py
+++ b/meta/lib/oe/rootfs.py
@@ -853,9 +853,8 @@ class OpkgRootfs(DpkgOpkgRootfs):
 opkg_pre_process_cmds = self.d.getVar('OPKG_PREPROCESS_COMMANDS')
 opkg_post_process_cmds = self.d.getVar('OPKG_POSTPROCESS_COMMANDS')
 
-# update PM index files, unless users provide their own feeds
-if (self.d.getVar('BUILD_IMAGES_FROM_FEEDS') or "") != "1":
-self.pm.write_index()
+# update PM index files
+self.pm.write_index()
 
 execute_pre_post_process(self.d, opkg_pre_process_cmds)
 
-- 
2.19.0

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

Re: [OE-core] [PATCH] kernel.bbclass: allow exporting files from kernel recipes to sysroot

[Mikko.Rapeli]

On Mon, Sep 24, 2018 at 02:11:13PM +0100, Richard Purdie wrote:
> On Mon, 2018-09-24 at 12:19 +, mikko.rap...@bmw.de wrote:
> > > That was one old way, but not the only. And not for exposing non
> > > uapi
> > > headers.
> > 
> > What other ways exist?
> > 
> > I don't care how, but I must export custom kernel specific headers
> > and
> > other files to other recipes in a build in ways which are compatible
> > with
> > yocto upstream.
> > 
> > I have not seen any documented ways for this.
> 
> It may not be documented, perhaps because its actually very simple.
> 
> Any recipe can expose headers into the recipe sysroot, they simply
> install them where needed in do_install as normal.
> 
> So all you need is a recipe which installs the right headers and then
> you DEPEND on that recipe. Where that recipe gets the headers isn't
> relevant.

No, this does not work on sumo. My patch is needed for this to work.

Without my patch, users of kernel.bbclass have zero files in
tmp/sysroot-components even if they install extra files and extra header
only binary packages.

A generated image or SDK will have the files if the binary package is installed
but sysroot not.

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

Re: [OE-core] [PATCH] kernel.bbclass: allow exporting files from kernel recipes to sysroot

[Richard Purdie]

On Mon, 2018-09-24 at 12:19 +, mikko.rap...@bmw.de wrote:
> > That was one old way, but not the only. And not for exposing non
> > uapi
> > headers.
> 
> What other ways exist?
> 
> I don't care how, but I must export custom kernel specific headers
> and
> other files to other recipes in a build in ways which are compatible
> with
> yocto upstream.
> 
> I have not seen any documented ways for this.

It may not be documented, perhaps because its actually very simple.

Any recipe can expose headers into the recipe sysroot, they simply
install them where needed in do_install as normal.

So all you need is a recipe which installs the right headers and then
you DEPEND on that recipe. Where that recipe gets the headers isn't
relevant.

Cheers,

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

Re: [OE-core] [PATCH] kernel.bbclass: allow exporting files from kernel recipes to sysroot

[Mikko.Rapeli]

On Mon, Sep 24, 2018 at 08:12:53AM -0400, Bruce Ashfield wrote:
> On Mon, Sep 24, 2018 at 3:25 AM,   wrote:
> >> On Fri, Sep 21, 2018 at 7:49 AM, Mikko Rapeli  
> >> wrote:
> >> > This change enables kernel recipes to share files with other
> >> > recipes. Firmware, modules and kernel-depmod are still not shared
> >> > since according to git history they cause problems with multiarch,
> >> > but all others are allowed. Examples of shared files are
> >> > kernel version and recipe specific headers and scripts which
> >> > are not needed by common linux-libc-headers to bootstrap glibc.
> >> >
> >> > For example, if a kernel recipe wants to share headers, it can do:
> >> >
> >> > PACKAGES =+ "${PN}-headers"
> >> >
> >> > do_install_append() {
> >> > install -d "${D}${includedir}/${PN}"
> >> > oe_runmake INSTALL_HDR_PATH="${D}${includedir}/${PN}" headers_install
> >> }
> >>
> >> This is what I've always done in the past (and in fact, there's an
> >> open Yocto bug
> >> to track this), but I haven't actually needed to do what you are
> >> modifying in the
> >> bbclass itself.
> >
> > Without this patch, users of kernel.bbclass can provide the headers etc 
> > packages,
> > but other recipes can never see the files in their sysroot even if they 
> > depend
> > on the kernel recipe because kernel.bbclass has disabled sysroot_stage_all()
> > completely.
> 
> It doesn't need to be in a class, any kernel recipe can create a task to
> do this. The class implementation isn't special in this manner.
> 
> >
> > The recipes could define their own sysroot_stage_all() but I don't see
> > why kernel would be that special and why all of their installed files should
> > be excluded from build sysroots by default.
> 
> Exactly. It is because of the ability to clobber the libc-headers that is is
> special.
> 
> >
> > The old way to do this was to fork linux-libc-headers for the custom kernel
> > but now it has a big fat warning to not do this, but exposing header etc
> > files to other recipes to build against was still not resolved.
> 
> That was one old way, but not the only. And not for exposing non uapi
> headers.

What other ways exist?

I don't care how, but I must export custom kernel specific headers and
other files to other recipes in a build in ways which are compatible with
yocto upstream.

I have not seen any documented ways for this.

> >
> > With this patch the kernel recipe can just install the files needed and
> > users can see them unless they are filtered.
> 
> And as the warning points out, risk the libc-interface, which has caused
> many problems in the past .. and problems that are hard to detect and
> dig out at runtime.
> 
> >
> >> If you call the sysroot stage routines directly in that
> >> install_append, are you really
> >> not seeing the files appear in the recipe's sysroot ?
> >
> > Of course this can be done but why on earth is kernel so special that
> > it's installed files are not visible in sysroots by default?
> 
> because they clobber the uapi libc-headers :D
> 
> >
> > If certain files are problematic, they can be filtered out from the
> > sysroot like my patch tries to do.
> 
> Or we could catch that the clobbering is happening, and not let it happen.
> 
> >
> >> Have you confirmed that we get a warning/error from bitbake about
> >> conflicting files
> >> from multiple recipes if someone doesn't know to use a custom path for 
> >> their
> >> headers ? That has always been the main concern about allowing something 
> >> like
> >> this.
> >
> > No, but I do rely on this with other recipes as well. At least I know that
> > conflicting files warning will fail image and SDK generation.
> 
> For something that is being proposed as a general purpose addition to
> the core, it would probably be a good idea to test these extra cases.
> 
> >
> > I would expect that recipe specific sysroots don't allow conflicting files.
> 
> Agreed, but definitely worth testing and logging. That way the change
> won't be blamed for causing issues later.

If files from a recipe can replace files from another recipe when preparing
recipe specific sysroot we have bigger problems than just the kernel.

I can try test this out with the kernel recipe though.

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

Re: [OE-core] [PATCH] kernel.bbclass: allow exporting files from kernel recipes to sysroot

[Bruce Ashfield]

On Mon, Sep 24, 2018 at 3:25 AM,   wrote:
>> On Fri, Sep 21, 2018 at 7:49 AM, Mikko Rapeli  wrote:
>> > This change enables kernel recipes to share files with other
>> > recipes. Firmware, modules and kernel-depmod are still not shared
>> > since according to git history they cause problems with multiarch,
>> > but all others are allowed. Examples of shared files are
>> > kernel version and recipe specific headers and scripts which
>> > are not needed by common linux-libc-headers to bootstrap glibc.
>> >
>> > For example, if a kernel recipe wants to share headers, it can do:
>> >
>> > PACKAGES =+ "${PN}-headers"
>> >
>> > do_install_append() {
>> > install -d "${D}${includedir}/${PN}"
>> > oe_runmake INSTALL_HDR_PATH="${D}${includedir}/${PN}" headers_install
>> }
>>
>> This is what I've always done in the past (and in fact, there's an
>> open Yocto bug
>> to track this), but I haven't actually needed to do what you are
>> modifying in the
>> bbclass itself.
>
> Without this patch, users of kernel.bbclass can provide the headers etc 
> packages,
> but other recipes can never see the files in their sysroot even if they depend
> on the kernel recipe because kernel.bbclass has disabled sysroot_stage_all()
> completely.

It doesn't need to be in a class, any kernel recipe can create a task to
do this. The class implementation isn't special in this manner.

>
> The recipes could define their own sysroot_stage_all() but I don't see
> why kernel would be that special and why all of their installed files should
> be excluded from build sysroots by default.

Exactly. It is because of the ability to clobber the libc-headers that is is
special.

>
> The old way to do this was to fork linux-libc-headers for the custom kernel
> but now it has a big fat warning to not do this, but exposing header etc
> files to other recipes to build against was still not resolved.

That was one old way, but not the only. And not for exposing non uapi
headers.

>
> With this patch the kernel recipe can just install the files needed and
> users can see them unless they are filtered.

And as the warning points out, risk the libc-interface, which has caused
many problems in the past .. and problems that are hard to detect and
dig out at runtime.

>
>> If you call the sysroot stage routines directly in that
>> install_append, are you really
>> not seeing the files appear in the recipe's sysroot ?
>
> Of course this can be done but why on earth is kernel so special that
> it's installed files are not visible in sysroots by default?

because they clobber the uapi libc-headers :D

>
> If certain files are problematic, they can be filtered out from the
> sysroot like my patch tries to do.

Or we could catch that the clobbering is happening, and not let it happen.

>
>> Have you confirmed that we get a warning/error from bitbake about
>> conflicting files
>> from multiple recipes if someone doesn't know to use a custom path for their
>> headers ? That has always been the main concern about allowing something like
>> this.
>
> No, but I do rely on this with other recipes as well. At least I know that
> conflicting files warning will fail image and SDK generation.

For something that is being proposed as a general purpose addition to
the core, it would probably be a good idea to test these extra cases.

>
> I would expect that recipe specific sysroots don't allow conflicting files.

Agreed, but definitely worth testing and logging. That way the change
won't be blamed for causing issues later.

Bruce

>
> -Mikko



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

[OE-core] ✗ patchtest: failure for layer.conf: Add thud to LAYERSERIES_CORENAMES

[Patchwork]

== Series Details ==

Series: layer.conf: Add thud to LAYERSERIES_CORENAMES
Revision: 1
URL   : https://patchwork.openembedded.org/series/14195/
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 e3f5ceec69)



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] layer.conf: Add thud to LAYERSERIES_CORENAMES

[Richard Purdie]

With the release approaching, add thud to LAYERSERIES_CORENAMES and update
oe-core to use this release series. "sumo" will be removed during M4 in
the next couple of weeks so people need to start updating their master
layers in preperation for release.

Signed-off-by: Richard Purdie 
---
 meta/conf/layer.conf | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf
index 2cbe952801f..0728c51e5fd 100644
--- a/meta/conf/layer.conf
+++ b/meta/conf/layer.conf
@@ -7,12 +7,12 @@ BBFILE_COLLECTIONS += "core"
 BBFILE_PATTERN_core = "^${LAYERDIR}/"
 BBFILE_PRIORITY_core = "5"
 
-LAYERSERIES_CORENAMES = "sumo"
+LAYERSERIES_CORENAMES = "sumo thud"
 
 # This should only be incremented on significant changes that will
 # cause compatibility issues with other layers
 LAYERVERSION_core = "11"
-LAYERSERIES_COMPAT_core = "sumo"
+LAYERSERIES_COMPAT_core = "thud"
 
 BBLAYERS_LAYERINDEX_NAME_core = "openembedded-core"
 
-- 
2.17.1

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

Re: [OE-core] [oe-commits] [openembedded-core] 02/45: fribidi: use Meson instead of autotools

[Burton, Ross]

I can't seem to replicate this on our centos7 box:

[ross@centos7 build]$ gcc --version
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28)
[ross@centos7 build]$ gcc -ffdjsj
gcc: error: unrecognized command line option ‘-ffdjsj’
gcc: fatal error: no input files
compilation terminated.
[ross@centos7 build]$ gcc -fstack-protector-strong
gcc: fatal error: no input files
compilation terminated.

Presumably we've upgraded gcc at some point...

However I did replicate the same sort of problem outside of OE.  Can
one of you test
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=ross/mut=1e32317ad77457d2a026eaa67ea7c6eebe58b127
for me please?

Cheers,
Ross
On Mon, 24 Sep 2018 at 11:08, Burton, Ross  wrote:
>
> Looks like Meson is using the target link flags for linking even when
> it knows its doing a native build.  Talking to Meson upstream now and
> have a workaround.
>
> Ross
> On Sun, 23 Sep 2018 at 15:51, Khem Raj  wrote:
> >
> > On Sun, Sep 23, 2018 at 2:20 AM Martin Jansa  wrote:
> > >
> > > Was this one ever sent to ML? I haven't found it in the archives.
> > >
> > > With security flags enabled it fails on older hosts (e.g. Ubuntu 14.04 
> > > with gcc-4.8) now with:
> >
> > I am seeing same failure on ubuntu 14.04 and centos7 boxes
> > this definitely is regression, its being not to right about using
> > TARGET_CFLAGS where it should not be using them
> >
> > >
> > > DEBUG: Executing shell function do_compile
> > > [1/63] gcc -Igen.tab/gen.tab@@gen-unicode-version@exe -Igen.tab 
> > > -I../fribidi-1.0.5/gen.tab -I. -I../fribidi-1.0.5/ -Ilib 
> > > -I../fribidi-1.0.5/lib -pipe -D_FILE_OFFSET_BITS=64 -ansi 
> > > -fvisibility=hidden -O2 -g -feliminate-unused-debug-types 
> > > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0=/usr/src/debug/fribidi/1.0.5-r0
> > >  
> > > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0/recipe-sysroot=
> > >  
> > > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0/recipe-sysroot-native=
> > >  -UHAVE_CONFIG_H -DHAVE_STRINGIZE -DDONT_HAVE_FRIBIDI_CONFIG_H 
> > > -DHAVE_STDLIB_H -DHAVE_STRING_H -DHAVE_STRINGS_H -DSTDC_HEADERS=1  -MD 
> > > -MQ 'gen.tab/gen.tab@@gen-unicode-version@exe/gen-unicode-version.c.o' 
> > > -MF 'gen.tab/gen.tab@@gen-unicode-version@exe/gen-unicode-version.c.o.d' 
> > > -o 'gen.tab/gen.tab@@gen-unicode-version@exe/gen-unicode-version.c.o' -c 
> > > ../fribidi-1.0.5/gen.tab/gen-unicode-version.c
> > > [2/63] gcc   -o gen.tab/gen-unicode-version 
> > > 'gen.tab/gen.tab@@gen-unicode-version@exe/gen-unicode-version.c.o' 
> > > -Wl,--no-undefined -Wl,--as-needed -O2 -pipe -g 
> > > -feliminate-unused-debug-types 
> > > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0=/usr/src/debug/fribidi/1.0.5-r0
> > >  
> > > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0/recipe-sysroot=
> > >  
> > > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0/recipe-sysroot-native=
> > >  -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -fstack-protector-strong 
> > > -Wl,-z,relro,-z,now
> > > FAILED: gen.tab/gen-unicode-version
> > > gcc   -o gen.tab/gen-unicode-version 
> > > 'gen.tab/gen.tab@@gen-unicode-version@exe/gen-unicode-version.c.o' 
> > > -Wl,--no-undefined -Wl,--as-needed -O2 -pipe -g 
> > > -feliminate-unused-debug-types 
> > > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0=/usr/src/debug/fribidi/1.0.5-r0
> > >  
> > > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0/recipe-sysroot=
> > >  
> > > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0/recipe-sysroot-native=
> > >  -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -fstack-protector-strong 
> > > -Wl,-z,relro,-z,now
> > > gcc: error: unrecognized command line option ‘-fstack-protector-strong’
> > > ninja: build stopped: subcommand failed.
> > > WARNING: exit code 1 from a shell command.
> > >
> > > Is meson too active in adding SECURITY_FLAGS even to native part of the 
> > > build or should we just just remove -fstack-protector-strong completely 
> > > for fribidi?
> > >
> > >
> > >
> > > On Fri, Sep 21, 2018 at 5:24 PM  wrote:
> > >>
> > >> This is an automated email from the git hooks/post-receive script.
> > >>
> > >> rpurdie pushed a commit to branch master-next
> > >> in repository openembedded-core.
> > >>
> > >> commit d297f7ebf3f62528d055e1938a9693d6f3a61935
> > >> Author: Ross Burton 
> > >> AuthorDate: Fri Sep 14 00:28:39 2018 +0100
> > >>
> > >> fribidi: use Meson instead of autotools
> > >>
> > >> Upstream is moving to Meson, so backport a patch to use that instead 
> > >> of
> > >> autotools.
> > >>
> > >> Signed-off-by: Ross Burton 
> > >> ---
> > >>  meta/recipes-support/fribidi/fribidi/meson.patch | 44 
> > >> 
> > 

Re: [OE-core] [oe-commits] [openembedded-core] 02/45: fribidi: use Meson instead of autotools

[Burton, Ross]

Looks like Meson is using the target link flags for linking even when
it knows its doing a native build.  Talking to Meson upstream now and
have a workaround.

Ross
On Sun, 23 Sep 2018 at 15:51, Khem Raj  wrote:
>
> On Sun, Sep 23, 2018 at 2:20 AM Martin Jansa  wrote:
> >
> > Was this one ever sent to ML? I haven't found it in the archives.
> >
> > With security flags enabled it fails on older hosts (e.g. Ubuntu 14.04 with 
> > gcc-4.8) now with:
>
> I am seeing same failure on ubuntu 14.04 and centos7 boxes
> this definitely is regression, its being not to right about using
> TARGET_CFLAGS where it should not be using them
>
> >
> > DEBUG: Executing shell function do_compile
> > [1/63] gcc -Igen.tab/gen.tab@@gen-unicode-version@exe -Igen.tab 
> > -I../fribidi-1.0.5/gen.tab -I. -I../fribidi-1.0.5/ -Ilib 
> > -I../fribidi-1.0.5/lib -pipe -D_FILE_OFFSET_BITS=64 -ansi 
> > -fvisibility=hidden -O2 -g -feliminate-unused-debug-types 
> > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0=/usr/src/debug/fribidi/1.0.5-r0
> >  
> > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0/recipe-sysroot=
> >  
> > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0/recipe-sysroot-native=
> >  -UHAVE_CONFIG_H -DHAVE_STRINGIZE -DDONT_HAVE_FRIBIDI_CONFIG_H 
> > -DHAVE_STDLIB_H -DHAVE_STRING_H -DHAVE_STRINGS_H -DSTDC_HEADERS=1  -MD -MQ 
> > 'gen.tab/gen.tab@@gen-unicode-version@exe/gen-unicode-version.c.o' -MF 
> > 'gen.tab/gen.tab@@gen-unicode-version@exe/gen-unicode-version.c.o.d' -o 
> > 'gen.tab/gen.tab@@gen-unicode-version@exe/gen-unicode-version.c.o' -c 
> > ../fribidi-1.0.5/gen.tab/gen-unicode-version.c
> > [2/63] gcc   -o gen.tab/gen-unicode-version 
> > 'gen.tab/gen.tab@@gen-unicode-version@exe/gen-unicode-version.c.o' 
> > -Wl,--no-undefined -Wl,--as-needed -O2 -pipe -g 
> > -feliminate-unused-debug-types 
> > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0=/usr/src/debug/fribidi/1.0.5-r0
> >  
> > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0/recipe-sysroot=
> >  
> > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0/recipe-sysroot-native=
> >  -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -fstack-protector-strong 
> > -Wl,-z,relro,-z,now
> > FAILED: gen.tab/gen-unicode-version
> > gcc   -o gen.tab/gen-unicode-version 
> > 'gen.tab/gen.tab@@gen-unicode-version@exe/gen-unicode-version.c.o' 
> > -Wl,--no-undefined -Wl,--as-needed -O2 -pipe -g 
> > -feliminate-unused-debug-types 
> > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0=/usr/src/debug/fribidi/1.0.5-r0
> >  
> > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0/recipe-sysroot=
> >  
> > -fdebug-prefix-map=TOPDIR/BUILD/work/raspberrypi3-webos-linux-gnueabi/fribidi/1.0.5-r0/recipe-sysroot-native=
> >  -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -fstack-protector-strong 
> > -Wl,-z,relro,-z,now
> > gcc: error: unrecognized command line option ‘-fstack-protector-strong’
> > ninja: build stopped: subcommand failed.
> > WARNING: exit code 1 from a shell command.
> >
> > Is meson too active in adding SECURITY_FLAGS even to native part of the 
> > build or should we just just remove -fstack-protector-strong completely for 
> > fribidi?
> >
> >
> >
> > On Fri, Sep 21, 2018 at 5:24 PM  wrote:
> >>
> >> This is an automated email from the git hooks/post-receive script.
> >>
> >> rpurdie pushed a commit to branch master-next
> >> in repository openembedded-core.
> >>
> >> commit d297f7ebf3f62528d055e1938a9693d6f3a61935
> >> Author: Ross Burton 
> >> AuthorDate: Fri Sep 14 00:28:39 2018 +0100
> >>
> >> fribidi: use Meson instead of autotools
> >>
> >> Upstream is moving to Meson, so backport a patch to use that instead of
> >> autotools.
> >>
> >> Signed-off-by: Ross Burton 
> >> ---
> >>  meta/recipes-support/fribidi/fribidi/meson.patch | 44 
> >> 
> >>  meta/recipes-support/fribidi/fribidi_1.0.5.bb|  8 ++---
> >>  2 files changed, 47 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/meta/recipes-support/fribidi/fribidi/meson.patch 
> >> b/meta/recipes-support/fribidi/fribidi/meson.patch
> >> new file mode 100644
> >> index 000..8b3c4a9
> >> --- /dev/null
> >> +++ b/meta/recipes-support/fribidi/fribidi/meson.patch
> >> @@ -0,0 +1,44 @@
> >> +Upstream-Status: Backport
> >> +Signed-off-by: Ross Burton 
> >> +
> >> +From f5feb6c599adb52f24656f8589868039b0d14272 Mon Sep 17 00:00:00 2001
> >> +From: Heiko Becker 
> >> +Date: Fri, 7 Sep 2018 20:57:11 +0200
> >> +Subject: [PATCH] Build generator executables natively
> >> +
> >> +They are run during the build and not installed in the end. Without
> >> +this one gets the following error from meson: "ERROR: Can not use
> >> +target gen-unicode-version as a generator because it is 

[OE-core] [PATCH v2] openssl10: remove extra slash from libdir path

[Mikko Rapeli]

The configure script ended up creating Makefile with

LIBDIR=/lib

which got leaked into various places including all
pkg-config .pc files where lines like (note the
double slash //):

libdir=${exec_prefix}//lib
...
Libs: -L${libdir} -lcrypto

which causes pkg-config --libs to include the full absolute path
to the recipe specific sysroot. This isn't a big problem
until something like CMake projects start generating
their own .cmake modules using this absolute path and exposing
them to sysroots of other bitbake recipes thus escaping
their recipe specific sysroots.

Then the fun begins when these users of the .cmake module start
to randomly fail builds with error messages like:

/home/builder/src/base/build/tmp/work/corei7-64-linux/package/1.0-r0/recipe-sysroot-native/usr/bin/x86_64-linux/../../libexec/x86_64-linux/gcc/x86_64-linux/7.3.0/ld:
 cannot find /lib/libpthread.so.0
/home/builder/src/base/build/tmp/work/corei7-64-linux/package/1.0-r0/recipe-sysroot-native/usr/bin/x86_64-linux/../../libexec/x86_64-linux/gcc/x86_64-linux/7.3.0/ld:
 cannot find /usr/lib/libpthread_nonshared.a
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
WARNING: exit code 1 from a shell command.

As luck has it, this problem goes away by recompiling the recipes
alone but repeats with multiple recipes here and there when full
images are build.

A careful inspection of multi page linker command lines shows
that some linker paramaters point to libraries in a different
recipes sysroot than what bitbake was building when the task
failed.

So, fix is to remove this one extra slash from openssl
library path configuration option. This changes openssl
Makefile to have:

LIBDIR=lib

and all users of LIBDIR variable in the Makefile are already
adding slashes as path separators if that is needed.

With this the generated .pc files have:

libdir=${exec_prefix}/lib

and pkg-config --libs knows to strip the already default
sysroot path away.

This then fixes the generated .cmake files to not include
these absolute paths and fixes the random build failures
when building images.

Thanks to Thomas, Michael and Ross for debugging support!

Signed-off-by: Mikko Rapeli 
Cc: Thomas Witt 
Cc: Michael Ho 
Cc: Ross Burton 
---
 meta/recipes-connectivity/openssl/openssl10_1.0.2p.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

v1: 
http://lists.openembedded.org/pipermail/openembedded-core/2018-September/156019.html

v2: use syntax proposed by peter.kjellerst...@axis.com in

http://lists.openembedded.org/pipermail/openembedded-core/2018-September/156020.html

diff --git a/meta/recipes-connectivity/openssl/openssl10_1.0.2p.bb 
b/meta/recipes-connectivity/openssl/openssl10_1.0.2p.bb
index b7297fc..4920e12 100644
--- a/meta/recipes-connectivity/openssl/openssl10_1.0.2p.bb
+++ b/meta/recipes-connectivity/openssl/openssl10_1.0.2p.bb
@@ -191,7 +191,7 @@ do_configure () {
if [ "x$useprefix" = "x" ]; then
useprefix=/
fi
-   libdirleaf="$(echo ${libdir} | sed s:$useprefix::)"
+   libdirleaf="$( echo "${libdir}" | sed "s:^$useprefix/*::" )"
perl ./Configure ${EXTRA_OECONF} ${PACKAGECONFIG_CONFARGS} shared 
--prefix=$useprefix --openssldir=${libdir}/ssl --libdir=$libdirleaf $target
 }
 
-- 
1.9.1

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

[OE-core] [PATCH] kernel-yocto.bbclass: fix "referenced before assignment" error

[Max Kellermann]

From: Max Kellermann 

If "scc --configs" fails, do_kernel_configcheck() crashes like this:

  0338:try:
  0339:configs = subprocess.check_output(['scc', '--configs', '-o', 
s + '/.kernel-meta'], env=env).decode('utf-8')
  0340:except subprocess.CalledProcessError:
  *** 0341:bb.fatal( "Cannot gather config fragments for audit: %s" % 
configs)
  0342:
  0343:try:
  0344:subprocess.check_call(['kconf_check', '--report', '-o',
  0345:'%s/%s/cfg' % (s, kmeta), d.getVar('B') + 
'/.config', s, configs], cwd=s, env=env)
 Exception: UnboundLocalError: local variable 'configs' referenced before 
assignment

This crash bug was introduced by commit
21de5cc43cfedc703e5bc0515507a6dae36afb74

Signed-off-by: Max Kellermann 
---
 meta/classes/kernel-yocto.bbclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/classes/kernel-yocto.bbclass 
b/meta/classes/kernel-yocto.bbclass
index 2ecd060093..496c8a7f68 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -337,8 +337,8 @@ python do_kernel_configcheck() {
 
 try:
 configs = subprocess.check_output(['scc', '--configs', '-o', s + 
'/.kernel-meta'], env=env).decode('utf-8')
-except subprocess.CalledProcessError:
-bb.fatal( "Cannot gather config fragments for audit: %s" % configs)
+except subprocess.CalledProcessError as e:
+bb.fatal( "Cannot gather config fragments for audit: %s" % 
e.output.decode("utf-8") )
 
 try:
 subprocess.check_call(['kconf_check', '--report', '-o',
-- 
2.19.0

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

Re: [OE-core] [PATCH] kernel.bbclass: allow exporting files from kernel recipes to sysroot

[Mikko.Rapeli]

> On Fri, Sep 21, 2018 at 7:49 AM, Mikko Rapeli  wrote:
> > This change enables kernel recipes to share files with other
> > recipes. Firmware, modules and kernel-depmod are still not shared
> > since according to git history they cause problems with multiarch,
> > but all others are allowed. Examples of shared files are
> > kernel version and recipe specific headers and scripts which
> > are not needed by common linux-libc-headers to bootstrap glibc.
> >
> > For example, if a kernel recipe wants to share headers, it can do:
> >
> > PACKAGES =+ "${PN}-headers"
> >
> > do_install_append() {
> > install -d "${D}${includedir}/${PN}"
> > oe_runmake INSTALL_HDR_PATH="${D}${includedir}/${PN}" headers_install
> }
> 
> This is what I've always done in the past (and in fact, there's an
> open Yocto bug
> to track this), but I haven't actually needed to do what you are
> modifying in the
> bbclass itself.

Without this patch, users of kernel.bbclass can provide the headers etc 
packages,
but other recipes can never see the files in their sysroot even if they depend
on the kernel recipe because kernel.bbclass has disabled sysroot_stage_all()
completely.

The recipes could define their own sysroot_stage_all() but I don't see
why kernel would be that special and why all of their installed files should
be excluded from build sysroots by default.

The old way to do this was to fork linux-libc-headers for the custom kernel
but now it has a big fat warning to not do this, but exposing header etc
files to other recipes to build against was still not resolved.

With this patch the kernel recipe can just install the files needed and
users can see them unless they are filtered.

> If you call the sysroot stage routines directly in that
> install_append, are you really
> not seeing the files appear in the recipe's sysroot ?

Of course this can be done but why on earth is kernel so special that
it's installed files are not visible in sysroots by default?

If certain files are problematic, they can be filtered out from the
sysroot like my patch tries to do.

> Have you confirmed that we get a warning/error from bitbake about
> conflicting files
> from multiple recipes if someone doesn't know to use a custom path for their
> headers ? That has always been the main concern about allowing something like
> this.

No, but I do rely on this with other recipes as well. At least I know that
conflicting files warning will fail image and SDK generation.

I would expect that recipe specific sysroots don't allow conflicting files.

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

Re: [OE-core] [PATCH] openssl10: remove extra slash from libdir path

[Mikko.Rapeli]

On Fri, Sep 21, 2018 at 04:41:50PM +, Peter Kjellerstedt wrote:
> > diff --git a/meta/recipes-connectivity/openssl/openssl10_1.0.2p.bb
> > b/meta/recipes-connectivity/openssl/openssl10_1.0.2p.bb
> > index b7297fc..f09782c 100644
> > --- a/meta/recipes-connectivity/openssl/openssl10_1.0.2p.bb
> > +++ b/meta/recipes-connectivity/openssl/openssl10_1.0.2p.bb
> > @@ -191,7 +191,7 @@ do_configure () {
> > if [ "x$useprefix" = "x" ]; then
> > useprefix=/
> > fi
> > -   libdirleaf="$(echo ${libdir} | sed s:$useprefix::)"
> > +   libdirleaf="$( basename "${libdir}" )"
> 
> You are making assumptions about the value of ${libdir} here.
> May I suggest the following instead (just in case someone has 
> defined libdir as ${prefix}/foo/lib):
> 
>   libdirleaf="$(echo ${libdir} | sed s:^$useprefix/*::)"

Ok, sending v2 with this.

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