mirror of
git://git.yoctoproject.org/poky.git
synced 2025-07-19 21:09:03 +02:00
manuals: add shortcut for Wikipedia links
(From yocto-docs rev: 47101c15cce156ab71683cac1c42ab94f43bdbee) Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Michael Opdenacker
Richard Purdie
parent
ceb169bd59
commit
3a7dd1d368
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user