On Tue, 2021-07-06 at 13:58 -0400, bruce.ashfield@gmail.com wrote:

quoted

From: Bruce Ashfield <redacted>

We are always getting questions about building -stable, or mainline
master. Rather than introducing a separate set of recipes, we can
facilitate this sort of testing by using the existing devupstream
bbclass support.

To build an unpatched or otherwise modifed -stable of 5.13, simply
set the linux-yocto preferred version to:

  upstream+5.13%

And your wish will be granted, as the build will use v5.13/base
which matches the main linux-yocto version, simply with no extra
changes applied.

Signed-off-by: Bruce Ashfield <redacted>
---

Richard,

This is the patch that I was talking about earlier in the yocto dev
meeting.

I personally find this the easiest to maintain, since it is just
a variant of linux-yocto_<version>, and ends up just being a
different branch versus anything radically different.

I am open to making this a different / named recipe to make the
distinction more clear, but I'm worried about the impression
that we were doing extensive testing on the bare -stable branches
when most of the testing (which is transient to the base -stable)
happens on our standard/base branch.

Either way, I'll work on getting this and the -dev tweaks I sent
earlier added to some part of our AB testing to make sure that
they stay in good shape.

Sorry for the delay on this one, I wanted to try something. I have a
tweak to propose and since patches speak louder than words:

diff --git a/meta/recipes-kernel/linux/linux-yocto_5.13.bb b/meta/recipes-kernel/linux/linux-yocto_5.13.bb
index cd51e04b95d..ab81a977b8a 100644
--- a/meta/recipes-kernel/linux/linux-yocto_5.13.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_5.13.bb

@@ -25,13 +25,13 @@ SRCREV_machine_qemumips64 ?= "b74fe3dcca0653609fcb75aad883b1db07619081"
 SRCREV_machine ?= "b1cead8d98582ca687f93e06438543b97144e5bf"
 SRCREV_meta ?= "ceb5fa598d08902fe2934c041875aa92d9a6fa19"

-# set your preferred version of linux-yocto to 'upstream+<version>%', and you'll
+# set your preferred provider of virtual/kernel to 'linux-yocto-upstream', and you'll
 # get the <version>/base branch, which is pure upstream -stable, and the same
 # meta SRCREV as the linux-yocto-standard builds
 BBCLASSEXTEND = "devupstream:target"
 DEFAULT_PREFERENCE_class-devupstream = "-1"
 SRCREV_class-devupstream = "62fb9874f5da54fdb243003b386128037319b219"
-PV_class-devupstream = "upstream+${LINUX_VERSION}+git${SRCPV}"
+PN_class-devupstream = "linux-yocto-upstream"
 KBRANCH_class-devupstream = "v5.13/base"

 # remap qemuarm to qemuarma15 for the 5.8 kernel

Basically this does what you were doing but brings with it the advantages
of having the target in it's own recipe namespace by changing PN.

This means you'd set:

PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-upstream"

to enable and the advantage is that if multiple linux-yocto recipes have
this, you can do:

PREFERRED_VERSION_linux-yocto-upstream = "5.13%"

or whatever, it all works as normal.

This drops the hacked up PV field and I think makes things work nicely.

Does that seem reasonable to you? It should work just as well with your workflows?