[OE-core] ✗ patchtest: failure for linux-yocto_5.2.bb: Fix build races in kernel-selftests

[Patchwork]

== Series Details ==

Series: linux-yocto_5.2.bb: Fix build races in kernel-selftests
Revision: 1
URL   : https://patchwork.openembedded.org/series/19553/
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 684fc36402)

* Issue Added patch file is missing Upstream-Status in the header 
[test_upstream_status_presence_format] 
  Suggested fixAdd Upstream-Status:  to the header of 
meta/recipes-kernel/linux/files/0001-selftests-bpf-fix-test_verifier-test_maps-make-depen.patch
  Standard format  Upstream-Status: 
  Valid status Pending, Accepted, Backport, Denied, Inappropriate [reason], 
Submitted [where]



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

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

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

[OE-core] [PATCH] linux-yocto_5.2.bb: Fix build races in kernel-selftests

[Khem Raj]

Signed-off-by: Khem Raj 
Cc: Bruce Ashfield 
---
 ...x-test_verifier-test_maps-make-depen.patch | 58 +
 ...ructure-test_-progs-maps-verifier-te.patch | 86 +++
 meta/recipes-kernel/linux/linux-yocto_5.2.bb  |  3 +
 3 files changed, 147 insertions(+)
 create mode 100644 
meta/recipes-kernel/linux/files/0001-selftests-bpf-fix-test_verifier-test_maps-make-depen.patch
 create mode 100644 
meta/recipes-kernel/linux/files/0002-selftests-bpf-structure-test_-progs-maps-verifier-te.patch

diff --git 
a/meta/recipes-kernel/linux/files/0001-selftests-bpf-fix-test_verifier-test_maps-make-depen.patch
 
b/meta/recipes-kernel/linux/files/0001-selftests-bpf-fix-test_verifier-test_maps-make-depen.patch
new file mode 100644
index 00..e397b10cb4
--- /dev/null
+++ 
b/meta/recipes-kernel/linux/files/0001-selftests-bpf-fix-test_verifier-test_maps-make-depen.patch
@@ -0,0 +1,58 @@
+From 08a2303803397c98e0f279bb6fb22afc673786a3 Mon Sep 17 00:00:00 2001
+From: Andrii Nakryiko 
+Date: Tue, 16 Jul 2019 12:38:36 -0700
+Subject: [PATCH 1/2] selftests/bpf: fix test_verifier/test_maps make
+ dependencies
+
+e46fc22e60a4 ("selftests/bpf: make directory prerequisites order-only")
+exposed existing problem in Makefile for test_verifier and test_maps tests:
+their dependency on auto-generated header file with a list of all tests wasn't
+recorded explicitly. This patch fixes these issues.
+
+Fixes: 51a0e301a563 ("bpf: Add BPF_MAP_TYPE_SK_STORAGE test to test_maps")
+Fixes: 6b7b6995c43e ("selftests: bpf: tests.h should depend on .c files, not 
the output")
+Cc: Ilya Leoshkevich 
+Cc: Stanislav Fomichev 
+Cc: Martin KaFai Lau 
+Signed-off-by: Andrii Nakryiko 
+Signed-off-by: Alexei Starovoitov 
+---
+ tools/testing/selftests/bpf/Makefile | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/tools/testing/selftests/bpf/Makefile 
b/tools/testing/selftests/bpf/Makefile
+index b9e88ccc289b..cd12bf414056 100644
+--- a/tools/testing/selftests/bpf/Makefile
 b/tools/testing/selftests/bpf/Makefile
+@@ -77,8 +77,6 @@ all: $(TEST_CUSTOM_PROGS)
+ $(OUTPUT)/urandom_read: $(OUTPUT)/%: %.c
+   $(CC) -o $@ $< -Wl,--build-id
+ 
+-$(OUTPUT)/test_maps: map_tests/*.c
+-
+ BPFOBJ := $(OUTPUT)/libbpf.a
+ 
+ $(TEST_GEN_PROGS): $(BPFOBJ)
+@@ -242,9 +240,10 @@ MAP_TESTS_DIR = $(OUTPUT)/map_tests
+ $(MAP_TESTS_DIR):
+   mkdir -p $@
+ MAP_TESTS_H := $(MAP_TESTS_DIR)/tests.h
++MAP_TESTS_FILES := $(wildcard map_tests/*.c)
+ test_maps.c: $(MAP_TESTS_H)
+ $(OUTPUT)/test_maps: CFLAGS += $(TEST_MAPS_CFLAGS)
+-MAP_TESTS_FILES := $(wildcard map_tests/*.c)
++$(OUTPUT)/test_maps: test_maps.c $(MAP_TESTS_H) $(MAP_TESTS_FILES)
+ $(MAP_TESTS_H): $(MAP_TESTS_DIR) $(MAP_TESTS_FILES)
+   $(shell ( cd map_tests/; \
+ echo '/* Generated header, do not edit */'; \
+@@ -261,6 +260,7 @@ $(MAP_TESTS_H): $(MAP_TESTS_DIR) $(MAP_TESTS_FILES)
+ VERIFIER_TESTS_H := $(OUTPUT)/verifier/tests.h
+ test_verifier.c: $(VERIFIER_TESTS_H)
+ $(OUTPUT)/test_verifier: CFLAGS += $(TEST_VERIFIER_CFLAGS)
++$(OUTPUT)/test_verifier: test_verifier.c $(VERIFIER_TESTS_H)
+ 
+ VERIFIER_TESTS_DIR = $(OUTPUT)/verifier
+ $(VERIFIER_TESTS_DIR):
+-- 
+2.23.0
+
diff --git 
a/meta/recipes-kernel/linux/files/0002-selftests-bpf-structure-test_-progs-maps-verifier-te.patch
 
b/meta/recipes-kernel/linux/files/0002-selftests-bpf-structure-test_-progs-maps-verifier-te.patch
new file mode 100644
index 00..36692088b0
--- /dev/null
+++ 
b/meta/recipes-kernel/linux/files/0002-selftests-bpf-structure-test_-progs-maps-verifier-te.patch
@@ -0,0 +1,86 @@
+From 2fd88b60e6255206d46baa543a637aa1e1cc6186 Mon Sep 17 00:00:00 2001
+From: Andrii Nakryiko 
+Date: Tue, 16 Jul 2019 12:38:37 -0700
+Subject: [PATCH 2/2] selftests/bpf: structure test_{progs, maps, verifier}
+ test runners uniformly
+
+It's easier to follow the logic if it's structured the same.
+There is just slight difference between test_progs/test_maps and
+test_verifier. test_verifier's verifier/*.c files are not really compilable
+C files (they are more of include headers), so they can't be specified as
+explicit dependencies of test_verifier.
+
+Cc: Alexei Starovoitov 
+Signed-off-by: Andrii Nakryiko 
+Signed-off-by: Alexei Starovoitov 
+---
+ tools/testing/selftests/bpf/Makefile | 24 ++--
+ 1 file changed, 10 insertions(+), 14 deletions(-)
+
+diff --git a/tools/testing/selftests/bpf/Makefile 
b/tools/testing/selftests/bpf/Makefile
+index cd12bf414056..b76c43eb5d4f 100644
+--- a/tools/testing/selftests/bpf/Makefile
 b/tools/testing/selftests/bpf/Makefile
+@@ -161,6 +161,7 @@ endif
+ endif
+ 
+ TEST_PROGS_CFLAGS := -I. -I$(OUTPUT)
++TEST_MAPS_CFLAGS := -I. -I$(OUTPUT)
+ TEST_VERIFIER_CFLAGS := -I. -I$(OUTPUT) -Iverifier
+ 
+ ifneq ($(SUBREG_CODEGEN),)
+@@ -212,16 +213,14 @@ ifeq ($(DWARF2BTF),y)
+   $(BTF_PAHOLE) -J $@
+ endif
+ 
+-PROG_TESTS_H := $(OUTPUT)/prog_tests/tests.h
+-test_progs.c: $(PROG_TESTS_H)
+-$(OUTPUT)/test_progs: CFLAGS += 

[OE-core] [PATCH] libsolv:upgrade 0.7.5 -> 0.7.6

[Zang Ruochen]

Signed-off-by: Zang Ruochen 
---
 meta/recipes-extended/libsolv/{libsolv_0.7.5.bb => libsolv_0.7.6.bb} | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-extended/libsolv/{libsolv_0.7.5.bb => libsolv_0.7.6.bb} 
(93%)

diff --git a/meta/recipes-extended/libsolv/libsolv_0.7.5.bb 
b/meta/recipes-extended/libsolv/libsolv_0.7.6.bb
similarity index 93%
rename from meta/recipes-extended/libsolv/libsolv_0.7.5.bb
rename to meta/recipes-extended/libsolv/libsolv_0.7.6.bb
index 80ce76b..3df8993 100644
--- a/meta/recipes-extended/libsolv/libsolv_0.7.5.bb
+++ b/meta/recipes-extended/libsolv/libsolv_0.7.6.bb
@@ -10,7 +10,7 @@ DEPENDS = "expat zlib"
 SRC_URI = "git://github.com/openSUSE/libsolv.git \
 "
 
-SRCREV = "2cab7ea00d08390374b25b11d969f3740c4660f4"
+SRCREV = "17ce4bc4fb52a0b32964f3b7d491c18177980be1"
 
 UPSTREAM_CHECK_GITTAGREGEX = "(?P\d+(\.\d+)+)"
 
-- 
2.7.4



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

Re: [OE-core] [PATCH v2] perf: change dependencies on python to python3

[Bruce Ashfield]

On Wed, Aug 28, 2019 at 10:14 PM  wrote:
>
> From: Bruce Ashfield 
>
> The upstream kernel can now handle python3 for the perf scripts, coupled
> with the impending EOL of python2, we switch the dependencies in perf
> (scripting) to python3.
>
> Outside of dependency changes, we also pass the following two variables
> to the perf build: PYTHON=python3 PYTHON_CONFIG=python3-config. To
> ensure that our python3 components are used.
>
> For configurations that disable perf scripting, there is no change in
> behaviour.
>
> [YOCTO #13358]
>
> Signed-off-by: Bruce Ashfield 
> ---
>
> v2:
>   - tested against 4.19, 5.0 and 5.2+
>   - broadened search path for scripts
>   - added /usr/bin/python to the fixup list

Also, if a meta-python2 is created, we can do a perf variant that
depends on python2 so older kernels (that can't be patched) can still
use perf scripting if they want. But I'm betting the number of
users/kernels is quite small, so it may just be better as an "on
demand" thing.

Cheers,

Bruce

>
>  meta/recipes-kernel/perf/perf.bb | 19 +++
>  1 file changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/meta/recipes-kernel/perf/perf.bb 
> b/meta/recipes-kernel/perf/perf.bb
> index 4e603f1a32..af0410c88d 100644
> --- a/meta/recipes-kernel/perf/perf.bb
> +++ b/meta/recipes-kernel/perf/perf.bb
> @@ -13,7 +13,7 @@ PR = "r9"
>
>  PACKAGECONFIG ??= "scripting tui libunwind"
>  PACKAGECONFIG[dwarf] = ",NO_DWARF=1"
> -PACKAGECONFIG[scripting] = ",NO_LIBPERL=1 NO_LIBPYTHON=1,perl python"
> +PACKAGECONFIG[scripting] = ",NO_LIBPERL=1 NO_LIBPYTHON=1,perl python3"
>  # gui support was added with kernel 3.6.35
>  # since 3.10 libnewt was replaced by slang
>  # to cover a wide range of kernel we add both dependencies
> @@ -44,8 +44,8 @@ PROVIDES = "virtual/perf"
>  inherit linux-kernel-base kernel-arch manpages
>
>  # needed for building the tools/perf Python bindings
> -inherit ${@bb.utils.contains('PACKAGECONFIG', 'scripting', 'pythonnative', 
> '', d)}
> -inherit python-dir
> +inherit ${@bb.utils.contains('PACKAGECONFIG', 'scripting', 'python3native', 
> '', d)}
> +inherit python3-dir
>  export PYTHON_SITEPACKAGES_DIR
>
>  #kernel 3.1+ supports WERROR to disable warnings as errors
> @@ -94,6 +94,7 @@ EXTRA_OEMAKE += "\
>  'sharedir=${@os.path.relpath(datadir, prefix)}' \
>  'mandir=${@os.path.relpath(mandir, prefix)}' \
>  'infodir=${@os.path.relpath(infodir, prefix)}' \
> +${@bb.utils.contains('PACKAGECONFIG', 'scripting', 'PYTHON=python3 
> PYTHON_CONFIG=python3-config', '', d)} \
>  "
>
>  # During do_configure, we might run a 'make clean'. That often breaks
> @@ -132,7 +133,7 @@ do_install() {
> oe_runmake install
> # we are checking for this make target to be compatible with older 
> perf versions
> if ${@bb.utils.contains('PACKAGECONFIG', 'scripting', 'true', 
> 'false', d)} && grep -q install-python_ext ${S}/tools/perf/Makefile*; then
> -   oe_runmake DESTDIR=${D} install-python_ext
> +   oe_runmake DESTDIR=${D} install-python_ext
> fi
>  }
>
> @@ -232,8 +233,10 @@ do_configure_prepend () {
>  fi
>
>  # use /usr/bin/env instead of version specific python
> -for s in `find ${S}/tools/perf/scripts/python/ -name '*.py'`; do
> -sed -i 's,/usr/bin/python2,/usr/bin/env python,' "${s}"
> +for s in `find ${S}/tools/perf/ -name '*.py'`; do
> +sed -i 's,/usr/bin/python,/usr/bin/env python3,' "${s}"
> +sed -i 's,/usr/bin/python2,/usr/bin/env python3,' "${s}"
> +sed -i 's,/usr/bin/env python2,/usr/bin/env python3,' "${s}"
>  done
>
>  # unistd.h can be out of sync between libc-headers and the captured 
> version in the perf source
> @@ -252,9 +255,9 @@ PACKAGES =+ "${PN}-archive ${PN}-tests ${PN}-perl 
> ${PN}-python"
>
>  RDEPENDS_${PN} += "elfutils bash"
>  RDEPENDS_${PN}-archive =+ "bash"
> -RDEPENDS_${PN}-python =+ "bash python python-modules 
> ${@bb.utils.contains('PACKAGECONFIG', 'audit', 'audit-python', '', d)}"
> +RDEPENDS_${PN}-python =+ "bash python3 python3-modules 
> ${@bb.utils.contains('PACKAGECONFIG', 'audit', 'audit-python3', '', d)}"
>  RDEPENDS_${PN}-perl =+ "bash perl perl-modules"
> -RDEPENDS_${PN}-tests =+ "python"
> +RDEPENDS_${PN}-tests =+ "python3"
>
>  RSUGGESTS_SCRIPTING = "${@bb.utils.contains('PACKAGECONFIG', 'scripting', 
> '${PN}-perl ${PN}-python', '',d)}"
>  RSUGGESTS_${PN} += "${PN}-archive ${PN}-tests ${RSUGGESTS_SCRIPTING}"
> --
> 2.19.1
>


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

Re: [OE-core] [PATCH] serial-getty@.service: Allow device to fast fail if it does not exist

[Jason Wessel]

On 8/28/19 5:41 PM, Richard Purdie wrote:

On Wed, 2019-08-28 at 15:24 -0500, Jason Wessel wrote:

On 8/27/19 7:15 PM, richard.pur...@linuxfoundation.org wrote:

On Tue, 2019-08-27 at 19:03 -0500, Jason Wessel wrote:

On 8/27/19 5:58 PM, Richard Purdie wrote:

Hi Jason,
Somehow this change is responsible for this build failure:

https://autobuilder.yoctoproject.org/typhoon/#/builders/72/builds/976

(steps 5c and 7c so failure during testimage).

I have bisected it to this change, I haven't looked into why.

Thanks for tracking it down.   I am sure how to try an duplicate
this.  I clicked around to try and find out a bit about what it
is
running for these phases of the build but it is not very obvious.

Is there a local.conf I can try along with what ever commands it
ran?

The configuration its using is shown in
https://autobuilder.yoctoproject.org/typhoon/#/builders/72/builds/978/steps/8/logs/stdio
for each step.


I tried the configuration on my system but it seems to work fine, see
below.   Is there a way to get complete log file of the boot on the
broken host?  I am also curious if it fails every time or not.

/home/pokybuild/yocto-worker/qa-
extras2/build/build/tmp/work/qemux86_64-poky-linux/core-image-
sato/1.0-r0/testimage/qemu_boot_log.2019082722

I am not sure it will tell us anything further or not, but it
certainly looks like the system didn't boot correctly in the first
place.

I've rerun it as
https://autobuilder.yoctoproject.org/typhoon/#/builders/72/builds/983




I'll take a further look at it tomorrow.   I have no idea why systemd emitted 
this message:

[    4.750194] systemd[1]: Unnecessary job for /dev/ttyS1 was removed.
[    4.751666] systemd[1]: Unnecessary job for /dev/ttyS0 was removed.

[  OK  ] Started Serial Getty on ttyS0.
 Stopping Serial Getty on ttyS0...

I have an image now with the problem so, I'll make a copy of it in case the problem 
"goes away" again.  It will be interesting to see what the deal is with this 
corner case.

Cheers,

Jason.




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

[OE-core] [PATCH v2] perf: change dependencies on python to python3

[bruce . ashfield]

From: Bruce Ashfield 

The upstream kernel can now handle python3 for the perf scripts, coupled
with the impending EOL of python2, we switch the dependencies in perf
(scripting) to python3.

Outside of dependency changes, we also pass the following two variables
to the perf build: PYTHON=python3 PYTHON_CONFIG=python3-config. To
ensure that our python3 components are used.

For configurations that disable perf scripting, there is no change in
behaviour.

[YOCTO #13358]

Signed-off-by: Bruce Ashfield 
---

v2:
  - tested against 4.19, 5.0 and 5.2+
  - broadened search path for scripts
  - added /usr/bin/python to the fixup list

 meta/recipes-kernel/perf/perf.bb | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
index 4e603f1a32..af0410c88d 100644
--- a/meta/recipes-kernel/perf/perf.bb
+++ b/meta/recipes-kernel/perf/perf.bb
@@ -13,7 +13,7 @@ PR = "r9"
 
 PACKAGECONFIG ??= "scripting tui libunwind"
 PACKAGECONFIG[dwarf] = ",NO_DWARF=1"
-PACKAGECONFIG[scripting] = ",NO_LIBPERL=1 NO_LIBPYTHON=1,perl python"
+PACKAGECONFIG[scripting] = ",NO_LIBPERL=1 NO_LIBPYTHON=1,perl python3"
 # gui support was added with kernel 3.6.35
 # since 3.10 libnewt was replaced by slang
 # to cover a wide range of kernel we add both dependencies
@@ -44,8 +44,8 @@ PROVIDES = "virtual/perf"
 inherit linux-kernel-base kernel-arch manpages
 
 # needed for building the tools/perf Python bindings
-inherit ${@bb.utils.contains('PACKAGECONFIG', 'scripting', 'pythonnative', '', 
d)}
-inherit python-dir
+inherit ${@bb.utils.contains('PACKAGECONFIG', 'scripting', 'python3native', 
'', d)}
+inherit python3-dir
 export PYTHON_SITEPACKAGES_DIR
 
 #kernel 3.1+ supports WERROR to disable warnings as errors
@@ -94,6 +94,7 @@ EXTRA_OEMAKE += "\
 'sharedir=${@os.path.relpath(datadir, prefix)}' \
 'mandir=${@os.path.relpath(mandir, prefix)}' \
 'infodir=${@os.path.relpath(infodir, prefix)}' \
+${@bb.utils.contains('PACKAGECONFIG', 'scripting', 'PYTHON=python3 
PYTHON_CONFIG=python3-config', '', d)} \
 "
 
 # During do_configure, we might run a 'make clean'. That often breaks
@@ -132,7 +133,7 @@ do_install() {
oe_runmake install
# we are checking for this make target to be compatible with older perf 
versions
if ${@bb.utils.contains('PACKAGECONFIG', 'scripting', 'true', 'false', 
d)} && grep -q install-python_ext ${S}/tools/perf/Makefile*; then
-   oe_runmake DESTDIR=${D} install-python_ext
+   oe_runmake DESTDIR=${D} install-python_ext
fi
 }
 
@@ -232,8 +233,10 @@ do_configure_prepend () {
 fi
 
 # use /usr/bin/env instead of version specific python
-for s in `find ${S}/tools/perf/scripts/python/ -name '*.py'`; do
-sed -i 's,/usr/bin/python2,/usr/bin/env python,' "${s}"
+for s in `find ${S}/tools/perf/ -name '*.py'`; do
+sed -i 's,/usr/bin/python,/usr/bin/env python3,' "${s}"
+sed -i 's,/usr/bin/python2,/usr/bin/env python3,' "${s}"
+sed -i 's,/usr/bin/env python2,/usr/bin/env python3,' "${s}"
 done
 
 # unistd.h can be out of sync between libc-headers and the captured 
version in the perf source
@@ -252,9 +255,9 @@ PACKAGES =+ "${PN}-archive ${PN}-tests ${PN}-perl 
${PN}-python"
 
 RDEPENDS_${PN} += "elfutils bash"
 RDEPENDS_${PN}-archive =+ "bash"
-RDEPENDS_${PN}-python =+ "bash python python-modules 
${@bb.utils.contains('PACKAGECONFIG', 'audit', 'audit-python', '', d)}"
+RDEPENDS_${PN}-python =+ "bash python3 python3-modules 
${@bb.utils.contains('PACKAGECONFIG', 'audit', 'audit-python3', '', d)}"
 RDEPENDS_${PN}-perl =+ "bash perl perl-modules"
-RDEPENDS_${PN}-tests =+ "python"
+RDEPENDS_${PN}-tests =+ "python3"
 
 RSUGGESTS_SCRIPTING = "${@bb.utils.contains('PACKAGECONFIG', 'scripting', 
'${PN}-perl ${PN}-python', '',d)}"
 RSUGGESTS_${PN} += "${PN}-archive ${PN}-tests ${RSUGGESTS_SCRIPTING}"
-- 
2.19.1

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

[OE-core] [PATCH 2/2] tune-cortexa57: add tunes for ARM Cortex-A57

[Meng.Li]

From: Limeng 

commit 3613b2780a6b5d5d70ea6802be5060a8214cbdb5 from
git://github.com/renesas-rcar/meta-renesas

Signed-off-by: Meng Li 
---
 meta/conf/machine/include/tune-cortexa57.inc | 18 ++
 1 file changed, 18 insertions(+)
 create mode 100644 meta/conf/machine/include/tune-cortexa57.inc

diff --git a/meta/conf/machine/include/tune-cortexa57.inc 
b/meta/conf/machine/include/tune-cortexa57.inc
new file mode 100644
index 00..4a458948e6
--- /dev/null
+++ b/meta/conf/machine/include/tune-cortexa57.inc
@@ -0,0 +1,18 @@
+DEFAULTTUNE ?= "cortexa57"
+require conf/machine/include/arm/arch-armv8a.inc
+
+TUNEVALID[cortexa57] = "Enable Cortex-A57 specific processor optimizations"
+TUNECONFLICTS[aarch64] = "armv4 armv5 armv6 armv7 armv7a"
+
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "aarch64", " 
-march=armv8-a", "" ,d)}"
+
+MACHINEOVERRIDES =. "${@bb.utils.contains("TUNE_FEATURES", "cortexa57", 
"cortexa57:", "" ,d)}"
+
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "cortexa57", " 
-mtune=cortex-a57", "", d)}"
+
+# Little Endian base configs
+AVAILTUNES += "cortexa57"
+ARMPKGARCH_tune-cortexa57 = "cortexa57"
+TUNE_FEATURES_tune-cortexa57 = "${TUNE_FEATURES_tune-aarch64} cortexa57"
+PACKAGE_EXTRA_ARCHS_tune-cortexa57 = "${PACKAGE_EXTRA_ARCHS_tune-aarch64} 
cortexa57"
+BASE_LIB_tune-cortexa57 = "lib64"
-- 
2.18.1

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

[OE-core] [yocto] : ARM-Cortex-Tune: Add 2 kinds of ARM-Cortex-Tune

