MIRRORS/poky
1
0
Fork 0
mirror of git://git.yoctoproject.org/poky.git synced 2025-07-19 21:09:03 +02:00
Code Issues Actions Packages Projects Releases Wiki Activity

make the documentation a bit more inclusive

Browse Source 
Except the name of variables which can't be changed only in the
documentation for obvious reasons and workflow or developement
explanations around the use of the "master" branch which cannot be
replaced with "development" branch instead, most of the non-inclusive
words that appear in https://inclusivenaming.org/word-lists/tier-1/
should have been replaced in this patch.

(From yocto-docs rev: 2755f35060084f7af356091de9dc144f85530fe2)

Signed-off-by: Quentin Schulz <foss+yocto@0leil.net>
Reviewed-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Quentin Schulz 2021-12-06 16:04:01 +01:00 committed by Richard Purdie
parent 99474e0d68
commit e71983bc7d
14 changed files with 151 additions and 159 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
documentation/bsp-guide/bsp.rst
View File

@ -1121,12 +1121,12 @@ list describes them in order of preference:
how to use these variables. how to use these variables.
If you build as you normally would, without specifying any recipes in If you build as you normally would, without specifying any recipes in
the :term:`LICENSE_FLAGS_WHITELIST`, the build stops and provides you the :term:`LICENSE_FLAGS_WHITELIST` variable, the build stops and provides
with the list of recipes that you have tried to include in the image you with the list of recipes that you have tried to include in the image
that need entries in the :term:`LICENSE_FLAGS_WHITELIST`. Once you enter that need entries in the :term:`LICENSE_FLAGS_WHITELIST` variable. Once you
the appropriate license flags into the whitelist, restart the build enter the appropriate license flags into it, restart the build to continue
to continue where it left off. During the build, the prompt will not where it left off. During the build, the prompt will not appear again since
appear again since you have satisfied the requirement. you have satisfied the requirement.
Once the appropriate license flags are on the white list in the Once the appropriate license flags are on the white list in the
:term:`LICENSE_FLAGS_WHITELIST` variable, you can build the encumbered :term:`LICENSE_FLAGS_WHITELIST` variable, you can build the encumbered

159
documentation/dev-manual/common-tasks.rst
View File

