Hi,

On Tue, 2 Nov 2021, at 10:32, Martin Jansa wrote:

There is even bigger issue with git repos from github.com now:

I don't think this is a bigger issue because I don't see this warranting a default change. It is just an upstream protocol support change and we will update the respective recipes. If we don't, January will force us to. Maybe, we should have a warning in git fetcher for GitLab on the git protocol? I reckon it is reasonable to push people to update their recipes.

There is even bigger issue with git repos from github.com now:

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:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=14185

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?

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:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14185
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.

I suspect we'll see selftest failures as the dict of url parameters may lead to
non-deterministic urls from recipetool but as ever, I'll try and work through
the issues.
Cheers,
Richard

On Tue, 27 Jul 2021 at 18:54, Denys Dmytriyenko <denis@...> wrote:

Not necessarily. Providing latest LTS kernels for Dunfell also seems very
specific. For every extra year of official support for Dunfell, this can
offer a new LTS kernel version, that can be selected by PREFERRED_VERSION.
Creating a new branch for each kernel version seems wasteful. But I can do
that as well, if needed.

Hello Denys,

if I would like to add a 'dunfell/gizmo' branch to that repository, how
would it work if a given build needs both the kernel and the gizmo? Is the
repo supposed to be cloned twice into two separate locations on disk?
The page
https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS#LTS_.E2.80.9CMixin.E2.80.9D_repositories
doesn't make it clear either.

On Friday, 10 September 2021 19:54:11 NZST Richard Purdie wrote:

Do we change the master branch to something else? I personally have a
preference for "devel" over "main" regardless of what others are doing
as it matches what it is in our case. Changing that alone is days of
work for me trying to get all our automation to deal with it.

If the master branch gets renamed, what about yocto-buildhistory,
yocto-buildstats and yocto-testresults? Would master branches or tags
get renamed as well? Is this part of the day's worth of work you
mentioned?

Would the Yocto Project enforce a renaming in all the repos they host?

What about layer-index?

All good questions. The days of work I was mentioning would cover some of
this but there is a lot to do, more than people realise.

It's not readily visible in the UI, but the layer index already has an
internal means of specifying an alternative branch name that can be set by
admins on a per layer-branch basis. I deliberately haven't exposed it as I
thought it was better that people keep things simple and just use the same
scheme as OE-Core for their branches, but the mechanism exists. We could also
fairly easily add automatic mapping in the layer index code if we choose a
standard name to replace master, as well as changing the name shown in the UI
(and change the assumptions that "master" is the main branch, there are a few
sprinkled through the code). I think even if we do nothing else we'll have to
address those assumptions as there will probably be layer maintainers who want
to change (if they have not done so already). If it's not clear, I can
volunteer to take care of this ;)

I remembered what I was missing too:

j) Convert to SPDX license names

We should really switch to using SPDX license names in the LICENSE field
directly and be able to drop the current SPDX mapping code.

This I'm not sure of. Are these mappings costing us much? AFAICT we'd only
gain a bit of code simplification at the expense of making things a little bit
harder for our users.

Do we change the master branch to something else? I personally have a
preference for "devel" over "main" regardless of what others are doing
as it matches what it is in our case. Changing that alone is days of
work for me trying to get all our automation to deal with it.

If the master branch gets renamed, what about yocto-buildhistory,
yocto-buildstats and yocto-testresults? Would master branches or tags
get renamed as well? Is this part of the day's worth of work you
mentioned?

Would the Yocto Project enforce a renaming in all the repos they host?

What about layer-index?

All good questions. The days of work I was mentioning would cover some of
this but there is a lot to do, more than people realise.

I remembered what I was missing too:

j) Convert to SPDX license names

We should really switch to using SPDX license names in the LICENSE field
directly and be able to drop the current SPDX mapping code.

On Thu, Sep 16, 2021 at 7:28 PM Khem Raj <raj.khem@...> wrote:

On Thu, Sep 16, 2021 at 9:45 AM Mayank Agarwal
<mayank77fromindia@...> wrote:

Dear Experts,

Is there any way we can disable bbappend file from another meta-layer in the current
meta-layer or recipe file.It will be of great help.If we can use PNBLACKLIST or BBMASK
to disable bbappend file.

bbappends can not be undone sadly, maybe you can try some BBMASKing it
if its in unique location perhaps.

See here one example:
https://github.com/vu-plus/meta-vuplus/blob/master/conf/layer.conf#L4
vs one allowing them
https://git.openembedded.org/meta-handheld/tree/conf/layer.conf#n8
cheers
A.A.

Regards
Mayank

On Thu, Sep 16, 2021 at 9:45 AM Mayank Agarwal
<mayank77fromindia@...> wrote:

Dear Experts,

Is there any way we can disable bbappend file from another meta-layer in the current
meta-layer or recipe file.It will be of great help.If we can use PNBLACKLIST or BBMASK
to disable bbappend file.

bbappends can not be undone sadly, maybe you can try some BBMASKing it
if its in unique location perhaps.

Regards
Mayank

Dear Experts,

Is there any way we can disable bbappend file from another meta-layer in the current
meta-layer or recipe file.It will be of great help.If we can use PNBLACKLIST or BBMASK
to disable bbappend file.

Regards
Mayank

Hi All,

We have a decision facing us with 3.5. There are a number of invasive issues
looming on the horizon and I'm not sure exactly what the best thing to do with
them is.

a) Inclusive language

A lot of variables potentially need renaming with varying options for backwards
compatibility. Do we add compatibility for all cases. How much do we help users
with migration? Is there wide support for the changes?

Do we change the master branch to something else? I personally have a preference
for "devel" over "main" regardless of what others are doing as it matches what
it is in our case.