[Meng.Li]

From: Limeng 


Recently, I am working on renesas-rcar platform based on yocto-2.7,
and I found there are no arm-cortexa57 and arm-cortexa57-cortexa53
tunes for some Renesas SoC.
Therefore, add 2 kinds of ARM-Cortex-Tune.

Detail patches as below:

0001-tune-cortexa57-cortexa53-add-tunes-for-ARM-Cortex-A5.patch
0002-tune-cortexa57-add-tunes-for-ARM-Cortex-A57.patch

 tune-cortexa57-cortexa53.inc |   18 ++
 tune-cortexa57.inc   |   18 ++
 2 files changed, 36 insertions(+)


thanks,
Limeng

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

[OE-core] [PATCH 1/2] tune-cortexa57-cortexa53: add tunes for ARM Cortex-A53-Cortex-A57

[Meng.Li]

From: Limeng 

commit 3613b2780a6b5d5d70ea6802be5060a8214cbdb5 from
git://github.com/renesas-rcar/meta-renesas

There are 2 types cores in renesas rcar SoC H3/M3, so add a tune
for ARM Cortex-A53-Cortex-A57.

Signed-off-by: Meng Li 
---
 .../include/tune-cortexa57-cortexa53.inc   | 18 ++
 1 file changed, 18 insertions(+)
 create mode 100644 meta/conf/machine/include/tune-cortexa57-cortexa53.inc

diff --git a/meta/conf/machine/include/tune-cortexa57-cortexa53.inc 
b/meta/conf/machine/include/tune-cortexa57-cortexa53.inc
new file mode 100644
index 00..d05e93f51e
--- /dev/null
+++ b/meta/conf/machine/include/tune-cortexa57-cortexa53.inc
@@ -0,0 +1,18 @@
+DEFAULTTUNE ?= "cortexa57-cortexa53"
+require conf/machine/include/arm/arch-armv8a.inc
+
+TUNEVALID[cortexa57-cortexa53] = "Enable big.LITTLE Cortex-A57.Cortex-A53 
specific processor optimizations"
+TUNECONFLICTS[aarch64] = "armv4 armv5 armv6 armv7 armv7a"
+
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "aarch64", " 
-march=armv8-a", "" ,d)}"
+
+MACHINEOVERRIDES =. "${@bb.utils.contains("TUNE_FEATURES", 
"cortexa57-cortexa53", "cortexa57-cortexa53:", "" ,d)}"
+
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "cortexa57-cortexa53", " 
-mtune=cortex-a57.cortex-a53", "", d)}"
+
+# Little Endian base configs
+AVAILTUNES += "cortexa57-cortexa53"
+ARMPKGARCH_tune-cortexa57-cortexa53 = "cortexa57-cortexa53"
+TUNE_FEATURES_tune-cortexa57-cortexa53 = "${TUNE_FEATURES_tune-aarch64} 
cortexa57-cortexa53"
+PACKAGE_EXTRA_ARCHS_tune-cortexa57-cortexa53 = 
"${PACKAGE_EXTRA_ARCHS_tune-aarch64} cortexa57-cortexa53"
+BASE_LIB_tune-cortexa57-cortexa53 = "lib64"
-- 
2.18.1

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

Re: [OE-core] [PATCH 6/8] perf: v5.3+ build fixes

[Bruce Ashfield]

On Wed, Aug 28, 2019 at 8:32 PM Bruce Ashfield  wrote:
>
> On Wed, Aug 28, 2019 at 3:28 PM  wrote:
> >
> > From: Bruce Ashfield 
> >
> > In the 5.3+ perf builds, there are multiple unistd.h files that need
> > to be kept in sync. So not only do we update one, we update both to
> > ensure that libc-headers and the perf build are in sync.
> >
> > perf checks some key files itself to be sure they are in sync, and
> > bits.h can be out of sync. There's no build error that results with
> > bits.h at the moment, but we still make sure they are in sync to
> > avoid the configure/compile warning.
> >
> > Signed-off-by: Bruce Ashfield 
> > ---
> >  meta/recipes-kernel/perf/perf.bb | 4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/meta/recipes-kernel/perf/perf.bb 
> > b/meta/recipes-kernel/perf/perf.bb
> > index 8ac8e7c308..58543c73d8 100644
> > --- a/meta/recipes-kernel/perf/perf.bb
> > +++ b/meta/recipes-kernel/perf/perf.bb
> > @@ -241,6 +241,10 @@ do_configure_prepend () {
> >  # unistd.h can be out of sync between libc-headers and the captured 
> > version in the perf source
> >  # so we copy it from the sysroot unistd.h to the perf unistd.h
> >  install -D -m0644 ${STAGING_INCDIR}/asm-generic/unistd.h 
> > ${S}/tools/include/uapi/asm-generic/unistd.h
> > +install -D -m0644 ${STAGING_INCDIR}/asm-generic/unistd.h 
> > ${S}/include/uapi/asm-generic/unistd.h
> > +
>
> I just realized this may not be safe across all the kernel versions.
> I'll submit a new version (if required), after I've tested my python3
> changes to perf.

I've tested this across 4.19 -> 5.3 and didn't find any issues. So it
should be safe and I won't send a v2.

Bruce

>
> Cheers,
>
> Bruce
>
> > +# bits.h can have the same issuen as unistd.h, so we make the tools 
> > variant take precedence
> > +install -D -m0644 ${S}/tools/include/linux/bits.h 
> > ${S}/include/linux/bits.h
> >  }
> >
> >  python do_package_prepend() {
> > --
> > 2.19.1
> >
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II



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

Re: [OE-core] [PATCH 5/8] perf: change dependencies on python to python3

[Bruce Ashfield]

On Wed, Aug 28, 2019 at 8:27 PM Bruce Ashfield  wrote:
>
> On Wed, Aug 28, 2019 at 8:24 PM Bruce Ashfield  
> wrote:
> >
> > On Wed, Aug 28, 2019 at 8:18 PM Mittal, Anuj  wrote:
> > >
> > > On Wed, 2019-08-28 at 20:13 -0400, Bruce Ashfield wrote:
> > > > > On Wed, Aug 28, 2019 at 8:01 PM Mittal, Anuj 
> > > > wrote:
> > > > This is causing failure for 5.0 kernels probably because the attr.py
> > > > > python -> python3 changes are not there ...
> > > > >
> > > > > ERROR: perf-1.0-r9 do_package_qa: QA Issue: /usr/libexec/perf-
> > > > > core/tests/attr.py contained in package perf-tests requires
> > > > > /usr/bin/python, but no providers found in RDEPENDS_perf-tests?
> > > > > [file-
> > > > > rdeps]
> > > > > ERROR: perf-1.0-r9 do_package_qa: QA run found fatal errors. Please
> > > > > consider fixing them.
> > > > > ERROR: Logfile of failure stored in: /home/pokybuild/yocto-
> > > > > worker/genericx86/build/build/tmp/work/genericx86-poky-
> > > > > linux/perf/1.0-
> > > > > r9/temp/log.do_package_qa.36284
> > > > > NOTE: recipe perf-1.0-r9: task do_package_qa: Failed
> > > > >
> > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/975/steps/8/logs/step1b
> > > > ote:
> > > unfortunately, I can only cover the active kernels in master with any
> > > certainty, and I already have a patch to drop 5.0, so I didn't
> > > > trigger
> > > this.
> > > I can spin a patch for 5.0 and make sure it is version proofed a ibt,
> > > but if anyone else has issues with , they'll
> > > > need
> > > > >
> > > > unfortunately, I can only cover the active kernels in master with any
> > >
> > > Can we cover at least the kernels in OE-Core master right now affected
> > > by this change? So 4.19 as well ...
> >
> > Consider 5.0 to be not there. It is going to be deleted in about a
> > day. My hands are very full, so I'm not able to spend much time on it
> > at the moment.
> >
> > 4.19 did work in my earlier testing, but I will have a look ASAP
> > (probably next week, since my cycles are largely spoken for at the
> > moment).
>
> .. but I will visually check 4.19 for any other scripts that reference
> just 'python' visually and make sure my tests are broad enough. It is
> more builder and boot cycles that I don't have easily accessible. It
> shouldn't be too hard to make the fixes generic and broad enough to
> cover it.

I retract that statement. I was able to jiggle things and testing on
4.19 is no big deal. I'll send a v2 that covers 4.19/5.0/5.2/5.3-rc
testing shortly.

Bruce

>
> Bruce
>
> >
> > Bruce
> >
> > >
> > > Thanks,
> > >
> > > Anuj
> >
> >
> >
> > --
> > - Thou shalt not follow the NULL pointer, for chaos and madness await
> > thee at its end
> > - "Use the force Harry" - Gandalf, Star Trek II
>
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II



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

Re: [OE-core] [PATCH 6/8] perf: v5.3+ build fixes

[Bruce Ashfield]

On Wed, Aug 28, 2019 at 3:28 PM  wrote:
>
> From: Bruce Ashfield 
>
> In the 5.3+ perf builds, there are multiple unistd.h files that need
> to be kept in sync. So not only do we update one, we update both to
> ensure that libc-headers and the perf build are in sync.
>
> perf checks some key files itself to be sure they are in sync, and
> bits.h can be out of sync. There's no build error that results with
> bits.h at the moment, but we still make sure they are in sync to
> avoid the configure/compile warning.
>
> Signed-off-by: Bruce Ashfield 
> ---
>  meta/recipes-kernel/perf/perf.bb | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/meta/recipes-kernel/perf/perf.bb 
> b/meta/recipes-kernel/perf/perf.bb
> index 8ac8e7c308..58543c73d8 100644
> --- a/meta/recipes-kernel/perf/perf.bb
> +++ b/meta/recipes-kernel/perf/perf.bb
> @@ -241,6 +241,10 @@ do_configure_prepend () {
>  # unistd.h can be out of sync between libc-headers and the captured 
> version in the perf source
>  # so we copy it from the sysroot unistd.h to the perf unistd.h
>  install -D -m0644 ${STAGING_INCDIR}/asm-generic/unistd.h 
> ${S}/tools/include/uapi/asm-generic/unistd.h
> +install -D -m0644 ${STAGING_INCDIR}/asm-generic/unistd.h 
> ${S}/include/uapi/asm-generic/unistd.h
> +

I just realized this may not be safe across all the kernel versions.
I'll submit a new version (if required), after I've tested my python3
changes to perf.

Cheers,

Bruce

> +# bits.h can have the same issuen as unistd.h, so we make the tools 
> variant take precedence
> +install -D -m0644 ${S}/tools/include/linux/bits.h 
> ${S}/include/linux/bits.h
>  }
>
>  python do_package_prepend() {
> --
> 2.19.1
>


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

Re: [OE-core] [PATCH 5/8] perf: change dependencies on python to python3

[Bruce Ashfield]

On Wed, Aug 28, 2019 at 8:24 PM Bruce Ashfield  wrote:
>
> On Wed, Aug 28, 2019 at 8:18 PM Mittal, Anuj  wrote:
> >
> > On Wed, 2019-08-28 at 20:13 -0400, Bruce Ashfield wrote:
> > > > On Wed, Aug 28, 2019 at 8:01 PM Mittal, Anuj 
> > > wrote:
> > > This is causing failure for 5.0 kernels probably because the attr.py
> > > > python -> python3 changes are not there ...
> > > >
> > > > ERROR: perf-1.0-r9 do_package_qa: QA Issue: /usr/libexec/perf-
> > > > core/tests/attr.py contained in package perf-tests requires
> > > > /usr/bin/python, but no providers found in RDEPENDS_perf-tests?
> > > > [file-
> > > > rdeps]
> > > > ERROR: perf-1.0-r9 do_package_qa: QA run found fatal errors. Please
> > > > consider fixing them.
> > > > ERROR: Logfile of failure stored in: /home/pokybuild/yocto-
> > > > worker/genericx86/build/build/tmp/work/genericx86-poky-
> > > > linux/perf/1.0-
> > > > r9/temp/log.do_package_qa.36284
> > > > NOTE: recipe perf-1.0-r9: task do_package_qa: Failed
> > > >
> > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/975/steps/8/logs/step1b
> > > ote:
> > unfortunately, I can only cover the active kernels in master with any
> > certainty, and I already have a patch to drop 5.0, so I didn't
> > > trigger
> > this.
> > I can spin a patch for 5.0 and make sure it is version proofed a ibt,
> > but if anyone else has issues with , they'll
> > > need
> > > >
> > > unfortunately, I can only cover the active kernels in master with any
> >
> > Can we cover at least the kernels in OE-Core master right now affected
> > by this change? So 4.19 as well ...
>
> Consider 5.0 to be not there. It is going to be deleted in about a
> day. My hands are very full, so I'm not able to spend much time on it
> at the moment.
>
> 4.19 did work in my earlier testing, but I will have a look ASAP
> (probably next week, since my cycles are largely spoken for at the
> moment).

.. but I will visually check 4.19 for any other scripts that reference
just 'python' visually and make sure my tests are broad enough. It is
more builder and boot cycles that I don't have easily accessible. It
shouldn't be too hard to make the fixes generic and broad enough to
cover it.

Bruce

>
> Bruce
>
> >
> > Thanks,
> >
> > Anuj
>
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II



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

Re: [OE-core] [PATCH 5/8] perf: change dependencies on python to python3

[Bruce Ashfield]

On Wed, Aug 28, 2019 at 8:18 PM Mittal, Anuj  wrote:
>
> On Wed, 2019-08-28 at 20:13 -0400, Bruce Ashfield wrote:
> > > On Wed, Aug 28, 2019 at 8:01 PM Mittal, Anuj 
> > wrote:
> > This is causing failure for 5.0 kernels probably because the attr.py
> > > python -> python3 changes are not there ...
> > >
> > > ERROR: perf-1.0-r9 do_package_qa: QA Issue: /usr/libexec/perf-
> > > core/tests/attr.py contained in package perf-tests requires
> > > /usr/bin/python, but no providers found in RDEPENDS_perf-tests?
> > > [file-
> > > rdeps]
> > > ERROR: perf-1.0-r9 do_package_qa: QA run found fatal errors. Please
> > > consider fixing them.
> > > ERROR: Logfile of failure stored in: /home/pokybuild/yocto-
> > > worker/genericx86/build/build/tmp/work/genericx86-poky-
> > > linux/perf/1.0-
> > > r9/temp/log.do_package_qa.36284
> > > NOTE: recipe perf-1.0-r9: task do_package_qa: Failed
> > >
> > > https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/975/steps/8/logs/step1b
> > ote:
> unfortunately, I can only cover the active kernels in master with any
> certainty, and I already have a patch to drop 5.0, so I didn't
> > trigger
> this.
> I can spin a patch for 5.0 and make sure it is version proofed a ibt,
> but if anyone else has issues with , they'll
> > need
> > >
> > unfortunately, I can only cover the active kernels in master with any
>
> Can we cover at least the kernels in OE-Core master right now affected
> by this change? So 4.19 as well ...

Consider 5.0 to be not there. It is going to be deleted in about a
day. My hands are very full, so I'm not able to spend much time on it
at the moment.

4.19 did work in my earlier testing, but I will have a look ASAP
(probably next week, since my cycles are largely spoken for at the
moment).

Bruce

>
> Thanks,
>
> Anuj



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

Re: [OE-core] [PATCH 5/8] perf: change dependencies on python to python3

[Mittal, Anuj]

On Wed, 2019-08-28 at 20:13 -0400, Bruce Ashfield wrote:
> > On Wed, Aug 28, 2019 at 8:01 PM Mittal, Anuj 
> wrote:
> This is causing failure for 5.0 kernels probably because the attr.py
> > python -> python3 changes are not there ...
> > 
> > ERROR: perf-1.0-r9 do_package_qa: QA Issue: /usr/libexec/perf-
> > core/tests/attr.py contained in package perf-tests requires
> > /usr/bin/python, but no providers found in RDEPENDS_perf-tests?
> > [file-
> > rdeps]
> > ERROR: perf-1.0-r9 do_package_qa: QA run found fatal errors. Please
> > consider fixing them.
> > ERROR: Logfile of failure stored in: /home/pokybuild/yocto-
> > worker/genericx86/build/build/tmp/work/genericx86-poky-
> > linux/perf/1.0-
> > r9/temp/log.do_package_qa.36284
> > NOTE: recipe perf-1.0-r9: task do_package_qa: Failed
> > 
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/975/steps/8/logs/step1b
> ote:
unfortunately, I can only cover the active kernels in master with any
certainty, and I already have a patch to drop 5.0, so I didn't
> trigger
this.
I can spin a patch for 5.0 and make sure it is version proofed a ibt,
but if anyone else has issues with , they'll
> need
> > 
> unfortunately, I can only cover the active kernels in master with any

Can we cover at least the kernels in OE-Core master right now affected
by this change? So 4.19 as well ...

Thanks,

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

Re: [OE-core] [PATCH 5/8] perf: change dependencies on python to python3

[Bruce Ashfield]

On Wed, Aug 28, 2019 at 8:01 PM Mittal, Anuj  wrote:
>
> This is causing failure for 5.0 kernels probably because the attr.py
> python -> python3 changes are not there ...
>
> ERROR: perf-1.0-r9 do_package_qa: QA Issue: /usr/libexec/perf-
> core/tests/attr.py contained in package perf-tests requires
> /usr/bin/python, but no providers found in RDEPENDS_perf-tests? [file-
> rdeps]
> ERROR: perf-1.0-r9 do_package_qa: QA run found fatal errors. Please
> consider fixing them.
> ERROR: Logfile of failure stored in: /home/pokybuild/yocto-
> worker/genericx86/build/build/tmp/work/genericx86-poky-linux/perf/1.0-
> r9/temp/log.do_package_qa.36284
> NOTE: recipe perf-1.0-r9: task do_package_qa: Failed
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/975/steps/8/logs/step1b

unfortunately, I can only cover the active kernels in master with any
certainty, and I already have a patch to drop 5.0, so I didn't trigger
this.
I can spin a patch for 5.0 and make sure it is version proofed a ibt,
but if anyone else has issues with , they'll need
to send their own patch.

Bruce

>
> Thanks,
>
> Anuj
>
> On Wed, 2019-08-28 at 15:28 -0400, bruce.ashfi...@gmail.com wrote:
> > From: Bruce Ashfield 
> >
> > The upstream kernel can now handle python3 for the perf scripts,
> > coupled
> > with the impending EOL of python2, we switch the dependencies in perf
> > (scripting) to python3.
> >
> > Outside of dependency changes, we also pass the following two
> > variables
> > to the perf build: PYTHON=python3 PYTHON_CONFIG=python3-config. To
> > ensure that our python3 components are used.
> >
> > For configurations that disable perf scripting, there is no change in
> > behaviour.
> >
> > [YOCTO #13358]
> >
> > Signed-off-by: Bruce Ashfield 
> > ---
> >  meta/recipes-kernel/perf/perf.bb | 16 +---
> >  1 file changed, 9 insertions(+), 7 deletions(-)
> >
> > diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-
> > kernel/perf/perf.bb
> > index 4e603f1a32..8ac8e7c308 100644
> > --- a/meta/recipes-kernel/perf/perf.bb
> > +++ b/meta/recipes-kernel/perf/perf.bb
> > @@ -13,7 +13,7 @@ PR = "r9"
> >
> >  PACKAGECONFIG ??= "scripting tui libunwind"
> >  PACKAGECONFIG[dwarf] = ",NO_DWARF=1"
> > -PACKAGECONFIG[scripting] = ",NO_LIBPERL=1 NO_LIBPYTHON=1,perl
> > python"
> > +PACKAGECONFIG[scripting] = ",NO_LIBPERL=1 NO_LIBPYTHON=1,perl
> > python3"
> >  # gui support was added with kernel 3.6.35
> >  # since 3.10 libnewt was replaced by slang
> >  # to cover a wide range of kernel we add both dependencies
> > @@ -44,8 +44,8 @@ PROVIDES = "virtual/perf"
> >  inherit linux-kernel-base kernel-arch manpages
> >
> >  # needed for building the tools/perf Python bindings
> > -inherit ${@bb.utils.contains('PACKAGECONFIG', 'scripting',
> > 'pythonnative', '', d)}
> > -inherit python-dir
> > +inherit ${@bb.utils.contains('PACKAGECONFIG', 'scripting',
> > 'python3native', '', d)}
> > +inherit python3-dir
> >  export PYTHON_SITEPACKAGES_DIR
> >
> >  #kernel 3.1+ supports WERROR to disable warnings as errors
> > @@ -94,6 +94,7 @@ EXTRA_OEMAKE += "\
> >  'sharedir=${@os.path.relpath(datadir, prefix)}' \
> >  'mandir=${@os.path.relpath(mandir, prefix)}' \
> >  'infodir=${@os.path.relpath(infodir, prefix)}' \
> > +${@bb.utils.contains('PACKAGECONFIG', 'scripting',
> > 'PYTHON=python3 PYTHON_CONFIG=python3-config', '', d)} \
> >  "
> >
> >  # During do_configure, we might run a 'make clean'. That often
> > breaks
> > @@ -132,7 +133,7 @@ do_install() {
> >   oe_runmake install
> >   # we are checking for this make target to be compatible with
> > older perf versions
> >   if ${@bb.utils.contains('PACKAGECONFIG', 'scripting', 'true',
> > 'false', d)} && grep -q install-python_ext ${S}/tools/perf/Makefile*;
> > then
> > - oe_runmake DESTDIR=${D} install-python_ext
> > + oe_runmake DESTDIR=${D} install-python_ext
> >   fi
> >  }
> >
> > @@ -233,7 +234,8 @@ do_configure_prepend () {
> >
> >  # use /usr/bin/env instead of version specific python
> >  for s in `find ${S}/tools/perf/scripts/python/ -name '*.py'`; do
> > -sed -i 's,/usr/bin/python2,/usr/bin/env python,' "${s}"
> > +sed -i 's,/usr/bin/python2,/usr/bin/env python3,' "${s}"
> > +sed -i 's,/usr/bin/env python2,/usr/bin/env python3,' "${s}"
> >  done
> >
> >  # unistd.h can be out of sync between libc-headers and the
> > captured version in the perf source
> > @@ -252,9 +254,9 @@ PACKAGES =+ "${PN}-archive ${PN}-tests ${PN}-perl
> > ${PN}-python"
> >
> >  RDEPENDS_${PN} += "elfutils bash"
> >  RDEPENDS_${PN}-archive =+ "bash"
> > -RDEPENDS_${PN}-python =+ "bash python python-modules
> > ${@bb.utils.contains('PACKAGECONFIG', 'audit', 'audit-python', '',
> > d)}"
> > +RDEPENDS_${PN}-python =+ "bash python3 python3-modules
> > ${@bb.utils.contains('PACKAGECONFIG', 'audit', 'audit-python3', '',
> > d)}"
> >  RDEPENDS_${PN}-perl =+ "bash perl perl-modules"
> > -RDEPENDS_${PN}-tests =+ 

Re: [OE-core] [PATCH 5/8] perf: change dependencies on python to python3

[Mittal, Anuj]

This is causing failure for 5.0 kernels probably because the attr.py
python -> python3 changes are not there ... 

ERROR: perf-1.0-r9 do_package_qa: QA Issue: /usr/libexec/perf-
core/tests/attr.py contained in package perf-tests requires
/usr/bin/python, but no providers found in RDEPENDS_perf-tests? [file-
rdeps]
ERROR: perf-1.0-r9 do_package_qa: QA run found fatal errors. Please
consider fixing them.
ERROR: Logfile of failure stored in: /home/pokybuild/yocto-
worker/genericx86/build/build/tmp/work/genericx86-poky-linux/perf/1.0-
r9/temp/log.do_package_qa.36284
NOTE: recipe perf-1.0-r9: task do_package_qa: Failed

https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/975/steps/8/logs/step1b

Thanks,

Anuj

On Wed, 2019-08-28 at 15:28 -0400, bruce.ashfi...@gmail.com wrote:
> From: Bruce Ashfield 
> 
> The upstream kernel can now handle python3 for the perf scripts,
> coupled
> with the impending EOL of python2, we switch the dependencies in perf
> (scripting) to python3.
> 
> Outside of dependency changes, we also pass the following two
> variables
> to the perf build: PYTHON=python3 PYTHON_CONFIG=python3-config. To
> ensure that our python3 components are used.
> 
> For configurations that disable perf scripting, there is no change in
> behaviour.
> 
> [YOCTO #13358]
> 
> Signed-off-by: Bruce Ashfield 
> ---
>  meta/recipes-kernel/perf/perf.bb | 16 +---
>  1 file changed, 9 insertions(+), 7 deletions(-)
> 
> diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-
> kernel/perf/perf.bb
> index 4e603f1a32..8ac8e7c308 100644
> --- a/meta/recipes-kernel/perf/perf.bb
> +++ b/meta/recipes-kernel/perf/perf.bb
> @@ -13,7 +13,7 @@ PR = "r9"
>  
>  PACKAGECONFIG ??= "scripting tui libunwind"
>  PACKAGECONFIG[dwarf] = ",NO_DWARF=1"
> -PACKAGECONFIG[scripting] = ",NO_LIBPERL=1 NO_LIBPYTHON=1,perl
> python"
> +PACKAGECONFIG[scripting] = ",NO_LIBPERL=1 NO_LIBPYTHON=1,perl
> python3"
>  # gui support was added with kernel 3.6.35
>  # since 3.10 libnewt was replaced by slang
>  # to cover a wide range of kernel we add both dependencies
> @@ -44,8 +44,8 @@ PROVIDES = "virtual/perf"
>  inherit linux-kernel-base kernel-arch manpages
>  
>  # needed for building the tools/perf Python bindings
> -inherit ${@bb.utils.contains('PACKAGECONFIG', 'scripting',
> 'pythonnative', '', d)}
> -inherit python-dir
> +inherit ${@bb.utils.contains('PACKAGECONFIG', 'scripting',
> 'python3native', '', d)}
> +inherit python3-dir
>  export PYTHON_SITEPACKAGES_DIR
>  
>  #kernel 3.1+ supports WERROR to disable warnings as errors
> @@ -94,6 +94,7 @@ EXTRA_OEMAKE += "\
>  'sharedir=${@os.path.relpath(datadir, prefix)}' \
>  'mandir=${@os.path.relpath(mandir, prefix)}' \
>  'infodir=${@os.path.relpath(infodir, prefix)}' \
> +${@bb.utils.contains('PACKAGECONFIG', 'scripting',
> 'PYTHON=python3 PYTHON_CONFIG=python3-config', '', d)} \
>  "
>  
>  # During do_configure, we might run a 'make clean'. That often
> breaks
> @@ -132,7 +133,7 @@ do_install() {
>   oe_runmake install
>   # we are checking for this make target to be compatible with
> older perf versions
>   if ${@bb.utils.contains('PACKAGECONFIG', 'scripting', 'true',
> 'false', d)} && grep -q install-python_ext ${S}/tools/perf/Makefile*;
> then
> - oe_runmake DESTDIR=${D} install-python_ext
> + oe_runmake DESTDIR=${D} install-python_ext
>   fi
>  }
>  
> @@ -233,7 +234,8 @@ do_configure_prepend () {
>  
>  # use /usr/bin/env instead of version specific python
>  for s in `find ${S}/tools/perf/scripts/python/ -name '*.py'`; do
> -sed -i 's,/usr/bin/python2,/usr/bin/env python,' "${s}"
> +sed -i 's,/usr/bin/python2,/usr/bin/env python3,' "${s}"
> +sed -i 's,/usr/bin/env python2,/usr/bin/env python3,' "${s}"
>  done
>  
>  # unistd.h can be out of sync between libc-headers and the
> captured version in the perf source
> @@ -252,9 +254,9 @@ PACKAGES =+ "${PN}-archive ${PN}-tests ${PN}-perl 
> ${PN}-python"
>  
>  RDEPENDS_${PN} += "elfutils bash"
>  RDEPENDS_${PN}-archive =+ "bash"
> -RDEPENDS_${PN}-python =+ "bash python python-modules 
> ${@bb.utils.contains('PACKAGECONFIG', 'audit', 'audit-python', '',
> d)}"
> +RDEPENDS_${PN}-python =+ "bash python3 python3-modules 
> ${@bb.utils.contains('PACKAGECONFIG', 'audit', 'audit-python3', '',
> d)}"
>  RDEPENDS_${PN}-perl =+ "bash perl perl-modules"
> -RDEPENDS_${PN}-tests =+ "python"
> +RDEPENDS_${PN}-tests =+ "python3"
>  
>  RSUGGESTS_SCRIPTING = "${@bb.utils.contains('PACKAGECONFIG',
> 'scripting', '${PN}-perl ${PN}-python', '',d)}"
>  RSUGGESTS_${PN} += "${PN}-archive ${PN}-tests
> ${RSUGGESTS_SCRIPTING}"
> -- 
> 2.19.1
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] serial-getty@.service: Allow device to fast fail if it does not exist

