Yocto 2.5
Move OpenBMC to Yocto 2.5(sumo)
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
Change-Id: I5c5ad6904a16e14c1c397f0baf10c9d465594a78
diff --git a/import-layers/yocto-poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-execution.xml b/import-layers/yocto-poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-execution.xml
index e4cc422..f1caaec 100644
--- a/import-layers/yocto-poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-execution.xml
+++ b/import-layers/yocto-poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual-execution.xml
@@ -781,7 +781,7 @@
The code in <filename>meta/lib/oe/sstatesig.py</filename> shows two examples
of this and also illustrates how you can insert your own policy into the system
if so desired.
- This file defines the two basic signature generators OpenEmbedded Core
+ This file defines the two basic signature generators OpenEmbedded-Core
uses: "OEBasic" and "OEBasicHash".
By default, there is a dummy "noop" signature handler enabled in BitBake.
This means that behavior is unchanged from previous versions.
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 c721e86..29ae486 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
@@ -777,6 +777,43 @@
</para>
</section>
+ <section id='repo-fetcher'>
+ <title>Repo Fetcher (<filename>repo://</filename>)</title>
+
+ <para>
+ This fetcher submodule fetches code from
+ <filename>google-repo</filename> source control system.
+ The fetcher works by initiating and syncing sources of the
+ repository into
+ <link linkend='var-REPODIR'><filename>REPODIR</filename></link>,
+ which is usually
+ <link linkend='var-DL_DIR'><filename>DL_DIR</filename></link><filename>/repo</filename>.
+ </para>
+
+ <para>
+ This fetcher supports the following parameters:
+ <itemizedlist>
+ <listitem><para>
+ <emphasis>"protocol":</emphasis>
+ Protocol to fetch the repository manifest (default: git).
+ </para></listitem>
+ <listitem><para>
+ <emphasis>"branch":</emphasis>
+ Branch or tag of repository to get (default: master).
+ </para></listitem>
+ <listitem><para>
+ <emphasis>"manifest":</emphasis>
+ Name of the manifest file (default: <filename>default.xml</filename>).
+ </para></listitem>
+ </itemizedlist>
+ Here are some example URLs:
+ <literallayout class='monospaced'>
+ SRC_URI = "repo://REPOROOT;protocol=git;branch=some_branch;manifest=my_manifest.xml"
+ SRC_URI = "repo://REPOROOT;protocol=file;branch=some_branch;manifest=my_manifest.xml"
+ </literallayout>
+ </para>
+ </section>
+
<section id='other-fetchers'>
<title>Other Fetchers</title>
@@ -796,9 +833,6 @@
Secure Shell (<filename>ssh://</filename>)
</para></listitem>
<listitem><para>
- Repo (<filename>repo://</filename>)
- </para></listitem>
- <listitem><para>
OSC (<filename>osc://</filename>)
</para></listitem>
<listitem><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 9253eaf..9076f0f 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
@@ -260,7 +260,7 @@
files.
For this example, you need to create the file in your project directory
and define some key BitBake variables.
- For more information on the <filename>bitbake.conf</filename>,
+ For more information on the <filename>bitbake.conf</filename> file,
see
<ulink url='http://git.openembedded.org/bitbake/tree/conf/bitbake.conf'></ulink>.
</para>
@@ -273,14 +273,32 @@
some editor to create the <filename>bitbake.conf</filename>
so that it contains the following:
<literallayout class='monospaced'>
+ <link linkend='var-PN'>PN</link> = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[0] or 'defaultpkgname'}"
+ </literallayout>
+ <literallayout class='monospaced'>
TMPDIR = "${<link linkend='var-TOPDIR'>TOPDIR</link>}/tmp"
<link linkend='var-CACHE'>CACHE</link> = "${TMPDIR}/cache"
- <link linkend='var-STAMP'>STAMP</link> = "${TMPDIR}/stamps"
- <link linkend='var-T'>T</link> = "${TMPDIR}/work"
- <link linkend='var-B'>B</link> = "${TMPDIR}"
+ <link linkend='var-STAMP'>STAMP</link> = "${TMPDIR}/${PN}/stamps"
+ <link linkend='var-T'>T</link> = "${TMPDIR}/${PN}/work"
+ <link linkend='var-B'>B</link> = "${TMPDIR}/${PN}"
</literallayout>
+ <note>
+ Without a value for <filename>PN</filename>, the
+ variables <filename>STAMP</filename>,
+ <filename>T</filename>, and <filename>B</filename>,
+ prevent more than one recipe from working. You can fix
+ this by either setting <filename>PN</filename> to have
+ a value similar to what OpenEmbedded and BitBake use
+ in the default <filename>bitbake.conf</filename> file
+ (see previous example). Or, by manually updating each
+ recipe to set <filename>PN</filename>. You will also
+ need to include <filename>PN</filename> as part of the
+ <filename>STAMP</filename>, <filename>T</filename>, and
+ <filename>B</filename> variable definitions in the
+ <filename>local.conf</filename> file.
+ </note>
The <filename>TMPDIR</filename> variable establishes a directory
- that BitBake uses for build output and intermediate files (other
+ that BitBake uses for build output and intermediate files other
than the cached information used by the
<link linkend='setscene'>Setscene</link> process.
Here, the <filename>TMPDIR</filename> directory is set to
@@ -300,19 +318,19 @@
file exists, you can run the <filename>bitbake</filename>
command again:
<literallayout class='monospaced'>
-$ bitbake
-ERROR: Traceback (most recent call last):
- File "/home/scott-lenovo/bitbake/lib/bb/cookerdata.py", line 163, in wrapped
- return func(fn, *args)
- File "/home/scott-lenovo/bitbake/lib/bb/cookerdata.py", line 177, in _inherit
- bb.parse.BBHandler.inherit(bbclass, "configuration INHERITs", 0, data)
- File "/home/scott-lenovo/bitbake/lib/bb/parse/parse_py/BBHandler.py", line 92, in inherit
- include(fn, file, lineno, d, "inherit")
- File "/home/scott-lenovo/bitbake/lib/bb/parse/parse_py/ConfHandler.py", line 100, in include
- raise ParseError("Could not %(error_out)s file %(fn)s" % vars(), oldfn, lineno)
-ParseError: ParseError in configuration INHERITs: Could not inherit file classes/base.bbclass
+ $ bitbake
+ ERROR: Traceback (most recent call last):
+ File "/home/scott-lenovo/bitbake/lib/bb/cookerdata.py", line 163, in wrapped
+ return func(fn, *args)
+ File "/home/scott-lenovo/bitbake/lib/bb/cookerdata.py", line 177, in _inherit
+ bb.parse.BBHandler.inherit(bbclass, "configuration INHERITs", 0, data)
+ File "/home/scott-lenovo/bitbake/lib/bb/parse/parse_py/BBHandler.py", line 92, in inherit
+ include(fn, file, lineno, d, "inherit")
+ File "/home/scott-lenovo/bitbake/lib/bb/parse/parse_py/ConfHandler.py", line 100, in include
+ raise ParseError("Could not %(error_out)s file %(fn)s" % vars(), oldfn, lineno)
+ ParseError: ParseError in configuration INHERITs: Could not inherit file classes/base.bbclass
-ERROR: Unable to parse base: ParseError in configuration INHERITs: Could not inherit file classes/base.bbclass
+ ERROR: Unable to parse base: ParseError in configuration INHERITs: Could not inherit file classes/base.bbclass
</literallayout>
In the sample output, BitBake could not find the
<filename>classes/base.bbclass</filename> file.
@@ -365,10 +383,10 @@
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 layers at
- <ulink url='http://www.yoctoproject.org/docs/2.3/bitbake-user-manual/bitbake-user-manual.html#layers'></ulink>.
- </note>
- </para>
+ You can find additional information on layers in the
+ "<link linkend='layers'>Layers</link>" section.
+ </note></para>
+
<para>Minimally, you need a recipe file and a layer configuration
file in your layer.
The configuration file needs to be in the <filename>conf</filename>
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 08d9afd..4cf0ed9 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
@@ -488,8 +488,6 @@
target that failed and anything depending on it cannot
be built, as much as possible will be built before
stopping.
- -a, --tryaltconfigs Continue with builds by trying to use alternative
- providers where possible.
-f, --force Force the specified targets/task to run (invalidating
any existing stamp file).
-c CMD, --cmd=CMD Specify the task to execute. The exact options
@@ -504,19 +502,20 @@
Read the specified file before bitbake.conf.
-R POSTFILE, --postread=POSTFILE
Read the specified file after bitbake.conf.
- -v, --verbose Enable tracing of shell tasks (with 'set -x').
- Also print bb.note(...) messages to stdout (in
- addition to writing them to ${T}/log.do_<task>).
- -D, --debug Increase the debug level. You can specify this
- more than once. -D sets the debug level to 1,
- where only bb.debug(1, ...) messages are printed
- to stdout; -DD sets the debug level to 2, where
- both bb.debug(1, ...) and bb.debug(2, ...)
- messages are printed; etc. Without -D, no debug
- messages are printed. Note that -D only affects
- output to stdout. All debug messages are written
- to ${T}/log.do_taskname, regardless of the debug
- level.
+ -v, --verbose Enable tracing of shell tasks (with 'set -x'). Also
+ print bb.note(...) messages to stdout (in addition to
+ writing them to ${T}/log.do_<task>).
+ -D, --debug Increase the debug level. You can specify this more
+ than once. -D sets the debug level to 1, where only
+ bb.debug(1, ...) messages are printed to stdout; -DD
+ sets the debug level to 2, where both bb.debug(1, ...)
+ and bb.debug(2, ...) messages are printed; etc.
+ Without -D, no debug messages are printed. Note that
+ -D only affects output to stdout. All debug messages
+ are written to ${T}/log.do_taskname, regardless of the
+ debug level.
+ -q, --quiet Output less log message data to the terminal. You can
+ specify this more than once.
-n, --dry-run Don't execute, just go through the motions.
-S SIGNATURE_HANDLER, --dump-signatures=SIGNATURE_HANDLER
Dump out the signature construction information, with
@@ -539,30 +538,38 @@
-l DEBUG_DOMAINS, --log-domains=DEBUG_DOMAINS
Show debug logging for the specified logging domains
-P, --profile Profile the command and save reports.
- -u UI, --ui=UI The user interface to use (taskexp, knotty or
- ncurses - default knotty).
- -t SERVERTYPE, --servertype=SERVERTYPE
- Choose which server type to use (process or xmlrpc -
- default process).
+ -u UI, --ui=UI The user interface to use (knotty, ncurses or taskexp
+ - default knotty).
--token=XMLRPCTOKEN Specify the connection token to be used when
connecting to a remote server.
--revisions-changed Set the exit code depending on whether upstream
floating revisions have changed or not.
--server-only Run bitbake without a UI, only starting a server
(cooker) process.
- -B BIND, --bind=BIND The name/address for the bitbake server to bind to.
+ -B BIND, --bind=BIND The name/address for the bitbake xmlrpc server to bind
+ to.
+ -T SERVER_TIMEOUT, --idle-timeout=SERVER_TIMEOUT
+ Set timeout to unload bitbake server due to
+ inactivity, set to -1 means no unload, default:
+ Environment variable BB_SERVER_TIMEOUT.
--no-setscene Do not run any setscene tasks. sstate will be ignored
and everything needed, built.
--setscene-only Only run setscene tasks, don't run any real tasks.
--remote-server=REMOTE_SERVER
Connect to the specified server.
- -m, --kill-server Terminate the remote server.
+ -m, --kill-server Terminate any running bitbake server.
--observe-only Connect to a server as an observing-only client.
--status-only Check the status of the remote bitbake server.
-w WRITEEVENTLOG, --write-log=WRITEEVENTLOG
Writes the event log of the build to a bitbake event
json file. Use '' (empty string) to assign the name
automatically.
+ --runall=RUNALL Run the specified task for any recipe in the taskgraph
+ of the specified target (even if it wouldn't otherwise
+ have run).
+ --runonly=RUNONLY Run only the specified task within the taskgraph of
+ the specified targets (and any task dependencies those
+ tasks may have).
</literallayout>
</para>
</section>
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 0cfa53d..b4fc64e 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
@@ -2132,6 +2132,8 @@
<listitem><para>
<filename>bb.event.BuildStarted()</filename>:
Fired when a new build starts.
+ BitBake fires multiple "BuildStarted" events (one per configuration)
+ when multiple configuration (multiconfig) is enabled.
</para></listitem>
<listitem><para>
<filename>bb.build.TaskStarted()</filename>:
@@ -2650,47 +2652,70 @@
</para>
<para>
- This list is a place holder of content existed from previous work
- on the manual.
- Some or all of it probably needs integrated into the subsections
- that make up this section.
- For now, I have just provided a short glossary-like description
- for each variable.
- Ultimately, this list goes away.
+ These checksums are stored in
+ <link linkend='var-STAMP'><filename>STAMP</filename></link>.
+ You can examine the checksums using the following BitBake command:
+ <literallayout class='monospaced'>
+ $ bitbake-dumpsigs
+ </literallayout>
+ This command returns the signature data in a readable format
+ that allows you to examine the inputs used when the
+ OpenEmbedded build system generates signatures.
+ For example, using <filename>bitbake-dumpsigs</filename>
+ allows you to examine the <filename>do_compile</filename>
+ task's “sigdata” for a C application (e.g.
+ <filename>bash</filename>).
+ Running the command also reveals that the “CC” variable is part of
+ the inputs that are hashed.
+ Any changes to this variable would invalidate the stamp and
+ cause the <filename>do_compile</filename> task to run.
+ </para>
+
+ <para>
+ The following list describes related variables:
<itemizedlist>
- <listitem><para><filename>STAMP</filename>:
- The base path to create stamp files.</para></listitem>
- <listitem><para><filename>STAMPCLEAN</filename>
- Again, the base path to create stamp files but can use wildcards
- for matching a range of files for clean operations.
- </para></listitem>
- <listitem><para><filename>BB_STAMP_WHITELIST</filename>
- Lists stamp files that are looked at when the stamp policy
- is "whitelist".
- </para></listitem>
- <listitem><para><filename>BB_STAMP_POLICY</filename>
- Defines the mode for comparing timestamps of stamp files.
- </para></listitem>
- <listitem><para><filename>BB_HASHCHECK_FUNCTION</filename>
+ <listitem><para>
+ <link linkend='var-BB_HASHCHECK_FUNCTION'><filename>BB_HASHCHECK_FUNCTION</filename></link>:
Specifies the name of the function to call during
the "setscene" part of the task's execution in order
to validate the list of task hashes.
</para></listitem>
- <listitem><para><filename>BB_SETSCENE_VERIFY_FUNCTION2</filename>
- Specifies a function to call that verifies the list of
- planned task execution before the main task execution
- happens.
- </para></listitem>
- <listitem><para><filename>BB_SETSCENE_DEPVALID</filename>
+ <listitem><para>
+ <link linkend='var-BB_SETSCENE_DEPVALID'><filename>BB_SETSCENE_DEPVALID</filename></link>:
Specifies a function BitBake calls that determines
whether BitBake requires a setscene dependency to
be met.
</para></listitem>
- <listitem><para><filename>BB_TASKHASH</filename>
+ <listitem><para>
+ <link linkend='var-BB_SETSCENE_VERIFY_FUNCTION2'><filename>BB_SETSCENE_VERIFY_FUNCTION2</filename></link>:
+ Specifies a function to call that verifies the list of
+ planned task execution before the main task execution
+ happens.
+ </para></listitem>
+ <listitem><para>
+ <link linkend='var-BB_STAMP_POLICY'><filename>BB_STAMP_POLICY</filename></link>:
+ Defines the mode for comparing timestamps of stamp files.
+ </para></listitem>
+ <listitem><para>
+ <link linkend='var-BB_STAMP_WHITELIST'><filename>BB_STAMP_WHITELIST</filename></link>:
+ Lists stamp files that are looked at when the stamp policy
+ is "whitelist".
+ </para></listitem>
+ <listitem><para>
+ <link linkend='var-BB_TASKHASH'><filename>BB_TASKHASH</filename></link>:
Within an executing task, this variable holds the hash
of the task as returned by the currently enabled
signature generator.
</para></listitem>
+ <listitem><para>
+ <link linkend='var-STAMP'><filename>STAMP</filename></link>:
+ The base path to create stamp files.
+ </para></listitem>
+ <listitem><para>
+ <link linkend='var-STAMPCLEAN'><filename>STAMPCLEAN</filename></link>:
+ Again, the base path to create stamp files but can use wildcards
+ for matching a range of files for clean operations.
+ </para></listitem>
</itemizedlist>
</para>
</section>
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 d89e123..0313359 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
@@ -78,7 +78,7 @@
</para>
<para>
- In OpenEmbedded Core, <filename>ASSUME_PROVIDED</filename>
+ In OpenEmbedded-Core, <filename>ASSUME_PROVIDED</filename>
mostly specifies native tools that should not be built.
An example is <filename>git-native</filename>, which
when specified allows for the Git binary from the host to
@@ -964,7 +964,7 @@
Allows you to extend a recipe so that it builds variants
of the software.
Some examples of these variants for recipes from the
- OpenEmbedded Core metadata are "natives" such as
+ OpenEmbedded-Core metadata are "natives" such as
<filename>quilt-native</filename>, which is a copy of
Quilt built to run on the build system; "crosses" such
as <filename>gcc-cross</filename>, which is a compiler
@@ -980,7 +980,7 @@
amount of code, it usually is as simple as adding the
variable to your recipe.
Here are two examples.
- The "native" variants are from the OpenEmbedded Core
+ The "native" variants are from the OpenEmbedded-Core
metadata:
<literallayout class='monospaced'>
BBCLASSEXTEND =+ "native nativesdk"
@@ -2089,6 +2089,16 @@
</glossdef>
</glossentry>
+ <glossentry id='var-REPODIR'><glossterm>REPODIR</glossterm>
+ <glossdef>
+ <para>
+ The directory in which a local copy of a
+ <filename>google-repo</filename> directory is stored
+ when it is synced.
+ </para>
+ </glossdef>
+ </glossentry>
+
<glossentry id='var-RPROVIDES'><glossterm>RPROVIDES</glossterm>
<glossdef>
<para>
diff --git a/import-layers/yocto-poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual.xml b/import-layers/yocto-poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual.xml
index 4aef4e7..d793265 100644
--- a/import-layers/yocto-poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual.xml
+++ b/import-layers/yocto-poky/bitbake/doc/bitbake-user-manual/bitbake-user-manual.xml
@@ -56,7 +56,7 @@
-->
<copyright>
- <year>2004-2016</year>
+ <year>2004-2018</year>
<holder>Richard Purdie</holder>
<holder>Chris Larson</holder>
<holder>and Phil Blundell</holder>