Yocto 2.4
Move OpenBMC to Yocto 2.4(rocko)
Tested: Built and verified Witherspoon and Palmetto images
Change-Id: I12057b18610d6fb0e6903c60213690301e9b0c67
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
diff --git a/import-layers/yocto-poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.xml b/import-layers/yocto-poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.xml
index d1ce43e..c721e86 100644
--- a/import-layers/yocto-poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.xml
+++ b/import-layers/yocto-poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.xml
@@ -620,7 +620,9 @@
The Git Submodules fetcher is not a complete fetcher
implementation.
The fetcher has known issues where it does not use the
- normal source mirroring infrastructure properly.
+ normal source mirroring infrastructure properly. Further,
+ the submodule sources it fetches are not visible to the
+ licensing and source archiving infrastructures.
</para>
</note>
</para>
diff --git a/import-layers/yocto-poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-hello.xml b/import-layers/yocto-poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-hello.xml
index 2685c0e..9253eaf 100644
--- a/import-layers/yocto-poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-hello.xml
+++ b/import-layers/yocto-poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-hello.xml
@@ -128,15 +128,8 @@
</para>
<note>
- This example was inspired by and drew heavily from these sources:
- <itemizedlist>
- <listitem><para>
- <ulink url="http://www.mail-archive.com/yocto@yoctoproject.org/msg09379.html">Mailing List post - The BitBake equivalent of "Hello, World!"</ulink>
- </para></listitem>
- <listitem><para>
- <ulink url="https://web.archive.org/web/20150325165911/http://hambedded.org/blog/2012/11/24/from-bitbake-hello-world-to-an-image/">Hambedded Linux blog post - From Bitbake Hello World to an Image</ulink>
- </para></listitem>
- </itemizedlist>
+ This example was inspired by and drew heavily from
+ <ulink url="http://www.mail-archive.com/yocto@yoctoproject.org/msg09379.html">Mailing List post - The BitBake equivalent of "Hello, World!"</ulink>.
</note>
<para>
@@ -269,7 +262,7 @@
and define some key BitBake variables.
For more information on the <filename>bitbake.conf</filename>,
see
- <ulink url='https://web.archive.org/web/20150325165911/http://hambedded.org/blog/2012/11/24/from-bitbake-hello-world-to-an-image/#an-overview-of-bitbakeconf'></ulink>
+ <ulink url='http://git.openembedded.org/bitbake/tree/conf/bitbake.conf'></ulink>.
</para>
<para>Use the following commands to create the <filename>conf</filename>
directory in the project directory:
@@ -352,9 +345,6 @@
Of course, the <filename>base.bbclass</filename> can have much
more depending on which build environments BitBake is
supporting.
- For more information on the <filename>base.bbclass</filename> file,
- you can look at
- <ulink url='https://web.archive.org/web/20150325165911/http://hambedded.org/blog/2012/11/24/from-bitbake-hello-world-to-an-image/#tasks'></ulink>.
</para></listitem>
<listitem><para><emphasis>Run Bitbake:</emphasis>
After making sure that the <filename>classes/base.bbclass</filename>
@@ -375,8 +365,8 @@
code separate from the general metadata used by BitBake.
Thus, this example creates and uses a layer called "mylayer".
<note>
- You can find additional information on adding a layer at
- <ulink url='https://web.archive.org/web/20150325165911/http://hambedded.org/blog/2012/11/24/from-bitbake-hello-world-to-an-image/#adding-an-example-layer'></ulink>.
+ You can find additional information on layers at
+ <ulink url='http://www.yoctoproject.org/docs/2.3/bitbake-user-manual/bitbake-user-manual.html#layers'></ulink>.
</note>
</para>
<para>Minimally, you need a recipe file and a layer configuration
diff --git a/import-layers/yocto-poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-intro.xml b/import-layers/yocto-poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-intro.xml
index ca7f724..08d9afd 100644
--- a/import-layers/yocto-poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-intro.xml
+++ b/import-layers/yocto-poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-intro.xml
@@ -440,7 +440,7 @@
Build Checkout:</emphasis>
A final possibility for getting a copy of BitBake is that it
already comes with your checkout of a larger Bitbake-based build
- system, such as Poky or Yocto Project.
+ system, such as Poky.
Rather than manually checking out individual layers and
gluing them together yourself, you can check
out an entire build system.
diff --git a/import-layers/yocto-poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-metadata.xml b/import-layers/yocto-poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-metadata.xml
index 1d1e5b3..0cfa53d 100644
--- a/import-layers/yocto-poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-metadata.xml
+++ b/import-layers/yocto-poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-metadata.xml
@@ -669,7 +669,7 @@
<literallayout class='monospaced'>
DEPENDS = "glibc ncurses"
OVERRIDES = "machine:local"
- DEPENDS_append_machine = "libmad"
+ DEPENDS_append_machine = " libmad"
</literallayout>
In this example, <filename>DEPENDS</filename> becomes
"glibc ncurses libmad".
@@ -899,11 +899,12 @@
<para>
The <filename>inherit</filename> directive is a rudimentary
- means of specifying what classes of functionality your
- recipes require.
+ means of specifying functionality contained in class files
+ that your recipes require.
For example, you can easily abstract out the tasks involved in
building a package that uses Autoconf and Automake and put
- those tasks into a class file that can be used by your recipe.
+ those tasks into a class file and then have your recipe
+ inherit that class file.
</para>
<para>
@@ -922,13 +923,24 @@
inherited class within your recipe by doing so
after the "inherit" statement.
</note>
+ If you want to use the directive to inherit
+ multiple classes, separate them with spaces.
+ The following example shows how to inherit both the
+ <filename>buildhistory</filename> and <filename>rm_work</filename>
+ classes:
+ <literallayout class='monospaced'>
+ inherit buildhistory rm_work
+ </literallayout>
</para>
<para>
- If necessary, it is possible to inherit a class
- conditionally by using
- a variable expression after the <filename>inherit</filename>
- statement.
+ An advantage with the inherit directive as compared to both
+ the
+ <link linkend='include-directive'>include</link> and
+ <link linkend='require-inclusion'>require</link> directives
+ is that you can inherit class files conditionally.
+ You can accomplish this by using a variable expression
+ after the <filename>inherit</filename> statement.
Here is an example:
<literallayout class='monospaced'>
inherit ${VARNAME}
@@ -985,6 +997,17 @@
</para>
<para>
+ The include directive is a more generic method of including
+ functionality as compared to the
+ <link linkend='inherit-directive'>inherit</link> directive,
+ which is restricted to class (i.e. <filename>.bbclass</filename>)
+ files.
+ The include directive is applicable for any other kind of
+ shared or encapsulated functionality or configuration that
+ does not suit a <filename>.bbclass</filename> file.
+ </para>
+
+ <para>
As an example, suppose you needed a recipe to include some
self-test definitions:
<literallayout class='monospaced'>
@@ -1018,6 +1041,18 @@
</para>
<para>
+ The require directive, like the include directive previously
+ described, is a more generic method of including
+ functionality as compared to the
+ <link linkend='inherit-directive'>inherit</link> directive,
+ which is restricted to class (i.e. <filename>.bbclass</filename>)
+ files.
+ The require directive is applicable for any other kind of
+ shared or encapsulated functionality or configuration that
+ does not suit a <filename>.bbclass</filename> file.
+ </para>
+
+ <para>
Similar to how BitBake handles
<link linkend='include-directive'><filename>include</filename></link>,
if the path specified
@@ -1049,8 +1084,9 @@
<para>
When creating a configuration file (<filename>.conf</filename>),
- you can use the <filename>INHERIT</filename> directive to
- inherit a class.
+ you can use the
+ <link linkend='var-INHERIT'><filename>INHERIT</filename></link>
+ configuration directive to inherit a class.
BitBake only supports this directive when used within
a configuration file.
</para>
@@ -1083,7 +1119,7 @@
<filename>autotools</filename> and <filename>pkgconfig</filename>
classes:
<literallayout class='monospaced'>
- inherit autotools pkgconfig
+ INHERIT += "autotools pkgconfig"
</literallayout>
</para>
</section>
@@ -2029,7 +2065,7 @@
before any tasks are executed so would be in the global
configuration datastore namespace.
No recipe-specific metadata exists in that namespace.
- The "BuildStarted" and "buildCompleted" events also run in
+ The "BuildStarted" and "BuildCompleted" events also run in
the main cooker/server process rather than any worker context.
Thus, any changes made to the datastore would be seen by other
cooker/server events within the current build but not seen
diff --git a/import-layers/yocto-poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.xml b/import-layers/yocto-poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.xml
index 0e89bf2..d89e123 100644
--- a/import-layers/yocto-poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.xml
+++ b/import-layers/yocto-poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.xml
@@ -1143,8 +1143,6 @@
<glossdef>
<para>
Sets the base location where layers are stored.
- By default, this location is set to
- <filename>${COREBASE}</filename>.
This setting is used in conjunction with
<filename>bitbake-layers layerindex-fetch</filename> and
tells <filename>bitbake-layers</filename> where to place
@@ -1596,9 +1594,19 @@
<glossentry id='var-INHERIT'><glossterm>INHERIT</glossterm>
<glossdef>
<para>
- Causes the named class to be inherited at
- this point during parsing.
- The variable is only valid in configuration files.
+ Causes the named class or classes to be inherited globally.
+ Anonymous functions in the class or classes
+ are not executed for the
+ base configuration and in each individual recipe.
+ The OpenEmbedded build system ignores changes to
+ <filename>INHERIT</filename> in individual recipes.
+ </para>
+
+ <para>
+ For more information on <filename>INHERIT</filename>, see
+ the
+ "<link linkend="inherit-configuration-directive"><filename>INHERIT</filename> Configuration Directive</link>"
+ section.
</para>
</glossdef>
</glossentry>
@@ -1893,7 +1901,7 @@
Here are two examples:
<literallayout class='monospaced'>
PREFERRED_VERSION_python = "2.7.3"
- PREFERRED_VERSION_linux-yocto = "3.10%"
+ PREFERRED_VERSION_linux-yocto = "4.12%"
</literallayout>
</para>
</glossdef>