@ -5598,13 +5598,13 @@ file::
./mkefidisk-201804191017-sda.direct ./mkefidisk-201804191017-sda.direct
The following build artifacts were used to create the image(s): The following build artifacts were used to create the image(s):
ROOTFS_DIR: /home/stephano/build/master/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/rootfs ROOTFS_DIR: /home/stephano/yocto/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/rootfs
BOOTIMG_DIR: /home/stephano/build/master/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/share BOOTIMG_DIR: /home/stephano/yocto/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/share
KERNEL_DIR: /home/stephano/build/master/build/tmp-glibc/deploy/images/qemux86 KERNEL_DIR: /home/stephano/yocto/build/tmp-glibc/deploy/images/qemux86
NATIVE_SYSROOT: /home/stephano/build/master/build/tmp-glibc/work/i586-oe-linux/wic-tools/1.0-r0/recipe-sysroot-native NATIVE_SYSROOT: /home/stephano/yocto/build/tmp-glibc/work/i586-oe-linux/wic-tools/1.0-r0/recipe-sysroot-native
INFO: The image(s) were created using OE kickstart file: INFO: The image(s) were created using OE kickstart file:
/home/stephano/build/master/openembedded-core/scripts/lib/wic/canned-wks/mkefidisk.wks /home/stephano/yocto/openembedded-core/scripts/lib/wic/canned-wks/mkefidisk.wks
The previous example shows the easiest way to create an image by running The previous example shows the easiest way to create an image by running
in cooked mode and supplying a kickstart file and the "-e" option to in cooked mode and supplying a kickstart file and the "-e" option to
@ -5665,8 +5665,8 @@ in the ``scripts/lib/image/canned-wks`` directory and then by changing
the lines that specify the target disk from which to boot. the lines that specify the target disk from which to boot.
:: ::
$ cp /home/stephano/poky/scripts/lib/wic/canned-wks/directdisk-gpt.wks \ $ cp /home/stephano/yocto/poky/scripts/lib/wic/canned-wks/directdisk-gpt.wks \
/home/stephano/poky/scripts/lib/wic/canned-wks/directdisksdb-gpt.wks /home/stephano/yocto/poky/scripts/lib/wic/canned-wks/directdisksdb-gpt.wks
Next, the example modifies the ``directdisksdb-gpt.wks`` file and Next, the example modifies the ``directdisksdb-gpt.wks`` file and
changes all instances of "``--ondisk sda``" to "``--ondisk sdb``". The changes all instances of "``--ondisk sda``" to "``--ondisk sdb``". The
@ -5698,13 +5698,13 @@ Computing (nuc) :term:`MACHINE` the
./directdisksdb-gpt-201710090938-sdb.direct ./directdisksdb-gpt-201710090938-sdb.direct
The following build artifacts were used to create the image(s): The following build artifacts were used to create the image(s):
ROOTFS_DIR: /home/stephano/build/master/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/rootfs ROOTFS_DIR: /home/stephano/yocto/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/rootfs
BOOTIMG_DIR: /home/stephano/build/master/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/share BOOTIMG_DIR: /home/stephano/yocto/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/share
KERNEL_DIR: /home/stephano/build/master/build/tmp-glibc/deploy/images/qemux86 KERNEL_DIR: /home/stephano/yocto/build/tmp-glibc/deploy/images/qemux86
NATIVE_SYSROOT: /home/stephano/build/master/build/tmp-glibc/work/i586-oe-linux/wic-tools/1.0-r0/recipe-sysroot-native NATIVE_SYSROOT: /home/stephano/yocto/build/tmp-glibc/work/i586-oe-linux/wic-tools/1.0-r0/recipe-sysroot-native
INFO: The image(s) were created using OE kickstart file: INFO: The image(s) were created using OE kickstart file:
/home/stephano/poky/scripts/lib/wic/canned-wks/directdisksdb-gpt.wks /home/stephano/yocto/poky/scripts/lib/wic/canned-wks/directdisksdb-gpt.wks
Continuing with the example, you can now directly ``dd`` the image to a Continuing with the example, you can now directly ``dd`` the image to a
USB stick, or whatever media for which you built your image, and boot USB stick, or whatever media for which you built your image, and boot
@ -5724,11 +5724,11 @@ Mode) and uses a modified kickstart file. The example also uses the
``-o`` option to cause Wic to create the output somewhere other than the ``-o`` option to cause Wic to create the output somewhere other than the
default output directory, which is the current directory:: default output directory, which is the current directory::
$ wic create /home/stephano/my_yocto/test.wks -o /home/stephano/testwic \ $ wic create test.wks -o /home/stephano/testwic \
--rootfs-dir /home/stephano/build/master/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/rootfs \ --rootfs-dir /home/stephano/yocto/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/rootfs \
--bootimg-dir /home/stephano/build/master/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/share \ --bootimg-dir /home/stephano/yocto/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/share \
--kernel-dir /home/stephano/build/master/build/tmp/deploy/images/qemux86 \ --kernel-dir /home/stephano/yocto/build/tmp/deploy/images/qemux86 \
--native-sysroot /home/stephano/build/master/build/tmp/work/i586-poky-linux/wic-tools/1.0-r0/recipe-sysroot-native --native-sysroot /home/stephano/yocto/build/tmp/work/i586-poky-linux/wic-tools/1.0-r0/recipe-sysroot-native
INFO: Creating image(s)... INFO: Creating image(s)...
@ -5736,13 +5736,13 @@ default output directory, which is the current directory::
/home/stephano/testwic/test-201710091445-sdb.direct /home/stephano/testwic/test-201710091445-sdb.direct
The following build artifacts were used to create the image(s): The following build artifacts were used to create the image(s):
ROOTFS_DIR: /home/stephano/build/master/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/rootfs ROOTFS_DIR: /home/stephano/yocto/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/rootfs
BOOTIMG_DIR: /home/stephano/build/master/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/share BOOTIMG_DIR: /home/stephano/yocto/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/share
KERNEL_DIR: /home/stephano/build/master/build/tmp-glibc/deploy/images/qemux86 KERNEL_DIR: /home/stephano/yocto/build/tmp-glibc/deploy/images/qemux86
NATIVE_SYSROOT: /home/stephano/build/master/build/tmp-glibc/work/i586-oe-linux/wic-tools/1.0-r0/recipe-sysroot-native NATIVE_SYSROOT: /home/stephano/yocto/build/tmp-glibc/work/i586-oe-linux/wic-tools/1.0-r0/recipe-sysroot-native
INFO: The image(s) were created using OE kickstart file: INFO: The image(s) were created using OE kickstart file:
/home/stephano/my_yocto/test.wks test.wks
For this example, For this example,
:term:`MACHINE` did not have to be :term:`MACHINE` did not have to be
@ -7097,7 +7097,7 @@ Generating and Using Signed Packages
In order to add security to RPM packages used during a build, you can In order to add security to RPM packages used during a build, you can
take steps to securely sign them. Once a signature is verified, the take steps to securely sign them. Once a signature is verified, the
OpenEmbedded build system can use the package in the build. If security OpenEmbedded build system can use the package in the build. If security
fails for a signed package, the build system aborts the build. fails for a signed package, the build system stops the build.
This section describes how to sign RPM packages during a build and how This section describes how to sign RPM packages during a build and how
to use signed package feeds (repositories) when doing a build. to use signed package feeds (repositories) when doing a build.
@ -8392,11 +8392,11 @@ The OpenEmbedded build system can run tests on real hardware, and for
certain devices it can also deploy the image to be tested onto the certain devices it can also deploy the image to be tested onto the
device beforehand. device beforehand.
For automated deployment, a "master image" is installed onto the For automated deployment, a "controller image" is installed onto the
hardware once as part of setup. Then, each time tests are to be run, the hardware once as part of setup. Then, each time tests are to be run, the
following occurs: following occurs:
1. The master image is booted into and used to write the image to be 1. The controller image is booted into and used to write the image to be
tested to a second partition. tested to a second partition.
2. The device is then rebooted using an external script that you need to 2. The device is then rebooted using an external script that you need to
@ -8465,15 +8465,15 @@ not need any information in this section. You can skip down to the
":ref:`dev-manual/common-tasks:running tests`" section. ":ref:`dev-manual/common-tasks:running tests`" section.
If you did set :term:`TEST_TARGET` to "SystemdbootTarget", you also need to If you did set :term:`TEST_TARGET` to "SystemdbootTarget", you also need to
perform a one-time setup of your master image by doing the following: perform a one-time setup of your controller image by doing the following:
1. *Set EFI_PROVIDER:* Be sure that :term:`EFI_PROVIDER` is as follows:: 1. *Set EFI_PROVIDER:* Be sure that :term:`EFI_PROVIDER` is as follows::
EFI_PROVIDER = "systemd-boot" EFI_PROVIDER = "systemd-boot"
2. *Build the master image:* Build the ``core-image-testmaster`` image. 2. *Build the controller image:* Build the ``core-image-testmaster`` image.
The ``core-image-testmaster`` recipe is provided as an example for a The ``core-image-testmaster`` recipe is provided as an example for a
"master" image and you can customize the image recipe as you would "controller" image and you can customize the image recipe as you would
any other recipe. any other recipe.
Here are the image recipe requirements: Here are the image recipe requirements:
@ -9588,51 +9588,51 @@ If you examine the output or the log file, you see the failure during
| /bin/mkdir -p include/near | /bin/mkdir -p include/near
| /bin/mkdir -p include/near | /bin/mkdir -p include/near
| /bin/mkdir -p include/near | /bin/mkdir -p include/near
| ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/ | ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
0.14-r0/neard-0.14/include/types.h include/near/types.h 0.14-r0/neard-0.14/include/types.h include/near/types.h
| ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/ | ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
0.14-r0/neard-0.14/include/log.h include/near/log.h 0.14-r0/neard-0.14/include/log.h include/near/log.h
| ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/ | ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
0.14-r0/neard-0.14/include/plugin.h include/near/plugin.h 0.14-r0/neard-0.14/include/plugin.h include/near/plugin.h
| /bin/mkdir -p include/near | /bin/mkdir -p include/near
| /bin/mkdir -p include/near | /bin/mkdir -p include/near
| /bin/mkdir -p include/near | /bin/mkdir -p include/near
| ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/ | ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
0.14-r0/neard-0.14/include/tag.h include/near/tag.h 0.14-r0/neard-0.14/include/tag.h include/near/tag.h
| /bin/mkdir -p include/near | /bin/mkdir -p include/near
| ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/ | ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
0.14-r0/neard-0.14/include/adapter.h include/near/adapter.h 0.14-r0/neard-0.14/include/adapter.h include/near/adapter.h
| /bin/mkdir -p include/near | /bin/mkdir -p include/near
| ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/ | ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
0.14-r0/neard-0.14/include/ndef.h include/near/ndef.h 0.14-r0/neard-0.14/include/ndef.h include/near/ndef.h
| ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/ | ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
0.14-r0/neard-0.14/include/tlv.h include/near/tlv.h 0.14-r0/neard-0.14/include/tlv.h include/near/tlv.h
| /bin/mkdir -p include/near | /bin/mkdir -p include/near
| /bin/mkdir -p include/near | /bin/mkdir -p include/near
| ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/ | ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
0.14-r0/neard-0.14/include/setting.h include/near/setting.h 0.14-r0/neard-0.14/include/setting.h include/near/setting.h
| /bin/mkdir -p include/near | /bin/mkdir -p include/near
| /bin/mkdir -p include/near | /bin/mkdir -p include/near
| /bin/mkdir -p include/near | /bin/mkdir -p include/near
| ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/ | ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
0.14-r0/neard-0.14/include/device.h include/near/device.h 0.14-r0/neard-0.14/include/device.h include/near/device.h
| ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/ | ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
0.14-r0/neard-0.14/include/nfc_copy.h include/near/nfc_copy.h 0.14-r0/neard-0.14/include/nfc_copy.h include/near/nfc_copy.h
| ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/ | ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
0.14-r0/neard-0.14/include/snep.h include/near/snep.h 0.14-r0/neard-0.14/include/snep.h include/near/snep.h
| ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/ | ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
0.14-r0/neard-0.14/include/version.h include/near/version.h 0.14-r0/neard-0.14/include/version.h include/near/version.h
| ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/ | ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
0.14-r0/neard-0.14/include/dbus.h include/near/dbus.h 0.14-r0/neard-0.14/include/dbus.h include/near/dbus.h
| ./src/genbuiltin nfctype1 nfctype2 nfctype3 nfctype4 p2p > src/builtin.h | ./src/genbuiltin nfctype1 nfctype2 nfctype3 nfctype4 p2p > src/builtin.h
| i586-poky-linux-gcc -m32 -march=i586 --sysroot=/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/ | i586-poky-linux-gcc -m32 -march=i586 --sysroot=/home/pokybuild/yocto-autobuilder/nightly-x86/
build/build/tmp/sysroots/qemux86 -DHAVE_CONFIG_H -I. -I./include -I./src -I./gdbus -I/home/pokybuild/ build/build/tmp/sysroots/qemux86 -DHAVE_CONFIG_H -I. -I./include -I./src -I./gdbus -I/home/pokybuild/
yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/sysroots/qemux86/usr/include/glib-2.0 yocto-autobuilder/nightly-x86/build/build/tmp/sysroots/qemux86/usr/include/glib-2.0
-I/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/sysroots/qemux86/usr/ -I/home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/sysroots/qemux86/usr/
lib/glib-2.0/include -I/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/ lib/glib-2.0/include -I/home/pokybuild/yocto-autobuilder/nightly-x86/build/build/
tmp/sysroots/qemux86/usr/include/dbus-1.0 -I/home/pokybuild/yocto-autobuilder/yocto-slave/ tmp/sysroots/qemux86/usr/include/dbus-1.0 -I/home/pokybuild/yocto-autobuilder/
nightly-x86/build/build/tmp/sysroots/qemux86/usr/lib/dbus-1.0/include -I/home/pokybuild/yocto-autobuilder/ nightly-x86/build/build/tmp/sysroots/qemux86/usr/lib/dbus-1.0/include -I/home/pokybuild/yocto-autobuilder/
yocto-slave/nightly-x86/build/build/tmp/sysroots/qemux86/usr/include/libnl3 nightly-x86/build/build/tmp/sysroots/qemux86/usr/include/libnl3
-DNEAR_PLUGIN_BUILTIN -DPLUGINDIR=\""/usr/lib/near/plugins"\" -DNEAR_PLUGIN_BUILTIN -DPLUGINDIR=\""/usr/lib/near/plugins"\"
-DCONFIGDIR=\""/etc/neard\"" -O2 -pipe -g -feliminate-unused-debug-types -c -DCONFIGDIR=\""/etc/neard\"" -O2 -pipe -g -feliminate-unused-debug-types -c
-o tools/snep-send.o tools/snep-send.c -o tools/snep-send.o tools/snep-send.c
@ -10810,12 +10810,12 @@ package::
LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly license_emgd_1.10" LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly license_emgd_1.10"
As a convenience, you do not need to specify the As a convenience, you do not need to specify the
complete license string in the whitelist for every package. You can use complete license string for every package. You can use
an abbreviated form, which consists of just the first portion or an abbreviated form, which consists of just the first portion or
portions of the license string before the initial underscore character portions of the license string before the initial underscore character
or characters. A partial string will match any license that contains the or characters. A partial string will match any license that contains the
given string as the first portion of its license. For example, the given string as the first portion of its license. For example, the
following whitelist string will also match both of the packages following value will also match both of the packages
previously mentioned as well as any other packages that have licenses previously mentioned as well as any other packages that have licenses
starting with "commercial" or "license". starting with "commercial" or "license".
:: ::
@ -10828,8 +10828,8 @@ License Flag Matching
License flag matching allows you to control what recipes the License flag matching allows you to control what recipes the
OpenEmbedded build system includes in the build. Fundamentally, the OpenEmbedded build system includes in the build. Fundamentally, the
build system attempts to match :term:`LICENSE_FLAGS` strings found in build system attempts to match :term:`LICENSE_FLAGS` strings found in
recipes against :term:`LICENSE_FLAGS_WHITELIST` strings found in the recipes against strings found in :term:`LICENSE_FLAGS_WHITELIST`.
whitelist. A match causes the build system to include a recipe in the A match causes the build system to include a recipe in the
build, while failure to find a match causes the build system to exclude build, while failure to find a match causes the build system to exclude
a recipe. a recipe.
@ -10837,18 +10837,19 @@ In general, license flag matching is simple. However, understanding some
concepts will help you correctly and effectively use matching. concepts will help you correctly and effectively use matching.
Before a flag defined by a particular recipe is tested against the Before a flag defined by a particular recipe is tested against the
contents of the whitelist, the expanded string ``_${PN}`` is appended to entries of :term:`LICENSE_FLAGS_WHITELIST`, the expanded
the flag. This expansion makes each :term:`LICENSE_FLAGS` value string ``_${PN}`` is appended to the flag. This expansion makes each
recipe-specific. After expansion, the string is then matched against the :term:`LICENSE_FLAGS` value recipe-specific. After expansion, the
whitelist. Thus, specifying ``LICENSE_FLAGS = "commercial"`` in recipe string is then matched against the entries. Thus, specifying
"foo", for example, results in the string ``"commercial_foo"``. And, to ``LICENSE_FLAGS = "commercial"`` in recipe "foo", for example, results
create a match, that string must appear in the whitelist. in the string ``"commercial_foo"``. And, to create a match, that string
must appear among the entries of :term:`LICENSE_FLAGS_WHITELIST`.
Judicious use of the :term:`LICENSE_FLAGS` strings and the contents of the Judicious use of the :term:`LICENSE_FLAGS` strings and the contents of the
:term:`LICENSE_FLAGS_WHITELIST` variable allows you a lot of flexibility for :term:`LICENSE_FLAGS_WHITELIST` variable allows you a lot of flexibility for
including or excluding recipes based on licensing. For example, you can including or excluding recipes based on licensing. For example, you can
broaden the matching capabilities by using license flags string subsets broaden the matching capabilities by using license flags string subsets
in the whitelist. in :term:`LICENSE_FLAGS_WHITELIST`.
.. note:: .. note::
@ -10856,43 +10857,44 @@ in the whitelist.
string that precedes the appended underscore character (e.g. string that precedes the appended underscore character (e.g.
``usethispart_1.3``, ``usethispart_1.4``, and so forth). ``usethispart_1.3``, ``usethispart_1.4``, and so forth).
For example, simply specifying the string "commercial" in the whitelist For example, simply specifying the string "commercial" in the
matches any expanded :term:`LICENSE_FLAGS` definition that starts with the :term:`LICENSE_FLAGS_WHITELIST` variable matches any expanded
string "commercial" such as "commercial_foo" and "commercial_bar", which :term:`LICENSE_FLAGS` definition that starts with the string
"commercial" such as "commercial_foo" and "commercial_bar", which
are the strings the build system automatically generates for are the strings the build system automatically generates for
hypothetical recipes named "foo" and "bar" assuming those recipes simply hypothetical recipes named "foo" and "bar" assuming those recipes simply
specify the following:: specify the following::
LICENSE_FLAGS = "commercial" LICENSE_FLAGS = "commercial"
Thus, you can choose Thus, you can choose to exhaustively enumerate each license flag in the
to exhaustively enumerate each license flag in the whitelist and allow list and allow only specific recipes into the image, or you can use a
only specific recipes into the image, or you can use a string subset string subset that causes a broader range of matches to allow a range of
that causes a broader range of matches to allow a range of recipes into recipes into the image.
the image.
This scheme works even if the :term:`LICENSE_FLAGS` string already has This scheme works even if the :term:`LICENSE_FLAGS` string already has
``_${PN}`` appended. For example, the build system turns the license ``_${PN}`` appended. For example, the build system turns the license
flag "commercial_1.2_foo" into "commercial_1.2_foo_foo" and would match flag "commercial_1.2_foo" into "commercial_1.2_foo_foo" and would match
both the general "commercial" and the specific "commercial_1.2_foo" both the general "commercial" and the specific "commercial_1.2_foo"
strings found in the whitelist, as expected. strings found in the :term:`LICENSE_FLAGS_WHITELIST` variable, as expected.
Here are some other scenarios: Here are some other scenarios:
- You can specify a versioned string in the recipe such as - You can specify a versioned string in the recipe such as
"commercial_foo_1.2" in a "foo" recipe. The build system expands this "commercial_foo_1.2" in a "foo" recipe. The build system expands this
string to "commercial_foo_1.2_foo". Combine this license flag with a string to "commercial_foo_1.2_foo". Combine this license flag with a
whitelist that has the string "commercial" and you match the flag :term:`LICENSE_FLAGS_WHITELIST` variable that has the string
along with any other flag that starts with the string "commercial". "commercial" and you match the flag along with any other flag that
starts with the string "commercial".
- Under the same circumstances, you can use "commercial_foo" in the - Under the same circumstances, you can add "commercial_foo" in the
whitelist and the build system not only matches "commercial_foo_1.2" :term:`LICENSE_FLAGS_WHITELIST` variable and the build system not only
but also matches any license flag with the string "commercial_foo", matches "commercial_foo_1.2" but also matches any license flag with
regardless of the version. the string "commercial_foo", regardless of the version.
- You can be very specific and use both the package and version parts - You can be very specific and use both the package and version parts
in the whitelist (e.g. "commercial_foo_1.2") to specifically match a in the :term:`LICENSE_FLAGS_WHITELIST` list (e.g.
versioned recipe. "commercial_foo_1.2") to specifically match a versioned recipe.
Other Variables Related to Commercial Licenses Other Variables Related to Commercial Licenses
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ -10916,9 +10918,10 @@ file::
LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly commercial_gst-plugins-bad commercial_qmmp" LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly commercial_gst-plugins-bad commercial_qmmp"
Of course, you could also create a matching whitelist for those Of course, you could also create a matching list for those
components using the more general "commercial" in the whitelist, but components using the more general "commercial" in the
that would also enable all the other packages with :term:`LICENSE_FLAGS` :term:`LICENSE_FLAGS_WHITELIST` variable, but that would also enable all
the other packages with :term:`LICENSE_FLAGS`
containing "commercial", which you may or may not want:: containing "commercial", which you may or may not want::
LICENSE_FLAGS_WHITELIST = "commercial" LICENSE_FLAGS_WHITELIST = "commercial"

