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/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>