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/kernel-dev/advanced.rst b/poky/documentation/kernel-dev/advanced.rst
index dd0b76b..fb6dfca 100644
--- a/poky/documentation/kernel-dev/advanced.rst
+++ b/poky/documentation/kernel-dev/advanced.rst
@@ -56,8 +56,8 @@
the same "intel-corei7-64" value for ``KMACHINE``. It is important to
realize that ``KMACHINE`` is just for kernel mapping, while ``MACHINE``
is the machine type within a BSP Layer. Even with this distinction,
-however, these two variables can hold the same value. See the `BSP
-Descriptions <#bsp-descriptions>`__ section for more information.
+however, these two variables can hold the same value. See the
+":ref:`kernel-dev/advanced:bsp descriptions`" section for more information.
Every linux-yocto style recipe must also indicate the Linux kernel
source repository branch used to build the Linux kernel. The
@@ -87,7 +87,7 @@
arguments used by the kernel tools to find the appropriate description
within the kernel Metadata with which to build out the sources and
configuration. The linux-yocto recipes define "standard", "tiny", and
-"preempt-rt" kernel types. See the "`Kernel Types <#kernel-types>`__"
+"preempt-rt" kernel types. See the ":ref:`kernel-dev/advanced:kernel types`"
section for more information on kernel types.
During the build, the kern-tools search for the BSP description file
@@ -123,8 +123,8 @@
within the kernel Metadata itself. The examples here are taken from the
``yocto-kernel-cache`` repository. Each branch of this repository
contains "features" and "cfg" subdirectories at the top-level. For more
-information, see the "`Kernel Metadata
-Syntax <#kernel-metadata-syntax>`__" section.
+information, see the ":ref:`kernel-dev/advanced:kernel metadata syntax`"
+section.
Kernel Metadata Syntax
======================
@@ -148,7 +148,7 @@
fragments into a modular reusable unit. You can use features to
implement conceptually separate kernel Metadata descriptions such as
pure configuration fragments, simple patches, complex features, and
-kernel types. `Kernel types <#kernel-types>`__ define general kernel
+kernel types. :ref:`kernel-dev/advanced:kernel types` define general kernel
features and policy to be reused in the BSPs.
BSPs define hardware-specific features and aggregate them with kernel
@@ -167,10 +167,9 @@
ktypes/
patches/
-The ``bsp`` directory contains the `BSP
-descriptions <#bsp-descriptions>`__. The remaining directories all
-contain "features". Separating ``bsp`` from the rest of the structure
-aids conceptualizing intended usage.
+The ``bsp`` directory contains the :ref:`kernel-dev/advanced:bsp descriptions`.
+The remaining directories all contain "features". Separating ``bsp`` from the
+rest of the structure aids conceptualizing intended usage.
Use these guidelines to help place your ``scc`` description files within
the structure:
@@ -198,11 +197,12 @@
Paths used in kernel Metadata files are relative to base, which is
either
:term:`FILESEXTRAPATHS` if
-you are creating Metadata in `recipe-space <#recipe-space-metadata>`__,
+you are creating Metadata in
+:ref:`recipe-space <kernel-dev/advanced:recipe-space metadata>`,
or the top level of
:yocto_git:`yocto-kernel-cache </yocto-kernel-cache/tree/>`
-if you are creating `Metadata outside of the
-recipe-space <#metadata-outside-the-recipe-space>`__.
+if you are creating
+:ref:`kernel-dev/advanced:metadata outside the recipe-space`.
.. [1]
``scc`` stands for Series Configuration Control, but the naming has
@@ -353,9 +353,9 @@
Typically, features are less granular than configuration fragments and
are more likely than configuration fragments and patches to be the types
of things you want to specify in the ``KERNEL_FEATURES`` variable of the
-Linux kernel recipe. See the "`Using Kernel Metadata in a
-Recipe <#using-kernel-metadata-in-a-recipe>`__" section earlier in the
-manual.
+Linux kernel recipe. See the
+":ref:`kernel-dev/advanced:using kernel metadata in a recipe`" section earlier
+in the manual.
Kernel Types
------------
@@ -364,7 +364,7 @@
non-hardware configuration fragments with patches you want to use when
building a Linux kernel of a specific type (e.g. a real-time kernel).
Syntactically, kernel types are no different than features as described
-in the "`Features <#features>`__" section. The
+in the ":ref:`kernel-dev/advanced:features`" section. The
:term:`LINUX_KERNEL_TYPE`
variable in the kernel recipe selects the kernel type. For example, in
the ``linux-yocto_4.12.bb`` kernel recipe found in
@@ -540,7 +540,7 @@
This file aggregates all the configuration
fragments, patches, and features that make up your standard kernel
-policy. See the "`Kernel Types <#kernel-types>`__" section for more
+policy. See the ":ref:`kernel-dev/advanced:kernel types`" section for more
information.
To aggregate common configurations and features specific to the kernel
@@ -825,11 +825,11 @@
source repository. Rather, you just take the static patches you need and
encapsulate them within a feature description. Once you have the feature
description, you simply include that into the BSP description as
-described in the "`BSP Descriptions <#bsp-descriptions>`__" section.
+described in the ":ref:`kernel-dev/advanced:bsp descriptions`" section.
You can find information on how to create patches and BSP descriptions
-in the "`Patches <#patches>`__" and "`BSP
-Descriptions <#bsp-descriptions>`__" sections.
+in the ":ref:`kernel-dev/advanced:patches`" and
+":ref:`kernel-dev/advanced:bsp descriptions`" sections.
Machine Branches
----------------
diff --git a/poky/documentation/kernel-dev/common.rst b/poky/documentation/kernel-dev/common.rst
index 0e545d1..56217b9 100644
--- a/poky/documentation/kernel-dev/common.rst
+++ b/poky/documentation/kernel-dev/common.rst
@@ -365,8 +365,7 @@
At this point, you are ready to start making modifications to the kernel
using traditional kernel development steps. For a continued example, see
-the "`Using Traditional Kernel Development to Patch the
-Kernel <#using-traditional-kernel-development-to-patch-the-kernel>`__"
+the ":ref:`kernel-dev/common:using traditional kernel development to patch the kernel`"
section.
Creating and Preparing a Layer
@@ -463,8 +462,8 @@
- :ref:`kernel-dev/common:changing the configuration`
Before modifying an existing recipe, be sure that you have created a
-minimal, custom layer from which you can work. See the "`Creating and
-Preparing a Layer <#creating-and-preparing-a-layer>`__" section for
+minimal, custom layer from which you can work. See the
+":ref:`kernel-dev/common:creating and preparing a layer`" section for
information.
Creating the Append File
@@ -710,7 +709,7 @@
applies the new configuration before building the kernel.
For a detailed example showing how to configure the kernel, see the
-"`Configuring the Kernel <#configuring-the-kernel>`__" section.
+":ref:`kernel-dev/common:configuring the kernel`" section.
Using an "In-Tree" ``defconfig`` File
--------------------------------------
@@ -954,15 +953,14 @@
the kernel's ``calibrate.c`` source code file. Applying the patch and
booting the modified image causes the added messages to appear on the
emulator's console. The example is a continuation of the setup procedure
-found in the "`Getting Ready for Traditional Kernel
-Development <#getting-ready-for-traditional-kernel-development>`__"
+found in the
+":ref:`kernel-dev/common:getting ready for traditional kernel development`"
Section.
1. *Edit the Source Files* Prior to this step, you should have used Git
to create a local copy of the repository for your kernel. Assuming
- you created the repository as directed in the "`Getting Ready for
- Traditional Kernel
- Development <#getting-ready-for-traditional-kernel-development>`__"
+ you created the repository as directed in the
+ ":ref:`kernel-dev/common:getting ready for traditional kernel development`"
section, use the following commands to edit the ``calibrate.c`` file:
1. *Change the working directory*: You need to locate the source
@@ -1104,9 +1102,9 @@
The :term:`FILESEXTRAPATHS` and :term:`SRC_URI` statements
enable the OpenEmbedded build system to find the patch file.
- For more information on append files and patches, see the "`Creating
- the Append File <#creating-the-append-file>`__" and "`Applying
- Patches <#applying-patches>`__" sections. You can also see the
+ For more information on append files and patches, see the
+ ":ref:`kernel-dev/common:creating the append file`" and
+ ":ref:`kernel-dev/common:applying patches`" sections. You can also see the
":ref:`dev-manual/common-tasks:using .bbappend files in your layer`"
section in the Yocto Project Development Tasks Manual.
@@ -1140,8 +1138,8 @@
``.config`` file to create the leanest kernel configuration file
possible.
-For more information on kernel configuration, see the "`Changing the
-Configuration <#changing-the-configuration>`__" section.
+For more information on kernel configuration, see the
+":ref:`kernel-dev/common:changing the configuration`" section.
Using ``menuconfig``
---------------------
@@ -1297,8 +1295,8 @@
applies these on top of and after applying the existing ``defconfig`` file
configurations.
-For more information on configuring the kernel, see the "`Changing the
-Configuration <#changing-the-configuration>`__" section.
+For more information on configuring the kernel, see the
+":ref:`kernel-dev/common:changing the configuration`" section.
Creating Configuration Fragments
--------------------------------
@@ -1369,8 +1367,8 @@
$ bitbake linux-yocto -c diffconfig
The ``diffconfig`` command creates a file that is a list of Linux kernel
-``CONFIG_`` assignments. See the "`Changing the
-Configuration <#changing-the-configuration>`__" section for additional
+``CONFIG_`` assignments. See the
+":ref:`kernel-dev/common:changing the configuration`" section for additional
information on how to use the output as a configuration fragment.
.. note::
@@ -1614,8 +1612,7 @@
":ref:`kernel-dev/common:using \`\`devtool\`\` to patch the kernel`"
section. For
information on building the kernel image when using Bitbake, see the
- "`Using Traditional Kernel Development to Patch the
- Kernel <#using-traditional-kernel-development-to-patch-the-kernel>`__"
+ ":ref:`kernel-dev/common:using traditional kernel development to patch the kernel`"
section.
Working With Your Own Sources
@@ -1733,8 +1730,9 @@
5. *Customize Your Recipe as Needed:* Provide further customizations to
your recipe as needed just as you would customize an existing
- linux-yocto recipe. See the "`Modifying an Existing
- Recipe <#modifying-an-existing-recipe>`__" section for information.
+ linux-yocto recipe. See the
+ ":ref:`ref-manual/devtool-reference:modifying an existing recipe`" section
+ for information.
Working with Out-of-Tree Modules
================================
@@ -1914,7 +1912,7 @@
$ git show origin/standard/base..origin/standard/emenlow
Use this command to create individual patches for each change. Here is
-an example that that creates patch files for each commit and places them
+an example that creates patch files for each commit and places them
in your ``Documents`` directory:
::
diff --git a/poky/documentation/kernel-dev/intro.rst b/poky/documentation/kernel-dev/intro.rst
index f6c9b97..5592f74 100644
--- a/poky/documentation/kernel-dev/intro.rst
+++ b/poky/documentation/kernel-dev/intro.rst
@@ -90,8 +90,7 @@
- The ":ref:`dev-manual/common-tasks:understanding and creating layers`"
section in the Yocto Project Development Tasks Manual.
-- The "`Kernel Modification
- Workflow <#kernel-modification-workflow>`__" section.
+- The ":ref:`kernel-dev/intro:kernel modification workflow`" section.
Kernel Modification Workflow
============================
diff --git a/poky/documentation/kernel-dev/maint-appx.rst b/poky/documentation/kernel-dev/maint-appx.rst
index 89f4b43..44c4389 100644
--- a/poky/documentation/kernel-dev/maint-appx.rst
+++ b/poky/documentation/kernel-dev/maint-appx.rst
@@ -64,7 +64,7 @@
kernel versions (e.g. "yocto-4.12", "yocto-4.10", "yocto-4.9", and so forth).
Once you have checked out and switched to appropriate branches, you can
-see a snapshot of all the kernel source files used to used to build that
+see a snapshot of all the kernel source files used to build that
particular Yocto Linux kernel for a particular board.
To see the features and configurations for a particular Yocto Linux