6
documentation/kernel-dev/advanced.rst
View File

@ -763,7 +763,7 @@ Organizing Your Source
====================== ======================
Many recipes based on the ``linux-yocto-custom.bb`` recipe use Linux Many recipes based on the ``linux-yocto-custom.bb`` recipe use Linux
kernel sources that have only a single branch - "master". This type of kernel sources that have only a single branch. This type of
repository structure is fine for linear development supporting a single repository structure is fine for linear development supporting a single
machine and architecture. However, if you work with multiple boards and machine and architecture. However, if you work with multiple boards and
architectures, a kernel source repository with multiple branches is more architectures, a kernel source repository with multiple branches is more
@ -772,7 +772,7 @@ board to boot. Sometimes, these patches are works-in-progress or
fundamentally wrong, yet they are still necessary for specific boards. fundamentally wrong, yet they are still necessary for specific boards.
In these situations, you most likely do not want to include these In these situations, you most likely do not want to include these
patches in every kernel you build (i.e. have the patches as part of the patches in every kernel you build (i.e. have the patches as part of the
lone "master" branch). It is situations like these that give rise to default branch). It is situations like these that give rise to
multiple branches used within a Linux kernel sources Git repository. multiple branches used within a Linux kernel sources Git repository.
Here are repository organization strategies maximizing source reuse, Here are repository organization strategies maximizing source reuse,
@ -812,7 +812,7 @@ Machine Branches
When you have multiple machines and architectures to support, or you are When you have multiple machines and architectures to support, or you are
actively working on board support, it is more efficient to create actively working on board support, it is more efficient to create
branches in the repository based on individual machines. Having machine branches in the repository based on individual machines. Having machine
branches allows common source to remain in the "master" branch with any branches allows common source to remain in the development branch with any
features specific to a machine stored in the appropriate machine branch. features specific to a machine stored in the appropriate machine branch.
This organization method frees you from continually reintegrating your This organization method frees you from continually reintegrating your
patches into a feature. patches into a feature.

