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/ref-manual/ref-classes.rst b/poky/documentation/ref-manual/classes.rst
similarity index 97%
rename from poky/documentation/ref-manual/ref-classes.rst
rename to poky/documentation/ref-manual/classes.rst
index 249b58e..5a30ce3 100644
--- a/poky/documentation/ref-manual/ref-classes.rst
+++ b/poky/documentation/ref-manual/classes.rst
@@ -68,7 +68,7 @@
materials with the binaries.
For more details on the source archiver, 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. You can also see
the :term:`ARCHIVER_MODE` variable for information
about the variable flags (varflags) that help control archive creation.
@@ -86,7 +86,7 @@
should usually be enough to define a few standard variables and then
simply ``inherit autotools``. These classes can also work with software
that emulates Autotools. For more information, see the
-":ref:`new-recipe-autotooled-package`" section
+":ref:`dev-manual/common-tasks:autotooled package`" section
in the Yocto Project Development Tasks Manual.
By default, the ``autotools*`` classes use out-of-tree builds (i.e.
@@ -236,7 +236,7 @@
which can be used to detect possible regressions as well as used for
analysis of the build output. For more information on using Build
History, see the
-":ref:`dev-manual/dev-manual-common-tasks:maintaining build output quality`"
+":ref:`dev-manual/common-tasks:maintaining build output quality`"
section in the Yocto Project Development Tasks Manual.
.. _ref-classes-buildstats:
@@ -406,7 +406,7 @@
The ``cross-canadian`` class provides support for the recipes that build
the Canadian Cross-compilation tools for SDKs. See the
-":ref:`overview-manual/overview-manual-concepts:cross-development toolchain generation`"
+":ref:`overview-manual/concepts:cross-development toolchain generation`"
section in the Yocto Project Overview and Concepts Manual for more
discussion on these cross-compilation tools.
@@ -417,7 +417,7 @@
The ``crosssdk`` class provides support for the recipes that build the
cross-compilation tools used for building SDKs. See the
-":ref:`overview-manual/overview-manual-concepts:cross-development toolchain generation`"
+":ref:`overview-manual/concepts:cross-development toolchain generation`"
section in the Yocto Project Overview and Concepts Manual for more
discussion on these cross-compilation tools.
@@ -458,7 +458,7 @@
====================
The ``devshell`` class adds the ``do_devshell`` task. Distribution
-policy dictates whether to include this class. See the ":ref:`platdev-appdev-devshell`"
+policy dictates whether to include this class. See the ":ref:`dev-manual/common-tasks:using a development shell`"
section in the Yocto Project Development Tasks Manual for more
information about using ``devshell``.
@@ -586,7 +586,7 @@
``meta/classes/externalsrc.bbclass`` in the :term:`Source Directory`.
For information on how to use the
``externalsrc`` class, see the
-":ref:`dev-manual/dev-manual-common-tasks:building software from an external source`"
+":ref:`dev-manual/common-tasks:building software from an external source`"
section in the Yocto Project Development Tasks Manual.
.. _ref-classes-extrausers:
@@ -927,10 +927,10 @@
install into the image.
For information on customizing images, see the
-":ref:`usingpoky-extend-customimage`" section
+":ref:`dev-manual/common-tasks:customizing images`" section
in the Yocto Project Development Tasks Manual. For information on how
images are created, see the
-":ref:`images-dev-environment`" section in the
+":ref:`overview-manual/concepts:images`" section in the
Yocto Project Overview and Concpets Manual.
.. _ref-classes-image-buildinfo:
@@ -1033,7 +1033,7 @@
either raise a warning or an error message. Typically, failures for new
tests generate a warning. Subsequent failures for the same test would
then generate an error message once the metadata is in a known and good
-condition. See the ":doc:`ref-qa-checks`" Chapter for a list of all the warning
+condition. See the ":doc:`/ref-manual/qa-checks`" Chapter for a list of all the warning
and error messages you might encounter using a default configuration.
Use the :term:`WARN_QA` and
@@ -1276,7 +1276,7 @@
- ``textrel:`` Checks for ELF binaries that contain relocations in
their ``.text`` sections, which can result in a performance impact at
runtime. See the explanation for the ``ELF binary`` message in
- ":doc:`ref-qa-checks`" for more information regarding runtime performance
+ ":doc:`/ref-manual/qa-checks`" for more information regarding runtime performance
issues.
- ``unlisted-pkg-lics:`` Checks that all declared licenses applying
@@ -1344,7 +1344,7 @@
The ``kernel`` class contains logic that allows you to embed an initial
RAM filesystem (initramfs) image when you build the kernel image. For
information on how to build an initramfs, see the
-":ref:`building-an-initramfs-image`" section in
+":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) image`" section in
the Yocto Project Development Tasks Manual.
Various other classes are used by the ``kernel`` and ``module`` classes
@@ -1596,7 +1596,7 @@
everything needed to build and package a kernel module.
For general information on out-of-tree Linux kernel modules, see the
-":ref:`kernel-dev/kernel-dev-common:incorporating out-of-tree modules`"
+":ref:`kernel-dev/common:incorporating out-of-tree modules`"
section in the Yocto Project Linux Kernel Development Manual.
.. _ref-classes-module-base:
@@ -1620,7 +1620,7 @@
them side-by-side in the same image.
For more information on using the Multilib feature, see the
-":ref:`combining-multiple-versions-library-files-into-one-image`"
+":ref:`dev-manual/common-tasks:combining multiple versions of library files into one image`"
section in the Yocto Project Development Tasks Manual.
.. _ref-classes-native:
@@ -1732,7 +1732,7 @@
fetcher to have dependencies fetched and packaged automatically.
For information on how to create NPM packages, see the
-":ref:`dev-manual/dev-manual-common-tasks:creating node package manager (npm) packages`"
+":ref:`dev-manual/common-tasks:creating node package manager (npm) packages`"
section in the Yocto Project Development Tasks Manual.
.. _ref-classes-oelint:
@@ -1802,7 +1802,7 @@
the development host that can be used by DNF, you can install packages
from the feed while you are running the image on the target (i.e.
runtime installation of packages). For more information, see the
-":ref:`dev-manual/dev-manual-common-tasks:using runtime package management`"
+":ref:`dev-manual/common-tasks:using runtime package management`"
section in the Yocto Project Development Tasks Manual.
The package-specific class you choose can affect build-time performance
@@ -1921,7 +1921,7 @@
inherit this class.
For information on how to use this class, see the
-":ref:`usingpoky-extend-customimage-customtasks`"
+":ref:`dev-manual/common-tasks:customizing images using custom package groups`"
section in the Yocto Project Development Tasks Manual.
Previously, this class was called the ``task`` class.
@@ -1986,7 +1986,7 @@
The ``populate_sdk`` class provides support for SDK-only recipes. For
information on advantages gained when building a cross-development
toolchain using the :ref:`ref-tasks-populate_sdk`
-task, see the ":ref:`sdk-manual/sdk-appendix-obtain:building an sdk installer`"
+task, see the ":ref:`sdk-manual/appendix-obtain:building an sdk installer`"
section in the Yocto Project Application Development and the Extensible
Software Development Kit (eSDK) manual.
@@ -2039,12 +2039,12 @@
class.
For more information on the cross-development toolchain generation, see
-the ":ref:`overview-manual/overview-manual-concepts:cross-development toolchain generation`"
+the ":ref:`overview-manual/concepts:cross-development toolchain generation`"
section in the Yocto Project Overview and Concepts Manual. For
information on advantages gained when building a cross-development
toolchain using the :ref:`ref-tasks-populate_sdk`
task, see the
-":ref:`sdk-manual/sdk-appendix-obtain:building an sdk installer`"
+":ref:`sdk-manual/appendix-obtain:building an sdk installer`"
section in the Yocto Project Application Development and the Extensible
Software Development Kit (eSDK) manual.
@@ -2080,7 +2080,7 @@
==================
The ``prserv`` class provides functionality for using a :ref:`PR
-service <dev-manual/dev-manual-common-tasks:working with a pr service>` in order to
+service <dev-manual/common-tasks:working with a pr service>` in order to
automatically manage the incrementing of the :term:`PR`
variable for each recipe.
@@ -2100,7 +2100,7 @@
This class is intended to be inherited by individual recipes. However,
the class' functionality is largely disabled unless "ptest" appears in
:term:`DISTRO_FEATURES`. See the
-":ref:`dev-manual/dev-manual-common-tasks:testing packages with ptest`"
+":ref:`dev-manual/common-tasks:testing packages with ptest`"
section in the Yocto Project Development Tasks Manual for more information
on ptest.
@@ -2113,7 +2113,7 @@
have tests intended to be executed with ``gnome-desktop-testing``.
For information on setting up and running ptests, see the
-":ref:`dev-manual/dev-manual-common-tasks:testing packages with ptest`"
+":ref:`dev-manual/common-tasks:testing packages with ptest`"
section in the Yocto Project Development Tasks Manual.
.. _ref-classes-python-dir:
@@ -2199,7 +2199,7 @@
========================
The ``report-error`` class supports enabling the :ref:`error reporting
-tool <dev-manual/dev-manual-common-tasks:using the error reporting tool>`",
+tool <dev-manual/common-tasks:using the error reporting tool>`",
which allows you to submit build error information to a central database.
The class collects debug information for recipe, recipe version, task,
@@ -2268,7 +2268,7 @@
:term:`PACKAGE_CLASSES` variable.
For information on how root filesystem images are created, see the
-":ref:`image-generation-dev-environment`"
+":ref:`overview-manual/concepts:image generation`"
section in the Yocto Project Overview and Concepts Manual.
.. _ref-classes-sanity:
@@ -2375,7 +2375,7 @@
:term:`INHERIT_DISTRO` variable's default value.
For more information on sstate, 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.
.. _ref-classes-staging:
@@ -2554,7 +2554,7 @@
:term:`SYSTEMD_AUTO_ENABLE` to "disable".
For more information on ``systemd``, see the
-":ref:`dev-manual/dev-manual-common-tasks:selecting an initialization manager`"
+":ref:`dev-manual/common-tasks:selecting an initialization manager`"
section in the Yocto Project Development Tasks Manual.
.. _ref-classes-systemd-boot:
@@ -2631,7 +2631,7 @@
:term:`TESTIMAGE_AUTO` must be set to "1").
For information on how to enable, run, and create new tests, see the
-":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`"
+":ref:`dev-manual/common-tasks:performing automated runtime testing`"
section in the Yocto Project Development Tasks Manual.
.. _ref-classes-testsdk:
@@ -2774,7 +2774,7 @@
These variables list alternative commands needed by a package, provide
pathnames for links, default links for targets, and so forth. For
details on how to use this class, see the comments in the
-:yocto_git:`update-alternatives.bbclass </cgit/cgit.cgi/poky/tree/meta/classes/update-alternatives.bbclass>`
+:yocto_git:`update-alternatives.bbclass </poky/tree/meta/classes/update-alternatives.bbclass>`
file.
.. note::
diff --git a/poky/documentation/ref-manual/ref-devtool-reference.rst b/poky/documentation/ref-manual/devtool-reference.rst
similarity index 96%
rename from poky/documentation/ref-manual/ref-devtool-reference.rst
rename to poky/documentation/ref-manual/devtool-reference.rst
index ad8889e..cc5848f 100644
--- a/poky/documentation/ref-manual/ref-devtool-reference.rst
+++ b/poky/documentation/ref-manual/devtool-reference.rst
@@ -11,7 +11,7 @@
This chapter provides a Quick Reference for the ``devtool`` command. For
more information on how to apply the command when using the extensible
-SDK, see the ":doc:`../sdk-manual/sdk-extensible`" chapter in the Yocto
+SDK, see the ":doc:`/sdk-manual/extensible`" chapter in the Yocto
Project Application Development and the Extensible Software Development
Kit (eSDK) manual.
@@ -193,7 +193,7 @@
run your application. If dependent packages (e.g. libraries) do not
exist on the target, your application, when run, will fail to find
those functions. For more information, see the
- ":ref:`ref-manual/ref-devtool-reference:deploying your software on the target machine`"
+ ":ref:`ref-manual/devtool-reference:deploying your software on the target machine`"
section.
By default, ``devtool add`` uses the latest revision (i.e. master) when
@@ -349,10 +349,10 @@
.. note::
- For the ``oe-core`` layer, recipe maintainers come from the
- `maintainers.inc <http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/conf/distro/include/maintainers.inc>`_
+ :yocto_git:`maintainers.inc </poky/tree/meta/conf/distro/include/maintainers.inc>`
file.
- - If the recipe is using the :ref:`bitbake:git-fetcher`
+ - If the recipe is using the :ref:`bitbake:bitbake-user-manual/bitbake-user-manual-fetching:git fetcher (\`\`git://\`\`)`
rather than a
tarball, the commit hash points to the commit that matches the
recipe's latest version tag.
@@ -388,7 +388,7 @@
When a reason for not upgrading displays, the reason is usually
written into the recipe using the ``RECIPE_NO_UPDATE_REASON``
variable. See the
- :yocto_git:`base-passwd.bb </cgit/cgit.cgi/poky/tree/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb>`
+ :yocto_git:`base-passwd.bb </poky/tree/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb>`
recipe for an example.
::
@@ -413,7 +413,7 @@
As software matures, upstream recipes are upgraded to newer versions. As
a developer, you need to keep your local recipes up-to-date with the
upstream version releases. Several methods exist by which you can
-upgrade recipes. You can read about them in the ":ref:`gs-upgrading-recipes`"
+upgrade recipes. You can read about them in the ":ref:`dev-manual/common-tasks:upgrading recipes`"
section of the Yocto Project Development Tasks Manual. This section
overviews the ``devtool upgrade`` command.
@@ -438,10 +438,10 @@
forth.
You can read more on the ``devtool upgrade`` workflow 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. You can also see an example of
-how to use ``devtool upgrade`` in the ":ref:`gs-using-devtool-upgrade`"
+how to use ``devtool upgrade`` in the ":ref:`dev-manual/common-tasks:using \`\`devtool upgrade\`\``"
section in the Yocto Project Development Tasks Manual.
.. _devtool-resetting-a-recipe:
@@ -561,7 +561,7 @@
Use the ``devtool undeploy-target`` command to remove deployed build
output from the target machine. For the ``devtool undeploy-target``
command to work, you must have previously used the
-":ref:`devtool deploy-target <ref-manual/ref-devtool-reference:deploying your software on the target machine>`"
+":ref:`devtool deploy-target <ref-manual/devtool-reference:deploying your software on the target machine>`"
command.
::
@@ -609,7 +609,7 @@
$ devtool status
Following is sample output after using
-:ref:`devtool add <ref-manual/ref-devtool-reference:adding a new recipe to the workspace layer>`
+:ref:`devtool add <ref-manual/devtool-reference:adding a new recipe to the workspace layer>`
to create and add the ``mtr_0.86.bb`` recipe to the ``workspace`` directory:
::
diff --git a/poky/documentation/ref-manual/faq.rst b/poky/documentation/ref-manual/faq.rst
index 576863e..f67c538 100644
--- a/poky/documentation/ref-manual/faq.rst
+++ b/poky/documentation/ref-manual/faq.rst
@@ -22,7 +22,7 @@
**A:** You can get the required tools on your host development system a
couple different ways (i.e. building a tarball or downloading a
tarball). 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 for steps on how to update your build tools.
**Q:** How can you claim Poky / OpenEmbedded-Core is stable?
@@ -45,9 +45,9 @@
**A:** Support for an additional board is added by creating a Board
Support Package (BSP) layer for it. For more information on how to
create a BSP layer, 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 and the
-:doc:`../bsp-guide/bsp-guide`.
+:doc:`/bsp-guide/index`.
Usually, if the board is not completely exotic, adding support in the
Yocto Project is fairly straightforward.
@@ -73,7 +73,7 @@
**A:** To add a package, you need to create a BitBake recipe. For
information on how to create a BitBake recipe, see the
-":ref:`dev-manual/dev-manual-common-tasks:writing a new recipe`"
+":ref:`dev-manual/common-tasks:writing a new recipe`"
section in the Yocto Project Development Tasks Manual.
**Q:** Do I have to reflash my entire board with a new Yocto Project
@@ -140,7 +140,7 @@
``meta-poky/conf/site.conf.sample`` file that shows how to configure CVS
and Git proxy servers if needed. For more information on setting up
various proxy types and configuring proxy servers, see the
-":yocto_wiki:`Working Behind a Network Proxy </wiki/Working_Behind_a_Network_Proxy>`"
+":yocto_wiki:`Working Behind a Network Proxy </Working_Behind_a_Network_Proxy>`"
Wiki page.
**Q:** What's the difference between target and target\ ``-native``?
@@ -198,10 +198,10 @@
configured and built.
You can find more information on licensing in the
-":ref:`overview-manual/overview-manual-development-environment:licensing`"
+":ref:`overview-manual/development-environment:licensing`"
section in the Yocto
Project Overview and Concepts Manual and also in 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.
**Q:** How do I disable the cursor on my touchscreen device?
@@ -362,7 +362,7 @@
.. note::
You can find more information on the
- ":yocto_wiki:`Working Behind a Network Proxy </wiki/Working_Behind_a_Network_Proxy>`"
+ ":yocto_wiki:`Working Behind a Network Proxy </Working_Behind_a_Network_Proxy>`"
Wiki page.
**Q:** Can I get rid of build output so I can start over?
diff --git a/poky/documentation/ref-manual/ref-features.rst b/poky/documentation/ref-manual/features.rst
similarity index 96%
rename from poky/documentation/ref-manual/ref-features.rst
rename to poky/documentation/ref-manual/features.rst
index f28ad2b..89c06eb 100644
--- a/poky/documentation/ref-manual/ref-features.rst
+++ b/poky/documentation/ref-manual/features.rst
@@ -118,7 +118,7 @@
- *api-documentation:* Enables generation of API documentation during
recipe builds. The resulting documentation is added to SDK tarballs
when the ``bitbake -c populate_sdk`` command is used. See the
- ":ref:`sdk-manual/sdk-appendix-customizing-standard:adding api documentation to the standard sdk`"
+ ":ref:`sdk-manual/appendix-customizing-standard:adding api documentation to the standard sdk`"
section in the Yocto Project Application Development and the
Extensible Software Development Kit (eSDK) manual.
@@ -156,7 +156,7 @@
- *ptest:* Enables building the package tests where supported by
individual recipes. For more information on package tests, see the
- ":ref:`dev-manual/dev-manual-common-tasks:testing packages with ptest`" section
+ ":ref:`dev-manual/common-tasks:testing packages with ptest`" section
in the Yocto Project Development Tasks Manual.
- *smbfs:* Include SMB networks client support (for mounting
@@ -236,7 +236,7 @@
- *read-only-rootfs:* Creates an image whose root filesystem is
read-only. See the
- ":ref:`dev-manual/dev-manual-common-tasks:creating a read-only root filesystem`"
+ ":ref:`dev-manual/common-tasks:creating a read-only root filesystem`"
section in the Yocto Project Development Tasks Manual for more
information.
@@ -261,7 +261,7 @@
- *perf:* Installs profiling tools such as ``perf``, ``systemtap``, and
``LTTng``. For general information on user-space tools, see the
- :doc:`../sdk-manual/sdk-manual` manual.
+ :doc:`/sdk-manual/index` manual.
- *ssh-server-dropbear:* Installs the Dropbear minimal SSH server.
@@ -273,9 +273,9 @@
- *tools-debug:* Installs debugging tools such as ``strace`` and
``gdb``. For information on GDB, see the
- ":ref:`platdev-gdb-remotedebug`" section
+ ":ref:`dev-manual/common-tasks:debugging with the gnu project debugger (gdb) remotely`" section
in the Yocto Project Development Tasks Manual. For information on
- tracing and profiling, see the :doc:`../profile-manual/profile-manual`.
+ tracing and profiling, see the :doc:`/profile-manual/index`.
- *tools-sdk:* Installs a full SDK that runs on the device.
diff --git a/poky/documentation/ref-manual/ref-images.rst b/poky/documentation/ref-manual/images.rst
similarity index 97%
rename from poky/documentation/ref-manual/ref-images.rst
rename to poky/documentation/ref-manual/images.rst
index 56ec856..5e9374e 100644
--- a/poky/documentation/ref-manual/ref-images.rst
+++ b/poky/documentation/ref-manual/images.rst
@@ -122,7 +122,7 @@
deployed to a separate partition so that you can boot into it and use
it to deploy a second image to be tested. You can find more
information about runtime testing in the
- ":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`"
+ ":ref:`dev-manual/common-tasks:performing automated runtime testing`"
section in the Yocto Project Development Tasks Manual.
- ``core-image-testmaster-initramfs``: A RAM-based Initial Root
@@ -132,7 +132,7 @@
- ``core-image-weston``: A very basic Wayland image with a terminal.
This image provides the Wayland protocol libraries and the reference
Weston compositor. For more information, see the
- ":ref:`dev-manual/dev-manual-common-tasks:using wayland and weston`"
+ ":ref:`dev-manual/common-tasks:using wayland and weston`"
section in the Yocto Project Development Tasks Manual.
- ``core-image-x11``: A very basic X11 image with a terminal.
diff --git a/poky/documentation/ref-manual/index.rst b/poky/documentation/ref-manual/index.rst
new file mode 100644
index 0000000..deb0383
--- /dev/null
+++ b/poky/documentation/ref-manual/index.rst
@@ -0,0 +1,31 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+==============================
+Yocto Project Reference Manual
+==============================
+
+|
+
+.. toctree::
+ :caption: Table of Contents
+ :numbered:
+
+ system-requirements
+ terms
+ release-process
+ migration
+ structure
+ classes
+ tasks
+ devtool-reference
+ kickstart
+ qa-checks
+ images
+ features
+ variables
+ varlocality
+ faq
+ resources
+ history
+
+.. include:: /boilerplate.rst
diff --git a/poky/documentation/ref-manual/ref-kickstart.rst b/poky/documentation/ref-manual/kickstart.rst
similarity index 98%
rename from poky/documentation/ref-manual/ref-kickstart.rst
rename to poky/documentation/ref-manual/kickstart.rst
index 7f6d4eb..bb9c046 100644
--- a/poky/documentation/ref-manual/ref-kickstart.rst
+++ b/poky/documentation/ref-manual/kickstart.rst
@@ -79,7 +79,7 @@
source of the data that populates the partition. The most common
value for this option is "rootfs", but you can use any value that
maps to a valid source plugin. For information on the source plugins,
- see the ":ref:`dev-manual/dev-manual-common-tasks:using the wic plugin interface`"
+ see the ":ref:`dev-manual/common-tasks:using the wic plugin interface`"
section in the Yocto Project Development Tasks Manual.
If you use ``--source rootfs``, Wic creates a partition as large as
diff --git a/poky/documentation/ref-manual/migration-1.3.rst b/poky/documentation/ref-manual/migration-1.3.rst
index 5f97585..12e225b 100644
--- a/poky/documentation/ref-manual/migration-1.3.rst
+++ b/poky/documentation/ref-manual/migration-1.3.rst
@@ -173,7 +173,7 @@
``meta-gnome``. For the remainder, you can now find them in the
``meta-extras`` repository, which is in the
:yocto_git:`Source Repositories <>` at
-:yocto_git:`/cgit/cgit.cgi/meta-extras/`.
+:yocto_git:`/meta-extras/`.
.. _1.3-linux-kernel-naming:
diff --git a/poky/documentation/ref-manual/migration-1.4.rst b/poky/documentation/ref-manual/migration-1.4.rst
index daaea0f..0b7e861 100644
--- a/poky/documentation/ref-manual/migration-1.4.rst
+++ b/poky/documentation/ref-manual/migration-1.4.rst
@@ -84,7 +84,7 @@
you can find in the :term:`Source Directory` at
``meta/recipes-core/init-ifupdown``. For information on how to use
append files, see the
-":ref:`dev-manual/dev-manual-common-tasks:using .bbappend files in your layer`"
+":ref:`dev-manual/common-tasks:using .bbappend files in your layer`"
section in the Yocto Project Development Tasks Manual.
.. _migration-1.4-remote-debugging:
diff --git a/poky/documentation/ref-manual/migration-1.5.rst b/poky/documentation/ref-manual/migration-1.5.rst
index fc7afac..2716bc9 100644
--- a/poky/documentation/ref-manual/migration-1.5.rst
+++ b/poky/documentation/ref-manual/migration-1.5.rst
@@ -26,7 +26,7 @@
tarball, which provides an SDK-like environment containing them.
For more information on this requirement, 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.
.. _migration-1.5-atom-pc-bsp:
@@ -181,7 +181,7 @@
The ``/run`` directory from the Filesystem Hierarchy Standard 3.0 has
been introduced. You can find some of the implications for this change
-`here <http://cgit.openembedded.org/openembedded-core/commit/?id=0e326280a15b0f2c4ef2ef4ec441f63f55b75873>`__.
+:oe_git:`here </openembedded-core/commit/?id=0e326280a15b0f2c4ef2ef4ec441f63f55b75873>`.
The change also means that recipes that install files to ``/var/run``
must be changed. You can find a guide on how to make these changes
`here <https://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg31649.html>`__.
@@ -246,7 +246,7 @@
framework replaces the older ``imagetest-qemu`` framework.
You can learn more about performing automated image tests in the
-":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`"
+":ref:`dev-manual/common-tasks:performing automated runtime testing`"
section in the Yocto Project Development Tasks Manual.
.. _migration-1.5-build-history:
@@ -269,7 +269,7 @@
option for each utility for more information on the new syntax.
For more information on Build History, see the
-":ref:`dev-manual/dev-manual-common-tasks:maintaining build output quality`"
+":ref:`dev-manual/common-tasks:maintaining build output quality`"
section in the Yocto Project Development Tasks Manual.
.. _migration-1.5-udev:
diff --git a/poky/documentation/ref-manual/migration-1.6.rst b/poky/documentation/ref-manual/migration-1.6.rst
index a6c4c8a..ed155d0 100644
--- a/poky/documentation/ref-manual/migration-1.6.rst
+++ b/poky/documentation/ref-manual/migration-1.6.rst
@@ -12,7 +12,7 @@
The :ref:`archiver <ref-classes-archiver>` class has been rewritten
and its configuration has been simplified. For more details on the
source archiver, 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.
.. _migration-1.6-packaging-changes:
@@ -126,7 +126,7 @@
--------------------
The following variables have changed. For information on the
-OpenEmbedded build system variables, see the ":doc:`ref-variables`" Chapter.
+OpenEmbedded build system variables, see the ":doc:`/ref-manual/variables`" Chapter.
.. _migration-1.6-variable-changes-TMPDIR:
@@ -148,7 +148,7 @@
The ``PRINC`` variable has been deprecated and triggers a warning if
detected during a build. For :term:`PR` increments on changes,
use the PR service instead. You can find out more about this service in
-the ":ref:`dev-manual/dev-manual-common-tasks:working with a pr service`"
+the ":ref:`dev-manual/common-tasks:working with a pr service`"
section in the Yocto Project Development Tasks Manual.
.. _migration-1.6-variable-changes-IMAGE_TYPES:
@@ -221,7 +221,7 @@
Package Tests (ptest) are built but not installed by default. For
information on using Package Tests, see the
-":ref:`dev-manual/dev-manual-common-tasks:testing packages with ptest`"
+":ref:`dev-manual/common-tasks:testing packages with ptest`"
section in the Yocto Project Development Tasks Manual. For information on the
``ptest`` class, see the ":ref:`ptest.bbclass <ref-classes-ptest>`"
section.
@@ -411,6 +411,6 @@
``routerstationpro`` machines are still available in a new
``meta-yocto-bsp-old`` layer in the
:yocto_git:`Source Repositories <>` at
-:yocto_git:`/cgit/cgit.cgi/meta-yocto-bsp-old/`.
+:yocto_git:`/meta-yocto-bsp-old/`.
diff --git a/poky/documentation/ref-manual/migration-1.7.rst b/poky/documentation/ref-manual/migration-1.7.rst
index 5a5151e..19275b3 100644
--- a/poky/documentation/ref-manual/migration-1.7.rst
+++ b/poky/documentation/ref-manual/migration-1.7.rst
@@ -26,13 +26,13 @@
Minimum Git version
-------------------
-The minimum :ref:`overview-manual/overview-manual-development-environment:git`
+The minimum :ref:`overview-manual/development-environment:git`
version required on the
build host is now 1.7.8 because the ``--list`` option is now required by
BitBake's Git fetcher. As always, if your host distribution does not
provide a version of Git that meets this requirement, you can use the
``buildtools-tarball`` that does. 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 for more information.
.. _migration-1.7-autotools-class-changes:
@@ -66,8 +66,8 @@
foreign mode themselves, the option is mostly superfluous. However,
some recipes will need patches for this change. You can easily make
the change by patching ``configure.ac`` so that it passes "foreign"
- to ``AM_INIT_AUTOMAKE()``. See `this
- commit <http://cgit.openembedded.org/openembedded-core/commit/?id=01943188f85ce6411717fb5bf702d609f55813f2>`__
+ to ``AM_INIT_AUTOMAKE()``. See :oe_git:`this
+ commit </openembedded-core/commit/?id=01943188f85ce6411717fb5bf702d609f55813f2>`
for an example showing how to make the patch.
.. _migration-1.7-binary-configuration-scripts-disabled:
@@ -157,7 +157,7 @@
added in order to verify that file dependencies are satisfied (e.g.
package contains a script requiring ``/bin/bash``) and build-time
dependencies are declared, respectively. For more information, please
- see the ":doc:`ref-qa-checks`" chapter.
+ see the ":doc:`/ref-manual/qa-checks`" chapter.
- Package QA checks are now performed during a new
:ref:`ref-tasks-package_qa` task rather than being
@@ -217,7 +217,7 @@
should manually remove old "build-id" files from your existing build
history repositories to avoid confusion. For information on the build
history feature, see the
- ":ref:`dev-manual/dev-manual-common-tasks:maintaining build output quality`"
+ ":ref:`dev-manual/common-tasks:maintaining build output quality`"
section in the Yocto Project Development Tasks Manual.
diff --git a/poky/documentation/ref-manual/migration-1.8.rst b/poky/documentation/ref-manual/migration-1.8.rst
index d601e6b..73789bd 100644
--- a/poky/documentation/ref-manual/migration-1.8.rst
+++ b/poky/documentation/ref-manual/migration-1.8.rst
@@ -79,7 +79,7 @@
inherit from ``kernel-yocto`` or include ``linux-yocto.inc``, you might
wish to refer to the ``linux.inc`` file in the ``meta-oe`` layer for the
kinds of changes you need to make. For reference, here is the
-`commit <http://cgit.openembedded.org/meta-openembedded/commit/meta-oe/recipes-kernel/linux/linux.inc?id=fc7132ede27ac67669448d3d2845ce7d46c6a1ee>`__
+:oe_git:`commit </meta-openembedded/commit/meta-oe/recipes-kernel/linux/linux.inc?id=fc7132ede27ac67669448d3d2845ce7d46c6a1ee>`
where the ``linux.inc`` file in ``meta-oe`` was updated.
Recipes that rely on the kernel source code and do not inherit the
diff --git a/poky/documentation/ref-manual/migration-2.1.rst b/poky/documentation/ref-manual/migration-2.1.rst
index 0220221..e8b3ada 100644
--- a/poky/documentation/ref-manual/migration-2.1.rst
+++ b/poky/documentation/ref-manual/migration-2.1.rst
@@ -217,7 +217,7 @@
- *Hob GTK+-based UI*: Removed because it is unmaintained and based on
the outdated GTK+ 2 library. The Toaster web-based UI is much more
capable and is actively maintained. See the
- ":ref:`toaster-manual/toaster-manual-setup-and-use:using the toaster web interface`"
+ ":ref:`toaster-manual/setup-and-use:using the toaster web interface`"
section in the Toaster User Manual for more information on this
interface.
@@ -231,10 +231,10 @@
The Application Development Toolkit (ADT) has been removed because its
functionality almost completely overlapped with the :ref:`standard
-SDK <sdk-manual/sdk-using:using the standard sdk>` and the
-:ref:`extensible SDK <sdk-manual/sdk-extensible:using the extensible sdk>`. For
+SDK <sdk-manual/using:using the standard sdk>` and the
+:ref:`extensible SDK <sdk-manual/extensible:using the extensible sdk>`. For
information on these SDKs and how to build and use them, see the
-:doc:`../sdk-manual/sdk-manual` manual.
+:doc:`/sdk-manual/index` manual.
.. note::
@@ -346,7 +346,7 @@
files through GObject introspection, which is the standard mechanism for
accessing GObject-based software from runtime environments. You can
enable, disable, and test the generation of this data. See the
-":ref:`dev-manual/dev-manual-common-tasks:enabling gobject introspection support`"
+":ref:`dev-manual/common-tasks:enabling gobject introspection support`"
section in the Yocto Project Development Tasks Manual for more
information.
@@ -360,7 +360,7 @@
- The minimum Git version has been increased to 1.8.3.1. If your host
distribution does not provide a sufficiently recent version, you can
install the buildtools, which will provide it. 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 for more information on the buildtools tarball.
- The buggy and incomplete support for the RPM version 4 package
@@ -386,7 +386,7 @@
removed at runtime).
- The
- :ref:`devtool modify <sdk-manual/sdk-extensible:use \`\`devtool modify\`\` to modify the source of an existing component>`
+ :ref:`devtool modify <sdk-manual/extensible:use \`\`devtool modify\`\` to modify the source of an existing component>`
command now defaults to extracting the source since that is most
commonly expected. The "-x" or "--extract" options are now no-ops. If
you wish to provide your own existing source tree, you will now need
diff --git a/poky/documentation/ref-manual/migration-2.2.rst b/poky/documentation/ref-manual/migration-2.2.rst
index 8afa8ff..ac247dc 100644
--- a/poky/documentation/ref-manual/migration-2.2.rst
+++ b/poky/documentation/ref-manual/migration-2.2.rst
@@ -292,9 +292,9 @@
functionality. These changes will affect external tools that use
BitBake's tinfoil module. For information on these changes, see the
changes made to the scripts supplied with OpenEmbedded-Core:
- `1 <http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=189371f8393971d00bca0fceffd67cc07784f6ee>`__
+ :yocto_git:`1 </poky/commit/?id=189371f8393971d00bca0fceffd67cc07784f6ee>`
and
- `2 <http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=4a5aa7ea4d07c2c90a1654b174873abb018acc67>`__.
+ :yocto_git:`2 </poky/commit/?id=4a5aa7ea4d07c2c90a1654b174873abb018acc67>`.
- The task management code has been rewritten to avoid using ID
indirection in order to improve performance. This change is unlikely
diff --git a/poky/documentation/ref-manual/migration-2.3.rst b/poky/documentation/ref-manual/migration-2.3.rst
index 5bf3e70..3e97581 100644
--- a/poky/documentation/ref-manual/migration-2.3.rst
+++ b/poky/documentation/ref-manual/migration-2.3.rst
@@ -51,7 +51,7 @@
:term:`SYSROOT_PREPROCESS_FUNCS`.
For an example, see the ``pixbufcache`` class in ``meta/classes/`` in
- the :ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`.
+ the :ref:`overview-manual/development-environment:yocto project source repositories`.
.. note::
@@ -198,7 +198,7 @@
fetcher passes the new parameter through the ``SVN_SSH`` environment
variable during the :ref:`ref-tasks-fetch` task.
- See the ":ref:`bitbake:svn-fetcher`"
+ See the ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-fetching:subversion (svn) fetcher (\`\`svn://\`\`)`"
section in the BitBake
User Manual for additional information.
@@ -323,7 +323,7 @@
.. note::
For further details on this change, see the
- :yocto_git:`commit message </cgit/cgit.cgi/poky/commit/?id=f4d4f99cfbc2396e49c1613a7d237b9e57f06f81>`.
+ :yocto_git:`commit message </poky/commit/?id=f4d4f99cfbc2396e49c1613a7d237b9e57f06f81>`.
.. _migration-2.3-removed-recipes:
@@ -366,7 +366,7 @@
.. note::
For more information on Wic, see the
- ":ref:`dev-manual/dev-manual-common-tasks:creating partitioned images using wic`"
+ ":ref:`dev-manual/common-tasks:creating partitioned images using wic`"
section in the Yocto Project Development Tasks Manual.
- *Default Output Directory Changed:* Wic's default output directory is
@@ -404,7 +404,7 @@
For additional information, see the
:ref:`insane <ref-classes-insane>` class and the
- ":ref:`ref-manual/ref-qa-checks:errors and warnings`" section.
+ ":ref:`ref-manual/qa-checks:errors and warnings`" section.
.. _migration-2.3-miscellaneous-changes:
diff --git a/poky/documentation/ref-manual/migration-2.5.rst b/poky/documentation/ref-manual/migration-2.5.rst
index 1aeddc8..9f45ffc 100644
--- a/poky/documentation/ref-manual/migration-2.5.rst
+++ b/poky/documentation/ref-manual/migration-2.5.rst
@@ -180,7 +180,7 @@
The earlier build-time provides behavior was a quirk of the
way the Python manifest file was created. For more information on this
change please see :yocto_git:`this commit
-</cgit/cgit.cgi/poky/commit/?id=8d94b9db221d1def42f091b991903faa2d1651ce>`.
+</poky/commit/?id=8d94b9db221d1def42f091b991903faa2d1651ce>`.
.. _migration-2.5-miscellaneous-changes:
@@ -266,7 +266,7 @@
will trigger a warning during ``do_rootfs``.
For more information, see the
- ":ref:`dev-manual/dev-manual-common-tasks:post-installation scripts`"
+ ":ref:`dev-manual/common-tasks:post-installation scripts`"
section in the Yocto Project Development Tasks Manual.
- The ``elf`` image type has been removed. This image type was removed
@@ -293,8 +293,8 @@
- Patches whose context does not match exactly (i.e. where patch
reports "fuzz" when applying) will generate a warning. For an example
- of this see `this
- commit <http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=cc97bc08125b63821ce3f616771830f77c456f57>`__.
+ of this see :yocto_git:`this commit
+ </poky/commit/?id=cc97bc08125b63821ce3f616771830f77c456f57>`.
- Layers are expected to set ``LAYERSERIES_COMPAT_layername`` to match
the version(s) of OpenEmbedded-Core they are compatible with. This is
diff --git a/poky/documentation/ref-manual/migration-2.6.rst b/poky/documentation/ref-manual/migration-2.6.rst
index 2f0da48..5d524f3 100644
--- a/poky/documentation/ref-manual/migration-2.6.rst
+++ b/poky/documentation/ref-manual/migration-2.6.rst
@@ -278,7 +278,7 @@
specifying list items to remove, be aware that leading and trailing
whitespace resulting from the removal is retained.
- See the ":ref:`bitbake:removing-override-style-syntax`"
+ See the ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:removal (override style syntax)`"
section in the BitBake User Manual for a detailed example.
.. _migration-2.6-systemd-configuration-now-split-out-to-system-conf:
@@ -372,7 +372,7 @@
an error during the :ref:`ref-tasks-rootfs` task.
For more information on post-installation behavior, see the
-":ref:`dev-manual/dev-manual-common-tasks:post-installation scripts`"
+":ref:`dev-manual/common-tasks:post-installation scripts`"
section in the Yocto Project Development Tasks Manual.
.. _migration-2.6-python-3-profile-guided-optimizations:
diff --git a/poky/documentation/ref-manual/migration-3.0.rst b/poky/documentation/ref-manual/migration-3.0.rst
index 047b755..7ef2742 100644
--- a/poky/documentation/ref-manual/migration-3.0.rst
+++ b/poky/documentation/ref-manual/migration-3.0.rst
@@ -197,7 +197,7 @@
- The arguments passed to functions used with
:term:`bitbake:BB_HASHCHECK_FUNCTION`
have changed. If you are using your own custom hash check function,
- see :yocto_git:`/cgit/cgit.cgi/poky/commit/?id=40a5e193c4ba45c928fccd899415ea56b5417725`
+ see :yocto_git:`/poky/commit/?id=40a5e193c4ba45c928fccd899415ea56b5417725`
for details.
- Task specifications in ``BB_TASKDEPDATA`` and class implementations
diff --git a/poky/documentation/ref-manual/migration-3.2.rst b/poky/documentation/ref-manual/migration-3.2.rst
index 9b65e26..65a9ff4 100644
--- a/poky/documentation/ref-manual/migration-3.2.rst
+++ b/poky/documentation/ref-manual/migration-3.2.rst
@@ -71,7 +71,7 @@
In addition, pseudo's behaviour on mismatches has now been changed - rather
than doing what turns out to be a rather dangerous "fixup" if it sees a file
with a different path but the same inode as another file it has previously seen,
-pseudo will throw an ``abort()`` and direct you to a :yocto_wiki:`wiki page </wiki/Pseudo_Abort>`
+pseudo will throw an ``abort()`` and direct you to a :yocto_wiki:`wiki page </Pseudo_Abort>`
that explains how to deal with this.
diff --git a/poky/documentation/ref-manual/ref-qa-checks.rst b/poky/documentation/ref-manual/qa-checks.rst
similarity index 100%
rename from poky/documentation/ref-manual/ref-qa-checks.rst
rename to poky/documentation/ref-manual/qa-checks.rst
diff --git a/poky/documentation/ref-manual/ref-manual.rst b/poky/documentation/ref-manual/ref-manual.rst
deleted file mode 100644
index 033f4ba..0000000
--- a/poky/documentation/ref-manual/ref-manual.rst
+++ /dev/null
@@ -1,31 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
-
-==============================
-Yocto Project Reference Manual
-==============================
-
-|
-
-.. toctree::
- :caption: Table of Contents
- :numbered:
-
- ref-system-requirements
- ref-terms
- ref-release-process
- migration
- ref-structure
- ref-classes
- ref-tasks
- ref-devtool-reference
- ref-kickstart
- ref-qa-checks
- ref-images
- ref-features
- ref-variables
- ref-varlocality
- faq
- resources
- history
-
-.. include:: /boilerplate.rst
diff --git a/poky/documentation/ref-manual/ref-release-process.rst b/poky/documentation/ref-manual/release-process.rst
similarity index 93%
rename from poky/documentation/ref-manual/ref-release-process.rst
rename to poky/documentation/ref-manual/release-process.rst
index a6d9ff6..d8d3622 100644
--- a/poky/documentation/ref-manual/ref-release-process.rst
+++ b/poky/documentation/ref-manual/release-process.rst
@@ -50,7 +50,7 @@
=======================
Each major release receives a codename that identifies the release in
-the :ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`.
+the :ref:`overview-manual/development-environment:yocto project source repositories`.
The concept is that branches of :term:`Metadata` with the same
codename are likely to be compatible and thus work together.
@@ -64,7 +64,7 @@
Releases are given a nominal release version as well but the codename is
used in repositories for this reason. You can find information on Yocto
Project releases and codenames at
-:yocto_wiki:`/wiki/Releases`.
+:yocto_wiki:`/Releases`.
Stable Release Process
======================
@@ -94,7 +94,7 @@
patches for older releases. However, these types of patches do not go
through the same release process as do point releases. You can find more
information about stable branch maintenance at
-:yocto_wiki:`/wiki/Stable_branch_maintenance`.
+:yocto_wiki:`/Stable_branch_maintenance`.
Testing and Quality Assurance
=============================
@@ -106,7 +106,7 @@
developer, you can validate your projects. This section overviews the
available test infrastructure used in the Yocto Project. For information
on how to run available tests on your projects, see the
-":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`"
+":ref:`dev-manual/common-tasks:performing automated runtime testing`"
section in the Yocto Project Development Tasks Manual.
The QA/testing infrastructure is woven into the project to the point
@@ -128,12 +128,12 @@
- :ref:`testimage.bbclass <ref-classes-testimage*>`: This class
performs runtime testing of images after they are built. The tests
- are usually used with :doc:`QEMU <../dev-manual/dev-manual-qemu>`
+ are usually used with :doc:`QEMU </dev-manual/qemu>`
to boot the images and check the combined runtime result boot
operation and functions. However, the test can also use the IP
address of a machine to test.
-- :ref:`ptest <dev-manual/dev-manual-common-tasks:testing packages with ptest>`:
+- :ref:`ptest <dev-manual/common-tasks:testing packages with ptest>`:
Runs tests against packages produced during the build for a given
piece of software. The test allows the packages to be be run within a
target image.
@@ -146,7 +146,7 @@
.. note::
Running ``oe-selftest`` requires host packages beyond the "Essential"
- grouping. See the :ref:`ref-manual/ref-system-requirements:required packages for the build host`
+ grouping. See the :ref:`ref-manual/system-requirements:required packages for the build host`
section for more information.
Originally, much of this testing was done manually. However, significant
diff --git a/poky/documentation/ref-manual/resources.rst b/poky/documentation/ref-manual/resources.rst
index 2ef182f..77c3678 100644
--- a/poky/documentation/ref-manual/resources.rst
+++ b/poky/documentation/ref-manual/resources.rst
@@ -23,7 +23,7 @@
to the project either by creating and sending pull requests, or by
submitting patches through email. For information on how to do both as
well as information on how to identify the maintainer for each area of
-code, see the ":ref:`how-to-submit-a-change`" section in the
+code, see the ":ref:`dev-manual/common-tasks:submitting a change to the yocto project`" section in the
Yocto Project Development Tasks Manual.
.. _resources-bugtracker:
@@ -47,10 +47,10 @@
submit a bug. For information on how to use Bugzilla to submit a bug
against the Yocto Project, see the following:
-- The ":ref:`dev-manual/dev-manual-common-tasks:submitting a defect against the yocto project`"
+- The ":ref:`dev-manual/common-tasks:submitting a defect against the yocto project`"
section in the Yocto Project Development Tasks Manual.
-- The Yocto Project :yocto_wiki:`Bugzilla wiki page </wiki/Bugzilla_Configuration_and_Bug_Tracking>`
+- The Yocto Project :yocto_wiki:`Bugzilla wiki page </Bugzilla_Configuration_and_Bug_Tracking>`
For information on Bugzilla in general, see http://www.bugzilla.org/about/.
@@ -108,7 +108,7 @@
- :yocto_home:`The Yocto Project Website <>`\ *:* The home site
for the Yocto Project.
-- :yocto_wiki:`The Yocto Project Main Wiki Page </wiki/Main_Page>`\ *:* The main wiki page for
+- :yocto_wiki:`The Yocto Project Main Wiki Page <>`\ *:* The main wiki page for
the Yocto Project. This page contains information about project
planning, release engineering, QA & automation, a reference site map,
and other resources related to the Yocto Project.
@@ -125,33 +125,33 @@
guide to the BitBake tool. If you want information on BitBake, see
this manual.
-- :doc:`../brief-yoctoprojectqs/brief-yoctoprojectqs` *:* This
+- :doc:`/brief-yoctoprojectqs/index` *:* This
short document lets you experience building an image using the Yocto
Project without having to understand any concepts or details.
-- :doc:`../overview-manual/overview-manual` *:* This manual provides overview
+- :doc:`/overview-manual/index` *:* This manual provides overview
and conceptual information about the Yocto Project.
-- :doc:`../dev-manual/dev-manual` *:* This manual is a "how-to" guide
+- :doc:`/dev-manual/index` *:* This manual is a "how-to" guide
that presents procedures useful to both application and system
developers who use the Yocto Project.
-- :doc:`../sdk-manual/sdk-manual` *manual :* This
+- :doc:`/sdk-manual/index` *manual :* This
guide provides information that lets you get going with the standard
or extensible SDK. An SDK, with its cross-development toolchains,
allows you to develop projects inside or outside of the Yocto Project
environment.
-- :doc:`../bsp-guide/bsp` *:* This guide defines the structure
+- :doc:`/bsp-guide/bsp` *:* This guide defines the structure
for BSP components. Having a commonly understood structure encourages
standardization.
-- :doc:`../kernel-dev/kernel-dev` *:* This manual describes
+- :doc:`/kernel-dev/index` *:* This manual describes
how to work with Linux Yocto kernels as well as provides a bit of
conceptual information on the construction of the Yocto Linux kernel
tree.
-- :doc:`../ref-manual/ref-manual` *:* This
+- :doc:`/ref-manual/index` *:* This
manual provides reference material such as variable, task, and class
descriptions.
@@ -161,17 +161,17 @@
which you can easily search for phrases and terms used in the Yocto
Project documentation set.
-- :doc:`../profile-manual/profile-manual` *:* This manual presents a set of
+- :doc:`/profile-manual/index` *:* This manual presents a set of
common and generally useful tracing and profiling schemes along with
their applications (as appropriate) to each tool.
-- :doc:`../toaster-manual/toaster-manual` *:* This manual
+- :doc:`/toaster-manual/index` *:* This manual
introduces and describes how to set up and use Toaster. Toaster is an
Application Programming Interface (API) and web-based interface to
the :term:`OpenEmbedded Build System`, which uses
BitBake, that reports build information.
-- :yocto_wiki:`FAQ </wiki/FAQ>`\ *:* A list of commonly asked
+- :yocto_wiki:`FAQ </FAQ>`\ *:* A list of commonly asked
questions and their answers.
- *Release Notes:* Features, updates and known issues for the current
@@ -184,7 +184,8 @@
the Yocto Project uses. If you find problems with the Yocto Project,
you should report them using this application.
-- :yocto_wiki:`Bugzilla Configuration and Bug Tracking Wiki Page </wiki/Bugzilla_Configuration_and_Bug_Tracking>`\ *:*
+- :yocto_wiki:`Bugzilla Configuration and Bug Tracking Wiki Page
+ </Bugzilla_Configuration_and_Bug_Tracking>`\ *:*
Information on how to get set up and use the Yocto Project
implementation of Bugzilla for logging and tracking Yocto Project
defects.
diff --git a/poky/documentation/ref-manual/ref-structure.rst b/poky/documentation/ref-manual/structure.rst
similarity index 96%
rename from poky/documentation/ref-manual/ref-structure.rst
rename to poky/documentation/ref-manual/structure.rst
index db1ea97..ad3f4ab 100644
--- a/poky/documentation/ref-manual/ref-structure.rst
+++ b/poky/documentation/ref-manual/structure.rst
@@ -12,7 +12,7 @@
For information on how to establish a local Source Directory on your
development system, 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.
.. note::
@@ -104,7 +104,7 @@
This directory contains the Yocto Project reference hardware Board
Support Packages (BSPs). For more information on BSPs, see the
-:doc:`../bsp-guide/bsp-guide`.
+:doc:`/bsp-guide/index`.
.. _structure-meta-selftest:
@@ -176,7 +176,7 @@
custom distribution, you can include your own version of this
configuration file to mention the targets defined by your distribution.
See the
-":ref:`dev-manual/dev-manual-common-tasks:creating a custom template configuration directory`"
+":ref:`dev-manual/common-tasks:creating a custom template configuration directory`"
section in the Yocto Project Development Tasks Manual for more
information.
@@ -193,7 +193,7 @@
The OpenEmbedded build system uses the template configuration files, which
are found by default in the ``meta-poky/conf/`` directory in the Source
Directory. See the
-":ref:`dev-manual/dev-manual-common-tasks:creating a custom template configuration directory`"
+":ref:`dev-manual/common-tasks:creating a custom template configuration directory`"
section in the Yocto Project Development Tasks Manual for more
information.
@@ -236,7 +236,7 @@
build history via the ``buildhistory`` class file. The directory
organizes build information into image, packages, and SDK
subdirectories. For information on the build history feature, see the
-":ref:`dev-manual/dev-manual-common-tasks:maintaining build output quality`"
+":ref:`dev-manual/common-tasks:maintaining build output quality`"
section in the Yocto Project Development Tasks Manual.
.. _structure-build-conf-local.conf:
@@ -292,7 +292,7 @@
----------------------------
This configuration file defines
-:ref:`layers <dev-manual/dev-manual-common-tasks:understanding and creating layers>`,
+:ref:`layers <dev-manual/common-tasks:understanding and creating layers>`,
which are directory trees, traversed (or walked) by BitBake. The
``bblayers.conf`` file uses the :term:`BBLAYERS`
variable to list the layers BitBake tries to find.
@@ -399,8 +399,8 @@
build process. The :term:`DEPLOY_DIR` variable points
to this directory. For more detail on the contents of the ``deploy``
directory, see the
-":ref:`images-dev-environment`" and
-":ref:`sdk-dev-environment`" sections in the Yocto
+":ref:`overview-manual/concepts:images`" and
+":ref:`overview-manual/concepts:application development sdk`" sections in the Yocto
Project Overview and Concepts Manual.
.. _structure-build-tmp-deploy-deb:
@@ -438,7 +438,7 @@
``glibc`` (among others) that in turn contain appropriate ``COPYING``
license files with other licensing information. For information on
licensing, 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.
.. _structure-build-tmp-deploy-images:
@@ -477,7 +477,7 @@
The OpenEmbedded build system creates this directory to hold toolchain
installer scripts which, when executed, install the sysroot that matches
your target hardware. You can find out more about these installers in
-the ":ref:`sdk-manual/sdk-appendix-obtain:building an sdk installer`"
+the ":ref:`sdk-manual/appendix-obtain:building an sdk installer`"
section in the Yocto Project Application Development and the Extensible
Software Development Kit (eSDK) manual.
@@ -545,7 +545,7 @@
For information on how BitBake uses stamp files to determine if a task
should be rerun, 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.
.. _structure-build-tmp-log:
@@ -577,7 +577,7 @@
``tmp/work/qemux86-poky-linux/linux-yocto/3.0+git1+<.....>``, referred
to as the ``WORKDIR``, is created. Within this directory, the source is
unpacked to ``linux-qemux86-standard-build`` and then patched by Quilt.
-(See the ":ref:`using-a-quilt-workflow`" section in
+(See the ":ref:`dev-manual/common-tasks:using quilt in your workflow`" section in
the Yocto Project Development Tasks Manual for more information.) Within
the ``linux-qemux86-standard-build`` directory, standard Quilt
directories ``linux-3.0/patches`` and ``linux-3.0/.pc`` are created, and
@@ -682,7 +682,7 @@
``image.bbclass``, ``rootfs_*.bbclass`` and ``package*.bbclass``.
For reference information on classes, see the
-":ref:`ref-manual/ref-classes:Classes`" chapter.
+":ref:`ref-manual/classes:Classes`" chapter.
.. _structure-meta-conf:
diff --git a/poky/documentation/ref-manual/ref-system-requirements.rst b/poky/documentation/ref-manual/system-requirements.rst
similarity index 96%
rename from poky/documentation/ref-manual/ref-system-requirements.rst
rename to poky/documentation/ref-manual/system-requirements.rst
index fe7c925..66afb08 100644
--- a/poky/documentation/ref-manual/ref-system-requirements.rst
+++ b/poky/documentation/ref-manual/system-requirements.rst
@@ -15,14 +15,14 @@
For introductory information on the Yocto Project, see the
:yocto_home:`Yocto Project Website <>` and the
-":ref:`overview-manual/overview-manual-development-environment:the yocto project development environment`"
+":ref:`overview-manual/development-environment:the yocto project development environment`"
chapter in the Yocto Project Overview and Concepts Manual.
If you want to use the Yocto Project to quickly build an image without
having to understand concepts, work through the
-:doc:`../brief-yoctoprojectqs/brief-yoctoprojectqs` document. You can find "how-to"
-information in the :doc:`../dev-manual/dev-manual`. You can find Yocto Project overview
-and conceptual information in the :doc:`../overview-manual/overview-manual`.
+:doc:`/brief-yoctoprojectqs/index` document. You can find "how-to"
+information in the :doc:`/dev-manual/index`. You can find Yocto Project overview
+and conceptual information in the :doc:`/overview-manual/index`.
.. note::
@@ -93,8 +93,8 @@
Bugzilla <>` and submit a bug. We are
interested in hearing about your experience. For information on
how to submit a bug, see the Yocto Project
- :yocto_wiki:`Bugzilla wiki page </wiki/Bugzilla_Configuration_and_Bug_Tracking>`
- and the ":ref:`dev-manual/dev-manual-common-tasks:submitting a defect against the yocto project`"
+ :yocto_wiki:`Bugzilla wiki page </Bugzilla_Configuration_and_Bug_Tracking>`
+ and the ":ref:`dev-manual/common-tasks:submitting a defect against the yocto project`"
section in the Yocto Project Development Tasks Manual.
diff --git a/poky/documentation/ref-manual/ref-tasks.rst b/poky/documentation/ref-manual/tasks.rst
similarity index 92%
rename from poky/documentation/ref-manual/ref-tasks.rst
rename to poky/documentation/ref-manual/tasks.rst
index 9ef0141..9fe1c29 100644
--- a/poky/documentation/ref-manual/ref-tasks.rst
+++ b/poky/documentation/ref-manual/tasks.rst
@@ -122,7 +122,7 @@
Fetches the source code. This task uses the
:term:`SRC_URI` variable and the argument's prefix to
-determine the correct :ref:`fetcher <bitbake:bb-fetchers>`
+determine the correct :ref:`fetcher <bitbake:bitbake-user-manual/bitbake-user-manual-fetching:fetchers>`
module.
.. _ref-tasks-image:
@@ -140,7 +140,7 @@
:term:`IMAGE_PREPROCESS_COMMAND` and
dynamically generates supporting ``do_image_*`` tasks as needed.
-For more information on image creation, see the ":ref:`image-generation-dev-environment`"
+For more information on image creation, see the ":ref:`overview-manual/concepts:image generation`"
section in the Yocto Project Overview and Concepts Manual.
.. _ref-tasks-image-complete:
@@ -159,7 +159,7 @@
:term:`IMAGE_POSTPROCESS_COMMAND`.
For more information on image creation, see the
-":ref:`image-generation-dev-environment`"
+":ref:`overview-manual/concepts:image generation`"
section in the Yocto Project Overview and Concepts Manual.
.. _ref-tasks-install:
@@ -174,7 +174,7 @@
that either directly or indirectly depend on the installed files (e.g.
:ref:`ref-tasks-package`, ``do_package_write_*``, and
:ref:`ref-tasks-rootfs`), run under
-:ref:`fakeroot <overview-manual/overview-manual-concepts:fakeroot and pseudo>`.
+:ref:`fakeroot <overview-manual/concepts:fakeroot and pseudo>`.
.. note::
@@ -218,7 +218,7 @@
:ref:`ref-tasks-packagedata` task, also saves some
important package metadata. For additional information, see the
:term:`PKGDESTWORK` variable and 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.
.. _ref-tasks-package_qa:
@@ -237,7 +237,7 @@
Creates Debian packages (i.e. ``*.deb`` files) and places them in the
``${``\ :term:`DEPLOY_DIR_DEB`\ ``}`` directory in
the package feeds area. For more information, see the
-":ref:`package-feeds-dev-environment`" section in
+":ref:`overview-manual/concepts:package feeds`" section in
the Yocto Project Overview and Concepts Manual.
.. _ref-tasks-package_write_ipk:
@@ -248,7 +248,7 @@
Creates IPK packages (i.e. ``*.ipk`` files) and places them in the
``${``\ :term:`DEPLOY_DIR_IPK`\ ``}`` directory in
the package feeds area. For more information, see the
-":ref:`package-feeds-dev-environment`" section in
+":ref:`overview-manual/concepts:package feeds`" section in
the Yocto Project Overview and Concepts Manual.
.. _ref-tasks-package_write_rpm:
@@ -259,7 +259,7 @@
Creates RPM packages (i.e. ``*.rpm`` files) and places them in the
``${``\ :term:`DEPLOY_DIR_RPM`\ ``}`` directory in
the package feeds area. For more information, see the
-":ref:`package-feeds-dev-environment`" section in
+":ref:`overview-manual/concepts:package feeds`" section in
the Yocto Project Overview and Concepts Manual.
.. _ref-tasks-package_write_tar:
@@ -270,7 +270,7 @@
Creates tarballs and places them in the
``${``\ :term:`DEPLOY_DIR_TAR`\ ``}`` directory in
the package feeds area. For more information, see the
-":ref:`package-feeds-dev-environment`" section in
+":ref:`overview-manual/concepts:package feeds`" section in
the Yocto Project Overview and Concepts Manual.
.. _ref-tasks-packagedata:
@@ -301,7 +301,7 @@
Patch files, by default, are ``*.patch`` and ``*.diff`` files created
and kept in a subdirectory of the directory holding the recipe file. For
example, consider the
-:yocto_git:`bluez5 </cgit/cgit.cgi/poky/tree/meta/recipes-connectivity/bluez5>`
+:yocto_git:`bluez5 </poky/tree/meta/recipes-connectivity/bluez5>`
recipe from the OE-Core layer (i.e. ``poky/meta``):
::
@@ -349,9 +349,9 @@
applied as a patch by default except for the ``patch_file5`` patch.
You can find out more about the patching process in the
-":ref:`patching-dev-environment`" section in
+":ref:`overview-manual/concepts:patching`" section in
the Yocto Project Overview and Concepts Manual and the
-":ref:`new-recipe-patching-code`" section in the
+":ref:`dev-manual/common-tasks:patching code`" section in the
Yocto Project Development Tasks Manual.
.. _ref-tasks-populate_lic:
@@ -368,7 +368,7 @@
-------------------
Creates the file and directory structure for an installable SDK. See the
-":ref:`sdk-generation-dev-environment`"
+":ref:`overview-manual/concepts:sdk generation`"
section in the Yocto Project Overview and Concepts Manual for more
information.
@@ -378,7 +378,7 @@
-----------------------
Creates the file and directory structure for an installable extensible
-SDK (eSDK). See the ":ref:`sdk-generation-dev-environment`"
+SDK (eSDK). See the ":ref:`overview-manual/concepts:sdk generation`"
section in the Yocto Project Overview and Concepts Manual for more
information.
@@ -434,7 +434,7 @@
``${``\ :term:`WORKDIR`\ ``}``. The :term:`S`
variable also plays a role in where unpacked source files ultimately
reside. For more information on how source files are unpacked, see the
-":ref:`source-fetching-dev-environment`"
+":ref:`overview-manual/concepts:source fetching`"
section in the Yocto Project Overview and Concepts Manual and also see
the ``WORKDIR`` and ``S`` variable descriptions.
@@ -461,7 +461,7 @@
$ devtool latest-version
$ devtool check-upgrade-status
-See the ":ref:`ref-manual/ref-devtool-reference:\`\`devtool\`\` quick reference`"
+See the ":ref:`ref-manual/devtool-reference:\`\`devtool\`\` quick reference`"
chapter for more information on
``devtool``. See the ":ref:`devtool-checking-on-the-upgrade-status-of-a-recipe`"
section for information on checking the upgrade status of a recipe.
@@ -500,7 +500,7 @@
$ bitbake -c clean recipe
Running this task does not remove the
-:ref:`sstate <overview-manual/overview-manual-concepts:shared state cache>` cache files.
+:ref:`sstate <overview-manual/concepts:shared state cache>` cache files.
Consequently, if no changes have been made and the recipe is rebuilt
after cleaning, output files are simply restored from the sstate cache.
If you want to remove the sstate cache files for the recipe, you need to
@@ -513,7 +513,7 @@
---------------
Removes all output files, shared state
-(:ref:`sstate <overview-manual/overview-manual-concepts:shared state cache>`) cache, and
+(:ref:`sstate <overview-manual/concepts:shared state cache>`) cache, and
downloaded source files for a target (i.e. the contents of
:term:`DL_DIR`). Essentially, the ``do_cleanall`` task is
identical to the :ref:`ref-tasks-cleansstate` task
@@ -534,10 +534,10 @@
------------------
Removes all output files and shared state
-(:ref:`sstate <overview-manual/overview-manual-concepts:shared state cache>`) cache for a
+(:ref:`sstate <overview-manual/concepts:shared state cache>`) cache for a
target. Essentially, the ``do_cleansstate`` task is identical to the
:ref:`ref-tasks-clean` task with the added removal of
-shared state (:ref:`sstate <overview-manual/overview-manual-concepts:shared state cache>`)
+shared state (:ref:`sstate <overview-manual/concepts:shared state cache>`)
cache.
You can run this task using BitBake as follows:
@@ -567,7 +567,7 @@
Starts a shell in which an interactive Python interpreter allows you to
interact with the BitBake build environment. From within this shell, you
can directly examine and set bits from the data store and execute
-functions as if within the BitBake environment. See the ":ref:`platdev-appdev-devpyshell`" section in
+functions as if within the BitBake environment. See the ":ref:`dev-manual/common-tasks:using a development python shell`" section in
the Yocto Project Development Tasks Manual for more information about
using ``devpyshell``.
@@ -577,7 +577,7 @@
---------------
Starts a shell whose environment is set up for development, debugging,
-or both. See the ":ref:`platdev-appdev-devshell`" section in the
+or both. See the ":ref:`dev-manual/common-tasks:using a development shell`" section in the
Yocto Project Development Tasks Manual for more information about using
``devshell``.
@@ -593,7 +593,7 @@
``do_package_index``
--------------------
-Creates or updates the index in the :ref:`package-feeds-dev-environment` area.
+Creates or updates the index in the :ref:`overview-manual/concepts:package feeds` area.
.. note::
@@ -631,7 +631,7 @@
-------------
Creates the root filesystem (file and directory structure) for an image.
-See the ":ref:`image-generation-dev-environment`"
+See the ":ref:`overview-manual/concepts:image generation`"
section in the Yocto Project Overview and Concepts Manual for more
information on how the root filesystem is created.
@@ -642,7 +642,7 @@
Boots an image and performs runtime tests within the image. For
information on automatically testing images, see the
-":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`"
+":ref:`dev-manual/common-tasks:performing automated runtime testing`"
section in the Yocto Project Development Tasks Manual.
.. _ref-tasks-testimage_auto:
@@ -655,7 +655,7 @@
:term:`TESTIMAGE_AUTO` equal to "1".
For information on automatically testing images, see the
-":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`"
+":ref:`dev-manual/common-tasks:performing automated runtime testing`"
section in the Yocto Project Development Tasks Manual.
Kernel-Related Tasks
@@ -693,7 +693,7 @@
$ bitbake linux-yocto -c diffconfig
For more information, 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.
.. _ref-tasks-kernel_checkout:
@@ -724,7 +724,7 @@
$ bitbake linux-yocto -c kernel_configcheck -f
For more information, see the
-":ref:`kernel-dev/kernel-dev-common:validating configuration`"
+":ref:`kernel-dev/common:validating configuration`"
section in the Yocto Project Linux Kernel Development Manual.
.. _ref-tasks-kernel_configme:
@@ -756,7 +756,7 @@
$ bitbake linux-yocto -c menuconfig
-See the ":ref:`kernel-dev/kernel-dev-common:using \`\`menuconfig\`\``"
+See the ":ref:`kernel-dev/common:using \`\`menuconfig\`\``"
section in the Yocto Project Linux Kernel Development Manual for more
information on this configuration tool.
@@ -780,7 +780,7 @@
Runs ``make menuconfig`` for the kernel. For information on
``menuconfig``, see the
-":ref:`kernel-dev/kernel-dev-common:using \`\`menuconfig\`\``"
+":ref:`kernel-dev/common:using \`\`menuconfig\`\``"
section in the Yocto Project Linux Kernel Development Manual.
.. _ref-tasks-savedefconfig:
diff --git a/poky/documentation/ref-manual/ref-terms.rst b/poky/documentation/ref-manual/terms.rst
similarity index 92%
rename from poky/documentation/ref-manual/ref-terms.rst
rename to poky/documentation/ref-manual/terms.rst
index b4ceebc..c07dd4b 100644
--- a/poky/documentation/ref-manual/ref-terms.rst
+++ b/poky/documentation/ref-manual/terms.rst
@@ -21,7 +21,7 @@
Information in append files extends or overrides the information in the
similarly-named recipe file. For an example of an append file in use, see
- the ":ref:`dev-manual/dev-manual-common-tasks:Using .bbappend Files in
+ the ":ref:`dev-manual/common-tasks:Using .bbappend Files in
Your Layer`" section in the Yocto Project Development Tasks Manual.
When you name an append file, you can use the "``%``" wildcard character
@@ -58,14 +58,13 @@
:term:`Board Support Package (BSP)`
A group of drivers, definitions, and other components that provide support
for a specific hardware configuration. For more information on BSPs, see
- the :ref:`bsp-guide/bsp-guide:Yocto Project Board Support Package
- Developer's Guide`.
+ the :doc:`/bsp-guide/index`.
:term:`Build Directory`
This term refers to the area used by the OpenEmbedded build system for
builds. The area is created when you ``source`` the setup environment
script that is found in the Source Directory
- (i.e. :ref:`ref-manual/ref-structure:\`\`oe-init-build-env\`\``). The
+ (i.e. :ref:`ref-manual/structure:\`\`oe-init-build-env\`\``). The
:term:`TOPDIR` variable points to the Build Directory.
You have a lot of flexibility when creating the Build Directory.
@@ -118,7 +117,7 @@
Files that provide for logic encapsulation and inheritance so that
commonly used patterns can be defined once and then easily used in
multiple recipes. For reference information on the Yocto Project classes,
- see the ":ref:`ref-manual/ref-classes:Classes`" chapter. Class files end with the
+ see the ":ref:`ref-manual/classes:Classes`" chapter. Class files end with the
``.bbclass`` filename extension.
:term:`Configuration File`
@@ -161,27 +160,24 @@
Creation of these toolchains is simple and automated. For information on
toolchain concepts as they apply to the Yocto Project, see the
- ":ref:`overview-manual/overview-manual-concepts:Cross-Development
+ ":ref:`overview-manual/concepts:Cross-Development
Toolchain Generation`" section in the Yocto Project Overview and Concepts
Manual. You can also find more information on using the relocatable
- toolchain in the :ref:`sdk-manual/sdk-manual:Yocto Project Application
- Development and the Extensible Software Development Kit (eSDK)` manual.
+ toolchain in the :doc:`/sdk-manual/index` manual.
:term:`Extensible Software Development Kit (eSDK)`
A custom SDK for 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 :ref:`sdk-manual/sdk-manual:Yocto
- Project Application Development and the Extensible Software Development
- Kit (eSDK)` manual.
+ For information on the eSDK, see the :doc:`/sdk-manual/index` manual.
:term:`Image`
An image is an artifact of the BitBake build process given a collection of
recipes and related Metadata. Images are the binary output that run on
specific hardware or QEMU and are used for specific use-cases. For a list
of the supported image types that the Yocto Project provides, see the
- ":ref:`ref-manual/ref-images:Images`" chapter.
+ ":ref:`ref-manual/images:Images`" chapter.
:term:`Layer`
A collection of related recipes. Layers allow you to consolidate related
@@ -193,10 +189,10 @@
layers used within Yocto Project.
For introductory information on layers, see the
- ":ref:`overview-manual/overview-manual-yp-intro:The Yocto Project Layer
+ ":ref:`overview-manual/yp-intro:The Yocto Project Layer
Model`" section in the Yocto Project Overview and Concepts Manual. For
more detailed information on layers, see the
- ":ref:`dev-manual/dev-manual-common-tasks:Understanding and Creating
+ ":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 Project Board Support Packages (BSP)
@@ -218,7 +214,7 @@
In the context of the kernel ("kernel Metadata"), the term refers to
the kernel config fragments and features contained in the
- :yocto_git:`yocto-kernel-cache </cgit/cgit.cgi/yocto-kernel-cache>`
+ :yocto_git:`yocto-kernel-cache </yocto-kernel-cache>`
Git repository.
:term:`OpenEmbedded-Core (OE-Core)`
@@ -232,7 +228,7 @@
core set of recipes.
You can see the Metadata in the ``meta`` directory of the Yocto
- Project :yocto_git:`Source Repositories </cgit/cgit.cgi/poky>`.
+ Project :yocto_git:`Source Repositories </poky>`.
:term:`OpenEmbedded Build System`
The build system specific to the Yocto
@@ -256,7 +252,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 are compiled binaries that, when installed, add functionality to
your Linux distribution.
@@ -370,7 +366,7 @@
For more information on concepts related to Git repositories,
branches, and tags, see the
- ":ref:`overview-manual/overview-manual-development-environment:repositories, tags, and branches`"
+ ":ref:`overview-manual/development-environment:repositories, tags, and branches`"
section in the Yocto Project Overview and Concepts Manual.
:term:`Task`
@@ -384,7 +380,7 @@
The interface enables you to
configure and run your builds. Information about builds is collected
and stored in a database. For information on Toaster, see the
- :doc:`../toaster-manual/toaster-manual`.
+ :doc:`/toaster-manual/index`.
:term:`Upstream`
A reference to source code or repositories that are not
diff --git a/poky/documentation/ref-manual/ref-variables.rst b/poky/documentation/ref-manual/variables.rst
similarity index 97%
rename from poky/documentation/ref-manual/ref-variables.rst
rename to poky/documentation/ref-manual/variables.rst
index e552351..8c6cc46 100644
--- a/poky/documentation/ref-manual/ref-variables.rst
+++ b/poky/documentation/ref-manual/variables.rst
@@ -239,7 +239,7 @@
so that it does contain ``${SRCPV}``.
For more information see the
- ":ref:`dev-manual/dev-manual-common-tasks:automatically incrementing a package version number`"
+ ":ref:`dev-manual/common-tasks:automatically incrementing a package version number`"
section in the Yocto Project Development Tasks Manual.
:term:`AVAILABLE_LICENSES`
@@ -261,7 +261,7 @@
The list simply presents the tunes that are available. Not all tunes
may be compatible with a particular machine configuration, or with
each other in a
- :ref:`Multilib <dev-manual/dev-manual-common-tasks:combining multiple versions of library files into one image>`
+ :ref:`Multilib <dev-manual/common-tasks:combining multiple versions of library files into one image>`
configuration.
To add a tune to the list, be sure to append it with spaces using the
@@ -317,7 +317,7 @@
:term:`BASE_LIB`
The library directory name for the CPU or Application Binary
Interface (ABI) tune. The ``BASE_LIB`` applies only in the Multilib
- context. See the ":ref:`dev-manual/dev-manual-common-tasks:combining multiple versions of library files into one image`"
+ context. See the ":ref:`dev-manual/common-tasks:combining multiple versions of library files into one image`"
section in the Yocto Project Development Tasks Manual for information
on Multilib.
@@ -545,7 +545,7 @@
is not set higher than "20".
For more information on speeding up builds, see the
- ":ref:`dev-manual/dev-manual-common-tasks:speeding up a build`"
+ ":ref:`dev-manual/common-tasks:speeding up a build`"
section in the Yocto Project Development Tasks Manual.
:term:`BB_SERVER_TIMEOUT`
@@ -746,7 +746,7 @@
For information on how to use ``BBMULTICONFIG`` in an environment
that supports building targets with multiple configurations, see the
- ":ref:`dev-building-images-for-multiple-targets-using-multiple-configurations`"
+ ":ref:`dev-manual/common-tasks:building images for multiple targets using multiple configurations`"
section in the Yocto Project Development Tasks Manual.
:term:`BBPATH`
@@ -1002,7 +1002,7 @@
When inheriting the :ref:`buildhistory <ref-classes-buildhistory>`
class, this variable specifies the build history features to be
enabled. For more information on how build history works, see the
- ":ref:`dev-manual/dev-manual-common-tasks:maintaining build output quality`"
+ ":ref:`dev-manual/common-tasks:maintaining build output quality`"
section in the Yocto Project Development Tasks Manual.
You can specify these features in the form of a space-separated list:
@@ -1016,7 +1016,7 @@
(SDK).
- *task:* Save output file signatures for
- :ref:`shared state <overview-manual/overview-manual-concepts:shared state cache>`
+ :ref:`shared state <overview-manual/concepts:shared state cache>`
(sstate) tasks.
This saves one file per task and lists the SHA-256 checksums for
each file staged (i.e. the output of the task).
@@ -1299,7 +1299,7 @@
will be the aggregate of all of them.
For information on creating an initramfs, see the
- ":ref:`building-an-initramfs-image`" section
+ ":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) image`" section
in the Yocto Project Development Tasks Manual.
:term:`CONFIG_SITE`
@@ -1402,7 +1402,7 @@
newly installed packages to an image, which might be most suitable for
read-only filesystems that cannot be upgraded. See the
:term:`LICENSE_CREATE_PACKAGE` variable for additional information.
- You can also reference the ":ref:`dev-manual/dev-manual-common-tasks:providing license text`"
+ You can also reference the ":ref:`dev-manual/common-tasks:providing license text`"
section in the Yocto Project Development Tasks Manual for
information on providing license text.
@@ -1418,7 +1418,7 @@
newly installed packages to an image, which might be most suitable for
read-only filesystems that cannot be upgraded. See the
:term:`LICENSE_CREATE_PACKAGE` variable for additional information.
- You can also reference the ":ref:`dev-manual/dev-manual-common-tasks:providing license text`"
+ You can also reference the ":ref:`dev-manual/common-tasks:providing license text`"
section in the Yocto Project Development Tasks Manual for
information on providing license text.
@@ -1522,7 +1522,7 @@
.. note::
Tasks that read from or write to this directory should run under
- :ref:`fakeroot <overview-manual/overview-manual-concepts:fakeroot and pseudo>`.
+ :ref:`fakeroot <overview-manual/concepts:fakeroot and pseudo>`.
:term:`DATE`
The date the build was started. Dates appear using the year, month,
@@ -1641,7 +1641,7 @@
- One recipe having another recipe in ``DEPENDS`` does not by
itself add any runtime dependencies between the packages
produced by the two recipes. However, as explained in 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,
runtime dependencies will often be added automatically, meaning
``DEPENDS`` alone is sufficient for most recipes.
@@ -1670,11 +1670,11 @@
``${TMPDIR}/deploy``.
For more information on the structure of the Build Directory, see
- ":ref:`ref-manual/ref-structure:the build directory - \`\`build/\`\``" section.
+ ":ref:`ref-manual/structure:the build directory - \`\`build/\`\``" section.
For more detail on the contents of the ``deploy`` directory, see the
- ":ref:`Images <images-dev-environment>`", ":ref:`Package
- Feeds <package-feeds-dev-environment>`", and
- ":ref:`sdk-dev-environment`" sections all in the
+ ":ref:`overview-manual/concepts:images`",
+ ":ref:`overview-manual/concepts:package feeds`", and
+ ":ref:`overview-manual/concepts:application development sdk`" sections all in the
Yocto Project Overview and Concepts Manual.
:term:`DEPLOY_DIR_DEB`
@@ -1695,8 +1695,8 @@
``DEPLOY_DIR_DEB`` variable to make sure the
:ref:`ref-tasks-package_write_deb` task
writes Debian packages into the appropriate folder. For more
- information on how packaging works, see the ":ref:`Package
- Feeds <package-feeds-dev-environment>`" section
+ information on how packaging works, see the
+ ":ref:`overview-manual/concepts:package feeds`" section
in the Yocto Project Overview and Concepts Manual.
:term:`DEPLOY_DIR_IMAGE`
@@ -1708,10 +1708,10 @@
``${DEPLOY_DIR}/images/${MACHINE}/``.
For more information on the structure of the Build Directory, see
- ":ref:`ref-manual/ref-structure:the build directory - \`\`build/\`\``" section.
+ ":ref:`ref-manual/structure:the build directory - \`\`build/\`\``" section.
For more detail on the contents of the ``deploy`` directory, see the
- ":ref:`Images <images-dev-environment>`" and
- ":ref:`sdk-dev-environment`" sections both in
+ ":ref:`overview-manual/concepts:images`" and
+ ":ref:`overview-manual/concepts:application development sdk`" sections both in
the Yocto Project Overview and Concepts Manual.
:term:`DEPLOY_DIR_IPK`
@@ -1731,8 +1731,8 @@
``DEPLOY_DIR_IPK`` variable to make sure the
:ref:`ref-tasks-package_write_ipk` task
writes IPK packages into the appropriate folder. For more information
- on how packaging works, see the ":ref:`Package
- Feeds <package-feeds-dev-environment>`" section
+ on how packaging works, see the
+ ":ref:`overview-manual/concepts:package feeds`" section
in the Yocto Project Overview and Concepts Manual.
:term:`DEPLOY_DIR_RPM`
@@ -1752,8 +1752,8 @@
``DEPLOY_DIR_RPM`` variable to make sure the
:ref:`ref-tasks-package_write_rpm` task
writes RPM packages into the appropriate folder. For more information
- on how packaging works, see the ":ref:`Package
- Feeds <package-feeds-dev-environment>`" section
+ on how packaging works, see the
+ ":ref:`overview-manual/concepts:package feeds`" section
in the Yocto Project Overview and Concepts Manual.
:term:`DEPLOY_DIR_TAR`
@@ -1773,8 +1773,8 @@
``DEPLOY_DIR_TAR`` variable to make sure the
:ref:`ref-tasks-package_write_tar` task
writes TAR packages into the appropriate folder. For more information
- on how packaging works, see the ":ref:`Package
- Feeds <package-feeds-dev-environment>`" section
+ on how packaging works, see the
+ ":ref:`overview-manual/concepts:package feeds`" section
in the Yocto Project Overview and Concepts Manual.
:term:`DEPLOYDIR`
@@ -1997,7 +1997,7 @@
process gets source files when working behind a firewall or proxy
server, see this specific question in the ":doc:`faq`"
chapter. You can also refer to the
- ":yocto_wiki:`Working Behind a Network Proxy </wiki/Working_Behind_a_Network_Proxy>`"
+ ":yocto_wiki:`Working Behind a Network Proxy </Working_Behind_a_Network_Proxy>`"
Wiki page.
:term:`DOC_COMPRESS`
@@ -2029,7 +2029,7 @@
When used with the :ref:`report-error <ref-classes-report-error>`
class, specifies the path used for storing the debug files created by
the :ref:`error reporting
- tool <dev-manual/dev-manual-common-tasks:using the error reporting tool>`, which
+ tool <dev-manual/common-tasks:using the error reporting tool>`, which
allows you to submit build errors you encounter to a central
database. By default, the value of this variable is
``${``\ :term:`LOG_DIR`\ ``}/error-report``.
@@ -2129,7 +2129,7 @@
For more information on ``externalsrc.bbclass``, see the
":ref:`externalsrc.bbclass <ref-classes-externalsrc>`" section. You
can also find information on how to use this variable in the
- ":ref:`dev-manual/dev-manual-common-tasks:building software from an external source`"
+ ":ref:`dev-manual/common-tasks:building software from an external source`"
section in the Yocto Project Development Tasks Manual.
:term:`EXTERNALSRC_BUILD`
@@ -2143,7 +2143,7 @@
For more information on ``externalsrc.bbclass``, see the
":ref:`externalsrc.bbclass <ref-classes-externalsrc>`" section. You
can also find information on how to use this variable in the
- ":ref:`dev-manual/dev-manual-common-tasks:building software from an external source`"
+ ":ref:`dev-manual/common-tasks:building software from an external source`"
section in the Yocto Project Development Tasks Manual.
:term:`EXTRA_AUTORECONF`
@@ -2181,7 +2181,7 @@
useful if you want to develop against the libraries in the image.
- "read-only-rootfs" - Creates an image whose root filesystem is
read-only. See the
- ":ref:`dev-manual/dev-manual-common-tasks:creating a read-only root filesystem`"
+ ":ref:`dev-manual/common-tasks:creating a read-only root filesystem`"
section in the Yocto Project Development Tasks Manual for more
information
- "tools-debug" - Adds debugging tools such as gdb and strace.
@@ -2194,7 +2194,7 @@
Project, see the ":ref:`ref-features-image`" section.
For an example that shows how to customize your image by using this
- variable, see the ":ref:`usingpoky-extend-customimage-imagefeatures`"
+ variable, see the ":ref:`dev-manual/common-tasks:customizing images using custom \`\`image_features\`\` and \`\`extra_image_features\`\``"
section in the Yocto Project Development Tasks Manual.
:term:`EXTRA_IMAGECMD`
@@ -2419,7 +2419,7 @@
The previous statement appears in the
``linux-yocto-dev.bbappend`` file, which is found in the
- :ref:`overview-manual/overview-manual-development-environment:yocto project source repositories` in
+ :ref:`overview-manual/development-environment:yocto project source repositories` in
``meta-intel/common/recipes-kernel/linux``. Here, the machine
override is a special :term:`PACKAGE_ARCH`
definition for multiple ``meta-intel`` machines.
@@ -2509,9 +2509,9 @@
build system uses files from ``files/defconfig``.
You can find out more about the patching process in the
- ":ref:`patching-dev-environment`" section
+ ":ref:`overview-manual/concepts:patching`" section
in the Yocto Project Overview and Concepts Manual and the
- ":ref:`new-recipe-patching-code`" section in
+ ":ref:`dev-manual/common-tasks:patching code`" section in
the Yocto Project Development Tasks Manual. See the
:ref:`ref-tasks-patch` task as well.
@@ -2904,10 +2904,10 @@
the same files into a ``boot`` directory within the target partition.
You can find information on how to use the Wic tool in the
- ":ref:`dev-manual/dev-manual-common-tasks:creating partitioned images using wic`"
+ ":ref:`dev-manual/common-tasks:creating partitioned images using wic`"
section of the Yocto Project Development Tasks Manual. Reference
material for Wic is located in the
- ":doc:`../ref-manual/ref-kickstart`" chapter.
+ ":doc:`/ref-manual/kickstart`" chapter.
:term:`IMAGE_BOOT_FILES`
A space-separated list of files installed into the boot partition
@@ -2940,10 +2940,10 @@
the same files into a ``boot`` directory within the target partition.
You can find information on how to use the Wic tool in the
- ":ref:`dev-manual/dev-manual-common-tasks:creating partitioned images using wic`"
+ ":ref:`dev-manual/common-tasks:creating partitioned images using wic`"
section of the Yocto Project Development Tasks Manual. Reference
material for Wic is located in the
- ":doc:`../ref-manual/ref-kickstart`" chapter.
+ ":doc:`/ref-manual/kickstart`" chapter.
:term:`IMAGE_CLASSES`
A list of classes that all images should inherit. You typically use
@@ -3000,7 +3000,7 @@
the ":ref:`ref-features-image`" section.
For an example that shows how to customize your image by using this
- variable, see the ":ref:`usingpoky-extend-customimage-imagefeatures`"
+ variable, see the ":ref:`dev-manual/common-tasks:customizing images using custom \`\`image_features\`\` and \`\`extra_image_features\`\``"
section in the Yocto Project Development Tasks Manual.
:term:`IMAGE_FSTYPES`
@@ -3051,18 +3051,18 @@
.. note::
- When working with a
- :ref:`core-image-minimal-initramfs <ref-manual/ref-images:images>`
+ :ref:`core-image-minimal-initramfs <ref-manual/images:images>`
image, do not use the ``IMAGE_INSTALL`` variable to specify
packages for installation. Instead, use the
:term:`PACKAGE_INSTALL` variable, which
allows the initial RAM filesystem (initramfs) recipe to use a
fixed set of packages and not be affected by ``IMAGE_INSTALL``.
For information on creating an initramfs, see the
- ":ref:`building-an-initramfs-image`"
+ ":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) image`"
section in the Yocto Project Development Tasks Manual.
- Using ``IMAGE_INSTALL`` with the
- :ref:`+= <bitbake:appending-and-prepending>`
+ :ref:`+= <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:appending (+=) and prepending (=+) with spaces>`
BitBake operator within the ``/conf/local.conf`` file or from
within an image recipe is not recommended. Use of this operator
in these ways can cause ordering issues. Since
@@ -3126,7 +3126,7 @@
The location is
derived using the :term:`DEPLOY_DIR_IMAGE`
and :term:`IMAGE_NAME` variables. You can find
- information on how the image is created in the ":ref:`image-generation-dev-environment`"
+ information on how the image is created in the ":ref:`overview-manual/concepts:image generation`"
section in the Yocto Project Overview and Concepts Manual.
:term:`IMAGE_NAME`
@@ -3554,7 +3554,7 @@
:term:`INITRAMFS_IMAGE_BUNDLE`
variable, which allows the generated image to be bundled inside the
kernel image. Additionally, for information on creating an initramfs
- image, see the ":ref:`building-an-initramfs-image`" section
+ image, see the ":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) image`" section
in the Yocto Project Development Tasks Manual.
:term:`INITRAMFS_IMAGE_BUNDLE`
@@ -3600,9 +3600,9 @@
configuration file. You cannot set the variable in a recipe file.
See the
- :yocto_git:`local.conf.sample.extended </cgit/cgit.cgi/poky/tree/meta-poky/conf/local.conf.sample.extended>`
+ :yocto_git:`local.conf.sample.extended </poky/tree/meta-poky/conf/local.conf.sample.extended>`
file for additional information. Also, for information on creating an
- initramfs, see the ":ref:`building-an-initramfs-image`" section
+ initramfs, see the ":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) image`" section
in the Yocto Project Development Tasks Manual.
:term:`INITRAMFS_LINK_NAME`
@@ -3723,7 +3723,7 @@
- qemu
- mips
- You define the ``KARCH`` variable in the :ref:`kernel-dev/kernel-dev-advanced:bsp descriptions`.
+ You define the ``KARCH`` variable in the :ref:`kernel-dev/advanced:bsp descriptions`.
:term:`KBRANCH`
A regular expression used by the build process to explicitly identify
@@ -3793,7 +3793,7 @@
For more
information on how to use the ``KBUILD_DEFCONFIG`` variable, see the
- ":ref:`kernel-dev/kernel-dev-common:using an "in-tree" \`\`defconfig\`\` file`"
+ ":ref:`kernel-dev/common:using an "in-tree" \`\`defconfig\`\` file`"
section in the Yocto Project Linux Kernel Development Manual.
:term:`KERNEL_ALT_IMAGETYPE`
@@ -4029,7 +4029,7 @@
of the :term:`STAGING_KERNEL_DIR` within
the :ref:`module <ref-classes-module>` class. For information on
how this variable is used, see the
- ":ref:`kernel-dev/kernel-dev-common:incorporating out-of-tree modules`"
+ ":ref:`kernel-dev/common:incorporating out-of-tree modules`"
section in the Yocto Project Linux Kernel Development Manual.
To help maximize compatibility with out-of-tree drivers used to build
@@ -4043,7 +4043,7 @@
of the :term:`STAGING_KERNEL_DIR` within
the :ref:`module <ref-classes-module>` class. For information on
how this variable is used, see the
- ":ref:`kernel-dev/kernel-dev-common:incorporating out-of-tree modules`"
+ ":ref:`kernel-dev/common:incorporating out-of-tree modules`"
section in the Yocto Project Linux Kernel Development Manual.
To help maximize compatibility with out-of-tree drivers used to build
@@ -4108,13 +4108,13 @@
:term:`KTYPE`
Defines the kernel type to be used in assembling the configuration.
The linux-yocto recipes define "standard", "tiny", and "preempt-rt"
- kernel types. See the ":ref:`kernel-dev/kernel-dev-advanced:kernel types`"
+ kernel types. See the ":ref:`kernel-dev/advanced:kernel types`"
section in the
Yocto Project Linux Kernel Development Manual for more information on
kernel types.
You define the ``KTYPE`` variable in the
- :ref:`kernel-dev/kernel-dev-advanced:bsp descriptions`. The
+ :ref:`kernel-dev/advanced:bsp descriptions`. The
value you use must match the value used for the
:term:`LINUX_KERNEL_TYPE` value used by the
kernel recipe.
@@ -4177,7 +4177,7 @@
To specify the OE-Core versions for which a layer is compatible, use
this variable in your layer's ``conf/layer.conf`` configuration file.
For the list, use the Yocto Project
- :yocto_wiki:`Release Name </wiki/Releases>` (e.g.
+ :yocto_wiki:`Release Name </Releases>` (e.g.
DISTRO_NAME_NO_CAP). To specify multiple OE-Core versions for the
layer, use a space-separated list:
::
@@ -4191,7 +4191,7 @@
The OpenEmbedded build system produces a warning if the variable
is not set for any given layer.
- See the ":ref:`dev-manual/dev-manual-common-tasks:creating your own layer`"
+ See the ":ref:`dev-manual/common-tasks:creating your own layer`"
section in the Yocto Project Development Tasks Manual.
:term:`LAYERVERSION`
@@ -4240,7 +4240,7 @@
This variable must be defined for all recipes (unless
:term:`LICENSE` is set to "CLOSED").
- For more information, see the ":ref:`usingpoky-configuring-lic_files_chksum`"
+ For more information, see the ":ref:`dev-manual/common-tasks:tracking license changes`"
section in the Yocto Project Development Tasks Manual.
:term:`LICENSE`
@@ -4306,7 +4306,7 @@
For related information on providing license text, see the
:term:`COPY_LIC_DIRS` variable, the
:term:`COPY_LIC_MANIFEST` variable, and the
- ":ref:`dev-manual/dev-manual-common-tasks:providing license text`"
+ ":ref:`dev-manual/common-tasks:providing license text`"
section in the Yocto Project Development Tasks Manual.
:term:`LICENSE_FLAGS`
@@ -4319,7 +4319,7 @@
typically used to mark recipes that might require additional licenses
in order to be used in a commercial product. For more information,
see the
- ":ref:`dev-manual/dev-manual-common-tasks:enabling commercially licensed recipes`"
+ ":ref:`dev-manual/common-tasks:enabling commercially licensed recipes`"
section in the Yocto Project Development Tasks Manual.
:term:`LICENSE_FLAGS_WHITELIST`
@@ -4327,7 +4327,7 @@
:term:`LICENSE_FLAGS` within a recipe should not
prevent that recipe from being built. This practice is otherwise
known as "whitelisting" license flags. For more information, see the
- ":ref:`dev-manual/dev-manual-common-tasks:enabling commercially licensed recipes`"
+ ":ref:`dev-manual/common-tasks:enabling commercially licensed recipes`"
section in the Yocto Project Development Tasks Manual.
:term:`LICENSE_PATH`
@@ -4343,7 +4343,7 @@
:term:`LINUX_KERNEL_TYPE`
Defines the kernel type to be used in assembling the configuration.
The linux-yocto recipes define "standard", "tiny", and "preempt-rt"
- kernel types. See the ":ref:`kernel-dev/kernel-dev-advanced:kernel types`"
+ kernel types. See the ":ref:`kernel-dev/advanced:kernel types`"
section in the
Yocto Project Linux Kernel Development Manual for more information on
kernel types.
@@ -4890,7 +4890,7 @@
Controls how the OpenEmbedded build system spawns interactive
terminals on the host development system (e.g. using the BitBake
command with the ``-c devshell`` command-line option). For more
- information, see the ":ref:`platdev-appdev-devshell`" section in
+ information, see the ":ref:`dev-manual/common-tasks:using a development shell`" section in
the Yocto Project Development Tasks Manual.
You can use the following values for the ``OE_TERMINAL`` variable:
@@ -4959,7 +4959,7 @@
An easy way to see what overrides apply is to search for ``OVERRIDES``
in the output of the ``bitbake -e`` command. See the
- ":ref:`dev-debugging-viewing-variable-values`" section in the Yocto
+ ":ref:`dev-manual/common-tasks:viewing variable values`" section in the Yocto
Project Development Tasks Manual for more information.
:term:`P`
@@ -4981,7 +4981,7 @@
specific by using the package name as a suffix.
You can find out more about applying this variable in the
- ":ref:`dev-manual/dev-manual-common-tasks:adding custom metadata to packages`"
+ ":ref:`dev-manual/common-tasks:adding custom metadata to packages`"
section in the Yocto Project Development Tasks Manual.
:term:`PACKAGE_ARCH`
@@ -5079,7 +5079,7 @@
separate ``*-src`` pkg. This is the default behavior.
You can find out more about debugging using GDB by reading the
- ":ref:`platdev-gdb-remotedebug`" section
+ ":ref:`dev-manual/common-tasks:debugging with the gnu project debugger (gdb) remotely`" section
in the Yocto Project Development Tasks Manual.
:term:`PACKAGE_EXCLUDE_COMPLEMENTARY`
@@ -5240,10 +5240,10 @@
general, you should use the
:term:`IMAGE_INSTALL` variable to specify
packages for installation. The exception to this is when working with
- the :ref:`core-image-minimal-initramfs <ref-manual/ref-images:images>`
+ the :ref:`core-image-minimal-initramfs <ref-manual/images:images>`
image. When working with an initial RAM filesystem (initramfs) image,
use the ``PACKAGE_INSTALL`` variable. For information on creating an
- initramfs, see the ":ref:`building-an-initramfs-image`" section
+ initramfs, see the ":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) image`" section
in the Yocto Project Development Tasks Manual.
:term:`PACKAGE_INSTALL_ATTEMPTONLY`
@@ -5266,7 +5266,7 @@
``PACKAGE_WRITE_DEPS``.
For information on running post-installation scripts, see the
- ":ref:`dev-manual/dev-manual-common-tasks:post-installation scripts`"
+ ":ref:`dev-manual/common-tasks:post-installation scripts`"
section in the Yocto Project Development Tasks Manual.
:term:`PACKAGECONFIG`
@@ -5423,7 +5423,7 @@
For an example of how to use the ``PACKAGES_DYNAMIC`` variable when
you are splitting packages, see the
- ":ref:`dev-manual/dev-manual-common-tasks:handling optional module packaging`"
+ ":ref:`dev-manual/common-tasks:handling optional module packaging`"
section in the Yocto Project Development Tasks Manual.
:term:`PACKAGESPLITFUNCS`
@@ -5458,7 +5458,7 @@
the ``do_compile`` task that result in race conditions, you can clear
the ``PARALLEL_MAKE`` variable within the recipe as a workaround. For
information on addressing race conditions, see the
- ":ref:`dev-manual/dev-manual-common-tasks:debugging parallel make races`"
+ ":ref:`dev-manual/common-tasks:debugging parallel make races`"
section in the Yocto Project Development Tasks Manual.
For single socket systems (i.e. one CPU), you should not have to
@@ -5468,7 +5468,7 @@
not set higher than "-j 20".
For more information on speeding up builds, see the
- ":ref:`dev-manual/dev-manual-common-tasks:speeding up a build`"
+ ":ref:`dev-manual/common-tasks:speeding up a build`"
section in the Yocto Project Development Tasks Manual.
:term:`PARALLEL_MAKEINST`
@@ -5488,7 +5488,7 @@
the ``do_install`` task that result in race conditions, you can
clear the ``PARALLEL_MAKEINST`` variable within the recipe as a
workaround. For information on addressing race conditions, see the
- ":ref:`dev-manual/dev-manual-common-tasks:debugging parallel make races`"
+ ":ref:`dev-manual/common-tasks:debugging parallel make races`"
section in the Yocto Project Development Tasks Manual.
:term:`PATCHRESOLVE`
@@ -5578,9 +5578,9 @@
${STAGING_DIR_HOST}/pkgdata
For examples of how this data is used, 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 and the
- ":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\`\``"
section in the Yocto Project Development Tasks Manual. For more
information on the shared, global-state directory, see
:term:`STAGING_DIR_HOST`.
@@ -5691,9 +5691,9 @@
The OpenEmbedded build system does not need the aid of ``PR``
to know when to rebuild a recipe. The build system uses the task
- :ref:`input checksums <overview-checksums>` along with the
+ :ref:`input checksums <overview-manual/concepts:checksums (signatures)>` along with the
:ref:`stamp <structure-build-tmp-stamps>` and
- :ref:`overview-manual/overview-manual-concepts:shared state cache`
+ :ref:`overview-manual/concepts:shared state cache`
mechanisms.
The ``PR`` variable primarily becomes significant when a package
@@ -5713,7 +5713,7 @@
Because manually managing ``PR`` can be cumbersome and error-prone,
an automated solution exists. See the
- ":ref:`dev-manual/dev-manual-common-tasks:working with a pr service`" section
+ ":ref:`dev-manual/common-tasks:working with a pr service`" section
in the Yocto Project Development Tasks Manual for more information.
:term:`PREFERRED_PROVIDER`
@@ -5738,7 +5738,7 @@
PREFERRED_PROVIDER_virtual/libgl ?= "mesa"
For more
- information, see the ":ref:`metadata-virtual-providers`"
+ information, see the ":ref:`dev-manual/common-tasks:using virtual providers`"
section in the Yocto Project Development Tasks Manual.
.. note::
@@ -5875,7 +5875,7 @@
libplds4.so"
For more information, 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.
:term:`PROVIDES`
@@ -5951,7 +5951,7 @@
You must
set the variable if you want to automatically start a local :ref:`PR
- service <dev-manual/dev-manual-common-tasks:working with a pr service>`. You can
+ service <dev-manual/common-tasks:working with a pr service>`. You can
set ``PRSERV_HOST`` to other values to use a remote PR service.
@@ -5965,7 +5965,7 @@
:term:`PTEST_ENABLED`
Specifies whether or not :ref:`Package
- Test <dev-manual/dev-manual-common-tasks:testing packages with ptest>` (ptest)
+ Test <dev-manual/common-tasks:testing packages with ptest>` (ptest)
functionality is enabled when building a recipe. You should not set
this variable directly. Enabling and disabling building Package Tests
at build time should be done by adding "ptest" to (or removing it
@@ -6068,7 +6068,7 @@
runtime dependencies are automatically detected and added. Therefore,
most recipes do not need to set ``RDEPENDS``. For more information,
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.
The practical effect of the above ``RDEPENDS`` assignment is that
@@ -6542,7 +6542,7 @@
For additional information on how to customize the extensible SDK's
configuration, see the
- ":ref:`sdk-manual/sdk-appendix-customizing:configuring the extensible sdk`"
+ ":ref:`sdk-manual/appendix-customizing:configuring the extensible sdk`"
section in the Yocto Project Application Development and the
Extensible Software Development Kit (eSDK) manual.
@@ -6568,7 +6568,7 @@
For additional information on how to customize the extensible SDK's
configuration, see the
- ":ref:`sdk-manual/sdk-appendix-customizing:configuring the extensible sdk`"
+ ":ref:`sdk-manual/appendix-customizing:configuring the extensible sdk`"
section in the Yocto Project Application Development and the
Extensible Software Development Kit (eSDK) manual.
@@ -6587,7 +6587,7 @@
For additional information on how to customize the extensible SDK's
configuration, see the
- ":ref:`sdk-manual/sdk-appendix-customizing:configuring the extensible sdk`"
+ ":ref:`sdk-manual/appendix-customizing:configuring the extensible sdk`"
section in the Yocto Project Application Development and the
Extensible Software Development Kit (eSDK) manual.
@@ -6710,7 +6710,7 @@
``SDK_TITLE`` is set to "Poky (Yocto Project Reference Distro)".
For information on how to change this default title, see the
- ":ref:`sdk-manual/sdk-appendix-customizing:changing the extensible sdk installer title`"
+ ":ref:`sdk-manual/appendix-customizing:changing the extensible sdk installer title`"
section in the Yocto Project Application Development and the
Extensible Software Development Kit (eSDK) manual.
@@ -6748,7 +6748,7 @@
default distribution "poky", the ``SDKEXTPATH`` is set to "poky_sdk".
For information on how to change this default directory, see the
- ":ref:`sdk-manual/sdk-appendix-customizing:changing the default sdk installation directory`"
+ ":ref:`sdk-manual/appendix-customizing:changing the default sdk installation directory`"
section in the Yocto Project Application Development and the
Extensible Software Development Kit (eSDK) manual.
@@ -7000,7 +7000,7 @@
various ``SPL_*`` variables used by the OpenEmbedded build system.
See the BeagleBone machine configuration example in the
- ":ref:`dev-manual/dev-manual-common-tasks:adding a layer using the \`\`bitbake-layers\`\` script`"
+ ":ref:`dev-manual/common-tasks:adding a layer using the \`\`bitbake-layers\`\` script`"
section in the Yocto Project Board Support Package Developer's Guide
for additional information.
@@ -7018,12 +7018,12 @@
protocols are highly dependent on particular BitBake Fetcher
submodules. Depending on the fetcher BitBake uses, various URL
parameters are employed. For specifics on the supported Fetchers, see
- the ":ref:`Fetchers <bitbake:bb-fetchers>`" section in the
+ the ":ref:`Fetchers <bitbake:bitbake-user-manual/bitbake-user-manual-fetching:fetchers>`" section in the
BitBake User Manual.
- ``file://`` - Fetches files, which are usually files shipped
with the :term:`Metadata`, from the local machine (e.g.
- :ref:`patch <patching-dev-environment>` files).
+ :ref:`patch <overview-manual/concepts:patching>` files).
The path is relative to the :term:`FILESPATH`
variable. Thus, the build system searches, in order, from the
following directories, which are assumed to be a subdirectories of
@@ -7200,7 +7200,7 @@
For information on limitations when inheriting the latest revision
of software using ``SRCREV``, see the :term:`AUTOREV` variable
description and the
- ":ref:`automatically-incrementing-a-binary-package-revision-number`"
+ ":ref:`dev-manual/common-tasks:automatically incrementing a package version number`"
section, which is in the Yocto Project Development Tasks Manual.
:term:`SSTATE_DIR`
@@ -7314,9 +7314,9 @@
For information on how staging for recipe-specific sysroots occurs,
see the :ref:`ref-tasks-populate_sysroot`
- task, the ":ref:`sdk-manual/sdk-extensible:sharing files between recipes`"
+ task, the ":ref:`sdk-manual/extensible:sharing files between recipes`"
section in the Yocto Project Development Tasks Manual, the
- ":ref:`configuration-compilation-and-staging-dev-environment`"
+ ":ref:`overview-manual/concepts:configuration, compilation, and staging`"
section in the Yocto Project Overview and Concepts Manual, and the
:term:`SYSROOT_DIRS` variable.
@@ -7437,7 +7437,7 @@
For information on how BitBake uses stamp files to determine if a
task should be rerun, 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.
See :term:`STAMPS_DIR`,
@@ -7660,7 +7660,7 @@
:term:`SYSVINIT_ENABLED_GETTYS`
When using
- :ref:`SysVinit <dev-manual/dev-manual-common-tasks:enabling system services>`,
+ :ref:`SysVinit <dev-manual/common-tasks:enabling system services>`,
specifies a space-separated list of the virtual terminals that should
run a `getty <http://en.wikipedia.org/wiki/Getty_%28Unix%29>`__
(allowing login), assuming :term:`USE_VT` is not set to
@@ -7946,7 +7946,7 @@
file.
For more information on testing images, see the
- ":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`"
+ ":ref:`dev-manual/common-tasks:performing automated runtime testing`"
section in the Yocto Project Development Tasks Manual.
:term:`TEST_SERIALCONTROL_CMD`
@@ -8022,7 +8022,7 @@
TEST_SUITES = "test_A test_B"
For more information on testing images, see the
- ":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`"
+ ":ref:`dev-manual/common-tasks:performing automated runtime testing`"
section in the Yocto Project Development Tasks Manual.
:term:`TEST_TARGET`
@@ -8042,7 +8042,7 @@
You can provide the following arguments with ``TEST_TARGET``:
- *"qemu":* Boots a QEMU image and runs the tests. See the
- ":ref:`qemu-image-enabling-tests`" section
+ ":ref:`dev-manual/common-tasks:enabling runtime tests on qemu`" section
in the Yocto Project Development Tasks Manual for more
information.
@@ -8058,7 +8058,7 @@
``meta/lib/oeqa/controllers/simpleremote.py``.
For information on running tests on hardware, see the
- ":ref:`hardware-image-enabling-tests`"
+ ":ref:`dev-manual/common-tasks:enabling runtime tests on hardware`"
section in the Yocto Project Development Tasks Manual.
:term:`TEST_TARGET_IP`
@@ -8096,7 +8096,7 @@
For more information
on enabling, running, and writing these tests, see the
- ":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`"
+ ":ref:`dev-manual/common-tasks:performing automated runtime testing`"
section in the Yocto Project Development Tasks Manual and the
":ref:`testimage*.bbclass <ref-classes-testimage*>`" section.
@@ -8145,16 +8145,16 @@
In this case, a default list of packages is
set in this variable, but you can add additional packages to the
list. See the
- ":ref:`sdk-manual/sdk-appendix-customizing-standard:adding individual packages to the standard sdk`" section
+ ":ref:`sdk-manual/appendix-customizing-standard:adding individual packages to the standard sdk`" section
in the Yocto Project Application Development and the Extensible
Software Development Kit (eSDK) manual for more information.
For background information on cross-development toolchains in the
Yocto Project development environment, see the
- ":ref:`sdk-manual/sdk-intro:the cross-development toolchain`"
+ ":ref:`sdk-manual/intro:the cross-development toolchain`"
section in the Yocto Project Overview and Concepts Manual. For
information on setting up a cross-development environment, see the
- :doc:`../sdk-manual/sdk-manual` manual.
+ :doc:`/sdk-manual/index` manual.
:term:`TOOLCHAIN_OUTPUTNAME`
This variable defines the name used for the toolchain output. The
@@ -8175,16 +8175,16 @@
target hardware), which includes libraries and headers. Use this
variable to add individual packages to the part of the SDK that runs
on the target. See the
- ":ref:`sdk-manual/sdk-appendix-customizing-standard:adding individual packages to the standard sdk`" section
+ ":ref:`sdk-manual/appendix-customizing-standard:adding individual packages to the standard sdk`" section
in the Yocto Project Application Development and the Extensible
Software Development Kit (eSDK) manual for more information.
For background information on cross-development toolchains in the
Yocto Project development environment, see the
- ":ref:`sdk-manual/sdk-intro:the cross-development toolchain`"
+ ":ref:`sdk-manual/intro:the cross-development toolchain`"
section in the Yocto Project Overview and Concepts Manual. For
information on setting up a cross-development environment, see the
- :doc:`../sdk-manual/sdk-manual` manual.
+ :doc:`/sdk-manual/index` manual.
:term:`TOPDIR`
The top-level :term:`Build Directory`. BitBake
@@ -8554,13 +8554,13 @@
specifically set. Typically, you would set ``USE_DEVFS`` to "0" for a
statically populated ``/dev`` directory.
- See the ":ref:`selecting-dev-manager`" section in
+ See the ":ref:`dev-manual/common-tasks:selecting a device manager`" section in
the Yocto Project Development Tasks Manual for information on how to
use this variable.
:term:`USE_VT`
When using
- :ref:`SysVinit <new-recipe-enabling-system-services>`,
+ :ref:`SysVinit <dev-manual/common-tasks:enabling system services>`,
determines whether or not to run a
`getty <http://en.wikipedia.org/wiki/Getty_%28Unix%29>`__ on any
virtual terminals in order to enable logging in through those
@@ -8735,9 +8735,9 @@
OpenEmbedded build system to create a partitioned image
(image\ ``.wic``). For information on how to create a partitioned
image, see the
- ":ref:`dev-manual/dev-manual-common-tasks:creating partitioned images using wic`"
+ ":ref:`dev-manual/common-tasks:creating partitioned images using wic`"
section in the Yocto Project Development Tasks Manual. For details on
- the kickstart file format, see the ":doc:`../ref-manual/ref-kickstart`" Chapter.
+ the kickstart file format, see the ":doc:`/ref-manual/kickstart`" Chapter.
:term:`WKS_FILE_DEPENDS`
When placed in the recipe that builds your image, this variable lists
diff --git a/poky/documentation/ref-manual/ref-varlocality.rst b/poky/documentation/ref-manual/varlocality.rst
similarity index 100%
rename from poky/documentation/ref-manual/ref-varlocality.rst
rename to poky/documentation/ref-manual/varlocality.rst