Either that, or it can hold multiple versions... -- Regards, Denys Dmytriyenko <denis@...> PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964 Fingerprint: 25FC E4A5 8A72 2F69 1186

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

All, The layer has been updated and moved to git.yoctoproject.org under a central mixin repo called "meta-lts-mixins", branch

Hi, Just a reminder about our upcoming OpenEmbedded Happy Hour on July 28 for Europe/Americas timezones @ 1700/5pm UTC (1pm ET / 10am

Paul, Thanks for the review! Right, good point. I put it there for testing and totally forgot about it. Sure, will add a standard MIT one. Yeah, it was missing because GitHub is a temporary

<mark.hatle@...> wrote: Yes, see https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=dunfell&id=5981a05525442f1a0db1c4e710b319dbf1fbba8b I missed that one, but it seems safe

"Denys Dmytriyenko" <denis@...> wrote: Hi Denys, This looks like a good initiative. A couple of initial comments: layer.conf contains `PREFERRED_VERSION_linux-yocto ?= "5.10%"`. It'd be

Did someone already backport the change to Dunfell to fix the module.lds for out of tree kernel builds? Master commit 596b0474d3d? For gatesgarth, we ended up porting a copy of this into our

All, Recently several Yocto Project members have expressed interest in being able to upgrade the Linux kernel in Dunfell LTS release from 5.4 to 5.10. Both of those Linux kernel versions are

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

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

The view I've also had and used to explain to others. There are two scopes of variables in OE. global and recipe specific. Adding an override anywhere else, really adds additional (hidden) scopes

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

(trimmed to add a minor comment) In this case ${PN} is just a name. It's because PACKAGES contains ${PN} by default. Really it's RDEPENDS_<package>. Which is distinctly different

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

The part of the code I worked on, the override was used as an optimization to avoid: d.getVar("RDEPENDS_%s" % package) or d.getVar("RDEPENDS") (and similar for all of the other variables that could

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

Hi, I am getting error in do_image_rdk function while building the core-minimal-image for the rdk code. Please let me know how can i debug the error and where to see the full error log that can help

Well, I am not asking we support both forever, but that we offer a proper transition period. For most key (and public) layers, it might be an option to switch 'quickly' enough, but for developers