4
documentation/kernel-dev/concepts-appx.rst
View File

@ -211,8 +211,8 @@ view, there is a linear path that travels from the baseline
``kernel.org``, through a select group of features and ends with their ``kernel.org``, through a select group of features and ends with their
BSP-specific commits. In other words, the divisions of the kernel are BSP-specific commits. In other words, the divisions of the kernel are
transparent and are not relevant to the developer on a day-to-day basis. transparent and are not relevant to the developer on a day-to-day basis.
From the developer's perspective, this path is the "master" branch in From the developer's perspective, this path is the development branch.
Git terms. The developer does not need to be aware of the existence of The developer does not need to be aware of the existence of
any other branches at all. Of course, it can make sense to have these any other branches at all. Of course, it can make sense to have these
branches in the tree, should a person decide to explore them. For branches in the tree, should a person decide to explore them. For
example, a comparison between two BSPs at either the commit level or at example, a comparison between two BSPs at either the commit level or at

2
documentation/migration-guides/migration-1.6.rst
View File

@ -231,7 +231,7 @@ Build Changes
------------- -------------
Separate build and source directories have been enabled by default for Separate build and source directories have been enabled by default for
selected recipes where it is known to work (a whitelist) and for all selected recipes where it is known to work and for all
recipes that inherit the :ref:`cmake <ref-classes-cmake>` class. In recipes that inherit the :ref:`cmake <ref-classes-cmake>` class. In
future releases the :ref:`autotools <ref-classes-autotools>` class future releases the :ref:`autotools <ref-classes-autotools>` class
will enable a separate build directory by default as well. Recipes will enable a separate build directory by default as well. Recipes

