I think we put a warning on master and forwards but not older bitbakes. Cheers, Richard

Thanks for reporting this, it helps to know this is happening as we'll probably start seeing odd error reports for the brownouts. I've updated the conversion script I mentioned earlier in this thread

Yes, exact timing to be determined but hopefully sooner than later (before April release). Cheers, Richard

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 th

I'm really trying to say it is another change we could potentially make (in the spirit of the rest of the list). The license functions are like spaghetti and trying to fix up the tests to work after I

At the very least we probably have to detect usage of old variables. There is an argument that compatibility could be retained for some of them for a transition period and previously there has been a

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

There are releases of hardknott and dunfell currently in QA so this won't make it in until the ones after that. I understand the concern however I don't think it is reasonable to wait that long. You d

I have continued to work on this and I now think we're as ready as we'll ever be with the core. I have: * submitted a section for the migration guide documenting the conversion process * increased the

Hi Marco, I agree it is important this is documented. I've sent a patch to the manuals to add a section to the 3.4 migration guide: https://lists.yoctoproject.org/g/docs/message/1589 Does that help? H

Hi All, I've spent quite a bit of time seeing how to progress things. I now have a script which can convert layers and seems to have reasonable success on OE-Core, bitbake, yocto-docs, meta-yocto, met

I think that defeats the idea of specific purpose layers? Cheers, Richard

Should the layer be called kernel-5.10 since there potentially may be other versions? Cheers, Richard

Hi All, I now have an actual proposed plan for changing override syntax which I hope will mitigate the issues raised in the previous discussion as far a is possible whilst still letting the project mo

Branch updated, it now lets a core-image-sato build successfully. Cheers, Richard

Overrides are one of the key things which make OE function as an architecture and how a lot of the "magic" in our metadata happens. There is a hierarchy of overrides, some are system wide some are loc

Just to update, I have an experiment: http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=rpurdie/overrides-convert This contains a conversion script which can convert poky to use ":" instead of

I'm not sure it is going to be feasible to take two years to make this kind of transition. I've been looking for alternatives and one possibility may be semi-automated translation. By that, I mean tha

I have to admit I'm leaning the other way, make this explicit and hope that it actually helps users understand overrides a little better by making it clear. If we support both forms, firstly, few of t

This is the dilemma. We hear a lot about usability and the syntax being confusing and hard to use/understand. If we try and improve that, we are going to have to break compatibility at some point/leve