[PATCH 1/2] documentation: ref-manual: order alphabetically the glossary sources

* [PATCH 1/2] documentation: ref-manual: order alphabetically the glossary sources
@ 2021-07-26 15:29 Quentin Schulz
  2021-07-26 15:29 ` [PATCH 2/2] documentation: ref-manual: force glossary output to be alphabetically sorted quentin.schulz
  0 siblings, 1 reply; 4+ messages in thread
From: Quentin Schulz @ 2021-07-26 15:29 UTC (permalink / raw)
  Cc: Quentin Schulz, docs, Quentin Schulz

This reorders a few entry so that they are alphabetically sorted.

Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Signed-off-by: Quentin Schulz <foss@0leil.net>
---
 documentation/ref-manual/terms.rst     |  26 ++--
 documentation/ref-manual/variables.rst | 196 ++++++++++++-------------
 2 files changed, 111 insertions(+), 111 deletions(-)

diff --git a/documentation/ref-manual/terms.rst b/documentation/ref-manual/terms.rst
index 54469e507..545100efa 100644
--- a/documentation/ref-manual/terms.rst
+++ b/documentation/ref-manual/terms.rst
@@ -213,19 +213,6 @@ universal, the list includes them just in case:
       :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
@@ -240,6 +227,19 @@ universal, the list includes them just in case:
 
          For some historical information about Poky, see the :term:`Poky` term.
 
+   :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:`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").
diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
index 3de37a1ab..e5525e922 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -1306,6 +1306,40 @@ system and gives an overview of their function and contents.
       the recipe will be skipped, and if the build system attempts to build
       the recipe then an error will be triggered.
 
+   :term:`COPY_LIC_DIRS`
+      If set to "1" along with the
+      :term:`COPY_LIC_MANIFEST` variable, the
+      OpenEmbedded build system copies into the image the license files,
+      which are located in ``/usr/share/common-licenses``, for each
+      package. The license files are placed in directories within the image
+      itself during build time.
+
+      .. note::
+
+         The :term:`COPY_LIC_DIRS` does not offer a path for adding licenses for
+         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/common-tasks:providing license text`"
+         section in the Yocto Project Development Tasks Manual for
+         information on providing license text.
+
+   :term:`COPY_LIC_MANIFEST`
+      If set to "1", the OpenEmbedded build system copies the license
+      manifest for the image to
+      ``/usr/share/common-licenses/license.manifest`` within the image
+      itself during build time.
+
+      .. note::
+
+         The :term:`COPY_LIC_MANIFEST` does not offer a path for adding licenses for
+         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/common-tasks:providing license text`"
+         section in the Yocto Project Development Tasks Manual for
+         information on providing license text.
+
    :term:`COPYLEFT_LICENSE_EXCLUDE`
       A space-separated list of licenses to exclude from the source
       archived by the :ref:`archiver <ref-classes-archiver>` class. In
@@ -1374,40 +1408,6 @@ system and gives an overview of their function and contents.
       is set by the :ref:`copyleft_filter <ref-classes-copyleft_filter>`
       class, which is inherited by the ``archiver`` class.
 
-   :term:`COPY_LIC_DIRS`
-      If set to "1" along with the
-      :term:`COPY_LIC_MANIFEST` variable, the
-      OpenEmbedded build system copies into the image the license files,
-      which are located in ``/usr/share/common-licenses``, for each
-      package. The license files are placed in directories within the image
-      itself during build time.
-
-      .. note::
-
-         The :term:`COPY_LIC_DIRS` does not offer a path for adding licenses for
-         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/common-tasks:providing license text`"
-         section in the Yocto Project Development Tasks Manual for
-         information on providing license text.
-
-   :term:`COPY_LIC_MANIFEST`
-      If set to "1", the OpenEmbedded build system copies the license
-      manifest for the image to
-      ``/usr/share/common-licenses/license.manifest`` within the image
-      itself during build time.
-
-      .. note::
-
-         The :term:`COPY_LIC_MANIFEST` does not offer a path for adding licenses for
-         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/common-tasks:providing license text`"
-         section in the Yocto Project Development Tasks Manual for
-         information on providing license text.
-
    :term:`CORE_IMAGE_EXTRA_INSTALL`
       Specifies the list of packages to be added to the image. You should
       only set this variable in the ``local.conf`` configuration file found