2
documentation/migration-guides/migration-3.3.rst
View File

@ -89,7 +89,7 @@ example::
S = "${WORKDIR}/git/python/pythonmodule" S = "${WORKDIR}/git/python/pythonmodule"
then in ``setup.py`` it works with source code in a relative fashion, such then in ``setup.py`` it works with source code in a relative fashion, such
as ``../../src``. This causes pseudo to abort as it isn't able to track as ``../../src``. This causes pseudo to fail as it isn't able to track
the paths properly. This release introduces a new :term:`DISTUTILS_SETUP_PATH` the paths properly. This release introduces a new :term:`DISTUTILS_SETUP_PATH`
variable so that recipes can specify it explicitly, for example:: variable so that recipes can specify it explicitly, for example::

10
documentation/overview-manual/concepts.rst
View File

@ -1718,7 +1718,7 @@ inputs still exits - items already built and present in the
:term:`Build Directory`. The checksum (or :term:`Build Directory`. The checksum (or
signature) for a particular task needs to add the hashes of all the signature) for a particular task needs to add the hashes of all the
tasks on which the particular task depends. Choosing which dependencies tasks on which the particular task depends. Choosing which dependencies
to add is a policy decision. However, the effect is to generate a master to add is a policy decision. However, the effect is to generate a
checksum that combines the basehash and the hashes of the task's checksum that combines the basehash and the hashes of the task's
dependencies. dependencies.
@ -1735,12 +1735,8 @@ included in any checksum)::
PRSERV_DUMPDIR PRSERV_DUMPFILE PRSERV_LOCKDOWN PARALLEL_MAKE \\ PRSERV_DUMPDIR PRSERV_DUMPFILE PRSERV_LOCKDOWN PARALLEL_MAKE \\
CCACHE_DIR EXTERNAL_TOOLCHAIN CCACHE CCACHE_DISABLE LICENSE_PATH SDKPKGSUFFIX" CCACHE_DIR EXTERNAL_TOOLCHAIN CCACHE CCACHE_DISABLE LICENSE_PATH SDKPKGSUFFIX"
The The previous example does not include :term:`WORKDIR` since that variable is
previous example excludes actually constructed as a path within :term:`TMPDIR`, which is included above.
:term:`WORKDIR` since that variable
is actually constructed as a path within
:term:`TMPDIR`, which is on the
whitelist.
The rules for deciding which hashes of dependent tasks to include The rules for deciding which hashes of dependent tasks to include
through dependency chains are more complex and are generally through dependency chains are more complex and are generally

45
documentation/overview-manual/development-environment.rst
View File

