diff options
| author | Andrew Geissler <geissonator@yahoo.com> | 2021-05-08 00:11:35 +0300 |
|---|---|---|
| committer | Brad Bishop <bradleyb@fuzziesquirrel.com> | 2021-05-27 15:46:22 +0300 |
| commit | c926e17c956a1babdf42d31f644bf0eedfa7f5f6 (patch) | |
| tree | 1f86e19ce74be674e46d31a88a438050f83d3762 /poky/documentation/ref-manual | |
| parent | 5e7fd51182f375f58130989e8d0e206e3e14dee1 (diff) | |
| download | openbmc-c926e17c956a1babdf42d31f644bf0eedfa7f5f6.tar.xz | |
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
Diffstat (limited to 'poky/documentation/ref-manual')
25 files changed, 450 insertions, 869 deletions
diff --git a/poky/documentation/ref-manual/classes.rst b/poky/documentation/ref-manual/classes.rst index 52a50faf6..9a1fc2c93 100644 --- a/poky/documentation/ref-manual/classes.rst +++ b/poky/documentation/ref-manual/classes.rst @@ -168,8 +168,7 @@ example use for this class. the "subpath" parameter limits the checkout to a specific subpath of the tree. Here is an example where ``${BP}`` is used so that the files are extracted into the subdirectory expected by the default value of - ``S``: - :: + ``S``:: SRC_URI = "git://example.com/downloads/somepackage.rpm;subpath=${BP}" @@ -221,8 +220,7 @@ each recipe you wish to blacklist. Specify the :term:`PN` value as a variable flag (varflag) and provide a reason, which is reported, if the package is requested to be built as the value. For example, if you want to blacklist a recipe called "exoticware", you add -the following to your ``local.conf`` or distribution configuration: -:: +the following to your ``local.conf`` or distribution configuration:: INHERIT += "blacklist" PNBLACKLIST[exoticware] = "Not supported by our organization." @@ -470,8 +468,7 @@ information about using ``devshell``. The ``devupstream`` class uses :term:`BBCLASSEXTEND` to add a variant of the recipe that fetches from an alternative URI (e.g. Git) instead of a -tarball. Following is an example: -:: +tarball. Following is an example:: BBCLASSEXTEND = "devupstream:target" SRC_URI_class-devupstream = "git://git.example.com/example" @@ -481,8 +478,7 @@ Adding the above statements to your recipe creates a variant that has :term:`DEFAULT_PREFERENCE` set to "-1". Consequently, you need to select the variant of the recipe to use it. Any development-specific adjustments can be done by using the -``class-devupstream`` override. Here is an example: -:: +``class-devupstream`` override. Here is an example:: DEPENDS_append_class-devupstream = " gperf-native" do_configure_prepend_class-devupstream() { @@ -544,8 +540,7 @@ By default, this class expects the source code to support recipe builds that use the :term:`B` variable to point to the directory in which the OpenEmbedded build system places the generated objects built from the recipes. By default, the ``B`` directory is set to the -following, which is separate from the source directory (``S``): -:: +following, which is separate from the source directory (``S``):: ${WORKDIR}/${BPN}/{PV}/ @@ -581,8 +576,7 @@ be performed using the useradd class to add user and group configuration to a specific recipe. -Here is an example that uses this class in an image recipe: -:: +Here is an example that uses this class in an image recipe:: inherit extrausers EXTRA_USERS_PARAMS = "\ @@ -595,8 +589,7 @@ Here is an example that uses this class in an image recipe: " Here is an example that adds two users named "tester-jim" and "tester-sue" and assigns -passwords: -:: +passwords:: inherit extrausers EXTRA_USERS_PARAMS = "\ @@ -604,8 +597,7 @@ passwords: useradd -P tester01 tester-sue; \ " -Finally, here is an example that sets the root password to "1876*18": -:: +Finally, here is an example that sets the root password to "1876*18":: inherit extrausers EXTRA_USERS_PARAMS = "\ @@ -867,8 +859,7 @@ system need to either inherit the ``icecc`` class or nobody should. At the distribution level, you can inherit the ``icecc`` class to be sure that all builders start with the same sstate signatures. After inheriting the class, you can then disable the feature by setting the -:term:`ICECC_DISABLED` variable to "1" as follows: -:: +:term:`ICECC_DISABLED` variable to "1" as follows:: INHERIT_DISTRO_append = " icecc" ICECC_DISABLED ??= "1" @@ -876,8 +867,7 @@ inheriting the class, you can then disable the feature by setting the This practice makes sure everyone is using the same signatures but also requires individuals that do want to use Icecream to enable the feature -individually as follows in your ``local.conf`` file: -:: +individually as follows in your ``local.conf`` file:: ICECC_DISABLED = "" @@ -925,8 +915,7 @@ types. By default, the :ref:`image <ref-classes-image>` class automatically enables the ``image_types`` class. The ``image`` class uses the -``IMGCLASSES`` variable as follows: -:: +``IMGCLASSES`` variable as follows:: IMGCLASSES = "rootfs_${IMAGE_PKGTYPE} image_types ${IMAGE_CLASSES}" IMGCLASSES += "${@['populate_sdk_base', 'populate_sdk_ext']['linux' in d.getVar("SDK_OS")]}" @@ -968,8 +957,7 @@ during the :ref:`ref-tasks-rootfs` task, which optimizes the size of libraries contained in the image. By default, the class is enabled in the ``local.conf.template`` using -the :term:`USER_CLASSES` variable as follows: -:: +the :term:`USER_CLASSES` variable as follows:: USER_CLASSES ?= "buildstats image-mklibs image-prelink" @@ -984,8 +972,7 @@ the dynamic linking of shared libraries to reduce executable startup time. By default, the class is enabled in the ``local.conf.template`` using -the :term:`USER_CLASSES` variable as follows: -:: +the :term:`USER_CLASSES` variable as follows:: USER_CLASSES ?= "buildstats image-mklibs image-prelink" @@ -1014,8 +1001,7 @@ configuration). However, to skip one or more checks in recipes, you should use :term:`INSANE_SKIP`. For example, to skip the check for symbolic link ``.so`` files in the main package of a recipe, add the following to the recipe. You need to realize that the -package name override, in this example ``${PN}``, must be used: -:: +package name override, in this example ``${PN}``, must be used:: INSANE_SKIP_${PN} += "dev-so" @@ -1152,8 +1138,7 @@ The following list shows the tests you can list with the ``WARN_QA`` and - ``invalid-packageconfig:`` Checks that no undefined features are being added to :term:`PACKAGECONFIG`. For - example, any name "foo" for which the following form does not exist: - :: + example, any name "foo" for which the following form does not exist:: PACKAGECONFIG[foo] = "..." @@ -1636,8 +1621,7 @@ a couple different ways: .. note:: When creating a recipe this way, the recipe name must follow this - naming convention: - :: + naming convention:: myrecipe-native.bb @@ -1645,8 +1629,7 @@ a couple different ways: Not using this naming convention can lead to subtle problems caused by existing code that depends on that naming convention. -- Create or modify a target recipe that contains the following: - :: +- Create or modify a target recipe that contains the following:: BBCLASSEXTEND = "native" @@ -1677,8 +1660,7 @@ couple different ways: inherit statement in the recipe after all other inherit statements so that the ``nativesdk`` class is inherited last. -- Create a ``nativesdk`` variant of any recipe by adding the following: - :: +- Create a ``nativesdk`` variant of any recipe by adding the following:: BBCLASSEXTEND = "nativesdk" @@ -1689,8 +1671,7 @@ couple different ways: .. note:: - When creating a recipe, you must follow this naming convention: - :: + When creating a recipe, you must follow this naming convention:: nativesdk-myrecipe.bb @@ -1753,8 +1734,7 @@ before attempting to fetch it from the upstream specified in :term:`SRC_URI` within each recipe. To use this class, inherit it globally and specify -:term:`SOURCE_MIRROR_URL`. Here is an example: -:: +:term:`SOURCE_MIRROR_URL`. Here is an example:: INHERIT += "own-mirrors" SOURCE_MIRROR_URL = "http://example.com/my-source-mirror" @@ -2017,8 +1997,7 @@ established and then populates the SDK. After populating the SDK, the contains the cross-compiler and associated tooling, and the target, which contains a target root filesystem that is configured for the SDK usage. These two images reside in :term:`SDK_OUTPUT`, -which consists of the following: -:: +which consists of the following:: ${SDK_OUTPUT}/${SDK_ARCH}-nativesdk-pkgs ${SDK_OUTPUT}/${SDKTARGETSYSROOT}/target-pkgs @@ -2180,8 +2159,7 @@ installed by ``libtool``. Removing these files results in them being absent from both the sysroot and target packages. If a recipe needs the ``.la`` files to be installed, then the recipe can -override the removal by setting ``REMOVE_LIBTOOL_LA`` to "0" as follows: -:: +override the removal by setting ``REMOVE_LIBTOOL_LA`` to "0" as follows:: REMOVE_LIBTOOL_LA = "0" @@ -2231,8 +2209,7 @@ recipe, enabling ``rm_work`` will potentially result in your changes to the source being lost. To exclude some recipes from having their work directories deleted by ``rm_work``, you can add the names of the recipe or recipes you are working on to the ``RM_WORK_EXCLUDE`` variable, which -can also be set in your ``local.conf`` file. Here is an example: -:: +can also be set in your ``local.conf`` file. Here is an example:: RM_WORK_EXCLUDE += "busybox glibc" @@ -2531,8 +2508,7 @@ You should set :term:`SYSTEMD_SERVICE` to the name of the service file. You should also use a package name override to indicate the package to which the value applies. If the value applies to the recipe's main package, use ``${``\ :term:`PN`\ ``}``. Here -is an example from the connman recipe: -:: +is an example from the connman recipe:: SYSTEMD_SERVICE_${PN} = "connman.service" @@ -2608,8 +2584,7 @@ The tests are commands that run on the target system over ``ssh``. Each test is written in Python and makes use of the ``unittest`` module. The ``testimage.bbclass`` runs tests on an image when called using the -following: -:: +following:: $ bitbake -c testimage image @@ -2628,8 +2603,7 @@ section in the Yocto Project Development Tasks Manual. This class supports running automated tests against software development kits (SDKs). The ``testsdk`` class runs tests on an SDK when called -using the following: -:: +using the following:: $ bitbake -c testsdk image @@ -2684,8 +2658,7 @@ the environment for installed SDKs. The ``typecheck`` class provides support for validating the values of variables set at the configuration level against their defined types. The OpenEmbedded build system allows you to define the type of a -variable using the "type" varflag. Here is an example: -:: +variable using the "type" varflag. Here is an example:: IMAGE_FEATURES[type] = "list" @@ -2695,14 +2668,12 @@ variable using the "type" varflag. Here is an example: ======================== The ``uboot-config`` class provides support for U-Boot configuration for -a machine. Specify the machine in your recipe as follows: -:: +a machine. Specify the machine in your recipe as follows:: UBOOT_CONFIG ??= <default> UBOOT_CONFIG[foo] = "config,images" -You can also specify the machine using this method: -:: +You can also specify the machine using this method:: UBOOT_MACHINE = "config" diff --git a/poky/documentation/ref-manual/devtool-reference.rst b/poky/documentation/ref-manual/devtool-reference.rst index 629aa2ffb..0ce321983 100644 --- a/poky/documentation/ref-manual/devtool-reference.rst +++ b/poky/documentation/ref-manual/devtool-reference.rst @@ -22,8 +22,7 @@ Getting Help The ``devtool`` command line is organized similarly to Git in that it has a number of sub-commands for each function. You can run -``devtool --help`` to see all the commands: -:: +``devtool --help`` to see all the commands:: $ devtool -h NOTE: Starting bitbake server... @@ -79,8 +78,7 @@ has a number of sub-commands for each function. You can run As directed in the general help output, you can get more syntax on a specific command by providing the command name and -using "--help": -:: +using "--help":: $ devtool add --help NOTE: Starting bitbake server... @@ -172,8 +170,7 @@ you. The source files the recipe uses should exist in an external area. The following example creates and adds a new recipe named ``jackson`` to a workspace layer the tool creates. The source code built by the recipes -resides in ``/home/user/sources/jackson``: -:: +resides in ``/home/user/sources/jackson``:: $ devtool add jackson /home/user/sources/jackson @@ -201,8 +198,7 @@ unpacking files from a remote URI. In some cases, you might want to specify a source revision by branch, tag, or commit hash. You can specify these options when using the ``devtool add`` command: -- To specify a source branch, use the ``--srcbranch`` option: - :: +- To specify a source branch, use the ``--srcbranch`` option:: $ devtool add --srcbranch &DISTRO_NAME_NO_CAP; jackson /home/user/sources/jackson @@ -210,8 +206,7 @@ specify these options when using the ``devtool add`` command: branch. - To specify a specific tag or commit hash, use the ``--srcrev`` - option: - :: + option:: $ devtool add --srcrev &DISTRO_REL_TAG; jackson /home/user/sources/jackson $ devtool add --srcrev some_commit_hash /home/user/sources/jackson @@ -269,8 +264,7 @@ The ``devtool modify`` command extracts the source for a recipe, sets it up as a Git repository if the source had not already been fetched from Git, checks out a branch for development, and applies any patches from the recipe as commits on top. You can use the following command to -checkout the source files: -:: +checkout the source files:: $ devtool modify recipe @@ -309,8 +303,7 @@ compile, and test the code. When you are satisfied with the results and you have committed your changes to the Git repository, you can then run the -``devtool update-recipe`` to create the patches and update the recipe: -:: +``devtool update-recipe`` to create the patches and update the recipe:: $ devtool update-recipe recipe @@ -321,8 +314,7 @@ Often, you might want to apply customizations made to your software in your own layer rather than apply them to the original recipe. If so, you can use the ``-a`` or ``--append`` option with the ``devtool update-recipe`` command. These options allow you to specify -the layer into which to write an append file: -:: +the layer into which to write an append file:: $ devtool update-recipe recipe -a base-layer-directory @@ -358,8 +350,7 @@ particular recipe. recipe's latest version tag. As with all ``devtool`` commands, you can get help on the individual -command: -:: +command:: $ devtool check-upgrade-status -h NOTE: Starting bitbake server... @@ -462,8 +453,7 @@ files have been modified, the command preserves the modified files in a separate "attic" subdirectory under the workspace layer. Here is an example that resets the workspace directory that contains the -``mtr`` recipe: -:: +``mtr`` recipe:: $ devtool reset mtr NOTE: Cleaning sysroot for recipe mtr... @@ -482,8 +472,7 @@ Use the ``devtool build`` command to build your recipe. The When you use the ``devtool build`` command, you must supply the root name of the recipe (i.e. do not provide versions, paths, or extensions). You can use either the "-s" or the "--disable-parallel-make" options to -disable parallel makes during the build. Here is an example: -:: +disable parallel makes during the build. Here is an example:: $ devtool build recipe @@ -499,8 +488,7 @@ device for testing. For proper integration into a final image, you need to edit your custom image recipe appropriately. When you use the ``devtool build-image`` command, you must supply the -name of the image. This command has no command line options: -:: +name of the image. This command has no command line options:: $ devtool build-image image @@ -510,8 +498,7 @@ Deploying Your Software on the Target Machine ============================================= Use the ``devtool deploy-target`` command to deploy the recipe's build -output to the live target machine: -:: +output to the live target machine:: $ devtool deploy-target recipe target @@ -582,15 +569,13 @@ new workspace layer, it is populated with the ``README`` file and the ``conf`` directory only. The following example creates a new workspace layer in your current -working and by default names the workspace layer "workspace": -:: +working and by default names the workspace layer "workspace":: $ devtool create-workspace You can create a workspace layer anywhere by supplying a pathname with the command. The following command creates a new workspace layer named -"new-workspace": -:: +"new-workspace":: $ devtool create-workspace /home/scottrif/new-workspace @@ -603,15 +588,13 @@ Use the ``devtool status`` command to list the recipes currently in your workspace. Information includes the paths to their respective external source trees. -The ``devtool status`` command has no command-line options: -:: +The ``devtool status`` command has no command-line options:: $ devtool status Following is sample output after using :ref:`devtool add <ref-manual/devtool-reference:adding a new recipe to the workspace layer>` -to create and add the ``mtr_0.86.bb`` recipe to the ``workspace`` directory: -:: +to create and add the ``mtr_0.86.bb`` recipe to the ``workspace`` directory:: $ devtool status mtr:/home/scottrif/poky/build/workspace/sources/mtr (/home/scottrif/poky/build/workspace/recipes/mtr/mtr_0.86.bb) diff --git a/poky/documentation/ref-manual/faq.rst b/poky/documentation/ref-manual/faq.rst index 64fdfdf75..e7bca829a 100644 --- a/poky/documentation/ref-manual/faq.rst +++ b/poky/documentation/ref-manual/faq.rst @@ -125,7 +125,7 @@ file. Following is the applicable code for setting various proxy types in the ``.wgetrc`` file. By default, these settings are disabled with comments. -To use them, remove the comments: :: +To use them, remove the comments:: # You can set the default proxies for Wget to use for http, https, and ftp. # They will override the value in the environment. @@ -209,8 +209,7 @@ section in the Yocto Project Development Tasks Manual. **A:** You need to create a form factor file as described in the ":ref:`bsp-guide/bsp:miscellaneous bsp-specific recipe files`" section in the Yocto Project Board Support Packages (BSP) Developer's Guide. Set -the ``HAVE_TOUCHSCREEN`` variable equal to one as follows: -:: +the ``HAVE_TOUCHSCREEN`` variable equal to one as follows:: HAVE_TOUCHSCREEN=1 @@ -224,7 +223,7 @@ to add a BSP-specific netbase that includes an interfaces file. See the the Yocto Project Board Support Packages (BSP) Developer's Guide for information on creating these types of miscellaneous recipe files. -For example, add the following files to your layer: :: +For example, add the following files to your layer:: meta-MACHINE/recipes-bsp/netbase/netbase/MACHINE/interfaces meta-MACHINE/recipes-bsp/netbase/netbase_5.0.bbappend @@ -300,7 +299,7 @@ fail. As an example, you could add a specific server for the build system to attempt before any others by adding something like the following to the -``local.conf`` configuration file: :: +``local.conf`` configuration file:: PREMIRRORS_prepend = "\ git://.*/.* http://www.yoctoproject.org/sources/ \n \ @@ -313,8 +312,7 @@ HTTPS requests and direct them to the ``http://`` sources mirror. You can use ``file://`` URLs to point to local directories or network shares as well. -Aside from the previous technique, these options also exist: -:: +Aside from the previous technique, these options also exist:: BB_NO_NETWORK = "1" @@ -322,8 +320,7 @@ This statement tells BitBake to issue an error instead of trying to access the Internet. This technique is useful if you want to ensure code builds only from local sources. -Here is another technique: -:: +Here is another technique:: BB_FETCH_PREMIRRORONLY = "1" @@ -331,8 +328,7 @@ This statement limits the build system to pulling source from the ``PREMIRRORS`` only. Again, this technique is useful for reproducing builds. -Here is another technique: -:: +Here is another technique:: BB_GENERATE_MIRROR_TARBALLS = "1" @@ -343,7 +339,7 @@ however, the technique can simply waste time during the build. Finally, consider an example where you are behind an HTTP-only firewall. You could make the following changes to the ``local.conf`` configuration -file as long as the ``PREMIRRORS`` server is current: :: +file as long as the ``PREMIRRORS`` server is current:: PREMIRRORS_prepend = "\ ftp://.*/.* http://www.yoctoproject.org/sources/ \n \ diff --git a/poky/documentation/ref-manual/features.rst b/poky/documentation/ref-manual/features.rst index 89c06eb65..eb4947d59 100644 --- a/poky/documentation/ref-manual/features.rst +++ b/poky/documentation/ref-manual/features.rst @@ -26,8 +26,7 @@ One method you can use to determine which recipes are checking to see if a particular feature is contained or not is to ``grep`` through the :term:`Metadata` for the feature. Here is an example that discovers the recipes whose build is potentially changed based on a -given feature: -:: +given feature:: $ cd poky $ git grep 'contains.*MACHINE_FEATURES.*feature' diff --git a/poky/documentation/ref-manual/images.rst b/poky/documentation/ref-manual/images.rst index cf5cc1109..b2db1a773 100644 --- a/poky/documentation/ref-manual/images.rst +++ b/poky/documentation/ref-manual/images.rst @@ -18,8 +18,7 @@ image you want. are going to build an image using non-GPLv3 and similarly licensed components, you must make the following changes in the ``local.conf`` file before using the BitBake command to build the minimal or base - image: - :: + image:: 1. Comment out the EXTRA_IMAGE_FEATURES line 2. Set INCOMPATIBLE_LICENSE = "GPL-3.0 LGPL-3.0 AGPL-3.0" @@ -27,7 +26,7 @@ image you want. From within the ``poky`` Git repository, you can use the following command to display the list of directories within the :term:`Source Directory` -that contain image recipe files: :: +that contain image recipe files:: $ ls meta*/recipes*/images/*.bb diff --git a/poky/documentation/ref-manual/kickstart.rst b/poky/documentation/ref-manual/kickstart.rst index b87cdc13b..843292b52 100644 --- a/poky/documentation/ref-manual/kickstart.rst +++ b/poky/documentation/ref-manual/kickstart.rst @@ -30,8 +30,7 @@ Command: part or partition ========================== Either of these commands creates a partition on the system and uses the -following syntax: -:: +following syntax:: part [mntpoint] partition [mntpoint] @@ -59,8 +58,7 @@ must also provide one of the ``--ondrive``, ``--ondisk``, or versions of these application are currently excluded. Here is an example that uses "/" as the mountpoint. The command uses -``--ondisk`` to force the partition onto the ``sdb`` disk: -:: +``--ondisk`` to force the partition onto the ``sdb`` disk:: part / --source rootfs --ondisk sdb --fstype=ext3 --label platform --align 1024 diff --git a/poky/documentation/ref-manual/migration-1.3.rst b/poky/documentation/ref-manual/migration-1.3.rst index 0929f490d..b90767ff9 100644 --- a/poky/documentation/ref-manual/migration-1.3.rst +++ b/poky/documentation/ref-manual/migration-1.3.rst @@ -29,7 +29,7 @@ location (either local or remote) and then point to it in :term:`SSTATE_MIRRORS`, you need to append "PATH" to the end of the mirror URL so that the path used by BitBake before the mirror substitution is appended to the path used to access the mirror. -Here is an example: :: +Here is an example:: SSTATE_MIRRORS = "file://.* http://someserver.tld/share/sstate/PATH" @@ -181,14 +181,13 @@ Linux Kernel Naming ------------------- The naming scheme for kernel output binaries has been changed to now -include :term:`PE` as part of the filename: -:: +include :term:`PE` as part of the filename:: KERNEL_IMAGE_BASE_NAME ?= "${KERNEL_IMAGETYPE}-${PE}-${PV}-${PR}-${MACHINE}-${DATETIME}" Because the ``PE`` variable is not set by default, these binary files could result with names that include two dash characters. Here is an -example: :: +example:: bzImage--3.10.9+git0+cd502a8814_7144bcc4b8-r0-qemux86-64-20130830085431.bin diff --git a/poky/documentation/ref-manual/migration-1.4.rst b/poky/documentation/ref-manual/migration-1.4.rst index f5fac7a2a..deb848749 100644 --- a/poky/documentation/ref-manual/migration-1.4.rst +++ b/poky/documentation/ref-manual/migration-1.4.rst @@ -40,8 +40,7 @@ Differences include the following: - *Shared State Code:* The shared state code has been optimized to avoid running unnecessary tasks. For example, the following no longer - populates the target sysroot since that is not necessary: - :: + populates the target sysroot since that is not necessary:: $ bitbake -c rootfs some-image @@ -136,8 +135,7 @@ Target Package Management with RPM If runtime package management is enabled and the RPM backend is selected, Smart is now installed for package download, dependency resolution, and upgrades instead of Zypper. For more information on how -to use Smart, run the following command on the target: -:: +to use Smart, run the following command on the target:: smart --help diff --git a/poky/documentation/ref-manual/migration-1.6.rst b/poky/documentation/ref-manual/migration-1.6.rst index 4c6afab1f..5a18d6310 100644 --- a/poky/documentation/ref-manual/migration-1.6.rst +++ b/poky/documentation/ref-manual/migration-1.6.rst @@ -53,8 +53,7 @@ Matching Branch Requirement for Git Fetching When fetching source from a Git repository using :term:`SRC_URI`, BitBake will now validate the :term:`SRCREV` value against the branch. You can specify -the branch using the following form: -:: +the branch using the following form:: SRC_URI = "git://server.name/repository;branch=branchname" @@ -207,7 +206,7 @@ functions to call and not arbitrary shell commands: For migration purposes, you can simply wrap shell commands in a shell -function and then call the function. Here is an example: :: +function and then call the function. Here is an example:: my_postprocess_function() { echo "hello" > ${IMAGE_ROOTFS}/hello.txt @@ -248,8 +247,7 @@ the ``autotools`` or ``autotools_stage``\ classes. ``qemu-native`` now builds without SDL-based graphical output support by default. The following additional lines are needed in your -``local.conf`` to enable it: -:: +``local.conf`` to enable it:: PACKAGECONFIG_pn-qemu-native = "sdl" ASSUME_PROVIDED += "libsdl-native" diff --git a/poky/documentation/ref-manual/migration-1.7.rst b/poky/documentation/ref-manual/migration-1.7.rst index 9cf467f28..46bf12658 100644 --- a/poky/documentation/ref-manual/migration-1.7.rst +++ b/poky/documentation/ref-manual/migration-1.7.rst @@ -15,8 +15,7 @@ optional features. The method used to set defaults for these options means that existing ``local.conf`` files will need to be modified to append to ``PACKAGECONFIG`` for ``qemu-native`` and ``nativesdk-qemu`` instead of setting it. In other words, to enable graphical output for -QEMU, you should now have these lines in ``local.conf``: -:: +QEMU, you should now have these lines in ``local.conf``:: PACKAGECONFIG_append_pn-qemu-native = " sdl" PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl" @@ -80,8 +79,7 @@ disable the scripts due to the scripts previously requiring error-prone path substitution. Software that links against these libraries using these scripts should use the much more robust ``pkg-config`` instead. The list of recipes changed in this version (and their configuration -scripts) is as follows: -:: +scripts) is as follows:: directfb (directfb-config) freetype (freetype-config) diff --git a/poky/documentation/ref-manual/migration-1.8.rst b/poky/documentation/ref-manual/migration-1.8.rst index ec2b13879..68d5dcf85 100644 --- a/poky/documentation/ref-manual/migration-1.8.rst +++ b/poky/documentation/ref-manual/migration-1.8.rst @@ -56,7 +56,7 @@ you can now remove them. Additionally, a ``bluetooth`` class has been added to make selection of the appropriate bluetooth support within a recipe a little easier. If you wish to make use of this class in a recipe, add something such as -the following: :: +the following:: inherit bluetooth PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', '${BLUEZ}', '', d)}" @@ -84,7 +84,7 @@ where the ``linux.inc`` file in ``meta-oe`` was updated. Recipes that rely on the kernel source code and do not inherit the module classes might need to add explicit dependencies on the -``do_shared_workdir`` kernel task, for example: :: +``do_shared_workdir`` kernel task, for example:: do_configure[depends] += "virtual/kernel:do_shared_workdir" @@ -131,7 +131,7 @@ One of the improvements is to attempt to run "make clean" during the ``do_configure`` task if a ``Makefile`` exists. Some software packages do not provide a working clean target within their make files. If you have such recipes, you need to set -:term:`CLEANBROKEN` to "1" within the recipe, for example: :: +:term:`CLEANBROKEN` to "1" within the recipe, for example:: CLEANBROKEN = "1" diff --git a/poky/documentation/ref-manual/migration-2.0.rst b/poky/documentation/ref-manual/migration-2.0.rst index 9da60dfdc..8319b0ee3 100644 --- a/poky/documentation/ref-manual/migration-2.0.rst +++ b/poky/documentation/ref-manual/migration-2.0.rst @@ -25,8 +25,7 @@ and the porting guide at https://gcc.gnu.org/gcc-5/porting_to.html. Alternatively, you can switch back to GCC 4.9 or 4.8 by setting -``GCCVERSION`` in your configuration, as follows: -:: +``GCCVERSION`` in your configuration, as follows:: GCCVERSION = "4.9%" @@ -91,8 +90,7 @@ unlikely to require any changes to Metadata. However, these minor changes in behavior exist: - All potential overrides are now visible in the variable history as - seen when you run the following: - :: + seen when you run the following:: $ bitbake -e @@ -200,8 +198,7 @@ changes. Additionally, work directories for old versions of recipes are now pruned. If you wish to disable pruning old work directories, you can set -the following variable in your configuration: -:: +the following variable in your configuration:: SSTATE_PRUNE_OBSOLETEWORKDIR = "0" diff --git a/poky/documentation/ref-manual/migration-2.1.rst b/poky/documentation/ref-manual/migration-2.1.rst index 1eb9ab552..32d193f0f 100644 --- a/poky/documentation/ref-manual/migration-2.1.rst +++ b/poky/documentation/ref-manual/migration-2.1.rst @@ -42,8 +42,7 @@ defaulted to False if not specified. Now, however, no default exists so one must be specified. You must change any ``getVar()`` calls that do not specify the final expand parameter to calls that do specify the parameter. You can run the following ``sed`` command at the base of a -layer to make this change: -:: +layer to make this change:: sed -e 's:\(\.getVar([^,()]*\)):\1, False):g' -i `grep -ril getVar *` sed -e 's:\(\.getVarFlag([^,()]*,[^,()]*\)):\1, False):g' -i `grep -ril getVarFlag *` @@ -285,8 +284,7 @@ The following changes have been made for the Poky distribution: Any recipe that needs to opt-out of having the "--disable-static" option specified on the configure command line either because it is not a supported option for the configure script or because static - libraries are needed should set the following variable: - :: + libraries are needed should set the following variable:: DISABLE_STATIC = "" @@ -369,8 +367,7 @@ These additional changes exist: - Previously, the following list of packages were removed if package-management was not in :term:`IMAGE_FEATURES`, regardless of any - dependencies: - :: + dependencies:: update-rc.d base-passwd diff --git a/poky/documentation/ref-manual/migration-2.2.rst b/poky/documentation/ref-manual/migration-2.2.rst index 198181a46..a9d3cde7b 100644 --- a/poky/documentation/ref-manual/migration-2.2.rst +++ b/poky/documentation/ref-manual/migration-2.2.rst @@ -144,8 +144,7 @@ The new ``runqemu`` is a Python script. Machine knowledge is no longer hardcoded into ``runqemu``. You can choose to use the ``qemuboot`` configuration file to define the BSP's own arguments and to make it bootable with ``runqemu``. If you use a configuration file, use the -following form: -:: +following form:: image-name-machine.qemuboot.conf @@ -160,8 +159,7 @@ rootfs). QEMU boot arguments can be set in BSP's configuration file and the ``qemuboot`` class will save them to ``qemuboot.conf``. If you want to use ``runqemu`` without a configuration file, use the -following command form: -:: +following command form:: $ runqemu machine rootfs kernel [options] @@ -179,7 +177,7 @@ Supported machines are as follows: Consider the following example, which uses the ``qemux86-64`` machine, provides a -root filesystem, provides an image, and uses the ``nographic`` option: :: +root filesystem, provides an image, and uses the ``nographic`` option:: $ runqemu qemux86-64 tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.ext4 tmp/deploy/images/qemux86-64/bzImage nographic @@ -244,8 +242,7 @@ recipes. You need to fix these recipes so that they use the expected ``LDFLAGS``. Depending on how the software is built, the build system used by the software (e.g. a Makefile) might need to be patched. However, sometimes making this fix is as simple as adding the following -to the recipe: -:: +to the recipe:: TARGET_CC_ARCH += "${LDFLAGS}" @@ -258,8 +255,7 @@ The ``KERNEL_IMAGE_BASE_NAME`` variable no longer uses the :term:`KERNEL_IMAGETYPE` variable to create the image's base name. Because the OpenEmbedded build system can now build multiple kernel image types, this part of the kernel image base name as -been removed leaving only the following: -:: +been removed leaving only the following:: KERNEL_IMAGE_BASE_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}" diff --git a/poky/documentation/ref-manual/migration-2.3.rst b/poky/documentation/ref-manual/migration-2.3.rst index 0541eb3e7..dfbda612a 100644 --- a/poky/documentation/ref-manual/migration-2.3.rst +++ b/poky/documentation/ref-manual/migration-2.3.rst @@ -114,8 +114,7 @@ Changes to Scripts The following changes to scripts took place: - ``oe-find-native-sysroot``: The usage for the - ``oe-find-native-sysroot`` script has changed to the following: - :: + ``oe-find-native-sysroot`` script has changed to the following:: $ . oe-find-native-sysroot recipe @@ -124,8 +123,7 @@ The following changes to scripts took place: was not necessary to provide the script with the command. - ``oe-run-native``: The usage for the ``oe-run-native`` script has - changed to the following: - :: + changed to the following:: $ oe-run-native native_recipe tool @@ -453,14 +451,11 @@ The following miscellaneous changes have occurred: tools. - The ``USE_LDCONFIG`` variable has been replaced with the "ldconfig" - ``DISTRO_FEATURES`` feature. Distributions that previously set: - :: + ``DISTRO_FEATURES`` feature. Distributions that previously set:: USE_LDCONFIG = "0" - should now instead use the following: - - :: + should now instead use the following:: DISTRO_FEATURES_BACKFILL_CONSIDERED_append = " ldconfig" @@ -478,8 +473,7 @@ The following miscellaneous changes have occurred: order to allow module packages from multiple kernel versions to co-exist on a target system. If you wish to return to the previous naming scheme that does not include the version suffix, use the - following: - :: + following:: KERNEL_MODULE_PACKAGE_SUFFIX = "" diff --git a/poky/documentation/ref-manual/migration-2.5.rst b/poky/documentation/ref-manual/migration-2.5.rst index 9ef4b5539..86a0da9c4 100644 --- a/poky/documentation/ref-manual/migration-2.5.rst +++ b/poky/documentation/ref-manual/migration-2.5.rst @@ -138,13 +138,11 @@ The following are BitBake changes: tree" tasks have been removed (e.g. ``fetchall``, ``checkuriall``, and the ``*all`` tasks provided by the ``distrodata`` and ``archiver`` classes). There is a BitBake option to complete this for - any arbitrary task. For example: - :: + any arbitrary task. For example:: bitbake <target> -c fetchall - should now be replaced with: - :: + should now be replaced with:: bitbake <target> --runall=fetch @@ -169,7 +167,7 @@ one of the packages provided by the Python recipe. You can no longer run ``bitbake python-foo`` or have a :term:`DEPENDS` on ``python-foo``, but doing either of the following causes the package to work as -expected: :: +expected:: IMAGE_INSTALL_append = " python-foo" diff --git a/poky/documentation/ref-manual/migration-2.6.rst b/poky/documentation/ref-manual/migration-2.6.rst index aeac50980..d1c6c0c5f 100644 --- a/poky/documentation/ref-manual/migration-2.6.rst +++ b/poky/documentation/ref-manual/migration-2.6.rst @@ -161,13 +161,11 @@ The following changes have been made: allows easier and more direct changes. The ``IMAGE_VERSION_SUFFIX`` variable is set in the ``bitbake.conf`` - configuration file as follows: - :: + configuration file as follows:: IMAGE_VERSION_SUFFIX = "-${DATETIME}" -- Several variables have changed names for consistency: - :: +- Several variables have changed names for consistency:: Old Variable Name New Variable Name ======================================================== @@ -292,8 +290,7 @@ avoids the ``systemd`` recipe from becoming machine-specific for cases where machine-specific configurations need to be applied (e.g. for ``qemu*`` machines). -Currently, the new recipe packages the following files: -:: +Currently, the new recipe packages the following files:: ${sysconfdir}/machine-id ${sysconfdir}/systemd/coredump.conf @@ -393,8 +390,7 @@ If you wish to disable Python profile-guided optimization regardless of the value of ``MACHINE_FEATURES``, then ensure that :term:`PACKAGECONFIG` for the ``python3`` recipe does not contain "pgo". You could accomplish the latter using the -following at the configuration level: -:: +following at the configuration level:: PACKAGECONFIG_remove_pn-python3 = "pgo" @@ -411,8 +407,7 @@ The following miscellaneous changes occurred: - Default to using the Thumb-2 instruction set for armv7a and above. If you have any custom recipes that build software that needs to be built with the ARM instruction set, change the recipe to set the - instruction set as follows: - :: + instruction set as follows:: ARM_INSTRUCTION_SET = "arm" diff --git a/poky/documentation/ref-manual/migration-3.1.rst b/poky/documentation/ref-manual/migration-3.1.rst index 84d32502e..7822285a8 100644 --- a/poky/documentation/ref-manual/migration-3.1.rst +++ b/poky/documentation/ref-manual/migration-3.1.rst @@ -71,8 +71,7 @@ when building a simple image such as core-image-minimal. If you do not need runtime tests enabled for core components, then it is recommended that you remove "ptest" from :term:`DISTRO_FEATURES` to save a significant -amount of build time e.g. by adding the following in your configuration: -:: +amount of build time e.g. by adding the following in your configuration:: DISTRO_FEATURES_remove = "ptest" @@ -179,12 +178,12 @@ parameter instead of the earlier ``name`` which overlapped with the generic ``name`` parameter. All recipes using the npm fetcher will need to be changed as a result. -An example of the new scheme: :: +An example of the new scheme:: SRC_URI = "npm://registry.npmjs.org;package=array-flatten;version=1.1.1 \ npmsw://${THISDIR}/npm-shrinkwrap.json" -Another example where the sources are fetched from git rather than an npm repository: :: +Another example where the sources are fetched from git rather than an npm repository:: SRC_URI = "git://github.com/foo/bar.git;protocol=https \ npmsw://${THISDIR}/npm-shrinkwrap.json" diff --git a/poky/documentation/ref-manual/migration-3.2.rst b/poky/documentation/ref-manual/migration-3.2.rst index 39743af70..956a56f62 100644 --- a/poky/documentation/ref-manual/migration-3.2.rst +++ b/poky/documentation/ref-manual/migration-3.2.rst @@ -90,12 +90,12 @@ If you have anonymous python or in-line python conditionally adding dependencies in your custom recipes, and you intend for those recipes to work with multilib, then you will need to ensure that ``${MLPREFIX}`` is prefixed on the package names in the dependencies, for example -(from the ``glibc`` recipe): :: +(from the ``glibc`` recipe):: RRECOMMENDS_${PN} = "${@bb.utils.contains('DISTRO_FEATURES', 'ldconfig', '${MLPREFIX}ldconfig', '', d)}" This also applies when conditionally adding packages to :term:`PACKAGES` where -those packages have dependencies, for example (from the ``alsa-plugins`` recipe): :: +those packages have dependencies, for example (from the ``alsa-plugins`` recipe):: PACKAGES += "${@bb.utils.contains('PACKAGECONFIG', 'pulseaudio', 'alsa-plugins-pulseaudio-conf', '', d)}" ... @@ -229,7 +229,7 @@ needs ``/etc/ld.so.conf`` to be present at image build time: When some recipe installs libraries to a non-standard location, and therefore installs in a file in ``/etc/ld.so.conf.d/foo.conf``, we -need ``/etc/ld.so.conf`` containing: :: +need ``/etc/ld.so.conf`` containing:: include /etc/ld.so.conf.d/*.conf diff --git a/poky/documentation/ref-manual/qa-checks.rst b/poky/documentation/ref-manual/qa-checks.rst index 6cb767d93..9cc4c577c 100644 --- a/poky/documentation/ref-manual/qa-checks.rst +++ b/poky/documentation/ref-manual/qa-checks.rst @@ -221,8 +221,7 @@ Errors and Warnings Typically, the way to solve this performance issue is to add "-fPIC" or "-fpic" to the compiler command-line options. For example, given software that reads :term:`CFLAGS` when you build it, - you could add the following to your recipe: - :: + you could add the following to your recipe:: CFLAGS_append = " -fPIC " @@ -240,8 +239,7 @@ Errors and Warnings variable is being passed to the linker command. A common workaround for this situation is to pass in ``LDFLAGS`` using :term:`TARGET_CC_ARCH` within the recipe as - follows: - :: + follows:: TARGET_CC_ARCH += "${LDFLAGS}" @@ -265,8 +263,7 @@ Errors and Warnings The ``/usr/share/info/dir`` should not be packaged. Add the following line to your :ref:`ref-tasks-install` task or to your - ``do_install_append`` within the recipe as follows: - :: + ``do_install_append`` within the recipe as follows:: rm ${D}${infodir}/dir @@ -675,7 +672,7 @@ Errors and Warnings task. Patch fuzz is a situation when the ``patch`` tool ignores some of the context lines in order to apply the patch. Consider this example: - Patch to be applied: :: + Patch to be applied:: --- filename +++ filename @@ -687,7 +684,7 @@ Errors and Warnings context line 5 context line 6 - Original source code: :: + Original source code:: different context line 1 different context line 2 @@ -696,7 +693,7 @@ Errors and Warnings different context line 5 different context line 6 - Outcome (after applying patch with fuzz): :: + Outcome (after applying patch with fuzz):: different context line 1 different context line 2 @@ -716,14 +713,14 @@ Errors and Warnings *How to eliminate patch fuzz warnings* Use the ``devtool`` command as explained by the warning. First, unpack the - source into devtool workspace: :: + source into devtool workspace:: devtool modify <recipe> This will apply all of the patches, and create new commits out of them in the workspace - with the patch context updated. - Then, replace the patches in the recipe layer: :: + Then, replace the patches in the recipe layer:: devtool finish --force-patch-refresh <recipe> <layer_path> diff --git a/poky/documentation/ref-manual/structure.rst b/poky/documentation/ref-manual/structure.rst index 0f2093a8d..f8dc7d282 100644 --- a/poky/documentation/ref-manual/structure.rst +++ b/poky/documentation/ref-manual/structure.rst @@ -153,8 +153,7 @@ When you run this script, your Yocto Project environment is set up, a :term:`Build Directory` is created, your working directory becomes the Build Directory, and you are presented with some simple suggestions as to what to do next, including a list of some -possible targets to build. Here is an example: -:: +possible targets to build. Here is an example:: $ source oe-init-build-env @@ -185,8 +184,7 @@ creates the ``build/`` directory in your current working directory. If you provide a Build Directory argument when you ``source`` the script, you direct the OpenEmbedded build system to create a Build Directory of your choice. For example, the following command creates a Build -Directory named ``mybuilds/`` that is outside of the :term:`Source Directory`: -:: +Directory named ``mybuilds/`` that is outside of the :term:`Source Directory`:: $ source oe-init-build-env ~/mybuilds @@ -269,8 +267,7 @@ and to ``meta/conf/`` when you are building from the OpenEmbedded-Core environment. Because the script variable points to the source of the ``local.conf.sample`` file, this implies that you can configure your build environment from any layer by setting the variable in the -top-level build environment setup script as follows: -:: +top-level build environment setup script as follows:: TEMPLATECONF=your_layer/conf @@ -309,8 +306,7 @@ Project development environment, and to ``meta/conf/`` when you are building from the OpenEmbedded-Core environment. Because the script variable points to the source of the ``bblayers.conf.sample`` file, this implies that you can base your build from any layer by setting the -variable in the top-level build environment setup script as follows: -:: +variable in the top-level build environment setup script as follows:: TEMPLATECONF=your_layer/conf @@ -463,8 +459,7 @@ image again. If you do accidentally delete files here, you will need to force them to be re-created. In order to do that, you will need to know the target that produced them. For example, these commands rebuild and re-create -the kernel files: -:: +the kernel files:: $ bitbake -c clean virtual/kernel $ bitbake virtual/kernel @@ -535,8 +530,7 @@ recipe-specific :term:`WORKDIR` directories. Thus, the This directory holds information that BitBake uses for accounting purposes to track what tasks have run and when they have run. The directory is sub-divided by architecture, package name, and version. -Following is an example: -:: +Following is an example:: stamps/all-poky-linux/distcc-config/1.0-r0.do_build-2fdd....2do diff --git a/poky/documentation/ref-manual/system-requirements.rst b/poky/documentation/ref-manual/system-requirements.rst index 80378cedb..4fa4d3ef5 100644 --- a/poky/documentation/ref-manual/system-requirements.rst +++ b/poky/documentation/ref-manual/system-requirements.rst @@ -120,8 +120,7 @@ supported Ubuntu or Debian Linux distribution: might experience QEMU build failures due to the package installing its own custom ``/usr/include/linux/soundcard.h`` on the Debian system. If you run into this situation, either of the following - solutions exist: - :: + solutions exist:: $ sudo apt-get build-dep qemu $ sudo apt-get remove oss4-dev @@ -132,14 +131,12 @@ supported Ubuntu or Debian Linux distribution: $ sudo pip3 install GitPython pylint==1.9.5 -- *Essentials:* Packages needed to build an image on a headless system: - :: +- *Essentials:* Packages needed to build an image on a headless system:: $ sudo apt-get install &UBUNTU_HOST_PACKAGES_ESSENTIAL; - *Documentation:* Packages needed if you are going to build out the - Yocto Project documentation manuals: - :: + Yocto Project documentation manuals:: $ sudo apt-get install make python3-pip &PIP3_HOST_PACKAGES_DOC; @@ -157,14 +154,12 @@ The following list shows the required packages by function given a supported Fedora Linux distribution: - *Essentials:* Packages needed to build an image for a headless - system: - :: + system:: $ sudo dnf install &FEDORA_HOST_PACKAGES_ESSENTIAL; - *Documentation:* Packages needed if you are going to build out the - Yocto Project documentation manuals: - :: + Yocto Project documentation manuals:: $ sudo dnf install make python3-pip which &PIP3_HOST_PACKAGES_DOC; @@ -176,14 +171,12 @@ The following list shows the required packages by function given a supported openSUSE Linux distribution: - *Essentials:* Packages needed to build an image for a headless - system: - :: + system:: $ sudo zypper install &OPENSUSE_HOST_PACKAGES_ESSENTIAL; - *Documentation:* Packages needed if you are going to build out the - Yocto Project documentation manuals: - :: + Yocto Project documentation manuals:: $ sudo zypper install make python3-pip which &PIP3_HOST_PACKAGES_DOC; @@ -196,8 +189,7 @@ The following list shows the required packages by function given a supported CentOS-7 Linux distribution: - *Essentials:* Packages needed to build an image for a headless - system: - :: + system:: $ sudo yum install &CENTOS7_HOST_PACKAGES_ESSENTIAL; @@ -212,8 +204,7 @@ supported CentOS-7 Linux distribution: ``epel-release``. - *Documentation:* Packages needed if you are going to build out the - Yocto Project documentation manuals: - :: + Yocto Project documentation manuals:: $ sudo yum install make python3-pip which &PIP3_HOST_PACKAGES_DOC; @@ -225,8 +216,7 @@ The following list shows the required packages by function given a supported CentOS-8 Linux distribution: - *Essentials:* Packages needed to build an image for a headless - system: - :: + system:: $ sudo dnf install &CENTOS8_HOST_PACKAGES_ESSENTIAL; @@ -244,8 +234,7 @@ supported CentOS-8 Linux distribution: ``epel-release``. - *Documentation:* Packages needed if you are going to build out the - Yocto Project documentation manuals: - :: + Yocto Project documentation manuals:: $ sudo dnf install make python3-pip which &PIP3_HOST_PACKAGES_DOC; @@ -287,8 +276,7 @@ The ``install-buildtools`` script is the easiest of the three methods by which you can get these tools. It downloads a pre-built buildtools installer and automatically installs the tools for you: -1. Execute the ``install-buildtools`` script. Here is an example: - :: +1. Execute the ``install-buildtools`` script. Here is an example:: $ cd poky $ scripts/install-buildtools --without-extended-buildtools \ @@ -302,22 +290,19 @@ installer and automatically installs the tools for you: installation is functional. To avoid the need of ``sudo`` privileges, the ``install-buildtools`` - script will by default tell the installer to install in: - :: + script will by default tell the installer to install in:: /path/to/poky/buildtools If your host development system needs the additional tools provided in the ``buildtools-extended`` tarball, you can instead execute the - ``install-buildtools`` script with the default parameters: - :: + ``install-buildtools`` script with the default parameters:: $ cd poky $ scripts/install-buildtools 2. Source the tools environment setup script by using a command like the - following: - :: + following:: $ source /path/to/poky/buildtools/environment-setup-x86_64-pokysdk-linux @@ -342,13 +327,11 @@ steps: 1. Locate and download the ``*.sh`` at &YOCTO_RELEASE_DL_URL;/buildtools/ 2. Execute the installation script. Here is an example for the - traditional installer: - :: + traditional installer:: $ sh ~/Downloads/x86_64-buildtools-nativesdk-standalone-&DISTRO;.sh - Here is an example for the extended installer: - :: + Here is an example for the extended installer:: $ sh ~/Downloads/x86_64-buildtools-extended-nativesdk-standalone-&DISTRO;.sh @@ -357,8 +340,7 @@ steps: ``/home/your-username/buildtools`` 3. Source the tools environment setup script by using a command like the - following: - :: + following:: $ source /home/your_username/buildtools/environment-setup-i586-poky-linux @@ -390,13 +372,11 @@ installer: your build environment with the setup script (:ref:`structure-core-script`). -2. Run the BitBake command to build the tarball: - :: +2. Run the BitBake command to build the tarball:: $ bitbake buildtools-tarball - or run the BitBake command to build the extended tarball: - :: + or run the BitBake command to build the extended tarball:: $ bitbake buildtools-extended-tarball @@ -415,13 +395,11 @@ installer: 4. On the machine that does not meet the requirements, run the ``.sh`` file to install the tools. Here is an example for the traditional - installer: - :: + installer:: $ sh ~/Downloads/x86_64-buildtools-nativesdk-standalone-&DISTRO;.sh - Here is an example for the extended installer: - :: + Here is an example for the extended installer:: $ sh ~/Downloads/x86_64-buildtools-extended-nativesdk-standalone-&DISTRO;.sh @@ -430,8 +408,7 @@ installer: ``/home/your_username/buildtools`` 5. Source the tools environment setup script by using a command like the - following: - :: + following:: $ source /home/your_username/buildtools/environment-setup-x86_64-poky-linux diff --git a/poky/documentation/ref-manual/tasks.rst b/poky/documentation/ref-manual/tasks.rst index 9fe1c296a..001edf6bb 100644 --- a/poky/documentation/ref-manual/tasks.rst +++ b/poky/documentation/ref-manual/tasks.rst @@ -93,8 +93,7 @@ output from ``${DEPLOYDIR}`` to ``${DEPLOY_DIR_IMAGE}``. The ``do_deploy`` task is not added as a task by default and consequently needs to be added manually. If you want the task to run after :ref:`ref-tasks-compile`, you can add it by doing -the following: -:: +the following:: addtask deploy after do_compile @@ -103,8 +102,7 @@ Adding ``do_deploy`` after other tasks works the same way. .. note:: You do not need to add ``before do_build`` to the ``addtask`` command - (though it is harmless), because the ``base`` class contains the following: - :: + (though it is harmless), because the ``base`` class contains the following:: do_build[recrdeptask] += "do_deploy" @@ -302,13 +300,11 @@ Patch files, by default, are ``*.patch`` and ``*.diff`` files created and kept in a subdirectory of the directory holding the recipe file. For example, consider the :yocto_git:`bluez5 </poky/tree/meta/recipes-connectivity/bluez5>` -recipe from the OE-Core layer (i.e. ``poky/meta``): -:: +recipe from the OE-Core layer (i.e. ``poky/meta``):: poky/meta/recipes-connectivity/bluez5 -This recipe has two patch files located here: -:: +This recipe has two patch files located here:: poky/meta/recipes-connectivity/bluez5/bluez5 @@ -323,8 +319,7 @@ and patch files needed to build the package. As mentioned earlier, the build system treats files whose file types are ``.patch`` and ``.diff`` as patch files. However, you can use the "apply=yes" parameter with the ``SRC_URI`` statement to indicate any -file as a patch file: -:: +file as a patch file:: SRC_URI = " \ git://path_to_repo/some_package \ @@ -334,8 +329,7 @@ file as a patch file: Conversely, if you have a directory full of patch files and you want to exclude some so that the ``do_patch`` task does not apply them during the patch phase, you can use the "apply=no" parameter with the -``SRC_URI`` statement: -:: +``SRC_URI`` statement:: SRC_URI = " \ git://path_to_repo/some_package \ @@ -455,8 +449,7 @@ of the recipe exists upstream and a status of not updated, updated, or unknown. To check the upstream version and status of a recipe, use the following -devtool commands: -:: +devtool commands:: $ devtool latest-version $ devtool check-upgrade-status @@ -467,8 +460,7 @@ chapter for more information on section for information on checking the upgrade status of a recipe. To build the ``checkpkg`` task, use the ``bitbake`` command with the -"-c" option and task name: -:: +"-c" option and task name:: $ bitbake core-image-minimal -c checkpkg @@ -494,8 +486,7 @@ Removes all output files for a target from the :ref:`ref-tasks-install`, and :ref:`ref-tasks-package`). -You can run this task using BitBake as follows: -:: +You can run this task using BitBake as follows:: $ bitbake -c clean recipe @@ -519,8 +510,7 @@ downloaded source files for a target (i.e. the contents of identical to the :ref:`ref-tasks-cleansstate` task with the added removal of downloaded source files. -You can run this task using BitBake as follows: -:: +You can run this task using BitBake as follows:: $ bitbake -c cleanall recipe @@ -540,8 +530,7 @@ target. Essentially, the ``do_cleansstate`` task is identical to the shared state (:ref:`sstate <overview-manual/concepts:shared state cache>`) cache. -You can run this task using BitBake as follows: -:: +You can run this task using BitBake as follows:: $ bitbake -c cleansstate recipe @@ -553,8 +542,7 @@ scratch is guaranteed. The ``do_cleansstate`` task cannot remove sstate from a remote sstate mirror. If you need to build a target from scratch using remote mirrors, use - the "-f" option as follows: - :: + the "-f" option as follows:: $ bitbake -f -c do_cleansstate target @@ -687,8 +675,7 @@ changes made by the user with other methods (i.e. using (:ref:`ref-tasks-kernel_menuconfig`). Once the file of differences is created, it can be used to create a config fragment that only contains the differences. You can invoke this task -from the command line as follows: -:: +from the command line as follows:: $ bitbake linux-yocto -c diffconfig @@ -718,8 +705,7 @@ Validates the configuration produced by the configuration does not appear in the final ``.config`` file or when you override a policy configuration in a hardware configuration fragment. You can run this task explicitly and view the output by using the -following command: -:: +following command:: $ bitbake linux-yocto -c kernel_configcheck -f @@ -750,8 +736,7 @@ tool, which you then use to modify the kernel configuration. .. note:: - You can also invoke this tool from the command line as follows: - :: + You can also invoke this tool from the command line as follows:: $ bitbake linux-yocto -c menuconfig @@ -793,8 +778,7 @@ instead of the default defconfig. The saved defconfig contains the differences between the default defconfig and the changes made by the user using other methods (i.e. the :ref:`ref-tasks-kernel_menuconfig` task. You -can invoke the task using the following command: -:: +can invoke the task using the following command:: $ bitbake linux-yocto -c savedefconfig diff --git a/poky/documentation/ref-manual/terms.rst b/poky/documentation/ref-manual/terms.rst index 32bb75b27..0af9af648 100644 --- a/poky/documentation/ref-manual/terms.rst +++ b/poky/documentation/ref-manual/terms.rst @@ -26,8 +26,7 @@ universal, the list includes them just in case: When you name an append file, you can use the "``%``" wildcard character to allow for matching recipe names. For example, suppose you have an - append file named as follows: - :: + append file named as follows:: busybox_1.21.%.bbappend diff --git a/poky/documentation/ref-manual/variables.rst b/poky/documentation/ref-manual/variables.rst index 74ac12bf9..c339d45e1 100644 --- a/poky/documentation/ref-manual/variables.rst +++ b/poky/documentation/ref-manual/variables.rst @@ -24,8 +24,7 @@ system and gives an overview of their function and contents. ABI extensions are set in the machine include files. For example, the ``meta/conf/machine/include/arm/arch-arm.inc`` file sets the - following extension: - :: + following extension:: ABIEXTENSION = "eabi" @@ -37,8 +36,7 @@ system and gives an overview of their function and contents. requirement on the existence of the package. Like all package-controlling variables, you must always use them in - conjunction with a package name override, as in: - :: + conjunction with a package name override, as in:: ALLOW_EMPTY_${PN} = "1" ALLOW_EMPTY_${PN}-dev = "1" @@ -54,8 +52,7 @@ system and gives an overview of their function and contents. To use the variable, list out the package's commands that also exist as part of another package. For example, if the ``busybox`` package has four commands that also exist as part of another package, you - identify them as follows: - :: + identify them as follows:: ALTERNATIVE_busybox = "sh sed test bracket" @@ -68,8 +65,7 @@ system and gives an overview of their function and contents. locations. For example, if the ``bracket`` command provided by the ``busybox`` package is duplicated through another package, you must use the ``ALTERNATIVE_LINK_NAME`` variable to specify the actual - location: - :: + location:: ALTERNATIVE_LINK_NAME[bracket] = "/usr/bin/[" @@ -90,8 +86,7 @@ system and gives an overview of their function and contents. default regardless of the command name or package, a default for specific duplicated commands regardless of the package, or a default for specific commands tied to particular packages. Here are the - available syntax forms: - :: + available syntax forms:: ALTERNATIVE_PRIORITY = "priority" ALTERNATIVE_PRIORITY[name] = "priority" @@ -107,8 +102,7 @@ system and gives an overview of their function and contents. default location for all duplicated commands regardless of the command name or package, a default for specific duplicated commands regardless of the package, or a default for specific commands tied to - particular packages. Here are the available syntax forms: - :: + particular packages. Here are the available syntax forms:: ALTERNATIVE_TARGET = "target" ALTERNATIVE_TARGET[name] = "target" @@ -159,8 +153,7 @@ system and gives an overview of their function and contents. determines the type of information used to create a released archive. You can use this variable to create archives of patched source, original source, configured source, and so forth by employing the - following variable flags (varflags): - :: + following variable flags (varflags):: ARCHIVER_MODE[src] = "original" # Uses original (unpacked) source files. ARCHIVER_MODE[src] = "patched" # Uses patched source files. This is the default. @@ -193,14 +186,12 @@ system and gives an overview of their function and contents. system. Separate multiple entries using spaces. As an example, use the following form to add an ``shlib`` provider of - shlibname in packagename with the optional version: - :: + shlibname in packagename with the optional version:: shlibname:packagename[_version] Here is an example that adds a shared library named ``libEGL.so.1`` - as being provided by the ``libegl-implementation`` package: - :: + as being provided by the ``libegl-implementation`` package:: ASSUME_SHLIBS = "libEGL.so.1:libegl-implementation" @@ -224,8 +215,7 @@ system and gives an overview of their function and contents. :term:`AUTOREV` When ``SRCREV`` is set to the value of this variable, it specifies to - use the latest source revision in the repository. Here is an example: - :: + use the latest source revision in the repository. Here is an example:: SRCREV = "${AUTOREV}" @@ -286,8 +276,7 @@ system and gives an overview of their function and contents. The directory within the :term:`Build Directory` in which the OpenEmbedded build system places generated objects during a recipe's build process. By default, this directory is the same as the - :term:`S` directory, which is defined as: - :: + :term:`S` directory, which is defined as:: S = "${WORKDIR}/${BP}" @@ -301,15 +290,13 @@ system and gives an overview of their function and contents. packages are packages installed only through the :term:`RRECOMMENDS` variable. You can prevent any of these "recommended" packages from being installed by listing them - with the ``BAD_RECOMMENDATIONS`` variable: - :: + with the ``BAD_RECOMMENDATIONS`` variable:: BAD_RECOMMENDATIONS = "package_name package_name package_name ..." You can set this variable globally in your ``local.conf`` file or you can attach it to a specific image recipe by using the recipe name - override: - :: + override:: BAD_RECOMMENDATIONS_pn-target_image = "package_name" @@ -394,8 +381,7 @@ system and gives an overview of their function and contents. You can change the default behavior by setting this variable to "1", "yes", or "true" in your ``local.conf`` file, which is located in the - :term:`Build Directory`: Here is an example: - :: + :term:`Build Directory`: Here is an example:: BB_DANGLINGAPPENDS_WARNONLY = "1" @@ -444,8 +430,7 @@ system and gives an overview of their function and contents. not specify G, M, or K, Kbytes is assumed by default. Do not use GB, MB, or KB. - Here are some examples: - :: + Here are some examples:: BB_DISKMON_DIRS = "ABORT,${TMPDIR},1G,100K WARN,${SSTATE_DIR},1G,100K" BB_DISKMON_DIRS = "STOPTASKS,${TMPDIR},1G" @@ -485,8 +470,7 @@ system and gives an overview of their function and contents. If you do not provide a ``BB_DISKMON_WARNINTERVAL`` variable and you do use ``BB_DISKMON_DIRS`` with the "WARN" action, the disk - monitoring interval defaults to the following: - :: + monitoring interval defaults to the following:: BB_DISKMON_WARNINTERVAL = "50M,5K" @@ -509,8 +493,7 @@ system and gives an overview of their function and contents. G, M, or K for Gbytes, Mbytes, or Kbytes, respectively. You cannot use GB, MB, or KB. - Here is an example: - :: + Here is an example:: BB_DISKMON_DIRS = "WARN,${SSTATE_DIR},1G,100K" BB_DISKMON_WARNINTERVAL = "50M,5K" @@ -566,8 +549,7 @@ system and gives an overview of their function and contents. long the BitBake server stays resident between invocations. For example, the following statement in your ``local.conf`` file - instructs the server to be unloaded after 20 seconds of inactivity: - :: + instructs the server to be unloaded after 20 seconds of inactivity:: BB_SERVER_TIMEOUT = "20" @@ -585,8 +567,7 @@ system and gives an overview of their function and contents. "``multilib:``\ multilib_name". To build a different variant of the recipe with a minimal amount of - code, it usually is as simple as adding the following to your recipe: - :: + code, it usually is as simple as adding the following to your recipe:: BBCLASSEXTEND =+ "native nativesdk" BBCLASSEXTEND =+ "multilib:multilib_name" @@ -662,8 +643,7 @@ system and gives an overview of their function and contents. Use the following form for ``BBFILES_DYNAMIC``: collection_name:filename_pattern The following example identifies two - collection names and two filename patterns: - :: + collection names and two filename patterns:: BBFILES_DYNAMIC += " \ clang-layer:${LAYERDIR}/bbappends/meta-clang/*/*/*.bbappend \ @@ -691,8 +671,7 @@ system and gives an overview of their function and contents. :term:`BBLAYERS` Lists the layers to enable during the build. This variable is defined in the ``bblayers.conf`` configuration file in the :term:`Build Directory`. - Here is an example: - :: + Here is an example:: BBLAYERS = " \ /home/scottrif/poky/meta \ @@ -721,14 +700,13 @@ system and gives an overview of their function and contents. The following example uses a complete regular expression to tell BitBake to ignore all recipe and recipe append files in the - ``meta-ti/recipes-misc/`` directory: - :: + ``meta-ti/recipes-misc/`` directory:: BBMASK = "meta-ti/recipes-misc/" If you want to mask out multiple directories or recipes, you can specify multiple regular expression fragments. This next example - masks out multiple directories and individual recipes: :: + masks out multiple directories and individual recipes:: BBMASK += "/meta-ti/recipes-misc/ meta-ti/recipes-ti/packagegroup/" BBMASK += "/meta-oe/recipes-support/" @@ -746,8 +724,7 @@ system and gives an overview of their function and contents. building targets with multiple configurations. Use this variable in your ``conf/local.conf`` configuration file. Specify a multiconfigname for each configuration file you are using. For - example, the following line specifies three configuration files: - :: + example, the following line specifies three configuration files:: BBMULTICONFIG = "configA configB configC" @@ -770,8 +747,7 @@ system and gives an overview of their function and contents. If you run BitBake from a directory outside of the :term:`Build Directory`, you must be sure to set ``BBPATH`` to point to the Build Directory. Set the variable as you would any - environment variable and then run BitBake: - :: + environment variable and then run BitBake:: $ BBPATH = "build_directory" $ export BBPATH @@ -783,8 +759,7 @@ system and gives an overview of their function and contents. BitBake remote server. Use the following format to export the variable to the BitBake - environment: - :: + environment:: export BBSERVER=localhost:$port @@ -803,8 +778,7 @@ system and gives an overview of their function and contents. replaced. To add multiple scripts, separate them by spaces. Here is an example - from the ``libpng`` recipe: - :: + from the ``libpng`` recipe:: BINCONFIG = "${bindir}/libpng-config ${bindir}/libpng16-config" @@ -834,8 +808,7 @@ system and gives an overview of their function and contents. :term:`BP` The base recipe name and version but without any special recipe name suffix (i.e. ``-native``, ``lib64-``, and so forth). ``BP`` is - comprised of the following: - :: + comprised of the following:: ${BPN}-${PV} @@ -975,8 +948,7 @@ system and gives an overview of their function and contents. you should set this value to "1". By default, the ``buildhistory`` class does not commit the build - history output in a local Git repository: - :: + history output in a local Git repository:: BUILDHISTORY_COMMIT ?= "0" @@ -992,8 +964,7 @@ system and gives an overview of their function and contents. email@host". Providing an email address or host that is not valid does not produce an error. - By default, the ``buildhistory`` class sets the variable as follows: - :: + By default, the ``buildhistory`` class sets the variable as follows:: BUILDHISTORY_COMMIT_AUTHOR ?= "buildhistory <buildhistory@${DISTRO}>" @@ -1003,8 +974,7 @@ system and gives an overview of their function and contents. information is kept. For more information on how the variable works, see the ``buildhistory.class``. - By default, the ``buildhistory`` class sets the directory as follows: - :: + By default, the ``buildhistory`` class sets the directory as follows:: BUILDHISTORY_DIR ?= "${TOPDIR}/buildhistory" @@ -1032,8 +1002,7 @@ system and gives an overview of their function and contents. each file staged (i.e. the output of the task). By default, the ``buildhistory`` class enables the following - features: - :: + features:: BUILDHISTORY_FEATURES ?= "image package sdk" @@ -1049,8 +1018,7 @@ system and gives an overview of their function and contents. Consequently, you can include files that might not always be present. By default, the ``buildhistory`` class provides paths to the - following files: - :: + following files:: BUILDHISTORY_IMAGE_FILES ?= "/etc/passwd /etc/group" @@ -1067,8 +1035,7 @@ system and gives an overview of their function and contents. that you have set up manually using ``git remote`` within the local repository. - By default, the ``buildhistory`` class sets the variable as follows: - :: + By default, the ``buildhistory`` class sets the variable as follows:: BUILDHISTORY_PUSH_REPO ?= "" @@ -1152,8 +1119,7 @@ system and gives an overview of their function and contents. ``bitbake.conf`` file. As an example, the following override allows you to install extra - files, but only when building for the target: - :: + files, but only when building for the target:: do_install_append_class-target() { install my-extra-file ${D}${sysconfdir} @@ -1161,8 +1127,7 @@ system and gives an overview of their function and contents. Here is an example where ``FOO`` is set to "native" when building for the build host, and to "other" when not - building for the build host: - :: + building for the build host:: FOO_class-native = "native" FOO = "other" @@ -1235,8 +1200,7 @@ system and gives an overview of their function and contents. To add a new feature item pointing to a wildcard, use a variable flag to specify the feature item name and use the value to specify the - wildcard. Here is an example: - :: + wildcard. Here is an example:: COMPLEMENTARY_GLOB[dev-pkgs] = '*-dev' @@ -1268,8 +1232,7 @@ system and gives an overview of their function and contents. To use the ``CONFFILES`` variable, provide a package name override that identifies the resulting package. Then, provide a - space-separated list of files. Here is an example: - :: + space-separated list of files. Here is an example:: CONFFILES_${PN} += "${sysconfdir}/file1 \ ${sysconfdir}/file2 ${sysconfdir}/file3" @@ -1524,8 +1487,7 @@ system and gives an overview of their function and contents. The destination directory. The location in the :term:`Build Directory` where components are installed by the :ref:`ref-tasks-install` task. This location defaults - to: - :: + to:: ${WORKDIR}/image @@ -1547,8 +1509,7 @@ system and gives an overview of their function and contents. which is the default behavior, ``DEBIAN_NOAUTONAME`` specifies a particular package should not be renamed according to Debian library package naming. You must use the package name as an override when you - set this variable. Here is an example from the ``fontconfig`` recipe: - :: + set this variable. Here is an example from the ``fontconfig`` recipe:: DEBIAN_NOAUTONAME_fontconfig-utils = "1" @@ -1558,17 +1519,10 @@ system and gives an overview of their function and contents. the library name for an individual package. Overriding the library name in these cases is rare. You must use the package name as an override when you set this variable. Here is an example from the - ``dbus`` recipe: - :: + ``dbus`` recipe:: DEBIANNAME_${PN} = "dbus-1" - :term:`DEBUGINFOD_URLS` - Points to the URL of the "debuginfod" server. Such that for every - debugging information lookup, the debuginfod client will query the - server and return the requested information. You set this variable - in your ``local.conf`` file. - :term:`DEBUG_BUILD` Specifies to build packages with debugging information. This influences the value of the ``SELECTED_OPTIMIZATION`` variable. @@ -1610,8 +1564,7 @@ system and gives an overview of their function and contents. needed by the recipe at build time. As an example, consider a recipe ``foo`` that contains the following - assignment: - :: + assignment:: DEPENDS = "bar" @@ -1635,8 +1588,7 @@ system and gives an overview of their function and contents. As another example, ``DEPENDS`` can also be used to add utilities that run on the build machine during the build. For example, a recipe that makes use of a code generator built by the recipe ``codegen`` - might have the following: - :: + might have the following:: DEPENDS = "codegen-native" @@ -1702,8 +1654,7 @@ system and gives an overview of their function and contents. The BitBake configuration file initially defines the ``DEPLOY_DIR_DEB`` variable as a sub-folder of - :term:`DEPLOY_DIR`: - :: + :term:`DEPLOY_DIR`:: DEPLOY_DIR_DEB = "${DEPLOY_DIR}/deb" @@ -1738,8 +1689,7 @@ system and gives an overview of their function and contents. "package_ipk". The BitBake configuration file initially defines this variable as a - sub-folder of :term:`DEPLOY_DIR`: - :: + sub-folder of :term:`DEPLOY_DIR`:: DEPLOY_DIR_IPK = "${DEPLOY_DIR}/ipk" @@ -1759,8 +1709,7 @@ system and gives an overview of their function and contents. "package_rpm". The BitBake configuration file initially defines this variable as a - sub-folder of :term:`DEPLOY_DIR`: - :: + sub-folder of :term:`DEPLOY_DIR`:: DEPLOY_DIR_RPM = "${DEPLOY_DIR}/rpm" @@ -1780,8 +1729,7 @@ system and gives an overview of their function and contents. "package_tar". The BitBake configuration file initially defines this variable as a - sub-folder of :term:`DEPLOY_DIR`: - :: + sub-folder of :term:`DEPLOY_DIR`:: DEPLOY_DIR_TAR = "${DEPLOY_DIR}/tar" @@ -1796,8 +1744,7 @@ system and gives an overview of their function and contents. :term:`DEPLOYDIR` When inheriting the :ref:`deploy <ref-classes-deploy>` class, the ``DEPLOYDIR`` points to a temporary work area for deployed files that - is set in the ``deploy`` class as follows: - :: + is set in the ``deploy`` class as follows:: DEPLOYDIR = "${WORKDIR}/deploy-${PN}" @@ -1824,8 +1771,7 @@ system and gives an overview of their function and contents. :term:`Source Directory`. Within that ``poky.conf`` file, the ``DISTRO`` variable is set as - follows: - :: + follows:: DISTRO = "poky" @@ -1899,8 +1845,7 @@ system and gives an overview of their function and contents. able to reuse the default :term:`DISTRO_FEATURES` options without the need to write out the full set. Here is an example that uses - ``DISTRO_FEATURES_DEFAULT`` from a custom distro configuration file: - :: + ``DISTRO_FEATURES_DEFAULT`` from a custom distro configuration file:: DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} myfeature" @@ -1948,8 +1893,7 @@ system and gives an overview of their function and contents. of the :term:`Source Directory`. Within that ``poky.conf`` file, the ``DISTRO_NAME`` variable is set - as follows: - :: + as follows:: DISTRO_NAME = "Poky (Yocto Project Reference Distro)" @@ -2065,8 +2009,7 @@ system and gives an overview of their function and contents. You can set ``ERR_REPORT_DIR`` to the path you want the error reporting tool to store the debug files as follows in your - ``local.conf`` file: - :: + ``local.conf`` file:: ERR_REPORT_DIR = "path" @@ -2094,8 +2037,7 @@ system and gives an overview of their function and contents. package's particular libraries only and not the whole package. Use the ``EXCLUDE_FROM_SHLIBS`` variable by setting it to "1" for a - particular package: - :: + particular package:: EXCLUDE_FROM_SHLIBS = "1" @@ -2129,8 +2071,7 @@ system and gives an overview of their function and contents. The full package version specification as it appears on the final packages produced by a recipe. The variable's value is normally used to fix a runtime dependency to the exact same version of another - package in the same recipe: - :: + package in the same recipe:: RDEPENDS_${PN}-additional-module = "${PN} (= ${EXTENDPKGV})" @@ -2230,8 +2171,7 @@ system and gives an overview of their function and contents. Specifies additional options for the image creation command that has been specified in :term:`IMAGE_CMD`. When setting this variable, use an override for the associated image type. Here is - an example: - :: + an example:: EXTRA_IMAGECMD_ext3 ?= "-i 4096" @@ -2255,8 +2195,7 @@ system and gives an overview of their function and contents. added to the beginning of the environment variable ``PATH``. As an example, the following prepends "${STAGING_BINDIR_NATIVE}/foo:${STAGING_BINDIR_NATIVE}/bar:" to - ``PATH``: - :: + ``PATH``:: EXTRANATIVEPATH = "foo bar" @@ -2294,8 +2233,7 @@ system and gives an overview of their function and contents. The set list of commands you can configure using the ``EXTRA_USERS_PARAMS`` is shown in the ``extrausers`` class. These - commands map to the normal Unix commands of the same names: - :: + commands map to the normal Unix commands of the same names:: # EXTRA_USERS_PARAMS = "\ # useradd -p '' tester; \ @@ -2321,8 +2259,7 @@ system and gives an overview of their function and contents. Defines one or more packages to include in an image when a specific item is included in :term:`IMAGE_FEATURES`. When setting the value, ``FEATURE_PACKAGES`` should have the name of - the feature item as an override. Here is an example: - :: + the feature item as an override. Here is an example:: FEATURE_PACKAGES_widget = "package1 package2" @@ -2342,8 +2279,7 @@ system and gives an overview of their function and contents. OPKG to support runtime package management of IPK packages. You set this variable in your ``local.conf`` file. - Consider the following example: - :: + Consider the following example:: FEED_DEPLOYDIR_BASE_URI = "http://192.168.7.1/BOARD-dir" @@ -2362,8 +2298,7 @@ system and gives an overview of their function and contents. To use the ``FILES`` variable, provide a package name override that identifies the resulting package. Then, provide a space-separated list of files or paths that identify the files you want included as - part of the resulting package. Here is an example: - :: + part of the resulting package. Here is an example:: FILES_${PN} += "${bindir}/mydir1 ${bindir}/mydir2/myfile" @@ -2398,8 +2333,7 @@ system and gives an overview of their function and contents. symbolic link (symlink) for shared libraries on the target platform. The following statement from the ``bitbake.conf`` shows how it is - set: - :: + set:: FILES_SOLIBSDEV ?= "${base_libdir}/lib*${SOLIBSDEV} ${libdir}/lib*${SOLIBSDEV}" @@ -2413,8 +2347,7 @@ system and gives an overview of their function and contents. Best practices dictate that you accomplish this by using ``FILESEXTRAPATHS`` from within a ``.bbappend`` file and that you - prepend paths as follows: - :: + prepend paths as follows:: FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" @@ -2436,8 +2369,7 @@ system and gives an overview of their function and contents. are directing BitBake to extend the path by prepending directories to the search path. - Here is another common use: - :: + Here is another common use:: FILESEXTRAPATHS_prepend := "${THISDIR}/files:" @@ -2445,15 +2377,13 @@ system and gives an overview of their function and contents. ``FILESPATH`` variable to include a directory named ``files`` that is in the same directory as the corresponding append file. - This next example specifically adds three paths: - :: + This next example specifically adds three paths:: FILESEXTRAPATHS_prepend := "path_1:path_2:path_3:" A final example shows how you can extend the search path and include a :term:`MACHINE`-specific override, which is useful - in a BSP layer: - :: + in a BSP layer:: FILESEXTRAPATHS_prepend_intel-x86-common := "${THISDIR}/${PN}:" @@ -2485,8 +2415,7 @@ system and gives an overview of their function and contents. ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:conditional syntax (overrides)`" section of the BitBake User Manual. - By default, the ``FILESOVERRIDES`` variable is defined as: - :: + By default, the ``FILESOVERRIDES`` variable is defined as:: FILESOVERRIDES = "${TRANSLATED_TARGET_ARCH}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}" @@ -2507,8 +2436,7 @@ system and gives an overview of their function and contents. The default value for the ``FILESPATH`` variable is defined in the ``base.bbclass`` class found in ``meta/classes`` in the - :term:`Source Directory`: - :: + :term:`Source Directory`:: FILESPATH = "${@base_set_filespath(["${FILE_DIRNAME}/${BP}", \ "${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}" @@ -2533,8 +2461,7 @@ system and gives an overview of their function and contents. You can take advantage of this searching behavior in useful ways. For example, consider a case where the following directory structure - exists for general and machine-specific configurations: - :: + exists for general and machine-specific configurations:: files/defconfig files/MACHINEA/defconfig @@ -2662,16 +2589,14 @@ system and gives an overview of their function and contents. Programming (ROP) attacks much more difficult to execute. By default the ``security_flags.inc`` file enables PIE by setting the - variable as follows: - :: + variable as follows:: GCCPIE ?= "--enable-default-pie" :term:`GCCVERSION` Specifies the default version of the GNU C Compiler (GCC) used for compilation. By default, ``GCCVERSION`` is set to "8.x" in the - ``meta/conf/distro/include/tcmode-default.inc`` include file: - :: + ``meta/conf/distro/include/tcmode-default.inc`` include file:: GCCVERSION ?= "8.%" @@ -2706,8 +2631,7 @@ system and gives an overview of their function and contents. passed to the ``groupadd`` command if you wish to add a group to the system when the package is installed. - Here is an example from the ``dbus`` recipe: - :: + Here is an example from the ``dbus`` recipe:: GROUPADD_PARAM_${PN} = "-r netdev" @@ -2855,13 +2779,11 @@ system and gives an overview of their function and contents. section. Setting this variable to "1" in your ``local.conf`` disables the - function: - :: + function:: ICECC_DISABLED ??= "1" - To enable the function, set the variable as follows: - :: + To enable the function, set the variable as follows:: ICECC_DISABLED = "" @@ -2946,8 +2868,7 @@ system and gives an overview of their function and contents. installed name, separate it from the original name with a semi-colon (;). Source files need to be located in :term:`DEPLOY_DIR_IMAGE`. Here are two - examples: - :: + examples:: IMAGE_EFI_BOOT_FILES = "${KERNEL_IMAGETYPE};bz2" IMAGE_EFI_BOOT_FILES = "${KERNEL_IMAGETYPE} microcode.cpio" @@ -2956,8 +2877,7 @@ system and gives an overview of their function and contents. this case, the destination file must have the same name as the base name of the source file path. To install files into a directory within the target location, pass its name after a semi-colon (;). - Here are two examples: - :: + Here are two examples:: IMAGE_EFI_BOOT_FILES = "boot/loader/*" IMAGE_EFI_BOOT_FILES = "boot/loader/*;boot/" @@ -2982,8 +2902,7 @@ system and gives an overview of their function and contents. installed name, separate it from the original name with a semi-colon (;). Source files need to be located in :term:`DEPLOY_DIR_IMAGE`. Here are two - examples: - :: + examples:: IMAGE_BOOT_FILES = "u-boot.img uImage;kernel" IMAGE_BOOT_FILES = "u-boot.${UBOOT_SUFFIX} ${KERNEL_IMAGETYPE}" @@ -2992,8 +2911,7 @@ system and gives an overview of their function and contents. this case, the destination file must have the same name as the base name of the source file path. To install files into a directory within the target location, pass its name after a semi-colon (;). - Here are two examples: - :: + Here are two examples:: IMAGE_BOOT_FILES = "bcm2835-bootfiles/*" IMAGE_BOOT_FILES = "bcm2835-bootfiles/*;boot/" @@ -3026,8 +2944,7 @@ system and gives an overview of their function and contents. type, which corresponds to the value set in :term:`IMAGE_FSTYPES`, (e.g. ``ext3``, ``btrfs``, and so forth). When setting this variable, you should use - an override for the associated type. Here is an example: - :: + an override for the associated type. Here is an example:: IMAGE_CMD_jffs2 = "mkfs.jffs2 --root=${IMAGE_ROOTFS} \ --faketime --output=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.jffs2 \ @@ -3071,8 +2988,7 @@ system and gives an overview of their function and contents. Specifies the formats the OpenEmbedded build system uses during the build when creating the root filesystem. For example, setting ``IMAGE_FSTYPES`` as follows causes the build system to create root - filesystems using two formats: ``.ext3`` and ``.tar.bz2``: - :: + filesystems using two formats: ``.ext3`` and ``.tar.bz2``:: IMAGE_FSTYPES = "ext3 tar.bz2" @@ -3103,8 +3019,7 @@ system and gives an overview of their function and contents. auto-generated entries in ``IMAGE_INSTALL`` in addition to its default contents. - When you use this variable, it is best to use it as follows: - :: + When you use this variable, it is best to use it as follows:: IMAGE_INSTALL_append = " package-name" @@ -3147,8 +3062,7 @@ system and gives an overview of their function and contents. into separate packages. Setting the ``IMAGE_LINGUAS`` variable ensures that any locale packages that correspond to packages already selected for installation into the image are also installed. Here is - an example: - :: + an example:: IMAGE_LINGUAS = "pt-br de-de" @@ -3167,8 +3081,7 @@ system and gives an overview of their function and contents. The name of the output image symlink (which does not include the version part as :term:`IMAGE_NAME` does). The default value is derived using the :term:`IMAGE_BASENAME` and :term:`MACHINE` - variables: - :: + variables:: IMAGE_LINK_NAME ?= "${IMAGE_BASENAME}-${MACHINE}" @@ -3176,14 +3089,12 @@ system and gives an overview of their function and contents. :term:`IMAGE_MANIFEST` The manifest file for the image. This file lists all the installed packages that make up the image. The file contains package - information on a line-per-package basis as follows: - :: + information on a line-per-package basis as follows:: packagename packagearch version The :ref:`image <ref-classes-image>` class defines the manifest - file as follows: - :: + file as follows:: IMAGE_MANIFEST ="${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.manifest" @@ -3197,8 +3108,7 @@ system and gives an overview of their function and contents. The name of the output image files minus the extension. This variable is derived using the :term:`IMAGE_BASENAME`, :term:`MACHINE`, and :term:`IMAGE_VERSION_SUFFIX` - variables: - :: + variables:: IMAGE_NAME ?= "${IMAGE_BASENAME}-${MACHINE}${IMAGE_VERSION_SUFFIX}" @@ -3229,8 +3139,7 @@ system and gives an overview of their function and contents. to boot and allows for basic post installs while still leaving a small amount of free disk space. If 30% free space is inadequate, you can increase the default value. For example, the following setting - gives you 50% free space added to the image: - :: + gives you 50% free space added to the image:: IMAGE_OVERHEAD_FACTOR = "1.5" @@ -3271,8 +3180,7 @@ system and gives an overview of their function and contents. :term:`IMAGE_POSTPROCESS_COMMAND` Specifies a list of functions to call once the OpenEmbedded build system creates the final image output files. You can specify - functions separated by semicolons: - :: + functions separated by semicolons:: IMAGE_POSTPROCESS_COMMAND += "function; ... " @@ -3285,8 +3193,7 @@ system and gives an overview of their function and contents. :term:`IMAGE_PREPROCESS_COMMAND` Specifies a list of functions to call before the OpenEmbedded build system creates the final image output files. You can specify - functions separated by semicolons: - :: + functions separated by semicolons:: IMAGE_PREPROCESS_COMMAND += "function; ... " @@ -3317,14 +3224,12 @@ system and gives an overview of their function and contents. This variable is particularly useful when you want to ensure that a specific amount of free disk space is available on a device after an image is installed and running. For example, to be sure 5 Gbytes of - free disk space is available, set the variable as follows: - :: + free disk space is available, set the variable as follows:: IMAGE_ROOTFS_EXTRA_SPACE = "5242880" For example, the Yocto Project Build Appliance specifically requests - 40 Gbytes of extra space with the line: - :: + 40 Gbytes of extra space with the line:: IMAGE_ROOTFS_EXTRA_SPACE = "41943040" @@ -3335,8 +3240,7 @@ system and gives an overview of their function and contents. the generated image, a requested size for the image, and requested additional free disk space to be added to the image. Programatically, the build system determines the final size of the generated image as - follows: - :: + follows:: if (image-du * overhead) < rootfs-size: internal-rootfs-size = rootfs-size + xspace @@ -3355,8 +3259,7 @@ system and gives an overview of their function and contents. :term:`IMAGE_TYPEDEP` Specifies a dependency from one image type on another. Here is an - example from the :ref:`image-live <ref-classes-image-live>` class: - :: + example from the :ref:`image-live <ref-classes-image-live>` class:: IMAGE_TYPEDEP_live = "ext3" @@ -3443,8 +3346,7 @@ system and gives an overview of their function and contents. variable. Once the variable is defined in the ``include`` file, you can use the variable to set the ``PR`` values in each recipe. You will notice that when you set a recipe's ``PR`` you can provide more - granular revisioning by appending values to the ``INC_PR`` variable: - :: + granular revisioning by appending values to the ``INC_PR`` variable:: recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR = "r2" recipes-graphics/xorg-font/encodings_1.0.4.bb:PR = "${INC_PR}.1" @@ -3467,8 +3369,7 @@ system and gives an overview of their function and contents. .. note:: This functionality is only regularly tested using the following - setting: - :: + setting:: INCOMPATIBLE_LICENSE = "GPL-3.0 LGPL-3.0 AGPL-3.0" @@ -3482,8 +3383,7 @@ system and gives an overview of their function and contents. It is possible to define a list of licenses that are allowed to be used instead of the licenses that are excluded. To do this, define a variable ``COMPATIBLE_LICENSES`` with the names of the licenses - that are allowed. Then define ``INCOMPATIBLE_LICENSE`` as: - :: + that are allowed. Then define ``INCOMPATIBLE_LICENSE`` as:: INCOMPATIBLE_LICENSE = "${@' '.join(sorted(set(d.getVar('AVAILABLE_LICENSES').split()) - set(d.getVar('COMPATIBLE_LICENSES').split())))}" @@ -3508,8 +3408,7 @@ system and gives an overview of their function and contents. unlikely that you want to edit this variable. The default value of the variable is set as follows in the - ``meta/conf/distro/defaultsetup.conf`` file: - :: + ``meta/conf/distro/defaultsetup.conf`` file:: INHERIT_DISTRO ?= "debian devshell sstate license" @@ -3533,8 +3432,7 @@ system and gives an overview of their function and contents. To prevent the build system from splitting out debug information during packaging, set the ``INHIBIT_PACKAGE_DEBUG_SPLIT`` variable as - follows: - :: + follows:: INHIBIT_PACKAGE_DEBUG_SPLIT = "1" @@ -3646,15 +3544,13 @@ system and gives an overview of their function and contents. Setting the variable to "1" in a configuration file causes the OpenEmbedded build system to generate a kernel image with the - initramfs specified in ``INITRAMFS_IMAGE`` bundled within: - :: + initramfs specified in ``INITRAMFS_IMAGE`` bundled within:: INITRAMFS_IMAGE_BUNDLE = "1" By default, the :ref:`kernel <ref-classes-kernel>` class sets this variable to a - null string as follows: - :: + null string as follows:: INITRAMFS_IMAGE_BUNDLE ?= "" @@ -3672,15 +3568,13 @@ system and gives an overview of their function and contents. :term:`INITRAMFS_LINK_NAME` The link name of the initial RAM filesystem image. This variable is set in the ``meta/classes/kernel-artifact-names.bbclass`` file as - follows: - :: + follows:: INITRAMFS_LINK_NAME ?= "initramfs-${KERNEL_ARTIFACT_LINK_NAME}" The value of the ``KERNEL_ARTIFACT_LINK_NAME`` variable, which is set in the same - file, has the following value: - :: + file, has the following value:: KERNEL_ARTIFACT_LINK_NAME ?= "${MACHINE}" @@ -3690,14 +3584,12 @@ system and gives an overview of their function and contents. :term:`INITRAMFS_NAME` The base name of the initial RAM filesystem image. This variable is set in the ``meta/classes/kernel-artifact-names.bbclass`` file as - follows: - :: + follows:: INITRAMFS_NAME ?= "initramfs-${KERNEL_ARTIFACT_NAME}" The value of the :term:`KERNEL_ARTIFACT_NAME` - variable, which is set in the same file, has the following value: - :: + variable, which is set in the same file, has the following value:: KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}" @@ -3735,8 +3627,7 @@ system and gives an overview of their function and contents. variable. :term:`INITSCRIPT_PARAMS` - Specifies the options to pass to ``update-rc.d``. Here is an example: - :: + Specifies the options to pass to ``update-rc.d``. Here is an example:: INITSCRIPT_PARAMS = "start 99 5 2 . stop 20 0 1 6 ." @@ -3756,8 +3647,7 @@ system and gives an overview of their function and contents. recipe. For example, to skip the check for symbolic link ``.so`` files in the main package of a recipe, add the following to the recipe. The package name override must be used, which in this example - is ``${PN}``: - :: + is ``${PN}``:: INSANE_SKIP_${PN} += "dev-so" @@ -3799,8 +3689,7 @@ system and gives an overview of their function and contents. kernel's append file. For example, if you are using the ``linux-yocto_4.12`` kernel, the kernel recipe file is the ``meta/recipes-kernel/linux/linux-yocto_4.12.bb`` file. ``KBRANCH`` - is set as follows in that kernel recipe file: - :: + is set as follows in that kernel recipe file:: KBRANCH ?= "standard/base" @@ -3812,8 +3701,7 @@ system and gives an overview of their function and contents. Beaglebone, EdgeRouter, and generic versions of both 32 and 64-bit IA machines (``meta-yocto-bsp``) is named ``meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.12.bbappend``. - Here are the related statements from that append file: - :: + Here are the related statements from that append file:: KBRANCH_genericx86 = "standard/base" KBRANCH_genericx86-64 = "standard/base" @@ -3839,19 +3727,16 @@ system and gives an overview of their function and contents. ``defconfig`` file. To use the variable, set it in the append file for your kernel recipe - using the following form: - :: + using the following form:: KBUILD_DEFCONFIG_KMACHINE ?= defconfig_file Here is an example from a "raspberrypi2" ``KMACHINE`` build that uses - a ``defconfig`` file named "bcm2709_defconfig": - :: + a ``defconfig`` file named "bcm2709_defconfig":: KBUILD_DEFCONFIG_raspberrypi2 = "bcm2709_defconfig" - As an alternative, you can use the following within your append file: - :: + As an alternative, you can use the following within your append file:: KBUILD_DEFCONFIG_pn-linux-yocto ?= defconfig_file @@ -3872,8 +3757,7 @@ system and gives an overview of their function and contents. The value of ``KERNEL_ARTIFACT_NAME``, which is set in the ``meta/classes/kernel-artifact-names.bbclass`` file, has the - following default value: - :: + following default value:: KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}" @@ -3905,15 +3789,13 @@ system and gives an overview of their function and contents. :term:`KERNEL_DTB_LINK_NAME` The link name of the kernel device tree binary (DTB). This variable is set in the ``meta/classes/kernel-artifact-names.bbclass`` file as - follows: - :: + follows:: KERNEL_DTB_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}" The value of the ``KERNEL_ARTIFACT_LINK_NAME`` variable, which is set in - the same file, has the following value: - :: + the same file, has the following value:: KERNEL_ARTIFACT_LINK_NAME ?= "${MACHINE}" @@ -3923,14 +3805,12 @@ system and gives an overview of their function and contents. :term:`KERNEL_DTB_NAME` The base name of the kernel device tree binary (DTB). This variable is set in the ``meta/classes/kernel-artifact-names.bbclass`` file as - follows: - :: + follows:: KERNEL_DTB_NAME ?= "${KERNEL_ARTIFACT_NAME}" The value of the :term:`KERNEL_ARTIFACT_NAME` - variable, which is set in the same file, has the following value: - :: + variable, which is set in the same file, has the following value:: KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}" @@ -3965,8 +3845,7 @@ system and gives an overview of their function and contents. For example, the following example from the ``linux-yocto-rt_4.12`` kernel recipe adds "netfilter" and "taskstats" features to all BSPs as well as "virtio" configurations to all QEMU machines. The last two - statements add specific configurations to targeted machine types: - :: + statements add specific configurations to targeted machine types:: KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc features/taskstats/taskstats.scc" KERNEL_FEATURES_append = "${KERNEL_EXTRA_FEATURES}" @@ -3977,15 +3856,13 @@ system and gives an overview of their function and contents. :term:`KERNEL_FIT_LINK_NAME` The link name of the kernel flattened image tree (FIT) image. This variable is set in the ``meta/classes/kernel-artifact-names.bbclass`` - file as follows: - :: + file as follows:: KERNEL_FIT_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}" The value of the ``KERNEL_ARTIFACT_LINK_NAME`` variable, which is set in the same - file, has the following value: - :: + file, has the following value:: KERNEL_ARTIFACT_LINK_NAME ?= "${MACHINE}" @@ -3995,28 +3872,24 @@ system and gives an overview of their function and contents. :term:`KERNEL_FIT_NAME` The base name of the kernel flattened image tree (FIT) image. This variable is set in the ``meta/classes/kernel-artifact-names.bbclass`` - file as follows: - :: + file as follows:: KERNEL_FIT_NAME ?= "${KERNEL_ARTIFACT_NAME}" The value of the :term:`KERNEL_ARTIFACT_NAME` - variable, which is set in the same file, has the following value: - :: + variable, which is set in the same file, has the following value:: KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}" :term:`KERNEL_IMAGE_LINK_NAME` The link name for the kernel image. This variable is set in the - ``meta/classes/kernel-artifact-names.bbclass`` file as follows: - :: + ``meta/classes/kernel-artifact-names.bbclass`` file as follows:: KERNEL_IMAGE_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}" The value of the ``KERNEL_ARTIFACT_LINK_NAME`` variable, which is set in the same - file, has the following value: - :: + file, has the following value:: KERNEL_ARTIFACT_LINK_NAME ?= "${MACHINE}" @@ -4038,15 +3911,13 @@ system and gives an overview of their function and contents. :term:`KERNEL_IMAGE_NAME` The base name of the kernel image. This variable is set in the - ``meta/classes/kernel-artifact-names.bbclass`` file as follows: - :: + ``meta/classes/kernel-artifact-names.bbclass`` file as follows:: KERNEL_IMAGE_NAME ?= "${KERNEL_ARTIFACT_NAME}" The value of the :term:`KERNEL_ARTIFACT_NAME` variable, - which is set in the same file, has the following value: - :: + which is set in the same file, has the following value:: KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}" @@ -4074,8 +3945,7 @@ system and gives an overview of their function and contents. configuration file, an append file for the recipe, or the recipe itself). - Specify it as follows: - :: + Specify it as follows:: KERNEL_MODULE_AUTOLOAD += "module_name1 module_name2 module_name3" @@ -4083,8 +3953,7 @@ system and gives an overview of their function and contents. system to populate the ``/etc/modules-load.d/modname.conf`` file with the list of modules to be auto-loaded on boot. The modules appear one-per-line in the file. Here is an example of the most common use - case: - :: + case:: KERNEL_MODULE_AUTOLOAD += "module_name" @@ -4146,8 +4015,7 @@ system and gives an overview of their function and contents. Provides a short description of a configuration fragment. You use this variable in the ``.scc`` file that describes a configuration fragment file. Here is the variable used in a file named ``smp.scc`` - to describe SMP being enabled: - :: + to describe SMP being enabled:: define KFEATURE_DESCRIPTION "Enable SMP" @@ -4163,8 +4031,7 @@ system and gives an overview of their function and contents. These mappings between different names occur in the Yocto Linux Kernel's ``meta`` branch. As an example take a look in the - ``common/recipes-kernel/linux/linux-yocto_3.19.bbappend`` file: - :: + ``common/recipes-kernel/linux/linux-yocto_3.19.bbappend`` file:: LINUX_VERSION_core2-32-intel-common = "3.19.0" COMPATIBLE_MACHINE_core2-32-intel-common = "${MACHINE}" @@ -4202,8 +4069,7 @@ system and gives an overview of their function and contents. :term:`LAYERDEPENDS` Lists the layers, separated by spaces, on which this recipe depends. Optionally, you can specify a specific layer version for a dependency - by adding it to the end of the layer name. Here is an example: - :: + by adding it to the end of the layer name. Here is an example:: LAYERDEPENDS_mylayer = "anotherlayer (=3)" @@ -4228,8 +4094,7 @@ system and gives an overview of their function and contents. Optionally, you can specify a specific layer version for a recommendation by adding the version to the end of the layer name. - Here is an example: - :: + Here is an example:: LAYERRECOMMENDS_mylayer = "anotherlayer (=3)" @@ -4253,8 +4118,7 @@ system and gives an overview of their function and contents. For the list, use the Yocto Project :yocto_wiki:`Release Name </Releases>` (e.g. &DISTRO_NAME_NO_CAP;). To specify multiple OE-Core versions for the - layer, use a space-separated list: - :: + layer, use a space-separated list:: LAYERSERIES_COMPAT_layer_root_name = "&DISTRO_NAME_NO_CAP; &DISTRO_NAME_NO_CAP_MINUS_ONE;" @@ -4335,8 +4199,7 @@ system and gives an overview of their function and contents. :term:`SPDXLICENSEMAP` flag names defined in ``meta/conf/licenses.conf``. - Here are some examples: - :: + Here are some examples:: LICENSE = "LGPLv2.1 | GPLv3" LICENSE = "MPL-1 & LGPLv2.1" @@ -4353,8 +4216,7 @@ system and gives an overview of their function and contents. situations where components of the output have different licenses. For example, a piece of software whose code is licensed under GPLv2 but has accompanying documentation licensed under the GNU Free - Documentation License 1.2 could be specified as follows: - :: + Documentation License 1.2 could be specified as follows:: LICENSE = "GFDL-1.2 & GPLv2" LICENSE_${PN} = "GPLv2" @@ -4409,8 +4271,7 @@ system and gives an overview of their function and contents. OpenEmbedded build system uses ``COMMON_LICENSE_DIR`` to define the directory that holds common license text used during the build. The ``LICENSE_PATH`` variable allows you to extend that location to other - areas that have additional licenses: - :: + areas that have additional licenses:: LICENSE_PATH += "path-to-additional-common-licenses" @@ -4434,14 +4295,12 @@ system and gives an overview of their function and contents. being built using the OpenEmbedded build system is based. You define this variable in the kernel recipe. For example, the ``linux-yocto-3.4.bb`` kernel recipe found in - ``meta/recipes-kernel/linux`` defines the variables as follows: - :: + ``meta/recipes-kernel/linux`` defines the variables as follows:: LINUX_VERSION ?= "3.4.24" The ``LINUX_VERSION`` variable is used to define :term:`PV` - for the recipe: - :: + for the recipe:: PV = "${LINUX_VERSION}+git${SRCPV}" @@ -4449,16 +4308,14 @@ system and gives an overview of their function and contents. A string extension compiled into the version string of the Linux kernel built with the OpenEmbedded build system. You define this variable in the kernel recipe. For example, the linux-yocto kernel - recipes all define the variable as follows: - :: + recipes all define the variable as follows:: LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE}" Defining this variable essentially sets the Linux kernel configuration item ``CONFIG_LOCALVERSION``, which is visible through the ``uname`` command. Here is an example that shows the extension - assuming it was set as previously shown: - :: + assuming it was set as previously shown:: $ uname -r 3.7.0-rc8-custom @@ -4475,8 +4332,7 @@ system and gives an overview of their function and contents. ``MACHINE`` in the ``local.conf`` file found in the :term:`Build Directory`. By default, ``MACHINE`` is set to "qemux86", which is an x86-based architecture machine to be emulated - using QEMU: - :: + using QEMU:: MACHINE ?= "qemux86" @@ -4488,8 +4344,7 @@ system and gives an overview of their function and contents. ``meta/conf/machine``. The list of machines supported by the Yocto Project as shipped - include the following: - :: + include the following:: MACHINE ?= "qemuarm" MACHINE ?= "qemuarm64" @@ -4535,8 +4390,7 @@ system and gives an overview of their function and contents. As an example, suppose the machine for which you are building requires ``example-init`` to be run during boot to initialize the hardware. In this case, you would use the following in the machine's - ``.conf`` configuration file: - :: + ``.conf`` configuration file:: MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "example-init" @@ -4567,8 +4421,7 @@ system and gives an overview of their function and contents. "recommends" relationship so that in the latter case, the build will not fail due to the missing package. To accomplish this, assuming the package for the module was called ``kernel-module-ab123``, you would - use the following in the machine's ``.conf`` configuration file: - :: + use the following in the machine's ``.conf`` configuration file:: MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-module-ab123" @@ -4604,8 +4457,7 @@ system and gives an overview of their function and contents. exist, so it is acceptable for the build process to depend upon finding the package. In this case, assuming the package for the firmware was called ``wifidriver-firmware``, you would use the - following in the ``.conf`` file for the machine: - :: + following in the ``.conf`` file for the machine:: MACHINE_EXTRA_RDEPENDS += "wifidriver-firmware" @@ -4631,8 +4483,7 @@ system and gives an overview of their function and contents. the build to succeed instead of failing as a result of the package not being found. To accomplish this, assuming the package for the module was called ``kernel-module-examplewifi``, you would use the - following in the ``.conf`` file for the machine: - :: + following in the ``.conf`` file for the machine:: MACHINE_EXTRA_RRECOMMENDS += "kernel-module-examplewifi" @@ -4671,16 +4522,14 @@ system and gives an overview of their function and contents. should apply to a machine. For example, all machines emulated in QEMU (e.g. ``qemuarm``, ``qemux86``, and so forth) include a file named ``meta/conf/machine/include/qemu.inc`` that prepends the following - override to ``MACHINEOVERRIDES``: - :: + override to ``MACHINEOVERRIDES``:: MACHINEOVERRIDES =. "qemuall:" This override allows variables to be overridden for all machines emulated in QEMU, like in the following example from the ``connman-conf`` - recipe: - :: + recipe:: SRC_URI_append_qemuall = " file://wired.config \ file://wired-setup \ @@ -4734,27 +4583,23 @@ system and gives an overview of their function and contents. recipes by using :term:`DEPENDS`, then a dependency on "foo" will automatically get rewritten to a dependency on "nativesdk-foo". However, dependencies like the following will not - get rewritten automatically: - :: + get rewritten automatically:: do_foo[depends] += "recipe:do_foo" If you want such a dependency to also get transformed, you can do the - following: - :: + following:: do_foo[depends] += "${MLPREFIX}recipe:do_foo" module_autoload This variable has been replaced by the ``KERNEL_MODULE_AUTOLOAD`` variable. You should replace all occurrences of ``module_autoload`` - with additions to ``KERNEL_MODULE_AUTOLOAD``, for example: - :: + with additions to ``KERNEL_MODULE_AUTOLOAD``, for example:: module_autoload_rfcomm = "rfcomm" - should now be replaced with: - :: + should now be replaced with:: KERNEL_MODULE_AUTOLOAD += "rfcomm" @@ -4773,8 +4618,7 @@ system and gives an overview of their function and contents. :term:`KERNEL_MODULE_AUTOLOAD` variable. - Here is the general syntax: - :: + Here is the general syntax:: module_conf_module_name = "modprobe.d-syntax" @@ -4786,8 +4630,7 @@ system and gives an overview of their function and contents. Including ``module_conf`` causes the OpenEmbedded build system to populate the ``/etc/modprobe.d/modname.conf`` file with ``modprobe.d`` syntax lines. Here is an example that adds the options - ``arg1`` and ``arg2`` to a module named ``mymodule``: - :: + ``arg1`` and ``arg2`` to a module named ``mymodule``:: module_conf_mymodule = "options mymodule arg1=val1 arg2=val2" @@ -4801,15 +4644,13 @@ system and gives an overview of their function and contents. :term:`MODULE_TARBALL_LINK_NAME` The link name of the kernel module tarball. This variable is set in - the ``meta/classes/kernel-artifact-names.bbclass`` file as follows: - :: + the ``meta/classes/kernel-artifact-names.bbclass`` file as follows:: MODULE_TARBALL_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}" The value of the ``KERNEL_ARTIFACT_LINK_NAME`` variable, which is set in the - same file, has the following value: - :: + same file, has the following value:: KERNEL_ARTIFACT_LINK_NAME ?= "${MACHINE}" @@ -4817,14 +4658,12 @@ system and gives an overview of their function and contents. :term:`MODULE_TARBALL_NAME` The base name of the kernel module tarball. This variable is set in - the ``meta/classes/kernel-artifact-names.bbclass`` file as follows: - :: + the ``meta/classes/kernel-artifact-names.bbclass`` file as follows:: MODULE_TARBALL_NAME ?= "${KERNEL_ARTIFACT_NAME}" The value of the :term:`KERNEL_ARTIFACT_NAME` variable, - which is set in the same file, has the following value: - :: + which is set in the same file, has the following value:: KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}" @@ -4834,8 +4673,7 @@ system and gives an overview of their function and contents. target systems to be put into different subdirectories of the same output directory. - The default value of this variable is: - :: + The default value of this variable is:: ${PACKAGE_ARCH}${TARGET_VENDOR}-${TARGET_OS} @@ -4874,15 +4712,13 @@ system and gives an overview of their function and contents. not exist in common licenses. The following example shows how to add ``NO_GENERIC_LICENSE`` to a - recipe: - :: + recipe:: NO_GENERIC_LICENSE[license_name] = "license_file_in_fetched_source" The following is an example that uses the ``LICENSE.Abilis.txt`` file as the license from the fetched - source: - :: + source:: NO_GENERIC_LICENSE[Firmware-Abilis] = "LICENSE.Abilis.txt" @@ -4890,13 +4726,13 @@ system and gives an overview of their function and contents. Prevents installation of all "recommended-only" packages. Recommended-only packages are packages installed only through the :term:`RRECOMMENDS` variable). Setting the - ``NO_RECOMMENDATIONS`` variable to "1" turns this feature on: :: + ``NO_RECOMMENDATIONS`` variable to "1" turns this feature on:: NO_RECOMMENDATIONS = "1" You can set this variable globally in your ``local.conf`` file or you can attach it to a specific image recipe by using the recipe name - override: :: + override:: NO_RECOMMENDATIONS_pn-target_image = "1" @@ -4923,8 +4759,7 @@ system and gives an overview of their function and contents. Disables auto package from splitting ``.debug`` files. If a recipe requires ``FILES_${PN}-dbg`` to be set manually, the ``NOAUTOPACKAGEDEBUG`` can be defined allowing you to define the - content of the debug package. For example: - :: + content of the debug package. For example:: NOAUTOPACKAGEDEBUG = "1" FILES_${PN}-dev = "${includedir}/${QT_DIR_NAME}/Qt/*" @@ -5016,8 +4851,7 @@ system and gives an overview of their function and contents. As an example, if the string "an-override" appears as an element in the colon-separated list in ``OVERRIDES``, then the following assignment will override ``FOO`` with the value "overridden" at the - end of parsing: - :: + end of parsing:: FOO_an-override = "overridden" @@ -5032,8 +4866,7 @@ system and gives an overview of their function and contents. :term:`DISTROOVERRIDES` variables. Another important override included by default is ``pn-${PN}``. This override allows variables to be set for a single recipe within configuration - (``.conf``) files. Here is an example: - :: + (``.conf``) files. Here is an example:: FOO_pn-myrecipe = "myrecipe-specific value" @@ -5045,8 +4878,7 @@ system and gives an overview of their function and contents. Project Development Tasks Manual for more information. :term:`P` - The recipe name and version. ``P`` is comprised of the following: - :: + The recipe name and version. ``P`` is comprised of the following:: ${PN}-${PV} @@ -5082,8 +4914,7 @@ system and gives an overview of their function and contents. However, if your recipe's output packages are built specific to the target machine rather than generally for the architecture of the machine, you should set ``PACKAGE_ARCH`` to the value of - :term:`MACHINE_ARCH` in the recipe as follows: - :: + :term:`MACHINE_ARCH` in the recipe as follows:: PACKAGE_ARCH = "${MACHINE_ARCH}" @@ -5119,8 +4950,7 @@ system and gives an overview of their function and contents. The build system uses only the first argument in the list as the package manager when creating your image or SDK. However, packages will be created using any additional packaging classes you specify. - For example, if you use the following in your ``local.conf`` file: - :: + For example, if you use the following in your ``local.conf`` file:: PACKAGE_CLASSES ?= "package_ipk" @@ -5178,15 +5008,13 @@ system and gives an overview of their function and contents. :term:`PACKAGE_EXCLUDE` Lists packages that should not be installed into an image. For - example: - :: + example:: PACKAGE_EXCLUDE = "package_name package_name package_name ..." You can set this variable globally in your ``local.conf`` file or you can attach it to a specific image recipe by using the recipe name - override: - :: + override:: PACKAGE_EXCLUDE_pn-target_image = "package_name" @@ -5230,8 +5058,7 @@ system and gives an overview of their function and contents. Consider the following example where the ``PACKAGE_FEED_URIS``, ``PACKAGE_FEED_BASE_PATHS``, and ``PACKAGE_FEED_ARCHS`` variables are - defined in your ``local.conf`` file: - :: + defined in your ``local.conf`` file:: PACKAGE_FEED_URIS = "https://example.com/packagerepos/release \ https://example.com/packagerepos/updates" @@ -5260,8 +5087,7 @@ system and gives an overview of their function and contents. Consider the following example where the ``PACKAGE_FEED_URIS``, ``PACKAGE_FEED_BASE_PATHS``, and ``PACKAGE_FEED_ARCHS`` variables are - defined in your ``local.conf`` file: - :: + defined in your ``local.conf`` file:: PACKAGE_FEED_URIS = "https://example.com/packagerepos/release \ https://example.com/packagerepos/updates" @@ -5290,8 +5116,7 @@ system and gives an overview of their function and contents. Consider the following example where the ``PACKAGE_FEED_URIS``, ``PACKAGE_FEED_BASE_PATHS``, and ``PACKAGE_FEED_ARCHS`` variables are - defined in your ``local.conf`` file: - :: + defined in your ``local.conf`` file:: PACKAGE_FEED_URIS = "https://example.com/packagerepos/release \ https://example.com/packagerepos/updates" @@ -5356,8 +5181,7 @@ system and gives an overview of their function and contents. recipe on a per-recipe basis. ``PACKAGECONFIG`` blocks are defined in recipes when you specify features and then arguments that define feature behaviors. Here is the basic block structure (broken over - multiple lines for readability): - :: + multiple lines for readability):: PACKAGECONFIG ??= "f1 f2 f3 ..." PACKAGECONFIG[f1] = "\ @@ -5423,26 +5247,22 @@ system and gives an overview of their function and contents. - *Append file:* Create an append file named recipename\ ``.bbappend`` in your layer and override the value of ``PACKAGECONFIG``. You can either completely override the - variable: - :: + variable:: PACKAGECONFIG = "f4 f5" - Or, you can just append the variable: - :: + Or, you can just append the variable:: PACKAGECONFIG_append = " f4" - *Configuration file:* This method is identical to changing the block through an append file except you edit your ``local.conf`` or ``mydistro.conf`` file. As with append files previously - described, you can either completely override the variable: - :: + described, you can either completely override the variable:: PACKAGECONFIG_pn-recipename = "f4 f5" - Or, you can just amend the variable: - :: + Or, you can just amend the variable:: PACKAGECONFIG_append_pn-recipename = " f4" @@ -5467,8 +5287,7 @@ system and gives an overview of their function and contents. :term:`PACKAGES` The list of packages the recipe creates. The default value is the - following: - :: + following:: ${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN} @@ -5594,8 +5413,7 @@ system and gives an overview of their function and contents. patched, it uses "patch". If you wish to use an alternative patching tool, set the variable in - the recipe using one of the following: - :: + the recipe using one of the following:: PATCHTOOL = "patch" PATCHTOOL = "quilt" @@ -5641,8 +5459,7 @@ system and gives an overview of their function and contents. :term:`PKGD` Points to the destination directory for files to be packaged before they are split into individual packages. This directory defaults to - the following: - :: + the following:: ${WORKDIR}/package @@ -5654,8 +5471,7 @@ system and gives an overview of their function and contents. :ref:`ref-tasks-packagedata` task packages data for each recipe and installs it into this temporary, shared area. This directory defaults to the following, which you should not - change: - :: + change:: ${STAGING_DIR_HOST}/pkgdata @@ -5670,8 +5486,7 @@ system and gives an overview of their function and contents. :term:`PKGDEST` Points to the parent directory for files to be packaged after they have been split into individual packages. This directory defaults to - the following: - :: + the following:: ${WORKDIR}/packages-split @@ -5682,8 +5497,7 @@ system and gives an overview of their function and contents. :term:`PKGDESTWORK` Points to a temporary work area where the :ref:`ref-tasks-package` task saves package metadata. - The ``PKGDESTWORK`` location defaults to the following: - :: + The ``PKGDESTWORK`` location defaults to the following:: ${WORKDIR}/pkgdata @@ -5732,16 +5546,14 @@ system and gives an overview of their function and contents. To prevent a recipe from being built, use the ``PNBLACKLIST`` variable in your ``local.conf`` file. Here is an example that - prevents ``myrecipe`` from being built: - :: + prevents ``myrecipe`` from being built:: PNBLACKLIST[myrecipe] = "Not supported by our organization." :term:`POPULATE_SDK_POST_HOST_COMMAND` Specifies a list of functions to call once the OpenEmbedded build system has created the host part of the SDK. You can specify - functions separated by semicolons: - :: + functions separated by semicolons:: POPULATE_SDK_POST_HOST_COMMAND += "function; ... " @@ -5753,8 +5565,7 @@ system and gives an overview of their function and contents. :term:`POPULATE_SDK_POST_TARGET_COMMAND` Specifies a list of functions to call once the OpenEmbedded build system has created the target part of the SDK. You can specify - functions separated by semicolons: - :: + functions separated by semicolons:: POPULATE_SDK_POST_TARGET_COMMAND += "function; ... " @@ -5804,8 +5615,7 @@ system and gives an overview of their function and contents. preferred provider). You should always suffix this variable with the name of the provided item. And, you should define the variable using the preferred recipe's name (:term:`PN`). Here is a common - example: - :: + example:: PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto" @@ -5813,8 +5623,7 @@ system and gives an overview of their function and contents. The ``PREFERRED_PROVIDER`` variable is set with the name (``PN``) of the recipe you prefer to provide "virtual/kernel". - Following are more examples: - :: + Following are more examples:: PREFERRED_PROVIDER_virtual/xserver = "xserver-xf86" PREFERRED_PROVIDER_virtual/libgl ?= "mesa" @@ -5842,8 +5651,7 @@ system and gives an overview of their function and contents. through the "``%``" character. You can use the character to match any number of characters, which can be useful when specifying versions that contain long revision numbers that potentially change. Here are - two examples: - :: + two examples:: PREFERRED_VERSION_python = "3.4.0" PREFERRED_VERSION_linux-yocto = "5.0%" @@ -5857,35 +5665,30 @@ system and gives an overview of their function and contents. The specified version is matched against :term:`PV`, which does not necessarily match the version part of the recipe's filename. For example, consider two recipes ``foo_1.2.bb`` and ``foo_git.bb`` - where ``foo_git.bb`` contains the following assignment: - :: + where ``foo_git.bb`` contains the following assignment:: PV = "1.1+git${SRCPV}" In this case, the correct way to select - ``foo_git.bb`` is by using an assignment such as the following: - :: + ``foo_git.bb`` is by using an assignment such as the following:: PREFERRED_VERSION_foo = "1.1+git%" Compare that previous example - against the following incorrect example, which does not work: - :: + against the following incorrect example, which does not work:: PREFERRED_VERSION_foo = "git" Sometimes the ``PREFERRED_VERSION`` variable can be set by configuration files in a way that is hard to change. You can use :term:`OVERRIDES` to set a machine-specific - override. Here is an example: - :: + override. Here is an example:: PREFERRED_VERSION_linux-yocto_qemux86 = "5.0%" Although not recommended, worst case, you can also use the "forcevariable" override, which is the strongest override possible. - Here is an example: - :: + Here is an example:: PREFERRED_VERSION_linux-yocto_forcevariable = "5.0%" @@ -5913,8 +5716,7 @@ system and gives an overview of their function and contents. Typically, you could add a specific server for the build system to attempt before any others by adding something like the following to the ``local.conf`` configuration file in the - :term:`Build Directory`: - :: + :term:`Build Directory`:: PREMIRRORS_prepend = "\ git://.*/.* http://www.yoctoproject.org/sources/ \n \ @@ -5950,8 +5752,7 @@ system and gives an overview of their function and contents. standard version of the library. Libraries specified in this variable should be specified by their - file name. For example, from the Firefox recipe in meta-browser: - :: + file name. For example, from the Firefox recipe in meta-browser:: PRIVATE_LIBS = "libmozjs.so \ libxpcom.so \ @@ -5975,8 +5776,7 @@ system and gives an overview of their function and contents. ``DEPENDS``. Consider the following example ``PROVIDES`` statement from the recipe - file ``eudev_3.2.9.bb``: - :: + file ``eudev_3.2.9.bb``:: PROVIDES += "udev" @@ -6013,8 +5813,7 @@ system and gives an overview of their function and contents. the component that manages the ``/dev`` directory. Setting the "preferred provider" for runtime dependencies is as - simple as using the following assignment in a configuration file: - :: + simple as using the following assignment in a configuration file:: VIRTUAL-RUNTIME_dev_manager = "udev" @@ -6024,8 +5823,7 @@ system and gives an overview of their function and contents. The ``conf/local.conf.sample.extended`` configuration file in the :term:`Source Directory` shows how the - ``PRSERV_HOST`` variable is set: - :: + ``PRSERV_HOST`` variable is set:: PRSERV_HOST = "localhost:0" @@ -6086,8 +5884,7 @@ system and gives an overview of their function and contents. OpenEmbedded build system automatically sets it for you. The variable allows recipes to use common infrastructure such as the - following: - :: + following:: DEPENDS += "${PYTHON_PN}-native" @@ -6102,8 +5899,7 @@ system and gives an overview of their function and contents. will not be installed if conflicting packages are not first removed. Like all package-controlling variables, you must always use them in - conjunction with a package name override. Here is an example: - :: + conjunction with a package name override. Here is an example:: RCONFLICTS_${PN} = "another_conflicting_package_name" @@ -6111,8 +5907,7 @@ system and gives an overview of their function and contents. specifying versioned dependencies. Although the syntax varies depending on the packaging format, BitBake hides these differences from you. Here is the general syntax to specify versions with the - ``RCONFLICTS`` variable: - :: + ``RCONFLICTS`` variable:: RCONFLICTS_${PN} = "package (operator version)" @@ -6125,8 +5920,7 @@ system and gives an overview of their function and contents. - >= For example, the following sets up a dependency on version 1.2 or - greater of the package ``foo``: - :: + greater of the package ``foo``:: RCONFLICTS_${PN} = "foo (>= 1.2)" @@ -6135,8 +5929,7 @@ system and gives an overview of their function and contents. packages that must be installed in order for the package to function correctly. As an example, the following assignment declares that the package ``foo`` needs the packages ``bar`` and ``baz`` to be - installed: - :: + installed:: RDEPENDS_foo = "bar baz" @@ -6177,8 +5970,7 @@ system and gives an overview of their function and contents. name (remember that a single recipe can build multiple packages). For example, suppose you are building a development package that depends on the ``perl`` package. In this case, you would use the following - ``RDEPENDS`` statement: - :: + ``RDEPENDS`` statement:: RDEPENDS_${PN}-dev += "perl" @@ -6207,8 +5999,7 @@ system and gives an overview of their function and contents. specifying versioned dependencies. Although the syntax varies depending on the packaging format, BitBake hides these differences from you. Here is the general syntax to specify versions with the - ``RDEPENDS`` variable: - :: + ``RDEPENDS`` variable:: RDEPENDS_${PN} = "package (operator version)" @@ -6228,8 +6019,7 @@ system and gives an overview of their function and contents. specification. For example, the following sets up a dependency on version 1.2 or - greater of the package ``foo``: - :: + greater of the package ``foo``:: RDEPENDS_${PN} = "foo (>= 1.2)" @@ -6270,8 +6060,7 @@ system and gives an overview of their function and contents. :term:`ROOT_HOME` Defines the root home directory. By default, this directory is set as - follows in the BitBake configuration file: - :: + follows in the BitBake configuration file:: ROOT_HOME ??= "/home/root" @@ -6284,8 +6073,7 @@ system and gives an overview of their function and contents. You can override the default by setting the variable in any layer or in the ``local.conf`` file. Because the default is set using a "weak" assignment (i.e. "??="), you can use either of the following forms to - define your override: - :: + define your override:: ROOT_HOME = "/root" ROOT_HOME ?= "/root" @@ -6303,8 +6091,7 @@ system and gives an overview of their function and contents. :term:`ROOTFS_POSTINSTALL_COMMAND` Specifies a list of functions to call after the OpenEmbedded build system has installed packages. You can specify functions separated by - semicolons: - :: + semicolons:: ROOTFS_POSTINSTALL_COMMAND += "function; ... " @@ -6317,8 +6104,7 @@ system and gives an overview of their function and contents. :term:`ROOTFS_POSTPROCESS_COMMAND` Specifies a list of functions to call once the OpenEmbedded build system has created the root filesystem. You can specify functions - separated by semicolons: - :: + separated by semicolons:: ROOTFS_POSTPROCESS_COMMAND += "function; ... " @@ -6333,8 +6119,7 @@ system and gives an overview of their function and contents. system has removed unnecessary packages. When runtime package management is disabled in the image, several packages are removed including ``base-passwd``, ``shadow``, and ``update-alternatives``. - You can specify functions separated by semicolons: - :: + You can specify functions separated by semicolons:: ROOTFS_POSTUNINSTALL_COMMAND += "function; ... " @@ -6347,8 +6132,7 @@ system and gives an overview of their function and contents. :term:`ROOTFS_PREPROCESS_COMMAND` Specifies a list of functions to call before the OpenEmbedded build system has created the root filesystem. You can specify functions - separated by semicolons: - :: + separated by semicolons:: ROOTFS_PREPROCESS_COMMAND += "function; ... " @@ -6370,8 +6154,7 @@ system and gives an overview of their function and contents. As with all package-controlling variables, you must always use the variable in conjunction with a package name override. Here is an - example: - :: + example:: RPROVIDES_${PN} = "widget-abi-2" @@ -6402,8 +6185,7 @@ system and gives an overview of their function and contents. particular package whose usability is being extended. For example, suppose you are building a development package that is extended to support wireless functionality. In this case, you would use the - following: - :: + following:: RRECOMMENDS_${PN}-dev += "wireless_package_name" @@ -6416,8 +6198,7 @@ system and gives an overview of their function and contents. specifying versioned recommends. Although the syntax varies depending on the packaging format, BitBake hides these differences from you. Here is the general syntax to specify versions with the - ``RRECOMMENDS`` variable: - :: + ``RRECOMMENDS`` variable:: RRECOMMENDS_${PN} = "package (operator version)" @@ -6430,8 +6211,7 @@ system and gives an overview of their function and contents. - >= For example, the following sets up a recommend on version 1.2 or - greater of the package ``foo``: - :: + greater of the package ``foo``:: RRECOMMENDS_${PN} = "foo (>= 1.2)" @@ -6443,8 +6223,7 @@ system and gives an overview of their function and contents. the other package to the ``RCONFLICTS`` variable. As with all package-controlling variables, you must use this variable - in conjunction with a package name override. Here is an example: - :: + in conjunction with a package name override. Here is an example:: RREPLACES_${PN} = "other_package_being_replaced" @@ -6452,8 +6231,7 @@ system and gives an overview of their function and contents. specifying versioned replacements. Although the syntax varies depending on the packaging format, BitBake hides these differences from you. Here is the general syntax to specify versions with the - ``RREPLACES`` variable: - :: + ``RREPLACES`` variable:: RREPLACES_${PN} = "package (operator version)" @@ -6466,8 +6244,7 @@ system and gives an overview of their function and contents. - >= For example, the following sets up a replacement using version 1.2 - or greater of the package ``foo``: - :: + or greater of the package ``foo``:: RREPLACES_${PN} = "foo (>= 1.2)" @@ -6478,8 +6255,7 @@ system and gives an overview of their function and contents. As with all package-controlling variables, you must always use this variable in conjunction with a package name override. Here is an - example: - :: + example:: RSUGGESTS_${PN} = "useful_package another_package" @@ -6497,8 +6273,7 @@ system and gives an overview of their function and contents. As an example, assume a :term:`Source Directory` top-level folder named ``poky`` and a default Build Directory at ``poky/build``. In this case, the work directory the build system - uses to keep the unpacked recipe for ``db`` is the following: - :: + uses to keep the unpacked recipe for ``db`` is the following:: poky/build/tmp/work/qemux86-poky-linux/db/5.1.19-r3/db-5.1.19 @@ -6508,8 +6283,7 @@ system and gives an overview of their function and contents. repositories are cloned to ``${WORKDIR}/git`` during :ref:`ref-tasks-fetch`. Since this path is different from the default value of ``S``, you must set it specifically so the - source can be located: - :: + source can be located:: SRC_URI = "git://path/to/repo.git" S = "${WORKDIR}/git" @@ -6544,8 +6318,7 @@ system and gives an overview of their function and contents. The directory set up and used by the :ref:`populate_sdk_base <ref-classes-populate-sdk>` class to which the SDK is deployed. The ``populate_sdk_base`` class defines - ``SDK_DEPLOY`` as follows: - :: + ``SDK_DEPLOY`` as follows:: SDK_DEPLOY = "${TMPDIR}/deploy/sdk" @@ -6553,8 +6326,7 @@ system and gives an overview of their function and contents. The parent directory used by the OpenEmbedded build system when creating SDK output. The :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` class defines - the variable as follows: - :: + the variable as follows:: SDK_DIR = "${WORKDIR}/sdk" @@ -6579,14 +6351,12 @@ system and gives an overview of their function and contents. The manifest file for the host part of the SDK. This file lists all the installed packages that make up the host part of the SDK. The file contains package information on a line-per-package basis as - follows: - :: + follows:: packagename packagearch version The :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` class - defines the manifest file as follows: - :: + defines the manifest file as follows:: SDK_HOST_MANIFEST = "${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.host.manifest" @@ -6624,8 +6394,7 @@ system and gives an overview of their function and contents. A list of classes to remove from the :term:`INHERIT` value globally within the extensible SDK configuration. The :ref:`populate-sdk-ext <ref-classes-populate-sdk-*>` class sets the - default value: - :: + default value:: SDK_INHERIT_BLACKLIST ?= "buildhistory icecc" @@ -6688,8 +6457,7 @@ system and gives an overview of their function and contents. :term:`DISTRO`, :term:`TCLIBC`, :term:`SDK_ARCH`, :term:`IMAGE_BASENAME`, and - :term:`TUNE_PKGARCH` variables: - :: + :term:`TUNE_PKGARCH` variables:: SDK_NAME = "${DISTRO}-${TCLIBC}-${SDK_ARCH}-${IMAGE_BASENAME}-${TUNE_PKGARCH}" @@ -6700,8 +6468,7 @@ system and gives an overview of their function and contents. :term:`SDK_OUTPUT` The location used by the OpenEmbedded build system when creating SDK output. The :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` - class defines the variable as follows: - :: + class defines the variable as follows:: SDK_DIR = "${WORKDIR}/sdk" SDK_OUTPUT = "${SDK_DIR}/image" @@ -6766,14 +6533,12 @@ system and gives an overview of their function and contents. The manifest file for the target part of the SDK. This file lists all the installed packages that make up the target part of the SDK. The file contains package information on a line-per-package basis as - follows: - :: + follows:: packagename packagearch version The :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` class - defines the manifest file as follows: - :: + defines the manifest file as follows:: SDK_TARGET_MANIFEST = "${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.target.manifest" @@ -6793,8 +6558,7 @@ system and gives an overview of their function and contents. this title is based on the :term:`DISTRO_NAME` or :term:`DISTRO` variable and is set in the :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` class as - follows: - :: + follows:: SDK_TITLE ??= "${@d.getVar('DISTRO_NAME') or d.getVar('DISTRO')} SDK" @@ -6817,8 +6581,7 @@ system and gives an overview of their function and contents. :term:`SDK_VERSION` Specifies the version of the SDK. The Poky distribution configuration file (``/meta-poky/conf/distro/poky.conf``) sets the default - ``SDK_VERSION`` as follows: - :: + ``SDK_VERSION`` as follows:: SDK_VERSION = "${@d.getVar('DISTRO_VERSION').replace('snapshot-${METADATA_REVISION}', 'snapshot')}" @@ -6831,8 +6594,7 @@ system and gives an overview of their function and contents. default, this directory is based on the :term:`DISTRO` variable and is set in the :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` class as - follows: - :: + follows:: SDKEXTPATH ??= "~/${@d.getVar('DISTRO')}_sdk" @@ -6846,8 +6608,7 @@ system and gives an overview of their function and contents. :term:`SDKIMAGE_FEATURES` Equivalent to ``IMAGE_FEATURES``. However, this variable applies to - the SDK generated from an image using the following command: - :: + the SDK generated from an image using the following command:: $ bitbake -c populate_sdk imagename @@ -6899,8 +6660,7 @@ system and gives an overview of their function and contents. Defines a serial console (TTY) to enable using `getty <https://en.wikipedia.org/wiki/Getty_(Unix)>`__. Provide a value that specifies the baud rate followed by the TTY device name - separated by a space. You cannot specify more than one TTY device: - :: + separated by a space. You cannot specify more than one TTY device:: SERIAL_CONSOLE = "115200 ttyS0" @@ -6913,8 +6673,7 @@ system and gives an overview of their function and contents. Defines a serial console (TTY) to enable using `getty <https://en.wikipedia.org/wiki/Getty_(Unix)>`__. Provide a value that specifies the baud rate followed by the TTY device name - separated by a semicolon. Use spaces to separate multiple devices: - :: + separated by a semicolon. Use spaces to separate multiple devices:: SERIAL_CONSOLES = "115200;ttyS0 115200;ttyS1" @@ -6924,17 +6683,21 @@ system and gives an overview of their function and contents. ``/proc/console`` before enabling them using getty. This variable allows aliasing in the format: <device>:<alias>. If a device was listed as "sclp_line0" in ``/dev/`` and "ttyS0" was listed in - ``/proc/console``, you would do the following: :: + ``/proc/console``, you would do the following:: SERIAL_CONSOLES_CHECK = "slcp_line0:ttyS0" This variable is currently only supported with SysVinit (i.e. not - with systemd). + with systemd). Note that :term:`SERIAL_CONSOLES_CHECK` also requires + ``/etc/inittab`` to be writable when used with SysVinit. This makes it + incompatible with customizations such as the following:: + + EXTRA_IMAGE_FEATURES += "read-only-rootfs" :term:`SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS` A list of recipe dependencies that should not be used to determine signatures of tasks from one recipe when they depend on tasks from - another recipe. For example: :: + another recipe. For example:: SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += "intone->mplayer2" @@ -6942,7 +6705,7 @@ system and gives an overview of their function and contents. You can use the special token ``"*"`` on the left-hand side of the dependency to match all recipes except the one on the right-hand - side. Here is an example: :: + side. Here is an example:: SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += "*->quilt-native" @@ -7044,8 +6807,7 @@ system and gives an overview of their function and contents. To use this variable, you must globally inherit the :ref:`own-mirrors <ref-classes-own-mirrors>` class and then provide - the URL to your mirrors. Here is the general syntax: - :: + the URL to your mirrors. Here is the general syntax:: INHERIT += "own-mirrors" SOURCE_MIRROR_URL = "http://example.com/my_source_mirror" @@ -7076,8 +6838,7 @@ system and gives an overview of their function and contents. U-Boot recipe. The SPL file type is set to "null" by default in the ``u-boot.inc`` - file as follows: - :: + file as follows:: # Some versions of u-boot build an SPL (Second Program Loader) image that # should be packaged along with the u-boot binary as well as placed in the @@ -7236,8 +6997,7 @@ system and gives an overview of their function and contents. - ``name`` - Specifies a name to be used for association with ``SRC_URI`` checksums or :term:`SRCREV` when you have more than one - file or git repository specified in ``SRC_URI``. For example: - :: + file or git repository specified in ``SRC_URI``. For example:: SRC_URI = "git://example.com/foo.git;name=first \ git://example.com/bar.git;name=second \ @@ -7268,16 +7028,14 @@ system and gives an overview of their function and contents. The ``SRCPV`` variable is defined in the ``meta/conf/bitbake.conf`` configuration file in the :term:`Source Directory` as - follows: - :: + follows:: SRCPV = "${@bb.fetch2.get_srcrev(d)}" Recipes that need to define ``PV`` do so with the help of the ``SRCPV``. For example, the ``ofono`` recipe (``ofono_git.bb``) located in ``meta/recipes-connectivity`` in the Source Directory - defines ``PV`` as follows: - :: + defines ``PV`` as follows:: PV = "0.12-git${SRCPV}" @@ -7328,8 +7086,7 @@ system and gives an overview of their function and contents. :term:`NATIVELSBSTRING` set by the :ref:`uninative <ref-classes-uninative>` class. For example, the following maps the local search path ``universal-4.9`` to the - server-provided path server_url_sstate_path: - :: + server-provided path server_url_sstate_path:: SSTATE_MIRRORS ?= "file://universal-4.9/(.*) http://server_url_sstate_path/universal-4.8/\1 \n" @@ -7524,8 +7281,7 @@ system and gives an overview of their function and contents. to an actual stamp file is constructed by evaluating this string and then appending additional information. Currently, the default assignment for ``STAMP`` as set in the ``meta/conf/bitbake.conf`` - file is: - :: + file is:: STAMP = "${STAMPS_DIR}/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}" @@ -7562,8 +7318,7 @@ system and gives an overview of their function and contents. :term:`SYSLINUX_DEFAULT_CONSOLE` Specifies the kernel boot default console. If you want to use a console other than the default, set this variable in your recipe as - follows where "X" is the console number you want to use: - :: + follows where "X" is the console number you want to use:: SYSLINUX_DEFAULT_CONSOLE = "console=ttyX" @@ -7582,8 +7337,7 @@ system and gives an overview of their function and contents. Specifies the alternate serial port or turns it off. To turn off serial, set this variable to an empty string in your recipe. The variable's default value is set in the - :ref:`syslinux <ref-classes-syslinux>` class as follows: - :: + :ref:`syslinux <ref-classes-syslinux>` class as follows:: SYSLINUX_SERIAL ?= "0 115200" @@ -7592,8 +7346,7 @@ system and gives an overview of their function and contents. :term:`SYSLINUX_SERIAL_TTY` Specifies the alternate console=tty... kernel boot argument. The variable's default value is set in the - :ref:`syslinux <ref-classes-syslinux>` class as follows: - :: + :ref:`syslinux <ref-classes-syslinux>` class as follows:: SYSLINUX_SERIAL_TTY ?= "console=ttyS0,115200" @@ -7616,8 +7369,7 @@ system and gives an overview of their function and contents. :term:`SYSROOT_DIRS` Directories that are staged into the sysroot by the :ref:`ref-tasks-populate_sysroot` task. By - default, the following directories are staged: - :: + default, the following directories are staged:: SYSROOT_DIRS = " \ ${includedir} \ @@ -7632,8 +7384,7 @@ system and gives an overview of their function and contents. :ref:`ref-tasks-populate_sysroot` task. You can use this variable to exclude certain subdirectories of directories listed in :term:`SYSROOT_DIRS` from - staging. By default, the following directories are not staged: - :: + staging. By default, the following directories are not staged:: SYSROOT_DIRS_BLACKLIST = " \ ${mandir} \ @@ -7650,8 +7401,7 @@ system and gives an overview of their function and contents. :ref:`ref-tasks-populate_sysroot` task for ``-native`` recipes, in addition to those specified in :term:`SYSROOT_DIRS`. By default, the following - extra directories are staged: - :: + extra directories are staged:: SYSROOT_DIRS_NATIVE = " \ ${bindir} \ @@ -7680,8 +7430,7 @@ system and gives an overview of their function and contents. :term:`SYSTEMD_SERVICE` should start automatically or not. By default, the service is enabled to automatically start at boot time. The default setting is in the - :ref:`systemd <ref-classes-systemd>` class as follows: - :: + :ref:`systemd <ref-classes-systemd>` class as follows:: SYSTEMD_AUTO_ENABLE ??= "enable" @@ -7692,8 +7441,7 @@ system and gives an overview of their function and contents. "systemd-boot", the ``SYSTEMD_BOOT_CFG`` variable specifies the configuration file that should be used. By default, the :ref:`systemd-boot <ref-classes-systemd-boot>` class sets the - ``SYSTEMD_BOOT_CFG`` as follows: - :: + ``SYSTEMD_BOOT_CFG`` as follows:: SYSTEMD_BOOT_CFG ?= "${:term:`S`}/loader.conf" @@ -7706,8 +7454,7 @@ system and gives an overview of their function and contents. list of entry files (``*.conf``) to install that contain one boot entry per file. By default, the :ref:`systemd-boot <ref-classes-systemd-boot>` class sets the - ``SYSTEMD_BOOT_ENTRIES`` as follows: - :: + ``SYSTEMD_BOOT_ENTRIES`` as follows:: SYSTEMD_BOOT_ENTRIES ?= "" @@ -7719,8 +7466,7 @@ system and gives an overview of their function and contents. "systemd-boot", the ``SYSTEMD_BOOT_TIMEOUT`` variable specifies the boot menu timeout in seconds. By default, the :ref:`systemd-boot <ref-classes-systemd-boot>` class sets the - ``SYSTEMD_BOOT_TIMEOUT`` as follows: - :: + ``SYSTEMD_BOOT_TIMEOUT`` as follows:: SYSTEMD_BOOT_TIMEOUT ?= "10" @@ -7732,8 +7478,7 @@ system and gives an overview of their function and contents. this variable locates the systemd unit files when they are not found in the main recipe's package. By default, the ``SYSTEMD_PACKAGES`` variable is set such that the systemd unit files are assumed to - reside in the recipes main package: - :: + reside in the recipes main package:: SYSTEMD_PACKAGES ?= "${PN}" @@ -7747,8 +7492,7 @@ system and gives an overview of their function and contents. When you specify this file in your recipe, use a package name override to indicate the package to which the value applies. Here is - an example from the connman recipe: - :: + an example from the connman recipe:: SYSTEMD_SERVICE_${PN} = "connman.service" @@ -7766,8 +7510,7 @@ system and gives an overview of their function and contents. :term:`T` This variable points to a directory were BitBake places temporary files, which consist mostly of task logs and scripts, when building a - particular recipe. The variable is typically set as follows: - :: + particular recipe. The variable is typically set as follows:: T = "${WORKDIR}/temp" @@ -7801,8 +7544,7 @@ system and gives an overview of their function and contents. Specifies architecture-specific assembler flags for the target system. ``TARGET_AS_ARCH`` is initialized from :term:`TUNE_ASARGS` by default in the BitBake - configuration file (``meta/conf/bitbake.conf``): - :: + configuration file (``meta/conf/bitbake.conf``):: TARGET_AS_ARCH = "${TUNE_ASARGS}" @@ -7869,8 +7611,7 @@ system and gives an overview of their function and contents. Specifies architecture-specific linker flags for the target system. ``TARGET_LD_ARCH`` is initialized from :term:`TUNE_LDARGS` by default in the BitBake - configuration file (``meta/conf/bitbake.conf``): - :: + configuration file (``meta/conf/bitbake.conf``):: TARGET_LD_ARCH = "${TUNE_LDARGS}" @@ -8051,8 +7792,7 @@ system and gives an overview of their function and contents. 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" @@ -8090,8 +7830,7 @@ system and gives an overview of their function and contents. Tests include ``ping``, ``ssh``, ``df`` among others. You can add your own tests to the list of tests by appending ``TEST_SUITES`` as - follows: - :: + follows:: TEST_SUITES_append = " mytest" @@ -8110,8 +7849,7 @@ system and gives an overview of their function and contents. another test must appear later in the list than the test on which they depend. For example, if you append the list of tests with two tests (``test_A`` and ``test_B``) where ``test_B`` is dependent on - ``test_A``, then you must order the tests as follows: - :: + ``test_A``, then you must order the tests as follows:: TEST_SUITES = "test_A test_B" @@ -8121,8 +7859,7 @@ system and gives an overview of their function and contents. :term:`TEST_TARGET` Specifies the target controller to use when running tests against a - test image. The default controller to use is "qemu": - :: + test image. The default controller to use is "qemu":: TEST_TARGET = "qemu" @@ -8161,8 +7898,7 @@ system and gives an overview of their function and contents. set to "qemu". When you specify the IP address, you can also include a port. Here is - an example: - :: + an example:: TEST_TARGET_IP = "192.168.1.4:2201" @@ -8211,8 +7947,7 @@ system and gives an overview of their function and contents. If you want to establish this directory in a location other than the default, you can uncomment and edit the following statement in the - ``conf/local.conf`` file in the :term:`Source Directory`: - :: + ``conf/local.conf`` file in the :term:`Source Directory`:: #TMPDIR = "${TOPDIR}/tmp" @@ -8231,8 +7966,7 @@ system and gives an overview of their function and contents. packages specified by this variable are part of the toolchain set that runs on the :term:`SDKMACHINE`, and each package should usually have the prefix ``nativesdk-``. For example, - consider the following command when building an SDK: - :: + consider the following command when building an SDK:: $ bitbake -c populate_sdk imagename @@ -8253,8 +7987,7 @@ system and gives an overview of their function and contents. :term:`TOOLCHAIN_OUTPUTNAME` This variable defines the name used for the toolchain output. The :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` class sets - the ``TOOLCHAIN_OUTPUTNAME`` variable as follows: - :: + the ``TOOLCHAIN_OUTPUTNAME`` variable as follows:: TOOLCHAIN_OUTPUTNAME ?= "${SDK_NAME}-toolchain-${SDK_VERSION}" @@ -8310,8 +8043,7 @@ system and gives an overview of their function and contents. ``TUNE_ARCH`` is tied closely to :term:`TARGET_ARCH`, which defines the target machine's architecture. The BitBake configuration file - (``meta/conf/bitbake.conf``) sets ``TARGET_ARCH`` as follows: - :: + (``meta/conf/bitbake.conf``) sets ``TARGET_ARCH`` as follows:: TARGET_ARCH = "${TUNE_ARCH}" @@ -8333,8 +8065,7 @@ system and gives an overview of their function and contents. typically under ``meta/conf/machine/include/`` and are influenced through :term:`TUNE_FEATURES`. For example, the ``meta/conf/machine/include/x86/arch-x86.inc`` file defines the flags - for the x86 architecture as follows: - :: + for the x86 architecture as follows:: TUNE_ASARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-x32", "", d)}" @@ -8367,8 +8098,7 @@ system and gives an overview of their function and contents. are not conflicting and that they are supported. The BitBake configuration file (``meta/conf/bitbake.conf``) defines - ``TUNE_FEATURES`` as follows: - :: + ``TUNE_FEATURES`` as follows:: TUNE_FEATURES ??= "${TUNE_FEATURES_tune-${DEFAULTTUNE}}" @@ -8381,8 +8111,7 @@ system and gives an overview of their function and contents. typically under ``meta/conf/machine/include/`` and are influenced through :term:`TUNE_FEATURES`. For example, the ``meta/conf/machine/include/x86/arch-x86.inc`` file defines the flags - for the x86 architecture as follows: - :: + for the x86 architecture as follows:: TUNE_LDARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-m elf32_x86_64", "", d)}" @@ -8395,15 +8124,13 @@ system and gives an overview of their function and contents. :term:`TUNE_PKGARCH` The package architecture understood by the packaging system to define the architecture, ABI, and tuning of output packages. The specific - tune is defined using the "_tune" override as follows: - :: + tune is defined using the "_tune" override as follows:: TUNE_PKGARCH_tune-tune = "tune" These tune-specific package architectures are defined in the machine include files. Here is an example of the "core2-32" tuning as used in - the ``meta/conf/machine/include/tune-core2.inc`` file: - :: + the ``meta/conf/machine/include/tune-core2.inc`` file:: TUNE_PKGARCH_tune-core2-32 = "core2-32" @@ -8449,8 +8176,7 @@ system and gives an overview of their function and contents. the :term:`Source Directory`. Here is an example from the ``meta/conf/machine/include/mips/arch-mips.inc`` include file that lists the "o32" and "n64" features as conflicting with the "n32" - feature: - :: + feature:: TUNECONFLICTS[n32] = "o32 n64" @@ -8459,8 +8185,7 @@ system and gives an overview of their function and contents. feature. The specified feature is stored as a flag. Valid features are specified in the machine include files (e.g. ``meta/conf/machine/include/arm/arch-arm.inc``). Here is an example - from that file: - :: + from that file:: TUNEVALID[bigendian] = "Enable big-endian mode." @@ -8516,8 +8241,7 @@ system and gives an overview of their function and contents. Appends a string to the name of the local version of the U-Boot image. For example, assuming the version of the U-Boot image built was "2013.10", the full version string reported by U-Boot would be - "2013.10-yocto" given the following statement: - :: + "2013.10-yocto" given the following statement:: UBOOT_LOCALVERSION = "-yocto" @@ -8691,8 +8415,7 @@ system and gives an overview of their function and contents. OpenEmbedded build system to enable extra features (e.g. ``buildstats``, ``image-mklibs``, and so forth). - The default list is set in your ``local.conf`` file: - :: + The default list is set in your ``local.conf`` file:: USER_CLASSES ?= "buildstats image-mklibs image-prelink" @@ -8712,8 +8435,7 @@ system and gives an overview of their function and contents. ``USERADD_ERROR_DYNAMIC`` variable is by default not set. If you plan on using statically assigned ``gid`` and ``uid`` values, you should set the ``USERADD_ERROR_DYNAMIC`` variable in your ``local.conf`` - file as follows: - :: + file as follows:: USERADD_ERROR_DYNAMIC = "error" @@ -8743,8 +8465,7 @@ system and gives an overview of their function and contents. When applying static group identification (``gid``) values, the OpenEmbedded build system looks in :term:`BBPATH` for a ``files/group`` file and then applies those ``uid`` values. Set the - variable as follows in your ``local.conf`` file: - :: + variable as follows in your ``local.conf`` file:: USERADD_GID_TABLES = "files/group" @@ -8761,8 +8482,7 @@ system and gives an overview of their function and contents. You must set this variable if the recipe inherits the class. For example, the following enables adding a user for the main package in - a recipe: - :: + a recipe:: USERADD_PACKAGES = "${PN}" @@ -8778,8 +8498,7 @@ system and gives an overview of their function and contents. the ``useradd`` command if you add a user to the system when the package is installed. - Here is an example from the ``dbus`` recipe: - :: + Here is an example from the ``dbus`` recipe:: USERADD_PARAM_${PN} = "--system --home ${localstatedir}/lib/dbus \ --no-create-home --shell /bin/false \ @@ -8797,8 +8516,7 @@ system and gives an overview of their function and contents. When applying static user identification (``uid``) values, the OpenEmbedded build system looks in :term:`BBPATH` for a ``files/passwd`` file and then applies those ``uid`` values. Set the - variable as follows in your ``local.conf`` file: - :: + variable as follows in your ``local.conf`` file:: USERADD_UID_TABLES = "files/passwd" @@ -8869,8 +8587,7 @@ system and gives an overview of their function and contents. With the ``WKS_FILE_DEPENDS`` variable, you have the possibility to specify a list of additional dependencies (e.g. native tools, bootloaders, and so forth), that are required to build Wic images. - Following is an example: - :: + Following is an example:: WKS_FILE_DEPENDS = "some-native-tool" @@ -8884,8 +8601,7 @@ system and gives an overview of their function and contents. :term:`TMPDIR` directory structure and is specific to the recipe being built and the system for which it is being built. - The ``WORKDIR`` directory is defined as follows: - :: + The ``WORKDIR`` directory is defined as follows:: ${TMPDIR}/work/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR} @@ -8904,8 +8620,7 @@ system and gives an overview of their function and contents. ``qemux86-poky-linux`` machine target system. Furthermore, suppose your recipe is named ``foo_1.3.0-r0.bb``. In this case, the work directory the build system uses to build the package would be as - follows: - :: + follows:: poky/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0 |