poky: subtree update:0ac99625bf..796be0593a
Alexander Kanavin (31):
netbase: upgrade 6.1 -> 6.2
meson: upgrade 0.55.1 -> 0.56.0
vulkan-samples: update to latest revision
libcap: update 2.44 -> 2.45
bind: upgrade 9.16.7 -> 9.16.9
quota: upgrade 4.05 -> 4.06
pango: upgrade 1.46.2 -> 1.48.0
elfutils: upgrade 0.181 -> 0.182
ifupdown: upgrade 0.8.35 -> 0.8.36
createrepo-c: upgrade 0.16.1 -> 0.16.2
acpica: upgrade 20200925 -> 20201113
grep: upgrade 3.5 -> 3.6
man-pages: upgrade 5.08 -> 5.09
stress-ng: upgrade 0.11.23 -> 0.11.24
libhandy: upgrade 1.0.1 -> 1.0.2
piglit: upgrade to latest revision
xkbcomp: upgrade 1.4.3 -> 1.4.4
lz4: upgrade 1.9.2 -> 1.9.3
bison: upgrade 3.7.3 -> 3.7.4
python3-setuptools-scm: fix upstream version check
cantarell-fonts: update 0.0.25 -> 0.201
meta/lib/oe/reproducible.py: gitsm:// works just as fine as git:// for timestamps
llvm: fix reproducibility
ruby: fix reproducibility
webkitgtk: fix reproducibility
ffmpeg: fix reproducibility
piglit: fix reproducibility
serf: do not install the static library
llvm: sort the lists in generated source reproducibibly
kea: fix reproducibility
poky.conf: do not write current date into distro version, use git hash instead
Andrej Valek (1):
kernel-dummy: fix executing unexpected tasks
Anuj Mittal (1):
releases.rst: add gatesgarth to current releases
Brett Warren (1):
libffi: add patch to revert clang VFP workaround
Chandana kalluri (1):
populate_sdk_ext: use SDK_CUSTOM_TEPLATECONF variable to enable custom templateconf.cfg
Changqing Li (1):
buildtools-tarball: add wic dependency into extended buildtools
Diego Sueiro (2):
modutils-initscripts: Fix modules.dep creation when USE_DEPMOD="0"
initscripts: Change execution order between checkroot and modutils
Dmitry Baryshkov (2):
linux-firmware: upgrade 20201022 -> 20201118
linux-firmware: package ath11k firmware
Fabio Berton (1):
mesa: Update 20.2.1 -> 20.2.4
Gratian Crisan (1):
kernel-module-split.bbclass: fix kernel modules getting marked as CONFFILES
Jack Mitchell (3):
Revert "connman: set service to conflict with systemd-networkd"
systemd-conf: add PACKAGECONFIG to enable/disable auto ethernet DHCP
systemd-conf: match ethernet interfaces by type rather than globbing
Joshua Watt (2):
bitbake: hashserv: client: Fix AF_UNIX path length limits
bitbake: hashserv: Fix broken AF_UNIX path length limit
Kai Kang (2):
systemd-systemctl-native: capable to call without argument
systemd.bbclass: update command to check systemctl available
Kevin Hao (1):
tune-octeontx2.inc: Add tune for Marvell OCTEON TX2 core
Li Wang (2):
qemu: CVE-2020-29129 CVE-2020-29130
qemu: CVE-2020-25624
Luca Boccassi (1):
dbus: move messagebus user to dbus-common package
Michael Halstead (1):
releases: conf: add link to 3.1.4, update to include 3.1.4
Nicolas Dechesne (19):
sphinx: add .vscode in .gitignore
{dev,kernel,sdk}-manual: replace hardcoded release version with &DISTRO;
sphinx: replace bitbake labels with references to corresponding title
brief-yoctoprojectqs: replace labels with references to section title
dev-manual: replace labels with references to section title
ref-manual: replace labels with references to section title
sdk-manual: replace labels with references to section title
overview-manual: remove unused labels
dev-manual: remove unused labels
sphinx: rename top level document in each manual
sphinx: use absolute paths for :doc: references
test-manual: remove 'test-manual' from filenames
toaster-manual: remove 'toaster-manual' from filenames
dev-manual: remove 'dev-manual' from filenames
kernel-dev: remove 'kernel-dev' from filenames
profile-manual: remove 'profile-manual' from filenames
overview-manual: remove 'overview-manual' from filenames
sdk-manual: remove 'sdk' from filenames
ref-manual: remove 'ref' from filenames
Paul Barker (5):
documentation: Simplify yocto_wiki links
documentation: Simplify yocto_git links
ref-manual: Simplify oe_git links
poky.conf: Add opensuseleap-15.2 and fedora-33 to tested distros
poky.conf: Drop fedora-30 from tested distros
Peter Kjellerstedt (2):
pseudo: Simplify pseudo_client_ignore_path_chroot()
bitbake.conf: Add all layers (from BBLAYERS) to PSEUDO_IGNORE_PATHS
Richard Purdie (8):
lz4: Use the new branch naming from upstream
Revert "bitbake.conf: Add all layers (from BBLAYERS) to PSEUDO_IGNORE_PATHS"
build-appliance-image: Update to master head revision
bitbake: Revert "fetch2: use relative symlinks for anything pulled from PREMIRRORS"
build-appliance-image: Update to master head revision
metadata_scm: Fix signature handling of METADATA_REVISION and METADATA_BRANCH
poky: Set SDK_VERSION explicitly
build-appliance-image: Update to master head revision
Ross Burton (9):
oeqa/devtool: use Yocto mirror for pv-1.5.3 tarball
image_types: remove obsolete tar comment
image_types: sort tarball file listings
package_manager/ipk: neaten OPKGLIBDIR logic
ldconfig-native: don't write auxiliary cache
package_manager/ipk: improve remove_packaging_data
oeqa/selftest/containerimage: update for improved cleanup
coreutils: add SUSE-specific issues to CVE whitelist
bitbake: msg: use safe YAML loader
Sinan Kaya (1):
poky-tiny: enable section removal
Tomasz Dziendzielski (1):
pseudo: Update to print PSEUDO_LOGFILE in abort message on path mismatches
sangeeta jain (1):
meta/lib/oeqa/manual/oe-core.json: Update test_bitbake_devshell
zangrc (3):
libinput: upgrade 1.16.3 -> 1.16.4
lighttpd: upgrade 1.4.55 -> 1.4.56
sysstat: upgrade 12.4.0 -> 12.4.1
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Change-Id: I65f2f1c9d44433f3e62609240012c42256679b51
diff --git a/poky/documentation/ref-manual/terms.rst b/poky/documentation/ref-manual/terms.rst
new file mode 100644
index 0000000..c07dd4b
--- /dev/null
+++ b/poky/documentation/ref-manual/terms.rst
@@ -0,0 +1,390 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+*******************
+Yocto Project Terms
+*******************
+
+Following is a list of terms and definitions users new to the Yocto Project
+development environment might find helpful. While some of these terms are
+universal, the list includes them just in case:
+
+.. glossary::
+
+ :term:`Append Files`
+ Files that append build information to a recipe file. Append files are
+ known as BitBake append files and ``.bbappend`` files. The OpenEmbedded
+ build system expects every append file to have a corresponding recipe
+ (``.bb``) file. Furthermore, the append file and corresponding recipe file
+ must use the same root filename. The filenames can differ only in the
+ file type suffix used (e.g. ``formfactor_0.0.bb`` and
+ ``formfactor_0.0.bbappend``).
+
+ 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/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
+ to allow for matching recipe names. For example, suppose you have an
+ append file named as follows:
+ ::
+
+ busybox_1.21.%.bbappend
+
+ That append file
+ would match any ``busybox_1.21.``\ x\ ``.bb`` version of the recipe. So,
+ the append file would match any of the following recipe names:
+
+ .. code-block:: shell
+
+ busybox_1.21.1.bb
+ busybox_1.21.2.bb
+ busybox_1.21.3.bb
+ busybox_1.21.10.bb
+ busybox_1.21.25.bb
+
+ .. note::
+
+ The use of the "%" character is limited in that it only works
+ directly in front of the .bbappend portion of the append file's
+ name. You cannot use the wildcard character in any other location of
+ the name.
+
+ :term:`BitBake`
+ The task executor and scheduler used by the OpenEmbedded build system to
+ build images. For more information on BitBake, see the :doc:`BitBake User
+ Manual <bitbake:index>`.
+
+ :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 :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/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.
+ Following are some examples that show how to create the directory. The
+ examples assume your :term:`Source Directory` is named ``poky``:
+
+ - Create the Build Directory inside your Source Directory and let
+ the name of the Build Directory default to ``build``:
+
+ .. code-block:: shell
+
+ $ cd $HOME/poky
+ $ source oe-init-build-env
+
+ - Create the Build Directory inside your home directory and
+ specifically name it ``test-builds``:
+
+ .. code-block:: shell
+
+ $ cd $HOME
+ $ source poky/oe-init-build-env test-builds
+
+ - Provide a directory path and specifically name the Build
+ Directory. Any intermediate folders in the pathname must exist.
+ This next example creates a Build Directory named
+ ``YP-POKYVERSION`` in your home directory within the existing
+ directory ``mybuilds``:
+
+ .. code-block:: shell
+
+ $ cd $HOME
+ $ source $HOME/poky/oe-init-build-env $HOME/mybuilds/YP-POKYVERSION
+
+ .. note::
+
+ By default, the Build Directory contains :term:`TMPDIR`, which is a
+ temporary directory the build system uses for its work. ``TMPDIR`` cannot
+ be under NFS. Thus, by default, the Build Directory cannot be under
+ NFS. However, if you need the Build Directory to be under NFS, you can
+ set this up by setting ``TMPDIR`` in your ``local.conf`` file to use a local
+ drive. Doing so effectively separates ``TMPDIR`` from :term:`TOPDIR`, which is the
+ Build Directory.
+
+ :term:`Build Host`
+ The system used to build images in a Yocto Project Development
+ environment. The build system is sometimes referred to as the development
+ host.
+
+ :term:`Classes`
+ 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/classes:Classes`" chapter. Class files end with the
+ ``.bbclass`` filename extension.
+
+ :term:`Configuration File`
+ Files that hold global definitions of variables, user-defined variables,
+ and hardware configuration information. These files tell the OpenEmbedded
+ build system what to build and what to put into the image to support a
+ particular platform.
+
+ Configuration files end with a ``.conf`` filename extension. The
+ :file:`conf/local.conf` configuration file in the :term:`Build Directory`
+ contains user-defined variables that affect every build. The
+ :file:`meta-poky/conf/distro/poky.conf` configuration file defines Yocto
+ "distro" configuration variables used only when building with this
+ policy. Machine configuration files, which are located throughout the
+ :term:`Source Directory`, define variables for specific hardware and are
+ only used when building for that target (e.g. the
+ :file:`machine/beaglebone.conf` configuration file defines variables for
+ the Texas Instruments ARM Cortex-A8 development board).
+
+ :term:`Container Layer`
+ Layers that hold other layers. An example of a container layer is
+ OpenEmbedded's `meta-openembedded
+ <https://github.com/openembedded/meta-openembedded>`_ layer. The
+ ``meta-openembedded`` layer contains many ``meta-*`` layers.
+
+ :term:`Cross-Development Toolchain`
+ In general, a cross-development toolchain is a collection of software
+ development tools and utilities that run on one architecture and allow you
+ to develop software for a different, or targeted, architecture. These
+ toolchains contain cross-compilers, linkers, and debuggers that are
+ specific to the target architecture.
+
+ The Yocto Project supports two different cross-development toolchains:
+
+ - A toolchain only used by and within BitBake when building an image for a
+ target architecture.
+
+ - A relocatable toolchain used outside of BitBake by developers when
+ developing applications that will run on a targeted device.
+
+ 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/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 :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 :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/images:Images`" chapter.
+
+ :term:`Layer`
+ A collection of related recipes. Layers allow you to consolidate related
+ metadata to customize your build. Layers also isolate information used
+ when building for multiple architectures. Layers are hierarchical in
+ their ability to override previous specifications. You can include any
+ number of available layers from the Yocto Project and customize the build
+ by adding your layers after them. You can search the Layer Index for
+ layers used within Yocto Project.
+
+ For introductory information on layers, see the
+ ":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/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)
+ Developer's Guide.
+
+ :term:`Metadata`
+ A key element of the Yocto Project is the Metadata that
+ is used to construct a Linux distribution and is contained in the
+ files that the :term:`OpenEmbedded Build System`
+ parses when building an image. In general, Metadata includes recipes,
+ configuration files, and other information that refers to the build
+ instructions themselves, as well as the data used to control what
+ things get built and the effects of the build. Metadata also includes
+ commands and data used to indicate what versions of software are
+ used, from where they are obtained, and changes or additions to the
+ software itself (patches or auxiliary files) that are used to fix
+ bugs or customize the software for use in a particular situation.
+ OpenEmbedded-Core is an important set of validated metadata.
+
+ 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 </yocto-kernel-cache>`
+ Git repository.
+
+ :term:`OpenEmbedded-Core (OE-Core)`
+ OE-Core is metadata comprised of
+ foundational recipes, classes, and associated files that are meant to
+ be common among many different OpenEmbedded-derived systems,
+ including the Yocto Project. OE-Core is a curated subset of an
+ original repository developed by the OpenEmbedded community that has
+ been pared down into a smaller, core set of continuously validated
+ recipes. The result is a tightly controlled and an quality-assured
+ core set of recipes.
+
+ You can see the Metadata in the ``meta`` directory of the Yocto
+ Project :yocto_git:`Source Repositories </poky>`.
+
+ :term:`OpenEmbedded Build System`
+ The build system specific to the Yocto
+ Project. The OpenEmbedded build system is based on another project
+ known as "Poky", which uses :term:`BitBake` as the task
+ executor. Throughout the Yocto Project documentation set, the
+ OpenEmbedded build system is sometimes referred to simply as "the
+ build system". If other build systems, such as a host or target build
+ system are referenced, the documentation clearly states the
+ difference.
+
+ .. note::
+
+ For some historical information about Poky, see the :term:`Poky` term.
+
+ :term:`Package`
+ In the context of the Yocto Project, this term refers to a
+ recipe's packaged output produced by BitBake (i.e. a "baked recipe").
+ A package is generally the compiled binaries produced from the
+ recipe's sources. You "bake" something by running it through BitBake.
+
+ 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/system-requirements:required packages for the build host`"
+ section are compiled binaries that, when installed, add functionality to
+ your Linux distribution.
+
+ Another point worth noting is that historically within the Yocto
+ Project, recipes were referred to as packages - thus, the existence
+ of several BitBake variables that are seemingly mis-named, (e.g.
+ :term:`PR`, :term:`PV`, and
+ :term:`PE`).
+
+ :term:`Package Groups`
+ Arbitrary groups of software Recipes. You use
+ package groups to hold recipes that, when built, usually accomplish a
+ single task. For example, a package group could contain the recipes
+ for a company's proprietary or value-add software. Or, the package
+ group could contain the recipes that enable graphics. A package group
+ is really just another recipe. Because package group files are
+ recipes, they end with the ``.bb`` filename extension.
+
+ :term:`Poky`
+ Poky, which is pronounced *Pock*-ee, is a reference embedded
+ distribution and a reference test configuration. Poky provides the
+ following:
+
+ - A base-level functional distro used to illustrate how to customize
+ a distribution.
+
+ - A means by which to test the Yocto Project components (i.e. Poky
+ is used to validate the Yocto Project).
+
+ - A vehicle through which you can download the Yocto Project.
+
+ Poky is not a product level distro. Rather, it is a good starting
+ point for customization.
+
+ .. note::
+
+ Poky began as an open-source project initially developed by
+ OpenedHand. OpenedHand developed Poky from the existing
+ OpenEmbedded build system to create a commercially supportable
+ build system for embedded Linux. After Intel Corporation acquired
+ OpenedHand, the poky project became the basis for the Yocto
+ Project's build system.
+
+ :term:`Recipe`
+ A set of instructions for building packages. A recipe
+ describes where you get source code, which patches to apply, how to
+ configure the source, how to compile it and so on. Recipes also
+ describe dependencies for libraries or for other recipes. Recipes
+ represent the logical unit of execution, the software to build, the
+ images to build, and use the ``.bb`` file extension.
+
+ :term:`Reference Kit`
+ A working example of a system, which includes a
+ :term:`BSP<Board Support Package (BSP)>` as well as a
+ :term:`build host<Build Host>` and other components, that can
+ work on specific hardware.
+
+ :term:`Source Directory`
+ This term refers to the directory structure
+ created as a result of creating a local copy of the ``poky`` Git
+ repository ``git://git.yoctoproject.org/poky`` or expanding a
+ released ``poky`` tarball.
+
+ .. note::
+
+ Creating a local copy of the
+ poky
+ Git repository is the recommended method for setting up your
+ Source Directory.
+
+ Sometimes you might hear the term "poky directory" used to refer to
+ this directory structure.
+
+ .. note::
+
+ The OpenEmbedded build system does not support file or directory
+ names that contain spaces. Be sure that the Source Directory you
+ use does not contain these types of names.
+
+ The Source Directory contains BitBake, Documentation, Metadata and
+ other files that all support the Yocto Project. Consequently, you
+ must have the Source Directory in place on your development system in
+ order to do any development using the Yocto Project.
+
+ When you create a local copy of the Git repository, you can name the
+ repository anything you like. Throughout much of the documentation,
+ "poky" is used as the name of the top-level folder of the local copy
+ of the poky Git repository. So, for example, cloning the ``poky`` Git
+ repository results in a local Git repository whose top-level folder
+ is also named "poky".
+
+ While it is not recommended that you use tarball expansion to set up
+ the Source Directory, if you do, the top-level directory name of the
+ Source Directory is derived from the Yocto Project release tarball.
+ For example, downloading and unpacking
+ :yocto_dl:`/releases/yocto/&DISTRO_REL_TAG;/&YOCTO_POKY;.tar.bz2`
+ results in a Source Directory whose root folder is named ``poky``.
+
+ It is important to understand the differences between the Source
+ Directory created by unpacking a released tarball as compared to
+ cloning ``git://git.yoctoproject.org/poky``. When you unpack a
+ tarball, you have an exact copy of the files based on the time of
+ release - a fixed release point. Any changes you make to your local
+ files in the Source Directory are on top of the release and will
+ remain local only. On the other hand, when you clone the ``poky`` Git
+ repository, you have an active development repository with access to
+ the upstream repository's branches and tags. In this case, any local
+ changes you make to the local Source Directory can be later applied
+ to active development branches of the upstream ``poky`` Git
+ repository.
+
+ For more information on concepts related to Git repositories,
+ branches, and tags, see the
+ ":ref:`overview-manual/development-environment:repositories, tags, and branches`"
+ section in the Yocto Project Overview and Concepts Manual.
+
+ :term:`Task`
+ A unit of execution for BitBake (e.g.
+ :ref:`ref-tasks-compile`,
+ :ref:`ref-tasks-fetch`,
+ :ref:`ref-tasks-patch`, and so forth).
+
+ :term:`Toaster`
+ A web interface to the Yocto Project's :term:`OpenEmbedded Build System`.
+ 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/index`.
+
+ :term:`Upstream`
+ A reference to source code or repositories that are not
+ local to the development system but located in a master area that is
+ controlled by the maintainer of the source code. For example, in
+ order for a developer to work on a particular piece of code, they
+ need to first get a copy of it from an "upstream" source.