@ -163,9 +163,9 @@ these tarballs gives you a snapshot of the released files.
- Be sure to always work in matching branches for both the selected - Be sure to always work in matching branches for both the selected
BSP repository and the Source Directory (i.e. ``poky``) BSP repository and the Source Directory (i.e. ``poky``)
repository. For example, if you have checked out the "master" repository. For example, if you have checked out the "&DISTRO_NAME_NO_CAP;"
branch of ``poky`` and you are going to use ``meta-intel``, be branch of ``poky`` and you are going to use ``meta-intel``, be
sure to checkout the "master" branch of ``meta-intel``. sure to checkout the "&DISTRO_NAME_NO_CAP;" branch of ``meta-intel``.
In summary, here is where you can get the project files needed for In summary, here is where you can get the project files needed for
development: development:
@ -233,8 +233,8 @@ all diverging functionality. Although there is no need to use Git, many
open source projects do so. open source projects do so.
For the Yocto Project, a key individual called the "maintainer" is For the Yocto Project, a key individual called the "maintainer" is
responsible for the integrity of the "master" branch of a given Git responsible for the integrity of the development branch of a given Git
repository. The "master" branch is the "upstream" repository from which repository. The development branch is the "upstream" repository from which
final or most recent builds of a project occur. The maintainer is final or most recent builds of a project occur. The maintainer is
responsible for accepting changes from other developers and for responsible for accepting changes from other developers and for
organizing the underlying branch structure to reflect release strategies organizing the underlying branch structure to reflect release strategies
@ -279,8 +279,8 @@ submitting patches and changes, see the
":ref:`dev-manual/common-tasks:submitting a change to the yocto project`" ":ref:`dev-manual/common-tasks:submitting a change to the yocto project`"
section in the Yocto Project Development Tasks Manual. section in the Yocto Project Development Tasks Manual.
In summary, there is a single point of entry for changes into a "master" In summary, there is a single point of entry for changes into the
or development branch of the Git repository, which is controlled by the development branch of the Git repository, which is controlled by the
project's maintainer. A set of developers independently project's maintainer. A set of developers independently
develop, test, and submit changes to "contrib" areas for the maintainer develop, test, and submit changes to "contrib" areas for the maintainer
to examine. The maintainer then chooses which changes are going to to examine. The maintainer then chooses which changes are going to
@ -311,7 +311,7 @@ Book <https://book.git-scm.com>`__.
host. You can name these branches anything you like. It is helpful to host. You can name these branches anything you like. It is helpful to
give them names associated with the particular feature or change on give them names associated with the particular feature or change on
which you are working. Once you are done with a feature or change and which you are working. Once you are done with a feature or change and
have merged it into your local master branch, simply discard the have merged it into your local development branch, simply discard the
temporary branch. temporary branch.
- *Merge Changes:* The ``git merge`` command allows you to take the - *Merge Changes:* The ``git merge`` command allows you to take the
@ -348,7 +348,7 @@ Book <https://book.git-scm.com>`__.
- *Patch Workflow:* This workflow allows you to notify the maintainer - *Patch Workflow:* This workflow allows you to notify the maintainer
through an email that you have a change (or patch) you would like through an email that you have a change (or patch) you would like
considered for the "master" branch of the Git repository. To send considered for the development branch of the Git repository. To send
this type of change, you format the patch and then send the email this type of change, you format the patch and then send the email
using the Git commands ``git format-patch`` and ``git send-email``. using the Git commands ``git format-patch`` and ``git send-email``.
For information on how to use these scripts, see the For information on how to use these scripts, see the
@ -433,17 +433,12 @@ development branch in the repository. To help illustrate, consider the
following example Git commands:: following example Git commands::
$ cd ~ $ cd ~
$ git clone git://git.yoctoproject.org/poky $ git clone git://git.yoctoproject.org/poky -b &DISTRO_NAME_NO_CAP;
$ cd poky
$ git checkout -b &DISTRO_NAME_NO_CAP; origin/&DISTRO_NAME_NO_CAP;
In the previous example In the previous example
after moving to the home directory, the ``git clone`` command creates a after moving to the home directory, the ``git clone`` command creates a
local copy of the upstream ``poky`` Git repository. By default, Git local copy of the upstream ``poky`` Git repository and checks out a
checks out the "master" branch for your work. After changing the working local branch named "&DISTRO_NAME_NO_CAP;", which tracks the upstream
directory to the new local repository (i.e. ``poky``), the
``git checkout`` command creates and checks out a local branch named
"&DISTRO_NAME_NO_CAP;", which tracks the upstream
"origin/&DISTRO_NAME_NO_CAP;" branch. Changes you make while in this "origin/&DISTRO_NAME_NO_CAP;" branch. Changes you make while in this
branch would ultimately affect the upstream "&DISTRO_NAME_NO_CAP;" branch branch would ultimately affect the upstream "&DISTRO_NAME_NO_CAP;" branch
of the ``poky`` repository. of the ``poky`` repository.
@ -558,9 +553,9 @@ descriptions and strategies on how to use these commands:
- *git pull --rebase:* Retrieves information from an upstream Git - *git pull --rebase:* Retrieves information from an upstream Git
repository and places it in your local Git repository. You use this repository and places it in your local Git repository. You use this
command to make sure you are synchronized with the repository from command to make sure you are synchronized with the repository from
which you are basing changes (.e.g. the "master" branch). The which you are basing changes (e.g. the "&DISTRO_NAME_NO_CAP;"
"--rebase" option ensures that any local commits you have in your branch). The "--rebase" option ensures that any local commits you
branch are preserved at the top of your local branch. have in your branch are preserved at the top of your local branch.
- *git push repo-name local-branch:upstream-branch:* Sends - *git push repo-name local-branch:upstream-branch:* Sends
all your committed local changes to the upstream Git repository that all your committed local changes to the upstream Git repository that
@ -571,13 +566,13 @@ descriptions and strategies on how to use these commands:
- *git merge:* Combines or adds changes from one local branch of - *git merge:* Combines or adds changes from one local branch of
your repository with another branch. When you create a local Git your repository with another branch. When you create a local Git
repository, the default branch is named "master". A typical workflow repository, the default branch may be named "main". A typical
is to create a temporary branch that is based off "master" that you workflow is to create a temporary branch that is based off "main"
would use for isolated work. You would make your changes in that that you would use for isolated work. You would make your changes in
isolated branch, stage and commit them locally, switch to the that isolated branch, stage and commit them locally, switch to the
"master" branch, and then use the ``git merge`` command to apply the "main" branch, and then use the ``git merge`` command to apply the
changes from your isolated branch into the currently checked out changes from your isolated branch into the currently checked out
branch (e.g. "master"). After the merge is complete and if you are branch (e.g. "main"). After the merge is complete and if you are
done with working in that isolated branch, you can safely delete the done with working in that isolated branch, you can safely delete the
isolated branch. isolated branch.

2
documentation/overview-manual/yp-intro.rst
View File

@ -371,7 +371,7 @@ Yocto Project:
- *AutoBuilder:* AutoBuilder is a project that automates build tests - *AutoBuilder:* AutoBuilder is a project that automates build tests
and quality assurance (QA). By using the public AutoBuilder, anyone and quality assurance (QA). By using the public AutoBuilder, anyone
can determine the status of the current "master" branch of Poky. can determine the status of the current development branch of Poky.
.. note:: .. note::

