Re: Default branch names in git urls

Martin Jansa

There is even bigger issue with git repos from now:

bitbake git fetcher uses git:// protocol by default and as of today you can experience "short brownouts" and on January 11 it will all fail to fetch (and only fully populated PREMIRRORS can save you for a while, until SRCREV is updated).

Short statistics from current oe-core/master:
martin@jama:/OE/openembedded-core$ git grep git://github.* | grep -v protocol= | wc -l
martin@jama:/OE/openembedded-core$ git grep git://github.*protocol=https | wc -l
martin@jama:/OE/openembedded-core$ git grep git://github.*protocol=git | wc -l

54 from 74 recipes will fail to fetch in oe-core only.

On Fri, Oct 29, 2021 at 4:14 PM Richard Purdie <richard.purdie@...> wrote:
On Fri, 2021-10-29 at 15:45 +0200, Konrad Weihmann wrote:
> On 29.10.21 15:09, Richard Purdie wrote:
> > We've had concerns about the default behaviours of tools like git and how
> > they'll handle the default branch names going forward. There are also concerns
> > about what providers like github may do, and the potential impact on our tools
> > like recipetool.
> >
> > A bug was filed about some of this:
> >
> >
> >
> > I am frustrated not much has moved forward with some of the inclusive language
> > work and this bug is languishing too.
> >
> > We do aim to be explicit with our SRC_URI entries so having the branch specified
> > would seem to be the overall best thing to do here. I have done what was
> > suggested in the bug and sent out patches to add a warning to the fetcher and
> > updated the urls in OE-Core to include the branch name.
> >
> > The harder part of these changes is discussing and explaining them and putting
> > transition plans in place. I am trying to do that here (and I will also mention
> > in the next tech call and in the weekly status report).
> >
> > In the patch I've proposed there is a script, similar to the overrides
> > conversion one which converts metadata to add the branch name explicitly. It is
> > far from perfect but should probably help in the majority of cases.
> >
> > If there aren't objections I'll likely merge the core change. The warning change
> > will follow in a week or two once at least the layers being tested on the
> > autobuilder have updated. I'm worried a ton of warnings suddenly showing up
> > would mask out other real issues.
> Although the situation is a bit unfortunate I like the proposal and the
> script will likely make the transition less painful.
> Are you planning to turn the warning into an error at some point?

Yes, exact timing to be determined but hopefully sooner than later (before April



Join { to automatically receive all group messages.