diff options
| author | Andrew Geissler <geissonator@yahoo.com> | 2020-12-13 17:44:15 +0300 |
|---|---|---|
| committer | Andrew Geissler <geissonator@yahoo.com> | 2020-12-15 21:53:47 +0300 |
| commit | 09209eec235a35b7089db987561c12e9bd023237 (patch) | |
| tree | 2d3580484ffacafe11b72e9abaab50a428dd617d /poky/documentation/ref-manual | |
| parent | f7ba29eda266e04f867e4338b6b8b10c1969419c (diff) | |
| download | openbmc-09209eec235a35b7089db987561c12e9bd023237.tar.xz | |
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
Diffstat (limited to 'poky/documentation/ref-manual')
29 files changed, 306 insertions, 309 deletions
diff --git a/poky/documentation/ref-manual/ref-classes.rst b/poky/documentation/ref-manual/classes.rst index 249b58e60..5a30ce379 100644 --- a/poky/documentation/ref-manual/ref-classes.rst +++ b/poky/documentation/ref-manual/classes.rst @@ -68,7 +68,7 @@ The ``archiver`` class supports releasing source code and other 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 @@ standardization. This class defines a set of tasks (e.g. ``configure``, 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 @@ The ``buildhistory`` class records a history of build output metadata, 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 @@ cross-compilation tools. 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 @@ discussion on these cross-compilation tools. 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 @@ staging the files from ``DEPLOYDIR`` to ``DEPLOY_DIR_IMAGE``. ==================== 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 @@ For more information on the ``externalsrc`` class, see the comments in ``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 @@ then one or more image files are created. 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 @@ You can configure the sanity checks so that specific test failures 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 @@ The following list shows the tests you can list with the ``WARN_QA`` and - ``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 @@ packages such as ``kernel-vmlinux``. 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 @@ and implements the :ref:`ref-tasks-compile` and 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 @@ different target optimizations or target architectures and installing 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 @@ package manager (NPM) <https://en.wikipedia.org/wiki/Npm_(software)>`__. 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 @@ If you take the optional step to set up a repository (package feed) on 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 @@ so forth). It is highly recommended that all package group recipes 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 @@ files. 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 @@ These classes are inherited by and used with the ``populate_sdk_base`` 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 ``primport`` class provides functionality for importing ================== 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 @@ runtime tests for recipes that build software that provides these tests. 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 @@ Enables package tests (ptests) specifically for GNOME packages, which 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 @@ override the removal by setting ``REMOVE_LIBTOOL_LA`` to "0" as follows: ======================== 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 @@ The root filesystem is created from packages using one of the :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 @@ default, the class is enabled through the :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 @@ unless you have set :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 @@ runs tests on an image after the image is constructed (i.e. :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 @@ To use this class, you need to define a number of variables: 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 index ad8889ed2..cc5848fd4 100644 --- a/poky/documentation/ref-manual/ref-devtool-reference.rst +++ b/poky/documentation/ref-manual/devtool-reference.rst @@ -11,7 +11,7 @@ is a key part of the extensible SDK. 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 @@ external source tree. 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 @@ particular recipe. .. 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 @@ satisfied. 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 @@ Upgrading a Recipe 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 @@ revision to which you want to upgrade (i.e. the 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 @@ Removing Your Software from the Target Machine 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 @@ The ``devtool status`` command has no command-line options: $ 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 576863eec..f67c53824 100644 --- a/poky/documentation/ref-manual/faq.rst +++ b/poky/documentation/ref-manual/faq.rst @@ -22,7 +22,7 @@ Can I still use the Yocto Project? **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 @@ section for steps on how to update your build tools. **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 @@ device. **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 @@ The Yocto Project also includes a ``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 @@ and also any configuration information about how that package was 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 @@ redirect requests through proxy servers. .. 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 index f28ad2bb4..89c06eb65 100644 --- a/poky/documentation/ref-manual/ref-features.rst +++ b/poky/documentation/ref-manual/features.rst @@ -118,7 +118,7 @@ metadata: - *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 @@ metadata: - *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 @@ The following image features are available for all images: - *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 @@ these valid features is as follows: - *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 @@ these valid features is as follows: - *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 index 56ec8562f..5e9374eae 100644 --- a/poky/documentation/ref-manual/ref-images.rst +++ b/poky/documentation/ref-manual/images.rst @@ -122,7 +122,7 @@ Following is a list of supported recipes: 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 @@ Following is a list of supported recipes: - ``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/ref-manual.rst b/poky/documentation/ref-manual/index.rst index 033f4ba28..deb0383cf 100644 --- a/poky/documentation/ref-manual/ref-manual.rst +++ b/poky/documentation/ref-manual/index.rst @@ -10,20 +10,20 @@ Yocto Project Reference Manual :caption: Table of Contents :numbered: - ref-system-requirements - ref-terms - ref-release-process + system-requirements + terms + 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 + structure + classes + tasks + devtool-reference + kickstart + qa-checks + images + features + variables + varlocality faq resources history diff --git a/poky/documentation/ref-manual/ref-kickstart.rst b/poky/documentation/ref-manual/kickstart.rst index 7f6d4ebe1..bb9c0460f 100644 --- a/poky/documentation/ref-manual/ref-kickstart.rst +++ b/poky/documentation/ref-manual/kickstart.rst @@ -79,7 +79,7 @@ the ``part`` and ``partition`` commands: 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 5f975850b..12e225b14 100644 --- a/poky/documentation/ref-manual/migration-1.3.rst +++ b/poky/documentation/ref-manual/migration-1.3.rst @@ -173,7 +173,7 @@ the OpenEmbedded community layers such as ``meta-oe`` and ``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 daaea0ffa..0b7e86117 100644 --- a/poky/documentation/ref-manual/migration-1.4.rst +++ b/poky/documentation/ref-manual/migration-1.4.rst @@ -84,7 +84,7 @@ create an append file for the ``init-ifupdown`` recipe instead, which 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 fc7aface9..2716bc9cf 100644 --- a/poky/documentation/ref-manual/migration-1.5.rst +++ b/poky/documentation/ref-manual/migration-1.5.rst @@ -26,7 +26,7 @@ provide packages for these, you can install and use the Buildtools 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 following changes have been made that relate to 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 @@ A new automated image testing framework has been added through the 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 @@ Following are changes to Build History: 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 a6c4c8a93..ed155d0df 100644 --- a/poky/documentation/ref-manual/migration-1.6.rst +++ b/poky/documentation/ref-manual/migration-1.6.rst @@ -12,7 +12,7 @@ Project 1.6 Release from the prior release. 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 @@ Changes to Variables -------------------- 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 @@ NFS mount, an error occurs. 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 Test (ptest) 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 @@ The previous reference BSPs for the ``beagleboard`` and ``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 5a5151ec1..19275b3cd 100644 --- a/poky/documentation/ref-manual/migration-1.7.rst +++ b/poky/documentation/ref-manual/migration-1.7.rst @@ -26,13 +26,13 @@ QEMU, you should now have these lines in ``local.conf``: 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 @@ occurred: 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 @@ The following changes have occurred to the QA check process: 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 @@ The following miscellaneous change occurred: 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 d601e6b63..73789bd51 100644 --- a/poky/documentation/ref-manual/migration-1.8.rst +++ b/poky/documentation/ref-manual/migration-1.8.rst @@ -79,7 +79,7 @@ particular, users need to ensure that ``${S}`` (source files) and 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 0220221e0..e8b3ada26 100644 --- a/poky/documentation/ref-manual/migration-2.1.rst +++ b/poky/documentation/ref-manual/migration-2.1.rst @@ -217,7 +217,7 @@ The following changes have been made to the build system user interface: - *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 @@ ADT Removed 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 @@ This release supports generation of GLib Introspective Repository (GIR) 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 @@ These additional changes exist: - 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 @@ These additional changes exist: 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 8afa8ffdd..ac247dce4 100644 --- a/poky/documentation/ref-manual/migration-2.2.rst +++ b/poky/documentation/ref-manual/migration-2.2.rst @@ -292,9 +292,9 @@ The following changes took place for BitBake: 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 5bf3e7033..3e9758119 100644 --- a/poky/documentation/ref-manual/migration-2.3.rst +++ b/poky/documentation/ref-manual/migration-2.3.rst @@ -51,7 +51,7 @@ Consider the following: :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 @@ The following changes took place for BitBake: 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 @@ The following package management changes took place: .. 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 @@ The following changes have been made to Wic: .. 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 @@ The following QA checks have changed: 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 1aeddc81c..9f45ffce7 100644 --- a/poky/documentation/ref-manual/migration-2.5.rst +++ b/poky/documentation/ref-manual/migration-2.5.rst @@ -180,7 +180,7 @@ or :: 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 @@ The following are additional changes: 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 @@ The following are additional changes: - 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 2f0da48ab..5d524f381 100644 --- a/poky/documentation/ref-manual/migration-2.6.rst +++ b/poky/documentation/ref-manual/migration-2.6.rst @@ -278,7 +278,7 @@ The following changes have occurred: 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 @@ Any failure of a ``pkg_postinst()`` script (including exit 1) triggers 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 047b75526..7ef2742f8 100644 --- a/poky/documentation/ref-manual/migration-3.0.rst +++ b/poky/documentation/ref-manual/migration-3.0.rst @@ -197,7 +197,7 @@ The following BitBake changes have occurred. - 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 9b65e26c4..65a9ff4ca 100644 --- a/poky/documentation/ref-manual/migration-3.2.rst +++ b/poky/documentation/ref-manual/migration-3.2.rst @@ -71,7 +71,7 @@ be monitoring. 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 index 54977dcb2..54977dcb2 100644 --- a/poky/documentation/ref-manual/ref-qa-checks.rst +++ b/poky/documentation/ref-manual/qa-checks.rst diff --git a/poky/documentation/ref-manual/ref-release-process.rst b/poky/documentation/ref-manual/release-process.rst index a6d9ff60e..d8d362282 100644 --- a/poky/documentation/ref-manual/ref-release-process.rst +++ b/poky/documentation/ref-manual/release-process.rst @@ -50,7 +50,7 @@ Major Release Codenames ======================= 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 @@ codename are likely to be compatible and thus work together. 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 @@ Community LTS trees and branches exist where community members share 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 @@ Additionally, because the test strategies are visible to you as a 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 @@ consists of the following pieces: - :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 @@ consists of the following pieces: .. 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 2ef182fb1..77c367809 100644 --- a/poky/documentation/ref-manual/resources.rst +++ b/poky/documentation/ref-manual/resources.rst @@ -23,7 +23,7 @@ The Yocto Project gladly accepts contributions. You can submit changes 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 @@ A general procedure and guidelines exist for when you use Bugzilla to 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 @@ Here is a list of resources you might find helpful: - :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 @@ Here is a list of resources you might find helpful: 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 @@ Here is a list of resources you might find helpful: 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 @@ Here is a list of resources you might find helpful: 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 index db1ea9797..ad3f4ab44 100644 --- a/poky/documentation/ref-manual/ref-structure.rst +++ b/poky/documentation/ref-manual/structure.rst @@ -12,7 +12,7 @@ and directories. 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 @@ metadata to define the Poky reference distribution. 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 @@ within the :term:`Source Directory`. If you design a 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 @@ Directory named ``mybuilds/`` that is outside of the :term:`Source Directory`: 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 @@ The OpenEmbedded build system creates this directory when you enable 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 @@ file, it uses ``sed`` to substitute final ---------------------------- 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 @@ This directory contains any "end result" output from the OpenEmbedded 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 @@ directory contains sub-directories for ``bash``, ``busybox``, and ``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 kernel files: 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 @@ and timestamps for tracking purposes. 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 @@ built within the Yocto Project. For this package, a work directory of ``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 @@ generation or packaging also have their specific class files such as ``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 index fe7c9252c..66afb0810 100644 --- a/poky/documentation/ref-manual/ref-system-requirements.rst +++ b/poky/documentation/ref-manual/system-requirements.rst @@ -15,14 +15,14 @@ Yocto Project. 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 @@ distributions: 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 index 9ef014139..9fe1c296a 100644 --- a/poky/documentation/ref-manual/ref-tasks.rst +++ b/poky/documentation/ref-manual/tasks.rst @@ -122,7 +122,7 @@ If the ``do_deploy`` task re-executes, any previous output is removed 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 @@ The ``do_image`` task performs pre-processing on the image through the :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 @@ through the :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 @@ compilation directory. The ``do_install`` task, as well as other tasks 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 @@ The ``do_package`` task, in conjunction with the :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 @@ see the :ref:`insane <ref-classes-insane>` class. 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 @@ the Yocto Project Overview and Concepts Manual. 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 @@ the Yocto Project Overview and Concepts Manual. 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 @@ the Yocto Project Overview and Concepts Manual. 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 @@ to locate and apply patch files to the source code. 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 @@ patch files end with either ``.patch`` or ``.diff``, every file would be 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 @@ the image is constructed. ------------------- 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 @@ information. ----------------------- 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 @@ Unpacks the source code into a working directory pointed to by ``${``\ :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 commands: $ 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 @@ You can run this task using BitBake as follows: $ 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 @@ use the :ref:`ref-tasks-cleansstate` task instead --------------- 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 @@ task. ------------------ 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 @@ scratch is guaranteed. 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 @@ using ``devpyshell``. --------------- 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 @@ Lists all defined tasks for a target. ``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 @@ has some more information about these types of images. ------------- 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 @@ information on how the root filesystem is created. 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 @@ after it has been built. This task is enabled when you set :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 @@ from the command line as follows: $ 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 @@ following command: $ 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 @@ tool, which you then use to modify the kernel configuration. $ 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 @@ which can then be applied by subsequent tasks such as 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 index b4ceebc0b..c07dd4b12 100644 --- a/poky/documentation/ref-manual/ref-terms.rst +++ b/poky/documentation/ref-manual/terms.rst @@ -21,7 +21,7 @@ universal, the list includes them just in case: 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 @@ universal, the list includes them just in case: :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 @@ universal, the list includes them just in case: 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 @@ universal, the list includes them just in case: 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 @@ universal, the list includes them just in case: 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 @@ universal, the list includes them just in case: 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 @@ universal, the list includes them just in case: 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 @@ universal, the list includes them just in case: 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 @@ universal, the list includes them just in case: 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 @@ universal, the list includes them just in case: 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 index e552351e3..8c6cc46b6 100644 --- a/poky/documentation/ref-manual/ref-variables.rst +++ b/poky/documentation/ref-manual/variables.rst @@ -239,7 +239,7 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. :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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. (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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. .. 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 @@ system and gives an overview of their function and contents. - 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 @@ system and gives an overview of their function and contents. ``${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 @@ system and gives an overview of their function and contents. ``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 @@ system and gives an overview of their function and contents. ``${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 @@ system and gives an overview of their function and contents. ``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 @@ system and gives an overview of their function and contents. ``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 @@ system and gives an overview of their function and contents. ``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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. .. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. :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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. - 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. :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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. :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 @@ system and gives an overview of their function and contents. :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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. ``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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. ${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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. :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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. ``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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. :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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. ``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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 @@ system and gives an overview of their function and contents. 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 index 5f7dba877..5f7dba877 100644 --- a/poky/documentation/ref-manual/ref-varlocality.rst +++ b/poky/documentation/ref-manual/varlocality.rst |