[Richard Purdie]

On Wed, 2019-08-28 at 15:24 -0500, Jason Wessel wrote:
> On 8/27/19 7:15 PM, richard.pur...@linuxfoundation.org wrote:
> > On Tue, 2019-08-27 at 19:03 -0500, Jason Wessel wrote:
> > > On 8/27/19 5:58 PM, Richard Purdie wrote:
> > > > Hi Jason,
> > > > Somehow this change is responsible for this build failure:
> > > > 
> > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/72/builds/976
> > > > 
> > > > (steps 5c and 7c so failure during testimage).
> > > > 
> > > > I have bisected it to this change, I haven't looked into why.
> > > 
> > > Thanks for tracking it down.   I am sure how to try an duplicate
> > > this.  I clicked around to try and find out a bit about what it
> > > is
> > > running for these phases of the build but it is not very obvious.
> > > 
> > > Is there a local.conf I can try along with what ever commands it
> > > ran?
> > 
> > The configuration its using is shown in
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/72/builds/978/steps/8/logs/stdio
> > for each step.
> > 
> 
> I tried the configuration on my system but it seems to work fine, see
> below.   Is there a way to get complete log file of the boot on the
> broken host?  I am also curious if it fails every time or not.
> 
> /home/pokybuild/yocto-worker/qa-
> extras2/build/build/tmp/work/qemux86_64-poky-linux/core-image-
> sato/1.0-r0/testimage/qemu_boot_log.2019082722
> 
> I am not sure it will tell us anything further or not, but it
> certainly looks like the system didn't boot correctly in the first
> place.

I've rerun it as 
https://autobuilder.yoctoproject.org/typhoon/#/builders/72/builds/983

Cheers,

Richard

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

Re: [OE-core] [PATCH] serial-getty@.service: Allow device to fast fail if it does not exist

[richard . purdie]

On Wed, 2019-08-28 at 15:24 -0500, Jason Wessel wrote:
> On 8/27/19 7:15 PM, richard.pur...@linuxfoundation.org wrote:
> > On Tue, 2019-08-27 at 19:03 -0500, Jason Wessel wrote:
> > > On 8/27/19 5:58 PM, Richard Purdie wrote:
> > > > Hi Jason,
> > > > Somehow this change is responsible for this build failure:
> > > > 
> > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/72/builds/976
> > > > 
> > > > (steps 5c and 7c so failure during testimage).
> > > > 
> > > > I have bisected it to this change, I haven't looked into why.
> > > 
> > > Thanks for tracking it down.   I am sure how to try an duplicate
> > > this.  I clicked around to try and find out a bit about what it
> > > is
> > > running for these phases of the build but it is not very obvious.
> > > 
> > > Is there a local.conf I can try along with what ever commands it
> > > ran?
> > 
> > The configuration its using is shown in
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/72/builds/978/steps/8/logs/stdio
> > for each step.
> > 
> 
> I tried the configuration on my system but it seems to work fine, see
> below.   Is there a way to get complete log file of the boot on the
> broken host?  I am also curious if it fails every time or not.
> 
> /home/pokybuild/yocto-worker/qa-
> extras2/build/build/tmp/work/qemux86_64-poky-linux/core-image-
> sato/1.0-r0/testimage/qemu_boot_log.2019082722

If we'd got this straight after the build then yes but its been
recycled now.

It did seem to fail repeatedly when I tested it. I'd probably have to
add the patch back and retest again to get the log.

> I am not sure it will tell us anything further or not, but it
> certainly looks like the system didn't boot correctly in the first
> place.

It does seem like a boot issue somehow...

The test case one the autobuilder seems simple enough, systemd boot
alone with no sysvinit.

Cheers,

Richard

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

Re: [OE-core] [PATCH 4/8] kernel-devsrc: remove python2 dependency

[Bruce Ashfield]

On Wed, Aug 28, 2019 at 5:58 PM Adrian Bunk  wrote:
>
> On Wed, Aug 28, 2019 at 04:11:43PM -0400, Bruce Ashfield wrote:
> >...
> > There's zero risk to these, and no reason to sit on them.
>
> What range of LTS kernels is covered by the "zero risk"?

It has nothing to do with LTS kernels.

Cheers,

Bruce

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


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

[OE-core] ✗ patchtest: failure for bitbake: cooker: Ensure bbappends are found in stable order

[Patchwork]

== Series Details ==

Series: bitbake: cooker: Ensure bbappends are found in stable order
Revision: 1
URL   : https://patchwork.openembedded.org/series/19547/
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 bitbake-de...@lists.openembedded.org 
[http://git.openembedded.org/bitbake/]
  Patch's path:bitbake/lib/bb/cooker.py

* 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 684fc36402)



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

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

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

Re: [OE-core] [PATCH 4/8] kernel-devsrc: remove python2 dependency

[Adrian Bunk]

On Wed, Aug 28, 2019 at 04:11:43PM -0400, Bruce Ashfield wrote:
>...
> There's zero risk to these, and no reason to sit on them.

What range of LTS kernels is covered by the "zero risk"?

> Bruce

cu
Adrian

-- 

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

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

[OE-core] [PATCH] bitbake: cooker: Ensure bbappends are found in stable order

[Wes Lindauer]

Thanks to wildcards in bbappend filenames, it's possible to have
multiple bbappends that apply to the same recipe in the same directory.
In order to get sstate hits between different workspaces, we want to
apply those bbappend files in a consistent order.  Since readdir()
returns files in a non-deterministic order between workspaces (based on
inode number and/or time of creation), we'll need to sort its result in
order to have any consistency.

Signed-off-by: Wes Lindauer 
---
 bitbake/lib/bb/cooker.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/bitbake/lib/bb/cooker.py b/bitbake/lib/bb/cooker.py
index 0607fcc708..a9ee142aa5 100644
--- a/bitbake/lib/bb/cooker.py
+++ b/bitbake/lib/bb/cooker.py
@@ -1869,6 +1869,7 @@ class CookerCollectFiles(object):
 (bbappend, filename) = b
 if (bbappend == f) or ('%' in bbappend and 
bbappend.startswith(f[:bbappend.index('%')])):
 filelist.append(filename)
+filelist.sort()
 return filelist
 
 def collection_priorities(self, pkgfns, d):
-- 
2.14.5

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

Re: [OE-core] [PATCH 4/8] kernel-devsrc: remove python2 dependency

[Alexander Kanavin]

On Wed, 28 Aug 2019 at 22:12,  wrote:

> > Yocto 3.0 ships and supports Python 2.7, so there is no urgent need
> > for
> > last-minute Python 2 -> 3 changes.
>
> Removal of 2.X dependencies where we can was an objective of 3.0 and
> 2.X is EOL and will expire in the lifetime of 3.0. I'd say this is
> therefore quite in keeping with that...
>

I just sent the ltp patch, the last remaining target piece. What remains is
eliminating the undercover usage of host python2 at build time (I am now
running test builds to determine what needs fixing), and then dropping py2
from self-hosted packagegroup and HOSTTOOLS. Once we're there, we can
remove py2 recipes from oe-core (which will probably happen after 3.0 is
out).

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

[OE-core] [PATCH] ltp: move from python 2.x to python 3.x

[Alexander Kanavin]

Signed-off-by: Alexander Kanavin 
---
 ...thon3-everywhere-to-run-python-scrip.patch | 161 ++
 meta/recipes-extended/ltp/ltp_20190517.bb |   3 +-
 2 files changed, 163 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-extended/ltp/ltp/0001-testcases-use-python3-everywhere-to-run-python-scrip.patch

diff --git 
a/meta/recipes-extended/ltp/ltp/0001-testcases-use-python3-everywhere-to-run-python-scrip.patch
 
b/meta/recipes-extended/ltp/ltp/0001-testcases-use-python3-everywhere-to-run-python-scrip.patch
new file mode 100644
index 000..f4f87f38ab7
--- /dev/null
+++ 
b/meta/recipes-extended/ltp/ltp/0001-testcases-use-python3-everywhere-to-run-python-scrip.patch
@@ -0,0 +1,161 @@
+From 0463d793566772a606255957915f99d166d5740c Mon Sep 17 00:00:00 2001
+From: Alexander Kanavin 
+Date: Wed, 28 Aug 2019 18:30:23 +0200
+Subject: [PATCH] testcases: use python3 everywhere to run python scripts
+
+The scripts themselves have #!/usr/bin/python3 in them,
+so I trust they are already py3-compatible.
+
+Upstream-Status: Pending
+Signed-off-by: Alexander Kanavin 
+---
+ testcases/kernel/power_management/runpwtests05.sh  |  2 +-
+ .../power_management/runpwtests_exclusive01.sh |  2 +-
+ .../power_management/runpwtests_exclusive02.sh |  2 +-
+ .../power_management/runpwtests_exclusive03.sh |  2 +-
+ .../power_management/runpwtests_exclusive04.sh |  2 +-
+ .../power_management/runpwtests_exclusive05.sh |  2 +-
+ testcases/network/nfsv4/acl/runtest| 14 +++---
+ testcases/realtime/func/pi-tests/run_auto.sh   |  6 +++---
+ 8 files changed, 16 insertions(+), 16 deletions(-)
+
+diff --git a/testcases/kernel/power_management/runpwtests05.sh 
b/testcases/kernel/power_management/runpwtests05.sh
+index 8a7d0f6e0..43e234d01 100755
+--- a/testcases/kernel/power_management/runpwtests05.sh
 b/testcases/kernel/power_management/runpwtests05.sh
+@@ -35,7 +35,7 @@ else
+   max_sched_smt=1
+ fi
+ 
+-tst_test_cmds python
++tst_test_cmds python3
+ 
+ if ! grep sched_debug -qw /proc/cmdline ; then
+   tst_brkm TCONF "Kernel cmdline parameter 'sched_debug' needed," \
+diff --git a/testcases/kernel/power_management/runpwtests_exclusive01.sh 
b/testcases/kernel/power_management/runpwtests_exclusive01.sh
+index ec78319e2..9fefcbf6e 100755
+--- a/testcases/kernel/power_management/runpwtests_exclusive01.sh
 b/testcases/kernel/power_management/runpwtests_exclusive01.sh
+@@ -35,7 +35,7 @@ else
+   max_sched_smt=1
+ fi
+ 
+-tst_test_cmds python
++tst_test_cmds python3
+ 
+ hyper_threaded=$(is_hyper_threaded)
+ multi_socket=$(is_multi_socket)
+diff --git a/testcases/kernel/power_management/runpwtests_exclusive02.sh 
b/testcases/kernel/power_management/runpwtests_exclusive02.sh
+index e107fce35..2cd0ecb05 100755
+--- a/testcases/kernel/power_management/runpwtests_exclusive02.sh
 b/testcases/kernel/power_management/runpwtests_exclusive02.sh
+@@ -33,7 +33,7 @@ else
+   max_sched_smt=1
+ fi
+ 
+-tst_test_cmds python
++tst_test_cmds python3
+ 
+ hyper_threaded=$(is_hyper_threaded)
+ multi_socket=$(is_multi_socket)
+diff --git a/testcases/kernel/power_management/runpwtests_exclusive03.sh 
b/testcases/kernel/power_management/runpwtests_exclusive03.sh
+index 490344bb3..ab3a5d11d 100755
+--- a/testcases/kernel/power_management/runpwtests_exclusive03.sh
 b/testcases/kernel/power_management/runpwtests_exclusive03.sh
+@@ -35,7 +35,7 @@ else
+   max_sched_smt=1
+ fi
+ 
+-tst_test_cmds python
++tst_test_cmds python3
+ 
+ hyper_threaded=$(is_hyper_threaded)
+ multi_socket=$(is_multi_socket)
+diff --git a/testcases/kernel/power_management/runpwtests_exclusive04.sh 
b/testcases/kernel/power_management/runpwtests_exclusive04.sh
+index 978ca02ae..438ef603f 100755
+--- a/testcases/kernel/power_management/runpwtests_exclusive04.sh
 b/testcases/kernel/power_management/runpwtests_exclusive04.sh
+@@ -27,7 +27,7 @@ export TST_TOTAL=2
+ # Checking test environment
+ check_kervel_arch
+ 
+-tst_test_cmds python
++tst_test_cmds python3
+ 
+ hyper_threaded=$(is_hyper_threaded)
+ multi_socket=$(is_multi_socket)
+diff --git a/testcases/kernel/power_management/runpwtests_exclusive05.sh 
b/testcases/kernel/power_management/runpwtests_exclusive05.sh
+index a0dad5834..3a9afdbf2 100755
+--- a/testcases/kernel/power_management/runpwtests_exclusive05.sh
 b/testcases/kernel/power_management/runpwtests_exclusive05.sh
+@@ -35,7 +35,7 @@ else
+   max_sched_smt=1
+ fi
+ 
+-tst_test_cmds python
++tst_test_cmds python3
+ 
+ hyper_threaded=$(is_hyper_threaded)
+ multi_socket=$(is_multi_socket)
+diff --git a/testcases/network/nfsv4/acl/runtest 
b/testcases/network/nfsv4/acl/runtest
+index d2e1b4c49..a859e85bc 100755
+--- a/testcases/network/nfsv4/acl/runtest
 b/testcases/network/nfsv4/acl/runtest
+@@ -22,7 +22,7 @@ do
+ done
+ 
+ #  creation of users on the remote machine (removed only at the end of the 
tests)
+-rsh -n $REMOTEHOST python $PWD/create_users.py -u 50 

Re: [OE-core] [PATCH] serial-getty@.service: Allow device to fast fail if it does not exist

[Jason Wessel]

On 8/27/19 7:15 PM, richard.pur...@linuxfoundation.org wrote:

On Tue, 2019-08-27 at 19:03 -0500, Jason Wessel wrote:


On 8/27/19 5:58 PM, Richard Purdie wrote:

Hi Jason,
Somehow this change is responsible for this build failure:

https://autobuilder.yoctoproject.org/typhoon/#/builders/72/builds/976

(steps 5c and 7c so failure during testimage).

I have bisected it to this change, I haven't looked into why.


Thanks for tracking it down.   I am sure how to try an duplicate
this.  I clicked around to try and find out a bit about what it is
running for these phases of the build but it is not very obvious.

Is there a local.conf I can try along with what ever commands it ran?


The configuration its using is shown in
https://autobuilder.yoctoproject.org/typhoon/#/builders/72/builds/978/steps/8/logs/stdio
for each step.




I tried the configuration on my system but it seems to work fine, see below.   
Is there a way to get complete log file of the boot on the broken host?  I am 
also curious if it fails every time or not.

/home/pokybuild/yocto-worker/qa-extras2/build/build/tmp/work/qemux86_64-poky-linux/core-image-sato/1.0-r0/testimage/qemu_boot_log.2019082722

I am not sure it will tell us anything further or not, but it certainly looks 
like the system didn't boot correctly in the first place.


Jason.





Initialising tasks: 100% 
|###
Sstate summary: Wanted 0 Found 0 Missed 0 Current 90 (0% match, 100% complete)
NOTE: Executing Tasks
NOTE: Setscene tasks completed
Started HTTPService on 128.224.149.46:38317
Test requires apt to be installed
Stopped HTTPService on 128.224.149.46:38317
Test requires autoconf to be installed
Test requires gtk+3 to be installed
Test requires autoconf to be installed
Started HTTPService on 128.224.149.46:32961
Stopped HTTPService on 128.224.149.46:32961
Test requires gcc to be installed
Test requires g++ to be installed
Test requires g++ to be installed
Test requires make to be installed
Test requires python3-pygobject to be installed
Test requires gcc to be installed
Test requires ldd to be installed
Test requires logrotate to be installed
Test case logrotate.LogrotateTest.test_2_logrotate depends on 
logrotate.LogrotateTest.test_1_logrotate_setup but it didn'
Not appropiate for systemd image
Test requires opkg to be installed
Test requires pam to be in DISTRO_FEATURES
Test requires ptest-runner to be installed
Test requires systemtap to be installed
Startup finished in 3.840s (kernel) + 2.157s (userspace) = 5.998s.
RESULTS:
RESULTS - connman.ConnmanTest.test_connmand_help: PASSED (0.11s)
RESULTS - connman.ConnmanTest.test_connmand_running: PASSED (0.11s)
RESULTS - date.DateTest.test_date: PASSED (0.63s)
RESULTS - df.DfTest.test_df: PASSED (0.11s)
RESULTS - dnf.DnfBasicTest.test_dnf_help: PASSED (0.78s)
RESULTS - dnf.DnfBasicTest.test_dnf_history: PASSED (0.44s)
RESULTS - dnf.DnfBasicTest.test_dnf_info: PASSED (0.37s)
RESULTS - dnf.DnfBasicTest.test_dnf_search: PASSED (0.35s)
RESULTS - dnf.DnfBasicTest.test_dnf_version: PASSED (0.32s)
RESULTS - dnf.DnfRepoTest.test_dnf_exclude: PASSED (5.03s)
RESULTS - dnf.DnfRepoTest.test_dnf_install: PASSED (0.78s)
RESULTS - dnf.DnfRepoTest.test_dnf_install_dependency: PASSED (1.77s)
RESULTS - dnf.DnfRepoTest.test_dnf_install_from_disk: PASSED (1.97s)
RESULTS - dnf.DnfRepoTest.test_dnf_install_from_http: PASSED (1.52s)
RESULTS - dnf.DnfRepoTest.test_dnf_installroot: PASSED (6.91s)
RESULTS - dnf.DnfRepoTest.test_dnf_makecache: PASSED (0.42s)
RESULTS - dnf.DnfRepoTest.test_dnf_reinstall: PASSED (0.61s)
RESULTS - dnf.DnfRepoTest.test_dnf_repoinfo: PASSED (0.35s)
RESULTS - oe_syslog.SyslogTest.test_syslog_running: PASSED (0.12s)
RESULTS - oe_syslog.SyslogTestConfig.test_syslog_logger: PASSED (1.21s)
RESULTS - oe_syslog.SyslogTestConfig.test_syslog_restart: PASSED (0.21s)
RESULTS - parselogs.ParseLogsTest.test_parselogs: PASSED (1.91s)
RESULTS - perl.PerlTest.test_perl_works: PASSED (0.11s)
RESULTS - ping.PingTest.test_ping: PASSED (0.06s)
RESULTS - python.PythonTest.test_python3: PASSED (0.12s)
RESULTS - rpm.RpmBasicTest.test_rpm_help: PASSED (0.11s)
RESULTS - rpm.RpmBasicTest.test_rpm_query: PASSED (0.18s)
RESULTS - rpm.RpmBasicTest.test_rpm_query_nonroot: PASSED (0.89s)
RESULTS - 
rpm.RpmInstallRemoveTest.test_check_rpm_install_removal_log_file_size: PASSED 
(3.54s)
RESULTS - rpm.RpmInstallRemoveTest.test_rpm_install: PASSED (0.37s)
RESULTS - rpm.RpmInstallRemoveTest.test_rpm_remove: PASSED (0.15s)
RESULTS - scp.ScpTest.test_scp_file: PASSED (0.41s)
RESULTS - ssh.SSHTest.test_ssh: PASSED (0.51s)
RESULTS - systemd.SystemdBasicTests.test_systemd_basic: PASSED (0.12s)
RESULTS - systemd.SystemdBasicTests.test_systemd_failed: PASSED (0.21s)
RESULTS - systemd.SystemdBasicTests.test_systemd_list: PASSED (0.44s)
RESULTS - systemd.SystemdJournalTests.test_systemd_boot_time: PASSED (0.11s)
RESULTS - 

