On Mon, Sep 30, 2024 at 6:09 AM Quentin Schulz <[email protected]> wrote: > > Hi Bruce, > > On 9/25/24 4:23 PM, Bruce Ashfield wrote: > > On Wed, Sep 25, 2024 at 10:07 AM Quentin Schulz <[email protected]> > > wrote: > > > >> Hi Bruce, > >> > >> On 9/25/24 3:57 PM, Bruce Ashfield wrote: > >>> On Wed, Sep 25, 2024 at 9:37 AM Quentin Schulz <[email protected] > >>> > >>> wrote: > >>> > >>>> Hi Bruce, > >>>> > >>>> On 9/24/24 4:11 PM, Bruce Ashfield wrote: > >>>>> On Tue, Sep 24, 2024 at 9:02 AM Quentin Schulz < > >> [email protected] > >>>>> > >>>>> wrote: > >>>>> > >>>>>> Hi Bruce, > >>>>>> > >>>>>> On 8/11/24 8:04 PM, Bruce Ashfield via lists.openembedded.org wrote: > >>>>>>> From: Bruce Ashfield <[email protected]> > >>>>>>> > >>>>>>> Signed-off-by: Bruce Ashfield <[email protected]> > >>>>>>> --- > >>>>>>> meta/recipes-kernel/linux/linux-yocto-dev.bb | 4 ++-- > >>>>>>> 1 file changed, 2 insertions(+), 2 deletions(-) > >>>>>>> > >>>>>>> diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb > >>>>>> b/meta/recipes-kernel/linux/linux-yocto-dev.bb > >>>>>>> index 0097fec7b2..292897ce43 100644 > >>>>>>> --- a/meta/recipes-kernel/linux/linux-yocto-dev.bb > >>>>>>> +++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb > >>>>>>> @@ -14,7 +14,7 @@ require recipes-kernel/linux/linux-yocto.inc > >>>>>>> # provide this .inc to set specific revisions > >>>>>>> include recipes-kernel/linux/linux-yocto-dev-revisions.inc > >>>>>>> > >>>>>>> -KBRANCH = "v6.10/standard/base" > >>>>>>> +KBRANCH = "v6.11/standard/base" > >>>>>>> KMETA = "kernel-meta" > >>>>>>> > >>>>>>> SRC_URI = "git:// > >>>>>> > >>>> > >> git.yoctoproject.org/linux-yocto-dev.git;branch=${KBRANCH};name=machine;protocol=https > >> <http://git.yoctoproject.org/linux-yocto-dev.git;branch=$%7BKBRANCH%7D;name=machine;protocol=https> > >>>> < > >> http://git.yoctoproject.org/linux-yocto-dev.git;branch=$%7BKBRANCH%7D;name=machine;protocol=https > >>> > >>>>>> < > >>>> > >> http://git.yoctoproject.org/linux-yocto-dev.git;branch=$%7BKBRANCH%7D;name=machine;protocol=https > >>>>> > >>>>>> \ > >>>>>>> @@ -28,7 +28,7 @@ SRC_URI = "git:// > >>>>>> git.yoctoproject.org/linux-yocto-dev.git;branch=${KBRANCH};name > >> <http://git.yoctoproject.org/linux-yocto-dev.git;branch=$%7BKBRANCH%7D;name> > >>>> < > >> http://git.yoctoproject.org/linux-yocto-dev.git;branch=$%7BKBRANCH%7D;name > >>> > >>>>>> < > >>>> > >> http://git.yoctoproject.org/linux-yocto-dev.git;branch=$%7BKBRANCH%7D;name > >>>>> > >>>>>>> SRCREV_machine ?= > >>>>>> '${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel", > >>>>>> "linux-yocto-dev", "${AUTOREV}", > >>>>>> "29594404d7fe73cd80eaa4ee8c43dcc53970c60e", d)}' > >>>>>>> SRCREV_meta ?= > >>>>>> '${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel", > >>>>>> "linux-yocto-dev", "${AUTOREV}", > >>>>>> "29594404d7fe73cd80eaa4ee8c43dcc53970c60e", d)}' > >>>>>>> > >>>>>>> -LINUX_VERSION ?= "6.10" > >>>>>>> +LINUX_VERSION ?= "6.11" > >>>>>>> LINUX_VERSION_EXTENSION ?= "-yoctodev-${LINUX_KERNEL_TYPE}" > >>>>>>> PV = "${LINUX_VERSION}+git" > >>>>>>> > >>>>>> > >>>>>> I haven't tried to compile linux-yocto-dev but I have my own v6.11-rc6 > >>>>>> based kernel recipe. > >>>>>> > >>>>>> It failed to build on Scarthgap because I was missing coreutils-native > >>>>>> (specifically truncate binary) because CONFIG_KALLSYMS was enabled. > >> This > >>>>>> comes from > >>>>>> > >>>>>> > >>>> > >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1472464c6248575bf2d01c7f076b94704bb32c95 > >>>>>> > >>>>>> It seems there are some config fragments in linux-yocto-cache > >>>>>> (ktypes/base/base.cfg) with it, so maybe we want to always add the > >>>>>> dependency (or is there a way to add a build time dependency from an > >>>>>> .scc file?). > >>>>>> > >>>>> > >>>>> > >>>>> Interesting! > >>>>> > >>>>> I build linux-yocto-dev nightly, so I can confidently say that this > >> isn't > >>>>> being seen with the reference recipe. > >>>>> > >>>>> I also do have KALLSYMS in the default .config, so I've worked through > >>>> the > >>>>> same new commit and enabling option. > >>>>> > >>>>> I get truncate in my kernel builds via hosttools, so the dependency > >>>>> wasn't/isn't needed. > >>>>> > >>>> > >>>> truncate isn't in HOSTTOOLS in any release yet, just master. > >>>> > >>>> c.f. > >>>> > >>>> > >> https://git.openembedded.org/openembedded-core/commit/?id=522000ce5c4f0201cbe42d7826b6a8489ed10117 > >>>> > >>>> This means people won't be able to build 6.11 and later with > >>>> CONFIG_KALLSYMS enabled in Scarthgap and earlier releases... > >>>> > >>>> ... unless we backport this patch to still supported releases? > >>>> > >>>> BTW, I could reproduce on Scarthgap by checking out poky in its > >>>> scarthgap branch, then running `git checkout origin/master -- > >>>> meta/recipes-kernel/linux/linux-yocto-dev.bb`, then adding > >>>> `PREFERRED_PROVIDER_virtual/kernel="linux-yocto-dev"` to conf/local.conf > >>>> and then running `MACHINE=qemuarm64 bitbake linux-yocto-dev` from either > >>>> a kas-container (4.3.2) or Debian Bullseye. > >>>> > >>> > >>> Right. I only target linux-yocto-dev at the latest master where we do all > >>> our testing. The support matrix of ever newer kernels against the older > >>> releases can get complicated, but we can at least say a given release > >>> supports the reference kernels + the reference -dev kernel version. > >>> > >>> Anything more we do on a case by case basis. > >>> > >> > >> Oh for sure! I wasn't implying we aren't testing appropriately or that > >> we need to increase the number of kernels to support per release. Just > >> that **some** people (likely me.... :) ) may want to support 6.12 on > >> Scarthgap whenever it's out and that will be an issue. The answer to > >> that issue could very well be "upstream isn't interested in supporting > >> this for already-released versions, just handle this in your layer". > >> > >> I assume one could simply add HOSTTOOLS += "truncate" in the kernel > >> recipe and be done with it? I would be worried to add it globally as it > >> could then break/change other stuff since the host's tool would be used > >> instead of the one in recipe-sysroot-native (is that even true?)? > >> > > > > That would mess with the configuration space from a recipe, and won't > > work. It's already gone into use long before the kernel starts to be > > parsed and built. > > > > > >> > >>> I'd go with that simple host tool addition, rather than adding > >>> coreutils-native > >>> as a dependency. > >>> > >>> I have a patch locally that can test hosttools and if truncate is missing > >>> conditionally add the dependency. That balances the speed vs supporting > >>> non-default host configuration. > >>> > >> > >> I'm not planning on using linux-yocto for our products so was hoping for > >> a generic solution maybe? If there's one :) > >> > > > > I really push back on polluting kernel.bbclass with any version specific > > dependencies and changes. It is best handled in the versioned recipes > > until it is no longer version specific. > > > > > >> > >> I guess adding truncate to HOSTTOOLS in conf/bitbake.conf in an > >> already-released version is just not something we want? > >> > >> > > I personally have no issue with it, the tool is tiny and I'd be shocked if > > it wasn't on all the supported hosts for the release(s) in question. > > > > It is far preferable to doing kernel version specific tests and dependencies > > and/or adding coreutils-native unconditionally. > > > > > > > >> Just looking for guidance so I know which direction to go in 3/4 months > >> from now when I'll be supporting 6.12 :) > >> > > > > I'd append to HOSTTOOLS in your layer ! Or just copy into your > > kernel recipe what I'm about to add to linux-yocto-dev :) > > > > Did you send something already? I think I missed it if you did? > > Will send the backport patches as an RFC for scarthgap in any case but > I'm still interested to see what you came up with :)
I didn't send anything yet, as my test and add coreutils-native as a DEPENDS, seemed less ideal than just adding the hosttool to older releases. Since anything newer will have that hosttool passthrough. There's a number of other tools that could get the same treatment (i.e. don't assume they are in hosttools and build a -native in that case). That being said, I can definitely send it, and will do so once I'm through some other test cycles. Bruce > > Cheers, > Quentin -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#205170): https://lists.openembedded.org/g/openembedded-core/message/205170 Mute This Topic: https://lists.openembedded.org/mt/107843657/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
