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

By backward compatibility do you mean allowing a layer to use one of the offending variables? if so, what is the point? You mean like in a script? You mean this LF project?

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

Hi, We will be having an OpenEmbedded Happy Hour on Auguest 25 for Asia/Pacific timezones @ 2100/9pm UTC (5pm ET / 2pm

Hi, i am getting below errors on compiling moduleone using yocto.I am doing cross compilation and the toolchain path i am providing in moduleone

Hi Marco, I don't expect any layer which has separate branch for each OE release to migrate to new syntax in other branches than master. But for layers which are compatible across wider range of OE

Hi Richard, please apologize my question but I am not sure I have a clear vision of the global impact of this new feature across the branches because the answers above are confusing me. From what I

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

<peter.kjellerstedt@...> wrote: I am currently testing the change in dunfell and so far so good. If no issues are found support will be present in the 3.1.11 release currently scheduled for

<richard.purdie@...> wrote: Thank you very much Martin and Richard. Cheers A.A.

I forgot to mention: https://github.com/ros/meta-ros/pull/895 https://github.com/ros/meta-ros-webos/pull/18 and today added draft PR for meta-clang as

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

Yesterday I've spent some time migrating the layers I sometimes use. It's definitely not perfect, but it's useful as a starting point (I was even able to build an image with these changes). I've sent

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

Sooner the better is my view... Thanks for all of this, I know it's going to make things better longer term no matter when it switches over to the new format. (Also making the tune-XXX a first class

Hi Richard, thank you for your precious work. IMHO it is important to produce a clear documentation about the new features maybe providing some practical cases. Just my 2 cents, Cheers, -- Marco

Em qua., 28 de jul. de 2021 às 12:43, Richard Purdie <richard.purdie@...> escreveu: I believe your plan is good and given the new layers will work down to dunfell I see no big

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,

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