reset upstream subtrees to yocto 2.6
Reset the following subtrees on thud HEAD:
poky: 87e3a9739d
meta-openembedded: 6094ae18c8
meta-security: 31dc4e7532
meta-raspberrypi: a48743dc36
meta-xilinx: c42016e2e6
Also re-apply backports that didn't make it into thud:
poky:
17726d0 systemd-systemctl-native: handle Install wildcards
meta-openembedded:
4321a5d libtinyxml2: update to 7.0.1
042f0a3 libcereal: Add native and nativesdk classes
e23284f libcereal: Allow empty package
030e8d4 rsyslog: curl-less build with fmhttp PACKAGECONFIG
179a1b9 gtest: update to 1.8.1
Squashed OpenBMC subtree compatibility updates:
meta-aspeed:
Brad Bishop (1):
aspeed: add yocto 2.6 compatibility
meta-ibm:
Brad Bishop (1):
ibm: prepare for yocto 2.6
meta-ingrasys:
Brad Bishop (1):
ingrasys: set layer compatibility to yocto 2.6
meta-openpower:
Brad Bishop (1):
openpower: set layer compatibility to yocto 2.6
meta-phosphor:
Brad Bishop (3):
phosphor: set layer compatibility to thud
phosphor: libgpg-error: drop patches
phosphor: react to fitimage artifact rename
Ed Tanous (4):
Dropbear: upgrade options for latest upgrade
yocto2.6: update openssl options
busybox: remove upstream watchdog patch
systemd: Rebase CONFIG_CGROUP_BPF patch
Change-Id: I7b1fe71cca880d0372a82d94b5fd785323e3a9e7
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
diff --git a/poky/documentation/ref-manual/migration.xml b/poky/documentation/ref-manual/migration.xml
index b060968..c648d8d 100644
--- a/poky/documentation/ref-manual/migration.xml
+++ b/poky/documentation/ref-manual/migration.xml
@@ -3619,7 +3619,7 @@
<para>
The
- <link linkend='var-KERNEL_IMAGE_BASE_NAME'><filename>KERNEL_IMAGE_BASE_NAME</filename></link>
+ <filename>KERNEL_IMAGE_BASE_NAME</filename>
variable no longer uses the
<link linkend='var-KERNEL_IMAGETYPE'><filename>KERNEL_IMAGETYPE</filename></link>
variable to create the image's base name.
@@ -5557,8 +5557,9 @@
incompatible with other implementations.
</para></listitem>
<listitem><para>
- By default, the <filename>cmake</filename> class uses
- <filename>ninja</filename> instead of
+ By default, the
+ <link linkend='ref-classes-cmake'><filename>cmake</filename></link>
+ class uses <filename>ninja</filename> instead of
<filename>make</filename> for building.
This improves build performance.
If a recipe is broken with <filename>ninja</filename>, then
@@ -5608,7 +5609,11 @@
Any failure of a <filename>pkg_postinst()</filename>
script (including <filename>exit 1</filename>)
will trigger a warning during
- <filename>do_rootfs</filename>.
+ <filename>do_rootfs</filename>.</para>
+
+ <para>For more information, see the
+ "<ulink url='&YOCTO_DOCS_DEV_URL;#new-recipe-post-installation-scripts'>Post-Installation Scripts</ulink>"
+ section in the Yocto Project Development Tasks Manual.
</para></listitem>
<listitem><para>
The <filename>elf</filename> image type has been removed.
@@ -5678,6 +5683,648 @@
</para>
</section>
</section>
+
+<section id='moving-to-the-yocto-project-2.6-release'>
+ <title>Moving to the Yocto Project 2.6 Release</title>
+
+ <para>
+ This section provides migration information for moving to the
+ Yocto Project 2.6 Release from the prior release.
+ </para>
+
+ <section id='migration-2.6-gcc-changes'>
+ <title>GCC 8.2 is Now Used by Default</title>
+
+ <para>
+ The GNU Compiler Collection version 8.2 is now used by default
+ for compilation.
+ For more information on what has changed in the GCC 8.x release,
+ see
+ <ulink url='https://gcc.gnu.org/gcc-8/changes.html'></ulink>.
+ </para>
+
+ <para>
+ If you still need to compile with version 7.x, GCC 7.3 is
+ also provided.
+ You can select this version by setting the
+ and can be selected by setting the
+ <link linkend='var-GCCVERSION'><filename>GCCVERSION</filename></link>
+ variable to "7.%" in your configuration.
+ </para>
+ </section>
+
+ <section id='migration-2.6-removed-recipes'>
+ <title>Removed Recipes</title>
+
+ <para>
+ The following recipes have been removed:
+ <literallayout class='monospaced'>
+ <emphasis><filename>beecrypt</filename>:</emphasis> No longer needed since moving to RPM 4.
+ <emphasis><filename>bigreqsproto</filename>:</emphasis> Replaced by <filename>xorgproto</filename>.
+ <emphasis><filename>calibrateproto</filename>:</emphasis> Removed in favor of <filename>xinput</filename>.
+ <emphasis><filename>compositeproto</filename>:</emphasis> Replaced by <filename>xorgproto</filename>.
+ <emphasis><filename>damageproto</filename>:</emphasis> Replaced by <filename>xorgproto</filename>.
+ <emphasis><filename>dmxproto</filename>:</emphasis> Replaced by <filename>xorgproto</filename>.
+ <emphasis><filename>dri2proto</filename>:</emphasis> Replaced by <filename>xorgproto</filename>.
+ <emphasis><filename>dri3proto</filename>:</emphasis> Replaced by <filename>xorgproto</filename>.
+ <emphasis><filename>eee-acpi-scripts</filename>:</emphasis> Became obsolete.
+ <emphasis><filename>fixesproto</filename>:</emphasis> Replaced by <filename>xorgproto</filename>.
+ <emphasis><filename>fontsproto</filename>:</emphasis> Replaced by <filename>xorgproto</filename>.
+ <emphasis><filename>fstests</filename>:</emphasis> Became obsolete.
+ <emphasis><filename>gccmakedep</filename>:</emphasis> No longer used.
+ <emphasis><filename>glproto</filename>:</emphasis> Replaced by <filename>xorgproto</filename>.
+ <emphasis><filename>gnome-desktop3</filename>:</emphasis> No longer needed. This recipe has moved to <filename>meta-oe</filename>.
+ <emphasis><filename>icon-naming-utils</filename>:</emphasis> No longer used since the Sato theme was removed in 2016.
+ <emphasis><filename>inputproto</filename>:</emphasis> Replaced by <filename>xorgproto</filename>.
+ <emphasis><filename>kbproto</filename>:</emphasis> Replaced by <filename>xorgproto</filename>.
+ <emphasis><filename>libusb-compat</filename>:</emphasis> Became obsolete.
+ <emphasis><filename>libuser</filename>:</emphasis> Became obsolete.
+ <emphasis><filename>libnfsidmap</filename>:</emphasis> No longer an external requirement since <filename>nfs-utils</filename> 2.2.1. <filename>libnfsidmap</filename> is now integrated.
+ <emphasis><filename>libxcalibrate</filename>:</emphasis> No longer needed with <filename>xinput</filename>
+ <emphasis><filename>mktemp</filename>:</emphasis> Became obsolete. The <filename>mktemp</filename> command is provided by both <filename>busybox</filename> and <filename>coreutils</filename>.
+ <emphasis><filename>ossp-uuid</filename>:</emphasis> Is not being maintained and has mostly been replaced by <filename>uuid.h</filename> in <filename>util-linux</filename>.
+ <emphasis><filename>pax-utils</filename>:</emphasis> No longer needed. Previous QA tests that did use this recipe are now done at build time.
+ <emphasis><filename>pcmciautils</filename>:</emphasis> Became obsolete.
+ <emphasis><filename>pixz</filename>:</emphasis> No longer needed. <filename>xz</filename> now supports multi-threaded compression.
+ <emphasis><filename>presentproto</filename>:</emphasis> Replaced by <filename>xorgproto</filename>.
+ <emphasis><filename>randrproto</filename>:</emphasis> Replaced by <filename>xorgproto</filename>.
+ <emphasis><filename>recordproto</filename>:</emphasis> Replaced by <filename>xorgproto</filename>.
+ <emphasis><filename>renderproto</filename>:</emphasis> Replaced by <filename>xorgproto</filename>.
+ <emphasis><filename>resourceproto</filename>:</emphasis> Replaced by <filename>xorgproto</filename>.
+ <emphasis><filename>scrnsaverproto</filename>:</emphasis> Replaced by <filename>xorgproto</filename>.
+ <emphasis><filename>trace-cmd</filename>:</emphasis> Became obsolete. <filename>perf</filename> replaced this recipe's functionally.
+ <emphasis><filename>videoproto</filename>:</emphasis> Replaced by <filename>xorgproto</filename>.
+ <emphasis><filename>wireless-tools</filename>:</emphasis> Became obsolete. Superseded by <filename>iw</filename>.
+ <emphasis><filename>xcmiscproto</filename>:</emphasis> Replaced by <filename>xorgproto</filename>.
+ <emphasis><filename>xextproto</filename>:</emphasis> Replaced by <filename>xorgproto</filename>.
+ <emphasis><filename>xf86dgaproto</filename>:</emphasis> Replaced by <filename>xorgproto</filename>.
+ <emphasis><filename>xf86driproto</filename>:</emphasis> Replaced by <filename>xorgproto</filename>.
+ <emphasis><filename>xf86miscproto</filename>:</emphasis> Replaced by <filename>xorgproto</filename>.
+ <emphasis><filename>xf86-video-omapfb</filename>:</emphasis> Became obsolete. Use kernel modesetting driver instead.
+ <emphasis><filename>xf86-video-omap</filename>:</emphasis> Became obsolete. Use kernel modesetting driver instead.
+ <emphasis><filename>xf86vidmodeproto</filename>:</emphasis> Replaced by <filename>xorgproto</filename>.
+ <emphasis><filename>xineramaproto</filename>:</emphasis> Replaced by <filename>xorgproto</filename>.
+ <emphasis><filename>xproto</filename>:</emphasis> Replaced by <filename>xorgproto</filename>.
+ <emphasis><filename>yasm</filename>:</emphasis> No longer needed since previous usages are now satisfied by <filename>nasm</filename>.
+ </literallayout>
+ </para>
+ </section>
+
+ <section id='migration-2.6-packaging-changes'>
+ <title>Packaging Changes</title>
+
+ <para>
+ The following packaging changes have been made:
+ <itemizedlist>
+ <listitem><para>
+ <emphasis><filename>cmake</filename>:</emphasis>
+ <filename>cmake.m4</filename> and
+ <filename>toolchain</filename> files have been moved to the
+ main package.
+ </para></listitem>
+ <listitem><para>
+ <emphasis><filename>iptables</filename>:</emphasis>
+ The <filename>iptables</filename> modules have been split
+ into separate packages.
+ </para></listitem>
+ <listitem><para>
+ <emphasis><filename>alsa-lib</filename>:</emphasis>
+ <filename>libasound</filename> is now in the main
+ <filename>alsa-lib</filename> package instead of
+ <filename>libasound</filename>.
+ </para></listitem>
+ <listitem><para>
+ <emphasis><filename>glibc</filename>:</emphasis>
+ <filename>libnss-db</filename> is now in its own package
+ along with a <filename>/var/db/makedbs.sh</filename>
+ script to update databases.
+ </para></listitem>
+ <listitem><para>
+ <emphasis><filename>python</filename> and <filename>python3</filename>:</emphasis>
+ The main package has been removed from the recipe.
+ You must install specific packages or
+ <filename>python-modules</filename> /
+ <filename>python3-modules</filename> for everything.
+ </para></listitem>
+ <listitem><para>
+ <emphasis><filename>systemtap</filename>:</emphasis>
+ Moved <filename>systemtap-exporter</filename> into its own
+ package.
+ </para></listitem>
+ </itemizedlist>
+ </para>
+ </section>
+
+ <section id='migration-2.6-xorg-protocol-dependencies'>
+ <title>XOrg Protocol dependencies</title>
+
+ <para>
+ The "*proto" upstream repositories have been combined into one
+ "xorgproto" repository.
+ Thus, the corresponding recipes have also been combined into a
+ single <filename>xorgproto</filename> recipe.
+ Any recipes that depend upon the older <filename>*proto</filename>
+ recipes need to be changed to depend on the newer
+ <filename>xorgproto</filename> recipe instead.
+ </para>
+
+ <para>
+ For names of recipes removed because of this repository change,
+ see the
+ <link linkend="migration-2.6-removed-recipes">Removed Recipes</link>
+ section.
+ </para>
+ </section>
+
+ <section id='migration-2.6-distutils-distutils3-fetching-dependencies'>
+ <title><filename>distutils</filename> and <filename>distutils3</filename> Now Prevent Fetching Dependencies During the <filename>do_configure</filename> Task</title>
+
+ <para>
+ Previously, it was possible for Python recipes that inherited
+ the
+ <link linkend='ref-classes-distutils'><filename>distutils</filename></link>
+ and
+ <link linkend='ref-classes-distutils3'><filename>distutils3</filename></link>
+ classes to fetch code during the
+ <link linkend='ref-tasks-configure'><filename>do_configure</filename></link>
+ task to satisfy dependencies mentioned in
+ <filename>setup.py</filename> if those dependencies were not
+ provided in the sysroot (i.e. recipes providing the dependencies
+ were missing from
+ <link linkend='var-DEPENDS'><filename>DEPENDS</filename></link>).
+ <note>
+ This change affects classes beyond just the two mentioned
+ (i.e. <filename>distutils</filename> and
+ <filename>distutils3</filename>).
+ Any recipe that inherits <filename>distutils*</filename>
+ classes are affected.
+ For example, the <filename>setuptools</filename> and
+ <filename>setuptools3</filename> recipes are affected since
+ they inherit the <filename>distutils*</filename> classes.
+ </note>
+ </para>
+
+ <para>
+ Fetching these types of dependencies that are not provided in the
+ sysroot negatively affects the ability to reproduce builds.
+ This type of fetching is now explicitly disabled.
+ Consequently, any missing dependencies in Python recipes that
+ use these classes now result in an error during the
+ <filename>do_configure</filename> task.
+ </para>
+ </section>
+
+ <section id='migration-2.6-linux-yocto-configuration-audit-issues-now-correctly-reported'>
+ <title><filename>linux-yocto</filename> Configuration Audit Issues Now Correctly Reported</title>
+
+ <para>
+ Due to a bug, the kernel configuration audit functionality was
+ not writing out any resulting warnings during the build.
+ This issue is now corrected.
+ You might notice these warnings now if you have a custom kernel
+ configuration with a <filename>linux-yocto</filename> style
+ kernel recipe.
+ </para>
+ </section>
+
+ <section id='migration-2.6-image-kernel-artifact-naming-changes'>
+ <title>Image/Kernel Artifact Naming Changes</title>
+
+ <para>
+ The following changes have been made:
+ <itemizedlist>
+ <listitem><para>
+ Name variables (e.g.
+ <link linkend='var-IMAGE_NAME'><filename>IMAGE_NAME</filename></link>)
+ use a new <filename>IMAGE_VERSION_SUFFIX</filename>
+ variable instead of
+ <link linkend='var-DATETIME'><filename>DATETIME</filename></link>.
+ Using <filename>IMAGE_VERSION_SUFFIX</filename> allows
+ easier and more direct changes.</para>
+
+ <para>The <filename>IMAGE_VERSION_SUFFIX</filename>
+ variable is set in the
+ <filename>bitbake.conf</filename> configuration file as
+ follows:
+ <literallayout class='monospaced'>
+ IMAGE_VERSION_SUFFIX = "-${DATETIME}"
+ </literallayout>
+ </para></listitem>
+ <listitem><para>
+ Several variables have changed names for consistency:
+ <literallayout class='monospaced'>
+ Old Variable Name New Variable Name
+ ========================================================
+ KERNEL_IMAGE_BASE_NAME <link linkend='var-KERNEL_IMAGE_NAME'>KERNEL_IMAGE_NAME</link>
+ KERNEL_IMAGE_SYMLINK_NAME <link linkend='var-KERNEL_IMAGE_LINK_NAME'>KERNEL_IMAGE_LINK_NAME</link>
+ MODULE_TARBALL_BASE_NAME <link linkend='var-MODULE_TARBALL_NAME'>MODULE_TARBALL_NAME</link>
+ MODULE_TARBALL_SYMLINK_NAME <link linkend='var-MODULE_TARBALL_LINK_NAME'>MODULE_TARBALL_LINK_NAME</link>
+ INITRAMFS_BASE_NAME <link linkend='var-INITRAMFS_NAME'>INITRAMFS_NAME</link>
+ </literallayout>
+ </para></listitem>
+ <listitem><para>
+ The <filename>MODULE_IMAGE_BASE_NAME</filename> variable
+ has been removed.
+ The module tarball name is now controlled directly with the
+ <link linkend='var-MODULE_TARBALL_NAME'><filename>MODULE_TARBALL_NAME</filename></link>
+ variable.
+ </para></listitem>
+ <listitem><para>
+ The
+ <link linkend='var-KERNEL_DTB_NAME'><filename>KERNEL_DTB_NAME</filename></link>
+ and
+ <link linkend='var-KERNEL_DTB_LINK_NAME'><filename>KERNEL_DTB_LINK_NAME</filename></link>
+ variables have been introduced to control kernel Device
+ Tree Binary (DTB) artifact names instead of mangling
+ <filename>KERNEL_IMAGE_*</filename> variables.
+ </para></listitem>
+ <listitem><para>
+ The
+ <link linkend='var-KERNEL_FIT_NAME'><filename>KERNEL_FIT_NAME</filename></link>
+ and
+ <link linkend='var-KERNEL_FIT_LINK_NAME'><filename>KERNEL_FIT_LINK_NAME</filename></link>
+ variables have been introduced to specify the name of
+ flattened image tree (FIT) kernel images similar to other
+ deployed artifacts.
+ </para></listitem>
+ <listitem><para>
+ The
+ <link linkend='var-MODULE_TARBALL_NAME'><filename>MODULE_TARBALL_NAME</filename></link>
+ and
+ <link linkend='var-MODULE_TARBALL_LINK_NAME'><filename>MODULE_TARBALL_LINK_NAME</filename></link>
+ variable values no longer include the "module-" prefix or
+ ".tgz" suffix.
+ These parts are now hardcoded so that the values are
+ consistent with other artifact naming variables.
+ </para></listitem>
+ <listitem><para>
+ Added the
+ <link linkend='var-INITRAMFS_LINK_NAME'><filename>INITRAMFS_LINK_NAME</filename></link>
+ variable so that the symlink can be controlled similarly
+ to other artifact types.
+ </para></listitem>
+ <listitem><para>
+ <link linkend='var-INITRAMFS_NAME'><filename>INITRAMFS_NAME</filename></link>
+ now uses
+ "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
+ instead of
+ "${PV}-${PR}-${MACHINE}-${DATETIME}", which
+ makes it consistent with other variables.
+ </para></listitem>
+ </itemizedlist>
+ </para>
+ </section>
+
+ <section id='migration-2.6-serial-console-deprecated'>
+ <title><filename>SERIAL_CONSOLE</filename> Deprecated</title>
+
+ <para>
+ The
+ <link linkend='var-SERIAL_CONSOLE'><filename>SERIAL_CONSOLE</filename></link>
+ variable has been functionally replaced by the
+ <link linkend='var-SERIAL_CONSOLES'><filename>SERIAL_CONSOLES</filename></link>
+ variable for some time.
+ With the Yocto Project 2.6 release,
+ <filename>SERIAL_CONSOLE</filename> has been officially deprecated.
+ </para>
+
+ <para>
+ <filename>SERIAL_CONSOLE</filename> will continue to work as
+ before for the 2.6 release.
+ However, for the sake of future compatibility, it is recommended
+ that you replace all instances of
+ <filename>SERIAL_CONSOLE</filename> with
+ <filename>SERIAL_CONSOLES</filename>.
+ <note>
+ The only difference in usage is that
+ <filename>SERIAL_CONSOLES</filename> expects entries to be
+ separated using semicolons as compared to
+ <filename>SERIAL_CONSOLE</filename>, which expects spaces.
+ </note>
+ </para>
+ </section>
+
+ <section id='migration-2.6-poky-sets-unknown-configure-option-to-qa-error'>
+ <title>Configure Script Reports Unknown Options as Errors</title>
+
+ <para>
+ If the configure script reports an unknown option, this now
+ triggers a QA error instead of a warning.
+ Any recipes that previously got away with specifying such unknown
+ options now need to be fixed.
+ </para>
+ </section>
+
+ <section id='migration-2.6-override-changes'>
+ <title>Override Changes</title>
+
+ <para>
+ The following changes have occurred:
+ <itemizedlist>
+ <listitem><para>
+ <emphasis>The <filename>virtclass-native</filename> and
+ <filename>virtclass-nativesdk</filename> Overrides Have
+ Been Removed:</emphasis>
+ The <filename>virtclass-native</filename> and
+ <filename>virtclass-nativesdk</filename> overrides have
+ been deprecated since 2012 in favor of
+ <filename>class-native</filename> and
+ <filename>class-nativesdk</filename>, respectively.
+ Both <filename>virtclass-native</filename> and
+ <filename>virtclass-nativesdk</filename> are now dropped.
+ <note>
+ The <filename>virtclass-multilib-</filename> overrides
+ for multilib are still valid.
+ </note>
+ </para></listitem>
+ <listitem><para>
+ <emphasis>The <filename>forcevariable</filename>
+ Override Now Has a Higher Priority Than
+ <filename>libc</filename> Overrides:</emphasis>
+ The <filename>forcevariable</filename> override is
+ documented to be the highest priority override.
+ However, due to a long-standing quirk of how
+ <link linkend='var-OVERRIDES'><filename>OVERRIDES</filename></link>
+ is set, the <filename>libc</filename> overrides (e.g.
+ <filename>libc-glibc</filename>,
+ <filename>libc-musl</filename>, and so forth) erroneously
+ had a higher priority.
+ This issue is now corrected.</para>
+
+ <para>It is likely this change will not cause any
+ problems.
+ However, it is possible with some unusual configurations
+ that you might see a change in behavior if you were
+ relying on the previous behavior.
+ Be sure to check how you use
+ <filename>forcevariable</filename> and
+ <filename>libc-*</filename> overrides in your custom
+ layers and configuration files to ensure they make sense.
+ </para></listitem>
+ <listitem><para>
+ <emphasis>The <filename>build-${BUILD_OS}</filename>
+ Override Has Been Removed:</emphasis>
+ The <filename>build-${BUILD_OS}</filename>, which is
+ typically <filename>build-linux</filename>, override has
+ been removed because building on a host operating system
+ other than a recent version of Linux is neither supported
+ nor recommended.
+ Dropping the override avoids giving the impression that
+ other host operating systems might be supported.
+ </para></listitem>
+ <listitem><para>
+ The "_remove" operator now preserves whitespace.
+ Consequently, when specifying list items to remove, be
+ aware that leading and trailing whitespace resulting from
+ the removal is retained.</para>
+
+ <para>See the
+ "<ulink url='&YOCTO_DOCS_BB_URL;#removing-override-style-syntax'>Removal (Override Style Syntax)</ulink>"
+ section in the BitBake User Manual for a detailed example.
+ </para></listitem>
+ </itemizedlist>
+ </para>
+ </section>
+
+ <section id='migration-2.6-systemd-configuration-now-split-out-to-system-conf'>
+ <title><filename>systemd</filename> Configuration is Now Split Into <filename>systemd-conf</filename></title>
+
+ <para>
+ The configuration for the <filename>systemd</filename> recipe
+ has been moved into a <filename>system-conf</filename> recipe.
+ Moving this configuration to a separate recipe avoids the
+ <filename>systemd</filename> recipe from becoming machine-specific
+ for cases where machine-specific configurations need to be applied
+ (e.g. for <filename>qemu*</filename> machines).
+ </para>
+
+ <para>
+ Currently, the new recipe packages the following files:
+ <literallayout class='monospaced'>
+ ${sysconfdir}/machine-id
+ ${sysconfdir}/systemd/coredump.conf
+ ${sysconfdir}/systemd/journald.conf
+ ${sysconfdir}/systemd/logind.conf
+ ${sysconfdir}/systemd/system.conf
+ ${sysconfdir}/systemd/user.conf
+ </literallayout>
+ If you previously used bbappend files to append the
+ <filename>systemd</filename> recipe to change any of the
+ listed files, you must do so for the
+ <filename>systemd-conf</filename> recipe instead.
+ </para>
+ </section>
+
+ <section id='migration-2.6-automatic-testing-changes'>
+ <title>Automatic Testing Changes</title>
+
+ <para>
+ This section provides information about automatic testing
+ changes:
+ <itemizedlist>
+ <listitem><para>
+ <emphasis><filename>TEST_IMAGE</filename> Variable Removed:</emphasis>
+ Prior to this release, you set the
+ <filename>TEST_IMAGE</filename> variable to "1" to
+ enable automatic testing for successfully built images.
+ The <filename>TEST_IMAGE</filename> variable no longer
+ exists and has been replaced by the
+ <link linkend='var-TESTIMAGE_AUTO'><filename>TESTIMAGE_AUTO</filename></link>
+ variable.
+ </para></listitem>
+ <listitem><para>
+ <emphasis>Inheriting the <filename>testimage</filename> and
+ <filename>testsdk</filename> Classes:</emphasis>
+ Best practices now dictate that you use the
+ <link linkend='var-IMAGE_CLASSES'><filename>IMAGE_CLASSES</filename></link>
+ variable rather than the
+ <link linkend='var-INHERIT'><filename>INHERIT</filename></link>
+ variable when you inherit the
+ <link linkend='ref-classes-testimage*'><filename>testimage</filename></link>
+ and
+ <link linkend='ref-classes-testsdk'><filename>testsdk</filename></link>
+ classes used for automatic testing.
+ </para></listitem>
+ </itemizedlist>
+ </para>
+ </section>
+
+ <section id='migration-2.6-openssl-changes'>
+ <title>OpenSSL Changes</title>
+
+ <para>
+ <ulink url='https://www.openssl.org/'>OpenSSL</ulink> has been
+ upgraded from 1.0 to 1.1.
+ By default, this upgrade could cause problems for recipes that
+ have both versions in their dependency chains.
+ The problem is that both versions cannot be installed together
+ at build time.
+ <note>
+ It is possible to have both versions of the library at runtime.
+ </note>
+ </para>
+ </section>
+
+ <section id='migration-2.6-bitbake-changes'>
+ <title>BitBake Changes</title>
+
+ <para>
+ The server logfile <filename>bitbake-cookerdaemon.log</filename> is
+ now always placed in the
+ <link linkend='build-directory'>Build Directory</link>
+ instead of the current directory.
+ </para>
+ </section>
+
+ <section id='migration-2.6-security-changes'>
+ <title>Security Changes</title>
+
+ <para>
+ The Poky distribution now uses security compiler flags by
+ default.
+ Inclusion of these flags could cause new failures due to stricter
+ checking for various potential security issues in code.
+ </para>
+ </section>
+
+ <section id='migration-2.6-post-installation-changes'>
+ <title>Post Installation Changes</title>
+
+ <para>
+ You must explicitly mark post installs to defer to the target.
+ If you want to explicitly defer a postinstall to first boot on
+ the target rather than at rootfs creation time, use
+ <filename>pkg_postinst_ontarget()</filename> or call
+ <filename>postinst-intercepts defer_to_first_boot</filename> from
+ <filename>pkg_postinst()</filename>.
+ Any failure of a <filename>pkg_postinst()</filename> script
+ (including exit 1) triggers an error during the
+ <link linkend='ref-tasks-rootfs'><filename>do_rootfs</filename></link> task.
+ </para>
+
+ <para>
+ For more information on post-installation behavior, see the
+ "<ulink url='&YOCTO_DOCS_DEV_URL;#new-recipe-post-installation-scripts'>Post-Installation Scripts</ulink>"
+ section in the Yocto Project Development Tasks Manual.
+ </para>
+ </section>
+
+ <section id='migration-2.6-python-3-profile-guided-optimizations'>
+ <title>Python 3 Profile-Guided Optimization</title>
+
+ <para>
+ The <filename>python3</filename> recipe now enables profile-guided
+ optimization.
+ Using this optimization requires a little extra build time in
+ exchange for improved performance on the target at runtime.
+ Additionally, the optimization is only enabled if the current
+ <link linkend='var-MACHINE'><filename>MACHINE</filename></link>
+ has support for user-mode emulation in QEMU (i.e. "qemu-usermode"
+ is in
+ <link linkend='var-MACHINE_FEATURES'><filename>MACHINE_FEATURES</filename></link>,
+ which it is by default).
+ </para>
+
+ <para>
+ If you wish to disable Python profile-guided optimization
+ regardless of the value of
+ <filename>MACHINE_FEATURES</filename>, then ensure that
+ <link linkend='var-PACKAGECONFIG'><filename>PACKAGECONFIG</filename></link>
+ for the <filename>python3</filename> recipe does not contain "pgo".
+ You could accomplish the latter using the following at the
+ configuration level:
+ <literallayout class='monospaced'>
+ PACKAGECONFIG_remove_pn-python3 = "pgo"
+ </literallayout>
+ Alternatively, you can set
+ <filename>PACKAGECONFIG</filename> using an append file for the
+ <filename>python3</filename> recipe.
+ </para>
+ </section>
+
+ <section id='migration-2.6-miscellaneous-changes'>
+ <title>Miscellaneous Changes</title>
+
+ <para>
+ The following miscellaneous changes occurred:
+ <itemizedlist>
+ <listitem><para>
+ 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:
+ <literallayout class='monospaced'>
+ ARM_INSTRUCTION_SET = "arm"
+ </literallayout>
+ </para></listitem>
+ <listitem><para>
+ <filename>run-postinsts</filename> no longer uses
+ <filename>/etc/*-postinsts</filename> for
+ <filename>dpkg/opkg</filename> in favor of built-in
+ postinst support.
+ RPM behavior remains unchanged.
+ </para></listitem>
+ <listitem><para>
+ The <filename>NOISO</filename> and
+ <filename>NOHDD</filename> variables are no longer used.
+ You now control building <filename>*.iso</filename> and
+ <filename>*.hddimg</filename> image types directly
+ by using the
+ <link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>
+ variable.
+ </para></listitem>
+ <listitem><para>
+ The <filename>scripts/contrib/mkefidisk.sh</filename>
+ has been removed in favor of Wic.
+ </para></listitem>
+ <listitem><para>
+ <filename>kernel-modules</filename> has been removed from
+ <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>
+ for <filename>qemumips</filename> and
+ <filename>qemumips64</filename> machines.
+ Removal also impacts the <filename>x86-base.inc</filename>
+ file.
+ <note>
+ <filename>genericx86</filename> and
+ <filename>genericx86-64</filename> retain
+ <filename>kernel-modules</filename> as part of the
+ <filename>RRECOMMENDS</filename> variable setting.
+ </note>
+ </para></listitem>
+ <listitem><para>
+ The <filename>LGPLv2_WHITELIST_GPL-3.0</filename>
+ variable has been removed.
+ If you are setting this variable in your configuration,
+ set or append it to the
+ <filename>WHITELIST_GPL-3.0</filename> variable instead.
+ </para></listitem>
+ <listitem><para>
+ <filename>${ASNEEDED}</filename> is now included in
+ the
+ <link linkend='var-TARGET_LDFLAGS'><filename>TARGET_LDFLAGS</filename></link>
+ variable directly.
+ The remaining definitions from
+ <filename>meta/conf/distro/include/as-needed.inc</filename>
+ have been moved to corresponding recipes.
+ </para></listitem>
+ <listitem><para>
+ Support for DSA host keys has been dropped from the
+ OpenSSH recipes.
+ If you are still using DSA keys, you must switch over to a
+ more secure algorithm as recommended by OpenSSH upstream.
+ </para></listitem>
+ <listitem><para>
+ The <filename>dhcp</filename> recipe now uses the
+ <filename>dhcpd6.conf</filename> configuration file in
+ <filename>dhcpd6.service</filename> for IPv6 DHCP rather
+ than re-using <filename>dhcpd.conf</filename>, which is
+ now reserved for IPv4.
+ </para></listitem>
+ </itemizedlist>
+ </para>
+ </section>
+</section>
</chapter>
<!--
vim: expandtab tw=80 ts=4
diff --git a/poky/documentation/ref-manual/ref-classes.xml b/poky/documentation/ref-manual/ref-classes.xml
index 77f21ed..d602851 100644
--- a/poky/documentation/ref-manual/ref-classes.xml
+++ b/poky/documentation/ref-manual/ref-classes.xml
@@ -449,12 +449,13 @@
<title><filename>cmake.bbclass</filename></title>
<para>
- The <filename>cmake</filename> class allows for
- recipes that need to build software using the CMake build system.
+ The <filename>cmake</filename> class allows for recipes that need to
+ build software using the
+ <ulink url='https://cmake.org/overview/'>CMake</ulink> build system.
You can use the
<link linkend='var-EXTRA_OECMAKE'><filename>EXTRA_OECMAKE</filename></link>
- variable to specify additional configuration options to be passed on
- the <filename>cmake</filename> command line.
+ variable to specify additional configuration options to be passed
+ using the <filename>cmake</filename> command line.
</para>
</section>
@@ -645,6 +646,54 @@
</para>
</section>
+<section id='ref-classes-devupstream'>
+ <title><filename>devupstream.bbclass</filename></title>
+
+ <para>
+ The <filename>devupstream</filename> class uses
+ <link linkend='var-BBCLASSEXTEND'><filename>BBCLASSEXTEND</filename></link>
+ to add a variant of the recipe that fetches from an alternative URI
+ (e.g. Git) instead of a tarball.
+ Following is an example:
+ <literallayout class='monospaced'>
+ BBCLASSEXTEND = "devupstream:target"
+ SRC_URI_class-devupstream = "git://git.example.com/example"
+ SRCREV_class-devupstream = "abcd1234"
+ </literallayout>
+ Adding the above statements to your recipe creates a variant that has
+ <link linkend='var-DEFAULT_PREFERENCE'><filename>DEFAULT_PREFERENCE</filename></link>
+ 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
+ <filename>class-devupstream</filename> override.
+ Here is an example:
+ <literallayout class='monospaced'>
+ DEPENDS_append_class-devupstream = " gperf-native"
+
+ do_configure_prepend_class-devupstream() {
+ touch ${S}/README
+ }
+ </literallayout>
+ The class currently only supports creating a development variant of
+ the target recipe, not <filename>native</filename> or
+ <filename>nativesdk</filename> variants.
+ </para>
+
+ <para>
+ The <filename>BBCLASSEXTEND</filename> syntax
+ (i.e. <filename>devupstream:target</filename>) provides support for
+ <filename>native</filename> and <filename>nativesdk</filename>
+ variants.
+ Consequently, this functionality can be added in a future release.
+ </para>
+
+ <para>
+ Support for other version control systems such as Subversion is
+ limited due to BitBake's automatic fetch dependencies (e.g.
+ <filename>subversion-native</filename>).
+ </para>
+</section>
+
<section id='ref-classes-distro_features_check'>
<title><filename>distro_features_check.bbclass</filename></title>
@@ -1266,28 +1315,35 @@
<title><filename>image_types.bbclass</filename></title>
<para>
- The <filename>image_types</filename> class defines all of
- the standard image output types that you can enable through the
+ The <filename>image_types</filename> class defines all of the
+ standard image output types that you can enable through the
<link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>
variable.
- You can use this class as a reference on how to add support for custom
- image output types.
+ You can use this class as a reference on how to add support for
+ custom image output types.
</para>
<para>
- By default, this class is enabled through the
- <link linkend='var-IMAGE_CLASSES'><filename>IMAGE_CLASSES</filename></link>
- variable in
- <link linkend='ref-classes-image'><filename>image.bbclass</filename></link>.
- If you define your own image types using a custom BitBake class and
- then use <filename>IMAGE_CLASSES</filename> to enable it, the custom
- class must either inherit <filename>image_types</filename> or
- <filename>image_types</filename> must also appear in
- <filename>IMAGE_CLASSES</filename>.
+ By default, the
+ <link linkend='ref-classes-image'><filename>image</filename></link>
+ class automatically enables the <filename>image_types</filename> class.
+ The <filename>image</filename> class uses the
+ <filename>IMGCLASSES</filename> variable as follows:
+ <literallayout class='monospaced'>
+ IMGCLASSES = "rootfs_${IMAGE_PKGTYPE} image_types ${IMAGE_CLASSES}"
+ IMGCLASSES += "${@['populate_sdk_base', 'populate_sdk_ext']['linux' in d.getVar("SDK_OS")]}"
+ IMGCLASSES += "${@bb.utils.contains_any('IMAGE_FSTYPES', 'live iso hddimg', 'image-live', '', d)}"
+ IMGCLASSES += "${@bb.utils.contains('IMAGE_FSTYPES', 'container', 'image-container', '', d)}"
+ IMGCLASSES += "image_types_wic"
+ IMGCLASSES += "rootfs-postcommands"
+ IMGCLASSES += "image-postinst-intercepts"
+ inherit ${IMGCLASSES}
+ </literallayout>
</para>
<para>
- This class also handles conversion and compression of images.
+ The <filename>image_types</filename> class also handles conversion and
+ compression of images.
<note>
To build a VMware VMDK image, you need to add "wic.vmdk" to
<filename>IMAGE_FSTYPES</filename>.
@@ -1314,14 +1370,6 @@
Normally, you do not use this class directly.
Instead, you add "live" to
<link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>.
- You can selectively build just one of these types through the
- <link linkend='var-NOISO'><filename>NOISO</filename></link>
- and
- <link linkend='var-NOHDD'><filename>NOHDD</filename></link> variables.
- For example, if you were building an ISO image, you would add "live"
- to <filename>IMAGE_FSTYPES</filename>, set the
- <filename>NOISO</filename> variable to "0" and the build system would
- use the <filename>image-live</filename> class to build the ISO image.
</para>
</section>
@@ -2173,8 +2221,9 @@
<para>
The <filename>native</filename> class provides common
- functionality for recipes that wish to build tools to run on the build
- host (i.e. tools that use the compiler or other tools from the
+ functionality for recipes that build tools to run on the
+ <link linkend='hardware-build-system-term'>build host</link>
+ (i.e. tools that use the compiler or other tools from the
build host).
</para>
@@ -2182,30 +2231,35 @@
You can create a recipe that builds tools that run natively on the
host a couple different ways:
<itemizedlist>
- <listitem><para>Create a <replaceable>myrecipe</replaceable><filename>-native.bb</filename>
- that inherits the <filename>native</filename> class.
+ <listitem><para>
+ Create a
+ <replaceable>myrecipe</replaceable><filename>-native.bb</filename>
+ recipe that inherits the <filename>native</filename> class.
If you use this method, you must order the inherit statement
in the recipe after all other inherit statements so that the
<filename>native</filename> class is inherited last.
+ <note><title>Warning</title>
+ When creating a recipe this way, the recipe name must
+ follow this naming convention:
+ <literallayout class='monospaced'>
+ <replaceable>myrecipe</replaceable>-native.bb
+ </literallayout>
+ Not using this naming convention can lead to subtle
+ problems caused by existing code that depends on that
+ naming convention.
+ </note>
</para></listitem>
- <listitem><para>Create or modify a target recipe that contains
- the following:
+ <listitem><para>
+ Create or modify a target recipe that contains the following:
<literallayout class='monospaced'>
<link linkend='var-BBCLASSEXTEND'><filename>BBCLASSEXTEND</filename></link> = "native"
</literallayout>
Inside the recipe, use <filename>_class-native</filename> and
<filename>_class-target</filename> overrides to specify any
functionality specific to the respective native or target
- case.</para></listitem>
+ case.
+ </para></listitem>
</itemizedlist>
- <note><title>Warning</title>
- When creating a recipe, you must follow this naming convention:
- <literallayout class='monospaced'>
- native-<replaceable>myrecipe</replaceable>.bb
- </literallayout>
- Not doing so can lead to subtle problems because code exists
- that depends on the naming convention.
- </note>
</para>
<para>
@@ -3145,12 +3199,6 @@
and <filename><link linkend='var-SITEINFO_BITS'>SITEINFO_BITS</link></filename>
that can be used elsewhere in the metadata.
</para>
-
- <para>
- Because the
- <link linkend='ref-classes-base'><filename>base</filename></link> class
- includes the <filename>siteinfo</filename> class, it is always active.
- </para>
</section>
<section id='ref-classes-spdx'>
@@ -3502,6 +3550,14 @@
The classes handle loading the tests and starting the image.
To use the classes, you need to perform steps to set up the
environment.
+ <note><title>Tip</title>
+ Best practices include using
+ <link linkend='var-IMAGE_CLASSES'><filename>IMAGE_CLASSES</filename></link>
+ rather than
+ <link linkend='var-INHERIT'><filename>INHERIT</filename></link> to
+ inherit the <filename>testimage</filename> class for automated
+ image testing.
+ </note>
</para>
<para>
@@ -3519,7 +3575,7 @@
</literallayout>
The <filename>testimage-auto</filename> class runs tests on an image
after the image is constructed (i.e.
- <link linkend='var-TEST_IMAGE'><filename>TEST_IMAGE</filename></link>
+ <link linkend='var-TESTIMAGE_AUTO'><filename>TESTIMAGE_AUTO</filename></link>
must be set to "1").
</para>
@@ -3541,6 +3597,14 @@
<literallayout class='monospaced'>
$ bitbake -c testsdk image
</literallayout>
+ <note><title>Tip</title>
+ Best practices include using
+ <link linkend='var-IMAGE_CLASSES'><filename>IMAGE_CLASSES</filename></link>
+ rather than
+ <link linkend='var-INHERIT'><filename>INHERIT</filename></link> to
+ inherit the <filename>testsdk</filename> class for automated
+ SDK testing.
+ </note>
</para>
</section>
diff --git a/poky/documentation/ref-manual/ref-manual.xml b/poky/documentation/ref-manual/ref-manual.xml
index 9d491e1..f834d2d 100644
--- a/poky/documentation/ref-manual/ref-manual.xml
+++ b/poky/documentation/ref-manual/ref-manual.xml
@@ -123,14 +123,14 @@
<revremark>Released with the Yocto Project 2.5 Release.</revremark>
</revision>
<revision>
- <revnumber>2.5.1</revnumber>
- <date>September 2018</date>
- <revremark>The initial document released with the Yocto Project 2.5.1 Release.</revremark>
+ <revnumber>2.6</revnumber>
+ <date>November 2018</date>
+ <revremark>Released with the Yocto Project 2.6 Release.</revremark>
</revision>
<revision>
- <revnumber>2.5.2</revnumber>
+ <revnumber>2.6.1</revnumber>
<date>&REL_MONTH_YEAR;</date>
- <revremark>The initial document released with the Yocto Project 2.5.2 Release.</revremark>
+ <revremark>Released with the Yocto Project 2.6.1 Release.</revremark>
</revision>
</revhistory>
diff --git a/poky/documentation/ref-manual/ref-release-process.xml b/poky/documentation/ref-manual/ref-release-process.xml
index c665cd9..5efe174 100644
--- a/poky/documentation/ref-manual/ref-release-process.xml
+++ b/poky/documentation/ref-manual/ref-release-process.xml
@@ -189,7 +189,7 @@
Running <filename>oe-selftest</filename> requires
host packages beyond the "Essential" grouping.
See the
- "<link linkend='required-packages-for-the-host-development-system'>Required Packages for the Host Development System</link>"
+ "<link linkend='required-packages-for-the-build-host'>Required Packages for the Build Host</link>"
section for more information.
</note>
</para></listitem>
diff --git a/poky/documentation/ref-manual/ref-system-requirements.xml b/poky/documentation/ref-manual/ref-system-requirements.xml
index aea1fdf..69d4b4e 100644
--- a/poky/documentation/ref-manual/ref-system-requirements.xml
+++ b/poky/documentation/ref-manual/ref-system-requirements.xml
@@ -66,6 +66,14 @@
below.
</para></listitem>
<listitem><para>
+ The Yocto Project is not compatible with the
+ <ulink url='https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux'>Windows Subsystem for Linux</ulink>
+ (WSL).
+ You cannot use a
+ <link linkend='hardware-build-system-term'>build host</link>
+ that is running WSL.
+ </para></listitem>
+ <listitem><para>
If you encounter problems, please go to
<ulink url='&YOCTO_BUGZILLA_URL;'>Yocto Project Bugzilla</ulink>
and submit a bug.
@@ -80,46 +88,49 @@
</itemizedlist>
</note>
<itemizedlist>
-<!--
- <listitem><para>Ubuntu 10.04</para></listitem>
+<!-- <listitem><para>Ubuntu 10.04</para></listitem>
<listitem><para>Ubuntu 11.10</para></listitem>
<listitem><para>Ubuntu 12.04 (LTS)</para></listitem>
<listitem><para>Ubuntu 13.10</para></listitem>
- <listitem><para>Ubuntu 14.04 (LTS)</para></listitem> -->
+ <listitem><para>Ubuntu 14.04 (LTS)</para></listitem>
<listitem><para>Ubuntu 14.10</para></listitem>
<listitem><para>Ubuntu 15.04</para></listitem>
- <listitem><para>Ubuntu 15.10</para></listitem>
+ <listitem><para>Ubuntu 15.10</para></listitem> -->
<listitem><para>Ubuntu 16.04 (LTS)</para></listitem>
-<!-- <listitem><para>Fedora 16 (Verne)</para></listitem>
+ <listitem><para>Ubuntu 16.10 (LTS)</para></listitem>
+ <listitem><para>Ubuntu 17.04</para></listitem>
+<!-- <listitem><para>Fedora 16 (Verne)</para></listitem>
<listitem><para>Fedora 17 (Spherical)</para></listitem>
- <listitem><para>Fedora release 19 (Schrödinger's Cat)</para></listitem>
- <listitem><para>Fedora release 20 (Heisenbug)</para></listitem> -->
+ <listitem><para>Fedora 19 (Schrödinger's Cat)</para></listitem>
+ <listitem><para>Fedora release 20 (Heisenbug)</para></listitem>
<listitem><para>Fedora release 22</para></listitem>
<listitem><para>Fedora release 23</para></listitem>
-<!-- <listitem><para>Fedora release 24</para></listitem>
- <listitem><para>CentOS release 5.6 (Final)</para></listitem>
+ <listitem><para>Fedora release 24</para></listitem> -->
+ <listitem><para>Fedora release 26</para></listitem>
+<!-- <listitem><para>CentOS release 5.6 (Final)</para></listitem>
<listitem><para>CentOS release 5.7 (Final)</para></listitem>
<listitem><para>CentOS release 5.8 (Final)</para></listitem>
<listitem><para>CentOS release 6.3 (Final)</para></listitem>
<listitem><para>CentOS release 6.x</para></listitem> -->
<listitem><para>CentOS release 7.x</para></listitem>
-<!-- <listitem><para>Debian GNU/Linux 6.0 (Squeeze)</para></listitem>
+<!-- <listitem><para>Debian GNU/Linux 6.0 (Squeeze)</para></listitem>
<listitem><para>Debian GNU/Linux 7.x (Wheezy)</para></listitem> -->
<listitem><para>Debian GNU/Linux 8.x (Jessie)</para></listitem>
<listitem><para>Debian GNU/Linux 9.x (Stretch)</para></listitem>
-<!-- <listitem><para>Debian GNU/Linux 7.1 (Wheezy)</para></listitem>
+<!-- <listitem><para>Debian GNU/Linux 7.1 (Wheezy)</para></listitem>
<listitem><para>Debian GNU/Linux 7.2 (Wheezy)</para></listitem>
<listitem><para>Debian GNU/Linux 7.3 (Wheezy)</para></listitem>
<listitem><para>Debian GNU/Linux 7.4 (Wheezy)</para></listitem>
<listitem><para>Debian GNU/Linux 7.5 (Wheezy)</para></listitem>
- <listitem><para>Debian GNU/Linux 7.6 (Wheezy)</para></listitem> -->
-<!-- <listitem><para>openSUSE 11.4</para></listitem>
+ <listitem><para>Debian GNU/Linux 7.6 (Wheezy)</para></listitem>
+ <listitem><para>openSUSE 11.4</para></listitem>
<listitem><para>openSUSE 12.1</para></listitem>
<listitem><para>openSUSE 12.2</para></listitem>
<listitem><para>openSUSE 12.3</para></listitem>
- <listitem><para>openSUSE 13.1</para></listitem> -->
- <listitem><para>openSUSE 13.2</para></listitem>
+ <listitem><para>openSUSE 13.1</para></listitem>
+ <listitem><para>openSUSE 13.2</para></listitem> -->
<listitem><para>openSUSE 42.1</para></listitem>
+ <listitem><para>openSUSE 42.2</para></listitem>
</itemizedlist>
</para>
@@ -132,8 +143,8 @@
</note>
</section>
- <section id='required-packages-for-the-host-development-system'>
- <title>Required Packages for the Host Development System</title>
+ <section id='required-packages-for-the-build-host'>
+ <title>Required Packages for the Build Host</title>
<para>
The list of packages you need on the host development system can
diff --git a/poky/documentation/ref-manual/ref-tasks.xml b/poky/documentation/ref-manual/ref-tasks.xml
index e6cf686..8f3ff26 100644
--- a/poky/documentation/ref-manual/ref-tasks.xml
+++ b/poky/documentation/ref-manual/ref-tasks.xml
@@ -596,15 +596,6 @@
</para>
</section>
- <section id='ref-tasks-rm_work_all'>
- <title><filename>do_rm_work_all</filename></title>
-
- <para>
- Top-level task for removing work files after the build system has
- finished with them.
- </para>
- </section>
-
<section id='ref-tasks-unpack'>
<title><filename>do_unpack</filename></title>
@@ -895,7 +886,7 @@
Boots an image and performs runtime tests within the image
immediately after it has been built.
This task is enabled when you set
- <link linkend='var-TEST_IMAGE'><filename>TEST_IMAGE</filename></link>
+ <link linkend='var-TESTIMAGE_AUTO'><filename>TESTIMAGE_AUTO</filename></link>
equal to "1".
</para>
diff --git a/poky/documentation/ref-manual/ref-terms.xml b/poky/documentation/ref-manual/ref-terms.xml
index cc09d3f..c573a52 100644
--- a/poky/documentation/ref-manual/ref-terms.xml
+++ b/poky/documentation/ref-manual/ref-terms.xml
@@ -29,11 +29,31 @@
information in the similarly-named recipe file.
For an example of an append file in use, see the
"<ulink url='&YOCTO_DOCS_DEV_URL;#using-bbappend-files'>Using .bbappend Files in Your Layer</ulink>"
- section in the Yocto Project Development Tasks Manual.
- <note>
- Append files can also use wildcard patterns in their
- version numbers so they can be applied to more than one
- version of the underlying recipe file.
+ section in the Yocto Project Development Tasks Manual.</para>
+
+ <para>When you name an append file, you can use the
+ "<filename>%</filename>" wildcard character to allow for
+ matching recipe names.
+ For example, suppose you have an append file named as follows:
+ <literallayout class='monospaced'>
+ busybox_1.21.%.bbappend
+ </literallayout>
+ That append file would match any
+ <filename>busybox_1.21.</filename><replaceable>x</replaceable><filename>.bb</filename>
+ version of the recipe.
+ So, the append file would match the following recipe names:
+ <literallayout class='monospaced'>
+ busybox_1.21.1.bb
+ busybox_1.21.2.bb
+ busybox_1.21.3.bb
+ </literallayout>
+ <note><title>Important</title>
+ The use of the "<filename>%</filename>" character
+ is limited in that it only works directly in front of the
+ <filename>.bbappend</filename> portion of the append file's
+ name.
+ You cannot use the wildcard character in any other
+ location of the name.
</note>
</para></listitem>
<listitem><para id='bitbake-term'>
@@ -329,7 +349,7 @@
<para>It is worth noting that the term "package" can,
in general, have subtle meanings.
For example, the packages referred to in the
- "<link linkend='required-packages-for-the-host-development-system'>Required Packages for the Host Development System</link>"
+ "<link linkend='required-packages-for-the-build-host'>Required Packages for the Build Host</link>"
section are compiled binaries that, when installed, add
functionality to your Linux distribution.</para>
diff --git a/poky/documentation/ref-manual/ref-variables.xml b/poky/documentation/ref-manual/ref-variables.xml
index e883896..9e51b75 100644
--- a/poky/documentation/ref-manual/ref-variables.xml
+++ b/poky/documentation/ref-manual/ref-variables.xml
@@ -679,6 +679,20 @@
<literallayout class='monospaced'>
BB_ALLOWED_NETWORKS = "*.gnu.org"
</literallayout>
+ <note><title>Important</title>
+ <para>The use of the "<filename>*</filename>"
+ character only works at the beginning of
+ a host name and it must be isolated from
+ the remainder of the host name.
+ You cannot use the wildcard character in any
+ other location of the name or combined with
+ the front part of the name.</para>
+
+ <para>For example,
+ <filename>*.foo.bar</filename> is supported,
+ while <filename>*aa.foo.bar</filename> is not.
+ </para>
+ </note>
</para></listitem>
<listitem><para>
Mirrors not in the host list are skipped and
@@ -1133,12 +1147,22 @@
<glossentry id='var-BBFILES'><glossterm>BBFILES</glossterm>
<info>
- BBFILES[doc] = "List of recipe files used by BitBake to build software."
+ BBFILES[doc] = "A space-separated list of recipe files BitBake uses to build software."
</info>
<glossdef>
<para role="glossdeffirst">
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
- List of recipe files used by BitBake to build software.
+ A space-separated list of recipe files BitBake uses to
+ build software.
+ </para>
+
+ <para>
+ When specifying recipe files, you can pattern match using
+ Python's
+ <ulink url='https://docs.python.org/3/library/glob.html'><filename>glob</filename></ulink>
+ syntax.
+ For details on the syntax, see the documentation by
+ following the previous link.
</para>
</glossdef>
</glossentry>
@@ -1267,15 +1291,19 @@
match any of the expressions.
It is as if BitBake does not see them at all.
Consequently, matching files are not parsed or otherwise
- used by BitBake.</para>
+ used by BitBake.
+ </para>
+
<para>
The values you provide are passed to Python's regular
expression compiler.
+ Consequently, the syntax follows Python's Regular
+ Expression (re) syntax.
The expressions are compared against the full paths to
the files.
For complete syntax information, see Python's
- documentation for the appropriate release at
- <ulink url='http://docs.python.org/release/'></ulink>.
+ documentation at
+ <ulink url='http://docs.python.org/3/library/re.html#re'></ulink>.
</para>
<para>
@@ -1336,7 +1364,7 @@
<filename>BBMULTICONFIG</filename> in an environment that
supports building targets with multiple configurations,
see the
- "<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-building-targets-with-multiple-configurations'>Building Targets with Multiple Configurations</ulink>"
+ "<ulink url='&YOCTO_DOCS_DEV_URL;#dev-building-images-for-multiple-targets-using-multiple-configurations'>Building Images for Multiple Targets Using Multiple Configurations</ulink>"
section in the Yocto Project Development Tasks Manual.
</para>
</glossdef>
@@ -1443,6 +1471,17 @@
set up during compilation so that they are correct for
use when installed into the sysroot and called by the
build processes of other recipes.
+ <note>
+ The <filename>BINCONFIG_GLOB</filename> variable
+ uses
+ <ulink url='http://tldp.org/LDP/abs/html/globbingref.html'>shell globbing</ulink>,
+ which is recognition and expansion of wildcards during
+ pattern matching.
+ Shell globbing is very similar to
+ <ulink url='https://docs.python.org/2/library/fnmatch.html#module-fnmatch'><filename>fnmatch</filename></ulink>
+ and
+ <ulink url='https://docs.python.org/2/library/glob.html'><filename>glob</filename></ulink>.
+ </note>
</para>
<para>
@@ -2366,6 +2405,14 @@
Defines wildcards to match when installing a list of
complementary packages for all the packages explicitly
(or implicitly) installed in an image.
+ <note>
+ The <filename>COMPLEMENTARY_GLOB</filename> variable
+ uses Unix filename pattern matching
+ (<ulink url='https://docs.python.org/2/library/fnmatch.html#module-fnmatch'><filename>fnmatch</filename></ulink>),
+ which is similar to the Unix style pathname pattern
+ expansion
+ (<ulink url='https://docs.python.org/2/library/glob.html'><filename>glob</filename></ulink>).
+ </note>
The resulting list of complementary packages is associated
with an item that can be added to
<link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>.
@@ -4586,7 +4633,12 @@
<glossdef>
<para role="glossdeffirst">
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
- Additional <filename>cmake</filename> options.
+ Additional
+ <ulink url='https://cmake.org/overview/'>CMake</ulink>
+ options.
+ See the
+ <link linkend='ref-classes-cmake'><filename>cmake</filename></link>
+ class for additional information.
</para>
</glossdef>
</glossentry>
@@ -4782,23 +4834,38 @@
<literallayout class='monospaced'>
FILES_${PN} += "${bindir}/mydir1 ${bindir}/mydir2/myfile"
</literallayout>
+ <note><title>Notes</title>
+ <itemizedlist>
+ <listitem><para>
+ When specifying files or paths, you can pattern
+ match using Python's
+ <ulink url='https://docs.python.org/2/library/glob.html'><filename>glob</filename></ulink>
+ syntax.
+ For details on the syntax, see the
+ documentation by following the previous link.
+ </para></listitem>
+ <listitem><para>
+ When specifying paths as part of the
+ <filename>FILES</filename> variable, it is
+ good practice to use appropriate path
+ variables.
+ For example, use <filename>${sysconfdir}</filename>
+ rather than <filename>/etc</filename>, or
+ <filename>${bindir}</filename> rather than
+ <filename>/usr/bin</filename>.
+ You can find a list of these variables at the
+ top of the
+ <filename>meta/conf/bitbake.conf</filename>
+ file in the
+ <link linkend='source-directory'>Source Directory</link>.
+ You will also find the default values of the
+ various <filename>FILES_*</filename> variables
+ in this file.
+ </para></listitem>
+ </itemizedlist>
+ </note>
</para>
- <note>
- When specifying paths as part of the
- <filename>FILES</filename> variable, it is good practice
- to use appropriate path variables.
- For example, use <filename>${sysconfdir}</filename> rather
- than <filename>/etc</filename>, or
- <filename>${bindir}</filename> rather than
- <filename>/usr/bin</filename>.
- You can find a list of these variables at the top of the
- <filename>meta/conf/bitbake.conf</filename> file in the
- <link linkend='source-directory'>Source Directory</link>.
- You will also find the default values of the various
- <filename>FILES_*</filename> variables in this file.
- </note>
-
<para>
If some of the files you provide with the
<filename>FILES</filename> variable are editable and you
@@ -5166,6 +5233,28 @@
</glossdef>
</glossentry>
+ <glossentry id='var-GCCVERSION'><glossterm>GCCVERSION</glossterm>
+ <info>
+ GCCVERSION[doc] = "Specifies the default version of the GNU C Compiler (GCC) to use."
+ </info>
+ <glossdef>
+ <para role="glossdeffirst">
+<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+ Specifies the default version of the GNU C Compiler (GCC)
+ used for compilation.
+ By default, <filename>GCCVERSION</filename> is set to
+ "8.x" in the
+ <filename>meta/conf/distro/include/tcmode-default.inc</filename>
+ include file:
+ <literallayout class='monospaced'>
+ GCCVERSION ?= "8.%"
+ </literallayout>
+ You can override this value by setting it in a configuration
+ file such as the <filename>local.conf</filename>.
+ </para>
+ </glossdef>
+ </glossentry>
+
<glossentry id='var-GDB'><glossterm>GDB</glossterm>
<info>
GDB[doc] = "The minimal command and arguments to run the GNU Debugger."
@@ -6940,6 +7029,61 @@
</glossdef>
</glossentry>
+ <glossentry id='var-INITRAMFS_LINK_NAME'><glossterm>INITRAMFS_LINK_NAME</glossterm>
+ <info>
+ INITRAMFS_LINK_NAME[doc] = "The link name of the initial RAM filesystem image."
+ </info>
+ <glossdef>
+ <para role="glossdeffirst">
+<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+ The link name of the initial RAM filesystem image.
+ This variable is set in the
+ <filename>meta/classes/kernel-artifact-names.bbclass</filename>
+ file as follows:
+ <literallayout class='monospaced'>
+ INITRAMFS_LINK_NAME ?= "initramfs-${KERNEL_ARTIFACT_LINK_NAME}"
+ </literallayout>
+ The value of the <filename>KERNEL_ARTIFACT_LINK_NAME</filename>
+ variable, which is set in the same file, has the following
+ value:
+ <literallayout class='monospaced'>
+ KERNEL_ARTIFACT_LINK_NAME ?= "${MACHINE}"
+ </literallayout>
+ </para>
+
+ <para>
+ See the
+ <link linkend='var-MACHINE'><filename>MACHINE</filename></link>
+ variable for additional information.
+ </para>
+ </glossdef>
+ </glossentry>
+
+ <glossentry id='var-INITRAMFS_NAME'><glossterm>INITRAMFS_NAME</glossterm>
+ <info>
+ INITRAMFS_NAME[doc] = "The base name of the initial RAM filesystem image."
+ </info>
+ <glossdef>
+ <para role="glossdeffirst">
+<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+ The base name of the initial RAM filesystem image.
+ This variable is set in the
+ <filename>meta/classes/kernel-artifact-names.bbclass</filename>
+ file as follows:
+ <literallayout class='monospaced'>
+ INITRAMFS_NAME ?= "initramfs-${KERNEL_ARTIFACT_NAME}"
+ </literallayout>
+ The value of the
+ <link linkend='var-KERNEL_ARTIFACT_NAME'><filename>KERNEL_ARTIFACT_NAME</filename></link>
+ variable, which is set in the same file, has the following
+ value:
+ <literallayout class='monospaced'>
+ KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
+ </literallayout>
+ </para>
+ </glossdef>
+ </glossentry>
+
<glossentry id='var-INITRD'><glossterm>INITRD</glossterm>
<info>
INITRD[doc] = "Indicates a list of filesystem images to concatenate and use as an initial RAM disk (initrd)."
@@ -7316,6 +7460,45 @@
</glossdef>
</glossentry>
+ <glossentry id='var-KERNEL_ARTIFACT_NAME'><glossterm>KERNEL_ARTIFACT_NAME</glossterm>
+ <info>
+ KERNEL_ARTIFACT_NAME[doc] = "Specifies the name of all of the build artifacts."
+ </info>
+ <glossdef>
+ <para role="glossdeffirst">
+<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+ Specifies the name of all of the build artifacts.
+ You can change the name of the artifacts by changing the
+ <filename>KERNEL_ARTIFACT_NAME</filename> variable.
+ </para>
+
+ <para>
+ The value of <filename>KERNEL_ARTIFACT_NAME</filename>,
+ which is set in the
+ <filename> meta/classes/kernel-artifact-names.bbclass</filename>
+ file, has the following default value:
+ <literallayout class='monospaced'>
+ KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
+ </literallayout>
+ </para>
+
+ <para>
+ See the
+ <link linkend='var-PKGE'><filename>PKGE</filename></link>,
+ <link linkend='var-PKGV'><filename>PKGV</filename></link>,
+ <link linkend='var-PKGR'><filename>PKGR</filename></link>,
+ and
+ <link linkend='var-MACHINE'><filename>MACHINE</filename></link>
+ variables for additional information.
+ <note>
+ The <filename>IMAGE_VERSION_SUFFIX</filename> variable
+ is set to
+ <link linkend='var-DATETIME'><filename>DATETIME</filename></link>.
+ </note>
+ </para>
+ </glossdef>
+ </glossentry>
+
<glossentry id='var-KERNEL_CLASSES'><glossterm>KERNEL_CLASSES</glossterm>
<info>
KERNEL_CLASSES[doc] = "A list of classes defining kernel image types that kernel class should inherit."
@@ -7365,6 +7548,61 @@
</glossdef>
</glossentry>
+ <glossentry id='var-KERNEL_DTB_LINK_NAME'><glossterm>KERNEL_DTB_LINK_NAME</glossterm>
+ <info>
+ KERNEL_DTB_LINK_NAME[doc] = "The link name of the kernel device tree binary (DTB)."
+ </info>
+ <glossdef>
+ <para role="glossdeffirst">
+<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+ The link name of the kernel device tree binary (DTB).
+ This variable is set in the
+ <filename>meta/classes/kernel-artifact-names.bbclass</filename>
+ file as follows:
+ <literallayout class='monospaced'>
+ KERNEL_DTB_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}"
+ </literallayout>
+ The value of the <filename>KERNEL_ARTIFACT_LINK_NAME</filename>
+ variable, which is set in the same file, has the following
+ value:
+ <literallayout class='monospaced'>
+ KERNEL_ARTIFACT_LINK_NAME ?= "${MACHINE}"
+ </literallayout>
+ </para>
+
+ <para>
+ See the
+ <link linkend='var-MACHINE'><filename>MACHINE</filename></link>
+ variable for additional information.
+ </para>
+ </glossdef>
+ </glossentry>
+
+ <glossentry id='var-KERNEL_DTB_NAME'><glossterm>KERNEL_DTB_NAME</glossterm>
+ <info>
+ KERNEL_DTB_NAME[doc] = "The base name of the kernel device tree binary (DTB)."
+ </info>
+ <glossdef>
+ <para role="glossdeffirst">
+<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+ The base name of the kernel device tree binary (DTB).
+ This variable is set in the
+ <filename>meta/classes/kernel-artifact-names.bbclass</filename>
+ file as follows:
+ <literallayout class='monospaced'>
+ KERNEL_DTB_NAME ?= "${KERNEL_ARTIFACT_NAME}"
+ </literallayout>
+ The value of the
+ <link linkend='var-KERNEL_ARTIFACT_NAME'><filename>KERNEL_ARTIFACT_NAME</filename></link>
+ variable, which is set in the same file, has the following
+ value:
+ <literallayout class='monospaced'>
+ KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
+ </literallayout>
+ </para>
+ </glossdef>
+ </glossentry>
+
<glossentry id='var-KERNEL_EXTRA_ARGS'><glossterm>KERNEL_EXTRA_ARGS</glossterm>
<info>
KERNEL_EXTRA_ARGS[doc] = "Specifies additional make command-line arguments the OpenEmbedded build system passes on when compiling the kernel."
@@ -7422,38 +7660,93 @@
<literallayout class='monospaced'>
KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc features/taskstats/taskstats.scc"
KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}"
- KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc"
- KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc"
- KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc"
- </literallayout></para>
+ KERNEL_FEATURES_append_qemuall = " cfg/virtio.scc"
+ KERNEL_FEATURES_append_qemux86 = " cfg/sound.scc cfg/paravirt_kvm.scc"
+ KERNEL_FEATURES_append_qemux86-64 = " cfg/sound.scc" </literallayout></para>
</glossdef>
</glossentry>
- <glossentry id='var-KERNEL_IMAGE_BASE_NAME'><glossterm>KERNEL_IMAGE_BASE_NAME</glossterm>
+ <glossentry id='var-KERNEL_FIT_LINK_NAME'><glossterm>KERNEL_FIT_LINK_NAME</glossterm>
<info>
- KERNEL_IMAGE_BASE_NAME[doc] = "The base name of the kernel image."
+ KERNEL_FIT_LINK_NAME[doc] = "The link name of the kernel flattened image tree (FIT) image."
</info>
<glossdef>
<para role="glossdeffirst">
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
- The base name of the kernel image.
+ The link name of the kernel flattened image tree (FIT) image.
This variable is set in the
- <link linkend='ref-classes-kernel'>kernel</link> class
- as follows:
+ <filename>meta/classes/kernel-artifact-names.bbclass</filename>
+ file as follows:
<literallayout class='monospaced'>
- KERNEL_IMAGE_BASE_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}"
+ KERNEL_FIT_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}"
+ </literallayout>
+ The value of the <filename>KERNEL_ARTIFACT_LINK_NAME</filename>
+ variable, which is set in the same file, has the following
+ value:
+ <literallayout class='monospaced'>
+ KERNEL_ARTIFACT_LINK_NAME ?= "${MACHINE}"
</literallayout>
</para>
<para>
See the
- <link linkend='var-PKGE'><filename>PKGE</filename></link>,
- <link linkend='var-PKGV'><filename>PKGV</filename></link>,
- <link linkend='var-PKGR'><filename>PKGR</filename></link>,
- <link linkend='var-MACHINE'><filename>MACHINE</filename></link>,
- and
- <link linkend='var-DATETIME'><filename>DATETIME</filename></link>
- variables for additional information.
+ <link linkend='var-MACHINE'><filename>MACHINE</filename></link>
+ variable for additional information.
+ </para>
+ </glossdef>
+ </glossentry>
+
+ <glossentry id='var-KERNEL_FIT_NAME'><glossterm>KERNEL_FIT_NAME</glossterm>
+ <info>
+ KERNEL_FIT_NAME[doc] = "The base name of the kernel flattened image tree (FIT) image."
+ </info>
+ <glossdef>
+ <para role="glossdeffirst">
+<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+ The base name of the kernel flattened image tree (FIT) image.
+ This variable is set in the
+ <filename>meta/classes/kernel-artifact-names.bbclass</filename>
+ file as follows:
+ <literallayout class='monospaced'>
+ KERNEL_FIT_NAME ?= "${KERNEL_ARTIFACT_NAME}"
+ </literallayout>
+ The value of the
+ <link linkend='var-KERNEL_ARTIFACT_NAME'><filename>KERNEL_ARTIFACT_NAME</filename></link>
+ variable, which is set in the same file, has the following
+ value:
+ <literallayout class='monospaced'>
+ KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
+ </literallayout>
+ </para>
+ </glossdef>
+ </glossentry>
+
+ <glossentry id='var-KERNEL_IMAGE_LINK_NAME'><glossterm>KERNEL_IMAGE_LINK_NAME</glossterm>
+ <info>
+ KERNEL_IMAGE_LINK_NAME[doc] = "The link name for the kernel image."
+ </info>
+ <glossdef>
+ <para role="glossdeffirst">
+<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+ The link name for the kernel image.
+ This variable is set in the
+ <filename>meta/classes/kernel-artifact-names.bbclass</filename>
+ file as follows:
+ <literallayout class='monospaced'>
+ KERNEL_IMAGE_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}"
+ </literallayout>
+ The value of the <filename>KERNEL_ARTIFACT_LINK_NAME</filename>
+ variable, which is set in the same file, has the following
+ value:
+ <literallayout class='monospaced'>
+ KERNEL_ARTIFACT_LINK_NAME ?= "${MACHINE}"
+ </literallayout>
+ </para>
+
+ <para>
+ See the
+ <link linkend='var-MACHINE'><filename>MACHINE</filename></link>
+ variable for additional information.
</para>
</glossdef>
</glossentry>
@@ -7489,6 +7782,31 @@
</glossdef>
</glossentry>
+ <glossentry id='var-KERNEL_IMAGE_NAME'><glossterm>KERNEL_IMAGE_NAME</glossterm>
+ <info>
+ KERNEL_IMAGE_NAME[doc] = "The base name of the kernel image."
+ </info>
+ <glossdef>
+ <para role="glossdeffirst">
+<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+ The base name of the kernel image.
+ This variable is set in the
+ <filename>meta/classes/kernel-artifact-names.bbclass</filename>
+ file as follows:
+ <literallayout class='monospaced'>
+ KERNEL_IMAGE_NAME ?= "${KERNEL_ARTIFACT_NAME}"
+ </literallayout>
+ The value of the
+ <link linkend='var-KERNEL_ARTIFACT_NAME'><filename>KERNEL_ARTIFACT_NAME</filename></link>
+ variable, which is set in the same file, has the following
+ value:
+ <literallayout class='monospaced'>
+ KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
+ </literallayout>
+ </para>
+ </glossdef>
+ </glossentry>
+
<glossentry id='var-KERNEL_IMAGETYPE'><glossterm>KERNEL_IMAGETYPE</glossterm>
<info>
KERNEL_IMAGETYPE[doc] = "The type of kernel to build for a device, usually set by the machine configuration files and defaults to 'zImage'."
@@ -8902,35 +9220,6 @@
</glossdef>
</glossentry>
- <glossentry id='var-MODULE_IMAGE_BASE_NAME'><glossterm>MODULE_IMAGE_BASE_NAME</glossterm>
- <info>
- MODULE_IMAGE_BASE_NAME[doc] = "The base name of the kernel modules tarball."
- </info>
- <glossdef>
- <para role="glossdeffirst">
-<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
- The base name of the kernel modules tarball.
- This variable is set in the
- <link linkend='ref-classes-kernel'>kernel</link> class
- as follows:
- <literallayout class='monospaced'>
- MODULE_IMAGE_BASE_NAME ?= "modules-${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}"
- </literallayout>
- </para>
-
- <para>
- See the
- <link linkend='var-PKGE'><filename>PKGE</filename></link>,
- <link linkend='var-PKGV'><filename>PKGV</filename></link>,
- <link linkend='var-PKGR'><filename>PKGR</filename></link>,
- <link linkend='var-MACHINE'><filename>MACHINE</filename></link>,
- and
- <link linkend='var-DATETIME'><filename>DATETIME</filename></link>
- variables for additional information.
- </para>
- </glossdef>
- </glossentry>
-
<glossentry id='var-MODULE_TARBALL_DEPLOY'><glossterm>MODULE_TARBALL_DEPLOY</glossterm>
<info>
MODULE_TARBALL_DEPLOY[doc] = "Controls creation of the modules-*.tgz file. Set this variable to "0" to disable creation of this file, which contains all of the kernel modules resulting from a kernel build."
@@ -8947,6 +9236,61 @@
</glossdef>
</glossentry>
+ <glossentry id='var-MODULE_TARBALL_LINK_NAME'><glossterm>MODULE_TARBALL_LINK_NAME</glossterm>
+ <info>
+ MODULE_TARBALL_LINK_NAME[doc] = "The link name of the kernel module tarball."
+ </info>
+ <glossdef>
+ <para role="glossdeffirst">
+<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+ The link name of the kernel module tarball.
+ This variable is set in the
+ <filename>meta/classes/kernel-artifact-names.bbclass</filename>
+ file as follows:
+ <literallayout class='monospaced'>
+ MODULE_TARBALL_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}"
+ </literallayout>
+ The value of the <filename>KERNEL_ARTIFACT_LINK_NAME</filename>
+ variable, which is set in the same file, has the following
+ value:
+ <literallayout class='monospaced'>
+ KERNEL_ARTIFACT_LINK_NAME ?= "${MACHINE}"
+ </literallayout>
+ </para>
+
+ <para>
+ See the
+ <link linkend='var-MACHINE'><filename>MACHINE</filename></link>
+ variable for additional information.
+ </para>
+ </glossdef>
+ </glossentry>
+
+ <glossentry id='var-MODULE_TARBALL_NAME'><glossterm>MODULE_TARBALL_NAME</glossterm>
+ <info>
+ MODULE_TARBALL_NAME[doc] = "The base name of the kernel module tarball."
+ </info>
+ <glossdef>
+ <para role="glossdeffirst">
+<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+ The base name of the kernel module tarball.
+ This variable is set in the
+ <filename>meta/classes/kernel-artifact-names.bbclass</filename>
+ file as follows:
+ <literallayout class='monospaced'>
+ MODULE_TARBALL_NAME ?= "${KERNEL_ARTIFACT_NAME}"
+ </literallayout>
+ The value of the
+ <link linkend='var-KERNEL_ARTIFACT_NAME'><filename>KERNEL_ARTIFACT_NAME</filename></link>
+ variable, which is set in the same file, has the following
+ value:
+ <literallayout class='monospaced'>
+ KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
+ </literallayout>
+ </para>
+ </glossdef>
+ </glossentry>
+
<!--
<glossentry id='var-MULTIMACH_HOST_SYS'><glossterm>MULTIMACH_HOST_SYS</glossterm>
<info>
@@ -9058,6 +9402,40 @@
</glossdef>
</glossentry>
+ <glossentry id='var-NO_GENERIC_LICENSE'><glossterm>NO_GENERIC_LICENSE</glossterm>
+ <info>
+ NO_GENERIC_LICENSE[doc] = "Used to allow copying a license that does not exist in common licenses."
+ </info>
+ <glossdef>
+ <para role="glossdeffirst">
+<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+ Avoids QA errors when you use a non-common, non-CLOSED
+ license in a recipe.
+ Packages exist, such as the linux-firmware package, with
+ many licenses that are not in any way common.
+ Also, new licenses are added occasionally to avoid
+ introducing a lot of common license files, which are only
+ applicable to a specific package.
+ <filename>NO_GENERIC_LICENSE</filename> is used to allow
+ copying a license that does not exist in common licenses.
+ </para>
+
+ <para>
+ The following example shows how to add
+ <filename>NO_GENERIC_LICENSE</filename> to a recipe:
+ <literallayout class='monospaced'>
+ NO_GENERIC_LICENSE[<replaceable>license_name</replaceable>] = "<replaceable>license_file_in_fetched_source</replaceable>"
+ </literallayout>
+ The following is an example that uses the
+ <filename>LICENSE.Abilis.txt</filename> file as the license
+ from the fetched source:
+ <literallayout class='monospaced'>
+ NO_GENERIC_LICENSE[Firmware-Abilis] = "LICENSE.Abilis.txt"
+ </literallayout>
+ </para>
+ </glossdef>
+ </glossentry>
+
<glossentry id='var-NO_RECOMMENDATIONS'><glossterm>NO_RECOMMENDATIONS</glossterm>
<info>
NO_RECOMMENDATIONS[doc] = "When set to '1', no recommended packages will be installed. Some recommended packages might be required for certain system functionality, such as kernel-modules. It is up to the user to add packages to IMAGE_INSTALL as needed."
@@ -9141,44 +9519,6 @@
</para>
</glossdef>
</glossentry>
-
- <glossentry id='var-NOHDD'><glossterm>NOHDD</glossterm>
- <info>
- NOHDD[doc] = "Causes the OpenEmbedded build system to skip building the .hddimg image."
- </info>
- <glossdef>
- <para role="glossdeffirst">
-<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
- Causes the OpenEmbedded build system to skip building the
- <filename>.hddimg</filename> image.
- The <filename>NOHDD</filename> variable is used with the
- <link linkend='ref-classes-image-live'><filename>image-live</filename></link>
- class.
- Set the variable to "1" to prevent the
- <filename>.hddimg</filename> image from being built.
- </para>
- </glossdef>
- </glossentry>
-
- <glossentry id='var-NOISO'><glossterm>NOISO</glossterm>
- <info>
- NOISO[doc] = "Causes the OpenEmbedded build system to skip building the ISO image."
- </info>
- <glossdef>
- <para role="glossdeffirst">
-<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
- Causes the OpenEmbedded build system to skip building the
- ISO image.
- The <filename>NOISO</filename> variable is used with the
- <link linkend='ref-classes-image-live'><filename>image-live</filename></link>
- class.
- Set the variable to "1" to prevent the ISO image from
- being built.
- To enable building an ISO image, set the variable to "0".
- </para>
- </glossdef>
- </glossentry>
-
</glossdiv>
<glossdiv id='var-glossary-o'><title>O</title>
@@ -9612,6 +9952,12 @@
".debug" previously described with the exception
that no source files are installed.
</para></listitem>.
+ <listitem><para>
+ "debug-with-srcpkg": The same behavior as
+ ".debug" previously described with the exception
+ that all source files are placed in a separate
+ <filename>*-src</filename> pkg.
+ </para></listitem>
</itemizedlist>
</para>
@@ -9991,9 +10337,9 @@
Here is the basic block structure:
<literallayout class='monospaced'>
PACKAGECONFIG ??= "f1 f2 f3 ..."
- PACKAGECONFIG[f1] = "--with-f1,--without-f1,build-deps-f1,rt-deps-f1"
- PACKAGECONFIG[f2] = "--with-f2,--without-f2,build-deps-f2,rt-deps-f2"
- PACKAGECONFIG[f3] = "--with-f3,--without-f3,build-deps-f3,rt-deps-f3"
+ PACKAGECONFIG[f1] = "--with-f1,--without-f1,build-deps-f1,rt-deps-f1,rt-recs-f1"
+ PACKAGECONFIG[f2] = "--with-f2,--without-f2,build-deps-f2,rt-deps-f2,rt-recs-f2"
+ PACKAGECONFIG[f3] = "--with-f3,--without-f3,build-deps-f3,rt-deps-f3,rt-recs-f3"
</literallayout>
</para>
@@ -10002,7 +10348,7 @@
variable itself specifies a space-separated list of the
features to enable.
Following the features, you can determine the behavior of
- each feature by providing up to four order-dependent
+ each feature by providing up to five order-dependent
arguments, which are separated by commas.
You can omit any argument you like but must retain the
separating commas.
@@ -10028,6 +10374,10 @@
(<link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>)
that should be added if the feature is enabled.
</para></listitem>
+ <listitem><para>Additional runtime recommendations
+ (<link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>)
+ that should be added if the feature is enabled.
+ </para></listitem>
</orderedlist>
</para>
@@ -10076,7 +10426,7 @@
<filename>PACKAGECONFIG</filename>.
You can either completely override the variable:
<literallayout class='monospaced'>
- PACKAGECONFIG="f4 f5"
+ PACKAGECONFIG = "f4 f5"
</literallayout>
Or, you can just append the variable:
<literallayout class='monospaced'>
@@ -10090,7 +10440,7 @@
As with append files previously described,
you can either completely override the variable:
<literallayout class='monospaced'>
- PACKAGECONFIG_pn-<replaceable>recipename</replaceable>="f4 f5"
+ PACKAGECONFIG_pn-<replaceable>recipename</replaceable> = "f4 f5"
</literallayout>
Or, you can just amend the variable:
<literallayout class='monospaced'>
@@ -10708,17 +11058,16 @@
to build.
This variable works in conjunction with the
<link linkend='ref-classes-blacklist'><filename>blacklist</filename></link>
- class, which the recipe must inherit globally.
+ class, which is inherited globally.
</para>
<para>
- To prevent a recipe from being built, inherit the class
- globally and use the variable in your
+ To prevent a recipe from being built, use the
+ <filename>PNBLACKLIST</filename> variable in your
<filename>local.conf</filename> file.
Here is an example that prevents
<filename>myrecipe</filename> from being built:
<literallayout class='monospaced'>
- INHERIT += "blacklist"
PNBLACKLIST[myrecipe] = "Not supported by our organization."
</literallayout>
</para>
@@ -10896,47 +11245,63 @@
<glossdef>
<para role="glossdeffirst">
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
- If there are multiple versions of recipes available, this
- variable determines which recipe should be given preference.
+ If multiple versions of recipes exist, this
+ variable determines which version is given preference.
You must always suffix the variable with the
<link linkend='var-PN'><filename>PN</filename></link>
you want to select, and you should set the
<link linkend='var-PV'><filename>PV</filename></link>
accordingly for precedence.
- You can use the "<filename>%</filename>" character as a
- wildcard to match any number of characters, which can be
- useful when specifying versions that contain long revision
- numbers that could potentially change.
+ </para>
+
+ <para>
+ The <filename>PREFERRED_VERSION</filename> variable
+ supports limited wildcard use through the
+ "<filename>%</filename>" 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:
<literallayout class='monospaced'>
PREFERRED_VERSION_python = "3.4.0"
PREFERRED_VERSION_linux-yocto = "4.12%"
</literallayout>
- <note>
- The specified version is matched against
- <link linkend='var-PV'><filename>PV</filename></link>,
- which does not necessarily match the version part of
- the recipe's filename.
- For example, consider two recipes
- <filename>foo_1.2.bb</filename> and
- <filename>foo_git.bb</filename> where
- <filename>foo_git.bb</filename> contains the following
- assignment:
- <literallayout class='monospaced'>
- PV = "1.1+git${SRCPV}"
- </literallayout>
- In this case, the correct way to select
- <filename>foo_git.bb</filename> is by using an
- assignment such as the following:
- <literallayout class='monospaced'>
- PREFERRED_VERSION_foo = "1.1+git%"
- </literallayout>
- Compare that previous example against the following
- incorrect example, which does not work:
- <literallayout class='monospaced'>
- PREFERRED_VERSION_foo = "git"
- </literallayout>
+ <note><title>Important</title>
+ The use of the "<filename>%</filename>" character
+ is limited in that it only works at the end of the
+ string.
+ You cannot use the wildcard character in any other
+ location of the string.
</note>
+ </para>
+
+ <para>
+ The specified version is matched against
+ <link linkend='var-PV'><filename>PV</filename></link>,
+ which does not necessarily match the version part of
+ the recipe's filename.
+ For example, consider two recipes
+ <filename>foo_1.2.bb</filename> and
+ <filename>foo_git.bb</filename> where
+ <filename>foo_git.bb</filename> contains the following
+ assignment:
+ <literallayout class='monospaced'>
+ PV = "1.1+git${SRCPV}"
+ </literallayout>
+ In this case, the correct way to select
+ <filename>foo_git.bb</filename> is by using an
+ assignment such as the following:
+ <literallayout class='monospaced'>
+ PREFERRED_VERSION_foo = "1.1+git%"
+ </literallayout>
+ Compare that previous example against the following
+ incorrect example, which does not work:
+ <literallayout class='monospaced'>
+ PREFERRED_VERSION_foo = "git"
+ </literallayout>
+ </para>
+
+ <para>
Sometimes the <filename>PREFERRED_VERSION</filename>
variable can be set by configuration files in a way that
is hard to change.
@@ -12566,22 +12931,33 @@
<glossentry id='var-SDK_TITLE'><glossterm>SDK_TITLE</glossterm>
<info>
- SDK_TITLE[doc] = "Specifies a title to be printed when running the SDK installer."
+ SDK_TITLE[doc] = "The title to be printed when running the SDK installer."
</info>
<glossdef>
<para role="glossdeffirst">
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
- Specifies a title to be printed when running the SDK
- installer.
- The <filename>SDK_TITLE</filename> variable defaults to
- "<replaceable>distro</replaceable> SDK" for the standard
- SDK and "<replaceable>distro</replaceable> Extensible SDK"
- for the extensible SDK, where
- <replaceable>distro</replaceable> is the first one of
+ The title to be printed when running the SDK installer.
+ By default, this title is based on the
<link linkend='var-DISTRO_NAME'><filename>DISTRO_NAME</filename></link>
or
<link linkend='var-DISTRO'><filename>DISTRO</filename></link>
- that is set in your configuration.
+ variable and is set in the
+ <link linkend='ref-classes-populate-sdk-*'><filename>populate_sdk_base</filename></link>
+ class as follows:
+ <literallayout class='monospaced'>
+ SDK_TITLE ??= "${@d.getVar('DISTRO_NAME') or d.getVar('DISTRO')} SDK"
+ </literallayout>
+ For the default distribution "poky",
+ <filename>SDK_TITLE</filename> is set to
+ "Poky (Yocto Project Reference Distro)".
+ </para>
+
+ <para>
+ For information on how to change this default title,
+ see the
+ "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-changing-the-sdk-installer-title'>Changing the Extensible SDK Installer Title</ulink>"
+ section in the Yocto Project Application Development and
+ the Extensible Software Development Kit (eSDK) manual.
</para>
</glossdef>
</glossentry>
@@ -12640,6 +13016,36 @@
</glossdef>
</glossentry>
+ <glossentry id='var-SDKEXTPATH'><glossterm>SDKEXTPATH</glossterm>
+ <info>
+ SDKEXTPATH[doc] = "The default installation directory for the extensible SDK."
+ </info>
+ <glossdef>
+ <para role="glossdeffirst">
+<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+ The default installation directory for the Extensible SDK.
+ By default, this directory is based on the
+ <link linkend='var-DISTRO'><filename>DISTRO</filename></link>
+ variable and is set in the
+ <link linkend='ref-classes-populate-sdk-*'><filename>populate_sdk_base</filename></link>
+ class as follows:
+ <literallayout class='monospaced'>
+ SDKEXTPATH ??= "~/${@d.getVar('DISTRO')}_sdk"
+ </literallayout>
+ For the default distribution "poky", the
+ <filename>SDKEXTPATH</filename> is set to "poky_sdk".
+ </para>
+
+ <para>
+ For information on how to change this default directory,
+ see the
+ "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-changing-the-default-sdk-installation-directory'>Changing the Default SDK Installation Directory</ulink>"
+ section in the Yocto Project Application Development and
+ the Extensible Software Development Kit (eSDK) manual.
+ </para>
+ </glossdef>
+ </glossentry>
+
<glossentry id='var-SDKIMAGE_FEATURES'><glossterm>SDKIMAGE_FEATURES</glossterm>
<info>
SDKIMAGE_FEATURES[doc] = "Equivalent to IMAGE_FEATURES. However, this variable applies to the SDK generated from an image using the command 'bitbake -c populate_sdk imagename'."
@@ -13506,7 +13912,7 @@
<link linkend='var-MIRRORS'><filename>MIRRORS</filename></link>
and <link linkend='var-PREMIRRORS'><filename>PREMIRRORS</filename></link>
and points to the cache locations to check for the shared
- objects.
+ state (sstate) objects.
</para>
<para>
@@ -13519,6 +13925,25 @@
</para>
<para>
+ When pointing to sstate build artifacts on another machine
+ that uses a different GCC version for native builds,
+ you must configure <filename>SSTATE_MIRROR</filename>
+ with a regular expression that maps local search paths
+ to server paths.
+ The paths need to take into account
+ <link linkend='var-NATIVELSBSTRING'><filename>NATIVELSBSTRING</filename></link>
+ set by the
+ <link linkend='ref-classes-uninative'><filename>uninative</filename></link>
+ class.
+ For example, the following maps the local search path
+ <filename>universal-4.9</filename> to the server-provided
+ path <replaceable>server_url_sstate_path</replaceable>:
+ <literallayout class='monospaced'>
+ SSTATE_MIRRORS ?= file://universal-4.9/(.*) http://<replaceable>server_url_sstate_path</replaceable>/universal-4.8/\1 \n
+ </literallayout>
+ </para>
+
+ <para>
If a mirror uses the same structure as
<link linkend='var-SSTATE_DIR'><filename>SSTATE_DIR</filename></link>,
you need to add
@@ -14860,6 +15285,26 @@
</glossdef>
</glossentry>
+ <glossentry id='var-TCLIBC'><glossterm>TCLIBC</glossterm>
+ <info>
+ TCLIBC[doc] = "Specifies GNU standard C library (libc) variant to use during the build process. You can select 'glibc', 'musl' or "newlib."
+ </info>
+ <glossdef>
+ <para role="glossdeffirst">
+<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+ Specifies the GNU standard C library
+ (<filename>libc</filename>) variant to use during the
+ build process.
+ This variable replaces <filename>POKYLIBC</filename>,
+ which is no longer supported.
+ </para>
+
+ <para>
+ You can select "glibc", "musl", "newlib", or "baremetal"
+ </para>
+ </glossdef>
+ </glossentry>
+
<glossentry id='var-TCLIBCAPPEND'><glossterm>TCLIBCAPPEND</glossterm>
<info>
TCLIBCAPPEND[doc] = "Specifies a suffix appended to TMPDIR that identifies the libc variant for the build."
@@ -14891,25 +15336,6 @@
</glossdef>
</glossentry>
- <glossentry id='var-TCLIBC'><glossterm>TCLIBC</glossterm>
- <info>
- TCLIBC[doc] = "Specifies GNU standard C library (libc) variant to use during the build process. You can select 'glibc' or 'musl'."
- </info>
- <glossdef>
- <para role="glossdeffirst">
-<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
- Specifies the GNU standard C library (<filename>libc</filename>)
- variant to use during the build process.
- This variable replaces <filename>POKYLIBC</filename>, which is no longer
- supported.
- </para>
-
- <para>
- You can select "glibc" or "musl".
- </para>
- </glossdef>
- </glossentry>
-
<glossentry id='var-TCMODE'><glossterm>TCMODE</glossterm>
<info>
TCMODE[doc] = "Enables an external toolchain (where provided by an additional layer) if set to a value other than 'default'."
@@ -15017,41 +15443,6 @@
</glossdef>
</glossentry>
- <glossentry id='var-TEST_IMAGE'><glossterm>TEST_IMAGE</glossterm>
- <info>
- TEST_IMAGE[doc] = "Enables test booting of virtual machine images under the QEMU emulator after any root filesystems are created and runs tests against those images."
- </info>
- <glossdef>
- <para role="glossdeffirst">
-<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
- Automatically runs the series of automated tests for
- images when an image is successfully built.
- </para>
-
- <para>
- These tests are written in Python making use of the
- <filename>unittest</filename> module, and the majority of
- them run commands on the target system over
- <filename>ssh</filename>.
- You can set this variable to "1" in your
- <filename>local.conf</filename> file in the
- <link linkend='build-directory'>Build Directory</link>
- to have the OpenEmbedded build system automatically run
- these tests after an image successfully builds:
- <literallayout class='monospaced'>
- TEST_IMAGE = "1"
- </literallayout>
- For more information on enabling, running, and writing
- these tests, see the
- "<ulink url='&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing'>Performing Automated Runtime Testing</ulink>"
- section in the Yocto Project Development Tasks Manual and
- the
- "<link linkend='ref-classes-testimage*'><filename>testimage*.bbclass</filename></link>"
- section.
- </para>
- </glossdef>
- </glossentry>
-
<glossentry id='var-TEST_LOG_DIR'><glossterm>TEST_LOG_DIR</glossterm>
<info>
TEST_LOG_DIR[doc] = "Holds the SSH log and the boot log for QEMU machines. The TEST_LOG_DIR variable defaults to "${WORKDIR}/testimage"."
@@ -15211,9 +15602,9 @@
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
Specifies the target controller to use when running tests
against a test image.
- The default controller to use is "qemu":
+ The default controller to use is "QemuTarget":
<literallayout class='monospaced'>
- TEST_TARGET = "qemu"
+ TEST_TARGET = "QemuTarget"
</literallayout>
</para>
@@ -15232,35 +15623,24 @@
You can provide the following arguments with
<filename>TEST_TARGET</filename>:
<itemizedlist>
- <listitem><para><emphasis>"qemu" and "QemuTarget":</emphasis>
+ <listitem><para><emphasis>"QemuTarget":</emphasis>
Boots a QEMU image and runs the tests.
See the
"<ulink url='&YOCTO_DOCS_DEV_URL;#qemu-image-enabling-tests'>Enabling Runtime Tests on QEMU</ulink>"
section in the Yocto Project Development Tasks
Manual for more information.
</para></listitem>
- <listitem><para><emphasis>"simpleremote" and "SimpleRemoteTarget":</emphasis>
+ <listitem><para><emphasis>"SimpleRemoteTarget":</emphasis>
Runs the tests on target hardware that is already
up and running.
The hardware can be on the network or it can be
a device running an image on QEMU.
You must also set
<link linkend='var-TEST_TARGET_IP'><filename>TEST_TARGET_IP</filename></link>
- when you use "simpleremote" or "SimpleRemoteTarget".
+ when you use "SimpleRemoteTarget".
<note>
This argument is defined in
- <filename>meta/lib/oeqa/targetcontrol.py</filename>.
- The small caps names are kept for compatibility
- reasons.
- </note>
- </para></listitem>
- <listitem><para><emphasis>"GummibootTarget":</emphasis>
- Automatically deploys and runs tests on an
- EFI-enabled machine that has a master image
- installed.
- <note>
- This argument is defined in
- <filename>meta/lib/oeqa/controllers/masterimage.py</filename>.
+ <filename>meta/lib/oeqa/controllers/simpleremote.py</filename>.
</note>
</para></listitem>
</itemizedlist>
@@ -15363,6 +15743,47 @@
</glossdef>
</glossentry>
+ <glossentry id='var-TESTIMAGE_AUTO'><glossterm>TESTIMAGE_AUTO</glossterm>
+ <info>
+ TESTIMAGE_AUTO[doc] = "Enables automatic testing of an image once it is built."
+ </info>
+ <glossdef>
+ <para role="glossdeffirst">
+<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+ Automatically runs the series of automated tests for
+ images when an image is successfully built.
+ Setting <filename>TESTIMAGE_AUTO</filename> to "1"
+ causes any image that successfully builds to automatically
+ boot under QEMU.
+ Using the variable also adds in dependencies so that any
+ SDK for which testing is requested is automatically built
+ first.
+ </para>
+
+ <para>
+ These tests are written in Python making use of the
+ <filename>unittest</filename> module, and the majority of
+ them run commands on the target system over
+ <filename>ssh</filename>.
+ You can set this variable to "1" in your
+ <filename>local.conf</filename> file in the
+ <link linkend='build-directory'>Build Directory</link>
+ to have the OpenEmbedded build system automatically run
+ these tests after an image successfully builds:
+ <literallayout class='monospaced'>
+ TESTIMAGE_AUTO = "1"
+ </literallayout>
+ For more information on enabling, running, and writing
+ these tests, see the
+ "<ulink url='&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing'>Performing Automated Runtime Testing</ulink>"
+ section in the Yocto Project Development Tasks Manual and
+ the
+ "<link linkend='ref-classes-testimage*'><filename>testimage*.bbclass</filename></link>"
+ section.
+ </para>
+ </glossdef>
+ </glossentry>
+
<glossentry id='var-THISDIR'><glossterm>THISDIR</glossterm>
<info>
THISDIR[doc] = "The directory in which the file BitBake is currently parsing is located."