Date
1 - 6 of 6
Inclusive Language Proposal for YP/OE
|
Jon Mason
From the beginning, OpenEmbedded and The Yocto Project have always
strived to be as inclusive as possible to all races, sexes, orientations, religions, nationalities, and any other thing which might divide people. As continuation of this striving, there are suggested changes below that are being proposed to make the projects more inclusive and show the community as the professional, friendly, and welcoming group that it is. There are words in use by the projects directly or one of its derivative layers that could be offensive to some. For more information on which words we selected and why, please consult https://inclusivenaming.org/word-lists/overview/ In the process of changing these, we are using this opportunity to make the terms more obvious and useful, as well as removing cruft and other unused code. This is the pure definition of a win-win solution. With this in mind, a group of people have tried to identify issues and come up with a plan to address these. We’ve divided the tasks into 3 areas: bitbake variables, oe-core variables, and everything else. Bitbake Variables Taking issues in turn, for bitbake: For BB_DISKMON_DIRS, the actions "ABORT, STOPTASKS and WARN" would become "HALT, NO_NEW_TASKS and "WARN". BB_ENV_WHITELIST -> BB_ENV_PASSTHROUGH BB_ENV_EXTRAWHITE -> BB_ENV_PASSTHROUGH_ADDITIONS BB_HASHCONFIG_WHITELIST -> BB_HASHCONFIG_IGNORE_VARS BB_SETSCENE_ENFORCE_WHITELIST -> BB_SETSCENE_ENFORCE_IGNORE_TASKS BB_HASHBASE_WHITELIST -> BB_BASEHASH_IGNORE_VARS MULTI_PROVIDER_WHITELIST -> BB_MULTI_PROVIDER_ALLOWED BB_STAMP_WHITELIST and BB_STAMP_POLICY -> delete the code (already merged) basewhitelist and taskwhitelist as used in sigdata/siginfo will need to be renamed and older file usage of the variables renamed at import for backwards compatibility. The variables in bitbake along with usage of abort will be renamed as appropriate. For most variables, errors will be shown to the user if the old variable names are set. Mostly this can be done in event hooks but some like the BB_ENV changes will need special handling. These changes hopefully improve consistency (e.g. a consistent BB_ prefix and BASHHASH as terminology used elsewhere) and also improve the description of the variables to be more understandable to users. OE-Core Variables For OE-Core, the proposals are: For blacklist.bbclass, the proposal is to add the functionality to the anonymous Python in base.bbclass instead. PNBLACKLIST[xxx] would become SKIP_RECIPE[xxx]. INHERIT_BLACKLIST would simply be dropped. SSTATE_DUPWHITELIST -> SSTATE_ALLOW_OVERLAP_FILES CVE_CHECK_PN_WHITELIST -> CVE_CHECK_SKIPRECIPE CVE_CHECK_WHITELIST -> CVE_CHECK_IGNORECVE SYSROOT_DIRS_BLACKLIST -> SYSROOT_DIRS_IGNORE LICENSE_FLAGS_WHITELIST -> LICENSE_FLAGS_ACCEPTED UNKNOWN_CONFIGURE_WHITELIST -> UNKNOWN_CONFIGURE_OPT_IGNORE SDK_LOCAL_CONF_BLACKLIST -> ESDK_LOCALCONF_REMOVE SDK_LOCAL_CONF_WHITELIST -> ESDK_LOCALCONF_ALLOW SDK_INHERIT_BLACKLIST -> ESDK_CLASS_INHERIT_DISABLE TUNEABI_WHITELIST - already removed as obsolete For the ICECC_USER_XXX and ICECC_SYSTEM_XXX, we think these can likely be merged into single variables: ICECC_USER_CLASS_BL -> ICECC_CLASS_DISABLE ICECC_SYSTEM_CLASS_BL -> ICECC_CLASS_DISABLE ICECC_USER_PACKAGE_WL -> ICECC_RECIPE_ENABLE ICECC_USER_PACKAGE_BL -> ICECC_RECIPE_DISABLE ICECC_SYSTEM_PACKAGE_BL -> ICECC_RECIPE_DISABLE 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. Everything else The migration plan includes writing a script to assist with the migration. In many cases it can likely make the translation. In cases where that isn’t possible, it will aim to list the areas the user needs to fix references. A warning mechanism will be added to bitbake to detect usage of old variable names (post parsing), except for BB_ENV issues which will likely need special handling. A (limited) conversion script will be created to help with the migration. For those instances where a 1-1 mapping is not achievable, a list of the occurrences and what it should be changed to will occur. Patch files in OE to be renamed: 11_tcpd_blacklist.patch -> 11_tcpd_blocklist.patch mount.blacklist -> mount.disallow 0001-lxdm.conf.in-blacklist-root-for-release-images.patch -> 0001-lxdm.conf.in-deny-root-for-release-images.patch 022-RH-Remove-the-property-blacklist-exception-builtin.patch -> 022-RH-Remove-the-default-property-exception-builtin.patch 0001-Cargo.toml-do-not-abort-on-panic.patch -> 0001-Cargo.toml-do-not-exit-on-panic.patch 0004-Cargo.toml-do-not-abort-on-panic.patch -> 0004-Cargo.toml-do-not-exit-on-panic.patch Also, there are a few others outside of OE that should probably be patched too. Branch Names The “master” branches on the relevant OpenEmbedded and Yocto Project git trees will be changed to an alternative name at some point in the future. The current preferred name is “devel”. There is no time table for this currently, and there is no obligation or requirement to change the branch name for any downstream project which is beyond the project’s remit. Similarly, there is no need to change any recipes that are using a “master” branch as part of the SRC_URI. Those are outside the scope of YP/OE and this effort. Note These changes are only to bitbake and OE-Core. There is no requirement to change any other layers but we’d note consistency is encouraged and helpful to users. Helping If you would like to help, please put your name by the items in question on the inclusive language wiki page. https://wiki.yoctoproject.org/wiki/Inclusive_language Thanks Special thanks to Richard Purdie, Michael Opdenacker. Marta Rybczynska, Scott Murray, Jan-Simon Moeller, Saul Wold, and Armin Kuster for providing their time, technical details, text, and feedback on this task. |
|
|
|
On 24/01/2022 16:17, Jon Mason wrote:
From the beginning, OpenEmbedded and The Yocto Project have always This is an excellent proposal, the new variable names for bitbake & oe-core are clear and easy to understand. Everything elseThe layer index may need some modification to handle different layers having different names for the in-development branch. We could implement the layer index changes first to support other layers which rename their master branch. I'm going to bite the bullet with meta-linux-mainline and rename the master branch to "dev" this week to see what happens. Similarly, there is no need to change any recipes that are using aThanks all, it's great to see this moving forward! -- Paul Barker Principal Software Engineer SanCloud Ltd e: paul.barker@... w: https://sancloud.co.uk/ |
|
|
|
Ross Burton <ross@...>
On Mon, 24 Jan 2022 at 16:18, Jon Mason <jdmason@...> wrote:
CVE_CHECK_PN_WHITELIST -> CVE_CHECK_SKIPRECIPEThis 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 |
|
|
|
Mikko Rapeli <mikko.rapeli@...>
Hi,
On Tue, Jan 25, 2022 at 04:30:40PM +0000, Ross Burton wrote: On Mon, 24 Jan 2022 at 16:18, Jon Mason <jdmason@...> wrote:Please don't include CVE twice in the variable name, that's was annoying and justCVE_CHECK_PN_WHITELIST -> CVE_CHECK_SKIPRECIPEThis is the only one that sticks out to me. I think it needs another got used to the CVE_CHECK_WHITELIST one. CVE_CHECK_IGNORE would do. Cheers, -Mikko Other than that, +1. |
|
|
|
Peter Kjellerstedt
toggle quoted message
Show quoted text
-----Original Message-----[cut] For license handling, we’d use the opportunity to clean up theI 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 |
|
|
|
Marta Rybczynska
On Mon, Jan 24, 2022 at 5:18 PM Jon Mason <jdmason@...> wrote: CVE_CHECK_PN_WHITELIST -> CVE_CHECK_SKIPRECIPE 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 |
|
|