From: Jon Mason <email@example.com>
Patches and discussions about the oe-core layer
OpenEmbedded Devel List
Subject: Inclusive Language Proposal for YP/OE
Date: Mon, 24 Jan 2022 11:17:58 -0500 [thread overview]
Message-ID: <CAPoiz9wL16OTzxNHdw_5-L72GOHkhhM0--WZF7An071cx6sr_A@mail.gmail.com> (raw)
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
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.
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.
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.
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
Also, there are a few others outside of OE that should probably be patched too.
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
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.
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.
If you would like to help, please put your name by the items in
question on the inclusive language wiki page.
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.
next reply other threads:[~2022-01-24 16:18 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-24 16:17 Jon Mason [this message]
2022-01-25 8:26 ` Inclusive Language Proposal for YP/OE Paul Barker
2022-01-26 1:51 ` [yocto] " Paul Eggleton
2022-01-25 15:50 ` [OE-core] " Chuck Wolber
2022-01-25 16:00 ` [oe] " Ross Burton
2022-01-25 16:30 ` [oe] " Ross Burton
2022-01-26 8:37 ` Mikko.Rapeli
2022-01-25 23:07 ` [OE-core] " Randy MacLeod
2022-01-29 3:30 ` [oe] " Peter Kjellerstedt
2022-02-04 13:21 ` [OE-core] " Enrico Scholz
2022-02-04 13:58 ` [oe] " Alexander Kanavin
2022-02-04 14:16 ` Enrico Scholz
2022-02-04 15:01 ` Bryan Evenson
2022-02-04 18:38 ` Enrico Scholz
2022-02-04 19:12 ` Alexander Kanavin
2022-02-04 20:08 ` Enrico Scholz
2022-02-21 8:21 ` [oe] " Marta Rybczynska
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).