Re: [OE-core] [oe] Inclusive Language Proposal for YP/OE

2022-02-21 Thread Marta Rybczynska
On Mon, Jan 24, 2022 at 5:18 PM Jon Mason  wrote:

> CVE_CHECK_PN_WHITELIST -> CVE_CHECK_SKIPRECIPE
> CVE_CHECK_WHITELIST -> CVE_CHECK_IGNORECVE
>

When running master-next I have found one missing rename, cve-check has
"CVE STATUS" result
which is still Patched, Unpatched, Whitelisted. I propose to rename
Whitelisted to Ignored to be in-line
with the variable rename.

Is there anyone using the states in scripting or other tools today?

Marta

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162018): 
https://lists.openembedded.org/g/openembedded-core/message/162018
Mute This Topic: https://lists.openembedded.org/mt/89289634/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [oe] Inclusive Language Proposal for YP/OE

2022-01-28 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-de...@lists.openembedded.org  de...@lists.openembedded.org> On Behalf Of Jon Mason
> Sent: den 24 januari 2022 17:18
> To: yo...@lists.yoctoproject.org; Patches and discussions about the oe-
> core layer ; OpenEmbedded Devel
> List 
> Subject: [oe] Inclusive Language Proposal for YP/OE

[cut]

> For license handling, we’d use the opportunity to clean up the
> WHITELIST_(ANY LICENSE) syntax and replace it with a
> INCOMPATIBLE_LICENSE_ALLOWED_RECIPES, which would be a list of 
> recipes which are of a blocked the INCOMPATIBLE_LICENSE list.

I am not so sure about this name. Not only is it extremely long, 
but at least I would like to revise the entire system of how 
licenses are handled. The major reason for this is that our 
legal department requires us to have a list of allowed licenses 
rather than a list of disallowed licenses. Thus we have a 
COMPATIBLE_LICENSES variable. We then set INCOMPATIBLE_LICENSE 
to AVAILABLE_LICENSES - COMPATIBLE_LICENSES. However, after the 
introduction of all official SPDX licenses into OE-Core a while 
ago this became problematic as the current implementation will 
go through all licenses specified in INCOMPATIBLE_LICENSE many, 
many times during recipe parsing, which caused the time to parse 
all recipes to increase three times for us. Thus I would like to 
implement proper support for COMPATIBLE_LICENSES in addition to 
the INCOMPATIABLE_LICENSE variable to allow choosing the option 
that suits the situation best.

However, in either case there would still need to be a way to 
specify exceptions to the incompatible licenses, which is why I 
would prefer that the name is not locked to the 
INCOMPATIBLE_LICENSE variable. Here are a couple of alternatives:

* LICENSE_EXCEPTIONS
* ALLOWED_RECIPES
* LICENSE_ALLOWED_RECIPES

It is also that the WHITELIST variables have two use cases today, 
one is to allow a _recipe_ to be built and the other is to allow 
a _package_ to be added to an image even if it has an incompatible 
license. The first use case can just as easily be achieved by 
setting INCOMPATIBLE_LICENSE:pn-foo = "" for a recipe foo that 
shall be allowed to be built even if it has an incompatible 
license. With this in mind, maybe the variable should actually be 
an image variable and specify a list of allowed packages instead, 
e.g., IMAGE_ALLOWED_PACKAGES. Whether the variable with a list of 
allowed recipes is then still needed or if it is enough to 
manipulate INCOMPATIBLE_LICENSE as per above can be discussed.

//Peter


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161096): 
https://lists.openembedded.org/g/openembedded-core/message/161096
Mute This Topic: https://lists.openembedded.org/mt/88760881/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [oe] Inclusive Language Proposal for YP/OE

2022-01-26 Thread Mikko Rapeli
Hi,

On Tue, Jan 25, 2022 at 04:30:40PM +, Ross Burton wrote:
> On Mon, 24 Jan 2022 at 16:18, Jon Mason  wrote:
> > CVE_CHECK_PN_WHITELIST -> CVE_CHECK_SKIPRECIPE
> > CVE_CHECK_WHITELIST -> CVE_CHECK_IGNORECVE
> 
> This is the only one that sticks out to me.  I think it needs another
> _, SKIP_RECIPE and IGNORE_CVE.

Please don't include CVE twice in the variable name, that's was annoying and 
just
got used to the CVE_CHECK_WHITELIST one. CVE_CHECK_IGNORE would do.

Cheers,

-Mikko

> Other than that, +1.
> 
> Will we have a bit of logic to detect the obsolete names being set and
> emit warnings/errors?
> 
> Ross

> 
> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160962): 
https://lists.openembedded.org/g/openembedded-core/message/160962
Mute This Topic: https://lists.openembedded.org/mt/88675507/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [OE-core] [oe] Inclusive Language Proposal for YP/OE

2022-01-25 Thread Ross Burton
On Mon, 24 Jan 2022 at 16:18, Jon Mason  wrote:
> CVE_CHECK_PN_WHITELIST -> CVE_CHECK_SKIPRECIPE
> CVE_CHECK_WHITELIST -> CVE_CHECK_IGNORECVE

This is the only one that sticks out to me.  I think it needs another
_, SKIP_RECIPE and IGNORE_CVE.

Other than that, +1.

Will we have a bit of logic to detect the obsolete names being set and
emit warnings/errors?

Ross

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160946): 
https://lists.openembedded.org/g/openembedded-core/message/160946
Mute This Topic: https://lists.openembedded.org/mt/88675507/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-