I'm not terribly convinced it is. If the problem is that there's no way to clear the OVERRIDES, maybe we should just have a new verb to do that specifically rather than a new assignment operator

Is that an issue that needs to actually be fixed? This is just another example of weird BSP given by vendors to me, right? Resetting IMAGE_FSTYPES_collie to INITRAMFS_FSTYPES should be enough to fix

We have an interesting problem with initramfs images. They do something like: IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}" which looks innocent enough until a BSP does: IMAGE_FSTYPES_collie =

We're starting to hit a maturity level with our internal development using multiconfigs that we need a way to export this into an eSDK. Currently we're working on the ability to build a system, it's

Hi, Due to the Yocto Project Summit running during our regular OpenEmbedded Happy Hour today, we decided to move it down by 3 hours and have Happy Hour at the end of the Summit, May 26 @ 2000/8pm

> https://www.openembedded.org/wiki/OEDVM_2021 > https://pretalx.com/yocto-project-summit-2021/talk/BVZMYW/ > 1530 UTC on Zoom (link in the URL above) In preparation for the BSP discussion at today's

I think people will know what is appropriate in their own circumstances. There was an ask that some of these things be "documented" and I'm trying to do that as I think some of the things here are

Thanks for summarizing all this. So is the ask to forward this within the one's Employer? -armin

TLDR: The project is seen as mature, employers don't prioritise maintaining things and we're struggling for maintainers and help with day to day work Open source projects survive, not just through

I'm pleased to be able to announce that the project is planning to have the April 2022 release next year be our next LTS release. This fits in with our original announced plan of 2 year cycles

Part of the Yocto Project Summit (May 25-26, 2021), OpenEmbedded is hosting a Virtual Developer meeting. (https://pretalx.com/yocto-project-summit-2021/schedule/) Since this will be a virtual event,

Not sure if I understand the question, but maybe you're looking for this example (given in section 3.3.1): KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}" KERNEL_FEATURES_append_qemux86="

I see for Bitbake appends and prepends are overrides flavor. I still keep my position, generally there is no override component in appending and prepending regardless which life area is

Reminder, next Happy Hour is in one day - everyone is welcome to meet with fellow developers and chat about any interesting topics over Zoom. BYOB - bring your own beverage. -- Regards, Denys

Regarding second point in my post above I see example for kernel seems to use overrides-interface component, which however takes place in different code thus not visible in shown example yet chapter

I, for one, really like OVERRIDES mechanism! It may not be intuitive at first, but once mastered, it's a very powerful mechanism and, as Chris mentioned, allows doing layered (from generic to

As _append, _prepend, _remove are special cases of the override mechanism. That was one of the reasons for 2015 discussion during OEDEM to see if _append and _prepend need to be re-implemented to

I use Bitbake user manual mentioned chapter as knowledge source to get more about override mechanism as OVERRIDE variable description in YP Reference Manual refers to that document for more details.

If to use same chapter in order to continue my point regarding intersection of overriding and appending/prepending I don't see in example provided in bullet "Appending and Prepending:" any piece of

I am also not comfortable with two first examples provided in chapter myself referred previously too. The first one, short one: why is "_nooverride = blabla" component necessary? Will variable default