Re: [OE-core] [PATCH] strace: fix failing ptests

2020-05-21 Thread Anuj Mittal
On Thu, 2020-05-21 at 21:57 -0700, Tim Orling wrote: > Is this for Zeus? Yes, I forgot to include the prefix. Have sent it again with right prefix now. Thanks, Anuj -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138577):

[OE-core] ✗ patchtest: failure for strace: fix failing ptests

2020-05-21 Thread Patchwork
== Series Details == Series: strace: fix failing ptests Revision: 1 URL : https://patchwork.openembedded.org/series/24266/ 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

[OE-core] [zeus][PATCH] strace: fix failing ptests

2020-05-21 Thread Anuj Mittal
From: Alexander Kanavin 1. They need to be run under regular user. 2. Some tests genuinely need more time than 30 seconds 3. The Makefile patch erroneously introduced a test-breaking change. (From OE-Core rev: 3d6bf58c7080c1cacf3ed1f270ff5acf4858c790) Signed-off-by: Alexander Kanavin

Re: [OE-core] [PATCH] strace: fix failing ptests

2020-05-21 Thread Tim Orling
Is this for Zeus? On Thu, May 21, 2020 at 9:51 PM Anuj Mittal wrote: > From: Alexander Kanavin > > 1. They need to be run under regular user. > 2. Some tests genuinely need more time than 30 seconds > 3. The Makefile patch erroneously introduced a test-breaking change. > > (From OE-Core rev:

[OE-core] [PATCH] strace: fix failing ptests

2020-05-21 Thread Anuj Mittal
From: Alexander Kanavin 1. They need to be run under regular user. 2. Some tests genuinely need more time than 30 seconds 3. The Makefile patch erroneously introduced a test-breaking change. (From OE-Core rev: 3d6bf58c7080c1cacf3ed1f270ff5acf4858c790) Signed-off-by: Alexander Kanavin

[OE-core] [PATCH 4/4] go.bbclass: Add `-trimpath` to default build flags

2020-05-21 Thread Otavio Salvador
The `-trimpath` option is important for reproducible builds so full build paths and module paths are not embedded. Signed-off-by: Otavio Salvador --- meta/classes/go.bbclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass

[OE-core] [PATCH 1/4] go-mod.bbclass: Add class for `go mod` support

2020-05-21 Thread Otavio Salvador
When using Go Modules, the the current working directory MUST be at or below the location of the 'go.mod' file when the go tool is used, and there is no way to tell it to look elsewhere. It will automatically look upwards for the file, but not downwards. To support this use case, we provide the

[OE-core] [PATCH 3/4] go-dep: Avoid use of 'go mod' support

2020-05-21 Thread Otavio Salvador
dep utility must not use 'go mod' support, so we explicitly disable it. Signed-off-by: Otavio Salvador --- meta/recipes-devtools/go/go-dep_0.5.4.bb | 4 1 file changed, 4 insertions(+) diff --git a/meta/recipes-devtools/go/go-dep_0.5.4.bb b/meta/recipes-devtools/go/go-dep_0.5.4.bb index

[OE-core] [PATCH 2/4] glide: Avoid use of 'go mod' support

2020-05-21 Thread Otavio Salvador
Glide utility must not use 'go mod' support, so we explicitly disable it. Signed-off-by: Otavio Salvador --- meta/recipes-devtools/glide/glide_0.13.3.bb | 4 1 file changed, 4 insertions(+) diff --git a/meta/recipes-devtools/glide/glide_0.13.3.bb

Re: [OE-core] [PATCH] libsecret: add meson option introspection

2020-05-21 Thread kai
On 2020/5/21 下午6:07, Martin Jansa wrote: If it's no longer mandatory, then please remove: https://github.com/openembedded/openembedded-core/commit/08c86406186828dce19e101adfd118ed5d9e947e together with: # gobject-introspection is mandatory and cannot be configured REQUIRED_DISTRO_FEATURES =

[OE-core] [PATCH] armv8/tunes: Set TUNE_PKGARCH_64 based on ARMPKGARCH

2020-05-21 Thread Khem Raj
The setting is to modify TUNE_PKGARCH which is filled with TUNE_PKGARCH_64 or TUNE_PKGARCH_32 in arm-arch64.inc This lets higher up tune files for arm64 SOCs override them if needed, this can help building multiple armv8 machines with different tunes in same workspace. No need to set TUNE_PKGARCH

Re: [oe-core][PATCH 1/1] terminal.py: do not stop searching for auto

2020-05-21 Thread Joe Slater
Yes, I think it is what Richard says. But, that's a specific case, and I think that, in general, it would be better to look for something that does work. Like my glorious leader says, "What have you got to lose?" The change does print out a warning, so you can check out what the problem is,

Re: [OE-core] [dunfell][ 08/10] armv8/tunes: Define TUNE_PKGARCH

2020-05-21 Thread Anuj Mittal
On Thu, 2020-05-21 at 17:05 -0700, Khem Raj wrote: > On Thu, May 21, 2020 at 4:49 PM Mittal, Anuj > wrote: > > On Thu, 2020-05-21 at 19:37 +0200, Martin Jansa wrote: > > > On Thu, May 21, 2020 at 6:16 PM Khem Raj > > > wrote: > > > > Now that they uses -mcpu, its better to have tune specific > >

Re: [OE-core] [dunfell][ 08/10] armv8/tunes: Define TUNE_PKGARCH

2020-05-21 Thread Khem Raj
On Thu, May 21, 2020 at 4:49 PM Mittal, Anuj wrote: > > On Thu, 2020-05-21 at 19:37 +0200, Martin Jansa wrote: > > On Thu, May 21, 2020 at 6:16 PM Khem Raj wrote: > > > Now that they uses -mcpu, its better to have tune specific build > > > directories, since aarch64 wont be appropriate any

Re: [OE-core] [dunfell][ 08/10] armv8/tunes: Define TUNE_PKGARCH

2020-05-21 Thread Anuj Mittal
On Thu, 2020-05-21 at 19:37 +0200, Martin Jansa wrote: > On Thu, May 21, 2020 at 6:16 PM Khem Raj wrote: > > Now that they uses -mcpu, its better to have tune specific build > > directories, since aarch64 wont be appropriate any longer > > I agree with Steve that this is a bit invasive for

Re: [oe-core][PATCH 1/1] terminal.py: do not stop searching for auto

2020-05-21 Thread Richard Purdie
On Thu, 2020-05-21 at 15:52 -0400, Randy MacLeod wrote: > On 2020-05-21 2:41 p.m., Joe Slater wrote: > > If a terminal fails to spawn() we should continue looking. > > gnome-terminal, in particular can be present but not start. > > Do you mean that it doesn't start on the first try but that > it

Re: [oe-core][PATCH 1/1] terminal.py: do not stop searching for auto

2020-05-21 Thread Randy MacLeod
On 2020-05-21 2:41 p.m., Joe Slater wrote: If a terminal fails to spawn() we should continue looking. gnome-terminal, in particular can be present but not start. Do you mean that it doesn't start on the first try but that it may / usually does start on subsequent tries? Since the user has

[oe-core][PATCH 1/1] terminal.py: do not stop searching for auto

2020-05-21 Thread Joe Slater
If a terminal fails to spawn() we should continue looking. gnome-terminal, in particular can be present but not start. Signed-off-by: Joe Slater --- meta/lib/oe/terminal.py | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/meta/lib/oe/terminal.py b/meta/lib/oe/terminal.py

Re: [OE-core] [dunfell][ 08/10] armv8/tunes: Define TUNE_PKGARCH

2020-05-21 Thread Martin Jansa
On Thu, May 21, 2020 at 6:16 PM Khem Raj wrote: > Now that they uses -mcpu, its better to have tune specific build > directories, since aarch64 wont be appropriate any longer > I agree with Steve that this is a bit invasive for stable branch, but on the other hand it's long overdue and if we

[OE-core] [PATCH 3/3] qemu: enable virglrenderer and glx options subject to 'opengl' DISTRO_FEATURE

2020-05-21 Thread Alexander Kanavin
Note that to actually use accelerated GL passthrough, there are two options 1) a suitable frontend need to be also enabled - gtk+ and SDL both seem to work well. Previously I struggled to make SDL work, but now it seems fine. 2) it is also possible to render off-screen with -display

