diff options
Diffstat (limited to 'poky/documentation/ref-manual')
| -rw-r--r-- | poky/documentation/ref-manual/classes.rst | 51 | ||||
| -rw-r--r-- | poky/documentation/ref-manual/devtool-reference.rst | 73 | ||||
| -rw-r--r-- | poky/documentation/ref-manual/history.rst | 74 | ||||
| -rw-r--r-- | poky/documentation/ref-manual/index.rst | 1 | ||||
| -rw-r--r-- | poky/documentation/ref-manual/qa-checks.rst | 4 | ||||
| -rw-r--r-- | poky/documentation/ref-manual/resources.rst | 13 | ||||
| -rw-r--r-- | poky/documentation/ref-manual/system-requirements.rst | 5 | ||||
| -rw-r--r-- | poky/documentation/ref-manual/tasks.rst | 31 | ||||
| -rw-r--r-- | poky/documentation/ref-manual/terms.rst | 8 | ||||
| -rw-r--r-- | poky/documentation/ref-manual/variables.rst | 117 |
10 files changed, 195 insertions, 182 deletions
diff --git a/poky/documentation/ref-manual/classes.rst b/poky/documentation/ref-manual/classes.rst index 3af023895..5c60fd8c8 100644 --- a/poky/documentation/ref-manual/classes.rst +++ b/poky/documentation/ref-manual/classes.rst @@ -543,7 +543,7 @@ which the OpenEmbedded build system places the generated objects built from the recipes. By default, the :term:`B` directory is set to the following, which is separate from the source directory (:term:`S`):: - ${WORKDIR}/${BPN}/{PV}/ + ${WORKDIR}/${BPN}-{PV}/ See these variables for more information: :term:`WORKDIR`, :term:`BPN`, and @@ -1710,6 +1710,55 @@ one such example. However, being aware of this class can reduce the proliferation of different versions of similar classes across multiple layers. +.. _ref-classes-overlayfs: + +``overlayfs.bbclass`` +======================= + +It's often desired in Embedded System design to have a read-only rootfs. +But a lot of different applications might want to have read-write access to +some parts of a filesystem. It can be especially useful when your update mechanism +overwrites the whole rootfs, but you may want your application data to be preserved +between updates. The :ref:`overlayfs <ref-classes-overlayfs>` class provides a way +to achieve that by means of ``overlayfs`` and at the same time keeping the base +rootfs read-only. + +To use this class, set a mount point for a partition ``overlayfs`` is going to use as upper +layer in your machine configuration. The underlying file system can be anything that +is supported by ``overlayfs``. This has to be done in your machine configuration:: + + OVERLAYFS_MOUNT_POINT[data] = "/data" + +.. note:: + + * QA checks fail to catch file existence if you redefine this variable in your recipe! + * Only the existence of the systemd mount unit file is checked, not its contents. + * To get more details on ``overlayfs``, its internals and supported operations, please refer + to the official documentation of the `Linux kernel <https://www.kernel.org/doc/html/latest/filesystems/overlayfs.html>`_. + +The class assumes you have a ``data.mount`` systemd unit defined elsewhere in your BSP +(e.g. in ``systemd-machine-units`` recipe) and it's installed into the image. + +Then you can specify writable directories on a recipe basis (e.g. in my-application.bb):: + + OVERLAYFS_WRITABLE_PATHS[data] = "/usr/share/my-custom-application" + +To support several mount points you can use a different variable flag. Assuming we +want to have a writable location on the file system, but do not need that the data +survives a reboot, then we could have a ``mnt-overlay.mount`` unit for a ``tmpfs`` file system. + +In your machine configuration:: + + OVERLAYFS_MOUNT_POINT[mnt-overlay] = "/mnt/overlay" + +and then in your recipe:: + + OVERLAYFS_WRITABLE_PATHS[mnt-overlay] = "/usr/share/another-application" + +.. note:: + + The class does not support the ``/etc`` directory itself, because ``systemd`` depends on it. + .. _ref-classes-own-mirrors: ``own-mirrors.bbclass`` diff --git a/poky/documentation/ref-manual/devtool-reference.rst b/poky/documentation/ref-manual/devtool-reference.rst index 1862c481d..a1a8bcdc9 100644 --- a/poky/documentation/ref-manual/devtool-reference.rst +++ b/poky/documentation/ref-manual/devtool-reference.rst @@ -78,7 +78,7 @@ has a number of sub-commands for each function. You can run As directed in the general help output, you can get more syntax on a specific command by providing the command name and -using "--help":: +using ``--help``:: $ devtool add --help NOTE: Starting bitbake server... @@ -284,10 +284,7 @@ is identified using the ``EDITOR`` variable, on the specified recipe. When you use the ``devtool edit-recipe`` command, you must supply the root name of the recipe (i.e. no version, paths, or extensions). Also, the recipe file itself must reside in the workspace as a result of the -``devtool add`` or ``devtool upgrade`` commands. However, you can -override that requirement by using the "-a" or "--any-recipe" option. -Using either of these options allows you to edit any recipe regardless -of its location. +``devtool add`` or ``devtool upgrade`` commands. .. _devtool-updating-a-recipe: @@ -331,23 +328,37 @@ Checking on the Upgrade Status of a Recipe Upstream recipes change over time. Consequently, you might find that you need to determine if you can upgrade a recipe to a newer version. -To check on the upgrade status of a recipe, use the -``devtool check-upgrade-status`` command. The command displays a table -of your current recipe versions, the latest upstream versions, the email -address of the recipe's maintainer, and any additional information such -as commit hash strings and reasons you might not be able to upgrade a -particular recipe. +To check on the upgrade status of a recipe, you can use the +``devtool latest-version recipe`` command, which quickly shows the current +version and the latest version available upstream. To get a more global +picture, use the ``devtool check-upgrade-status`` command, which takes a +list of recipes as input, or no arguments, in which case it checks all +available recipes. This command will only print the recipes for which +a new upstream version is available. Each such recipe will have its current +version and latest upstream version, as well as the email of the maintainer +and any additional information such as the commit hash or reason for not +being able to upgrade it, displayed in a table. + +This upgrade checking mechanism relies on the optional :term:`UPSTREAM_CHECK_URI`, +:term:`UPSTREAM_CHECK_REGEX`, :term:`UPSTREAM_CHECK_GITTAGREGEX`, +:term:`UPSTREAM_CHECK_COMMITS` and :term:`UPSTREAM_VERSION_UNKNOWN` +variables in package recipes. .. note:: + - Most of the time, the above variables are unnecessary. They are only + required when upstream does something unusual, and default + mechanisms cannot find the new upstream versions. + - For the ``oe-core`` layer, recipe maintainers come from the :yocto_git:`maintainers.inc </poky/tree/meta/conf/distro/include/maintainers.inc>` file. - 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. + rather than a tarball, the commit hash points to the commit that matches + the recipe's latest version tag, or in the absence of suitable tags, + to the latest commit (when :term:`UPSTREAM_CHECK_COMMITS` set to ``1`` + in the recipe). As with all ``devtool`` commands, you can get help on the individual command:: @@ -372,29 +383,25 @@ Following is a partial example table that reports on all the recipes. Notice the reported reason for not upgrading the ``base-passwd`` recipe. In this example, while a new version is available upstream, you do not want to use it because the dependency on ``cdebconf`` is not easily -satisfied. - -.. note:: - - 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 </poky/tree/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb>` - recipe for an example. +satisfied. Maintainers can explicit the reason that is shown by adding +the :term:`RECIPE_NO_UPDATE_REASON` variable to the corresponding recipe. +See :yocto_git:`base-passwd.bb </poky/tree/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb>` +for an example. :: $ devtool check-upgrade-status ... - NOTE: acpid 2.0.30 2.0.31 Ross Burton <ross.burton@intel.com> - NOTE: u-boot-fw-utils 2018.11 2019.01 Marek Vasut <marek.vasut@gmail.com> d3689267f92c5956e09cc7d1baa4700141662bff - NOTE: u-boot-tools 2018.11 2019.01 Marek Vasut <marek.vasut@gmail.com> d3689267f92c5956e09cc7d1baa4700141662bff - . - . - . - NOTE: base-passwd 3.5.29 3.5.45 Anuj Mittal <anuj.mittal@intel.com> cannot be updated due to: Version 3.5.38 requires cdebconf for update-passwd utility - NOTE: busybox 1.29.2 1.30.0 Andrej Valek <andrej.valek@siemens.com> - NOTE: dbus-test 1.12.10 1.12.12 Chen Qi <Qi.Chen@windriver.com> + INFO: bind 9.16.20 9.16.21 Armin Kuster <akuster808@gmail.com> + INFO: inetutils 2.1 2.2 Tom Rini <trini@konsulko.com> + INFO: iproute2 5.13.0 5.14.0 Changhyeok Bae <changhyeok.bae@gmail.com> + INFO: openssl 1.1.1l 3.0.0 Alexander Kanavin <alex.kanavin@gmail.com> + INFO: base-passwd 3.5.29 3.5.51 Anuj Mittal <anuj.mittal@intel.com> cannot be updated due to: Version 3.5.38 requires cdebconf for update-passwd utility + ... + +Last but not least, you may set :term:`UPSTREAM_VERSION_UNKNOWN` to ``1`` +in a recipe when there's currently no way to determine its latest upstream +version. .. _devtool-upgrading-a-recipe: @@ -471,7 +478,7 @@ Use the ``devtool build`` command to build your recipe. The When you use the ``devtool build`` command, you must supply the root name of the recipe (i.e. do not provide versions, paths, or extensions). -You can use either the "-s" or the "--disable-parallel-make" options to +You can use either the ``-s`` or the ``--disable-parallel-make`` options to disable parallel makes during the build. Here is an example:: $ devtool build recipe diff --git a/poky/documentation/ref-manual/history.rst b/poky/documentation/ref-manual/history.rst deleted file mode 100644 index dc0a2ae79..000000000 --- a/poky/documentation/ref-manual/history.rst +++ /dev/null @@ -1,74 +0,0 @@ -.. SPDX-License-Identifier: CC-BY-SA-2.0-UK - -*********************** -Manual Revision History -*********************** - -.. list-table:: - :widths: 10 15 40 - :header-rows: 1 - - * - Revision - - Date - - Note - * - 0.9 - - November 2010 - - The initial document released with the Yocto Project 0.9 Release - * - 1.0 - - April 2011 - - Released with the Yocto Project 1.0 Release. - * - 1.1 - - October 2011 - - Released with the Yocto Project 1.1 Release. - * - 1.2 - - April 2012 - - Released with the Yocto Project 1.2 Release. - * - 1.3 - - October 2012 - - Released with the Yocto Project 1.3 Release. - * - 1.4 - - April 2013 - - Released with the Yocto Project 1.4 Release. - * - 1.5 - - October 2013 - - Released with the Yocto Project 1.5 Release. - * - 1.6 - - April 2014 - - Released with the Yocto Project 1.6 Release. - * - 1.7 - - October 2014 - - Released with the Yocto Project 1.7 Release. - * - 1.8 - - April 2015 - - Released with the Yocto Project 1.8 Release. - * - 2.0 - - October 2015 - - Released with the Yocto Project 2.0 Release. - * - 2.1 - - April 2016 - - Released with the Yocto Project 2.1 Release. - * - 2.2 - - October 2016 - - Released with the Yocto Project 2.2 Release. - * - 2.3 - - May 2017 - - Released with the Yocto Project 2.3 Release. - * - 2.4 - - October 2017 - - Released with the Yocto Project 2.4 Release. - * - 2.5 - - May 2018 - - Released with the Yocto Project 2.5 Release. - * - 2.6 - - November 2018 - - Released with the Yocto Project 2.6 Release. - * - 2.7 - - May 2019 - - Released with the Yocto Project 2.7 Release. - * - 3.0 - - October 2019 - - Released with the Yocto Project 3.0 Release. - * - 3.1 - - April 2020 - - Released with the Yocto Project 3.1 Release. - diff --git a/poky/documentation/ref-manual/index.rst b/poky/documentation/ref-manual/index.rst index 5cf10c5c2..a746dde49 100644 --- a/poky/documentation/ref-manual/index.rst +++ b/poky/documentation/ref-manual/index.rst @@ -25,6 +25,5 @@ Yocto Project Reference Manual varlocality faq resources - history .. include:: /boilerplate.rst diff --git a/poky/documentation/ref-manual/qa-checks.rst b/poky/documentation/ref-manual/qa-checks.rst index c3e40dba5..792c099d0 100644 --- a/poky/documentation/ref-manual/qa-checks.rst +++ b/poky/documentation/ref-manual/qa-checks.rst @@ -151,7 +151,7 @@ Errors and Warnings occur if you add a path which contains a ``.debug`` directory and do not explicitly add the ``.debug`` directory to the ``-dbg`` package. If this is the case, add the ``.debug`` directory explicitly to - ``FILES_${PN}-dbg``. See :term:`FILES` for additional + ``FILES:${PN}-dbg``. See :term:`FILES` for additional information on :term:`FILES`. @@ -435,7 +435,7 @@ Errors and Warnings (e.g. :term:`PN` happens to be the same as :term:`MACHINE` or :term:`DISTRO`), it can have unexpected consequences. For example, assignments such as - ``FILES_${PN} = "xyz"`` effectively turn into ``FILES = "xyz"``. + ``FILES:${PN} = "xyz"`` effectively turn into ``FILES = "xyz"``. Rename your recipe (or if :term:`PN` is being set explicitly, change the :term:`PN` value) so that the conflict does not occur. See :term:`FILES` for additional information. diff --git a/poky/documentation/ref-manual/resources.rst b/poky/documentation/ref-manual/resources.rst index 5ffd2b399..c94238466 100644 --- a/poky/documentation/ref-manual/resources.rst +++ b/poky/documentation/ref-manual/resources.rst @@ -90,12 +90,12 @@ For more Yocto Project-related mailing lists, see the Internet Relay Chat (IRC) ========================= -Two IRC channels on Freenode are available for the Yocto Project and -Poky discussions: +Two IRC channels on `Libera Chat <https://libera.chat/>`__ +are available for the Yocto Project and OpenEmbedded discussions: - ``#yocto`` -- ``#poky`` +- ``#oe`` .. _resources-links-and-related-documentation: @@ -187,9 +187,10 @@ Here is a list of resources you might find helpful: implementation of Bugzilla for logging and tracking Yocto Project defects. -- *Internet Relay Chat (IRC):* Two IRC channels on Freenode are - available for Yocto Project and Poky discussions: ``#yocto`` and - ``#poky``, respectively. +- *Internet Relay Chat (IRC):* Two IRC channels on + `Libera Chat <https://libera.chat/>`__ are + available for Yocto Project and OpenEmbeddded discussions: ``#yocto`` and + ``#oe``, respectively. - `Quick EMUlator (QEMU) <https://wiki.qemu.org/Index.html>`__\ *:* An open-source machine emulator and virtualizer. diff --git a/poky/documentation/ref-manual/system-requirements.rst b/poky/documentation/ref-manual/system-requirements.rst index e9d995c61..5e5c105d6 100644 --- a/poky/documentation/ref-manual/system-requirements.rst +++ b/poky/documentation/ref-manual/system-requirements.rst @@ -4,7 +4,7 @@ System Requirements ******************* -Welcome to the Yocto Project Reference Manual! This manual provides +Welcome to the Yocto Project Reference Manual. This manual provides reference information for the current release of the Yocto Project, and is most effectively used after you have an understanding of the basics of the Yocto Project. The manual is neither meant to be read as a @@ -277,7 +277,8 @@ installer and automatically installs the tools for you: 1. Execute the ``install-buildtools`` script. Here is an example:: $ cd poky - $ scripts/install-buildtools --without-extended-buildtools \ + $ scripts/install-buildtools \ + --without-extended-buildtools \ --base-url &YOCTO_DL_URL;/releases/yocto \ --release yocto-&DISTRO; \ --installer-version &DISTRO; diff --git a/poky/documentation/ref-manual/tasks.rst b/poky/documentation/ref-manual/tasks.rst index ecc701856..4edae3339 100644 --- a/poky/documentation/ref-manual/tasks.rst +++ b/poky/documentation/ref-manual/tasks.rst @@ -438,37 +438,6 @@ Manually Called Tasks These tasks are typically manually triggered (e.g. by using the ``bitbake -c`` command-line option): -.. _ref-tasks-checkpkg: - -``do_checkpkg`` ---------------- - -Provides information about the recipe including its upstream version and -status. The upstream version and status reveals whether or not a version -of the recipe exists upstream and a status of not updated, updated, or -unknown. - -To check the upstream version and status of a recipe, use the following -devtool commands:: - - $ devtool latest-version - $ devtool check-upgrade-status - -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. - -To build the ``checkpkg`` task, use the ``bitbake`` command with the -"-c" option and task name:: - - $ bitbake core-image-minimal -c checkpkg - -By default, the results are stored in :term:`$LOG_DIR <LOG_DIR>` (e.g. -``$BUILD_DIR/tmp/log``). - -.. _ref-tasks-checkuri: - ``do_checkuri`` --------------- diff --git a/poky/documentation/ref-manual/terms.rst b/poky/documentation/ref-manual/terms.rst index 32658051a..e5a7565df 100644 --- a/poky/documentation/ref-manual/terms.rst +++ b/poky/documentation/ref-manual/terms.rst @@ -367,10 +367,16 @@ universal, the list includes them just in case: section in the Yocto Project Overview and Concepts Manual. :term:`Task` - A unit of execution for BitBake (e.g. + A per-recipe unit of execution for BitBake (e.g. :ref:`ref-tasks-compile`, :ref:`ref-tasks-fetch`, :ref:`ref-tasks-patch`, and so forth). + One of the major benefits of the build system is that, since each + recipe will typically spawn the execution of numerous tasks, + it is entirely possible that many tasks can execute in parallel, + either tasks from separate recipes or independent tasks within + the same recipe, potentially up to the parallelism of your + build system. :term:`Toaster` A web interface to the Yocto Project's :term:`OpenEmbedded Build System`. diff --git a/poky/documentation/ref-manual/variables.rst b/poky/documentation/ref-manual/variables.rst index d5ac1926b..5f6f91146 100644 --- a/poky/documentation/ref-manual/variables.rst +++ b/poky/documentation/ref-manual/variables.rst @@ -3589,6 +3589,12 @@ system and gives an overview of their function and contents. .. note:: + Bundling the initramfs with the kernel conflates the code in the + initramfs with the GPLv2 licensed Linux kernel binary. Thus only GPLv2 + compatible software may be part of a bundled initramfs. + + .. note:: + Using an extra compilation pass to bundle the initramfs avoids a circular dependency between the kernel recipe and the initramfs recipe should the initramfs include kernel modules. Should that be @@ -5064,33 +5070,44 @@ system and gives an overview of their function and contents. ":ref:`package.bbclass <ref-classes-package>`" section. :term:`PACKAGE_DEBUG_SPLIT_STYLE` - Determines how to split up the binary and debug information when - creating ``*-dbg`` packages to be used with the GNU Project Debugger - (GDB). - - With the :term:`PACKAGE_DEBUG_SPLIT_STYLE` variable, you can control - where debug information, which can include or exclude source files, - is stored: - - - ".debug": Debug symbol files are placed next to the binary in a - ``.debug`` directory on the target. For example, if a binary is - installed into ``/bin``, the corresponding debug symbol files are - installed in ``/bin/.debug``. Source files are placed in - ``/usr/src/debug``. - - - "debug-file-directory": Debug symbol files are placed under - ``/usr/lib/debug`` on the target, and separated by the path from - where the binary is installed. For example, if a binary is - installed in ``/bin``, the corresponding debug symbols are - installed in ``/usr/lib/debug/bin``. Source files are placed in - ``/usr/src/debug``. - - - "debug-without-src": The same behavior as ".debug" previously - described with the exception that no source files are installed. - - - "debug-with-srcpkg": The same behavior as ".debug" previously - described with the exception that all source files are placed in a - separate ``*-src`` pkg. This is the default behavior. + Determines how to split up and package debug and source information + when creating debugging packages to be used with the GNU Project + Debugger (GDB). In general, based on the value of this variable, + you can combine the source and debug info in a single package, + you can break out the source into a separate package that can be + installed independently, or you can choose to not have the source + packaged at all. + + The possible values of :term:`PACKAGE_DEBUG_SPLIT_STYLE` variable: + + - "``.debug``": All debugging and source info is placed in a single + ``*-dbg`` package; debug symbol files are placed next to the + binary in a ``.debug`` directory so that, if a binary is installed + into ``/bin``, the corresponding debug symbol file is installed + in ``/bin/.debug``. Source files are installed in the same ``*-dbg`` + package under ``/usr/src/debug``. + + - "``debug-file-directory``": As above, all debugging and source info + is placed in a single ``*-dbg`` package; debug symbol files are + placed entirely under the directory ``/usr/lib/debug`` and separated + by the path from where the binary is installed, so that if a binary + is installed in ``/bin``, the corresponding debug symbols are installed + in ``/usr/lib/debug/bin``, and so on. As above, source is installed + in the same package under ``/usr/src/debug``. + + - "``debug-with-srcpkg``": Debugging info is placed in the standard + ``*-dbg`` package as with the ``.debug`` value, while source is + placed in a separate ``*-src`` package, which can be installed + independently. This is the default setting for this variable, + as defined in Poky's ``bitbake.conf`` file. + + - "``debug-without-src``": The same behavior as with the ``.debug`` + setting, but no source is packaged at all. + + .. note:: + + Much of the above package splitting can be overridden via + use of the :term:`INHIBIT_PACKAGE_DEBUG_SPLIT` variable. You can find out more about debugging using GDB by reading the ":ref:`dev-manual/common-tasks:debugging with the gnu project debugger (gdb) remotely`" section @@ -5391,7 +5408,7 @@ system and gives an overview of their function and contents. The list of packages the recipe creates. The default value is the following:: - ${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN} + ${PN}-src ${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN} During packaging, the :ref:`ref-tasks-package` task goes through :term:`PACKAGES` and uses the :term:`FILES` @@ -6132,6 +6149,13 @@ system and gives an overview of their function and contents. BitBake User Manual for additional information on tasks and dependencies. + :term:`RECIPE_NO_UPDATE_REASON` + If a recipe should not be replaced by a more recent upstream version, + putting the reason why in this variable in a recipe allows + ``devtool check-upgrade-status`` command to display it, as explained + in the ":ref:`ref-manual/devtool-reference:checking on the upgrade status of a recipe`" + section. + :term:`REQUIRED_DISTRO_FEATURES` When inheriting the :ref:`features_check <ref-classes-features_check>` @@ -7503,6 +7527,7 @@ system and gives an overview of their function and contents. ${base_libdir} \ ${nonarch_base_libdir} \ ${datadir} \ + /sysroot-only \ " :term:`SYSROOT_DIRS_BLACKLIST` @@ -7516,10 +7541,16 @@ system and gives an overview of their function and contents. ${mandir} \ ${docdir} \ ${infodir} \ - ${datadir}/locale \ + ${datadir}/X11/locale \ ${datadir}/applications \ + ${datadir}/bash-completion \ ${datadir}/fonts \ + ${datadir}/gtk-doc/html \ + ${datadir}/installed-tests \ + ${datadir}/locale \ ${datadir}/pixmaps \ + ${datadir}/terminfo \ + ${libdir}/${BPN}/ptest \ " :term:`SYSROOT_DIRS_NATIVE` @@ -8476,9 +8507,21 @@ system and gives an overview of their function and contents. install initscripts package them in the main package for the recipe, you rarely need to set this variable in individual recipes. + :term:`UPSTREAM_CHECK_COMMITS` + You can perform a per-recipe check for what the latest upstream + source code version is by calling ``devtool latest-version recipe``. If + the recipe source code is provided from Git repositories, but + releases are not identified by Git tags, set :term:`UPSTREAM_CHECK_COMMITS` + to ``1`` in the recipe, and the OpenEmbedded build system + will compare the latest commit with the one currently specified + by the recipe (:term:`SRCREV`). + :: + + UPSTREAM_CHECK_COMMITS = "1" + :term:`UPSTREAM_CHECK_GITTAGREGEX` You can perform a per-recipe check for what the latest upstream - source code version is by calling ``bitbake -c checkpkg`` recipe. If + source code version is by calling ``devtool latest-version recipe``. If the recipe source code is provided from Git repositories, the OpenEmbedded build system determines the latest upstream version by picking the latest tag from the list of all repository tags. @@ -8501,7 +8544,7 @@ system and gives an overview of their function and contents. :term:`UPSTREAM_CHECK_URI` You can perform a per-recipe check for what the latest upstream - source code version is by calling ``bitbake -c checkpkg`` recipe. If + source code version is by calling ``devtool latest-version recipe``. If the source code is provided from tarballs, the latest version is determined by fetching the directory listing where the tarball is and attempting to find a later tarball. When this approach does not work, @@ -8511,6 +8554,18 @@ system and gives an overview of their function and contents. UPSTREAM_CHECK_URI = "recipe_url" + :term:`UPSTREAM_VERSION_UNKNOWN` + You can perform a per-recipe check for what the latest upstream + source code version is by calling ``devtool latest-version recipe``. + If no combination of the :term:`UPSTREAM_CHECK_URI`, :term:`UPSTREAM_CHECK_REGEX`, + :term:`UPSTREAM_CHECK_GITTAGREGEX` and :term:`UPSTREAM_CHECK_COMMITS` variables in + the recipe allows to determine what the latest upstream version is, + you can set :term:`UPSTREAM_VERSION_UNKNOWN` to ``1`` in the recipe + to acknowledge that the check cannot be performed. + :: + + UPSTREAM_VERSION_UNKNOWN = "1" + :term:`USE_DEVFS` Determines if ``devtmpfs`` is used for ``/dev`` population. The default value used for :term:`USE_DEVFS` is "1" when no value is |