meta-openembedded and poky: subtree updates
Squash of the following due to dependencies among them
and OpenBMC changes:
meta-openembedded: subtree update:d0748372d2..9201611135
meta-openembedded: subtree update:9201611135..17fd382f34
poky: subtree update:9052e5b32a..2e11d97b6c
poky: subtree update:2e11d97b6c..a8544811d7
The change log was too large for the jenkins plugin
to handle therefore it has been removed. Here is
the first and last commit of each subtree:
meta-openembedded:d0748372d2
cppzmq: bump to version 4.6.0
meta-openembedded:17fd382f34
mpv: Remove X11 dependency
poky:9052e5b32a
package_ipk: Remove pointless comment to trigger rebuild
poky:a8544811d7
pbzip2: Fix license warning
Change-Id: If0fc6c37629642ee207a4ca2f7aa501a2c673cd6
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
diff --git a/poky/documentation/dev-manual/dev-manual-common-tasks.xml b/poky/documentation/dev-manual/dev-manual-common-tasks.xml
index 00741ee..e9ce182 100644
--- a/poky/documentation/dev-manual/dev-manual-common-tasks.xml
+++ b/poky/documentation/dev-manual/dev-manual-common-tasks.xml
@@ -184,6 +184,10 @@
variable.
</para></listitem>
<listitem><para>
+ <ulink url='&YOCTO_DOCS_REF_URL;#var-LAYERDEPENDS'><filename>LAYERDEPENDS</filename></ulink>:
+ Lists all layers on which this layer depends (if any).
+ </para></listitem>
+ <listitem><para>
<ulink url='&YOCTO_DOCS_REF_URL;#var-LAYERSERIES_COMPAT'><filename>LAYERSERIES_COMPAT</filename></ulink>:
Lists the
<ulink url='&YOCTO_WIKI_URL;/wiki/Releases'>Yocto Project</ulink>
@@ -315,12 +319,26 @@
DEPENDS_append_one = " foo"
DEPENDS_prepend_one = "foo "
</literallayout>
- As an actual example, here's a line from the recipe
- for gnutls, which adds dependencies on
- "argp-standalone" when building with the musl C
- library:
+ As an actual example, here's a snippet from the
+ generic kernel include file
+ <filename>linux-yocto.inc</filename>,
+ wherein the kernel compile and link options are
+ adjusted in the case of a subset of the supported
+ architectures:
<literallayout class='monospaced'>
- DEPENDS_append_libc-musl = " argp-standalone"
+ DEPENDS_append_aarch64 = " libgcc"
+ KERNEL_CC_append_aarch64 = " ${TOOLCHAIN_OPTIONS}"
+ KERNEL_LD_append_aarch64 = " ${TOOLCHAIN_OPTIONS}"
+
+ DEPENDS_append_nios2 = " libgcc"
+ KERNEL_CC_append_nios2 = " ${TOOLCHAIN_OPTIONS}"
+ KERNEL_LD_append_nios2 = " ${TOOLCHAIN_OPTIONS}"
+
+ DEPENDS_append_arc = " libgcc"
+ KERNEL_CC_append_arc = " ${TOOLCHAIN_OPTIONS}"
+ KERNEL_LD_append_arc = " ${TOOLCHAIN_OPTIONS}"
+
+ KERNEL_FEATURES_append_qemuall=" features/debug/printk.scc"
</literallayout>
<note>
Avoiding "+=" and "=+" and using
@@ -580,11 +598,19 @@
<filename>bitbake -e</filename>).
</para></listitem>
<listitem><para>
+ <filename>common.test_world</filename>:
+ Verifies that <filename>bitbake world</filename> works.
+ </para></listitem>
+ <listitem><para>
<filename>common.test_signatures</filename>:
Tests to be sure that BSP and DISTRO layers do not
come with recipes that change signatures.
</para></listitem>
<listitem><para>
+ <filename>common.test_layerseries_compat</filename>:
+ Verifies layer compatibility is set properly.
+ </para></listitem>
+ <listitem><para>
<filename>bsp.test_bsp_defines_machines</filename>:
Tests if a BSP layer has machine configurations.
</para></listitem>
@@ -594,11 +620,22 @@
machine when the layer is added.
</para></listitem>
<listitem><para>
+ <filename>bsp.test_machine_world</filename>:
+ Verifies that <filename>bitbake world</filename>
+ works regardless of which machine is selected.
+ </para></listitem>
+ <listitem><para>
+ <filename>bsp.test_machine_signatures</filename>:
+ Verifies that building for a particular machine
+ affects only the signature of tasks specific to that
+ machine.
+ </para></listitem>
+ <listitem><para>
<filename>distro.test_distro_defines_distros</filename>:
Tests if a DISTRO layer has distro configurations.
</para></listitem>
<listitem><para>
- <filename>distro.test_distro_no_set_distro</filename>:
+ <filename>distro.test_distro_no_set_distros</filename>:
Tests to ensure a DISTRO layer does not set the
distribution when the layer is added.
</para></listitem>
@@ -1397,7 +1434,7 @@
package specified in the <filename>PACKAGES</filename>
statement.
<note>
- The <filename>inherit packages</filename> should be
+ The <filename>inherit packagegroup</filename> line should be
located near the top of the recipe, certainly before
the <filename>PACKAGES</filename> statement.
</note>
@@ -1417,28 +1454,32 @@
<para>
Here is a short, fabricated example showing the same basic
- pieces:
+ pieces for a hypothetical packagegroup defined in
+ <filename>packagegroup-custom.bb</filename>, where the
+ variable <filename>PN</filename> is the standard way to
+ abbreviate the reference to the full packagegroup name
+ <filename>packagegroup-custom</filename>:
<literallayout class='monospaced'>
DESCRIPTION = "My Custom Package Groups"
inherit packagegroup
PACKAGES = "\
- packagegroup-custom-apps \
- packagegroup-custom-tools \
+ ${PN}-apps \
+ ${PN}-tools \
"
- RDEPENDS_packagegroup-custom-apps = "\
+ RDEPENDS_${PN}-apps = "\
dropbear \
portmap \
psplash"
- RDEPENDS_packagegroup-custom-tools = "\
+ RDEPENDS_${PN}-tools = "\
oprofile \
oprofileui-server \
lttng-tools"
- RRECOMMENDS_packagegroup-custom-tools = "\
+ RRECOMMENDS_${PN}-tools = "\
kernel-module-oprofile"
</literallayout>
</para>
@@ -1900,9 +1941,9 @@
<para>
The <filename>SRC_URI</filename> variable in your recipe must
define each unique location for your source files.
- It is good practice to not hard-code pathnames in an URL used
+ It is good practice to not hard-code version numbers in a URL used
in <filename>SRC_URI</filename>.
- Rather than hard-code these paths, use
+ Rather than hard-code these values, use
<filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink><filename>}</filename>,
which causes the fetch process to use the version specified in
the recipe filename.
@@ -1913,13 +1954,13 @@
<para>
Here is a simple example from the
- <filename>meta/recipes-devtools/cdrtools/cdrtools-native_3.01a20.bb</filename>
+ <filename>meta/recipes-devtools/strace/strace_5.5.bb</filename>
recipe where the source comes from a single tarball.
Notice the use of the
<ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink>
variable:
<literallayout class='monospaced'>
- SRC_URI = "ftp://ftp.berlios.de/pub/cdrecord/alpha/cdrtools-${PV}.tar.bz2"
+ SRC_URI = "https://strace.io/files/${PV}/strace-${PV}.tar.xz \
</literallayout>
</para>
@@ -1978,16 +2019,17 @@
For these cases, you provide a name for each URL as part of
the <filename>SRC_URI</filename> and then reference that name
in the subsequent checksum statements.
- Here is an example:
+ Here is an example combining lines from the files
+ <filename>git.inc</filename> and
+ <filename>git_2.24.1.bb</filename>:
<literallayout class='monospaced'>
- SRC_URI = "${DEBIAN_MIRROR}/main/a/apmd/apmd_3.2.2.orig.tar.gz;name=tarball \
- ${DEBIAN_MIRROR}/main/a/apmd/apmd_${PV}.diff.gz;name=patch"
+ SRC_URI = "${KERNELORG_MIRROR}/software/scm/git/git-${PV}.tar.gz;name=tarball \
+ ${KERNELORG_MIRROR}/software/scm/git/git-manpages-${PV}.tar.gz;name=manpages"
- SRC_URI[tarball.md5sum] = "b1e6309e8331e0f4e6efd311c2d97fa8"
- SRC_URI[tarball.sha256sum] = "7f7d9f60b7766b852881d40b8ff91d8e39fccb0d1d913102a5c75a2dbb52332d"
-
- SRC_URI[patch.md5sum] = "57e1b689264ea80f78353519eece0c92"
- SRC_URI[patch.sha256sum] = "7905ff96be93d725544d0040e425c42f9c05580db3c272f11cff75b9aa89d430"
+ SRC_URI[tarball.md5sum] = "166bde96adbbc11c8843d4f8f4f9811b"
+ SRC_URI[tarball.sha256sum] = "ad5334956301c86841eb1e5b1bb20884a6bad89a10a6762c958220c7cf64da02"
+ SRC_URI[manpages.md5sum] = "31c2272a8979022497ba3d4202df145d"
+ SRC_URI[manpages.sha256sum] = "9a7ae3a093bea39770eb96ca3e5b40bff7af0b9f6123f089d7821d0e5b8e1230"
</literallayout>
</para>
@@ -3242,8 +3284,6 @@
The script defined in the post-installation function is
called when the root filesystem is created.
If the script succeeds, the package is marked as installed.
- If the script fails, the package is marked as unpacked and
- the script is executed when the image boots again.
<note>
Any RPM post-installation script that runs on the target
should return a 0 exit code.
@@ -3262,7 +3302,7 @@
mark post installs to defer to the target.
You can use <filename>pkg_postinst_ontarget()</filename> or
call
- <filename>postinst-intercepts defer_to_first_boot</filename>
+ <filename>postinst_intercept delay_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
@@ -7609,7 +7649,6 @@
available Wic images as follows:
<literallayout class='monospaced'>
$ wic list images
- mpc8315e-rdb Create SD card image for MPC8315E-RDB
genericx86 Create an EFI disk image for genericx86*
beaglebone-yocto Create SD card image for Beaglebone
edgerouter Create SD card image for Edgerouter
@@ -7797,7 +7836,6 @@
files:
<literallayout class='monospaced'>
$ wic list images
- mpc8315e-rdb Create SD card image for MPC8315E-RDB
genericx86 Create an EFI disk image for genericx86*
beaglebone-yocto Create SD card image for Beaglebone
edgerouter Create SD card image for Edgerouter
@@ -10550,7 +10588,7 @@
<filename>devtool</filename> and the NPM fetcher to
create the recipe:
<literallayout class='monospaced'>
- $ devtool add "npm://registry.npmjs.org;name=cute-files;version=1.0.2"
+ $ devtool add "npm://registry.npmjs.org;package=cute-files;version=1.0.2"
</literallayout>
The <filename>devtool add</filename> command runs
<filename>recipetool create</filename> and uses the
@@ -10575,25 +10613,13 @@
</para>
<para>
- <filename>recipetool</filename> creates "shrinkwrap" and
- "lockdown" files for your recipe.
+ <filename>recipetool</filename> creates a "shrinkwrap" file
+ for your recipe.
Shrinkwrap files capture the version of all dependent
modules.
Many packages do not provide shrinkwrap files.
<filename>recipetool</filename> create a shrinkwrap
file as it runs.
- You can replace the shrinkwrap file with your own file
- by setting the <filename>NPM_SHRINKWRAP</filename>
- variable.
- </para>
-
- <para>
- Lockdown files contain the checksum for each module
- to determine if your users download the same files when
- building with a recipe.
- Lockdown files ensure that dependencies have not been
- changed and that your NPM registry is still providing
- the same file.
<note>
A package is created for each sub-module.
This policy is the only practical way to have the
@@ -10608,23 +10634,26 @@
<literallayout class='monospaced'>
$ devtool edit-recipe cute-files
SUMMARY = "Turn any folder on your computer into a cute file browser, available on the local network."
- LICENSE = "BSD-3-Clause & Unknown & MIT & ISC"
+ LICENSE = "MIT & ISC & Unknown"
LIC_FILES_CHKSUM = "file://LICENSE;md5=71d98c0a1db42956787b1909c74a86ca \
- file://node_modules/content-disposition/LICENSE;md5=c6e0ce1e688c5ff16db06b7259e9cd20 \
- file://node_modules/express/LICENSE;md5=5513c00a5c36cd361da863dd9aa8875d \
+ file://node_modules/toidentifier/LICENSE;md5=1a261071a044d02eb6f2bb47f51a3502 \
+ file://node_modules/debug/LICENSE;md5=ddd815a475e7338b0be7a14d8ee35a99 \
...
- SRC_URI = "npm://registry.npmjs.org;name=cute-files;version=${PV}"
- NPM_SHRINKWRAP := "${THISDIR}/${PN}/npm-shrinkwrap.json"
- NPM_LOCKDOWN := "${THISDIR}/${PN}/lockdown.json"
- inherit npm
- # Must be set after inherit npm since that itself sets S
- S = "${WORKDIR}/npmpkg"
+ SRC_URI = " \
+ npm://registry.npmjs.org/;package=cute-files;version=${PV} \
+ npmsw://${THISDIR}/${BPN}/npm-shrinkwrap.json \
+ "
- LICENSE_${PN}-content-disposition = "MIT"
- ...
- LICENSE_${PN}-express = "MIT"
+ S = "${WORKDIR}/npm"
+
+ inherit npm
+
LICENSE_${PN} = "MIT"
+ LICENSE_${PN}-accepts = "MIT"
+ LICENSE_${PN}-array-flatten = "MIT"
+ ...
+ LICENSE_${PN}-vary = "MIT"
</literallayout>
Three key points exist in the previous example:
<itemizedlist>
@@ -10717,11 +10746,10 @@
However, the <filename>SRC_URI</filename> looks like the
following:
<literallayout class='monospaced'>
- SRC_URI = "git://github.com/martinaglv/cute-files.git;protocol=https \
- npm://registry.npmjs.org;name=commander;version=2.9.0;subdir=node_modules/commander \
- npm://registry.npmjs.org;name=express;version=4.14.0;subdir=node_modules/express \
- npm://registry.npmjs.org;name=content-disposition;version=0.3.0;subdir=node_modules/content-disposition \
- "
+ SRC_URI = " \
+ git://github.com/martinaglv/cute-files.git;protocol=https \
+ npmsw://${THISDIR}/${BPN}/npm-shrinkwrap.json \
+ "
</literallayout>
In this example, the main module is taken from the Git
repository and dependents are taken from the NPM registry.
@@ -10822,7 +10850,7 @@
Use the following BitBake command form to fetch all the
necessary sources without starting the build:
<literallayout class='monospaced'>
- $ bitbake -c <replaceable>target</replaceable> runall="fetch"
+ $ bitbake <replaceable>target</replaceable> --runall=fetch
</literallayout>
This variation of the BitBake command guarantees that you
have all the sources for that BitBake target should you
@@ -10845,15 +10873,6 @@
</para>
<para>
- By default, the Yocto Project uses SysVinit as the initialization
- manager.
- However, support also exists for systemd,
- which is a full replacement for init with
- parallel starting of services, reduced shell overhead and other
- features that are used by many distributions.
- </para>
-
- <para>
Within the system, SysVinit treats system components as services.
These services are maintained as shell scripts stored in the
<filename>/etc/init.d/</filename> directory.
@@ -11164,18 +11183,18 @@
<para>
To create the read-only root filesystem, simply add the
- "read-only-rootfs" feature to your image.
- Using either of the following statements in your
- image recipe or from within the
- <filename>local.conf</filename> file found in the
- <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>
- causes the build system to create a read-only root filesystem:
+ "read-only-rootfs" feature to your image, normally in one of two ways.
+ The first way is to add the "read-only-rootfs" image feature
+ in the image's recipe file via the
+ <filename>IMAGE_FEATURES</filename> variable:
<literallayout class='monospaced'>
- IMAGE_FEATURES = "read-only-rootfs"
+ IMAGE_FEATURES += "read-only-rootfs"
</literallayout>
- or
+ As an alternative, you can add the same feature from within your
+ build directory's <filename>local.conf</filename> file with the
+ associated <filename>EXTRA_IMAGE_FEATURES</filename> variable, as in:
<literallayout class='monospaced'>
- EXTRA_IMAGE_FEATURES += "read-only-rootfs"
+ EXTRA_IMAGE_FEATURES = "read-only-rootfs"
</literallayout>
</para>
@@ -12038,15 +12057,15 @@
In order to run tests on hardware, you need to set
<filename>TEST_TARGET</filename> to an appropriate value.
For QEMU, you do not have to change anything, the default
- value is "QemuTarget".
+ value is "qemu".
For running tests on hardware, the following options exist:
<itemizedlist>
- <listitem><para><emphasis>"SimpleRemoteTarget":</emphasis>
- Choose "SimpleRemoteTarget" if you are going to
+ <listitem><para><emphasis>"simpleremote":</emphasis>
+ Choose "simpleremote" if you are going to
run tests on a target system that is already
running the image to be tested and is available
on the network.
- You can use "SimpleRemoteTarget" in conjunction
+ You can use "simpleremote" in conjunction
with either real hardware or an image running
within a separately started QEMU or any
other virtual machine manager.
@@ -12221,7 +12240,7 @@
<title>Power Control</title>
<para>
- For most hardware targets other than SimpleRemoteTarget,
+ For most hardware targets other than "simpleremote",
you can control power:
<itemizedlist>
<listitem><para>
@@ -12618,7 +12637,7 @@
<listitem><para><emphasis><filename>target</filename>:</emphasis>
The target controller object used to deploy
and start an image on a particular target
- (e.g. QemuTarget, SimpleRemote, and
+ (e.g. Qemu, SimpleRemote, and
SystemdbootTarget).
Tests usually use the following:
<itemizedlist>