[OE-core] [PATCH 1/3] bitbake.conf: propagate 'opengl' DISTRO_FEATURE to native/nativesdk from target

2020-05-21 Thread Alexander Kanavin
This will allow better control over native virgl/qemu configurations. Adjust gtk+3/cairo native configurations to actually ignore opengl when building for -native: we do not need it, and it would cause build failures as only a limited subset of mesa-native is currently built. Drop

[OE-core] [PATCH 2/3] libsdl2: enable opengl option for native/nativesdk, subject to 'opengl' in DISTRO_FEATURES

2020-05-21 Thread Alexander Kanavin
This allows virgl support in qemu with the SDL frontend Signed-off-by: Alexander Kanavin --- meta/recipes-graphics/libsdl2/libsdl2_2.0.12.bb | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-graphics/libsdl2/libsdl2_2.0.12.bb

[OE-core] [dunfell][ 10/10] cve-check: Run it after do_fetch

2020-05-21 Thread Khem Raj
Certain recipes e.g. bash readline ( from meta-gplv2 ) download patches instead of having them in metadata, this could fail cve_check ERROR: readline-5.2-r9 do_cve_check: File Not found: qemuarm/build/../downloads/readline52-001 This patch ensures that download is done before running CVE scan,

[OE-core] [dunfell][ 06/10] tune-cortexa57.inc: Add new tune file

