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/ref-manual/ref-variables.xml b/poky/documentation/ref-manual/ref-variables.xml
index 02abc59..b44fdcb 100644
--- a/poky/documentation/ref-manual/ref-variables.xml
+++ b/poky/documentation/ref-manual/ref-variables.xml
@@ -367,7 +367,7 @@
<glossentry id='var-ASSUME_SHLIBS'><glossterm>ASSUME_SHLIBS</glossterm>
<info>
- ASSUME_SHLIBS[doc] = Provides additional shlibs provider mapping information, which adds to or overwrites the information provided automatically by the system."
+ ASSUME_SHLIBS[doc] = "Provides additional shlibs provider mapping information, which adds to or overwrites the information provided automatically by the system."
</info>
<glossdef>
<para role="glossdeffirst">
@@ -495,6 +495,30 @@
</glossdef>
</glossentry>
+ <glossentry id='var-AVAILABLE_LICENSES'><glossterm>AVAILABLE_LICENSES</glossterm>
+ <info>
+ AVAILABLE_LICENSES[doc] = "List of licenses found in the directories specified by COMMON_LICENSE_DIR and LICENSE_PATH."
+ </info>
+ <glossdef>
+ <para role="glossdeffirst">
+<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+
+ List of licenses found in the directories specified
+ by <link linkend='var-COMMON_LICENSE_DIR'><filename>COMMON_LICENSE_DIR</filename></link>
+ and <link linkend='var-LICENSE_PATH'><filename>LICENSE_PATH</filename></link>.
+
+ <note>
+ It is assumed that all changes
+ to <filename>COMMON_LICENSE_DIR</filename>
+ and <filename>LICENSE_PATH</filename> have been done
+ before <filename>AVAILABLE_LICENSES</filename> is
+ defined
+ (in <link linkend='ref-classes-license'>license.bbclass</link>).
+ </note>
+ </para>
+ </glossdef>
+ </glossentry>
+
<glossentry id='var-AVAILTUNES'><glossterm>AVAILTUNES</glossterm>
<info>
AVAILTUNES[doc] = "The list of defined CPU and Application Binary Interface (ABI) tunings (i.e. "tunes") available for use by the OpenEmbedded build system."
@@ -1423,7 +1447,7 @@
Use the following format to export the variable to the
BitBake environment:
<literallayout class='monospaced'>
- export BBSERVER=localhost:$port"
+ export BBSERVER=localhost:$port
</literallayout>
</para>
@@ -3786,7 +3810,7 @@
It is not intended to be user-configurable.
It is best to just reference the variable to see which distro features are
being backfilled for all distro configurations.
- See the <link linkend='ref-features-backfill'>Feature Backfilling</link> section for
+ See the "<link linkend='ref-features-backfill'>Feature Backfilling</link>" section for
more information.
</para>
</glossdef>
@@ -6750,6 +6774,25 @@
components that are required to produce a functional system
image.
</note>
+
+ <note><title>Tips</title>
+ It is possible to define a list of licenses that are allowed
+ to be used instead of the licenses that are excluded. To do
+ this, define a
+ variable <filename>COMPATIBLE_LICENSES</filename> with the
+ names of the licences that are allowed. Then
+ define <filename>INCOMPATIBLE_LICENSE</filename> as:
+ <literallayout class='monospaced'>
+ INCOMPATIBLE_LICENSE = "${@' '.join(sorted(set(d.getVar('AVAILABLE_LICENSES').split()) - set(d.getVar('COMPATIBLE_LICENSES').split())))}"
+ </literallayout>
+ This will result
+ in <filename>INCOMPATIBLE_LICENSE</filename> containing the
+ names of all licences
+ from <link linkend='var-AVAILABLE_LICENSES'><filename>AVAILABLE_LICENSES</filename></link>
+ except the ones specified
+ in <filename>COMPATIBLE_LICENSES</filename>, thus only
+ allowing the latter licences to be used.
+ </note>
</glossdef>
</glossentry>
@@ -7428,7 +7471,6 @@
KBRANCH_genericx86-64 = "standard/base"
KBRANCH_edgerouter = "standard/edgerouter"
KBRANCH_beaglebone = "standard/beaglebone"
- KBRANCH_mpc8315e-rdb = "standard/fsl-mpc8315e-rdb"
</literallayout>
The <filename>KBRANCH</filename> statements identify
the kernel branch to use when building for each
@@ -8746,7 +8788,6 @@
MACHINE ?= "genericx86"
MACHINE ?= "genericx86-64"
MACHINE ?= "beaglebone"
- MACHINE ?= "mpc8315e-rdb"
MACHINE ?= "edgerouter"
</literallayout>
The last five are Yocto Project reference hardware boards, which
@@ -10376,12 +10417,20 @@
<filename>PACKAGECONFIG</filename> blocks are defined
in recipes when you specify features and then arguments
that define feature behaviors.
- Here is the basic block structure:
+ Here is the basic block structure (broken over multiple
+ lines for readability):
<literallayout class='monospaced'>
PACKAGECONFIG ??= "f1 f2 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"
+ PACKAGECONFIG[f1] = "\
+ --with-f1, \
+ --without-f1, \
+ build-deps-for-f1, \
+ runtime-deps-for-f1, \
+ runtime-recommends-for-f1, \
+ packageconfig-conflicts-for-f1 \
+ "
+ PACKAGECONFIG[f2] = "\
+ ... and so on and so on ...
</literallayout>
</para>
@@ -10390,7 +10439,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 five order-dependent
+ each feature by providing up to six order-dependent
arguments, which are separated by commas.
You can omit any argument you like but must retain the
separating commas.
@@ -10420,6 +10469,10 @@
(<link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>)
that should be added if the feature is enabled.
</para></listitem>
+ <listitem><para>Any conflicting (that is, mutually
+ exclusive) <filename>PACKAGECONFIG</filename>
+ settings for this feature.
+ </para></listitem>
</orderedlist>
</para>
@@ -10427,25 +10480,23 @@
Consider the following
<filename>PACKAGECONFIG</filename> block taken from the
<filename>librsvg</filename> recipe.
- In this example the feature is <filename>croco</filename>,
+ In this example the feature is <filename>gtk</filename>,
which has three arguments that determine the feature's
behavior.
<literallayout class='monospaced'>
- PACKAGECONFIG ??= "croco"
- PACKAGECONFIG[croco] = "--with-croco,--without-croco,libcroco"
+ PACKAGECONFIG[gtk] = "--with-gtk3,--without-gtk3,gtk+3"
</literallayout>
- The <filename>--with-croco</filename> and
- <filename>libcroco</filename> arguments apply only if
+ The <filename>--with-gtk3</filename> and
+ <filename>gtk+3</filename> arguments apply only if
the feature is enabled.
- In this case, <filename>--with-croco</filename> is
+ In this case, <filename>--with-gtk3</filename> is
added to the configure script argument list and
- <filename>libcroco</filename> is added to
+ <filename>gtk+3</filename> is added to
<filename>DEPENDS</filename>.
On the other hand, if the feature is disabled say through
a <filename>.bbappend</filename> file in another layer, then
- the second argument <filename>--without-croco</filename> is
- added to the configure script rather than
- <filename>--with-croco</filename>.
+ the second argument <filename>--without-gtk3</filename> is
+ added to the configure script instead.
</para>
<para>
@@ -11054,7 +11105,7 @@
<glossentry id='var-PN'><glossterm>PN</glossterm>
<info>
- PN[doc] = "PN refers to a recipe name in the context of a file used by the OpenEmbedded build system as input to create a package.
+ PN[doc] = "PN refers to a recipe name in the context of a file used by the OpenEmbedded build system as input to create a package."
</info>
<glossdef>
<para role="glossdeffirst">
@@ -11501,23 +11552,35 @@
By default, a recipe's own
<filename><link linkend='var-PN'>PN</link></filename>
is implicitly already in its <filename>PROVIDES</filename>
- list.
+ list and therefore does not need to mention that it provides itself.
If a recipe uses <filename>PROVIDES</filename>, the
additional aliases are synonyms for the recipe and can
- be useful satisfying dependencies of other recipes during
+ be useful for satisfying dependencies of other recipes during
the build as specified by
<filename><link linkend='var-DEPENDS'>DEPENDS</link></filename>.
</para>
<para>
Consider the following example
- <filename>PROVIDES</filename> statement from a recipe
- file <filename>libav_0.8.11.bb</filename>:
+ <filename>PROVIDES</filename> statement from the recipe
+ file <filename>eudev_3.2.9.bb</filename>:
<literallayout class='monospaced'>
- PROVIDES += "libpostproc"
+ PROVIDES = "udev"
</literallayout>
The <filename>PROVIDES</filename> statement results in
- the "libav" recipe also being known as "libpostproc".
+ the "eudev" recipe also being available as simply "udev".
+
+ <note>
+ Given that a recipe's own recipe name is already
+ implicitly in its own <filename>PROVIDES</filename> list,
+ it is unnecessary to add aliases with the "+=" operator;
+ using a simple assignment will be sufficient. In other
+ words, while you could write:
+ <literallayout class='monospaced'>
+ PROVIDES += "udev"
+ </literallayout>
+ in the above, the "+=" is overkill and unnecessary.
+ </note>
</para>
<para>
@@ -13383,8 +13446,7 @@
<glossentry id='var-SKIP_FILEDEPS'><glossterm>SKIP_FILEDEPS</glossterm>
<info>
- SKIP_FILEDEPS[doc] = "Enables you to remove all files from
- the "Provides" section of an RPM package."
+ SKIP_FILEDEPS[doc] = "Enables you to remove all files from the 'Provides' section of an RPM package."
</info>
<glossdef>
<para role="glossdeffirst">
@@ -15331,7 +15393,7 @@
<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."
+ 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">
@@ -15646,9 +15708,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 "QemuTarget":
+ The default controller to use is "qemu":
<literallayout class='monospaced'>
- TEST_TARGET = "QemuTarget"
+ TEST_TARGET = "qemu"
</literallayout>
</para>
@@ -15667,21 +15729,21 @@
You can provide the following arguments with
<filename>TEST_TARGET</filename>:
<itemizedlist>
- <listitem><para><emphasis>"QemuTarget":</emphasis>
+ <listitem><para><emphasis>"qemu":</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>"SimpleRemoteTarget":</emphasis>
+ <listitem><para><emphasis>"simpleremote":</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 "SimpleRemoteTarget".
+ when you use "simpleremote".
<note>
This argument is defined in
<filename>meta/lib/oeqa/controllers/simpleremote.py</filename>.
@@ -16473,7 +16535,7 @@
Appends a string to the name of the local version of the
U-Boot image.
For example, assuming the version of the U-Boot image
- built was "2013.10, the full version string reported by
+ built was "2013.10", the full version string reported by
U-Boot would be "2013.10-yocto" given the following
statement:
<literallayout class='monospaced'>
@@ -16771,18 +16833,21 @@
<glossentry id='var-USERADD_ERROR_DYNAMIC'><glossterm>USERADD_ERROR_DYNAMIC</glossterm>
<info>
- USERADD_ERROR_DYNAMIC[doc] = "If set to 'error', forces the OpenEmbedded build system to produce an error if the user identification (uid) and group identification (gid) values are not defined in files/passwd and files/group files. If set to 'warn', a warning will be issued instead."
+ USERADD_ERROR_DYNAMIC[doc] = "If set to 'error', forces the OpenEmbedded build system to produce an error if the user identification (uid) and group identification (gid) values are not defined in any of the files listed in USERADD_UID_TABLES and USERADD_GID_TABLES. If set to 'warn', a warning will be issued instead."
</info>
<glossdef>
<para role="glossdeffirst">
<!-- <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
- If set to "error", forces the OpenEmbedded build system to
- produce an error if the user identification
- (<filename>uid</filename>) and group identification
- (<filename>gid</filename>) values are not defined
- in <filename>files/passwd</filename>
- and <filename>files/group</filename> files.
- If set to "warn", a warning will be issued instead.
+
+ If set to <filename>error</filename>, forces the
+ OpenEmbedded build system to produce an error if the user
+ identification (<filename>uid</filename>) and group
+ identification (<filename>gid</filename>) values are not
+ defined in any of the files listed
+ in <link linkend='var-USERADD_UID_TABLES'><filename>USERADD_UID_TABLES</filename></link>
+ and <link linkend='var-USERADD_GID_TABLES'><filename>USERADD_GID_TABLES</filename></link>. If
+ set to <filename>warn</filename>, a warning will be issued
+ instead.
</para>
<para>
@@ -16809,6 +16874,20 @@
<link linkend='var-USERADD_GID_TABLES'><filename>USERADD_GID_TABLES</filename></link>
variables.
</para>
+
+ <note>
+ There is a difference in behavior between
+ setting <filename>USERADD_ERROR_DYNAMIC</filename>
+ to <filename>error</filename> and setting it
+ to <filename>warn</filename>. When it is set
+ to <filename>warn</filename>, the build system will report a
+ warning for every undefined <filename>uid</filename> and
+ <filename>gid</filename> in any recipe. But when it is set
+ to <filename>error</filename>, it will only report errors
+ for recipes that are actually built. This saves you from
+ having to add static IDs for recipes that you know will
+ never be built.
+ </note>
</glossdef>
</glossentry>
@@ -17108,7 +17187,7 @@
"<ulink url='&YOCTO_DOCS_DEV_URL;#creating-partitioned-images-using-wic'>Creating Partitioned Images Using Wic</ulink>"
section in the Yocto Project Development Tasks Manual.
For details on the kickstart file format, see the
- "<link linkend='ref-kickstart'>OpenEmbedded Kickstart (<filename>.wks</filename>) Reference</link>
+ "<link linkend='ref-kickstart'>OpenEmbedded Kickstart (<filename>.wks</filename>) Reference</link>"
Chapter.
</para>
</glossdef>
@@ -17178,8 +17257,7 @@
<glossentry id='var-XSERVER'><glossterm>XSERVER</glossterm>
<info>
- XSERVER[doc] = "Specifies the packages that should be installed
- to provide an X server and drivers for the current machine."
+ XSERVER[doc] = "Specifies the packages that should be installed to provide an X server and drivers for the current machine."
</info>
<glossdef>
<para role="glossdeffirst">