poky: subtree update:1203d1f24d..2dcd1f2a21
Alejandro Enedino Hernandez Samaniego (2):
python3: Improve logging, syntax and update deprecated modules to create_manifest
python3: Upgrade 3.9.2 -> 3.9.4
Alexander Kanavin (22):
scripts/oe-debuginfod: correct several issues
libmicrohttpd: add a recipe from meta-oe
maintainers.inc: add libmicrohttpd entry
xwayland: add a standalone recipe
weston: use standalone xwayland instead of outdated xserver-xorg version
elfutils: correct debuginfod builds on x32
elfutils: adjust ptests for correct debuginfod testing
default-distrovars.inc: add debuginfod to default DISTRO_FEATURES
oeqa: tear down oeqa decorators if one of them raises an exception in setup
meta/lib/oeqa/core/tests/cases/timeout.py: add a testcase for the previous fix
core-image-weston: add sdk/ptest images
oeqa/core/tests/test_data.py: use weston image instead of sato
oeqa/selftest: transition to weston images
core-image-multilib-example: base on weston, and not sato
dev-manual/common-tasks.rst: correct the documentation for debuginfod
diffoscope: add native libraries to LD_LIBRARY_PATH
Revert "oeqa: Set LD_LIBRARY_PATH when executing native commands"
boost: correct upstream version check
vte: use tarballs again
gdk-pixbuf: update 2.40.0 -> 2.42.6
glib-2.0: update 2.68.0 -> 2.68.1
gnu-config: update to latest revision
Anatol Belski (1):
cross-canadian: Whitelist "mingw32" as TARGET_OS
Anders Wallin (3):
lttng-tools: Fix missing legacy test files
lttng-tools: Fix path for test_python_looging
scripts/contrib/image-manifest: add new script
Andreas Müller (1):
xwayland: remove protocol.txt - it clashes with xserver-xorg
Anthony Bagwell (1):
systemd: upgrade 247.4 -> 247.6
Anuj Mittal (2):
Revert "qemu: fix CVE-2021-3392"
qemu: fix CVE-2021-3392
Armin Kuster (6):
binutils: rename BRANCH var
libseccomp: move recipe from meta-security to core
gnutls: Enable seccomp if FEATURE is set
systemd: Enable seccomp if FEATURE is set
qemu: Enable seccomp if FEATURE is set
default-distrovars.inc: Add seccomp to DISTRO_FEATURES_DEFAULT
Bastian Krause (1):
ccache: add packageconfig docs option
Bruce Ashfield (20):
kern-tools: add dropped options to audit output
linux-yocto/5.4: update to v5.4.109
linux-yocto/5.10: update to v5.10.27
linux-yocto/5.10: BSP configuration fixes
linux-yocto/5.10: update to v5.10.29
linux-yocto/5.4: update to v5.4.111
linux-yocto/5.10: update to v5.10.30
linux-yocto-rt/5.10: update to -rt34
linux-yocto/5.4: update to v5.4.112
linux-yocto/5.4: fix arm defconfig warnings
linux-yocto/5.10: fix arm defconfig warnings
linux-yocto/5.10: aufs fixes
linux-yocto/5.10: qemuriscv32.cfg: RV32 only supports 1G physical memory
linux-yocto/5.10: update to v5.10.32
perf: fix python-audit RDEPENDS
linux-yocto/5.4: update to v5.4.114
linux-yocto/5.10: update to v5.10.34
linux-yocto/5.4: update to v5.4.116
linux-yocto/5.10: qemuppc32: reduce serial shutdown issues
yocto-check-layer: Only note a layer without a conf/layer.conf (versus error)
Changqing Li (2):
libpam: make volatile files created successfully
gcr: fix one parallel build failure
Chen Qi (3):
busybox: fix CVE-2021-28831
weston: fix build failure due to race condition
rsync: fix CVE-2020-14387
Christophe Chapuis (1):
rootfs.py: find .ko.gz and .ko.xz kernel modules as well
Daniel Ammann (1):
archiver: Fix typos
Devendra Tewari (2):
bitbake: lib/bb: Add bb.utils.rename() helper function and use for renaming
classes/lib/scripts: Use bb.utils.rename() instead of os.rename()
Diego Sueiro (3):
oeqa/selftest/bblayers: Add test case for bitbake-layers layerindex-show-depends
bitbake: layerindex: Fix bitbake-layers layerindex-show-depends command
bitbake: layerindex: Add --fetchdir parameter to layerindex-fetch
Douglas Royds (2):
Revert "externalsrc: Detect code changes in submodules"
externalsrc: Detect code changes in submodules
Gavin Li (1):
kmod: do not symlink config.guess/config.sub during autoreconf
Harald Brinkmann (1):
bitbake: fetch/svn: Fix parsing revision of SVN repos with redirects
He Zhe (1):
linux-yocto-dev: add features/scsi/scsi-debug.scc features/gpio/mockup.scc to KERNEL_FEATURES
Henning Schild (3):
bitbake: fetch/git: add support for disabling shared clones on unpack
bitbake: tests/fetch: deduplicate local git testing code
bitbake: tests/fetch: add tests for local and remote "noshared" git fetching
Jon Mason (1):
oeqa/runtime: space needed
Jonas Höppner (1):
ltp: fix empty ltp-dev package
Jose Quaresma (4):
gstreamer1.0: update patch upstream status
ptest-runner: libgcc must be installed for pthread_cancel to work
gstreamer1.0: rename patches
gstreamer1.0: update ptest patch
Joshua Watt (2):
bitbake: knotty: Re-enable command line logging levels
classes/image: Use xargs to set file timestamps
Kai Kang (2):
cmake.bbclass: remove ${B} before cmake_do_configure
kernel-yocto.bbclass: chdir to ${WORKDIR} for do_kernel_checkout
Kevin Hao (3):
modutils-initscripts: Bail out when no module is installed
sysvinit-inittab/start_getty: Check /sys for the tty device existence
Revert "inittab: Add getty launch on hvc0 for qemuppc64"
Khairul Rohaizzat Jamaluddin (1):
qemu: Fix CVE-2020-35517
Khem Raj (54):
gcc: Upgrade to 10.3.0 bug-fix release
glibc: Rename glibc src package
gcc-runtime: Make DEBUG_PREFIX_MAP relative to S
valgrind: Delete trailing whitespaces
valgrind: Add glibc-src to ptest rdeps
valgrind: Add libstdc++ debug symbols for ptest
vte: Upgrade to 0.64.0 release
systemd: Fix build on mips/musl
epiphany: Add missing dependency on gnutls
cups: Turn gnutls into a packageconfig knob
wpa-supplicant: Enable openssl
curl: Use openssl backend
libpsl: Add config knobs for runtime/builtin conversion choices
glib-networking: Prefer openssl backend instead of gnutls
gstreamer1.0-plugins-bad: Add packageconfigs for hls crypto backends
ca-certificates: Fix openssl runtime cert dependencies
weston: Drop loading xwayland.so module
elfutils: Make 64bit time_t fix generic
binutils: Fix linking failures when using dwarf-5
go: Use dl.google.com for SRC_URI
musl: Update to latest master
llvm: Upgrade to LLVM 12 release
python3-docutils: Upgrade to 0.17.1
python3-markupsafe: Enable ptests
python3-jinja2: Enable ptests
python3-pyyaml: Add recipe
apt: Fix build on musl when seccomp is enabled
default-distrovars.inc: Remove seccomp for riscv32
gcc-target: Create a LTO plugin symlink in bfd-plugins directory
bitbake.conf: Use gcc-nm as default NM
gcc-cross: Install linker LTO plugin for binutils tools
gcc-cross-canadian: Install LTO linker plugin to BFD searchable location
gnutls: Point to staging area for finding seccomp libs and includes
libjpeg-turbo: Use --reproducible option for nasm
libid3tag: Filter -ffile-prefix-map too
openssl: Filter out -ffile-prefix-map as well
ltp: Filter out -ffile-prefix-map
gcc-runtime: Fix __FILE__ related reproducablity issues
reproducible_build.bbclass: Enable -Wdate-time
pkgconfig: Fix nativesdk builds for mingw sdk hosts
m4: Do not use SIGSTKSZ
bluez: Fix shadowing of pause function from libc
valgrind: Disable leak_cpp_interior test
findutils: Do not use SIGSTKSZ
bash: Include files needed for run-heredoc ptest
libpam: Provide needed env for tst-pam_start_confdir ptest
cml1.bbclass: Return sorted list of cfg files
busybox: Enable long options for enabled applets
webkitgtk: Fix reproducibility in minibrowser
webkitgtk: Update patch status
libgcc-initial: Do not build fp128 to decimal ppc functions
gcc: Upgrade to GCC 11
busybox: Fix reproducibility
strace: Upgrade to 5.12
Konrad Weihmann (2):
cpan-base: set default UPSTREAM_CHECK_REGEX
cve-update-db-native: skip on empty cpe23Uri
Marek Vasut (1):
linux-firmware: Package RSI 911x WiFi firmware
Martin Jansa (2):
xwayland: add opengl to REQUIRED_DISTRO_FEATURES
ofono: prevent using bundled ell headers and fix build with ell-0.39
Michael Halstead (1):
releases: update to include 3.3
Michael Opdenacker (7):
dev-manual: fix code insertion
manuals: simplify code insertion
manuals: code insertion simplification over two lines
bitbake: doc: bitbake-user-manual: simplify colon usage
bitbake: doc: bitbake-user-manual: code insertion simplification over two lines
dev-manual: update references to Docker installation instructions
sanity.bbclass: mention CONNECTIVITY_CHECK_URIS in network failure message
Mikko Rapeli (4):
bitbake: bitbake: tests/fetch: fix test execution without .gitconfig
bitbake: bitbake: tests/fetch: remove write protected files too
lz4: use CFLAGS from bitbake
unzip: use optimization from bitbake
Mingli Yu (6):
libxshmfence: Build fixes for riscv32
packagegroup-core-tools-profile: Remove valgrind for riscv32
packagegroup-core-tools-testapps.bb: Remove kexec for riscv32
libtool: make sure autoheader run before automake
groff: not ship /usr/bin/grap2graph
rpm: Upgrade to 4.16.1.3
Minjae Kim (1):
qemu: fix CVE-2021-3392
Nicolas Dechesne (1):
bitbake: doc: bitbake-user-manual: fix typo left over from Sphinx migration
Niels Avonds (1):
bitbake: fetch/gitsm: Fix crash when using git LFS and submodules
Oleksandr Kravchuk (2):
python3-setuptools: update to 56.0.0
autoconf-archive: update to 2021.02.19
Otavio Salvador (2):
gstreamer1.0-plugins-base: Add 'viv-fb' OpenGL Window System option
gstreamer1.0-plugins-base: Use bb.utils.filter to reduce code
Paul Barker (10):
bitbake: hashserv: Use generic ConnectionError
bitbake: asyncrpc: Common implementation of RPC using json & asyncio
bitbake: hashserv: Refactor to use asyncrpc
bitbake: prserv: Drop obsolete python version check
bitbake: prserv: Drop unused dump_db method
bitbake: prserv: Add connect function
prservice: Use new connect API
bitbake: prserv: Use multiprocessing to auto start prserver
bitbake: prserv: Extract daemonization from PRServer class
bitbake: prserv: Handle requests in main thread
Paulo Cesar Zaneti (1):
perl: fix startperl configuration option for perl-native
Peter Budny (1):
lib/oe/terminal: Fix tmux new-session on older tmux versions (<1.9)
Petr Vorel (1):
ltp: Replace musl patches with do_patch[postfuncs]
Przemyslaw Gorszkowski (2):
bitbake: progress: LineFilterProgressHandler - Handle parsing line which ends with CR only
bitbake: fetch/s3: Add progress handler for S3 cp command
Randy MacLeod (2):
sqlite3: upgrade 3.35.0 -> 3.35.3
oe-time-dd-test.sh: increase timeout to 15 sec
Reto Schneider (2):
license_image.bbclass: Detect broken symlinks
license_image.bbclass: Fix symlink to generic license files
Richard Purdie (32):
oeqa/selftest: Hardcode test assumptions about heartbeat event timings
pseudo: Upgrade to add trailing slashes ignore path fix
oeqa/selftest: Ensure packages classes are set correctly for maintainers test
layer.conf: Update to add post 3.3 release honister series
sanity: Add error check for '%' in build path
bitbake: runqueue: Fix deferred task issues
bitbake: tinfoil/data_smart: Allow variable history emit() to function remotely
sanity: Further improve directory sanity tests
bitbake: bitbake-server: Remove now unneeded code
bitbake: doc/user-manual-fetching: Remove basepath unpack parameter docs
poky.conf: Post release version bump
runqemu: Ensure we cleanup snapshot files after image run
patchelf: Backport fix from upstream for note section overlap error
pyyaml: Add missing HOMEPAGE
yocto-check-layer: Avoid bug when iterating and autoadding dependencies
libseccomp: Add MAINTAINERS entry and HOMEPAGE
libseccomp: Fix reproducibility issue
apt: Disable libseccomp
libxcrypt: Update to 4.4.19 release and fix symbol version issues
patchelf: Fix note section alignment issues
bitbake: runqueue: Fix multiconfig deferred task sstate validity caching issue
bitbake: runqueue: Handle deferred task rehashing in multiconfig builds
patchelf: Fix alignment patch
pybootchart/draw: Avoid divide by zero error
yocto-uninative: Update to 3.1 which includes a patchelf fix
Revert "perl: fix startperl configuration option for perl-native"
bitbake: bin/bitbake-getvar: Add a new command to query a variable value (with history)
bitbake: bitbake: Switch to post release version number 1.51.0
sanity.conf: Require bitbake 1.51.0
oeqa/qemurunner: Improve logging thread exit handling for qemu shutdown test
oeqa/qemurunner: Handle path length issues for qmp socket
lib/package_manager: Use shutil.copy instead of bb.utils.copyfile for intercepts
Robert Joslyn (3):
btrfs-tools: Update to 5.11.1
btrfs-tools: Add PACKAGECONFIG options
btrfs-tools: Try to follow style guide
Robert P. J. Day (3):
sdk-manual: "beablebone" -> "beaglebone"
sdk-manual: fix broken formatting of sample command
bitbake.conf: sort MIRROR list, add missing SAMBA_MIRROR
Ross Burton (4):
glslang: strip whitespace in pkgconfig file
insane: clean up some more warning messages
bitbake: bitbake-server: ensure server timeout is a float
oe-buildenv-internal: add BitBake's library to PYTHONPATH
Sakib Sajal (12):
oe-time-dd-test.sh: make executable
oe-time-dd-test.sh: provide more information from "top"
qemu: fix CVE-2021-20181
qemu: fix CVE-2020-29443
qemu: fix CVE-2021-20221
qemu: fix CVE-2021-3409
qemu: fix CVE-2021-3416
qemu: fix CVE-2021-20257
oe-time-dd-test.sh: collect cooker log when timeout is exceeded
buildstats.bbclass: collect data in the same file.
qemu: fix CVE-2020-27821
qemu: fix CVE-2021-20263
Samuli Piippo (1):
assimp: BBCLASSEXTEND to native and nativesdk
Saul Wold (4):
pango: re-enable ptest
qemu-system-native: install qmp python module
qemurunner: Add support for qmp commands
qemurunner: change warning to info
Stefan Ghinea (3):
wpa-supplicant: fix CVE-2021-30004
libssh2: fix build failure with option no-ecdsa
xserver-xorg: fix CVE-2021-3472
Stefano Babic (1):
libubootenv: upgrade 0.3.1 -> 0.3.2
Teoh Jay Shen (6):
oeqa/manual/bsp-hw.json : remove boot_from_runlevel_3 and boot_from_runlevel_5 manual test
oeqa/manual/bsp-hw.json : remove ethernet_static_ip_set_in_connman and ethernet_get_IP_in_connman_via_DHCP manual test
oeqa/manual/bsp-hw.json : remove standby and Test_if_LAN_device_works_well_after_resume_from_suspend_state manual test
oeqa/manual/bsp-hw.json : remove click_terminal_icon_on_X_desktop manual test
oeqa/manual/bsp-hw.json :remove Check_if_RTC_(Real_Time_Clock)_can_work_correctly manual test
oeqa/manual/bsp-hw.json : remove Test_if_usb_hid_device_works_well_after_resume_from_suspend_state manual test
Trevor Gamblin (2):
nettle: upgrade 3.7.1 -> 3.7.2
ref-manual/variables.rst: Add incompatibility warning for SERIAL_CONSOLES_CHECK
Ulrich Ölmann (1):
arch-armv6m.inc: fix access rights
Vinay Kumar (1):
binutils: Fix CVE-2021-20197
Vineela Tummalapalli (1):
Adding dunfell 3.1.7 to the switcher and release list.
Wang Mingyu (6):
at-spi2-core: upgrade 2.38.0 -> 2.40.0
babeltrace2: upgrade 2.0.3 -> 2.0.4
boost-build-native: upgrade 4.3.0 -> 4.4.1
libassuan: upgrade 2.5.4 -> 2.5.5
webkitgtk: upgrade 2.30.5 -> 2.30.6
vte: upgrade 0.62.2 -> 0.62.3
Wes Lindauer (1):
oeqa/runtime/cases: Only disable/enable for current boot
Yanfei Xu (1):
parselogs: ignore floppy error on qemu-system-x86 at boot stage
Yi Fan Yu (7):
valgrind: update 3.16.1 -> 3.17.0
valgrind: Disable ptest swapcontext.vgtest
valgrind: Fix ptest swapcontext.vgtest
Revert "glib-2.0: add workaround to fix codegen.py.test failing"
re2c: Upgrade 2.0.3 -> 2.1.1
valgrind: Enable drd/tests/bar_bad* ptest
libevent: Increase ptest timing tolerance 50 ms -> 100 ms
Zqiang (1):
rt-tests: Update rt-tests
hongxu (1):
deb: apply postinstall on sdk
wangmy (34):
ell: upgrade 0.38 -> 0.39
dbus-glib: upgrade 0.110 -> 0.112
ccache: upgrade 4.2 -> 4.2.1
gcr: upgrade 3.38.1 -> 3.40.0
ghostscript: upgrade 9.53.3 -> 9.54.0
libsolv: upgrade 0.7.17 -> 0.7.18
glib-2.0: upgrade 2.66.7 -> 2.68.0
file: upgrade 5.39 -> 5.40
curl: upgrade 7.75.0 -> 7.76.0
acpica: upgrade 20210105 -> 20210331
help2man: upgrade 1.48.2 -> 1.48.3
libportal: upgrade 0.3 -> 0.4
libksba: upgrade 1.5.0 -> 1.5.1
go: upgrade 1.16.2 -> 1.16.3
libcap: upgrade 2.48 -> 2.49
libcomps: upgrade 0.1.15 -> 0.1.16
icu: upgrade 68.2 -> 69.1
mpg123: upgrade 1.26.4 -> 1.26.5
man-pages: upgrade 5.10 -> 5.11
go: update SRC_URI to use https protocol
mesa: upgrade 21.0.1 -> 21.0.2
openssh: upgrade 8.5p1 -> 8.6p1
mtools: upgrade 4.0.26 -> 4.0.27
python3-cython: upgrade 0.29.22 -> 0.29.23
tiff: upgrade 4.2.0 -> 4.3.0
boost: upgrade 1.75.0 -> 1.76.0
wpebackend-fdo: upgrade 1.8.2 -> 1.8.3
mesa: upgrade 21.0.2 -> 21.0.3
gdb: upgrade 10.1 -> 10.2
glib-networking: upgrade 2.66.0 -> 2.68.1
glslang: upgrade 11.2.0 -> 11.4.0
hdparm: upgrade 9.60 -> 9.61
libhandy: upgrade 1.2.1 -> 1.2.2
libjitterentropy: upgrade 3.0.1 -> 3.0.2
zangrc (1):
maintainers.inc: Modify email address
zhengruoqin (19):
epiphany: upgrade 3.38.2 -> 3.38.3
wpebackend-fdo: upgrade 1.8.0 -> 1.8.2
netbase: upgrade 6.2 -> 6.3
python3-dbusmock: upgrade 0.22.0 -> 0.23.0
python3-gitdb: upgrade 4.0.5 -> 4.0.7
libva: upgrade 2.10.0 -> 2.11.0
ruby: upgrade 3.0.0 -> 3.0.1
libva-utils: upgrade 2.10.0 -> 2.11.1
libdazzle: upgrade 3.38.0 -> 3.40.0
librepo: upgrade 1.13.0 -> 1.14.0
libdrm: upgrade 2.4.104 -> 2.4.105
python3-pygobject: upgrade 3.38.0 -> 3.40.1
libedit: upgrade 20210216-3.1 -> 20210419-3.1
libhandy: upgrade 1.2.0 -> 1.2.1
libical: upgrade 3.0.9 -> 3.0.10
libsolv: upgrade 0.7.18 -> 0.7.19
libmicrohttpd: upgrade 0.9.72 -> 0.9.73
python3-numpy: upgrade 1.20.1 -> 1.20.2
wireless-regdb: upgrade 2020.11.20 -> 2021.04.21
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Change-Id: Ibdaea694cae40b0749d472bf08b53002a45b31d7
diff --git a/poky/documentation/dev-manual/common-tasks.rst b/poky/documentation/dev-manual/common-tasks.rst
index 176025f..37c7a19 100644
--- a/poky/documentation/dev-manual/common-tasks.rst
+++ b/poky/documentation/dev-manual/common-tasks.rst
@@ -49,15 +49,13 @@
(e.g. the cloned ``poky`` repository).
While not strictly required, prepend the name of the directory with
- the string "meta-". For example:
- ::
+ the string "meta-". For example::
meta-mylayer
meta-GUI_xyz
meta-mymachine
- With rare exceptions, a layer's name follows this form:
- ::
+ With rare exceptions, a layer's name follows this form::
meta-root_name
@@ -77,8 +75,7 @@
:yocto_git:`Source Repositories </poky/tree/meta-yocto-bsp/conf>`
demonstrates the required syntax. For your layer, you need to replace
"yoctobsp" with a unique identifier for your layer (e.g. "machinexyz"
- for a layer named "meta-machinexyz"):
- ::
+ for a layer named "meta-machinexyz")::
# We have a conf and classes directory, add to BBPATH
BBPATH .= ":${LAYERDIR}"
@@ -195,8 +192,7 @@
machine "one". To do so, you use an append file named
``base-files.bbappend`` and create a dependency on "foo" by
altering the :term:`DEPENDS`
- variable:
- ::
+ variable::
DEPENDS = "foo"
@@ -209,14 +205,12 @@
``foo``.
To make sure your changes apply only when building machine "one",
- use a machine override with the ``DEPENDS`` statement:
- ::
+ use a machine override with the ``DEPENDS`` statement::
DEPENDS_one = "foo"
You should follow the same strategy when using ``_append``
- and ``_prepend`` operations:
- ::
+ and ``_prepend`` operations::
DEPENDS_append_one = " foo"
DEPENDS_prepend_one = "foo "
@@ -224,8 +218,7 @@
As an actual example, here's a
snippet from the generic kernel include file ``linux-yocto.inc``,
wherein the kernel compile and link options are adjusted in the
- case of a subset of the supported architectures:
- ::
+ case of a subset of the supported architectures::
DEPENDS_append_aarch64 = " libgcc"
KERNEL_CC_append_aarch64 = " ${TOOLCHAIN_OPTIONS}"
@@ -252,8 +245,7 @@
file, you can use an append file to cause the build to use your
own version of the file. For example, an append file in your layer
at ``meta-one/recipes-core/base-files/base-files.bbappend`` could
- extend :term:`FILESPATH` using :term:`FILESEXTRAPATHS` as follows:
- ::
+ extend :term:`FILESPATH` using :term:`FILESEXTRAPATHS` as follows::
FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}:"
@@ -375,8 +367,7 @@
layer, the layer must pass the COMMON and BSP set of tests.
To execute the script, enter the following commands from your build
-directory:
-::
+directory::
$ source oe-init-build-env
$ yocto-check-layer your_layer_directory
@@ -432,8 +423,7 @@
``BBLAYERS`` variable in your ``conf/bblayers.conf`` file, which is
found in the :term:`Build Directory`.
The following example shows how to enable a layer named
-``meta-mylayer``:
-::
+``meta-mylayer``::
# POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
@@ -488,8 +478,7 @@
formfactor append file both from the :term:`Source Directory`.
Here is the main
formfactor recipe, which is named ``formfactor_0.0.bb`` and located in
-the "meta" layer at ``meta/recipes-bsp/formfactor``:
-::
+the "meta" layer at ``meta/recipes-bsp/formfactor``::
SUMMARY = "Device formfactor information"
DESCRIPTION = "A formfactor configuration file provides information about the \
@@ -521,8 +510,7 @@
Following is the append file, which is named ``formfactor_0.0.bbappend``
and is from the Raspberry Pi BSP Layer named ``meta-raspberrypi``. The
-file is in the layer at ``recipes-bsp/formfactor``:
-::
+file is in the layer at ``recipes-bsp/formfactor``::
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
@@ -570,8 +558,7 @@
To specify the layer's priority manually, use the
:term:`BBFILE_PRIORITY`
-variable and append the layer's root name:
-::
+variable and append the layer's root name::
BBFILE_PRIORITY_mylayer = "1"
@@ -595,8 +582,7 @@
applicable recipes can help to reveal potential problems.
For help on the BitBake layer management tool, use the following
-command:
-::
+command::
$ bitbake-layers --help
NOTE: Starting bitbake server...
@@ -676,8 +662,7 @@
variable values, you need to tidy these up yourself. Consider the
following example. Here, the ``bitbake-layers`` command adds the
line ``#### bbappended ...`` so that you know where the following
- lines originate:
- ::
+ lines originate::
...
DESCRIPTION = "A useful utility"
@@ -691,8 +676,7 @@
EXTRA_OECONF += "--enable-somethingelse"
- Ideally, you would tidy up these utilities as follows:
- ::
+ Ideally, you would tidy up these utilities as follows::
...
DESCRIPTION = "Customized utility"
@@ -746,14 +730,12 @@
In its simplest form, you can use the following command form to create a
layer. The command creates a layer whose name corresponds to
-"your_layer_name" in the current directory:
-::
+"your_layer_name" in the current directory::
$ bitbake-layers create-layer your_layer_name
As an example, the following command creates a layer named ``meta-scottrif``
-in your home directory:
-::
+in your home directory::
$ cd /usr/home
$ bitbake-layers create-layer meta-scottrif
@@ -770,8 +752,7 @@
The easiest way to see how the ``bitbake-layers create-layer`` command
works is to experiment with the script. You can also read the usage
-information by entering the following:
-::
+information by entering the following::
$ bitbake-layers create-layer --help
NOTE: Starting bitbake server...
@@ -799,16 +780,14 @@
makes the OpenEmbedded build system aware of your layer so that it can
search it for metadata.
-Add your layer by using the ``bitbake-layers add-layer`` command:
-::
+Add your layer by using the ``bitbake-layers add-layer`` command::
$ bitbake-layers add-layer your_layer_name
Here is an example that adds a
layer named ``meta-scottrif`` to the configuration file. Following the
command that adds the layer is another ``bitbake-layers`` command that
-shows the layers that are in your ``bblayers.conf`` file:
-::
+shows the layers that are in your ``bblayers.conf`` file::
$ bitbake-layers add-layer meta-scottrif
NOTE: Starting bitbake server...
@@ -851,8 +830,7 @@
all images, which might not be what you require.
To add a package to your image using the local configuration file, use
-the ``IMAGE_INSTALL`` variable with the ``_append`` operator:
-::
+the ``IMAGE_INSTALL`` variable with the ``_append`` operator::
IMAGE_INSTALL_append = " strace"
@@ -870,8 +848,7 @@
As shown in its simplest use, ``IMAGE_INSTALL_append`` affects all
images. It is possible to extend the syntax so that the variable applies
-to a specific image only. Here is an example:
-::
+to a specific image only. Here is an example::
IMAGE_INSTALL_append_pn-core-image-minimal = " strace"
@@ -942,8 +919,7 @@
You can also customize an image by creating a custom recipe that defines
additional software as part of the image. The following example shows
-the form for the two lines you need:
-::
+the form for the two lines you need::
IMAGE_INSTALL = "packagegroup-core-x11-base package1 package2"
inherit core-image
@@ -958,8 +934,7 @@
existing image. For example, if you want to create an image based on
``core-image-sato`` but add the additional package ``strace`` to the
image, copy the ``meta/recipes-sato/images/core-image-sato.bb`` to a new
-``.bb`` and add the following line to the end of the copy:
-::
+``.bb`` and add the following line to the end of the copy::
IMAGE_INSTALL += "strace"
@@ -990,8 +965,7 @@
Here is a short, fabricated example showing the same basic pieces for a
hypothetical packagegroup defined in ``packagegroup-custom.bb``, where
the variable ``PN`` is the standard way to abbreviate the reference to
-the full packagegroup name ``packagegroup-custom``:
-::
+the full packagegroup name ``packagegroup-custom``::
DESCRIPTION = "My Custom Package Groups"
@@ -1033,13 +1007,11 @@
You can customize this name by altering the value of the "hostname"
variable in the ``base-files`` recipe using either an append file or a
-configuration file. Use the following in an append file:
-::
+configuration file. Use the following in an append file::
hostname = "myhostname"
-Use the following in a configuration file:
-::
+Use the following in a configuration file::
hostname_pn-base-files = "myhostname"
@@ -1054,8 +1026,7 @@
Another point of interest is that if you unset the variable, the image
will have no default hostname in the filesystem. Here is an example that
-unsets the variable in a configuration file:
-::
+unsets the variable in a configuration file::
hostname_pn-base-files = ""
@@ -1136,8 +1107,7 @@
:term:`Build Directory` and have sourced the
build environment setup script (i.e.
:ref:`structure-core-script`).
-To get help on the tool, use the following command:
-::
+To get help on the tool, use the following command::
$ recipetool -h
NOTE: Starting bitbake server...
@@ -1166,8 +1136,7 @@
Following are some syntax examples:
- Use this syntax to generate a recipe based on source. Once generated,
- the recipe resides in the existing source code layer:
- ::
+ the recipe resides in the existing source code layer::
recipetool create -o OUTFILE source
@@ -1180,8 +1149,7 @@
- Use this syntax to generate a recipe based on source. The options
direct ``recipetool`` to generate debugging information. Once generated,
- the recipe resides in the existing source code layer:
- ::
+ the recipe resides in the existing source code layer::
recipetool create -d -o OUTFILE source
@@ -1236,8 +1204,7 @@
recipe through the layer's ``conf/layer.conf`` file and the
:term:`BBFILES` variable. This
variable sets up a path from which the build system can locate
- recipes. Here is the typical use:
- ::
+ recipes. Here is the typical use::
BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
@@ -1249,8 +1216,7 @@
":ref:`dev-manual/common-tasks:understanding and creating layers`" section.
- *Naming Your Recipe:* When you name your recipe, you need to follow
- this naming convention:
- ::
+ this naming convention::
basename_version.bb
@@ -1276,8 +1242,7 @@
:ref:`structure-core-script`) and you are in
the :term:`Build Directory`, use
BitBake to process your recipe. All you need to provide is the
-``basename`` of the recipe as described in the previous section:
-::
+``basename`` of the recipe as described in the previous section::
$ bitbake basename
@@ -1289,8 +1254,7 @@
The path to the per-recipe temporary work directory depends on the
context in which it is being built. The quickest way to find this path
-is to have BitBake return it by running the following:
-::
+is to have BitBake return it by running the following::
$ bitbake -e basename | grep ^WORKDIR=
@@ -1299,8 +1263,7 @@
``poky/build``, and a ``qemux86-poky-linux`` machine target system.
Furthermore, suppose your recipe is named ``foo_1.3.0.bb``. In this
case, the work directory the build system uses to build the package
-would be as follows:
-::
+would be as follows::
poky/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0
@@ -1352,8 +1315,7 @@
Here is a simple example from the
``meta/recipes-devtools/strace/strace_5.5.bb`` recipe where the source
comes from a single tarball. Notice the use of the
-:term:`PV` variable:
-::
+:term:`PV` variable::
SRC_URI = "https://strace.io/files/${PV}/strace-${PV}.tar.xz \
@@ -1369,8 +1331,7 @@
you should specify :term:`PV` to include
the revision with :term:`SRCPV`. Here
is an example from the recipe
-``meta/recipes-kernel/blktrace/blktrace_git.bb``:
-::
+``meta/recipes-kernel/blktrace/blktrace_git.bb``::
SRCREV = "d6918c8832793b4205ed3bfede78c2f915c23385"
@@ -1392,8 +1353,7 @@
each URL. For these cases, you provide a name for each URL as part of
the ``SRC_URI`` and then reference that name in the subsequent checksum
statements. Here is an example combining lines from the files
-``git.inc`` and ``git_2.24.1.bb``:
-::
+``git.inc`` and ``git_2.24.1.bb``::
SRC_URI = "${KERNELORG_MIRROR}/software/scm/git/git-${PV}.tar.gz;name=tarball \
${KERNELORG_MIRROR}/software/scm/git/git-manpages-${PV}.tar.gz;name=manpages"
@@ -1512,8 +1472,7 @@
include ``COPYING``, ``LICENSE``, and ``README`` files. You could
also find the information near the top of a source file. For example,
given a piece of software licensed under the GNU General Public
- License version 2, you would set ``LICENSE`` as follows:
- ::
+ License version 2, you would set ``LICENSE`` as follows::
LICENSE = "GPLv2"
@@ -1543,8 +1502,7 @@
See the ":ref:`dev-manual/common-tasks:fetching code`" section for
additional information.
- Here is an example that assumes the software has a ``COPYING`` file:
- ::
+ Here is an example that assumes the software has a ``COPYING`` file::
LIC_FILES_CHKSUM = "file://COPYING;md5=xxx"
@@ -1747,8 +1705,7 @@
When you use custom kernel headers you need to get them from
:term:`STAGING_KERNEL_DIR`,
which is the directory with kernel headers that are required to build
-out-of-tree modules. Your recipe will also need the following:
-::
+out-of-tree modules. Your recipe will also need the following::
do_configure[depends] += "virtual/kernel:do_shared_workdir"
@@ -1779,8 +1736,7 @@
To fix the problem, you need to either satisfy the missing dependency
in the Makefile or whatever script produced the Makefile, or (as a
- workaround) set :term:`PARALLEL_MAKE` to an empty string:
- ::
+ workaround) set :term:`PARALLEL_MAKE` to an empty string::
PARALLEL_MAKE = ""
@@ -1889,8 +1845,7 @@
missing dependencies between targets that can result in race
conditions. If you experience intermittent failures during
``do_install``, you might be able to work around them by disabling
- parallel Makefile installs by adding the following to the recipe:
- ::
+ parallel Makefile installs by adding the following to the recipe::
PARALLEL_MAKEINST = ""
@@ -2006,8 +1961,7 @@
:term:`MACHINE` value is passed
into the configure script or a patch is applied only for a particular
machine), you should mark them as such by adding the following to the
- recipe:
- ::
+ recipe::
PACKAGE_ARCH = "${MACHINE_ARCH}"
@@ -2016,8 +1970,7 @@
all (e.g. recipes that simply package script files or configuration
files), you should use the
:ref:`allarch <ref-classes-allarch>` class to
- do this for you by adding this to your recipe:
- ::
+ do this for you by adding this to your recipe::
inherit allarch
@@ -2061,8 +2014,7 @@
:term:`SYSROOT_DIRS` variable to automatically populate the sysroot. It
is possible to modify the list of directories that populate the sysroot.
The following example shows how you could add the ``/opt`` directory to
-the list of directories within a recipe:
-::
+the list of directories within a recipe::
SYSROOT_DIRS += "/opt"
@@ -2091,8 +2043,7 @@
in some way uses a :term:`PROVIDES`
statement that essentially identifies itself as being able to provide
``virtual/kernel``. Here is one way through the
-:ref:`kernel <ref-classes-kernel>` class:
-::
+:ref:`kernel <ref-classes-kernel>` class::
PROVIDES += "${@ "virtual/kernel" if (d.getVar("KERNEL_PACKAGE_NAME") == "kernel") else "" }"
@@ -2107,8 +2058,7 @@
</poky/tree/meta/conf/machine/include/x86-base.inc>` include file, which is a
machine (i.e. :term:`MACHINE`) configuration file. This include file is the
reason all x86-based machines use the ``linux-yocto`` kernel. Here are the
-relevant lines from the include file:
-::
+relevant lines from the include file::
PREFERRED_PROVIDER_virtual/kernel ??= "linux-yocto"
PREFERRED_VERSION_linux-yocto ??= "4.15%"
@@ -2116,8 +2066,7 @@
When you use a virtual provider, you do not have to "hard code" a recipe
name as a build dependency. You can use the
:term:`DEPENDS` variable to state the
-build is dependent on ``virtual/kernel`` for example:
-::
+build is dependent on ``virtual/kernel`` for example::
DEPENDS = "virtual/kernel"
@@ -2125,8 +2074,7 @@
the correct recipe needed for the ``virtual/kernel`` dependency based on
the ``PREFERRED_PROVIDER`` variable. If you want to use the small kernel
mentioned at the beginning of this section, configure your build as
-follows:
-::
+follows::
PREFERRED_PROVIDER_virtual/kernel ??= "kernel-small"
@@ -2178,8 +2126,7 @@
convention is to set :term:`PV` within the
recipe to "previous_version+current_version". You can use an additional
variable so that you can use the current version elsewhere. Here is an
-example:
-::
+example::
REALPV = "0.8.16-rc1"
PV = "0.8.15+${REALPV}"
@@ -2198,8 +2145,7 @@
``${``\ :term:`PN`\ ``}`` in place of
PACKAGENAME.
-A post-installation function has the following structure:
-::
+A post-installation function has the following structure::
pkg_postinst_PACKAGENAME() {
# Commands to carry out
@@ -2352,13 +2298,11 @@
Some applications might require extra parameters to be passed to the
compiler. For example, the application might need an additional header
path. You can accomplish this by adding to the ``CFLAGS`` variable. The
-following example shows this:
-::
+following example shows this::
CFLAGS_prepend = "-I ${S}/include "
-In the following example, ``mtd-utils`` is a makefile-based package:
-::
+In the following example, ``mtd-utils`` is a makefile-based package::
SUMMARY = "Tools for managing memory technology devices"
SECTION = "base"
@@ -2403,8 +2347,7 @@
Following is an example that uses the ``libxpm`` recipe. By default,
this recipe generates a single package that contains the library along
with a few binaries. You can modify the recipe to split the binaries
-into separate packages:
-::
+into separate packages::
require xorg-lib-common.inc
@@ -2498,8 +2441,7 @@
that replaces ``do_configure`` and ``do_compile`` with custom
versions, then you can use the
``[``\ :ref:`noexec <bitbake-user-manual/bitbake-user-manual-metadata:variable flags>`\ ``]``
- flag to turn the tasks into no-ops, as follows:
- ::
+ flag to turn the tasks into no-ops, as follows::
do_configure[noexec] = "1"
do_compile[noexec] = "1"
@@ -2558,8 +2500,7 @@
supported.
The following example shows some of the ways you can use variables in
- recipes:
- ::
+ recipes::
S = "${WORKDIR}/postfix-${PV}"
CFLAGS += "-DNO_ASM"
@@ -2572,8 +2513,7 @@
syntax, although access to OpenEmbedded variables and internal
methods are also available.
- The following is an example function from the ``sed`` recipe:
- ::
+ The following is an example function from the ``sed`` recipe::
do_install () {
autotools_do_install
@@ -2594,16 +2534,14 @@
from other files (``include`` and ``require``) and export variables
to the environment (``export``).
- The following example shows the use of some of these keywords:
- ::
+ The following example shows the use of some of these keywords::
export POSTCONF = "${STAGING_BINDIR}/postconf"
inherit autoconf
require otherfile.inc
- *Comments (#):* Any lines that begin with the hash character (``#``)
- are treated as comment lines and are ignored:
- ::
+ are treated as comment lines and are ignored::
# This is a comment
@@ -2615,8 +2553,7 @@
- *Line Continuation (\\):* Use the backward slash (``\``) character to
split a statement over multiple lines. Place the slash character at
- the end of the line that is to be continued on the next line:
- ::
+ the end of the line that is to be continued on the next line::
VAR = "A really long \
line"
@@ -2627,8 +2564,7 @@
slash character.
- *Using Variables (${VARNAME}):* Use the ``${VARNAME}`` syntax to
- access the contents of a variable:
- ::
+ access the contents of a variable::
SRC_URI = "${SOURCEFORGE_MIRROR}/libpng/zlib-${PV}.tar.gz"
@@ -2648,8 +2584,7 @@
when you make the assignment, but this is not generally needed.
- *Quote All Assignments ("value"):* Use double quotes around values in
- all variable assignments (e.g. ``"value"``). Following is an example:
- ::
+ all variable assignments (e.g. ``"value"``). Following is an example::
VAR1 = "${OTHERVAR}"
VAR2 = "The version is ${PV}"
@@ -2663,13 +2598,11 @@
Here is an example where ``VAR1`` is set to "New value" if it is
currently empty. However, if ``VAR1`` has already been set, it
- remains unchanged:
- ::
+ remains unchanged::
VAR1 ?= "New value"
- In this next example, ``VAR1`` is left with the value "Original value":
- ::
+ In this next example, ``VAR1`` is left with the value "Original value"::
VAR1 = "Original value"
VAR1 ?= "New value"
@@ -2682,8 +2615,7 @@
This operator adds a space between the existing content of the
variable and the new content.
- Here is an example:
- ::
+ Here is an example::
SRC_URI += "file://fix-makefile.patch"
@@ -2695,8 +2627,7 @@
This operator adds a space between the new content and the
existing content of the variable.
- Here is an example:
- ::
+ Here is an example::
VAR =+ "Starts"
@@ -2708,15 +2639,13 @@
The following example shows the space being explicitly added to the
start to ensure the appended value is not merged with the existing
- value:
- ::
+ value::
SRC_URI_append = " file://fix-makefile.patch"
You can also use
the ``_append`` operator with overrides, which results in the actions
- only being performed for the specified target or machine:
- ::
+ only being performed for the specified target or machine::
SRC_URI_append_sh4 = " file://fix-makefile.patch"
@@ -2728,15 +2657,13 @@
The following example shows the space being explicitly added to the
end to ensure the prepended value is not merged with the existing
- value:
- ::
+ value::
CFLAGS_prepend = "-I${S}/myincludes "
You can also use the
``_prepend`` operator with overrides, which results in the actions
- only being performed for the specified target or machine:
- ::
+ only being performed for the specified target or machine::
CFLAGS_prepend_sh4 = "-I${S}/myincludes "
@@ -2746,8 +2673,7 @@
value to "standard/base" for any target
:term:`MACHINE`, except for
qemuarm where it should be set to "standard/arm-versatile-926ejs",
- you would do the following:
- ::
+ you would do the following::
KBRANCH = "standard/base"
KBRANCH_qemuarm = "standard/arm-versatile-926ejs"
@@ -2770,8 +2696,7 @@
search and replacement on a variable).
You indicate Python code using the ``${@python_code}`` syntax for the
- variable assignment:
- ::
+ variable assignment::
SRC_URI = "ftp://ftp.info-zip.org/pub/infozip/src/zip${@d.getVar('PV',1).replace('.', '')}.tgz
@@ -2861,8 +2786,7 @@
a location similar to ``defconfig`` files used for other machines in a
given kernel recipe. A possible way to do this is by listing the file in
the ``SRC_URI`` and adding the machine to the expression in
-``COMPATIBLE_MACHINE``:
-::
+``COMPATIBLE_MACHINE``::
COMPATIBLE_MACHINE = '(qemux86|qemumips)'
@@ -2889,8 +2813,7 @@
defaults, see the ``meta/recipes-bsp/formfactor/files/config`` file
found in the same area.
-Following is an example for "qemuarm" machine:
-::
+Following is an example for "qemuarm" machine::
HAVE_TOUCHSCREEN=1
HAVE_KEYBOARD=1
@@ -2961,22 +2884,19 @@
2. *Make Sure Git is Configured:* The AUH utility requires Git to be
configured because AUH uses Git to save upgrades. Thus, you must have
Git user and email configured. The following command shows your
- configurations:
- ::
+ configurations::
$ git config --list
If you do not have the user and
- email configured, you can use the following commands to do so:
- ::
+ email configured, you can use the following commands to do so::
$ git config --global user.name some_name
$ git config --global user.email username@domain.com
3. *Clone the AUH Repository:* To use AUH, you must clone the repository
onto your development host. The following command uses Git to create
- a local copy of the repository on your system:
- ::
+ a local copy of the repository on your system::
$ git clone git://git.yoctoproject.org/auto-upgrade-helper
Cloning into 'auto-upgrade-helper'... remote: Counting objects: 768, done.
@@ -2992,8 +2912,7 @@
4. *Create a Dedicated Build Directory:* Run the
:ref:`structure-core-script`
script to create a fresh build directory that you use exclusively for
- running the AUH utility:
- ::
+ running the AUH utility::
$ cd poky
$ source oe-init-build-env your_AUH_build_directory
@@ -3010,8 +2929,7 @@
- If you want to enable :ref:`Build
History <dev-manual/common-tasks:maintaining build output quality>`,
which is optional, you need the following lines in the
- ``conf/local.conf`` file:
- ::
+ ``conf/local.conf`` file::
INHERIT =+ "buildhistory"
BUILDHISTORY_COMMIT = "1"
@@ -3024,23 +2942,20 @@
- If you want to enable testing through the
:ref:`testimage <ref-classes-testimage*>`
class, which is optional, you need to have the following set in
- your ``conf/local.conf`` file:
- ::
+ your ``conf/local.conf`` file::
INHERIT += "testimage"
.. note::
If your distro does not enable by default ptest, which Poky
- does, you need the following in your ``local.conf`` file:
- ::
+ does, you need the following in your ``local.conf`` file::
DISTRO_FEATURES_append = " ptest"
6. *Optionally Start a vncserver:* If you are running in a server
- without an X11 session, you need to start a vncserver:
- ::
+ without an X11 session, you need to start a vncserver::
$ vncserver :1
$ export DISPLAY=:1
@@ -3064,45 +2979,38 @@
This next set of examples describes how to use the AUH:
- *Upgrading a Specific Recipe:* To upgrade a specific recipe, use the
- following form:
- ::
+ following form::
$ upgrade-helper.py recipe_name
- For example, this command upgrades the ``xmodmap`` recipe:
- ::
+ For example, this command upgrades the ``xmodmap`` recipe::
$ upgrade-helper.py xmodmap
- *Upgrading a Specific Recipe to a Particular Version:* To upgrade a
- specific recipe to a particular version, use the following form:
- ::
+ specific recipe to a particular version, use the following form::
$ upgrade-helper.py recipe_name -t version
- For example, this command upgrades the ``xmodmap`` recipe to version 1.2.3:
- ::
+ For example, this command upgrades the ``xmodmap`` recipe to version 1.2.3::
$ upgrade-helper.py xmodmap -t 1.2.3
- *Upgrading all Recipes to the Latest Versions and Suppressing Email
Notifications:* To upgrade all recipes to their most recent versions
- and suppress the email notifications, use the following command:
- ::
+ and suppress the email notifications, use the following command::
$ upgrade-helper.py all
- *Upgrading all Recipes to the Latest Versions and Send Email
Notifications:* To upgrade all recipes to their most recent versions
and send email messages to maintainers for each attempted recipe as
- well as a status email, use the following command:
- ::
+ well as a status email, use the following command::
$ upgrade-helper.py -e all
Once you have run the AUH utility, you can find the results in the AUH
-build directory:
-::
+build directory::
${BUILDDIR}/upgrade-helper/timestamp
@@ -3127,15 +3035,13 @@
Software Development Kit (eSDK) Manual.
To see all the command-line options available with ``devtool upgrade``,
-use the following help command:
-::
+use the following help command::
$ devtool upgrade -h
If you want to find out what version a recipe is currently at upstream
without any attempt to upgrade your local version of the recipe, you can
-use the following command:
-::
+use the following command::
$ devtool latest-version recipe_name
@@ -3161,15 +3067,13 @@
":ref:`bitbake-layers <bsp-guide/bsp:creating a new bsp layer using the \`\`bitbake-layers\`\` script>`"
script. For example, suppose you use the ``nano.bb`` recipe from the
``meta-oe`` layer in the ``meta-openembedded`` repository. For this
-example, assume that the layer has been cloned into following area:
-::
+example, assume that the layer has been cloned into following area::
/home/scottrif/meta-openembedded
The following command from your
:term:`Build Directory` adds the layer to
-your build configuration (i.e. ``${BUILDDIR}/conf/bblayers.conf``):
-::
+your build configuration (i.e. ``${BUILDDIR}/conf/bblayers.conf``)::
$ bitbake-layers add-layer /home/scottrif/meta-openembedded/meta-oe
NOTE: Starting bitbake server...
@@ -3210,8 +3114,7 @@
NOTE: New recipe is /home/scottrif/poky/build/workspace/recipes/nano/nano_2.9.3.bb
Continuing with this example, you can use ``devtool build`` to build the
-newly upgraded recipe:
-::
+newly upgraded recipe::
$ devtool build nano
NOTE: Starting bitbake server...
@@ -3236,8 +3139,7 @@
Once the tree is clean, you can clean things up in this example with the
following command from the ``${BUILDDIR}/workspace/sources/nano``
-directory:
-::
+directory::
$ devtool finish nano meta-oe
NOTE: Starting bitbake server...
@@ -3341,8 +3243,7 @@
:term:`S` variable. Below is the default
value for the ``S`` variable as defined in the
``meta/conf/bitbake.conf`` configuration file in the
-:term:`Source Directory`:
-::
+:term:`Source Directory`::
S = "${WORKDIR}/${BP}"
@@ -3353,16 +3254,14 @@
.. note::
The :term:`BP` represents the base recipe name, which consists of the name
- and version:
- ::
+ and version::
BP = "${BPN}-${PV}"
The path to the work directory for the recipe
(:term:`WORKDIR`) is defined as
-follows:
-::
+follows::
${TMPDIR}/work/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}
@@ -3388,8 +3287,7 @@
``poky``, a default Build Directory at ``poky/build``, and a
``qemux86-poky-linux`` machine target system. Furthermore, suppose your
recipe is named ``foo_1.3.0.bb``. In this case, the work directory the
-build system uses to build the package would be as follows:
-::
+build system uses to build the package would be as follows::
poky/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0
@@ -3426,15 +3324,13 @@
3. *Create a New Patch:* Before modifying source code, you need to
create a new patch. To create a new patch file, use ``quilt new`` as
- below:
- ::
+ below::
$ quilt new my_changes.patch
4. *Notify Quilt and Add Files:* After creating the patch, you need to
notify Quilt about the files you plan to edit. You notify Quilt by
- adding the files to the patch you just created:
- ::
+ adding the files to the patch you just created::
$ quilt add file1.c file2.c file3.c
@@ -3443,8 +3339,7 @@
6. *Test Your Changes:* Once you have modified the source code, the
easiest way to test your changes is by calling the ``do_compile``
- task as shown in the following example:
- ::
+ task as shown in the following example::
$ bitbake -c compile -f package
@@ -3481,8 +3376,7 @@
that holds the recipe (``.bb``) file or the append (``.bbappend``)
file. Placing the patch here guarantees that the OpenEmbedded build
system will find the patch. Next, add the patch into the ``SRC_URI``
- of the recipe. Here is an example:
- ::
+ of the recipe. Here is an example::
SRC_URI += "file://my_changes.patch"
@@ -3503,8 +3397,7 @@
be used with the OpenEmbedded build system.
Following is an example that uses ``devshell`` on a target named
-``matchbox-desktop``:
-::
+``matchbox-desktop``::
$ bitbake matchbox-desktop -c devshell
@@ -3533,8 +3426,7 @@
directory (e.g., ``run.do_configure.``\ `pid`). If a task's script does
not exist, which would be the case if the task was skipped by way of the
sstate cache, you can create the task by first running it outside of the
-``devshell``:
-::
+``devshell``::
$ bitbake -c task
@@ -3581,8 +3473,7 @@
Python objects and code are available in the same way they are to
BitBake tasks, in particular, the data store 'd'. So, commands such as
the following are useful when exploring the data store and running
-functions:
-::
+functions::
pydevshell> d.getVar("STAGING_DIR")
'/media/build1/poky/build/tmp/sysroots'
@@ -3602,8 +3493,7 @@
OpenEmbedded build system.
Following is an example that uses ``devpyshell`` on a target named
-``matchbox-desktop``:
-::
+``matchbox-desktop``::
$ bitbake matchbox-desktop -c devpyshell
@@ -3664,8 +3554,7 @@
2. *Initialize the Build Environment:* Initialize the build environment
by sourcing the build environment script (i.e.
- :ref:`structure-core-script`):
- ::
+ :ref:`structure-core-script`)::
$ source oe-init-build-env [build_dir]
@@ -3690,8 +3579,7 @@
and a centralized tarball download directory through the
:term:`DL_DIR` variable.
-4. *Build the Image:* Build the image using the ``bitbake`` command:
- ::
+4. *Build the Image:* Build the image using the ``bitbake`` command::
$ bitbake target
@@ -3710,8 +3598,7 @@
Project Reference Manual.
As an example, the following command builds the
- ``core-image-minimal`` image:
- ::
+ ``core-image-minimal`` image::
$ bitbake core-image-minimal
@@ -3763,8 +3650,7 @@
Here is an example showing the minimal statements needed in a
configuration file for a "qemux86" target whose temporary build
- directory is ``tmpmultix86``:
- ::
+ directory is ``tmpmultix86``::
MACHINE = "qemux86"
TMPDIR = "${TOPDIR}/tmpmultix86"
@@ -3789,8 +3675,7 @@
variable in your ``conf/local.conf`` configuration file to specify
each multiconfig. Continuing with the example from the previous
figure, the ``BBMULTICONFIG`` variable needs to enable two
- multiconfigs: "x86" and "arm" by specifying each configuration file:
- ::
+ multiconfigs: "x86" and "arm" by specifying each configuration file::
BBMULTICONFIG = "x86 arm"
@@ -3804,13 +3689,11 @@
with "".
- *Launch BitBake*: Use the following BitBake command form to launch
- the multiple configuration build:
- ::
+ the multiple configuration build::
$ bitbake [mc:multiconfigname:]target [[[mc:multiconfigname:]target] ... ]
- For the example in this section, the following command applies:
- ::
+ For the example in this section, the following command applies::
$ bitbake mc:x86:core-image-minimal mc:arm:core-image-sato mc::core-image-base
@@ -3844,15 +3727,13 @@
To enable dependencies in a multiple configuration build, you must
declare the dependencies in the recipe using the following statement
-form:
-::
+form::
task_or_package[mcdepends] = "mc:from_multiconfig:to_multiconfig:recipe_name:task_on_which_to_depend"
To better show how to use this statement, consider the example scenario
from the first paragraph of this section. The following statement needs
-to be added to the recipe that builds the ``core-image-sato`` image:
-::
+to be added to the recipe that builds the ``core-image-sato`` image::
do_image[mcdepends] = "mc:x86:arm:core-image-minimal:do_rootfs"
@@ -3862,8 +3743,7 @@
with the "arm" multiconfig.
Once you set up this dependency, you can build the "x86" multiconfig
-using a BitBake command as follows:
-::
+using a BitBake command as follows::
$ bitbake mc:x86:core-image-sato
@@ -3874,8 +3754,7 @@
Having a recipe depend on the root filesystem of another build might not
seem that useful. Consider this change to the statement in the
-``core-image-sato`` recipe:
-::
+``core-image-sato`` recipe::
do_image[mcdepends] = "mc:x86:arm:core-image-minimal:do_image"
@@ -4091,8 +3970,7 @@
filesystem itself or select a different filesystem.
First, find out what is hogging your root filesystem by running the
-``dirsize.py`` script from your root directory:
-::
+``dirsize.py`` script from your root directory::
$ cd root-directory-of-image
$ dirsize.py 100000 > dirsize-100k.log
@@ -4107,8 +3985,7 @@
You need to be sure that what you eliminate does not cripple the
functionality you need. One way to see how packages relate to each other
-is by using the Dependency Explorer UI with the BitBake command:
-::
+is by using the Dependency Explorer UI with the BitBake command::
$ cd image-directory
$ bitbake -u taskexp -g image
@@ -4124,8 +4001,7 @@
Use your ``local.conf`` file to make changes. For example, to eliminate
``udev`` and ``glib``, set the following in the local configuration
-file:
-::
+file::
VIRTUAL-RUNTIME_dev_manager = ""
@@ -4153,8 +4029,7 @@
You can modify the kernel source if you want to help with boot time.
Run the ``ksize.py`` script from the top-level Linux build directory to
-get an idea of what is making up the kernel:
-::
+get an idea of what is making up the kernel::
$ cd top-level-linux-build-directory
$ ksize.py > ksize.log
@@ -4168,8 +4043,7 @@
and taking up around the "90% rule."
To examine, or drill down, into any particular area, use the ``-d``
-option with the script:
-::
+option with the script::
$ ksize.py -d > ksize.log
@@ -4316,8 +4190,7 @@
machine-architecture dependent, make sure your recipe enables the
"machine" package architecture through the
:term:`MACHINE_ARCH`
- variable:
- ::
+ variable::
PACKAGE_ARCH = "${MACHINE_ARCH}"
@@ -4325,8 +4198,7 @@
specifically enable a package architecture through the
:term:`PACKAGE_ARCH`, The
OpenEmbedded build system defaults to the
- :term:`TUNE_PKGARCH` setting:
- ::
+ :term:`TUNE_PKGARCH` setting::
PACKAGE_ARCH = "${TUNE_PKGARCH}"
@@ -4426,15 +4298,13 @@
and then set the
:term:`EXTERNALSRC` variable to
point to your external source code. Here are the statements to put in
-your ``local.conf`` file:
-::
+your ``local.conf`` file::
INHERIT += "externalsrc"
EXTERNALSRC_pn-myrecipe = "path-to-your-source-tree"
This next example shows how to accomplish the same thing by setting
-``EXTERNALSRC`` in the recipe itself or in the recipe's append file:
-::
+``EXTERNALSRC`` in the recipe itself or in the recipe's append file::
EXTERNALSRC = "path"
EXTERNALSRC_BUILD = "path"
@@ -4451,8 +4321,7 @@
to have the source built in the same directory in which it resides, or
some other nominated directory, you can set
:term:`EXTERNALSRC_BUILD`
-to point to that directory:
-::
+to point to that directory::
EXTERNALSRC_BUILD_pn-myrecipe = "path-to-your-source-tree"
@@ -4475,8 +4344,7 @@
an empty location or one that does not yet exist.
2. *Generate Tarballs of the Source Git Repositories:* Edit your
- ``local.conf`` configuration file as follows:
- ::
+ ``local.conf`` configuration file as follows::
DL_DIR = "/home/your-download-dir/"
BB_GENERATE_MIRROR_TARBALLS = "1"
@@ -4489,8 +4357,7 @@
variable for more information.
3. *Populate Your Downloads Directory Without Building:* Use BitBake to
- fetch your sources but inhibit the build:
- ::
+ fetch your sources but inhibit the build::
$ bitbake target --runonly=fetch
@@ -4536,8 +4403,7 @@
``${``\ :term:`TMPDIR`\ ``}``
directory or using a new :term:`Build Directory`.
-3. *Build Your Target:* Use BitBake to build your target:
- ::
+3. *Build Your Target:* Use BitBake to build your target::
$ bitbake target
@@ -4550,8 +4416,7 @@
The offline build does not work if recipes attempt to find the
latest version of software by setting
:term:`SRCREV` to
- ``${``\ :term:`AUTOREV`\ ``}``:
- ::
+ ``${``\ :term:`AUTOREV`\ ``}``::
SRCREV = "${AUTOREV}"
@@ -4670,8 +4535,7 @@
- Disable static library generation for recipes derived from
``autoconf`` or ``libtool``: Following is an example showing how to
disable static libraries and still provide an override to handle
- exceptions:
- ::
+ exceptions::
STATICLIBCONF = "--disable-static"
STATICLIBCONF_sqlite3-native = ""
@@ -4726,8 +4590,7 @@
static library files through ``${PN}-dev``.
Following is part of the BitBake configuration file, where you can see
-how the static library files are defined:
-::
+how the static library files are defined::
PACKAGE_BEFORE_PN ?= ""
PACKAGES = "${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}"
@@ -4833,8 +4696,7 @@
combination of multiple libraries you want to build. You accomplish this
through your ``local.conf`` configuration file in the
:term:`Build Directory`. An example
-configuration would be as follows:
-::
+configuration would be as follows::
MACHINE = "qemux86-64"
require conf/multilib.conf
@@ -4850,14 +4712,12 @@
The example then includes ``lib32-glib-2.0`` in all the images, which
illustrates one method of including a multiple library dependency. You
-can use a normal image build to include this dependency, for example:
-::
+can use a normal image build to include this dependency, for example::
$ bitbake core-image-sato
You can also build Multilib packages
-specifically with a command like this:
-::
+specifically with a command like this::
$ bitbake lib32-glib-2.0
@@ -4952,8 +4812,7 @@
the :term:`DEPENDS` variable to
create the dependency. Continuing with the same example, if you want to
have a recipe depend on the 1.8 version of the ``clutter`` library, use
-the following in your recipe:
-::
+the following in your recipe::
DEPENDS = "clutter-1.8"
@@ -4996,8 +4855,7 @@
- Support for large images exists.
To use the x32 psABI, you need to edit your ``conf/local.conf``
-configuration file as follows:
-::
+configuration file as follows::
MACHINE = "qemux86-64"
DEFAULTTUNE = "x86-64-x32"
@@ -5006,8 +4864,7 @@
Once you have set
up your configuration file, use BitBake to build an image that supports
-the x32 psABI. Here is an example:
-::
+the x32 psABI. Here is an example::
$ bitbake core-image-sato
@@ -5066,8 +4923,7 @@
3. Try to build the recipe. If you encounter build errors that look like
something is unable to find ``.so`` libraries, check where these
libraries are located in the source tree and add the following to the
- recipe:
- ::
+ recipe::
GIR_EXTRA_LIBS_PATH = "${B}/something/.libs"
@@ -5097,8 +4953,7 @@
combination. If so, you can use either of the following methods to
disable GIR file generations:
-- Add the following to your distro configuration:
- ::
+- Add the following to your distro configuration::
DISTRO_FEATURES_BACKFILL_CONSIDERED = "gobject-introspection-data"
@@ -5106,8 +4961,7 @@
QEMU but will still enable building introspection tools and libraries
(i.e. building them does not require the use of QEMU).
-- Add the following to your machine configuration:
- ::
+- Add the following to your machine configuration::
MACHINE_FEATURES_BACKFILL_CONSIDERED = "qemu-usermode"
@@ -5140,8 +4994,7 @@
3. Launch a Terminal and then start Python in the terminal.
-4. Enter the following in the terminal:
- ::
+4. Enter the following in the terminal::
>>> from gi.repository import GLib
>>> GLib.get_host_name()
@@ -5289,8 +5142,7 @@
form generated by the OpenEmbedded build system.
- You must build several native tools, which are built to run on the
- build system:
- ::
+ build system::
$ bitbake parted-native dosfstools-native mtools-native
@@ -5306,8 +5158,7 @@
You can get general help for the ``wic`` command by entering the ``wic``
command by itself or by entering the command with a help argument as
-follows:
-::
+follows::
$ wic -h
$ wic --help
@@ -5315,32 +5166,27 @@
Currently, Wic supports seven commands: ``cp``, ``create``, ``help``,
``list``, ``ls``, ``rm``, and ``write``. You can get help for all these
-commands except "help" by using the following form:
-::
+commands except "help" by using the following form::
$ wic help command
For example, the following command returns help for the ``write``
-command:
-::
+command::
$ wic help write
Wic supports help for three topics: ``overview``, ``plugins``, and
-``kickstart``. You can get help for any topic using the following form:
-::
+``kickstart``. You can get help for any topic using the following form::
$ wic help topic
-For example, the following returns overview help for Wic:
-::
+For example, the following returns overview help for Wic::
$ wic help overview
One additional level of help exists for Wic. You can get help on
individual images through the ``list`` command. You can use the ``list``
-command to return the available Wic images as follows:
-::
+command to return the available Wic images as follows::
$ wic list images
genericx86 Create an EFI disk image for genericx86*
@@ -5359,8 +5205,7 @@
Once you know the list of available
Wic images, you can use ``help`` with the command to get help on a
particular image. For example, the following command returns help on the
-"beaglebone-yocto" image:
-::
+"beaglebone-yocto" image::
$ wic list beaglebone-yocto help
@@ -5397,8 +5242,7 @@
Contrast this behavior with cooked mode where Wic looks in the Build
Directory (e.g. ``tmp/deploy/images/``\ machine).
-The general form of the ``wic`` command in raw mode is:
-::
+The general form of the ``wic`` command in raw mode is::
$ wic create wks_file options ...
@@ -5456,8 +5300,7 @@
by using the "-e" option. Wic looks in the Build Directory (e.g.
``tmp/deploy/images/``\ machine) for artifacts.
-The general form of the ``wic`` command using Cooked Mode is as follows:
-::
+The general form of the ``wic`` command using Cooked Mode is as follows::
$ wic create wks_file -e IMAGE_NAME
@@ -5480,14 +5323,12 @@
If you do not want to create your own kickstart file, you can use an
existing file provided by the Wic installation. As shipped, kickstart
files can be found in the :ref:`overview-manual/development-environment:yocto project source repositories` in the
-following two locations:
-::
+following two locations::
poky/meta-yocto-bsp/wic
poky/scripts/lib/wic/canned-wks
-Use the following command to list the available kickstart files:
-::
+Use the following command to list the available kickstart files::
$ wic list images
genericx86 Create an EFI disk image for genericx86*
@@ -5505,15 +5346,13 @@
When you use an existing file, you
do not have to use the ``.wks`` extension. Here is an example in Raw
-Mode that uses the ``directdisk`` file:
-::
+Mode that uses the ``directdisk`` file::
$ wic create directdisk -r rootfs_dir -b bootimg_dir \
-k kernel_dir -n native_sysroot
Here are the actual partition language commands used in the
-``genericx86.wks`` file to generate an image:
-::
+``genericx86.wks`` file to generate an image::
# short-description: Create an EFI disk image for genericx86*
# long-description: Creates a partitioned EFI disk image for genericx86* machines
@@ -5571,8 +5410,7 @@
implementation, it looks for the plugin with the same name as the
``--source`` parameter used in the kickstart file given to that
partition. For example, if the partition is set up using the following
-command in a kickstart file:
-::
+command in a kickstart file::
part /boot --source bootimg-pcbios --ondisk sda --label boot --active --align 1024
@@ -5583,8 +5421,7 @@
To be more concrete, here is the corresponding plugin definition from
the ``bootimg-pcbios.py`` file for the previous command along with an
example method called by the Wic implementation when it needs to prepare
-a partition using an implementation-specific function:
-::
+a partition using an implementation-specific function::
.
.
@@ -5675,8 +5512,7 @@
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This example runs in Cooked Mode and uses the ``mkefidisk`` kickstart
-file:
-::
+file::
$ wic create mkefidisk -e core-image-minimal
INFO: Building wic-tools...
@@ -5712,8 +5548,7 @@
Continuing with the example, you can now write the image from the Build
Directory onto a USB stick, or whatever media for which you built your
image, and boot from the media. You can write the image by using
-``bmaptool`` or ``dd``:
-::
+``bmaptool`` or ``dd``::
$ oe-run-native bmaptool copy mkefidisk-201804191017-sda.direct /dev/sdX
@@ -5761,8 +5596,7 @@
Next, the example modifies the ``directdisksdb-gpt.wks`` file and
changes all instances of "``--ondisk sda``" to "``--ondisk sdb``". The
example changes the following two lines and leaves the remaining lines
-untouched:
-::
+untouched::
part /boot --source bootimg-pcbios --ondisk sdb --label boot --active --align 1024
part / --source rootfs --ondisk sdb --fstype=ext4 --label platform --align 1024 --use-uuid
@@ -5799,8 +5633,7 @@
Continuing with the example, you can now directly ``dd`` the image to a
USB stick, or whatever media for which you built your image, and boot
-the resulting media:
-::
+the resulting media::
$ sudo dd if=directdisksdb-gpt-201710090938-sdb.direct of=/dev/sdb
140966+0 records in
@@ -5814,8 +5647,7 @@
This next example manually specifies each build artifact (runs in Raw
Mode) and uses a modified kickstart file. The example also uses the
``-o`` option to cause Wic to create the output somewhere other than the
-default output directory, which is the current directory:
-::
+default output directory, which is the current directory::
$ wic create /home/stephano/my_yocto/test.wks -o /home/stephano/testwic \
--rootfs-dir /home/stephano/build/master/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/rootfs \
@@ -5860,8 +5692,7 @@
the existing kernel, and then inserts a new kernel:
1. *List the Partitions:* Use the ``wic ls`` command to list all the
- partitions in the Wic image:
- ::
+ partitions in the Wic image::
$ wic ls tmp/deploy/images/qemux86/core-image-minimal-qemux86.wic
Num Start End Size Fstype
@@ -5877,8 +5708,7 @@
.. note::
You can get command usage on any Wic command using the following
- form:
- ::
+ form::
$ wic help command
@@ -5886,14 +5716,12 @@
For example, the following command shows you the various ways to
use the
wic ls
- command:
- ::
+ command::
$ wic help ls
- The following command shows what is in partition one:
- ::
+ The following command shows what is in partition one::
$ wic ls tmp/deploy/images/qemux86/core-image-minimal-qemux86.wic:1
Volume in drive : is boot
@@ -5915,8 +5743,7 @@
If you see the following error, you need to update or create a
``~/.mtoolsrc`` file and be sure to have the line "mtools_skip_check=1"
- in the file. Then, run the Wic command again:
- ::
+ in the file. Then, run the Wic command again::
ERROR: _exec_cmd: /usr/bin/mdir -i /tmp/wic-parttfokuwra ::/ returned '1' instead of 0
output: Total number of sectors (47824) not a multiple of sectors per track (32)!
@@ -5924,8 +5751,7 @@
3. *Remove the Old Kernel:* Use the ``wic rm`` command to remove the
- ``vmlinuz`` file (kernel):
- ::
+ ``vmlinuz`` file (kernel)::
$ wic rm tmp/deploy/images/qemux86/core-image-minimal-qemux86.wic:1/vmlinuz
@@ -5937,8 +5763,7 @@
kernel will be in the ``workspace/sources`` area.
The following example assumes ``devtool`` was used to build the
- kernel:
- ::
+ kernel::
$ wic cp poky_sdk/tmp/work/qemux86-poky-linux/linux-yocto/4.12.12+git999-r0/linux-yocto-4.12.12+git999/arch/x86/boot/bzImage \
poky/build/tmp/deploy/images/qemux86/core-image-minimal-qemux86.wic:1/vmlinuz
@@ -5968,14 +5793,12 @@
- If you are using Ubuntu or Debian distributions, you can install
the ``bmap-tools`` package using the following command and then
use the tool without specifying ``PATH`` even from the root
- account:
- ::
+ account::
$ sudo apt-get install bmap-tools
- If you are unable to install the ``bmap-tools`` package, you will
- need to build Bmaptool before using it. Use the following command:
- ::
+ need to build Bmaptool before using it. Use the following command::
$ bitbake bmap-tools-native
@@ -5984,15 +5807,13 @@
any type of image. Use these steps to flash an image using Bmaptool:
1. *Update your local.conf File:* You need to have the following set
- in your ``local.conf`` file before building your image:
- ::
+ in your ``local.conf`` file before building your image::
IMAGE_FSTYPES += "wic wic.bmap"
2. *Get Your Image:* Either have your image ready (pre-built with the
:term:`IMAGE_FSTYPES`
- setting previously mentioned) or take the step to build the image:
- ::
+ setting previously mentioned) or take the step to build the image::
$ bitbake image
@@ -6000,20 +5821,17 @@
depending on your particular setup. The following commands assume the
image resides in the Build Directory's ``deploy/images/`` area:
- - If you have write access to the media, use this command form:
- ::
+ - If you have write access to the media, use this command form::
$ oe-run-native bmap-tools-native bmaptool copy build-directory/tmp/deploy/images/machine/image.wic /dev/sdX
- If you do not have write access to the media, set your permissions
- first and then use the same command form:
- ::
+ first and then use the same command form::
$ sudo chmod 666 /dev/sdX
$ oe-run-native bmap-tools-native bmaptool copy build-directory/tmp/deploy/images/machine/image.wic /dev/sdX
-For help on the ``bmaptool`` command, use the following command:
-::
+For help on the ``bmaptool`` command, use the following command::
$ bmaptool --help
@@ -6107,8 +5925,7 @@
Use the following line in your ``local.conf`` file or in your custom
distribution configuration file to enable the security compiler and
-linker flags for your build:
-::
+linker flags for your build::
require conf/distro/include/security_flags.inc
@@ -6123,8 +5940,7 @@
When creating a new project, the default is to provide you with an
initial ``local.conf`` file that enables this feature using the
:term:`EXTRA_IMAGE_FEATURES`
- variable with the line:
- ::
+ variable with the line::
EXTRA_IMAGE_FEATURES = "debug-tweaks"
@@ -6250,8 +6066,7 @@
:term:`DISTRO` variable to point to
your distribution's configuration file. For example, if your
distribution's configuration file is named ``mydistro.conf``, then
- you point to it as follows:
- ::
+ you point to it as follows::
DISTRO = "mydistro"
@@ -6292,8 +6107,7 @@
configuration information that ultimately ends up in the
:term:`Build Directory` ``conf`` directory.
By default, ``TEMPLATECONF`` is set as follows in the ``poky``
-repository:
-::
+repository::
TEMPLATECONF=${TEMPLATECONF:-meta-poky/conf}
@@ -6335,8 +6149,7 @@
targets appears as part of the script's output.
Here is the default list of targets displayed as a result of running
-either of the setup scripts:
-::
+either of the setup scripts::
You can now run 'bitbake <target>'
@@ -6355,8 +6168,7 @@
To help conserve disk space during builds, you can add the following
statement to your project's ``local.conf`` configuration file found in
-the :term:`Build Directory`:
-::
+the :term:`Build Directory`::
INHERIT += "rm_work"
@@ -6534,8 +6346,7 @@
development system that builds the package feed (building system). For
this scenario, you can enable a local PR Service by setting
:term:`PRSERV_HOST` in your
-``local.conf`` file in the :term:`Build Directory`:
-::
+``local.conf`` file in the :term:`Build Directory`::
PRSERV_HOST = "localhost:0"
@@ -6546,8 +6357,7 @@
If you have a more complex setup where multiple host development systems
work against a common, shared package feed, you have a single PR Service
running and it is connected to each building system. For this scenario,
-you need to start the PR Service using the ``bitbake-prserv`` command:
-::
+you need to start the PR Service using the ``bitbake-prserv`` command::
bitbake-prserv --host ip --port port --start
@@ -6559,8 +6369,7 @@
It is also recommended you use build history, which adds some sanity
checks to binary package versions, in conjunction with the server that
is running the PR Service. To enable build history, add the following to
-each building system's ``local.conf`` file:
-::
+each building system's ``local.conf`` file::
# It is recommended to activate "buildhistory" for testing the PR service
INHERIT += "buildhistory"
@@ -6629,15 +6438,13 @@
``SRCREV`` variable to
:term:`AUTOREV` to cause the
OpenEmbedded build system to automatically use the latest revision of
-the software:
-::
+the software::
SRCREV = "${AUTOREV}"
Furthermore, you need to reference ``SRCPV`` in ``PV`` in order to
automatically update the version whenever the revision of the source
-code changes. Here is an example:
-::
+code changes. Here is an example::
PV = "1.0+git${SRCPV}"
@@ -6707,8 +6514,7 @@
:term:`PACKAGES` variable and
setting the appropriate values for ``FILES_packagename``,
``RDEPENDS_packagename``, ``DESCRIPTION_packagename``, and so forth.
-Here is an example from the ``lighttpd`` recipe:
-::
+Here is an example from the ``lighttpd`` recipe::
python populate_packages_prepend () {
lighttpd_libdir = d.expand('${libdir}')
@@ -6751,8 +6557,7 @@
also find examples in ``meta/classes/kernel.bbclass``.
Following is a reference that shows ``do_split_packages`` mandatory and
-optional arguments:
-::
+optional arguments::
Mandatory arguments
@@ -6840,8 +6645,7 @@
your recipe. You can be sure these dependencies are satisfied by using
the :term:`PACKAGES_DYNAMIC`
variable. Here is an example that continues with the ``lighttpd`` recipe
-shown earlier:
-::
+shown earlier::
PACKAGES_DYNAMIC = "lighttpd-module-.*"
@@ -6933,8 +6737,7 @@
:term:`Build Directory` (e.g.
``poky/build/conf/local.conf``).
-2. Select the desired package format as follows:
- ::
+2. Select the desired package format as follows::
PACKAGE_CLASSES ?= "package_packageformat"
@@ -6968,15 +6771,13 @@
Whenever you perform any sort of build step that can potentially
generate a package or modify existing package, it is always a good idea
to re-generate the package index after the build by using the following
-command:
-::
+command::
$ bitbake package-index
It might be tempting to build the
package and the package index at the same time with a command such as
-the following:
-::
+the following::
$ bitbake some-package package-index
@@ -7024,8 +6825,7 @@
:term:`PACKAGE_CLASSES`
setting), simply start the server. The following example assumes a build
directory of ``poky/build/tmp/deploy/rpm`` and a ``PACKAGE_CLASSES``
-setting of "package_rpm":
-::
+setting of "package_rpm"::
$ cd poky/build/tmp/deploy/rpm
$ python3 -m http.server
@@ -7091,8 +6891,7 @@
architectures.
- *Create a Single (Full) Package Index:* Define a single base URL that
- identifies where a full package database is located:
- ::
+ identifies where a full package database is located::
[oe-packages]
baseurl=http://my.server/rpm
@@ -7210,8 +7009,7 @@
To enable signing RPM packages, you must set up the following
configurations in either your ``local.config`` or ``distro.config``
-file:
-::
+file::
# Inherit sign_rpm.bbclass to enable signing functionality
INHERIT += " sign_rpm"
@@ -7242,8 +7040,7 @@
The steps you need to take to enable signed package feed use are similar
to the steps used to sign RPM packages. You must define the following in
-your ``local.config`` or ``distro.config`` file:
-::
+your ``local.config`` or ``distro.config`` file::
INHERIT += "sign_package_feed"
PACKAGE_FEED_GPG_NAME = "key_name"
@@ -7282,8 +7079,7 @@
binary and checks the output to an elaborate system of test binaries and
data files.
-The test generates output in the format used by Automake:
-::
+The test generates output in the format used by Automake::
result: testname
@@ -7305,8 +7101,7 @@
:term:`DISTRO_FEATURES` and
:term:`EXTRA_IMAGE_FEATURES`
variables to your ``local.conf`` file, which is found in the
-:term:`Build Directory`:
-::
+:term:`Build Directory`::
DISTRO_FEATURES_append = " ptest"
EXTRA_IMAGE_FEATURES += "ptest-pkgs"
@@ -7331,16 +7126,14 @@
- *Be sure the recipe inherits
the* :ref:`ptest <ref-classes-ptest>` *class:*
- Include the following line in each recipe:
- ::
+ Include the following line in each recipe::
inherit ptest
- *Create run-ptest:* This script starts your test. Locate the
script where you will refer to it using
:term:`SRC_URI`. Here is an
- example that starts a test for ``dbus``:
- ::
+ example that starts a test for ``dbus``::
#!/bin/sh
cd test
@@ -7352,8 +7145,7 @@
:term:`DEPENDS` and
:term:`RDEPENDS` variables in
your recipe in order for the package to meet the dependencies. Here
- is an example where the package has a runtime dependency on "make":
- ::
+ is an example where the package has a runtime dependency on "make"::
RDEPENDS_${PN}-ptest += "make"
@@ -7374,8 +7166,7 @@
Regardless, you still must add a ``do_compile_ptest`` function to
build the test suite. Add a function similar to the following to your
- recipe:
- ::
+ recipe::
do_compile_ptest() {
oe_runmake buildtest-TESTS
@@ -7457,8 +7248,7 @@
You must know the ``cute-files`` module version.
The first thing you need to do is use ``devtool`` and the NPM fetcher to
-create the recipe:
-::
+create the recipe::
$ devtool add "npm://registry.npmjs.org;package=cute-files;version=1.0.2"
@@ -7486,8 +7276,7 @@
practical way to have the licenses for all of the dependencies
represented in the license manifest of the image.
-The ``devtool edit-recipe`` command lets you take a look at the recipe:
-::
+The ``devtool edit-recipe`` command lets you take a look at the recipe::
$ devtool edit-recipe cute-files
SUMMARY = "Turn any folder on your computer into a cute file browser, available on the local network."
@@ -7520,8 +7309,7 @@
:ref:`npm <ref-classes-npm>` class to package
up all the modules.
-You can run the following command to build the ``cute-files`` package:
-::
+You can run the following command to build the ``cute-files`` package::
$ devtool build cute-files
@@ -7529,8 +7317,7 @@
the target before your package.
Assuming 192.168.7.2 for the target's IP address, use the following
-command to deploy your package:
-::
+command to deploy your package::
$ devtool deploy-target -s cute-files root@192.168.7.2
@@ -7569,15 +7356,13 @@
source files.
Replicating the same example, (i.e. ``cute-files``) use the following
-command:
-::
+command::
$ devtool add https://github.com/martinaglv/cute-files.git
The
recipe this command generates is very similar to the recipe created in
-the previous section. However, the ``SRC_URI`` looks like the following:
-::
+the previous section. However, the ``SRC_URI`` looks like the following::
SRC_URI = " \
git://github.com/martinaglv/cute-files.git;protocol=https \
@@ -7629,8 +7414,7 @@
variable flag ``separator``.
The following is an example that adds two custom fields for ipk
-packages:
-::
+packages::
PACKAGE_ADD_METADATA_IPK = "Vendor: CustomIpk\nGroup:Applications/Spreadsheets"
@@ -7660,8 +7444,7 @@
checks local directories first for existing tarballs before checking the
Internet.
-Here is an efficient way to set it up in your ``local.conf`` file:
-::
+Here is an efficient way to set it up in your ``local.conf`` file::
SOURCE_MIRROR_URL ?= "file:///home/you/your-download-dir/"
INHERIT += "own-mirrors"
@@ -7692,8 +7475,7 @@
which is located with :term:`DL_DIR`.
Use the following BitBake command form to fetch all the necessary
-sources without starting the build:
-::
+sources without starting the build::
$ bitbake target --runall=fetch
@@ -7740,15 +7522,13 @@
Using systemd Exclusively
-------------------------
-Set these variables in your distribution configuration file as follows:
-::
+Set these variables in your distribution configuration file as follows::
DISTRO_FEATURES_append = " systemd"
VIRTUAL-RUNTIME_init_manager = "systemd"
You can also prevent the SysVinit distribution feature from
-being automatically enabled as follows:
-::
+being automatically enabled as follows::
DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
@@ -7756,8 +7536,7 @@
redundant SysVinit scripts.
To remove initscripts from your image altogether, set this variable
-also:
-::
+also::
VIRTUAL-RUNTIME_initscripts = ""
@@ -7767,8 +7546,7 @@
Using systemd for the Main Image and Using SysVinit for the Rescue Image
------------------------------------------------------------------------
-Set these variables in your distribution configuration file as follows:
-::
+Set these variables in your distribution configuration file as follows::
DISTRO_FEATURES_append = " systemd"
VIRTUAL-RUNTIME_init_manager = "systemd"
@@ -7800,8 +7578,7 @@
To use the static method for device population, you need to set the
:term:`USE_DEVFS` variable to "0"
-as follows:
-::
+as follows::
USE_DEVFS = "0"
@@ -7813,8 +7590,7 @@
variable in your ``local.conf`` configuration file.
If you do not define the ``IMAGE_DEVICE_TABLES`` variable, the default
-``device_table-minimal.txt`` is used:
-::
+``device_table-minimal.txt`` is used::
IMAGE_DEVICE_TABLES = "device_table-mymachine.txt"
@@ -7826,8 +7602,7 @@
To use the dynamic method for device population, you need to use (or be
sure to set) the :term:`USE_DEVFS`
-variable to "1", which is the default:
-::
+variable to "1", which is the default::
USE_DEVFS = "1"
@@ -7844,8 +7619,7 @@
like ``udev`` or ``busybox-mdev``. You choose the device manager by
defining the ``VIRTUAL-RUNTIME_dev_manager`` variable in your machine or
distro configuration file. Alternatively, you can set this variable in
-your ``local.conf`` configuration file:
-::
+your ``local.conf`` configuration file::
VIRTUAL-RUNTIME_dev_manager = "udev"
@@ -7866,14 +7640,12 @@
To enable this behavior, the :term:`PV` of
the recipe needs to reference
-:term:`SRCPV`. Here is an example:
-::
+:term:`SRCPV`. Here is an example::
PV = "1.2.3+git${SRCPV}"
Then, you can add the following to your
-``local.conf``:
-::
+``local.conf``::
SRCREV_pn-PN = "${AUTOREV}"
@@ -7881,20 +7653,17 @@
which you want to enable automatic source revision updating.
If you do not want to update your local configuration file, you can add
-the following directly to the recipe to finish enabling the feature:
-::
+the following directly to the recipe to finish enabling the feature::
SRCREV = "${AUTOREV}"
The Yocto Project provides a distribution named ``poky-bleeding``, whose
-configuration file contains the line:
-::
+configuration file contains the line::
require conf/distro/include/poky-floating-revisions.inc
This line pulls in the
-listed include file that contains numerous lines of exactly that form:
-::
+listed include file that contains numerous lines of exactly that form::
#SRCREV_pn-opkg-native ?= "${AUTOREV}"
#SRCREV_pn-opkg-sdk ?= "${AUTOREV}"
@@ -7946,15 +7715,13 @@
To create the read-only root filesystem, simply add the
"read-only-rootfs" feature to your image, normally in one of two ways.
The first way is to add the "read-only-rootfs" image feature in the
-image's recipe file via the ``IMAGE_FEATURES`` variable:
-::
+image's recipe file via the ``IMAGE_FEATURES`` variable::
IMAGE_FEATURES += "read-only-rootfs"
As an alternative, you can add the same feature
from within your build directory's ``local.conf`` file with the
-associated ``EXTRA_IMAGE_FEATURES`` variable, as in:
-::
+associated ``EXTRA_IMAGE_FEATURES`` variable, as in::
EXTRA_IMAGE_FEATURES = "read-only-rootfs"
@@ -8051,8 +7818,7 @@
``INHERIT`` statement and set the
:term:`BUILDHISTORY_COMMIT`
variable to "1" at the end of your ``conf/local.conf`` file found in the
-:term:`Build Directory`:
-::
+:term:`Build Directory`::
INHERIT += "buildhistory"
BUILDHISTORY_COMMIT = "1"
@@ -8140,8 +7906,7 @@
:term:`SRCREV` is set to
${:term:`AUTOREV`}. Here is an
example assuming
-``buildhistory/packages/qemux86-poky-linux/linux-yocto/latest_srcrev``):
-::
+``buildhistory/packages/qemux86-poky-linux/linux-yocto/latest_srcrev``)::
# SRCREV_machine = "38cd560d5022ed2dbd1ab0dca9642e47c98a0aa1"
SRCREV_machine = "38cd560d5022ed2dbd1ab0dca9642e47c98a0aa1"
@@ -8154,8 +7919,7 @@
in a format suitable for use in global configuration (e.g.,
``local.conf`` or a distro include file) to override floating
``AUTOREV`` values to a fixed set of revisions. Here is some example
-output from this command:
-::
+output from this command::
$ buildhistory-collect-srcrevs -a
# i586-poky-linux
@@ -8270,8 +8034,7 @@
in collecting specific package or SDK information, you can enable
writing only image information without any history by adding the
following to your ``conf/local.conf`` file found in the
-:term:`Build Directory`:
-::
+:term:`Build Directory`::
INHERIT += "buildhistory"
BUILDHISTORY_COMMIT = "0"
@@ -8370,8 +8133,7 @@
To see any changes that have occurred (assuming you have
:term:`BUILDHISTORY_COMMIT` = "1"),
you can simply use any Git command that allows you to view the history
-of a repository. Here is one method:
-::
+of a repository. Here is one method::
$ git log -p
@@ -8381,8 +8143,7 @@
A command-line tool called ``buildhistory-diff`` does exist, though,
that queries the Git repository and prints just the differences that
-might be significant in human-readable form. Here is an example:
-::
+might be significant in human-readable form. Here is an example::
$ poky/poky/scripts/buildhistory-diff . HEAD^
Changes to images/qemux86_64/glibc/core-image-minimal (files-in-image.txt):
@@ -8402,8 +8163,7 @@
.. note::
The ``buildhistory-diff`` tool requires the ``GitPython``
- package. Be sure to install it using Pip3 as follows:
- ::
+ package. Be sure to install it using Pip3 as follows::
$ pip3 install GitPython --user
@@ -8473,8 +8233,7 @@
with sudo.
- The package recipe ``qemu-helper-native`` is required to run
- this script. Build the package using the following command:
- ::
+ this script. Build the package using the following command::
$ bitbake qemu-helper-native
@@ -8609,8 +8368,7 @@
If you did set ``TEST_TARGET`` to "SystemdbootTarget", you also need to
perform a one-time setup of your master image by doing the following:
-1. *Set EFI_PROVIDER:* Be sure that ``EFI_PROVIDER`` is as follows:
- ::
+1. *Set EFI_PROVIDER:* Be sure that ``EFI_PROVIDER`` is as follows::
EFI_PROVIDER = "systemd-boot"
@@ -8648,16 +8406,14 @@
"SystemdbootTarget" is to set up the test image:
1. *Set up your local.conf file:* Make sure you have the following
- statements in your ``local.conf`` file:
- ::
+ statements in your ``local.conf`` file::
IMAGE_FSTYPES += "tar.gz"
INHERIT += "testimage"
TEST_TARGET = "SystemdbootTarget"
TEST_TARGET_IP = "192.168.2.3"
-2. *Build your test image:* Use BitBake to build the image:
- ::
+2. *Build your test image:* Use BitBake to build the image::
$ bitbake core-image-sato
@@ -8671,8 +8427,7 @@
``TEST_POWERCONTROL_EXTRA_ARGS`` as a command that runs on the host
and does power cycling. The test code passes one argument to that
command: off, on or cycle (off then on). Here is an example that
- could appear in your ``local.conf`` file:
- ::
+ could appear in your ``local.conf`` file::
TEST_POWERCONTROL_CMD = "powercontrol.exp test 10.11.12.1 nuc1"
@@ -8705,8 +8460,7 @@
the required power action. This script requires either KDialog or Zenity
to be installed. To use this script, set the
:term:`TEST_POWERCONTROL_CMD`
-variable as follows:
-::
+variable as follows::
TEST_POWERCONTROL_CMD = "${COREBASE}/scripts/contrib/dialog-power-control"
@@ -8728,8 +8482,7 @@
command simply needs to connect to the serial console and forward that
connection to standard input and output as any normal terminal program
does. For example, to use the picocom terminal program on serial device
-``/dev/ttyUSB0`` at 115200bps, you would set the variable as follows:
-::
+``/dev/ttyUSB0`` at 115200bps, you would set the variable as follows::
TEST_SERIALCONTROL_CMD = "picocom /dev/ttyUSB0 -b 115200"
@@ -8737,8 +8490,7 @@
devices where the serial port device disappears when the device reboots,
an additional "serdevtry" wrapper script is provided. To use this
wrapper, simply prefix the terminal command with
-``${COREBASE}/scripts/contrib/serdevtry``:
-::
+``${COREBASE}/scripts/contrib/serdevtry``::
TEST_SERIALCONTROL_CMD = "${COREBASE}/scripts/contrib/serdevtry picocom -b 115200 /dev/ttyUSB0"
@@ -8752,27 +8504,23 @@
set the
:term:`TESTIMAGE_AUTO`
variable to "1" in your ``local.conf`` file in the
- :term:`Build Directory`:
- ::
+ :term:`Build Directory`::
TESTIMAGE_AUTO = "1"
Next, build your image. If the image successfully builds, the
- tests run:
- ::
+ tests run::
bitbake core-image-sato
- *Manually running tests:* To manually run the tests, first globally
inherit the
:ref:`testimage <ref-classes-testimage*>` class
- by editing your ``local.conf`` file:
- ::
+ by editing your ``local.conf`` file::
INHERIT += "testimage"
- Next, use BitBake to run the tests:
- ::
+ Next, use BitBake to run the tests::
bitbake -c testimage image
@@ -8815,18 +8563,15 @@
Here are some things to keep in mind when running tests:
-- The default tests for the image are defined as:
- ::
+- The default tests for the image are defined as::
DEFAULT_TEST_SUITES_pn-image = "ping ssh df connman syslog xorg scp vnc date rpm dnf dmesg"
-- Add your own test to the list of the by using the following:
- ::
+- Add your own test to the list of the by using the following::
TEST_SUITES_append = " mytest"
-- Run a specific list of tests as follows:
- ::
+- Run a specific list of tests as follows::
TEST_SUITES = "test1 test2 test3"
@@ -8842,16 +8587,14 @@
defined in :term:`TEST_SUITES`.
If your image is already built, make sure the following are set in your
-``local.conf`` file:
-::
+``local.conf`` file::
INHERIT += "testexport"
TEST_TARGET_IP = "IP-address-for-the-test-target"
TEST_SERVER_IP = "IP-address-for-the-test-server"
You can then export the tests with the
-following BitBake command form:
-::
+following BitBake command form::
$ bitbake image -c testexport
@@ -8860,28 +8603,24 @@
``tmp/testexport/``\ image, which is controlled by the
``TEST_EXPORT_DIR`` variable.
-You can now run the tests outside of the build environment:
-::
+You can now run the tests outside of the build environment::
$ cd tmp/testexport/image
$ ./runexported.py testdata.json
Here is a complete example that shows IP addresses and uses the
-``core-image-sato`` image:
-::
+``core-image-sato`` image::
INHERIT += "testexport"
TEST_TARGET_IP = "192.168.7.2"
TEST_SERVER_IP = "192.168.7.1"
-Use BitBake to export the tests:
-::
+Use BitBake to export the tests::
$ bitbake core-image-sato -c testexport
Run the tests outside of
-the build environment using the following:
-::
+the build environment using the following::
$ cd tmp/testexport/core-image-sato
$ ./runexported.py testdata.json
@@ -9157,14 +8896,12 @@
BitBake's ``-e`` option is used to display variable values after
parsing. The following command displays the variable values after the
configuration files (i.e. ``local.conf``, ``bblayers.conf``,
-``bitbake.conf`` and so forth) have been parsed:
-::
+``bitbake.conf`` and so forth) have been parsed::
$ bitbake -e
The following command displays variable values after a specific recipe has
-been parsed. The variables include those from the configuration as well:
-::
+been parsed. The variables include those from the configuration as well::
$ bitbake -e recipename
@@ -9187,8 +8924,7 @@
helpful during debugging.
Variables that are exported to the environment are preceded by
-``export`` in the output of ``bitbake -e``. See the following example:
-::
+``export`` in the output of ``bitbake -e``. See the following example::
export CC="i586-poky-linux-gcc -m32 -march=i586 --sysroot=/home/ulf/poky/build/tmp/sysroots/qemux86"
@@ -9250,8 +8986,7 @@
- ``oe-pkgdata-util find-path path ...``: Lists the names of
the packages that contain the given paths. For example, the following
tells us that ``/usr/share/man/man1/make.1`` is contained in the
- ``make-doc`` package:
- ::
+ ``make-doc`` package::
$ oe-pkgdata-util find-path /usr/share/man/man1/make.1
make-doc: /usr/share/man/man1/make.1
@@ -9260,8 +8995,7 @@
of the recipes that produce the given packages.
For more information on the ``oe-pkgdata-util`` command, use the help
-facility:
-::
+facility::
$ oe-pkgdata-util --help
$ oe-pkgdata-util subcommand --help
@@ -9274,8 +9008,7 @@
understand why a recipe is built.
To generate dependency information for a recipe, run the following
-command:
-::
+command::
$ bitbake -g recipename
@@ -9305,8 +9038,7 @@
provide useful information.
As an example, the ``task-depends.dot`` file contains lines such
- as the following:
- ::
+ as the following::
"libxslt.do_configure" -> "libxml2.do_populate_sysroot"
@@ -9323,8 +9055,7 @@
displays paths between graph nodes.
You can use a different method to view dependency information by using
-the following command:
-::
+the following command::
$ bitbake -g -u taskexp recipename
@@ -9350,8 +9081,7 @@
automatically for a given task, you can list the variable dependencies
BitBake has determined by doing the following:
-1. Build the recipe containing the task:
-::
+1. Build the recipe containing the task::
$ bitbake recipename
@@ -9362,8 +9092,7 @@
checksum for the task. As an example, for the
:ref:`ref-tasks-fetch` task of the
``db`` recipe, the ``sigdata`` file might be found in the following
- location:
- ::
+ location::
${BUILDDIR}/tmp/stamps/i586-poky-linux/db/6.0.30-r1.do_fetch.sigdata.7c048c18222b16ff0bcee2000ef648b1
@@ -9375,8 +9104,7 @@
same information as ``sigdata`` files.
3. Run ``bitbake-dumpsig`` on the ``sigdata`` or ``siginfo`` file. Here
- is an example:
- ::
+ is an example::
$ bitbake-dumpsig ${BUILDDIR}/tmp/stamps/i586-poky-linux/db/6.0.30-r1.do_fetch.sigdata.7c048c18222b16ff0bcee2000ef648b1
@@ -9406,8 +9134,7 @@
You can also use BitBake to dump out the signature construction
information without executing tasks by using either of the following
-BitBake command-line options:
-::
+BitBake command-line options::
‐‐dump-signatures=SIGNATURE_HANDLER
-S SIGNATURE_HANDLER
@@ -9494,8 +9221,7 @@
``do_build`` and any tasks on which it depends build first. Some tasks,
such as ``do_devshell``, are not part of the default build chain. If you
wish to run a task that is not part of the default build chain, you can
-use the ``-c`` option in BitBake. Here is an example:
-::
+use the ``-c`` option in BitBake. Here is an example::
$ bitbake matchbox-desktop -c devshell
@@ -9520,8 +9246,7 @@
[\ :ref:`nostamp <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:variable flags>`\ ]
variable flag is already set for the task.
-The following example shows one way you can use the ``-f`` option:
-::
+The following example shows one way you can use the ``-f`` option::
$ bitbake matchbox-desktop
.
@@ -9550,8 +9275,7 @@
:ref:`ref-tasks-build` task, which is
the default task if no task is given, and the tasks on which it depends.
You could replace the final two commands in the previous example with
-the following single command:
-::
+the following single command::
$ bitbake matchbox-desktop -C compile
@@ -9575,16 +9299,14 @@
and build output might not be in the clean state they would be in for
a "normal" build, depending on what actions you took. To get rid of
such warnings, you can remove the work directory and rebuild the
- recipe, as follows:
- ::
+ recipe, as follows::
$ bitbake matchbox-desktop -c clean
$ bitbake matchbox-desktop
You can view a list of tasks in a given package by running the
-``do_listtasks`` task as follows:
-::
+``do_listtasks`` task as follows::
$ bitbake matchbox-desktop -c listtasks
@@ -9608,8 +9330,7 @@
-----------------------------
To build a specific recipe (``.bb`` file), you can use the following
-command form:
-::
+command form::
$ bitbake -b somepath/somerecipe.bb
@@ -9678,8 +9399,7 @@
Following is an example written in Python. The code handles logging for
a function that determines the number of tasks needed to be run. See the
":ref:`ref-tasks-listtasks`"
-section for additional information:
-::
+section for additional information::
python do_listtasks() {
bb.debug(2, "Starting to figure out the task list")
@@ -9841,21 +9561,18 @@
:term:`PARALLEL_MAKE` variable
in your ``local.conf`` file to a high number (e.g. "-j 20"). Using a
high value for ``PARALLEL_MAKE`` increases the chances of the race
-condition showing up:
-::
+condition showing up::
$ bitbake neard
-Once the local build for "neard" completes, start a ``devshell`` build:
-::
+Once the local build for "neard" completes, start a ``devshell`` build::
$ bitbake neard -c devshell
For information on how to use a ``devshell``, see the
":ref:`dev-manual/common-tasks:using a development shell`" section.
-In the ``devshell``, do the following:
-::
+In the ``devshell``, do the following::
$ make clean
$ make tools/snep-send.o
@@ -9863,8 +9580,7 @@
The ``devshell`` commands cause the failure to clearly
be visible. In this case, a missing dependency exists for the "neard"
Makefile target. Here is some abbreviated, sample output with the
-missing dependency clearly visible at the end:
-::
+missing dependency clearly visible at the end::
i586-poky-linux-gcc -m32 -march=i586 --sysroot=/home/scott-lenovo/......
.
@@ -9885,8 +9601,7 @@
Because there is a missing dependency for the Makefile target, you need
to patch the ``Makefile.am`` file, which is generated from
-``Makefile.in``. You can use Quilt to create the patch:
-::
+``Makefile.in``. You can use Quilt to create the patch::
$ quilt new parallelmake.patch
Patch patches/parallelmake.patch is now on top
@@ -9898,14 +9613,12 @@
At this point you need to make the edits to ``Makefile.am`` to add the
missing dependency. For our example, you have to add the following line
-to the file:
-::
+to the file::
tools/snep-send.$(OBJEXT): include/near/dbus.h
Once you have edited the file, use the ``refresh`` command to create the
-patch:
-::
+patch::
$ quilt refresh
Refreshed patch patches/parallelmake.patch
@@ -9913,8 +9626,7 @@
Once
the patch file exists, you need to add it back to the originating recipe
folder. Here is an example assuming a top-level
-:term:`Source Directory` named ``poky``:
-::
+:term:`Source Directory` named ``poky``::
$ cp patches/parallelmake.patch poky/meta/recipes-connectivity/neard/neard
@@ -9922,8 +9634,7 @@
update the "neard" recipe (i.e. ``neard-0.14.bb``) so that the
:term:`SRC_URI` statement includes
the patch file. The recipe file is in the folder above the patch. Here
-is what the edited ``SRC_URI`` statement would look like:
-::
+is what the edited ``SRC_URI`` statement would look like::
SRC_URI = "${KERNELORG_MIRROR}/linux/network/nfc/${BPN}-${PV}.tar.xz \
file://neard.in \
@@ -9932,8 +9643,7 @@
"
With the patch complete and moved to the correct folder and the
-``SRC_URI`` statement updated, you can exit the ``devshell``:
-::
+``SRC_URI`` statement updated, you can exit the ``devshell``::
$ exit
@@ -9941,16 +9651,14 @@
~~~~~~~~~~~~~~~~~
With everything in place, you can get back to trying the build again
-locally:
-::
+locally::
$ bitbake neard
This build should succeed.
Now you can open up a ``devshell`` again and repeat the clean and make
-operations as follows:
-::
+operations as follows::
$ bitbake neard -c devshell
$ make clean
@@ -9997,42 +9705,47 @@
Using the debuginfod server method
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-"debuginfod" from "elfutils" is a way to distribute "debuginfo" files.
-Running a "debuginfod" server makes debug symbols readily available,
+``debuginfod`` from ``elfutils`` is a way to distribute ``debuginfo`` files.
+Running a ``debuginfod`` server makes debug symbols readily available,
which means you don't need to download debugging information
and the binaries of the process being debugged. You can just fetch
debug symbols from the server.
-To run a debuginfod server, you need to do the following:
+To run a ``debuginfod`` server, you need to do the following:
-- Ensure that this variable is set in your ``local.conf`` file:
- ::
+- Ensure that ``debuginfod`` is present in :term:`DISTRO_FEATURES`
+ (it already is in ``OpenEmbedded-core`` defaults and ``poky`` reference distribution).
+ If not, set in your distro config file or in ``local.conf``::
- PACKAGECONFIG_pn-elfutils-native = "debuginfod libdebuginfod"
+ DISTRO_FEATURES_append = " debuginfod"
- This :term:`PACKAGECONFIG` option enables debuginfod and libdebuginfod for
- "elfutils-native".
+ This distro feature enables the server and client library in ``elfutils``,
+ and enables ``debuginfod`` support in clients (at the moment, ``gdb`` and ``binutils``).
-- Run the following commands to set up the "debuginfod" server:
- ::
+- Run the following commands to launch the ``debuginfod`` server on the host::
$ oe-debuginfod
+- To use ``debuginfod`` on the target, you need to know the ip:port where
+ ``debuginfod`` is listening on the host (port defaults to 8002), and export
+ that into the shell environment, for example in ``qemu``::
-To use debuginfod on the target, you need the following:
+ root@qemux86-64:~# export DEBUGINFOD_URLS="http://192.168.7.1:8002/"
-- Ensure that this variable is set in your ``local.conf`` file:
- ::
+- Then debug info fetching should simply work when running the target ``gdb``,
+ ``readelf`` or ``objdump``, for example::
- DEBUGINFOD_URLS = "http://localhost:8002/"
+ root@qemux86-64:~# gdb /bin/cat
+ ...
+ Reading symbols from /bin/cat...
+ Downloading separate debug info for /bin/cat...
+ Reading symbols from /home/root/.cache/debuginfod_client/923dc4780cfbc545850c616bffa884b6b5eaf322/debuginfo...
- This :term:`DEBUGINFOD_URLS` option does the client configuration.
+- It's also possible to use ``debuginfod-find`` to just query the server::
- ::
+ root@qemux86-64:~# debuginfod-find debuginfo /bin/ls
+ /home/root/.cache/debuginfod_client/356edc585f7f82d46f94fcb87a86a3fe2d2e60bd/debuginfo
- PACKAGECONFIG_pn-gdb = "debuginfod"
-
- This :term:`PACKAGECONFIG` option enables "debuginfod" for "gdb".
Using the gdbserver method
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -10069,8 +9782,7 @@
1. *Configure your build system to construct the companion debug
filesystem:*
- In your ``local.conf`` file, set the following:
- ::
+ In your ``local.conf`` file, set the following::
IMAGE_GEN_DEBUGFS = "1"
IMAGE_FSTYPES_DEBUGFS = "tar.bz2"
@@ -10090,8 +9802,7 @@
2. *Configure the system to include gdbserver in the target filesystem:*
Make the following addition in either your ``local.conf`` file or in
- an image recipe:
- ::
+ an image recipe::
IMAGE_INSTALL_append = " gdbserver"
@@ -10101,29 +9812,25 @@
3. *Build the environment:*
Use the following command to construct the image and the companion
- Debug Filesystem:
- ::
+ Debug Filesystem::
$ bitbake image
Build the cross GDB component and
make it available for debugging. Build the SDK that matches the
image. Building the SDK is best for a production build that can be
- used later for debugging, especially during long term maintenance:
- ::
+ used later for debugging, especially during long term maintenance::
$ bitbake -c populate_sdk image
Alternatively, you can build the minimal toolchain components that
match the target. Doing so creates a smaller than typical SDK and
only contains a minimal set of components with which to build simple
- test applications, as well as run the debugger:
- ::
+ test applications, as well as run the debugger::
$ bitbake meta-toolchain
- A final method is to build Gdb itself within the build system:
- ::
+ A final method is to build Gdb itself within the build system::
$ bitbake gdb-cross-<architecture>
@@ -10140,8 +9847,7 @@
4. *Set up the* ``debugfs``\ *:*
- Run the following commands to set up the ``debugfs``:
- ::
+ Run the following commands to set up the ``debugfs``::
$ mkdir debugfs
$ cd debugfs
@@ -10180,8 +9886,7 @@
Documentation <https://www.gnu.org/software/gdb/documentation/>`__.
After running gdbserver on the target, you need to run Gdb on the
- host and configure it and connect to the target. Use these commands:
- ::
+ host and configure it and connect to the target. Use these commands::
$ cd directory-holding-the-debugfs-directory
$ arch-gdb
@@ -10212,8 +9917,7 @@
If the binary is processed through the debug splitting in
OpenEmbedded, you should also copy the debug items (i.e. ``.debug``
contents and corresponding ``/usr/src/debug`` files) from the work
- directory. Here is an example:
- ::
+ directory. Here is an example::
$ bitbake bash
$ bitbake -c devshell bash
@@ -10234,25 +9938,21 @@
To support this kind of debugging, you need do the following:
- Ensure that GDB is on the target. You can do this by adding "gdb" to
- :term:`IMAGE_INSTALL`:
- ::
+ :term:`IMAGE_INSTALL`::
IMAGE_INSTALL_append = " gdb"
- Alternatively, you can add "tools-debug" to :term:`IMAGE_FEATURES`:
- ::
+ Alternatively, you can add "tools-debug" to :term:`IMAGE_FEATURES`::
IMAGE_FEATURES_append = " tools-debug"
- Ensure that debug symbols are present. You can make sure these
- symbols are present by installing ``-dbg``:
- ::
+ symbols are present by installing ``-dbg``::
IMAGE_INSTALL_append = "packagename-dbg"
Alternatively, you can do the following to include
- all the debug symbols:
- ::
+ all the debug symbols::
IMAGE_FEATURES_append = " dbg-pkgs"
@@ -10262,8 +9962,7 @@
of optimization used by the compiler. For example, when adding the
following line to your ``local.conf`` file, you will reduce optimization
from :term:`FULL_OPTIMIZATION` of "-O2" to :term:`DEBUG_OPTIMIZATION`
- of "-O -fno-omit-frame-pointer":
- ::
+ of "-O -fno-omit-frame-pointer"::
DEBUG_BUILD = "1"
@@ -10307,8 +10006,7 @@
Using GNU Grep, you can use the following shell function to
recursively search through common recipe-related files, skipping
binary files, ``.git`` directories, and the Build Directory (assuming
- its name starts with "build"):
- ::
+ its name starts with "build")::
g() {
grep -Ir \
@@ -10321,8 +10019,7 @@
"$@"
}
- Following are some usage examples:
- ::
+ Following are some usage examples::
$ g FOO # Search recursively for "FOO"
$ g -i foo # Search recursively for "foo", ignoring case
@@ -10581,8 +10278,7 @@
specific convention for bug references - any commit that addresses
a specific bug should use the following form for the detailed
description. Be sure to use the actual bug-tracking ID from
- Bugzilla for bug-id:
- ::
+ Bugzilla for bug-id::
Fixes [YOCTO #bug-id]
@@ -10608,8 +10304,7 @@
provide the command, you must include a revision list or a number of
patches as part of the command. For example, either of these two
commands takes your most recent single commit and formats it as an
- email message in the current directory:
- ::
+ email message in the current directory::
$ git format-patch -1
@@ -10701,8 +10396,7 @@
1. *Push Your Commits to a "Contrib" Upstream:* If you have arranged for
permissions to push to an upstream contrib repository, push the
- change to that repository:
- ::
+ change to that repository::
$ git push upstream_remote_repo local_branch_name
@@ -10711,8 +10405,7 @@
working in a local branch named `your_name`\ ``/README``. The following
command pushes your local commits to the ``meta-intel-contrib``
upstream repository and puts the commit in a branch named
- `your_name`\ ``/README``:
- ::
+ `your_name`\ ``/README``::
$ git push meta-intel-contrib your_name/README
@@ -10729,8 +10422,7 @@
- *Search by File:* Using :ref:`overview-manual/development-environment:git`, you can
enter the following command to bring up a short list of all
- commits against a specific file:
- ::
+ commits against a specific file::
git shortlog -- filename
@@ -10764,8 +10456,7 @@
First, create the pull request. For example, the following command
runs the script, specifies the upstream repository in the contrib
directory into which you pushed the change, and provides a subject
- line in the created patch files:
- ::
+ line in the created patch files::
$ poky/scripts/create-pull-request -u meta-intel-contrib -s "Updated Manual Section Reference in README"
@@ -10778,8 +10469,7 @@
editing the cover letter, send the pull request. For example, the
following command runs the script and specifies the patch directory
and email address. In this example, the email address is a mailing
- list:
- ::
+ list::
$ poky/scripts/send-pull-request -p ~/meta-intel/pull-10565 -t meta-intel@yoctoproject.org
@@ -10788,8 +10478,7 @@
.. note::
For help on using these scripts, simply provide the ``-h``
- argument as follows:
- ::
+ argument as follows::
$ poky/scripts/create-pull-request -h
$ poky/scripts/send-pull-request -h
@@ -10901,8 +10590,7 @@
The ``LIC_FILES_CHKSUM`` variable contains checksums of the license text
in the source code for the recipe. Following is an example of how to
-specify ``LIC_FILES_CHKSUM``:
-::
+specify ``LIC_FILES_CHKSUM``::
LIC_FILES_CHKSUM = "file://COPYING;md5=xxxx \
file://licfile1.txt;beginline=5;endline=29;md5=yyyy \
@@ -10925,8 +10613,7 @@
``LIC_FILES_CHKSUM``. The previous example employs the default
directory.
-Consider this next example:
-::
+Consider this next example::
LIC_FILES_CHKSUM = "file://src/ls.c;beginline=5;endline=16;\
md5=bb14ed3c4cda583abc85401304b5cd4e"
@@ -10988,15 +10675,13 @@
:term:`LICENSE_FLAGS` variable
definition in the affected recipe. For instance, the
``poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly`` recipe
-contains the following statement:
-::
+contains the following statement::
LICENSE_FLAGS = "commercial"
Here is a
slightly more complicated example that contains both an explicit recipe
-name and version (after variable expansion):
-::
+name and version (after variable expansion)::
LICENSE_FLAGS = "license_${PN}_${PV}"
@@ -11011,8 +10696,7 @@
general string "commercial" to ``LICENSE_FLAGS_WHITELIST``. See the
":ref:`dev-manual/common-tasks:license flag matching`" section for a full
explanation of how ``LICENSE_FLAGS`` matching works. Here is the
-example:
-::
+example::
LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly"
@@ -11020,8 +10704,7 @@
containing ``LICENSE_FLAGS = "license_${PN}_${PV}"``, and assuming that
the actual recipe name was ``emgd_1.10.bb``, the following string would
enable that package as well as the original ``gst-plugins-ugly``
-package:
-::
+package::
LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly license_emgd_1.10"
@@ -11077,8 +10760,7 @@
string "commercial" such as "commercial_foo" and "commercial_bar", which
are the strings the build system automatically generates for
hypothetical recipes named "foo" and "bar" assuming those recipes simply
-specify the following:
-::
+specify the following::
LICENSE_FLAGS = "commercial"
@@ -11116,8 +10798,7 @@
Other helpful variables related to commercial license handling exist and
are defined in the
-``poky/meta/conf/distro/include/default-distrovars.inc`` file:
-::
+``poky/meta/conf/distro/include/default-distrovars.inc`` file::
COMMERCIAL_AUDIO_PLUGINS ?= ""
COMMERCIAL_VIDEO_PLUGINS ?= ""
@@ -11125,8 +10806,7 @@
If you
want to enable these components, you can do so by making sure you have
statements similar to the following in your ``local.conf`` configuration
-file:
-::
+file::
COMMERCIAL_AUDIO_PLUGINS = "gst-plugins-ugly-mad \
gst-plugins-ugly-mpegaudioparse"
@@ -11138,8 +10818,7 @@
Of course, you could also create a matching whitelist for those
components using the more general "commercial" in the whitelist, but
that would also enable all the other packages with ``LICENSE_FLAGS``
-containing "commercial", which you may or may not want:
-::
+containing "commercial", which you may or may not want::
LICENSE_FLAGS_WHITELIST = "commercial"
@@ -11219,8 +10898,7 @@
One way of doing this (but certainly not the only way) is to release
just the source as a tarball. You can do this by adding the following to
the ``local.conf`` file found in the
-:term:`Build Directory`:
-::
+:term:`Build Directory`::
INHERIT += "archiver"
ARCHIVER_MODE[src] = "original"
@@ -11276,8 +10954,7 @@
This requirement also needs to be dealt with prior to generating the
final image. Some licenses require the license text to accompany the
binary. You can achieve this by adding the following to your
-``local.conf`` file:
-::
+``local.conf`` file::
COPY_LIC_MANIFEST = "1"
COPY_LIC_DIRS = "1"
@@ -11344,8 +11021,7 @@
convenience is to modify ``meta-poky/conf/bblayers.conf.sample`` to
ensure that when the end user utilizes the released build system to
build an image, the development organization's layers are included in
-the ``bblayers.conf`` file automatically:
-::
+the ``bblayers.conf`` file automatically::
# POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
@@ -11413,8 +11089,7 @@
non-common, non-CLOSED license in a recipe.
The following is an example that uses the ``LICENSE.Abilis.txt`` file as
-the license from the fetched source:
-::
+the license from the fetched source::
NO_GENERIC_LICENSE[Firmware-Abilis] = "LICENSE.Abilis.txt"
@@ -11457,8 +11132,7 @@
By default, the error reporting feature stores information in
``${``\ :term:`LOG_DIR`\ ``}/error-report``.
However, you can specify a directory to use by adding the following to
-your ``local.conf`` file:
-::
+your ``local.conf`` file::
ERR_REPORT_DIR = "path"
@@ -11467,8 +11141,7 @@
in a file as previously described. When the build system encounters an
error, it includes a command as part of the console output. You can run
the command to send the error file to the server. For example, the
-following command sends the errors to an upstream server:
-::
+following command sends the errors to an upstream server::
$ send-error-report /home/brandusa/project/poky/build/tmp/log/error-report/error_report_201403141617.txt
@@ -11476,8 +11149,7 @@
available at https://errors.yoctoproject.org, which is used by the
entire community. If you specify a particular server, you can send the
errors to a different database. Use the following command for more
-information on available options:
-::
+information on available options::
$ send-error-report --help
@@ -11557,8 +11229,7 @@
(`KMS <https://wiki.archlinux.org/index.php/Kernel_Mode_Setting>`__)
support, include the "wayland" flag in the
:term:`DISTRO_FEATURES`
-statement in your ``local.conf`` file:
-::
+statement in your ``local.conf`` file::
DISTRO_FEATURES_append = " wayland"
@@ -11573,8 +11244,7 @@
To install the Wayland feature into an image, you must include the
following
:term:`CORE_IMAGE_EXTRA_INSTALL`
-statement in your ``local.conf`` file:
-::
+statement in your ``local.conf`` file::
CORE_IMAGE_EXTRA_INSTALL += "wayland weston"
@@ -11589,14 +11259,12 @@
(CLI), which is better suited for development work. To run Weston under
the CLI, you need to do the following after your image is built:
-1. Run these commands to export ``XDG_RUNTIME_DIR``:
- ::
+1. Run these commands to export ``XDG_RUNTIME_DIR``::
mkdir -p /tmp/$USER-weston
chmod 0700 /tmp/$USER-weston
export XDG_RUNTIME_DIR=/tmp/$USER-weston
-2. Launch Weston in the shell:
- ::
+2. Launch Weston in the shell::
weston