@@ -1356,7 +1356,7 @@ Project Reference Manual.
- :term:`EXTRA_IMAGECMD`:
Specifies additional options for image creation commands. In this
example, the "-lnp " option is used when creating the
- `JFFS2 <https://en.wikipedia.org/wiki/JFFS2>`__ image.
+ :wikipedia:`JFFS2 <JFFS2>` image.
- :term:`WKS_FILE`: The location of
the :ref:`Wic kickstart <ref-manual/kickstart:openembedded kickstart (\`\`.wks\`\`) reference>` file used
@@ -106,6 +106,7 @@ extlinks = {
'oe_wiki': ('https://www.openembedded.org/wiki%s', None),
'oe_layerindex': ('https://layers.openembedded.org%s', None),
'oe_layer': ('https://layers.openembedded.org/layerindex/branch/master/layer%s', None),
+ 'wikipedia': ('https://en.wikipedia.org/wiki/%s', None),
}
# Intersphinx config to use cross reference with BitBake user manual
@@ -7157,8 +7157,7 @@ system. This section provides information for RPM, IPK, and DEB.
Using RPM
^^^^^^^^^
-The `Dandified Packaging
-Tool <https://en.wikipedia.org/wiki/DNF_(software)>`__ (DNF) performs
+The :wikipedia:`Dandified Packaging <DNF_(software)>` (DNF) performs
runtime package management of RPM packages. In order to use DNF for
runtime package management, you must perform an initial setup on the
target machine for cases where the ``PACKAGE_FEED_*`` variables were not
@@ -7501,7 +7500,7 @@ test. Here is what you have to do for each recipe:
Creating Node Package Manager (NPM) Packages
--------------------------------------------
-`NPM <https://en.wikipedia.org/wiki/Npm_(software)>`__ is a package
+:wikipedia:`NPM <Npm_(software)>` is a package
manager for the JavaScript programming language. The Yocto Project
supports the NPM :ref:`fetcher <bitbake:bitbake-user-manual/bitbake-user-manual-fetching:fetchers>`. You can
use this fetcher in combination with
@@ -9374,8 +9373,7 @@ This command writes the following files in the current directory:
- ``task-depends.dot``: A graph showing dependencies between tasks.
-The graphs are in
-`DOT <https://en.wikipedia.org/wiki/DOT_%28graph_description_language%29>`__
+The graphs are in :wikipedia:`DOT <DOT_%28graph_description_language%29>`
format and can be converted to images (e.g. using the ``dot`` tool from
`Graphviz <https://www.graphviz.org/>`__).
@@ -11435,7 +11433,7 @@ Vulnerabilities in Poky and OE-Core
The Yocto Project has an infrastructure to track and address unfixed
known security vulnerabilities, as tracked by the public
-`Common Vulnerabilities and Exposures (CVE) <https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures>`__
+:wikipedia:`Common Vulnerabilities and Exposures (CVE) <Common_Vulnerabilities_and_Exposures>`
database.
The Yocto Project maintains a `list of known vulnerabilities
@@ -11791,7 +11789,7 @@ Instructions on how to set it up are in the README document.
Using Wayland and Weston
========================
-`Wayland <https://en.wikipedia.org/wiki/Wayland_(display_server_protocol)>`__
+:wikipedia:`Wayland <Wayland_(display_server_protocol)>`
is a computer display server protocol that provides a method for
compositing window managers to communicate directly with applications
and video hardware and expects them to communicate with input hardware
@@ -11800,20 +11798,18 @@ in better control over graphics frame rendering than an application
might otherwise achieve.
The Yocto Project provides the Wayland protocol libraries and the
-reference
-`Weston <https://en.wikipedia.org/wiki/Wayland_(display_server_protocol)#Weston>`__
+reference :wikipedia:`Weston <Wayland_(display_server_protocol)#Weston>`
compositor as part of its release. You can find the integrated packages
in the ``meta`` layer of the :term:`Source Directory`.
Specifically, you
can find the recipes that build both Wayland and Weston at
``meta/recipes-graphics/wayland``.
-You can build both the Wayland and Weston packages for use only with
-targets that accept the `Mesa 3D and Direct Rendering
-Infrastructure <https://en.wikipedia.org/wiki/Mesa_(computer_graphics)>`__,
-which is also known as Mesa DRI. This implies that you cannot build and
-use the packages if your target uses, for example, the Intel Embedded
-Media and Graphics Driver (Intel EMGD) that overrides Mesa DRI.
+You can build both the Wayland and Weston packages for use only with targets
+that accept the :wikipedia:`Mesa 3D and Direct Rendering Infrastructure
+<Mesa_(computer_graphics)>`, which is also known as Mesa DRI. This implies that
+you cannot build and use the packages if your target uses, for example, the
+Intel Embedded Media and Graphics Driver (Intel EMGD) that overrides Mesa DRI.
.. note::
@@ -273,7 +273,7 @@ For Linux (WSL 2).
.. note::
The Yocto Project is not compatible with version 1 of
- `Windows Subsystem for Linux <https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux>`__.
+ :wikipedia:`Windows Subsystem for Linux <Windows_Subsystem_for_Linux>`.
It is compatible but neither officially supported nor validated with
WSL 2. If you still decide to use WSL please upgrade to
`WSL 2 <https://learn.microsoft.com/en-us/windows/wsl/install>`__.
@@ -1043,7 +1043,7 @@ Using ``menuconfig``
The easiest way to define kernel configurations is to set them through
the ``menuconfig`` tool. This tool provides an interactive method with
which to set kernel configurations. For general information on
-``menuconfig``, see https://en.wikipedia.org/wiki/Menuconfig.
+``menuconfig``, see :wikipedia:`Menuconfig`.
To use the ``menuconfig`` tool in the Yocto Project development
environment, you must do the following:
@@ -108,7 +108,7 @@ Packaging Changes
The following packaging changes have occurred.
-- The `Epiphany <https://en.wikipedia.org/wiki/GNOME_Web>`__ browser
+- The :wikipedia:`Epiphany <GNOME_Web>` browser
has been dropped from ``packagegroup-self-hosted`` as it has not been
needed inside ``build-appliance-image`` for quite some time and was
causing resource problems.
@@ -183,8 +183,8 @@ a new :term:`KERNEL_DEBUG_TIMESTAMPS` variable to "1".
Supported host distribution changes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Support for `AlmaLinux <https://en.wikipedia.org/wiki/AlmaLinux>`__
- hosts replacing `CentOS <https://en.wikipedia.org/wiki/CentOS>`__.
+- Support for :wikipedia:`AlmaLinux <AlmaLinux>`
+ hosts replacing :wikipedia:`CentOS <CentOS>`.
The following distribution versions were dropped: CentOS 8, Ubuntu 16.04 and Fedora 30, 31 and 32.
- ``gcc`` version 7.5 is now required at minimum on the build host. For older
@@ -32,7 +32,7 @@ New Features / Enhancements in 4.0
:ref:`overlayfs-etc <ref-classes-overlayfs-etc>` classes and
``overlayroot`` support in the :term:`Initramfs` framework to make it easier to
overlay read-only filesystems (for example) with
- `OverlayFS <https://en.wikipedia.org/wiki/OverlayFS>`__.
+ :wikipedia:`OverlayFS <OverlayFS>`.
- Inclusive language adjustments to some variable names - see the
:ref:`4.0 migration guide <migration-4.0-inclusive-language>` for details.
@@ -104,7 +104,7 @@ New Features / Enhancements in 4.0
- Shared state (sstate) improvements:
- - Switched to `ZStandard (zstd) <https://en.wikipedia.org/wiki/Zstd>`__ instead
+ - Switched to :wikipedia:`ZStandard (zstd) <Zstd>` instead
of Gzip, for better performance.
- Allow validation of sstate signatures against a list of keys
- Improved error messages and exception handling
@@ -110,7 +110,7 @@ Class files (``.bbclass``) contain information that is useful to share
between recipes files. An example is the
:ref:`autotools <ref-classes-autotools>` class,
which contains common settings for any application that is built with
-the `GNU Autotools <https://en.wikipedia.org/wiki/GNU_Autotools>`__.
+the :wikipedia:`GNU Autotools <GNU_Autotools>`.
The ":ref:`ref-manual/classes:Classes`" chapter in the Yocto Project
Reference Manual provides details about classes and how to use them.
@@ -2061,7 +2061,7 @@ dependencies, you must manually declare the dependencies.
located. For each shared library, the package that contains the
shared library is registered as providing the shared library. More
specifically, the package is registered as providing the
- `soname <https://en.wikipedia.org/wiki/Soname>`__ of the library. The
+ :wikipedia:`soname <Soname>` of the library. The
resulting shared-library-to-package mapping is saved globally in
:term:`PKGDATA_DIR` by the
:ref:`ref-tasks-packagedata`
@@ -39,10 +39,9 @@ Linus Torvalds in 1991. Conversely, a good example of a non-open source
project is the Windows family of operating systems developed by
Microsoft Corporation.
-Wikipedia has a good historical description of the Open Source
-Philosophy `here <https://en.wikipedia.org/wiki/Open_source>`__. You can
-also find helpful information on how to participate in the Linux
-Community
+Wikipedia has a good :wikipedia:`historical description of the Open Source
+Philosophy <Open_source>`. You can also find helpful information on how
+to participate in the Linux Community
`here <https://www.kernel.org/doc/html/latest/process/index.html>`__.
The Development Host
@@ -608,18 +607,16 @@ licensing structures in place. License evolution for both Open Source
and Free Software has an interesting history. If you are interested in
this history, you can find basic information here:
-- `Open source license
- history <https://en.wikipedia.org/wiki/Open-source_license>`__
+- :wikipedia:`Open source license history <Open-source_license>`
-- `Free software license
- history <https://en.wikipedia.org/wiki/Free_software_license>`__
+- :wikipedia:`Free software license history <Free_software_license>`
In general, the Yocto Project is broadly licensed under the
Massachusetts Institute of Technology (MIT) License. MIT licensing
permits the reuse of software within proprietary software as long as the
license is distributed with that software. Patches to the Yocto Project
follow the upstream licensing scheme. You can find information on the
-MIT license `here <https://en.wikipedia.org/wiki/MIT_License>`__.
+MIT license :wikipedia:`here <MIT_License>`.
When you build an image using the Yocto Project, the build process uses
a known list of licenses to ensure compliance. You can find this list in
@@ -85,7 +85,7 @@ about the variable flags (varflags) that help control archive creation.
======================
The :ref:`autotools* <ref-classes-autotools>` classes support packages built with the
-`GNU Autotools <https://en.wikipedia.org/wiki/GNU_Autotools>`__.
+:wikipedia:`GNU Autotools <GNU_Autotools>`.
The ``autoconf``, ``automake``, and ``libtool`` packages bring
standardization. This class defines a set of tasks (e.g. ``configure``,
@@ -1775,8 +1775,8 @@ is not needed.
``npm.bbclass``
===============
-Provides support for building Node.js software fetched using the `node
-package manager (NPM) <https://en.wikipedia.org/wiki/Npm_(software)>`__.
+Provides support for building Node.js software fetched using the
+:wikipedia:`node package manager (NPM) <Npm_(software)>`.
.. note::
@@ -126,10 +126,9 @@ metadata, as extra layers can define their own:
- *3g:* Include support for cellular data.
-- *acl:* Include
- `Access Control List <https://en.wikipedia.org/wiki/Access-control_list>`__ support.
+- *acl:* Include :wikipedia:`Access Control List <Access-control_list>` support.
-- *alsa:* Include `Advanced Linux Sound Architecture <https://en.wikipedia.org/wiki/Advanced_Linux_Sound_Architecture>`__
+- *alsa:* Include :wikipedia:`Advanced Linux Sound Architecture <Advanced_Linux_Sound_Architecture>`
support (OSS compatibility kernel modules installed if available).
- *api-documentation:* Enables generation of API documentation during
@@ -167,7 +166,7 @@ metadata, as extra layers can define their own:
- *multiarch:* Enable building applications with multiple architecture
support.
-- *ld-is-gold:* Use the `gold <https://en.wikipedia.org/wiki/Gold_(linker)>`__
+- *ld-is-gold:* Use the :wikipedia:`gold <Gold_(linker)>`
linker instead of the standard GCC linker (bfd).
- *ldconfig:* Include support for ldconfig and ``ld.so.conf`` on the
@@ -190,14 +189,14 @@ metadata, as extra layers can define their own:
- *overlayfs:* Include `OverlayFS <https://docs.kernel.org/filesystems/overlayfs.html>`__
support.
-- *pam:* Include `Pluggable Authentication Module (PAM) <https://en.wikipedia.org/wiki/Pluggable_authentication_module>`__
+- *pam:* Include :wikipedia:`Pluggable Authentication Module (PAM) <Pluggable_authentication_module>`
support.
- *pci:* Include PCI bus support.
- *pcmcia:* Include PCMCIA/CompactFlash support.
-- *polkit:* Include `Polkit <https://en.wikipedia.org/wiki/Polkit>`__ support.
+- *polkit:* Include :wikipedia:`Polkit <Polkit>` support.
- *ppp:* Include PPP dialup support.
@@ -210,11 +209,11 @@ metadata, as extra layers can define their own:
`PulseAudio <https://www.freedesktop.org/wiki/Software/PulseAudio/>`__.
- *selinux:* Include support for
- `Security-Enhanced Linux (SELinux) <https://en.wikipedia.org/wiki/Security-Enhanced_Linux>`__
+ :wikipedia:`Security-Enhanced Linux (SELinux) <Security-Enhanced_Linux>`
(requires `meta-selinux <https://layers.openembedded.org/layerindex/layer/meta-selinux/>`__).
- *seccomp:* Enables building applications with
- `seccomp <https://en.wikipedia.org/wiki/Seccomp>`__ support, to
+ :wikipedia:`seccomp <Seccomp>` support, to
allow them to strictly restrict the system calls that they are allowed
to invoke.
@@ -236,11 +235,10 @@ metadata, as extra layers can define their own:
directories into their respective counterparts in the ``/usr``
directory to provide better package and application compatibility.
-- *vfat:* Include `FAT filesystem <https://en.wikipedia.org/wiki/File_Allocation_Table>`__
+- *vfat:* Include :wikipedia:`FAT filesystem <File_Allocation_Table>`
support.
-- *vulkan:* Include support for the
- `Vulkan API <https://en.wikipedia.org/wiki/Vulkan>`__.
+- *vulkan:* Include support for the :wikipedia:`Vulkan API <Vulkan>`.
- *wayland:* Include the Wayland display server protocol and the
library that supports it.
@@ -250,7 +248,7 @@ metadata, as extra layers can define their own:
- *x11:* Include the X server and libraries.
- *xattr:* Include support for
- `extended file attributes <https://en.wikipedia.org/wiki/Extended_file_attributes>`__.
+ :wikipedia:`extended file attributes <Extended_file_attributes>`.
- *zeroconf:* Include support for
`zero configuration networking <https://en.wikipedia.org/wiki/Zero-configuration_networking>`__.
@@ -177,7 +177,7 @@ the ``part`` and ``partition`` commands:
- ``--part-type``: This option is a Wic-specific option that
specifies the partition type globally unique identifier (GUID) for
GPT partitions. You can find the list of partition type GUIDs at
- https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs.
+ :wikipedia:`GUID_Partition_Table#Partition_type_GUIDs`.
- ``--use-uuid``: This option is a Wic-specific option that causes
Wic to generate a random GUID for the partition. The generated
@@ -330,7 +330,7 @@ universal, the list includes them just in case:
This can be used by the recipients of the software to assess
their exposure to license compliance and security vulnerability issues.
- See the `Software Supply Chain <https://en.wikipedia.org/wiki/Software_supply_chain>`__
+ See the :wikipedia:`Software Supply Chain <Software_supply_chain>`
article on Wikipedia for more details.
The OpenEmbedded Build System can generate such documentation for your
@@ -405,7 +405,7 @@ universal, the list includes them just in case:
<https://spdx.dev/>`__ and is used by the OpenEmbedded Build System to
provide an :term:`SBOM` associated to each a software image.
- For details, see Wikipedia's `SPDX page <https://en.wikipedia.org/wiki/Software_Package_Data_Exchange>`__
+ For details, see Wikipedia's :wikipedia:`SPDX page <Software_Package_Data_Exchange>`
and the ":ref:`dev-manual/common-tasks:creating a software bill of materials`"
section of the Development Tasks manual.
@@ -3699,8 +3699,8 @@ system and gives an overview of their function and contents.
:term:`Initramfs`
An Initial RAM Filesystem (:term:`Initramfs`) is an optionally compressed
- `cpio <https://en.wikipedia.org/wiki/Cpio>`__ archive which is extracted
- by the Linux kernel into RAM in a special `tmpfs <https://en.wikipedia.org/wiki/Tmpfs>`__
+ :wikipedia:`cpio <Cpio>` archive which is extracted
+ by the Linux kernel into RAM in a special :wikipedia:`tmpfs <Tmpfs>`
instance, used as the initial root filesystem.
This is a replacement for the legacy init RAM disk ("initrd")
@@ -3756,7 +3756,7 @@ system and gives an overview of their function and contents.
``meta/conf/bitbake.conf`` configuration file in the
:term:`Source Directory`, is "cpio.gz". The Linux kernel's
:term:`Initramfs` mechanism, as opposed to the initial RAM filesystem
- `initrd <https://en.wikipedia.org/wiki/Initrd>`__ mechanism, expects
+ :wikipedia:`initrd <Initrd>` mechanism, expects
an optionally compressed cpio archive.
:term:`INITRAMFS_IMAGE`
@@ -176,9 +176,8 @@ the installed SDKs to update the installed SDKs by using the
``devtool sdk-update`` command:
1. Create a directory that can be shared over HTTP or HTTPS. You can do
- this by setting up a web server such as an `Apache HTTP
- Server <https://en.wikipedia.org/wiki/Apache_HTTP_Server>`__ or
- `Nginx <https://en.wikipedia.org/wiki/Nginx>`__ server in the cloud
+ this by setting up a web server such as an :wikipedia:`Apache HTTP Server
+ <Apache_HTTP_Server>` or :wikipedia:`Nginx <Nginx>` server in the cloud
to host the directory. This directory must contain the published SDK.
2. Set the
@@ -262,9 +261,8 @@ source, you need to do a number of things:
2. Expose the ``sstate-cache`` directory produced by the build.
Typically, you expose this directory by making it available through
- an `Apache HTTP
- Server <https://en.wikipedia.org/wiki/Apache_HTTP_Server>`__ or
- `Nginx <https://en.wikipedia.org/wiki/Nginx>`__ server.
+ an :wikipedia:`Apache HTTP Server <Apache_HTTP_Server>` or
+ :wikipedia:`Nginx <Nginx>` server.
3. Set the appropriate configuration so that the produced SDK knows how
to find the configuration. The variable you need to set is
@@ -11,9 +11,9 @@ Autotools-Based Projects
========================
Once you have a suitable :ref:`sdk-manual/intro:the cross-development toolchain`
-installed, it is very easy to develop a project using the `GNU
-Autotools-based <https://en.wikipedia.org/wiki/GNU_Build_System>`__
-workflow, which is outside of the :term:`OpenEmbedded Build System`.
+installed, it is very easy to develop a project using the :wikipedia:`GNU
+Autotools-based <GNU_Build_System>` workflow, which is outside of the
+:term:`OpenEmbedded Build System`.
The following figure presents a simple Autotools workflow.
@@ -74,8 +74,7 @@ simple JSON files.
The project uses Buildbot for historical reasons but also because
many of the project developers have knowledge of Python. It is
possible to use the outer layers from another Continuous Integration
- (CI) system such as
- `Jenkins <https://en.wikipedia.org/wiki/Jenkins_(software)>`__
+ (CI) system such as :wikipedia:`Jenkins <Jenkins_(software)>`
instead of Buildbot.
The following figure shows the Yocto Project Autobuilder stack with a
@@ -28,8 +28,7 @@ at :oe_layerindex:`/`. You can find the code for this
layer index's web application at :yocto_git:`/layerindex-web/`.
When you tie a layer source into Toaster, it can query the layer source
-through a
-`REST <https://en.wikipedia.org/wiki/Representational_state_transfer>`__
+through a :wikipedia:`REST <Representational_state_transfer>`
API, store the information about the layers in the Toaster database, and
then show the information to users. Users are then able to view that
information and build layers from Toaster itself without having to
@@ -369,8 +368,8 @@ Remote Toaster Monitoring
Toaster has an API that allows remote management applications to
directly query the state of the Toaster server and its builds in a
machine-to-machine manner. This API uses the
-`REST <https://en.wikipedia.org/wiki/Representational_state_transfer>`__
-interface and the transfer of JSON files. For example, you might monitor
+:wikipedia:`REST <Representational_state_transfer>` interface and the
+transfer of JSON files. For example, you might monitor
a build inside a container through well supported known HTTP ports in
order to easily access a Toaster server inside the container. In this
example, when you use this direct JSON API, you avoid having web page