14
documentation/ref-manual/classes.rst
View File

@ -214,13 +214,13 @@ the class.
===================== =====================
The ``blacklist`` class prevents the OpenEmbedded build system from The ``blacklist`` class prevents the OpenEmbedded build system from
building specific recipes (blacklists them). To use this class, inherit building specific recipes. To use this class, inherit
the class globally and set :term:`PNBLACKLIST` for the class globally and set :term:`PNBLACKLIST` for
each recipe you wish to blacklist. Specify the :term:`PN` each recipe you wish to ignore. Specify the :term:`PN`
value as a variable flag (varflag) and provide a reason, which is value as a variable flag (varflag) and provide a reason, which is
reported, if the package is requested to be built as the value. For reported, if the package is requested to be built as the value. For
example, if you want to blacklist a recipe called "exoticware", you add example, if you want to ignore a recipe called "exoticware", you
the following to your ``local.conf`` or distribution configuration:: add the following to your ``local.conf`` or distribution configuration::
INHERIT += "blacklist" INHERIT += "blacklist"
PNBLACKLIST[exoticware] = "Not supported by our organization." PNBLACKLIST[exoticware] = "Not supported by our organization."
@ -845,10 +845,10 @@ provided by the recipe ``icecc-create-env-native.bb``.
icecc. icecc.
If you do not want the Icecream distributed compile support to apply to If you do not want the Icecream distributed compile support to apply to
specific recipes or classes, you can effectively "blacklist" them by specific recipes or classes, you can ask them to be ignored by Icecream
listing the recipes and classes using the by listing the recipes and classes using the
:term:`ICECC_USER_PACKAGE_BL` and :term:`ICECC_USER_PACKAGE_BL` and
:term:`ICECC_USER_CLASS_BL`, variables, :term:`ICECC_USER_CLASS_BL` variables,
respectively, in your ``local.conf`` file. Doing so causes the respectively, in your ``local.conf`` file. Doing so causes the
OpenEmbedded build system to handle these compilations locally. OpenEmbedded build system to handle these compilations locally.

2
documentation/ref-manual/images.rst
View File

@ -112,7 +112,7 @@ Following is a list of supported recipes:
development headers and libraries to form a complete standalone SDK development headers and libraries to form a complete standalone SDK
and is suitable for development using the target. and is suitable for development using the target.
- ``core-image-testmaster``: A "master" image designed to be used for - ``core-image-testmaster``: A "controller" image designed to be used for
automated runtime testing. Provides a "known good" image that is automated runtime testing. Provides a "known good" image that is
deployed to a separate partition so that you can boot into it and use deployed to a separate partition so that you can boot into it and use
it to deploy a second image to be tested. You can find more it to deploy a second image to be tested. You can find more

2
documentation/ref-manual/terms.rst
View File

@ -404,7 +404,7 @@ universal, the list includes them just in case:
:term:`Upstream` :term:`Upstream`
A reference to source code or repositories that are not A reference to source code or repositories that are not
local to the development system but located in a master area that is local to the development system but located in a remote area that is
controlled by the maintainer of the source code. For example, in controlled by the maintainer of the source code. For example, in
order for a developer to work on a particular piece of code, they order for a developer to work on a particular piece of code, they
need to first get a copy of it from an "upstream" source. need to first get a copy of it from an "upstream" source.

39
documentation/ref-manual/variables.rst
View File

