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.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160256):
https://lists.openembedded.org/g/openembedded-core/message/160256
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]
-=-=-=-=-=-=-=-=-=-=-=-