2020-05-21 Thread Khem Raj
Signed-off-by: Khem Raj Signed-off-by: Richard Purdie --- meta/conf/machine/include/tune-cortexa57.inc | 17 + 1 file changed, 17 insertions(+) create mode 100644 meta/conf/machine/include/tune-cortexa57.inc diff --git a/meta/conf/machine/include/tune-cortexa57.inc

[OE-core] [dunfell][ 01/10] tunes: Add new tune files for cortexa55 and cortexa73-cortexa53

2020-05-21 Thread Khem Raj
Signed-off-by: Khem Raj Signed-off-by: Richard Purdie --- meta/conf/machine/include/tune-cortexa55.inc | 17 ++ .../include/tune-cortexa73-cortexa53.inc | 23 +++ 2 files changed, 40 insertions(+) create mode 100644 meta/conf/machine/include/tune-cortexa55.inc

[OE-core] [dunfell][ 09/10] gcc: Do not set -march for arm64 for libatomic

2020-05-21 Thread Khem Raj
libatomic has mind of its own when it comes to setting -march for arm64 which conflicts with -mcpu option we pass from environment in some cases since we always pass -march/-mcpu in OE, its safe to remove this option mcpu removal from cortex-a55 is no longer needed since the option conflict is

[OE-core] [dunfell][ 02/10] gcc-runtime: Avoid march conflicts with newer cortex-a55 CPUs

2020-05-21 Thread Khem Raj
gcc-runtime/libatomic explicitly add -march=armv8-a+lse for all arch64 but cortex-a55 is armv8.2-a, which essentially conflicts, so let gcc override it by not forcing the -mcpu option from TUNE_CCARGS Signed-off-by: Khem Raj Signed-off-by: Richard Purdie ---

[OE-core] [dunfell][ 08/10] armv8/tunes: Define TUNE_PKGARCH

2020-05-21 Thread Khem Raj
Now that they uses -mcpu, its better to have tune specific build directories, since aarch64 wont be appropriate any longer Signed-off-by: Khem Raj Signed-off-by: Richard Purdie --- meta/conf/machine/include/tune-cortexa53.inc | 4 meta/conf/machine/include/tune-cortexa55.inc

[OE-core] [dunfell][ 05/10] tune-cortexa55.inc: crc and crypto extentions are default on cortex-a55

2020-05-21 Thread Khem Raj
Signed-off-by: Khem Raj Signed-off-by: Richard Purdie --- meta/conf/machine/include/tune-cortexa55.inc | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/meta/conf/machine/include/tune-cortexa55.inc b/meta/conf/machine/include/tune-cortexa55.inc index

[OE-core] [dunfell][ 04/10] wayland: fix condition for strndup detection

2020-05-21 Thread Khem Raj
current check does not work with gcc10 Signed-off-by: Khem Raj Signed-off-by: Richard Purdie --- .../0001-build-Fix-strndup-detection-on-MinGW.patch| 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git

[OE-core] [dunfell][ 07/10] aarch64: Adjust big.LITTLE tune files to use -mcpu