@ -400,7 +400,7 @@ system and gives an overview of their function and contents.
where: where:
action is: action is:
ABORT: Immediately abort the build when ABORT: Immediately stop the build when
a threshold is broken. a threshold is broken.
STOPTASKS: Stop the build after the currently STOPTASKS: Stop the build after the currently
executing tasks have finished when executing tasks have finished when
@ -438,7 +438,7 @@ system and gives an overview of their function and contents.
The first example works only if you also provide the The first example works only if you also provide the
:term:`BB_DISKMON_WARNINTERVAL` :term:`BB_DISKMON_WARNINTERVAL`
variable in the ``conf/local.conf``. This example causes the build variable in the ``conf/local.conf``. This example causes the build
system to immediately abort when either the disk space in system to immediately stop when either the disk space in
``${TMPDIR}`` drops below 1 Gbyte or the available free inodes drops ``${TMPDIR}`` drops below 1 Gbyte or the available free inodes drops
below 100 Kbytes. Because two directories are provided with the below 100 Kbytes. Because two directories are provided with the
variable, the build system also issue a warning when the disk space variable, the build system also issue a warning when the disk space
@ -452,7 +452,7 @@ system and gives an overview of their function and contents.
directory drops below 1 Gbyte. No disk monitoring occurs for the free directory drops below 1 Gbyte. No disk monitoring occurs for the free
inodes in this case. inodes in this case.
The final example immediately aborts the build when the number of The final example immediately stops the build when the number of
free inodes in the ``${TMPDIR}`` directory drops below 100 Kbytes. No free inodes in the ``${TMPDIR}`` directory drops below 100 Kbytes. No
disk space monitoring for the directory itself occurs in this case. disk space monitoring for the directory itself occurs in this case.
@ -652,7 +652,7 @@ system and gives an overview of their function and contents.
" "
This next example shows an error message that occurs because invalid This next example shows an error message that occurs because invalid
entries are found, which cause parsing to abort: entries are found, which cause parsing to fail:
.. code-block:: none .. code-block:: none
@ -2894,9 +2894,9 @@ system and gives an overview of their function and contents.
:ref:`icecc <ref-classes-icecc>` class. You set this variable in :ref:`icecc <ref-classes-icecc>` class. You set this variable in
your ``local.conf`` file. your ``local.conf`` file.
When you list classes using this variable, you are "blacklisting" When you list classes using this variable, the recipes inheriting
them from distributed compilation across remote hosts. Any classes those classes will not benefit from distributed compilation across
you list will be distributed and compiled locally. remote hosts. Instead they will be built locally.
:term:`ICECC_USER_PACKAGE_BL` :term:`ICECC_USER_PACKAGE_BL`
Identifies user recipes that you do not want the Icecream distributed Identifies user recipes that you do not want the Icecream distributed
@ -2904,9 +2904,9 @@ system and gives an overview of their function and contents.
:ref:`icecc <ref-classes-icecc>` class. You set this variable in :ref:`icecc <ref-classes-icecc>` class. You set this variable in
your ``local.conf`` file. your ``local.conf`` file.
When you list packages using this variable, you are "blacklisting" When you list recipes using this variable, you are excluding them
them from distributed compilation across remote hosts. Any packages from distributed compilation across remote hosts. Instead they will
you list will be distributed and compiled locally. be built locally.
:term:`ICECC_USER_PACKAGE_WL` :term:`ICECC_USER_PACKAGE_WL`
Identifies user recipes that use an empty Identifies user recipes that use an empty
@ -4366,9 +4366,9 @@ system and gives an overview of their function and contents.
section in the Yocto Project Development Tasks Manual. section in the Yocto Project Development Tasks Manual.
:term:`LICENSE_FLAGS` :term:`LICENSE_FLAGS`
Specifies additional flags for a recipe you must whitelist through Specifies additional flags for a recipe you must allow through
:term:`LICENSE_FLAGS_WHITELIST` in :term:`LICENSE_FLAGS_WHITELIST` in
order to allow the recipe to be built. When providing multiple flags, order for the recipe to be built. When providing multiple flags,
separate them with spaces. separate them with spaces.
This value is independent of :term:`LICENSE` and is This value is independent of :term:`LICENSE` and is
@ -4381,8 +4381,7 @@ system and gives an overview of their function and contents.
:term:`LICENSE_FLAGS_WHITELIST` :term:`LICENSE_FLAGS_WHITELIST`
Lists license flags that when specified in Lists license flags that when specified in
:term:`LICENSE_FLAGS` within a recipe should not :term:`LICENSE_FLAGS` within a recipe should not
prevent that recipe from being built. This practice is otherwise prevent that recipe from being built. For more information, see the
known as "whitelisting" license flags. For more information, see the
":ref:`dev-manual/common-tasks:enabling commercially licensed recipes`" ":ref:`dev-manual/common-tasks:enabling commercially licensed recipes`"
section in the Yocto Project Development Tasks Manual. section in the Yocto Project Development Tasks Manual.
@ -5186,8 +5185,8 @@ system and gives an overview of their function and contents.
.. note:: .. note::
You can use the :term:`PACKAGE_FEED_ARCHS` You can use the :term:`PACKAGE_FEED_ARCHS`
variable to whitelist specific package architectures. If you do variable to allow specific package architectures. If you do
not need to whitelist specific architectures, which is a common not need to allow specific architectures, which is a common
case, you can omit this variable. Omitting the variable results in case, you can omit this variable. Omitting the variable results in
all available architectures for the current machine being included all available architectures for the current machine being included
into remote package feeds. into remote package feeds.
@ -6583,9 +6582,9 @@ system and gives an overview of their function and contents.
:ref:`populate-sdk-ext <ref-classes-populate-sdk-*>` class. :ref:`populate-sdk-ext <ref-classes-populate-sdk-*>` class.
This list overrides the variables specified using the This list overrides the variables specified using the
:term:`SDK_LOCAL_CONF_BLACKLIST` :term:`SDK_LOCAL_CONF_BLACKLIST` variable as well as
variable as well as any variables identified by automatic other variables automatically added due to the "/" character
blacklisting due to the "/" character being found at the start of the being found at the start of the
value, which is usually indicative of being a path and thus might not value, which is usually indicative of being a path and thus might not
be valid on the system where the SDK is installed. be valid on the system where the SDK is installed.
@ -8244,7 +8243,7 @@ system and gives an overview of their function and contents.
variable is used. variable is used.
:term:`TUNEABI_WHITELIST` :term:`TUNEABI_WHITELIST`
A whitelist of permissible :term:`TUNEABI` values. If A list of permissible :term:`TUNEABI` values. If
:term:`TUNEABI_WHITELIST` is not set, all tunes are allowed. Providers :term:`TUNEABI_WHITELIST` is not set, all tunes are allowed. Providers
that use prebuilt libraries can use the :term:`TUNEABI_WHITELIST`, that use prebuilt libraries can use the :term:`TUNEABI_WHITELIST`,
:term:`TUNEABI_OVERRIDE`, and :term:`TUNEABI` :term:`TUNEABI_OVERRIDE`, and :term:`TUNEABI`

11
documentation/sdk-manual/appendix-customizing.rst
View File

@ -43,7 +43,7 @@ build system applies them against ``local.conf`` and ``auto.conf``:
:term:`SDK_INHERIT_BLACKLIST` :term:`SDK_INHERIT_BLACKLIST`
are disabled. Using :term:`SDK_INHERIT_BLACKLIST` to disable these are disabled. Using :term:`SDK_INHERIT_BLACKLIST` to disable these
classes is the typical method to disable classes that are problematic classes is the typical method to disable classes that are problematic
or unnecessary in the SDK context. The default value blacklists the or unnecessary in the SDK context. The default value disables the
:ref:`buildhistory <ref-classes-buildhistory>` :ref:`buildhistory <ref-classes-buildhistory>`
and :ref:`icecc <ref-classes-icecc>` classes. and :ref:`icecc <ref-classes-icecc>` classes.
@ -63,9 +63,8 @@ adjustments:
- If your SDK configuration inherits additional classes using the - If your SDK configuration inherits additional classes using the
:term:`INHERIT` variable and you :term:`INHERIT` variable and you
do not need or want those classes enabled in the SDK, you can do not need or want those classes enabled in the SDK, you can
blacklist them by adding them to the disable them by adding them to the :term:`SDK_INHERIT_BLACKLIST`
:term:`SDK_INHERIT_BLACKLIST` variable as described in the previous section.
variable as described in the fourth bullet of the previous section.
.. note:: .. note::
@ -275,8 +274,8 @@ source, you need to do a number of things:
places or it will fail quickly on the OpenEmbedded build system places or it will fail quickly on the OpenEmbedded build system
side, and its contents will not interfere with the build), then side, and its contents will not interfere with the build), then
you can set the variable in your ``local.conf`` or custom distro you can set the variable in your ``local.conf`` or custom distro
configuration file. You can then "whitelist" the variable through configuration file. You can then pass the variable to the SDK by
to the SDK by adding the following:: adding the following::
SDK_LOCAL_CONF_WHITELIST = "SSTATE_MIRRORS" SDK_LOCAL_CONF_WHITELIST = "SSTATE_MIRRORS"