Date   

Re: [PATCH v2 2/2] vim: set PACKAGECONFIG idiomatically

Peter Kjellerstedt
 

-----Original Message-----
From: openembedded-core@... <openembedded-
core@...> On Behalf Of Richard Purdie
Sent: den 3 december 2021 11:07
To: Andre McCurdy <armccurdy@...>
Cc: Ross Burton <ross@...>; OE Core mailing list <openembedded-
core@...>
Subject: Re: [OE-core] [PATCH v2 2/2] vim: set PACKAGECONFIG idiomatically

On Fri, 2021-12-03 at 01:39 -0800, Andre McCurdy wrote:
On Wed, Dec 1, 2021 at 2:33 PM Richard Purdie
<richard.purdie@...> wrote:

On Tue, 2021-11-30 at 13:45 -0800, Andre McCurdy wrote:
On Tue, Nov 30, 2021 at 1:20 PM Ross Burton <ross@...>
wrote:

On Tue, 30 Nov 2021 at 19:32, Andre McCurdy <armccurdy@...>
wrote:
This isn't equivalent - it will cause a change in behaviour for
anyone
using PACKAGECONFIG += "foo" from a .bbappend.
Correct, but this is likely the only recipe in the greater
ecosystem
which has this behaviour, so I'm not that bothered to be honest.
:)

The only recipe? There are many recipes which set a default
PACKAGECONFIG with ?= and many which set it with ??=. Your change is
effectively switching the vim recipe from one approach to the other.
The fact that adding PACKAGECONFIG options from a .bbappend with +=
sometimes works OK and sometimes not is a source of confusion for
new
users.

You are right that no one seems to care though...
Some of us very much do care, it is actually bothering me a lot and
I've posted
several times on the architecture list about this kind of issue.

We haven't worked out what we can agree to do about it though :(.
As a first, very easy, step, make a statement here on the mailing list
that all PACKAGECONFIG defaults should be assigned with ?= instead of
??= and fix the recipes in oe-core accordingly.
The question is whether we all agree on that and I'm not sure we all do.
I definitely agree that using "??=" in the recipe for PACKAGECONFIG is
a bad idea. In all our own recipes we use "=" so that is what I would
prefer, but "?=" is ok and it would alleviate the need to use
PACKAGECONFIG:append in bbappends instead of "PACKAGECONFIG +=".

The reason I think "=" is better than "?=" is that if you want to
override the PACKAGECONFIG in a bbappend, using "=" a second time will
work fine, and if you want to do the override in a configuration file
like local.conf, you would use PACKAGECONFIG:pn-foo, which also would
override whatever the recipe set using "=". So unless I am missing a
use case, there really isn't a need to use "?=".

As a second step, the parser could generate a warning (or even an
error) if any variable is assigned to with only ??= and += (the end
result of that combination is not what any user would expect and I
doubt if any legitimate use case relies on it).
Would be interesting to see if there is valid use so it is probably worth
some tests/analysis. The ??= operator never did what I'd hoped it would in
reality sadly.

Cheers,

Richard
//Peter


[PATCH] glew: update patch status

Ross Burton <ross@...>
 

