poky: subtree update:7d0988966c..1203d1f24d
Alexander Kanavin (5):
mesa: update 21.0.0 -> 21.0.1
runqemu: do not stop processing graphical options after nographic
mesa: gallium option requires libdrm
mesa: enable dri in native/nativesdk through gallium drivers
ptest-runner: correct version check
Alistair Francis (2):
conf/machine: Enable bochs-display on RISC-V machines
conf/machine: Enable keyboard and mouse on RISC-V machines
Anibal Limon (1):
ptest-runner: Upgrade to 2.4.1
Awais Belal (2):
perl: allow empty lines and comments in perl-rdepends.txt
perl: fix creation and generate new perl-rdepends.txt
Bruce Ashfield (1):
perf-tests: add bash into RDEPENDS (v5.12-rc5+)
Chen Qi (1):
apt: Fix do_compile error when enable ccache
Denys Dmytriyenko (1):
make-mod-scripts: pass CROSS_COMPILE to configure and build
Guillaume Champagne (1):
image-live.bbclass: optional depends when ROOTFS empty
Janne Kiiskila (1):
poky.yaml: Use git instead of git-core for Ubunti
Joshua Watt (1):
bitbake.conf: Limit the number of OpenMP threads
Khem Raj (3):
mesa-gl: Use swrast gallium driver
binutils: Fix a missing break in case statement
webkitgtk: Drop include_array.patch
Klaus Heinrich Kiwi (6):
uboot: Deploy default symlinks with fitImage
u-boot: Move definitions to common locations
u-boot: Add infrastructure to SPL verified boot
u-boot: Use a different Key for SPL signing
oe-selftest: Add U-Boot fitImage signing testcases
uboot: Fixes SPL verified boot on corner cases
Matt Madison (1):
libxcb: use PN for naming dynamic packages
Michael Halstead (1):
releases: update to include 3.2.3
Michael Opdenacker (7):
manuals: Spellcheck and capitalization fixes
SDK manual: fix reference to appendix
Quick build: checkout a branch instead of a fixed tag
manuals: Fix typos and spacing
overview-manual: style improvements
ref-manual: fix typo
manuals: fix suspicious newlines
Nicolas Dechesne (1):
docs: add a top level page for bitbake documentation
Paul Eggleton (16):
bitbake: bitbake-user-manual: document no support for using passwords in git URLs
bitbake: bitbake-user-manual: add REQUIRED_VERSION and adjust PREFERRED_VERSION entry
ref-manual: add METADATA_REVISION and METADATA_BRANCH
Use variables for minimum host versions and bump Python to 3.6
ref-manual: update/fix text for SDK_VERSION
overview-manual: fix git command line
ref-manual: and SDK_CUSTOM_TEMPLATECONF to glossary
ref-manual: add REQUIRED_VERSION and adjust PREFERRED_VERSION entry
ref-manual: add python3targetconfig class and remove python 2 references
ref-manual: add passwd-expire to EXTRA_USERS_PARAMS
ref-manual: add FIT_KERNEL_COMP_ALG*
ref-manual: fix reference to build-essential
ref-manual: tweak buildtools section
ref-manual: add migration section for 3.3 release
ref-manual: migration guide: add release codenames
ref-manual: add mention of DISTUTILS_SETUP_PATH
Quentin Schulz (1):
docs: replace anchor links
Richard Purdie (9):
oeqa/concurrencytest: Rename variables to improve the code
oeqa/concurrencytest: Fix display of test stdout/stderr
diffoscope: Upgrade 168 -> 172
oeqa/runqemu: Support RUNQEMU_TMPFS_DIR as a location to copy snapshot images to
bitbake: runqueue: Further fixes for confused setscene tasks
documentation/poky.yaml: Fix latest 3.2 series tag reference
poky.conf: Bump version for 3.3 hardknott release
build-appliance-image: Update to master head revision
bitbake: bitbake: Update version to 1.50.0 stable release series
Ross Burton (2):
poky.yaml: change gcc-multilib to gcc
oeqa/selftest: add test case for SRC_URI dependency sniffing
Ulrich Ölmann (1):
sdk-manual: fix typo
Yann Dirson (1):
kernel-yocto: fix do_kernel_configme indentation
Yi Fan Yu (2):
python3: Skip failing ptests due to load variability
valgrind: print failed ptest details
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Change-Id: Id57d0682ec91b67b90fac931313457f5ed6f3d5c
diff --git a/poky/documentation/overview-manual/concepts.rst b/poky/documentation/overview-manual/concepts.rst
index 257de44..ada5143 100644
--- a/poky/documentation/overview-manual/concepts.rst
+++ b/poky/documentation/overview-manual/concepts.rst
@@ -132,7 +132,7 @@
Layers are repositories that contain related metadata (i.e. sets of
instructions) that tell the OpenEmbedded build system how to build a
-target. Yocto Project's `layer model <#the-yocto-project-layer-model>`__
+target. :ref:`overview-manual/yp-intro:the yocto project layer model`
facilitates collaboration, sharing, customization, and reuse within the
Yocto Project development environment. Layers logically separate
information for your project. For example, you can use a layer to hold
@@ -207,8 +207,8 @@
the image, where to store downloaded source, and other build properties.
The following figure shows an expanded representation of the "User
-Configuration" box of the `general workflow
-figure <#general-workflow-figure>`__:
+Configuration" box of the :ref:`general workflow
+figure <overview-manual/concepts:openembedded build system concepts>`:
.. image:: figures/user-configuration.png
:align: center
@@ -374,7 +374,7 @@
In general, three types of layer input exists. You can see them below
the "User Configuration" box in the `general workflow
-figure <#general-workflow-figure>`__:
+figure <overview-manual/concepts:openembedded build system concepts>`:
- *Metadata (.bb + Patches):* Software layers containing
user-supplied recipe files, patches, and append files. A good example
@@ -387,8 +387,8 @@
- *Machine BSP Configuration:* Board Support Package (BSP) layers (i.e.
"BSP Layer" in the following figure) providing machine-specific
configurations. This type of information is specific to a particular
- target architecture. A good example of a BSP layer from the `Poky
- Reference Distribution <#gs-reference-distribution-poky>`__ is the
+ target architecture. A good example of a BSP layer from the
+ :ref:`overview-manual/yp-intro:reference distribution (poky)` is the
:yocto_git:`meta-yocto-bsp </poky/tree/meta-yocto-bsp>`
layer.
@@ -403,7 +403,8 @@
that contain many policy configurations for the Poky distribution.
The following figure shows an expanded representation of these three
-layers from the `general workflow figure <#general-workflow-figure>`__:
+layers from the :ref:`general workflow figure
+<overview-manual/concepts:openembedded build system concepts>`:
.. image:: figures/layer-input.png
:align: center
@@ -418,9 +419,9 @@
section in the
Yocto Project Development Tasks Manual. For a general discussion on
layers and the many layers from which you can draw, see the
-"`Layers <#overview-layers>`__" and "`The Yocto Project Layer
-Model <#the-yocto-project-layer-model>`__" sections both earlier in this
-manual.
+":ref:`overview-manual/concepts:layers`" and
+":ref:`overview-manual/yp-intro:the yocto project layer model`" sections both
+earlier in this manual.
If you explored the previous links, you discovered some areas where many
layers that work with the Yocto Project exist. The :yocto_git:`Source
@@ -514,11 +515,12 @@
-------
In order for the OpenEmbedded build system to create an image or any
-target, it must be able to access source files. The `general workflow
-figure <#general-workflow-figure>`__ represents source files using the
-"Upstream Project Releases", "Local Projects", and "SCMs (optional)"
-boxes. The figure represents mirrors, which also play a role in locating
-source files, with the "Source Materials" box.
+target, it must be able to access source files. The :ref:`general workflow
+figure <overview-manual/concepts:openembedded build system concepts>`
+represents source files using the "Upstream Project Releases", "Local
+Projects", and "SCMs (optional)" boxes. The figure represents mirrors,
+which also play a role in locating source files, with the "Source
+Materials" box.
The method by which source files are ultimately organized is a function
of the project. For example, for released software, projects tend to use
@@ -554,7 +556,7 @@
The remainder of this section provides a deeper look into the source
files and the mirrors. Here is a more detailed look at the source file
-area of the `general workflow figure <#general-workflow-figure>`__:
+area of the :ref:`general workflow figure <overview-manual/concepts:openembedded build system concepts>`:
.. image:: figures/source-input.png
:align: center
@@ -628,9 +630,9 @@
When the OpenEmbedded build system generates an image or an SDK, it gets
the packages from a package feed area located in the
-:term:`Build Directory`. The `general
-workflow figure <#general-workflow-figure>`__ shows this package feeds
-area in the upper-right corner.
+:term:`Build Directory`. The :ref:`general workflow figure
+<overview-manual/concepts:openembedded build system concepts>`
+shows this package feeds area in the upper-right corner.
This section looks a little closer into the package feeds area used by
the build system. Here is a more detailed look at the area:
@@ -691,10 +693,10 @@
The OpenEmbedded build system uses
:term:`BitBake` to produce images and
-Software Development Kits (SDKs). You can see from the `general workflow
-figure <#general-workflow-figure>`__, the BitBake area consists of
-several functional areas. This section takes a closer look at each of
-those areas.
+Software Development Kits (SDKs). You can see from the :ref:`general workflow
+figure <overview-manual/concepts:openembedded build system concepts>`,
+the BitBake area consists of several functional areas. This section takes a
+closer look at each of those areas.
.. note::
@@ -820,7 +822,7 @@
:term:`S` directory.
For more information on how the source directories are created, see the
-"`Source Fetching <#source-fetching-dev-environment>`__" section. For
+":ref:`overview-manual/concepts:source fetching`" section. For
more information on how to create patches and how the build system
processes patches, see the
":ref:`dev-manual/common-tasks:patching code`"
@@ -957,8 +959,8 @@
Depending on the type of packages being created (RPM, DEB, or IPK), the
:ref:`do_package_write_* <ref-tasks-package_write_deb>`
task creates the actual packages and places them in the Package Feed
-area, which is ``${TMPDIR}/deploy``. You can see the "`Package
-Feeds <#package-feeds-dev-environment>`__" section for more detail on
+area, which is ``${TMPDIR}/deploy``. You can see the
+":ref:`overview-manual/concepts:package feeds`" section for more detail on
that part of the build process.
.. note::
@@ -1119,7 +1121,7 @@
:ref:`ref-tasks-populate_sdk_ext`
tasks use these key variables to help create the list of packages to
actually install. For information on the variables listed in the figure,
-see the "`Application Development SDK <#sdk-dev-environment>`__"
+see the ":ref:`overview-manual/concepts:application development sdk`"
section.
The ``do_populate_sdk`` task helps create the standard SDK and handles
@@ -1147,8 +1149,8 @@
into the :term:`STAMPS_DIR`
directory. The beginning of the stamp file's filename is determined by
the :term:`STAMP` variable, and the end
-of the name consists of the task's name and current `input
-checksum <#overview-checksums>`__.
+of the name consists of the task's name and current :ref:`input
+checksum <overview-manual/concepts:checksums (signatures)>`.
.. note::
@@ -1165,10 +1167,10 @@
.. note::
The stamp mechanism is more general than the shared state (sstate)
- cache mechanism described in the "`Setscene Tasks and Shared
- State <#setscene-tasks-and-shared-state>`__" section. BitBake avoids
- rerunning any task that has a valid stamp file, not just tasks that
- can be accelerated through the sstate cache.
+ cache mechanism described in the
+ ":ref:`overview-manual/concepts:setscene tasks and shared state`" section.
+ BitBake avoids rerunning any task that has a valid stamp file, not just
+ tasks that can be accelerated through the sstate cache.
However, you should realize that stamp files only serve as a marker
that some work has been done and that these files do not record task
@@ -1271,7 +1273,8 @@
The images produced by the build system are compressed forms of the root
filesystem and are ready to boot on a target device. You can see from
-the `general workflow figure <#general-workflow-figure>`__ that BitBake
+the :ref:`general workflow figure
+<overview-manual/concepts:openembedded build system concepts>` that BitBake
output, in part, consists of images. This section takes a closer look at
this output:
@@ -1327,7 +1330,8 @@
Application Development SDK
---------------------------
-In the `general workflow figure <#general-workflow-figure>`__, the
+In the :ref:`general workflow figure
+<overview-manual/concepts:openembedded build system concepts>`, the
output labeled "Application Development SDK" represents an SDK. The SDK
generation process differs depending on whether you build an extensible
SDK (e.g. ``bitbake -c populate_sdk_ext`` imagename) or a standard SDK
@@ -1357,8 +1361,8 @@
your own SDK installer.
- For background information on cross-development toolchains in the
- Yocto Project development environment, see the "`Cross-Development
- Toolchain Generation <#cross-development-toolchain-generation>`__"
+ Yocto Project development environment, see the
+ ":ref:`overview-manual/concepts:cross-development toolchain generation`"
section.
- For information on setting up a cross-development environment, see
@@ -1773,10 +1777,10 @@
BB_SIGNATURE_HANDLER ?= "OEBasicHash"
The "OEBasicHash" ``BB_SIGNATURE_HANDLER`` is the same
-as the "OEBasic" version but adds the task hash to the `stamp
-files <#stamp-files-and-the-rerunning-of-tasks>`__. This results in any
-metadata change that changes the task hash, automatically causing the
-task to be run again. This removes the need to bump
+as the "OEBasic" version but adds the task hash to the :ref:`stamp
+files <overview-manual/concepts:stamp files and the rerunning of tasks>`. This
+results in any metadata change that changes the task hash, automatically causing
+the task to be run again. This removes the need to bump
:term:`PR` values, and changes to metadata
automatically ripple across the build.
@@ -1901,9 +1905,10 @@
- The ``do_deploy[stamp-extra-info] = "${MACHINE_ARCH}"`` line appends
- extra metadata to the `stamp
- file <#stamp-files-and-the-rerunning-of-tasks>`__. In this case, the
- metadata makes the task specific to a machine's architecture. See
+ extra metadata to the :ref:`stamp
+ file <overview-manual/concepts:stamp files and the rerunning of tasks>`. In
+ this case, the metadata makes the task specific to a machine's architecture.
+ See
":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-execution:the task list`"
section in the BitBake User Manual for more information on the
``stamp-extra-info`` flag.
@@ -2111,8 +2116,7 @@
under fakeroot. Otherwise, the task cannot run root-only operations,
and cannot see the fake file ownership and permissions set by the
other task. You need to also add a dependency on
- virtual/fakeroot-native:do_populate_sysroot
- , giving the following:
+ ``virtual/fakeroot-native:do_populate_sysroot``, giving the following:
::
fakeroot do_mytask () {