u-boot: set git repo branch with SRCBRANCH

Enables changing branch from "master" to "next"
when building bleeding edge upstream versions for
testing purposes. Now local.conf setup to
build latest "next" version becomes:

INHERIT += "poky-bleeding"
POKY_AUTOREV_RECIPES += "u-boot"
SRCBRANCH:pn-u-boot = "next"

Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
---
 meta/recipes-bsp/u-boot/u-boot-common.inc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

On Fri, 4 Apr 2025 at 09:51, Mikko Rapeli via lists.openembedded.org
<mikko.rapeli=linaro.org@lists.openembedded.org> wrote:
>
> Enables changing branch from "master" to "next"
> when building bleeding edge upstream versions for
> testing purposes. Now local.conf setup to
> build latest "next" version becomes:
>
> INHERIT += "poky-bleeding"
> POKY_AUTOREV_RECIPES += "u-boot"
> SRCBRANCH:pn-u-boot = "next"

But 'next' is not a bleeding edge branch. It's a fluid, and probably
forced-pushed-to testing branch which is not even on top of master,
but rather master has commits that next does not:

https://source.denx.de/u-boot/u-boot/-/branches

Is there a use case for using it in yocto builds?

Another problem is that this sets a precedent we'd rather not set. If
you want to tweak bits of SRC_URI, it's better to just reset the whole
thing.

Alex

Hi,

On Mon, Apr 07, 2025 at 07:05:54PM +0200, Alexander Kanavin wrote:
> On Fri, 4 Apr 2025 at 09:51, Mikko Rapeli via lists.openembedded.org
> <mikko.rapeli=linaro.org@lists.openembedded.org> wrote:
> >
> > Enables changing branch from "master" to "next"
> > when building bleeding edge upstream versions for
> > testing purposes. Now local.conf setup to
> > build latest "next" version becomes:
> >
> > INHERIT += "poky-bleeding"
> > POKY_AUTOREV_RECIPES += "u-boot"
> > SRCBRANCH:pn-u-boot = "next"
> 
> But 'next' is not a bleeding edge branch. It's a fluid, and probably
> forced-pushed-to testing branch which is not even on top of master,
> but rather master has commits that next does not:
> 
> https://source.denx.de/u-boot/u-boot/-/branches
> 
> Is there a use case for using it in yocto builds?

Yes, testing features which are queued to merging but this process is taking
quite some time. If "yocto builds" is your oe-core/poky CI builds then I
think it's a no, no uses. But for me, I care about u-boot, tf-a, optee etc
and want to build their 'next' and master branches from time to time
to test features which are being merged. For example optee support for some new
HW or u-boot pmem support to boot memory based OS images.

FWIW, upstream optee developers use buildroot integration setup for similar
things and I have a need to use yocto based one.

> Another problem is that this sets a precedent we'd rather not set. If
> you want to tweak bits of SRC_URI, it's better to just reset the whole
> thing.

SRC_URI contains more than just SCM URIs and I don't want to overwrite
them. For example all the config snippets and patches. I'm also interested
if patches no longer apply and/or break builds. So I really just want to change
the upstream SCMs to different branch.

A lot of recipes do this already in oe-core so I though it would not be
a big deal for you.

Cheers,

-Mikko

On Tue, 8 Apr 2025 at 08:42, Mikko Rapeli <mikko.rapeli@linaro.org> wrote:

> SRC_URI contains more than just SCM URIs and I don't want to overwrite
> them. For example all the config snippets and patches. I'm also interested
> if patches no longer apply and/or break builds. So I really just want to change
> the upstream SCMs to different branch.

The next thing someone will want to do is test their u-boot fork, so
we introduce ${BASE_SRC_URI}. And then we get flooded with similar
tweaks all over the place, all of them serving special needs.

Seriously, please no. Make a commit that tweaks the branch name, and
rebase it on top of poky master every sometimes.

Alex

