| Message ID | 20211215201615.536707-1-matt@madison.systems |
|---|---|
| State | Accepted, archived |
| Commit | 3a3cfb5f48fc92e548333e5856f3d3fcce27da46 |
| Headers | show |
| Series | qemu.bbclass: drop OLDEST_KERNEL reference | expand |
On 12/15/21 12:16 PM, 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. > This would need a qemu backport for riscv32 https://lists.nongnu.org/archive/html/qemu-riscv/2021-12/msg00220.html > 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"
On Wed, Dec 15, 2021 at 12:24 PM Khem Raj <raj.khem@gmail.com> wrote: > > > > On 12/15/21 12:16 PM, 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. > > > > This would need a qemu backport for riscv32 > https://lists.nongnu.org/archive/html/qemu-riscv/2021-12/msg00220.html Thanks, Khem. I'll publish a V2 with that addition. -Matt > > > 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"
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" Rather worryingly this breaks a few docs packages for reproducibility: http://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20211219-6kkv1f8k/packages/diff-html/ which raises a number of questions in my mind. Investigation is needed as the hashes clearly aren't encoding everything they should :(. Cheers, Richard
On Sun, Dec 19, 2021 at 3:36 PM Richard Purdie <richard.purdie@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" > > Rather worryingly this breaks a few docs packages for reproducibility: > > http://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20211219-6kkv1f8k/packages/diff-html/ > > which raises a number of questions in my mind. Investigation is needed as the > hashes clearly aren't encoding everything they should :(. I think the problem is in manpages.bbclass - the ":append" for adding to the pkg_postinst/pkg_postrm functions is in the wrong place. Fixing them so the ":append" is at the end, rather than before "${MAN_PKG}", causes the function text and dependencies to show up in dumpsig output again. -Matt > > Cheers, > > Richard >
On Mon, 2021-12-20 at 05:40 -0800, Matt Madison wrote: > On Sun, Dec 19, 2021 at 3:36 PM Richard Purdie > <richard.purdie@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" > > > > Rather worryingly this breaks a few docs packages for reproducibility: > > > > http://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20211219-6kkv1f8k/packages/diff-html/ > > > > which raises a number of questions in my mind. Investigation is needed as the > > hashes clearly aren't encoding everything they should :(. > > I think the problem is in manpages.bbclass - the ":append" for adding > to the pkg_postinst/pkg_postrm functions is in the wrong place. > Fixing them so the ":append" is at the end, rather than before > "${MAN_PKG}", causes the function text and dependencies to show up in > dumpsig output again. I agree, I'd come to the same conclusion and there is a patch in master-next testing on the autobuilder to see if that does resolve the issue. I've not sent it out yet as invalidating the data from a reproducibility perspective is tricky. Cheers, Richard
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. 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). Cheers, Richard
On Fri, Jan 7, 2022 at 3:19 AM Richard Purdie <richard.purdie@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. -Matt > > Cheers, > > Richard > > >
On Fri, 2022-01-07 at 04:36 -0800, Matt Madison wrote: > On Fri, Jan 7, 2022 at 3:19 AM Richard Purdie > <richard.purdie@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
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.purdie@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... Cheers, Richard
On Fri, Jan 7, 2022 at 4:56 AM Richard Purdie <richard.purdie@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.purdie@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. Thanks, -Matt > > Cheers, > > Richard >
On Fri, 2022-01-07 at 06:44 -0800, Matt Madison wrote: > On Fri, Jan 7, 2022 at 4:56 AM Richard Purdie > <richard.purdie@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.purdie@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! Cheers, Richard
On Sat, Jan 8, 2022 at 6:34 AM Richard Purdie <richard.purdie@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.purdie@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.purdie@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. -Matt > > Cheers, > > Richard >
On Sat, 2022-01-08 at 07:10 -0800, Matt Madison wrote: > On Sat, Jan 8, 2022 at 6:34 AM Richard Purdie > <richard.purdie@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.purdie@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.purdie@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 :/ Cheers, Richard
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.purdie@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.purdie@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.purdie@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 (#160277): https://lists.openembedded.org/g/openembedded-core/message/160277 > Mute This Topic: https://lists.openembedded.org/mt/87752526/3647476 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [kweihmann@outlook.com] > -=-=-=-=-=-=-=-=-=-=-=- >
> -----Original Message----- > From: openembedded-core@lists.openembedded.org <openembedded- > core@lists.openembedded.org> On Behalf Of Konrad Weihmann > Sent: den 9 januari 2022 10:24 > To: Richard Purdie <richard.purdie@linuxfoundation.org> > Cc: Patches and discussions about the oe-core layer <openembedded- > core@lists.openembedded.org> > Subject: Re: [OE-core][PATCH] qemu.bbclass: drop OLDEST_KERNEL reference > > 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.purdie@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.purdie@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.purdie@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/ste > ps/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? That seems like the wrong solution. As far as possible, bbclasses should be designed to be able to inherit them in any order, and it should be possible to rewrite this change so that is still possible to do. > > > > Cheers, > > > > Richard //Peter
On Sun, Jan 9, 2022 at 3:32 AM Peter Kjellerstedt <peter.kjellerstedt@axis.com> wrote: > > > -----Original Message----- > > From: openembedded-core@lists.openembedded.org <openembedded- > > core@lists.openembedded.org> On Behalf Of Konrad Weihmann > > Sent: den 9 januari 2022 10:24 > > To: Richard Purdie <richard.purdie@linuxfoundation.org> > > Cc: Patches and discussions about the oe-core layer <openembedded- > > core@lists.openembedded.org> > > Subject: Re: [OE-core][PATCH] qemu.bbclass: drop OLDEST_KERNEL reference > > > > 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.purdie@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.purdie@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.purdie@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/ste > > ps/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? > > That seems like the wrong solution. As far as possible, bbclasses should > be designed to be able to inherit them in any order, and it should be possible > to rewrite this change so that is still possible to do. Doing so would be a bit ugly, since it's a Python function. Something like if bb.data.inherits_class('qemu', d): d.setVar("qemu_wrapper_cmdline", "def qemu_wrapper_cmdline(data, rootfs_path, library_paths):\n return 'false'\n") in the anonymous python function in allarch.bbclass would do that. -Matt > > > > > > > Cheers, > > > > > > Richard > > //Peter > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#160280): https://lists.openembedded.org/g/openembedded-core/message/160280 > Mute This Topic: https://lists.openembedded.org/mt/87752526/3618418 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [matt@madison.systems] > -=-=-=-=-=-=-=-=-=-=-=- >
> -----Original Message----- > From: Matt Madison <matt@madison.systems> > Sent: den 9 januari 2022 13:04 > To: Peter Kjellerstedt <peter.kjellerstedt@axis.com> > Cc: Konrad Weihmann <kweihmann@outlook.com>; Richard Purdie > <richard.purdie@linuxfoundation.org>; Patches and discussions about the > oe-core layer <openembedded-core@lists.openembedded.org> > Subject: Re: [OE-core][PATCH] qemu.bbclass: drop OLDEST_KERNEL reference > > On Sun, Jan 9, 2022 at 3:32 AM Peter Kjellerstedt > <peter.kjellerstedt@axis.com> wrote: > > > > > -----Original Message----- > > > From: openembedded-core@lists.openembedded.org <openembedded- > > > core@lists.openembedded.org> On Behalf Of Konrad Weihmann > > > Sent: den 9 januari 2022 10:24 > > > To: Richard Purdie <richard.purdie@linuxfoundation.org> > > > Cc: Patches and discussions about the oe-core layer <openembedded- > > > core@lists.openembedded.org> > > > Subject: Re: [OE-core][PATCH] qemu.bbclass: drop OLDEST_KERNEL > reference > > > > > > 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.purdie@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.purdie@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.purdie@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/ste > > > ps/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? > > > > That seems like the wrong solution. As far as possible, bbclasses should > > be designed to be able to inherit them in any order, and it should be > possible > > to rewrite this change so that is still possible to do. > > Doing so would be a bit ugly, since it's a Python function. Something like > > if bb.data.inherits_class('qemu', d): > d.setVar("qemu_wrapper_cmdline", "def > qemu_wrapper_cmdline(data, rootfs_path, library_paths):\n return > 'false'\n") > > in the anonymous python function in allarch.bbclass would do that. Ok, that's ugly. How about solving it in qemu.bbclass instead by doing: def qemu_wrapper_cmdline(data, rootfs_path, library_paths): import string if bb.data.inherits_class('allarch', data): return 'false' ... > > -Matt > > > > > > > > > > > Cheers, > > > > > > > > Richard > > > > //Peter //Peter
On Sun, Jan 9, 2022 at 5:52 AM Peter Kjellerstedt <peter.kjellerstedt@axis.com> wrote: > > > -----Original Message----- > > From: Matt Madison <matt@madison.systems> > > Sent: den 9 januari 2022 13:04 > > To: Peter Kjellerstedt <peter.kjellerstedt@axis.com> > > Cc: Konrad Weihmann <kweihmann@outlook.com>; Richard Purdie > > <richard.purdie@linuxfoundation.org>; Patches and discussions about the > > oe-core layer <openembedded-core@lists.openembedded.org> > > Subject: Re: [OE-core][PATCH] qemu.bbclass: drop OLDEST_KERNEL reference > > > > On Sun, Jan 9, 2022 at 3:32 AM Peter Kjellerstedt > > <peter.kjellerstedt@axis.com> wrote: > > > > > > > -----Original Message----- > > > > From: openembedded-core@lists.openembedded.org <openembedded- > > > > core@lists.openembedded.org> On Behalf Of Konrad Weihmann > > > > Sent: den 9 januari 2022 10:24 > > > > To: Richard Purdie <richard.purdie@linuxfoundation.org> > > > > Cc: Patches and discussions about the oe-core layer <openembedded- > > > > core@lists.openembedded.org> > > > > Subject: Re: [OE-core][PATCH] qemu.bbclass: drop OLDEST_KERNEL > > reference > > > > > > > > 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.purdie@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.purdie@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.purdie@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/ste > > > > ps/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? > > > > > > That seems like the wrong solution. As far as possible, bbclasses should > > > be designed to be able to inherit them in any order, and it should be > > possible > > > to rewrite this change so that is still possible to do. > > > > Doing so would be a bit ugly, since it's a Python function. Something like > > > > if bb.data.inherits_class('qemu', d): > > d.setVar("qemu_wrapper_cmdline", "def > > qemu_wrapper_cmdline(data, rootfs_path, library_paths):\n return > > 'false'\n") > > > > in the anonymous python function in allarch.bbclass would do that. > > Ok, that's ugly. How about solving it in qemu.bbclass instead by doing: > > def qemu_wrapper_cmdline(data, rootfs_path, library_paths): > import string > > if bb.data.inherits_class('allarch', data): > return 'false' Unfortunately, that wouldn't fix the problem, since task signatures are computed based on the parsed text of the function, which would still include the reference to the OLDEST_KERNEL variable. A somewhat less ugly approach might be to just to do: if bb.data.inherits_class('qemu', d): d.setVar('QEMU_OPTIONS', '') along with all the other variable changes in allarch.bbclass. -Matt > > ... > > > > > -Matt > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > Richard > > > > > > //Peter > > //Peter >
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"
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(-)