poky: subtree update:0ac99625bf..796be0593a
Alexander Kanavin (31):
netbase: upgrade 6.1 -> 6.2
meson: upgrade 0.55.1 -> 0.56.0
vulkan-samples: update to latest revision
libcap: update 2.44 -> 2.45
bind: upgrade 9.16.7 -> 9.16.9
quota: upgrade 4.05 -> 4.06
pango: upgrade 1.46.2 -> 1.48.0
elfutils: upgrade 0.181 -> 0.182
ifupdown: upgrade 0.8.35 -> 0.8.36
createrepo-c: upgrade 0.16.1 -> 0.16.2
acpica: upgrade 20200925 -> 20201113
grep: upgrade 3.5 -> 3.6
man-pages: upgrade 5.08 -> 5.09
stress-ng: upgrade 0.11.23 -> 0.11.24
libhandy: upgrade 1.0.1 -> 1.0.2
piglit: upgrade to latest revision
xkbcomp: upgrade 1.4.3 -> 1.4.4
lz4: upgrade 1.9.2 -> 1.9.3
bison: upgrade 3.7.3 -> 3.7.4
python3-setuptools-scm: fix upstream version check
cantarell-fonts: update 0.0.25 -> 0.201
meta/lib/oe/reproducible.py: gitsm:// works just as fine as git:// for timestamps
llvm: fix reproducibility
ruby: fix reproducibility
webkitgtk: fix reproducibility
ffmpeg: fix reproducibility
piglit: fix reproducibility
serf: do not install the static library
llvm: sort the lists in generated source reproducibibly
kea: fix reproducibility
poky.conf: do not write current date into distro version, use git hash instead
Andrej Valek (1):
kernel-dummy: fix executing unexpected tasks
Anuj Mittal (1):
releases.rst: add gatesgarth to current releases
Brett Warren (1):
libffi: add patch to revert clang VFP workaround
Chandana kalluri (1):
populate_sdk_ext: use SDK_CUSTOM_TEPLATECONF variable to enable custom templateconf.cfg
Changqing Li (1):
buildtools-tarball: add wic dependency into extended buildtools
Diego Sueiro (2):
modutils-initscripts: Fix modules.dep creation when USE_DEPMOD="0"
initscripts: Change execution order between checkroot and modutils
Dmitry Baryshkov (2):
linux-firmware: upgrade 20201022 -> 20201118
linux-firmware: package ath11k firmware
Fabio Berton (1):
mesa: Update 20.2.1 -> 20.2.4
Gratian Crisan (1):
kernel-module-split.bbclass: fix kernel modules getting marked as CONFFILES
Jack Mitchell (3):
Revert "connman: set service to conflict with systemd-networkd"
systemd-conf: add PACKAGECONFIG to enable/disable auto ethernet DHCP
systemd-conf: match ethernet interfaces by type rather than globbing
Joshua Watt (2):
bitbake: hashserv: client: Fix AF_UNIX path length limits
bitbake: hashserv: Fix broken AF_UNIX path length limit
Kai Kang (2):
systemd-systemctl-native: capable to call without argument
systemd.bbclass: update command to check systemctl available
Kevin Hao (1):
tune-octeontx2.inc: Add tune for Marvell OCTEON TX2 core
Li Wang (2):
qemu: CVE-2020-29129 CVE-2020-29130
qemu: CVE-2020-25624
Luca Boccassi (1):
dbus: move messagebus user to dbus-common package
Michael Halstead (1):
releases: conf: add link to 3.1.4, update to include 3.1.4
Nicolas Dechesne (19):
sphinx: add .vscode in .gitignore
{dev,kernel,sdk}-manual: replace hardcoded release version with &DISTRO;
sphinx: replace bitbake labels with references to corresponding title
brief-yoctoprojectqs: replace labels with references to section title
dev-manual: replace labels with references to section title
ref-manual: replace labels with references to section title
sdk-manual: replace labels with references to section title
overview-manual: remove unused labels
dev-manual: remove unused labels
sphinx: rename top level document in each manual
sphinx: use absolute paths for :doc: references
test-manual: remove 'test-manual' from filenames
toaster-manual: remove 'toaster-manual' from filenames
dev-manual: remove 'dev-manual' from filenames
kernel-dev: remove 'kernel-dev' from filenames
profile-manual: remove 'profile-manual' from filenames
overview-manual: remove 'overview-manual' from filenames
sdk-manual: remove 'sdk' from filenames
ref-manual: remove 'ref' from filenames
Paul Barker (5):
documentation: Simplify yocto_wiki links
documentation: Simplify yocto_git links
ref-manual: Simplify oe_git links
poky.conf: Add opensuseleap-15.2 and fedora-33 to tested distros
poky.conf: Drop fedora-30 from tested distros
Peter Kjellerstedt (2):
pseudo: Simplify pseudo_client_ignore_path_chroot()
bitbake.conf: Add all layers (from BBLAYERS) to PSEUDO_IGNORE_PATHS
Richard Purdie (8):
lz4: Use the new branch naming from upstream
Revert "bitbake.conf: Add all layers (from BBLAYERS) to PSEUDO_IGNORE_PATHS"
build-appliance-image: Update to master head revision
bitbake: Revert "fetch2: use relative symlinks for anything pulled from PREMIRRORS"
build-appliance-image: Update to master head revision
metadata_scm: Fix signature handling of METADATA_REVISION and METADATA_BRANCH
poky: Set SDK_VERSION explicitly
build-appliance-image: Update to master head revision
Ross Burton (9):
oeqa/devtool: use Yocto mirror for pv-1.5.3 tarball
image_types: remove obsolete tar comment
image_types: sort tarball file listings
package_manager/ipk: neaten OPKGLIBDIR logic
ldconfig-native: don't write auxiliary cache
package_manager/ipk: improve remove_packaging_data
oeqa/selftest/containerimage: update for improved cleanup
coreutils: add SUSE-specific issues to CVE whitelist
bitbake: msg: use safe YAML loader
Sinan Kaya (1):
poky-tiny: enable section removal
Tomasz Dziendzielski (1):
pseudo: Update to print PSEUDO_LOGFILE in abort message on path mismatches
sangeeta jain (1):
meta/lib/oeqa/manual/oe-core.json: Update test_bitbake_devshell
zangrc (3):
libinput: upgrade 1.16.3 -> 1.16.4
lighttpd: upgrade 1.4.55 -> 1.4.56
sysstat: upgrade 12.4.0 -> 12.4.1
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Change-Id: I65f2f1c9d44433f3e62609240012c42256679b51
diff --git a/poky/documentation/overview-manual/overview-manual-concepts.rst b/poky/documentation/overview-manual/concepts.rst
similarity index 96%
rename from poky/documentation/overview-manual/overview-manual-concepts.rst
rename to poky/documentation/overview-manual/concepts.rst
index 736fd95..8fbbabb 100644
--- a/poky/documentation/overview-manual/overview-manual-concepts.rst
+++ b/poky/documentation/overview-manual/concepts.rst
@@ -34,17 +34,15 @@
BitBake knows how to combine multiple data sources together and refers
to each data source as a layer. For information on layers, see the
-":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+":ref:`dev-manual/common-tasks:understanding and creating layers`"
section of the Yocto Project Development Tasks Manual.
Following are some brief details on these core components. For
additional information on how these components interact during a build,
see the
-":ref:`overview-manual/overview-manual-concepts:openembedded build system concepts`"
+":ref:`overview-manual/concepts:openembedded build system concepts`"
section.
-.. _usingpoky-components-bitbake:
-
BitBake
-------
@@ -78,7 +76,7 @@
selected by the distribution configuration. You can get more details
about how BitBake chooses between different target versions and
providers in the
-":ref:`Preferences <bitbake:bb-bitbake-preferences>`" section
+":ref:`Preferences <bitbake:bitbake-user-manual/bitbake-user-manual-execution:preferences>`" section
of the BitBake User Manual.
BitBake also tries to execute any dependent tasks first. So for example,
@@ -92,8 +90,6 @@
remade. However, when you use this option other dependencies can still
be processed.
-.. _overview-components-recipes:
-
Recipes
-------
@@ -109,8 +105,6 @@
build system (i.e. ``.ipk`` or ``.deb`` files), this document avoids
using the term "package" when referring to recipes.
-.. _overview-components-classes:
-
Classes
-------
@@ -118,12 +112,10 @@
between recipes files. An example is the
:ref:`autotools <ref-classes-autotools>` class,
which contains common settings for any application that Autotools uses.
-The ":ref:`ref-manual/ref-classes:Classes`" chapter in the
+The ":ref:`ref-manual/classes:Classes`" chapter in the
Yocto Project Reference Manual provides details about classes and how to
use them.
-.. _overview-components-configurations:
-
Configurations
--------------
@@ -135,8 +127,6 @@
``conf/local.conf``, which is found in the :term:`Build Directory`.
-.. _overview-layers:
-
Layers
======
@@ -163,11 +153,9 @@
during builds on where to find types of metadata. You can find
procedures and learn about tools (i.e. ``bitbake-layers``) for creating
layers suitable for the Yocto Project in the
-":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+":ref:`dev-manual/common-tasks:understanding and creating layers`"
section of the Yocto Project Development Tasks Manual.
-.. _openembedded-build-system-build-concepts:
-
OpenEmbedded Build System Concepts
==================================
@@ -285,7 +273,7 @@
build environment. Here is a list of a few. To see the default
configurations in a ``local.conf`` file created by the build environment
script, see the
-:yocto_git:`local.conf.sample </cgit/cgit.cgi/poky/tree/meta-poky/conf/local.conf.sample>`
+:yocto_git:`local.conf.sample </poky/tree/meta-poky/conf/local.conf.sample>`
in the ``meta-poky`` layer:
- *Target Machine Selection:* Controlled by the
@@ -329,7 +317,7 @@
layers minimally needed by the build system. However, you must manually
add any custom layers you have created. You can find more information on
working with the ``bblayers.conf`` file in the
-":ref:`dev-manual/dev-manual-common-tasks:enabling your layer`"
+":ref:`dev-manual/common-tasks:enabling your layer`"
section in the Yocto Project Development Tasks Manual.
The files ``site.conf`` and ``auto.conf`` are not created by the
@@ -405,17 +393,17 @@
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
- :yocto_git:`meta-yocto-bsp </cgit/cgit.cgi/poky/tree/meta-yocto-bsp>`
+ :yocto_git:`meta-yocto-bsp </poky/tree/meta-yocto-bsp>`
layer.
- *Policy Configuration:* Distribution Layers (i.e. "Distro Layer" in
the following figure) providing top-level or general policies for the
images or SDKs being built for a particular distribution. For
example, in the Poky Reference Distribution the distro layer is the
- :yocto_git:`meta-poky </cgit/cgit.cgi/poky/tree/meta-poky>`
+ :yocto_git:`meta-poky </poky/tree/meta-poky>`
layer. Within the distro layer is a ``conf/distro`` directory that
contains distro configuration files (e.g.
- :yocto_git:`poky.conf </cgit/cgit.cgi/poky/tree/meta-poky/conf/distro/poky.conf>`
+ :yocto_git:`poky.conf </poky/tree/meta-poky/conf/distro/poky.conf>`
that contain many policy configurations for the Poky distribution.
The following figure shows an expanded representation of these three
@@ -430,7 +418,7 @@
distributed, a configuration directory, and recipe directories. You can
learn about the general structure for layers used with the Yocto Project
in the
-":ref:`dev-manual/dev-manual-common-tasks:creating your own layer`"
+":ref:`dev-manual/common-tasks:creating your own layer`"
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
@@ -439,9 +427,8 @@
manual.
If you explored the previous links, you discovered some areas where many
-layers that work with the Yocto Project exist. The `Source
-Repositories <http://git.yoctoproject.org/>`__ also shows layers
-categorized under "Yocto Metadata Layers."
+layers that work with the Yocto Project exist. The :yocto_git:`Source
+Repositories <>` also shows layers categorized under "Yocto Metadata Layers."
.. note::
@@ -469,7 +456,7 @@
can be shared among recipes in the distribution. When your recipes
inherit a class, they take on the settings and functions for that
class. You can read more about class files in the
- ":ref:`ref-manual/ref-classes:Classes`" chapter of the Yocto
+ ":ref:`ref-manual/classes:Classes`" chapter of the Yocto
Reference Manual.
- *conf:* This area holds configuration files for the layer
@@ -494,7 +481,7 @@
hardware. Everything in this layer is specific to the machine for which
you are building the image or the SDK. A common structure or form is
defined for BSP layers. You can learn more about this structure in the
-:doc:`../bsp-guide/bsp-guide`.
+:doc:`/bsp-guide/index`.
.. note::
@@ -527,8 +514,6 @@
This layer contains any recipes, append files, and patches, that your
project needs.
-.. _sources-dev-environment:
-
Sources
-------
@@ -601,13 +586,11 @@
or a recipe's append file to override or set the recipe to point to the
local directory on your disk to pull in the whole source tree.
-.. _scms:
-
Source Control Managers (Optional)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Another place from which the build system can get source files is with
-:ref:`fetchers <bitbake:bb-fetchers>` employing various Source
+:ref:`fetchers <bitbake:bitbake-user-manual/bitbake-user-manual-fetching:fetchers>` employing various Source
Control Managers (SCMs) such as Git or Subversion. In such cases, a
repository is cloned or checked out. The
:ref:`ref-tasks-fetch` task inside
@@ -644,8 +627,6 @@
alternative location for source code should the primary site not be
functioning for some reason or another.
-.. _package-feeds-dev-environment:
-
Package Feeds
-------------
@@ -709,8 +690,6 @@
``build/tmp/deploy/ipk/i586``, while packages for the qemux86
architecture are placed in ``build/tmp/deploy/ipk/qemux86``.
-.. _bitbake-dev-environment:
-
BitBake Tool
------------
@@ -727,8 +706,6 @@
BitBake User Manual
for reference material on BitBake.
-.. _source-fetching-dev-environment:
-
Source Fetching
~~~~~~~~~~~~~~~
@@ -819,8 +796,6 @@
what the OpenEmbedded build system is using as a build target (e.g.
general architecture, a build host, an SDK, or a specific machine).
-.. _patching-dev-environment:
-
Patching
~~~~~~~~
@@ -852,17 +827,15 @@
"`Source Fetching <#source-fetching-dev-environment>`__" section. For
more information on how to create patches and how the build system
processes patches, see the
-":ref:`dev-manual/dev-manual-common-tasks:patching code`"
+":ref:`dev-manual/common-tasks:patching code`"
section in the
Yocto Project Development Tasks Manual. You can also see the
-":ref:`sdk-manual/sdk-extensible:use \`\`devtool modify\`\` to modify the source of an existing component`"
+":ref:`sdk-manual/extensible:use \`\`devtool modify\`\` to modify the source of an existing component`"
section in the Yocto Project Application Development and the Extensible
Software Development Kit (SDK) manual and the
-":ref:`kernel-dev/kernel-dev-common:using traditional kernel development to patch the kernel`"
+":ref:`kernel-dev/common:using traditional kernel development to patch the kernel`"
section in the Yocto Project Linux Kernel Development Manual.
-.. _configuration-compilation-and-staging-dev-environment:
-
Configuration, Compilation, and Staging
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -905,7 +878,7 @@
variables. For information on how this variable works within that
class, see the
:ref:`autotools <ref-classes-autotools>` class
- :yocto_git:`here </cgit/cgit.cgi/poky/tree/meta/classes/autotools.bbclass>`.
+ :yocto_git:`here </poky/tree/meta/classes/autotools.bbclass>`.
- *do_compile*: Once a configuration task has been satisfied,
BitBake compiles the source using the
@@ -922,8 +895,6 @@
variable. Packaging occurs later using files from this holding
directory.
-.. _package-splitting-dev-environment:
-
Package Splitting
~~~~~~~~~~~~~~~~~
@@ -985,7 +956,7 @@
files that go into each package in
:term:`PACKAGES`. If you want
details on how this is accomplished, you can look at
-:yocto_git:`package.bbclass </cgit/cgit.cgi/poky/tree/meta/classes/package.bbclass>`.
+:yocto_git:`package.bbclass </poky/tree/meta/classes/package.bbclass>`.
Depending on the type of packages being created (RPM, DEB, or IPK), the
:ref:`do_package_write_* <ref-tasks-package_write_deb>`
@@ -1004,8 +975,6 @@
functionality is highly distribution-specific and thus is not
provided out of the box.
-.. _image-generation-dev-environment:
-
Image Generation
~~~~~~~~~~~~~~~~
@@ -1060,7 +1029,7 @@
of the packages are run. Any scripts that fail to run on the build host
are run on the target when the target system is first booted. If you are
using a
-:ref:`read-only root filesystem <dev-manual/dev-manual-common-tasks:creating a read-only root filesystem>`,
+:ref:`read-only root filesystem <dev-manual/common-tasks:creating a read-only root filesystem>`,
all the post installation scripts must succeed on the build host during
the package installation phase since the root filesystem on the target
is read-only.
@@ -1127,8 +1096,6 @@
Pseudo. Running under Pseudo ensures that the files in the root filesystem
have correct ownership.
-.. _sdk-generation-dev-environment:
-
SDK Generation
~~~~~~~~~~~~~~
@@ -1142,10 +1109,10 @@
.. note::
For more information on the cross-development toolchain generation,
- see the ":ref:`overview-manual/overview-manual-concepts:cross-development toolchain generation`"
+ see the ":ref:`overview-manual/concepts:cross-development toolchain generation`"
section. For information on advantages gained when building a
cross-development toolchain using the do_populate_sdk task, see the
- ":ref:`sdk-manual/sdk-appendix-obtain:building an sdk installer`" section in
+ ":ref:`sdk-manual/appendix-obtain:building an sdk installer`" section in
the Yocto Project Application Development and the Extensible Software
Development Kit (eSDK) manual.
@@ -1225,7 +1192,7 @@
also always be considered out of date, which might not be what you want.
For details on how to view information about a task's signature, see the
-":ref:`dev-manual/dev-manual-common-tasks:viewing task variable dependencies`"
+":ref:`dev-manual/common-tasks:viewing task variable dependencies`"
section in the Yocto Project Development Tasks Manual.
Setscene Tasks and Shared State
@@ -1303,8 +1270,6 @@
needs to be followed, and whether for any given relationship the
function needs to be passed. The function returns a True or False value.
-.. _images-dev-environment:
-
Images
------
@@ -1320,7 +1285,7 @@
.. note::
For a list of example images that the Yocto Project provides, see the
- ":doc:`../ref-manual/ref-images`" chapter in the Yocto Project Reference
+ ":doc:`/ref-manual/images`" chapter in the Yocto Project Reference
Manual.
The build process writes images out to the :term:`Build Directory`
@@ -1363,8 +1328,6 @@
These links might be useful for external scripts that need to obtain
the latest version of each file.
-.. _sdk-dev-environment:
-
Application Development SDK
---------------------------
@@ -1403,7 +1366,7 @@
section.
- For information on setting up a cross-development environment, see
- the :doc:`../sdk-manual/sdk-manual` manual.
+ the :doc:`/sdk-manual/index` manual.
All the output files for an SDK are written to the ``deploy/sdk`` folder
inside the :term:`Build Directory` as
@@ -1480,10 +1443,10 @@
======================================
The Yocto Project does most of the work for you when it comes to
-creating :ref:`sdk-manual/sdk-intro:the cross-development toolchain`. This
+creating :ref:`sdk-manual/intro:the cross-development toolchain`. This
section provides some technical background on how cross-development
toolchains are created and used. For more information on toolchains, you
-can also see the :doc:`../sdk-manual/sdk-manual` manual.
+can also see the :doc:`/sdk-manual/index` manual.
In the Yocto Project development environment, cross-development
toolchains are used to build images and applications that run on the
@@ -1610,7 +1573,7 @@
For information on advantages gained when building a
cross-development toolchain installer, see the
- ":ref:`sdk-manual/sdk-appendix-obtain:building an sdk installer`" appendix
+ ":ref:`sdk-manual/appendix-obtain:building an sdk installer`" appendix
in the Yocto Project Application Development and the
Extensible Software Development Kit (eSDK) manual.
@@ -1663,22 +1626,20 @@
the shared state packages. Consequently, considerations exist that
affect maintaining shared state feeds. For information on how the
build system works with packages and can track incrementing ``PR``
- information, see the ":ref:`dev-manual/dev-manual-common-tasks:automatically incrementing a package version number`"
+ information, see the ":ref:`dev-manual/common-tasks:automatically incrementing a package version number`"
section in the Yocto Project Development Tasks Manual.
- The code in the build system that supports incremental builds is
not simple code. For techniques that help you work around issues
related to shared state code, see the
- ":ref:`dev-manual/dev-manual-common-tasks:viewing metadata used to create the input signature of a shared state task`"
+ ":ref:`dev-manual/common-tasks:viewing metadata used to create the input signature of a shared state task`"
and
- ":ref:`dev-manual/dev-manual-common-tasks:invalidating shared state to force a task to run`"
+ ":ref:`dev-manual/common-tasks:invalidating shared state to force a task to run`"
sections both in the Yocto Project Development Tasks Manual.
The rest of this section goes into detail about the overall incremental
build architecture, the checksums (signatures), and shared state.
-.. _concepts-overall-architecture:
-
Overall Architecture
--------------------
@@ -1697,8 +1658,6 @@
users to easily add new tasks in layers or as external recipes without
touching the packaged-staging core.
-.. _overview-checksums:
-
Checksums (Signatures)
----------------------
@@ -1949,7 +1908,7 @@
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
- ":ref:`bitbake:ref-bitbake-tasklist`"
+ ":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.
diff --git a/poky/documentation/overview-manual/overview-manual-development-environment.rst b/poky/documentation/overview-manual/development-environment.rst
similarity index 94%
rename from poky/documentation/overview-manual/overview-manual-development-environment.rst
rename to poky/documentation/overview-manual/development-environment.rst
index 4bedd6d..9a2997d 100644
--- a/poky/documentation/overview-manual/overview-manual-development-environment.rst
+++ b/poky/documentation/overview-manual/development-environment.rst
@@ -45,8 +45,6 @@
Community
`here <https://www.kernel.org/doc/html/latest/process/index.html>`__.
-.. _gs-the-development-host:
-
The Development Host
====================
@@ -68,7 +66,7 @@
environment that is similar to what you see when using a Linux-based
development host. For the steps needed to set up a system using CROPS,
see the
-":ref:`dev-manual/dev-manual-start:setting up to use cross platforms (crops)`"
+":ref:`dev-manual/start:setting up to use cross platforms (crops)`"
section in
the Yocto Project Development Tasks Manual.
@@ -79,7 +77,7 @@
also need to be sure that the correct set of host packages are installed
that allow development using the Yocto Project. For the steps needed to
set up a development host that runs Linux, see the
-":ref:`dev-manual/dev-manual-start:setting up a native linux host`"
+":ref:`dev-manual/start:setting up a native linux host`"
section in the Yocto Project Development Tasks Manual.
Once your development host is set up to use the Yocto Project, several
@@ -96,7 +94,7 @@
through your Linux distribution and the Yocto Project.
For a general flow of the build procedures, see the
- ":ref:`dev-manual/dev-manual-common-tasks:building a simple image`"
+ ":ref:`dev-manual/common-tasks:building a simple image`"
section in the Yocto Project Development Tasks Manual.
- *Board Support Package (BSP) Development:* Development of BSPs
@@ -105,7 +103,7 @@
hardware. To development BSPs, you need to take some additional steps
beyond what was described in setting up a development host.
- The :doc:`../bsp-guide/bsp-guide` provides BSP-related development
+ The :doc:`/bsp-guide/index` provides BSP-related development
information. For specifics on development host preparation, see the
":ref:`bsp-guide/bsp:preparing your build host to work with bsp layers`"
section in the Yocto Project Board Support Package (BSP) Developer's
@@ -116,10 +114,10 @@
using ``devtool`` makes kernel development quicker by reducing
iteration cycle times.
- The :doc:`../kernel-dev/kernel-dev` provides kernel-related
+ The :doc:`/kernel-dev/index` provides kernel-related
development information. For specifics on development host
preparation, see the
- ":ref:`kernel-dev/kernel-dev-common:preparing the build host to work on the kernel`"
+ ":ref:`kernel-dev/common:preparing the build host to work on the kernel`"
section in the Yocto Project Linux Kernel Development Manual.
- *Using Toaster:* The other Yocto Project development method that
@@ -132,9 +130,7 @@
For steps that show you how to set up your development host to use
Toaster and on how to use Toaster in general, see the
- :doc:`../toaster-manual/toaster-manual`.
-
-.. _yocto-project-repositories:
+ :doc:`/toaster-manual/index`.
Yocto Project Source Repositories
=================================
@@ -182,7 +178,7 @@
:align: center
For steps on how to view and access these upstream Git repositories,
- see the ":ref:`dev-manual/dev-manual-start:accessing source repositories`"
+ see the ":ref:`dev-manual/start:accessing source repositories`"
Section in the Yocto Project Development Tasks Manual.
- :yocto_dl:`Index of /releases: </releases>` This is an index
@@ -196,7 +192,7 @@
:align: center
For steps on how to view and access these files, see the
- ":ref:`dev-manual/dev-manual-start:accessing index of releases`"
+ ":ref:`dev-manual/start:accessing index of releases`"
section in the Yocto Project Development Tasks Manual.
- *"DOWNLOADS" page for the* :yocto_home:`Yocto Project Website <>` *:*
@@ -211,11 +207,9 @@
:align: center
For steps on how to use the "DOWNLOADS" page, see the
- ":ref:`dev-manual/dev-manual-start:using the downloads page`"
+ ":ref:`dev-manual/start:using the downloads page`"
section in the Yocto Project Development Tasks Manual.
-.. _gs-git-workflows-and-the-yocto-project:
-
Git Workflows and the Yocto Project
===================================
@@ -248,7 +242,7 @@
For information on finding out who is responsible for (maintains) a
particular area of code in the Yocto Project, see the
- ":ref:`dev-manual/dev-manual-common-tasks:submitting a change to the yocto project`"
+ ":ref:`dev-manual/common-tasks:submitting a change to the yocto project`"
section of the Yocto Project Development Tasks Manual.
The Yocto Project ``poky`` Git repository also has an upstream
@@ -280,7 +274,7 @@
maintainer include them into an upstream branch. This process is called
"submitting a patch" or "submitting a change." For information on
submitting patches and changes, see the
-":ref:`dev-manual/dev-manual-common-tasks:submitting a change to the yocto project`"
+":ref:`dev-manual/common-tasks:submitting a change to the yocto project`"
section in the Yocto Project Development Tasks Manual.
In summary, a single point of entry exists for changes into a "master"
@@ -347,7 +341,7 @@
the ``scripts`` folder of the
:term:`Source Directory`. For information
on how to use these scripts, see the
- ":ref:`dev-manual/dev-manual-common-tasks:using scripts to push a change upstream and request a pull`"
+ ":ref:`dev-manual/common-tasks:using scripts to push a change upstream and request a pull`"
section in the Yocto Project Development Tasks Manual.
- *Patch Workflow:* This workflow allows you to notify the maintainer
@@ -356,7 +350,7 @@
this type of change, you format the patch and then send the email
using the Git commands ``git format-patch`` and ``git send-email``.
For information on how to use these scripts, see the
- ":ref:`dev-manual/dev-manual-common-tasks:submitting a change to the yocto project`"
+ ":ref:`dev-manual/common-tasks:submitting a change to the yocto project`"
section in the Yocto Project Development Tasks Manual.
Git
@@ -382,7 +376,7 @@
page, see http://git-scm.com/download.
- For information beyond the introductory nature in this section,
- see the ":ref:`dev-manual/dev-manual-start:locating yocto project source files`"
+ see the ":ref:`dev-manual/start:locating yocto project source files`"
section in the Yocto Project Development Tasks Manual.
Repositories, Tags, and Branches
@@ -414,7 +408,7 @@
an identical copy of the repository on your development system. Once you
have a local copy of a repository, you can take steps to develop
locally. For examples on how to clone Git repositories, see the
-":ref:`dev-manual/dev-manual-start:locating yocto project source files`"
+":ref:`dev-manual/start:locating yocto project source files`"
section in the Yocto Project Development Tasks Manual.
It is important to understand that Git tracks content change and not
@@ -422,7 +416,7 @@
For example, the ``poky`` repository has several branches that include
the current "&DISTRO_NAME_NO_CAP;" branch, the "master" branch, and many
branches for past Yocto Project releases. You can see all the branches
-by going to https://git.yoctoproject.org/cgit.cgi/poky/ and clicking on the
+by going to :yocto_git:`/poky/` and clicking on the
``[...]`` link beneath the "Branch" heading.
Each of these branches represents a specific area of development. The
@@ -467,9 +461,8 @@
Git uses "tags" to mark specific changes in a repository branch
structure. Typically, a tag is used to mark a special point such as the
final change (or commit) before a project is released. You can see the
-tags used with the ``poky`` Git repository by going to
-https://git.yoctoproject.org/cgit.cgi/poky/ and clicking on the ``[...]`` link
-beneath the "Tag" heading.
+tags used with the ``poky`` Git repository by going to :yocto_git:`/poky/`
+and clicking on the ``[...]`` link beneath the "Tag" heading.
Some key tags for the ``poky`` repository are ``jethro-14.0.3``,
``morty-16.0.1``, ``pyro-17.0.0``, and
@@ -668,5 +661,5 @@
For information that can help you maintain compliance with various open
source licensing during the lifecycle of a product created using the
Yocto Project, see the
-":ref:`dev-manual/dev-manual-common-tasks:maintaining open source license compliance during your product's lifecycle`"
+":ref:`dev-manual/common-tasks:maintaining open source license compliance during your product's lifecycle`"
section in the Yocto Project Development Tasks Manual.
diff --git a/poky/documentation/overview-manual/overview-manual.rst b/poky/documentation/overview-manual/index.rst
similarity index 69%
rename from poky/documentation/overview-manual/overview-manual.rst
rename to poky/documentation/overview-manual/index.rst
index f20b20e..123aed9b 100644
--- a/poky/documentation/overview-manual/overview-manual.rst
+++ b/poky/documentation/overview-manual/index.rst
@@ -10,10 +10,10 @@
:caption: Table of Contents
:numbered:
- overview-manual-intro
- overview-manual-yp-intro
- overview-manual-development-environment
- overview-manual-concepts
+ intro
+ yp-intro
+ development-environment
+ concepts
history
.. include:: /boilerplate.rst
diff --git a/poky/documentation/overview-manual/overview-manual-intro.rst b/poky/documentation/overview-manual/intro.rst
similarity index 86%
rename from poky/documentation/overview-manual/overview-manual-intro.rst
rename to poky/documentation/overview-manual/intro.rst
index 8885eb8..bd247dd 100644
--- a/poky/documentation/overview-manual/overview-manual-intro.rst
+++ b/poky/documentation/overview-manual/intro.rst
@@ -4,8 +4,6 @@
The Yocto Project Overview and Concepts Manual
**********************************************
-.. _overview-manual-welcome:
-
Welcome
=======
@@ -30,7 +28,7 @@
Yocto Project source repositories, workflows using Git and the Yocto
Project, a Git primer, and information about licensing.
-- :doc:`overview-manual-concepts` *:* This
+- :doc:`/overview-manual/concepts` *:* This
chapter presents various concepts regarding the Yocto Project. You
can find conceptual information about components, development,
cross-toolchains, and so forth.
@@ -39,17 +37,17 @@
- *Step-by-step Instructions for Development Tasks:* Instructional
procedures reside in other manuals within the Yocto Project
- documentation set. For example, the :doc:`../dev-manual/dev-manual`
+ documentation set. For example, the :doc:`/dev-manual/index`
provides examples on how to perform
various development tasks. As another example, the
- :doc:`../sdk-manual/sdk-manual` manual contains detailed
+ :doc:`/sdk-manual/index` manual contains detailed
instructions on how to install an SDK, which is used to develop
applications for target hardware.
- *Reference Material:* This type of material resides in an appropriate
reference manual. For example, system variables are documented in the
- :doc:`../ref-manual/ref-manual`. As another
- example, the :doc:`../bsp-guide/bsp-guide` contains reference information on
+ :doc:`/ref-manual/index`. As another
+ example, the :doc:`/bsp-guide/index` contains reference information on
BSPs.
- *Detailed Public Information Not Specific to the Yocto Project:* For
@@ -57,8 +55,6 @@
Manager Git is better covered with Internet searches and official Git
Documentation than through the Yocto Project documentation.
-.. _overview-manual-other-information:
-
Other Information
=================
@@ -67,7 +63,7 @@
additional introductory information on the Yocto Project, see the
:yocto_home:`Yocto Project Website <>`. If you want to build an image
with no knowledge of Yocto Project as a way of quickly testing it out,
-see the :doc:`../brief-yoctoprojectqs/brief-yoctoprojectqs` document.
+see the :doc:`/brief-yoctoprojectqs/index` document.
For a comprehensive list of links and other documentation, see the
":ref:`Links and Related
Documentation <resources-links-and-related-documentation>`"
diff --git a/poky/documentation/overview-manual/overview-manual-yp-intro.rst b/poky/documentation/overview-manual/yp-intro.rst
similarity index 94%
rename from poky/documentation/overview-manual/overview-manual-yp-intro.rst
rename to poky/documentation/overview-manual/yp-intro.rst
index 9073582..66a88c9 100644
--- a/poky/documentation/overview-manual/overview-manual-yp-intro.rst
+++ b/poky/documentation/overview-manual/yp-intro.rst
@@ -35,8 +35,6 @@
The remainder of this section overviews advantages and challenges tied
to the Yocto Project.
-.. _gs-features:
-
Features
--------
@@ -113,7 +111,7 @@
development.
- *Releases According to a Strict Schedule:* Major releases occur on a
- :doc:`six-month cycle <../ref-manual/ref-release-process>`
+ :doc:`six-month cycle </ref-manual/release-process>`
predictably in October and April. The most recent two releases
support point releases to address common vulnerabilities and
exposures. This predictability is crucial for projects based on the
@@ -132,12 +130,10 @@
arbitrarily include packages.
- *License Manifest:* The Yocto Project provides a :ref:`license
- manifest <dev-manual/dev-manual-common-tasks:maintaining open source license compliance during your product's lifecycle>`
+ manifest <dev-manual/common-tasks:maintaining open source license compliance during your product's lifecycle>`
for review by people who need to track the use of open source
licenses (e.g. legal teams).
-.. _gs-challenges:
-
Challenges
----------
@@ -232,7 +228,7 @@
- Layers support the inclusion of technologies, hardware components,
and software components. The :ref:`Yocto Project
- Compatible <dev-manual/dev-manual-common-tasks:making sure your layer is compatible with yocto project>`
+ Compatible <dev-manual/common-tasks:making sure your layer is compatible with yocto project>`
designation provides a minimum level of standardization that
contributes to a strong ecosystem. "YP Compatible" is applied to
appropriate products and software components such as BSPs, other
@@ -255,7 +251,7 @@
.. note::
For general information on BSP layer structure, see the
- :doc:`../bsp-guide/bsp-guide`
+ :doc:`/bsp-guide/index`
.
The :term:`Source Directory`
@@ -271,15 +267,14 @@
, but it is a commonly accepted standard in the Yocto Project
community.
-For example, if you were to examine the `tree
-view <https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/>`__ of the
-``poky`` repository, you will see several layers: ``meta``,
+For example, if you were to examine the :yocto_git:`tree view </poky/tree/>`
+of the ``poky`` repository, you will see several layers: ``meta``,
``meta-skeleton``, ``meta-selftest``, ``meta-poky``, and
``meta-yocto-bsp``. Each of these repositories represents a distinct
layer.
For procedures on how to create layers, see the
-":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+":ref:`dev-manual/common-tasks:understanding and creating layers`"
section in the Yocto Project Development Tasks Manual.
Components and Tools
@@ -296,8 +291,6 @@
This section provides brief overviews of the components and tools
associated with the Yocto Project.
-.. _gs-development-tools:
-
Development Tools
-----------------
@@ -334,7 +327,7 @@
You can read about the ``devtool`` workflow in the Yocto Project
Application Development and Extensible Software Development Kit
(eSDK) Manual in the
- ":ref:`sdk-manual/sdk-extensible:using \`\`devtool\`\` in your sdk workflow`"
+ ":ref:`sdk-manual/extensible:using \`\`devtool\`\` in your sdk workflow`"
section.
- *Extensible Software Development Kit (eSDK):* The eSDK provides a
@@ -346,14 +339,12 @@
experience supplemented with the powerful set of ``devtool`` commands
tailored for the Yocto Project environment.
- For information on the eSDK, see the :doc:`../sdk-manual/sdk-manual` Manual.
+ For information on the eSDK, see the :doc:`/sdk-manual/index` Manual.
- *Toaster:* Toaster is a web interface to the Yocto Project
OpenEmbedded build system. Toaster allows you to configure, run, and
view information about builds. For information on Toaster, see the
- :doc:`../toaster-manual/toaster-manual`.
-
-.. _gs-production-tools:
+ :doc:`/toaster-manual/index`.
Production Tools
----------------
@@ -366,7 +357,7 @@
(BitBake and
OE-Core) automatically generates upgrades for recipes that are based
on new versions of the recipes published upstream. See
- :ref:`dev-manual/dev-manual-common-tasks:using the auto upgrade helper (auh)`
+ :ref:`dev-manual/common-tasks:using the auto upgrade helper (auh)`
for how to set it up.
- *Recipe Reporting System:* The Recipe Reporting System tracks recipe
@@ -401,7 +392,7 @@
benefit of the development community.
You can learn more about the AutoBuilder used by the Yocto Project
- Autobuilder :doc:`here <../test-manual/test-manual-understand-autobuilder>`.
+ Autobuilder :doc:`here </test-manual/understand-autobuilder>`.
- *Cross-Prelink:* Prelinking is the process of pre-computing the load
addresses and link tables generated by the dynamic linker as compared
@@ -450,8 +441,6 @@
You can read more about Pseudo in the "`Fakeroot and
Pseudo <#fakeroot-and-pseudo>`__" section.
-.. _gs-openembedded-build-system:
-
Open-Embedded Build System Components
-------------------------------------
@@ -477,7 +466,7 @@
OpenEmbedded-derived systems, which includes the Yocto Project. The
Yocto Project and the OpenEmbedded Project both maintain the
OpenEmbedded-Core. You can find the OE-Core metadata in the Yocto
- Project :yocto_git:`Source Repositories </cgit/cgit.cgi/poky/tree/meta>`.
+ Project :yocto_git:`Source Repositories </poky/tree/meta>`.
Historically, the Yocto Project integrated the OE-Core metadata
throughout the Yocto Project source repository reference system
@@ -496,8 +485,6 @@
components such as BitBake, OE-Core, script "glue", and documentation
for its build system.
-.. _gs-reference-distribution-poky:
-
Reference Distribution (Poky)
-----------------------------
@@ -520,8 +507,6 @@
You can read more about Poky in the "`Reference Embedded Distribution
(Poky) <#reference-embedded-distribution>`__" section.
-.. _gs-packages-for-finished-targets:
-
Packages for Finished Targets
-----------------------------
@@ -560,8 +545,6 @@
You can find the opkg source in the Yocto Project
:yocto_git:`Source Repositories <>`.
-.. _gs-archived-components:
-
Archived Components
-------------------
@@ -588,8 +571,6 @@
using the Yocto Project on a system not native to Linux is with
`CROPS <#gs-crops-overview>`__.
-.. _gs-development-methods:
-
Development Methods
===================
@@ -608,7 +589,7 @@
.. note::
For additional detail about the Yocto Project development
- environment, see the ":doc:`overview-manual-development-environment`"
+ environment, see the ":doc:`/overview-manual/development-environment`"
chapter.
- *Native Linux Host:* By far the best option for a Build Host. A
@@ -620,7 +601,7 @@
For information on how to set up a Build Host on a system running
Linux as its native operating system, see the
- ":ref:`dev-manual/dev-manual-start:setting up a native linux host`"
+ ":ref:`dev-manual/start:setting up a native linux host`"
section in the Yocto Project Development Tasks Manual.
- *CROss PlatformS (CROPS):* Typically, you use
@@ -640,7 +621,7 @@
system natively running Linux.
For information on how to set up a Build Host with CROPS, see the
- ":ref:`dev-manual/dev-manual-start:setting up to use cross platforms (crops)`"
+ ":ref:`dev-manual/start:setting up to use cross platforms (crops)`"
section in the Yocto Project Development Tasks Manual.
- *Windows Subsystem For Linux (WSLv2):* You may use Windows Subsystem
@@ -657,7 +638,7 @@
virtualization technology.
For information on how to set up a Build Host with WSLv2, see the
- ":ref:`dev-manual/dev-manual-start:setting up to use windows subsystem for linux (wslv2)`"
+ ":ref:`dev-manual/start:setting up to use windows subsystem for linux (wslv2)`"
section in the Yocto Project Development Tasks Manual.
- *Toaster:* Regardless of what your Build Host is running, you can use
@@ -669,9 +650,7 @@
configure and start builds on multiple remote build servers.
For information about and how to use Toaster, see the
- :doc:`../toaster-manual/toaster-manual`.
-
-.. _reference-embedded-distribution:
+ :doc:`/toaster-manual/index`.
Reference Embedded Distribution (Poky)
======================================
@@ -691,13 +670,13 @@
found in ``meta``), ``meta-poky``, ``meta-yocto-bsp``, and documentation
provided all together and known to work well together. You can view
these items that make up the Poky repository in the
-:yocto_git:`Source Repositories </cgit/cgit.cgi/poky/tree/>`.
+:yocto_git:`Source Repositories </poky/tree/>`.
.. note::
If you are interested in all the contents of the
poky
- Git repository, see the ":ref:`ref-manual/ref-structure:top-level core components`"
+ Git repository, see the ":ref:`ref-manual/structure:top-level core components`"
section in the Yocto Project Reference Manual.
The following figure illustrates what generally comprises Poky:
@@ -741,7 +720,7 @@
own version. Major releases occur at the same time major releases (point
releases) occur for the Yocto Project, which are typically in the Spring
and Fall. For more information on the Yocto Project release schedule and
-cadence, see the ":doc:`../ref-manual/ref-release-process`" chapter in the
+cadence, see the ":doc:`/ref-manual/release-process`" chapter in the
Yocto Project Reference Manual.
Much has been said about Poky being a "default configuration". A default
@@ -776,8 +755,6 @@
":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:appending and prepending (override style syntax)`"
section in the BitBake User's Manual.
-.. _openembedded-build-system-workflow:
-
The OpenEmbedded Build System Workflow
======================================
@@ -821,7 +798,7 @@
It helps to understand some basic fundamental terms when learning the
Yocto Project. Although a list of terms exists in the ":doc:`Yocto Project
-Terms <../ref-manual/ref-terms>`" section of the Yocto Project
+Terms </ref-manual/terms>`" section of the Yocto Project
Reference Manual, this section provides the definitions of some terms
helpful for getting started:
@@ -835,7 +812,7 @@
application developers. This eSDK allows developers to incorporate
their library and programming changes back into the image to make
their code available to other application developers. For information
- on the eSDK, see the :doc:`../sdk-manual/sdk-manual` manual.
+ on the eSDK, see the :doc:`/sdk-manual/index` manual.
- *Layer:* A collection of related recipes. Layers allow you to
consolidate related metadata to customize your build. Layers also
@@ -847,7 +824,7 @@
Project.
For more detailed information on layers, see the
- ":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+ ":ref:`dev-manual/common-tasks:understanding and creating layers`"
section in the Yocto Project Development Tasks Manual. For a
discussion specifically on BSP Layers, see the
":ref:`bsp-guide/bsp:bsp layers`" section in the Yocto
@@ -892,8 +869,7 @@
set of recipes.
You can see the Metadata in the ``meta`` directory of the Yocto
- Project `Source
- Repositories <http://git.yoctoproject.org/cgit/cgit.cgi>`__.
+ Project :yocto_git:`Source Repositories <>`.
- *Packages:* In the context of the Yocto Project, this term refers to
a recipe's packaged output produced by BitBake (i.e. a "baked
@@ -903,7 +879,7 @@
It is worth noting that the term "package" can, in general, have
subtle meanings. For example, the packages referred to in the
- ":ref:`ref-manual/ref-system-requirements:required packages for the build host`"
+ ":ref:`ref-manual/system-requirements:required packages for the build host`"
section in the Yocto Project Reference Manual are compiled binaries
that, when installed, add functionality to your Linux distribution.