Re: [OE-core] [PATCH 4/8] kernel-devsrc: remove python2 dependency

[richard . purdie]

On Wed, 2019-08-28 at 23:05 +0300, Adrian Bunk wrote:
> On Wed, Aug 28, 2019 at 03:28:38PM -0400, bruce.ashfi...@gmail.com
> wrote:
> > From: Bruce Ashfield 
> > 
> > Witht the approaching EOL of python2, the kernel packages need to
> > be updated to depend on python3.
> > ...
> 
> Yocto 3.0 ships and supports Python 2.7, so there is no urgent need
> for 
> last-minute Python 2 -> 3 changes.

Removal of 2.X dependencies where we can was an objective of 3.0 and
2.X is EOL and will expire in the lifetime of 3.0. I'd say this is
therefore quite in keeping with that...

Cheers,

Richard

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

Re: [OE-core] [PATCH 4/8] kernel-devsrc: remove python2 dependency

[Bruce Ashfield]

On Wed, Aug 28, 2019 at 4:05 PM Adrian Bunk  wrote:
>
> On Wed, Aug 28, 2019 at 03:28:38PM -0400, bruce.ashfi...@gmail.com wrote:
> > From: Bruce Ashfield 
> >
> > Witht the approaching EOL of python2, the kernel packages need to
> > be updated to depend on python3.
> >...
>
> Yocto 3.0 ships and supports Python 2.7, so there is no urgent need for
> last-minute Python 2 -> 3 changes.

Actually, there is.

This was discussed in detail on the yocto dev call, Richard is waiting
for these changes. In particular, since the support window for this
release goes out past the EOL, and one of the stretch goals was a
python2 free image. There's zero risk to these, and no reason to sit
on them.

Bruce

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


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

[OE-core] [PATCH v2] linux-yocto: introduce 5.2 recipes

[bruce . ashfield]

From: Bruce Ashfield 

Introducing the 5.2 linux-yocto reference kernels. 5.0 is EOL and will
be removed, leaving 4.19 (LTS) and 5.2 as the reference kernels.

This has been build/boot tested on all qemu architectures for
core-image-kernel-dev, and graphics tesed via core-image-sato. No
blocking issues have been found.

Signed-off-by: Bruce Ashfield 
---

v2: dropped the bogus "foo.patch" which crept in during the git add.

Bruce

 .../linux/linux-yocto-rt_5.2.bb   | 44 +++
 .../linux/linux-yocto-tiny_5.2.bb | 32 +++
 meta/recipes-kernel/linux/linux-yocto_5.2.bb  | 54 +++
 3 files changed, 130 insertions(+)
 create mode 100644 meta/recipes-kernel/linux/linux-yocto-rt_5.2.bb
 create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny_5.2.bb
 create mode 100644 meta/recipes-kernel/linux/linux-yocto_5.2.bb

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.2.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_5.2.bb
new file mode 100644
index 00..b4376b431d
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.2.bb
@@ -0,0 +1,44 @@
+KBRANCH ?= "v5.2/standard/preempt-rt/base"
+
+require recipes-kernel/linux/linux-yocto.inc
+
+# Skip processing of this recipe if it is not explicitly specified as the
+# PREFERRED_PROVIDER for virtual/kernel. This avoids errors when trying
+# to build multiple virtual/kernel providers, e.g. as dependency of
+# core-image-rt-sdk, core-image-rt.
+python () {
+if d.getVar("KERNEL_PACKAGE_NAME") == "kernel" and 
d.getVar("PREFERRED_PROVIDER_virtual/kernel") != "linux-yocto-rt":
+raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to 
linux-yocto-rt to enable it")
+}
+
+SRCREV_machine ?= "ea07aa34bed4e662fe374d04d50b6ddb9882bb19"
+SRCREV_meta ?= "b53e99257175fd6f41f31e5ebec46c1bd11076b8"
+
+SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \
+   
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.2;destsuffix=${KMETA}"
+
+LINUX_VERSION ?= "5.2.10"
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=bbea815ee2795b2f4230826c0c6b8814"
+
+DEPENDS += "${@bb.utils.contains('ARCH', 'x86', 'elfutils-native', '', d)}"
+DEPENDS += "openssl-native util-linux-native"
+
+PV = "${LINUX_VERSION}+git${SRCPV}"
+
+KMETA = "kernel-meta"
+KCONF_BSP_AUDIT_LEVEL = "2"
+
+LINUX_KERNEL_TYPE = "preempt-rt"
+
+COMPATIBLE_MACHINE = 
"(qemux86|qemux86-64|qemuarm|qemuarmv5|qemuarm64|qemuppc|qemumips)"
+
+KERNEL_DEVICETREE_qemuarmv5 = "versatile-pb.dtb"
+
+# Functionality flags
+KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc 
features/taskstats/taskstats.scc"
+KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}"
+KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc"
+KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc"
+KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc"
+KERNEL_FEATURES_append = "${@bb.utils.contains("DISTRO_FEATURES", "ptest", " 
features/scsi/scsi-debug.scc", "" ,d)}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.2.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_5.2.bb
new file mode 100644
index 00..f55e607b97
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.2.bb
@@ -0,0 +1,32 @@
+KBRANCH ?= "v5.2/standard/tiny/base"
+KBRANCH_qemuarm  ?= "v5.2/standard/tiny/arm-versatile-926ejs"
+
+LINUX_KERNEL_TYPE = "tiny"
+KCONFIG_MODE = "--allnoconfig"
+
+require recipes-kernel/linux/linux-yocto.inc
+
+LINUX_VERSION ?= "5.2.10"
+LIC_FILES_CHKSUM = "file://COPYING;md5=bbea815ee2795b2f4230826c0c6b8814"
+
+DEPENDS += "${@bb.utils.contains('ARCH', 'x86', 'elfutils-native', '', d)}"
+DEPENDS += "openssl-native util-linux-native"
+
+KMETA = "kernel-meta"
+KCONF_BSP_AUDIT_LEVEL = "2"
+
+SRCREV_machine_qemuarm ?= "ab7b49b196280d4289f18c35cf6ea534f364d104"
+SRCREV_machine ?= "77c28ea0e55cabb0b22b47d4eb2cc94b0940dfe6"
+SRCREV_meta ?= "b53e99257175fd6f41f31e5ebec46c1bd11076b8"
+
+PV = "${LINUX_VERSION}+git${SRCPV}"
+
+SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \
+   
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.2;destsuffix=${KMETA}"
+
+COMPATIBLE_MACHINE = "qemux86|qemux86-64|qemuarm|qemuarmv5"
+
+# Functionality flags
+KERNEL_FEATURES = ""
+
+KERNEL_DEVICETREE_qemuarmv5 = "versatile-pb.dtb"
diff --git a/meta/recipes-kernel/linux/linux-yocto_5.2.bb 
b/meta/recipes-kernel/linux/linux-yocto_5.2.bb
new file mode 100644
index 00..d873a1f2b3
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto_5.2.bb
@@ -0,0 +1,54 @@
+KBRANCH ?= "v5.2/standard/base"
+
+require recipes-kernel/linux/linux-yocto.inc
+
+# board specific branches
+KBRANCH_qemuarm  ?= "v5.2/standard/arm-versatile-926ejs"
+KBRANCH_qemuarm64 ?= "v5.2/standard/qemuarm64"
+KBRANCH_qemumips ?= "v5.2/standard/mti-malta32"
+KBRANCH_qemuppc  ?= "v5.2/standard/qemuppc"
+KBRANCH_qemuriscv64  ?= "v5.2/standard/base"

Re: [OE-core] [PATCH 2/8] linux-yocto: introduce 5.2 recipes

[Bruce Ashfield]

On Wed, Aug 28, 2019 at 4:00 PM Adrian Bunk  wrote:
>
> On Wed, Aug 28, 2019 at 03:28:36PM -0400, bruce.ashfi...@gmail.com wrote:
> >...
> > --- /dev/null
> > +++ b/meta/recipes-kernel/linux/files/0001-foo.patch
> > @@ -0,0 +1,25 @@
> > +From 9ddc5e377434e28f1f3c74c9be011b0c9dfb1de4 Mon Sep 17 00:00:00 2001
> > +From: Bruce Ashfield 
> > +Date: Fri, 1 Mar 2019 10:09:43 -0500
> > +Subject: [PATCH] foo
> >...
>
> Debug change that leaked into the submission,
> or missing proper patch description?

Damnit. I scanned right over that :D

Thanks for the catch..

Bruce

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


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

Re: [OE-core] [PATCH 4/8] kernel-devsrc: remove python2 dependency

[Adrian Bunk]

On Wed, Aug 28, 2019 at 03:28:38PM -0400, bruce.ashfi...@gmail.com wrote:
> From: Bruce Ashfield 
> 
> Witht the approaching EOL of python2, the kernel packages need to
> be updated to depend on python3.
>...

Yocto 3.0 ships and supports Python 2.7, so there is no urgent need for 
last-minute Python 2 -> 3 changes.

cu
Adrian

-- 

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

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

Re: [OE-core] [PATCH 2/8] linux-yocto: introduce 5.2 recipes

[Adrian Bunk]

On Wed, Aug 28, 2019 at 03:28:36PM -0400, bruce.ashfi...@gmail.com wrote:
>...
> --- /dev/null
> +++ b/meta/recipes-kernel/linux/files/0001-foo.patch
> @@ -0,0 +1,25 @@
> +From 9ddc5e377434e28f1f3c74c9be011b0c9dfb1de4 Mon Sep 17 00:00:00 2001
> +From: Bruce Ashfield 
> +Date: Fri, 1 Mar 2019 10:09:43 -0500
> +Subject: [PATCH] foo
>...

Debug change that leaked into the submission,
or missing proper patch description?

cu
Adrian

-- 

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

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

[OE-core] ✗ patchtest: failure for kernel/kernel-yocto: consolidated M3 feature pull request

[Patchwork]

== Series Details ==

Series: kernel/kernel-yocto: consolidated M3 feature pull request
Revision: 1
URL   : https://patchwork.openembedded.org/series/19543/
State : failure

== Summary ==


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



* Issue Added patch file is missing Upstream-Status in the header 
[test_upstream_status_presence_format] 
  Suggested fixAdd Upstream-Status:  to the header of 
meta/recipes-kernel/linux/files/0001-foo.patch
  Standard format  Upstream-Status: 
  Valid status Pending, Accepted, Backport, Denied, Inappropriate [reason], 
Submitted [where]



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

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

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

[OE-core] [PATCH 7/8] devsrc: update arm64 scripts/prepare for kernels 5.3+

[bruce . ashfield]

From: Bruce Ashfield 

We need to include a few more small files for on target module
builds for 5.3+ kernels.

Signed-off-by: Bruce Ashfield 
---
 meta/recipes-kernel/linux/kernel-devsrc.bb | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb 
