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. 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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9514): https://lists.yoctoproject.org/g/meta-virtualization/message/9514 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]] -=-=-=-=-=-=-=-=-=-=-=-