2020-05-21 Thread Khem Raj
mcpu is more appropriate on aarch64 and generates more optimized code forr a given SOC, unlike -march/-mtune combination as decribed here [1] [1] https://community.arm.com/developer/tools-software/tools/b/tools-software-ides-blog/posts/compiler-flags-across-architectures-march-mtune-and-mcpu

[OE-core] [dunfell][ 03/10] glibc: Update to latest on 2.31 branch

2020-05-21 Thread Khem Raj
There are few fixes specifically for compiling with gcc10 that are good to have, before hitting them later Backport build fix from master for aarch64 with gcc10 Drop CVE-2020-10029 patch its already applied on latest 2.31 branch latest glibc 2.31 added fix for __getauxval/aarch64 issue

[OE-core] ✗ patchtest: failure for Bump layer version

2020-05-21 Thread Patchwork
== Series Details == Series: Bump layer version Revision: 1 URL : https://patchwork.openembedded.org/series/24255/ 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

Re: [OE-core][PATCH] Bump layer version

2020-05-21 Thread Richard Purdie
On Thu, 2020-05-21 at 10:34 -0500, Joshua Watt wrote: > The commits 910ffaf5be ("pyelftools: Import from meta-python") and > a96f815c53 ("pycryptodome: Import from meta-python") moved recipes > from > meta-python to oe-core. In order for this to be communicated with > users, > bump the

[OE-core][PATCH] Bump layer version

2020-05-21 Thread Joshua Watt
The commits 910ffaf5be ("pyelftools: Import from meta-python") and a96f815c53 ("pycryptodome: Import from meta-python") moved recipes from meta-python to oe-core. In order for this to be communicated with users, bump the LAYERVERSION so that meta-python can key of it in its LAYERDEPENDS.

[OE-core][PATCH] diffoscope: upgrade 143 -> 144

2020-05-21 Thread Joshua Watt
Signed-off-by: Joshua Watt --- .../diffoscope/{diffoscope_143.bb => diffoscope_144.bb} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-support/diffoscope/{diffoscope_143.bb => diffoscope_144.bb} (75%) diff --git

[OE-core][PATCH] python3-magic: upgrade 0.4.15 -> 0.4.18

2020-05-21 Thread Joshua Watt
Signed-off-by: Joshua Watt --- .../{python3-magic_0.4.15.bb => python3-magic_0.4.18.bb} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-devtools/python/{python3-magic_0.4.15.bb => python3-magic_0.4.18.bb} (78%) diff --git

[OE-core] [PATCH] cve-check: Run it after do_fetch

2020-05-21 Thread Khem Raj
Certain recipes e.g. bash readline ( from meta-gplv2 ) download patches instead of having them in metadata, this could fail cve_check ERROR: readline-5.2-r9 do_cve_check: File Not found: qemuarm/build/../downloads/readline52-001 This patch ensures that download is done before running CVE scan,

Re: [OE-core] [OE-Core][PATCH 2/2] rootfs-postcommands: Enable rootfs_check_host_user_contaminated

2020-05-21 Thread Alex Kiernan
Hi Ross On Thu, Jan 2, 2020 at 11:20 PM Ross Burton wrote: > > On 19/12/2019 22:17, Alex Kiernan wrote: > > Enable rootfs_check_host_user_contaminated by default > > Useful check! > > WARNING: Paths in the rootfs are owned by the same user or group as the > user running bitbake. See the logfile

[OE-core] [dunfell][PATCH] file: add bzip2-replacement-native to DEPENDS to fix sstate issue

2020-05-21 Thread Jan-Simon Möller
From: Jan-Simon Moeller file-native when built on a Debian 10 host will embed a dependency to 'libbz2.so.1.0' (instead of 'libbz2.so.1'). This can cause issues when sharing the sstate between hosts e.g.: recipe-sysroot-native/usr/lib/rpm/rpmdeps: error while loading shared libraries:

[OE-core] [PATCH] file: add bzip2-replacement-native to DEPENDS to fix sstate issue

2020-05-21 Thread Jan-Simon Möller
From: Jan-Simon Moeller file-native when built on a Debian 10 host will embed a dependency to 'libbz2.so.1.0' (instead of 'libbz2.so.1'). This can cause issues when sharing the sstate between hosts e.g.: recipe-sysroot-native/usr/lib/rpm/rpmdeps: error while loading shared libraries:

