Hi Richard, I hope you had an enjoyable summer! Picking up on this thread now, almost half a year later :) Sorry for the late reply but turned out (a little surprising) that I’m going to have a

Wind River already has a mechanism to do something like this, called templates. https://github.com/WindRiver-Labs/wr-template/tree/WRLINUX_10_21_BASE Each template can have (optionally): # README

<richard.purdie@...> wrote: This could be a subset of a broader feature, one that allows adding and removing pre-canned 'config fragments' to local.conf. The proposal is to have such

lists.openembedded.org wrote: I've gone ahead and sent some patches for this for OE-Core and BitBake. There is more work to do so if anyone has a few minutes and wants to clean up a few more file

Hi all, Today I’m excited to publish a tool I’ve been developing internally for about a year now. It is called ‘yb’, and you can think of it like a cross between kas, Google’s repo, and

Hi, Just chiming in quickly. IMO using Dunfell 3.1.10 is as bad as using Honister 3.4.4. Even though we say Dunfell is an LTS, its the branch that is, not the tag. The point would be to say when a

lists.openembedded.org wrote: Some of this is autogenerated from the autobuilder and we can't simply remove it as it needs to stay for the older releases. We'll likely need to tweak the code to better

Hi Lee Thanks for the milestone release! Have you seen the discussion on the Openembedded-architecture mailing list? It seems there's a consensus to drop meta-gplv2 from master, and also from the

I usually google "yocto releases" and the first result is what you need (all the maintenance and EOL details): https://wiki.yoctoproject.org/wiki/Releases -- Denys

I'm reluctant to add even more things to the banner, there more you have there, the more it becomes 'noise'. But we can have a link to the releases wiki and the lifecycle policy in it, that does not

Two things which would help users: - LTS releases (the longer the better) so that users can stick with an OE version for longer without it becoming EOL. OE 3.1 has been a huge success in that

Keep in mind that the LTS are still comparatively new in the timescales people work within and that we have changed and defined a new policy comparatively recently. A large portion of this is a social

Oops, forgot the link to the bug: https://bugzilla.yoctoproject.org/show_bug.cgi?id=14503 Don't hesitate to add your comments directly to Bugzilla. Thanks Michael. -- Michael Opdenacker,

Greetings, Exactly. I filed a bug about this last year but I don't know how to fix it. In a few words, I'd like to add "Supported until MM/YYYY" to the description of each supported release. This

I tend to agree that warnings popping out of nowhere when the stable branch is close to (or beyond) EOL is 'too late' - if you got yourself into that situation, you're likely to have a broader

Who is the user base you're referring to? The end customer? They don't see build logs or EOL warnings. The OEM creating releases to add new features to the boxes in the field? They would see the EOL

Hi, I agree. For those active in the community the LTS and release statuses are clear but for outsiders not. I can't see the branch and release status with 2 clicks from

We are trying to use technology to solve a social problem. No amount of tweaking the code will stop people from making poor choices. How can we do a better job of communicating bad practices to the

Em seg., 1 de ago. de 2022 às 19:41, Richard Purdie <richard.purdie@...> escreveu: What about security flaws that aren't fixed and could lead to a compromised device and people not knowing they were

Taking something like Dunfell where it was originally for two years, then was extended you could end up with the date not agreeing with the reality in some checkouts if they weren't updated. There is