Lines Matching +full:rpm +full:- +full:msg +full:- +full:ram
1 .. SPDX-License-Identifier: CC-BY-SA-2.0-UK
21 ":ref:`overview-manual/yp-intro:the yocto project layer model`"
25 -----------------------
33 layer-creation tools, see the
34 ":ref:`bsp-guide/bsp:creating a new bsp layer using the \`\`bitbake-layers\`\` script`"
36 …Guide and the ":ref:`dev-manual/common-tasks:creating a general layer using the \`\`bitbake-layers…
54 the string "meta-". For example::
56 meta-mylayer
57 meta-GUI_xyz
58 meta-mymachine
62 meta-root_name
66 layer name begins with "meta-". A notable example is in configuration
68 "meta-" string are appended to several variables used in the
76 The ``meta-yocto-bsp/conf/layer.conf`` file in the Yocto Project
77 :yocto_git:`Source Repositories </poky/tree/meta-yocto-bsp/conf>`
80 for a layer named "meta-machinexyz")::
85 # We have recipes-* directories, add to BBFILES
86 BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
87 ${LAYERDIR}/recipes-*/*/*.bbappend"
97 - :term:`BBPATH`: Adds the layer's
107 - :term:`BBFILES`: Defines the
110 - :term:`BBFILE_COLLECTIONS`:
114 representation for the container layer named "meta-yocto-bsp".
116 - :term:`BBFILE_PATTERN`:
120 - :term:`BBFILE_PRIORITY`:
125 - :term:`LAYERVERSION`:
132 - :term:`LAYERDEPENDS`:
135 - :term:`LAYERSERIES_COMPAT`:
146 recipes you need in ``recipes-*`` subdirectories within the layer.
151 Yocto Project, see the ":ref:`bsp-guide/bsp:example filesystem layout`"
158 ":ref:`dev-manual/common-tasks:making sure your layer is compatible with yocto project`"
162 ---------------------------------------------
168 - *Avoid "Overlaying" Entire Recipes from Other Layers in Your
174 - *Avoid Duplicating Include Files:* Use append files (``.bbappend``)
178 use ``require recipes-core/``\ `package`\ ``/``\ `file`\ ``.inc`` instead
187 - *Structure Your Layers:* Proper use of overrides within append files
188 and placement of machine-specific files within your layer can ensure
192 - *Modify Variables to Support a Different Machine:* Suppose you
193 have a layer named ``meta-one`` that adds support for building
195 ``base-files.bbappend`` and create a dependency on "foo" by
202 build that includes the layer ``meta-one``. However, you might not
205 the ``meta-one`` layer included. During the build, the
206 ``base-files`` for machine "two" will also have the dependency on
221 snippet from the generic kernel include file ``linux-yocto.inc``,
239 - *Place Machine-Specific Files in Machine-Specific Locations:* When
240 you have a base recipe, such as ``base-files.bb``, that contains a
244 at ``meta-one/recipes-core/base-files/base-files.bbappend`` could
249 The build for machine "one" will pick up your machine-specific file as
251 ``meta-one/recipes-core/base-files/base-files/``. However, if you
253 file includes the ``meta-one`` layer and the location of your
254 machine-specific file is the first location where that file is
256 also use that machine-specific file.
258 You can make sure that a machine-specific file is used for a
261 ``meta-one/recipes-core/base-files/base-files/`` as shown above,
262 put it in ``meta-one/recipes-core/base-files/base-files/one/``.
268 :term:`SRC_URI` in a machine-specific subdirectory within the layer in
269 order to restrict those files to machine-specific builds.
271 - *Perform Steps to Apply for Yocto Project Compatibility:* If you want
275 ":ref:`dev-manual/common-tasks:making sure your layer is compatible with yocto project`"
278 - *Follow the Layer Naming Convention:* Store custom layers in a Git
279 repository that use the ``meta-layer_name`` format.
281 - *Group Your Layers Locally:* Clone your repository alongside other
285 -------------------------------------------------------
305 1. Successfully passing a script (``yocto-check-layer``) that when run
312 :yocto_home:`/webform/yocto-project-compatible-registration`.
317 - Be able to check the box indicating that you got a "PASS" when
320 - Answer "Yes" to the questions on the form or have an acceptable
323 - Be a Yocto Project Member Organization.
326 form and on the ``yocto-check-layer`` script.
336 :yocto_home:`/webform/yocto-project-compatible-registration`.
341 - *Contact Information:* Provide your contact information as the fields
345 - *Acceptance Criteria:* Provide "Yes" or "No" answers for each of the
349 - *Recommendations:* Provide answers for the questions regarding Linux
352 ``yocto-check-layer`` Script
355 The ``yocto-check-layer`` script provides you a way to assess how
369 $ source oe-init-build-env
370 $ yocto-check-layer your_layer_directory
379 - ``common.test_readme``: Tests if a ``README`` file exists in the
382 - ``common.test_parse``: Tests to make sure that BitBake can parse the
383 files without error (i.e. ``bitbake -p``).
385 - ``common.test_show_environment``: Tests that the global or per-recipe
386 environment is in order without errors (i.e. ``bitbake -e``).
388 - ``common.test_world``: Verifies that ``bitbake world`` works.
390 - ``common.test_signatures``: Tests to be sure that BSP and DISTRO
393 - ``common.test_layerseries_compat``: Verifies layer compatibility is
396 - ``bsp.test_bsp_defines_machines``: Tests if a BSP layer has machine
399 - ``bsp.test_bsp_no_set_machine``: Tests to ensure a BSP layer does not
402 - ``bsp.test_machine_world``: Verifies that ``bitbake world`` works
405 - ``bsp.test_machine_signatures``: Verifies that building for a
409 - ``distro.test_distro_defines_distros``: Tests if a DISTRO layer has
412 - ``distro.test_distro_no_set_distros``: Tests to ensure a DISTRO layer
416 -------------------
423 ``meta-mylayer`` layer (note how your new layer exists outside of
433 /home/user/poky/meta-poky \
434 /home/user/poky/meta-yocto-bsp \
435 /home/user/mystuff/meta-mylayer \
445 -----------------------------------------------
467 number-specific. If the corresponding recipe is renamed to update to a
482 the "meta" layer at ``meta/recipes-bsp/formfactor``::
501 install -d ${D}${sysconfdir}/formfactor/
502 install -m 0644 ${S}/config ${D}${sysconfdir}/formfactor/
503 if [ -s "${S}/machconfig" ]; then
504 install -m 0644 ${S}/machconfig ${D}${sysconfdir}/formfactor/
513 and is from the Raspberry Pi BSP Layer named ``meta-raspberrypi``. The
514 file is in the layer at ``recipes-bsp/formfactor``::
530 ``meta-raspberrypi/recipes-bsp/formfactor``. This implies that you must
536 important as it ensures that items in the list remain colon-separated.
551 ``meta-raspberrypi/recipes-bsp/formfactor/formfactor/rpi/machconfig`` will be
552 used during :ref:`ref-tasks-fetch` and the test for a non-zero file size in
553 :ref:`ref-tasks-install` will return true, and the file will be installed.
558 As another example, consider the main ``xserver-xf86-config`` recipe and a
559 corresponding ``xserver-xf86-config`` append file both from the :term:`Source
560 Directory`. Here is the main ``xserver-xf86-config`` recipe, which is named
561 ``xserver-xf86-config_0.1.bb`` and located in the "meta" layer at
562 ``meta/recipes-graphics/xorg-xserver``::
581 if test -s ${WORKDIR}/xorg.conf; then
582 install -d ${D}/${sysconfdir}/X11
583 install -m 0644 ${WORKDIR}/xorg.conf ${D}/${sysconfdir}/X11/
587 Following is the append file, which is named ``xserver-xf86-config_%.bbappend``
588 and is from the Raspberry Pi BSP Layer named ``meta-raspberrypi``. The
589 file is in the layer at ``recipes-graphics/xorg-xserver``::
594 file://xorg.conf.d/98-pitft.conf \
595 file://xorg.conf.d/99-calibration.conf \
600 install -d ${D}/${sysconfdir}/X11/xorg.conf.d/
601 install -m 0644 ${WORKDIR}/xorg.conf.d/98-pitft.conf ${D}/${sysconfdir}/X11/xorg.conf.d/
602 … install -m 0644 ${WORKDIR}/xorg.conf.d/99-calibration.conf ${D}/${sysconfdir}/X11/xorg.conf.d/
611 the list of :term:`OVERRIDES`. The :ref:`ref-tasks-install` task will then perform a
617 -----------------------
644 ---------------
646 You can use the BitBake layer management tool ``bitbake-layers`` to
647 provide a view into the structure of recipes across a multi-layer
655 $ bitbake-layers --help
657 usage: bitbake-layers [-d] [-q] [-F] [--color COLOR] [-h] <subcommand> ...
662 -d, --debug Enable debug output
663 -q, --quiet Print only errors
664 -F, --force Force add without recipe parse verification
665 --color COLOR Colorize output (where COLOR is auto, always, never)
666 -h, --help show this help message and exit
670 layerindex-fetch Fetches a layer from a layer index along with its
672 layerindex-show-depends
674 add-layer Add one or more layers to bblayers.conf.
675 remove-layer Remove one or more layers from bblayers.conf.
678 show-layers show current configured layers.
679 show-overlayed list overlayed recipes (where the same recipe exists
681 show-recipes list available recipes, showing the layer they are
683 show-appends list bbappend files and recipe files they apply to
684 show-cross-depends Show dependencies between recipes that cross layer
686 create-layer Create a basic layer
688 Use bitbake-layers <subcommand> --help to get help on a specific command
692 - ``help:`` Displays general help or help on a specified command.
694 - ``show-layers:`` Shows the current configured layers.
696 - ``show-overlayed:`` Lists overlayed recipes. A recipe is overlayed
700 - ``show-recipes:`` Lists available recipes and the layers that
703 - ``show-appends:`` Lists ``.bbappend`` files and the recipe files to
706 - ``show-cross-depends:`` Lists dependency relationships between
709 - ``add-layer:`` Adds a layer to ``bblayers.conf``.
711 - ``remove-layer:`` Removes a layer from ``bblayers.conf``
713 - ``flatten:`` Flattens the layer configuration into a separate
720 - Non-recipe files (such as patches) are overwritten. The flatten
723 - Anything beyond the normal layer setup has been added to the
727 - Overridden and appended items from ``.bbappend`` files need to be
731 following example. Here, the ``bitbake-layers`` command adds the
738 EXTRA_OECONF = "--enable-something"
741 #### bbappended from meta-anotherlayer ####
744 EXTRA_OECONF += "--enable-somethingelse"
752 EXTRA_OECONF = "--enable-something --enable-somethingelse"
755 - ``layerindex-fetch``: Fetches a layer from a layer index, along
759 - ``layerindex-show-depends``: Finds layer dependencies from the
762 - ``create-layer``: Creates a basic layer.
764 Creating a General Layer Using the ``bitbake-layers`` Script
765 ------------------------------------------------------------
767 The ``bitbake-layers`` script with the ``create-layer`` subcommand
772 - For information on BSP layers, see the ":ref:`bsp-guide/bsp:bsp layers`"
776 - In order to use a layer with the OpenEmbedded build system, you
778 …file. See the ":ref:`dev-manual/common-tasks:adding a layer using the \`\`bitbake-layers\`\` scrip…
784 - A layer priority of 6.
786 - A ``conf`` subdirectory that contains a ``layer.conf`` file.
788 - A ``recipes-example`` subdirectory that contains a further
792 - A ``COPYING.MIT``, which is the license statement for the layer. The
796 - A ``README`` file, which is a file describing the contents of your
803 $ bitbake-layers create-layer your_layer_name
805 As an example, the following command creates a layer named ``meta-scottrif``
809 $ bitbake-layers create-layer meta-scottrif
811 Add your new layer with 'bitbake-layers add-layer meta-scottrif'
814 value of "6", you can either use the ``--priority`` option or you
819 default, you can use the ``--example-recipe-name`` option.
821 The easiest way to see how the ``bitbake-layers create-layer`` command
825 $ bitbake-layers create-layer --help
827 usage: bitbake-layers create-layer [-h] [--priority PRIORITY]
828 [--example-recipe-name EXAMPLERECIPE]
837 -h, --help show this help message and exit
838 --priority PRIORITY, -p PRIORITY
840 --example-recipe-name EXAMPLERECIPE, -e EXAMPLERECIPE
843 Adding a Layer Using the ``bitbake-layers`` Script
844 --------------------------------------------------
851 Add your layer by using the ``bitbake-layers add-layer`` command::
853 $ bitbake-layers add-layer your_layer_name
856 layer named ``meta-scottrif`` to the configuration file. Following the
857 command that adds the layer is another ``bitbake-layers`` command that
860 $ bitbake-layers add-layer meta-scottrif
864 $ bitbake-layers show-layers
869 meta-poky /home/scottrif/poky/meta-poky 5
870 meta-yocto-bsp /home/scottrif/poky/meta-yocto-bsp 5
872 meta-scottrif /home/scottrif/poky/build/meta-scottrif 6
890 ---------------------------------------
921 IMAGE_INSTALL:append:pn-core-image-minimal = " strace"
923 This example adds ``strace`` to the ``core-image-minimal`` image only.
927 ``core-image-*`` images are affected.
930 -------------------------------------------------------------------------------
933 high-level image features by using the
943 :ref:`meta/classes/image.bbclass <ref-classes-image>`.
946 as ``debug-tweaks`` and ``read-only-rootfs``, resolve as general
967 Dropbear is a minimal SSH server appropriate for resource-constrained
968 environments, while OpenSSH is a well-known standard SSH server
969 implementation. By default, the ``core-image-sato`` image is configured
970 to use Dropbear. The ``core-image-full-cmdline`` and ``core-image-lsb``
971 images both include OpenSSH. The ``core-image-minimal`` image does not
978 ``ssh-server-dropbear`` or ``ssh-server-openssh``.
982 See the ":ref:`ref-manual/features:image features`" section in the Yocto
987 -----------------------------------------
993 IMAGE_INSTALL = "packagegroup-core-x11-base package1 package2"
994 inherit core-image
1000 ``glibc-dev`` instead of ``libc6-dev``).
1004 ``core-image-sato`` but add the additional package ``strace`` to the
1005 image, copy the ``meta/recipes-sato/images/core-image-sato.bb`` to a new
1011 ----------------------------------------------
1016 ``meta/recipes-core/packagegroups/packagegroup-base.bb``.
1021 ``-dev``, ``-dbg``, and ``-ptest`` complementary packages for each
1032 in the ``packagegroup-base.bb`` recipe.
1035 hypothetical packagegroup defined in ``packagegroup-custom.bb``, where
1037 the full packagegroup name ``packagegroup-custom``::
1044 ${PN}-apps \
1045 ${PN}-tools \
1048 RDEPENDS:${PN}-apps = "\
1053 RDEPENDS:${PN}-tools = "\
1055 oprofileui-server \
1056 lttng-tools"
1058 RRECOMMENDS:${PN}-tools = "\
1059 kernel-module-oprofile"
1063 ``packagegroup-custom-apps``, and ``packagegroup-custom-tools``. To
1065 ``packagegroup-custom-apps`` and/or ``packagegroup-custom-tools`` to
1070 -----------------------------
1078 variable in the ``base-files`` recipe using either an append file or a
1085 hostname:pn-base-files = "myhostname"
1100 hostname:pn-base-files = ""
1117 ":ref:`ref-manual/varlocality:recipes`" section of the Yocto Project
1121 --------
1126 .. image:: figures/recipe-workflow.png
1130 --------------------------------------------
1135 - ``devtool add``: A command that assists in creating a recipe and an
1138 - ``recipetool create``: A command provided by the Yocto Project that
1141 - *Existing Recipes:* Location and modification of an existing recipe
1147 ":ref:`dev-manual/common-tasks:recipe syntax`" section.
1152 The ``devtool add`` command uses the same logic for auto-creating the
1160 the ":ref:`sdk-manual/extensible:a closer look at \`\`devtool add\`\``" section
1170 pre-build information into the recipe. For example, suppose you have an
1172 ``recipetool`` results in a recipe that has the pre-build dependencies,
1178 :ref:`structure-core-script`).
1181 $ recipetool -h
1183 usage: recipetool [-d] [-q] [--color COLOR] [-h] <subcommand> ...
1188 -d, --debug Enable debug output
1189 -q, --quiet Print only errors
1190 --color COLOR Colorize output (where COLOR is auto, always, never)
1191 -h, --help show this help message and exit
1201 Use recipetool <subcommand> --help to get help on a specific command
1203 Running ``recipetool create -o OUTFILE`` creates the base recipe and
1207 - Use this syntax to generate a recipe based on source. Once generated,
1210 recipetool create -o OUTFILE source
1212 - Use this syntax to generate a recipe using code that
1217 recipetool create -o OUTFILE -x EXTERNALSRC source
1219 - Use this syntax to generate a recipe based on source. The options
1223 recipetool create -d -o OUTFILE source
1238 - *Locate and modify a recipe that is close to what you want to do:*
1249 - *Use and modify the following skeleton recipe:* If for some reason
1265 -----------------------------
1272 - *Storing Your Recipe:* The OpenEmbedded build system locates your
1278 BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
1279 ${LAYERDIR}/recipes-*/*/*.bbappend"
1285 ":ref:`dev-manual/common-tasks:understanding and creating layers`" section.
1287 - *Naming Your Recipe:* When you name your recipe, you need to follow
1292 Use lower-cased characters and do not include the reserved suffixes
1293 ``-native``, ``-cross``, ``-initial``, or ``-dev`` casually (i.e. do not use
1297 .. code-block:: none
1301 irssi_0.8.16-rc1.bb
1304 -----------------------------
1311 :ref:`structure-core-script`) and you are in
1324 The path to the per-recipe temporary work directory depends on the
1328 $ bitbake -e basename | grep ^WORKDIR=
1331 top-level folder named ``poky``, a default Build Directory at
1332 ``poky/build``, and a ``qemux86-poky-linux`` machine target system.
1337 poky/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0
1339 Inside this directory you can find sub-directories such as ``image``,
1340 ``packages-split``, and ``temp``. After the build, you can examine these
1346 directory (e.g. ``poky/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0/temp``).
1351 ":doc:`/overview-manual/development-environment`"
1355 -------------
1362 ":ref:`overview-manual/concepts:sources`" section in
1365 The :ref:`ref-tasks-fetch` task uses
1367 which :ref:`fetcher <bitbake:bitbake-user-manual/bitbake-user-manual-fetching:fetchers>` to use to …
1369 The :ref:`ref-tasks-patch` task uses
1376 for your source files. It is good practice to not hard-code version
1377 numbers in a URL used in :term:`SRC_URI`. Rather than hard-code these
1385 ``meta/recipes-devtools/strace/strace_5.5.bb`` recipe where the source
1389 SRC_URI = "https://strace.io/files/${PV}/strace-${PV}.tar.xz \
1394 :ref:`ref-tasks-unpack` task. For
1396 ":ref:`dev-manual/common-tasks:autotooled package`" section.
1401 ``meta/recipes-core/musl/gcompat_git.bb``::
1422 SRC_URI = "${KERNELORG_MIRROR}/software/scm/git/git-${PV}.tar.gz;name=tarball \
1423 ${KERNELORG_MIRROR}/software/scm/git/git-manpages-${PV}.tar.gz;name=manpages"
1451 ``meta/recipes-sato/rxvt-unicode/rxvt-unicode_9.20.bb`` recipe. The
1457 SRC_URI = "http://dist.schmorp.de/rxvt-unicode/Attic/rxvt-unicode-${PV}.tar.bz2 \
1471 ":ref:`dev-manual/common-tasks:single .c file package (hello world!)`" section.
1477 ":ref:`dev-manual/common-tasks:patching code`" section.
1483 See the ":doc:`/ref-manual/faq`" chapter for advice.
1496 --------------
1499 :ref:`ref-tasks-unpack` task unpacks
1505 convention of a top-level subdirectory named
1506 ``${``\ :term:`BPN`\ ``}-${``\ :term:`PV`\ ``}``,
1516 -------------
1522 :ref:`ref-tasks-patch` task
1525 The build system should be able to apply patches with the "-p1" option
1541 ---------
1548 - :term:`LICENSE`: This variable specifies the license for the software.
1557 LICENSE = "GPL-2.0-only"
1562 ``meta/files/common-licenses/`` or the :term:`SPDXLICENSEMAP` flag names
1565 - :term:`LIC_FILES_CHKSUM`: The OpenEmbedded build system uses this
1576 ":ref:`dev-manual/common-tasks:tracking license changes`" section.
1582 See the ":ref:`dev-manual/common-tasks:fetching code`" section for
1595 ------------
1599 main categories: build-time dependencies, which are required when the
1603 Within a recipe, you specify build-time dependencies using the
1606 recipes. It is important that you specify all build-time dependencies
1613 use), instead of hard-disabling the functionality, you can use the
1618 Similar to build-time dependencies, you specify runtime dependencies
1619 through a variable -
1621 package-specific. All variables that are package-specific need to have
1627 ``RDEPENDS:${PN}``. If the package were named ``${PN}-tools``, then you
1628 would set ``RDEPENDS:${PN}-tools``, and so forth.
1636 ":ref:`overview-manual/concepts:automatically added runtime dependencies`"
1641 ----------------------
1643 Most software provides some means of setting build-time configuration
1652 the scripts previously requiring error-prone path substitution. The
1653 OpenEmbedded build system uses ``pkg-config`` now, which is much more
1654 robust. You can find a list of the ``*-config`` scripts that are disabled
1655 in the ":ref:`migration-1.7-binary-configuration-scripts-disabled`" section
1658 A major part of build-time configuration is about checking for
1659 build-time dependencies and possibly enabling optional functionality as
1660 a result. You need to specify any build-time dependencies for the
1664 build-time or runtime dependencies described in the software's
1670 - *Autotools:* If your source files have a ``configure.ac`` file, then
1675 :ref:`autotools <ref-classes-autotools>` class
1677 :ref:`ref-tasks-configure` task.
1684 - *CMake:* If your source files have a ``CMakeLists.txt`` file, then
1689 :ref:`cmake <ref-classes-cmake>` class and your
1691 :ref:`ref-tasks-configure` task.
1702 - *Other:* If your source files do not have a ``configure.ac`` or
1706 :ref:`ref-tasks-configure` task
1717 ``./configure --help`` and look for the options you need to set.
1721 been enabled and no additional build-time dependencies need to be added
1731 ``./configure --help`` command within ``${S}`` or consult the software's
1735 ---------------------------------------
1741 ``meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc`` file.
1743 with custom or machine-specific header information. If you customize
1750 ``meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc``).
1759 - Never modify ``linux-libc-headers.inc``. Consider that file to be
1764 - Applications that must talk directly to devices should either provide
1778 to modify the ``linux-kernel-headers.inc`` file. However, take care to not
1788 out-of-tree modules. Your recipe will also need the following::
1793 -----------
1806 the more robust ``pkg-config``. See the note in section
1807 ":ref:`dev-manual/common-tasks:Configuring the Recipe`" for additional information.
1809 - *Parallel build failures:* These failures manifest themselves as
1824 ":ref:`dev-manual/common-tasks:debugging parallel make races`" section.
1826 - *Improper host path usage:* This failure applies to recipes building
1829 from the host system when cross-compiling for the target.
1836 - *Failure to find required libraries/headers:* If a build-time
1844 configure script as well as possibly add additional build-time
1855 ----------
1872 - *Autotools and CMake:* If the software your recipe is building uses
1882 - *Other (using* ``make install``\ *)*: You need to define a ``do_install``
1890 ":ref:`dev-manual/common-tasks:makefile-based package`" section.
1892 - *Manual:* You need to define a ``do_install`` function in your
1893 recipe. The function must first use ``install -d`` to create the
1900 https://www.gnu.org/software/coreutils/manual/html_node/install-invocation.html.
1910 - During the installation process, you might need to modify some of
1912 might need to replace hard-coded paths in an initscript with
1918 re-execute ``do_install`` if needed.
1920 - ``oe_runmake install``, which can be run directly or can be run
1922 :ref:`autotools <ref-classes-autotools>` and
1923 :ref:`cmake <ref-classes-cmake>` classes,
1934 - If you need to install one or more custom CMake toolchain files
1937 :ref:`ref-tasks-install`.
1940 ------------------------
1961 - *SysVinit:* SysVinit is a system and service manager that manages the
1968 :ref:`update-rc.d <ref-classes-update-rc.d>`
1979 - *systemd:* System Management Daemon (systemd) was designed to replace
1985 :ref:`systemd <ref-classes-systemd>` class. See
1991 ---------
1997 - *Splitting Files*: The ``do_package`` task splits the files produced
2003 - *Running QA Checks*: The
2004 :ref:`insane <ref-classes-insane>` class adds a
2010 :ref:`insane <ref-classes-insane>` class and
2011 the ":ref:`ref-manual/qa-checks:qa error and warning messages`"
2014 - *Hand-Checking Your Packages*: After you build your software, you
2016 ``${``\ :term:`WORKDIR`\ ``}/packages-split``
2023 - *Splitting an Application into Multiple Packages*: If you need to
2025 ":ref:`dev-manual/common-tasks:splitting an application into multiple packages`"
2028 - *Installing a Post-Installation Script*: For an example showing how
2029 to install a post-installation script, see the
2030 ":ref:`dev-manual/common-tasks:post-installation scripts`" section.
2032 - *Marking Package Architecture*: Depending on what your recipe is
2040 machine-specific (e.g. the
2052 :ref:`allarch <ref-classes-allarch>` class to
2066 -----------------------------
2073 (``recipe-sysroot``) and one for files that are native to the build host
2074 (``recipe-sysroot-native``).
2085 :ref:`ref-tasks-install` task within
2092 A subset of the files installed by the :ref:`ref-tasks-install` task are
2093 used by the :ref:`ref-tasks-populate_sysroot` task as defined by the the
2103 The `/sysroot-only` is to be used by recipes that generate artifacts
2107 For a more complete description of the :ref:`ref-tasks-populate_sysroot`
2109 :ref:`staging <ref-classes-staging>` class.
2112 -----------------------
2117 determined at build-time.
2121 :term:`PN` values map to ``kernel-big``,
2122 ``kernel-mid``, and ``kernel-small``. Furthermore, each of these recipes
2126 :ref:`kernel <ref-classes-kernel>` class::
2130 Any recipe that inherits the :ref:`kernel <ref-classes-kernel>` class is
2137 an example, consider the :yocto_git:`x86-base.inc
2138 </poky/tree/meta/conf/machine/include/x86/x86-base.inc>` include file, which is a
2140 reason all x86-based machines use the ``linux-yocto`` kernel. Here are the
2143 PREFERRED_PROVIDER_virtual/kernel ??= "linux-yocto"
2144 PREFERRED_VERSION_linux-yocto ??= "4.15%"
2159 PREFERRED_PROVIDER_virtual/kernel ??= "kernel-small"
2170 - ``virtual/kernel``: Provides the name of the kernel recipe to use
2173 - ``virtual/bootloader``: Provides the name of the bootloader to use
2176 - ``virtual/libgbm``: Provides ``gbm.pc``.
2178 - ``virtual/egl``: Provides ``egl.pc`` and possibly ``wayland-egl.pc``.
2180 - ``virtual/libgl``: Provides ``gl.pc`` (i.e. libGL).
2182 - ``virtual/libgles1``: Provides ``glesv1_cm.pc`` (i.e. libGLESv1_CM).
2184 - ``virtual/libgles2``: Provides ``glesv2.pc`` (i.e. libGLESv2).
2192 Properly Versioning Pre-Release Recipes
2193 ---------------------------------------
2197 ``irssi_0.8.16-rc1.bb`` recipe file in the list of example recipes in
2198 the ":ref:`dev-manual/common-tasks:storing and naming the recipe`" section.
2201 change from ``0.8.16-rc1`` to ``0.8.16`` is seen as a decrease by the
2211 REALPV = "0.8.16-rc1"
2214 Post-Installation Scripts
2215 -------------------------
2217 Post-installation scripts run immediately after installing a package on
2219 image. To add a post-installation script to a package, add a
2222 to attach to the ``postinst`` script. To apply the post-installation
2228 A post-installation function has the following structure::
2234 The script defined in the post-installation function is called when the
2240 Any RPM post-installation script that runs on the target should
2241 return a 0 exit code. RPM does not allow non-zero exit codes for
2242 these scripts, and the RPM package manager will cause the package to
2245 Sometimes it is necessary for the execution of a post-installation
2253 :ref:`ref-tasks-rootfs` task.
2256 the use of non-standard native tools that have dependencies during
2261 post-installation script is deferred until first boot. Deferring the
2262 script to the first boot is undesirable and impossible for read-only
2267 There is equivalent support for pre-install, pre-uninstall, and post-uninstall
2275 -------
2282 packages, see ":ref:`dev-manual/common-tasks:customizing images`" section.
2285 --------
2290 - Recipes that use local files
2292 - Using an Autotooled package
2294 - Using a Makefile-based package
2296 - Splitting an application into multiple packages
2298 - Adding binaries to an image
2308 :term:`WORKDIR` in this case - the
2322 ${CC} ${LDFLAGS} helloworld.c -o helloworld
2326 install -d ${D}${bindir}
2327 install -m 0755 helloworld ${D}${bindir}
2330 By default, the ``helloworld``, ``helloworld-dbg``, and
2331 ``helloworld-dev`` packages are built. For information on how to
2333 ":ref:`dev-manual/common-tasks:splitting an application into multiple packages`"
2342 :ref:`autotools <ref-classes-autotools>` class,
2344 Autotool-based application. The result of the build is automatically
2352 LICENSE = "GPL-2.0-or-later"
2355 SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz"
2361 ":ref:`dev-manual/common-tasks:tracking license changes`" section in
2363 Autotool-based recipes in a manner similar to the previous example.
2365 Makefile-Based Package
2384 CFLAGS:prepend = "-I ${S}/include "
2386 In the following example, ``lz4`` is a makefile-based package::
2389 …h multi-cores CPU. It also features an extremely fast decoder, with speed in multiple GB/s per cor…
2392 LICENSE = "BSD-2-Clause | GPL-2.0-only"
2403 file://CVE-2021-3520.patch \
2410 CVE_CHECK_IGNORE += "CVE-2014-4715"
2431 require xorg-lib-common.inc
2457 Sometimes, you need to add pre-compiled binaries to an image. For
2473 :ref:`bin_package <ref-classes-bin-package>` class
2475 In most cases, the :ref:`bin_package <ref-classes-bin-package>` class handles "skipping" the
2478 both the :ref:`ref-tasks-configure`
2479 and :ref:`ref-tasks-compile` tasks,
2481 :ref:`ref-tasks-install` task, which
2483 :ref:`bin_package <ref-classes-bin-package>` class works well when the files extracted into ``${S}``
2494 - Using :term:`DEPENDS` is a good
2502 - Using :term:`DEPENDS` also allows runtime dependencies between
2504 ":ref:`overview-manual/concepts:automatically added runtime dependencies`"
2508 If you cannot use the :ref:`bin_package <ref-classes-bin-package>` class, you need to be sure you a…
2511 - Create a recipe where the
2512 :ref:`ref-tasks-configure` and
2513 :ref:`ref-tasks-compile` tasks do
2522 ``[``\ :ref:`noexec <bitbake-user-manual/bitbake-user-manual-metadata:variable flags>`\ ``]``
2523 flag to turn the tasks into no-ops, as follows::
2529 :ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:deleting a task`,
2531 :ref:`ref-tasks-fetch`,
2532 :ref:`ref-tasks-unpack`, and
2533 :ref:`ref-tasks-patch` tasks to the
2534 :ref:`ref-tasks-install` task.
2536 - Make sure your ``do_install`` task installs the binaries
2539 - Ensure that you set up :term:`FILES`
2547 ---------------------------------
2560 -------------
2565 ":doc:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata`"
2568 - *Variable Assignments and Manipulations:* Variable assignments allow
2577 S = "${WORKDIR}/postfix-${PV}"
2578 CFLAGS += "-DNO_ASM"
2581 - *Functions:* Functions provide a series of actions to be performed.
2592 install -d ${D}${base_bindir}
2604 - *Keywords:* BitBake recipes use only a few keywords. You use keywords
2615 - *Comments (#):* Any lines that begin with the hash character (``#``)
2623 :doc:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata` chapter
2626 - *Line Continuation (\\):* Use the backward slash (``\``) character to
2638 - *Using Variables (${VARNAME}):* Use the ``${VARNAME}`` syntax to
2641 SRC_URI = "${SOURCEFORGE_MIRROR}/libpng/zlib-${PV}.tar.gz"
2647 expansion of these expressions happens on-demand later (e.g.
2658 - *Quote All Assignments ("value"):* Use double quotes around values in
2664 - *Conditional Assignment (?=):* Conditional assignment is used to
2682 - *Appending (+=):* Use the plus character followed by the equals sign
2692 SRC_URI += "file://fix-makefile.patch"
2694 - *Prepending (=+):* Use the equals sign followed by the plus character
2706 - *Appending (:append):* Use the ``:append`` operator to append values
2716 SRC_URI:append = " file://fix-makefile.patch"
2722 SRC_URI:append:sh4 = " file://fix-makefile.patch"
2724 - *Prepending (:prepend):* Use the ``:prepend`` operator to prepend
2734 CFLAGS:prepend = "-I${S}/myincludes "
2740 CFLAGS:prepend:sh4 = "-I${S}/myincludes "
2742 - *Overrides:* You can use overrides to set a value conditionally,
2747 qemuarm where it should be set to "standard/arm-versatile-926ejs",
2751 KBRANCH:qemuarm = "standard/arm-versatile-926ejs"
2761 - *Indentation:* Use spaces for indentation rather than tabs. For
2766 - *Using Python for Complex Operations:* For more advanced processing,
2773 SRC_URI = "ftp://ftp.info-zip.org/pub/infozip/src/zip${@d.getVar('PV',1).replace('.', '')}.tgz
2775 - *Shell Function Syntax:* Write shell functions as if you were writing
2778 it does not require any ``bash`` or other shell-specific
2782 implementations - including those from BusyBox.
2799 ":ref:`bsp-guide/bsp:creating a new bsp layer using the \`\`bitbake-layers\`\` script`"
2804 -------------------------------------
2816 file or include from a lower-level configuration file are as follows:
2818 - :term:`TARGET_ARCH` (e.g. "arm")
2820 - ``PREFERRED_PROVIDER_virtual/kernel``
2822 - :term:`MACHINE_FEATURES` (e.g. "apm screen wifi")
2826 - :term:`SERIAL_CONSOLES` (e.g. "115200;ttyS0 115200;ttyS1")
2828 - :term:`KERNEL_IMAGETYPE` (e.g. "zImage")
2830 - :term:`IMAGE_FSTYPES` (e.g. "tar.gz jffs2")
2834 ``meta-yocto-bsp/conf/machine/``.
2837 -------------------------------
2842 examples in the Source Directory at ``meta/recipes-kernel/linux`` that
2845 If you are creating a new kernel recipe, normal recipe-writing rules
2852 and potentially some of the ``linux-*.inc`` files, most other
2866 ":ref:`kernel-dev/common:changing the configuration`"
2870 --------------------------------------
2882 the ``meta/recipes-bsp/formfactor/files`` directory. This directory
2885 defaults, see the ``meta/recipes-bsp/formfactor/files/config`` file
2904 by layer recipes. It is recommended to keep recipes up-to-date with
2909 using the ``devtool check-upgrade-status`` command. See the
2910 ":ref:`devtool-checking-on-the-upgrade-status-of-a-recipe`"
2916 ``devtool upgrade`` to set up semi-automatic version upgrades. Finally,
2920 -----------------------------------
2940 - When AUH cannot complete the upgrade sequence. This situation
2945 - When for any reason you want fuller control over the upgrade
2954 ":ref:`dev-manual/start:Preparing the Build Host`" section.
2961 $ git config --list
2966 $ git config --global user.name some_name
2967 $ git config --global user.email username@domain.com
2973 $ git clone git://git.yoctoproject.org/auto-upgrade-helper
2974 Cloning into 'auto-upgrade-helper'... remote: Counting objects: 768, done.
2981 AUH is not part of the :term:`OpenEmbedded-Core (OE-Core)` or
2985 :ref:`structure-core-script`
2990 $ source oe-init-build-env your_AUH_build_directory
2992 Re-using an existing build directory and its configurations is not
3001 - If you want to enable :ref:`Build
3002 History <dev-manual/common-tasks:maintaining build output quality>`,
3011 ``upgrade-helper/work/recipe/buildhistory-diff.txt`` file found in
3014 - If you want to enable testing through the
3015 :ref:`testimage <ref-classes-testimage*>`
3036 ``upgrade-helper/upgrade-helper.conf`` configuration file in your
3038 :yocto_git:`AUH source repository </auto-upgrade-helper/tree/>`.
3042 described earlier, you must enable it in ``upgrade-helper.conf``.
3045 with Poky and located in ``meta-yocto`` and you do not set a
3047 ``upgrade-helper.conf`` configuration, and you specify "-e all" on
3048 the AUH command-line, the utility automatically sends out emails to
3053 - *Upgrading a Specific Recipe:* To upgrade a specific recipe, use the
3056 $ upgrade-helper.py recipe_name
3060 $ upgrade-helper.py xmodmap
3062 - *Upgrading a Specific Recipe to a Particular Version:* To upgrade a
3065 $ upgrade-helper.py recipe_name -t version
3069 $ upgrade-helper.py xmodmap -t 1.2.3
3071 - *Upgrading all Recipes to the Latest Versions and Suppressing Email
3075 $ upgrade-helper.py all
3077 - *Upgrading all Recipes to the Latest Versions and Send Email
3082 $ upgrade-helper.py -e all
3087 ${BUILDDIR}/upgrade-helper/timestamp
3095 :yocto_git:`weeklyjob.sh </auto-upgrade-helper/tree/weeklyjob.sh>`
3099 -------------------------
3103 :doc:`devtool upgrade </ref-manual/devtool-reference>`.
3105 ":ref:`sdk-manual/extensible:use \`\`devtool upgrade\`\` to create a version of the recipe that sup…
3109 To see all the command-line options available with ``devtool upgrade``,
3112 $ devtool upgrade -h
3118 $ devtool latest-version recipe_name
3121 works in a less-automated manner than AUH. Specifically,
3139 ":ref:`bitbake-layers <bsp-guide/bsp:creating a new bsp layer using the \`\`bitbake-layers\`\` scri…
3141 ``meta-oe`` layer in the ``meta-openembedded`` repository. For this
3144 /home/scottrif/meta-openembedded
3150 $ bitbake-layers add-layer /home/scottrif/meta-openembedded/meta-oe
3166 Using the ``-V`` option is not necessary. Omitting the version number causes
3171 $ devtool upgrade nano -V 2.9.3
3216 $ devtool finish nano meta-oe
3222 NOTE: Adding new patch 0001-nano.bb-Stuff-I-changed-when-upgrading-nano.bb.patch
3224 NOTE: Removing file /home/scottrif/meta-openembedded/meta-oe/recipes-support/nano/nano_2.7.4.bb
3225 NOTE: Moving recipe file to /home/scottrif/meta-openembedded/meta-oe/recipes-support/nano
3226 …NOTE: Leaving source tree /home/scottrif/poky/build/workspace/sources/nano as-is; if you no longer…
3231 source directory in a sub-directory named ``nano`` in this case.
3234 ---------------------------
3237 :ref:`dev-manual/common-tasks:Using the Auto Upgrade Helper (AUH)` or
3238 by :ref:`dev-manual/common-tasks:Using \`\`devtool upgrade\`\``,
3263 - License statements were updated for the new version. For this
3274 - Custom patches carried by the older version of the recipe might
3290 backwards-compatibility. If so, you need to take steps to mitigate or
3309 force a re-compile and quickly test your altered code. Once you settle
3331 BP = "${BPN}-${PV}"
3338 ${TMPDIR}/work/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}
3342 - :term:`TMPDIR`: The top-level build
3345 - :term:`MULTIMACH_TARGET_SYS`:
3348 - :term:`PN`: The recipe name.
3350 - :term:`EXTENDPE`: The epoch - (if
3354 - :term:`PV`: The recipe version.
3356 - :term:`PR`: The recipe revision.
3358 As an example, assume a Source Directory top-level folder named
3360 ``qemux86-poky-linux`` machine target system. Furthermore, suppose your
3364 poky/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0
3379 :ref:`devtool workflow <sdk-manual/extensible:using \`\`devtool\`\` in your sdk workflow>`
3389 ":ref:`dev-manual/common-tasks:finding temporary source code`" section to
3416 $ bitbake -c compile -f package
3418 The ``-f`` or ``--force`` option forces the specified task to
3420 editing and re-testing iteratively until things work as expected.
3426 (i.e. ``bitbake -c clean package`` and ``bitbake -c cleanall package``).
3429 ":ref:`dev-manual/common-tasks:conserving disk space during builds`"
3461 :ref:`ref-tasks-patch` are run for the
3464 directory. In the new terminal, all the OpenEmbedded build-related
3472 ``matchbox-desktop``::
3474 $ bitbake matchbox-desktop -c devshell
3483 - The ``PATH`` variable includes the cross-toolchain.
3485 - The ``pkgconfig`` variables find the correct ``.pc`` files.
3487 - The ``configure`` command finds the Yocto Project site files as well
3503 $ bitbake -c task
3507 - Execution of a task's ``run.*`` script and BitBake's execution of
3508 a task are identical. In other words, running the script re-runs
3509 the task just as it would be run using the ``bitbake -c`` command.
3511 - Any ``run.*`` file that does not have a ``.pid`` extension is a
3517 provide the appropriate options for cross-compilation and so forth as
3525 - It is worth remembering that when using ``devshell`` you need to
3526 use the full compiler name such as ``arm-poky-linux-gnueabi-gcc``
3532 - It is also worth noting that ``devshell`` still works over X11
3543 :ref:`ref-tasks-patch` are run for the
3568 ``matchbox-desktop``::
3570 $ bitbake matchbox-desktop -c pydevshell
3588 -----------------------
3599 - For information on how to build an image using
3601 :doc:`/toaster-manual/index`.
3603 - For information on how to use ``devtool`` to build images, see the
3604 ":ref:`sdk-manual/extensible:using \`\`devtool\`\` in your sdk workflow`"
3608 - For a quick example on how to build an image using the
3610 :doc:`/brief-yoctoprojectqs/index` document.
3615 using BitBake, see the ":ref:`overview-manual/concepts:images`" section in the
3620 .. image:: figures/bitbake-build-flow.png
3629 :ref:`structure-core-script`)::
3631 $ source oe-init-build-env [build_dir]
3665 targets are the images in ``meta/recipes-core/images``,
3666 ``meta/recipes-sato/images``, and so forth all found in the
3671 ":ref:`ref-manual/images:Images`" chapter in the Yocto
3675 ``core-image-minimal`` image::
3677 $ bitbake core-image-minimal
3683 run pre-built images such as ``qemux86`` and ``qemuarm``, see the
3684 :doc:`/sdk-manual/index` manual. For
3689 ------------------------------------------------------------------
3698 and how to account for cross-build dependencies between the
3712 - *Create Separate Configuration Files*: You need to create a single
3722 for two distributions such as "poky" and "poky-lsb". In this case,
3733 They must reside in the current build directory in a sub-directory of
3742 Consequently, using the configuration file as a pre-configuration
3746 - *Add the BitBake Multi-configuration Variable to the Local
3765 - *Launch BitBake*: Use the following BitBake command form to launch
3772 $ bitbake mc:x86:core-image-minimal mc:arm:core-image-sato mc::core-image-base
3774 The previous BitBake command builds a ``core-image-minimal`` image
3776 ``core-image-sato`` image that is configured through the ``arm.conf``
3777 configuration file and a ``core-image-base`` that is configured
3794 build a ``core-image-sato`` image for an "x86" multiconfig, the root
3797 :ref:`ref-tasks-image` task in the
3798 ``core-image-sato`` recipe depends on the completion of the
3799 :ref:`ref-tasks-rootfs` task of the
3800 ``core-image-minimal`` recipe.
3810 to be added to the recipe that builds the ``core-image-sato`` image::
3812 do_image[mcdepends] = "mc:x86:arm:core-image-minimal:do_rootfs"
3816 ``do_rootfs`` task from the ``core-image-minimal`` recipe associated
3822 $ bitbake mc:x86:core-image-sato
3825 ``core-image-sato`` image for the "x86" multiconfig. Because of the
3831 ``core-image-sato`` recipe::
3833 do_image[mcdepends] = "mc:x86:arm:core-image-minimal:do_image"
3836 create the ``core-image-minimal`` image for the "arm" build since the
3844 Building an Initial RAM Filesystem (initramfs) Image
3845 ----------------------------------------------------
3847 An initial RAM filesystem (initramfs) image provides a temporary root
3853 The initramfs image is the successor of initial RAM disk (initrd). It
3863 ``core-image-minimal-initramfs.bb`` recipe found in the
3864 ``meta/recipes-core`` directory of the :term:`Source Directory`
3900 `Initial RAM Disk (initrd) <https://en.wikipedia.org/wiki/Initrd>`__.
3903 information, see the :ref:`ref-classes-image-live` file.
3913 are set by the :ref:`image <ref-classes-image>`
3914 or :ref:`core-image <ref-classes-core-image>`
3937 …on ":ref:`dev-manual/common-tasks:building images for multiple targets using multiple configuratio…
3941 TMPDIR="${TOPDIR}/tmp-initramfscfg"
3949 INITRAMFS_DEPLOY_DIR_IMAGE = "${TOPDIR}/tmp-initramfscfg/deploy/images/${MACHINE}"
3963 or to build a different :term:`DISTRO` for it such as ``poky-tiny``.
3967 ----------------------
3970 requiring less on-die or in-package memory (cheaper), better performance
3973 real-world examples where a very small distribution gives you distinct
3978 distribution to even smaller sizes than the ``poky-tiny`` distribution,
3979 which is around 5 Mbytes, that can be built out-of-the-box using the
3988 initial RAM disks:
3990 - :ref:`Determine your goals and guiding principles
3991 <dev-manual/common-tasks:goals and guiding principles>`
3993 - :ref:`dev-manual/common-tasks:understand what contributes to your image size`
3995 - :ref:`Reduce the size of the root filesystem
3996 <dev-manual/common-tasks:trim the root filesystem>`
3998 - :ref:`Reduce the size of the kernel <dev-manual/common-tasks:trim the kernel>`
4000 - :ref:`dev-manual/common-tasks:remove package management requirements`
4002 - :ref:`dev-manual/common-tasks:look for other ways to minimize size`
4004 - :ref:`dev-manual/common-tasks:iterate on the process`
4013 - Determine how much space you need (e.g. a kernel that is 1 Mbyte or
4016 - Find the areas that are currently taking 90% of the space and
4019 - Do not create any difficult "hacks" to achieve your goals.
4021 - Leverage the device-specific options.
4023 - Work in a separate layer so that you keep changes isolated. For
4025 ":ref:`dev-manual/common-tasks:understanding and creating layers`" section.
4031 distribution. You can use the Yocto Project out-of-the-box to create the
4032 ``poky-tiny`` distribution. Ultimately, you will want to make changes in
4033 your own distribution that are likely modeled after ``poky-tiny``.
4037 To use ``poky-tiny`` in your build, set the :term:`DISTRO` variable in your
4038 ``local.conf`` file to "poky-tiny" as described in the
4039 ":ref:`dev-manual/common-tasks:creating your own distribution`"
4056 - ``ksize.py``: Reports component sizes for the kernel build objects.
4058 - ``dirsize.py``: Reports component sizes for the root filesystem.
4061 view file dependencies in a human-readable form:
4063 - ``merge_config.sh``: Helps you manage configuration files and
4072 repositories (i.e. ``linux-yocto-3.14``, ``linux-yocto-3.10``,
4073 ``linux-yocto-3.8``, and so forth) in the ``scripts/kconfig``
4077 ":ref:`kernel-dev/common:creating configuration fragments`"
4080 - ``bitbake -u taskexp -g bitbake_target``: Using the BitBake command
4097 $ cd root-directory-of-image
4098 $ dirsize.py 100000 > dirsize-100k.log
4099 $ cat dirsize-100k.log
4112 $ cd image-directory
4113 $ bitbake -u taskexp -g image
4128 VIRTUAL-RUNTIME_dev_manager = ""
4134 Mbyte journal. If you are okay with running read-only, you do not need
4145 The kernel is built by including policies for hardware-independent
4153 Run the ``ksize.py`` script from the top-level Linux build directory to
4156 $ cd top-level-linux-build-directory
4161 the built-in ``.o`` files for drivers, networking, core kernel files,
4167 To examine, or drill down, into any particular area, use the ``-d``
4170 $ ksize.py -d > ksize.log
4203 "package-management" is not part of your
4217 - ``glibc``: In general, follow this process:
4234 - ``busybox``: For BusyBox, use a process similar as described for
4255 -----------------------------------------
4277 - *Share the Build Directory:* If at all possible, share the
4284 can reuse the existing native and often cross-recipes for multiple
4294 - *Enable the Appropriate Package Architecture:* By default, the
4305 :ref:`allarch <ref-classes-allarch>` class.
4309 If your recipe needs to generate packages that are machine-specific
4311 machine-architecture dependent, which makes your recipe also
4312 machine-architecture dependent, make sure your recipe enables the
4327 - *Choose a Generic Tuning File if Possible:* Some tunes are more
4340 - *Manage Granular Level Packaging:* Sometimes there are cases where
4345 :yocto_git:`meta-freescale </meta-freescale/>`.
4347 …:yocto_git:`fsl-dynamic-packagearch </meta-freescale/tree/classes/fsl-dynamic-packagearch.bbclass>`
4349 the AMD GPU. The i.MX6-based boards can do the same because all
4352 the sub-architecture values. If so, the class sets the
4355 provide or depend on one of the sub-architecture values but it
4356 matches a value in the machine-specific filter, it sets
4361 - *Use Tools to Debug Issues:* Sometimes you can run into situations
4365 situations are usually due to references to machine-specific
4370 and so forth in code that is supposed to only be tune-specific or
4388 - ``state-diff-machines.sh``*:* You can find this tool in the
4392 - *BitBake's "-S printdiff" Option:* Using this option causes
4394 (e.g. in the shared state cache) and then run ``bitbake-diffsigs``
4399 -----------------------------------------
4419 :ref:`externalsrc <ref-classes-externalsrc>` class
4426 EXTERNALSRC:pn-myrecipe = "path-to-your-source-tree"
4437 locally inherit the :ref:`externalsrc <ref-classes-externalsrc>`
4440 By default, :ref:`ref-classes-externalsrc` builds the source code in a
4448 EXTERNALSRC_BUILD:pn-myrecipe = "path-to-your-source-tree"
4451 ---------------------------
4471 DL_DIR = "/home/your-download-dir/"
4484 $ bitbake target --runonly=fetch
4497 files, you can create your "own-mirror" and build your target.
4506 :ref:`own-mirrors <ref-classes-own-mirrors>` class, and use the
4510 SOURCE_MIRROR_URL ?= "file:///home/your-download-dir/"
4511 INHERIT += "own-mirrors"
4514 The :term:`SOURCE_MIRROR_URL` and :ref:`own-mirrors <ref-classes-own-mirrors>`
4518 from your "own-mirror" are used.
4553 history <dev-manual/common-tasks:maintaining build output quality>`.
4555 2. Use the ``buildhistory-collect-srcrevs`` command to collect the
4558 ":ref:`dev-manual/common-tasks:build history package information`"
4576 - :term:`BB_NUMBER_THREADS`:
4579 - :term:`BB_NUMBER_PARSE_THREADS`:
4582 - :term:`PARALLEL_MAKE`: Extra
4584 :ref:`ref-tasks-compile` task in
4587 - :term:`PARALLEL_MAKEINST`:
4589 :ref:`ref-tasks-install` task in
4594 auto-scaling ensures that the build system fundamentally takes advantage
4600 - File system type: The file system type that the build is being
4605 - Disabling the updating of access time using ``noatime``: The
4609 - Setting a longer commit: Using the "commit=" mount option increases
4615 - Choosing the packaging backend: Of the available packaging backends,
4619 - Using ``tmpfs`` for :term:`TMPDIR`
4621 the benefits are limited due to the compiler using ``-pipe``. The
4627 - Inheriting the
4628 :ref:`rm_work <ref-classes-rm-work>` class:
4643 - Remove items from
4647 - Exclude debug symbols and other debug information: If you do not need
4648 these symbols and other debug information, disabling the ``*-dbg``
4654 - Disable static library generation for recipes derived from
4659 STATICLIBCONF = "--disable-static"
4660 STATICLIBCONF:sqlite3-native = ""
4665 - Some recipes need static libraries in order to work correctly
4666 (e.g. ``pseudo-native`` needs ``sqlite3-native``). Overrides,
4670 - Some packages have packaging code that assumes the presence of
4681 - :ref:`How to include static library files
4682 <dev-manual/common-tasks:including static library files>`
4684 - :ref:`How to use the Multilib feature to combine multiple versions of
4686 <dev-manual/common-tasks:combining multiple versions of library files into one image>`
4688 - :ref:`How to install multiple versions of the same library in parallel on
4690 <dev-manual/common-tasks:installing multiple versions of the same library>`
4693 ------------------------------
4703 variable includes ``${PN}-staticdev``, which represents all static
4709 static library files through ``${PN}-dev``.
4715 …PACKAGES = "${PN}-src ${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_…
4716 PACKAGES_DYNAMIC = "^${PN}-locale-.*"
4730 FILES:${PN}-bin = "${bindir}/* ${sbindir}/*"
4732 FILES:${PN}-doc = "${docdir} ${mandir} ${infodir} ${datadir}/gtk-doc \
4734 SECTION:${PN}-doc = "doc"
4737 FILES:${PN}-dev = "${includedir} ${FILES_SOLIBSDEV} ${libdir}/*.la \
4742 SECTION:${PN}-dev = "devel"
4743 ALLOW_EMPTY:${PN}-dev = "1"
4744 RDEPENDS:${PN}-dev = "${PN} (= ${EXTENDPKGV})"
4746 FILES:${PN}-staticdev = "${libdir}/*.a ${base_libdir}/*.a ${libdir}/${BPN}/*.a"
4747 SECTION:${PN}-staticdev = "devel"
4748 RDEPENDS:${PN}-staticdev = "${PN}-dev (= ${EXTENDPKGV})"
4751 -----------------------------------------------------------
4759 An example would be where you have most of a system compiled in 32-bit
4760 mode using 32-bit libraries, but you have something large, like a
4761 database engine, that needs to be a 64-bit application and uses 64-bit
4762 libraries. Multilib allows you to get the best of both 32-bit and 64-bit
4765 While the Multilib feature is most commonly used for 32 and 64-bit
4772 There are several examples in the ``meta-skeleton`` layer found in the
4775 - :oe_git:`conf/multilib-example.conf </openembedded-core/tree/meta-skeleton/conf/multilib-example…
4778 - :oe_git:`conf/multilib-example2.conf </openembedded-core/tree/meta-skeleton/conf/multilib-exampl…
4781 - :oe_git:`recipes-multilib/images/core-image-multilib-example.bb </openembedded-core/tree/meta-sk…
4787 User-specific requirements drive the Multilib feature. Consequently,
4788 there is no one "out-of-the-box" configuration that would
4801 For the most part, the :ref:`Multilib <ref-classes-multilib*>`
4804 :term:`MLPREFIX` is the particular multilib (e.g. "lib32-" or "lib64-").
4825 MACHINE = "qemux86-64"
4828 DEFAULTTUNE:virtclass-multilib-lib32 = "x86"
4829 IMAGE_INSTALL:append = "lib32-glib-2.0"
4835 ``meta/conf/machine/include/ia32/arch-ia32.inc``.
4837 The example then includes ``lib32-glib-2.0`` in all the images, which
4841 $ bitbake core-image-sato
4846 $ bitbake lib32-glib-2.0
4855 - The typical convention used for the class extension code as used by
4862 - The :term:`TARGET_VENDOR`
4863 value under Multilib will be extended to "-vendormlmultilib" (e.g.
4864 "-pokymllib32" for a "lib32" Multilib with Poky). The reason for this
4865 slightly unwieldy contraction is that any "-" characters in the
4869 Here are the implementation details for the RPM Package Management System:
4871 - A unique architecture is defined for the Multilib packages, along
4872 with creating a unique deploy folder under ``tmp/deploy/rpm`` in the
4874 example, consider ``lib32`` in a ``qemux86-64`` image. The possible
4878 - The ``${MLPREFIX}`` variable is stripped from ``${PN}`` during RPM
4879 packaging. The naming for a normal RPM package and a Multilib RPM
4880 package in a ``qemux86-64`` system resolves to something similar to
4881 ``bash-4.1-r2.x86_64.rpm`` and ``bash-4.1.r2.lib32_x86.rpm``,
4884 - When installing a Multilib image, the RPM backend first installs the
4887 - The build system relies on RPM to resolve the identical files in the
4892 - The ``${MLPREFIX}`` is not stripped from ``${PN}`` during IPK
4893 packaging. The naming for a normal RPM package and a Multilib IPK
4894 package in a ``qemux86-64`` system resolves to something like
4895 ``bash_4.1-r2.x86_64.ipk`` and ``lib32-bash_4.1-rw:x86.ipk``,
4898 - The IPK deploy folder is not modified with ``${MLPREFIX}`` because
4902 - IPK defines a sanity check for Multilib installation using certain
4906 ------------------------------------------------
4924 the two separate versions of the ``clutter`` library to co-exist on the
4927 .. code-block:: none
4929 clutter-1.6_1.6.20.bb
4930 clutter-1.8_1.8.4.bb
4939 DEPENDS = "clutter-1.8"
4941 Working with Pre-Built Libraries
4945 -------------
4948 release pre-built binaries. When shared libraries are built, they should
4950 <https://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html>`__
4958 running ``readelf -d filename | grep SONAME``.
4961 pre-built libraries.
4964 -------------------
4966 In this example we work with pre-built libraries for the FT4222H USB I/O chip.
4970 ├── build-arm-hisiv300
4972 ├── build-arm-v5-sf
4974 ├── build-arm-v6-hf
4976 ├── build-arm-v7-hf
4978 ├── build-arm-v8
4980 ├── build-i386
4982 ├── build-i486
4984 ├── build-mips-eglibc-hf
4986 ├── build-pentium
4988 ├── build-x86_64
4991 │ ├── get-version.c
5003 - The vendor will probably have a proprietary licence, so set
5005 - The vendor provides a tarball containing libraries so set :term:`SRC_URI`
5007 - Set :term:`COMPATIBLE_HOST` so that the recipe cannot be used with an
5010 - As the vendor provides versioned libraries, we can use ``oe_soinstall``
5011 from :ref:`ref-classes-utils` to install the shared library and create
5013 non-versioned library guidelines in the next section.
5014 - As the vendor likely used :term:`LDFLAGS` different from those in your Yocto
5017 - The vendor will typically ship release builds without debugging symbols.
5029 COMPATIBLE_HOST = "(i.86|x86_64).*-linux"
5032 # at https://ftdichip.com/wp-content/uploads/2021/01/libft4222-linux-1.4.4.44.zip
5033 # Found on https://ftdichip.com/software-examples/ft4222h-software-examples/
5036 SRC_URI = "file://libft4222-linux-${PV}.tgz"
5040 ARCH_DIR:x86-64 = "build-x86_64"
5041 ARCH_DIR:i586 = "build-i386"
5042 ARCH_DIR:i686 = "build-i386"
5050 install -m 0755 -d ${D}${libdir}
5052 install -d ${D}${includedir}
5053 install -m 0755 ${S}/*.h ${D}${includedir}
5060 Non-Versioned Libraries
5061 -----------------------
5073 name (i.e. ``-lfoo`` to the linker). However, the linker follows the symbolic
5076 along with the headers in the development package ``${PN}-dev`` along with the
5085 recipe. By default, ``libfoo.so`` gets packaged into ``${PN}-dev``, which
5086 triggers a QA warning that a non-symlink library is in a ``-dev`` package,
5087 and binaries in the same recipe link to the library in ``${PN}-dev``,
5096 FILES:${PN}-dev = "... ${FILES_SOLIBSDEV} ..."
5100 variables are then used in ``FILES:${PN}`` and ``FILES:${PN}-dev``, which puts
5101 the real libraries into ``${PN}`` and the unversioned symbolic link into ``${PN}-dev``.
5110 ``${PN}-dev``. The changes are required because unless :term:`PACKAGES` is changed,
5111 ``${PN}-dev`` collects files before `${PN}`. ``${PN}-dev`` must not collect any of
5122 The example below installs an unversioned x86-64 pre-built library named
5124 x86-64 architecture while the :term:`INSANE_SKIP`, :term:`INHIBIT_PACKAGE_STRIP`
5135 COMPATIBLE_HOST = "x86_64.*-linux"
5144 install -d ${D}${libdir}
5145 install -m 0755 ${WORKDIR}/libfoo.so ${D}${libdir}
5151 x32 processor-specific Application Binary Interface (`x32
5152 psABI <https://software.intel.com/en-us/node/628948>`__) is a native
5153 32-bit processor-specific ABI for Intel 64 (x86-64) architectures. An
5158 Some processing environments prefer using 32-bit applications even when
5159 running on Intel 64-bit platforms. Consider the i386 psABI, which is a
5160 very old 32-bit ABI for Intel 64-bit platforms. The i386 psABI does not
5161 provide efficient use and access of the Intel 64-bit processor
5163 psABI. This ABI is newer and uses 64-bits for data sizes and program
5174 - You can create packages and images in x32 psABI format on x86_64
5177 - You can successfully build recipes with the x32 toolchain.
5179 - You can create and boot ``core-image-minimal`` and
5180 ``core-image-sato`` images.
5182 - There is RPM Package Manager (RPM) support for x32 binaries.
5184 - There is support for large images.
5189 MACHINE = "qemux86-64"
5190 DEFAULTTUNE = "x86-64-x32"
5191 baselib = "${@d.getVar('BASE_LIB:tune-' + (d.getVar('DEFAULTTUNE') \
5198 $ bitbake core-image-sato
5204 is the standard mechanism for accessing GObject-based software from
5217 GObject Introspection Repository (GIR) files go to ``-dev`` packages,
5225 Generating this data in a cross-compilation environment is difficult
5230 perfectly as mentioned in the ":ref:`dev-manual/common-tasks:known issues`"
5234 ---------------------------------------------
5240 :ref:`gobject-introspection <ref-classes-gobject-introspection>`
5245 "gobject-introspection-data" is not in
5247 and that "qemu-usermode" is not in
5260 See recipes in the ``oe-core`` repository that use that
5265 in a cross-compilation environment. For such cases, custom-made fixes
5268 lists <resources-mailinglist>`.
5277 ----------------------------------------------
5284 - Add the following to your distro configuration::
5286 DISTRO_FEATURES_BACKFILL_CONSIDERED = "gobject-introspection-data"
5292 - Add the following to your machine configuration::
5294 MACHINE_FEATURES_BACKFILL_CONSIDERED = "qemu-usermode"
5311 --------------------------------------------
5316 1. Make sure that "gobject-introspection-data" is not in
5318 and that "qemu-usermode" is not in
5321 2. Build ``core-image-sato``.
5331 https://python-gtk-3-tutorial.readthedocs.io/en/latest/introduction.html
5334 ------------
5338 - ``qemu-ppc64`` immediately crashes. Consequently, you cannot build
5341 - x32 is not supported by QEMU. Consequently, introspection data is
5344 - musl causes transient GLib binaries to crash on assertion failures.
5347 - Because QEMU is not able to run the binaries correctly, introspection
5351 - QEMU usermode might not work properly when running 64-bit binaries
5352 under 32-bit host machines. In particular, "qemumips64" is known to
5362 - Understand where the installed toolchain resides. For cases where you
5366 - Make sure you add the layer that contains the toolchain to your
5370 - Set the ``EXTERNAL_TOOLCHAIN`` variable in your ``local.conf`` file
5376 https://github.com/MentorEmbedded/meta-sourcery/. You can find
5399 ":ref:`dev-manual/common-tasks:generate an image using an existing kickstart file`"
5407 ":ref:`ref-manual/kickstart:openembedded kickstart (\`\`.wks\`\`) reference`"
5414 ":ref:`dev-manual/common-tasks:using the wic plugin interface`" section
5423 ----------
5428 - The name "Wic" is derived from OpenEmbedded Image Creator (oeic). The
5432 - Wic is loosely based on the Meego Image Creator (``mic``) framework.
5438 - Wic is a completely independent standalone utility that initially
5439 provides easier-to-use and more flexible replacements for an existing
5440 functionality in OE-Core's
5441 :ref:`image-live <ref-classes-image-live>`
5444 general-purpose partitioning language, which is based on Redhat
5448 ------------
5453 - The Linux distribution on your development host must support the
5454 Yocto Project. See the ":ref:`detailed-supported-distros`"
5458 - The standard system utilities, such as ``cp``, must be installed on
5461 - You must have sourced the build environment setup script (i.e.
5462 :ref:`structure-core-script`) found in the
5465 - You need to have the build artifacts already available, which
5467 Openembedded build system (e.g. ``core-image-minimal``). While it
5472 - You must build several native tools, which are built to run on the
5475 $ bitbake parted-native dosfstools-native mtools-native
5477 - Include "wic" as part of the
5481 - Include the name of the :ref:`wic kickstart file <openembedded-kickstart-wks-reference>`
5485 ------------
5491 $ wic -h
5492 $ wic --help
5522 beaglebone-yocto Create SD card image for Beaglebone
5523 qemux86-directdisk Create a qemu machine 'pcbios' direct disk image
5524 systemd-bootdisk Create an EFI disk image with systemd-boot
5527 sdimage-bootpart Create SD card image with a boot partition
5528 directdisk-multi-rootfs Create multi rootfs image using rootfs plugin
5530 … directdisk-bootloader-config Create a 'pcbios' direct disk image with custom bootloader config
5531 qemuriscv Create qcow2 image for RISC-V QEMU machines
5532 directdisk-gpt Create a 'pcbios' direct disk image
5533 efi-bootdisk
5538 "beaglebone-yocto" image::
5540 $ wic list beaglebone-yocto help
5546 -----------------
5552 - *Raw Mode:* You explicitly specify build artifacts through Wic
5553 command-line arguments.
5555 - *Cooked Mode:* The current
5587 -h, --help show this help message and exit
5588 -o OUTDIR, --outdir OUTDIR
5590 -e IMAGE_NAME, --image-name IMAGE_NAME
5591 name of the image to use the artifacts from e.g. core-
5592 image-sato
5593 -r ROOTFS_DIR, --rootfs-dir ROOTFS_DIR
5596 -b BOOTIMG_DIR, --bootimg-dir BOOTIMG_DIR
5600 -k KERNEL_DIR, --kernel-dir KERNEL_DIR
5603 -n NATIVE_SYSROOT, --native-sysroot NATIVE_SYSROOT
5606 -s, --skip-build-check
5608 -f, --build-rootfs build rootfs
5609 -c {gzip,bzip2,xz}, --compress-with {gzip,bzip2,xz}
5611 -m, --bmap generate .bmap
5612 --no-fstab-update Do not change fstab file.
5613 -v VARS_DIR, --vars VARS_DIR
5616 -D, --debug output debug information
5630 by using the "-e" option. Wic looks in the Build Directory (e.g.
5635 $ wic create wks_file -e IMAGE_NAME
5646 -e IMAGE_NAME, --image-name IMAGE_NAME
5647 name of the image to use the artifacts from e.g. core-
5648 image-sato
5651 --------------------------------
5655 files can be found in the :ref:`overview-manual/development-environment:yocto project source reposi…
5658 poky/meta-yocto-bsp/wic
5659 poky/scripts/lib/wic/canned-wks
5665 beaglebone-yocto Create SD card image for Beaglebone
5667 qemux86-directdisk Create a QEMU machine 'pcbios' direct disk image
5668 directdisk-gpt Create a 'pcbios' direct disk image
5671 systemd-bootdisk Create an EFI disk image with systemd-boot
5673 sdimage-bootpart Create SD card image with a boot partition
5674 directdisk-multi-rootfs Create multi rootfs image using rootfs plugin
5675 … directdisk-bootloader-config Create a 'pcbios' direct disk image with custom bootloader config
5681 $ wic create directdisk -r rootfs_dir -b bootimg_dir \
5682 -k kernel_dir -n native_sysroot
5687 # short-description: Create an EFI disk image for genericx86*
5688 # long-description: Creates a partitioned EFI disk image for genericx86* machines
5689 …part /boot --source bootimg-efi --sourceparams="loader=grub-efi" --ondisk sda --label msdos --acti…
5690 part / --source rootfs --ondisk sda --fstype=ext4 --label platform --align 1024 --use-uuid
5691 part swap --ondisk sda --size 44 --label swap1 --fstype=swap
5693 bootloader --ptable gpt --timeout=5 --append="rootfstype=ext4 console=ttyS0,115200 console=tty0"
5696 ------------------------------
5708 values that you specify using ``--source`` commands in kickstart files
5714 If you use plugins that have build-time dependencies (e.g. native
5728 the ``BootimgEFIPlugin`` source plugin found in the ``bootimg-efi.py``
5739 When the Wic implementation needs to invoke a partition-specific
5741 ``--source`` parameter used in the kickstart file given to that
5745 part /boot --source bootimg-pcbios --ondisk sda --label boot --active --align 1024
5748 members of the matching source plugin (i.e. ``bootimg-pcbios``) in the
5749 ``bootimg-pcbios.py`` plugin file are used.
5752 the ``bootimg-pcbios.py`` file for the previous command along with an
5754 a partition using an implementation-specific function::
5764 name = 'bootimg-pcbios'
5797 - ``do_prepare_partition()``: Called to populate a partition with
5801 - ``do_configure_partition()``: Called before
5805 - ``do_install_disk()``: Called after all partitions have been
5809 - ``do_stage_partition()``: Special content-staging hook called
5812 Typically, a partition just uses the passed-in parameters (e.g. the
5820 ``get_bitbake_var()`` allows you to access non-standard variables that
5833 ------------
5837 ":ref:`dev-manual/common-tasks:requirements`" section have been met. The
5839 ``core-image-minimal``.
5847 $ wic create mkefidisk -e core-image-minimal
5848 INFO: Building wic-tools...
5853 ./mkefidisk-201804191017-sda.direct
5856 …: /home/stephano/yocto/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/…
5857 … /home/stephano/yocto/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r…
5858 KERNEL_DIR: /home/stephano/yocto/build/tmp-glibc/deploy/images/qemux86
5859 …T: /home/stephano/yocto/build/tmp-glibc/work/i586-oe-linux/wic-tools/1.0-r0/recipe-s…
5862 /home/stephano/yocto/openembedded-core/scripts/lib/wic/canned-wks/mkefidisk.wks
5865 in cooked mode and supplying a kickstart file and the "-e" option to
5883 $ oe-run-native bmaptool copy mkefidisk-201804191017-sda.direct /dev/sdX
5887 $ sudo dd if=mkefidisk-201804191017-sda.direct of=/dev/sdX
5893 ":ref:`dev-manual/common-tasks:flashing images using \`\`bmaptool\`\``"
5902 ``directdisk-gpt`` kickstart file.
5906 ``directdisk-gpt.wks`` file resides is
5907 ``scripts/lib/image/canned-wks/``, which is located in the
5913 In this example, the existing ``directdisk-gpt`` file already does most
5916 ``directdisk-gpt`` kickstart file uses.
5918 The example begins by making a copy of the ``directdisk-gpt.wks`` file
5919 in the ``scripts/lib/image/canned-wks`` directory and then by changing
5923 $ cp /home/stephano/yocto/poky/scripts/lib/wic/canned-wks/directdisk-gpt.wks \
5924 /home/stephano/yocto/poky/scripts/lib/wic/canned-wks/directdisksdb-gpt.wks
5926 Next, the example modifies the ``directdisksdb-gpt.wks`` file and
5927 changes all instances of "``--ondisk sda``" to "``--ondisk sdb``". The
5931 part /boot --source bootimg-pcbios --ondisk sdb --label boot --active --align 1024
5932 part / --source rootfs --ondisk sdb --fstype=ext4 --label platform --align 1024 --use-uuid
5935 example generates the ``directdisksdb-gpt`` image. The command points
5936 the process at the ``core-image-minimal`` artifacts for the Next Unit of
5941 $ wic create directdisksdb-gpt -e core-image-minimal
5942 INFO: Building wic-tools...
5953 ./directdisksdb-gpt-201710090938-sdb.direct
5956 …: /home/stephano/yocto/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/…
5957 … /home/stephano/yocto/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r…
5958 KERNEL_DIR: /home/stephano/yocto/build/tmp-glibc/deploy/images/qemux86
5959 …T: /home/stephano/yocto/build/tmp-glibc/work/i586-oe-linux/wic-tools/1.0-r0/recipe-s…
5962 /home/stephano/yocto/poky/scripts/lib/wic/canned-wks/directdisksdb-gpt.wks
5968 $ sudo dd if=directdisksdb-gpt-201710090938-sdb.direct of=/dev/sdb
5979 ``-o`` option to cause Wic to create the output somewhere other than the
5982 $ wic create test.wks -o /home/stephano/testwic \
5983 …--rootfs-dir /home/stephano/yocto/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/root…
5984 …--bootimg-dir /home/stephano/yocto/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/rec…
5985 --kernel-dir /home/stephano/yocto/build/tmp/deploy/images/qemux86 \
5986 …--native-sysroot /home/stephano/yocto/build/tmp/work/i586-poky-linux/wic-tools/1.0-r0/recipe-sysro…
5991 /home/stephano/testwic/test-201710091445-sdb.direct
5994 …: /home/stephano/yocto/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/…
5995 … /home/stephano/yocto/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r…
5996 KERNEL_DIR: /home/stephano/yocto/build/tmp-glibc/deploy/images/qemux86
5997 …T: /home/stephano/yocto/build/tmp-glibc/work/i586-oe-linux/wic-tools/1.0-r0/recipe-s…
6027 $ wic ls tmp/deploy/images/qemux86/core-image-minimal-qemux86.wic
6033 ``core-image-minimal-qemux86.wic`` image.
6056 $ wic ls tmp/deploy/images/qemux86/core-image-minimal-qemux86.wic:1
6058 Volume Serial Number is E894-1809
6061 libcom32 c32 186500 2017-10-09 16:06
6062 libutil c32 24148 2017-10-09 16:06
6063 syslinux cfg 220 2017-10-09 16:06
6064 vesamenu c32 27104 2017-10-09 16:06
6065 vmlinuz 6904608 2017-10-09 16:06
6078 ERROR: _exec_cmd: /usr/bin/mdir -i /tmp/wic-parttfokuwra ::/ returned '1' instead of 0
6086 $ wic rm tmp/deploy/images/qemux86/core-image-minimal-qemux86.wic:1/vmlinuz
6098 …$ wic cp poky_sdk/tmp/work/qemux86-poky-linux/linux-yocto/4.12.12+git999-r0/linux-yocto-4.12.12+gi…
6099 poky/build/tmp/deploy/images/qemux86/core-image-minimal-qemux86.wic:1/vmlinuz
6103 <dev-manual/common-tasks:flashing images using \`\`bmaptool\`\`>`
6123 - If you are using Ubuntu or Debian distributions, you can install
6124 the ``bmap-tools`` package using the following command and then
6128 $ sudo apt install bmap-tools
6130 - If you are unable to install the ``bmap-tools`` package, you will
6133 $ bitbake bmap-tools-native
6144 2. *Get Your Image:* Either have your image ready (pre-built with the
6154 - If you have write access to the media, use this command form::
6156 …$ oe-run-native bmap-tools-native bmaptool copy build-directory/tmp/deploy/images/machine/image.wi…
6158 - If you do not have write access to the media, set your permissions
6162 …$ oe-run-native bmap-tools-native bmaptool copy build-directory/tmp/deploy/images/machine/image.wi…
6166 $ bmaptool --help
6175 - *"*\ `Security Risks of Embedded
6179 - *"*\ `Internet Census
6183 - *"*\ `Security Issues for Embedded
6184 Devices <https://elinux.org/images/6/6f/Security-issues.pdf>`__\ *"*
6203 ----------------------
6209 - Scan additional code you are adding to the system (e.g. application
6213 - Pay particular attention to the security for any web-based
6220 cross-site-scripting (XSS), unvalidated inputs, and so forth.
6223 web-based interface should not be the same across all devices. This
6225 be assumed that many end-users will not change the credentials.
6227 - Ensure you can update the software on the device to mitigate
6229 especially applies when your device is network-enabled.
6231 - Ensure you remove or disable debugging functionality before producing
6233 ":ref:`dev-manual/common-tasks:considerations specific to the openembedded build system`"
6236 - Ensure you have no network services listening that are not needed.
6238 - Remove any software from the image that is not needed.
6240 - Enable hardware support for secure boot functionality when your
6244 --------------
6263 --------------------------------------------------------
6268 - Ensure "debug-tweaks" is not one of your selected
6275 EXTRA_IMAGE_FEATURES = "debug-tweaks"
6279 "debug-tweaks" before producing your final image. Among other things,
6284 - It is possible to set a root password for the image and also to set
6290 :ref:`extrausers <ref-classes-extrausers>`
6293 ":ref:`ref-classes-extrausers`" section.
6305 - Consider enabling a Mandatory Access Control (MAC) framework such as
6308 :yocto_git:`meta-selinux </meta-selinux/>` layer.
6311 ------------------------------
6314 can find these tools in the ``meta-security`` layer of the
6323 package alternative selections, compile-time options, and other
6324 low-level configurations, you can create your own distribution.
6331 - *Create a layer for your new distro:* Create your distribution layer
6338 ":ref:`dev-manual/common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`"
6341 - *Create the distribution configuration file:* The distribution
6361 - :term:`DISTRO_NAME`
6363 - :term:`DISTRO_VERSION`
6368 - :term:`DISTRO_FEATURES`
6370 - :term:`DISTRO_EXTRA_RDEPENDS`
6372 - :term:`DISTRO_EXTRA_RRECOMMENDS`
6374 - :term:`TCLIBC`
6379 very basic configuration from OE-Core, you can use
6386 - *Provide miscellaneous variables:* Be sure to define any other
6392 - *Point to Your distribution configuration file:* In your
6402 - *Add more to the layer if necessary:* Use your layer to hold other
6405 - Add recipes for installing distro-specific configuration files
6407 distro-specific configuration files that are included by an
6411 ":ref:`dev-manual/common-tasks:creating your own layer`" and
6412 ":ref:`dev-manual/common-tasks:following best practices when creating layers`"
6415 - Add any image recipes that are specific to your distribution.
6417 - Add a ``psplash`` append file for a branded splash screen. For
6419 ":ref:`dev-manual/common-tasks:appending other layers metadata with your layer`"
6422 - Add any other append files to make custom changes that are
6441 TEMPLATECONF=${TEMPLATECONF:-meta-poky/conf}
6447 ``conf-notes.txt`` files. The build system uses these files to form the
6454 variable is set in the ``.templateconf`` file, which is in the top-level
6461 have a layer named ``meta-mylayer`` located in your home directory and
6470 TEMPLATECONF=${TEMPLATECONF:-meta-mylayer/myconf}
6472 Aside from the ``*.sample`` configuration files, the ``conf-notes.txt``
6473 also resides in the default ``meta-poky/conf`` directory. The script
6475 :ref:`structure-core-script`) uses this file to
6477 ``conf-notes.txt`` file is a good way to make sure your list of custom
6486 core-image-minimal
6487 core-image-sato
6488 meta-toolchain
6489 meta-ide-support
6492 ``conf-notes.txt`` in your custom template configuration directory and
6499 -----------------------------------
6510 :ref:`rm_work <ref-classes-rm-work>` class in the
6514 -------------------------------------------
6521 sstate-cache-management.sh --remove-duplicated --cache-dir=build/sstate-cache
6531 Run ``sstate-cache-management.sh`` for more details about this script.
6538 - :ref:`dev-manual/common-tasks:excluding packages from an image`
6540 - :ref:`dev-manual/common-tasks:incrementing a package version`
6542 - :ref:`dev-manual/common-tasks:handling optional module packaging`
6544 - :ref:`dev-manual/common-tasks:using runtime package management`
6546 - :ref:`dev-manual/common-tasks:generating and using signed packages`
6548 - :ref:`Setting up and running package test
6549 (ptest) <dev-manual/common-tasks:testing packages with ptest>`
6551 - :ref:`dev-manual/common-tasks:creating node package manager (npm) packages`
6553 - :ref:`dev-manual/common-tasks:adding custom metadata to packages`
6556 --------------------------------
6565 with IPK and RPM package types, not for Debian packages.
6571 - :term:`BAD_RECOMMENDATIONS`:
6572 Use this variable to specify "recommended-only" packages that you do
6575 - :term:`NO_RECOMMENDATIONS`:
6576 Use this variable to prevent all "recommended-only" packages from
6579 - :term:`PACKAGE_EXCLUDE`:
6581 regardless of whether they are "recommended-only" or not. You need to
6587 ------------------------------
6596 - Binary Package: The binary package that is eventually built and
6599 - Binary Package Version: The binary package version is composed of two
6600 components - a version and a revision.
6611 - :term:`PV`: The recipe version. :term:`PV` represents the version of the
6615 - :term:`PR`: The recipe revision.
6617 - :term:`SRCPV`: The OpenEmbedded
6621 - :yocto_wiki:`PR Service </PR_Service>`: A
6622 network-based service that helps automate keeping package feeds
6623 compatible with existing package manager applications such as RPM,
6631 - Automatically using a Package Revision Service (PR Service).
6633 - Manually incrementing the :term:`PR` and/or :term:`PV` variables.
6637 applications such as RPM, APT, and OPKG, using an automated system is
6643 ":ref:`dev-manual/common-tasks:automatically incrementing a package version number`"
6673 ":ref:`signatures <overview-manual/concepts:checksums (signatures)>`", which are
6712 you need to start the PR Service using the ``bitbake-prserv`` command::
6714 bitbake-prserv --host ip --port port --start
6717 hand-starting the service, you need to update the ``local.conf`` file of
6732 ":ref:`dev-manual/common-tasks:maintaining build output quality`" section.
6744 ":ref:`overview-manual/concepts:shared state cache`"
6780 Guidelines <https://www.debian.org/doc/debian-policy/ch-controlfields.html>`__.
6805 .. code-block:: none
6812 - If PR Service is enabled, the build system increments the number,
6818 .. code-block:: none
6820 hello-world-git_0.0+git0+b6558dd387-r0.0_armv7a-neon.ipk
6821 hello-world-git_0.0+git1+dd2f5c3565-r0.0_armv7a-neon.ipk
6823 - If PR Service is not enabled, the build system replaces the
6829 .. code-block:: none
6831 hello-world-git_0.0+git0+b6558dd387-r0.0_armv7a-neon.ipk
6832 hello-world-git_0.0+git0+dd2f5c3565-r0.0_armv7a-neon.ipk
6842 ----------------------------------
6853 - Ensure the module packaging is actually done.
6855 - Ensure that any dependencies on optional modules from other recipes
6874 'lighttpd-module-%s', 'Lighttpd module for %s',
6881 - A directory within the files installed by your recipe through
6884 - A regular expression used to match module files in that directory. In
6888 - A pattern to use for the package names.
6890 - A description for each package.
6892 - An empty string for ``extra_depends``, which disables the default
6895 ``lighttpd-module-alias`` is created for it and the
6907 ``connman.inc`` file in the ``meta/recipes-connectivity/connman/``
6908 directory of the ``poky`` :ref:`source repository <overview-manual/development-environment:yocto pr…
6937 True to perform a recursive search - default
6958 (${PN}) - if you do not want this, pass empty
6968 True to allow directories to be matched -
6984 True to allow symlinks to be matched - default
7002 PACKAGES_DYNAMIC = "lighttpd-module-.*"
7006 example, it is ``lighttpd-module-`` and is specified as the prefix to
7015 --------------------------------
7019 number of packages (e.g. ``bash``, ``bash-bashbug``,
7020 ``bash-completion``, ``bash-completion-dbg``, ``bash-completion-dev``,
7021 ``bash-completion-extra``, ``bash-dbg``, and so forth). Not all
7028 - You want to provide in-the-field updates to deployed devices (e.g.
7031 - You want to have a fast turn-around development cycle for one or more
7034 - You want to temporarily install the "debug" packages of various
7038 - You want to deploy a more minimal package selection of your device
7039 but allow in-the-field updates to add a larger selection for
7043 traditional Linux distribution in that in-field devices are able to
7044 receive pre-compiled packages from a server for installation or update.
7045 Being able to install these packages on a running, in-field device is
7049 machine that serves up the pre-compiled packages plus the required
7054 server (e.g. Internet-facing). In fact, doing so is advantageous for a
7096 where packageformat can be "ipk", "rpm",
7109 you can include "package-management" in the
7111 variable. Including "package-management" in this configuration variable
7113 includes the currently-known package databases as well as the
7114 target-specific tools required for runtime package management to be
7117 required on-target package tool(s). As an example, you could include
7125 to re-generate the package index after the build by using the following
7128 $ bitbake package-index
7134 $ bitbake some-package package-index
7148 variables to pre-configure target images to use a package feed. If you
7157 ``tmp`` and your selected package type is RPM, then your RPM packages
7158 are available in ``tmp/deploy/rpm``.
7179 directory of ``poky/build/tmp/deploy/rpm`` and a :term:`PACKAGE_CLASSES`
7182 $ cd poky/build/tmp/deploy/rpm
7183 $ python3 -m http.server
7189 system. This section provides information for RPM, IPK, and DEB.
7191 Using RPM
7196 runtime package management of RPM packages. In order to use DNF for
7213 ``/etc/yum.repos.d/oe-packages.repo`` and defining the ``oe-packages``.
7233 - *Create an Explicit List of Architectures:* Define individual base
7236 .. code-block:: none
7238 [oe-packages]
7239 baseurl=http://my.server/rpm/i586 http://my.server/rpm/qemux86 http://my.server/rpm/all
7245 - *Create a Single (Full) Package Index:* Define a single base URL that
7248 [oe-packages]
7249 baseurl=http://my.server/rpm
7258 .. code-block:: none
7294 .. code-block:: none
7303 .. code-block:: none
7331 .. code-block:: none
7340 .. code-block:: none
7349 ------------------------------------
7351 In order to add security to RPM packages used during a build, you can
7356 This section describes how to sign RPM packages during a build and how
7359 Signing RPM Packages
7362 To enable signing RPM packages, you must set up the following
7381 - *GPG_BIN:* Specifies a ``gpg`` binary/wrapper that is executed
7384 - *GPG_PATH:* Specifies the ``gpg`` home directory used when the
7390 In addition to being able to sign RPM packages, you can also enable
7391 signed package feeds for IPK and RPM packages.
7394 to the steps used to sign RPM packages. You must define the following in
7410 - *GPG_BIN* Specifies a ``gpg`` binary/wrapper that is executed
7413 - *GPG_PATH:* Specifies the ``gpg`` home directory used when the
7416 - *PACKAGE_FEED_GPG_SIGNATURE_TYPE:* Specifies the type of ``gpg``
7417 signature. This variable applies only to RPM and IPK package feeds.
7423 ---------------------------
7427 least two items: the actual test, and a shell script (``run-ptest``)
7429 contain the actual test - the script only starts the test. On the other
7446 A recipe is "ptest-enabled" if it inherits the
7447 :ref:`ptest <ref-classes-ptest>` class.
7459 EXTRA_IMAGE_FEATURES += "ptest-pkgs"
7468 The ``ptest-runner`` package installs a shell script that loops through
7479 - *Be sure the recipe inherits
7480 the* :ref:`ptest <ref-classes-ptest>` *class:*
7485 - *Create run-ptest:* This script starts your test. Locate the
7492 make -k runtest-TESTS
7494 - *Ensure dependencies are met:* If the test adds build or runtime
7502 RDEPENDS:${PN}-ptest += "make"
7504 - *Add a function to build the test suite:* Not many packages support
7505 cross-compilation of their test suites. Consequently, you usually
7506 need to add a cross-compilation function to the package.
7511 cross-compiling requires that the package is built on the host but
7517 cross-compiles.
7524 oe_runmake buildtest-TESTS
7527 - *Ensure special configurations are set:* If the package requires
7531 - *Install the test suite:* The ``ptest`` class automatically copies
7532 the file ``run-ptest`` to the target and then runs make
7533 ``install-ptest`` to run the tests. If this is not enough, you need
7535 called after the "make install-ptest" completes.
7538 --------------------------------------------
7542 supports the NPM :ref:`fetcher <bitbake:bitbake-user-manual/bitbake-user-manual-fetching:fetchers>`…
7544 :doc:`devtool </ref-manual/devtool-reference>` to create
7564 - Of the two methods that you can use ``devtool`` to create NPM
7568 (`npm-registry <https://docs.npmjs.com/misc/registry>`_), which
7571 - Be familiar with
7572 :doc:`devtool </ref-manual/devtool-reference>`.
7574 - The NPM host tools need the native ``nodejs-npm`` package, which is
7576 cloning the https://github.com/openembedded/meta-openembedded
7580 - ``devtool`` cannot detect native libraries in module dependencies.
7583 - While deploying NPM packages, ``devtool`` cannot determine which
7588 - Although you might not need NPM to run your node package, it is
7590 ``nodejs-npm``.
7595 This section presents an example that uses the ``cute-files`` module,
7600 You must know the ``cute-files`` module version.
7605 $ devtool add "npm://registry.npmjs.org;package=cute-files;version=1.0.2"
7627 A package is created for each sub-module. This policy is the only
7631 The ``devtool edit-recipe`` command lets you take a look at the recipe::
7633 $ devtool edit-recipe cute-files
7641 npm://registry.npmjs.org/;package=cute-files;version=${PV} \
7642 npmsw://${THISDIR}/${BPN}/npm-shrinkwrap.json \
7647 LICENSE:${PN}-accepts = "MIT"
7648 LICENSE:${PN}-array-flatten = "MIT"
7650 LICENSE:${PN}-vary = "MIT"
7654 - :term:`SRC_URI` uses the NPM
7657 - ``recipetool`` collects all the license information. If a
7658 sub-module's license is unavailable, the sub-module's name appears in
7661 - The ``inherit npm`` statement causes the
7662 :ref:`npm <ref-classes-npm>` class to package
7665 You can run the following command to build the ``cute-files`` package::
7667 $ devtool build cute-files
7675 $ devtool deploy-target -s cute-files root@192.168.7.2
7682 Because of a known issue, you cannot simply run ``cute-files`` as you would
7687 $ cd /usr/lib/node_modules/cute-files
7688 $ node cute-files.js
7693 .. image:: figures/cute-files-npm-example.png
7696 You can find the recipe in ``workspace/recipes/cute-files``. You can use
7711 Replicating the same example, (i.e. ``cute-files``) use the following
7714 $ devtool add https://github.com/martinaglv/cute-files.git
7721 git://github.com/martinaglv/cute-files.git;protocol=https \
7722 npmsw://${THISDIR}/${BPN}/npm-shrinkwrap.json \
7733 ----------------------------------
7746 - ``PACKAGE_ADD_METADATA_<PKGTYPE>:<PN>``
7748 - ``PACKAGE_ADD_METADATA_<PKGTYPE>``
7750 - ``PACKAGE_ADD_METADATA:<PN>``
7752 - :term:`PACKAGE_ADD_METADATA`
7757 - IPK for .ipk packages
7759 - DEB for .deb packages
7761 - RPM for .rpm packages
7765 The variable can contain multiple [one-line] metadata fields separated
7785 source files and how you can pre-fetch files all of which leads to more
7789 ----------------------------
7802 SOURCE_MIRROR_URL ?= "file:///home/you/your-download-dir/"
7803 INHERIT += "own-mirrors"
7821 ----------------------------------------------
7824 of build operations, is to pre-fetch all the source files without
7827 download directory :ref:`structure-build-downloads`,
7833 $ bitbake target --runall=fetch
7866 In a SysVinit-based system, services load sequentially (i.e. one by one)
7876 -------------------------
7881 VIRTUAL-RUNTIME_init_manager = "systemd"
7894 VIRTUAL-RUNTIME_initscripts = ""
7900 ------------------------------------------------------------------------
7905 VIRTUAL-RUNTIME_init_manager = "systemd"
7908 ``packagegroup-core-boot.bb`` recipe and systemd. The rescue/minimal
7913 Using systemd-journald without a traditional syslog daemon
7914 ----------------------------------------------------------
7916 Counter-intuitively, ``systemd-journald`` is not a syslog runtime or provider,
7917 and the proper way to use systemd-journald as your sole logging mechanism is to
7921 VIRTUAL-RUNTIME_syslog = ""
7922 VIRTUAL-RUNTIME_base-utils-syslog = ""
7924 Doing so will prevent ``rsyslog`` / ``busybox-syslog`` from being pulled in by
7933 - Persistent and Pre-Populated ``/dev``: For this case, the ``/dev``
7937 - Use ``devtmpfs`` with a Device Manager: For this case, the ``/dev``
7938 directory is provided by the kernel as an in-memory file system and
7941 manager like ``udev`` or ``busybox-mdev``.
7943 Using Persistent and Pre-Populated ``/dev``
7944 --------------------------------------------
7960 ``device_table-minimal.txt`` is used::
7962 IMAGE_DEVICE_TABLES = "device_table-mymachine.txt"
7968 ---------------------------------------
7986 like ``udev`` or ``busybox-mdev``. You choose the device manager by
7987 defining the ``VIRTUAL-RUNTIME_dev_manager`` variable in your machine or
7991 VIRTUAL-RUNTIME_dev_manager = "udev"
7994 # VIRTUAL-RUNTIME_dev_manager = "busybox-mdev"
7995 # VIRTUAL-RUNTIME_dev_manager = "systemd"
8017 SRCREV:pn-PN = "${AUTOREV}"
8027 The Yocto Project provides a distribution named ``poky-bleeding``, whose
8030 require conf/distro/include/poky-floating-revisions.inc
8035 #SRCREV:pn-opkg-native ?= "${AUTOREV}"
8036 #SRCREV:pn-opkg-sdk ?= "${AUTOREV}"
8037 #SRCREV:pn-opkg ?= "${AUTOREV}"
8038 #SRCREV:pn-opkg-utils-native ?= "${AUTOREV}"
8039 #SRCREV:pn-opkg-utils ?= "${AUTOREV}"
8040 SRCREV:pn-gconf-dbus ?= "${AUTOREV}"
8041 SRCREV:pn-matchbox-common ?= "${AUTOREV}"
8042 SRCREV:pn-matchbox-config-gtk ?= "${AUTOREV}"
8043 SRCREV:pn-matchbox-desktop ?= "${AUTOREV}"
8044 SRCREV:pn-matchbox-keyboard ?= "${AUTOREV}"
8045 SRCREV:pn-matchbox-panel-2 ?= "${AUTOREV}"
8046 SRCREV:pn-matchbox-themes-extra ?= "${AUTOREV}"
8047 SRCREV:pn-matchbox-terminal ?= "${AUTOREV}"
8048 SRCREV:pn-matchbox-wm ?= "${AUTOREV}"
8049 SRCREV:pn-settings-daemon ?= "${AUTOREV}"
8050 SRCREV:pn-screenshot ?= "${AUTOREV}"
8059 The ``poky-bleeding`` distribution is not tested on a regular basis. Keep
8062 Creating a Read-Only Root Filesystem
8066 root filesystem's write permissions (i.e. you need a read-only root
8068 from a read-only storage device. For either case, you can customize your
8073 Supporting a read-only root filesystem requires that the system and
8080 ----------------------------
8082 To create the read-only root filesystem, simply add the
8083 "read-only-rootfs" feature to your image, normally in one of two ways.
8084 The first way is to add the "read-only-rootfs" image feature in the
8087 IMAGE_FEATURES += "read-only-rootfs"
8093 EXTRA_IMAGE_FEATURES = "read-only-rootfs"
8096 ":ref:`dev-manual/common-tasks:Customizing Images Using Custom \`\`IMAGE_FEATURES\`\` and \`\`EXTRA…
8101 Post-Installation Scripts and Read-Only Root Filesystem
8102 -------------------------------------------------------
8104 It is very important that you make sure all post-Installation
8108 the first boot on the target device. With the "read-only-rootfs" feature
8109 enabled, the build system makes sure that all post-installation scripts
8112 immediately fails. These build-time checks ensure that the build fails
8116 Most of the common post-installation scripts generated by the build
8117 system for the out-of-the-box Yocto Project are engineered so that they
8118 can run during root filesystem creation (e.g. post-installation scripts
8122 Here are some common problems that prevent post-installation scripts
8125 - *Not using $D in front of absolute paths:* The build system defines
8133 - *Attempting to run processes that are specific to or dependent on the
8138 :ref:`qemu <ref-classes-qemu>` class.
8141 -----------------------
8143 With the "read-only-rootfs" feature enabled, any attempt by the target
8158 dependency on another library, which is auto-detected. If that library
8163 The :ref:`buildhistory <ref-classes-buildhistory>`
8173 - :ref:`How you can enable and disable build history <dev-manual/common-tasks:enabling and disabli…
8175 - :ref:`How to understand what the build history contains <dev-manual/common-tasks:understanding w…
8177 - :ref:`How to limit the information used for build history <dev-manual/common-tasks:using build h…
8179 - :ref:`How to examine the build history from both a command-line and web interface <dev-manual/co…
8182 ------------------------------------
8196 :ref:`overview-manual/development-environment:git` repository.
8208 ---------------------------------------------
8219 At the top level, there is a ``metadata-revs`` file that lists the
8228 The history for each package contains a text file that has name-value
8230 ``buildhistory/packages/i586-poky-linux/busybox/busybox/latest``
8233 .. code-block:: none
8238 RDEPENDS = glibc (>= 2.20) update-alternatives-opkg
8239 RRECOMMENDS = busybox-syslog busybox-udhcpc update-rc.d
8250 name-value pairs correspond to variables used to produce the package.
8256 came (e.g. ``buildhistory/packages/i586-poky-linux/busybox/latest``):
8258 .. code-block:: none
8262 DEPENDS = initscripts kern-tools-native update-rc.d-native \
8263 virtual/i586-poky-linux-compilerlibs virtual/i586-poky-linux-gcc \
8264 virtual/libc virtual/update-alternatives
8265 PACKAGES = busybox-ptest busybox-httpd busybox-udhcpd busybox-udhcpc \
8266 busybox-syslog busybox-mdev busybox-hwclock busybox-dbg \
8267 busybox-staticdev busybox-dev busybox-doc busybox-locale busybox
8276 ``buildhistory/packages/qemux86-poky-linux/linux-yocto/latest_srcrev``)::
8284 ``buildhistory-collect-srcrevs`` command with the ``-a`` option to
8291 $ buildhistory-collect-srcrevs -a
8292 # all-poky-linux
8293 SRCREV:pn-ca-certificates = "07de54fdcc5806bde549e1edf60738c6bccf50e8"
8294 SRCREV:pn-update-rc.d = "8636cf478d426b568c1be11dbd9346f67e03adac"
8295 # core2-64-poky-linux
8296 SRCREV:pn-binutils = "87d4632d36323091e731eb07b8aa65f90293da66"
8297 SRCREV:pn-btrfs-tools = "8ad326b2f28c044cb6ed9016d7c3285e23b673c8"
8298 SRCREV_bzip2-tests:pn-bzip2 = "f9061c030a25de5b6829e1abf373057309c734c0"
8299 SRCREV:pn-e2fsprogs = "02540dedd3ddc52c6ae8aaa8a95ce75c3f8be1c0"
8300 SRCREV:pn-file = "504206e53a89fd6eed71aeaf878aa3512418eab1"
8301 SRCREV_glibc:pn-glibc = "24962427071fa532c3c48c918e9d64d719cc8a6c"
8302 SRCREV:pn-gnome-desktop-testing = "e346cd4ed2e2102c9b195b614f3c642d23f5f6e7"
8303 SRCREV:pn-init-system-helpers = "dbd9197569c0935029acd5c9b02b84c68fd937ee"
8304 SRCREV:pn-kmod = "b6ecfc916a17eab8f93be5b09f4e4f845aabd3d1"
8305 SRCREV:pn-libnsl2 = "82245c0c58add79a8e34ab0917358217a70e5100"
8306 SRCREV:pn-libseccomp = "57357d2741a3b3d3e8425889a6b79a130e0fa2f3"
8307 SRCREV:pn-libxcrypt = "50cf2b6dd4fdf04309445f2eec8de7051d953abf"
8308 SRCREV:pn-ncurses = "51d0fd9cc3edb975f04224f29f777f8f448e8ced"
8309 SRCREV:pn-procps = "19a508ea121c0c4ac6d0224575a036de745eaaf8"
8310 SRCREV:pn-psmisc = "5fab6b7ab385080f1db725d6803136ec1841a15f"
8311 SRCREV:pn-ptest-runner = "bcb82804daa8f725b6add259dcef2067e61a75aa"
8312 SRCREV:pn-shared-mime-info = "18e558fa1c8b90b86757ade09a4ba4d6a6cf8f70"
8313 SRCREV:pn-zstd = "e47e674cd09583ff0503f0f6defd6d23d8b718d3"
8314 # qemux86_64-poky-linux
8315 SRCREV_machine:pn-linux-yocto = "20301aeb1a64164b72bc72af58802b315e025c9c"
8316 SRCREV_meta:pn-linux-yocto = "2d38a472b21ae343707c8bd64ac68a9eaca066a0"
8317 # x86_64-linux
8318 SRCREV:pn-binutils-cross-x86_64 = "87d4632d36323091e731eb07b8aa65f90293da66"
8319 SRCREV_glibc:pn-cross-localedef-native = "24962427071fa532c3c48c918e9d64d719cc8a6c"
8320 SRCREV_localedef:pn-cross-localedef-native = "794da69788cbf9bf57b59a852f9f11307663fa87"
8321 SRCREV:pn-debianutils-native = "de14223e5bffe15e374a441302c528ffc1cbed57"
8322 SRCREV:pn-libmodulemd-native = "ee80309bc766d781a144e6879419b29f444d94eb"
8323 SRCREV:pn-virglrenderer-native = "363915595e05fb252e70d6514be2f0c0b5ca312b"
8324 SRCREV:pn-zstd-native = "e47e674cd09583ff0503f0f6defd6d23d8b718d3"
8328 Here are some notes on using the ``buildhistory-collect-srcrevs`` command:
8330 - By default, only values where the :term:`SRCREV` was not hardcoded
8331 (usually when :term:`AUTOREV` is used) are reported. Use the ``-a``
8334 - The output statements might not have any effect if overrides are
8336 ``-f`` option to add the ``forcevariable`` override to each output
8339 - The script does apply special handling when building for multiple
8342 previously shown (e.g., ``i586-poky-linux``).
8349 - ``image-files:`` A directory containing selected files from the root
8353 - ``build-id.txt:`` Human-readable information about the build
8357 - ``*.dot:`` Dependency graphs for the image that are compatible with
8360 - ``files-in-image.txt:`` A list of files in the image with
8363 - ``image-info.txt:`` A text file containing name-value pairs with
8367 - ``installed-package-names.txt:`` A list of installed packages by name
8370 - ``installed-package-sizes.txt:`` A list of installed packages ordered
8373 - ``installed-packages.txt:`` A list of installed packages with full
8381 Here is an example of ``image-info.txt``:
8383 .. code-block:: none
8386 DISTRO_VERSION = 3.4+snapshot-a0245d7be08f3d24ea1875e9f8872aa6bbff93be
8389 IMAGE_FEATURES = debug-tweaks
8391 IMAGE_INSTALL = packagegroup-core-boot speex speexdsp
8401 name-value pairs are variables that may have influenced the content of
8428 ``bitbake -c populate_sdk imagename``) as compared to information it
8434 - ``files-in-sdk.txt:`` A list of files in the SDK with permissions,
8438 - ``sdk-info.txt:`` A text file containing name-value pairs with
8442 - ``sstate-task-sizes.txt:`` A text file containing name-value pairs
8444 tasks have a total size). The ``sstate-task-sizes.txt`` file exists
8447 - ``sstate-package-sizes.txt:`` A text file containing name-value pairs
8448 with information for the shared-state packages and sizes in the SDK.
8449 The ``sstate-package-sizes.txt`` file exists only when an extensible
8452 - ``sdk-files:`` A folder that contains copies of the files mentioned
8459 ``conf/auto.conf``, ``conf/locked-sigs.inc``, and
8461 copied into the ``sdk-files`` directory.
8463 - The following information appears under each of the ``host`` and
8473 - ``depends.dot:`` Dependency graph for the SDK that is compatible
8476 - ``installed-package-names.txt:`` A list of installed packages by
8479 - ``installed-package-sizes.txt:`` A list of installed packages
8482 - ``installed-packages.txt:`` A list of installed packages with full
8485 Here is an example of ``sdk-info.txt``:
8487 .. code-block:: none
8490 DISTRO_VERSION = 1.3+snapshot-20130327
8491 SDK_NAME = poky-glibc-i686-arm
8494 SDKIMAGE_FEATURES = dev-pkgs dbg-pkgs
8499 the total size of the files in the SDK in Kbytes, the name-value pairs
8515 $ git log -p
8521 There is a command-line tool called ``buildhistory-diff``, though,
8523 might be significant in human-readable form. Here is an example::
8525 $ poky/poky/scripts/buildhistory-diff . HEAD^
8526 Changes to images/qemux86_64/glibc/core-image-minimal (files-in-image.txt):
8529 * (installed-package-names.txt):
8531 Changes to images/qemux86_64/glibc/core-image-minimal (installed-package-names.txt):
8533 packages/qemux86_64-poky-linux/v86d: PACKAGES: added "v86d-extras"
8536 packages/qemux86_64-poky-linux/v86d/v86d: PKGSIZE changed from 110579 to 144381 (+30%)
8542 The ``buildhistory-diff`` tool requires the ``GitPython``
8545 $ pip3 install GitPython --user
8548 Alternatively, you can install ``python3-git`` using the appropriate
8553 :yocto_git:`here </buildhistory-web/>`.
8557 .. image:: figures/buildhistory-web.png
8572 Yocto Project, see the ":ref:`ref-manual/release-process:testing and quality assurance`"
8576 --------------
8588 - *Set up to avoid interaction with sudo for networking:* To
8591 - Add ``NOPASSWD`` for your user in ``/etc/sudoers`` either for all
8592 commands or just for ``runqemu-ifup``. You must provide the full
8601 - Manually configure a tap interface for your system.
8603 - Run as root the script in ``scripts/runqemu-gen-tapdevs``, which
8605 typically chosen for Autobuilder-type environments.
8609 - Be sure to use an absolute path when calling this script
8612 - The package recipe ``qemu-helper-native`` is required to run
8615 $ bitbake qemu-helper-native
8617 - *Set the DISPLAY variable:* You need to set this variable so that
8621 - *Be sure your host's firewall accepts incoming connections from
8625 ``${WORKDIR}/oe-rootfs-repo`` so it can run DNF channel commands.
8630 - *Be sure your host has the correct packages installed:* Depending
8634 - Ubuntu and Debian: ``sysstat`` and ``iproute2``
8636 - openSUSE: ``sysstat`` and ``iproute2``
8638 - Fedora: ``sysstat`` and ``iproute``
8640 - CentOS: ``sysstat`` and ``iproute``
8687 network on a pre-determined IP address. You can either use static IP
8697 - *"simpleremote":* Choose "simpleremote" if you are going to run tests
8703 - *"SystemdbootTarget":* Choose "SystemdbootTarget" if your hardware is
8704 an EFI-based machine with ``systemd-boot`` as bootloader and
8705 ``core-image-testmaster`` (or something similar) is installed. Also,
8706 your hardware under test must be in a DHCP-enabled network that gives
8711 ":ref:`dev-manual/common-tasks:selecting systemdboottarget`" section, which
8714 - *"BeagleBoneTarget":* Choose "BeagleBoneTarget" if you are deploying
8718 ``meta-yocto-bsp/lib/oeqa/controllers/beaglebonetarget.py`` file.
8720 - *"EdgeRouterTarget":* Choose "EdgeRouterTarget" if you are deploying
8724 ``meta-yocto-bsp/lib/oeqa/controllers/edgeroutertarget.py`` file.
8726 - *"GrubTarget":* Choose "GrubTarget" if you are deploying images and running
8729 ``meta-yocto-bsp/lib/oeqa/controllers/grubtarget.py`` file.
8731 - *"your-target":* Create your own custom target if you want to run
8736 For examples, see files in ``meta-yocto-bsp/lib/oeqa/controllers/``.
8743 ":ref:`dev-manual/common-tasks:running tests`" section.
8746 perform a one-time setup of your controller image by doing the following:
8750 EFI_PROVIDER = "systemd-boot"
8752 2. *Build the controller image:* Build the ``core-image-testmaster`` image.
8753 The ``core-image-testmaster`` recipe is provided as an example for a
8759 - Inherits ``core-image`` so that kernel modules are installed.
8761 - Installs normal linux utilities not BusyBox ones (e.g. ``bash``,
8764 - Uses a custom Initial RAM Disk (initramfs) image with a custom
8771 - First partition mounted under ``/boot``, labeled "boot".
8773 - The main root filesystem partition where this image gets installed,
8776 - Another partition labeled "testrootfs" where test images get
8795 $ bitbake core-image-sato
8803 - You can use :term:`TEST_POWERCONTROL_CMD` together with
8814 .. code-block:: shell
8827 - When no command is defined, it connects to the device over SSH and
8836 ``dialog-power-control`` script that shows a dialog prompting you to perform
8842 TEST_POWERCONTROL_CMD = "${COREBASE}/scripts/contrib/dialog-power-control"
8864 TEST_SERIALCONTROL_CMD = "picocom /dev/ttyUSB0 -b 115200"
8872 TEST_SERIALCONTROL_CMD = "${COREBASE}/scripts/contrib/serdevtry picocom -b 115200 /dev/ttyUSB0"
8875 -------------
8879 - *Automatically running tests:* To run the tests automatically after
8891 bitbake core-image-sato
8893 - *Manually running tests:* To manually run the tests, first globally
8895 :ref:`testimage <ref-classes-testimage*>` class
8902 bitbake -c testimage image
8925 RPM tests on an image without ``rpm``). Appending "auto" to
8933 "ping" in the list. The test class provides no re-ordering or dependency
8943 - The default tests for the image are defined as::
8945 DEFAULT_TEST_SUITES:pn-image = "ping ssh df connman syslog xorg scp vnc date rpm dnf dmesg"
8947 - Add your own test to the list of the by using the following::
8951 - Run a specific list of tests as follows::
8959 ---------------
8970 TEST_TARGET_IP = "IP-address-for-the-test-target"
8971 TEST_SERVER_IP = "IP-address-for-the-test-server"
8976 $ bitbake image -c testexport
8989 ``core-image-sato`` image::
8997 $ bitbake core-image-sato -c testexport
9002 $ cd tmp/testexport/core-image-sato
9006 -----------------
9015 - Filenames need to map directly to test (module) names.
9017 - Do not use module names that collide with existing core tests.
9019 - Minimally, an empty ``__init__.py`` file must be present in the runtime
9041 - *hasPackage(pkg):* Returns "True" if ``pkg`` is in the installed
9045 - *hasFeature(feature):* Returns "True" if the feature is in
9054 - *pscmd:* Equals "ps -ef" if ``procps`` is installed in the image.
9057 - *tc:* The called test context, which gives access to the
9060 - *d:* The BitBake datastore, which allows you to use stuff such
9061 as ``oeRuntimeTest.tc.d.getVar("VIRTUAL-RUNTIME_init_manager")``.
9063 - *testslist and testsrequired:* Used internally. The tests
9066 - *filesdir:* The absolute path to
9071 - *target:* The target controller object used to deploy and
9075 - *ip:* The target's IP address.
9077 - *server_ip:* The host's IP address, which is usually used
9080 - *run(cmd, timeout=None):* The single, most used method.
9083 names imply - the return code of "cmd" and whatever output it
9090 - *copy_to(localpath, remotepath):*
9093 - *copy_from(remotepath, localpath):*
9107 ----------------------------------------------------------
9129 - "pkg" - A mandatory string that is the name of the package to be
9132 - "rm" - An optional boolean, which defaults to "false", that specifies
9135 - "extract" - An optional boolean, which defaults to "false", that
9167 working version with examination of the changes and the re-application
9183 ":ref:`dev-manual/common-tasks:using the error reporting tool`"
9189 - ":ref:`dev-manual/common-tasks:viewing logs from failed tasks`" describes
9193 - ":ref:`dev-manual/common-tasks:viewing variable values`" describes how to
9194 use the BitBake ``-e`` option to examine variable values after a
9197 - ":ref:`dev-manual/common-tasks:viewing package information with \`\`oe-pkgdata-util\`\``"
9198 describes how to use the ``oe-pkgdata-util`` utility to query
9200 display package-related information for built packages.
9202 - ":ref:`dev-manual/common-tasks:viewing dependencies between recipes and tasks`"
9203 describes how to use the BitBake ``-g`` option to display recipe
9206 - ":ref:`dev-manual/common-tasks:viewing task variable dependencies`" describes
9207 how to use the ``bitbake-dumpsig`` command in conjunction with key
9212 - ":ref:`dev-manual/common-tasks:running specific tasks`" describes
9213 how to use several BitBake options (e.g. ``-c``, ``-C``, and ``-f``)
9215 tasks "out-of-order" when trying isolate build issues.
9217 - ":ref:`dev-manual/common-tasks:general bitbake problems`" describes how
9218 to use BitBake's ``-D`` debug output option to reveal more about what
9221 - ":ref:`dev-manual/common-tasks:building with no dependencies`"
9222 describes how to use the BitBake ``-b`` option to build a recipe
9225 - ":ref:`dev-manual/common-tasks:recipe logging mechanisms`"
9229 - ":ref:`dev-manual/common-tasks:debugging parallel make races`"
9235 - ":ref:`dev-manual/common-tasks:debugging with the gnu project debugger (gdb) remotely`"
9239 - ":ref:`dev-manual/common-tasks:debugging with the gnu project debugger (gdb) on the target`"
9242 - ":ref:`dev-manual/common-tasks:other debugging tips`" describes
9246 ------------------------------
9251 :ref:`ref-tasks-compile` task of the
9253 ``tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/temp/log.do_compile``.
9265 -----------------------
9270 <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:modifying existing
9273 BitBake's ``-e`` option is used to display variable values after
9278 $ bitbake -e
9283 $ bitbake -e recipename
9297 In the output of ``bitbake -e``, each variable is preceded by a
9304 ``export`` in the output of ``bitbake -e``. See the following example::
9306 …export CC="i586-poky-linux-gcc -m32 -march=i586 --sysroot=/home/ulf/poky/build/tmp/sysroots/qemux8…
9308 In addition to variable values, the output of the ``bitbake -e`` and
9309 ``bitbake -e`` recipe commands includes the following information:
9311 - The output starts with a tree listing all configuration files and
9314 system (including the behavior of the :ref:`ref-manual/tasks:normal recipe build tasks`) is
9316 :ref:`base <ref-classes-base>` class and the
9319 - After the variable values, all functions appear in the output. For
9322 override-style operators like ``:append`` and ``:prepend``, then the
9325 Viewing Package Information with ``oe-pkgdata-util``
9326 ----------------------------------------------------
9328 You can use the ``oe-pkgdata-util`` command-line utility to query
9330 various package-related information. When you use the utility, you must
9333 Following are a few of the available ``oe-pkgdata-util`` subcommands.
9340 - ``oe-pkgdata-util list-pkgs [pattern]``: Lists all packages
9344 - ``oe-pkgdata-util list-pkg-files package ...``: Lists the
9351 ``${``\ :term:`WORKDIR`\ ``}/packages-split``
9354 :ref:`ref-tasks-package` task
9358 If you want to inspect the ``${WORKDIR}/packages-split``
9360 :ref:`rm_work <ref-classes-rm-work>` is not
9363 - ``oe-pkgdata-util find-path path ...``: Lists the names of
9366 ``make-doc`` package::
9368 $ oe-pkgdata-util find-path /usr/share/man/man1/make.1
9369 make-doc: /usr/share/man/man1/make.1
9371 - ``oe-pkgdata-util lookup-recipe package ...``: Lists the name
9374 For more information on the ``oe-pkgdata-util`` command, use the help
9377 $ oe-pkgdata-util --help
9378 $ oe-pkgdata-util subcommand --help
9381 ----------------------------------------------
9390 $ bitbake -g recipename
9394 - ``pn-buildlist``: A list of recipes/targets involved in building
9401 - ``task-depends.dot``: A graph showing dependencies between tasks.
9410 - DOT files use a plain text format. The graphs generated using the
9411 ``bitbake -g`` command are often so large as to be difficult to
9412 read without special pruning (e.g. with Bitbake's ``-I`` option)
9417 As an example, the ``task-depends.dot`` file contains lines such
9420 "libxslt.do_configure" -> "libxml2.do_populate_sysroot"
9423 :ref:`ref-tasks-configure`
9425 :ref:`ref-tasks-populate_sysroot`
9430 - For an example of how ``.dot`` files can be processed, see the
9431 ``scripts/contrib/graph-tool`` Python script, which finds and
9437 $ bitbake -g -u taskexp recipename
9440 displays a GUI window from which you can view build-time and runtime
9444 ----------------------------------
9447 ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-execution:checksums (signatures)`" section o…
9454 ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:variable flags`" section of the Bit…
9470 :ref:`ref-tasks-fetch` task of the
9474 …${BUILDDIR}/tmp/stamps/i586-poky-linux/db/6.0.30-r1.do_fetch.sigdata.7c048c18222b16ff0bcee2000ef64…
9477 (:ref:`sstate <overview-manual/concepts:shared state cache>`) cache, an
9483 3. Run ``bitbake-dumpsig`` on the ``sigdata`` or ``siginfo`` file. Here
9486 …$ bitbake-dumpsig ${BUILDDIR}/tmp/stamps/i586-poky-linux/db/6.0.30-r1.do_fetch.sigdata.7c048c18222…
9501 The output of ``bitbake-dumpsig`` also includes the value each
9506 There is also a ``bitbake-diffsigs`` command for comparing two
9509 call ``bitbake-diffsigs`` with just one file, the command behaves like
9510 ``bitbake-dumpsig``.
9514 BitBake command-line options::
9516 ‐‐dump-signatures=SIGNATURE_HANDLER
9517 -S SIGNATURE_HANDLER
9531 --------------------------------------------------------------------------
9539 ":ref:`dev-manual/common-tasks:viewing task variable dependencies`" section.
9542 ":ref:`overview-manual/concepts:shared state`"
9546 ------------------------------------------------
9549 :ref:`checksums <overview-manual/concepts:checksums (signatures)>` and
9550 :ref:`overview-manual/concepts:shared state` cache to avoid unnecessarily
9580 :ref:`ref-tasks-package` or the
9592 ----------------------
9601 use the ``-c`` option in BitBake. Here is an example::
9603 $ bitbake matchbox-desktop -c devshell
9605 The ``-c`` option respects task dependencies, which means that all other
9608 task to run with ``-c``, BitBake will only run the task if it considers
9610 ":ref:`overview-manual/concepts:stamp files and the rerunning of tasks`"
9614 If you want to force an up-to-date task to be rerun (e.g. because you
9617 out), then you can use the ``-f`` option.
9621 The reason ``-f`` is never required when running the
9622 :ref:`ref-tasks-devshell` task is because the
9623 [\ :ref:`nostamp <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:variable flags>`\ ]
9626 The following example shows one way you can use the ``-f`` option::
9628 $ bitbake matchbox-desktop
9634 $ bitbake matchbox-desktop -c compile -f
9635 $ bitbake matchbox-desktop
9637 This sequence first builds and then recompiles ``matchbox-desktop``. The
9643 :ref:`ref-manual/tasks:normal recipe build tasks`
9644 that depend on it is to use the ``-C`` option.
9648 This option is upper-cased and is separate from the ``-c``
9649 option, which is lower-cased.
9652 :ref:`ref-tasks-build` task, which is
9657 $ bitbake matchbox-desktop -C compile
9659 Internally, the ``-f`` and ``-C`` options work by tainting (modifying)
9670 .. code-block:: none
9672 …WARNING: /home/ulf/poky/meta/recipes-sato/matchbox-desktop/matchbox-desktop_2.1.bb.do_compile is t…
9681 $ bitbake matchbox-desktop -c clean
9682 $ bitbake matchbox-desktop
9688 $ bitbake matchbox-desktop -c listtasks
9694 ------------------------
9696 You can see debug output from BitBake by using the ``-D`` option. The
9698 reason behind it. Each ``-D`` option you use increases the logging
9699 level. The most common usage is ``-DDD``.
9701 The output from ``bitbake -DDD -v targetname`` can reveal why BitBake
9707 -----------------------------
9712 $ bitbake -b somepath/somerecipe.bb
9724 -------------------------
9732 - ``bb.plain(msg)``: Writes msg as is to the log while also
9735 - ``bb.note(msg)``: Writes "NOTE: msg" to the log. Also logs to
9736 stdout if BitBake is called with "-v".
9738 - ``bb.debug(level, msg)``: Writes "DEBUG: msg" to the
9740 …level. See the ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-intro:usage and syntax`" opt…
9743 - ``bb.warn(msg)``: Writes "WARNING: msg" to the log while also
9746 - ``bb.error(msg)``: Writes "ERROR: msg" to the log while also
9753 - ``bb.fatal(msg)``: This logging function is similar to
9754 ``bb.error(msg)`` but also causes the calling task to fail.
9764 :ref:`logging <ref-classes-logging>` class
9778 ":ref:`ref-tasks-listtasks`"
9800 logs, you have the same goals - informative with minimal console output.
9828 -----------------------------
9836 presents a real-world example of an error encountered on the Yocto
9860 .. code-block:: none
9862 …| DEBUG: SITE files ['endian-little', 'bit-32', 'ix86-common', 'common-linux', 'common-glibc', 'i5…
9864 | NOTE: make -j 16
9865 | make --no-print-directory all-am
9866 | /bin/mkdir -p include/near
9867 | /bin/mkdir -p include/near
9868 | /bin/mkdir -p include/near
9869 | ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
9870 0.14-r0/neard-0.14/include/types.h include/near/types.h
9871 | ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
9872 0.14-r0/neard-0.14/include/log.h include/near/log.h
9873 | ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
9874 0.14-r0/neard-0.14/include/plugin.h include/near/plugin.h
9875 | /bin/mkdir -p include/near
9876 | /bin/mkdir -p include/near
9877 | /bin/mkdir -p include/near
9878 | ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
9879 0.14-r0/neard-0.14/include/tag.h include/near/tag.h
9880 | /bin/mkdir -p include/near
9881 | ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
9882 0.14-r0/neard-0.14/include/adapter.h include/near/adapter.h
9883 | /bin/mkdir -p include/near
9884 | ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
9885 0.14-r0/neard-0.14/include/ndef.h include/near/ndef.h
9886 | ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
9887 0.14-r0/neard-0.14/include/tlv.h include/near/tlv.h
9888 | /bin/mkdir -p include/near
9889 | /bin/mkdir -p include/near
9890 | ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
9891 0.14-r0/neard-0.14/include/setting.h include/near/setting.h
9892 | /bin/mkdir -p include/near
9893 | /bin/mkdir -p include/near
9894 | /bin/mkdir -p include/near
9895 | ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
9896 0.14-r0/neard-0.14/include/device.h include/near/device.h
9897 | ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
9898 0.14-r0/neard-0.14/include/nfc_copy.h include/near/nfc_copy.h
9899 | ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
9900 0.14-r0/neard-0.14/include/snep.h include/near/snep.h
9901 | ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
9902 0.14-r0/neard-0.14/include/version.h include/near/version.h
9903 | ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
9904 0.14-r0/neard-0.14/include/dbus.h include/near/dbus.h
9906 | i586-poky-linux-gcc -m32 -march=i586 --sysroot=/home/pokybuild/yocto-autobuilder/nightly-x86/
9907 …build/build/tmp/sysroots/qemux86 -DHAVE_CONFIG_H -I. -I./include -I./src -I./gdbus -I/home/pokybu…
9908 yocto-autobuilder/nightly-x86/build/build/tmp/sysroots/qemux86/usr/include/glib-2.0
9909 -I/home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/sysroots/qemux86/usr/
9910 lib/glib-2.0/include -I/home/pokybuild/yocto-autobuilder/nightly-x86/build/build/
9911 tmp/sysroots/qemux86/usr/include/dbus-1.0 -I/home/pokybuild/yocto-autobuilder/
9912 …nightly-x86/build/build/tmp/sysroots/qemux86/usr/lib/dbus-1.0/include -I/home/pokybuild/yocto-aut…
9913 nightly-x86/build/build/tmp/sysroots/qemux86/usr/include/libnl3
9914 -DNEAR_PLUGIN_BUILTIN -DPLUGINDIR=\""/usr/lib/near/plugins"\"
9915 -DCONFIGDIR=\""/etc/neard\"" -O2 -pipe -g -feliminate-unused-debug-types -c
9916 -o tools/snep-send.o tools/snep-send.c
9917 | In file included from tools/snep-send.c:16:0:
9922 | make[1]: *** [tools/snep-send.o] Error 1
9939 in your ``local.conf`` file to a high number (e.g. "-j 20"). Using a
9947 $ bitbake neard -c devshell
9950 ":ref:`dev-manual/common-tasks:using a development shell`" section.
9955 $ make tools/snep-send.o
9962 i586-poky-linux-gcc -m32 -march=i586 --sysroot=/home/scott-lenovo/......
9966 tools/snep-send.c
9967 In file included from tools/snep-send.c:16:0:
9972 make: *** [tools/snep-send.o] Error 1
9989 ":ref:`dev-manual/common-tasks:using quilt in your workflow`" section.
9995 tools/snep-send.$(OBJEXT): include/near/dbus.h
10004 recipe folder. Here is an example assuming a top-level
10007 $ cp patches/parallelmake.patch poky/meta/recipes-connectivity/neard/neard
10010 update the "neard" recipe (i.e. ``neard-0.14.bb``) so that the
10015 SRC_URI = "${KERNELORG_MIRROR}/linux/network/nfc/${BPN}-${PV}.tar.xz \
10039 $ bitbake neard -c devshell
10041 $ make tools/snep-send.o
10046 submit the fix for the recipe in OE-Core and upstream so that the
10048 ":ref:`dev-manual/common-tasks:submitting a change to the yocto project`"
10052 ------------------------------------------------------
10055 understand and fix problems. It also allows you to perform post-mortem
10058 ":ref:`ref-manual/images:Images`" chapter in the Yocto
10064 For best results, install debug (``-dbg``) packages for the applications you
10073 names, variable names and values, stack traces and so forth - even
10092 - Ensure that ``debuginfod`` is present in :term:`DISTRO_FEATURES`
10093 (it already is in ``OpenEmbedded-core`` defaults and ``poky`` reference distribution).
10101 - Run the following commands to launch the ``debuginfod`` server on the host::
10103 $ oe-debuginfod
10105 - To use ``debuginfod`` on the target, you need to know the ip:port where
10109 root@qemux86-64:~# export DEBUGINFOD_URLS="http://192.168.7.1:8002/"
10111 - Then debug info fetching should simply work when running the target ``gdb``,
10114 root@qemux86-64:~# gdb /bin/cat
10120 - It's also possible to use ``debuginfod-find`` to just query the server::
10122 root@qemux86-64:~# debuginfod-find debuginfo /bin/ls
10131 processes the debugging information that is run on a remote computer -
10171 ``-dbg`` packages.
10200 $ bitbake -c populate_sdk image
10207 $ bitbake meta-toolchain
10211 $ bitbake gdb-cross-<architecture>
10214 ``cross-gdb`` you can use for debugging during development. While
10216 are better when considering long-term maintenance strategies.
10220 If you run ``bitbake gdb-cross``, the OpenEmbedded build system suggests
10221 the actual image (e.g. ``gdb-cross-i586``). The suggestion is usually the
10230 $ tar xvfj build-dir/tmp-glibc/deploy/images/machine/image.rootfs.tar.bz2
10231 $ tar xvfj build-dir/tmp-glibc/deploy/images/machine/image-dbg.rootfs.tar.bz2
10240 …`build-dir`\ ``/tmp/sysroots/``\ `host`\ ``/usr/bin/``\ `architecture`\ ``/``\ `architecture`\ ``-…
10256 .. code-block:: shell
10267 $ cd directory-holding-the-debugfs-directory
10268 $ arch-gdb
10270 (gdb) set substitute-path /usr/src/debug debugfs/usr/src/debug
10271 (gdb) target remote IP-of-target:1234
10299 $ bitbake -c devshell bash
10301 $ scp packages-split/bash/bin/bash target:/bin/bash
10302 $ cp -a packages-split/bash-dbg/\* path/debugfs
10305 -----------------------------------------------------------
10316 - Ensure that GDB is on the target. You can do this by adding "gdb" to
10321 Alternatively, you can add "tools-debug" to :term:`IMAGE_FEATURES`::
10323 IMAGE_FEATURES:append = " tools-debug"
10325 - Ensure that debug symbols are present. You can make sure these
10326 symbols are present by installing ``-dbg``::
10328 IMAGE_INSTALL:append = "packagename-dbg"
10333 IMAGE_FEATURES:append = " dbg-pkgs"
10340 from :term:`FULL_OPTIMIZATION` of "-O2" to :term:`DEBUG_OPTIMIZATION`
10341 of "-O -fno-omit-frame-pointer"::
10349 --------------------
10353 - When adding new packages, it is worth watching for undesirable items
10358 - If you want to remove the ``psplash`` boot splashscreen, add
10364 - Removing :term:`TMPDIR` (usually
10370 ``sstate-cache/``, which is also in the Build Directory).
10378 - Understanding how a feature is used in practice within existing
10383 recursively search through common recipe-related files, skipping
10388 grep -Ir \
10389 --exclude-dir=.git \
10390 --exclude-dir='build*' \
10391 --include='*.bb*' \
10392 --include='*.inc*' \
10393 --include='*.conf*' \
10394 --include='*.py*' \
10401 $ g -i foo # Search recursively for "foo", ignoring case
10402 $ g -w FOO # Search recursively for "FOO" as a word, ignoring e.g. "FOOBAR"
10413 ":ref:`dev-manual/common-tasks:submitting a defect against the yocto project`"
10425 Because the Yocto Project is an open-source, community-based project,
10431 ---------------------------------------------
10437 Bugzilla <resources-bugtracker>`" section in the
10452 ``meta-intel`` layer, you would choose "Build System, Metadata &
10453 Runtime", "BSPs", and "bsps-meta-intel", respectively.
10489 ----------------------------------------
10496 The Yocto Project uses a mailing list and a patch-based workflow that is
10516 the combo-layer tool. The upstream location used for submitting changes
10519 - *Core Metadata:* Send your patch to the
10520 :oe_lists:`openembedded-core </g/openembedded-core>`
10524 - *BitBake:* For changes to BitBake (i.e. anything under the
10526 :oe_lists:`bitbake-devel </g/bitbake-devel>`
10529 - *"meta-\*" trees:* These trees contain Metadata. Use the
10532 - *Documentation*: For changes to the Yocto Project documentation, use the
10548 Yocto general mailing list or on the openembedded-devel mailing list.
10553 ":ref:`overview-manual/development-environment:git workflows and the yocto project`"
10557 Maintainers commonly use ``-next`` branches to test submissions prior to
10560 used testing branches for OpenEmbedded-Core are as follows:
10562 - *openembedded-core "master-next" branch:* This branch is part of the
10563 :oe_git:`openembedded-core </openembedded-core/>` repository and contains
10566 - *poky "master-next" branch:* This branch is part of the
10571 ``-next`` branches which collect proposed changes. For example,
10572 ``&DISTRO_NAME_NO_CAP;-next`` and ``&DISTRO_NAME_NO_CAP_MINUS_ONE;-next``
10573 branches in both the "openembdedded-core" and "poky" repositories.
10597 - Be sure to include a "Signed-off-by:" line in the same style as
10599 ``git commit -s`` command. Adding this line signifies that you,
10603 .. code-block:: none
10627 personal information I submit with it, including my sign-off) is
10631 - Provide a single-line summary of the change and, if more
10640 - For the body of the commit message, provide detailed information
10652 - If the change addresses a specific bug or issue that is associated
10653 with a bug-tracking ID, include a reference to that ID in your
10655 specific convention for bug references - any commit that addresses
10657 description. Be sure to use the actual bug-tracking ID from
10658 Bugzilla for bug-id::
10660 Fixes [YOCTO #bug-id]
10670 :ref:`list <dev-manual/common-tasks:submitting a change to the yocto project>`
10672 mailing lists, see the ":ref:`Mailing Lists <resources-mailinglist>`" section in the
10677 :ref:`dev-manual/common-tasks:preparing changes for submission` have been followed:
10680 format commits, use the ``git format-patch`` command. When you
10686 $ git format-patch -1
10690 $ git format-patch HEAD~
10696 ``git format-patch`` command produces a series of numbered files in
10698 one patch, you should also use the ``--cover`` option with the
10702 ``git format-patch`` command, see ``GIT_FORMAT_PATCH(1)`` displayed
10703 using the ``man git-format-patch`` command.
10712 relevant mailing lists by using the ``git send-email`` command.
10716 In order to use ``git send-email``, you must have the proper Git packages
10718 For Ubuntu, Debian, and Fedora the package is ``git-email``.
10720 The ``git send-email`` command sends email by using a local or remote
10732 The ``git send-email`` command is the preferred method for sending
10737 message. For information on how to use the ``git send-email``
10738 command, see ``GIT-SEND-EMAIL(1)`` displayed using the
10739 ``man git-send-email`` command.
10760 branch to an accessible repository and then using the ``create-pull-request``
10761 and ``send-pull-request`` scripts from openembedded-core to create and send a
10765 repository once the steps in :ref:`dev-manual/common-tasks:preparing changes for submission` have
10772 `Git Community Book <https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows>`__.
10781 into the upstream ``meta-intel-contrib`` repository and you are
10783 command pushes your local commits to the ``meta-intel-contrib``
10787 $ git push meta-intel-contrib your_name/README
10796 - *Maintenance File:* Examine the ``maintainers.inc`` file, which is
10800 - *Search by File:* Using :ref:`overview-manual/development-environment:git`, you can
10804 git shortlog -- filename
10812 - *Examine the List of Mailing Lists:* For a list of the Yocto
10814 lists <resources-mailinglist>`" section in
10822 are ``create-pull-request`` and ``send-pull-request``. You can find
10838 …$ poky/scripts/create-pull-request -u meta-intel-contrib -s "Updated Manual Section Reference in R…
10841 ``pull-``\ `PID` in the current directory. One of the patch files is a
10844 Before running the ``send-pull-request`` script, you must edit the
10851 … $ poky/scripts/send-pull-request -p ~/meta-intel/pull-10565 -t meta-intel@lists.yoctoproject.org
10857 For help on using these scripts, simply provide the ``-h``
10860 $ poky/scripts/create-pull-request -h
10861 $ poky/scripts/send-pull-request -h
10874 The patch should be amended using ``git commit --amend`` or perhaps ``git
10878 done by passing the ``-v`` argument to ``git format-patch`` with a version
10882 please don't just edit the patch file written out by ``git format-patch`` and
10903 End-Of-Life (EOL).
10911 See :ref:`dev-manual/common-tasks:checking for vulnerabilities`
10918 a. *If the fix is present in the master branch - Submit a backport request
10924 b. *If the fix is not present in the master branch - Submit the fix to the
10931 c. *If the fix is unsuitable for the master branch - Submit a patch
10937 steps in :ref:`dev-manual/common-tasks:preparing changes for submission` and
10938 …:ref:`dev-manual/common-tasks:using email to submit a patch` but modify the subject header of your…
10940 targetting. This can be done using the ``--subject-prefix`` argument to
10941 ``git format-patch``, for example to submit a patch to the dunfell
10943 ``git format-patch --subject-prefix='&DISTRO_NAME_NO_CAP_MINUS_ONE;][PATCH' ...``.
10948 As mentioned in the ":ref:`overview-manual/development-environment:licensing`"
10959 ------------------------
10982 - When using "beginline" and "endline", realize that line numbering
10987 - When a license check fails, the selected license text is included
11040 - If you specify an empty or invalid "md5" parameter,
11042 mis-match error and displays the correct "md5" parameter value
11046 - If the whole file contains only license text, you do not need to
11050 --------------------------------------
11054 are defined on a recipe-by-recipe basis through the
11057 ``poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly`` recipe
11074 ``poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly`` package, you
11075 could add either the string "commercial_gst-plugins-ugly" or the more
11077 ":ref:`dev-manual/common-tasks:license flag matching`" section for a full
11081 LICENSE_FLAGS_ACCEPTED = "commercial_gst-plugins-ugly"
11086 enable that package as well as the original ``gst-plugins-ugly``
11089 LICENSE_FLAGS_ACCEPTED = "commercial_gst-plugins-ugly license_emgd_1.10"
11121 :term:`LICENSE_FLAGS` value recipe-specific. After expansion, the
11162 - You can specify a versioned string in the recipe such as
11169 - Under the same circumstances, you can add "commercial_foo" in the
11174 - You can be very specific and use both the package and version parts
11183 ``poky/meta/conf/distro/include/default-distrovars.inc`` file::
11193 COMMERCIAL_AUDIO_PLUGINS = "gst-plugins-ugly-mad \
11194 gst-plugins-ugly-mpegaudioparse"
11195 COMMERCIAL_VIDEO_PLUGINS = "gst-plugins-ugly-mpeg2dec \
11196 gst-plugins-ugly-mpegstream gst-plugins-bad-mpegvideoparse"
11197 LICENSE_FLAGS_ACCEPTED = "commercial_gst-plugins-ugly commercial_gst-plugins-bad commercial_qmmp"
11215 --------------------------------------------------------------------------
11229 - Source code must be provided.
11231 - License text for the software must be provided.
11233 - Compilation scripts and modifications to the source code must be
11236 - spdx files can be provided.
11254 that is located in ``${DEPLOY_DIR}/licenses/``\ `image_name`\ ``-``\ `datestamp`
11262 for most compliance groups - providing the source. The Yocto Project has
11273 an :ref:`archiver <ref-classes-archiver>` class to
11276 Before you employ :term:`DL_DIR` or the :ref:`archiver <ref-classes-archiver>` class, you need to
11301 .. code-block:: shell
11307 src_release_dir="source-release"
11308 mkdir -p $src_release_dir
11313 p=${p%-*}
11314 p=${p%-*}
11316 numfiles=`ls tmp/deploy/licenses/$p/*GPL* 2> /dev/null | wc -l`
11317 if [ $numfiles -ge 1 ]; then
11319 mkdir -p $src_release_dir/$p/source
11321 mkdir -p $src_release_dir/$p/license
11354 ``/usr/share/common-licenses`` and the other resides in
11382 If the deployment team has a :ref:`overview-manual/concepts:bsp layer`
11391 .. code-block:: shell
11394 $ git clone -b dunfell git://git.yoctoproject.org/poky
11397 $ git clone -b release_branch git://git.mycompany.com/meta-my-bsp-layer
11398 $ git clone -b release_branch git://git.mycompany.com/meta-my-software-layer
11400 $ find . -name ".git" -type d -exec rm -rf {} \;
11403 thing a development organization might want to consider for end-user
11404 convenience is to modify ``meta-poky/conf/bblayers.conf.sample`` to
11418 ##OEROOT##/meta-poky \
11419 ##OEROOT##/meta-yocto-bsp \
11420 ##OEROOT##/meta-mylayer \
11437 :ref:`license <ref-classes-license>` and :ref:`archiver <ref-classes-archiver>`
11451 -----------------------------
11453 Some packages, such as the linux-firmware package, have many licenses
11459 non-common, non-CLOSED license in a recipe.
11464 NO_GENERIC_LICENSE[Firmware-Abilis] = "LICENSE.Abilis.txt"
11469 Vulnerabilities in Poky and OE-Core
11470 -----------------------------------
11478 <https://autobuilder.yocto.io/pub/non-release/patchmetrics/>`__
11479 for packages in Poky and OE-Core, tracking the evolution of the number of
11484 issues may be impacting Poky and OE-Core. It is up to the maintainers, users,
11487 It is recommended to work with Poky and OE-Core upstream maintainers and submit
11488 patches to fix them, see ":ref:`dev-manual/common-tasks:submitting a change to the yocto project`" …
11491 ---------------------------------
11493 To enable a check for CVE security vulnerabilities using :ref:`cve-check <ref-classes-cve-check>` i…
11496 INHERIT += "cve-check"
11499 deemed not to impact Poky or OE-Core. These CVE entries can be excluded from the
11502 include conf/distro/include/cve-extra-exclusions.inc
11508 - metadata about the software component like names and versions
11510 - metadata about the CVE issue such as description and NVD link
11512 - for each software component, a list of CVEs which are possibly impacting this version
11514 - status of each CVE: ``Patched``, ``Unpatched`` or ``Ignored``
11525 For example the CVE check report for the ``flex-native`` recipe looks like::
11527 $ cat poky/build/tmp/deploy/cve/flex-native
11529 PACKAGE NAME: flex-native
11531 CVE: CVE-2016-6354
11533 …CVE SUMMARY: Heap-based buffer overflow in the yy_get_next_buffer function in Flex before 2.6.1 mi…
11537 MORE INFORMATION: https://nvd.nist.gov/vuln/detail/CVE-2016-6354
11540 PACKAGE NAME: flex-native
11542 CVE: CVE-2019-6293
11544 …of '*' characters. Remote attackers could leverage this vulnerability to cause a denial-of-service.
11548 MORE INFORMATION: https://nvd.nist.gov/vuln/detail/CVE-2019-6293
11556 …: flex-2.6.4-r0 do_cve_check: Found unpatched CVE (CVE-2019-6293), for more information check /pok…
11557 …ive-3.5.1-r0 do_cve_check: Found unpatched CVE (CVE-2021-36976), for more information check /poky/…
11561 bitbake -c cve_check flex libarchive
11564 --------------------------------------------
11566 By default, :ref:`cve-check <ref-classes-cve-check>` uses the recipe name :term:`BPN` as CVE
11588 around the issues possibly for a long time in Poky and OE-Core side recipes. Feedback to
11589 … entries can be provided through the `NVD contact form <https://nvd.nist.gov/info/contact-form>`__.
11592 ---------------------------------
11595 version of the software component or by applying a patch. For Poky and OE-Core master branches, upd…
11606 file://0001-libavutil-include-assembly-with-full-path-from-sourc.patch \
11607 file://fix-CVE-2020-20446.patch \
11608 file://fix-CVE-2020-20453.patch \
11609 file://fix-CVE-2020-22015.patch \
11610 file://fix-CVE-2020-22021.patch \
11611 file://fix-CVE-2020-22033-CVE-2020-22019.patch \
11612 file://fix-CVE-2021-33815.patch \
11617 CVE: CVE-2020-22033
11631 ----------------------
11633 Here's what the :ref:`cve-check <ref-classes-cve-check>` class does to
11639 one is considered. Then, the code looks for ``CVE: CVE-ID`` lines in the patch
11645 - If the package name (:term:`PN`) is part of
11648 - If the CVE ID is part of :term:`CVE_CHECK_IGNORE`, it is
11651 - If the CVE ID is part of the patched CVE for the recipe, it is
11654 - Otherwise, the code checks whether the recipe version (:term:`PV`)
11661 sqlite3 downloads/CVE_CHECK/nvdcve_1.1.db .dump | grep CVE-2021-37462
11665 - study the latest information in `CVE database <https://nvd.nist.gov/vuln/search>`__.
11667 - check how upstream developers of the software component addressed the issue, e.g.
11670 - check what other Linux distributions like `Debian <https://security-tracker.debian.org/tracker/>…
11673 - follow security notices from other Linux distributions.
11675 - follow public `open source security mailing lists <https://oss-security.openwall.org/wiki/mailin…
11683 ":ref:`dev-manual/common-tasks:working with licenses`") and once vulnerability
11684 fixes are applied (see ":ref:`dev-manual/common-tasks:checking
11703 :ref:`create-spdx <ref-classes-create-spdx>` class from a configuration file::
11705 INHERIT += "create-spdx"
11708 ``IMAGE-MACHINE.spdx.json`` file in ``tmp/deploy/images/MACHINE/`` inside the
11711 This is a toplevel file accompanied by an ``IMAGE-MACHINE.spdx.index.json``
11713 with an ``IMAGE-MACHINE.spdx.tar.zst`` compressed archive containing all such
11716 The :ref:`ref-classes-create-spdx` class offers options to include
11728 - The individual :term:`SPDX` JSON files in the ``IMAGE-MACHINE.spdx.tar.zst``
11731 - Compressed archives of the files in the generated target packages,
11735 - Compressed archives of the source files used to build the host tools
11736 and the target packages in ``recipes/recipe-packagename.tar.zst``
11755 errors. The tool works using a client-server system where the client
11773 ---------------------------
11777 :ref:`report-error <ref-classes-report-error>`
11783 INHERIT += "report-error"
11786 ``${``\ :term:`LOG_DIR`\ ``}/error-report``.
11799 …$ send-error-report /home/brandusa/project/poky/build/tmp/log/error-report/error_report_2014031416…
11807 $ send-error-report --help
11819 ------------------
11826 INHERIT += "report-error"
11829 ------------------------------------------
11832 the code from the Git repository at :yocto_git:`/error-report-web/`.
11853 ``meta/recipes-graphics/wayland``.
11872 ----------------------------
11880 To cause Mesa to build the ``wayland-egl`` platform and Weston to build
11905 --------------
11911 Alternatively, you can run Weston through the command-line interpretor
11917 mkdir -p /tmp/$USER-weston
11918 chmod 0700 /tmp/$USER-weston
11919 export XDG_RUNTIME_DIR=/tmp/$USER-weston