@@ -2209,16 +2209,6 @@ system and gives an overview of their function and contents.
          To add packages to the root filesystem, see the various
          :term:`RDEPENDS` and :term:`RRECOMMENDS` variables.
 
-   :term:`EXTRANATIVEPATH`
-      A list of subdirectories of
-      ``${``\ :term:`STAGING_BINDIR_NATIVE`\ ``}``
-      added to the beginning of the environment variable ``PATH``. As an
-      example, the following prepends
-      "${STAGING_BINDIR_NATIVE}/foo:${STAGING_BINDIR_NATIVE}/bar:" to
-      ``PATH``::
-
-         EXTRANATIVEPATH = "foo bar"
-
    :term:`EXTRA_OECMAKE`
       Additional `CMake <https://cmake.org/overview/>`__ options. See the
       :ref:`cmake <ref-classes-cmake>` class for additional information.
@@ -2275,6 +2265,16 @@ system and gives an overview of their function and contents.
          At present, ``passwd-expire`` may only work for remote logins when
          using OpenSSH and not dropbear as an SSH server.
 
+   :term:`EXTRANATIVEPATH`
+      A list of subdirectories of
+      ``${``\ :term:`STAGING_BINDIR_NATIVE`\ ``}``
+      added to the beginning of the environment variable ``PATH``. As an
+      example, the following prepends
+      "${STAGING_BINDIR_NATIVE}/foo:${STAGING_BINDIR_NATIVE}/bar:" to
+      ``PATH``::
+
+         EXTRANATIVEPATH = "foo bar"
+
    :term:`FEATURE_PACKAGES`
       Defines one or more packages to include in an image when a specific
       item is included in :term:`IMAGE_FEATURES`.
@@ -2568,10 +2568,6 @@ system and gives an overview of their function and contents.
       Specifies the signature algorithm used in creating the FIT Image.
       For e.g. rsa2048.
 
-   :term:`FIT_SIGN_NUMBITS`
-      Size of private key in number of bits used in fitImage. The default
-      value is "2048".
-
    :term:`FIT_SIGN_INDIVIDUAL`
       If set to "1", then the :ref:`kernel-fitimage <ref-classes-kernel-fitimage>`
       class will sign the kernel, dtb and ramdisk images individually in addition
@@ -2579,6 +2575,10 @@ system and gives an overview of their function and contents.
       intending to verify signatures in another context than booting via
       U-Boot.
 
+   :term:`FIT_SIGN_NUMBITS`
+      Size of private key in number of bits used in fitImage. The default
+      value is "2048".
+
    :term:`FONT_EXTRA_RDEPENDS`
       When inheriting the :ref:`fontcache <ref-classes-fontcache>` class,
       this variable specifies the runtime dependencies for font packages.
@@ -2768,6 +2768,10 @@ system and gives an overview of their function and contents.
       -  Given a recipe being built for a little-endian MIPS target running
          Linux, the value might be "mipsel-linux".
 
+   :term:`HOST_VENDOR`
+      Specifies the name of the vendor. :term:`HOST_VENDOR` is normally the
+      same as :term:`TARGET_VENDOR`.
+
    :term:`HOSTTOOLS`
       A space-separated list (filter) of tools on the build host that
       should be allowed to be called from within build tasks. Using this
@@ -2788,10 +2792,6 @@ system and gives an overview of their function and contents.
       :term:`HOSTTOOLS_NONFATAL` is not found on the build host. Thus, you can
       use :term:`HOSTTOOLS_NONFATAL` to filter optional host tools.
 
-   :term:`HOST_VENDOR`
-      Specifies the name of the vendor. :term:`HOST_VENDOR` is normally the
-      same as :term:`TARGET_VENDOR`.
-
    :term:`ICECC_DISABLED`
       Disables or enables the ``icecc`` (Icecream) function. For more
       information on this function and best practices for using this
@@ -2879,40 +2879,6 @@ system and gives an overview of their function and contents.
       The base name of image output files. This variable defaults to the
       recipe name (``${``\ :term:`PN`\ ``}``).
 
