Hello, +layer maintainers to ensure they see that. -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com

wrote: Just as a warning, the code is actually confused. The base.bbclass code assumes it is a recipe name, the license_image code assumes it is a package name. All the more reason to come up with a

We need to be mindful that we need to resolve this to unblock the other language changes and feature creep here is potentially problematic. I do think it is worth trying to improve things rather than

The [3] should be https://git.openembedded.org/openembedded-core/commit/?id=311e61ae14b7216f5b98f1afe0e791644a07c9d0 that's where LAYERSERIES_CORENAMES was changed to kirkstone (it's not due to

It's not a typo. It's per design. The missing + is easier to spot than missing space after ". Still works in dunfell and earlier but likely not with master. This has both just to be extra super duper

Please note that INCOMPATIBLE_LICENSE_append += is bad. It should be: INCOMPATIBLE_LICENSE_append = " GPLv3 GPLv3+ LGPLv3 LGPLv3+" But probably it's a typo. -- Marco

Hi, Hmm, this rings a bell. Likely yes then :) But on the other hand this way we're quite explicit about what GPLv3 things we allow to compile. Compiling too much also hurts with compilation times

You should really try per-image INCOMPATIBLE_LICENSE :) Maintaining those whitelists/excludes is awkward, as developers constantly want more of them. Alex

Hi, Exactly, I'm using this in a lot of projects. Basically distro config has: INCOMPATIBLE_LICENSE_append += " GPLv3 GPLv3+ LGPLv3 LGPLv3+" and then various GPLv3 tools are allowed in build but

Hello everyone, There have been a number of failures in the autobuilder today [1] [2] due to the change currently sitting in master-next that switches LAYERSERIES_COMPAT from honister to

Common case seems to be allowing gdb in debug builds of distros which are otherwise free of GPLv3 etc, e.g.

Folks, I am working on a proposal to re-write how INCOMPATIBLE_LICENSES is used and processed to possibly include a COMPATIBLE_LICENSES variable as well, see PeterK's email [0] I am trying to

I'm working up something for (a) and at least the BitBake side of (i) (and also replacing other "abort" usage). One issue is there some variable names in Toaster code that look easy enough to change,

Thank RP for all that you have done, I will have a patch to master-next for the script shortly. I will start looking at the WHITELIST_<license> changes and review the old emails. Sau! -- Sau!

wrote: b), d), e), f), g) are now in master-next but will need debugging and impact other layers. I think a), c) and h) probably block merging, the remainder can follow post merge for

wrote: Let me follow up on where things are now at. I worked on the bitbake level rename support and we have a patch which resolves some of the issues above. 2) is fixed, 4) partially works and may

Hi All, I'm a little saddened/annoyed/frustrated that we're less that a week before feature freeze and yet there is still no mechanism in bitbake to handle variable deprecation/renaming. There has

This looks to be in good shape. Thank you to the reviewers for some excellent variable names.

This is a follow up to the Inclusive Language email I sent out on January 24 (see https://lore.kernel.org/yocto/CAPoiz9wL16OTzxNHdw_5-L72GOHkhhM0--WZF7An071cx6sr_A@.../). I'm adding a

Dear Alex, Richard was kind enough to forward my email. Thanks @Richard. I’m happy to continue the discussion here. Best Marius