On Sun, Jan 9, 2022 at 5:52 AM Peter Kjellerstedt
<peter.kjellerst...@axis.com> wrote:
>
> > -----Original Message-----
> > From: Matt Madison <matt@madison.systems>
> > Sent: den 9 januari 2022 13:04
> > To: Peter Kjellerstedt <peter.kjellerst...@axis.com>
> > Cc: Konrad Weihmann <kweihm...@outlook.com>; Richard Purdie
> > <richard.pur...@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.kjellerst...@axis.com> wrote:
> > >
> > > > -----Original Message-----
> > > > From: openembedded-core@lists.openembedded.org <openembedded-
> > > > c...@lists.openembedded.org> On Behalf Of Konrad Weihmann
> > > > Sent: den 9 januari 2022 10:24
> > > > To: Richard Purdie <richard.pur...@linuxfoundation.org>
> > > > Cc: Patches and discussions about the oe-core layer <openembedded-
> > > > c...@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.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/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
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160283):
https://lists.openembedded.org/g/openembedded-core/message/160283
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]
-=-=-=-=-=-=-=-=-=-=-=-
