On 08.01.22 16:13, Richard Purdie wrote:
On Sat, 2022-01-08 at 07:10 -0800, Matt Madison wrote:
On Sat, Jan 8, 2022 at 6:34 AM Richard Purdie
<richard.pur...@linuxfoundation.org> wrote:

On Fri, 2022-01-07 at 06:44 -0800, Matt Madison wrote:
On Fri, Jan 7, 2022 at 4:56 AM Richard Purdie
<richard.pur...@linuxfoundation.org> wrote:

On Fri, 2022-01-07 at 12:51 +0000, Richard Purdie via lists.openembedded.org
wrote:
On Fri, 2022-01-07 at 04:36 -0800, Matt Madison wrote:
On Fri, Jan 7, 2022 at 3:19 AM Richard Purdie
<richard.pur...@linuxfoundation.org> wrote:

On Wed, 2021-12-15 at 12:16 -0800, Matt Madison wrote:
which is introducing task hash changes for some
allarch package builds, and should no longer
be needed with recent versions of qemu.

Signed-off-by: Matt Madison <matt@madison.systems>
---
  meta/classes/qemu.bbclass | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/qemu.bbclass b/meta/classes/qemu.bbclass
index 01a7b86ae1..333202b7c4 100644
--- a/meta/classes/qemu.bbclass
+++ b/meta/classes/qemu.bbclass
@@ -54,7 +54,7 @@ def qemu_run_binary(data, rootfs_path, binary):
  # this dance). For others (e.g. arm) a -cpu option is not necessary, since the
  # qemu-arm default CPU supports all required architecture levels.

-QEMU_OPTIONS = "-r ${OLDEST_KERNEL} ${@d.getVar("QEMU_EXTRAOPTIONS_%s" % 
d.getVar('PACKAGE_ARCH')) or ""}"
+QEMU_OPTIONS = "${@d.getVar("QEMU_EXTRAOPTIONS_%s" % d.getVar('PACKAGE_ARCH')) or 
""}"
  QEMU_OPTIONS[vardeps] += "QEMU_EXTRAOPTIONS_${PACKAGE_ARCH}"

  QEMU_EXTRAOPTIONS_ppce500v2 = " -cpu e500v2"

I've sent a revert for this since the commit message isn't true, this is causing
autobuilder failures and there was also a user report of issues with it.

Bummer.  I think this is because our OLDEST_KERNEL setting for aarch64
(3.14.0) is
higher than the UNAME_MINIMUM_RELEASE definition in QEMU (3.8.0).

https://autobuilder.yoctoproject.org/typhoon/#/builders/42/builds/4559/steps/13/logs/stdio
(centos7 aarch64 build)

We'll have to find a different way to fix the allarch issue (more details
welcome on which package shows the issue).

I ran into the issue with cantarell-fonts and wayland-protocols, but
any recipe that inherits both allarch and meson should trigger it.

In my case, I have a layer check job for meta-tegra that runs
yocto-check-layer with the --machines option specifying qemux86 and
one of the (aarch64) machines in my layer, and that was reporting the
signature changes between the two architectures.

I wonder why we don't detect that with our standard tests? :/

There may be another fix:

diff --git a/meta/classes/allarch.bbclass b/meta/classes/allarch.bbclass
index 5bd5c44a276..0aadf7bfba6 100644
--- a/meta/classes/allarch.bbclass
+++ b/meta/classes/allarch.bbclass
@@ -43,6 +43,9 @@ python () {
          d.setVar("TARGET_LDFLAGS", "none")
          d.setVar("POPULATESYSROOTDEPS", "")

+        if bb.data.inherits_class("meson", d):
+            d.setVar("do_write_config", ":")
+
          # Avoid this being unnecessarily different due to nuances of
          # the target machine that aren't important for "all" arch
          # packages.



Sorry, that isn't quite right. We want to just remove the append to write_config
which generates the qemu wrapper which will probably need a little more invasive
juggling of the code to make it easier...

Your patch to disable the qemu wrapper for allarch looks like a good solution.
Hopefully, that will work OK across the board.

It seemed to be so I've merged it. Am hoping this resolves things!

Drat. Unfortunately, it only works if allarch is inherited after meson
(which inherits qemu).  So cantarell-fonts checks out OK,
but wayland-protocols doesn't, since it inherits allarch first.

Probably easy to fix but hard to spot new problems :/

would an insane check similar to native-last be of help here?


Cheers,

Richard





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160279): 
https://lists.openembedded.org/g/openembedded-core/message/160279
Mute This Topic: https://lists.openembedded.org/mt/87752526/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to