-   :term:`IMAGE_EFI_BOOT_FILES`
-      A space-separated list of files installed into the boot partition
-      when preparing an image using the Wic tool with the
-      ``bootimg-efi`` source plugin. By default,
-      the files are
-      installed under the same name as the source files. To change the
-      installed name, separate it from the original name with a semi-colon
-      (;). Source files need to be located in
-      :term:`DEPLOY_DIR_IMAGE`. Here are two
-      examples::
-
-         IMAGE_EFI_BOOT_FILES = "${KERNEL_IMAGETYPE};bz2"
-         IMAGE_EFI_BOOT_FILES = "${KERNEL_IMAGETYPE} microcode.cpio"
- 
-      Alternatively, source files can be picked up using a glob pattern. In
-      this case, the destination file must have the same name as the base
-      name of the source file path. To install files into a directory
-      within the target location, pass its name after a semi-colon (;).
-      Here are two examples::
-
-         IMAGE_EFI_BOOT_FILES = "boot/loader/*"
-         IMAGE_EFI_BOOT_FILES = "boot/loader/*;boot/"
-
-      The first example
-      installs all files from ``${DEPLOY_DIR_IMAGE}/boot/loader/``
-      into the root of the target partition. The second example installs
-      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/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/kickstart`" chapter.
-
    :term:`IMAGE_BOOT_FILES`
       A space-separated list of files installed into the boot partition
       when preparing an image using the Wic tool with the
@@ -2985,6 +2951,40 @@ system and gives an overview of their function and contents.
       device table files, see ``meta/files/device_table-minimal.txt`` as an
       example.
 
+   :term:`IMAGE_EFI_BOOT_FILES`
+      A space-separated list of files installed into the boot partition
+      when preparing an image using the Wic tool with the
+      ``bootimg-efi`` source plugin. By default,
+      the files are
+      installed under the same name as the source files. To change the
+      installed name, separate it from the original name with a semi-colon
+      (;). Source files need to be located in
+      :term:`DEPLOY_DIR_IMAGE`. Here are two
+      examples::
+
+         IMAGE_EFI_BOOT_FILES = "${KERNEL_IMAGETYPE};bz2"
+         IMAGE_EFI_BOOT_FILES = "${KERNEL_IMAGETYPE} microcode.cpio"
+ 
+      Alternatively, source files can be picked up using a glob pattern. In
+      this case, the destination file must have the same name as the base
+      name of the source file path. To install files into a directory
+      within the target location, pass its name after a semi-colon (;).
+      Here are two examples::
+
+         IMAGE_EFI_BOOT_FILES = "boot/loader/*"
+         IMAGE_EFI_BOOT_FILES = "boot/loader/*;boot/"
+
+      The first example
+      installs all files from ``${DEPLOY_DIR_IMAGE}/boot/loader/``
+      into the root of the target partition. The second example installs
+      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/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/kickstart`" chapter.
+
    :term:`IMAGE_FEATURES`
       The primary list of features to include in an image. Typically, you
       configure this variable in an image recipe. Although you can use this
@@ -5074,18 +5074,6 @@ system and gives an overview of their function and contents.
       ":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`
-      Prevents specific packages from being installed when you are
-      installing complementary packages.
-
-      You might find that you want to prevent installing certain packages
-      when you are installing complementary packages. For example, if you
-      are using :term:`IMAGE_FEATURES` to install
-      ``dev-pkgs``, you might not want to install all packages from a
-      particular multilib. If you find yourself in this situation, you can
-      use the :term:`PACKAGE_EXCLUDE_COMPLEMENTARY` variable to specify regular
-      expressions to match the packages you want to exclude.
-
    :term:`PACKAGE_EXCLUDE`
       Lists packages that should not be installed into an image. For
       example::
@@ -5113,6 +5101,18 @@ system and gives an overview of their function and contents.
       :term:`BAD_RECOMMENDATIONS` variables for
       related information.
 
+   :term:`PACKAGE_EXCLUDE_COMPLEMENTARY`
+      Prevents specific packages from being installed when you are
+      installing complementary packages.
+
+      You might find that you want to prevent installing certain packages
+      when you are installing complementary packages. For example, if you
+      are using :term:`IMAGE_FEATURES` to install
+      ``dev-pkgs``, you might not want to install all packages from a
+      particular multilib. If you find yourself in this situation, you can
+      use the :term:`PACKAGE_EXCLUDE_COMPLEMENTARY` variable to specify regular
+      expressions to match the packages you want to exclude.
+
    :term:`PACKAGE_EXTRA_ARCHS`
       Specifies the list of architectures compatible with the device CPU.
       This variable is useful when you build for several different devices
-- 
2.31.1


^ permalink raw reply related	[flat|nested] 4+ messages in thread