Signed-off-by: Ross Burton <ross.burton@...>
---
.../glew/glew/0001-Fix-build-race-in-Makefile.patch | 2 +-
meta/recipes-graphics/glew/glew/no-strip.patch | 2 +-
meta/recipes-graphics/glew/glew/notempdir.patch | 2 ++
3 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-graphics/glew/glew/0001-Fix-build-race-in-Makef=
ile.patch b/meta/recipes-graphics/glew/glew/0001-Fix-build-race-in-Makefi=
le.patch
index 7edcfe8de8..2418646689 100644
--- a/meta/recipes-graphics/glew/glew/0001-Fix-build-race-in-Makefile.pat=
ch
+++ b/meta/recipes-graphics/glew/glew/0001-Fix-build-race-in-Makefile.pat=
ch
@@ -1,4 +1,4 @@
-Upstream-Status: Submitted [https://github.com/nigels-com/glew/pull/311]
+Upstream-Status: Backport [767e0316450911f1158bd4f7fd8dcd066bae5c55]
Signed-off-by: Ross Burton <ross.burton@...>
=20
From 0ce0a85597db48a2fca619bd95e34af091e54ae8 Mon Sep 17 00:00:00 2001
diff --git a/meta/recipes-graphics/glew/glew/no-strip.patch b/meta/recipe=
s-graphics/glew/glew/no-strip.patch
index e411f11cb5..5708d93082 100644
--- a/meta/recipes-graphics/glew/glew/no-strip.patch
+++ b/meta/recipes-graphics/glew/glew/no-strip.patch
@@ -1,7 +1,7 @@
Don't forcibly strip the binaries.
=20
Signed-off-by: Ross Burton <ross.burton@...>
-Upstream-Status: Pending
+Upstream-Status: Backport [d7693eea09ac76c67f5f3aa538bb911ce2291e2c]
=20
diff --git a/Makefile b/Makefile
index 6a9803c..170c0ce 100644
diff --git a/meta/recipes-graphics/glew/glew/notempdir.patch b/meta/recip=
es-graphics/glew/glew/notempdir.patch
index 8d79ce0cdf..68b46b6641 100644
--- a/meta/recipes-graphics/glew/glew/notempdir.patch
+++ b/meta/recipes-graphics/glew/glew/notempdir.patch
@@ -2,6 +2,8 @@ We don't use the dist-* targets and hence DIST_DIR isn't =
used. The current code
creates a new temp directory in /tmp/ for every invocation of make. Lets
not do that.
=20
+https://github.com/nigels-com/glew/issues/334
+
Upstream-Status: Pending [a revised version would be needed for upstream=
]
Signed-off-by: Richard Purdie <richard.purdie@...>
=20
--=20
2.25.1


Re: [dunfell][PATCH] cmake: FindGTest: Add target for gmock library

Eero Aaltonen
 

On Tue, 2021-11-30 at 15:23 +0200, Eero Aaltonen via
lists.openembedded.org wrote:

Update `Modules/FindGTest.cmake` to provide the same targets as the
CMake Config-file Package and backwards compatible targets and result
variables.
Bump.

The googletest recipe at meta-oe dunfell branch is for version 1.10.
The fact that CMake Find Module masked the targets of the GTest package
resulted in a number of very confusing build failures.

This patch is mostly about backporting the fixed forwarding behaviour
from the Find Module to the Config-file Package that was released in
CMake v3.20.0.

--
Eero Aaltonen


[Isar] bbclass for Debian

Mickaël Delanoë
 

Hello,

I try to adapt my personal Yocto meta to Isar Project.

Currently, I try to add "minimalmodbus" recipie, and for this, I need "python-pyserial".
And for "python-pyserial" I need "setutools3"
inherit setuptools3

So I added "setuptools3.bbclass" on my project. But after this, I need other and other classes...

And I asked myself if I use the right ".bbclass" from the right "openembedded-core" branch.

In fact, as I worked with Krogoth distrimution to my previous Yocto Project, I used bbclass from this branch too for my new Isar Project. But Isar is based to Debian so it's maybe not the right way...

Do you know which branch I should used for compatible with Debian distribution ?

Best Regards,
--
Mickaël Delanoë
Ingénieur d'études | Design Engineer
T. +33 (0)5 87 03 80 58
E. mickael.delanoe@...
A. 31 rue du Châtenet 87410 Le Palais-sur-Vienne


Re: [PATCH v2 2/2] vim: set PACKAGECONFIG idiomatically

Richard Purdie
 

On Fri, 2021-12-03 at 01:39 -0800, Andre McCurdy wrote:
On Wed, Dec 1, 2021 at 2:33 PM Richard Purdie
<richard.purdie@...> wrote:

On Tue, 2021-11-30 at 13:45 -0800, Andre McCurdy wrote:
On Tue, Nov 30, 2021 at 1:20 PM Ross Burton <ross@...> wrote:

On Tue, 30 Nov 2021 at 19:32, Andre McCurdy <armccurdy@...> wrote:
This isn't equivalent - it will cause a change in behaviour for anyone
using PACKAGECONFIG += "foo" from a .bbappend.
Correct, but this is likely the only recipe in the greater ecosystem
which has this behaviour, so I'm not that bothered to be honest. :)
The only recipe? There are many recipes which set a default
PACKAGECONFIG with ?= and many which set it with ??=. Your change is
effectively switching the vim recipe from one approach to the other.
The fact that adding PACKAGECONFIG options from a .bbappend with +=
sometimes works OK and sometimes not is a source of confusion for new
users.

You are right that no one seems to care though...
Some of us very much do care, it is actually bothering me a lot and I've posted
several times on the architecture list about this kind of issue.

We haven't worked out what we can agree to do about it though :(.
As a first, very easy, step, make a statement here on the mailing list
that all PACKAGECONFIG defaults should be assigned with ?= instead of
??= and fix the recipes in oe-core accordingly.
The question is whether we all agree on that and I'm not sure we all do.

As a second step, the parser could generate a warning (or even an
error) if any variable is assigned to with only ??= and += (the end
result of that combination is not what any user would expect and I
doubt if any legitimate use case relies on it).
Would be interesting to see if there is valid use so it is probably worth some
tests/analysis. The ??= operator never did what I'd hoped it would in reality
sadly.

Cheers,

Richard


Re: [PATCH v2 2/2] vim: set PACKAGECONFIG idiomatically

Andre McCurdy
 

On Wed, Dec 1, 2021 at 2:33 PM Richard Purdie
<richard.purdie@...> wrote:

On Tue, 2021-11-30 at 13:45 -0800, Andre McCurdy wrote:
On Tue, Nov 30, 2021 at 1:20 PM Ross Burton <ross@...> wrote:

On Tue, 30 Nov 2021 at 19:32, Andre McCurdy <armccurdy@...> wrote:
This isn't equivalent - it will cause a change in behaviour for anyone
using PACKAGECONFIG += "foo" from a .bbappend.
Correct, but this is likely the only recipe in the greater ecosystem
which has this behaviour, so I'm not that bothered to be honest. :)
The only recipe? There are many recipes which set a default
PACKAGECONFIG with ?= and many which set it with ??=. Your change is
effectively switching the vim recipe from one approach to the other.
The fact that adding PACKAGECONFIG options from a .bbappend with +=
sometimes works OK and sometimes not is a source of confusion for new
users.

You are right that no one seems to care though...
Some of us very much do care, it is actually bothering me a lot and I've posted
several times on the architecture list about this kind of issue.

We haven't worked out what we can agree to do about it though :(.
As a first, very easy, step, make a statement here on the mailing list
that all PACKAGECONFIG defaults should be assigned with ?= instead of
??= and fix the recipes in oe-core accordingly.

As a second step, the parser could generate a warning (or even an
error) if any variable is assigned to with only ??= and += (the end
result of that combination is not what any user would expect and I
doubt if any legitimate use case relies on it).


Re: [PATCH 1/2] sstate: don't limit the thread pool size when checking mirrors

Jose Quaresma
 



Richard Purdie <richard.purdie@...> escreveu no dia quinta, 2/12/2021 à(s) 23:16:
On Thu, 2021-12-02 at 22:05 +0000, Jose Quaresma wrote:
> This improves the time needed to check the mirrors,
> reducing it from 50s to 8s when building the core-image-minimal
> using the yocto upstream sstate and hashequivlance servers
> on a machine with 8 cpu cores.
>
> Tested with:
>
>  SSTATE_MIRRORS = "file://.* http://sstate.yoctoproject.org/dev/PATH;downloadfilename=PATH"
>  BB_HASHSERVE_UPSTREAM = "typhoon.yocto.io:8687"
>  bitbake core-image-minimal
>
> Signed-off-by: Jose Quaresma <quaresma.jose@...>
> ---
>  meta/classes/sstate.bbclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
> index 0326d27c74..5e404d7cd8 100644
> --- a/meta/classes/sstate.bbclass
> +++ b/meta/classes/sstate.bbclass
> @@ -1005,7 +1005,7 @@ def sstate_checkhashes(sq_data, d, siginfo=False, currentcount=0, summary=True,
>              tasklist.append((tid, sstatefile))

>          if tasklist:
> -            nproc = min(int(d.getVar("BB_NUMBER_THREADS")), len(tasklist))
> +            nproc = len(tasklist)

>              progress = len(tasklist) >= 100
>              if progress:

No, we're not doing that. That opens a ton (thousands) of parallel connections
to the servers and isn't fair on the systems hosting the data. In many cases
that would look like a DoS attack.

Cheers,

Richard




Got it and I have to agree that it will launch a DoS to the server.
However there are some cases around that have the mirror hosted locally on the file system.
I'll try to find a solution that doesn't affect the http mirror.

--
Best regards,

José Quaresma


[PATCH] mesa: Fix build on ARM systems without Neon

Khem Raj
 

See [1]

[1] https://github.com/YoeDistro/yoe-distro/issues/626

Signed-off-by: Khem Raj <raj.khem@...>
Cc: Ross Burton <ross.burton@...>
---
...ormat-Check-for-NEON-before-using-it.patch | 49 +++++++++++++++++++
meta/recipes-graphics/mesa/mesa.inc | 1 +
2 files changed, 50 insertions(+)
create mode 100644 meta/recipes-graphics/mesa/files/0001-util-format-Check-for-NEON-before-using-it.patch

diff --git a/meta/recipes-graphics/mesa/files/0001-util-format-Check-for-NEON-before-using-it.patch b/meta/recipes-graphics/mesa/files/0001-util-format-Check-for-NEON-before-using-it.patch
new file mode 100644
index 00000000000..80b9af08e8f
--- /dev/null
+++ b/meta/recipes-graphics/mesa/files/0001-util-format-Check-for-NEON-before-using-it.patch
@@ -0,0 +1,49 @@
+From 4febda271c6bb0dc69ebf573446c6922a1ec35fb Mon Sep 17 00:00:00 2001
+From: Khem Raj <raj.khem@...>
+Date: Thu, 2 Dec 2021 19:57:42 -0800
+Subject: [PATCH] util/format: Check for NEON before using it
+
+This fixes build on rpi0-w and any other machine which does not have
+neon unit and is not used as FPU unit
+
+Fixes errors e.g.
+
+In file included from ../mesa-21.3.0/src/util/format/u_format_unpack_neon.c:35:
+/mnt/b/yoe/master/build/tmp/work/arm1176jzfshf-vfp-yoe-linux-gnueabi/mesa/2_21.3.0-r0/recipe-sysroot-native/usr/lib/clang/13.0.1/include/arm_neon.h:32:2: error: "NEON support not enabled"
+
+Upstream-Status: Submitted [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14032]
+Signed-off-by: Khem Raj <raj.khem@...>
+---
+ src/util/format/u_format.c | 2 +-
+ src/util/format/u_format_unpack_neon.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/util/format/u_format.c b/src/util/format/u_format.c
+index 36c5e52008e..f0a00971691 100644
+--- a/src/util/format/u_format.c
++++ b/src/util/format/u_format.c
+@@ -1138,7 +1138,7 @@ static void
+ util_format_unpack_table_init(void)
+ {
+ for (enum pipe_format format = PIPE_FORMAT_NONE; format < PIPE_FORMAT_COUNT; format++) {
+-#if (defined(PIPE_ARCH_AARCH64) || defined(PIPE_ARCH_ARM)) && !defined(NO_FORMAT_ASM) && !defined(__SOFTFP__)
++#if (defined(PIPE_ARCH_AARCH64) || (defined(__ARM_NEON) && defined(PIPE_ARCH_ARM))) && !defined(NO_FORMAT_ASM)
+ const struct util_format_unpack_description *unpack = util_format_unpack_description_neon(format);
+ if (unpack) {
+ util_format_unpack_table[format] = unpack;
+diff --git a/src/util/format/u_format_unpack_neon.c b/src/util/format/u_format_unpack_neon.c
+index a4a5cb1f723..1e4f794a295 100644
+--- a/src/util/format/u_format_unpack_neon.c
++++ b/src/util/format/u_format_unpack_neon.c
+@@ -23,7 +23,7 @@
+
+ #include <u_format.h>
+
+-#if (defined(PIPE_ARCH_AARCH64) || defined(PIPE_ARCH_ARM)) && !defined(NO_FORMAT_ASM) && !defined(__SOFTFP__)
++#if (defined(PIPE_ARCH_AARCH64) || (defined(__ARM_NEON) && defined(PIPE_ARCH_ARM))) && !defined(NO_FORMAT_ASM)
+
+ /* armhf builds default to vfp, not neon, and refuses to compile neon intrinsics
+ * unless you tell it "no really".
+--
+2.34.1
+
diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc
index ed60d982504..30b9e93f630 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -19,6 +19,7 @@ SRC_URI = "https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz \
file://0002-meson.build-make-TLS-ELF-optional.patch \
file://0001-meson-misdetects-64bit-atomics-on-mips-clang.patch \
file://0001-futex.h-Define-__NR_futex-if-it-does-not-exist.patch \
+ file://0001-util-format-Check-for-NEON-before-using-it.patch \
"

SRC_URI[sha256sum] = "a2753c09deef0ba14d35ae8a2ceff3fe5cd13698928c7bb62c2ec8736eb09ce1"
--
2.34.1


Re: [PATCH 1/2] sstate: don't limit the thread pool size when checking mirrors

Richard Purdie
 

On Thu, 2021-12-02 at 22:05 +0000, Jose Quaresma wrote:
This improves the time needed to check the mirrors,
reducing it from 50s to 8s when building the core-image-minimal
using the yocto upstream sstate and hashequivlance servers
on a machine with 8 cpu cores.

Tested with:

SSTATE_MIRRORS = "file://.* http://sstate.yoctoproject.org/dev/PATH;downloadfilename=PATH"
BB_HASHSERVE_UPSTREAM = "typhoon.yocto.io:8687"
bitbake core-image-minimal

Signed-off-by: Jose Quaresma <quaresma.jose@...>
---
meta/classes/sstate.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index 0326d27c74..5e404d7cd8 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -1005,7 +1005,7 @@ def sstate_checkhashes(sq_data, d, siginfo=False, currentcount=0, summary=True,
tasklist.append((tid, sstatefile))

if tasklist:
- nproc = min(int(d.getVar("BB_NUMBER_THREADS")), len(tasklist))
+ nproc = len(tasklist)

progress = len(tasklist) >= 100
if progress:
No, we're not doing that. That opens a ton (thousands) of parallel connections
to the servers and isn't fair on the systems hosting the data. In many cases
that would look like a DoS attack.

Cheers,

Richard


[PATCH] glslang: upgrade 11.7.0 -> 11.7.1

Jose Quaresma
 

changelog:
1f8c8b88 Revert port of GL_EXT_shader_realtime_clock to GL_EXT_spirv_intrinsics

Signed-off-by: Jose Quaresma <quaresma.jose@...>
---
.../glslang/{glslang_11.7.0.bb => glslang_11.7.1.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-graphics/glslang/{glslang_11.7.0.bb => glslang_11.7.1.bb} (95%)

diff --git a/meta/recipes-graphics/glslang/glslang_11.7.0.bb b/meta/recipes-graphics/glslang/glslang_11.7.1.bb
similarity index 95%
rename from meta/recipes-graphics/glslang/glslang_11.7.0.bb
rename to meta/recipes-graphics/glslang/glslang_11.7.1.bb
index 0b4bf21bca..30d9954ea5 100644
--- a/meta/recipes-graphics/glslang/glslang_11.7.0.bb
+++ b/meta/recipes-graphics/glslang/glslang_11.7.1.bb
@@ -8,7 +8,7 @@ HOMEPAGE = "https://www.khronos.org/opengles/sdk/tools/Reference-Compiler"
LICENSE = "BSD-3-Clause & BSD-2-Clause & MIT & Apache-2.0 & GPL-3-with-bison-exception"
LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=c5ce49c0456e9b413b98a4368c378229"

-SRCREV = "925503088e2bcd76921b1e102c37fc320bace254"
+SRCREV = "c9706bdda0ac22b9856f1aa8261e5b9e15cd20c5"
SRC_URI = "git://github.com/KhronosGroup/glslang.git;protocol=https;branch=master \
file://0001-generate-glslang-pkg-config.patch"
UPSTREAM_CHECK_GITTAGREGEX = "^(?P<pver>\d+(\.\d+)+)$"
--
2.34.1


[PATCH 2/2] sstate: use nproc for tasklist size on mirrors

Jose Quaresma
 

Signed-off-by: Jose Quaresma <quaresma.jose@...>
---
meta/classes/sstate.bbclass | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index 5e404d7cd8..9efd334a59 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -997,7 +997,7 @@ def sstate_checkhashes(sq_data, d, siginfo=False, currentcount=0, summary=True,
bb.error("SState: cannot test %s: %s" % (srcuri, e))

if progress:
- bb.event.fire(bb.event.ProcessProgress(msg, len(tasklist) - thread_worker.tasks.qsize()), d)
+ bb.event.fire(bb.event.ProcessProgress(msg, nproc - thread_worker.tasks.qsize()), d)

tasklist = []
for tid in missed:
@@ -1007,13 +1007,13 @@ def sstate_checkhashes(sq_data, d, siginfo=False, currentcount=0, summary=True,
if tasklist:
nproc = len(tasklist)

- progress = len(tasklist) >= 100
+ progress = nproc >= 100
if progress:
msg = "Checking sstate mirror object availability"
- bb.event.fire(bb.event.ProcessStarted(msg, len(tasklist)), d)
+ bb.event.fire(bb.event.ProcessStarted(msg, nproc), d)

bb.event.enable_threadlock()
- pool = oe.utils.ThreadedPool(nproc, len(tasklist),
+ pool = oe.utils.ThreadedPool(nproc, nproc,
worker_init=checkstatus_init, worker_end=checkstatus_end,
name="sstate_checkhashes-")
for t in tasklist:
--
2.34.1


[PATCH 1/2] sstate: don't limit the thread pool size when checking mirrors

Jose Quaresma
 

This improves the time needed to check the mirrors,
reducing it from 50s to 8s when building the core-image-minimal
using the yocto upstream sstate and hashequivlance servers
on a machine with 8 cpu cores.

Tested with:

SSTATE_MIRRORS = "file://.* http://sstate.yoctoproject.org/dev/PATH;downloadfilename=PATH"
BB_HASHSERVE_UPSTREAM = "typhoon.yocto.io:8687"
bitbake core-image-minimal

Signed-off-by: Jose Quaresma <quaresma.jose@...>
---
meta/classes/sstate.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index 0326d27c74..5e404d7cd8 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -1005,7 +1005,7 @@ def sstate_checkhashes(sq_data, d, siginfo=False, currentcount=0, summary=True,
tasklist.append((tid, sstatefile))

if tasklist:
- nproc = min(int(d.getVar("BB_NUMBER_THREADS")), len(tasklist))
+ nproc = len(tasklist)

progress = len(tasklist) >= 100
if progress:
--
2.34.1


Re: [PATCH] tune-cortexa72.inc: Add tune for nocrypto case

Khem Raj
 

On Thu, Dec 2, 2021 at 1:32 PM Peter Kjellerstedt
<peter.kjellerstedt@...> wrote:

-----Original Message-----
From: openembedded-core@... <openembedded-core@...> On Behalf Of Khem Raj
Sent: den 2 december 2021 21:21
To: openembedded-core@...
Cc: Khem Raj <raj.khem@...>
Subject: [OE-core] [PATCH] tune-cortexa72.inc: Add tune for nocrypto case

RPI4 based on BCM2711 soc which does not enable AES extentions
in hardware see [1] fixes [2]

[1] https://forums.raspberrypi.com/viewtopic.php?t=207888&start=25#p1642862
[2] https://github.com/agherzan/meta-raspberrypi/issues/964

[YOCTO #14641]

Signed-off-by: Khem Raj <raj.khem@...>
---
meta/conf/machine/include/arm/armv8a/tune-cortexa72.inc | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/meta/conf/machine/include/arm/armv8a/tune-cortexa72.inc b/meta/conf/machine/include/arm/armv8a/tune-cortexa72.inc
index 2a510bd45bd..b2eb35f111b 100644
--- a/meta/conf/machine/include/arm/armv8a/tune-cortexa72.inc
+++ b/meta/conf/machine/include/arm/armv8a/tune-cortexa72.inc
@@ -6,8 +6,14 @@ TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa72', ' -mcpu=corte
require conf/machine/include/arm/arch-armv8a.inc

# Little Endian base configs
-AVAILTUNES += "cortexa72"
+AVAILTUNES += "cortexa72 cortexa72-nocrypto"
ARMPKGARCH:tune-cortexa72 = "cortexa72"
TUNE_FEATURES:tune-cortexa72 = "${TUNE_FEATURES:tune-armv8a-crc-crypto} cortexa72"
PACKAGE_EXTRA_ARCHS:tune-cortexa72 = "${PACKAGE_EXTRA_ARCHS:tune-armv8a-crc-crypto} cortexa72"
BASE_LIB:tune-cortexa72 = "lib64"
+
+# Some implementations do not enabled crypto ( e.g. BCM2837B0 in rpi4 )
+ARMPKGARCH:tune-cortexa72-nocrypto = "cortexa72"
+TUNE_FEATURES:tune-cortexa72-nocrypto = "${TUNE_FEATURES:tune-armv8a-crc} cortexa72"
+PACKAGE_EXTRA_ARCHS:tune-cortexa72-nocrypto = "${PACKAGE_EXTRA_ARCHS:tune-armv8a-crc} cortexa72"
+BASE_LIB:tune-cortexa72-nocrypto = "lib64"
--
2.34.1
I do realize renaming cortexa72 to cortexa72-crypto would not be backwards
compatible, but is it really a good idea to introduce a name like this
that does not follow the naming other tunes use?
yeah I thought about it but its an exception than norm. We also have
novfp usecases.


//Peter


Re: [PATCH] tune-cortexa72.inc: Add tune for nocrypto case

Peter Kjellerstedt
 

-----Original Message-----
From: openembedded-core@... <openembedded-core@...> On Behalf Of Khem Raj
Sent: den 2 december 2021 21:21
To: openembedded-core@...
Cc: Khem Raj <raj.khem@...>
Subject: [OE-core] [PATCH] tune-cortexa72.inc: Add tune for nocrypto case

RPI4 based on BCM2711 soc which does not enable AES extentions
in hardware see [1] fixes [2]

[1] https://forums.raspberrypi.com/viewtopic.php?t=207888&start=25#p1642862
[2] https://github.com/agherzan/meta-raspberrypi/issues/964

[YOCTO #14641]

Signed-off-by: Khem Raj <raj.khem@...>
---
meta/conf/machine/include/arm/armv8a/tune-cortexa72.inc | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/meta/conf/machine/include/arm/armv8a/tune-cortexa72.inc b/meta/conf/machine/include/arm/armv8a/tune-cortexa72.inc
index 2a510bd45bd..b2eb35f111b 100644
--- a/meta/conf/machine/include/arm/armv8a/tune-cortexa72.inc
+++ b/meta/conf/machine/include/arm/armv8a/tune-cortexa72.inc
@@ -6,8 +6,14 @@ TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa72', ' -mcpu=corte
require conf/machine/include/arm/arch-armv8a.inc

# Little Endian base configs
-AVAILTUNES += "cortexa72"
+AVAILTUNES += "cortexa72 cortexa72-nocrypto"
ARMPKGARCH:tune-cortexa72 = "cortexa72"
TUNE_FEATURES:tune-cortexa72 = "${TUNE_FEATURES:tune-armv8a-crc-crypto} cortexa72"
PACKAGE_EXTRA_ARCHS:tune-cortexa72 = "${PACKAGE_EXTRA_ARCHS:tune-armv8a-crc-crypto} cortexa72"
BASE_LIB:tune-cortexa72 = "lib64"
+
+# Some implementations do not enabled crypto ( e.g. BCM2837B0 in rpi4 )
+ARMPKGARCH:tune-cortexa72-nocrypto = "cortexa72"
+TUNE_FEATURES:tune-cortexa72-nocrypto = "${TUNE_FEATURES:tune-armv8a-crc} cortexa72"
+PACKAGE_EXTRA_ARCHS:tune-cortexa72-nocrypto = "${PACKAGE_EXTRA_ARCHS:tune-armv8a-crc} cortexa72"
+BASE_LIB:tune-cortexa72-nocrypto = "lib64"
--
2.34.1
I do realize renaming cortexa72 to cortexa72-crypto would not be backwards
compatible, but is it really a good idea to introduce a name like this
that does not follow the naming other tunes use?

//Peter


Re: [PATCH] distutils3: fix bindir mangling to stop breaking symlinks

Ross Burton <ross@...>
 

I've not looked at that series yet (the Summit is eating time) but if
it does the same logic then yes.

Ross

On Thu, 2 Dec 2021 at 17:31, Konrad Weihmann <kweihmann@...> wrote:



On 02.12.21 18:17, Ross Burton wrote:
distutils3_do_install wants to sed out build directory references from
all binaries in ${bindir} and ${sbindir}. It tries to avoid touching
symlinks by doing 'test -f' on the files as it iterates, but test always
dereferences symlinks so this will touch both real files and symlinks to
real files.

The end result of this is that recipes which ship a script /usr/bin/foo
and a symlink /usr/bin/bar -> foo, bar will be replaced with a real file
which is a duplicate of foo, wasting disk space.

Replace the loop with a find loop which can look at the real file type,
not the target type.

Signed-off-by: Ross Burton <ross.burton@...>
---
meta/classes/distutils3.bbclass | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/meta/classes/distutils3.bbclass b/meta/classes/distutils3.bbclass
index be645d37bd..0973d304f4 100644
--- a/meta/classes/distutils3.bbclass
+++ b/meta/classes/distutils3.bbclass
@@ -43,11 +43,9 @@ distutils3_do_install() {
find ${D} -name "*.py" -exec grep -q ${D} {} \; \
-exec sed -i -e s:${D}::g {} \;

- for i in ${D}${bindir}/* ${D}${sbindir}/*; do
- if [ -f "$i" ]; then
- sed -i -e s:${PYTHON}:${USRBINPATH}/env\ ${DISTUTILS_PYTHON}:g $i
- sed -i -e s:${STAGING_BINDIR_NATIVE}:${bindir}:g $i
- fi
+ for bin in $(find ${D}${bindir} ${D}${sbindir} -type f -maxdepth 1); do
+ sed -i -e s:${PYTHON}:${USRBINPATH}/env\ ${DISTUTILS_PYTHON}:g $bin
+ sed -i -e s:${STAGING_BINDIR_NATIVE}:${bindir}:g $bin
Does the same also apply to setuptools as in Tim's distutils deprecation
series?
If so it should definitely we be merged there

done

rm -f ${D}${PYTHON_SITEPACKAGES_DIR}/easy-install.pth





[PATCH] tune-cortexa72.inc: Add tune for nocrypto case

Khem Raj
 

RPI4 based on BCM2711 soc which does not enable AES extentions
in hardware see [1] fixes [2]

[1] https://forums.raspberrypi.com/viewtopic.php?t=207888&start=25#p1642862
[2] https://github.com/agherzan/meta-raspberrypi/issues/964

[YOCTO #14641]

Signed-off-by: Khem Raj <raj.khem@...>
---
meta/conf/machine/include/arm/armv8a/tune-cortexa72.inc | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/meta/conf/machine/include/arm/armv8a/tune-cortexa72.inc b/meta/conf/machine/include/arm/armv8a/tune-cortexa72.inc
index 2a510bd45bd..b2eb35f111b 100644
--- a/meta/conf/machine/include/arm/armv8a/tune-cortexa72.inc
+++ b/meta/conf/machine/include/arm/armv8a/tune-cortexa72.inc
@@ -6,8 +6,14 @@ TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa72', ' -mcpu=corte
require conf/machine/include/arm/arch-armv8a.inc

# Little Endian base configs
-AVAILTUNES += "cortexa72"
+AVAILTUNES += "cortexa72 cortexa72-nocrypto"
ARMPKGARCH:tune-cortexa72 = "cortexa72"
TUNE_FEATURES:tune-cortexa72 = "${TUNE_FEATURES:tune-armv8a-crc-crypto} cortexa72"
PACKAGE_EXTRA_ARCHS:tune-cortexa72 = "${PACKAGE_EXTRA_ARCHS:tune-armv8a-crc-crypto} cortexa72"
BASE_LIB:tune-cortexa72 = "lib64"
+
+# Some implementations do not enabled crypto ( e.g. BCM2837B0 in rpi4 )
+ARMPKGARCH:tune-cortexa72-nocrypto = "cortexa72"
+TUNE_FEATURES:tune-cortexa72-nocrypto = "${TUNE_FEATURES:tune-armv8a-crc} cortexa72"
+PACKAGE_EXTRA_ARCHS:tune-cortexa72-nocrypto = "${PACKAGE_EXTRA_ARCHS:tune-armv8a-crc} cortexa72"
+BASE_LIB:tune-cortexa72-nocrypto = "lib64"
--
2.34.1


Re: [dunfell][PATCH] go-helloworld: test at runtime

Steve Sakoman
 

On Thu, Dec 2, 2021 at 1:21 AM Alexander Kanavin <alex.kanavin@...> wrote:

From: Alexander Kanavin <alex.kanavin@...>

This adds a smoke check for whether the Go toolchain actually
produces working executables across a range of architectures.
I'm getting a failure during autobuilder testing (qemuarm64-ptest):

DEBUG: Executing shell function do_configure
# Building C bootstrap tool.
cmd/dist
go tool dist: unknown architecture: aarch64
WARNING: exit code 1 from a shell command.
ERROR: Execution of
'TOPDIR/tmp/work/aarch64-linux/go-native/1.14.15-r0/temp/run.do_configure.318086'
failed with exit code 1

https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/2609

Steve

(From OE-Core rev: 2819bb2cf22c6cfcaeaee79f0280097ec9cb9327)

Signed-off-by: Alexander Kanavin <alex@...>
Signed-off-by: Richard Purdie <richard.purdie@...>
---
meta/classes/testimage.bbclass | 2 +-
meta/lib/oeqa/runtime/cases/go.py | 19 +++++++++++++++++++
.../packagegroup-core-tools-testapps.bb | 7 +++++++
3 files changed, 27 insertions(+), 1 deletion(-)
create mode 100644 meta/lib/oeqa/runtime/cases/go.py

diff --git a/meta/classes/testimage.bbclass b/meta/classes/testimage.bbclass
index b1aef626f7..80c19b1e60 100644
--- a/meta/classes/testimage.bbclass
+++ b/meta/classes/testimage.bbclass
@@ -58,7 +58,7 @@ BASICTESTSUITE = "\
ping date df ssh scp python perl gi ptest parselogs \
logrotate connman systemd oe_syslog pam stap ldd xorg \
kernelmodule gcc buildcpio buildlzip buildgalculator \
- dnf rpm opkg apt weston"
+ dnf rpm opkg apt weston go"

DEFAULT_TEST_SUITES = "${BASICTESTSUITE}"

diff --git a/meta/lib/oeqa/runtime/cases/go.py b/meta/lib/oeqa/runtime/cases/go.py
new file mode 100644
index 0000000000..89ba2c3ecb
--- /dev/null
+++ b/meta/lib/oeqa/runtime/cases/go.py
@@ -0,0 +1,19 @@
+#
+# SPDX-License-Identifier: MIT
+#
+
+from oeqa.runtime.case import OERuntimeTestCase
+from oeqa.core.decorator.depends import OETestDepends
+from oeqa.runtime.decorator.package import OEHasPackage
+
+class GoHelloworldTest(OERuntimeTestCase):
+ @OETestDepends(['ssh.SSHTest.test_ssh'])
+ @OEHasPackage(['go-helloworld'])
+ def test_gohelloworld(self):
+ cmd = "go-helloworld"
+ status, output = self.target.run(cmd)
+ msg = 'Exit status was not 0. Output: %s' % output
+ self.assertEqual(status, 0, msg=msg)
+
+ msg = 'Incorrect output: %s' % output
+ self.assertEqual(output, "Hello, Go examples!", msg=msg)
diff --git a/meta/recipes-core/packagegroups/packagegroup-core-tools-testapps.bb b/meta/recipes-core/packagegroups/packagegroup-core-tools-testapps.bb
index a5fc152859..3c946c57ef 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-tools-testapps.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-tools-testapps.bb
@@ -17,6 +17,12 @@ KEXECTOOLS_microblaze ?= ""
KEXECTOOLS_nios2 ?= ""
KEXECTOOLS_riscv64 ?= ""

+# go does not support ppc32, only ppc64
+# https://github.com/golang/go/issues/22885
+# gccgo may do better
+GOTOOLS ?= "go-helloworld"
+GOTOOLS:powerpc ?= ""
+
GSTEXAMPLES ?= "gst-examples"
GSTEXAMPLES_riscv64 = ""

@@ -48,4 +54,5 @@ RDEPENDS_${PN} = "\
${@bb.utils.contains('DISTRO_FEATURES', 'x11', "${X11TOOLS}", "", d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', "${X11GLTOOLS}", "", d)} \
${@bb.utils.contains('DISTRO_FEATURES', '3g', "${3GTOOLS}", "", d)} \
+ ${GOTOOLS} \
"
--
2.20.1




OpenEmbedded Developer Virtual Meeting (OEDVM) - Tomorrow

Jon Mason
 

Reminder

There will be an OpenEmbedded Developer Virtual Meeting (OEDVM) held
tomorrow (Friday, 03 December 2021)

The scheduled time will match the YP Summit's start at 12 UTC/7AM
Eastern, and run until 20 UTC/3PM (or earlier if we run out of topics,
but then will most likely turn into a happy hour).

We will be using Automotive Grade Linux's Zoom (and many thanks to AGL
for this!)
https://zoom.us/j/99151508871

There current topics of discussion are listed at:
https://www.openembedded.org/wiki/OEDVM_Nov_2021

There will be no given order, but priority will be given to topics
with moderators. If you want to add something to the list, please do
so as soon as possible.

If there is a topic you would like to comment on but have difficulties
at given times, please comment on Libera IRC at #oe (or respond to
this email if you are lacking IRC access). No promises given but we
will do our best to accommodate.

Please forward this email to anyone who might be interested.

As always, if you are not an OpenEmbedded Member (but are interested
in joining), please attend OEDVM and you can be voted in.

If there are any questions, please feel free to email me and/or the
entire OE board (board@...).

Thanks,
Jon


[PATCH] perf: Enable libunwind packageconfig on riscv64

Khem Raj
 

libunwind now supports risc64

Signed-off-by: Khem Raj <raj.khem@...>
---
meta/recipes-kernel/perf/perf.bb | 1 -
1 file changed, 1 deletion(-)

diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
index f473272096f..7bbc1ad70c5 100644
--- a/meta/recipes-kernel/perf/perf.bb
+++ b/meta/recipes-kernel/perf/perf.bb
@@ -31,7 +31,6 @@ PACKAGECONFIG[coresight] = "CORESIGHT=1,,opencsd"

# libunwind is not yet ported for some architectures
PACKAGECONFIG:remove:arc = "libunwind"
-PACKAGECONFIG:remove:riscv64 = "libunwind"
PACKAGECONFIG:remove:riscv32 = "libunwind"

DEPENDS = " \
--
2.34.1


Re: [PATCH] distutils3: fix bindir mangling to stop breaking symlinks

Konrad Weihmann <kweihmann@...>
 

On 02.12.21 18:17, Ross Burton wrote:
distutils3_do_install wants to sed out build directory references from
all binaries in ${bindir} and ${sbindir}. It tries to avoid touching
symlinks by doing 'test -f' on the files as it iterates, but test always
dereferences symlinks so this will touch both real files and symlinks to
real files.
The end result of this is that recipes which ship a script /usr/bin/foo
and a symlink /usr/bin/bar -> foo, bar will be replaced with a real file
which is a duplicate of foo, wasting disk space.
Replace the loop with a find loop which can look at the real file type,
not the target type.
Signed-off-by: Ross Burton <ross.burton@...>
---
meta/classes/distutils3.bbclass | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/meta/classes/distutils3.bbclass b/meta/classes/distutils3.bbclass
index be645d37bd..0973d304f4 100644
--- a/meta/classes/distutils3.bbclass
+++ b/meta/classes/distutils3.bbclass
@@ -43,11 +43,9 @@ distutils3_do_install() {
find ${D} -name "*.py" -exec grep -q ${D} {} \; \
-exec sed -i -e s:${D}::g {} \;
- for i in ${D}${bindir}/* ${D}${sbindir}/*; do
- if [ -f "$i" ]; then
- sed -i -e s:${PYTHON}:${USRBINPATH}/env\ ${DISTUTILS_PYTHON}:g $i
- sed -i -e s:${STAGING_BINDIR_NATIVE}:${bindir}:g $i
- fi
+ for bin in $(find ${D}${bindir} ${D}${sbindir} -type f -maxdepth 1); do
+ sed -i -e s:${PYTHON}:${USRBINPATH}/env\ ${DISTUTILS_PYTHON}:g $bin
+ sed -i -e s:${STAGING_BINDIR_NATIVE}:${bindir}:g $bin
Does the same also apply to setuptools as in Tim's distutils deprecation series?
If so it should definitely we be merged there

done
rm -f ${D}${PYTHON_SITEPACKAGES_DIR}/easy-install.pth

12061 - 12080 of 171170