Lines Matching +full:panel +full:- +full:mounted
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
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
3845 ----------------------------------------------------
3863 ``core-image-minimal-initramfs.bb`` recipe found in the
3864 ``meta/recipes-core`` directory of the :term:`Source Directory`
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
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
4871 - A unique architecture is defined for the Multilib packages, along
4874 example, consider ``lib32`` in a ``qemux86-64`` image. The possible
4878 - The ``${MLPREFIX}`` variable is stripped from ``${PN}`` during 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
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 --------------------------------
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
6631 - Automatically using a Package Revision Service (PR Service).
6633 - Manually incrementing the :term:`PR` and/or :term:`PV` variables.
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
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
7183 $ python3 -m http.server
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]
7245 - *Create a Single (Full) Package Index:* Define a single base URL that
7248 [oe-packages]
7258 .. code-block:: none
7294 .. code-block:: none
7303 .. code-block:: none
7331 .. code-block:: none
7340 .. code-block:: none
7349 ------------------------------------
7381 - *GPG_BIN:* Specifies a ``gpg`` binary/wrapper that is executed
7384 - *GPG_PATH:* Specifies the ``gpg`` home directory used when the
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``
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,
8774 which is mounted under ``/``.
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
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
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