* [PATCH] linux-yocto/5.13: add devupstream support
@ 2021-07-06 17:58 Bruce Ashfield
2021-07-06 21:48 ` [OE-core] " Paul Barker
2021-07-11 9:53 ` Richard Purdie
0 siblings, 2 replies; 7+ messages in thread
From: Bruce Ashfield @ 2021-07-06 17:58 UTC (permalink / raw
To: richard.purdie; +Cc: openembedded-core
From: Bruce Ashfield <bruce.ashfield@gmail.com>
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 <bruce.ashfield@gmail.com>
---
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.
Cheers,
Bruce
meta/recipes-kernel/linux/linux-yocto_5.13.bb | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/meta/recipes-kernel/linux/linux-yocto_5.13.bb b/meta/recipes-kernel/linux/linux-yocto_5.13.bb
index 66384d8f7d..cd51e04b95 100644
--- a/meta/recipes-kernel/linux/linux-yocto_5.13.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_5.13.bb
@@ -25,6 +25,15 @@ SRCREV_machine_qemumips64 ?= "b74fe3dcca0653609fcb75aad883b1db07619081"
SRCREV_machine ?= "b1cead8d98582ca687f93e06438543b97144e5bf"
SRCREV_meta ?= "ceb5fa598d08902fe2934c041875aa92d9a6fa19"
+# set your preferred version of linux-yocto to 'upstream+<version>%', 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}"
+KBRANCH_class-devupstream = "v5.13/base"
+
# remap qemuarm to qemuarma15 for the 5.8 kernel
# KMACHINE_qemuarm ?= "qemuarma15"
--
2.19.1
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [OE-core] [PATCH] linux-yocto/5.13: add devupstream support
2021-07-06 17:58 [PATCH] linux-yocto/5.13: add devupstream support Bruce Ashfield
@ 2021-07-06 21:48 ` Paul Barker
2021-07-07 2:04 ` Bruce Ashfield
2021-07-11 9:53 ` Richard Purdie
1 sibling, 1 reply; 7+ messages in thread
From: Paul Barker @ 2021-07-06 21:48 UTC (permalink / raw
To: Bruce Ashfield; +Cc: richard.purdie, openembedded-core
[-- Attachment #1: Type: text/plain, Size: 1875 bytes --]
On Tue, 6 Jul 2021 13:58:21 -0400
"Bruce Ashfield" <bruce.ashfield@gmail.com> wrote:
> From: Bruce Ashfield <bruce.ashfield@gmail.com>
>
> 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 <bruce.ashfield@gmail.com>
This looks like a good thing to have in oe-core, in the basic case of
just wanting the latest mainline as-is you'd not need to add extra
layers any longer. meta-linux-mainline would still fill a niche as it
provides recipes for older stable kernels and supports using mainline &
newer stable kernels on dunfell & hardknott.
I guess the meta repository (yocto-kernel-cache) would still be cloned
and the upstream kernel could still be modified by patches or config
fragments enabled by KERNEL_FEATURES. That may be worth noting in the
documentation if I'm right. For my use-case where I want to use the
exact upstream defconfig I would probably need to override this, e.g.
`KERNEL_FEATURES_forcevariable = ""`, to make use of this.
I also guess this would also allow you to follow newer kernel releases
as they're added to linux-yocto recipes by setting the preferred version
to 'upstream%' (or maybe 'upstream+%' to be more restrictive). That
would then avoid the build breaking when the 5.13 recipe disappears and
is replaced by 5.14 or something else later.
Thanks,
--
Paul Barker
https://pbarker.dev/
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 235 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [OE-core] [PATCH] linux-yocto/5.13: add devupstream support
2021-07-06 21:48 ` [OE-core] " Paul Barker
@ 2021-07-07 2:04 ` Bruce Ashfield
0 siblings, 0 replies; 7+ messages in thread
From: Bruce Ashfield @ 2021-07-07 2:04 UTC (permalink / raw
To: Paul Barker
Cc: Richard Purdie, Patches and discussions about the oe-core layer
On Tue, Jul 6, 2021 at 5:48 PM Paul Barker <paul@pbarker.dev> wrote:
>
> On Tue, 6 Jul 2021 13:58:21 -0400
> "Bruce Ashfield" <bruce.ashfield@gmail.com> wrote:
>
> > From: Bruce Ashfield <bruce.ashfield@gmail.com>
> >
> > 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 <bruce.ashfield@gmail.com>
>
> This looks like a good thing to have in oe-core, in the basic case of
> just wanting the latest mainline as-is you'd not need to add extra
> layers any longer. meta-linux-mainline would still fill a niche as it
> provides recipes for older stable kernels and supports using mainline &
> newer stable kernels on dunfell & hardknott.
Agreed, since we are still holding to the cadence in master of LTS +
"latest" + dev. So those older -stables are still being updated in the
various linux-yocto branches, but the SRCREV bumps and versioned
recipes are still only in their respective release branches. So someone
that wants those older versions, needs a copy of the recipe, or uses
meta-linux-mainline (as you just said :)
>
> I guess the meta repository (yocto-kernel-cache) would still be cloned
> and the upstream kernel could still be modified by patches or config
> fragments enabled by KERNEL_FEATURES. That may be worth noting in the
> documentation if I'm right. For my use-case where I want to use the
> exact upstream defconfig I would probably need to override this, e.g.
> `KERNEL_FEATURES_forcevariable = ""`, to make use of this.
Right, I want to clear some of the features when this is used, since they aren't
all available. I've run into it a few times myself, and the unconditional append
of some of the features are an issue, not only in this use case but in others
where fragments are supported, but linux-yocto isn't used. I just need to
detangle things a bit and make their appends be specific to linux-yocto and
skip them for the devupstream variant.
So hopefully once I have this into shape, we won't need to document it, since
it'll be 'fixed' .. but good catch, that is an important point.
>
> I also guess this would also allow you to follow newer kernel releases
> as they're added to linux-yocto recipes by setting the preferred version
> to 'upstream%' (or maybe 'upstream+%' to be more restrictive). That
> would then avoid the build breaking when the 5.13 recipe disappears and
> is replaced by 5.14 or something else later.
Yes. That wasn't something I was thinking about, but you could definitely
do that and have it follow along as the newly versioned recipe is added
(and potentially older ones removed) without needing to explicitly change
your preferred version.
Bruce
>
> Thanks,
>
> --
> Paul Barker
> https://pbarker.dev/
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] linux-yocto/5.13: add devupstream support
2021-07-06 17:58 [PATCH] linux-yocto/5.13: add devupstream support Bruce Ashfield
2021-07-06 21:48 ` [OE-core] " Paul Barker
@ 2021-07-11 9:53 ` Richard Purdie
2021-07-11 16:10 ` Bruce Ashfield
1 sibling, 1 reply; 7+ messages in thread
From: Richard Purdie @ 2021-07-11 9:53 UTC (permalink / raw
To: bruce.ashfield; +Cc: openembedded-core
On Tue, 2021-07-06 at 13:58 -0400, bruce.ashfield@gmail.com wrote:
> From: Bruce Ashfield <bruce.ashfield@gmail.com>
>
> 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 <bruce.ashfield@gmail.com>
> ---
>
> 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?
Cheers,
Richard
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] linux-yocto/5.13: add devupstream support
2021-07-11 9:53 ` Richard Purdie
@ 2021-07-11 16:10 ` Bruce Ashfield
2021-07-11 16:41 ` Richard Purdie
0 siblings, 1 reply; 7+ messages in thread
From: Bruce Ashfield @ 2021-07-11 16:10 UTC (permalink / raw
To: Richard Purdie; +Cc: Patches and discussions about the oe-core layer
On Sun, Jul 11, 2021 at 5:53 AM Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> On Tue, 2021-07-06 at 13:58 -0400, bruce.ashfield@gmail.com wrote:
> > From: Bruce Ashfield <bruce.ashfield@gmail.com>
> >
> > 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 <bruce.ashfield@gmail.com>
> > ---
> >
> > 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?
>
Most definitely.
That meets my goals of just having one more SRCREV to bump in the main
recipe, and it is easily accessible.
I can spin a v2, unless you want to just take your changes and merge
them as-is ?
Bruce
> Cheers,
>
> Richard
>
>
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] linux-yocto/5.13: add devupstream support
2021-07-11 16:10 ` Bruce Ashfield
@ 2021-07-11 16:41 ` Richard Purdie
2021-07-11 16:52 ` Bruce Ashfield
0 siblings, 1 reply; 7+ messages in thread
From: Richard Purdie @ 2021-07-11 16:41 UTC (permalink / raw
To: Bruce Ashfield; +Cc: Patches and discussions about the oe-core layer
On Sun, 2021-07-11 at 12:10 -0400, Bruce Ashfield wrote:
> On Sun, Jul 11, 2021 at 5:53 AM Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> >
> > On Tue, 2021-07-06 at 13:58 -0400, bruce.ashfield@gmail.com wrote:
> > > From: Bruce Ashfield <bruce.ashfield@gmail.com>
> > >
> > > 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 <bruce.ashfield@gmail.com>
> > > ---
> > >
> > > 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?
> >
>
> Most definitely.
>
> That meets my goals of just having one more SRCREV to bump in the main
> recipe, and it is easily accessible.
>
> I can spin a v2, unless you want to just take your changes and merge
> them as-is ?
v2 is probably best as it does change the commit message and so on quite
a bit? I can fix it all up so don't mind either way really but I'll assume
v2 unless you say otherwise :)
Cheers,
Richard
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] linux-yocto/5.13: add devupstream support
2021-07-11 16:41 ` Richard Purdie
@ 2021-07-11 16:52 ` Bruce Ashfield
0 siblings, 0 replies; 7+ messages in thread
From: Bruce Ashfield @ 2021-07-11 16:52 UTC (permalink / raw
To: Richard Purdie; +Cc: Patches and discussions about the oe-core layer
On Sun, Jul 11, 2021 at 12:41 PM Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> On Sun, 2021-07-11 at 12:10 -0400, Bruce Ashfield wrote:
> > On Sun, Jul 11, 2021 at 5:53 AM Richard Purdie
> > <richard.purdie@linuxfoundation.org> wrote:
> > >
> > > On Tue, 2021-07-06 at 13:58 -0400, bruce.ashfield@gmail.com wrote:
> > > > From: Bruce Ashfield <bruce.ashfield@gmail.com>
> > > >
> > > > 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 <bruce.ashfield@gmail.com>
> > > > ---
> > > >
> > > > 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?
> > >
> >
> > Most definitely.
> >
> > That meets my goals of just having one more SRCREV to bump in the main
> > recipe, and it is easily accessible.
> >
> > I can spin a v2, unless you want to just take your changes and merge
> > them as-is ?
>
> v2 is probably best as it does change the commit message and so on quite
> a bit? I can fix it all up so don't mind either way really but I'll assume
> v2 unless you say otherwise :)
I'll send v2 on Monday!
Bruce
>
> Cheers,
>
> Richard
>
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-07-11 16:53 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-07-06 17:58 [PATCH] linux-yocto/5.13: add devupstream support Bruce Ashfield
2021-07-06 21:48 ` [OE-core] " Paul Barker
2021-07-07 2:04 ` Bruce Ashfield
2021-07-11 9:53 ` Richard Purdie
2021-07-11 16:10 ` Bruce Ashfield
2021-07-11 16:41 ` Richard Purdie
2021-07-11 16:52 ` Bruce Ashfield
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.