On Sun, Jan 4, 2026 at 12:20 AM Bruce Ashfield via
lists.yoctoproject.org
<[email protected]> wrote:
>
> On Sat, Jan 3, 2026 at 11:44 PM ChenQi <[email protected]> wrote:
> >
> > Hi Bruce,
> >
> > Thanks a lot for your prompt response and efforts.
> >
> > The BB_GIT_SHALLOW_EXTRA_REFS is the only one that actually breaks build.
> > Switching to the tag parameter looks like a good approach.
> > In case you want to check if things work for that new approach:
> > 1. Add in local.conf:
> > BB_GENERATE_SHALLOW_TARBALLS = "1"
> > BB_GIT_SHALLOW = "1"
> > 2. bitbake cni -c fetch
>
> I have updates to the hybrid fetcher (it was missing some
> de-duplication logic that
> is part of the go fetcher), and regenerations to all the recipes completed.
>
> The recipes all have BB_GIT_SHALLOW = "1" now (for testing), and use tag=
> when the discovery hasn't "unshallowed" a clone and the reference is a tag.
>
> shallow=1 is still in the src_uri entries, as I mentioned it is an
> indication of intent
> that I'm going to leverage in the future. It simply means, the
> go-mod-vcs process
> thinks that this repository will work in shallow mode.

The changes are on master-next. I also confirmed that:

BB_GENERATE_SHALLOW_TARBALLS = "1"
BB_GIT_SHALLOW = "1"
bitbake cni -c fetch

Passes for me.

Bruce

>
> Cheers,
>
> Bruce
>
> >
> > Regards,
> > Qi
> >
> > On 12/30/25 20:33, Bruce Ashfield wrote:
> >
> >
> >
> > On Tue, Dec 30, 2025 at 12:11 AM Bruce Ashfield via lists.yoctoproject.org 
> > <[email protected]> wrote:
> >>
> >>
> >>
> >> On Mon, Dec 29, 2025 at 11:23 PM Chen, Qi <[email protected]> wrote:
> >>>
> >>> Hi Bruce,
> >>>
> >>>
> >>>
> >>> The new go-mod-vcs recently introduced in meta-virt  has some some 
> >>> problems.
> >>>
> >>>
> >>>
> >>> The first and most significant one is the misuse of 
> >>> BB_GIT_SHALLOW_EXTRA_REFS. It causes fetching failure when shallow 
> >>> tarball generation is enabled.
> >>
> >>
> >> I wouldn't call it a misuse, it is actually required to make the support 
> >> work
> >> and attempt to save some download space. There are thousands of 
> >> dependencies
> >> for some of the recipes and MANY of them have tags that aren't on 
> >> branches, or
> >> aren't at the tip of branches, so those refs are there to force a deep 
> >> enough fetch
> >> or to ensure that bitbake does the same "deshallowing"  as was done during
> >> generation.
> >>
> >> I could probably switch it out for tag= in the different entries. I've 
> >> made that
> >> tweak and will run some tests.
> >>
> >>
> >>>
> >>> Use the following steps to reproduce the error:
> >>>
> >>> Add in local.conf:
> >>>
> >>> BB_GENERATE_SHALLOW_TARBALLS = "1"
> >>>
> >>> BB_GIT_SHALLOW = "1"
> >>>
> >>> bitbake cni -c fetch
> >>>
> >>>
> >>>
> >>> Error message: fatal: couldn't find remote ref v0.0.4
> >>>
> >>> Root cause: the repos specified in SRC_URI does not contain the required 
> >>> extra refs specified by BB_GIT_SHALLOW_EXTRA_REFS.
> >>
> >> I run with that all the time, I've never seen it, those 
> >> BB_GIT_SHALLOW_EXTRA_REFS are
> >> not magic, they come directly from the repositories during discovery and 
> >> are required to deshallow
> >> a repository.
> >>
> >> My tests with the tag parameter may solve the issue. So stay tuned, I have 
> >> that and several other
> >> changes pending. But none of them will be until the end of next week once 
> >> I am back in the office.
> >>
> >>>
> >>>
> >>>
> >>> The second one is the duplicate entries in SRC_URI. Example: errdefs in 
> >>> docker-compose.
> >>>
> >>>
> >>
> >>
> >> It builds fine here, what issues are you seeing with it ? Are you using VCS
> >> mode ? or hybrid ?
> >
> >
> > There are multiple places that the vcs generator looks for (and removes 
> > duplicates).
> > I added another and am testing it. So once I fix the shallow clone logic, I 
> > can push
> > this as well.
> >
> > I was able to build both modes locally, so it is a cosmetic fix, but worth 
> > doing.
> >
> > Cheers,
> >
> > Bruce
> >
> >
> >>
> >>
> >> You can be assured that anything I pushed has been built many times, and 
> >> has
> >> been runtime tested. So the first information you need to provide is more 
> >> details
> >> about what you are building, so I can track down the differences.
> >>
> >>>
> >>> The third one is the ‘shallow=1’ parameter in SRC_URI. The problem is 
> >>> that git fetcher does not support such parameter.
> >>>
> >>> In fetch2/git.py: ud.shallow = d.getVar("BB_GIT_SHALLOW") == "1"
> >>>
> >>> So I guess these could be removed? And switching to use 
> >>> BB_GIT_SHALLOW:pn-xxx = “1”?
> >>
> >>
> >> No. I plan to add more support for that later, it just isn't ready yet. 
> >> They will stay.
> >>
> >>>
> >>>
> >>> P.S.
> >>>
> >>> I sent a related patch to bitbake: 
> >>> https://lists.openembedded.org/g/bitbake-devel/message/18656
> >>>
> >>> The problem in bitbake is revealed by the current SRC_URI settings in 
> >>> meta-virt.
> >>>
> >>> If you get similar error, you can apply the above patch.
> >>
> >>
> >> If I was going to see that error, I would have already ...
> >>
> >> Bruce
> >>
> >>
> >>>
> >>>
> >>>
> >>> Regards,
> >>>
> >>> Qi
> >>
> >>
> >>
> >> --
> >> - Thou shalt not follow the NULL pointer, for chaos and madness await thee 
> >> at its end
> >> - "Use the force Harry" - Gandalf, Star Trek II
> >>
> >>
> >>
> >>
> >
> >
> > --
> > - Thou shalt not follow the NULL pointer, for chaos and madness await thee 
> > at its end
> > - "Use the force Harry" - Gandalf, Star Trek II
> >
> >
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>
> 
>


-- 
- 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 (#9517): 
https://lists.yoctoproject.org/g/meta-virtualization/message/9517
Mute This Topic: https://lists.yoctoproject.org/mt/116993898/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/unsub 
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to