On Fri, 2025-04-04 at 10:51 +0300, Mikko Rapeli via lists.openembedded.org wrote:
> Enables changing branch from "master" to "next"
> when building bleeding edge upstream versions for
> testing purposes. Now local.conf setup to
> build latest "next" version becomes:
> 
> INHERIT += "poky-bleeding"
> POKY_AUTOREV_RECIPES += "u-boot"
> SRCBRANCH:pn-u-boot = "next"
> 
> Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> ---
>  meta/recipes-bsp/u-boot/u-boot-common.inc | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/recipes-bsp/u-boot/u-boot-common.inc b/meta/recipes-bsp/u-boot/u-boot-common.inc
> index fc860248ed..9e96c46b74 100644
> --- a/meta/recipes-bsp/u-boot/u-boot-common.inc
> +++ b/meta/recipes-bsp/u-boot/u-boot-common.inc
> @@ -13,8 +13,8 @@ PE = "1"
>  # We use the revision in order to avoid having to fetch it from the
>  # repo during parse
>  SRCREV = "6d41f0a39d6423c8e57e92ebbe9f8c0333a63f72"
> -
> -SRC_URI = "git://source.denx.de/u-boot/u-boot.git;protocol=https;branch=master"
> +SRCBRANCH ?= "master"
> +SRC_URI = "git://source.denx.de/u-boot/u-boot.git;protocol=https;branch=${SRCBRANCH}"
>  
>  S = "${WORKDIR}/git"
>  B = "${WORKDIR}/build"

I do want to be able to do this kind of thing, so to be clear, I do
strongly support the idea.

I am however worried about the implication of how this will scale (or
not). If I merge this, I'm likely to get this change for many other
recipes. I also suspect people will want to parameterise the
"source.denx.de/u-boot/u-boot.git" url part too so they can use their
own local repo.

I can't help wonder if we need some other mechanism for this. I've
talked with Joshua about variable "filter" mecahnisms before which
would be one idea. It would also be possible to filter the variable
with some inline python magic, in much the same way that the code
already tweaks SRCREV to add AUTOREV.

I did also wonder whether our mirror rewriting code could be used
somehow...

Cheers,

Richard

Hi,

On Tue, Apr 08, 2025 at 10:00:05AM +0100, Richard Purdie wrote:
> On Fri, 2025-04-04 at 10:51 +0300, Mikko Rapeli via lists.openembedded.org wrote:
> > Enables changing branch from "master" to "next"
> > when building bleeding edge upstream versions for
> > testing purposes. Now local.conf setup to
> > build latest "next" version becomes:
> > 
> > INHERIT += "poky-bleeding"
> > POKY_AUTOREV_RECIPES += "u-boot"
> > SRCBRANCH:pn-u-boot = "next"
> > 
> > Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
> > ---
> > �meta/recipes-bsp/u-boot/u-boot-common.inc | 4 ++--
> > �1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/meta/recipes-bsp/u-boot/u-boot-common.inc b/meta/recipes-bsp/u-boot/u-boot-common.inc
> > index fc860248ed..9e96c46b74 100644
> > --- a/meta/recipes-bsp/u-boot/u-boot-common.inc
> > +++ b/meta/recipes-bsp/u-boot/u-boot-common.inc
> > @@ -13,8 +13,8 @@ PE = "1"
> > �# We use the revision in order to avoid having to fetch it from the
> > �# repo during parse
> > �SRCREV = "6d41f0a39d6423c8e57e92ebbe9f8c0333a63f72"
> > -
> > -SRC_URI = "git://source.denx.de/u-boot/u-boot.git;protocol=https;branch=master"
> > +SRCBRANCH ?= "master"
> > +SRC_URI = "git://source.denx.de/u-boot/u-boot.git;protocol=https;branch=${SRCBRANCH}"
> > �
> > �S = "${WORKDIR}/git"
> > �B = "${WORKDIR}/build"
> 
> I do want to be able to do this kind of thing,�so to be clear, I do
> strongly support the idea.
> 
> I am however worried about the implication of how this will scale (or
> not). If I merge this, I'm likely to get this change for many other
> recipes. I also suspect people will want to parameterise the
> "source.denx.de/u-boot/u-boot.git" url part too so they can use their
> own local repo.
> 
> I can't help wonder if we need some other mechanism for this. I've
> talked with Joshua about variable "filter" mecahnisms before which
> would be one idea. It would also be possible to filter the variable
> with some inline python magic, in much the same way that the code
> already tweaks SRCREV to add AUTOREV.
> 
> I did also wonder whether our mirror rewriting code could be used
> somehow...

So a variable for pokybleeding_version_handler() to rewrite
"branch" variable in SRC_URI?

That could work but at the moment outside of fetcher code.

Cheers,

-Mikko