diff options
-rw-r--r-- | documentation/bsp-guide/bsp.rst | 12 | ||||
-rw-r--r-- | documentation/dev-manual/common-tasks.rst | 159 | ||||
-rw-r--r-- | documentation/kernel-dev/advanced.rst | 6 | ||||
-rw-r--r-- | documentation/kernel-dev/concepts-appx.rst | 4 | ||||
-rw-r--r-- | documentation/migration-guides/migration-1.6.rst | 2 | ||||
-rw-r--r-- | documentation/migration-guides/migration-3.3.rst | 2 | ||||
-rw-r--r-- | documentation/overview-manual/concepts.rst | 10 | ||||
-rw-r--r-- | documentation/overview-manual/development-environment.rst | 45 | ||||
-rw-r--r-- | documentation/overview-manual/yp-intro.rst | 2 | ||||
-rw-r--r-- | documentation/ref-manual/classes.rst | 14 | ||||
-rw-r--r-- | documentation/ref-manual/images.rst | 2 | ||||
-rw-r--r-- | documentation/ref-manual/terms.rst | 2 | ||||
-rw-r--r-- | documentation/ref-manual/variables.rst | 39 | ||||
-rw-r--r-- | documentation/sdk-manual/appendix-customizing.rst | 11 |
14 files changed, 151 insertions, 159 deletions
diff --git a/documentation/bsp-guide/bsp.rst b/documentation/bsp-guide/bsp.rst index 65652ff898..f8d38ca484 100644 --- a/documentation/bsp-guide/bsp.rst +++ b/documentation/bsp-guide/bsp.rst | |||
@@ -1121,12 +1121,12 @@ list describes them in order of preference: | |||
1121 | how to use these variables. | 1121 | how to use these variables. |
1122 | 1122 | ||
1123 | If you build as you normally would, without specifying any recipes in | 1123 | If you build as you normally would, without specifying any recipes in |
1124 | the :term:`LICENSE_FLAGS_WHITELIST`, the build stops and provides you | 1124 | the :term:`LICENSE_FLAGS_WHITELIST` variable, the build stops and provides |
1125 | with the list of recipes that you have tried to include in the image | 1125 | you with the list of recipes that you have tried to include in the image |
1126 | that need entries in the :term:`LICENSE_FLAGS_WHITELIST`. Once you enter | 1126 | that need entries in the :term:`LICENSE_FLAGS_WHITELIST` variable. Once you |
1127 | the appropriate license flags into the whitelist, restart the build | 1127 | enter the appropriate license flags into it, restart the build to continue |
1128 | to continue where it left off. During the build, the prompt will not | 1128 | where it left off. During the build, the prompt will not appear again since |
1129 | appear again since you have satisfied the requirement. | 1129 | you have satisfied the requirement. |
1130 | 1130 | ||
1131 | Once the appropriate license flags are on the white list in the | 1131 | Once the appropriate license flags are on the white list in the |
1132 | :term:`LICENSE_FLAGS_WHITELIST` variable, you can build the encumbered | 1132 | :term:`LICENSE_FLAGS_WHITELIST` variable, you can build the encumbered |
diff --git a/documentation/dev-manual/common-tasks.rst b/documentation/dev-manual/common-tasks.rst index 0c267d5f48..c25af4eff2 100644 --- a/documentation/dev-manual/common-tasks.rst +++ b/documentation/dev-manual/common-tasks.rst | |||
@@ -5598,13 +5598,13 @@ file:: | |||
5598 | ./mkefidisk-201804191017-sda.direct | 5598 | ./mkefidisk-201804191017-sda.direct |
5599 | 5599 | ||
5600 | The following build artifacts were used to create the image(s): | 5600 | The following build artifacts were used to create the image(s): |
5601 | ROOTFS_DIR: /home/stephano/build/master/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/rootfs | 5601 | ROOTFS_DIR: /home/stephano/yocto/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/rootfs |
5602 | BOOTIMG_DIR: /home/stephano/build/master/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/share | 5602 | BOOTIMG_DIR: /home/stephano/yocto/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/share |
5603 | KERNEL_DIR: /home/stephano/build/master/build/tmp-glibc/deploy/images/qemux86 | 5603 | KERNEL_DIR: /home/stephano/yocto/build/tmp-glibc/deploy/images/qemux86 |
5604 | NATIVE_SYSROOT: /home/stephano/build/master/build/tmp-glibc/work/i586-oe-linux/wic-tools/1.0-r0/recipe-sysroot-native | 5604 | NATIVE_SYSROOT: /home/stephano/yocto/build/tmp-glibc/work/i586-oe-linux/wic-tools/1.0-r0/recipe-sysroot-native |
5605 | 5605 | ||
5606 | INFO: The image(s) were created using OE kickstart file: | 5606 | INFO: The image(s) were created using OE kickstart file: |
5607 | /home/stephano/build/master/openembedded-core/scripts/lib/wic/canned-wks/mkefidisk.wks | 5607 | /home/stephano/yocto/openembedded-core/scripts/lib/wic/canned-wks/mkefidisk.wks |
5608 | 5608 | ||
5609 | The previous example shows the easiest way to create an image by running | 5609 | The previous example shows the easiest way to create an image by running |
5610 | in cooked mode and supplying a kickstart file and the "-e" option to | 5610 | 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 | |||
5665 | the lines that specify the target disk from which to boot. | 5665 | the lines that specify the target disk from which to boot. |
5666 | :: | 5666 | :: |
5667 | 5667 | ||
5668 | $ cp /home/stephano/poky/scripts/lib/wic/canned-wks/directdisk-gpt.wks \ | 5668 | $ cp /home/stephano/yocto/poky/scripts/lib/wic/canned-wks/directdisk-gpt.wks \ |
5669 | /home/stephano/poky/scripts/lib/wic/canned-wks/directdisksdb-gpt.wks | 5669 | /home/stephano/yocto/poky/scripts/lib/wic/canned-wks/directdisksdb-gpt.wks |
5670 | 5670 | ||
5671 | Next, the example modifies the ``directdisksdb-gpt.wks`` file and | 5671 | Next, the example modifies the ``directdisksdb-gpt.wks`` file and |
5672 | changes all instances of "``--ondisk sda``" to "``--ondisk sdb``". The | 5672 | changes all instances of "``--ondisk sda``" to "``--ondisk sdb``". The |
@@ -5698,13 +5698,13 @@ Computing (nuc) :term:`MACHINE` the | |||
5698 | ./directdisksdb-gpt-201710090938-sdb.direct | 5698 | ./directdisksdb-gpt-201710090938-sdb.direct |
5699 | 5699 | ||
5700 | The following build artifacts were used to create the image(s): | 5700 | The following build artifacts were used to create the image(s): |
5701 | ROOTFS_DIR: /home/stephano/build/master/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/rootfs | 5701 | ROOTFS_DIR: /home/stephano/yocto/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/rootfs |
5702 | BOOTIMG_DIR: /home/stephano/build/master/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/share | 5702 | BOOTIMG_DIR: /home/stephano/yocto/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/share |
5703 | KERNEL_DIR: /home/stephano/build/master/build/tmp-glibc/deploy/images/qemux86 | 5703 | KERNEL_DIR: /home/stephano/yocto/build/tmp-glibc/deploy/images/qemux86 |
5704 | NATIVE_SYSROOT: /home/stephano/build/master/build/tmp-glibc/work/i586-oe-linux/wic-tools/1.0-r0/recipe-sysroot-native | 5704 | NATIVE_SYSROOT: /home/stephano/yocto/build/tmp-glibc/work/i586-oe-linux/wic-tools/1.0-r0/recipe-sysroot-native |
5705 | 5705 | ||
5706 | INFO: The image(s) were created using OE kickstart file: | 5706 | INFO: The image(s) were created using OE kickstart file: |
5707 | /home/stephano/poky/scripts/lib/wic/canned-wks/directdisksdb-gpt.wks | 5707 | /home/stephano/yocto/poky/scripts/lib/wic/canned-wks/directdisksdb-gpt.wks |
5708 | 5708 | ||
5709 | Continuing with the example, you can now directly ``dd`` the image to a | 5709 | Continuing with the example, you can now directly ``dd`` the image to a |
5710 | USB stick, or whatever media for which you built your image, and boot | 5710 | 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 | |||
5724 | ``-o`` option to cause Wic to create the output somewhere other than the | 5724 | ``-o`` option to cause Wic to create the output somewhere other than the |
5725 | default output directory, which is the current directory:: | 5725 | default output directory, which is the current directory:: |
5726 | 5726 | ||
5727 | $ wic create /home/stephano/my_yocto/test.wks -o /home/stephano/testwic \ | 5727 | $ wic create test.wks -o /home/stephano/testwic \ |
5728 | --rootfs-dir /home/stephano/build/master/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/rootfs \ | 5728 | --rootfs-dir /home/stephano/yocto/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/rootfs \ |
5729 | --bootimg-dir /home/stephano/build/master/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/share \ | 5729 | --bootimg-dir /home/stephano/yocto/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/share \ |
5730 | --kernel-dir /home/stephano/build/master/build/tmp/deploy/images/qemux86 \ | 5730 | --kernel-dir /home/stephano/yocto/build/tmp/deploy/images/qemux86 \ |
5731 | --native-sysroot /home/stephano/build/master/build/tmp/work/i586-poky-linux/wic-tools/1.0-r0/recipe-sysroot-native | 5731 | --native-sysroot /home/stephano/yocto/build/tmp/work/i586-poky-linux/wic-tools/1.0-r0/recipe-sysroot-native |
5732 | 5732 | ||
5733 | INFO: Creating image(s)... | 5733 | INFO: Creating image(s)... |
5734 | 5734 | ||
@@ -5736,13 +5736,13 @@ default output directory, which is the current directory:: | |||
5736 | /home/stephano/testwic/test-201710091445-sdb.direct | 5736 | /home/stephano/testwic/test-201710091445-sdb.direct |
5737 | 5737 | ||
5738 | The following build artifacts were used to create the image(s): | 5738 | The following build artifacts were used to create the image(s): |
5739 | ROOTFS_DIR: /home/stephano/build/master/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/rootfs | 5739 | ROOTFS_DIR: /home/stephano/yocto/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/rootfs |
5740 | BOOTIMG_DIR: /home/stephano/build/master/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/share | 5740 | BOOTIMG_DIR: /home/stephano/yocto/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/share |
5741 | KERNEL_DIR: /home/stephano/build/master/build/tmp-glibc/deploy/images/qemux86 | 5741 | KERNEL_DIR: /home/stephano/yocto/build/tmp-glibc/deploy/images/qemux86 |
5742 | NATIVE_SYSROOT: /home/stephano/build/master/build/tmp-glibc/work/i586-oe-linux/wic-tools/1.0-r0/recipe-sysroot-native | 5742 | NATIVE_SYSROOT: /home/stephano/yocto/build/tmp-glibc/work/i586-oe-linux/wic-tools/1.0-r0/recipe-sysroot-native |
5743 | 5743 | ||
5744 | INFO: The image(s) were created using OE kickstart file: | 5744 | INFO: The image(s) were created using OE kickstart file: |
5745 | /home/stephano/my_yocto/test.wks | 5745 | test.wks |
5746 | 5746 | ||
5747 | For this example, | 5747 | For this example, |
5748 | :term:`MACHINE` did not have to be | 5748 | :term:`MACHINE` did not have to be |
@@ -7097,7 +7097,7 @@ Generating and Using Signed Packages | |||
7097 | In order to add security to RPM packages used during a build, you can | 7097 | In order to add security to RPM packages used during a build, you can |
7098 | take steps to securely sign them. Once a signature is verified, the | 7098 | take steps to securely sign them. Once a signature is verified, the |
7099 | OpenEmbedded build system can use the package in the build. If security | 7099 | OpenEmbedded build system can use the package in the build. If security |
7100 | fails for a signed package, the build system aborts the build. | 7100 | fails for a signed package, the build system stops the build. |
7101 | 7101 | ||
7102 | This section describes how to sign RPM packages during a build and how | 7102 | This section describes how to sign RPM packages during a build and how |
7103 | to use signed package feeds (repositories) when doing a build. | 7103 | 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 | |||
8392 | certain devices it can also deploy the image to be tested onto the | 8392 | certain devices it can also deploy the image to be tested onto the |
8393 | device beforehand. | 8393 | device beforehand. |
8394 | 8394 | ||
8395 | For automated deployment, a "master image" is installed onto the | 8395 | For automated deployment, a "controller image" is installed onto the |
8396 | hardware once as part of setup. Then, each time tests are to be run, the | 8396 | hardware once as part of setup. Then, each time tests are to be run, the |
8397 | following occurs: | 8397 | following occurs: |
8398 | 8398 | ||
8399 | 1. The master image is booted into and used to write the image to be | 8399 | 1. The controller image is booted into and used to write the image to be |
8400 | tested to a second partition. | 8400 | tested to a second partition. |
8401 | 8401 | ||
8402 | 2. The device is then rebooted using an external script that you need to | 8402 | 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 | |||
8465 | ":ref:`dev-manual/common-tasks:running tests`" section. | 8465 | ":ref:`dev-manual/common-tasks:running tests`" section. |
8466 | 8466 | ||
8467 | If you did set :term:`TEST_TARGET` to "SystemdbootTarget", you also need to | 8467 | If you did set :term:`TEST_TARGET` to "SystemdbootTarget", you also need to |
8468 | perform a one-time setup of your master image by doing the following: | 8468 | perform a one-time setup of your controller image by doing the following: |
8469 | 8469 | ||
8470 | 1. *Set EFI_PROVIDER:* Be sure that :term:`EFI_PROVIDER` is as follows:: | 8470 | 1. *Set EFI_PROVIDER:* Be sure that :term:`EFI_PROVIDER` is as follows:: |
8471 | 8471 | ||
8472 | EFI_PROVIDER = "systemd-boot" | 8472 | EFI_PROVIDER = "systemd-boot" |
8473 | 8473 | ||
8474 | 2. *Build the master image:* Build the ``core-image-testmaster`` image. | 8474 | 2. *Build the controller image:* Build the ``core-image-testmaster`` image. |
8475 | The ``core-image-testmaster`` recipe is provided as an example for a | 8475 | The ``core-image-testmaster`` recipe is provided as an example for a |
8476 | "master" image and you can customize the image recipe as you would | 8476 | "controller" image and you can customize the image recipe as you would |
8477 | any other recipe. | 8477 | any other recipe. |
8478 | 8478 | ||
8479 | Here are the image recipe requirements: | 8479 | Here are the image recipe requirements: |
@@ -9588,51 +9588,51 @@ If you examine the output or the log file, you see the failure during | |||
9588 | | /bin/mkdir -p include/near | 9588 | | /bin/mkdir -p include/near |
9589 | | /bin/mkdir -p include/near | 9589 | | /bin/mkdir -p include/near |
9590 | | /bin/mkdir -p include/near | 9590 | | /bin/mkdir -p include/near |
9591 | | ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/ | 9591 | | ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/ |
9592 | 0.14-r0/neard-0.14/include/types.h include/near/types.h | 9592 | 0.14-r0/neard-0.14/include/types.h include/near/types.h |
9593 | | ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/ | 9593 | | ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/ |
9594 | 0.14-r0/neard-0.14/include/log.h include/near/log.h | 9594 | 0.14-r0/neard-0.14/include/log.h include/near/log.h |
9595 | | ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/ | 9595 | | ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/ |
9596 | 0.14-r0/neard-0.14/include/plugin.h include/near/plugin.h | 9596 | 0.14-r0/neard-0.14/include/plugin.h include/near/plugin.h |
9597 | | /bin/mkdir -p include/near | 9597 | | /bin/mkdir -p include/near |
9598 | | /bin/mkdir -p include/near | 9598 | | /bin/mkdir -p include/near |
9599 | | /bin/mkdir -p include/near | 9599 | | /bin/mkdir -p include/near |
9600 | | ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/ | 9600 | | ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/ |
9601 | 0.14-r0/neard-0.14/include/tag.h include/near/tag.h | 9601 | 0.14-r0/neard-0.14/include/tag.h include/near/tag.h |
9602 | | /bin/mkdir -p include/near | 9602 | | /bin/mkdir -p include/near |
9603 | | ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/ | 9603 | | ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/ |
9604 | 0.14-r0/neard-0.14/include/adapter.h include/near/adapter.h | 9604 | 0.14-r0/neard-0.14/include/adapter.h include/near/adapter.h |
9605 | | /bin/mkdir -p include/near | 9605 | | /bin/mkdir -p include/near |
9606 | | ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/ | 9606 | | ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/ |
9607 | 0.14-r0/neard-0.14/include/ndef.h include/near/ndef.h | 9607 | 0.14-r0/neard-0.14/include/ndef.h include/near/ndef.h |
9608 | | ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/ | 9608 | | ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/ |
9609 | 0.14-r0/neard-0.14/include/tlv.h include/near/tlv.h | 9609 | 0.14-r0/neard-0.14/include/tlv.h include/near/tlv.h |
9610 | | /bin/mkdir -p include/near | 9610 | | /bin/mkdir -p include/near |
9611 | | /bin/mkdir -p include/near | 9611 | | /bin/mkdir -p include/near |
9612 | | ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/ | 9612 | | ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/ |
9613 | 0.14-r0/neard-0.14/include/setting.h include/near/setting.h | 9613 | 0.14-r0/neard-0.14/include/setting.h include/near/setting.h |
9614 | | /bin/mkdir -p include/near | 9614 | | /bin/mkdir -p include/near |
9615 | | /bin/mkdir -p include/near | 9615 | | /bin/mkdir -p include/near |
9616 | | /bin/mkdir -p include/near | 9616 | | /bin/mkdir -p include/near |
9617 | | ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/ | 9617 | | ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/ |
9618 | 0.14-r0/neard-0.14/include/device.h include/near/device.h | 9618 | 0.14-r0/neard-0.14/include/device.h include/near/device.h |
9619 | | ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/ | 9619 | | ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/ |
9620 | 0.14-r0/neard-0.14/include/nfc_copy.h include/near/nfc_copy.h | 9620 | 0.14-r0/neard-0.14/include/nfc_copy.h include/near/nfc_copy.h |
9621 | | ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/ | 9621 | | ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/ |
9622 | 0.14-r0/neard-0.14/include/snep.h include/near/snep.h | 9622 | 0.14-r0/neard-0.14/include/snep.h include/near/snep.h |
9623 | | ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/ | 9623 | | ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/ |
9624 | 0.14-r0/neard-0.14/include/version.h include/near/version.h | 9624 | 0.14-r0/neard-0.14/include/version.h include/near/version.h |
9625 | | ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/ | 9625 | | ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/ |
9626 | 0.14-r0/neard-0.14/include/dbus.h include/near/dbus.h | 9626 | 0.14-r0/neard-0.14/include/dbus.h include/near/dbus.h |
9627 | | ./src/genbuiltin nfctype1 nfctype2 nfctype3 nfctype4 p2p > src/builtin.h | 9627 | | ./src/genbuiltin nfctype1 nfctype2 nfctype3 nfctype4 p2p > src/builtin.h |
9628 | | i586-poky-linux-gcc -m32 -march=i586 --sysroot=/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/ | 9628 | | i586-poky-linux-gcc -m32 -march=i586 --sysroot=/home/pokybuild/yocto-autobuilder/nightly-x86/ |
9629 | build/build/tmp/sysroots/qemux86 -DHAVE_CONFIG_H -I. -I./include -I./src -I./gdbus -I/home/pokybuild/ | 9629 | build/build/tmp/sysroots/qemux86 -DHAVE_CONFIG_H -I. -I./include -I./src -I./gdbus -I/home/pokybuild/ |
9630 | yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/sysroots/qemux86/usr/include/glib-2.0 | 9630 | yocto-autobuilder/nightly-x86/build/build/tmp/sysroots/qemux86/usr/include/glib-2.0 |
9631 | -I/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/sysroots/qemux86/usr/ | 9631 | -I/home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/sysroots/qemux86/usr/ |
9632 | lib/glib-2.0/include -I/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/ | 9632 | lib/glib-2.0/include -I/home/pokybuild/yocto-autobuilder/nightly-x86/build/build/ |
9633 | tmp/sysroots/qemux86/usr/include/dbus-1.0 -I/home/pokybuild/yocto-autobuilder/yocto-slave/ | 9633 | tmp/sysroots/qemux86/usr/include/dbus-1.0 -I/home/pokybuild/yocto-autobuilder/ |
9634 | nightly-x86/build/build/tmp/sysroots/qemux86/usr/lib/dbus-1.0/include -I/home/pokybuild/yocto-autobuilder/ | 9634 | nightly-x86/build/build/tmp/sysroots/qemux86/usr/lib/dbus-1.0/include -I/home/pokybuild/yocto-autobuilder/ |
9635 | yocto-slave/nightly-x86/build/build/tmp/sysroots/qemux86/usr/include/libnl3 | 9635 | nightly-x86/build/build/tmp/sysroots/qemux86/usr/include/libnl3 |
9636 | -DNEAR_PLUGIN_BUILTIN -DPLUGINDIR=\""/usr/lib/near/plugins"\" | 9636 | -DNEAR_PLUGIN_BUILTIN -DPLUGINDIR=\""/usr/lib/near/plugins"\" |
9637 | -DCONFIGDIR=\""/etc/neard\"" -O2 -pipe -g -feliminate-unused-debug-types -c | 9637 | -DCONFIGDIR=\""/etc/neard\"" -O2 -pipe -g -feliminate-unused-debug-types -c |
9638 | -o tools/snep-send.o tools/snep-send.c | 9638 | -o tools/snep-send.o tools/snep-send.c |
@@ -10810,12 +10810,12 @@ package:: | |||
10810 | LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly license_emgd_1.10" | 10810 | LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly license_emgd_1.10" |
10811 | 10811 | ||
10812 | As a convenience, you do not need to specify the | 10812 | As a convenience, you do not need to specify the |
10813 | complete license string in the whitelist for every package. You can use | 10813 | complete license string for every package. You can use |
10814 | an abbreviated form, which consists of just the first portion or | 10814 | an abbreviated form, which consists of just the first portion or |
10815 | portions of the license string before the initial underscore character | 10815 | portions of the license string before the initial underscore character |
10816 | or characters. A partial string will match any license that contains the | 10816 | or characters. A partial string will match any license that contains the |
10817 | given string as the first portion of its license. For example, the | 10817 | given string as the first portion of its license. For example, the |
10818 | following whitelist string will also match both of the packages | 10818 | following value will also match both of the packages |
10819 | previously mentioned as well as any other packages that have licenses | 10819 | previously mentioned as well as any other packages that have licenses |
10820 | starting with "commercial" or "license". | 10820 | starting with "commercial" or "license". |
10821 | :: | 10821 | :: |
@@ -10828,8 +10828,8 @@ License Flag Matching | |||
10828 | License flag matching allows you to control what recipes the | 10828 | License flag matching allows you to control what recipes the |
10829 | OpenEmbedded build system includes in the build. Fundamentally, the | 10829 | OpenEmbedded build system includes in the build. Fundamentally, the |
10830 | build system attempts to match :term:`LICENSE_FLAGS` strings found in | 10830 | build system attempts to match :term:`LICENSE_FLAGS` strings found in |
10831 | recipes against :term:`LICENSE_FLAGS_WHITELIST` strings found in the | 10831 | recipes against strings found in :term:`LICENSE_FLAGS_WHITELIST`. |
10832 | whitelist. A match causes the build system to include a recipe in the | 10832 | A match causes the build system to include a recipe in the |
10833 | build, while failure to find a match causes the build system to exclude | 10833 | build, while failure to find a match causes the build system to exclude |
10834 | a recipe. | 10834 | a recipe. |
10835 | 10835 | ||
@@ -10837,18 +10837,19 @@ In general, license flag matching is simple. However, understanding some | |||
10837 | concepts will help you correctly and effectively use matching. | 10837 | concepts will help you correctly and effectively use matching. |
10838 | 10838 | ||
10839 | Before a flag defined by a particular recipe is tested against the | 10839 | Before a flag defined by a particular recipe is tested against the |
10840 | contents of the whitelist, the expanded string ``_${PN}`` is appended to | 10840 | entries of :term:`LICENSE_FLAGS_WHITELIST`, the expanded |
10841 | the flag. This expansion makes each :term:`LICENSE_FLAGS` value | 10841 | string ``_${PN}`` is appended to the flag. This expansion makes each |
10842 | recipe-specific. After expansion, the string is then matched against the | 10842 | :term:`LICENSE_FLAGS` value recipe-specific. After expansion, the |
10843 | whitelist. Thus, specifying ``LICENSE_FLAGS = "commercial"`` in recipe | 10843 | string is then matched against the entries. Thus, specifying |
10844 | "foo", for example, results in the string ``"commercial_foo"``. And, to | 10844 | ``LICENSE_FLAGS = "commercial"`` in recipe "foo", for example, results |
10845 | create a match, that string must appear in the whitelist. | 10845 | in the string ``"commercial_foo"``. And, to create a match, that string |
10846 | must appear among the entries of :term:`LICENSE_FLAGS_WHITELIST`. | ||
10846 | 10847 | ||
10847 | Judicious use of the :term:`LICENSE_FLAGS` strings and the contents of the | 10848 | Judicious use of the :term:`LICENSE_FLAGS` strings and the contents of the |
10848 | :term:`LICENSE_FLAGS_WHITELIST` variable allows you a lot of flexibility for | 10849 | :term:`LICENSE_FLAGS_WHITELIST` variable allows you a lot of flexibility for |
10849 | including or excluding recipes based on licensing. For example, you can | 10850 | including or excluding recipes based on licensing. For example, you can |
10850 | broaden the matching capabilities by using license flags string subsets | 10851 | broaden the matching capabilities by using license flags string subsets |
10851 | in the whitelist. | 10852 | in :term:`LICENSE_FLAGS_WHITELIST`. |
10852 | 10853 | ||
10853 | .. note:: | 10854 | .. note:: |
10854 | 10855 | ||
@@ -10856,43 +10857,44 @@ in the whitelist. | |||
10856 | string that precedes the appended underscore character (e.g. | 10857 | string that precedes the appended underscore character (e.g. |
10857 | ``usethispart_1.3``, ``usethispart_1.4``, and so forth). | 10858 | ``usethispart_1.3``, ``usethispart_1.4``, and so forth). |
10858 | 10859 | ||
10859 | For example, simply specifying the string "commercial" in the whitelist | 10860 | For example, simply specifying the string "commercial" in the |
10860 | matches any expanded :term:`LICENSE_FLAGS` definition that starts with the | 10861 | :term:`LICENSE_FLAGS_WHITELIST` variable matches any expanded |
10861 | string "commercial" such as "commercial_foo" and "commercial_bar", which | 10862 | :term:`LICENSE_FLAGS` definition that starts with the string |
10863 | "commercial" such as "commercial_foo" and "commercial_bar", which | ||
10862 | are the strings the build system automatically generates for | 10864 | are the strings the build system automatically generates for |
10863 | hypothetical recipes named "foo" and "bar" assuming those recipes simply | 10865 | hypothetical recipes named "foo" and "bar" assuming those recipes simply |
10864 | specify the following:: | 10866 | specify the following:: |
10865 | 10867 | ||
10866 | LICENSE_FLAGS = "commercial" | 10868 | LICENSE_FLAGS = "commercial" |
10867 | 10869 | ||
10868 | Thus, you can choose | 10870 | Thus, you can choose to exhaustively enumerate each license flag in the |
10869 | to exhaustively enumerate each license flag in the whitelist and allow | 10871 | list and allow only specific recipes into the image, or you can use a |
10870 | only specific recipes into the image, or you can use a string subset | 10872 | string subset that causes a broader range of matches to allow a range of |
10871 | that causes a broader range of matches to allow a range of recipes into | 10873 | recipes into the image. |
10872 | the image. | ||
10873 | 10874 | ||
10874 | This scheme works even if the :term:`LICENSE_FLAGS` string already has | 10875 | This scheme works even if the :term:`LICENSE_FLAGS` string already has |
10875 | ``_${PN}`` appended. For example, the build system turns the license | 10876 | ``_${PN}`` appended. For example, the build system turns the license |
10876 | flag "commercial_1.2_foo" into "commercial_1.2_foo_foo" and would match | 10877 | flag "commercial_1.2_foo" into "commercial_1.2_foo_foo" and would match |
10877 | both the general "commercial" and the specific "commercial_1.2_foo" | 10878 | both the general "commercial" and the specific "commercial_1.2_foo" |
10878 | strings found in the whitelist, as expected. | 10879 | strings found in the :term:`LICENSE_FLAGS_WHITELIST` variable, as expected. |
10879 | 10880 | ||
10880 | Here are some other scenarios: | 10881 | Here are some other scenarios: |
10881 | 10882 | ||
10882 | - You can specify a versioned string in the recipe such as | 10883 | - You can specify a versioned string in the recipe such as |
10883 | "commercial_foo_1.2" in a "foo" recipe. The build system expands this | 10884 | "commercial_foo_1.2" in a "foo" recipe. The build system expands this |
10884 | string to "commercial_foo_1.2_foo". Combine this license flag with a | 10885 | string to "commercial_foo_1.2_foo". Combine this license flag with a |
10885 | whitelist that has the string "commercial" and you match the flag | 10886 | :term:`LICENSE_FLAGS_WHITELIST` variable that has the string |
10886 | along with any other flag that starts with the string "commercial". | 10887 | "commercial" and you match the flag along with any other flag that |
10888 | starts with the string "commercial". | ||
10887 | 10889 | ||
10888 | - Under the same circumstances, you can use "commercial_foo" in the | 10890 | - Under the same circumstances, you can add "commercial_foo" in the |
10889 | whitelist and the build system not only matches "commercial_foo_1.2" | 10891 | :term:`LICENSE_FLAGS_WHITELIST` variable and the build system not only |
10890 | but also matches any license flag with the string "commercial_foo", | 10892 | matches "commercial_foo_1.2" but also matches any license flag with |
10891 | regardless of the version. | 10893 | the string "commercial_foo", regardless of the version. |
10892 | 10894 | ||
10893 | - You can be very specific and use both the package and version parts | 10895 | - You can be very specific and use both the package and version parts |
10894 | in the whitelist (e.g. "commercial_foo_1.2") to specifically match a | 10896 | in the :term:`LICENSE_FLAGS_WHITELIST` list (e.g. |
10895 | versioned recipe. | 10897 | "commercial_foo_1.2") to specifically match a versioned recipe. |
10896 | 10898 | ||
10897 | Other Variables Related to Commercial Licenses | 10899 | Other Variables Related to Commercial Licenses |
10898 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 10900 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
@@ -10916,9 +10918,10 @@ file:: | |||
10916 | LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly commercial_gst-plugins-bad commercial_qmmp" | 10918 | LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly commercial_gst-plugins-bad commercial_qmmp" |
10917 | 10919 | ||
10918 | 10920 | ||
10919 | Of course, you could also create a matching whitelist for those | 10921 | Of course, you could also create a matching list for those |
10920 | components using the more general "commercial" in the whitelist, but | 10922 | components using the more general "commercial" in the |
10921 | that would also enable all the other packages with :term:`LICENSE_FLAGS` | 10923 | :term:`LICENSE_FLAGS_WHITELIST` variable, but that would also enable all |
10924 | the other packages with :term:`LICENSE_FLAGS` | ||
10922 | containing "commercial", which you may or may not want:: | 10925 | containing "commercial", which you may or may not want:: |
10923 | 10926 | ||
10924 | LICENSE_FLAGS_WHITELIST = "commercial" | 10927 | LICENSE_FLAGS_WHITELIST = "commercial" |
diff --git a/documentation/kernel-dev/advanced.rst b/documentation/kernel-dev/advanced.rst index 5a6b466ffb..b5290b61b3 100644 --- a/documentation/kernel-dev/advanced.rst +++ b/documentation/kernel-dev/advanced.rst | |||
@@ -763,7 +763,7 @@ Organizing Your Source | |||
763 | ====================== | 763 | ====================== |
764 | 764 | ||
765 | Many recipes based on the ``linux-yocto-custom.bb`` recipe use Linux | 765 | Many recipes based on the ``linux-yocto-custom.bb`` recipe use Linux |
766 | kernel sources that have only a single branch - "master". This type of | 766 | kernel sources that have only a single branch. This type of |
767 | repository structure is fine for linear development supporting a single | 767 | repository structure is fine for linear development supporting a single |
768 | machine and architecture. However, if you work with multiple boards and | 768 | machine and architecture. However, if you work with multiple boards and |
769 | architectures, a kernel source repository with multiple branches is more | 769 | 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 | |||
772 | fundamentally wrong, yet they are still necessary for specific boards. | 772 | fundamentally wrong, yet they are still necessary for specific boards. |
773 | In these situations, you most likely do not want to include these | 773 | In these situations, you most likely do not want to include these |
774 | patches in every kernel you build (i.e. have the patches as part of the | 774 | patches in every kernel you build (i.e. have the patches as part of the |
775 | lone "master" branch). It is situations like these that give rise to | 775 | default branch). It is situations like these that give rise to |
776 | multiple branches used within a Linux kernel sources Git repository. | 776 | multiple branches used within a Linux kernel sources Git repository. |
777 | 777 | ||
778 | Here are repository organization strategies maximizing source reuse, | 778 | Here are repository organization strategies maximizing source reuse, |
@@ -812,7 +812,7 @@ Machine Branches | |||
812 | When you have multiple machines and architectures to support, or you are | 812 | When you have multiple machines and architectures to support, or you are |
813 | actively working on board support, it is more efficient to create | 813 | actively working on board support, it is more efficient to create |
814 | branches in the repository based on individual machines. Having machine | 814 | branches in the repository based on individual machines. Having machine |
815 | branches allows common source to remain in the "master" branch with any | 815 | branches allows common source to remain in the development branch with any |
816 | features specific to a machine stored in the appropriate machine branch. | 816 | features specific to a machine stored in the appropriate machine branch. |
817 | This organization method frees you from continually reintegrating your | 817 | This organization method frees you from continually reintegrating your |
818 | patches into a feature. | 818 | patches into a feature. |
diff --git a/documentation/kernel-dev/concepts-appx.rst b/documentation/kernel-dev/concepts-appx.rst index cf2e75d853..910318e0f9 100644 --- a/documentation/kernel-dev/concepts-appx.rst +++ b/documentation/kernel-dev/concepts-appx.rst | |||
@@ -211,8 +211,8 @@ view, there is a linear path that travels from the baseline | |||
211 | ``kernel.org``, through a select group of features and ends with their | 211 | ``kernel.org``, through a select group of features and ends with their |
212 | BSP-specific commits. In other words, the divisions of the kernel are | 212 | BSP-specific commits. In other words, the divisions of the kernel are |
213 | transparent and are not relevant to the developer on a day-to-day basis. | 213 | transparent and are not relevant to the developer on a day-to-day basis. |
214 | From the developer's perspective, this path is the "master" branch in | 214 | From the developer's perspective, this path is the development branch. |
215 | Git terms. The developer does not need to be aware of the existence of | 215 | The developer does not need to be aware of the existence of |
216 | any other branches at all. Of course, it can make sense to have these | 216 | any other branches at all. Of course, it can make sense to have these |
217 | branches in the tree, should a person decide to explore them. For | 217 | branches in the tree, should a person decide to explore them. For |
218 | example, a comparison between two BSPs at either the commit level or at | 218 | example, a comparison between two BSPs at either the commit level or at |
diff --git a/documentation/migration-guides/migration-1.6.rst b/documentation/migration-guides/migration-1.6.rst index eea3d17676..e240038a7b 100644 --- a/documentation/migration-guides/migration-1.6.rst +++ b/documentation/migration-guides/migration-1.6.rst | |||
@@ -231,7 +231,7 @@ Build Changes | |||
231 | ------------- | 231 | ------------- |
232 | 232 | ||
233 | Separate build and source directories have been enabled by default for | 233 | Separate build and source directories have been enabled by default for |
234 | selected recipes where it is known to work (a whitelist) and for all | 234 | selected recipes where it is known to work and for all |
235 | recipes that inherit the :ref:`cmake <ref-classes-cmake>` class. In | 235 | recipes that inherit the :ref:`cmake <ref-classes-cmake>` class. In |
236 | future releases the :ref:`autotools <ref-classes-autotools>` class | 236 | future releases the :ref:`autotools <ref-classes-autotools>` class |
237 | will enable a separate build directory by default as well. Recipes | 237 | will enable a separate build directory by default as well. Recipes |
diff --git a/documentation/migration-guides/migration-3.3.rst b/documentation/migration-guides/migration-3.3.rst index f065a17e68..f982b1c80a 100644 --- a/documentation/migration-guides/migration-3.3.rst +++ b/documentation/migration-guides/migration-3.3.rst | |||
@@ -89,7 +89,7 @@ example:: | |||
89 | S = "${WORKDIR}/git/python/pythonmodule" | 89 | S = "${WORKDIR}/git/python/pythonmodule" |
90 | 90 | ||
91 | then in ``setup.py`` it works with source code in a relative fashion, such | 91 | then in ``setup.py`` it works with source code in a relative fashion, such |
92 | as ``../../src``. This causes pseudo to abort as it isn't able to track | 92 | as ``../../src``. This causes pseudo to fail as it isn't able to track |
93 | the paths properly. This release introduces a new :term:`DISTUTILS_SETUP_PATH` | 93 | the paths properly. This release introduces a new :term:`DISTUTILS_SETUP_PATH` |
94 | variable so that recipes can specify it explicitly, for example:: | 94 | variable so that recipes can specify it explicitly, for example:: |
95 | 95 | ||
diff --git a/documentation/overview-manual/concepts.rst b/documentation/overview-manual/concepts.rst index 33b4071026..bfd54208af 100644 --- a/documentation/overview-manual/concepts.rst +++ b/documentation/overview-manual/concepts.rst | |||
@@ -1718,7 +1718,7 @@ inputs still exits - items already built and present in the | |||
1718 | :term:`Build Directory`. The checksum (or | 1718 | :term:`Build Directory`. The checksum (or |
1719 | signature) for a particular task needs to add the hashes of all the | 1719 | signature) for a particular task needs to add the hashes of all the |
1720 | tasks on which the particular task depends. Choosing which dependencies | 1720 | tasks on which the particular task depends. Choosing which dependencies |
1721 | to add is a policy decision. However, the effect is to generate a master | 1721 | to add is a policy decision. However, the effect is to generate a |
1722 | checksum that combines the basehash and the hashes of the task's | 1722 | checksum that combines the basehash and the hashes of the task's |
1723 | dependencies. | 1723 | dependencies. |
1724 | 1724 | ||
@@ -1735,12 +1735,8 @@ included in any checksum):: | |||
1735 | PRSERV_DUMPDIR PRSERV_DUMPFILE PRSERV_LOCKDOWN PARALLEL_MAKE \\ | 1735 | PRSERV_DUMPDIR PRSERV_DUMPFILE PRSERV_LOCKDOWN PARALLEL_MAKE \\ |
1736 | CCACHE_DIR EXTERNAL_TOOLCHAIN CCACHE CCACHE_DISABLE LICENSE_PATH SDKPKGSUFFIX" | 1736 | CCACHE_DIR EXTERNAL_TOOLCHAIN CCACHE CCACHE_DISABLE LICENSE_PATH SDKPKGSUFFIX" |
1737 | 1737 | ||
1738 | The | 1738 | The previous example does not include :term:`WORKDIR` since that variable is |
1739 | previous example excludes | 1739 | actually constructed as a path within :term:`TMPDIR`, which is included above. |
1740 | :term:`WORKDIR` since that variable | ||
1741 | is actually constructed as a path within | ||
1742 | :term:`TMPDIR`, which is on the | ||
1743 | whitelist. | ||
1744 | 1740 | ||
1745 | The rules for deciding which hashes of dependent tasks to include | 1741 | The rules for deciding which hashes of dependent tasks to include |
1746 | through dependency chains are more complex and are generally | 1742 | through dependency chains are more complex and are generally |
diff --git a/documentation/overview-manual/development-environment.rst b/documentation/overview-manual/development-environment.rst index d719ba69eb..fc193f3135 100644 --- a/documentation/overview-manual/development-environment.rst +++ b/documentation/overview-manual/development-environment.rst | |||
@@ -163,9 +163,9 @@ these tarballs gives you a snapshot of the released files. | |||
163 | 163 | ||
164 | - Be sure to always work in matching branches for both the selected | 164 | - Be sure to always work in matching branches for both the selected |
165 | BSP repository and the Source Directory (i.e. ``poky``) | 165 | BSP repository and the Source Directory (i.e. ``poky``) |
166 | repository. For example, if you have checked out the "master" | 166 | repository. For example, if you have checked out the "&DISTRO_NAME_NO_CAP;" |
167 | branch of ``poky`` and you are going to use ``meta-intel``, be | 167 | branch of ``poky`` and you are going to use ``meta-intel``, be |
168 | sure to checkout the "master" branch of ``meta-intel``. | 168 | sure to checkout the "&DISTRO_NAME_NO_CAP;" branch of ``meta-intel``. |
169 | 169 | ||
170 | In summary, here is where you can get the project files needed for | 170 | In summary, here is where you can get the project files needed for |
171 | development: | 171 | development: |
@@ -233,8 +233,8 @@ all diverging functionality. Although there is no need to use Git, many | |||
233 | open source projects do so. | 233 | open source projects do so. |
234 | 234 | ||
235 | For the Yocto Project, a key individual called the "maintainer" is | 235 | For the Yocto Project, a key individual called the "maintainer" is |
236 | responsible for the integrity of the "master" branch of a given Git | 236 | responsible for the integrity of the development branch of a given Git |
237 | repository. The "master" branch is the "upstream" repository from which | 237 | repository. The development branch is the "upstream" repository from which |
238 | final or most recent builds of a project occur. The maintainer is | 238 | final or most recent builds of a project occur. The maintainer is |
239 | responsible for accepting changes from other developers and for | 239 | responsible for accepting changes from other developers and for |
240 | organizing the underlying branch structure to reflect release strategies | 240 | organizing the underlying branch structure to reflect release strategies |
@@ -279,8 +279,8 @@ submitting patches and changes, see the | |||
279 | ":ref:`dev-manual/common-tasks:submitting a change to the yocto project`" | 279 | ":ref:`dev-manual/common-tasks:submitting a change to the yocto project`" |
280 | section in the Yocto Project Development Tasks Manual. | 280 | section in the Yocto Project Development Tasks Manual. |
281 | 281 | ||
282 | In summary, there is a single point of entry for changes into a "master" | 282 | In summary, there is a single point of entry for changes into the |
283 | or development branch of the Git repository, which is controlled by the | 283 | development branch of the Git repository, which is controlled by the |
284 | project's maintainer. A set of developers independently | 284 | project's maintainer. A set of developers independently |
285 | develop, test, and submit changes to "contrib" areas for the maintainer | 285 | develop, test, and submit changes to "contrib" areas for the maintainer |
286 | to examine. The maintainer then chooses which changes are going to | 286 | to examine. The maintainer then chooses which changes are going to |
@@ -311,7 +311,7 @@ Book <https://book.git-scm.com>`__. | |||
311 | host. You can name these branches anything you like. It is helpful to | 311 | host. You can name these branches anything you like. It is helpful to |
312 | give them names associated with the particular feature or change on | 312 | give them names associated with the particular feature or change on |
313 | which you are working. Once you are done with a feature or change and | 313 | which you are working. Once you are done with a feature or change and |
314 | have merged it into your local master branch, simply discard the | 314 | have merged it into your local development branch, simply discard the |
315 | temporary branch. | 315 | temporary branch. |
316 | 316 | ||
317 | - *Merge Changes:* The ``git merge`` command allows you to take the | 317 | - *Merge Changes:* The ``git merge`` command allows you to take the |
@@ -348,7 +348,7 @@ Book <https://book.git-scm.com>`__. | |||
348 | 348 | ||
349 | - *Patch Workflow:* This workflow allows you to notify the maintainer | 349 | - *Patch Workflow:* This workflow allows you to notify the maintainer |
350 | through an email that you have a change (or patch) you would like | 350 | through an email that you have a change (or patch) you would like |
351 | considered for the "master" branch of the Git repository. To send | 351 | considered for the development branch of the Git repository. To send |
352 | this type of change, you format the patch and then send the email | 352 | this type of change, you format the patch and then send the email |
353 | using the Git commands ``git format-patch`` and ``git send-email``. | 353 | using the Git commands ``git format-patch`` and ``git send-email``. |
354 | For information on how to use these scripts, see the | 354 | For information on how to use these scripts, see the |
@@ -433,17 +433,12 @@ development branch in the repository. To help illustrate, consider the | |||
433 | following example Git commands:: | 433 | following example Git commands:: |
434 | 434 | ||
435 | $ cd ~ | 435 | $ cd ~ |
436 | $ git clone git://git.yoctoproject.org/poky | 436 | $ git clone git://git.yoctoproject.org/poky -b &DISTRO_NAME_NO_CAP; |
437 | $ cd poky | ||
438 | $ git checkout -b &DISTRO_NAME_NO_CAP; origin/&DISTRO_NAME_NO_CAP; | ||
439 | 437 | ||
440 | In the previous example | 438 | In the previous example |
441 | after moving to the home directory, the ``git clone`` command creates a | 439 | after moving to the home directory, the ``git clone`` command creates a |
442 | local copy of the upstream ``poky`` Git repository. By default, Git | 440 | local copy of the upstream ``poky`` Git repository and checks out a |
443 | checks out the "master" branch for your work. After changing the working | 441 | local branch named "&DISTRO_NAME_NO_CAP;", which tracks the upstream |
444 | directory to the new local repository (i.e. ``poky``), the | ||
445 | ``git checkout`` command creates and checks out a local branch named | ||
446 | "&DISTRO_NAME_NO_CAP;", which tracks the upstream | ||
447 | "origin/&DISTRO_NAME_NO_CAP;" branch. Changes you make while in this | 442 | "origin/&DISTRO_NAME_NO_CAP;" branch. Changes you make while in this |
448 | branch would ultimately affect the upstream "&DISTRO_NAME_NO_CAP;" branch | 443 | branch would ultimately affect the upstream "&DISTRO_NAME_NO_CAP;" branch |
449 | of the ``poky`` repository. | 444 | of the ``poky`` repository. |
@@ -558,9 +553,9 @@ descriptions and strategies on how to use these commands: | |||
558 | - *git pull --rebase:* Retrieves information from an upstream Git | 553 | - *git pull --rebase:* Retrieves information from an upstream Git |
559 | repository and places it in your local Git repository. You use this | 554 | repository and places it in your local Git repository. You use this |
560 | command to make sure you are synchronized with the repository from | 555 | command to make sure you are synchronized with the repository from |
561 | which you are basing changes (.e.g. the "master" branch). The | 556 | which you are basing changes (e.g. the "&DISTRO_NAME_NO_CAP;" |
562 | "--rebase" option ensures that any local commits you have in your | 557 | branch). The "--rebase" option ensures that any local commits you |
563 | branch are preserved at the top of your local branch. | 558 | have in your branch are preserved at the top of your local branch. |
564 | 559 | ||
565 | - *git push repo-name local-branch:upstream-branch:* Sends | 560 | - *git push repo-name local-branch:upstream-branch:* Sends |
566 | all your committed local changes to the upstream Git repository that | 561 | all your committed local changes to the upstream Git repository that |
@@ -571,13 +566,13 @@ descriptions and strategies on how to use these commands: | |||
571 | 566 | ||
572 | - *git merge:* Combines or adds changes from one local branch of | 567 | - *git merge:* Combines or adds changes from one local branch of |
573 | your repository with another branch. When you create a local Git | 568 | your repository with another branch. When you create a local Git |
574 | repository, the default branch is named "master". A typical workflow | 569 | repository, the default branch may be named "main". A typical |
575 | is to create a temporary branch that is based off "master" that you | 570 | workflow is to create a temporary branch that is based off "main" |
576 | would use for isolated work. You would make your changes in that | 571 | that you would use for isolated work. You would make your changes in |
577 | isolated branch, stage and commit them locally, switch to the | 572 | that isolated branch, stage and commit them locally, switch to the |
578 | "master" branch, and then use the ``git merge`` command to apply the | 573 | "main" branch, and then use the ``git merge`` command to apply the |
579 | changes from your isolated branch into the currently checked out | 574 | changes from your isolated branch into the currently checked out |
580 | branch (e.g. "master"). After the merge is complete and if you are | 575 | branch (e.g. "main"). After the merge is complete and if you are |
581 | done with working in that isolated branch, you can safely delete the | 576 | done with working in that isolated branch, you can safely delete the |
582 | isolated branch. | 577 | isolated branch. |
583 | 578 | ||
diff --git a/documentation/overview-manual/yp-intro.rst b/documentation/overview-manual/yp-intro.rst index 7aee9db04f..a8ca9e9440 100644 --- a/documentation/overview-manual/yp-intro.rst +++ b/documentation/overview-manual/yp-intro.rst | |||
@@ -371,7 +371,7 @@ Yocto Project: | |||
371 | 371 | ||
372 | - *AutoBuilder:* AutoBuilder is a project that automates build tests | 372 | - *AutoBuilder:* AutoBuilder is a project that automates build tests |
373 | and quality assurance (QA). By using the public AutoBuilder, anyone | 373 | and quality assurance (QA). By using the public AutoBuilder, anyone |
374 | can determine the status of the current "master" branch of Poky. | 374 | can determine the status of the current development branch of Poky. |
375 | 375 | ||
376 | .. note:: | 376 | .. note:: |
377 | 377 | ||
diff --git a/documentation/ref-manual/classes.rst b/documentation/ref-manual/classes.rst index e258469dcb..2c191f407e 100644 --- a/documentation/ref-manual/classes.rst +++ b/documentation/ref-manual/classes.rst | |||
@@ -214,13 +214,13 @@ the class. | |||
214 | ===================== | 214 | ===================== |
215 | 215 | ||
216 | The ``blacklist`` class prevents the OpenEmbedded build system from | 216 | The ``blacklist`` class prevents the OpenEmbedded build system from |
217 | building specific recipes (blacklists them). To use this class, inherit | 217 | building specific recipes. To use this class, inherit |
218 | the class globally and set :term:`PNBLACKLIST` for | 218 | the class globally and set :term:`PNBLACKLIST` for |
219 | each recipe you wish to blacklist. Specify the :term:`PN` | 219 | each recipe you wish to ignore. Specify the :term:`PN` |
220 | value as a variable flag (varflag) and provide a reason, which is | 220 | value as a variable flag (varflag) and provide a reason, which is |
221 | reported, if the package is requested to be built as the value. For | 221 | reported, if the package is requested to be built as the value. For |
222 | example, if you want to blacklist a recipe called "exoticware", you add | 222 | example, if you want to ignore a recipe called "exoticware", you |
223 | the following to your ``local.conf`` or distribution configuration:: | 223 | add the following to your ``local.conf`` or distribution configuration:: |
224 | 224 | ||
225 | INHERIT += "blacklist" | 225 | INHERIT += "blacklist" |
226 | PNBLACKLIST[exoticware] = "Not supported by our organization." | 226 | PNBLACKLIST[exoticware] = "Not supported by our organization." |
@@ -845,10 +845,10 @@ provided by the recipe ``icecc-create-env-native.bb``. | |||
845 | icecc. | 845 | icecc. |
846 | 846 | ||
847 | If you do not want the Icecream distributed compile support to apply to | 847 | If you do not want the Icecream distributed compile support to apply to |
848 | specific recipes or classes, you can effectively "blacklist" them by | 848 | specific recipes or classes, you can ask them to be ignored by Icecream |
849 | listing the recipes and classes using the | 849 | by listing the recipes and classes using the |
850 | :term:`ICECC_USER_PACKAGE_BL` and | 850 | :term:`ICECC_USER_PACKAGE_BL` and |
851 | :term:`ICECC_USER_CLASS_BL`, variables, | 851 | :term:`ICECC_USER_CLASS_BL` variables, |
852 | respectively, in your ``local.conf`` file. Doing so causes the | 852 | respectively, in your ``local.conf`` file. Doing so causes the |
853 | OpenEmbedded build system to handle these compilations locally. | 853 | OpenEmbedded build system to handle these compilations locally. |
854 | 854 | ||
diff --git a/documentation/ref-manual/images.rst b/documentation/ref-manual/images.rst index c6a7239c7e..0e3351bb7b 100644 --- a/documentation/ref-manual/images.rst +++ b/documentation/ref-manual/images.rst | |||
@@ -112,7 +112,7 @@ Following is a list of supported recipes: | |||
112 | development headers and libraries to form a complete standalone SDK | 112 | development headers and libraries to form a complete standalone SDK |
113 | and is suitable for development using the target. | 113 | and is suitable for development using the target. |
114 | 114 | ||
115 | - ``core-image-testmaster``: A "master" image designed to be used for | 115 | - ``core-image-testmaster``: A "controller" image designed to be used for |
116 | automated runtime testing. Provides a "known good" image that is | 116 | automated runtime testing. Provides a "known good" image that is |
117 | deployed to a separate partition so that you can boot into it and use | 117 | deployed to a separate partition so that you can boot into it and use |
118 | it to deploy a second image to be tested. You can find more | 118 | it to deploy a second image to be tested. You can find more |
diff --git a/documentation/ref-manual/terms.rst b/documentation/ref-manual/terms.rst index 89b140e3fe..09e0a98bb5 100644 --- a/documentation/ref-manual/terms.rst +++ b/documentation/ref-manual/terms.rst | |||
@@ -404,7 +404,7 @@ universal, the list includes them just in case: | |||
404 | 404 | ||
405 | :term:`Upstream` | 405 | :term:`Upstream` |
406 | A reference to source code or repositories that are not | 406 | A reference to source code or repositories that are not |
407 | local to the development system but located in a master area that is | 407 | local to the development system but located in a remote area that is |
408 | controlled by the maintainer of the source code. For example, in | 408 | controlled by the maintainer of the source code. For example, in |
409 | order for a developer to work on a particular piece of code, they | 409 | order for a developer to work on a particular piece of code, they |
410 | need to first get a copy of it from an "upstream" source. | 410 | need to first get a copy of it from an "upstream" source. |
diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst index 83f39af2cf..e5216b3f36 100644 --- a/documentation/ref-manual/variables.rst +++ b/documentation/ref-manual/variables.rst | |||
@@ -400,7 +400,7 @@ system and gives an overview of their function and contents. | |||
400 | where: | 400 | where: |
401 | 401 | ||
402 | action is: | 402 | action is: |
403 | ABORT: Immediately abort the build when | 403 | ABORT: Immediately stop the build when |
404 | a threshold is broken. | 404 | a threshold is broken. |
405 | STOPTASKS: Stop the build after the currently | 405 | STOPTASKS: Stop the build after the currently |
406 | executing tasks have finished when | 406 | executing tasks have finished when |
@@ -438,7 +438,7 @@ system and gives an overview of their function and contents. | |||
438 | The first example works only if you also provide the | 438 | The first example works only if you also provide the |
439 | :term:`BB_DISKMON_WARNINTERVAL` | 439 | :term:`BB_DISKMON_WARNINTERVAL` |
440 | variable in the ``conf/local.conf``. This example causes the build | 440 | variable in the ``conf/local.conf``. This example causes the build |
441 | system to immediately abort when either the disk space in | 441 | system to immediately stop when either the disk space in |
442 | ``${TMPDIR}`` drops below 1 Gbyte or the available free inodes drops | 442 | ``${TMPDIR}`` drops below 1 Gbyte or the available free inodes drops |
443 | below 100 Kbytes. Because two directories are provided with the | 443 | below 100 Kbytes. Because two directories are provided with the |
444 | variable, the build system also issue a warning when the disk space | 444 | 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. | |||
452 | directory drops below 1 Gbyte. No disk monitoring occurs for the free | 452 | directory drops below 1 Gbyte. No disk monitoring occurs for the free |
453 | inodes in this case. | 453 | inodes in this case. |
454 | 454 | ||
455 | The final example immediately aborts the build when the number of | 455 | The final example immediately stops the build when the number of |
456 | free inodes in the ``${TMPDIR}`` directory drops below 100 Kbytes. No | 456 | free inodes in the ``${TMPDIR}`` directory drops below 100 Kbytes. No |
457 | disk space monitoring for the directory itself occurs in this case. | 457 | disk space monitoring for the directory itself occurs in this case. |
458 | 458 | ||
@@ -652,7 +652,7 @@ system and gives an overview of their function and contents. | |||
652 | " | 652 | " |
653 | 653 | ||
654 | This next example shows an error message that occurs because invalid | 654 | This next example shows an error message that occurs because invalid |
655 | entries are found, which cause parsing to abort: | 655 | entries are found, which cause parsing to fail: |
656 | 656 | ||
657 | .. code-block:: none | 657 | .. code-block:: none |
658 | 658 | ||
@@ -2894,9 +2894,9 @@ system and gives an overview of their function and contents. | |||
2894 | :ref:`icecc <ref-classes-icecc>` class. You set this variable in | 2894 | :ref:`icecc <ref-classes-icecc>` class. You set this variable in |
2895 | your ``local.conf`` file. | 2895 | your ``local.conf`` file. |
2896 | 2896 | ||
2897 | When you list classes using this variable, you are "blacklisting" | 2897 | When you list classes using this variable, the recipes inheriting |
2898 | them from distributed compilation across remote hosts. Any classes | 2898 | those classes will not benefit from distributed compilation across |
2899 | you list will be distributed and compiled locally. | 2899 | remote hosts. Instead they will be built locally. |
2900 | 2900 | ||
2901 | :term:`ICECC_USER_PACKAGE_BL` | 2901 | :term:`ICECC_USER_PACKAGE_BL` |
2902 | Identifies user recipes that you do not want the Icecream distributed | 2902 | 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. | |||
2904 | :ref:`icecc <ref-classes-icecc>` class. You set this variable in | 2904 | :ref:`icecc <ref-classes-icecc>` class. You set this variable in |
2905 | your ``local.conf`` file. | 2905 | your ``local.conf`` file. |
2906 | 2906 | ||
2907 | When you list packages using this variable, you are "blacklisting" | 2907 | When you list recipes using this variable, you are excluding them |
2908 | them from distributed compilation across remote hosts. Any packages | 2908 | from distributed compilation across remote hosts. Instead they will |
2909 | you list will be distributed and compiled locally. | 2909 | be built locally. |
2910 | 2910 | ||
2911 | :term:`ICECC_USER_PACKAGE_WL` | 2911 | :term:`ICECC_USER_PACKAGE_WL` |
2912 | Identifies user recipes that use an empty | 2912 | Identifies user recipes that use an empty |
@@ -4366,9 +4366,9 @@ system and gives an overview of their function and contents. | |||
4366 | section in the Yocto Project Development Tasks Manual. | 4366 | section in the Yocto Project Development Tasks Manual. |
4367 | 4367 | ||
4368 | :term:`LICENSE_FLAGS` | 4368 | :term:`LICENSE_FLAGS` |
4369 | Specifies additional flags for a recipe you must whitelist through | 4369 | Specifies additional flags for a recipe you must allow through |
4370 | :term:`LICENSE_FLAGS_WHITELIST` in | 4370 | :term:`LICENSE_FLAGS_WHITELIST` in |
4371 | order to allow the recipe to be built. When providing multiple flags, | 4371 | order for the recipe to be built. When providing multiple flags, |
4372 | separate them with spaces. | 4372 | separate them with spaces. |
4373 | 4373 | ||
4374 | This value is independent of :term:`LICENSE` and is | 4374 | This value is independent of :term:`LICENSE` and is |
@@ -4381,8 +4381,7 @@ system and gives an overview of their function and contents. | |||
4381 | :term:`LICENSE_FLAGS_WHITELIST` | 4381 | :term:`LICENSE_FLAGS_WHITELIST` |
4382 | Lists license flags that when specified in | 4382 | Lists license flags that when specified in |
4383 | :term:`LICENSE_FLAGS` within a recipe should not | 4383 | :term:`LICENSE_FLAGS` within a recipe should not |
4384 | prevent that recipe from being built. This practice is otherwise | 4384 | prevent that recipe from being built. For more information, see the |
4385 | known as "whitelisting" license flags. For more information, see the | ||
4386 | ":ref:`dev-manual/common-tasks:enabling commercially licensed recipes`" | 4385 | ":ref:`dev-manual/common-tasks:enabling commercially licensed recipes`" |
4387 | section in the Yocto Project Development Tasks Manual. | 4386 | section in the Yocto Project Development Tasks Manual. |
4388 | 4387 | ||
@@ -5186,8 +5185,8 @@ system and gives an overview of their function and contents. | |||
5186 | .. note:: | 5185 | .. note:: |
5187 | 5186 | ||
5188 | You can use the :term:`PACKAGE_FEED_ARCHS` | 5187 | You can use the :term:`PACKAGE_FEED_ARCHS` |
5189 | variable to whitelist specific package architectures. If you do | 5188 | variable to allow specific package architectures. If you do |
5190 | not need to whitelist specific architectures, which is a common | 5189 | not need to allow specific architectures, which is a common |
5191 | case, you can omit this variable. Omitting the variable results in | 5190 | case, you can omit this variable. Omitting the variable results in |
5192 | all available architectures for the current machine being included | 5191 | all available architectures for the current machine being included |
5193 | into remote package feeds. | 5192 | into remote package feeds. |
@@ -6583,9 +6582,9 @@ system and gives an overview of their function and contents. | |||
6583 | :ref:`populate-sdk-ext <ref-classes-populate-sdk-*>` class. | 6582 | :ref:`populate-sdk-ext <ref-classes-populate-sdk-*>` class. |
6584 | 6583 | ||
6585 | This list overrides the variables specified using the | 6584 | This list overrides the variables specified using the |
6586 | :term:`SDK_LOCAL_CONF_BLACKLIST` | 6585 | :term:`SDK_LOCAL_CONF_BLACKLIST` variable as well as |
6587 | variable as well as any variables identified by automatic | 6586 | other variables automatically added due to the "/" character |
6588 | blacklisting due to the "/" character being found at the start of the | 6587 | being found at the start of the |
6589 | value, which is usually indicative of being a path and thus might not | 6588 | value, which is usually indicative of being a path and thus might not |
6590 | be valid on the system where the SDK is installed. | 6589 | be valid on the system where the SDK is installed. |
6591 | 6590 | ||
@@ -8244,7 +8243,7 @@ system and gives an overview of their function and contents. | |||
8244 | variable is used. | 8243 | variable is used. |
8245 | 8244 | ||
8246 | :term:`TUNEABI_WHITELIST` | 8245 | :term:`TUNEABI_WHITELIST` |
8247 | A whitelist of permissible :term:`TUNEABI` values. If | 8246 | A list of permissible :term:`TUNEABI` values. If |
8248 | :term:`TUNEABI_WHITELIST` is not set, all tunes are allowed. Providers | 8247 | :term:`TUNEABI_WHITELIST` is not set, all tunes are allowed. Providers |
8249 | that use prebuilt libraries can use the :term:`TUNEABI_WHITELIST`, | 8248 | that use prebuilt libraries can use the :term:`TUNEABI_WHITELIST`, |
8250 | :term:`TUNEABI_OVERRIDE`, and :term:`TUNEABI` | 8249 | :term:`TUNEABI_OVERRIDE`, and :term:`TUNEABI` |
diff --git a/documentation/sdk-manual/appendix-customizing.rst b/documentation/sdk-manual/appendix-customizing.rst index 4eccc28e9b..cac199bf7a 100644 --- a/documentation/sdk-manual/appendix-customizing.rst +++ b/documentation/sdk-manual/appendix-customizing.rst | |||
@@ -43,7 +43,7 @@ build system applies them against ``local.conf`` and ``auto.conf``: | |||
43 | :term:`SDK_INHERIT_BLACKLIST` | 43 | :term:`SDK_INHERIT_BLACKLIST` |
44 | are disabled. Using :term:`SDK_INHERIT_BLACKLIST` to disable these | 44 | are disabled. Using :term:`SDK_INHERIT_BLACKLIST` to disable these |
45 | classes is the typical method to disable classes that are problematic | 45 | classes is the typical method to disable classes that are problematic |
46 | or unnecessary in the SDK context. The default value blacklists the | 46 | or unnecessary in the SDK context. The default value disables the |
47 | :ref:`buildhistory <ref-classes-buildhistory>` | 47 | :ref:`buildhistory <ref-classes-buildhistory>` |
48 | and :ref:`icecc <ref-classes-icecc>` classes. | 48 | and :ref:`icecc <ref-classes-icecc>` classes. |
49 | 49 | ||
@@ -63,9 +63,8 @@ adjustments: | |||
63 | - If your SDK configuration inherits additional classes using the | 63 | - If your SDK configuration inherits additional classes using the |
64 | :term:`INHERIT` variable and you | 64 | :term:`INHERIT` variable and you |
65 | do not need or want those classes enabled in the SDK, you can | 65 | do not need or want those classes enabled in the SDK, you can |
66 | blacklist them by adding them to the | 66 | disable them by adding them to the :term:`SDK_INHERIT_BLACKLIST` |
67 | :term:`SDK_INHERIT_BLACKLIST` | 67 | variable as described in the previous section. |
68 | variable as described in the fourth bullet of the previous section. | ||
69 | 68 | ||
70 | .. note:: | 69 | .. note:: |
71 | 70 | ||
@@ -275,8 +274,8 @@ source, you need to do a number of things: | |||
275 | places or it will fail quickly on the OpenEmbedded build system | 274 | places or it will fail quickly on the OpenEmbedded build system |
276 | side, and its contents will not interfere with the build), then | 275 | side, and its contents will not interfere with the build), then |
277 | you can set the variable in your ``local.conf`` or custom distro | 276 | you can set the variable in your ``local.conf`` or custom distro |
278 | configuration file. You can then "whitelist" the variable through | 277 | configuration file. You can then pass the variable to the SDK by |
279 | to the SDK by adding the following:: | 278 | adding the following:: |
280 | 279 | ||
281 | SDK_LOCAL_CONF_WHITELIST = "SSTATE_MIRRORS" | 280 | SDK_LOCAL_CONF_WHITELIST = "SSTATE_MIRRORS" |
282 | 281 | ||