b/meta/recipes-kernel/linux/kernel-devsrc.bb
index e17c0ea0ab..b68d945a8f 100644
--- a/meta/recipes-kernel/linux/kernel-devsrc.bb
+++ b/meta/recipes-kernel/linux/kernel-devsrc.bb
@@ -141,7 +141,7 @@ do_install() {
# arch/arm64/include/asm/opcodes.h references arch/arm
cp -a --parents arch/arm/include/asm/opcodes.h $kerneldir/build/
 
-cp -a --parents arch/arm64/kernel/vdso/gettimeofday.S 
$kerneldir/build/
+cp -a --parents arch/arm64/kernel/vdso/*gettimeofday.* 
$kerneldir/build/
 cp -a --parents arch/arm64/kernel/vdso/sigreturn.S 
$kerneldir/build/
 cp -a --parents arch/arm64/kernel/vdso/note.S $kerneldir/build/
 cp -a --parents arch/arm64/kernel/vdso/gen_vdso_offsets.sh 
$kerneldir/build/
@@ -179,6 +179,8 @@ do_install() {
 
cp -a include $kerneldir/build
 
+   cp -a --parents lib/vdso/* $kerneldir/build/ 2>/dev/null || :
+
cp -a --parents tools/include/tools/le_byteshift.h $kerneldir/build/
cp -a --parents tools/include/tools/be_byteshift.h $kerneldir/build/
 
-- 
2.19.1

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

[OE-core] [PATCH 8/8] qemu: bump linux-yocto preferred version to 5.2

[bruce . ashfield]

From: Bruce Ashfield 

Signed-off-by: Bruce Ashfield 
---
 meta/conf/machine/include/x86-base.inc | 2 +-
 meta/conf/machine/qemuarmv5.conf   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/conf/machine/include/x86-base.inc 
b/meta/conf/machine/include/x86-base.inc
index 686f938233..0227f3c289 100644
--- a/meta/conf/machine/include/x86-base.inc
+++ b/meta/conf/machine/include/x86-base.inc
@@ -18,7 +18,7 @@ SERIAL_CONSOLES ?= "115200;ttyS0"
 # kernel-related variables
 #
 PREFERRED_PROVIDER_virtual/kernel ??= "linux-yocto"
-PREFERRED_VERSION_linux-yocto ??= "5.0%"
+PREFERRED_VERSION_linux-yocto ??= "5.2%"
 
 #
 # XSERVER subcomponents, used to build the XSERVER variable
diff --git a/meta/conf/machine/qemuarmv5.conf b/meta/conf/machine/qemuarmv5.conf
index 1c21d3342d..fb4789fdac 100644
--- a/meta/conf/machine/qemuarmv5.conf
+++ b/meta/conf/machine/qemuarmv5.conf
@@ -17,7 +17,7 @@ QB_KERNEL_CMDLINE_APPEND = "console=ttyAMA0,115200 
console=tty"
 QB_OPT_APPEND = "-show-cursor -usb -device usb-tablet"
 # Add the 'virtio-rng-pci' device otherwise the guest may run out of entropy
 QB_OPT_APPEND += "-object rng-random,filename=/dev/urandom,id=rng0 -device 
virtio-rng-pci,rng=rng0"
-PREFERRED_VERSION_linux-yocto ??= "5.0%"
+PREFERRED_VERSION_linux-yocto ??= "5.2%"
 QB_DTB = "${@oe.utils.version_less_or_equal('PREFERRED_VERSION_linux-yocto', 
'4.7', '', 'zImage-versatile-pb.dtb', d)}"
 
 KMACHINE_qemuarmv5 = "qemuarm"
-- 
2.19.1

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

[OE-core] [PATCH 6/8] perf: v5.3+ build fixes

[bruce . ashfield]

From: Bruce Ashfield 

In the 5.3+ perf builds, there are multiple unistd.h files that need
to be kept in sync. So not only do we update one, we update both to
ensure that libc-headers and the perf build are in sync.

perf checks some key files itself to be sure they are in sync, and
bits.h can be out of sync. There's no build error that results with
bits.h at the moment, but we still make sure they are in sync to
avoid the configure/compile warning.

Signed-off-by: Bruce Ashfield 
---
 meta/recipes-kernel/perf/perf.bb | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
index 8ac8e7c308..58543c73d8 100644
--- a/meta/recipes-kernel/perf/perf.bb
+++ b/meta/recipes-kernel/perf/perf.bb
@@ -241,6 +241,10 @@ do_configure_prepend () {
 # unistd.h can be out of sync between libc-headers and the captured 
version in the perf source
 # so we copy it from the sysroot unistd.h to the perf unistd.h
 install -D -m0644 ${STAGING_INCDIR}/asm-generic/unistd.h 
${S}/tools/include/uapi/asm-generic/unistd.h
+install -D -m0644 ${STAGING_INCDIR}/asm-generic/unistd.h 
${S}/include/uapi/asm-generic/unistd.h
+
+# bits.h can have the same issuen as unistd.h, so we make the tools 
variant take precedence
+install -D -m0644 ${S}/tools/include/linux/bits.h ${S}/include/linux/bits.h
 }
 
 python do_package_prepend() {
-- 
2.19.1

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

[OE-core] [PATCH 5/8] perf: change dependencies on python to python3

[bruce . ashfield]

From: Bruce Ashfield 

The upstream kernel can now handle python3 for the perf scripts, coupled
with the impending EOL of python2, we switch the dependencies in perf
(scripting) to python3.

Outside of dependency changes, we also pass the following two variables
to the perf build: PYTHON=python3 PYTHON_CONFIG=python3-config. To
ensure that our python3 components are used.

For configurations that disable perf scripting, there is no change in
behaviour.

[YOCTO #13358]

Signed-off-by: Bruce Ashfield 
---
 meta/recipes-kernel/perf/perf.bb | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
index 4e603f1a32..8ac8e7c308 100644
--- a/meta/recipes-kernel/perf/perf.bb
+++ b/meta/recipes-kernel/perf/perf.bb
@@ -13,7 +13,7 @@ PR = "r9"
 
 PACKAGECONFIG ??= "scripting tui libunwind"
 PACKAGECONFIG[dwarf] = ",NO_DWARF=1"
-PACKAGECONFIG[scripting] = ",NO_LIBPERL=1 NO_LIBPYTHON=1,perl python"
+PACKAGECONFIG[scripting] = ",NO_LIBPERL=1 NO_LIBPYTHON=1,perl python3"
 # gui support was added with kernel 3.6.35
 # since 3.10 libnewt was replaced by slang
 # to cover a wide range of kernel we add both dependencies
@@ -44,8 +44,8 @@ PROVIDES = "virtual/perf"
 inherit linux-kernel-base kernel-arch manpages
 
 # needed for building the tools/perf Python bindings
-inherit ${@bb.utils.contains('PACKAGECONFIG', 'scripting', 'pythonnative', '', 
d)}
-inherit python-dir
+inherit ${@bb.utils.contains('PACKAGECONFIG', 'scripting', 'python3native', 
'', d)}
+inherit python3-dir
 export PYTHON_SITEPACKAGES_DIR
 
 #kernel 3.1+ supports WERROR to disable warnings as errors
@@ -94,6 +94,7 @@ EXTRA_OEMAKE += "\
 'sharedir=${@os.path.relpath(datadir, prefix)}' \
 'mandir=${@os.path.relpath(mandir, prefix)}' \
 'infodir=${@os.path.relpath(infodir, prefix)}' \
+${@bb.utils.contains('PACKAGECONFIG', 'scripting', 'PYTHON=python3 
PYTHON_CONFIG=python3-config', '', d)} \
 "
 
 # During do_configure, we might run a 'make clean'. That often breaks
@@ -132,7 +133,7 @@ do_install() {
oe_runmake install
# we are checking for this make target to be compatible with older perf 
versions
if ${@bb.utils.contains('PACKAGECONFIG', 'scripting', 'true', 'false', 
d)} && grep -q install-python_ext ${S}/tools/perf/Makefile*; then
-   oe_runmake DESTDIR=${D} install-python_ext
+   oe_runmake DESTDIR=${D} install-python_ext
fi
 }
 
@@ -233,7 +234,8 @@ do_configure_prepend () {
 
 # use /usr/bin/env instead of version specific python
 for s in `find ${S}/tools/perf/scripts/python/ -name '*.py'`; do
-sed -i 's,/usr/bin/python2,/usr/bin/env python,' "${s}"
+sed -i 's,/usr/bin/python2,/usr/bin/env python3,' "${s}"
+sed -i 's,/usr/bin/env python2,/usr/bin/env python3,' "${s}"
 done
 
 # unistd.h can be out of sync between libc-headers and the captured 
version in the perf source
@@ -252,9 +254,9 @@ PACKAGES =+ "${PN}-archive ${PN}-tests ${PN}-perl 
${PN}-python"
 
 RDEPENDS_${PN} += "elfutils bash"
 RDEPENDS_${PN}-archive =+ "bash"
-RDEPENDS_${PN}-python =+ "bash python python-modules 
${@bb.utils.contains('PACKAGECONFIG', 'audit', 'audit-python', '', d)}"
+RDEPENDS_${PN}-python =+ "bash python3 python3-modules 
${@bb.utils.contains('PACKAGECONFIG', 'audit', 'audit-python3', '', d)}"
 RDEPENDS_${PN}-perl =+ "bash perl perl-modules"
-RDEPENDS_${PN}-tests =+ "python"
+RDEPENDS_${PN}-tests =+ "python3"
 
 RSUGGESTS_SCRIPTING = "${@bb.utils.contains('PACKAGECONFIG', 'scripting', 
'${PN}-perl ${PN}-python', '',d)}"
 RSUGGESTS_${PN} += "${PN}-archive ${PN}-tests ${RSUGGESTS_SCRIPTING}"
-- 
2.19.1

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

[OE-core] [PATCH 3/8] bluez5: fix build against libc-headers 5.2+

[bruce . ashfield]

From: Bruce Ashfield 

Backporting the following upstream commit to fix the build against
kernel 5.2+ headers:

[
   Subject: [PATCH] tools: Fix build after y2038 changes in glibc

   The 32-bit SIOCGSTAMP has been deprecated. Use the deprecated name
   to fix the build.
]

Upstream-Status: backport commit f36f71f60b1e68c0f12e615b9b128d089ec3dd19

Signed-off-by: Bruce Ashfield 
---
 meta/recipes-connectivity/bluez5/bluez5.inc   |  1 +
 ...x-build-after-y2038-changes-in-glibc.patch | 68 +++
 2 files changed, 69 insertions(+)
 create mode 100644 
meta/recipes-connectivity/bluez5/bluez5/0001-tools-Fix-build-after-y2038-changes-in-glibc.patch

diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc 
b/meta/recipes-connectivity/bluez5/bluez5.inc
index bffd174c0a..6c79ed0606 100644
--- a/meta/recipes-connectivity/bluez5/bluez5.inc
+++ b/meta/recipes-connectivity/bluez5/bluez5.inc
@@ -57,6 +57,7 @@ SRC_URI = "\
 file://0001-Makefile.am-Fix-a-race-issue-for-tools.patch \
 file://CVE-2018-10910.patch \
 file://gcc9-fixes.patch \
+file://0001-tools-Fix-build-after-y2038-changes-in-glibc.patch \
 "
 S = "${WORKDIR}/bluez-${PV}"
 
diff --git 
a/meta/recipes-connectivity/bluez5/bluez5/0001-tools-Fix-build-after-y2038-changes-in-glibc.patch
 
b/meta/recipes-connectivity/bluez5/bluez5/0001-tools-Fix-build-after-y2038-changes-in-glibc.patch
new file mode 100644
index 00..9ca20ae53b
--- /dev/null
+++ 
b/meta/recipes-connectivity/bluez5/bluez5/0001-tools-Fix-build-after-y2038-changes-in-glibc.patch
@@ -0,0 +1,68 @@
+From f36f71f60b1e68c0f12e615b9b128d089ec3dd19 Mon Sep 17 00:00:00 2001
+From: Bastien Nocera 
+Date: Fri, 7 Jun 2019 09:51:33 +0200
+Subject: [PATCH] tools: Fix build after y2038 changes in glibc
+
+The 32-bit SIOCGSTAMP has been deprecated. Use the deprecated name
+to fix the build.
+
+Upstream-Status: backport commit f36f71f60b1e68c0f12e615b9b128d089ec3dd19
+
+Signed-off-by: Bruce Ashfield 
+
+---
+ tools/l2test.c | 6 +-
+ tools/rctest.c | 6 +-
+ 2 files changed, 10 insertions(+), 2 deletions(-)
+
+diff --git a/tools/l2test.c b/tools/l2test.c
+index e755ac881..e787c2ce2 100644
+--- a/tools/l2test.c
 b/tools/l2test.c
+@@ -55,6 +55,10 @@
+ #define BREDR_DEFAULT_PSM 0x1011
+ #define LE_DEFAULT_PSM0x0080
+ 
++#ifndef SIOCGSTAMP_OLD
++#define SIOCGSTAMP_OLD SIOCGSTAMP
++#endif
++
+ /* Test modes */
+ enum {
+   SEND,
+@@ -907,7 +911,7 @@ static void recv_mode(int sk)
+   if (timestamp) {
+   struct timeval tv;
+ 
+-  if (ioctl(sk, SIOCGSTAMP, ) < 0) {
++  if (ioctl(sk, SIOCGSTAMP_OLD, ) < 0) {
+   timestamp = 0;
+   memset(ts, 0, sizeof(ts));
+   } else {
+diff --git a/tools/rctest.c b/tools/rctest.c
+index 94490f462..bc8ed875d 100644
+--- a/tools/rctest.c
 b/tools/rctest.c
+@@ -50,6 +50,10 @@
+ 
+ #include "src/shared/util.h"
+ 
++#ifndef SIOCGSTAMP_OLD
++#define SIOCGSTAMP_OLD SIOCGSTAMP
++#endif
++
+ /* Test modes */
+ enum {
+   SEND,
+@@ -505,7 +509,7 @@ static void recv_mode(int sk)
+   if (timestamp) {
+   struct timeval tv;
+ 
+-  if (ioctl(sk, SIOCGSTAMP, ) < 0) {
++  if (ioctl(sk, SIOCGSTAMP_OLD, ) < 0) {
+   timestamp = 0;
+   memset(ts, 0, sizeof(ts));
+   } else {
+-- 
+2.19.1
+
-- 
2.19.1

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

[OE-core] [PATCH 2/8] linux-yocto: introduce 5.2 recipes

[bruce . ashfield]

From: Bruce Ashfield 

Introducing the 5.2 linux-yocto reference kernels. 5.0 is EOL and will
be removed, leaving 4.19 (LTS) and 5.2 as the reference kernels.

This has been build/boot tested on all qemu architectures for
core-image-kernel-dev, and graphics tesed via core-image-sato. No
blockin issues have been found.

Signed-off-by: Bruce Ashfield 
---
 .../recipes-kernel/linux/files/0001-foo.patch | 25 +
 .../linux/linux-yocto-rt_5.2.bb   | 44 +++
 .../linux/linux-yocto-tiny_5.2.bb | 32 +++
 meta/recipes-kernel/linux/linux-yocto_5.2.bb  | 54 +++
 4 files changed, 155 insertions(+)
 create mode 100644 meta/recipes-kernel/linux/files/0001-foo.patch
 create mode 100644 meta/recipes-kernel/linux/linux-yocto-rt_5.2.bb
 create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny_5.2.bb
 create mode 100644 meta/recipes-kernel/linux/linux-yocto_5.2.bb

diff --git a/meta/recipes-kernel/linux/files/0001-foo.patch 
b/meta/recipes-kernel/linux/files/0001-foo.patch
new file mode 100644
index 00..0cd4578f33
--- /dev/null
+++ b/meta/recipes-kernel/linux/files/0001-foo.patch
@@ -0,0 +1,25 @@
+From 9ddc5e377434e28f1f3c74c9be011b0c9dfb1de4 Mon Sep 17 00:00:00 2001
+From: Bruce Ashfield 
+Date: Fri, 1 Mar 2019 10:09:43 -0500
+Subject: [PATCH] foo
+
+Signed-off-by: Bruce Ashfield 
+---
+ bsp/common-pc-64/common-pc-64-cpu.cfg | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/bsp/common-pc-64/common-pc-64-cpu.cfg 
b/bsp/common-pc-64/common-pc-64-cpu.cfg
+index 8dced733815..63bc167cf6f 100644
+--- a/bsp/common-pc-64/common-pc-64-cpu.cfg
 b/bsp/common-pc-64/common-pc-64-cpu.cfg
+@@ -12,6 +12,6 @@
+ #.
+ 
+ CONFIG_MCORE2=y
+-CONFIG_IA32_EMULATION=y
++#CONFIG_IA32_EMULATION is not set
+ CONFIG_NR_CPUS=24
+ CONFIG_PM=y
+-- 
+2.19.1
+
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.2.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_5.2.bb
new file mode 100644
index 00..b4376b431d
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.2.bb
@@ -0,0 +1,44 @@
+KBRANCH ?= "v5.2/standard/preempt-rt/base"
+
+require recipes-kernel/linux/linux-yocto.inc
+
+# Skip processing of this recipe if it is not explicitly specified as the
+# PREFERRED_PROVIDER for virtual/kernel. This avoids errors when trying
+# to build multiple virtual/kernel providers, e.g. as dependency of
+# core-image-rt-sdk, core-image-rt.
+python () {
+if d.getVar("KERNEL_PACKAGE_NAME") == "kernel" and 
d.getVar("PREFERRED_PROVIDER_virtual/kernel") != "linux-yocto-rt":
+raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to 
linux-yocto-rt to enable it")
+}
+
+SRCREV_machine ?= "ea07aa34bed4e662fe374d04d50b6ddb9882bb19"
+SRCREV_meta ?= "b53e99257175fd6f41f31e5ebec46c1bd11076b8"
+
+SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \
+   
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.2;destsuffix=${KMETA}"
+
+LINUX_VERSION ?= "5.2.10"
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=bbea815ee2795b2f4230826c0c6b8814"
+
+DEPENDS += "${@bb.utils.contains('ARCH', 'x86', 'elfutils-native', '', d)}"
+DEPENDS += "openssl-native util-linux-native"
+
+PV = "${LINUX_VERSION}+git${SRCPV}"
+
+KMETA = "kernel-meta"
+KCONF_BSP_AUDIT_LEVEL = "2"
+
+LINUX_KERNEL_TYPE = "preempt-rt"
+
+COMPATIBLE_MACHINE = 
"(qemux86|qemux86-64|qemuarm|qemuarmv5|qemuarm64|qemuppc|qemumips)"
+
+KERNEL_DEVICETREE_qemuarmv5 = "versatile-pb.dtb"
+
+# Functionality flags
+KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc 
features/taskstats/taskstats.scc"
+KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}"
+KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc"
+KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc"
+KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc"
+KERNEL_FEATURES_append = "${@bb.utils.contains("DISTRO_FEATURES", "ptest", " 
features/scsi/scsi-debug.scc", "" ,d)}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.2.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_5.2.bb
new file mode 100644
index 00..f55e607b97
--- /dev/null
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.2.bb
@@ -0,0 +1,32 @@
+KBRANCH ?= "v5.2/standard/tiny/base"
+KBRANCH_qemuarm  ?= "v5.2/standard/tiny/arm-versatile-926ejs"
+
+LINUX_KERNEL_TYPE = "tiny"
+KCONFIG_MODE = "--allnoconfig"
+
+require recipes-kernel/linux/linux-yocto.inc
+
+LINUX_VERSION ?= "5.2.10"
+LIC_FILES_CHKSUM = "file://COPYING;md5=bbea815ee2795b2f4230826c0c6b8814"
+
+DEPENDS += "${@bb.utils.contains('ARCH', 'x86', 'elfutils-native', '', d)}"
+DEPENDS += "openssl-native util-linux-native"
+
+KMETA = "kernel-meta"
+KCONF_BSP_AUDIT_LEVEL = "2"
+
+SRCREV_machine_qemuarm ?= "ab7b49b196280d4289f18c35cf6ea534f364d104"
+SRCREV_machine ?= "77c28ea0e55cabb0b22b47d4eb2cc94b0940dfe6"
+SRCREV_meta ?= 

[OE-core] [PATCH 4/8] kernel-devsrc: remove python2 dependency

[bruce . ashfield]

From: Bruce Ashfield 

Witht the approaching EOL of python2, the kernel packages need to
be updated to depend on python3.

The core kernel scripts are now python3 safe, making the RDEPENDS
change relatively simple.

but

There are some scripts that are captured in the devsrc files that
are not used, but reference /usr/bin/python. The python3 package
does not provide /usr/bin/python so any package managers with
automatic dependency detection will fail to assemble a rootfs due
to the missing intepreter.

We could drop the scripts from the source capture, but that
risks dropping something that we need in certain operations and
we'd miss when they are updated in tree to explicitly call python3
(since they won't be revisited often). Light testing shows that the
scripts do run with python3, so rather than removing them, we change
the interpreter once they are copied, and automatic dependency
detection won't cause us rootfs assembly issues.

Signed-off-by: Bruce Ashfield 
---
 meta/recipes-kernel/linux/kernel-devsrc.bb | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb 
b/meta/recipes-kernel/linux/kernel-devsrc.bb
index 3900489ac5..e17c0ea0ab 100644
--- a/meta/recipes-kernel/linux/kernel-devsrc.bb
+++ b/meta/recipes-kernel/linux/kernel-devsrc.bb
@@ -240,6 +240,15 @@ do_install() {
 # Copy .config to include/config/auto.conf so "make prepare" is 
unnecessary.
 cp $kerneldir/build/.config $kerneldir/build/include/config/auto.conf
 
+# make the scripts python3 safe. We won't be running these, and if they are
+# left as /usr/bin/python rootfs assembly will fail, since we only have 
python3
+# in the RDEPENDS (and the python3 package does not include 
/usr/bin/python)
+for ss in $(find $kerneldir/build/scripts -type f -name '*'); do
+   sed -i 's,/usr/bin/python2,/usr/bin/env python3,' "$ss"
+   sed -i 's,/usr/bin/env python2,/usr/bin/env python3,' "$ss"
+   sed -i 's,/usr/bin/python,/usr/bin/env python3,' "$ss"
+done
+
 chown -R root:root ${D}
 }
 
@@ -249,7 +258,7 @@ do_install[lockfiles] = "${TMPDIR}/kernel-scripts.lock"
 FILES_${PN} = "${KERNEL_BUILD_ROOT} ${KERNEL_SRC_PATH}"
 FILES_${PN}-dbg += "${KERNEL_BUILD_ROOT}*/build/scripts/*/.debug/*"
 
-RDEPENDS_${PN} = "bc python flex bison ${TCLIBC}-utils"
+RDEPENDS_${PN} = "bc python3 flex bison ${TCLIBC}-utils"
 # 4.15+ needs these next two RDEPENDS
 RDEPENDS_${PN} += "openssl-dev util-linux"
 # and x86 needs a bit more for 4.15+
-- 
2.19.1

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

[OE-core] [PATCH 1/8] linux-libc-headers: update to v5.2 headers

[bruce . ashfield]

From: Bruce Ashfield 

We drop the patch 
0001-arm64-sve-uapi-asm-ptrace.h-should-not-depend-on-uap.patch
since it was a backport and is already part of the 5.2 headers

Signed-off-by: Bruce Ashfield 
---
 meta/conf/distro/include/tcmode-default.inc   |  2 +-
 ...sm-ptrace.h-should-not-depend-on-uap.patch | 62 ---
 ...aders_5.0.bb => linux-libc-headers_5.2.bb} |  5 +-
 3 files changed, 3 insertions(+), 66 deletions(-)
 delete mode 100644 
meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-arm64-sve-uapi-asm-ptrace.h-should-not-depend-on-uap.patch
 rename meta/recipes-kernel/linux-libc-headers/{linux-libc-headers_5.0.bb => 
linux-libc-headers_5.2.bb} (75%)

diff --git a/meta/conf/distro/include/tcmode-default.inc 
b/meta/conf/distro/include/tcmode-default.inc
index c89b8e012d..5c28386c4f 100644
--- a/meta/conf/distro/include/tcmode-default.inc
+++ b/meta/conf/distro/include/tcmode-default.inc
@@ -23,7 +23,7 @@ SDKGCCVERSION ?= "${GCCVERSION}"
 BINUVERSION ?= "2.32%"
 GDBVERSION ?= "8.3%"
 GLIBCVERSION ?= "2.30%"
-LINUXLIBCVERSION ?= "5.0%"
+LINUXLIBCVERSION ?= "5.2%"
 QEMUVERSION ?= "4.1%"
 GOVERSION ?= "1.12%"
 # This can not use wildcards like 8.0.% since it is also used in mesa to denote
diff --git 
a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-arm64-sve-uapi-asm-ptrace.h-should-not-depend-on-uap.patch
 
b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-arm64-sve-uapi-asm-ptrace.h-should-not-depend-on-uap.patch
deleted file mode 100644
index 5ea46e9590..00
--- 
a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-arm64-sve-uapi-asm-ptrace.h-should-not-depend-on-uap.patch
+++ /dev/null
@@ -1,62 +0,0 @@
-From 35341ca0614ab13e1ef34ad4f29a39e15ef31fa8 Mon Sep 17 00:00:00 2001
-From: Anisse Astier 
-Date: Mon, 17 Jun 2019 15:22:22 +0200
-Subject: [PATCH] arm64/sve:  should not depend on
- 
-
-Pulling linux/prctl.h into asm/ptrace.h in the arm64 UAPI headers causes
-userspace build issues for any program (e.g. strace and qemu) that
-includes both  and  when using musl libc:
-
-  | error: redefinition of 'struct prctl_mm_map'
-  |  struct prctl_mm_map {
-
-See 
https://github.com/foundriesio/meta-lmp/commit/6d4a106e191b5d79c41b9ac78fd321316d3013c0
-for a public example of people working around this issue.
-
-Although it's a bit grotty, fix this breakage by duplicating the prctl
-constant definitions. Since these are part of the kernel ABI, they
-cannot be changed in future and so it's not the end of the world to have
-them open-coded.
-
-Fixes: 43d4da2c45b2 ("arm64/sve: ptrace and ELF coredump support")
-
-Upstream-Status: Backport 
[https://github.com/torvalds/linux/commit/35341ca0614ab13e1ef34ad4f29a39e15ef31fa8]
-Cc: sta...@vger.kernel.org
-Acked-by: Dave Martin 
-Signed-off-by: Anisse Astier 
-Signed-off-by: Will Deacon 

- arch/arm64/include/uapi/asm/ptrace.h | 8 +++-
- 1 file changed, 3 insertions(+), 5 deletions(-)
-
-diff --git a/arch/arm64/include/uapi/asm/ptrace.h 
b/arch/arm64/include/uapi/asm/ptrace.h
-index 97c53203150b..e932284993d4 100644
 a/arch/arm64/include/uapi/asm/ptrace.h
-+++ b/arch/arm64/include/uapi/asm/ptrace.h
-@@ -65,8 +65,6 @@
- 
- #ifndef __ASSEMBLY__
- 
--#include 
--
- /*
-  * User structures for general purpose, floating point and debug registers.
-  */
-@@ -113,10 +111,10 @@ struct user_sve_header {
- 
- /*
-  * Common SVE_PT_* flags:
-- * These must be kept in sync with prctl interface in 
-+ * These must be kept in sync with prctl interface in 
-  */
--#define SVE_PT_VL_INHERIT (PR_SVE_VL_INHERIT >> 16)
--#define SVE_PT_VL_ONEXEC  (PR_SVE_SET_VL_ONEXEC >> 16)
-+#define SVE_PT_VL_INHERIT ((1 << 17) /* PR_SVE_VL_INHERIT */ >> 
16)
-+#define SVE_PT_VL_ONEXEC  ((1 << 18) /* PR_SVE_SET_VL_ONEXEC */ 
>> 16)
- 
- 
- /*
--- 
-2.22.0
-
diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.0.bb 
b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.2.bb
similarity index 75%
rename from meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.0.bb
rename to meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.2.bb
index 473688d95f..9d18df76c6 100644
--- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.0.bb
+++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.2.bb
@@ -12,8 +12,7 @@ SRC_URI_append_libc-musl = "\
 SRC_URI_append = "\
 file://0001-scripts-Use-fixed-input-and-output-files-instead-of-.patch \
 file://0001-kbuild-install_headers.sh-Strip-_UAPI-from-if-define.patch \
-file://0001-arm64-sve-uapi-asm-ptrace.h-should-not-depend-on-uap.patch \
 "
 
-SRC_URI[md5sum] = "7381ce8aac80a01448e065ce795c19c0"
-SRC_URI[sha256sum] = 
"437b141a6499159f5a7282d5eb4b2be055f8e862ccce44d7464e8759c31a2e43"
+SRC_URI[md5sum] = "ddf994de00d7b18395886dd9b30b9262"
+SRC_URI[sha256sum] = 
"54ad66f672e1a831b574f5e704e8a05f1e6180a8245d4bdd811208a6cb0ac1e7"
-- 
2.19.1

-- 

[OE-core] [PATCH 0/8] kernel/kernel-yocto: consolidated M3 feature pull request

[bruce . ashfield]

From: Bruce Ashfield 

Hi all,

Sorry for this being slightly after the M3 feature cutoff, I ended up having
to churn through a lot of extra builds keeping up with master, dealing with
header issues, and working through the python3 changes at the same time.

With this series, we get an update of the libc-headers to 5.2, the introduction
of the 5.2 reference kernel, tweaked 5.2 kernel configuration fragments, some
misc build fixes to deal with the headers and the removal of python2 
dependencies
from kerneldevsrc and perf.

I have some follow up patches to meta-oe that fix a couple of build issues
with the 5.2 headers. As well as some changes to oe-core to drop the 5.0
recipes (once we get the reference BSPs updated) and also changes to poky to
set the default kernel to 5.2. Once we get this set stablized, and the
reference BSPs updated, I'll send those other patches.

I've built and booted all the qemu machines for 5.2 (core-image-sato,
core-image-kernel-dev) and executed unit tests. I've also built and
booted core-image-minimal for musl for all arches against the updated
headers. I'm sure that I still managed to miss some combination, or there's
some other package out there that doesn't like the header updates .. but
I've done the best I can and this needs autobuilder coverage now.

I've also built and tested python3 only images for core-image-kernel-dev and
haven't found any regressions in functionality. As a bonus to the python2
removal, I fixed perf scripting (which was broken) and headed off some perf
v5.3 issues.

Cheers,

Bruce

The following changes since commit c17113f1e2e7bd8ab019169660718fab81df16fb:

  quilt: added less to RDEPENDS list (2019-08-22 22:48:27 +0100)

are available in the Git repository at:

  git://git.pokylinux.org/poky-contrib zedd/kernel
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel

Bruce Ashfield (8):
  linux-libc-headers: update to v5.2 headers
  linux-yocto: introduce 5.2 recipes
  bluez5: fix build against libc-headers 5.2+
  kernel-devsrc: remove python2 dependency
  perf: change dependencies on python to python3
  perf: v5.3+ build fixes
  devsrc: update arm64 scripts/prepare for kernels 5.3+
  qemu: bump linux-yocto preferred version to 5.2

 meta/conf/distro/include/tcmode-default.inc   |  2 +-
 meta/conf/machine/include/x86-base.inc|  2 +-
 meta/conf/machine/qemuarmv5.conf  |  2 +-
 meta/recipes-connectivity/bluez5/bluez5.inc   |  1 +
 ...x-build-after-y2038-changes-in-glibc.patch | 68 +++
 ...sm-ptrace.h-should-not-depend-on-uap.patch | 62 -
 ...aders_5.0.bb => linux-libc-headers_5.2.bb} |  5 +-
 .../recipes-kernel/linux/files/0001-foo.patch | 25 +++
 meta/recipes-kernel/linux/kernel-devsrc.bb| 15 +++-
 .../linux/linux-yocto-rt_5.2.bb   | 44 
 .../linux/linux-yocto-tiny_5.2.bb | 32 +
 meta/recipes-kernel/linux/linux-yocto_5.2.bb  | 54 +++
 meta/recipes-kernel/perf/perf.bb  | 20 --
 13 files changed, 255 insertions(+), 77 deletions(-)
 create mode 100644 
meta/recipes-connectivity/bluez5/bluez5/0001-tools-Fix-build-after-y2038-changes-in-glibc.patch
 delete mode 100644 
meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0001-arm64-sve-uapi-asm-ptrace.h-should-not-depend-on-uap.patch
 rename meta/recipes-kernel/linux-libc-headers/{linux-libc-headers_5.0.bb => 
linux-libc-headers_5.2.bb} (75%)
 create mode 100644 meta/recipes-kernel/linux/files/0001-foo.patch
 create mode 100644 meta/recipes-kernel/linux/linux-yocto-rt_5.2.bb
 create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny_5.2.bb
 create mode 100644 meta/recipes-kernel/linux/linux-yocto_5.2.bb

-- 
2.19.1

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

[OE-core] [PATCH] yocto-check-layer: Allow any case for README file detection

[Mark Hatle]

It's become more commone for files to be named "readme" or "Readme" on github 
servers
in recent time.  So adjust the scanning to allow any mix of case.

Signed-off-by: Mark Hatle 
---
 scripts/lib/checklayer/cases/common.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/lib/checklayer/cases/common.py 
b/scripts/lib/checklayer/cases/common.py
index 8ffe028..b82304e 100644
--- a/scripts/lib/checklayer/cases/common.py
+++ b/scripts/lib/checklayer/cases/common.py
@@ -12,7 +12,7 @@ from checklayer.case import OECheckLayerTestCase
 class CommonCheckLayer(OECheckLayerTestCase):
 def test_readme(self):
 # The top-level README file may have a suffix (like README.rst or 
README.txt).
-readme_files = glob.glob(os.path.join(self.tc.layer['path'], 
'README*'))
+readme_files = glob.glob(os.path.join(self.tc.layer['path'], 
'[Rr][Ee][Aa][Dd][Mm][Ee]*'))
 self.assertTrue(len(readme_files) > 0,
 msg="Layer doesn't contains README file.")
 
-- 
1.8.3.1

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

Re: [OE-core] [PATCH] common-licenses: update BSD-2-CLAUSE license text

[Andre McCurdy]

On Wed, Aug 28, 2019 at 3:05 AM Christophe PRIOUZEAU
 wrote:
>
> Using the generic BSD-2-CLAUSE license as specified on
> https://opensource.org/licenses/BSD-2-Clause

Fixing these kind of issues has been discussed before. I think the
consensus was that a wider ranging cleanup is needed. The thread
starts here:

  
http://lists.openembedded.org/pipermail/openembedded-core/2018-June/270475.html

> Signed-off-by: Christophe Priouzeau 
> ---
>  meta/files/common-licenses/BSD-2-Clause | 11 ---
>  1 file changed, 4 insertions(+), 7 deletions(-)
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] glibc: Fix locale DEPENDS

[Joshua Watt]

On 8/28/19 11:09 AM, Richard Purdie wrote:

On Tue, 2019-08-27 at 07:45 -0500, Joshua Watt wrote:

gettext is required to generate the glibc locales in do_compile. If not
present, glibc will skip the generation which isn't reproducible.

Signed-off-by: Joshua Watt 
---
  meta/recipes-core/glibc/glibc.inc | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/glibc/glibc.inc 
b/meta/recipes-core/glibc/glibc.inc
index 252fd56c13c..f1a6ae2a245 100644
--- a/meta/recipes-core/glibc/glibc.inc
+++ b/meta/recipes-core/glibc/glibc.inc
@@ -6,7 +6,7 @@ DEPENDS = "virtual/${TARGET_PREFIX}gcc libgcc-initial 
linux-libc-headers"
  
  PROVIDES = "virtual/libc"

  PROVIDES += "virtual/libintl virtual/libiconv"
-inherit autotools texinfo distro_features_check systemd
+inherit autotools texinfo distro_features_check systemd gettext


FYI: I forgot to send this one in-reply-to a previous patch. There is 
more history here: 
http://lists.openembedded.org/pipermail/openembedded-core/2019-June/284158.html



I suspect this may not do what you expect.

At least as I read the class and recipes, glibc sets
INHIBIT_DEFAULT_DEPS which means no gettext-native dependency is added,
instead, configure has --disable-nls added.

Ah, yes I see that also.


Is that what we want?


I guess I'm not sure exactly what we want; It was a while ago so I don't 
remember exactly what glibc was doing, but it looks like it was 
sometimes generating locales (e.g. the first time it built) and 
sometimes not (when rebuilding) depending on the presence of gettext.




I'm curious to understand how glibc locales are ever generated
correctly and what we're aiming to add here (a gettext-native
dependency?)


I'm not sure how it ever works correctly :). Perhaps it would be best to 
just drop this patch for now until we take a more serious look at 
reproducible in the presence of partial recipe rebuilds. I'd rather 
focus on getting the existing QA test running ATM.




FWIW gettext-native is a very heavy thing to add in as a dependency
from a build time perspective.
Yes, that was discussed which is what led to using gettext.bbclass that 
might use gettext-minimal-native, but as you pointed out this isn't 
whats happening.


Cheers,

Richard


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

Re: [OE-core] [PATCH] glibc: Fix locale DEPENDS

[Richard Purdie]

On Tue, 2019-08-27 at 07:45 -0500, Joshua Watt wrote:
> gettext is required to generate the glibc locales in do_compile. If not
> present, glibc will skip the generation which isn't reproducible.
> 
> Signed-off-by: Joshua Watt 
> ---
>  meta/recipes-core/glibc/glibc.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-core/glibc/glibc.inc 
> b/meta/recipes-core/glibc/glibc.inc
> index 252fd56c13c..f1a6ae2a245 100644
> --- a/meta/recipes-core/glibc/glibc.inc
> +++ b/meta/recipes-core/glibc/glibc.inc
> @@ -6,7 +6,7 @@ DEPENDS = "virtual/${TARGET_PREFIX}gcc libgcc-initial 
> linux-libc-headers"
>  
>  PROVIDES = "virtual/libc"
>  PROVIDES += "virtual/libintl virtual/libiconv"
> -inherit autotools texinfo distro_features_check systemd
> +inherit autotools texinfo distro_features_check systemd gettext

I suspect this may not do what you expect.

At least as I read the class and recipes, glibc sets
INHIBIT_DEFAULT_DEPS which means no gettext-native dependency is added,
instead, configure has --disable-nls added.

Is that what we want?

I'm curious to understand how glibc locales are ever generated
correctly and what we're aiming to add here (a gettext-native
dependency?)

FWIW gettext-native is a very heavy thing to add in as a dependency
from a build time perspective.

Cheers,

Richard

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

Re: [OE-core] [PATCH V3] nfs-utils: decrease RLIMIT_NOFILE to 4k for systemd

[richard . purdie]

On Wed, 2019-08-28 at 09:29 +0800, Kang Kai wrote:
> On 2019/8/28 上午7:29, richard.pur...@linuxfoundation.org wrote:
> > On Tue, 2019-08-27 at 17:43 +0800, Kang Kai wrote:
> > > Hi Richard,
> > > 
> > > This patch could fix the test_image failure with systemd. Would
> > > like
> > > to
> > > try systemd as default init manager on yocto build again
> > > to check whether any more blocking issues?
> > 
> > There is at least one issue:
> > 
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/67/builds/967
> > 
> > Please monitor this build which should show up any other issues:
> 
> Got it. Thanks.
> 
> 
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/85/builds/645
> > 
> > (master-next was looking green other than this change).
> 
> It fails with libedit-native do fetch errors. I'll check it but it
> seems not systemd related at first sight.

Agreed, that is a different issue. For the systemd vs sysvinit we have:

qemux86-lsb parselogs failure:
https://autobuilder.yoctoproject.org/typhoon/#/builders/67/builds/967

qemuarm-lsb parselogs failure:
https://autobuilder.yoctoproject.org/typhoon/#/builders/38/builds/970

qemumips runtime systemd test failure:
https://autobuilder.yoctoproject.org/typhoon/#/builders/60/builds/962

qemumips64 runtime systemd test failure:
https://autobuilder.yoctoproject.org/typhoon/#/builders/74/builds/967

oe-selftest failures:
https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/658
2019-08-28 00:55:15,114 - oe-selftest - INFO - RESULTS -
runqemu.RunqemuTests.test_boot_machine_slirp_qcow2: ERROR (1025.19s)
2019-08-28 00:55:15,114 - oe-selftest - INFO - RESULTS -
runqemu.RunqemuTests.test_boot_recipe_image_vdi: ERROR (1010.73s)
2019-08-28 00:55:15,114 - oe-selftest - INFO - RESULTS -
runqemu.RunqemuTests.test_boot_recipe_image_vmdk: ERROR (1028.30s)
2019-08-28 00:55:15,114 - oe-selftest - INFO - RESULTS -
wic.Wic.test_iso_image: FAILED (63.97s)

and it looks like those runqemu failures happen on
qemux86-64:
https://autobuilder.yoctoproject.org/typhoon/#/builders/73/builds/969
qemumips:
https://autobuilder.yoctoproject.org/typhoon/#/builders/60/builds/962
qemux86:
https://autobuilder.yoctoproject.org/typhoon/#/builders/59/builds/961
qemuppc:
https://autobuilder.yoctoproject.org/typhoon/#/builders/63/builds/961
qemumips64:
https://autobuilder.yoctoproject.org/typhoon/#/builders/74/builds/967
qemuarm:
https://autobuilder.yoctoproject.org/typhoon/#/builders/53/builds/969

so it looks like 3-4 different issues.

Cheers,

Richard

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

[OE-core] [PATCH 4/4] mesa: disable gallium swrast driver on x86 x32

[Alexander Kanavin]

It was found to crash the X server on startup under qemu.

Signed-off-by: Alexander Kanavin 
---
 meta/conf/machine/qemux86-64.conf   | 5 -
 meta/recipes-graphics/mesa/mesa.inc | 3 +++
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/meta/conf/machine/qemux86-64.conf 
b/meta/conf/machine/qemux86-64.conf
index 7c70dbddf52..648cf2fe8f6 100644
--- a/meta/conf/machine/qemux86-64.conf
+++ b/meta/conf/machine/qemux86-64.conf
@@ -18,8 +18,11 @@ KERNEL_IMAGETYPE = "bzImage"
 
 SERIAL_CONSOLES ?= "115200;ttyS0 115200;ttyS1"
 
+# Install swrast and glx if opengl is in DISTRO_FEATURES and x32 is not in use.
+# This is because gallium swrast driver was found to crash X server on startup 
in qemu x32.
 XSERVER = "xserver-xorg \
-   ${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 
'mesa-driver-swrast xserver-xorg-extension-glx', '', d)} \
+   ${@bb.utils.contains('DISTRO_FEATURES', 'opengl', \
+   bb.utils.contains('TUNE_FEATURES', 'mx32', '', 'mesa-driver-swrast 
xserver-xorg-extension-glx', d), '', d)} \
xf86-video-cirrus \
xf86-video-fbdev \
xf86-video-vmware \
diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index fcd19884f54..8040d78992b 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -98,6 +98,9 @@ PACKAGECONFIG[vc4] = ""
 PACKAGECONFIG[v3d] = ""
 
 GALLIUMDRIVERS = "swrast"
+# gallium swrast was found to crash Xorg on startup in x32 qemu
+GALLIUMDRIVERS_x86-x32 = ""
+
 GALLIUMDRIVERS_append ="${@bb.utils.contains('PACKAGECONFIG', 'etnaviv', 
',etnaviv', '', d)}"
 GALLIUMDRIVERS_append ="${@bb.utils.contains('PACKAGECONFIG', 'kmsro', 
',kmsro', '', d)}"
 GALLIUMDRIVERS_append ="${@bb.utils.contains('PACKAGECONFIG', 'vc4', ',vc4', 
'', d)}"
-- 
2.17.1

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

[OE-core] [PATCH 3/4] qemu: switch to '-vga std' emulated hardware from vmware/cirrus for x86/mips

[Alexander Kanavin]

This is the qemu default since qemu 2.2, is generally supported better,
and is recommended by upstream. It also has already been in use for arm/risc
and ovmf.

Additional information:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13466
https://www.kraxel.org/blog/2014/10/qemu-using-cirrus-considered-harmful/

'-vga virtio' emulated hardware remains in use when virgl is enabled via a 
runqemu override.

Also, adjust the error whitelist, as there is a number of new messages
coming from the drivers that are not actual errors.

Signed-off-by: Alexander Kanavin 
---
 meta/conf/machine/include/qemuboot-mips.inc | 2 +-
 meta/conf/machine/include/qemuboot-x86.inc  | 2 +-
 meta/conf/machine/qemuarm.conf  | 2 +-
 meta/conf/machine/qemuarm64.conf| 2 +-
 meta/conf/machine/qemux86-64.conf   | 1 +
 meta/conf/machine/qemux86.conf  | 1 +
 meta/lib/oeqa/runtime/cases/parselogs.py| 6 +-
 scripts/runqemu | 6 --
 8 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/meta/conf/machine/include/qemuboot-mips.inc 
b/meta/conf/machine/include/qemuboot-mips.inc
index 1c2b532b482..978820a2e0b 100644
--- a/meta/conf/machine/include/qemuboot-mips.inc
+++ b/meta/conf/machine/include/qemuboot-mips.inc
@@ -2,6 +2,6 @@
 IMAGE_CLASSES += "qemuboot"
 QB_MACHINE = "-machine malta"
 QB_KERNEL_CMDLINE_APPEND = "console=ttyS0 console=tty"
-QB_OPT_APPEND = "-vga cirrus -show-cursor -usb -device usb-tablet"
+QB_OPT_APPEND = "-show-cursor -usb -device usb-tablet"
 # Add the 'virtio-rng-pci' device otherwise the guest may run out of entropy
 QB_OPT_APPEND += "-object rng-random,filename=/dev/urandom,id=rng0 -device 
virtio-rng-pci,rng=rng0"
diff --git a/meta/conf/machine/include/qemuboot-x86.inc 
b/meta/conf/machine/include/qemuboot-x86.inc
index 3931b0f0fb3..495418fa04b 100644
--- a/meta/conf/machine/include/qemuboot-x86.inc
+++ b/meta/conf/machine/include/qemuboot-x86.inc
@@ -9,7 +9,7 @@ QB_CPU_KVM_x86-64 = "-cpu core2duo"
 QB_AUDIO_DRV = "alsa"
 QB_AUDIO_OPT = "-soundhw ac97,es1370"
 QB_KERNEL_CMDLINE_APPEND = "vga=0 uvesafb.mode_option=${UVESA_MODE} 
oprofile.timer=1 uvesafb.task_timeout=-1"
-QB_OPT_APPEND = "-vga vmware -show-cursor -usb -device usb-tablet"
+QB_OPT_APPEND = "-show-cursor -usb -device usb-tablet"
 # Add the 'virtio-rng-pci' device otherwise the guest may run out of entropy
 QB_OPT_APPEND += "-object rng-random,filename=/dev/urandom,id=rng0 -device 
virtio-rng-pci,rng=rng0"
 
diff --git a/meta/conf/machine/qemuarm.conf b/meta/conf/machine/qemuarm.conf
index 26f40b14194..49daa7c6ef6 100644
--- a/meta/conf/machine/qemuarm.conf
+++ b/meta/conf/machine/qemuarm.conf
@@ -16,7 +16,7 @@ QB_CPU = "-cpu cortex-a15"
 # Standard Serial console
 QB_KERNEL_CMDLINE_APPEND = "console=ttyAMA0"
 # For graphics to work we need to define the VGA device as well as the 
necessary USB devices
-QB_OPT_APPEND = "-show-cursor -device VGA,edid=on"
+QB_OPT_APPEND = "-show-cursor"
 QB_OPT_APPEND += "-device qemu-xhci -device usb-tablet -device usb-kbd"
 # Add the virtio RNG
 QB_OPT_APPEND += "-object rng-random,filename=/dev/urandom,id=rng0 -device 
virtio-rng-pci,rng=rng0"
diff --git a/meta/conf/machine/qemuarm64.conf b/meta/conf/machine/qemuarm64.conf
index ec2a887bddf..05f0ee5e66f 100644
--- a/meta/conf/machine/qemuarm64.conf
+++ b/meta/conf/machine/qemuarm64.conf
@@ -17,7 +17,7 @@ QB_CPU_KVM = "-cpu host"
 # Standard Serial console
 QB_KERNEL_CMDLINE_APPEND = "console=ttyAMA0"
 # For graphics to work we need to define the VGA device as well as the 
necessary USB devices
-QB_OPT_APPEND = "-show-cursor -device VGA,edid=on"
+QB_OPT_APPEND = "-show-cursor"
 QB_OPT_APPEND += "-device qemu-xhci -device usb-tablet -device usb-kbd"
 # Add the 'virtio-rng-pci' device otherwise the guest may run out of entropy
 QB_OPT_APPEND += "-object rng-random,filename=/dev/urandom,id=rng0 -device 
virtio-rng-pci,rng=rng0"
diff --git a/meta/conf/machine/qemux86-64.conf 
b/meta/conf/machine/qemux86-64.conf
index 4b50e664e42..7c70dbddf52 100644
--- a/meta/conf/machine/qemux86-64.conf
+++ b/meta/conf/machine/qemux86-64.conf
@@ -24,6 +24,7 @@ XSERVER = "xserver-xorg \
xf86-video-fbdev \
xf86-video-vmware \
xf86-video-modesetting \
+   xf86-video-vesa \
xserver-xorg-module-libint10 \
"
 
diff --git a/meta/conf/machine/qemux86.conf b/meta/conf/machine/qemux86.conf
index 3832302f07b..8e0da820761 100644
--- a/meta/conf/machine/qemux86.conf
+++ b/meta/conf/machine/qemux86.conf
@@ -24,6 +24,7 @@ XSERVER = "xserver-xorg \
xf86-video-fbdev \
xf86-video-vmware \
xf86-video-modesetting \
+   xf86-video-vesa \
xserver-xorg-module-libint10 \
"
 
diff --git a/meta/lib/oeqa/runtime/cases/parselogs.py 
b/meta/lib/oeqa/runtime/cases/parselogs.py
index 19c9c52a0a9..0002730d46f 100644
--- a/meta/lib/oeqa/runtime/cases/parselogs.py
+++ 

[OE-core] [PATCH 1/4] rpm: resolve a host contamination issue for mono packaging

[Alexander Kanavin]

This is perhaps not the most elegant patch but it be dropped
once rpm is updated to the soon-to-be-released version 4.15
where upstream has removed mono dependency resolution altogether.

Signed-off-by: Alexander Kanavin 
---
 ...es-requires-do-not-use-monodis-from-.patch | 58 +++
 meta/recipes-devtools/rpm/rpm_4.14.2.1.bb |  1 +
 2 files changed, 59 insertions(+)
 create mode 100644 
meta/recipes-devtools/rpm/files/0001-mono-find-provides-requires-do-not-use-monodis-from-.patch

diff --git 
a/meta/recipes-devtools/rpm/files/0001-mono-find-provides-requires-do-not-use-monodis-from-.patch
 
b/meta/recipes-devtools/rpm/files/0001-mono-find-provides-requires-do-not-use-monodis-from-.patch
new file mode 100644
index 000..24aa4c7
--- /dev/null
+++ 
b/meta/recipes-devtools/rpm/files/0001-mono-find-provides-requires-do-not-use-monodis-from-.patch
@@ -0,0 +1,58 @@
+From 43fbc3f53302a395463e8450ac81c53f623eec3f Mon Sep 17 00:00:00 2001
+From: Alexander Kanavin 
+Date: Tue, 27 Aug 2019 17:42:34 +0200
+Subject: [PATCH] mono-find-provides/requires: do not use monodis from the host
+
+There was a host contamination issue here: if monodis was installed
+on the host, do_package would use that to resolve dependencies
+of mono libraries (and often fail in that). Without monodis,
+no dependencies are resolved, which is seemingly how things
+are supposed to work.
+
+Upstream-Status: Inappropriate [oe-core specific]
+Signed-off-by: Alexander Kanavin 
+---
+ scripts/mono-find-provides | 8 
+ scripts/mono-find-requires | 8 
+ 2 files changed, 8 insertions(+), 8 deletions(-)
+
+diff --git a/scripts/mono-find-provides b/scripts/mono-find-provides
+index 9348457d3..b28872ffb 100644
+--- a/scripts/mono-find-provides
 b/scripts/mono-find-provides
+@@ -18,11 +18,11 @@ monolist=($(printf "%s\n" "${filelist[@]}" | grep -E 
"\\.(exe|dll)\$"))
+ build_bindir="$2/usr/bin"
+ build_libdir="$2$3"
+ 
+-if [ -x $build_bindir/monodis ]; then
+-monodis="$build_bindir/monodis"
++if [ -x $build_bindir/monodis.bogus ]; then
++monodis="$build_bindir/monodis.bogus"
+ export LD_LIBRARY_PATH=$build_libdir${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
+-elif [ -x /usr/bin/monodis ]; then
+-monodis="/usr/bin/monodis"
++elif [ -x /usr/bin/monodis.bogus ]; then
++monodis="/usr/bin/monodis.bogus"
+ else
+ exit 0;
+ fi
+diff --git a/scripts/mono-find-requires b/scripts/mono-find-requires
+index ea58cae48..d270169e1 100644
+--- a/scripts/mono-find-requires
 b/scripts/mono-find-requires
+@@ -18,11 +18,11 @@ monolist=($(printf "%s\n" "${filelist[@]}" | grep -E 
"\\.(exe|dll)\$"))
+ build_bindir="$2/usr/bin"
+ build_libdir="$2$3"
+ 
+-if [ -x $build_bindir/monodis ]; then
+-monodis="$build_bindir/monodis"
++if [ -x $build_bindir/monodis.bogus ]; then
++monodis="$build_bindir/monodis.bogus"
+ export LD_LIBRARY_PATH=$build_libdir${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
+-elif [ -x /usr/bin/monodis ]; then
+-monodis="/usr/bin/monodis"
++elif [ -x /usr/bin/monodis.bogus ]; then
++monodis="/usr/bin/monodis.bogus"
+ else
+ exit 0;
+ fi
diff --git a/meta/recipes-devtools/rpm/rpm_4.14.2.1.bb 
b/meta/recipes-devtools/rpm/rpm_4.14.2.1.bb
index 063f4269a57..c37330eb4c6 100644
--- a/meta/recipes-devtools/rpm/rpm_4.14.2.1.bb
+++ b/meta/recipes-devtools/rpm/rpm_4.14.2.1.bb
@@ -41,6 +41,7 @@ SRC_URI = 
"git://github.com/rpm-software-management/rpm;branch=rpm-4.14.x \
file://0001-perl-disable-auto-reqs.patch \

file://0001-rpm-rpmio.c-restrict-virtual-memory-usage-if-limit-s.patch \

file://0016-rpmscript.c-change-logging-level-around-scriptlets-t.patch \
+   
file://0001-mono-find-provides-requires-do-not-use-monodis-from-.patch \
"
 
 PE = "1"
-- 
2.17.1

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

[OE-core] [PATCH 2/4] qemu: set default RAM to 256M for all machines

[Alexander Kanavin]

There was a discussion about what amount of RAM is appropriate for a
default; the outcome was that for now it is still 256M. Some qemu machine
definitions have however set this to 512M so for the sake of
treating all architectures fairly, they are reset back to 256M.

Also runqemu is adjusted to use 256M if QB_MEM is not set at all.

http://lists.openembedded.org/pipermail/openembedded-core/2019-August/285900.html

Signed-off-by: Alexander Kanavin 
---
 meta/conf/machine/include/qemuboot-mips.inc   | 1 -
 meta/conf/machine/include/riscv/qemuriscv.inc | 1 -
 meta/conf/machine/qemuarm.conf| 1 -
 meta/conf/machine/qemuarm64.conf  | 1 -
 scripts/runqemu   | 4 ++--
 5 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/meta/conf/machine/include/qemuboot-mips.inc 
b/meta/conf/machine/include/qemuboot-mips.inc
index a5f9ed821f4..1c2b532b482 100644
--- a/meta/conf/machine/include/qemuboot-mips.inc
+++ b/meta/conf/machine/include/qemuboot-mips.inc
@@ -1,6 +1,5 @@
 # For runqemu
 IMAGE_CLASSES += "qemuboot"
-QB_MEM = "-m 256"
 QB_MACHINE = "-machine malta"
 QB_KERNEL_CMDLINE_APPEND = "console=ttyS0 console=tty"
 QB_OPT_APPEND = "-vga cirrus -show-cursor -usb -device usb-tablet"
diff --git a/meta/conf/machine/include/riscv/qemuriscv.inc 
b/meta/conf/machine/include/riscv/qemuriscv.inc
index f1cb62818b7..952779e98e8 100644
--- a/meta/conf/machine/include/riscv/qemuriscv.inc
+++ b/meta/conf/machine/include/riscv/qemuriscv.inc
@@ -24,7 +24,6 @@ UBOOT_ENTRYPOINT_riscv64 = "0x8020"
 
 # qemuboot options
 QB_KERNEL_CMDLINE_APPEND = "earlycon=sbi"
-QB_MEM = "-m 512"
 QB_MACHINE = "-machine virt"
 QB_DEFAULT_BIOS = "fw_jump.elf"
 QB_TAP_OPT = "-netdev tap,id=net0,ifname=@TAP@,script=no,downscript=no"
diff --git a/meta/conf/machine/qemuarm.conf b/meta/conf/machine/qemuarm.conf
index 0a2c9953125..26f40b14194 100644
--- a/meta/conf/machine/qemuarm.conf
+++ b/meta/conf/machine/qemuarm.conf
@@ -11,7 +11,6 @@ SERIAL_CONSOLES ?= "115200;ttyAMA0 115200;hvc0"
 
 # For runqemu
 QB_SYSTEM_NAME = "qemu-system-arm"
-QB_MEM = "-m 512"
 QB_MACHINE = "-machine virt"
 QB_CPU = "-cpu cortex-a15"
 # Standard Serial console
diff --git a/meta/conf/machine/qemuarm64.conf b/meta/conf/machine/qemuarm64.conf
index 353ac927d94..ec2a887bddf 100644
--- a/meta/conf/machine/qemuarm64.conf
+++ b/meta/conf/machine/qemuarm64.conf
@@ -11,7 +11,6 @@ SERIAL_CONSOLES ?= "115200;ttyAMA0 115200;hvc0"
 
 # For runqemu
 QB_SYSTEM_NAME = "qemu-system-aarch64"
-QB_MEM = "-m 512"
 QB_MACHINE = "-machine virt"
 QB_CPU = "-cpu cortex-a57"
 QB_CPU_KVM = "-cpu host"
diff --git a/scripts/runqemu b/scripts/runqemu
index e9b83737cbf..7705b2b60e3 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -755,8 +755,8 @@ class BaseConfig(object):
 if s:
 self.set('QB_MEM', '-m %s' % s.group(1))
 elif not self.get('QB_MEM'):
-logger.info('QB_MEM is not set, use 512M by default')
-self.set('QB_MEM', '-m 512')
+logger.info('QB_MEM is not set, use 256M by default')
+self.set('QB_MEM', '-m 256')
 
 # Check and remove M or m suffix
 qb_mem = self.get('QB_MEM')
-- 
2.17.1

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

Re: [OE-core] [PATCH 1/11] binutils: Add do_check task for executing binutils test suite

[richard . purdie]

On Wed, 2019-08-28 at 05:06 +, Nathan Rossi wrote:
> Create the do_check task to the binutils-cross include. This task can
> be
> used to execute the binutils test suite for the cross target
> binutils.
> By default this executes all the check targets of the binutils
> Makefile,
> this can however be changed by setting MAKE_CHECK_TARGETS to the
> desired
> test suite target (e.g. check-gas).
> 
> The binutils test suites do not require any target execution, as such
> the check target can be run without QEMU or a target device. However
> since the binutils tests do rely on a C compiler there is dependence
> on
> both gcc and libc in order to run the tests.
> 
> Signed-off-by: Nathan Rossi 

Looking at this a bit further we have a problem with gcc-cross and
binutils-cross.

The trouble is we extracted all "target" dependencies away from the
cross recipes. This means we build *-cross once per target arch but the
runtime pieces are build once per target tune.

The tests are very much target tune specific so shouldn't be in the
cross recipes.

This is going to cause worlds of pain when we switch between machines
that use the same arch but different tunes and the sysroot has files
from a previous different tune.

I suspect this will manifest itself should we run the signature checks
but there real underlying problem here people will run into that we'll
have to solve before this can merge.

There is a secondary issue later in the series with adding the test
results to "selftest".

On the autobuilder we run "selftest" once and assume its machine
independent. These results clearly aren't. This gives problems for both
running the tests and processing the results.

Equally, "cross" toolchain tests aren't really "runtime" but are
machine/target specific. FWIW, injecting the test results the way you
are doing is good and the right thing to do but I think we may need a
different class of test, or we inject them as a special case of runtime
test, or runtime ptest (a cross runtime ptest result?).

I'm happy to try and help figure out how to address some of this if I
can help somehow. I am conscious the release deadlines are pressing too
:(.

Cheers,

Richard









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

Re: [OE-core] [PATCH 1/11] binutils: Add do_check task for executing binutils test suite

[richard . purdie]

On Wed, 2019-08-28 at 05:06 +, Nathan Rossi wrote:
> Create the do_check task to the binutils-cross include. This task can be
> used to execute the binutils test suite for the cross target binutils.
> By default this executes all the check targets of the binutils Makefile,
> this can however be changed by setting MAKE_CHECK_TARGETS to the desired
> test suite target (e.g. check-gas).
> 
> The binutils test suites do not require any target execution, as such
> the check target can be run without QEMU or a target device. However
> since the binutils tests do rely on a C compiler there is dependence on
> both gcc and libc in order to run the tests.
> 
> Signed-off-by: Nathan Rossi 
> ---
>  meta/recipes-devtools/binutils/binutils-cross.inc | 28 
> +++
>  1 file changed, 28 insertions(+)
> 
> diff --git a/meta/recipes-devtools/binutils/binutils-cross.inc 
> b/meta/recipes-devtools/binutils/binutils-cross.inc
> index 02ec891606..76eb453f0e 100644
> --- a/meta/recipes-devtools/binutils/binutils-cross.inc
> +++ b/meta/recipes-devtools/binutils/binutils-cross.inc
> @@ -36,3 +36,31 @@ do_install () {
>   rmdir ${D}${STAGING_DIR_NATIVE}${prefix_native}/${libdir}64 || :
>   rmdir ${D}${STAGING_DIR_NATIVE}${prefix_native}/${prefix} || :
>  }
> +
> +EXTRA_OEMAKE_prepend_task-check = "${PARALLEL_MAKE} "
> +MAKE_CHECK_TARGETS ??= "check-binutils check-gas check-gold check-ld 
> check-libiberty"
> +
> +python () {
> +# crosssdk deps have different virtual targets
> +if bb.data.inherits_class('crosssdk', d):
> +d.appendVarFlag("do_check", "depends", " 
> virtual/${TARGET_PREFIX}gcc-crosssdk:do_populate_sysroot")
> +d.appendVarFlag("do_check", "depends", " 
> virtual/nativesdk-${TARGET_PREFIX}compilerlibs:do_populate_sysroot")
> +else:
> +d.appendVarFlag("do_check", "depends", " 
> virtual/${TARGET_PREFIX}gcc:do_populate_sysroot")
> +d.appendVarFlag("do_check", "depends", " 
> virtual/${TARGET_PREFIX}compilerlibs:do_populate_sysroot")
> +}

I'm torn here on whether we should do:

do_check[depends] += "${BINUTILS_TARGETDEPS}"
BINUTILS_TARGETDEPS = "virtual/${TARGET_PREFIX}gcc:do_populate_sysroot 
virtual/${TARGET_PREFIX}compilerlibs:do_populate_sysroot"
BINUTILS_TARGETDEPS_class-crosssdk = 
"virtual/${TARGET_PREFIX}gcc-crosssdk:do_populate_sysroot 
virtual/nativesdk-${TARGET_PREFIX}compilerlibs:do_populate_sysroot"

instead of the above.

Cheers,

Richard


> +do_check[depends] += "dejagnu-native:do_populate_sysroot 
> expect-native:do_populate_sysroot"
> +do_check[depends] += "virtual/libc:do_populate_sysroot"
> +do_check[dirs] = "${B}"
> +do_check[nostamp] = "1"
> +do_check() {
> +# need to inject CC and CXX as the target CC and CXX with sysroot
> +oe_runmake -i ${MAKE_CHECK_TARGETS} \
> +RUNTESTFLAGS=" \
> +CC='${TARGET_PREFIX}gcc --sysroot=${STAGING_DIR_TARGET} 
> ${TUNE_CCARGS}' \
> +CXX='${TARGET_PREFIX}g++ --sysroot=${STAGING_DIR_TARGET} 
> ${TUNE_CCARGS}' \
> +"
> +}
> +addtask check after do_compile
> +
> ---
> 2.23.0.rc1
> 

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

Re: [OE-core] [PATCH] boost: update to 1.71.0

[Khem Raj]

few build regressions

https://errors.yoctoproject.org/Errors/Details/266071/
https://errors.yoctoproject.org/Errors/Details/266060/

On Mon, Aug 26, 2019 at 7:26 AM Alexander Kanavin
 wrote:
>
> Some notes:
> - bjam bootstrap scripts were changed, and the patch for that had to be
>   adjusted. tools/build/src/engine/build.sh now supports an --debug option
>   which the bjam-native recipe can use to get the debug build of b2.
> - a related patch was added to address a speed regression with the debug
>   version of bjam
> - gcc.jam patch had to be refreshed because boost added more "cpu-flags"
>   lines.
> - since 1.70.0, boost includes new cmake config files which are packaged
>   in ${PN}-dev now so they make it into the SDK. (although 1.71.0 is needed
>   to fix some bugs in them)
>
> Signed-off-by: Alexander Kanavin 
> ---
>  ...native_1.69.0.bb => bjam-native_1.71.0.bb} |  7 +--
>  .../{boost-1.69.0.inc => boost-1.71.0.inc}|  6 +--
>  meta/recipes-support/boost/boost.inc  |  2 +-
>  ...h-instruction-set-flags-we-do-that-o.patch | 15 --
>  .../{boost_1.69.0.bb => boost_1.71.0.bb}  |  0
>  .../0001-Build-debug-version-of-bjam.patch| 38 ++
>  sh-use-DNDEBUG-also-in-debug-builds.patch | 27 ++
>  .../files/bjam-native-build-bjam.debug.patch  | 50 ---
>  8 files changed, 83 insertions(+), 62 deletions(-)
>  rename meta/recipes-support/boost/{bjam-native_1.69.0.bb => 
> bjam-native_1.71.0.bb} (57%)
>  rename meta/recipes-support/boost/{boost-1.69.0.inc => boost-1.71.0.inc} 
> (77%)
>  rename meta/recipes-support/boost/{boost_1.69.0.bb => boost_1.71.0.bb} (100%)
>  create mode 100644 
> meta/recipes-support/boost/files/0001-Build-debug-version-of-bjam.patch
>  create mode 100644 
> meta/recipes-support/boost/files/0001-build.sh-use-DNDEBUG-also-in-debug-builds.patch
>  delete mode 100644 
> meta/recipes-support/boost/files/bjam-native-build-bjam.debug.patch
>
> diff --git a/meta/recipes-support/boost/bjam-native_1.69.0.bb 
> b/meta/recipes-support/boost/bjam-native_1.71.0.bb
> similarity index 57%
> rename from meta/recipes-support/boost/bjam-native_1.69.0.bb
> rename to meta/recipes-support/boost/bjam-native_1.71.0.bb
> index 94f96e62d8f..d843eb038cb 100644
> --- a/meta/recipes-support/boost/bjam-native_1.69.0.bb
> +++ b/meta/recipes-support/boost/bjam-native_1.71.0.bb
> @@ -5,8 +5,9 @@ SECTION = "devel"
>
>  inherit native
>
> -SRC_URI += "file://bjam-native-build-bjam.debug.patch \
> -"
> +SRC_URI += "file://0001-Build-debug-version-of-bjam.patch \
> +file://0001-build.sh-use-DNDEBUG-also-in-debug-builds.patch \
> +   "
>
>  do_compile() {
>  ./bootstrap.sh --with-toolset=gcc
> @@ -15,5 +16,5 @@ do_compile() {
>  do_install() {
>  install -d ${D}${bindir}/
>  # install unstripped version for bjam
> -install -c -m 755 bjam.debug ${D}${bindir}/bjam
> +install -c -m 755 b2 ${D}${bindir}/bjam
>  }
> diff --git a/meta/recipes-support/boost/boost-1.69.0.inc 
> b/meta/recipes-support/boost/boost-1.71.0.inc
> similarity index 77%
> rename from meta/recipes-support/boost/boost-1.69.0.inc
> rename to meta/recipes-support/boost/boost-1.71.0.inc
> index 923436b1e0d..7164d0f1c57 100644
> --- a/meta/recipes-support/boost/boost-1.69.0.inc
> +++ b/meta/recipes-support/boost/boost-1.71.0.inc
> @@ -11,9 +11,9 @@ BOOST_VER = "${@"_".join(d.getVar("PV").split("."))}"
>  BOOST_MAJ = "${@"_".join(d.getVar("PV").split(".")[0:2])}"
>  BOOST_P = "boost_${BOOST_VER}"
>
> -SRC_URI = 
> "${SOURCEFORGE_MIRROR}/project/boost/boost/${PV}/${BOOST_P}.tar.bz2"
> -SRC_URI[md5sum] = "a1332494397bf48332cb152abfefcec2"
> -SRC_URI[sha256sum] = 
> "8f32d4617390d1c2d16f26a27ab60d97807b35440d45891fa340fc2648b04406"
> +SRC_URI = 
> "https://dl.bintray.com/boostorg/release/${PV}/source/${BOOST_P}.tar.bz2;
> +SRC_URI[md5sum] = "4cdf9b5c2dc01fb2b7b733d5af30e558"
> +SRC_URI[sha256sum] = 
> "d73a8da01e8bf8c7eda40b4c84915071a8c8a0df4a6734537ddde4a8580524ee"
>
>  UPSTREAM_CHECK_URI = "http://www.boost.org/users/download/;
>  UPSTREAM_CHECK_REGEX = "boostorg/release/(?P.*)/source/"
> diff --git a/meta/recipes-support/boost/boost.inc 
> b/meta/recipes-support/boost/boost.inc
> index f385541653c..e15dce4e1d3 100644
> --- a/meta/recipes-support/boost/boost.inc
> +++ b/meta/recipes-support/boost/boost.inc
> @@ -83,7 +83,7 @@ FILES_boost-test = 
> "${libdir}/libboost_prg_exec_monitor*.so.* \
>
>  # -dev last to pick up the remaining stuff
>  PACKAGES += "${PN}-dev ${PN}-staticdev"
> -FILES_${PN}-dev = "${includedir} ${libdir}/libboost_*.so"
> +FILES_${PN}-dev = "${includedir} ${libdir}/libboost_*.so ${libdir}/cmake"
>  FILES_${PN}-staticdev = "${libdir}/libboost_*.a"
>
>  # "boost" is a metapackage which pulls in all boost librabries
> diff --git 
> a/meta/recipes-support/boost/boost/0001-Don-t-set-up-arch-instruction-set-flags-we-do-that-o.patch
>  
> b/meta/recipes-support/boost/boost/0001-Don-t-set-up-arch-instruction-set-flags-we-do-that-o.patch
> index 

Re: [OE-core] [PATCH 1/2] uboot-sign: Refactor do_deploy prefunc to do_deploy_prepend

[Richard Purdie]

On Wed, 2019-08-28 at 13:41 +0200, Daniel Klauer wrote:
> bitbake removes cleandirs once per prefunc and then again for the actual
> task.

That commit message isn't correct.

It removes cleandirs for the prefunc at the start of the prefunc and
cleandirs for the main function at the start of that main function.

The code is in lib/bb/build.py:

for func in (prefuncs or '').split():
exec_func(func, localdata)
exec_func(task, localdata)
for func in (postfuncs or '').split():
exec_func(func, localdata)

with the cleandirs happening in exec_func() for each function.

This does mean the cleandirs happens after the prefunc is called but
not as described above.

>  By moving the concat_dtb step here from prefunc to main task we can
> add
> do_deploy[cleandirs] = "${DEPLOYDIR}"
> to deploy.bbclass without losing the files produced by concat_dtb.

I think you also need to state here that this is only expected to be
run for the uboot recipe and not the kernel.

The patch itself is probably ok but I'd ask the commit message be
corrected please.

Cheers,

Richard

> It looks like using do_deploy(_append) was the original goal anyways.
> 
> I tested this with poky, putting the following in local.conf:
>   UBOOT_SIGN_ENABLE = "1"
>   KERNEL_CLASSES = " kernel-fitimage "
>   KERNEL_IMAGETYPE = "fitImage"
> and then doing
>   bitbake core-image-minimal
>   bitbake u-boot
> It builds successfully, the kernel and uboot recipes' temp/run.do_deploy
> scripts look good (kernel's do_deploy is not broken, and uboot's do_deploy
> still calls concat_dtb).
> 
> Signed-off-by: Daniel Klauer 
> ---
>  meta/classes/uboot-sign.bbclass | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/meta/classes/uboot-sign.bbclass b/meta/classes/uboot-sign.bbclass
> index 982ed46d01..713196df41 100644
> --- a/meta/classes/uboot-sign.bbclass
> +++ b/meta/classes/uboot-sign.bbclass
> @@ -117,15 +117,16 @@ do_install_append() {
>   fi
>  }
>  
> +do_deploy_prepend_pn-${UBOOT_PN}() {
> + if [ "${UBOOT_SIGN_ENABLE}" = "1" -a -n "${UBOOT_DTB_BINARY}" ]; then
> + concat_dtb
> + fi
> +}
> +
>  python () {
>  if d.getVar('UBOOT_SIGN_ENABLE') == '1' and d.getVar('PN') == 
> d.getVar('UBOOT_PN') and d.getVar('UBOOT_DTB_BINARY'):
>  kernel_pn = d.getVar('PREFERRED_PROVIDER_virtual/kernel')
>  
>  # Make "bitbake u-boot -cdeploy" deploys the signed u-boot.dtb
>  d.appendVarFlag('do_deploy', 'depends', ' %s:do_deploy' % kernel_pn)
> -
> -# kernerl's do_deploy is a litle special, so we can't use
> -# do_deploy_append, otherwise it would override
> -# kernel_do_deploy.
> -d.appendVarFlag('do_deploy', 'prefuncs', ' concat_dtb')
>  



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

[OE-core] [PATCH 1/2] uboot-sign: Refactor do_deploy prefunc to do_deploy_prepend

[Daniel Klauer]

bitbake removes cleandirs once per prefunc and then again for the actual
task. By moving the concat_dtb step here from prefunc to main task we can
add
do_deploy[cleandirs] = "${DEPLOYDIR}"
to deploy.bbclass without losing the files produced by concat_dtb.

It looks like using do_deploy(_append) was the original goal anyways.

I tested this with poky, putting the following in local.conf:
  UBOOT_SIGN_ENABLE = "1"
  KERNEL_CLASSES = " kernel-fitimage "
  KERNEL_IMAGETYPE = "fitImage"
and then doing
  bitbake core-image-minimal
  bitbake u-boot
It builds successfully, the kernel and uboot recipes' temp/run.do_deploy
scripts look good (kernel's do_deploy is not broken, and uboot's do_deploy
still calls concat_dtb).

Signed-off-by: Daniel Klauer 
---
 meta/classes/uboot-sign.bbclass | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/meta/classes/uboot-sign.bbclass b/meta/classes/uboot-sign.bbclass
index 982ed46d01..713196df41 100644
--- a/meta/classes/uboot-sign.bbclass
+++ b/meta/classes/uboot-sign.bbclass
@@ -117,15 +117,16 @@ do_install_append() {
fi
 }
 
+do_deploy_prepend_pn-${UBOOT_PN}() {
+   if [ "${UBOOT_SIGN_ENABLE}" = "1" -a -n "${UBOOT_DTB_BINARY}" ]; then
+   concat_dtb
+   fi
+}
+
 python () {
 if d.getVar('UBOOT_SIGN_ENABLE') == '1' and d.getVar('PN') == 
d.getVar('UBOOT_PN') and d.getVar('UBOOT_DTB_BINARY'):
 kernel_pn = d.getVar('PREFERRED_PROVIDER_virtual/kernel')
 
 # Make "bitbake u-boot -cdeploy" deploys the signed u-boot.dtb
 d.appendVarFlag('do_deploy', 'depends', ' %s:do_deploy' % kernel_pn)
-
-# kernerl's do_deploy is a litle special, so we can't use
-# do_deploy_append, otherwise it would override
-# kernel_do_deploy.
-d.appendVarFlag('do_deploy', 'prefuncs', ' concat_dtb')
 }
-- 
2.17.1

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

[OE-core] [PATCH 2/2] deploy.bbclass: Clean DEPLOYDIR before do_deploy

[Daniel Klauer]

It seems convenient for do_deploy to clean up ${DEPLOYDIR} (its output
directory) before running, just like do_install cleans up ${D} before
running. This way we can be sure that a recipe's do_deploy output is not
accidentally contaminated by previously existing files in DEPLOYDIR in
case of incremental builds.

All recipes using deploy.bbclass (grep -r 'inherit .*deploy') in poky,
meta-openembedded and meta-freescale look to me like they either benefit
from this or are at least not affected negatively by it. The only exception
I've noticed was uboot-sign.bbclass, which was however fixed by the
previous patch.

I tested this by running "bitbake virtual/kernel u-boot":
1. on patched, but clean poky source tree
2. after adding "touch ${DEPLOYDIR}/foo-${PN}" to linux-yocto's/u-boot's
   do_deploy, to manually trigger an incremental build of do_deploy only.
3. after removing the modifications again.
The foo-${PN} files existed in tmp/deploy/images/qemux86-64 after step 2,
and not anymore after step 3, as expected. Thus the cleandirs still works.

Signed-off-by: Daniel Klauer 
---
 meta/classes/deploy.bbclass| 1 +
 meta/classes/kernel.bbclass| 2 --
 meta/recipes-core/meta/signing-keys.bb | 2 --
 meta/recipes-core/ovmf/ovmf_git.bb | 1 -
 4 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/meta/classes/deploy.bbclass b/meta/classes/deploy.bbclass
index 6d52908783..737c26122b 100644
--- a/meta/classes/deploy.bbclass
+++ b/meta/classes/deploy.bbclass
@@ -8,4 +8,5 @@ python do_deploy_setscene () {
 }
 addtask do_deploy_setscene
 do_deploy[dirs] = "${DEPLOYDIR} ${B}"
+do_deploy[cleandirs] = "${DEPLOYDIR}"
 do_deploy[stamp-extra-info] = "${MACHINE_ARCH}"
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index bf3674238f..aa339ace7e 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -706,8 +706,6 @@ kernel_do_deploy() {
done
fi
 }
-do_deploy[cleandirs] = "${DEPLOYDIR}"
-do_deploy[dirs] = "${DEPLOYDIR} ${B}"
 do_deploy[prefuncs] += "package_get_auto_pr"
 
 addtask deploy after do_populate_sysroot do_packagedata
diff --git a/meta/recipes-core/meta/signing-keys.bb 
b/meta/recipes-core/meta/signing-keys.bb
index 1e1c7e3459..5bab94aa36 100644
--- a/meta/recipes-core/meta/signing-keys.bb
+++ b/meta/recipes-core/meta/signing-keys.bb
@@ -67,8 +67,6 @@ do_deploy () {
 fi
 }
 do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_RPM}"
-# cleandirs should possibly be in deploy.bbclass but we need it
-do_deploy[cleandirs] = "${DEPLOYDIR}"
 # clear stamp-extra-info since MACHINE_ARCH is normally put there by
 # deploy.bbclass
 do_deploy[stamp-extra-info] = ""
diff --git a/meta/recipes-core/ovmf/ovmf_git.bb 
b/meta/recipes-core/ovmf/ovmf_git.bb
index b569b593fc..2c804381ee 100644
--- a/meta/recipes-core/ovmf/ovmf_git.bb
+++ b/meta/recipes-core/ovmf/ovmf_git.bb
@@ -223,7 +223,6 @@ do_deploy[depends] += "${DEPLOYDEP}"
 
 do_deploy() {
 }
-do_deploy[cleandirs] = "${DEPLOYDIR}"
 do_deploy_class-target() {
 # For use with "runqemu ovmf".
 for i in \
-- 
2.17.1

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

Re: [OE-core] [v2] systemd: Fix interface bring-up on kernels >= 5.2

[Jan Klare]

Hi,

I think this patch is not needed anymore since both patches have already been 
backported to the latest stable version of systemd v242. To include these 
patches in the yocto builds we need to update the SRCREV to the latest commit 
in the v242-stable branch of systemd/systemd-stable 
(07f0549ffe3413f0e78b656dd34d64681cbd8f00).

https://github.com/systemd/systemd-stable/tree/v242-stable 


The same is done here https://patchwork.openembedded.org/series/19508/ 
 for systemd v241-stable.

Cheers,
Jan


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

[OE-core] [PATCH 1/2] ccache: 3.7.1 -> 3.7.3

[Robert Yang]

Signed-off-by: Robert Yang 
---
 meta/recipes-devtools/ccache/{ccache_3.7.1.bb => ccache_3.7.3.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-devtools/ccache/{ccache_3.7.1.bb => ccache_3.7.3.bb} (45%)

diff --git a/meta/recipes-devtools/ccache/ccache_3.7.1.bb 
b/meta/recipes-devtools/ccache/ccache_3.7.3.bb
similarity index 45%
rename from meta/recipes-devtools/ccache/ccache_3.7.1.bb
rename to meta/recipes-devtools/ccache/ccache_3.7.3.bb
index 1db7094..c6a682e 100644
--- a/meta/recipes-devtools/ccache/ccache_3.7.1.bb
+++ b/meta/recipes-devtools/ccache/ccache_3.7.3.bb
@@ -3,5 +3,5 @@ require ccache.inc
 LICENSE = "GPLv3+"
 LIC_FILES_CHKSUM = "file://LICENSE.adoc;md5=0094c59039cec66b8a4c905204333514"
 
-SRC_URI[md5sum] = "74339465ab87e0b406985ed69515f19b"
-SRC_URI[sha256sum] = 
"e562fcdbe766406b6fe4bf97ce5c001d2be8a17465f33bcddefc9499bbb057d8"
+SRC_URI[md5sum] = "7be62ea6e190941a8c12a3d5394fd926"
+SRC_URI[sha256sum] = 
"355955a61562c53c4ec4669e1c92708b0008f50d214b27f07a87cf4a1fa6b01e"
-- 
2.7.4

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

[OE-core] [PATCH 2/2] nfs-utils: 2.3.3 -> 2.4.1

[Robert Yang]

- Remove 0001-Do-not-pass-null-pointer-to-freeaddrinfo.patch, the new api
  can check the pointer before free it.

- Rmove 0001-makefile.am-update-the-path-of-libnfs.a.patch, it is already in
  the source.

- Rmove nfs-utils-musl-limits.patch, it is already fixed.

-  Rebased the following patches:
   0001-Makefile.am-fix-undefined-function-for-libnsm.a.patch
   0001-configure.ac-Do-not-fatalize-Wmissing-prototypes.patch
   bugfix-adjust-statd-service-name.patch
   nfs-utils-musl-res_querydomain.patch

Signed-off-by: Robert Yang 
---
 ...-Do-not-pass-null-pointer-to-freeaddrinfo.patch |  32 -
 ...le.am-fix-undefined-function-for-libnsm.a.patch |  22 ++--
 ...1-Makefile.am-update-the-path-of-libnfs.a.patch |  50 
 ...re.ac-Do-not-fatalize-Wmissing-prototypes.patch |   9 +-
 .../bugfix-adjust-statd-service-name.patch |  30 +++--
 .../nfs-utils/nfs-utils-musl-limits.patch  | 133 -
 .../nfs-utils/nfs-utils-musl-res_querydomain.patch |  23 +---
 .../{nfs-utils_2.3.3.bb => nfs-utils_2.4.1.bb} |  10 +-
 8 files changed, 41 insertions(+), 268 deletions(-)
 delete mode 100644 
meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Do-not-pass-null-pointer-to-freeaddrinfo.patch
 delete mode 100644 
meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Makefile.am-update-the-path-of-libnfs.a.patch
 delete mode 100644 
meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-utils-musl-limits.patch
 rename meta/recipes-connectivity/nfs-utils/{nfs-utils_2.3.3.bb => 
nfs-utils_2.4.1.bb} (92%)

diff --git 
a/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Do-not-pass-null-pointer-to-freeaddrinfo.patch
 
b/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Do-not-pass-null-pointer-to-freeaddrinfo.patch
deleted file mode 100644
index a44d1bf..000
--- 
a/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Do-not-pass-null-pointer-to-freeaddrinfo.patch
+++ /dev/null
@@ -1,32 +0,0 @@
-From 4f115fc314646500f7b4178d7248a02654c7cd10 Mon Sep 17 00:00:00 2001
-From: Khem Raj 
-Date: Fri, 30 Nov 2018 16:47:57 -0800
-Subject: [PATCH] Do not pass null pointer to freeaddrinfo()
-
-Passing null pointer as input parameter to freeaddrinfo() is undefined
-behaviour, some libcs e.g. glibc might just call free() which does
-accept null pointer but other libcs e.g. musl might not and instead
-cause the program to segfault. Therefore do not rely on undefined
-behaviour instead make it deterministic
-
-Upstream-Status: Pending
-
-Signed-off-by: Khem Raj 

- support/export/client.c | 3 ++-
- 1 file changed, 2 insertions(+), 1 deletion(-)
-
-Index: nfs-utils-2.3.2/support/export/client.c
-===
 nfs-utils-2.3.2.orig/support/export/client.c
-+++ nfs-utils-2.3.2/support/export/client.c
-@@ -309,7 +309,8 @@ client_lookup(char *hname, int canonical
-   init_addrlist(clp, ai);
- 
- out:
--  freeaddrinfo(ai);
-+  if (ai)
-+  freeaddrinfo(ai);
-   return clp;
- }
- 
diff --git 
a/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Makefile.am-fix-undefined-function-for-libnsm.a.patch
 
b/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Makefile.am-fix-undefined-function-for-libnsm.a.patch
index aa551eb..fcb0e99 100644
--- 
a/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Makefile.am-fix-undefined-function-for-libnsm.a.patch
+++ 
b/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Makefile.am-fix-undefined-function-for-libnsm.a.patch
@@ -22,25 +22,28 @@ so rename ../support/misc/file.c to ../support/misc/misc.c.
 Upstream-Status: 
Submitted[https://marc.info/?l=linux-nfs=154502780423058=2]
 
 Signed-off-by: Mingli Yu 
+
+Rebase it.
+
+Signed-off-by: Robert Yang 
 ---
  support/misc/Makefile.am |   2 +-
- support/misc/file.c  | 111 ---
- support/misc/misc.c  | 111 +++
+ support/misc/file.c  | 111 
---
+ support/misc/misc.c  | 111 
+++
  support/nsm/Makefile.am  |   2 +-
  4 files changed, 113 insertions(+), 113 deletions(-)
- delete mode 100644 support/misc/file.c
- create mode 100644 support/misc/misc.c
 
 diff --git a/support/misc/Makefile.am b/support/misc/Makefile.am
-index 8936b0d..d4c1f76 100644
+index f9993e3..8b0e9db 100644
 --- a/support/misc/Makefile.am
 +++ b/support/misc/Makefile.am
-@@ -1,6 +1,6 @@
+@@ -1,7 +1,7 @@
  ## Process this file with automake to produce Makefile.in
  
  noinst_LIBRARIES = libmisc.a
--libmisc_a_SOURCES = tcpwrapper.c from_local.c mountpoint.c file.c
-+libmisc_a_SOURCES = tcpwrapper.c from_local.c mountpoint.c misc.c
+-libmisc_a_SOURCES = tcpwrapper.c from_local.c mountpoint.c file.c \
++libmisc_a_SOURCES = tcpwrapper.c from_local.c mountpoint.c 

[OE-core] [PATCH 0/2] Recipes upgrade

[Robert Yang]

The following changes since commit 9b1c150573ffd0e68d37772d5f47482d86ddde6d:

  commands.py: fix typo (2019-08-27 22:52:41 +0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib rbt/pu
  http://cgit.openembedded.org/openembedded-core-contrib/log/?h=rbt/pu

Robert Yang (2):
  ccache: 3.7.1 -> 3.7.3
  nfs-utils: 2.3.3 -> 2.4.1

 ...-Do-not-pass-null-pointer-to-freeaddrinfo.patch |  32 -
 ...le.am-fix-undefined-function-for-libnsm.a.patch |  22 ++--
 ...1-Makefile.am-update-the-path-of-libnfs.a.patch |  50 
 ...re.ac-Do-not-fatalize-Wmissing-prototypes.patch |   9 +-
 .../bugfix-adjust-statd-service-name.patch |  30 +++--
 .../nfs-utils/nfs-utils-musl-limits.patch  | 133 -
 .../nfs-utils/nfs-utils-musl-res_querydomain.patch |  23 +---
 .../{nfs-utils_2.3.3.bb => nfs-utils_2.4.1.bb} |  10 +-
 .../ccache/{ccache_3.7.1.bb => ccache_3.7.3.bb}|   4 +-
 9 files changed, 43 insertions(+), 270 deletions(-)
 delete mode 100644 
meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Do-not-pass-null-pointer-to-freeaddrinfo.patch
 delete mode 100644 
meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Makefile.am-update-the-path-of-libnfs.a.patch
 delete mode 100644 
meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-utils-musl-limits.patch
 rename meta/recipes-connectivity/nfs-utils/{nfs-utils_2.3.3.bb => 
nfs-utils_2.4.1.bb} (92%)
 rename meta/recipes-devtools/ccache/{ccache_3.7.1.bb => ccache_3.7.3.bb} (45%)

-- 
2.7.4

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

[OE-core] [PATCH] common-licenses: update BSD-2-CLAUSE license text

[Christophe PRIOUZEAU]

Using the generic BSD-2-CLAUSE license as specified on
https://opensource.org/licenses/BSD-2-Clause

Signed-off-by: Christophe Priouzeau 
---
 meta/files/common-licenses/BSD-2-Clause | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/meta/files/common-licenses/BSD-2-Clause 
b/meta/files/common-licenses/BSD-2-Clause
index ade0f34d59..f1917d6b73 100644
--- a/meta/files/common-licenses/BSD-2-Clause
+++ b/meta/files/common-licenses/BSD-2-Clause
@@ -1,13 +1,10 @@
 
-The FreeBSD Copyright
-
-Copyright 1992-2010 The FreeBSD Project. All rights reserved.
+Copyright  
 
 Redistribution and use in source and binary forms, with or without 
modification, are permitted provided that the following conditions are met:
 
-Redistributions of source code must retain the above copyright notice, this 
list of conditions and the following disclaimer.
-Redistributions in binary form must reproduce the above copyright notice, this 
list of conditions and the following disclaimer in the documentation and/or 
other materials provided with the distribution.
-THIS SOFTWARE IS PROVIDED BY THE FREEBSD PROJECT ``AS IS`` AND ANY EXPRESS OR 
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO 
EVENT SHALL THE FREEBSD PROJECT OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, 
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, 
BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF 
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE 
OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF 
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+1. Redistributions of source code must retain the above copyright notice, this 
list of conditions and the following disclaimer.
 
-The views and conclusions contained in the software and documentation are 
those of the authors and should not be interpreted as representing official 
policies, either expressed or implied, of the FreeBSD Project.
+2. Redistributions in binary form must reproduce the above copyright notice, 
this list of conditions and the following disclaimer in the documentation 
and/or other materials provided with the distribution.
 
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" 
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE 
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR 
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER 
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, 
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-- 
2.17.1
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [warrior][PATCH v3] systemd: update SRCREV for systemd v241-stable

[Jan Klare]

Hi,

thanks for the new testing instructions, I ran the builds this morning and 
everything worked fine. Let me know if I can do anything else to verify the 
builds or help otherwise in the process.

Cheers,
Jan

> On 27. Aug 2019, at 19:11, Randy MacLeod  wrote:
> 
> On 8/27/19 12:15 PM, Jan Klare wrote:
>> Hi,
>> Thanks for all the initial help and the quick followup review. I 
>> successfully build systemd for the patched SRCREV for all the platforms you 
>> mentioned, should I post something of the output or some proof somewhere?
> 
> No, that usually would be fine.
> We trust you and the automated builders will verify that things work as well. 
> :)
> 
> But...
> 
> In this case I just realized that my oneline build-all was wrong;
> you need:
> 
> $ for i in `ls ../../oe-core.git/meta/conf/machine | \
>grep qemu | sed -e 's/\.conf//'`; \
> do \
>MACHINE=$i bitbake systemd && \
>touch sd-okay-$i || \
>touch sd-fail-$i; \
> done
> 
> 
> I had left off the setting of the MACHINE variable. Sorry about that.
> Can you re-run the test after removing the sd-* files?
> 
> ../Randy
> 
>> Cheers,
>> Jan
>>> On 27. Aug 2019, at 17:14, Randy MacLeod >> > wrote:
>>> 
>>> On 8/27/19 10:52 AM, Jan Klare wrote:
 Currently systemd 241 does break for kernels 5.2+ with the error described 
 here:
 * https://github.com/systemd/systemd/issues/12784
 The issue has been fixed in master and will be fixed in the release 243. 
 The
 necessary patches have been backported to systemd/systemd-stable in the 
 branch
 v241-stable, but currently in warrior an old version of that branch is 
 pulled
 in.
 This patch updates the SRCREV to the latest commit from that branch and
 therefore pulls in the needed fix to run systemd 241 on 5.2+ kernels.
 Signed-off-by: Jan Klare mailto:jan.kl...@bisdn.de>>
 ---
  meta/recipes-core/systemd/systemd.inc | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 diff --git a/meta/recipes-core/systemd/systemd.inc 
 b/meta/recipes-core/systemd/systemd.inc
 index 5bd88ed6ed..2b9c291959 100644
 --- a/meta/recipes-core/systemd/systemd.inc
 +++ b/meta/recipes-core/systemd/systemd.inc
 @@ -14,7 +14,7 @@ LICENSE = "GPLv2 & LGPLv2.1"
  LIC_FILES_CHKSUM = 
 "file://LICENSE.GPL2;md5=751419260aa954499f7abaabaa882bbe \
 file://LICENSE.LGPL2.1;md5=4fbd65380cdd255951079008b364516c"
  -SRCREV = "c1f8ff8d0de7e303b8004b02a0a47d4cc103a7f8"
 +SRCREV = "511646b8ac5c82f210b16920044465756913d238"
  SRCBRANCH = "v241-stable"
  SRC_URI = 
 "git://github.com/systemd/systemd-stable.git;protocol=git;branch=${SRCBRANCH}"
 
>>> 
>>> That's a better log since it explains your motivation.
>>> 
>>> We don't require it but if you send something like this commit again,
>>> it would be good to analyze the commit logs, like this (but likely
>>> without the tutorial flavour):
>>> 
>>> $ cd .../systemd-stable.git
>>> $ git checkout v241-stable
>>> $ git pull
>>> $ git log --oneline c1f8ff8d0de7..511646b8ac5c | wc -l
>>> 157
>>> 
>>> The patches are almost all (1) are cherry-picked back from master to fix 
>>> bugs. The four commits (2) that are not cherry-picks,
>>> are:
>>> 
>>> A revert of something that does not belong in stable,
>>> A customized fix for stable,
>>> A bug fix
>>> A merge commit
>>> 
>>> I was talking with Jan on IRC and he said that he had built
>>> and tested this update for his target (agema-ag7648 switch).
>>> I've asked Jan to build for all qemus so hopefully that goes well.
>>> 
>>> Looks good to me.
>>> 
>>> ../Randy
>>> 
>>> 
>>> [1]
>>> 
>>> $ git log --oneline \
>>>  --grep="cherry picked from commit" c1f8ff8d0de7..511646b8ac5c  | wc -l
>>> 153
>>> 
>>> $ git log --oneline c1f8ff8d0de7..511646b8ac5c | wc -l
>>> 157
>>> 
>>> 
>>> [2]
>>> 
>>> $ git log --oneline --grep="cherry picked from commit" \
>>>   --invert-grep c1f8ff8d0de7..511646b8ac5c
>>> 
>>> 099c5e4f5f Revert "meson: stop creating enablement symlinks
>>>   in /etc during installation"
>>> dc903ec516 Enable RestrictSUIDSGID=yes for our services
>>>   with DynamicUser=yes
>>> ce52d60450 fstab-generator: use DefaultDependencies=no for
>>>   /sysroot mounts
>>> 35387ea7e1 Merge pull request #48 from
>>>   yuwata/v241-stable-dbus-and-timedated
>>> 
>>> 
>>> --
>>> # Randy MacLeod
>>> # Wind River Linux
>>> --
>>> ___
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org 
>>> 
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> 
> 
> --
> # Randy MacLeod
> # Wind River Linux
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



signature.asc
Description: Message 

Re: [OE-core] [PATCH] populate_sdk: fix populate_sdk failed error

[Changqing Li]

ping

On 8/19/19 11:22 AM, changqing...@windriver.com wrote:

From: Changqing Li 

Configuration:
IMAGE_INSTALL_append = " bash"

require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "x86"

Reproduce cmd:
bitbake core-image-minimal -c populate_sdk

Error info:
--> Finished dependency resolution
Error:
  Problem: package target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target 
conflicts with /bin/sh provided by bash-5.0-r0.core2_64
   - package target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target 
conflicts with bash provided by bash-5.0-r0.core2_64
   - package target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target 
conflicts with /bin/bash provided by bash-5.0-r0.core2_64
   - package target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target 
obsoletes bash provided by bash-5.0-r0.core2_64
   - cannot install the best candidate for the job
   - conflicting requests

when do_populate_sdk, package target-sdk-provides-dummy provides
dummy /bin/sh, ... and package bash also provides this, we append
dummy arch sdk-provides-dummy-target to the end of ALL_MULTILIB_PACKAGE_ARCHS,
then reverted sdk-provides-dummy-target to the first arch
for dnf config  etc/dnf/vars/arch to make it high priority.

when multilib is enabled, below statement will not work as expected.
ALL_MULTILIB_PACKAGE_ARCHS = "${@all_multilib_tune_values(d, 'PACKAGE_ARCHS')}"

Eg:
For lib32 variant, PACKAGE_ARCHS is:
all any noarch x86 qemux86_64 sdk-provides-dummy-target

For lib64 variant, PACKAGE_ARCHS is:
all any noarch x86_64 core2-64 qemux86_64 sdk-provides-dummy-target

Then:
ALL_MULTILIB_PACKAGE_ARCHS will be
x86 qemux86_64 sdk-provides-dummy-target x86_64 core2-64

Fixed by append sdk-provides-dummy-target during do_populate_sdk

Signed-off-by: Changqing Li 
---
  meta/classes/populate_sdk_base.bbclass | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/populate_sdk_base.bbclass 
b/meta/classes/populate_sdk_base.bbclass
index 59920a5..3362656 100644
--- a/meta/classes/populate_sdk_base.bbclass
+++ b/meta/classes/populate_sdk_base.bbclass
@@ -21,7 +21,6 @@ def complementary_globs(featurevar, d):
  SDKIMAGE_FEATURES ??= "dev-pkgs dbg-pkgs src-pkgs 
${@bb.utils.contains('DISTRO_FEATURES', 'api-documentation', 'doc-pkgs', '', d)}"
  SDKIMAGE_INSTALL_COMPLEMENTARY = '${@complementary_globs("SDKIMAGE_FEATURES", 
d)}'
  
-PACKAGE_ARCHS_append_task-populate-sdk = " sdk-provides-dummy-target"

  SDK_PACKAGE_ARCHS += "sdk-provides-dummy-${SDKPKGSUFFIX}"
  
  # List of locales to install, or "all" for all of them, or unset for none.

@@ -130,6 +129,7 @@ def populate_sdk_common(d):
  inst_pkgs = (d.getVar("PACKAGE_INSTALL") or "").split()
  inst_attempt_pkgs = (d.getVar("PACKAGE_INSTALL_ATTEMPTONLY") or 
"").split()
  
+d.appendVar('ALL_MULTILIB_PACKAGE_ARCHS', ' sdk-provides-dummy-target')

  d.setVar('PACKAGE_INSTALL_ORIG', ' '.join(inst_pkgs))
  d.setVar('PACKAGE_INSTALL_ATTEMPTONLY', ' '.join(inst_attempt_pkgs))
  


--
BRs

Sandy(Li Changqing)

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

Re: [OE-core] [PATCH v2 2/2] runqemu: Fix guest has not initialized error

[Alexander Kanavin]

On Wed, 28 Aug 2019 at 07:46,  wrote:

> By default qemu use -device VGA,edid=on but in some case cannot use
> display because of it.
> +elif arg == 'gtk':
> +self.qemu_opt_script += ' -device virtio-gpu-pci'
>

This also needs:
a)  '-display gtk, gl=off' should be added explicitly - it is the default
now, but may not be in future qemu versions;
b) the option should be named 'gtk-virtio', as it is important which
emulated video card it is using;
c) the option should be documented at the beginning of runqemu script;
d) like in the previous patch, please first look into why '-vga virtio'
does not work for you;
e) also, if you can, please get to the reason why standard vga does not
work either. It should be working on all qemu variants.

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

Re: [OE-core] [PATCH v2 2/2] runqemu: Fix guest has not initialized error

[Alexander Kanavin]

On Wed, 28 Aug 2019 at 07:46,  wrote:

> By default qemu use -device VGA,edid=on but in some case cannot use
> display because of it.
> +elif arg == 'gtk':
> +self.qemu_opt_script += ' -device virtio-gpu-pci'
>

We would prefer to use standard vga, and enable virtio only for virgl
usage. Can you please look into what the issue is here?

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

Re: [OE-core] [PATCH] runqemu: Change to use -device virtio-gpu-pci instead of -vga virtio

[Alexander Kanavin]

On Wed, 28 Aug 2019 at 06:36,  wrote:

> If using qemu-system-aarch64 or qemu-system-arm with the options, an error
> occured as follows:
>
>   qemu-system-aarch64: Virtio VGA not available
>
> this commit fixes the error to use -device virtio-gpu-pci instead of
> -vga virtio.
>

Can you please look into why that error happens on arm, but not on x86?
-vga virtio is the officially documented option, so I would rather use that
everywhere.

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

[OE-core] [PATCH v2] ltp: cve/meltdown.c: Fix kernel symbol finding

[zhe.he]

From: He Zhe 

Backport a patch to fix the following error.
safe_file_ops.c:219: BROK: Expected 3 conversions got 2 at meltdown.c:272

Signed-off-by: He Zhe 
---
v2: Adjust context based on top of ltp in oe-core

 ...-cve-meltdown.c-Fix-kernel-symbol-finding.patch | 81 ++
 meta/recipes-extended/ltp/ltp_20190517.bb  |  1 +
 2 files changed, 82 insertions(+)
 create mode 100644 
meta/recipes-extended/ltp/ltp/0001-cve-meltdown.c-Fix-kernel-symbol-finding.patch

diff --git 
a/meta/recipes-extended/ltp/ltp/0001-cve-meltdown.c-Fix-kernel-symbol-finding.patch
 
b/meta/recipes-extended/ltp/ltp/0001-cve-meltdown.c-Fix-kernel-symbol-finding.patch
new file mode 100644
index 000..94f6f5a
--- /dev/null
+++ 
b/meta/recipes-extended/ltp/ltp/0001-cve-meltdown.c-Fix-kernel-symbol-finding.patch
@@ -0,0 +1,81 @@
+From fbeda82f440a0098be42dd668cbc47212a86ab48 Mon Sep 17 00:00:00 2001
+From: He Zhe 
+Date: Wed, 21 Aug 2019 16:27:24 +0800
+Subject: [PATCH] cve/meltdown.c: Fix kernel symbol finding
+
+meltdown case fails as below.
+safe_file_ops.c:219: BROK: Expected 3 conversions got 2 at meltdown.c:272
+
+find_kernel_symbol is defined to try twice with each of /proc/kallsyms and
+/boot/System.map-%s. Currently if the symbol is not found in /proc/kallsyms,
+when kernel option CONFIG_KALLSYMS_ALL is disabled, it would stop the case
+immediately due to SAFE_FILE_LINES_SCANF.
+
+This patch turns to use FILE_LINES_SCANF to give find_kernel_symbol second
+chance.
+
+[jstancek] Fix also condition introduced in 7709d2ae92ea, even if
+   /proc/kallsyms is disabled, we still want to try System.map.
+
+Signed-off-by: He Zhe 
+Signed-off-by: Jan Stancek 
+
+Upstream-Status: Backport
+[https://github.com/linux-test-project/ltp/commit/c2049b5c874bc071f8185bffb5fd7dcb042d9ec8]
+
+Remove the hunk for upstream 7709d2ae92ea ("cve/meltdown.c: abort the test if 
kallsyms was not enabled")
+that has been covered by this patch.
+
+Signed-off-by: He Zhe 
+---
+ testcases/cve/meltdown.c | 13 ++---
+ 1 file changed, 10 insertions(+), 3 deletions(-)
+
+diff --git a/testcases/cve/meltdown.c b/testcases/cve/meltdown.c
+index a53ea9b..22651a6 100644
+--- a/testcases/cve/meltdown.c
 b/testcases/cve/meltdown.c
+@@ -267,9 +267,15 @@ find_symbol_in_file(const char *filename, const char 
*symname)
+   int ret, read;
+   char fmt[strlen(symname) + 64];
+ 
++  tst_res(TINFO, "Looking for %s in %s", symname, filename);
++  if (access(filename, F_OK) == -1) {
++  tst_res(TINFO, "%s not available", filename);
++  return 0;
++  }
++
+   sprintf(fmt, "%%lx %%c %s%%c", symname);
+ 
+-  ret = SAFE_FILE_LINES_SCANF(filename, fmt, , , );
++  ret = FILE_LINES_SCANF(filename, fmt, , , );
+   if (ret)
+   return 0;
+ 
+@@ -287,13 +293,11 @@ find_kernel_symbol(const char *name)
+   if (addr)
+   return addr;
+ 
+-  tst_res(TINFO, "not found '%s' in /proc/kallsyms", name);
+   if (uname() < 0)
+   tst_brk(TBROK | TERRNO, "uname");
+ 
+   sprintf(systemmap, "/boot/System.map-%s", utsname.release);
+ 
+-  tst_res(TINFO, "looking in '%s'\n", systemmap);
+   addr = find_symbol_in_file(systemmap, name);
+   return addr;
+ }
+@@ -308,6 +312,9 @@ static void setup(void)
+   saved_cmdline_addr = find_kernel_symbol("saved_command_line");
+   tst_res(TINFO, "_command_line == 0x%lx", saved_cmdline_addr);
+ 
++  if (!saved_cmdline_addr)
++  tst_brk(TCONF, "saved_command_line not found");
++
+   spec_fd = SAFE_OPEN("/proc/cmdline", O_RDONLY);
+ 
+   memset(target_array, 1, sizeof(target_array));
+-- 
+2.7.4
+
diff --git a/meta/recipes-extended/ltp/ltp_20190517.bb 
b/meta/recipes-extended/ltp/ltp_20190517.bb
index b0e2f96..76c45f0 100644
--- a/meta/recipes-extended/ltp/ltp_20190517.bb
+++ b/meta/recipes-extended/ltp/ltp_20190517.bb
@@ -45,6 +45,7 @@ SRC_URI = "git://github.com/linux-test-project/ltp.git \
file://0002-check-for-RES_USE_INET6-during-configure.patch \

file://0001-syscalls-tgkill03-wait-for-defunct-tid-to-get-detach.patch \
file://0001-ustat02-Fix-EFAULT-in-32bit-compatibility-mode.patch \
+   file://0001-cve-meltdown.c-Fix-kernel-symbol-finding.patch \
"
 
 S = "${WORKDIR}/git"
-- 
2.7.4

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

Re: [OE-core] [PATCH] ltp: cve/meltdown.c: Fix kernel symbol finding

[He Zhe]

On 8/27/19 11:56 PM, Richard Purdie wrote:
> On Tue, 2019-08-27 at 12:38 +0800, zhe...@windriver.com wrote:
>> From: He Zhe 
>>
>> Backport a patch to fix the following error.
>> safe_file_ops.c:219: BROK: Expected 3 conversions got 2 at
>> meltdown.c:272
>>
>> Signed-off-by: He Zhe 
>> ---
>>  ...-cve-meltdown.c-Fix-kernel-symbol-finding.patch | 83
>> ++
>>  meta/recipes-extended/ltp/ltp_20190517.bb  |  1 +
>>  2 files changed, 84 insertions(+)
>>  create mode 100644 meta/recipes-extended/ltp/ltp/0001-cve-
>> meltdown.c-Fix-kernel-symbol-finding.patch
> Patch doesn't apply, how was this tested?

Sorry, my test environment messed up with upstream ltp.
v2 will be sent.

Zhe

>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/981/steps/8/logs/step1b
>
> Cheers,
>
> Richard
>
>

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