Re: [OE-core] [PATCH] package_ipk.bbclass: print opkg output on error

2020-05-21 Thread Konrad Weihmann
Yeah you're right 244cbcce0ecc4691a9ddfb0a44dc487ff7af0670 should already fix that. The last time I encountered this issue was on thud, where this fix never got applied - so all should be fine, patch can be ignored, as all branches starting from warrior are safe, there is really no need for

Re: [OE-core] [PATCH] package_ipk.bbclass: print opkg output on error

2020-05-21 Thread Richard Purdie
On Wed, 2020-05-20 at 22:17 +0200, Konrad Weihmann wrote: > On a second thought it should be bb.error not bb.fatal - are all > okay with fixing just this one for now? I think the problem here is specific to the way parallelism is done with oe.utils.multiprocess_launch. A quick grep shows a few

[OE-core] [PATCH] multilib/recipes: Use new RecipePostKeyExpansion event

2020-05-21 Thread Richard Purdie
There are issues with multilib due to the ordering of events where some functions see the remapped multilib dependencies and some do not. A significant problem is that the multilib class needs to make some changes before key expansion and some afterwards but by using existing event handlers, some

Re: [OE-core] [PATCH] libsecret: add meson option introspection

2020-05-21 Thread Martin Jansa
If it's no longer mandatory, then please remove: https://github.com/openembedded/openembedded-core/commit/08c86406186828dce19e101adfd118ed5d9e947e together with: # gobject-introspection is mandatory and cannot be configured REQUIRED_DISTRO_FEATURES = "gobject-introspection-data"

Re: [OE-core] [PATCH] devtool: do not write md5sums into upgraded recipes

2020-05-21 Thread Richard Purdie
On Tue, 2020-05-19 at 19:10 +0200, Alexander Kanavin wrote: > This will drop them md5sums from recipes that still have them, > and will not re-add them for recipes where they're already > removed. > > Signed-off-by: Alexander Kanavin > --- > scripts/lib/devtool/upgrade.py | 4 ++-- > 1 file

Re: [OE-core] [PATCH] gettext: upgrade 0.20.1 -> 0.20.2

2020-05-21 Thread Alexander Kanavin
Files supplied by gettext-minimal-native should be refreshed as well (and that recipe bumped to the new version). You can simply copy them from the full 0.20.2 installation. Alex On Thu, 21 May 2020 at 03:29, Wang Mingyu wrote: > rename gettext-0.20.1 to gettext-0.20.2 > >

[OE-core] [PATCH] libsecret: add meson option introspection

2020-05-21 Thread kai
From: Kai Kang Add meson option introspection for libsecret. For bsp which doesn't support qemu usermode, it could disable gobject introspection build. Signed-off-by: Kai Kang --- .../0001-meson-add-option-introspection.patch | 137 ++ .../libsecret/libsecret_0.20.3.bb

Re: [OE-core][PATCH 0/4] Import recipes from meta-python

2020-05-21 Thread Martin Jansa
On Tue, May 19, 2020 at 9:57 PM Andre McCurdy wrote: > On Tue, May 19, 2020 at 11:25 AM Martin Jansa > wrote: > > > > We have discussed this in OE TSC meeting yesterday: > > > https://lists.openembedded.org/g/tsc/topic/openembedded_tsc_meeting/74313532 > > > > tsc suggested to use LAYERVERSION

Re: [OE-core] [PATCH 1/1] archiver.bbclass: Fix duplicated SRC_URIs for do_ar_original

2020-05-21 Thread Richard Purdie
On Wed, 2020-05-20 at 21:05 -0700, Robert Yang wrote: > The argument urls of bb.fetch2.Fetch(urls, d) are duplicated to SRC_URI, > which caused errors like: > > bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression > was ${@bb.fetch2.get_srcrev(d)} which triggered exception

[OE-core] Does OE / Yocto support dts file remove device node /delete-node/?

2020-05-21 Thread JH
Hi, I have a following statement to remove a node in a DTS file: { /delete-node/ fsl,use-minimum-ecc; }; I can build it correctly in OpenWRT build, but I cannot built it correctly in OE / Yocto (Zeus), it did not remove the node fsl,use-minimum-ecc. The u-boot is appended from