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/dev-manual/dev-manual-common-tasks.rst b/poky/documentation/dev-manual/common-tasks.rst
similarity index 97%
rename from poky/documentation/dev-manual/dev-manual-common-tasks.rst
rename to poky/documentation/dev-manual/common-tasks.rst
index 683f555..ada3bac 100644
--- a/poky/documentation/dev-manual/dev-manual-common-tasks.rst
+++ b/poky/documentation/dev-manual/common-tasks.rst
@@ -18,7 +18,7 @@
Layers allow you to isolate different types of customizations from each
other. For introductory information on the Yocto Project Layer Model,
see the
-":ref:`overview-manual/overview-manual-yp-intro:the yocto project layer model`"
+":ref:`overview-manual/yp-intro:the yocto project layer model`"
section in the Yocto Project Overview and Concepts Manual.
Creating Your Own Layer
@@ -31,7 +31,7 @@
layer-creation tools, see the
":ref:`bsp-guide/bsp:creating a new bsp layer using the \`\`bitbake-layers\`\` script`"
section in the Yocto Project Board Support Package (BSP) Developer's
-Guide and the ":ref:`dev-manual/dev-manual-common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`"
+Guide and the ":ref:`dev-manual/common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`"
section further down in this manual.
Follow these general steps to create your layer without using tools:
@@ -75,7 +75,7 @@
``conf`` directory and then modify the file as needed.
The ``meta-yocto-bsp/conf/layer.conf`` file in the Yocto Project
- :yocto_git:`Source Repositories </cgit/cgit.cgi/poky/tree/meta-yocto-bsp/conf>`
+ :yocto_git:`Source Repositories </poky/tree/meta-yocto-bsp/conf>`
demonstrates the required syntax. For your layer, you need to replace
"yoctobsp" with a unique identifier for your layer (e.g. "machinexyz"
for a layer named "meta-machinexyz"):
@@ -135,7 +135,7 @@
Lists all layers on which this layer depends (if any).
- :term:`LAYERSERIES_COMPAT`:
- Lists the :yocto_wiki:`Yocto Project </wiki/Releases>`
+ Lists the :yocto_wiki:`Yocto Project </Releases>`
releases for which the current version is compatible. This
variable is a good way to indicate if your particular layer is
current.
@@ -160,8 +160,6 @@
Project <#making-sure-your-layer-is-compatible-with-yocto-project>`__"
section for more information.
-.. _best-practices-to-follow-when-creating-layers:
-
Following Best Practices When Creating Layers
---------------------------------------------
@@ -457,8 +455,6 @@
adds the recipes, classes and configurations contained within the
particular layer to the source directory.
-.. _using-bbappend-files:
-
Using .bbappend Files in Your Layer
-----------------------------------
@@ -729,7 +725,7 @@
- In order to use a layer with the OpenEmbedded build system, you
need to add the layer to your ``bblayers.conf`` configuration
- file. See the ":ref:`dev-manual/dev-manual-common-tasks:adding a layer using the \`\`bitbake-layers\`\` script`"
+ file. See the ":ref:`dev-manual/common-tasks:adding a layer using the \`\`bitbake-layers\`\` script`"
section for more information.
The default mode of the script's operation with this subcommand is to
@@ -839,16 +835,12 @@
During a build, the OpenEmbedded build system looks in the layers
from the top of the list down to the bottom in that order.
-.. _usingpoky-extend-customimage:
-
Customizing Images
==================
You can customize images to satisfy particular requirements. This
section describes several methods and provides guidelines for each.
-.. _usingpoky-extend-customimage-localconf:
-
Customizing Images Using ``local.conf``
---------------------------------------
@@ -891,8 +883,6 @@
``CORE_IMAGE_EXTRA_INSTALL`` variable. If you use this variable, only
``core-image-*`` images are affected.
-.. _usingpoky-extend-customimage-imagefeatures:
-
Customizing Images Using Custom ``IMAGE_FEATURES`` and ``EXTRA_IMAGE_FEATURES``
-------------------------------------------------------------------------------
@@ -945,12 +935,10 @@
.. note::
- See the ":ref:`ref-manual/ref-features:image features`" section in the Yocto
+ See the ":ref:`ref-manual/features:image features`" section in the Yocto
Project Reference Manual for a complete list of image features that ship
with the Yocto Project.
-.. _usingpoky-extend-customimage-custombb:
-
Customizing Images Using Custom .bb Files
-----------------------------------------
@@ -977,8 +965,6 @@
IMAGE_INSTALL += "strace"
-.. _usingpoky-extend-customimage-customtasks:
-
Customizing Images Using Custom Package Groups
----------------------------------------------
@@ -1039,8 +1025,6 @@
``IMAGE_INSTALL``. For other forms of image dependencies see the other
areas of this section.
-.. _usingpoky-extend-customimage-image-name:
-
Customizing an Image Hostname
-----------------------------
@@ -1080,8 +1064,6 @@
Having no default hostname in the filesystem is suitable for
environments that use dynamic hostnames such as virtual machines.
-.. _new-recipe-writing-a-new-recipe:
-
Writing a New Recipe
====================
@@ -1094,11 +1076,9 @@
For information on variables that are useful for recipes and for
information about recipe naming issues, see the
- ":ref:`ref-manual/ref-varlocality:recipes`" section of the Yocto Project
+ ":ref:`ref-manual/varlocality:recipes`" section of the Yocto Project
Reference Manual.
-.. _new-recipe-overview:
-
Overview
--------
@@ -1108,8 +1088,6 @@
.. image:: figures/recipe-workflow.png
:align: center
-.. _new-recipe-locate-or-automatically-create-a-base-recipe:
-
Locate or Automatically Create a Base Recipe
--------------------------------------------
@@ -1128,9 +1106,7 @@
.. note::
For information on recipe syntax, see the
- ":ref:`dev-manual/dev-manual-common-tasks:recipe syntax`" section.
-
-.. _new-recipe-creating-the-base-recipe-using-devtool:
+ ":ref:`dev-manual/common-tasks:recipe syntax`" section.
Creating the Base Recipe Using ``devtool add``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -1143,12 +1119,10 @@
included in a build.
You can find a complete description of the ``devtool add`` command in
-the ":ref:`sdk-manual/sdk-extensible:a closer look at \`\`devtool add\`\``" section
+the ":ref:`sdk-manual/extensible:a closer look at \`\`devtool add\`\``" section
in the Yocto Project Application Development and the Extensible Software
Development Kit (eSDK) manual.
-.. _new-recipe-creating-the-base-recipe-using-recipetool:
-
Creating the Base Recipe Using ``recipetool create``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -1213,8 +1187,6 @@
recipetool create -d -o OUTFILE source
-.. _new-recipe-locating-and-using-a-similar-recipe:
-
Locating and Using a Similar Recipe
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -1254,8 +1226,6 @@
SRC_URI = ""
-.. _new-recipe-storing-and-naming-the-recipe:
-
Storing and Naming the Recipe
-----------------------------
@@ -1298,8 +1268,6 @@
gawk_4.0.2.bb
irssi_0.8.16-rc1.bb
-.. _new-recipe-running-a-build-on-the-recipe:
-
Running a Build on the Recipe
-----------------------------
@@ -1351,11 +1319,9 @@
``log.do_fetch``, and ``log.do_compile``).
You can find more information about the build process in
-":doc:`../overview-manual/overview-manual-development-environment`"
+":doc:`/overview-manual/development-environment`"
chapter of the Yocto Project Overview and Concepts Manual.
-.. _new-recipe-fetching-code:
-
Fetching Code
-------------
@@ -1364,12 +1330,12 @@
:term:`SRC_URI` variable. Your recipe
must have a ``SRC_URI`` variable that points to where the source is
located. For a graphical representation of source locations, see the
-":ref:`sources-dev-environment`" section in
+":ref:`overview-manual/concepts:sources`" section in
the Yocto Project Overview and Concepts Manual.
The :ref:`ref-tasks-fetch` task uses
the prefix of each entry in the ``SRC_URI`` variable value to determine
-which :ref:`fetcher <bitbake:bb-fetchers>` to use to get your
+which :ref:`fetcher <bitbake:bitbake-user-manual/bitbake-user-manual-fetching:fetchers>` to use to get your
source files. It is the ``SRC_URI`` variable that triggers the fetcher.
The :ref:`ref-tasks-patch` task uses
the variable after source is fetched to apply patches. The OpenEmbedded
@@ -1490,8 +1456,6 @@
The build system automatically applies patches as described in the
"`Patching Code <#new-recipe-patching-code>`__" section.
-.. _new-recipe-unpacking-code:
-
Unpacking Code
--------------
@@ -1512,8 +1476,6 @@
files, you need to be sure that the directory pointed to by ``${S}``
matches the structure of the source.
-.. _new-recipe-patching-code:
-
Patching Code
-------------
@@ -1539,8 +1501,6 @@
(:term:`BP` and
:term:`BPN`) or "files".
-.. _new-recipe-licensing:
-
Licensing
---------
@@ -1578,7 +1538,7 @@
differences result in an error with the message containing the
current checksum. For more explanation and examples of how to set the
``LIC_FILES_CHKSUM`` variable, see the
- ":ref:`dev-manual/dev-manual-common-tasks:tracking license changes`" section.
+ ":ref:`dev-manual/common-tasks:tracking license changes`" section.
To determine the correct checksum string, you can list the
appropriate files in the ``LIC_FILES_CHKSUM`` variable with incorrect
@@ -1597,8 +1557,6 @@
correct string that you can substitute into the recipe file for a
subsequent build.
-.. _new-dependencies:
-
Dependencies
------------
@@ -1641,12 +1599,10 @@
contains a binary that links to "libexample" then the OpenEmbedded build
system will automatically add a runtime dependency to "mypackage" on
"example"). See the
-":ref:`overview-manual/overview-manual-concepts:automatically added runtime dependencies`"
+":ref:`overview-manual/concepts:automatically added runtime dependencies`"
section in the Yocto Project Overview and Concepts Manual for further
details.
-.. _new-recipe-configuring-the-recipe:
-
Configuring the Recipe
----------------------
@@ -1741,8 +1697,6 @@
``./configure --help`` command within ``${S}`` or consult the software's
upstream documentation.
-.. _new-recipe-using-headers-to-interface-with-devices:
-
Using Headers to Interface with Devices
---------------------------------------
@@ -1802,8 +1756,6 @@
do_configure[depends] += "virtual/kernel:do_shared_workdir"
-.. _new-recipe-compilation:
-
Compilation
-----------
@@ -1819,7 +1771,7 @@
For cases where improper paths are detected for configuration files
or for when libraries/headers cannot be found, be sure you are using
the more robust ``pkg-config``. See the note in section
- ":ref:`dev-manual/dev-manual-common-tasks:Configuring the Recipe`" for additional information.
+ ":ref:`dev-manual/common-tasks:Configuring the Recipe`" for additional information.
- *Parallel build failures:* These failures manifest themselves as
intermittent errors, or errors reporting that a file or directory
@@ -1867,8 +1819,6 @@
``STAGING_BINDIR``, ``STAGING_INCDIR``, ``STAGING_DATADIR``, and so
forth).
-.. _new-recipe-installing:
-
Installing
----------
@@ -1956,8 +1906,6 @@
files to ``${D}${datadir}/cmake/Modules`` during
:ref:`ref-tasks-install`.
-.. _new-recipe-enabling-system-services:
-
Enabling System Services
------------------------
@@ -2009,8 +1957,6 @@
section for
more information.
-.. _new-recipe-packaging:
-
Packaging
---------
@@ -2032,7 +1978,7 @@
of common problems that show up during runtime. For information on
these checks, see the
:ref:`insane <ref-classes-insane>` class and
- the ":ref:`ref-manual/ref-qa-checks:qa error and warning messages`"
+ the ":ref:`ref-manual/qa-checks:qa error and warning messages`"
chapter in the Yocto Project Reference Manual.
- *Hand-Checking Your Packages*: After you build your software, you
@@ -2089,8 +2035,6 @@
target machine, particularly if you run separate builds for more than
one target machine.
-.. _new-sharing-files-between-recipes:
-
Sharing Files Between Recipes
-----------------------------
@@ -2137,8 +2081,6 @@
task and its associated functions, see the
:ref:`staging <ref-classes-staging>` class.
-.. _metadata-virtual-providers:
-
Using Virtual Providers
-----------------------
@@ -2165,15 +2107,12 @@
Now comes the time to actually build an image and you need a kernel
recipe, but which one? You can configure your build to call out the
-kernel recipe you want by using the
-:term:`PREFERRED_PROVIDER`
-variable. As an example, consider the
-`x86-base.inc <https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/conf/machine/include/x86-base.inc>`_
-include file, which is a machine (i.e.
-:term:`MACHINE`) configuration file.
-This include file is the reason all x86-based machines use the
-``linux-yocto`` kernel. Here are the relevant lines from the include
-file:
+kernel recipe you want by using the :term:`PREFERRED_PROVIDER` variable. As
+an example, consider the :yocto_git:`x86-base.inc
+</poky/tree/meta/conf/machine/include/x86-base.inc>` include file, which is a
+machine (i.e. :term:`MACHINE`) configuration file. This include file is the
+reason all x86-based machines use the ``linux-yocto`` kernel. Here are the
+relevant lines from the include file:
::
PREFERRED_PROVIDER_virtual/kernel ??= "linux-yocto"
@@ -2251,8 +2190,6 @@
REALPV = "0.8.16-rc1"
PV = "0.8.15+${REALPV}"
-.. _new-recipe-post-installation-scripts:
-
Post-Installation Scripts
-------------------------
@@ -2313,8 +2250,6 @@
because of when they run, they are not applicable to being run at image
creation time like ``pkg_postinst``.
-.. _new-recipe-testing:
-
Testing
-------
@@ -2326,8 +2261,6 @@
packages, see the "`Customizing
Images <#usingpoky-extend-customimage>`__" section.
-.. _new-recipe-testing-examples:
-
Examples
--------
@@ -2344,8 +2277,6 @@
- Adding binaries to an image
-.. _new-recipe-single-c-file-package-hello-world:
-
Single .c File Package (Hello World!)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -2382,8 +2313,6 @@
Multiple Packages <#splitting-an-application-into-multiple-packages>`__"
section.
-.. _new-recipe-autotooled-package:
-
Autotooled Package
~~~~~~~~~~~~~~~~~~
@@ -2409,12 +2338,10 @@
The variable ``LIC_FILES_CHKSUM`` is used to track source license
changes as described in the
-":ref:`dev-manual/dev-manual-common-tasks:tracking license changes`" section in
+":ref:`dev-manual/common-tasks:tracking license changes`" section in
the Yocto Project Overview and Concepts Manual. You can quickly create
Autotool-based recipes in a manner similar to the previous example.
-.. _new-recipe-makefile-based-package:
-
Makefile-Based Package
~~~~~~~~~~~~~~~~~~~~~~
@@ -2559,7 +2486,7 @@
- Using ``DEPENDS`` also allows runtime dependencies between
packages to be added automatically. See the
- ":ref:`overview-manual/overview-manual-concepts:automatically added runtime dependencies`"
+ ":ref:`overview-manual/concepts:automatically added runtime dependencies`"
section in the Yocto Project Overview and Concepts Manual for more
information.
@@ -2864,8 +2791,6 @@
might wish to use. If in doubt, you should check with multiple
implementations - including those from BusyBox.
-.. _platdev-newmachine:
-
Adding a New Machine
====================
@@ -2885,8 +2810,6 @@
section in the Yocto Project Board Support Package (BSP) Developer's
Guide.
-.. _platdev-newmachine-conffile:
-
Adding the Machine Configuration File
-------------------------------------
@@ -2920,8 +2843,6 @@
You can leverage existing machine ``.conf`` files from
``meta-yocto-bsp/conf/machine/``.
-.. _platdev-newmachine-kernel:
-
Adding a Kernel for the Machine
-------------------------------
@@ -2953,11 +2874,9 @@
COMPATIBLE_MACHINE = '(qemux86|qemumips)'
For more information on ``defconfig`` files, see the
-":ref:`kernel-dev/kernel-dev-common:changing the configuration`"
+":ref:`kernel-dev/common:changing the configuration`"
section in the Yocto Project Linux Kernel Development Manual.
-.. _platdev-newmachine-formfactor:
-
Adding a Formfactor Configuration File
--------------------------------------
@@ -2990,8 +2909,6 @@
DISPLAY_DPI=150
DISPLAY_SUBPIXEL_ORDER=vrgb
-.. _gs-upgrading-recipes:
-
Upgrading Recipes
=================
@@ -3011,8 +2928,6 @@
``devtool upgrade`` to set up semi-automatic version upgrades. Finally,
you can manually upgrade a recipe by editing the recipe itself.
-.. _gs-using-the-auto-upgrade-helper:
-
Using the Auto Upgrade Helper (AUH)
-----------------------------------
@@ -3048,7 +2963,7 @@
1. *Be Sure the Development Host is Set Up:* You need to be sure that
your development host is set up to use the Yocto Project. For
information on how to set up your host, see the
- ":ref:`dev-manual/dev-manual-start:Preparing the Build Host`" section.
+ ":ref:`dev-manual/start:Preparing the Build Host`" section.
2. *Make Sure Git is Configured:* The AUH utility requires Git to be
configured because AUH uses Git to save upgrades. Thus, you must have
@@ -3100,7 +3015,7 @@
configurations:
- If you want to enable :ref:`Build
- History <dev-manual/dev-manual-common-tasks:maintaining build output quality>`,
+ History <dev-manual/common-tasks:maintaining build output quality>`,
which is optional, you need the following lines in the
``conf/local.conf`` file:
::
@@ -3140,7 +3055,7 @@
7. *Create and Edit an AUH Configuration File:* You need to have the
``upgrade-helper/upgrade-helper.conf`` configuration file in your
build directory. You can find a sample configuration file in the
- :yocto_git:`AUH source repository </cgit/cgit.cgi/auto-upgrade-helper/tree/>`.
+ :yocto_git:`AUH source repository </auto-upgrade-helper/tree/>`.
Read through the sample file and make configurations as needed. For
example, if you enabled build history in your ``local.conf`` as
@@ -3204,19 +3119,17 @@
You can easily set up to run the AUH utility on a regular basis by using
a cron job. See the
-:yocto_git:`weeklyjob.sh </cgit/cgit.cgi/auto-upgrade-helper/tree/weeklyjob.sh>`
+:yocto_git:`weeklyjob.sh </auto-upgrade-helper/tree/weeklyjob.sh>`
file distributed with the utility for an example.
-.. _gs-using-devtool-upgrade:
-
Using ``devtool upgrade``
-------------------------
As mentioned earlier, an alternative method for upgrading recipes to
newer versions is to use
-:doc:`devtool upgrade <../ref-manual/ref-devtool-reference>`.
+:doc:`devtool upgrade </ref-manual/devtool-reference>`.
You can read about ``devtool upgrade`` in general in the
-":ref:`sdk-manual/sdk-extensible:use \`\`devtool upgrade\`\` to create a version of the recipe that supports a newer version of the software`"
+":ref:`sdk-manual/extensible:use \`\`devtool upgrade\`\` to create a version of the recipe that supports a newer version of the software`"
section in the Yocto Project Application Development and the Extensible
Software Development Kit (eSDK) Manual.
@@ -3350,14 +3263,12 @@
file based on your commits. The tool puts all patch files back into the
source directory in a sub-directory named ``nano`` in this case.
-.. _dev-manually-upgrading-a-recipe:
-
Manually Upgrading a Recipe
---------------------------
If for some reason you choose not to upgrade recipes using
-:ref:`dev-manual/dev-manual-common-tasks:Using the Auto Upgrade Helper (AUH)` or
-by :ref:`dev-manual/dev-manual-common-tasks:Using \`\`devtool upgrade\`\``,
+:ref:`dev-manual/common-tasks:Using the Auto Upgrade Helper (AUH)` or
+by :ref:`dev-manual/common-tasks:Using \`\`devtool upgrade\`\``,
you can manually edit the recipe files to upgrade the versions.
.. note::
@@ -3419,8 +3330,6 @@
builds work and any testing is successful, you can create commits for
any changes in the layer holding your upgraded recipe.
-.. _finding-the-temporary-source-code:
-
Finding Temporary Source Code
=============================
@@ -3491,8 +3400,6 @@
poky/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0
-.. _using-a-quilt-workflow:
-
Using Quilt in Your Workflow
============================
@@ -3506,7 +3413,7 @@
With regard to preserving changes to source files, if you clean a
recipe or have ``rm_work`` enabled, the
- :ref:`devtool workflow <sdk-manual/sdk-extensible:using \`\`devtool\`\` in your sdk workflow>`
+ :ref:`devtool workflow <sdk-manual/extensible:using \`\`devtool\`\` in your sdk workflow>`
as described in the Yocto Project Application Development and the
Extensible Software Development Kit (eSDK) manual is a safer
development flow than the flow that uses Quilt.
@@ -3560,7 +3467,7 @@
(i.e. ``bitbake -c clean package`` and ``bitbake -c cleanall package``).
Modifications will also disappear if you use the ``rm_work`` feature as
described in the
- ":ref:`dev-manual/dev-manual-common-tasks:conserving disk space during builds`"
+ ":ref:`dev-manual/common-tasks:conserving disk space during builds`"
section.
7. *Generate the Patch:* Once your changes work as expected, you need to
@@ -3587,8 +3494,6 @@
SRC_URI += "file://my_changes.patch"
-.. _platdev-appdev-devshell:
-
Using a Development Shell
=========================
@@ -3671,8 +3576,6 @@
- It is also worth noting that ``devshell`` still works over X11
forwarding and similar situations.
-.. _platdev-appdev-devpyshell:
-
Using a Development Python Shell
================================
@@ -3720,8 +3623,6 @@
When you are finished using ``devpyshell``, you can exit the shell
either by using Ctrl+d or closing the terminal window.
-.. _dev-building:
-
Building
========
@@ -3729,8 +3630,6 @@
needed for a simple build, a target that uses multiple configurations,
building an image for more than one machine, and so forth.
-.. _dev-building-a-simple-image:
-
Building a Simple Image
-----------------------
@@ -3745,21 +3644,21 @@
- For information on how to build an image using
:term:`Toaster`, see the
- :doc:`../toaster-manual/toaster-manual`.
+ :doc:`/toaster-manual/index`.
- For information on how to use ``devtool`` to build images, see the
- ":ref:`sdk-manual/sdk-extensible:using \`\`devtool\`\` in your sdk workflow`"
+ ":ref:`sdk-manual/extensible:using \`\`devtool\`\` in your sdk workflow`"
section in the Yocto Project Application Development and the
Extensible Software Development Kit (eSDK) manual.
- For a quick example on how to build an image using the
OpenEmbedded build system, see the
- :doc:`../brief-yoctoprojectqs/brief-yoctoprojectqs` document.
+ :doc:`/brief-yoctoprojectqs/index` document.
The build process creates an entire Linux distribution from source and
places it in your :term:`Build Directory` under
``tmp/deploy/images``. For detailed information on the build process
-using BitBake, see the ":ref:`images-dev-environment`" section in the
+using BitBake, see the ":ref:`overview-manual/concepts:images`" section in the
Yocto Project Overview and Concepts Manual.
The following figure and list overviews the build process:
@@ -3768,7 +3667,7 @@
:align: center
1. *Set up Your Host Development System to Support Development Using the
- Yocto Project*: See the ":doc:`dev-manual-start`" section for options on how to get a
+ Yocto Project*: See the ":doc:`start`" section for options on how to get a
build host ready to use the Yocto Project.
2. *Initialize the Build Environment:* Initialize the build environment
@@ -3815,7 +3714,7 @@
can be the name of a recipe for a specific piece of software such as
BusyBox. For more details about the images the OpenEmbedded build
system supports, see the
- ":ref:`ref-manual/ref-images:Images`" chapter in the Yocto
+ ":ref:`ref-manual/images:Images`" chapter in the Yocto
Project Reference Manual.
As an example, the following command builds the
@@ -3829,12 +3728,10 @@
kernels built by the OpenEmbedded build system are placed in the
Build Directory in ``tmp/deploy/images``. For information on how to
run pre-built images such as ``qemux86`` and ``qemuarm``, see the
- :doc:`../sdk-manual/sdk-manual` manual. For
+ :doc:`/sdk-manual/index` manual. For
information about how to install these images, see the documentation
for your particular board or machine.
-.. _dev-building-images-for-multiple-targets-using-multiple-configurations:
-
Building Images for Multiple Targets Using Multiple Configurations
------------------------------------------------------------------
@@ -3848,8 +3745,6 @@
and how to account for cross-build dependencies between the
multiconfigs.
-.. _dev-setting-up-and-running-a-multiple-configuration-build:
-
Setting Up and Running a Multiple Configuration Build
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -3942,8 +3837,6 @@
directories, the build either loads from an existing sstate cache for
that build at the start or builds the object fresh.
-.. _dev-enabling-multiple-configuration-build-dependencies:
-
Enabling Multiple Configuration Build Dependencies
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -4003,8 +3896,6 @@
each build in the respective temporary build directories (i.e.
:term:`TMPDIR`).
-.. _building-an-initramfs-image:
-
Building an Initial RAM Filesystem (initramfs) Image
----------------------------------------------------
@@ -4095,8 +3986,6 @@
which is around 5 Mbytes, that can be built out-of-the-box using the
Yocto Project.
-.. _tiny-system-overview:
-
Tiny System Overview
~~~~~~~~~~~~~~~~~~~~
@@ -4145,8 +4034,6 @@
information on how to create layers, see the "`Understanding and
Creating Layers <#understanding-and-creating-layers>`__" section.
-.. _understand-what-gives-your-image-size:
-
Understand What Contributes to Your Image Size
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -4159,7 +4046,7 @@
To use ``poky-tiny`` in your build, set the ``DISTRO`` variable in your
``local.conf`` file to "poky-tiny" as described in the
- ":ref:`dev-manual/dev-manual-common-tasks:creating your own distribution`"
+ ":ref:`dev-manual/common-tasks:creating your own distribution`"
section.
Understanding some memory concepts will help you reduce the system size.
@@ -4197,7 +4084,7 @@
directory.
For more information on configuration fragments, see the
- ":ref:`kernel-dev/kernel-dev-common:creating configuration fragments`"
+ ":ref:`kernel-dev/common:creating configuration fragments`"
section in the Yocto Project Linux Kernel Development Manual.
- ``bitbake -u taskexp -g bitbake_target``: Using the BitBake command
@@ -4472,9 +4359,9 @@
higher levels noted earlier can be useful. For example, consider how
NXP (formerly Freescale) allows for the easy reuse of binary packages
in their layer
- :yocto_git:`meta-freescale </cgit/cgit.cgi/meta-freescale/>`.
+ :yocto_git:`meta-freescale </meta-freescale/>`.
In this example, the
- :yocto_git:`fsl-dynamic-packagearch </cgit/cgit.cgi/meta-freescale/tree/classes/fsl-dynamic-packagearch.bbclass>`
+ :yocto_git:`fsl-dynamic-packagearch </meta-freescale/tree/classes/fsl-dynamic-packagearch.bbclass>`
class shares GPU packages for i.MX53 boards because all boards share
the AMD GPU. The i.MX6-based boards can do the same because all
boards share the Vivante GPU. This class inspects the BitBake
@@ -4812,8 +4699,6 @@
the static libraries. If so, you might need to exclude them as
well.
-.. _platdev-working-with-libraries:
-
Working With Libraries
======================
@@ -4889,8 +4774,6 @@
SECTION_${PN}-staticdev = "devel"
RDEPENDS_${PN}-staticdev = "${PN}-dev (= ${EXTENDPKGV})"
-.. _combining-multiple-versions-library-files-into-one-image:
-
Combining Multiple Versions of Library Files into One Image
-----------------------------------------------------------
@@ -5299,8 +5182,6 @@
under 32-bit host machines. In particular, "qemumips64" is known to
not work under i686.
-.. _dev-optionally-using-an-external-toolchain:
-
Optionally Using an External Toolchain
======================================
@@ -5353,7 +5234,7 @@
.. note::
For a kickstart file reference, see the
- ":ref:`ref-manual/ref-kickstart:openembedded kickstart (\`\`.wks\`\`) reference`"
+ ":ref:`ref-manual/kickstart:openembedded kickstart (\`\`.wks\`\`) reference`"
Chapter in the Yocto Project Reference Manual.
The ``wic`` command and the infrastructure it is based on is by
@@ -5368,8 +5249,6 @@
to use the Wic utility, provides information on using the Wic plugins
interface, and provides several examples that show how to use Wic.
-.. _wic-background:
-
Background
----------
@@ -5395,8 +5274,6 @@
general-purpose partitioning language, which is based on Redhat
kickstart syntax.
-.. _wic-requirements:
-
Requirements
------------
@@ -5435,8 +5312,6 @@
- Include the name of the :ref:`wic kickstart file <openembedded-kickstart-wks-reference>`
as part of the :term:`WKS_FILE` variable
-.. _wic-getting-help:
-
Getting Help
------------
@@ -5610,14 +5485,12 @@
name of the image to use the artifacts from e.g. core-
image-sato
-.. _using-a-provided-kickstart-file:
-
Using an Existing Kickstart File
--------------------------------
If you do not want to create your own kickstart file, you can use an
existing file provided by the Wic installation. As shipped, kickstart
-files can be found in the :ref:`overview-manual/overview-manual-development-environment:yocto project source repositories` in the
+files can be found in the :ref:`overview-manual/development-environment:yocto project source repositories` in the
following two locations:
::
@@ -5661,8 +5534,6 @@
bootloader --ptable gpt --timeout=5 --append="rootfstype=ext4 console=ttyS0,115200 console=tty0"
-.. _wic-using-the-wic-plugin-interface:
-
Using the Wic Plugin Interface
------------------------------
@@ -5690,7 +5561,7 @@
Source plugins are subclasses defined in plugin files. As shipped, the
Yocto Project provides several plugin files. You can see the source
plugin files that ship with the Yocto Project
-:yocto_git:`here </cgit/cgit.cgi/poky/tree/scripts/lib/wic/plugins/source>`.
+:yocto_git:`here </poky/tree/scripts/lib/wic/plugins/source>`.
Each of these plugin files contains source plugins that are designed to
populate a specific Wic image partition.
@@ -5802,8 +5673,6 @@
interest. On success, these will be filled in with the actual methods.
See the Wic implementation for examples and details.
-.. _wic-usage-examples:
-
Wic Examples
------------
@@ -5813,8 +5682,6 @@
examples assume the previously generated image is
``core-image-minimal``.
-.. _generate-an-image-using-a-provided-kickstart-file:
-
Generate an Image using an Existing Kickstart File
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -5869,7 +5736,7 @@
For more information on how to use the ``bmaptool``
to flash a device with an image, see the
- ":ref:`dev-manual/dev-manual-common-tasks:flashing images using \`\`bmaptool\`\``"
+ ":ref:`dev-manual/common-tasks:flashing images using \`\`bmaptool\`\``"
section.
Using a Modified Kickstart File
@@ -6089,7 +5956,7 @@
Once the new kernel is added back into the image, you can use the
``dd`` command or :ref:`bmaptool
- <dev-manual/dev-manual-common-tasks:flashing images using \`\`bmaptool\`\`>`
+ <dev-manual/common-tasks:flashing images using \`\`bmaptool\`\`>`
to flash your wic image onto an SD card or USB stick and test your
target.
@@ -6305,7 +6172,7 @@
- Consider enabling a Mandatory Access Control (MAC) framework such as
SMACK or SELinux and tuning it appropriately for your device's usage.
You can find more information in the
- :yocto_git:`meta-selinux </cgit/cgit.cgi/meta-selinux/>` layer.
+ :yocto_git:`meta-selinux </meta-selinux/>` layer.
Tools for Hardening Your Image
------------------------------
@@ -6335,7 +6202,7 @@
just placing configurations in a ``local.conf`` configuration file
makes it easier to reproduce the same build configuration when using
multiple build machines. See the
- ":ref:`dev-manual/dev-manual-common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`"
+ ":ref:`dev-manual/common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`"
section for information on how to quickly set up a layer.
- *Create the distribution configuration file:* The distribution
@@ -6495,8 +6362,6 @@
``conf-notes.txt`` in your custom template configuration directory and
making sure you have ``TEMPLATECONF`` set to your directory.
-.. _dev-saving-memory-during-a-build:
-
Conserving Disk Space During Builds
===================================
@@ -6573,8 +6438,6 @@
prevent the installation of a package whose presence is required by
an installed package.
-.. _incrementing-a-binary-package-version:
-
Incrementing a Package Version
------------------------------
@@ -6610,7 +6473,7 @@
build system uses this string to help define the value of ``PV`` when
the source code revision needs to be included in it.
-- :yocto_wiki:`PR Service </wiki/PR_Service>`: A
+- :yocto_wiki:`PR Service </PR_Service>`: A
network-based service that helps automate keeping package feeds
compatible with existing package manager applications such as RPM,
APT, and OPKG.
@@ -6652,7 +6515,7 @@
.. note::
For additional information on using a PR Service, you can see the
- :yocto_wiki:`PR Service </wiki/PR_Service>` wiki page.
+ :yocto_wiki:`PR Service </PR_Service>` wiki page.
The Yocto Project uses variables in order of decreasing priority to
facilitate revision numbering (i.e.
@@ -6663,7 +6526,7 @@
and procedures of a given distribution and package feed.
Because the OpenEmbedded build system uses
-":ref:`signatures <overview-checksums>`", which are
+":ref:`signatures <overview-manual/concepts:checksums (signatures)>`", which are
unique to a given build, the build system knows when to rebuild
packages. All the inputs into a given task are represented by a
signature, which can trigger a rebuild when different. Thus, the build
@@ -6737,7 +6600,7 @@
use a PR Service while others do not leads to obvious problems.
For more information on shared state, see the
- ":ref:`overview-manual/overview-manual-concepts:shared state cache`"
+ ":ref:`overview-manual/concepts:shared state cache`"
section in the Yocto Project Overview and Concepts Manual.
Manually Bumping PR
@@ -6777,8 +6640,6 @@
These guidelines define how versions are compared and what "increasing"
a version means.
-.. _automatically-incrementing-a-binary-package-revision-number:
-
Automatically Incrementing a Package Version Number
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -6906,7 +6767,7 @@
For more examples that show how to use ``do_split_packages``, see the
``connman.inc`` file in the ``meta/recipes-connectivity/connman/``
-directory of the ``poky`` :ref:`source repository <yocto-project-repositories>`. You can
+directory of the ``poky`` :ref:`source repository <overview-manual/development-environment:yocto project source repositories>`. You can
also find examples in ``meta/classes/kernel.bbclass``.
Following is a reference that shows ``do_split_packages`` mandatory and
@@ -7077,8 +6938,6 @@
and beyond the basics. The remainder of this section describes what you
need to do.
-.. _runtime-package-management-build:
-
Build Considerations
~~~~~~~~~~~~~~~~~~~~
@@ -7165,8 +7024,6 @@
``tmp`` and your selected package type is RPM, then your RPM packages
are available in ``tmp/deploy/rpm``.
-.. _runtime-package-management-server:
-
Host or Server Machine Setup
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -7193,16 +7050,12 @@
$ cd ~/poky/build/tmp/deploy/rpm
$ python3 -m http.server
-.. _runtime-package-management-target:
-
Target Setup
~~~~~~~~~~~~
Setting up the target differs depending on the package management
system. This section provides information for RPM, IPK, and DEB.
-.. _runtime-package-management-target-rpm:
-
Using RPM
^^^^^^^^^
@@ -7283,8 +7136,6 @@
See the `DNF documentation <https://dnf.readthedocs.io/en/latest/>`__ for
additional information.
-.. _runtime-package-management-target-ipk:
-
Using IPK
^^^^^^^^^
@@ -7325,8 +7176,6 @@
The ``opkg`` application is now able to find, install, and upgrade packages
from the specified repository.
-.. _runtime-package-management-target-deb:
-
Using DEB
^^^^^^^^^
@@ -7462,7 +7311,7 @@
the testname can be any identifying string.
For a list of Yocto Project recipes that are already enabled with ptest,
-see the :yocto_wiki:`Ptest </wiki/Ptest>` wiki page.
+see the :yocto_wiki:`Ptest </Ptest>` wiki page.
.. note::
@@ -7567,9 +7416,9 @@
`NPM <https://en.wikipedia.org/wiki/Npm_(software)>`__ is a package
manager for the JavaScript programming language. The Yocto Project
-supports the NPM :ref:`fetcher <bitbake:bb-fetchers>`. You can
+supports the NPM :ref:`fetcher <bitbake:bitbake-user-manual/bitbake-user-manual-fetching:fetchers>`. You can
use this fetcher in combination with
-:doc:`devtool <../ref-manual/ref-devtool-reference>` to create
+:doc:`devtool </ref-manual/devtool-reference>` to create
recipes that produce NPM packages.
Two workflows exist that allow you to create NPM packages using
@@ -7583,8 +7432,6 @@
Additionally, some requirements and caveats exist.
-.. _npm-package-creation-requirements:
-
Requirements and Caveats
~~~~~~~~~~~~~~~~~~~~~~~~
@@ -7599,7 +7446,7 @@
is NPM's public registry.
- Be familiar with
- :doc:`devtool <../ref-manual/ref-devtool-reference>`.
+ :doc:`devtool </ref-manual/devtool-reference>`.
- The NPM host tools need the native ``nodejs-npm`` package, which is
part of the OpenEmbedded environment. You need to get the package by
@@ -7619,8 +7466,6 @@
useful to have NPM on your target. The NPM package name is
``nodejs-npm``.
-.. _npm-using-the-registry-modules-method:
-
Using the Registry Modules Method
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -7731,8 +7576,6 @@
You can find the recipe in ``workspace/recipes/cute-files``. You can use
the recipe in any layer you choose.
-.. _npm-using-the-npm-projects-method:
-
Using the NPM Projects Code Method
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -7956,8 +7799,6 @@
and the appropriate packages will have support for both systemd and
SysVinit.
-.. _selecting-dev-manager:
-
Selecting a Device Manager
==========================
@@ -7974,8 +7815,6 @@
configuration of device nodes is done in user space by a device
manager like ``udev`` or ``busybox-mdev``.
-.. _static-dev-management:
-
Using Persistent and Pre-Populated\ ``/dev``
--------------------------------------------
@@ -8002,8 +7841,6 @@
The population is handled by the ``makedevs`` utility during image
creation:
-.. _devtmpfs-dev-management:
-
Using ``devtmpfs`` and a Device Manager
---------------------------------------
@@ -8036,8 +7873,6 @@
# VIRTUAL-RUNTIME_dev_manager = "busybox-mdev"
# VIRTUAL-RUNTIME_dev_manager = "systemd"
-.. _platdev-appdev-srcrev:
-
Using an External SCM
=====================
@@ -8144,7 +7979,7 @@
EXTRA_IMAGE_FEATURES = "read-only-rootfs"
For more information on how to use these variables, see the
-":ref:`dev-manual/dev-manual-common-tasks:Customizing Images Using Custom \`\`IMAGE_FEATURES\`\` and \`\`EXTRA_IMAGE_FEATURES\`\``"
+":ref:`dev-manual/common-tasks:Customizing Images Using Custom \`\`IMAGE_FEATURES\`\` and \`\`EXTRA_IMAGE_FEATURES\`\``"
section. For information on the variables, see
:term:`IMAGE_FEATURES` and
:term:`EXTRA_IMAGE_FEATURES`.
@@ -8221,13 +8056,13 @@
The remainder of this section describes the following:
-- :ref:`How you can enable and disable build history <dev-manual/dev-manual-common-tasks:enabling and disabling build history>`
+- :ref:`How you can enable and disable build history <dev-manual/common-tasks:enabling and disabling build history>`
-- :ref:`How to understand what the build history contains <dev-manual/dev-manual-common-tasks:understanding what the build history contains>`
+- :ref:`How to understand what the build history contains <dev-manual/common-tasks:understanding what the build history contains>`
-- :ref:`How to limit the information used for build history <dev-manual/dev-manual-common-tasks:using build history to gather image information only>`
+- :ref:`How to limit the information used for build history <dev-manual/common-tasks:using build history to gather image information only>`
-- :ref:`How to examine the build history from both a command-line and web interface <dev-manual/dev-manual-common-tasks:examining build history information>`
+- :ref:`How to examine the build history from both a command-line and web interface <dev-manual/common-tasks:examining build history information>`
Enabling and Disabling Build History
------------------------------------
@@ -8245,7 +8080,7 @@
Enabling build history as
previously described causes the OpenEmbedded build system to collect
build output information and commit it as a single commit to a local
-:ref:`overview-manual/overview-manual-development-environment:git` repository.
+:ref:`overview-manual/development-environment:git` repository.
.. note::
@@ -8598,7 +8433,7 @@
To see changes to the build history using a web interface, follow the
instruction in the ``README`` file
-:yocto_git:`here </cgit/cgit.cgi/buildhistory-web/>`.
+:yocto_git:`here </buildhistory-web/>`.
Here is a sample screenshot of the interface:
@@ -8617,7 +8452,7 @@
write and add your own tests.
For information on the test and QA infrastructure available within the
-Yocto Project, see the ":ref:`ref-manual/ref-release-process:testing and quality assurance`"
+Yocto Project, see the ":ref:`ref-manual/release-process:testing and quality assurance`"
section in the Yocto Project Reference Manual.
Enabling Tests
@@ -8628,8 +8463,6 @@
following subsections for information on how to enable both types of
tests.
-.. _qemu-image-enabling-tests:
-
Enabling Runtime Tests on QEMU
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -8714,8 +8547,6 @@
You can find the output from the ``unittest`` in the task log at
``${WORKDIR}/temp/log.do_testimage``.
-.. _hardware-image-enabling-tests:
-
Enabling Runtime Tests on Hardware
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -8931,8 +8762,6 @@
TEST_SERIALCONTROL_CMD = "${COREBASE}/scripts/contrib/serdevtry picocom -b 115200 /dev/ttyUSB0"
-.. _qemu-image-running-tests:
-
Running Tests
-------------
@@ -9077,8 +8906,6 @@
$ cd tmp/testexport/core-image-sato
$ ./runexported.py testdata.json
-.. _qemu-image-writing-new-tests:
-
Writing New Tests
-----------------
@@ -9110,8 +8937,6 @@
is found in ``meta/lib/oetest.py``. This base class offers some helper
attributes, which are described in the following sections:
-.. _qemu-image-writing-tests-class-methods:
-
Class Methods
~~~~~~~~~~~~~
@@ -9125,8 +8950,6 @@
:term:`IMAGE_FEATURES` or
:term:`DISTRO_FEATURES`.
-.. _qemu-image-writing-tests-class-attributes:
-
Class Attributes
~~~~~~~~~~~~~~~~
@@ -9174,8 +8997,6 @@
- *copy_from(remotepath, localpath):*
``scp root@host:remotepath localpath``.
-.. _qemu-image-writing-tests-instance-attributes:
-
Instance Attributes
~~~~~~~~~~~~~~~~~~~
@@ -9241,8 +9062,6 @@
]
}
-.. _usingpoky-debugging-tools-and-techniques:
-
Debugging Tools and Techniques
==============================
@@ -9265,7 +9084,7 @@
completes to log error information into a common database, that can
help you figure out what might be going wrong. For information on how
to enable and use this feature, see the
- ":ref:`dev-manual/dev-manual-common-tasks:using the error reporting tool`"
+ ":ref:`dev-manual/common-tasks:using the error reporting tool`"
section.
The following list shows the debugging topics in the remainder of this
@@ -9281,7 +9100,7 @@
use the BitBake ``-e`` option to examine variable values after a
recipe has been parsed.
-- ":ref:`dev-manual/dev-manual-common-tasks:viewing package information with \`\`oe-pkgdata-util\`\``"
+- ":ref:`dev-manual/common-tasks:viewing package information with \`\`oe-pkgdata-util\`\``"
describes how to use the ``oe-pkgdata-util`` utility to query
:term:`PKGDATA_DIR` and
display package-related information for built packages.
@@ -9333,8 +9152,6 @@
- "`Other Debugging Tips <#dev-other-debugging-others>`__" describes
miscellaneous debugging tips that can be useful.
-.. _dev-debugging-viewing-logs-from-failed-tasks:
-
Viewing Logs from Failed Tasks
------------------------------
@@ -9354,8 +9171,6 @@
when it ran. The symlinks always point to the files corresponding to the
most recent run.
-.. _dev-debugging-viewing-variable-values:
-
Viewing Variable Values
-----------------------
@@ -9409,7 +9224,7 @@
- The output starts with a tree listing all configuration files and
classes included globally, recursively listing the files they include
or inherit in turn. Much of the behavior of the OpenEmbedded build
- system (including the behavior of the :ref:`ref-manual/ref-tasks:normal recipe build tasks`) is
+ system (including the behavior of the :ref:`ref-manual/tasks:normal recipe build tasks`) is
implemented in the
:ref:`base <ref-classes-base>` class and the
classes it inherits, rather than being built into BitBake itself.
@@ -9477,8 +9292,6 @@
$ oe-pkgdata-util --help
$ oe-pkgdata-util subcommand --help
-.. _dev-viewing-dependencies-between-recipes-and-tasks:
-
Viewing Dependencies Between Recipes and Tasks
----------------------------------------------
@@ -9545,8 +9358,6 @@
displays a GUI window from which you can view build-time and runtime
dependencies for the recipes involved in building recipename.
-.. _dev-viewing-task-variable-dependencies:
-
Viewing Task Variable Dependencies
----------------------------------
@@ -9583,7 +9394,7 @@
${BUILDDIR}/tmp/stamps/i586-poky-linux/db/6.0.30-r1.do_fetch.sigdata.7c048c18222b16ff0bcee2000ef648b1
For tasks that are accelerated through the shared state
- (:ref:`sstate <overview-manual/overview-manual-concepts:shared state cache>`) cache, an
+ (:ref:`sstate <overview-manual/concepts:shared state cache>`) cache, an
additional ``siginfo`` file is written into
:term:`SSTATE_DIR` along with
the cached task output. The ``siginfo`` files contain exactly the
@@ -9638,8 +9449,6 @@
``sigdata`` files in the ``stamps`` directory for every task it would
have executed instead of building the specified target package.
-.. _dev-viewing-metadata-used-to-create-the-input-signature-of-a-shared-state-task:
-
Viewing Metadata Used to Create the Input Signature of a Shared State Task
--------------------------------------------------------------------------
@@ -9652,17 +9461,15 @@
Dependencies <#dev-viewing-task-variable-dependencies>`__" section.
For conceptual information on shared state, see the
-":ref:`overview-manual/overview-manual-concepts:shared state`"
+":ref:`overview-manual/concepts:shared state`"
section in the Yocto Project Overview and Concepts Manual.
-.. _dev-invalidating-shared-state-to-force-a-task-to-run:
-
Invalidating Shared State to Force a Task to Run
------------------------------------------------
The OpenEmbedded build system uses
-:ref:`checksums <overview-checksums>` and
-:ref:`overview-manual/overview-manual-concepts:shared state` cache to avoid unnecessarily
+:ref:`checksums <overview-manual/concepts:checksums (signatures)>` and
+:ref:`overview-manual/concepts:shared state` cache to avoid unnecessarily
rebuilding tasks. Collectively, this scheme is known as "shared state
code".
@@ -9701,9 +9508,7 @@
For an example of a commit that makes a cosmetic change to invalidate
shared state, see this
- :yocto_git:`commit </cgit.cgi/poky/commit/meta/classes/package.bbclass?id=737f8bbb4f27b4837047cb9b4fbfe01dfde36d54>`.
-
-.. _dev-debugging-taskrunning:
+ :yocto_git:`commit </poky/commit/meta/classes/package.bbclass?id=737f8bbb4f27b4837047cb9b4fbfe01dfde36d54>`.
Running Specific Tasks
----------------------
@@ -9725,7 +9530,7 @@
depends on will be run before the task. Even when you manually specify a
task to run with ``-c``, BitBake will only run the task if it considers
it "out of date". See the
-":ref:`overview-manual/overview-manual-concepts:stamp files and the rerunning of tasks`"
+":ref:`overview-manual/concepts:stamp files and the rerunning of tasks`"
section in the Yocto Project Overview and Concepts Manual for how
BitBake determines whether a task is "out of date".
@@ -9759,7 +9564,7 @@
therefore understands that the other tasks also need to be run again.
Another, shorter way to rerun a task and all
-:ref:`ref-manual/ref-tasks:normal recipe build tasks`
+:ref:`ref-manual/tasks:normal recipe build tasks`
that depend on it is to use the ``-C`` option.
.. note::
@@ -9812,8 +9617,6 @@
The results appear as output to the console and are also in
the file ``${WORKDIR}/temp/log.do_listtasks``.
-.. _dev-debugging-bitbake:
-
General BitBake Problems
------------------------
@@ -9827,8 +9630,6 @@
provider. This command could also help you in a situation where you
think BitBake did something unexpected.
-.. _dev-debugging-buildfile:
-
Building with No Dependencies
-----------------------------
@@ -10190,8 +9991,6 @@
the Yocto Project <#how-to-submit-a-change>`__" section for more
information.
-.. _platdev-gdb-remotedebug:
-
Debugging With the GNU Project Debugger (GDB) Remotely
------------------------------------------------------
@@ -10199,7 +9998,7 @@
understand and fix problems. It also allows you to perform post-mortem
style analysis of program crashes. GDB is available as a package within
the Yocto Project and is installed in SDK images by default. See the
-":ref:`ref-manual/ref-images:Images`" chapter in the Yocto
+":ref:`ref-manual/images:Images`" chapter in the Yocto
Project Reference Manual for a description of these images. You can find
information on GDB at https://sourceware.org/gdb/.
@@ -10453,8 +10252,6 @@
Consider that this will reduce the application's performance and is
recommended only for debugging purposes.
-.. _dev-other-debugging-others:
-
Other Debugging Tips
--------------------
@@ -10520,7 +10317,7 @@
Project implementation of
:yocto_bugs:`Bugzilla <>`. For information on
how to submit a bug against the Yocto Project, see the Yocto Project
- Bugzilla :yocto_wiki:`wiki page </wiki/Bugzilla_Configuration_and_Bug_Tracking>`
+ Bugzilla :yocto_wiki:`wiki page </Bugzilla_Configuration_and_Bug_Tracking>`
and the "`Submitting a Defect Against the Yocto
Project <#submitting-a-defect-against-the-yocto-project>`__" section.
@@ -10548,7 +10345,7 @@
Bugzilla <resources-bugtracker>`" section in the
Yocto Project Reference Manual. For more detail on any of the following
steps, see the Yocto Project
-:yocto_wiki:`Bugzilla wiki page </wiki/Bugzilla_Configuration_and_Bug_Tracking>`.
+:yocto_wiki:`Bugzilla wiki page </Bugzilla_Configuration_and_Bug_Tracking>`.
Use the following general steps to submit a bug:
@@ -10596,8 +10393,6 @@
sending you an automated email concerning the particular change or
progress to the bug.
-.. _how-to-submit-a-change:
-
Submitting a Change to the Yocto Project
----------------------------------------
@@ -10662,7 +10457,8 @@
You can also push a change upstream and request a maintainer to pull the
change into the component's upstream repository. You do this by pushing
-to a contribution repository that is upstream. See the ":ref:`gs-git-workflows-and-the-yocto-project`"
+to a contribution repository that is upstream. See the
+":ref:`overview-manual/development-environment:git workflows and the yocto project`"
section in the Yocto Project Overview and Concepts Manual for additional
concepts on working in the Yocto Project development environment.
@@ -10676,7 +10472,7 @@
proposed changes to the core metadata.
- *poky "master-next" branch:* This branch is part of the
- :yocto_git:`poky </cgit/cgit.cgi/poky/>` repository and combines proposed
+ :yocto_git:`poky </poky/>` repository and combines proposed
changes to bitbake, the core metadata and the poky distro.
Similarly, stable branches maintained by the project may have corresponding
@@ -10690,8 +10486,6 @@
The following sections provide procedures for submitting a change.
-.. _preparing-changes-for-submissions:
-
Preparing Changes for Submission
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -10775,8 +10569,6 @@
detailed description of change
-.. _submitting-a-patch:
-
Using Email to Submit a Patch
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -10789,7 +10581,7 @@
Here is the general procedure on how to submit a patch through email
without using the scripts once the steps in
-:ref:`preparing-changes-for-submissions` have been followed:
+:ref:`dev-manual/common-tasks:preparing changes for submission` have been followed:
1. *Format the Commit:* Format the commit into an email message. To
format commits, use the ``git format-patch`` command. When you
@@ -10867,8 +10659,6 @@
Asking about the status of a patch or change is reasonable if the change
has been idle for a while with no feedback.
-.. _pushing-a-change-upstream:
-
Using Scripts to Push a Change Upstream and Request a Pull
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -10880,7 +10670,7 @@
patch series with a link to the branch for review.
Follow this procedure to push a change to an upstream "contrib" Git
-repository once the steps in :ref:`preparing-changes-for-submissions` have
+repository once the steps in :ref:`dev-manual/common-tasks:preparing changes for submission` have
been followed:
.. note::
@@ -10917,7 +10707,7 @@
located in the :term:`Source Directory` at
``meta/conf/distro/include``, to see who is responsible for code.
- - *Search by File:* Using :ref:`overview-manual/overview-manual-development-environment:git`, you can
+ - *Search by File:* Using :ref:`overview-manual/development-environment:git`, you can
enter the following command to bring up a short list of all
commits against a specific file:
::
@@ -11019,7 +10809,7 @@
The list of stable branches along with the status and maintainer for each
branch can be obtained from the
-:yocto_wiki:`Releases wiki page </wiki/Releases>`.
+:yocto_wiki:`Releases wiki page </Releases>`.
.. note::
@@ -11055,8 +10845,8 @@
a newer version of the software which includes an upstream fix for the
issue or when the issue has been fixed on the master branch in a way
that introduces backwards incompatible changes. In this case follow the
- steps in :ref:`preparing-changes-for-submissions` and
- :ref:`submitting-a-patch` but modify the subject header of your patch
+ steps in :ref:`dev-manual/common-tasks:preparing changes for submission` and
+ :ref:`dev-manual/common-tasks:using email to submit a patch` but modify the subject header of your patch
email to include the name of the stable branch which you are
targetting. This can be done using the ``--subject-prefix`` argument to
``git format-patch``, for example to submit a patch to the dunfell
@@ -11066,7 +10856,7 @@
Working With Licenses
=====================
-As mentioned in the ":ref:`overview-manual/overview-manual-development-environment:licensing`"
+As mentioned in the ":ref:`overview-manual/development-environment:licensing`"
section in the Yocto Project Overview and Concepts Manual, open source
projects are open to the public and they consequently have different
licensing structures in place. This section describes the mechanism by
@@ -11076,8 +10866,6 @@
during your project's lifecycle. The section also describes how to
enable commercially licensed recipes, which by default are disabled.
-.. _usingpoky-configuring-LIC_FILES_CHKSUM:
-
Tracking License Changes
------------------------
@@ -11088,8 +10876,6 @@
at the end of the configure step, and if the checksums do not match, the
build will fail.
-.. _usingpoky-specifying-LIC_FILES_CHKSUM:
-
Specifying the ``LIC_FILES_CHKSUM`` Variable
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -11133,8 +10919,6 @@
Note that ``LIC_FILES_CHKSUM`` variable is mandatory for all recipes,
unless the ``LICENSE`` variable is set to "CLOSED".
-.. _usingpoky-LIC_FILES_CHKSUM-explanation-of-syntax:
-
Explanation of Syntax
~~~~~~~~~~~~~~~~~~~~~
@@ -11515,7 +11299,7 @@
used during the build, you will be providing both compilation scripts
and the source code modifications in one step.
-If the deployment team has a :ref:`overview-manual/overview-manual-concepts:bsp layer`
+If the deployment team has a :ref:`overview-manual/concepts:bsp layer`
and a distro layer, and those
those layers are used to patch, compile, package, or modify (in any way)
any open source software included in your released images, you might be
@@ -11594,7 +11378,7 @@
SPDX_DEPLOY_DIR = "${DEPLOY_DIR}" //Optional
For more usage information refer to :yocto_git:`the meta-spdxscanner repository
-</cgit/cgit.cgi/meta-spdxscanner/>`.
+</meta-spdxscanner/>`.
Copying Licenses that Do Not Exist
@@ -11700,11 +11484,9 @@
------------------------------------------
If you want to set up your own error reporting server, you can obtain
-the code from the Git repository at :yocto_git:`/cgit/cgit.cgi/error-report-web/`.
+the code from the Git repository at :yocto_git:`/error-report-web/`.
Instructions on how to set it up are in the README document.
-.. _dev-using-wayland-and-weston:
-
Using Wayland and Weston
========================
@@ -11747,8 +11529,6 @@
To enable Wayland, you need to enable it to be built and enable it to be
included (installed) in the image.
-.. _enable-building:
-
Building Wayland
~~~~~~~~~~~~~~~~
@@ -11767,8 +11547,6 @@
If X11 has been enabled elsewhere, Weston will build Wayland with X11
support
-.. _enable-installation-in-an-image:
-
Installing Wayland and Weston
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/poky/documentation/dev-manual/dev-manual.rst b/poky/documentation/dev-manual/index.rst
similarity index 75%
rename from poky/documentation/dev-manual/dev-manual.rst
rename to poky/documentation/dev-manual/index.rst
index 8f09224..941db2d 100644
--- a/poky/documentation/dev-manual/dev-manual.rst
+++ b/poky/documentation/dev-manual/index.rst
@@ -10,10 +10,10 @@
:caption: Table of Contents
:numbered:
- dev-manual-intro
- dev-manual-start
- dev-manual-common-tasks
- dev-manual-qemu
+ intro
+ start
+ common-tasks
+ qemu
history
.. include:: /boilerplate.rst
diff --git a/poky/documentation/dev-manual/dev-manual-intro.rst b/poky/documentation/dev-manual/intro.rst
similarity index 92%
rename from poky/documentation/dev-manual/dev-manual-intro.rst
rename to poky/documentation/dev-manual/intro.rst
index 05136f7..23c848e 100644
--- a/poky/documentation/dev-manual/dev-manual-intro.rst
+++ b/poky/documentation/dev-manual/intro.rst
@@ -4,8 +4,6 @@
The Yocto Project Development Tasks Manual
******************************************
-.. _dev-welcome:
-
Welcome
=======
@@ -33,13 +31,13 @@
This manual does not provide the following:
- Redundant Step-by-step Instructions: For 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 or Conceptual Material: This type of material resides in an
appropriate reference manual. For example, system variables are
- documented in the :doc:`../ref-manual/ref-manual`.
+ documented in the :doc:`/ref-manual/index`.
- Detailed Public Information Not Specific to the Yocto Project: For
example, exhaustive information on how to use the Source Control
@@ -54,7 +52,7 @@
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.
+:doc:`/brief-yoctoprojectqs/index` document.
For a comprehensive list of links and other documentation, see the
":ref:`ref-manual/resources:links and related documentation`"
diff --git a/poky/documentation/dev-manual/dev-manual-qemu.rst b/poky/documentation/dev-manual/qemu.rst
similarity index 97%
rename from poky/documentation/dev-manual/dev-manual-qemu.rst
rename to poky/documentation/dev-manual/qemu.rst
index c91e8b5..766691b 100644
--- a/poky/documentation/dev-manual/dev-manual-qemu.rst
+++ b/poky/documentation/dev-manual/qemu.rst
@@ -10,8 +10,6 @@
EMUlator (QEMU) and other QEMU information helpful for development
purposes.
-.. _qemu-dev-overview:
-
Overview
========
@@ -39,8 +37,6 @@
- `Documentation <https://wiki.qemu.org/Manual>`__\ *:* The QEMU user
manual.
-.. _qemu-running-qemu:
-
Running QEMU
============
@@ -50,7 +46,7 @@
1. *Install QEMU:* QEMU is made available with the Yocto Project a
number of ways. One method is to install a Software Development Kit
- (SDK). See ":ref:`sdk-manual/sdk-intro:the qemu emulator`" section in the
+ (SDK). See ":ref:`sdk-manual/intro:the qemu emulator`" section in the
Yocto Project Application Development and the Extensible Software
Development Kit (eSDK) manual for information on how to install QEMU.
@@ -81,11 +77,11 @@
your :term:`Build Directory`.
- If you have not built an image, you can go to the
- :yocto_dl:`machines/qemu </releases/yocto/yocto-3.1.2/machines/qemu/>` area and download a
+ :yocto_dl:`machines/qemu </releases/yocto/yocto-&DISTRO;/machines/qemu/>` area and download a
pre-built image that matches your architecture and can be run on
QEMU.
- See the ":ref:`sdk-manual/sdk-appendix-obtain:extracting the root filesystem`"
+ See the ":ref:`sdk-manual/appendix-obtain:extracting the root filesystem`"
section in the Yocto Project Application Development and the
Extensible Software Development Kit (eSDK) manual for information on
how to extract a root filesystem.
@@ -187,8 +183,6 @@
can enter and leave the main window without the grab taking effect
leading to a better user experience.
-.. _qemu-running-under-a-network-file-system-nfs-server:
-
Running Under a Network File System (NFS) Server
================================================
@@ -243,8 +237,6 @@
runqemu-export-rootfs restart file-system-location
-.. _qemu-kvm-cpu-compatibility:
-
QEMU CPU Compatibility Under KVM
================================
@@ -266,8 +258,6 @@
the ``runqemu`` script. Running ``qemu -cpu help`` returns a list of
available supported CPU types.
-.. _qemu-dev-performance:
-
QEMU Performance
================
@@ -320,8 +310,6 @@
Server <#qemu-running-under-a-network-file-system-nfs-server>`__"
section for more information.
-.. _qemu-dev-command-line-syntax:
-
QEMU Command-Line Syntax
========================
@@ -377,8 +365,6 @@
runqemu path/to/<image>-<machine>.wic
runqemu path/to/<image>-<machine>.wic.vmdk
-.. _qemu-dev-runqemu-command-line-options:
-
``runqemu`` Command-Line Options
================================
diff --git a/poky/documentation/dev-manual/dev-manual-start.rst b/poky/documentation/dev-manual/start.rst
similarity index 92%
rename from poky/documentation/dev-manual/dev-manual-start.rst
rename to poky/documentation/dev-manual/start.rst
index a85b86f..03061a7 100644
--- a/poky/documentation/dev-manual/dev-manual-start.rst
+++ b/poky/documentation/dev-manual/start.rst
@@ -7,12 +7,10 @@
This chapter provides guidance on how to prepare to use the Yocto
Project. You can learn about creating a team environment to develop
using the Yocto Project, how to set up a :ref:`build
-host <dev-manual/dev-manual-start:preparing the build host>`, how to locate
+host <dev-manual/start:preparing the build host>`, how to locate
Yocto Project source repositories, and how to create local Git
repositories.
-.. _usingpoky-changes-collaborate:
-
Creating a Team Development Environment
=======================================
@@ -80,7 +78,7 @@
developing under the control of an SCM system that is compatible
with the OpenEmbedded build system is advisable. Of all of the SCMs
supported by BitBake, the Yocto Project team strongly recommends using
- :ref:`overview-manual/overview-manual-development-environment:git`.
+ :ref:`overview-manual/development-environment:git`.
Git is a distributed system
that is easy to back up, allows you to work remotely, and then
connects back to the infrastructure.
@@ -167,7 +165,7 @@
- Highlights when commits break the build.
- Populates an :ref:`sstate
- cache <overview-manual/overview-manual-concepts:shared state cache>` from which
+ cache <overview-manual/concepts:shared state cache>` from which
developers can pull rather than requiring local builds.
- Allows commit hook triggers, which trigger builds when commits
@@ -220,17 +218,17 @@
some best practices exist within the Yocto Project development
environment. Consider the following:
- - Use :ref:`overview-manual/overview-manual-development-environment:git` as the source control
+ - Use :ref:`overview-manual/development-environment:git` as the source control
system.
- Maintain your Metadata in layers that make sense for your
- situation. See the ":ref:`overview-manual/overview-manual-yp-intro:the yocto project layer model`"
+ situation. See the ":ref:`overview-manual/yp-intro:the yocto project layer model`"
section in the Yocto Project Overview and Concepts Manual and the
- ":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+ ":ref:`dev-manual/common-tasks:understanding and creating layers`"
section for more information on layers.
- Separate the project's Metadata and code by using separate Git
- repositories. See the ":ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`"
+ repositories. See the ":ref:`overview-manual/development-environment:yocto project source repositories`"
section in the Yocto Project Overview and Concepts Manual for
information on these repositories. See the "`Locating Yocto
Project Source Files <#locating-yocto-project-source-files>`__"
@@ -250,19 +248,17 @@
project to fix bugs or add features. If you do submit patches,
follow the project commit guidelines for writing good commit
messages. 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.
- Send changes to the core sooner than later as others are likely
to run into the same issues. For some guidance on mailing lists
to use, see the list in 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. For a description
of the available mailing lists, see the ":ref:`resources-mailinglist`" section in
the Yocto Project Reference Manual.
-.. _dev-preparing-the-build-host:
-
Preparing the Build Host
========================
@@ -292,7 +288,7 @@
section in the Yocto Project Board Support Package (BSP) Developer's
Guide.
-- *Kernel Development:* See the ":ref:`kernel-dev/kernel-dev-common:preparing the build host to work on the kernel`"
+- *Kernel Development:* See the ":ref:`kernel-dev/common:preparing the build host to work on the kernel`"
section in the Yocto Project Linux Kernel Development Manual.
Setting Up a Native Linux Host
@@ -309,7 +305,7 @@
validation and their status, see the ":ref:`Supported Linux
Distributions <detailed-supported-distros>`"
section in the Yocto Project Reference Manual and the wiki page at
- :yocto_wiki:`Distribution Support </wiki/Distribution_Support>`.
+ :yocto_wiki:`Distribution Support </Distribution_Support>`.
2. *Have Enough Free Memory:* Your system should have at least 50 Gbytes
of free disk space for building images.
@@ -329,7 +325,7 @@
If your build host does not meet any of these three listed version
requirements, you can take steps to prepare the system so that you
can still use the Yocto Project. See the
- ":ref:`ref-manual/ref-system-requirements:required git, tar, python and gcc versions`"
+ ":ref:`ref-manual/system-requirements:required git, tar, python and gcc versions`"
section in the Yocto Project Reference Manual for information.
4. *Install Development Host Packages:* Required development host
@@ -338,22 +334,20 @@
is large if you want to be able to cover all cases.
For lists of required packages for all scenarios, see 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.
Once you have completed the previous steps, you are ready to continue
using a given development path on your native Linux machine. If you are
going to use BitBake, see the
-":ref:`dev-manual/dev-manual-start:cloning the \`\`poky\`\` repository`"
+":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`"
section. If you are going
-to use the Extensible SDK, see the ":doc:`../sdk-manual/sdk-extensible`" Chapter in the Yocto
+to use the Extensible SDK, see the ":doc:`/sdk-manual/extensible`" Chapter in the Yocto
Project Application Development and the Extensible Software Development
-Kit (eSDK) manual. If you want to work on the kernel, see the :doc:`../kernel-dev/kernel-dev`. If you are going to use
-Toaster, see the ":doc:`../toaster-manual/toaster-manual-setup-and-use`"
+Kit (eSDK) manual. If you want to work on the kernel, see the :doc:`/kernel-dev/index`. If you are going to use
+Toaster, see the ":doc:`/toaster-manual/setup-and-use`"
section in the Toaster User Manual.
-.. _setting-up-to-use-crops:
-
Setting Up to Use CROss PlatformS (CROPS)
-----------------------------------------
@@ -446,16 +440,14 @@
Once you have a container set up, everything is in place to develop just
as if you were running on a native Linux machine. If you are going to
use the Poky container, see the
-":ref:`dev-manual/dev-manual-start:cloning the \`\`poky\`\` repository`"
+":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`"
section. If you are going to use the Extensible SDK container, see the
-":doc:`../sdk-manual/sdk-extensible`" Chapter in the Yocto
+":doc:`/sdk-manual/extensible`" Chapter in the Yocto
Project Application Development and the Extensible Software Development
Kit (eSDK) manual. If you are going to use the Toaster container, see
-the ":doc:`../toaster-manual/toaster-manual-setup-and-use`"
+the ":doc:`/toaster-manual/setup-and-use`"
section in the Toaster User Manual.
-.. _setting-up-to-use-wsl:
-
Setting Up to Use Windows Subsystem For Linux (WSLv2)
-----------------------------------------------------
@@ -565,10 +557,10 @@
Once you have WSLv2 set up, everything is in place to develop just as if
you were running on a native Linux machine. If you are going to use the
-Extensible SDK container, see the ":doc:`../sdk-manual/sdk-extensible`" Chapter in the Yocto
+Extensible SDK container, see the ":doc:`/sdk-manual/extensible`" Chapter in the Yocto
Project Application Development and the Extensible Software Development
Kit (eSDK) manual. If you are going to use the Toaster container, see
-the ":doc:`../toaster-manual/toaster-manual-setup-and-use`"
+the ":doc:`/toaster-manual/setup-and-use`"
section in the Toaster User Manual.
Locating Yocto Project Source Files
@@ -580,21 +572,21 @@
.. note::
- For concepts and introductory information about Git as it is used
- in the Yocto Project, see the ":ref:`overview-manual/overview-manual-development-environment:git`"
+ in the Yocto Project, see the ":ref:`overview-manual/development-environment:git`"
section in the Yocto Project Overview and Concepts Manual.
- For concepts on Yocto Project source repositories, see the
- ":ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`"
+ ":ref:`overview-manual/development-environment:yocto project source repositories`"
section in the Yocto Project Overview and Concepts Manual."
Accessing Source Repositories
-----------------------------
-Working from a copy of the upstream :ref:`dev-manual/dev-manual-start:accessing source repositories` is the
+Working from a copy of the upstream :ref:`dev-manual/start:accessing source repositories` is the
preferred method for obtaining and using a Yocto Project release. You
can view the Yocto Project Source Repositories at
:yocto_git:`/`. In particular, you can find the ``poky``
-repository at :yocto_git:`/cgit.cgi/poky`.
+repository at :yocto_git:`/poky`.
Use the following procedure to locate the latest upstream copy of the
``poky`` Git repository:
@@ -608,12 +600,12 @@
3. *Find the URL Used to Clone the Repository:* At the bottom of the
page, note the URL used to clone that repository
- (e.g. :yocto_git:`/cgit.cgi/poky`).
+ (e.g. :yocto_git:`/poky`).
.. note::
For information on cloning a repository, see the
- ":ref:`dev-manual/dev-manual-start:cloning the \`\`poky\`\` repository`" section.
+ ":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`" section.
Accessing Index of Releases
---------------------------
@@ -686,7 +678,7 @@
.. note::
For a "map" of Yocto Project releases to version numbers, see the
- :yocto_wiki:`Releases </wiki/Releases>` wiki page.
+ :yocto_wiki:`Releases </Releases>` wiki page.
You can use the "RELEASE ARCHIVE" link to reveal a menu of all Yocto
Project releases.
@@ -730,7 +722,7 @@
in the Yocto Project documentation.
The preferred method of creating your Source Directory is by using
-:ref:`overview-manual/overview-manual-development-environment:git` to clone a local copy of the upstream
+:ref:`overview-manual/development-environment:git` to clone a local copy of the upstream
``poky`` repository. Working from a cloned copy of the upstream
repository allows you to contribute back into the Yocto Project or to
simply work with the latest software on a development branch. Because
@@ -809,7 +801,7 @@
1. *Switch to the Poky Directory:* If you have a local poky Git
repository, switch to that directory. If you do not have the local
copy of poky, see the
- ":ref:`dev-manual/dev-manual-start:cloning the \`\`poky\`\` repository`"
+ ":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`"
section.
2. *Determine Existing Branch Names:*
@@ -855,8 +847,6 @@
master
* &DISTRO_NAME_NO_CAP;
-.. _checkout-out-by-tag-in-poky:
-
Checking Out by Tag in Poky
---------------------------
@@ -874,7 +864,7 @@
1. *Switch to the Poky Directory:* If you have a local poky Git
repository, switch to that directory. If you do not have the local
copy of poky, see the
- ":ref:`dev-manual/dev-manual-start:cloning the \`\`poky\`\` repository`"
+ ":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`"
section.
2. *Fetch the Tag Names:* To checkout the branch based on a tag name,