| Message ID | 20230714161823.20685-1-festevam@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | [1/2] u-boot: Switch to nobranch=1 | expand |
It's not in master branch, but it is in a branch, so please do not use nobranch, and just adjust the branch parameter together with the version update: https://source.denx.de/u-boot/u-boot/-/commit/83cdab8b2c6ea0fc0860f8444d083353b47f1d5c Alex On Fri, 14 Jul 2023 at 18:18, Fabio Estevam <festevam@gmail.com> wrote: > > From: Marek Vasut <marex@denx.de> > > U-Boot 2023.07.y tags are not in the master branch, switch to nobranch=1 > to be able to pull arbitrary commit from arbitrary branch. > > Signed-off-by: Marek Vasut <marex@denx.de> > Signed-off-by: Fabio Estevam <festevam@denx.de> > --- > meta/recipes-bsp/u-boot/u-boot-common.inc | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/meta/recipes-bsp/u-boot/u-boot-common.inc b/meta/recipes-bsp/u-boot/u-boot-common.inc > index 56f9be010793..29beac4c1127 100644 > --- a/meta/recipes-bsp/u-boot/u-boot-common.inc > +++ b/meta/recipes-bsp/u-boot/u-boot-common.inc > @@ -14,7 +14,7 @@ PE = "1" > # repo during parse > SRCREV = "05aa6516c6bb419d01d69fac457c0de563bfd694" > > -SRC_URI = "git://source.denx.de/u-boot/u-boot.git;protocol=https;branch=master" > +SRC_URI = "git://source.denx.de/u-boot/u-boot.git;protocol=https;nobranch=1" > > S = "${WORKDIR}/git" > B = "${WORKDIR}/build" > -- > 2.34.1 > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#184273): https://lists.openembedded.org/g/openembedded-core/message/184273 > Mute This Topic: https://lists.openembedded.org/mt/100144566/1686489 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alex.kanavin@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- >
On Fri, Jul 14, 2023 at 07:53:03PM +0200, Alexander Kanavin wrote: > It's not in master branch, but it is in a branch, so please do not use > nobranch, and just adjust the branch parameter together with the > version update: > https://source.denx.de/u-boot/u-boot/-/commit/83cdab8b2c6ea0fc0860f8444d083353b47f1d5c Won't this just make more churn later? The v2023.10 tag will be back on master (and we'll assume I don't goof it up), but if any of the "maybe we do an LTS? Hmm?" work comes through, then we start having to change things there, and then maybe can't as easily share inc files between something that tracks LTS and something that doesn't.
Then we’ll consider options, such as moving variable bits out of .inc or introducing a variable that strips last number from PV. I would want to avoid recipes fetching from dangling branch-less commits in core. The commit being on a branch is a QA check by the fetcher. Alex On Sat 15. Jul 2023 at 0.37, Tom Rini <trini@konsulko.com> wrote: > On Fri, Jul 14, 2023 at 07:53:03PM +0200, Alexander Kanavin wrote: > > > It's not in master branch, but it is in a branch, so please do not use > > nobranch, and just adjust the branch parameter together with the > > version update: > > > https://source.denx.de/u-boot/u-boot/-/commit/83cdab8b2c6ea0fc0860f8444d083353b47f1d5c > > Won't this just make more churn later? The v2023.10 tag will be back on > master (and we'll assume I don't goof it up), but if any of the "maybe > we do an LTS? Hmm?" work comes through, then we start having to change > things there, and then maybe can't as easily share inc files between > something that tracks LTS and something that doesn't. > > -- > Tom >
On 7/15/23 06:56, Alexander Kanavin wrote: > Then we’ll consider options, such as moving variable bits out of .inc or > introducing a variable that strips last number from PV. I would want to > avoid recipes fetching from dangling branch-less commits in core. The > commit being on a branch is a QA check by the fetcher. What difference does it make whether the commit is in a branch or not , as long as it is referenced ?
If you don’t list which branch a commit is on, it may be not in a branch at all and not intended for downstream consumption, or on a private or personal branch which is also not intended for private consumption. Requiring to name the branch guards us from either possibility, and means I do not have to go and check that manually or trust you blindly. Alex On Sat 15. Jul 2023 at 14.14, Marek Vasut <marex@denx.de> wrote: > On 7/15/23 06:56, Alexander Kanavin wrote: > > Then we’ll consider options, such as moving variable bits out of .inc or > > introducing a variable that strips last number from PV. I would want to > > avoid recipes fetching from dangling branch-less commits in core. The > > commit being on a branch is a QA check by the fetcher. > > What difference does it make whether the commit is in a branch or not , > as long as it is referenced ? >
On 7/15/23 15:00, Alexander Kanavin wrote: > If you don’t list which branch a commit is on, it may be not in a branch at > all That itself is not a problem as long as the commit is referenced, right? > and not intended for downstream consumption We do know that specific U-Boot commit is intended for consumption. >, or on a private or > personal branch which is also not intended for private consumption. This is also not applicable here. > Requiring to name the branch guards us from either possibility, and means I > do not have to go and check that manually or trust you blindly. This protection is really weak, this check fails on every single possibly bogus commit which is already on any random branch, so what is the gain here really ?
On Sun 16. Jul 2023 at 4.01, Marek Vasut <marex@denx.de> wrote: > This protection is really weak, this check fails on every single > possibly bogus commit which is already on any random branch, so what is > the gain here really ? The gain is that the branch name is seen in the recipe and we can make the judgement about it. You wouldn’t be able to switch from main to my-ugly-hacks or dangling commit without having to explain that. With nobranch the branch name disappears and this opens the door for bogus commits. You may reassure us that right now the commit is not bogus, this may not hold in future revision updates or if the branch is force pushed on your side. Alex
On Sun, Jul 16, 2023 at 08:12:42AM +0300, Alexander Kanavin wrote: > On Sun 16. Jul 2023 at 4.01, Marek Vasut <marex@denx.de> wrote: > > > This protection is really weak, this check fails on every single > > possibly bogus commit which is already on any random branch, so what is > > the gain here really ? > > The gain is that the branch name is seen in the recipe and we can make the > judgement about it. You wouldn’t be able to switch from main to > my-ugly-hacks or dangling commit without having to explain that. With > nobranch the branch name disappears and this opens the door for bogus > commits. You may reassure us that right now the commit is not bogus, this > may not hold in future revision updates or if the branch is force pushed on > your side. Does bitbake have any infrastructure atm for dealing with signed tags? I'm fine with (for now, as LTS is a hope not a feature) keeping the branch portion. But if it was possible to say it must be a tag signed by X key, that would help a little with the concern about moving to some more arbitrary commit.
On Sun, 16 Jul 2023 at 17:03, Tom Rini <trini@konsulko.com> wrote: > Does bitbake have any infrastructure atm for dealing with signed tags? > I'm fine with (for now, as LTS is a hope not a feature) keeping the > branch portion. But if it was possible to say it must be a tag signed > by X key, that would help a little with the concern about moving to some > more arbitrary commit. As far as I know, git fetcher doesn't verify tags. They don't even have to be signed, checking that a tag specified in a recipe matches a commit id specified in a recipe would also guard against unwanted commits, but the fetcher doesn't do that check either. Alex
On Sun, Jul 16, 2023 at 07:19:56PM +0200, Alexander Kanavin wrote: > On Sun, 16 Jul 2023 at 17:03, Tom Rini <trini@konsulko.com> wrote: > > Does bitbake have any infrastructure atm for dealing with signed tags? > > I'm fine with (for now, as LTS is a hope not a feature) keeping the > > branch portion. But if it was possible to say it must be a tag signed > > by X key, that would help a little with the concern about moving to some > > more arbitrary commit. > > As far as I know, git fetcher doesn't verify tags. They don't even > have to be signed, checking that a tag specified in a recipe matches a > commit id specified in a recipe would also guard against unwanted > commits, but the fetcher doesn't do that check either. That's what I figured, thanks.
diff --git a/meta/recipes-bsp/u-boot/u-boot-common.inc b/meta/recipes-bsp/u-boot/u-boot-common.inc index 56f9be010793..29beac4c1127 100644 --- a/meta/recipes-bsp/u-boot/u-boot-common.inc +++ b/meta/recipes-bsp/u-boot/u-boot-common.inc @@ -14,7 +14,7 @@ PE = "1" # repo during parse SRCREV = "05aa6516c6bb419d01d69fac457c0de563bfd694" -SRC_URI = "git://source.denx.de/u-boot/u-boot.git;protocol=https;branch=master" +SRC_URI = "git://source.denx.de/u-boot/u-boot.git;protocol=https;nobranch=1" S = "${WORKDIR}/git" B = "${WORKDIR}/build"