ref-manual: Added new section to the 1.6 migration section plus some 1.5 edits.

Added a new section on "Matching Branch Requirement for Git Fetching"
into the BitBake section.  Plus, made some minor corrections to
some of the 1.5 sections.

(From yocto-docs rev: 326a8009ca0bef0a4686510bb521010d8f58ac81)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

bitbake/doc/Makefile

@@ -18,21 +18,21 @@
 #
 # Examples:
 #
-#     make DOC=user-manual
-#     make pdf DOC=user-manual
+#     make DOC=bitbake-user-manual
+#     make pdf DOC=bitbake-user-manual
 #
 # The first example generates the HTML and PDF versions of the User Manual.
 # The second example generates the HTML version only of the User Manual.
 #
 
-ifeq ($(DOC),user-manual)
-XSLTOPTS = --stringparam html.stylesheet user-manual-style.css \
+ifeq ($(DOC),bitbake-user-manual)
+XSLTOPTS = --stringparam html.stylesheet bitbake-user-manual-style.css \
            --stringparam  chapter.autolabel 1 \
            --stringparam  section.autolabel 1 \
            --stringparam  section.label.includes.component.label 1 \
            --xinclude
 ALLPREQ = html pdf tarball
-TARFILES = user-manual-style.css user-manual.html user-manual.pdf figures/bitbake-title.png
+TARFILES = bitbake-user-manual-style.css bitbake-user-manual.html bitbake-user-manual.pdf figures/bitbake-title.png
 MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf
 FIGURES = figures
 STYLESHEET = $(DOC)/*.css
@@ -48,7 +48,7 @@ XSL_XHTML_URI = $(XSL_BASE_URI)/xhtml/docbook.xsl
 all: $(ALLPREQ)
 
 pdf:
-ifeq ($(DOC),user-manual)
+ifeq ($(DOC),bitbake-user-manual)
 	@echo " "
 	@echo "********** Building."$(DOC)
 	@echo " "
@@ -56,7 +56,7 @@ ifeq ($(DOC),user-manual)
 endif
 
 html:
-ifeq ($(DOC),user-manual)
+ifeq ($(DOC),bitbake-user-manual)
 #       See http://www.sagehill.net/docbookxsl/HtmlOutput.html
 	@echo " "
 	@echo "******** Building "$(DOC)

bitbake/doc/README

@@ -8,7 +8,7 @@ Manual Organization
 
 Folders exist for individual manuals as follows:
 
-* user-manual      - The BitBake User Manual 
+* bitbake-user-manual      - The BitBake User Manual 
 
 Each folder is self-contained regarding content and figures.
 
@@ -28,7 +28,7 @@ For example, the following command run from the documentation directory
 creates an HTML and a PDF version of the BitBake User Manual.
 The DOC variable specifies the manual you are making:
 
-     $ make DOC=user-manual
+     $ make DOC=bitbake-user-manual
 
 template
 ========

bitbake/doc/bitbake-user-manual/bitbake-user-manual-execution.xml

@@ -1,7 +1,7 @@
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
 
-<chapter id="user-manual-execution">
+<chapter id="bitbake-user-manual-execution">
     <title>Execution</title>
 
     <para>
@@ -24,7 +24,7 @@
         </literallayout>
         For information on the BitBake command and its options,
         see
-        "<link linkend='user-manual-command'>The BitBake Command</link>"
+        "<link linkend='bitbake-user-manual-command'>The BitBake Command</link>"
         section.
     </para>
 

bitbake/doc/bitbake-user-manual/bitbake-user-manual-hello.xml

@@ -0,0 +1,506 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+
+<appendix id='hello-world-example'>
+    <title>Hello World Example</title>
+
+    <section id='bitbake-hello-world'>
+        <title>BitBake Hello World</title>
+
+        <para>
+            The simplest example commonly used to demonstrate any new
+            programming language or tool is the
+            "<ulink url="http://en.wikipedia.org/wiki/Hello_world_program">Hello World</ulink>"
+            example.
+            This appendix demonstrates, in tutorial form, Hello
+            World within the context of BitBake.
+            The tutorial describes how to create a new project
+            and the applicable metadata files necessary to allow
+            BitBake to build it.
+        </para>
+    </section>
+
+    <section id='example-obtaining-bitbake'>
+        <title>Obtaining BitBake</title>
+
+        <para>
+            See the
+            "<link linkend='obtaining-bitbake'>Obtaining BitBake</link>"
+            section for information on how to obtain BitBake.
+            Once you have the source code on your machine, the BitBake directory
+            appears as follows:
+            <literallayout class='monospaced'>
+     $ ls -al
+     total 100
+     drwxrwxr-x. 9 wmat wmat  4096 Jan 31 13:44 .
+     drwxrwxr-x. 3 wmat wmat  4096 Feb  4 10:45 ..
+     -rw-rw-r--. 1 wmat wmat   365 Nov 26 04:55 AUTHORS
+     drwxrwxr-x. 2 wmat wmat  4096 Nov 26 04:55 bin
+     drwxrwxr-x. 4 wmat wmat  4096 Jan 31 13:44 build
+     -rw-rw-r--. 1 wmat wmat 16501 Nov 26 04:55 ChangeLog
+     drwxrwxr-x. 2 wmat wmat  4096 Nov 26 04:55 classes
+     drwxrwxr-x. 2 wmat wmat  4096 Nov 26 04:55 conf
+     drwxrwxr-x. 3 wmat wmat  4096 Nov 26 04:55 contrib
+     -rw-rw-r--. 1 wmat wmat 17987 Nov 26 04:55 COPYING
+     drwxrwxr-x. 3 wmat wmat  4096 Nov 26 04:55 doc
+     -rw-rw-r--. 1 wmat wmat    69 Nov 26 04:55 .gitignore
+     -rw-rw-r--. 1 wmat wmat   849 Nov 26 04:55 HEADER
+     drwxrwxr-x. 5 wmat wmat  4096 Jan 31 13:44 lib
+     -rw-rw-r--. 1 wmat wmat   195 Nov 26 04:55 MANIFEST.in
+     -rwxrwxr-x. 1 wmat wmat  3195 Jan 31 11:57 setup.py
+     -rw-rw-r--. 1 wmat wmat  2887 Nov 26 04:55 TODO
+            </literallayout>
+        </para>
+
+        <para>
+            At this point, you should have BitBake cloned to
+            a directory that matches the previous listing except for
+            dates and user names.
+        </para>
+    </section>
+
+    <section id='setting-up-the-bitbake-environment'>
+        <title>Setting Up the BitBake Environment</title>
+
+        <para>
+            First, you need to be sure that you can run BitBake.
+            Set your working directory to where your local BitBake
+            files are and run the following command:
+            <literallayout class='monospaced'>
+     $ ./bin/bitbake --version
+     BitBake Build Tool Core version 1.23.0, bitbake version 1.23.0
+            </literallayout>
+            The console output tells you what version you are running.
+        </para>
+
+        <para>
+            The recommended method to run BitBake is from a directory of your
+            choice.
+            To be able to run BitBake from any directory, you need to add the
+            executable binary to your binary to your shell's environment
+            <filename>PATH</filename> variable.
+            First, look at your current <filename>PATH</filename> variable
+            by entering the following:
+            <literallayout class='monospaced'>
+     $ echo $PATH
+            </literallayout>
+            Next, add the directory location for the BitBake binary to the
+            <filename>PATH</filename>.
+            Here is an example that adds the
+            <filename>/home/scott-lenovo/bitbake/bin</filename> directory
+            to the front of the <filename>PATH</filename> variable:
+            <literallayout class='monospaced'>
+     $ export PATH=/home/scott-lenovo/bitbake/bin:$PATH
+            </literallayout>
+            You should now be able to enter the <filename>bitbake</filename>
+            command from the command line while working from any directory.
+        </para>
+    </section>
+
+    <section id='the-hello-world-example'>
+        <title>The Hello World Example</title>
+
+        <para>
+            The overall goal of this exercise is to build a
+            complete "Hello World" example utilizing task and layer
+            concepts.
+            Because this is how modern projects such as OpenEmbedded and
+            the Yocto Project utilize BitBake, the example
+            provides an excellent starting point for understanding
+            BitBake.
+        </para>
+
+        <para>
+            To help you understand how to use BitBake to build targets,
+            the example starts with nothing but the <filename>bitbake</filename>
+            command, which causes BitBake to fail and report problems.
+            The example progresses by adding pieces to the build to
+            eventually conclude with a working, minimal "Hello World"
+            example.
+        </para>
+
+        <para>
+            While every attempt is made to explain what is happening during
+            the example, the descriptions cannot cover everything.
+            You can find further information throughout this manual.
+            Also, you can actively participate in the
+            <ulink url='http://lists.openembedded.org/mailman/listinfo/bitbake-devel'></ulink>
+            discussion mailing list about the BitBake build tool.
+        </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="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>
+        </note>
+
+        <para>
+            As stated earlier, the goal of this example
+            is to eventually compile "Hello World".
+            However, it is unknown what BitBake needs and what you have
+            to provide in order to achieve that goal.
+            Recall that BitBake utilizes three types of metadata files:
+            <link linkend='configuration-files'>Configuration Files</link>,
+            <link linkend='classes'>Classes</link>, and
+            <link linkend='recipes'>Recipes</link>.
+            But where do they go?
+            How does BitBake find them?
+            BitBake's error messaging helps you answer these types of questions
+            and helps you better understand exactly what is going on.
+        </para>
+
+        <para>
+            Following is the complete "Hello World" example.
+        </para>
+
+        <orderedlist>
+            <listitem><para><emphasis>Create a Project Directory:</emphasis>
+                First, set up a directory for the "Hello World" project.
+                Here is how you can do so in your home directory:
+                <literallayout class='monospaced'>
+     $ mkdir ~/hello
+     $ cd ~/hello
+                </literallayout>
+                This is the directory that BitBake will use to do all of
+                its work.
+                You can use this directory to keep all the metafiles needed
+                by BitBake.
+                Having a project directory is a good way to isolate your
+                project.
+                </para></listitem>
+            <listitem><para><emphasis>Run Bitbake:</emphasis>
+                At this point, you have nothing but a project directory.
+                Run the <filename>bitbake</filename> command and see what
+                it does:
+                <literallayout class='monospaced'>
+     $ bitbake
+     The BBPATH variable is not set and bitbake did not
+     find a conf/bblayers.conf file in the expected location.
+     Maybe you accidentally invoked bitbake from the wrong directory?
+     DEBUG: Removed the following variables from the environment:
+     GNOME_DESKTOP_SESSION_ID, XDG_CURRENT_DESKTOP,
+     GNOME_KEYRING_CONTROL, DISPLAY, SSH_AGENT_PID, LANG, no_proxy,
+     XDG_SESSION_PATH, XAUTHORITY, SESSION_MANAGER, SHLVL,
+     MANDATORY_PATH, COMPIZ_CONFIG_PROFILE, WINDOWID, EDITOR,
+     GPG_AGENT_INFO, SSH_AUTH_SOCK, GDMSESSION, GNOME_KEYRING_PID,
+     XDG_SEAT_PATH, XDG_CONFIG_DIRS, LESSOPEN, DBUS_SESSION_BUS_ADDRESS,
+     _, XDG_SESSION_COOKIE, DESKTOP_SESSION, LESSCLOSE, DEFAULTS_PATH,
+     UBUNTU_MENUPROXY, OLDPWD, XDG_DATA_DIRS, COLORTERM, LS_COLORS
+                </literallayout>
+                The majority of this output is specific to environment variables
+                that are not directly relevant to BitBake.
+                However, the very first message regarding the
+                <filename>BBPATH</filename> variable and the
+                <filename>conf/bblayers.conf</filename> file
+                is relevant.</para>
+                <para>
+                When you run BitBake, it begins looking for metadata files.
+                The
+                <link linkend='var-BBPATH'><filename>BBPATH</filename></link>
+                variable is what tells BitBake where to look for those files.
+                <filename>BBPATH</filename> is not set and you need to set it.
+                Without <filename>BBPATH</filename>, Bitbake cannot
+                find any configuration files (<filename>.conf</filename>)
+                or recipe files (<filename>.bb</filename>) at all.
+                BitBake also cannot find the <filename>bitbake.conf</filename>
+                file.
+                </para></listitem>
+            <listitem><para><emphasis>Setting <filename>BBPATH</filename>:</emphasis>
+                For this example, you can set <filename>BBPATH</filename>
+                in the same manner that you set <filename>PATH</filename>
+                earlier in the appendix.
+                You should realize, though, that it is much more flexible to set the
+                <filename>BBPATH</filename> variable up in a configuration
+                file for each project.</para>
+                <para>From your shell, enter the following commands to set and
+                export the <filename>BBPATH</filename> variable:
+                <literallayout class='monospaced'>
+     $ BBPATH="&lt;projectdirectory&gt;"
+     $ export BBPATH
+                </literallayout>
+                Use your actual project directory in the command.
+                BitBake uses that directory to find the metadata it needs for
+                your project.
+                <note>
+                    When specifying your project directory, do not use the
+                    tilde ("~") character as BitBake does not expand that character
+                    as the shell would.
+                </note>
+                </para></listitem>
+            <listitem><para><emphasis>Run Bitbake:</emphasis>
+                Now that you have <filename>BBPATH</filename> defined, 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 173, in parse_config_file
+         return bb.parse.handle(fn, data, include)
+       File "/home/scott-lenovo/bitbake/lib/bb/parse/__init__.py", line 99, in handle
+         return h['handle'](fn, data, include)
+       File "/home/scott-lenovo/bitbake/lib/bb/parse/parse_py/ConfHandler.py", line 120, in handle
+         abs_fn = resolve_file(fn, data)
+       File "/home/scott-lenovo/bitbake/lib/bb/parse/__init__.py", line 117, in resolve_file
+         raise IOError("file %s not found in %s" % (fn, bbpath))
+     IOError: file conf/bitbake.conf not found in /home/scott-lenovo/hello
+
+     ERROR: Unable to parse conf/bitbake.conf: file conf/bitbake.conf not found in /home/scott-lenovo/hello
+                </literallayout>
+                This sample output shows that BitBake could not find the
+                <filename>conf/bitbake.conf</filename> file in the project
+                directory.
+                This file is the first thing BitBake must find in order
+                to build a target.
+                And, since the project directory for this example is
+                empty, you need to provide a <filename>conf/bitbake.conf</filename>
+                file.
+                </para></listitem>
+            <listitem><para><emphasis>Creating <filename>conf/bitbake.conf</filename>:</emphasis>
+                The <filename>conf/bitbake.conf</filename> includes a number of
+                configuration variables BitBake uses for metadata and recipe
+                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>,
+                see
+                <ulink url='http://hambedded.org/blog/2012/11/24/from-bitbake-hello-world-to-an-image/#an-overview-of-bitbakeconf'></ulink>
+                </para>
+                <para>Use the following commands to create the <filename>conf</filename>
+                directory in the project directory:
+                <literallayout class='monospaced'>
+     $ mkdir conf
+                </literallayout>
+                From within the <filename>conf</filename> directory, use
+                some editor to create the <filename>bitbake.conf</filename>
+                so that it contains the following:
+                <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}"
+                </literallayout>
+                The <filename>TMPDIR</filename> variable establishes a directory
+                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
+                <filename>hello/tmp</filename>.
+                <note><title>Tip</title>
+                    You can always safely delete the <filename>tmp</filename>
+                    directory in order to rebuild a BitBake target.
+                    The build process creates the directory for you
+                    when you run BitBake.
+                </note></para>
+                <para>For information about each of the other variables defined in this
+                example, click on the links to take you to the definitions in
+                the glossary.
+                </para></listitem>
+            <listitem><para><emphasis>Run Bitbake:</emphasis>
+                After making sure that the <filename>conf/bitbake.conf</filename>
+                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
+
+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.
+                You need to create that file next.
+                </para></listitem>
+            <listitem><para><emphasis>Creating <filename>classes/base.bbclass</filename>:</emphasis>
+                BitBake uses class files to provide common code and functionality.
+                The minimally required class for BitBake is the
+                <filename>classes/base.bbclass</filename> file.
+                The <filename>base</filename> class is implicitly inherited by
+                every recipe.
+                BitBake looks for the class in the <filename>classes</filename>
+                directory of the project (i.e <filename>hello/classes</filename>
+                in this example).
+                </para>
+                <para>Create the <filename>classes</filename> directory as follows:
+                <literallayout class='monospaced'>
+     $ cd $HOME/hello
+     $ mkdir classes
+                </literallayout>
+                Move to the <filename>classes</filename> directory and then
+                create the <filename>base.bbclass</filename> file by inserting
+                this single line:
+                <literallayout class='monospaced'>
+     addtask build
+                </literallayout>
+                The minimal task that BitBake runs is the
+                <filename>do_build</filename> task.
+                This is all the example needs in order to build the project.
+                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='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>
+                file exists, you can run the <filename>bitbake</filename>
+                command again:
+                <literallayout class='monospaced'>
+     $ bitbake
+     Nothing to do.  Use 'bitbake world' to build everything, or run 'bitbake --help' for usage information.
+                </literallayout>
+                BitBake is finally reporting no errors.
+                However, you can see that it really does not have anything
+                to do.
+                You need to create a recipe that gives BitBake something to do.
+                </para></listitem>
+            <listitem><para><emphasis>Creating a Layer:</emphasis>
+                While it is not really necessary for such a small example,
+                it is good practice to create a layer in which to keep your
+                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='http://hambedded.org/blog/2012/11/24/from-bitbake-hello-world-to-an-image/#adding-an-example-layer'></ulink>.
+                </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>
+                directory inside the layer.
+                Use these commands to set up the layer and the <filename>conf</filename>
+                directory:
+                <literallayout class='monospaced'>
+     $ cd $HOME
+     $ mkdir mylayer
+     $ cd mylayer
+     $ mkdir conf
+                </literallayout>
+                Move to the <filename>conf</filename> directory and create a
+                <filename>layer.conf</filename> file that has the following:
+                <literallayout class='monospaced'>
+     BBPATH .= ":${<link linkend='var-LAYERDIR'>LAYERDIR</link>}"
+
+     <link linkend='var-BBFILES'>BBFILES</link> += "${LAYERDIR}/*.bb"
+
+     <link linkend='var-BBFILE_COLLECTIONS'>BBFILE_COLLECTIONS</link> += "mylayer"
+     <link linkend='var-BBFILE_PATTERN'>BBFILE_PATTERN_mylayer</link> := "^${LAYERDIR}/"
+                </literallayout>
+                For information on these variables, click the links
+                to go to the definitions in the glossary.</para>
+                <para>You need to create the recipe file next.
+                Inside your layer at the top-level, use an editor and create
+                a recipe file named <filename>printhello.bb</filename> that
+                has the following:
+                <literallayout class='monospaced'>
+     <link linkend='var-DESCRIPTION'>DESCRIPTION</link> = "Prints Hello World"
+     <link linkend='var-PN'>PN</link> = 'printhello'
+     <link linkend='var-PV'>PV</link> = '1'
+
+     python do_build() {
+        bb.plain("********************");
+        bb.plain("*                  *");
+        bb.plain("*  Hello, World!   *");
+        bb.plain("*                  *");
+        bb.plain("********************");
+     }
+                </literallayout>
+                The recipe file simply provides a description of the
+                recipe, the name, version, and the <filename>do_build</filename>
+                task, which prints out "Hello World" to the console.
+                For more information on these variables, follow the links
+                to the glossary.
+                </para></listitem>
+            <listitem><para><emphasis>Run Bitbake With a Target:</emphasis>
+                Now that a BitBake target exists, run the command and provide
+                that target:
+                <literallayout class='monospaced'>
+     $ cd $HOME/hello
+     $ bitbake printhello
+     ERROR: no recipe files to build, check your BBPATH and BBFILES?
+
+     Summary: There was 1 ERROR message shown, returning a non-zero exit code.
+                </literallayout>
+                We have created the layer with the recipe and the layer
+                configuration file but it still seems that BitBake cannot
+                find the recipe.
+                BitBake needs a <filename>conf/bblayers.conf</filename> that
+                lists the layers for the project.
+                Without this file, BitBake cannot find the recipe.
+                </para></listitem>
+            <listitem><para><emphasis>Creating <filename>conf/bblayers.conf</filename>:</emphasis>
+                BitBake uses the <filename>conf/bblayers.conf</filename> file
+                to locate layers needed for the project.
+                This file must reside in the <filename>conf</filename> directory
+                of the project (i.e. <filename>hello/conf</filename> for this
+                example).</para>
+                <para>Set your working directory to the <filename>hello/conf</filename>
+                directory and then create the <filename>bblayers.conf</filename>
+                file so that it contains the following:
+                <literallayout class='monospaced'>
+     BBLAYERS ?= " \
+       /home/&lt;you&gt;/mylayer \
+       "
+                </literallayout>
+                You need to provide your own information for
+                <filename>you</filename> in the file.
+                </para></listitem>
+            <listitem><para><emphasis>Run Bitbake With a Target:</emphasis>
+                Now that you have supplied the <filename>bblayers.conf</filename>
+                file, run the <filename>bitbake</filename> command and provide
+                the target:
+                <literallayout class='monospaced'>
+     $ bitbake printhello
+     Parsing recipes: 100% |##################################################################################|
+     Time: 00:00:00
+     Parsing of 1 .bb files complete (0 cached, 1 parsed). 1 targets, 0 skipped, 0 masked, 0 errors.
+     NOTE: Resolving any missing task queue dependencies
+     NOTE: Preparing runqueue
+     NOTE: Executing RunQueue Tasks
+     ********************
+     *                  *
+     *  Hello, World!   *
+     *                  *
+     ********************
+     NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be rerun and all succeeded.
+                </literallayout>
+                BitBake finds the <filename>printhello</filename> recipe and
+                successfully runs the task.
+                <note>
+                    After the first execution, re-running
+                    <filename>bitbake printhello</filename> again will not
+                    result in a BitBake run that prints the same console
+                    output.
+                    The reason for this is that the first time the
+                    <filename>printhello.bb</filename> recipe's
+                    <filename>do_build</filename> task executes
+                    successfully, BitBake writes a stamp file for the task.
+                    Thus, the next time you attempt to run the task
+                    using that same <filename>bitbake</filename> command,
+                    BitBake notices the stamp and therefore determines
+                    that the task does not need to be re-run.
+                    If you delete the <filename>tmp</filename> directory
+                    or run <filename>bitbake -c clean printhello</filename>
+                    and then re-run the build, the "Hello, World!" message will
+                    be printed again.
+                </note>
+                </para></listitem>
+        </orderedlist>
+    </section>
+</appendix>

bitbake/doc/bitbake-user-manual/bitbake-user-manual-intro.xml

@@ -1,7 +1,7 @@
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
     "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
 
-<chapter id="user-manual-intro">
+<chapter id="bitbake-user-manual-intro">
     <title>Overview</title>
 
     <para>
@@ -417,7 +417,7 @@
         </para>
     </section>
 
-    <section id="user-manual-command">
+    <section id="bitbake-user-manual-command">
         <title>The BitBake Command</title>
 
         <para>

bitbake/doc/bitbake-user-manual/bitbake-user-manual-metadata.xml

@@ -1,7 +1,7 @@
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
 
-<chapter id="user-manual-metadata">
+<chapter id="bitbake-user-manual-metadata">
     <title>Syntax and Operators</title>
 
     <para>
@@ -301,6 +301,29 @@
                 variable becoming the current date.
             </para>
         </section>
+
+        <section id='providing-pathnames'>
+            <title>Providing Pathnames</title>
+
+            <para>
+                When specifying pathnames for use with BitBake,
+                do not use the tilde ("~") character as a shortcut
+                for your home directory.
+                Doing so might cause BitBake to not recognize the
+                path since BitBake does not expand this character in
+                the same way a shell would.
+            </para>
+
+            <para>
+                Instead, provide a fuller path as the following
+                example illustrates:
+                <literallayout class='monospaced'>
+     BBLAYERS ?= " \
+       /home/scott-lenovo/LayerA \
+       "
+                </literallayout>
+            </para>
+        </section>
     </section>
 
     <section id='conditional-syntax-overrides'>
@@ -683,7 +706,7 @@
         <para>
             As with most languages, functions are the building blocks that
             are used to build up operations into tasks.
-            BitBake supports three types of functions:
+            BitBake supports these types of functions:
             <itemizedlist>
                 <listitem><para><emphasis>Shell Functions:</emphasis>
                     Functions written in shell script and executed either
@@ -697,6 +720,10 @@
                 <listitem><para><emphasis>Python Functions:</emphasis>
                     Functions written in Python and executed by Python.
                     </para></listitem>
+                <listitem><para><emphasis>Anonymous Python Functions:</emphasis>
+                    Python functions executed automatically during
+                    parsing.
+                    </para></listitem>
             </itemizedlist>
             Regardless of the type of function, you can only
             define them in class (<filename>.bbclass</filename>)
@@ -793,36 +820,71 @@
             </para>
         </section>
 
-        <section id='automatically-mapping-functions-within-the-context-of-a-class'>
-            <title>Automatically Mapping Functions Within the Context of a Class</title>
+        <section id='anonymous-python-functions'>
+            <title>Anonymous Python Functions</title>
+
+            <para>
+                Sometimes it is useful to run some code during
+                parsing to set variables or to perform other operations
+                programmatically.
+                To do this, you can define an anonymous Python function.
+                Here is an example that conditionally sets a
+                variable based on the value of another variable:
+                <literallayout class='monospaced'>
+     python __anonymous () {
+         if d.getVar('SOMEVAR', True) == 'value':
+             d.setVar('ANOTHERVAR', 'value2')
+     }
+                </literallayout>
+                The "__anonymous" function name is optional, so the
+                following example is functionally equivalent to the above:
+                <literallayout class='monospaced'>
+     python () {
+         if d.getVar('SOMEVAR', True) == 'value':
+             d.setVar('ANOTHERVAR', 'value2')
+     }
+                </literallayout>
+                Because unlike other Python functions anonymous
+                Python functions are executed during parsing, the
+                "d" variable within an anonymous Python function represents
+                the datastore for the entire recipe.
+                Consequently, you can set variable values here and
+                those values can be picked up by other functions.
+            </para>
+        </section>
+
+        <section id='flexible-inheritance-for-class-functions'>
+            <title>Flexible Inheritance for Class Functions</title>
 
             <para>
                 Through coding techniques and the use of
                 <filename>EXPORT_FUNCTIONS</filename>, BitBake supports
-                automatic mapping for functions within the context of
-                a class.
+                exporting a function from a class such that the
+                class function appears as the default implementation
+                of the function, but can still be called if a recipe
+                inheriting the class needs to define its own version of
+                the function.
             </para>
 
             <para>
-                To understand the benefits of this feature, consider the basic scenario
-                where a class defines a function and your recipe inherits the class.
-                In this basic scenario, your recipe has access to the function in the
-                class by way of inheritance and can freely call and use the function
-                as defined in the class.
-                However, if you need to have a modified version of that function
-                in your recipe you are limited to using either your modified version
-                of the function or using "prepend_" or "_append" operators to add
-                code to be executed before or after the original function in the
-                class.
-                Your recipe cannot use both versions of the fucntion.
+                To understand the benefits of this feature, consider
+                the basic scenario where a class defines a task function
+                and your recipe inherits the class.
+                In this basic scenario, your recipe inherits the task
+                function as defined in the class.
+                If desired, your recipe can add to the start and end of the
+                function by using the "_prepend" or "_append" operations
+                respectively, or it can redefine the function completely.
+                However, if it redefines the function, there is
+                no means  for it to call the class version of the function.
+                <filename>EXPORT_FUNCTIONS</filename> provides a mechanism
+                that enables the recipe's version of the function to call
+                the original version of the function.
             </para>
 
             <para>
-                Function mapping allows you to access both your custom function
-                function that is defined in the recipe and the original function that
-                is defined in the class.
-                You have this access all from within your recipe.
-                To accomplish this, you need some things in place:
+                To make use of this technique, you need the following
+                things in place:
                 <itemizedlist>
                     <listitem><para>
                         The class needs to define the function as follows:
@@ -853,12 +915,24 @@
                     <listitem><para>
                         You need to call the function appropriately from within your
                         recipe.
-                        Continuing with the same example,
-                        your recipe would call the <filename>do_foo</filename> function
-                        from the recipe by referring to it as
-                        <filename>bar_do_foo</filename>.
-                        To call your modified version of the function as defined in your
-                        recipe, call it as <filename>do_foo</filename>.
+                        Continuing with the same example, if your recipe
+                        needs to call the class version of the function,
+                        it should call <filename>bar_do_foo</filename>.
+                        Assuming <filename>do_foo</filename> was a shell function
+                        and <filename>EXPORT_FUNCTIONS</filename> was used as above,
+                        the recipe's function could conditionally call the
+                        class version of the function as follows:
+                        <literallayout class='monospaced'>
+     do_foo() {
+             if [ somecondition ] ; then
+                     bar_do_foo
+             else
+                     # Do something else
+             fi
+     }
+                        </literallayout>
+                        To call your modified version of the function as defined
+                        in your recipe, call it as <filename>do_foo</filename>.
                         </para></listitem>
                 </itemizedlist>
                 With these conditions met, your single recipe

bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.xml

@@ -1080,20 +1080,21 @@
                     (<filename>.conf</filename>) files.
                     This variable is analogous to the
                     <filename>PATH</filename> variable.
-                    <note>
-                        If you run BitBake from a directory outside of the
-                        build directory,
-                        you must be sure to set
-                        <filename>BBPATH</filename> to point to the
-                        build directory.
-                        Set the variable as you would any environment variable
-                        and then run BitBake:
-                        <literallayout class='monospaced'>
-     $ BBPATH = "&lt;build_directory&gt;"
+                </para>
+
+                <para>
+                    If you run BitBake from a directory outside of the
+                    build directory,
+                    you must be sure to set
+                    <filename>BBPATH</filename> to point to the
+                    build directory.
+                    Set the variable as you would any environment variable
+                    and then run BitBake:
+                    <literallayout class='monospaced'>
+     $ BBPATH="&lt;build_directory&gt;"
      $ export BBPATH
      $ bitbake &lt;target&gt;
-                        </literallayout>
-                    </note>
+                    </literallayout>
                 </para>
             </glossdef>
         </glossentry>

bitbake/doc/bitbake-user-manual/bitbake-user-manual.xml

@@ -73,16 +73,16 @@
         </legalnotice>
     </bookinfo>
 
-    <xi:include href="user-manual-intro.xml"/>
+    <xi:include href="bitbake-user-manual-intro.xml"/>
 
-    <xi:include href="user-manual-execution.xml"/>
+    <xi:include href="bitbake-user-manual-execution.xml"/>
 
-    <xi:include href="user-manual-metadata.xml"/>
+    <xi:include href="bitbake-user-manual-metadata.xml"/>
 
-    <xi:include href="user-manual-fetching.xml"/>
+    <xi:include href="bitbake-user-manual-fetching.xml"/>
 
-    <xi:include href="user-manual-ref-variables.xml"/>
+    <xi:include href="bitbake-user-manual-ref-variables.xml"/>
 
-    <xi:include href="user-manual-hello.xml"/>
+    <xi:include href="bitbake-user-manual-hello.xml"/>
 
 </book>

bitbake/doc/template/titlepage.templates.xml

@@ -144,7 +144,7 @@
 
 # If you leave this block of code in then the text title in the
 # <title>BitBake User Manual</title> statement of the
-# user-manual.xml file is rendered on the title page below the
+# bitbake-user-manual.xml file is rendered on the title page below the
 # image.  Commenting it out gets it out of there yet allows it
 # to be retained in the tab text for the HTML version of the
 # manual.
@@ -176,7 +176,7 @@
 <!--
 # If you leave this block of code in then the text title in the
 # <title>BitBake User Manual</title> statement of the
-# user-manual.xml file is rendered on the title page below the
+# bitbake-user-manual.xml file is rendered on the title page below the
 # image.  Commenting it out gets it out of there yet allows it
 # to be retained in the tab text for the HTML version of the
 # manual.

bitbake/doc/user-manual/user-manual-hello.xml

@@ -1,334 +0,0 @@
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
-
-<appendix id='hello-world-example'>
-    <title>Hello World Example</title>
-
-    <section id='bitbake-hello-world'>
-        <title>BitBake Hello World</title>
-
-        <para>
-            The simplest example commonly used to demonstrate any new
-            programming language or tool is the
-            <ulink url="http://en.wikipedia.org/wiki/Hello_world_program">Hello World</ulink>
-            example.
-            This appendix demonstrates, in tutorial form, Hello
-            World within the context of BitBake.
-            The tutorial describes how to create a new Project
-            and the applicable metadata files necessary to allow
-            BitBake to build it.
-        </para>
-    </section>
-
-    <section id='example-obtaining-bitbake'>
-        <title>Obtaining BitBake</title>
-
-        <para>
-            See the
-            "<link linkend='obtaining-bitbake'>Obtaining BitBake</link>"
-            section for information on how to obtain BitBake.
-            Once you have the source code on your machine, the BitBake directory
-            appears as follows:
-            <literallayout class='monospaced'>
-     $ ls -al
-     total 100
-     drwxrwxr-x. 9 wmat wmat  4096 Jan 31 13:44 .
-     drwxrwxr-x. 3 wmat wmat  4096 Feb  4 10:45 ..
-     -rw-rw-r--. 1 wmat wmat   365 Nov 26 04:55 AUTHORS
-     drwxrwxr-x. 2 wmat wmat  4096 Nov 26 04:55 bin
-     drwxrwxr-x. 4 wmat wmat  4096 Jan 31 13:44 build
-     -rw-rw-r--. 1 wmat wmat 16501 Nov 26 04:55 ChangeLog
-     drwxrwxr-x. 2 wmat wmat  4096 Nov 26 04:55 classes
-     drwxrwxr-x. 2 wmat wmat  4096 Nov 26 04:55 conf
-     drwxrwxr-x. 3 wmat wmat  4096 Nov 26 04:55 contrib
-     -rw-rw-r--. 1 wmat wmat 17987 Nov 26 04:55 COPYING
-     drwxrwxr-x. 3 wmat wmat  4096 Nov 26 04:55 doc
-     -rw-rw-r--. 1 wmat wmat    69 Nov 26 04:55 .gitignore
-     -rw-rw-r--. 1 wmat wmat   849 Nov 26 04:55 HEADER
-     drwxrwxr-x. 5 wmat wmat  4096 Jan 31 13:44 lib
-     -rw-rw-r--. 1 wmat wmat   195 Nov 26 04:55 MANIFEST.in
-     -rwxrwxr-x. 1 wmat wmat  3195 Jan 31 11:57 setup.py
-     -rw-rw-r--. 1 wmat wmat  2887 Nov 26 04:55 TODO
-            </literallayout>
-        </para>
-
-        <para>
-            At this point, you should have BitBake cloned to
-            a directory that matches the previous listing except for
-            dates and user names.
-        </para>
-    </section>
-
-    <section id='setting-up-the-bitbake-environment'>
-        <title>Setting Up the BitBake Environment</title>
-
-        <para>
-            The recommended method to run BitBake is from a directory of your
-            choice.
-            The directory can be within your home directory or in
-            <filename>/usr/local</filename>,
-            depending on your preference.
-        </para>
-
-        <para>
-            First, run BitBake to make sure it's working.
-            From the BitBake source code directory, issue the following command:
-            <literallayout class='monospaced'>
-     $ ./bin/bitbake --version
-     BitBake Build Tool Core version 1.19.0, bitbake version
-     1.19.0
-            </literallayout>
-            You are now ready to use BitBake.
-        </para>
-
-        <para>
-            A final step to make development easier is to add the executable
-            binary to your environment <filename>PATH</filename>.
-            First, look at your current <filename>PATH</filename> variable
-            by entering the following:
-            <literallayout class='monospaced'>
-     $ echo $PATH
-            </literallayout>
-            Next, add the directory location for the BitBake binary to the
-            <filename>PATH</filename> using this form:
-            <literallayout class='monospaced'>
-     $ export PATH=&lt;path-to-bitbake-executable&gt;:$PATH
-            </literallayout>
-            This will add the directory to the beginning of your
-            <filename>PATH</filename> environment variable.
-            You should now be able to enter the <filename>bitbake</filename>
-            command at the command line to run BitBake.
-        </para>
-
-        <para>
-            For a more permanent solution assuming you are running the BASH
-            shell, edit <filename>~/.bashrc</filename> and add the following to the end
-            of that file:
-            <literallayout class='monospaced'>
-     PATH=&lt;path-to-bitbake-executable&gt;:$PATH
-            </literallayout>
-        </para>
-
-        <para>
-            If you're a Vim user, you will find useful
-            Vim configuration contributions in the
-            <filename>contrib/vim</filename> directory.
-            Copy the files from that directory to your
-            <filename>/home/yourusername/.vim</filename>
-            directory.
-            If that directory does not exist, create it, and then
-            restart Vim.
-        </para>
-    </section>
-
-    <section id='the-hello-world-example'>
-        <title>The Hello World Example</title>
-
-        <para>
-            The following example leaps directly into how BitBake
-            works.
-            While every attempt is made to explain what is happening,
-            not everything can be covered.
-            You can find further information in the
-            "<link linkend='user-manual-metadata'>Syntax and Operators</link>"
-            chapter.
-        </para>
-
-        <para>
-            The overall goal of this exercise is to build a
-            complete "Hello World" example utilizing task and layer
-            concepts.
-            This is how modern projects such as OpenEmbedded and
-            the Yocto Project utilize BitBake, therefore it
-            provides an excellent starting point for understanding
-            BitBake.
-        </para>
-
-        <para>
-            It should be noted that this chapter was inspired by
-            and draws heavily from several sources:
-            <itemizedlist>
-                <listitem><para>
-                    <ulink href="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 href="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>
-        </para>
-
-        <section id='a-reverse-walk-through'>
-            <title>A Reverse Walk-Through</title>
-
-            <para>
-                A good way to understand anything is to walk through the steps
-                that take you to where you want to be and observe first
-                principles.
-                BitBake allows us to do this through the
-                <filename>-D</filename> or <filename>Debug</filename>
-                command-line parameter.
-            </para>
-
-            <para>
-                The goal is to eventually compile a "Hello World" example.
-                However, it is unknown what is needed to achieve that goal.
-                Recall that BitBake utilizes three types of metadata files:
-                <link linkend='configuration-files'>Configuration Files</link>,
-                <link linkend='classes'>Classes</link>, and
-                <link linkend='recipes'>Recipes</link>.
-                But where do they go?
-                How does BitBake find them?
-                BitBake's error messaging helps you answer these types of questions
-                and helps you better understand exactly what is going on.
-            </para>
-
-            <para>
-                First, set up a directory for the "Hello World" project.
-                Here is how you can do so in your home directory:
-                <literallayout class='monospaced'>
-     $ mkdir ~/dev/hello &amp;&amp; cd ~/dev/hello
-                </literallayout>
-                Within this new, empty directory, run BitBake with
-                debugging output and see what happens:
-                <literallayout class='monospaced'>
-     $ bitbake -DDD
-     The BBPATH variable is not set
-     DEBUG: Removed the following variables from the environment:
-     GNOME_DESKTOP_SESSION_ID, LESSOPEN, WINDOWID,
-     GNOME_KEYRING_CONTROL, DISPLAY, SSH_AGENT_PID, LANG,
-     XDG_SESSION_PATH, XAUTHORITY, LANGUAGE, SESSION_MANAGER,
-     SHLVL, MANDATORY_PATH, COMPIZ_CONFIG_PROFILE, TEXTDOMAIN,
-     GPG_AGENT_INFO, SSH_AUTH_SOCK, XDG_RUNTIME_DIR,
-     COMPIZ_BIN_PATH, GDMSESSION, DEFAULTS_PATH, TEXTDOMAINDIR,
-     XDG_SEAT_PATH, XDG_CONFIG_DIRS, XDG_CURRENT_DESKTOP,
-     DBUS_SESSION_BUS_ADDRESS, _, XDG_SESSION_COOKIE,
-     DESKTOP_SESSION, LESSCLOSE, GNOME_KEYRING_PID,
-     UBUNTU_MENUPROXY, OLDPWD, GTK_MODULES, XDG_DATA_DIRS,
-     COLORTERM, LS_COLORS
-                </literallayout>
-                The majority of this output is specific to environment variables
-                that are not directly relevant to BitBake.
-                However, the very first message
-                "<filename>The BBPATH variable is not set</filename>"
-                is relevant and you need to rectify it by setting
-                <link linkend='var-BBPATH'><filename>BBPATH</filename></link>.
-            </para>
-
-            <para>
-                When you run BitBake, it begins looking for metadata files.
-                The <filename>BBPATH</filename> variable is what tells
-                BitBake where to look.
-                You could set <filename>BBPATH</filename> in the same manner
-                that you set <filename>PATH</filename> as shown earlier.
-                However, it is much more flexible to set the
-                <link linkend='var-BBPATH'><filename>BBPATH</filename></link>
-                variable for each project.
-            </para>
-
-            <para>
-                Without <filename>BBPATH</filename>, Bitbake cannot
-                find any configuration files (<filename>.conf</filename>)
-                or recipe files (<filename>.bb</filename>) at all.
-                BitBake also cannot find the <filename>bitbake.conf</filename>
-                file.
-            </para>
-
-            <para>
-                It is standard practice to organize the project's directory tree
-                to include both a <filename>conf/</filename> and
-                <filename>classes/</filename> directory.
-                You need to add those directories to your project:
-                <literallayout class='monospaced'>
-     $ mkdir conf classes
-                </literallayout>
-                Once those directories are in place, you can copy the
-                sample configuration files provided in the
-                BitBake source tree to their appropriate directories.
-                First, change to the BitBake source tree directory and
-                then copy the directories:
-                <literallayout class='monospaced'>
-     cp conf/bitbake.conf ~/dev/hello/conf/
-     cp classes/base.bbclass ~/dev/hello/classes/
-                </literallayout>
-                At this point your project directory structure should look like
-                the following:
-               <literallayout class='monospaced'>
-     ~/dev/hello$ tree
-     .
-     |-- classes
-     |   +-- base.bbclass
-     +-- conf
-     +-- bitbake.conf
-                </literallayout>
-            </para>
-
-            <para>
-                Once you have copied these files into your project, you
-                can now get back to resolving the <filename>BBPATH</filename>
-                issue.
-            </para>
-
-            <para>
-                The first configuration file that BitBake looks for is always
-                <filename>bblayers.conf</filename>.
-                With this knowledge, you know that to resolve your
-                <filename>BBPATH</filename> error you can add a
-                <filename>conf/bblayers.conf</filename> file to the
-                project source tree and populate it with the
-                <filename>BBPATH</filename> variable declaration.
-            </para>
-
-            <para>
-                From your project source tree:
-                <literallayout class='monospaced'>
-     $ vim conf/bblayers.conf
-                </literallayout>
-                Now add the following to the empty
-                <filename>bblayers.conf</filename> file:
-                <literallayout class='monospaced'>
-     BBPATH := "${TOPDIR}"
-                </literallayout>
-            </para>
-
-            <para>
-                Now, from the root of your project directory, run BitBake
-                again and see what happens:
-                <literallayout class='monospaced'>
-     $ bitbake -DDD
-     Nothing to do.  Use 'bitbake world' to build everything, or run
-     'bitbake --help' for usage information.
-     DEBUG: Removed the following variables from the environment:
-     GNOME_DESKTOP_SESSION_ID, LESSOPEN, WINDOWID,
-     GNOME_KEYRING_CONTROL, DISPLAY, SSH_AGENT_PID, LANG,
-     XDG_SESSION_PATH, XAUTHORITY, LANGUAGE, SESSION_MANAGER,
-     SHLVL, MANDATORY_PATH, COMPIZ_CONFIG_PROFILE, TEXTDOMAIN,
-     GPG_AGENT_INFO, SSH_AUTH_SOCK, XDG_RUNTIME_DIR,
-     COMPIZ_BIN_PATH, GDMSESSION, DEFAULTS_PATH, TEXTDOMAINDIR,
-     XDG_SEAT_PATH, XDG_CONFIG_DIRS, XDG_CURRENT_DESKTOP,
-     DBUS_SESSION_BUS_ADDRESS, _, XDG_SESSION_COOKIE,
-     DESKTOP_SESSION, LESSCLOSE, GNOME_KEYRING_PID, UBUNTU_MENUPROXY,
-     OLDPWD, GTK_MODULES, XDG_DATA_DIRS, COLORTERM, LS_COLORS
-     DEBUG: Found bblayers.conf (/home/wmat/dev/hello/conf/
-     bblayers.conf)
-     DEBUG: LOAD /home/wmat/dev/hello/conf/bblayers.conf
-     DEBUG: LOAD /home/wmat/dev/hello/conf/bitbake.conf
-     DEBUG: BB configuration INHERITs:0: inheriting /home/wmat/dev/
-     hello/classes/base.bbclass
-     DEBUG: BB /home/wmat/dev/hello/classes/base.bbclass: handle
-     (data, include)
-     DEBUG: LOAD /home/wmat/dev/hello/classes/base.bbclass
-     DEBUG: Clearing SRCREV cache due to cache policy of: clear
-     DEBUG: Using cache in '/home/wmat/dev/hello/tmp/cache/
-     local_file_checksum_cache.dat'
-     DEBUG: Using cache in '/home/wmat/dev/hello/tmp/cache/
-     bb_codeparser.dat'
-                </literallayout>
-                <note>
-                    From this point forward in the example, the environment
-                    variable removal messages are ignored and omitted.
-                    Examine the relevant DEBUG messages:
-                </note>
-            </para>
-        </section>
-    </section>
-</appendix>

documentation/adt-manual/adt-manual.xml

@@ -73,7 +73,7 @@
             </revision>
             <revision>
                 <revnumber>1.6</revnumber>
-                <date>Sometime 2014</date>
+                <date>April 2014</date>
                 <revremark>Released with the Yocto Project 1.6 Release.</revremark>
             </revision>
        </revhistory>

documentation/bsp-guide/bsp-guide.xml

@@ -85,7 +85,7 @@
             </revision>
             <revision>
                 <revnumber>1.6</revnumber>
-                <date>Sometime 2014</date>
+                <date>April 2014</date>
                 <revremark>Released with the Yocto Project 1.6 Release.</revremark>
             </revision>
         </revhistory>

documentation/bsp-guide/bsp.xml

@@ -83,7 +83,7 @@
             <para>
                 Some layers function as a layer to hold other BSP layers.
                 An example of this type of layer is the <filename>meta-intel</filename> layer.
-                The <filename>meta-intel</filename> layer contains over 10 individual BSP layers.
+                The <filename>meta-intel</filename> layer contains many individual BSP layers.
             </para>
 
             <para>
@@ -185,13 +185,10 @@
      meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay/xorg.conf
      meta-crownbay/recipes-kernel/
      meta-crownbay/recipes-kernel/linux/
-     meta-crownbay/recipes-kernel/linux/linux-yocto_3.4.bbappend
-     meta-crownbay/recipes-kernel/linux/linux-yocto_3.8.bbappend
-     meta-crownbay/recipes-kernel/linux/linux-yocto_3.10.bbappend
      meta-crownbay/recipes-kernel/linux/linux-yocto-dev.bbappend
-     meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.4.bbappend
-     meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.8.bbappend
      meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.10.bbappend
+     meta-crownbay/recipes-kernel/linux/linux-yocto_3.10.bbappend
+     meta-crownbay/recipes-kernel/linux/linux-yocto_3.14.bbappend
                 </literallayout>
             </para>
 
@@ -399,8 +396,7 @@
                 For example, the Crown Bay BSP <filename>crownbay.conf</filename> contains the
                 following statements:
                 <literallayout class='monospaced'>
-     require conf/machine/include/tune-atom.inc
-     require conf/machine/include/ia32-base.inc
+     require conf/machine/include/intel-core2-32-common.inc
      require conf/machine/include/meta-intel.inc
      require conf/machine/include/meta-intel-emgd.inc
                 </literallayout>
@@ -519,20 +515,32 @@
                 <literallayout class='monospaced'>
      FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
 
+
+     COMPATIBLE_MACHINE_crownbay = "crownbay"
+     KMACHINE_crownbay = "crownbay"
+     KBRANCH_crownbay = "standard/crownbay"
+     KERNEL_FEATURES_append_crownbay = " features/drm-emgd/drm-emgd-1.18 cfg/vesafb"
+
      COMPATIBLE_MACHINE_crownbay-noemgd = "crownbay-noemgd"
      KMACHINE_crownbay-noemgd = "crownbay"
      KBRANCH_crownbay-noemgd = "standard/crownbay"
      KERNEL_FEATURES_append_crownbay-noemgd = " cfg/vesafb"
 
-     LINUX_VERSION = "3.10.11"
+     LINUX_VERSION_crownbay = "3.10.35"
+     SRCREV_meta_crownbay = "b6e58b33dd427fe471f8827c83e311acdf4558a4"
+     SRCREV_machine_crownbay = "cee957655fe67826b2e827e2db41f156fa8f0cc4"
+     SRCREV_emgd_crownbay = "42d5e4548e8e79e094fa8697949eed4cf6af00a3"
 
-     SRCREV_meta_crownbay-noemgd = "285f93bf942e8f6fa678ffc6cc53696ed5400718"
-     SRCREV_machine_crownbay-noemgd = "702040ac7c7ec66a29b4d147665ccdd0ff015577"
+     LINUX_VERSION_crownbay-noemgd = "3.10.35"
+     SRCREV_meta_crownbay-noemgd = "b6e58b33dd427fe471f8827c83e311acdf4558a4"
+     SRCREV_machine_crownbay-noemgd = "cee957655fe67826b2e827e2db41f156fa8f0cc4"
+
+     SRC_URI_crownbay = "git://git.yoctoproject.org/linux-yocto-3.10.git;protocol=git;nocheckout=1;branch=${KBRANCH},${KMETA},emgd-1.18;name=machine,meta,emgd"
                 </literallayout>
                 This append file contains statements used to support the Crown Bay BSP.
-                The file defines <filename>crownbay</filename> as the
+                The file defines machines using the
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-COMPATIBLE_MACHINE'><filename>COMPATIBLE_MACHINE</filename></ulink>
-                and uses the
+                variable and uses the
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-KMACHINE'><filename>KMACHINE</filename></ulink> variable to
                 ensure the machine name used by the OpenEmbedded build system maps to the
                 machine name used by the Linux Yocto kernel.
@@ -542,11 +550,15 @@
                 kernel branch.
                 The
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_FEATURES'><filename>KERNEL_FEATURES</filename></ulink>
-                variable enables features specific to the kernel.
-                Finally, the append file points to specific commits in the
+                variable enables features specific to the kernel
+                (e.g. graphics support in this case).
+                The append file points to specific commits in the
                 <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink> Git
                 repository and the <filename>meta</filename> Git repository branches to identify the
                 exact kernel needed to build the Crown Bay BSP.
+                Finally, the file includes the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
+                statement to locate the source files.
             </para>
 
             <para>
@@ -557,8 +569,9 @@
                 You can accomplish this definition by putting the configurations in a file or a set of files
                 inside a directory located at the same level as your kernel's append file and having the same
                 name as the kernel's main recipe file.
-                With all these conditions met, simply reference those files in a
-                <filename>SRC_URI</filename> statement in the append file.
+                With all these conditions met, simply reference those files in the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
+                statement in the append file.
             </para>
 
             <para>
@@ -1225,8 +1238,7 @@
                     is created in the current working directory.
                     This example assumes you have sourced the
                     <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
-                    and are currently in the top-level folder of the
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                    setup script.
                 </para>
 
                 <para>
@@ -1248,21 +1260,20 @@
      Getting branches from remote repo git://git.yoctoproject.org/linux-yocto-3.10.git...
      Please choose a machine branch to base your new BSP branch on: [default: standard/base]
 	     1) standard/arm-versatile-926ejs
-             2) standard/base
-	     3) standard/beaglebone
-	     4) standard/ck
-	     5) standard/crownbay
-	     6) standard/edf
-	     7) standard/emenlow
-	     8) standard/fri2
-	     9) standard/fsl-mpc8315e-rdb
-	     10) standard/ltsi
+	     2) standard/base
+	     3) standard/beagleboard
+	     4) standard/beaglebone
+	     5) standard/ck
+	     6) standard/crownbay
+	     7) standard/edgerouter
+             8) standard/emenlow
+	     9) standard/fri2
+	     10) standard/fsl-mpc8315e-rdb
 	     11) standard/mti-malta32
 	     12) standard/mti-malta64
-	     13) standard/ocf
-	     14) standard/qemuppc
-	     15) standard/edgerouter
-	     16) standard/sys940x
+	     13) standard/qemuppc
+	     14) standard/routerstationpro
+	     15) standard/sys940x
      1
      Would you like SMP support? (y/n) [default: y]
      Does your BSP have a touchscreen? (y/n) [default: n]
@@ -1270,17 +1281,17 @@
 
      New qemu BSP created in meta-myarm
                     </literallayout>
-                    Let's take a closer look at the example now:
+                    Take a closer look at the example now:
                     <orderedlist>
                         <listitem><para>For the QEMU architecture,
                             the script first prompts you for which emulated architecture to use.
                             In the example, we use the ARM architecture.
                             </para></listitem>
                         <listitem><para>The script then prompts you for the kernel.
-                            The default 3.10 kernel is acceptable.
+                            The default 3.14 kernel is acceptable.
                             So, the example accepts the default.
                             If you enter 'n', the script prompts you to further enter the kernel
-                            you do want to use (e.g. 3.2, 3.2_preempt-rt, and so forth.).</para></listitem>
+                            you do want to use.</para></listitem>
                         <listitem><para>Next, the script asks whether you would like to have a new
                             branch created especially for your BSP in the local
                             <ulink url='&YOCTO_DOCS_DEV_URL;#local-kernel-files'>Linux Yocto Kernel</ulink>

documentation/dev-manual/dev-manual-common-tasks.xml

@@ -2082,14 +2082,15 @@
                         and
                         <ulink url='&YOCTO_DOCS_REF_URL;#var-INITSCRIPT_PARAMS'><filename>INITSCRIPT_PARAMS</filename></ulink>
                         variables within your recipe.</para></listitem>
-                    <listitem><para><emphasis>Systemd:</emphasis>
-                        Systemd was designed to replace SysVinit and to provide
+                    <listitem><para><emphasis>systemd:</emphasis>
+                        System Management Daemon (systemd) was designed to
+                        replace SysVinit and to provide
                         enhanced management of services.
-                        For more information on Systemd, see the Systemd
+                        For more information on systemd, see the systemd
                         homepage at
                         <ulink url='http://freedesktop.org/wiki/Software/systemd/'></ulink>.
                         </para>
-                        <para>To enable a service using Systemd, your recipe
+                        <para>To enable a service using systemd, your recipe
                         needs to inherit the
                         <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-systemd'><filename>systemd</filename></ulink>
                         class.
@@ -2097,12 +2098,7 @@
                         located in your
                         <link linkend='source-directory'>Source Directory</link>.
                         section for more information.
-                        <note>For Systemd-based images, include the following
-                        in your <filename>local.conf</filename> file:
-                        <literallayout class='monospaced'>
-     VIRTUAL-RUNTIME_initscripts = ""
-                        </literallayout>
-                        </note></para></listitem>
+                        </para></listitem>
                 </itemizedlist>
             </para>
         </section>
@@ -5345,7 +5341,7 @@
         <para>
             By default, the Yocto Project uses SysVinit as the initialization
             manager.
-            However, support also exists for Systemd,
+            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.
@@ -5354,20 +5350,12 @@
         <para>
             If you want to use SysVinit, you do
             not have to do anything.
-            But, if you want to use Systemd, you must
+            But, if you want to use systemd, you must
             take some steps as described in the following sections.
         </para>
 
         <section id='using-systemd-exclusively'>
-            <title>Using Systemd Exclusively</title>
-
-            <para>
-                Set this variable in your <filename>local.conf</filename>
-                file:
-                <literallayout class='monospaced'>
-     VIRTUAL-RUNTIME_initscripts = ""
-                </literallayout>
-            </para>
+            <title>Using systemd Exclusively</title>
 
             <para>
                 Set the these variables in your distribution configuration
@@ -5385,6 +5373,14 @@
                 Doing so removes any redundant SysVinit scripts.
             </para>
 
+            <para>
+                To remove  initscripts from your image altogether,
+                set this variable also:
+                <literallayout class='monospaced'>
+     VIRTUAL-RUNTIME_initscripts = ""
+                </literallayout>
+            </para>
+
             <para>
                 For information on the backfill variable, see
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-DISTRO_FEATURES_BACKFILL_CONSIDERED'><filename>DISTRO_FEATURES_BACKFILL_CONSIDERED</filename></ulink>.
@@ -5392,15 +5388,7 @@
         </section>
 
         <section id='using-systemd-for-the-main-image-and-using-sysvinit-for-the-rescue-image'>
-            <title>Using Systemd for the Main Image and Using SysVinit for the Rescue Image</title>
-
-            <para>
-                Set this variable in your <filename>local.conf</filename>
-                file:
-                <literallayout class='monospaced'>
-     VIRTUAL-RUNTIME_initscripts = ""
-                </literallayout>
-            </para>
+            <title>Using systemd for the Main Image and Using SysVinit for the Rescue Image</title>
 
             <para>
                 Set the these variables in your distribution configuration
@@ -5411,11 +5399,11 @@
                 </literallayout>
                 Doing so causes your main image to use the
                 <filename>packagegroup-core-boot.bb</filename> recipe and
-                Systemd.
+                systemd.
                 The rescue/minimal image cannot use this package group.
                 However, it can install SysVinit
                 and the appropriate packages will have support for both
-                Systemd and SysVinit.
+                systemd and SysVinit.
             </para>
         </section>
     </section>
@@ -5447,7 +5435,7 @@
             Then, you can add the following to your
             <filename>local.conf</filename>:
             <literallayout class='monospaced'>
-     SRCREV_pn-&lt;PN&gt; = "${AUTOREF}"
+     SRCREV_pn-&lt;PN&gt; = "${AUTOREV}"
             </literallayout>
             <ulink url='&YOCTO_DOCS_REF_URL;#var-PN'><filename>PN</filename></ulink>
             is the name of the recipe for which you want to enable automatic source
@@ -5660,7 +5648,7 @@
             </para>
 
             <section id='qemu-image-enabling-tests'>
-                <title>QEMU</title>
+                <title>Enabling Runtime Tests on QEMU</title>
 
                 <para>
                     In order to run tests, you need to do the following:
@@ -5713,39 +5701,269 @@
                     </itemizedlist>
                 </para>
 
-                <note>
-                    Regardless of how you initiate the tests, if you built your
-                    image using <filename>rm_work</filename>,
-                    most of the tests will fail with errors because they rely on
-                    <filename>${WORKDIR}/installed_pkgs.txt</filename>.
-                </note>
+                <para>
+                    Once you start running the tests, the following happens:
+                    <itemizedlist>
+                        <listitem><para>A copy of the root filesystem is written
+                            to <filename>${WORKDIR}/testimage</filename>.
+                            </para></listitem>
+                        <listitem><para>The image is booted under QEMU using the
+                            standard <filename>runqemu</filename> script.
+                            </para></listitem>
+                        <listitem><para>A default timeout of 500 seconds occurs
+                            to allow for the boot process to reach the login prompt.
+                            You can change the timeout period by setting
+                            <ulink url='&YOCTO_DOCS_REF_URL;#var-TEST_QEMUBOOT_TIMEOUT'><filename>TEST_QEMUBOOT_TIMEOUT</filename></ulink>
+                            in the <filename>local.conf</filename> file.
+                            </para></listitem>
+                        <listitem><para>Once the boot process is reached and the
+                            login prompt appears, the tests run.
+                            The full boot log is written to
+                            <filename>${WORKDIR}/testimage/qemu_boot_log</filename>.
+                            </para></listitem>
+                        <listitem><para>Each test module loads in the order found
+                            in <filename>TEST_SUITES</filename>.
+                            You can find the full output of the commands run over
+                            SSH in
+                            <filename>${WORKDIR}/testimgage/ssh_target_log</filename>.
+                            </para></listitem>
+                        <listitem><para>If no failures occur, the task running the
+                            tests ends successfully.
+                            You can find the output from the
+                            <filename>unittest</filename> in the task log at
+                            <filename>${WORKDIR}/temp/log.do_testimage</filename>.
+                            </para></listitem>
+                    </itemizedlist>
+                </para>
             </section>
 
             <section id='hardware-image-enabling-tests'>
-                <title>Hardware</title>
+                <title>Enabling Runtime Tests on Hardware</title>
 
                 <para>
-                    This section needs the information specific to enabling
-                    tests to run on actual hardware.
-                    Here are some developer notes:
+                    The OpenEmbedded build system can run tests on real
+                    hardware, and for certain devices it can also deploy
+                    the image to be tested onto the device beforehand.
+                </para>
+
+                <para>
+                    For automated deployment, a "master image" is installed
+                    onto the hardware once as part of setup.
+                    Then, each time tests are to be run, the following
+                    occurs:
+                    <orderedlist>
+                        <listitem><para>The master image is booted into and
+                            used to write the image to be tested to
+                            a second partition.
+                            </para></listitem>
+                        <listitem><para>The device is then rebooted using an
+                            external script that you need to provide.
+                            </para></listitem>
+                        <listitem><para>The device boots into the image to be
+                            tested.
+                            </para></listitem>
+                    </orderedlist>
+                </para>
+
+                <para>
+                    When running tests (independent of whether the image
+                    has been deployed automatically or not), the device is
+                    expected to be connected to a network on a
+                    pre-determined IP address.
+                    You can either use static IP addresses written into
+                    the image, or set the image to use DHCP and have your
+                    DHCP server on the test network assign a known IP address
+                    based on the MAC address of the device.
+                </para>
+
+                <para>
+                    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".
+                    For running tests on hardware, two options exist:
+                    "SimpleRemoteTarget" and "GummibootTarget".
+                    <itemizedlist>
+                        <listitem><para><emphasis>"SimpleRemoteTarget":</emphasis>
+                            Choose "SimpleRemoteTarget" 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
+                            with either real hardware or an image running
+                            within a separately started QEMU or any
+                            other virtual machine manager.
+                            </para></listitem>
+                        <listitem><para><emphasis>"GummibootTarget":</emphasis>
+                            Choose "GummibootTarget" if your hardware is
+                            an EFI-based machine with
+                            <filename>gummiboot</filename> as bootloader and
+                            <filename>core-image-testmaster</filename>
+                            (or something similar) is installed.
+                            Also, your hardware under test must be in a
+                            DHCP-enabled network that gives it the same IP
+                            address for each reboot.</para>
+                            <para>If you choose "GummibootTarget", there are
+                            additional requirements and considerations.
+                            See the
+                            "<link linkend='selecting-gummiboottarget'>Selecting GummibootTarget</link>"
+                            section, which follows, for more information.
+                            </para></listitem>
+                    </itemizedlist>
+                </para>
+            </section>
+
+            <section id='selecting-gummiboottarget'>
+                <title>Selecting GummibootTarget</title>
+
+                <para>
+                    If you did not set <filename>TEST_TARGET</filename> to
+                    "GummibootTarget", then you do not need any information
+                    in this section.
+                    You can skip down to the
+                    "<link linkend='qemu-image-running-tests'>Running Tests</link>"
+                    section.
+                </para>
+
+                <para>
+                    If you did set <filename>TEST_TARGET</filename> to
+                    "GummibootTarget", you also need to perform a one-time
+                    setup of your master image by doing the following:
+                    <orderedlist>
+                        <listitem><para><emphasis>Set <filename>EFI_PROVIDER</filename>:</emphasis>
+                            Be sure that <filename>EFI_PROVIDER</filename>
+                            is as follows:
+                            <literallayout class='monospaced'>
+     EFI_PROVIDER = "gummiboot"
+                            </literallayout>
+                            </para></listitem>
+                        <listitem><para><emphasis>Build the master image:</emphasis>
+                            Build the <filename>core-image-testmaster</filename>
+                            image.
+                            The <filename>core-image-testmaster</filename>
+                            recipe is provided as an example for a
+                            "master" image and you can customize the image
+                            recipe as you would any other recipe.
+                            </para>
+                            <para>Here are the image recipe requirements:
+                            <itemizedlist>
+                                <listitem><para>Inherits
+                                    <filename>core-image</filename>
+                                    so that kernel modules are installed.
+                                    </para></listitem>
+                                <listitem><para>Installs normal linux utilities
+                                    not busybox ones (e.g.
+                                    <filename>bash</filename>,
+                                    <filename>coreutils</filename>,
+                                    <filename>tar</filename>,
+                                    <filename>gzip</filename>, and
+                                    <filename>kmod</filename>).
+                                    </para></listitem>
+                                <listitem><para>Uses a custom
+                                    initramfs image with a custom installer.
+                                    A normal image that you can install usually
+                                    creates a single rootfs partition.
+                                    This image uses another installer that
+                                    creates a specific partition layout.
+                                    Not all Board Support Packages (BSPs)
+                                    can use an installer.
+                                    For such cases, you need to manually create
+                                    the following partition layout on the
+                                    target:
+                                    <itemizedlist>
+                                        <listitem><para>First partition mounted
+                                            under <filename>/boot</filename>,
+                                            labeled "boot".
+                                            </para></listitem>
+                                        <listitem><para>The main rootfs
+                                            partition where this image gets
+                                            installed, which is mounted under
+                                            <filename>/</filename>.
+                                            </para></listitem>
+                                        <listitem><para>Another partition
+                                            labeled "testrootfs" where test
+                                            images get deployed.
+                                            </para></listitem>
+                                    </itemizedlist>
+                                    </para></listitem>
+                            </itemizedlist>
+                            </para></listitem>
+                        <listitem><para><emphasis>Install image:</emphasis>
+                            Install the image that you just built on the target
+                            system.
+                            </para></listitem>
+                    </orderedlist>
+                </para>
+
+                <para>
+                    The final thing you need to do when setting
+                    <filename>TEST_TARGET</filename> to "GummibootTarget" is
+                    to set up the test image:
+                    <orderedlist>
+                        <listitem><para><emphasis>Set up your <filename>local.conf</filename> file:</emphasis>
+                            Make sure you have the following statements in
+                            your <filename>local.conf</filename> file:
+                            <literallayout class='monospaced'>
+     IMAGE_FSTYPES += "tar.gz"
+     INHERIT += "testimage"
+     TEST_TARGET = "GummibootTarget"
+     TEST_TARGET_IP = "192.168.2.3"
+                            </literallayout>
+                            </para></listitem>
+                        <listitem><para><emphasis>Build your test image:</emphasis>
+                            Use BitBake to build the image:
+                            <literallayout class='monospaced'>
+     $ bitbake core-image-sato
+                            </literallayout>
+                            </para></listitem>
+                    </orderedlist>
+                </para>
+
+                <para>
+                    Here is some additional information regarding running
+                    "GummibootTarget" as your test target:
                     <itemizedlist>
                         <listitem><para>
-                            Paul says this "If you have deployed the image yourself,
-                            you can manually boot it, you know the IP address
-                            it will show up under, and SSH is installed with no
-                            password, then you can now run tests on any real
-                            machine."
+                            You can use
+                            <filename>TEST_POWERCONTROL_CMD</filename>
+                            together with
+                            <filename>TEST_POWERCONTROL_EXTRA_ARGS</filename>
+                            as a command that runs on the host and does power
+                            cycling.
+                            The test code passes one argument to that command:
+                            off, on or cycle (off then on).
+                            Here is an example that could appear in your
+                            <filename>local.conf</filename> file:
+                            <literallayout class='monospaced'>
+     TEST_POWERCONTROL_CMD = "powercontrol.exp test 10.11.12.1 nuc1"
+                            </literallayout>
+                            In this example, the expect script does the
+                            following:
+                            <literallayout class='monospaced'>
+     ssh test@10.11.12.1 "pyctl nuc1 &lt;arg&gt;"
+                            </literallayout>
+                            It then runs a Python script that controls power
+                            for a label called <filename>nuc1</filename>.
+                            <note>
+                                You need to customize
+                                <filename>TEST_POWERCONTROL_CMD</filename>
+                                and
+                                <filename>TEST_POWERCONTROL_EXTRA_ARGS</filename>
+                                for your own setup.
+                                The one requirement is that it accepts
+                                "on", "off", and "cycle" as the last argument.
+                            </note>
                             </para></listitem>
                         <listitem><para>
-                            <filename>TEST_TARGET</filename> variable needs to equal
-                            "simpleremote"
-                            </para></listitem>
-                        <listitem><para>
-                            Here are some notes from the patch - "The remote machine
-                            must be up with network and ssh and you need to set
-                            <filename>TEST_TARGET_IP</filename> with the IP address
-                            of the remote machine (it can still be a qemu instance that
-                            was manually started)
+                            When no command is defined, it connects to the
+                            device over SSH and uses the classic reboot command
+                            to reboot the device.
+                            Classic reboot is fine as long as the machine
+                            actually reboots (i.e. the SSH test has not
+                            failed).
+                            It is useful for scenarios where you have a simple
+                            setup, typically with a single board, and where
+                            some manual interaction is okay from time to time.
                             </para></listitem>
                     </itemizedlist>
                 </para>
@@ -5768,18 +5986,6 @@
                         <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>:
                         <literallayout class='monospaced'>
      TEST_IMAGE = "1"
-                        </literallayout>
-                        Next, also in the <filename>local.conf</filename>, set the
-                        <filename>TEST_TARGET</filename> variable to
-                        "simpleremote" if you want to run tests on real hardware or
-                        set it to "qemu" if you want to run tests using QEMU.
-                        file:
-                        <literallayout class='monospaced'>
-     TEST_TARGET = "simpleremote"
-                        </literallayout>
-                        or
-                        <literallayout class='monospaced'>
-     TEST_TARGET = "qemu"
                         </literallayout>
                         Next, build your image.
                         If the image successfully builds, the tests will be
@@ -5802,42 +6008,6 @@
                 </itemizedlist>
             </para>
 
-            <para>
-                Regardless of how you run the tests, once they start, the
-                following happens:
-                <itemizedlist>
-                    <listitem><para>A copy of the root filesystem is written
-                        to <filename>${WORKDIR}/testimage</filename>.
-                        </para></listitem>
-                    <listitem><para>The image is booted under QEMU using the
-                        standard <filename>runqemu</filename> script.
-                        </para></listitem>
-                    <listitem><para>A default timeout of 500 seconds occurs
-                        to allow for the boot process to reach the login prompt.
-                        You can change the timeout period by setting
-                        <ulink url='&YOCTO_DOCS_REF_URL;#var-TEST_QEMUBOOT_TIMEOUT'><filename>TEST_QEMUBOOT_TIMEOUT</filename></ulink>
-                        in the <filename>local.conf</filename> file.
-                        </para></listitem>
-                    <listitem><para>Once the boot process is reached and the
-                        login prompt appears, the tests run.
-                        The full boot log is written to
-                        <filename>${WORKDIR}/testimage/qemu_boot_log</filename>.
-                        </para></listitem>
-                    <listitem><para>Each test module loads in the order found
-                        in <filename>TEST_SUITES</filename>.
-                        You can find the full output of the commands run over
-                        SSH in
-                        <filename>${WORKDIR}/testimgage/ssh_target_log</filename>.
-                        </para></listitem>
-                    <listitem><para>If no failures occur, the task running the
-                        tests ends successfully.
-                        You can find the output from the
-                        <filename>unittest</filename> in the task log at
-                        <filename>${WORKDIR}/temp/log.do_testimage</filename>.
-                        </para></listitem>
-                </itemizedlist>
-            </para>
-
             <para>
                 All test files reside in
                 <filename>meta/lib/oeqa/runtime</filename> in the
@@ -5845,7 +6015,7 @@
                 A test name maps directly to a Python module.
                 Each test module may contain a number of individual tests.
                 Tests are usually grouped together by the area
-                tested (e.g tests for Systemd reside in
+                tested (e.g tests for systemd reside in
                 <filename>meta/lib/oeqa/runtime/systemd.py</filename>).
             </para>
 
@@ -5919,6 +6089,71 @@
             </para>
         </section>
 
+        <section id="exporting-tests">
+            <title>Exporting Tests</title>
+
+            <para>
+                You can export tests so that they can run independently of
+                the build system.
+                Exporting tests is required if you want to be able to hand
+                the test execution off to a scheduler.
+                You can only export tests that are defined in
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-TEST_SUITES'><filename>TEST_SUITES</filename></ulink>.
+            </para>
+
+            <para>
+                If you image is already built, make sure the following are set
+                in your <filename>local.conf</filename> file.
+                Be sure to provide the IP address you need:
+                <literallayout class='monospaced'>
+     TEST_EXPORT_ONLY = "1"
+     TEST_TARGET = "simpleremote"
+     TEST_TARGET_IP = "192.168.7.2"
+     TEST_SERVER_IP = "192.168.7.1"
+                </literallayout>
+                You can then export the tests with the following:
+                <literallayout class='monospaced'>
+     $ bitbake core-image-sato -c testimage
+                </literallayout>
+                Exporting the tests places them in the
+                <link linkend='build-directory'>Build Directory</link> in
+                <filename>tmp/testimage/core-image-sato</filename>, which
+                is controlled by the
+                <filename>TEST_EXPORT_DIR</filename> variable.
+            </para>
+
+            <para>
+                The exported data (i.e. <filename>testdata.json</filename>)
+                contains paths to the Build Directory.
+                Thus, the contents of the directory can be moved
+                to another machine as long as you update some paths in the
+                JSON.
+                Usually you only care about the
+                ${DEPLOY_DIR}/rpm directory (assuming the RPM and Smart tests
+                are enabled).
+                Consequently, running the tests on other machine
+                means that you have to move the contents and call
+                <filename>runexported</filename> with "--deploy-dir PATH:
+                ./runexported.py --deploy-dir /new/path/on/this/machine testdata.json
+                runexported.py accepts other arguments as well, see --help.
+            </para>
+
+            <para>
+                You can now run the tests outside of the build environment:
+                <literallayout class='monospaced'>
+     $ cd tmp/testimage/core-image-sato
+     $ ./runexported.py testdata.json
+                </literallayout>
+                <note>
+                    This "export" feature does not deploy or boot the target
+                    image.
+                    Your target (be it a Qemu or hardware one)
+                    has to already be up and running when you call
+                    <filename>runexported.py</filename>
+                </note>
+            </para>
+        </section>
+
         <section id="qemu-image-writing-new-tests">
             <title>Writing New Tests</title>
 
@@ -5971,9 +6206,7 @@
                         <listitem><para><emphasis><filename>hasPackage(pkg)</filename>:</emphasis>
                             Returns "True" if <filename>pkg</filename> is in the
                             installed package list of the image, which is based
-                            on
-                            <filename>${WORKDIR}/installed_pkgs.txt</filename>
-                            that is generated during the
+                            on the manifest file that is generated during the
                             <filename>do.rootfs</filename> task.
                             </para></listitem>
                         <listitem><para><emphasis><filename>hasFeature(feature)</filename>:</emphasis>
@@ -5982,12 +6215,6 @@
                             or
                             <ulink url='&YOCTO_DOCS_REF_URL;#var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></ulink>.
                             </para></listitem>
-                        <listitem><para><emphasis><filename>restartTarget(params)</filename>:</emphasis>
-                            Restarts the QEMU image optionally passing
-                            <filename>params</filename> to the
-                            <filename>runqemu</filename> script's
-                            <filename>qemuparams</filename> list (e.g "-m 1024" for
-                            more memory).</para></listitem>
                     </itemizedlist>
                 </para>
             </section>
@@ -6024,35 +6251,20 @@
                                     for copying on the target such as small
                                     files written in C for compilation.
                                     </para></listitem>
-                                <listitem><para><emphasis><filename>qemu</filename>:</emphasis>
-                                    Provides access to the
-                                    <filename>QemuRunner</filename> object,
-                                    which is the class that boots the image.
-                                    The <filename>qemu</filename> attribute
-                                    provides the following useful attributes:
+                                <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
+                                    GummibootTarget).
+                                    Tests usually use the following:
                                     <itemizedlist>
                                         <listitem><para><emphasis><filename>ip</filename>:</emphasis>
-                                            The machine's IP address.
+                                            The target's IP address.
                                             </para></listitem>
-                                        <listitem><para><emphasis><filename>host_ip</filename>:</emphasis>
-                                            The host IP address, which is only
-                                            used by smart tests.
-                                            </para></listitem>
-                                    </itemizedlist></para></listitem>
-                                <listitem><para><emphasis><filename>target</filename>:</emphasis>
-                                    The <filename>SSHControl</filename> object,
-                                    which is used for running the following
-                                    commands on the image:
-                                    <itemizedlist>
-                                        <listitem><para><emphasis><filename>host</filename>:</emphasis>
-                                            Used internally.
-                                            The tests do not use this command.
-                                            </para></listitem>
-                                        <listitem><para><emphasis><filename>timeout</filename>:</emphasis>
-                                            A global timeout for commands run on
-                                            the target for the instance of a
-                                            test.
-                                            The default is 300 seconds.
+                                        <listitem><para><emphasis><filename>server_ip</filename>:</emphasis>
+                                            The host's IP address, which is
+                                            usually used by the "smart" test
+                                            suite.
                                             </para></listitem>
                                         <listitem><para><emphasis><filename>run(cmd, timeout=None)</filename>:</emphasis>
                                             The single, most used method.
@@ -6446,18 +6658,6 @@
                         or
                         <ulink url='&YOCTO_DOCS_REF_URL;#structure-memres-core-script'><filename>oe-init-build-env-memres</filename></ulink>).
                         </para></listitem>
-                    <listitem><para><emphasis>Prepare your local configuration file:</emphasis>
-                        Toaster needs the
-                        <ulink url='&YOCTO_DOCS_REF_URL;#toaster'><filename>toaster</filename></ulink>
-                        class enabled
-                        in Bitbake in order to record target image package
-                        information.
-                        You can enable it by adding the following line to your
-                        <filename>conf/local.conf</filename> file:
-                        <literallayout class='monospaced'>
-     INHERIT += "toaster"
-                        </literallayout>
-                        </para></listitem>
                     <listitem><para><emphasis>Start Toaster:</emphasis>
                         Start the Toaster service using this
                         command from within your
@@ -6508,15 +6708,15 @@
             <para>
                 You access the information one of two ways:
                 <itemizedlist>
-                    <listitem><para>Open a Browser and type enter in the
-                        <filename>http://localhost:8000</filename> URL.
+                    <listitem><para>Open a Browser and enter
+                        <filename>http://localhost:8000</filename>
+                        for the URL.
                         </para></listitem>
                     <listitem><para>Use the <filename>xdg-open</filename>
                         tool from the shell and pass it the same URL.
                         </para></listitem>
                 </itemizedlist>
-                Either method opens the home page for the Toaster interface,
-                which is temporary for this release.
+                Either method opens the home page for the Toaster interface.
             </para>
 
             <note><title>Notes</title>
@@ -6550,50 +6750,24 @@
                 You can click on any build to see related information.
                 This information includes configuration details, information
                 about tasks, all recipes and packages built and their
-                dependencies, packages installed in your final image,
+                dependencies, packages and their directory structure as
+                installed in your final image,
                 execution time, CPU usage and disk I/O per task.
             </para>
 
             <para>
-                The home page of the interface into the database organizes
-                builds into areas:
-                <itemizedlist>
-                    <listitem><para>Recent successful builds, which appear
-                        in row format in a green area.</para></listitem>
-                    <listitem><para>Recent failed builds, which appear
-                        in row format in a red area.</para></listitem>
-                    <listitem><para>Recent builds in progress, which appear
-                        in row format in a yellow area.</para></listitem>
-                    <listitem><para>All builds, which appear in row format at
-                        the end of the page.</para></listitem>
-                </itemizedlist>
+                For details on the interface, see the
+                <ulink url='https://www.yoctoproject.org/documentation/toaster-manual'>Toaster Manual</ulink>.
             </para>
-
-            <para>
-                Each entry is linked to more detail on the particular build
-                or recipe.
-                You can click on the links to learn more information.
-            </para>
-
-            <para>
-                When you click on a failed recipe link, you can find out
-                information such as the work directory, the pathname to the
-                failing recipe, the exact error message, and precursor tasks.
-            </para>
-
-            <para>
-                Clicking on a successful build provides you with configuration,
-                task, and package information along with directory structure,
-                build time, CPU usage, and disk I/O information.
-            </para>
-
         </section>
 
         <section id='stopping-toaster'>
             <title>Stopping Toaster</title>
 
             <para>
-                Stop the Toaster service with the following command:
+                Stop the Toaster service with the following command
+                from with the
+                <link linkend='build-directory'>Build Directory</link>:
                 <literallayout class='monospaced'>
      $ source toaster stop
                 </literallayout>
@@ -7110,54 +7284,95 @@
         </para>
 
         <para>
-            By default, the error reporting tool is disabled.
-            You can enable it by inheriting the
-            <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-report-error'><filename>report-error</filename></ulink>
-            class by adding the following statement to the end of
-            your <filename>local.conf</filename> file in your
-            <link linkend='build-directory'>Build Directory</link>.
-            <literallayout class='monospaced'>
+            A live instance of the error reporting server exists at
+            <ulink url='http://errors.yoctoproject.org'></ulink>.
+            This server exists so that when you want to get help with
+            build failures, you can submit all of the information on the
+            failure easily and then point to the URL in your bug report
+            or send an email to the mailing list.
+            <note>
+                If you send error reports to this server, the reports become
+                publicly visible.
+            </note>
+        </para>
+
+        <section id='enabling-and-using-the-tool'>
+            <title>Enabling and Using the Tool</title>
+
+            <para>
+                By default, the error reporting tool is disabled.
+                You can enable it by inheriting the
+                <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-report-error'><filename>report-error</filename></ulink>
+                class by adding the following statement to the end of
+                your <filename>local.conf</filename> file in your
+                <link linkend='build-directory'>Build Directory</link>.
+                <literallayout class='monospaced'>
      INHERIT += "report-error"
-            </literallayout>
-            To disable the feature, simply remove or comment out the statement.
-        </para>
+                </literallayout>
+            </para>
 
-        <para>
-            By default, the error reporting feature stores information in
-            <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-LOG_DIR'><filename>LOG_DIR</filename></ulink><filename>}/error-report</filename>.
-            However, you can specify a directory to use by adding the following
-            to your <filename>local.conf</filename> file:
-            <literallayout class='monospaced'>
+            <para>
+                By default, the error reporting feature stores information in
+                <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-LOG_DIR'><filename>LOG_DIR</filename></ulink><filename>}/error-report</filename>.
+                However, you can specify a directory to use by adding the following
+                to your <filename>local.conf</filename> file:
+                <literallayout class='monospaced'>
      ERR_REPORT_DIR = "path"
-            </literallayout>
-            Enabling error reporting causes the build process to collect
-            the errors and store them in a file as previously described.
-            When the build system encounters an error, it includes a command
-            as part of the console output.
-            You can run the command to send the error file to the server.
-            For example, the following command sends the errors to an upstream
-            server:
-            <literallayout class='monospaced'>
+                </literallayout>
+                Enabling error reporting causes the build process to collect
+                the errors and store them in a file as previously described.
+                When the build system encounters an error, it includes a command
+                as part of the console output.
+                You can run the command to send the error file to the server.
+                For example, the following command sends the errors to an upstream
+                server:
+                <literallayout class='monospaced'>
      send-error-report /home/brandusa/project/poky/build/tmp/log/error-report/error_report_201403141617.txt [server]
-            </literallayout>
-            In the above example, the <filename>server</filename> parameter is
-            optional.
-            By default, the errors are sent to a database used by the entire
-            community.
-            If you specify a particular server, you can send them to a different
-            database.
-        </para>
+                </literallayout>
+                In the above example, the <filename>server</filename> parameter is
+                optional.
+                By default, the errors are sent to a database used by the entire
+                community.
+                If you specify a particular server, you can send them to a different
+                database.
+            </para>
 
-        <para>
-            When sending the error file, you receive a link that corresponds
-            to your entry in the database.
-            For example, here is a typical link:
-            <literallayout class='monospaced'>
+            <para>
+                When sending the error file, you receive a link that corresponds
+                to your entry in the database.
+                For example, here is a typical link:
+                <literallayout class='monospaced'>
      http://localhost:8000/Errors/Search/1/158
-            </literallayout>
-            Following the link takes you to a web interface where you can
-            browse, query the errors, and view statistics.
-         </para>
+                </literallayout>
+                Following the link takes you to a web interface where you can
+                browse, query the errors, and view statistics.
+             </para>
+        </section>
+
+        <section id='disabling-the-tool'>
+            <title>Disabling the Tool</title>
+
+            <para>
+                To disable the error reporting feature, simply remove or comment
+                out the following statement from the end of your
+                <filename>local.conf</filename> file in your
+                <link linkend='build-directory'>Build Directory</link>.
+                <literallayout class='monospaced'>
+     INHERIT += "report-error"
+                </literallayout>
+            </para>
+        </section>
+
+        <section id='setting-up-your-own-error-reporting-server'>
+            <title>Setting Up Your Own Error Reporting Server</title>
+
+            <para>
+                If you want to set up your own error reporting server, you
+                can obtain the code from the Git repository at
+                <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/error-report-web/'></ulink>.
+                Instructions on how to set it up are in the README document.
+            </para>
+        </section>
      </section>
 </chapter>
 

documentation/dev-manual/dev-manual.xml

@@ -63,7 +63,7 @@
             </revision>
             <revision>
                 <revnumber>1.6</revnumber>
-                <date>Sometime 2014</date>
+                <date>April 2014</date>
                 <revremark>Released with the Yocto Project 1.6 Release.</revremark>
             </revision>
         </revhistory>

documentation/kernel-dev/kernel-dev.xml

@@ -48,7 +48,7 @@
             </revision>
             <revision>
                 <revnumber>1.6</revnumber>
-                <date>Sometime 2014</date>
+                <date>April 2014</date>
                 <revremark>Released with the Yocto Project 1.6 Release.</revremark>
             </revision>
         </revhistory>

documentation/poky.ent

@@ -50,7 +50,7 @@
 <!ENTITY YOCTO_DOCS_KERNEL_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/kernel-manual/kernel-manual.html">
 <!ENTITY YOCTO_DOCS_KERNEL_DEV_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/kernel-dev/kernel-dev.html">
 <!ENTITY YOCTO_DOCS_PROF_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/profile-manual/profile-manual.html">
-<!ENTITY YOCTO_DOCS_BB_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/user-manual/user-manual.html">
+<!ENTITY YOCTO_DOCS_BB_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/bitbake-user-manual/bitbake-user-manual.html">
 <!ENTITY YOCTO_ADTPATH_DIR "/opt/poky/&DISTRO;">
 <!ENTITY YOCTO_POKY_TARBALL "&YOCTO_POKY;.tar.bz2">
 <!ENTITY OE_INIT_PATH "&YOCTO_POKY;/oe-init-build-env">

documentation/profile-manual/profile-manual.xml

@@ -48,7 +48,7 @@
             </revision>
             <revision>
                 <revnumber>1.6</revnumber>
-                <date>Sometime 2014</date>
+                <date>April 2014</date>
                 <revremark>Released with the Yocto Project 1.6 Release.</revremark>
             </revision>
         </revhistory>

documentation/ref-manual/introduction.xml

@@ -142,25 +142,29 @@
 <!--                <listitem><para>Ubuntu 10.04</para></listitem>
                 <listitem><para>Ubuntu 11.10</para></listitem> -->
                 <listitem><para>Ubuntu 12.04 (LTS)</para></listitem>
-                <listitem><para>Ubuntu 12.10</para></listitem>
-                <listitem><para>Ubuntu 13.04</para></listitem>
+                <listitem><para>Ubuntu 13.10</para></listitem>
+                <listitem><para>Ubuntu 14.04 (LTS)</para></listitem>
 <!--                <listitem><para>Fedora 16 (Verne)</para></listitem>
                 <listitem><para>Fedora 17 (Spherical)</para></listitem> -->
-                <listitem><para>Fedora release 18 (Spherical Cow)</para></listitem>
                 <listitem><para>Fedora release 19 (Schrödinger's Cat)</para></listitem>
+                <listitem><para>Fedora release 20 (Heisenbug)</para></listitem>
 <!--                <listitem><para>CentOS release 5.6 (Final)</para></listitem>
                 <listitem><para>CentOS release 5.7 (Final)</para></listitem>
                 <listitem><para>CentOS release 5.8 (Final)</para></listitem>
                 <listitem><para>CentOS release 6.3 (Final)</para></listitem> -->
                 <listitem><para>CentOS release 6.4</para></listitem>
+                <listitem><para>CentOS release 6.5</para></listitem>
 <!--                <listitem><para>Debian GNU/Linux 6.0 (Squeeze)</para></listitem> -->
-                <listitem><para>Debian GNU/Linux 6.0.7 (Squeeze)</para></listitem>
                 <listitem><para>Debian GNU/Linux 7.0 (Wheezy)</para></listitem>
                 <listitem><para>Debian GNU/Linux 7.1 (Wheezy)</para></listitem>
+                <listitem><para>Debian GNU/Linux 7.2 (Wheezy)</para></listitem>
+                <listitem><para>Debian GNU/Linux 7.3 (Wheezy)</para></listitem>
+                <listitem><para>Debian GNU/Linux 7.4 (Wheezy)</para></listitem>
 <!--                <listitem><para>openSUSE 11.4</para></listitem>
                 <listitem><para>openSUSE 12.1</para></listitem> -->
                 <listitem><para>openSUSE 12.2</para></listitem>
                 <listitem><para>openSUSE 12.3</para></listitem>
+                <listitem><para>openSUSE 13.1</para></listitem>
             </itemizedlist>
         </para>
 

documentation/ref-manual/migration.xml

@@ -829,10 +829,10 @@
     </section>
 
     <section id='migration-1.5-run'>
-        <title><filename>run</filename></title>
+        <title><filename>/run</filename></title>
 
         <para>
-            The <filename>run</filename> directory from the Filesystem
+            The <filename>/run</filename> directory from the Filesystem
             Hierarchy Standard 3.0 has been introduced.
             You can find some of the implications for this change
             <ulink url='http://cgit.openembedded.org/openembedded-core/commit/?id=0e326280a15b0f2c4ef2ef4ec441f63f55b75873'>here</ulink>.
@@ -878,7 +878,7 @@
         <para>
             The previously deprecated <filename>task.bbclass</filename> has
             now been dropped.
-            For recipes that previously inherited from this task, you should
+            For recipes that previously inherited from this class, you should
             rename them from <filename>task-*</filename> to
             <filename>packagegroup-*</filename> and inherit packagegroup
             instead.
@@ -1129,6 +1129,15 @@
                     moved to a dedicated
                     <filename>gtk-engines-schemas</filename> package.
                     </para></listitem>
+                <listitem><para>
+                    The <filename>armv7a</filename> with thumb package
+                    architecture suffix has changed.
+                    The suffix for these packages with the thumb
+                    optimization enabled is "t2" as it should be.
+                    Use of this suffix was not the case in the 1.5 release.
+                    Architecture names will change within package feeds as a
+                    result.
+                    </para></listitem>
             </itemizedlist>
         </para>
     </section>
@@ -1141,6 +1150,31 @@
             <ulink url='&YOCTO_DOCS_DEV_URL;#bitbake-term'>BitBake</ulink>.
         </para>
 
+        <section id='migration-1.6-matching-branch-requirement-for-git-fetching'>
+            <title>Matching Branch Requirement for Git Fetching</title>
+
+            <para>
+                When fetching source from a Git repository using
+                <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>,
+                BitBake will now validate the
+                <link linkend='var-SRCREV'><filename>SRCREV</filename></link>
+                value against the branch.
+                You can specify the branch using the following form:
+                <literallayout class='monospaced'>
+     SRC_URI = "git://server.name/repository;branch=&lt;branchname&gt;"
+                </literallayout>
+                If you do not specify a branch, BitBake looks
+                in the default "master" branch.
+            </para>
+
+            <para>
+                Alternatively, if you need to bypass this check (e.g.
+                if you are fetching a revision corresponding to a tag that
+                is not on any branch), you can add ";nobranch=1" to
+                the end of the URL within <filename>SRC_URI</filename>.
+            </para>
+        </section>
+
         <section id='migration-1.6-bitbake-deps'>
             <title>Python Definition substitutions</title>
 

documentation/ref-manual/ref-classes.xml

@@ -1283,118 +1283,6 @@
         <filename>WARN_QA</filename> and <filename>ERROR_QA</filename>
         variables:
         <itemizedlist>
-            <listitem><para><emphasis><filename>ldflags:</filename></emphasis>
-                Ensures that the binaries were linked with the
-                <filename>LDFLAGS</filename> options provided by the build system.
-                If this test fails, check that the <filename>LDFLAGS</filename> variable
-                is being passed to the linker command.</para></listitem>
-            <listitem><para><emphasis><filename>useless-rpaths:</filename></emphasis>
-                Checks for dynamic library load paths (rpaths) in the binaries that
-                by default on a standard system are searched by the linker (e.g.
-                <filename>/lib</filename> and <filename>/usr/lib</filename>).
-                While these paths will not cause any breakage, they do waste space and
-                are unnecessary.</para></listitem>
-            <listitem><para><emphasis><filename>rpaths:</filename></emphasis>
-                Checks for rpaths in the binaries that contain build system paths such
-                as <filename>TMPDIR</filename>.
-                If this test fails, bad <filename>-rpath</filename> options are being
-                passed to the linker commands and your binaries have potential security
-                issues.</para></listitem>
-            <listitem><para><emphasis><filename>dev-so:</filename></emphasis>
-                Checks that the <filename>.so</filename> symbolic links are in the
-                <filename>-dev</filename> package and not in any of the other packages.
-                In general, these symlinks are only useful for development purposes.
-                Thus, the <filename>-dev</filename> package is the correct location for
-                them.
-                Some very rare cases do exist for dynamically loaded modules where
-                these symlinks are needed instead in the main package.
-                </para></listitem>
-            <listitem><para><emphasis><filename>debug-files:</filename></emphasis>
-                Checks for <filename>.debug</filename> directories in anything but the
-                <filename>-dbg</filename> package.
-                The debug files should all be in the <filename>-dbg</filename> package.
-                Thus, anything packaged elsewhere is incorrect packaging.</para></listitem>
-            <listitem><para><emphasis><filename>arch:</filename></emphasis>
-                Checks the Executable and Linkable Format (ELF) type, bit size, and endianness
-                of any binaries to ensure they match the target architecture.
-                This test fails if any binaries don't match the type since there would be an
-                incompatibility.
-                Sometimes software, like bootloaders, might need to bypass this check.
-                </para></listitem>
-            <listitem><para><emphasis><filename>debug-deps:</filename></emphasis>
-                Checks that <filename>-dbg</filename> packages only depend on other
-                <filename>-dbg</filename> packages and not on any other types of packages,
-                which would cause a packaging bug.</para></listitem>
-            <listitem><para><emphasis><filename>dev-deps:</filename></emphasis>
-                Checks that <filename>-dev</filename> packages only depend on other
-                <filename>-dev</filename> packages and not on any other types of packages,
-                which would be a packaging bug.</para></listitem>
-            <listitem><para><emphasis><filename>pkgconfig:</filename></emphasis>
-                Checks <filename>.pc</filename> files for any
-                <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>/<link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>
-                paths.
-                Any <filename>.pc</filename> file containing these paths is incorrect
-                since <filename>pkg-config</filename> itself adds the correct sysroot prefix
-                when the files are accessed.</para></listitem>
-            <listitem><para><emphasis><filename>textrel:</filename></emphasis>
-                Checks for ELF binaries that contain relocations in their
-                <filename>.text</filename> sections, which can result in a
-                performance impact at runtime.</para></listitem>
-            <listitem><para><emphasis><filename>pkgvarcheck:</filename></emphasis>
-                Checks through the variables
-                <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>,
-                <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>,
-                <link linkend='var-RSUGGESTS'><filename>RSUGGESTS</filename></link>,
-                <link linkend='var-RCONFLICTS'><filename>RCONFLICTS</filename></link>,
-                <link linkend='var-RPROVIDES'><filename>RPROVIDES</filename></link>,
-                <link linkend='var-RREPLACES'><filename>RREPLACES</filename></link>,
-                <link linkend='var-FILES'><filename>FILES</filename></link>,
-                <link linkend='var-ALLOW_EMPTY'><filename>ALLOW_EMPTY</filename></link>,
-                <filename>pkg_preinst</filename>,
-                <filename>pkg_postinst</filename>,
-                <filename>pkg_prerm</filename>
-                and <filename>pkg_postrm</filename>, and reports if there are
-                variable sets that are not package-specific.
-                Using these variables without a package suffix is bad practice,
-                and might unnecessarily complicate dependencies of other packages
-                within the same recipe or have other unintended consequences.
-                </para></listitem>
-            <listitem><para><emphasis><filename>xorg-driver-abi:</filename></emphasis>
-                Checks that all packages containing Xorg drivers have ABI
-                dependencies.
-                The <filename>xserver-xorg</filename> recipe provides driver
-                ABI names.
-                All drivers should depend on the ABI versions that they have
-                been built against.
-                Driver recipes that include
-                <filename>xorg-driver-input.inc</filename>
-                or <filename>xorg-driver-video.inc</filename> will
-                automatically get these versions.
-                Consequently, you should only need to explicitly add
-                dependencies to binary driver recipes.
-                </para></listitem>
-            <listitem><para><emphasis><filename>libexec:</filename></emphasis>
-                Checks if a package contains files in
-                <filename>/usr/libexec</filename>.
-                This check is not performed if the
-                <filename>libexecdir</filename> variable has been set
-                explicitly to <filename>/usr/libexec</filename>.
-                </para></listitem>
-            <listitem><para><emphasis><filename>staticdev:</filename></emphasis>
-                Checks for static library files (<filename>*.a</filename>) in
-                non-<filename>staticdev</filename> packages.
-                </para></listitem>
-            <listitem><para><emphasis><filename>la:</filename></emphasis>
-                Checks <filename>.la</filename> files for any <filename>TMPDIR</filename>
-                paths.
-                Any <filename>.la</filename> file containing these paths is incorrect since
-                <filename>libtool</filename> adds the correct sysroot prefix when using the
-                files automatically itself.</para></listitem>
-            <listitem><para><emphasis><filename>desktop:</filename></emphasis>
-                Runs the <filename>desktop-file-validate</filename> program
-                against any <filename>.desktop</filename> files to validate
-                their contents against the specification for
-                <filename>.desktop</filename> files.</para></listitem>
             <listitem><para><emphasis><filename>already-stripped:</filename></emphasis>
                 Checks that produced binaries have not already been
                 stripped prior to the build system extracting debug symbols.
@@ -1404,15 +1292,85 @@
                 <filename>-dbg</filename> packages, this stripping must be
                 disabled.
                 </para></listitem>
-            <listitem><para><emphasis><filename>split-strip:</filename></emphasis>
-                Reports that splitting or stripping debug symbols from binaries
-                has failed.
-                </para></listitem>
             <listitem><para><emphasis><filename>arch:</filename></emphasis>
-                Checks to ensure the architecture, bit size, and endianness
-                of all output binaries matches that of the target.
-                This test can detect when the wrong compiler or compiler options
-                have been used.
+                Checks the Executable and Linkable Format (ELF) type, bit size,
+                and endianness of any binaries to ensure they match the target
+                architecture.
+                This test fails if any binaries do not match the type since
+                there would be an incompatibility.
+                The test could indicate that the
+                wrong compiler or compiler options have been used.
+                Sometimes software, like bootloaders, might need to bypass
+                this check.
+                </para></listitem>
+            <listitem><para><emphasis><filename>buildpaths:</filename></emphasis>
+                Checks for paths to locations on the build host inside the
+                output files.
+                Currently, this test triggers too many false positives and
+                thus is not normally enabled.
+                </para></listitem>
+            <listitem><para><emphasis><filename>compile-host-path:</filename></emphasis>
+                Checks the <filename>do_compile</filename> log for indications
+                that paths to locations on the build host were used.
+                Using such paths might result in host contamination of the
+                build output.
+                </para></listitem>
+            <listitem><para><emphasis><filename>debug-deps:</filename></emphasis>
+                Checks that <filename>-dbg</filename> packages only depend on other
+                <filename>-dbg</filename> packages and not on any other types of packages,
+                which would cause a packaging bug.</para></listitem>
+            <listitem><para><emphasis><filename>debug-files:</filename></emphasis>
+                Checks for <filename>.debug</filename> directories in anything but the
+                <filename>-dbg</filename> package.
+                The debug files should all be in the <filename>-dbg</filename> package.
+                Thus, anything packaged elsewhere is incorrect packaging.</para></listitem>
+            <listitem><para><emphasis><filename>dep-cmp:</filename></emphasis>
+                Checks for invalid version comparison statements in runtime
+                dependency relationships between packages (i.e. in
+                <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>,
+                <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>,
+                <link linkend='var-RSUGGESTS'><filename>RSUGGESTS</filename></link>,
+                <link linkend='var-RPROVIDES'><filename>RPROVIDES</filename></link>,
+                <link linkend='var-RREPLACES'><filename>RREPLACES</filename></link>,
+                and
+                <link linkend='var-RCONFLICTS'><filename>RCONFLICTS</filename></link>
+                variable values).
+                Any invalid comparisons might trigger failures or undesirable
+                behavior when passed to the package manager.
+                </para></listitem>
+            <listitem><para><emphasis><filename>desktop:</filename></emphasis>
+                Runs the <filename>desktop-file-validate</filename> program
+                against any <filename>.desktop</filename> files to validate
+                their contents against the specification for
+                <filename>.desktop</filename> files.</para></listitem>
+            <listitem><para><emphasis><filename>dev-deps:</filename></emphasis>
+                Checks that <filename>-dev</filename> packages only depend on other
+                <filename>-dev</filename> packages and not on any other types of packages,
+                which would be a packaging bug.</para></listitem>
+            <listitem><para><emphasis><filename>dev-so:</filename></emphasis>
+                Checks that the <filename>.so</filename> symbolic links are in the
+                <filename>-dev</filename> package and not in any of the other packages.
+                In general, these symlinks are only useful for development purposes.
+                Thus, the <filename>-dev</filename> package is the correct location for
+                them.
+                Some very rare cases do exist for dynamically loaded modules where
+                these symlinks are needed instead in the main package.
+                </para></listitem>
+            <listitem><para><emphasis><filename>files-invalid:</filename></emphasis>
+                Checks for
+                <link linkend='var-FILES'><filename>FILES</filename></link>
+                variable values that contain "//", which is invalid.
+                </para></listitem>
+            <listitem><para><emphasis><filename>incompatible-license:</filename></emphasis>
+                Report when packages are excluded from being created due to
+                being marked with a license that is in
+                <link linkend='var-INCOMPATIBLE_LICENSE'><filename>INCOMPATIBLE_LICENSE</filename></link>.
+                </para></listitem>
+            <listitem><para><emphasis><filename>install-host-path:</filename></emphasis>
+                Checks the <filename>do_install</filename> log for indications
+                that paths to locations on the build host were used.
+                Using such paths might result in host contamination of the
+                build output.
                 </para></listitem>
             <listitem><para><emphasis><filename>installed-vs-shipped:</filename></emphasis>
                 Reports when files have been installed within
@@ -1428,42 +1386,17 @@
                 <filename>do_install</filename> if the files are not
                 needed in any package.
                 </para></listitem>
-            <listitem><para><emphasis><filename>dep-cmp:</filename></emphasis>
-                Checks for invalid version comparison statements in runtime
-                dependency relationships between packages (i.e. in
-                <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>,
-                <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>,
-                <link linkend='var-RSUGGESTS'><filename>RSUGGESTS</filename></link>,
-                <link linkend='var-RPROVIDES'><filename>RPROVIDES</filename></link>,
-                <link linkend='var-RREPLACES'><filename>RREPLACES</filename></link>,
-                and
-                <link linkend='var-RCONFLICTS'><filename>RCONFLICTS</filename></link>
-                variable values).
-                Any invalid comparisons might trigger failures or undesirable
-                behavior when passed to the package manager.
-                </para></listitem>
-            <listitem><para><emphasis><filename>files-invalid:</filename></emphasis>
-                Checks for
-                <link linkend='var-FILES'><filename>FILES</filename></link>
-                variable values that contain "//", which is invalid.
-                </para></listitem>
-            <listitem><para><emphasis><filename>incompatible-license:</filename></emphasis>
-                Report when packages are excluded from being created due to
-                being marked with a license that is in
-                <link linkend='var-INCOMPATIBLE_LICENSE'><filename>INCOMPATIBLE_LICENSE</filename></link>.
-                </para></listitem>
-            <listitem><para><emphasis><filename>compile-host-path:</filename></emphasis>
-                Checks the <filename>do_compile</filename> log for indications
-                that paths to locations on the build host were used.
-                Using such paths might result in host contamination of the
-                build output.
-                </para></listitem>
-            <listitem><para><emphasis><filename>install-host-path:</filename></emphasis>
-                Checks the <filename>do_install</filename> log for indications
-                that paths to locations on the build host were used.
-                Using such paths might result in host contamination of the
-                build output.
-                </para></listitem>
+            <listitem><para><emphasis><filename>la:</filename></emphasis>
+                Checks <filename>.la</filename> files for any <filename>TMPDIR</filename>
+                paths.
+                Any <filename>.la</filename> file containing these paths is incorrect since
+                <filename>libtool</filename> adds the correct sysroot prefix when using the
+                files automatically itself.</para></listitem>
+            <listitem><para><emphasis><filename>ldflags:</filename></emphasis>
+                Ensures that the binaries were linked with the
+                <filename>LDFLAGS</filename> options provided by the build system.
+                If this test fails, check that the <filename>LDFLAGS</filename> variable
+                is being passed to the linker command.</para></listitem>
             <listitem><para><emphasis><filename>libdir:</filename></emphasis>
                 Checks for libraries being installed into incorrect
                 (possibly hardcoded) installation paths.
@@ -1474,6 +1407,13 @@
                 <filename>/usr/lib64/foo.so</filename> when
                 <filename>${libdir}</filename> is "/usr/lib".
                 </para></listitem>
+            <listitem><para><emphasis><filename>libexec:</filename></emphasis>
+                Checks if a package contains files in
+                <filename>/usr/libexec</filename>.
+                This check is not performed if the
+                <filename>libexecdir</filename> variable has been set
+                explicitly to <filename>/usr/libexec</filename>.
+                </para></listitem>
             <listitem><para><emphasis><filename>packages-list:</filename></emphasis>
                 Checks for the same package being listed multiple times through
                 the <link linkend='var-PACKAGES'><filename>PACKAGES</filename></link>
@@ -1493,12 +1433,45 @@
                 Reports lines in <filename>fs-perms.txt</filename> that
                 specify 'link' where the specified target already exists.
                 </para></listitem>
+            <listitem><para><emphasis><filename>perms:</filename></emphasis>
+                Currently, this check is unused but reserved.
+                </para></listitem>
+            <listitem><para><emphasis><filename>pkgconfig:</filename></emphasis>
+                Checks <filename>.pc</filename> files for any
+                <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>/<link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>
+                paths.
+                Any <filename>.pc</filename> file containing these paths is incorrect
+                since <filename>pkg-config</filename> itself adds the correct sysroot prefix
+                when the files are accessed.</para></listitem>
             <listitem><para><emphasis><filename>pkgname:</filename></emphasis>
                 Checks that all packages in
                 <link linkend='var-PACKAGES'><filename>PACKAGES</filename></link>
                 have names that do not contain invalid characters (i.e.
                 characters other than 0-9, a-z, ., +, and -).
                 </para></listitem>
+            <listitem><para><emphasis><filename>pkgv-undefined:</filename></emphasis>
+                Checks to see if the <filename>PKGV</filename> variable
+                is undefined during <filename>do_package</filename>.
+                </para></listitem>
+            <listitem><para><emphasis><filename>pkgvarcheck:</filename></emphasis>
+                Checks through the variables
+                <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>,
+                <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>,
+                <link linkend='var-RSUGGESTS'><filename>RSUGGESTS</filename></link>,
+                <link linkend='var-RCONFLICTS'><filename>RCONFLICTS</filename></link>,
+                <link linkend='var-RPROVIDES'><filename>RPROVIDES</filename></link>,
+                <link linkend='var-RREPLACES'><filename>RREPLACES</filename></link>,
+                <link linkend='var-FILES'><filename>FILES</filename></link>,
+                <link linkend='var-ALLOW_EMPTY'><filename>ALLOW_EMPTY</filename></link>,
+                <filename>pkg_preinst</filename>,
+                <filename>pkg_postinst</filename>,
+                <filename>pkg_prerm</filename>
+                and <filename>pkg_postrm</filename>, and reports if there are
+                variable sets that are not package-specific.
+                Using these variables without a package suffix is bad practice,
+                and might unnecessarily complicate dependencies of other packages
+                within the same recipe or have other unintended consequences.
+                </para></listitem>
             <listitem><para><emphasis><filename>pn-overrides:</filename></emphasis>
                 Checks that a recipe does not have a name
                 (<link linkend='var-PN'><filename>PN</filename></link>) value
@@ -1516,6 +1489,31 @@
                 <filename>FILES_${PN} = "xyz"</filename> effectively turn into
                 <filename>FILES = "xyz"</filename>.
                 </para></listitem>
+           <listitem><para><emphasis><filename>rpaths:</filename></emphasis>
+                Checks for rpaths in the binaries that contain build system paths such
+                as <filename>TMPDIR</filename>.
+                If this test fails, bad <filename>-rpath</filename> options are being
+                passed to the linker commands and your binaries have potential security
+                issues.</para></listitem>
+            <listitem><para><emphasis><filename>split-strip:</filename></emphasis>
+                Reports that splitting or stripping debug symbols from binaries
+                has failed.
+                </para></listitem>
+            <listitem><para><emphasis><filename>staticdev:</filename></emphasis>
+                Checks for static library files (<filename>*.a</filename>) in
+                non-<filename>staticdev</filename> packages.
+                </para></listitem>
+            <listitem><para><emphasis><filename>symlink-to-sysroot:</filename></emphasis>
+                Checks for symlinks in packages that point into
+                <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>
+                on the host.
+                Such symlinks will work on the host, but are clearly invalid
+                when running on the target.
+                </para></listitem>
+            <listitem><para><emphasis><filename>textrel:</filename></emphasis>
+                Checks for ELF binaries that contain relocations in their
+                <filename>.text</filename> sections, which can result in a
+                performance impact at runtime.</para></listitem>
             <listitem><para><emphasis><filename>unsafe-references-in-binaries:</filename></emphasis>
                 Reports when a binary installed in
                 <filename>${base_libdir}</filename>,
@@ -1558,6 +1556,12 @@
                     <filename>/usr</filename>.
                 </note>
                 </para></listitem>
+            <listitem><para><emphasis><filename>useless-rpaths:</filename></emphasis>
+                Checks for dynamic library load paths (rpaths) in the binaries that
+                by default on a standard system are searched by the linker (e.g.
+                <filename>/lib</filename> and <filename>/usr/lib</filename>).
+                While these paths will not cause any breakage, they do waste space and
+                are unnecessary.</para></listitem>
             <listitem><para><emphasis><filename>var-undefined:</filename></emphasis>
                 Reports when variables fundamental to packaging (i.e.
                 <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>,
@@ -1567,19 +1571,6 @@
                 <link linkend='var-PKGD'><filename>PKGD</filename></link>) are
                 undefined during <filename>do_package</filename>.
                 </para></listitem>
-            <listitem><para><emphasis><filename>pkgv-undefined:</filename></emphasis>
-                Checks to see if the <filename>PKGV</filename> variable
-                is undefined during <filename>do_package</filename>.
-                </para></listitem>
-            <listitem><para><emphasis><filename>buildpaths:</filename></emphasis>
-                Checks for paths to locations on the build host inside the
-                output files.
-                Currently, this test triggers too many false positives and
-                thus is not normally enabled.
-                </para></listitem>
-            <listitem><para><emphasis><filename>perms:</filename></emphasis>
-                Currently, this check is unused but reserved.
-                </para></listitem>
             <listitem><para><emphasis><filename>version-going-backwards:</filename></emphasis>
                 If Build History is enabled, reports when a package
                 being written out has a lower version than the previously
@@ -1595,6 +1586,20 @@
                     this situation.
                 </note>
                 </para></listitem>
+            <listitem><para><emphasis><filename>xorg-driver-abi:</filename></emphasis>
+                Checks that all packages containing Xorg drivers have ABI
+                dependencies.
+                The <filename>xserver-xorg</filename> recipe provides driver
+                ABI names.
+                All drivers should depend on the ABI versions that they have
+                been built against.
+                Driver recipes that include
+                <filename>xorg-driver-input.inc</filename>
+                or <filename>xorg-driver-video.inc</filename> will
+                automatically get these versions.
+                Consequently, you should only need to explicitly add
+                dependencies to binary driver recipes.
+                </para></listitem>
         </itemizedlist>
     </para>
 </section>
@@ -2896,14 +2901,6 @@
         to "disable".
     </para>
 
-    <note>
-        For Systemd-based images, include the following
-        in your <filename>local.conf</filename> file:
-        <literallayout class='monospaced'>
-     VIRTUAL-RUNTIME_initscripts = ""
-        </literallayout>
-    </note>
-
     <para>
         For more information on <filename>systemd</filename>, see the
         "<ulink url='&YOCTO_DOCS_DEV_URL;#selecting-an-initialization-manager'>Selecting an Initialization Manager</ulink>"
@@ -2942,12 +2939,8 @@
 
     <para>
         The <filename>testimage</filename> class supports running automated
-        tests against images.
+        tests against images using QEMU and on actual hardware.
         The class handles loading the tests and starting the image.
-        <note>
-            Currently, there is only support for running these tests
-            under QEMU.
-        </note>
     </para>
 
     <para>

documentation/ref-manual/ref-images.xml

@@ -61,10 +61,14 @@
             The image includes headers and libraries you can use in a host development
             environment.
             </para></listitem>
-        <listitem><para><emphasis><filename>core-image-minimal-initramfs</filename>:</emphasis>
+        <listitem><para id='images-core-image-minimal-initramfs'><emphasis><filename>core-image-minimal-initramfs</filename>:</emphasis>
             A <filename>core-image-minimal</filename> image that has the Minimal RAM-based
-            Initial Root Filesystem (<filename>initramfs</filename>) as part of the kernel,
+            Initial Root Filesystem (initramfs) as part of the kernel,
             which allows the system to find the first “init” program more efficiently.
+            See the
+            <link linkend='var-PACKAGE_INSTALL'><filename>PACKAGE_INSTALL</filename></link>
+            variable for additional information helpful when working with
+            initramfs images.
             </para></listitem>
         <listitem><para><emphasis><filename>core-image-minimal-mtdutils</filename>:</emphasis>
             A <filename>core-image-minimal</filename> image that has support
@@ -77,6 +81,15 @@
         <listitem><para><emphasis><filename>core-image-lsb</filename>:</emphasis>
             An image that conforms to the Linux Standard Base (LSB) specification.
             </para></listitem>
+        <listitem><para><emphasis><filename>core-image-testmaster</filename>:</emphasis>
+            A "master" image designed to be used for automated runtime testing.
+            Provides a "known good" image that is deployed to a separate
+            partition so that you can boot into it and use it to deploy a
+            second image to be tested.
+            You can find more information about runtime testing in the
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing'>Performing Automated Runtime Testing</ulink>"
+            section in the Yocto Project Development Manual.
+            </para></listitem>
         <listitem><para><emphasis><filename>core-image-lsb-dev</filename>:</emphasis>
             A <filename>core-image-lsb</filename> image that is suitable for development work
             using the host.

documentation/ref-manual/ref-manual.xml

@@ -79,7 +79,7 @@
             </revision>
             <revision>
                 <revnumber>1.6</revnumber>
-                <date>Sometime 2014</date>
+                <date>April 2014</date>
                 <revremark>Released with the Yocto Project 1.6 Release.</revremark>
             </revision>
         </revhistory>

documentation/ref-manual/ref-variables.xml

@@ -1431,7 +1431,15 @@
 
         <glossentry id='var-D'><glossterm>D</glossterm>
             <glossdef>
-                <para>The destination directory.</para>
+                <para>
+                    The destination directory.
+                    The location in the <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+                    where components are installed by the <filename>do_install</filename> task.
+                    This location defaults to:
+                    <literallayout class='monospaced'>
+     ${WORKDIR}/image
+                    </literallayout>
+                </para>
             </glossdef>
         </glossentry>
 
@@ -1609,6 +1617,56 @@
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-DISK_SIGNATURE'><glossterm>DISK_SIGNATURE</glossterm>
+            <glossdef>
+                <para>
+                    A 32-bit MBR disk signature used by
+                    <filename>directdisk</filename> images.
+                </para>
+
+                <para>
+                    By default, the signature is set to an automatically
+                    generated random value that allows the OpenEmbedded
+                    build system to create a boot loader.
+                    You can override the signature in the image recipe
+                    by setting <filename>DISK_SIGNATURE</filename> to an
+                    8-digit hex string.
+                    You might want to override
+                    <filename>DISK_SIGNATURE</filename> if you want the disk
+                    signature to remain constant between image builds.
+                </para>
+
+                <para>
+                    When using Linux 3.8 or later, you can use
+                    <filename>DISK_SIGNATURE</filename> to specify the root
+                    by UUID to allow the kernel to locate the root device
+                    even if the device name changes due to differences in
+                    hardware configuration.
+                    By default, <filename>SYSLINUX_ROOT</filename> is set
+                    as follows:
+                    <literallayout class='monospaced'>
+     SYSLINUX_ROOT = "root=/dev/sda2"
+                    </literallayout>
+                    However, you can change this to locate the root device
+                    using the disk signature instead:
+                    <literallayout class='monospaced'>
+     SYSLINUX_ROOT = "root=PARTUUID=${DISK_SIGNATURE}-02"
+                    </literallayout>
+                </para>
+
+                <para>
+                    As previously mentioned, it is possible to set the
+                    <filename>DISK_SIGNATURE</filename> variable in your
+                    <filename>local.conf</filename> file to a fixed
+                    value if you do not want <filename>syslinux.cfg</filename>
+                    changing for each build.
+                    You might find this useful when you want to upgrade the
+                    root filesystem on a device without having to recreate or
+                    modify the master boot record.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-DISTRO'><glossterm>DISTRO</glossterm>
             <glossdef>
                 <para>
@@ -2920,33 +2978,52 @@
             <glossdef>
                 <para>
                     Specifies the packages to install into an image.
-                    The <filename>IMAGE_INSTALL</filename> variable is a mechanism for an image
-                    recipe and you should use it with care to avoid ordering issues.
+                    The <filename>IMAGE_INSTALL</filename> variable is a
+                    mechanism for an image recipe and you should use it
+                    with care to avoid ordering issues.
+                    <note>
+                        When working with an
+                        <link linkend='images-core-image-minimal-initramfs'><filename>core-image-minimal-initramfs</filename></link>
+                        image, do not use the <filename>IMAGE_INSTALL</filename>
+                        variable to specify packages for installation.
+                        Instead, use the
+                        <link linkend='var-PACKAGE_INSTALL'><filename>PACKAGE_INSTALL</filename></link>
+                        variable, which allows the initial RAM disk (initramfs)
+                        recipe to use a fixed set of packages and not be
+                        affected by <filename>IMAGE_INSTALL</filename>.
+                    </note>
                 </para>
 
                 <para>
-                    Image recipes set <filename>IMAGE_INSTALL</filename> to specify the
-                    packages to install into an image through <filename>image.bbclass</filename>.
-                    Additionally, "helper" classes exist, such as <filename>core-image.bbclass</filename>,
-                    that can take
-                    <filename><link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></filename> lists
-                    and turn these into auto-generated entries in
-                    <filename>IMAGE_INSTALL</filename> in addition to its default contents.
+                    Image recipes set <filename>IMAGE_INSTALL</filename>
+                    to specify the packages to install into an image through
+                    <filename>image.bbclass</filename>.
+                    Additionally, "helper" classes exist, such as
+                    <filename>core-image.bbclass</filename>, that can take
+                    <filename><link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></filename>
+                    lists and turn these into auto-generated entries in
+                    <filename>IMAGE_INSTALL</filename> in addition to its
+                    default contents.
                 </para>
 
                 <para>
-                    Using <filename>IMAGE_INSTALL</filename> with the <filename>+=</filename>
-                    operator from the <filename>/conf/local.conf</filename> file or from within
-                    an image recipe is not recommended as it can cause ordering issues.
-                    Since <filename>core-image.bbclass</filename> sets <filename>IMAGE_INSTALL</filename>
-                    to a default value using the <filename>?=</filename> operator, using a
-                    <filename>+=</filename> operation against <filename>IMAGE_INSTALL</filename>
-                    will result in unexpected behavior when used in
+                    Using <filename>IMAGE_INSTALL</filename> with the
+                    <filename>+=</filename> operator from the
+                    <filename>/conf/local.conf</filename> file or from within
+                    an image recipe is not recommended as it can cause ordering
+                    issues.
+                    Since <filename>core-image.bbclass</filename> sets
+                    <filename>IMAGE_INSTALL</filename> to a default value using
+                    the <filename>?=</filename> operator, using a
+                    <filename>+=</filename> operation against
+                    <filename>IMAGE_INSTALL</filename> will result in
+                    unexpected behavior when used in
                     <filename>conf/local.conf</filename>.
-                    Furthermore, the same operation from within an image recipe may or may not
-                    succeed depending on the specific situation.
-                    In both these cases, the behavior is contrary to how most users expect
-                    the <filename>+=</filename> operator to work.
+                    Furthermore, the same operation from within an image
+                    recipe may or may not succeed depending on the specific
+                    situation.
+                    In both these cases, the behavior is contrary to how most
+                    users expect the <filename>+=</filename> operator to work.
                 </para>
 
                 <para>
@@ -2954,8 +3031,8 @@
                     <literallayout class='monospaced'>
      IMAGE_INSTALL_append = " package-name"
                     </literallayout>
-                    Be sure to include the space between the quotation character and the start of the
-                    package name or names.
+                    Be sure to include the space between the quotation character
+                    and the start of the package name or names.
                 </para>
             </glossdef>
         </glossentry>
@@ -3691,50 +3768,60 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
         <glossentry id='var-KBRANCH'><glossterm>KBRANCH</glossterm>
             <glossdef>
                 <para>
-                    A regular expression used by the build process to explicitly identify the kernel
-                    branch that is validated, patched and configured during a build.
+                    A regular expression used by the build process to explicitly
+                    identify the kernel branch that is validated, patched
+                    and configured during a build.
                     The <filename>KBRANCH</filename> variable is optional.
-                    You can use it to trigger checks to ensure the exact kernel branch you want is
-                    being used by the build process.
+                    You can use it to trigger checks to ensure the exact kernel
+                    branch you want is being used by the build process.
                 </para>
 
                 <para>
-                    Values for this variable are set in the kernel's recipe file and the kernel's
-                    append file.
-                    For example, if you are using the Yocto Project kernel that is based on the
-                    Linux 3.4 kernel, the kernel recipe file is the
-                    <filename>meta/recipes-kernel/linux/linux-yocto_3.4.bb</filename> file.
-                    Following is the default value for <filename>KBRANCH</filename> and the default
-                    override for the architectures the Yocto Project supports:
+                    Values for this variable are set in the kernel's recipe
+                    file and the kernel's append file.
+                    For example, if you are using the Yocto Project kernel that
+                    is based on the Linux 3.10 kernel, the kernel recipe file
+                    is the
+                    <filename>meta/recipes-kernel/linux/linux-yocto_3.10.bb</filename>
+                    file.
+                    Following is the default value for <filename>KBRANCH</filename>
+                    and the default override for the architectures the Yocto
+                    Project supports:
                     <literallayout class='monospaced'>
      KBRANCH_DEFAULT = "standard/base"
      KBRANCH = "${KBRANCH_DEFAULT}"
                     </literallayout>
-                    This branch exists in the <filename>linux-yocto-3.4</filename> kernel Git
-                    repository <ulink url='&YOCTO_GIT_URL;/cgit.cgi/linux-yocto-3.4/refs/heads'></ulink>.
+                    This branch exists in the <filename>linux-yocto-3.10</filename>
+                    kernel Git repository
+                    <ulink url='&YOCTO_GIT_URL;/cgit.cgi/linux-yocto-3.10/refs/heads'></ulink>.
                 </para>
 
                 <para>
-                    This variable is also used from the kernel's append file to identify the kernel
-                    branch specific to a particular machine or target hardware.
-                    The kernel's append file is located in the BSP layer for a given machine.
+                    This variable is also used from the kernel's append file
+                    to identify the kernel branch specific to a particular
+                    machine or target hardware.
+                    The kernel's append file is located in the BSP layer for
+                    a given machine.
                     For example, the kernel append file for the Crown Bay BSP is in the
                     <filename>meta-intel</filename> Git repository and is named
-                    <filename>meta-crownbay/recipes-kernel/linux/linux-yocto_3.4.bbappend</filename>.
+                    <filename>meta-crownbay/recipes-kernel/linux/linux-yocto_3.10.bbappend</filename>.
                     Here are the related statements from the append file:
                     <literallayout class='monospaced'>
      COMPATIBLE_MACHINE_crownbay = "crownbay"
-     KMACHINE_crownbay  = "crownbay"
-     KBRANCH_crownbay  = "standard/crownbay"
+     KMACHINE_crownbay = "crownbay"
+     KBRANCH_crownbay = "standard/crownbay"
+     KERNEL_FEATURES_append_crownbay = " features/drm-emgd/drm-emgd-1.18 cfg/vesafb"
 
      COMPATIBLE_MACHINE_crownbay-noemgd = "crownbay-noemgd"
-     KMACHINE_crownbay-noemgd  = "crownbay"
-     KBRANCH_crownbay-noemgd  = "standard/crownbay"
+     KMACHINE_crownbay-noemgd = "crownbay"
+     KBRANCH_crownbay-noemgd = "standard/crownbay"
+     KERNEL_FEATURES_append_crownbay-noemgd = " cfg/vesafb"
                     </literallayout>
-                        The <filename>KBRANCH_*</filename> statements identify the kernel branch to
-                        use when building for the Crown Bay BSP.
-                        In this case there are two identical statements: one for each type of
-                        Crown Bay machine.
+                        The <filename>KBRANCH_*</filename> statements identify
+                        the kernel branch to use when building for the Crown
+                        Bay BSP.
+                        In this case there are two identical statements: one
+                        for each type of Crown Bay machine.
                 </para>
             </glossdef>
         </glossentry>
@@ -4603,6 +4690,101 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-module_autoload'><glossterm>module_autoload</glossterm>
+            <glossdef>
+                <para>
+                    Lists kernel modules that need to be auto-loaded during
+                    boot.
+                </para>
+
+                <para>
+                    You can use this variable anywhere that it can be
+                    recognized by the kernel recipe or out-of-tree kernel
+                    module recipe (e.g. a machine configuration file, a
+                    distribution configuration file, an append file for the
+                    recipe, or the recipe itself).
+                </para>
+
+                <para>
+                    Specify it as follows:
+                    <literallayout class='monospaced'>
+     module_autoload_&lt;modname&gt; = "modname1 modname2 modname3"
+                    </literallayout>
+                    You must use the kernel module name override.
+                </para>
+
+                <para>
+                    Including <filename>module_autoload</filename> causes the
+                    OpenEmbedded build system to populate the
+                    <filename>/etc/modules-load.d/modname.conf</filename>
+                    file with the list of modules to be auto-loaded on boot.
+                    The modules appear one-per-line in the file.
+                    Here is an example of the most common use case:
+                    <literallayout class='monospaced'>
+     module_autoload_modname = "modname"
+                    </literallayout>
+                </para>
+
+                <para>
+                    For information on how to populate the
+                    <filename>modname.conf</filename> file with
+                    <filename>modprobe.d</filename> syntax lines, see the
+                    <link linkend='var-module_conf'><filename>module_conf</filename></link>
+                    variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-module_conf'><glossterm>module_conf</glossterm>
+            <glossdef>
+                <para>
+                    Specifies <filename>modprobe.d</filename> syntax lines
+                    for inclusion in the
+                    <filename>/etc/modprobe.d/modname.conf</filename> file.
+                </para>
+
+                <para>
+                    You can use this variable anywhere that it can be
+                    recognized by the kernel recipe or out-of-tree kernel
+                    module recipe (e.g. a machine configuration file, a
+                    distribution configuration file, an append file for the
+                    recipe, or the recipe itself).
+                </para>
+
+                <para>
+                    Here is the general syntax:
+                    <literallayout class='monospaced'>
+     module_conf_&lt;modname&gt; = "modprobe.d-syntax"
+                    </literallayout>
+                    You must use the kernel module name override.
+                </para>
+
+                <para>
+                    Run <filename>man modprobe.d</filename> in the shell to
+                    find out more information on the exact syntax for lines
+                    you want to provide with <filename>module_conf</filename>.
+                </para>
+
+                <para>
+                    Including <filename>module_conf</filename> causes the
+                    OpenEmbedded build system to populate the
+                    <filename>/etc/modprobe.d/modname.conf</filename>
+                    file with <filename>modprobe.d</filename> syntax lines.
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     module_conf_&lt;modname&gt; = "options modname arg1=val1 arg2=val2"
+                    </literallayout>
+                </para>
+
+                <para>
+                    For information on how to specify kernel modules to
+                    auto-load on boot, see the
+                    <link linkend='var-module_autoload'><filename>module_autoload</filename></link>
+                    variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-MODULE_IMAGE_BASE_NAME'><glossterm>MODULE_IMAGE_BASE_NAME</glossterm>
             <glossdef>
                 <para>
@@ -5049,18 +5231,25 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                 <para>
                     The final list of packages passed to the package manager
                     for installation into the image.
+                </para>
+
+                <para>
                     Because the package manager controls actual installation
                     of all packages, the list of packages passed using
                     <filename>PACKAGE_INSTALL</filename> is not the final list
                     of packages that are actually installed.
-                </para>
-
-                <para>
                     This variable is internal to the image construction
                     code.
-                    Use the
+                    Consequently, in general, you should use the
                     <link linkend='var-IMAGE_INSTALL'><filename>IMAGE_INSTALL</filename></link>
                     variable to specify packages for installation.
+                    The exception to this is when working with
+                    the
+                    <link linkend='images-core-image-minimal-initramfs'><filename>core-image-minimal-initramfs</filename></link>
+                    image.
+                    When working with an initial RAM disk (initramfs)
+                    image, use the <filename>PACKAGE_INSTALL</filename>
+                    variable.
                 </para>
             </glossdef>
         </glossentry>
@@ -7173,16 +7362,8 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
      SYSTEMD_AUTO_ENABLE ??= "enable"
                     </literallayout>
                     You can disable the service by setting the variable to
-                    "disable."
+                    "disable".
                 </para>
-
-                <note>
-                    For Systemd-based images, include the following
-                    in your <filename>local.conf</filename> file:
-                    <literallayout class='monospaced'>
-     VIRTUAL-RUNTIME_initscripts = ""
-                    </literallayout>
-                </note>
             </glossdef>
         </glossentry>
 
@@ -7206,14 +7387,6 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     or packages in which the build system can find the systemd
                     unit files.
                 </para>
-
-                <note>
-                    For Systemd-based images, include the following
-                    in your <filename>local.conf</filename> file:
-                    <literallayout class='monospaced'>
-     VIRTUAL-RUNTIME_initscripts = ""
-                    </literallayout>
-                </note>
             </glossdef>
         </glossentry>
 
@@ -7235,14 +7408,6 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
      SYSTEMD_SERVICE_${PN} = "connman.service"
                     </literallayout>
                 </para>
-
-                <note>
-                    For Systemd-based images, include the following
-                    in your <filename>local.conf</filename> file:
-                    <literallayout class='monospaced'>
-     VIRTUAL-RUNTIME_initscripts = ""
-                    </literallayout>
-                </note>
             </glossdef>
         </glossentry>
 
@@ -7399,15 +7564,41 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-TEST_EXPORT_DIR'><glossterm>TEST_EXPORT_DIR</glossterm>
+            <glossdef>
+                <para>
+                    The location the OpenEmbedded build system uses to export
+                    tests when the
+                    <link linkend='var-TEST_EXPORT_ONLY'><filename>TEST_EXPORT_ONLY</filename></link>
+                    variable is set to "1".
+                </para>
+
+                <para>
+                    The <filename>TEST_EXPORT_DIR</filename> variable defaults
+                    to <filename>"${TMPDIR}/testimage/${PN}"</filename>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TEST_EXPORT_ONLY'><glossterm>TEST_EXPORT_ONLY</glossterm>
+            <glossdef>
+                <para>
+                    Specifies to export the tests only.
+                    Set this variable to "1" if you do not want to run the
+                    tests but you want them to be exported in a manner that
+                    you to run them outside of the build system.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-TEST_IMAGE'><glossterm>TEST_IMAGE</glossterm>
             <glossdef>
                 <para>
                     Automatically runs the series of automated tests for
                     images when an image is successfully built.
-                    <note>
-                        Currently, there is only support for running these tests
-                        under QEMU.
-                    </note>
+                </para>
+
+                <para>
                     These tests are written in Python making use of the
                     <filename>unittest</filename> module, and the majority of
                     them run commands on the target system over
@@ -7430,6 +7621,21 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-TEST_LOG_DIR'><glossterm>TEST_LOG_DIR</glossterm>
+            <glossdef>
+                <para>
+                    Holds the SSH log and the boot log for QEMU machines.
+                    The <filename>TEST_LOG_DIR</filename> variable defaults
+                    to <filename>"${WORKDIR}/testimage"</filename>.
+                    <note>
+                        Actual test results reside in the task log
+                        (<filename>log.do_testimage</filename>), which is in
+                        the <filename>${WORKDIR}/temp/</filename> directory.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-TEST_QEMUBOOT_TIMEOUT'><glossterm>TEST_QEMUBOOT_TIMEOUT</glossterm>
             <glossdef>
                 <para>
@@ -7450,6 +7656,115 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-TEST_SERVER_IP'><glossterm>TEST_SERVER_IP</glossterm>
+            <glossdef>
+                <para>
+                    The IP address of the build machine (host machine).
+                    This IP address is usually automatically detected.
+                    However, if detection fails, this variable needs to be set
+                    to the IP address of the build machine (i.e. where
+                    the build is taking place).
+                    <note>
+                        The <filename>TEST_SERVER_IP</filename> variable
+                        is only used for a small number of tests such as
+                        the "smart" test suite, which needs to download
+                        packages from <filename>DEPLOY_DIR/rpm</filename>.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TEST_TARGET'><glossterm>TEST_TARGET</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the target controller to use when running tests
+                    against a test image.
+                    The default controller to use is "qemu":
+                    <literallayout class='monospaced'>
+     TEST_TARGET = "qemu"
+                    </literallayout>
+                    A target controller is a class that defines how an
+                    image gets deployed on a target and how a target is started.
+                    A layer can extend the controllers by adding a module
+                    in the layer's <filename>/lib/oeqa/controllers</filename>
+                    directory and by inheriting the
+                    <filename>BaseTarget</filename> class, which is an abstract
+                    class that cannot be used as a value of
+                    <filename>TEST_TARGET</filename>.
+                </para>
+
+                <para>
+                    You can provide the following arguments with
+                    <filename>TEST_TARGET</filename>:
+                    <itemizedlist>
+                        <listitem><para><emphasis>"qemu" and "QemuTarget":</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 Manual for
+                            more information.
+                            </para></listitem>
+                        <listitem><para><emphasis>"simpleremote" and "SimpleRemoteTarget":</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 "simpleremote" or "SimpleRemoteTarget".
+                            <note>
+                                This argument is defined in
+                                <filename>meta/lib/oeqa/targetcontrol.py</filename>.
+                                The small caps names are kept for compatibility
+                                reasons.
+                            </note>
+                            </para></listitem>
+                        <listitem><para><emphasis>"GummibootTarget":</emphasis>
+                            Automatically deploys and runs tests on an
+                            EFI-enabled machine that has a master image
+                            installed.
+                            <note>
+                                This argument is defined in
+                                <filename>meta/lib/oeqa/controllers/masterimage.py</filename>.
+                            </note>
+                            </para></listitem>
+                    </itemizedlist>
+                </para>
+
+                <para>
+                    For information on running tests on hardware, see the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#hardware-image-enabling-tests'>Enabling Runtime Tests on Hardware</ulink>"
+                    section in the Yocto Project Development Manual.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TEST_TARGET_IP'><glossterm>TEST_TARGET_IP</glossterm>
+            <glossdef>
+                <para>
+                    The IP address of your hardware under test.
+                    The <filename>TEST_TARGET_IP</filename> variable has no
+                    effect when
+                    <link linkend='var-TEST_TARGET'><filename>TEST_TARGET</filename></link>
+                    is set to "qemu".
+                </para>
+
+                <para>
+                    When you specify the IP address, you can also include a
+                    port.
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     TEST_TARGET_IP = "192.168.1.4:2201"
+                    </literallayout>
+                    Specifying a port is useful when SSH is started on a
+                    non-standard port or in cases when your hardware under test
+                    is behind a firewall or network that is not directly
+                    accessible from your host and you need to do port address
+                    translation.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-TEST_SUITES'><glossterm>TEST_SUITES</glossterm>
             <glossdef>
                 <para>

documentation/yocto-project-qs/yocto-project-qs.xml

@@ -827,7 +827,7 @@
             </para>
         </footnote>
         gives you a minimal description of how to use the Yocto Project to build
-        images for a BeagleBoard xM starting from scratch.
+        images for Beaglebone hardware starting from scratch.
         The steps were performed on a 64-bit Ubuntu 12.04 system that
         has four cores.
     </para>
@@ -893,7 +893,7 @@
             <literallayout class='monospaced'>
      BB_NUMBER_THREADS = "8"
      PARALLEL_MAKE = "-j 8"
-     MACHINE ?= "beagleboard"
+     MACHINE ?= "beaglebone"
             </literallayout>
             Briefly, set
             <ulink url='&YOCTO_DOCS_REF_URL;#var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></ulink>
@@ -949,7 +949,7 @@
 
         <para>
             At this point, you need to select an image to build for the
-            BeagleBoard xM.
+            Beaglebone hardware.
             If this is your first build using the Yocto Project, you should try
             the smallest and simplest image:
             <literallayout class='monospaced'>

meta-yocto/conf/distro/include/distro_alias.inc

@@ -15,13 +15,12 @@ DISTRO_PN_ALIAS_pn-adt-installer = "Intel"
 DISTRO_PN_ALIAS_pn-alsa-state = "OE-Core"
 DISTRO_PN_ALIAS_pn-alsa-utils-alsaconf = "OE-Core"
 DISTRO_PN_ALIAS_pn-atk = "Fedora=atk OpenSuSE=atk"
-DISTRO_PN_ALIAS_pn-atk-native = "Fedora=atk OpenSuSE=atk"
 DISTRO_PN_ALIAS_pn-augeas = "Ubuntu=libaugeas0 Debian=libaugeas0"
 DISTRO_PN_ALIAS_pn-avahi-ui = "Ubuntu=avahi-discover Debian=avahi-discover"
 DISTRO_PN_ALIAS_pn-babeltrace = "OSPDT"
 DISTRO_PN_ALIAS_pn-bdwgc = "OSPDT"
 DISTRO_PN_ALIAS_pn-bigreqsproto = "Meego=xorg-x11-proto-bigreqsproto"
-DISTRO_PN_ALIAS_pn-bjam-native = "OpenSuSE=boost-jam Debina=bjam"
+DISTRO_PN_ALIAS_pn-bjam = "OpenSuSE=boost-jam Debina=bjam"
 DISTRO_PN_ALIAS_pn-blktool = "Debian=blktool Mandriva=blktool"
 DISTRO_PN_ALIAS_pn-bluez4 = "Ubuntu=bluez Debian=bluez-utils"
 DISTRO_PN_ALIAS_pn-bluez5 = "Fedora=bluez  Opensuse=bluez"
@@ -32,7 +31,7 @@ DISTRO_PN_ALIAS_pn-builder = "OE-Core"
 DISTRO_PN_ALIAS_pn-buildtools-tarball = "OE-Core"
 DISTRO_PN_ALIAS_pn-calibrateproto = "OSPDT upstream=http://cgit.freedesktop.org/xorg/proto/calibrateproto"
 DISTRO_PN_ALIAS_pn-cdrtools = "OpenSUSE=cdrtools OSPDT"
-DISTRO_PN_ALIAS_pn-chkconfig-alternatives-native = "Mandriva=chkconfig Debian=chkconfig"
+DISTRO_PN_ALIAS_pn-chkconfig-alternatives = "Mandriva=chkconfig Debian=chkconfig"
 DISTRO_PN_ALIAS_pn-claws-plugin-gtkhtml2-viewer = "Fedora=claws-mail-plugins OpenSuSE=claws-mail-extra-plugins Debian=claws-mail-extra-plugins"
 DISTRO_PN_ALIAS_pn-claws-plugin-maildir = "Fedora=claws-mail-plugins OpenSuSE=claws-mail-extra-plugins Debian=claws-mail-extra-plugins"
 DISTRO_PN_ALIAS_pn-claws-plugin-mailmbox = "Fedora=claws-mail-plugins OpenSuSE=claws-mail-extra-plugins Debian=claws-mail-extra-plugins"
@@ -71,6 +70,7 @@ DISTRO_PN_ALIAS_pn-core-image-sato-sdk = "OE-Core"
 DISTRO_PN_ALIAS_pn-core-image-weston = "OE-Core"
 DISTRO_PN_ALIAS_pn-core-image-x11 = "OE-Core"
 DISTRO_PN_ALIAS_pn-cross-localedef = "OSPDT"
+DISTRO_PN_ALIAS_pn-cryptodev-linux = "OE-Core"
 DISTRO_PN_ALIAS_pn-cwautomacros = "OSPDT upstream=http://cwautomacros.berlios.de/"
 DISTRO_PN_ALIAS_pn-damageproto = "Meego=xorg-x11-proto-damageproto"
 DISTRO_PN_ALIAS_pn-db = "Debian=db5.1 Ubuntu=db5.1"
@@ -88,7 +88,6 @@ DISTRO_PN_ALIAS_pn-docbook-sgml-dtd-4.5 = "Fedora=docbook-dtds Mandriva=docbook-
 DISTRO_PN_ALIAS_pn-dri2proto = "Meego=xorg-x11-proto-dri2proto"
 DISTRO_PN_ALIAS_pn-dropbear = "Debian=dropbear Ubuntu=dropbear"
 DISTRO_PN_ALIAS_pn-dtc = "Fedora=dtc Ubuntu=dtc"
-DISTRO_PN_ALIAS_pn-dtc-native = "Fedora=dtc Ubuntu=dtc"
 DISTRO_PN_ALIAS_pn-eds-tools = "OpenedHand"
 DISTRO_PN_ALIAS_pn-eee-acpi-scripts = "Debian=eeepc-acpi-scripts Ubuntu=eeepc-acpi-scripts"
 DISTRO_PN_ALIAS_pn-eglibc = "OE-Core"
@@ -118,13 +117,15 @@ DISTRO_PN_ALIAS_pn-gccmakedep = "Mandriva=gccmakedep Ubuntu=xutils-dev"
 DISTRO_PN_ALIAS_pn-gcc-runtime = "Ubuntu=gcc Fedora=gcc"
 DISTRO_PN_ALIAS_pn-gconf-dbus = "Meego=GConf-dbus"
 DISTRO_PN_ALIAS_pn-gdk-pixbuf = "Debian=libgdk-pixbuf2.0 Fedora=gdk-pixbuf"
-DISTRO_PN_ALIAS_pn-gdk-pixbuf-csource-native = "Debian=libgdk-pixbuf2.0-0 Fedora=gdk-pixbuf2"
-DISTRO_PN_ALIAS_pn-gettext-minimal-native = "Debian=gettext Fedora=gettext"
+DISTRO_PN_ALIAS_pn-gdk-pixbuf-csource = "Debian=libgdk-pixbuf2.0-0 Fedora=gdk-pixbuf2"
+DISTRO_PN_ALIAS_pn-gettext-minimal = "Debian=gettext Fedora=gettext"
 DISTRO_PN_ALIAS_pn-glib-2.0 = "Meego=glib2 Fedora=glib2 OpenSuSE=glib2 Ubuntu=glib2.0 Mandriva=glib2.0 Debian=glib2.0"
 DISTRO_PN_ALIAS_pn-glproto = "Meego=xorg-x11-proto-glproto"
+DISTRO_PN_ALIAS_pn-gnome-desktop-testing = "Debian=gnome-desktop-testing Fedora=gnome-desktop-testing"
 DISTRO_PN_ALIAS_pn-gnu-config = "OpenedHand"
-DISTRO_PN_ALIAS_pn-grub-efi-i586 = "Ubuntu=grub Fedora=grub"
-DISTRO_PN_ALIAS_pn-grub-efi-x86-64-native = "Ubuntu=grub Fedora=grub"
+DISTRO_PN_ALIAS_pn-grub-efi = "Debian=grub-efi Fedora=grub2-efi"
+DISTRO_PN_ALIAS_pn-grub-efi-i586 = "Debian=grub-efi Fedora=grub2-efi"
+DISTRO_PN_ALIAS_pn-grub-efi-x86-64 = "Debian=grub-efi Fedora=grub2-efi"
 DISTRO_PN_ALIAS_pn-gst-ffmpeg = "Mandriva=gstreamer0.10-ffmpeg Debian=gstreamer0.10-ffmpeg"
 DISTRO_PN_ALIAS_pn-gst-fluendo-mp3 = "Debian=gstreamer0.10-fluendo-mp3 Ubuntu=gstreamer0.10-fluendo-mp3"
 DISTRO_PN_ALIAS_pn-gst-fluendo-mpegdemux = "Ubuntu=gstreamer0.10-fluendo-mpegdemux Debian=gstreamer0.10-fluendo-mpegdemux"
@@ -137,6 +138,7 @@ DISTRO_PN_ALIAS_pn-gst-plugins-gl = "Debian=gstreamer0.10-plugins-gl OpenSuSE=gs
 DISTRO_PN_ALIAS_pn-gst-plugins-good = "Meego=gst-plugins-good Fedora=gstreamer-plugins-good OpenSuSE=gstreamer-plugins-good Ubuntu=gst-plugins-good0.10 Mandriva=gstreamer0.10-plugins-good Debian=gst-plugins-good0.10"
 DISTRO_PN_ALIAS_pn-gst-plugins-ugly = "OpenSuSE=gstreamer-plugins-ugly Mandriva=gstreamer0.10-plugins-ugly Debian=gst-plugins-ugly0.10"
 DISTRO_PN_ALIAS_pn-gstreamer1.0 = "Debian=gstreamer1.0 Ubuntu=gstreamer1.0"
+DISTRO_PN_ALIAS_pn-gstreamer1.0-meta-base = "Meego=gstreamer Fedora=gstreamer OpenSuSE=gstreamer Ubuntu=gstreamer0.10"
 DISTRO_PN_ALIAS_pn-gstreamer1.0-plugins-bad = "Debian=gstreamer1.0-plugins-bad Ubuntu=gstreamer1.0-plugins-bad"
 DISTRO_PN_ALIAS_pn-gstreamer1.0-plugins-base = "Debian=gstreamer1.0-plugins-base Ubuntu=gstreamer1.0-plugins-base"
 DISTRO_PN_ALIAS_pn-gstreamer1.0-plugins-good = "Debian=gstreamer1.0-plugins-good Ubuntu=gstreamer1.0-plugins-bad"
@@ -148,6 +150,7 @@ DISTRO_PN_ALIAS_pn-gtk-engines = "Fedora=gtk2-engines OpenSuSE=gtk2-engines Ubun
 DISTRO_PN_ALIAS_pn-gtk-sato-engine = "OpenedHand"
 DISTRO_PN_ALIAS_pn-gtk-theme-torturer = "OSPDT upstream=http://wiki.laptop.org/go/GTK_for_OLPC"
 DISTRO_PN_ALIAS_pn-gtk-update-icon-cache-native = "OSPDT"
+DISTRO_PN_ALIAS_pn-gummiboot = "Debian=gummiboot Fedora=gummiboot"
 DISTRO_PN_ALIAS_pn-hello-mod = "OE-Core"
 DISTRO_PN_ALIAS_pn-hostap-conf = "OE-Core"
 DISTRO_PN_ALIAS_pn-hwlatdetect = "OSPDT"
@@ -158,6 +161,8 @@ DISTRO_PN_ALIAS_pn-initramfs-framework = "OE-Core"
 DISTRO_PN_ALIAS_pn-initramfs-live-boot = "OE-Core"
 DISTRO_PN_ALIAS_pn-initramfs-live-install = "OE-Core"
 DISTRO_PN_ALIAS_pn-initramfs-live-install-efi = "OE-Core"
+DISTRO_PN_ALIAS_pn-initramfs-live-install-efi-testfs = "OE-Core"
+DISTRO_PN_ALIAS_pn-initramfs-live-install-testfs = "OE-Core"
 DISTRO_PN_ALIAS_pn-initscripts = "Fedora=initscripts Mandravia=initscripts"
 DISTRO_PN_ALIAS_pn-inputproto = "Meego=xorg-x11-proto-inputproto"
 DISTRO_PN_ALIAS_pn-iproute2 = "OSPDT"
@@ -194,8 +199,9 @@ DISTRO_PN_ALIAS_pn-libi18n-collate-perl = "OSPDT"
 DISTRO_PN_ALIAS_pn-libical = "Ubuntu=libical Fedora=libical"
 DISTRO_PN_ALIAS_pn-libiconv = "Fedora=mingw-libiconv Opensuse=cross-mingw-libiconv"
 DISTRO_PN_ALIAS_pn-libjson = "Ubuntu=libjson0-dev Debian=libjson0-dev"
-DISTRO_PN_ALIAS_pn-libksba = "Fedora=libksba Debian=libksba8"
+DISTRO_PN_ALIAS_pn-libksba = "Fedora=libksba Debian=libksba8 Ubuntu=libksba"
 DISTRO_PN_ALIAS_pn-liblbxutil = "Mandriva=liblbxutil OpenSuse=xorg-x11-devel"
+DISTRO_PN_ALIAS_pn-libmatchbox = "Ubuntu=libmatchbox Fedora=libmatchbox"
 DISTRO_PN_ALIAS_pn-libmpc = "Fedora=libmpc OpenSuse=libmpc2"
 DISTRO_PN_ALIAS_pn-libnewt = "Debian=libnewt0.52 Fedora=newt"
 DISTRO_PN_ALIAS_pn-libnewt-python = "Ubuntu=python-newt Fedora=newt-python"
@@ -217,13 +223,13 @@ DISTRO_PN_ALIAS_pn-libtelepathy = "Debian=libtelepathy2 Ubuntu=libtelepathy2"
 DISTRO_PN_ALIAS_pn-libtimedate-perl = "Debian=libtimedate-perl Ubuntu=libtimedate-perl"
 DISTRO_PN_ALIAS_pn-liburcu = "Fedora=userspace-rcu Ubuntu=liburcu0"
 DISTRO_PN_ALIAS_pn-libusb1 = "Debian=libusb-1.0-0 Fedora=libusb1"
-DISTRO_PN_ALIAS_pn-libusb1-native = "Debian=libusb-1.0-0 Fedora=libusb1"
 DISTRO_PN_ALIAS_pn-libusb-compat = "OSPDT"
 DISTRO_PN_ALIAS_pn-libx11 = "Debian=libx11-6 Fedora=libX11 Ubuntu=libx11-6 OpenSuSE=xorg-x11-libX11"
 DISTRO_PN_ALIAS_pn-libx11-diet = "Debian=libx11-6 Fedora=libX11 Ubuntu=libx11-6 OpenSuSE=xorg-x11-libX11"
 DISTRO_PN_ALIAS_pn-libxcalibrate = "OSPDT upstream=http://cgit.freedesktop.org/xorg/lib/libXCalibrate/"
 DISTRO_PN_ALIAS_pn-libxfontcache = "Mandriva=libxfontcache Debian=libxfontcache"
 DISTRO_PN_ALIAS_pn-libxft = "Mandriva=libxft Debian=libxft2 Ubuntu=libxft2"
+DISTRO_PN_ALIAS_pn-libxi = "Ubuntu=libxi Fedora=libXi"
 DISTRO_PN_ALIAS_pn-libxkbcommon = "Fedora=libxkbcommon Debian=libxkbcommon"
 DISTRO_PN_ALIAS_pn-libxprintapputil = "Debian=libxprintapputil Ubuntu=libxprintapputil1 Mandriva=libxprintapputil"
 DISTRO_PN_ALIAS_pn-libxscrnsaver = "Fedora=libXScrnSaver Ubuntu=libxss1 Mandriva=libxscrnsaver"
@@ -243,8 +249,8 @@ DISTRO_PN_ALIAS_pn-ltp = "Mandriva=ltp Ubuntu=ltp"
 DISTRO_PN_ALIAS_pn-lttng-modules = "OSPDT upstream=http://lttng.org/"
 DISTRO_PN_ALIAS_pn-lttng-tools = "OSPDT upstream=http://lttng.org/"
 DISTRO_PN_ALIAS_pn-lttng-ust = "OSPDT upstream=http://lttng.org/"
+DISTRO_PN_ALIAS_pn-lz4 = "Debian=lz4 Fedora=lz4"
 DISTRO_PN_ALIAS_pn-lzo = "Debian=liblzo Ubuntu=liblzo Fedora=lzp"
-DISTRO_PN_ALIAS_pn-lzo-native = "Debian=liblzo Ubuntu=liblzo Fedora=lzp"
 DISTRO_PN_ALIAS_pn-mailx = "Debian=bsd-mailx Ubuntu=bsd-mailx"
 DISTRO_PN_ALIAS_pn-makedepend = "Mandriva=makedepend Ubuntu=xutils-dev"
 DISTRO_PN_ALIAS_pn-makedevs = "OE-Core"
@@ -265,7 +271,7 @@ DISTRO_PN_ALIAS_pn-matchbox-wm-2 = "Mandriva=matchbox-window-manager Debian=matc
 DISTRO_PN_ALIAS_pn-menu-cache = "OSPDT"
 DISTRO_PN_ALIAS_pn-mesa = "Fedora=mesa Ubuntu=libgl1-mesa-dri"
 DISTRO_PN_ALIAS_pn-mesa-gl = "Fedora=mesa Ubuntu=libgl1-mesa-dri"
-DISTRO_PN_ALIAS_pn-mesa-glsl-native = "Fedora=mesa Ubuntu=libgl1-mesa-dri"
+DISTRO_PN_ALIAS_pn-mesa-glsl = "Fedora=mesa Ubuntu=libgl1-mesa-dri"
 DISTRO_PN_ALIAS_pn-meta-environment-i586 = "OE-Core"
 DISTRO_PN_ALIAS_pn-meta-environment-qemux86 = "OE-Core"
 DISTRO_PN_ALIAS_pn-meta-environment-qemux86-64 = "OE-Core"
@@ -277,6 +283,7 @@ DISTRO_PN_ALIAS_pn-mini-x-session = "OSPDT"
 DISTRO_PN_ALIAS_pn-mkfontdir = "Mandriva=mkfontdir Ubuntu=xfonts-utils Fedora=xorg-x11-font-utils"
 DISTRO_PN_ALIAS_pn-mkfontscale = "Mandriva=mkfontscale Ubuntu=xfonts-utils Fedora=xorg-x11-font-utils"
 DISTRO_PN_ALIAS_pn-mktemp = "Mandriva=mktemp Fedora=mktemp"
+DISTRO_PN_ALIAS_pn-mmc-utils = "OE-Core"
 DISTRO_PN_ALIAS_pn-moblin-proto = "OE-Core"
 DISTRO_PN_ALIAS_pn-modutils-collateral = "OE-Core"
 DISTRO_PN_ALIAS_pn-modutils-initscripts = "OE-Core"
@@ -284,12 +291,6 @@ DISTRO_PN_ALIAS_pn-msynctool = "OpenSuse=msynctool Mandriva=msynctool"
 DISTRO_PN_ALIAS_pn-mtd-utils = "Debian=mtd-utils Ubuntu=mtd-utils"
 DISTRO_PN_ALIAS_pn-mx-1.0 = "Ubuntu=mx Debian=mx Fedora=mx"
 DISTRO_PN_ALIAS_pn-n450-audio = "Intel"
-DISTRO_PN_ALIAS_pn-nativesdk-libusb1 = "Debian=libusb-1.0-0 Fedora=libusb1"
-DISTRO_PN_ALIAS_pn-nativesdk-lzo = "Debian=liblzo Ubuntu=liblzo Fedora=lzp"
-DISTRO_PN_ALIAS_pn-nativesdk-packagegroup-qt-toolchain-host = "OE-Core"
-DISTRO_PN_ALIAS_pn-nativesdk-pkgconfig = "Ubuntu=pkg-config Fedora=pkgconfig"
-DISTRO_PN_ALIAS_pn-nativesdk-python-git = "Debian=python-git Fedora=GitPython"
-DISTRO_PN_ALIAS_pn-nativesdk-readline = "Fedora=readline Ubuntu=readline-common"
 DISTRO_PN_ALIAS_pn-neard = "Intel"
 DISTRO_PN_ALIAS_pn-network-suspend-scripts = "OE-Core"
 DISTRO_PN_ALIAS_pn-nfs-export-root = "OpenedHand"
@@ -303,18 +304,19 @@ DISTRO_PN_ALIAS_pn-opkg-collateral = "OE-Core"
 DISTRO_PN_ALIAS_pn-opkg-config-base = "OE-Core"
 DISTRO_PN_ALIAS_pn-opkg-nogpg = "OSPDT upstream=http://svn.openmoko.org/trunk/src/tar"
 DISTRO_PN_ALIAS_pn-opkg-utils = "OSPDT upstream=http://svn.openmoko.org/trunk/src/target/opkg/"
+DISTRO_PN_ALIAS_pn-oprofile = "Debian=oprofile Fedora=oprofile"
 DISTRO_PN_ALIAS_pn-oprofileui = "Fedora=oprofileui Ubuntu=oprofile-gui Debian=oprofile-gui"
 DISTRO_PN_ALIAS_pn-oprofileui-server = "Fedora=oprofileui Ubuntu=oprofile-gui Debian=oprofile-gui"
 DISTRO_PN_ALIAS_pn-owl-video = "OpenedHand"
 DISTRO_PN_ALIAS_pn-packagegroup-base = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-core = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-full-cmdline = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-core-boot = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-core-buildessential = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-core-clutter = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-core-device-devel = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-core-directfb = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-core-eclipse-debug = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-full-cmdline = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-core-lsb = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-core-nfs = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-core-qt = "OE-Core"
@@ -338,27 +340,31 @@ DISTRO_PN_ALIAS_pn-packagegroup-cross-canadian-qemux86-64 = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-qt4e = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-qte-toolchain-host = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-qte-toolchain-target = "Intel"
+DISTRO_PN_ALIAS_pn-packagegroup-qt-toolchain-host = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-qt-toolchain-target = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-sdk-host = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-self-hosted = "OE-Core"
 DISTRO_PN_ALIAS_pn-package-index = "OE-Core"
 DISTRO_PN_ALIAS_pn-perf = "OSPDT"
+DISTRO_PN_ALIAS_pn-piglit = "OE-Core"
 DISTRO_PN_ALIAS_pn-pkgconfig = "Ubuntu=pkg-config Fedora=pkgconfig"
-DISTRO_PN_ALIAS_pn-pkgconfig-native = "Ubuntu=pkg-config Fedora=pkgconfig"
 DISTRO_PN_ALIAS_pn-pointercal = "OE-Core"
 DISTRO_PN_ALIAS_pn-pointercal-xinput = "OE-Core"
 DISTRO_PN_ALIAS_pn-poky-feed-config-opkg = "OE-Core"
 DISTRO_PN_ALIAS_pn-pong-clock = "OpenedHand"
 DISTRO_PN_ALIAS_pn-portmap = "Debian=rpcbind Fedora=rpcbind"
+DISTRO_PN_ALIAS_pn-postinst-intercept = "OE-Core"
 DISTRO_PN_ALIAS_pn-powertop = "Meego=powertop Fedora=powertop Debian=powertop OpenSuSE=powertop Mandriva=powertop"
 DISTRO_PN_ALIAS_pn-ppp-dialin = "OE-Core"
+DISTRO_PN_ALIAS_pn-presentproto = "Debian=x11proto-present-dev Fedora=xorg-x11-proto-devel"
 DISTRO_PN_ALIAS_pn-printproto = "Debian=x11proto-print-dev Ubuntu=x11proto-print-dev Mandriva=x11-proto-devel"
 DISTRO_PN_ALIAS_pn-pseudo = "Windriver"
 DISTRO_PN_ALIAS_pn-psplash = "OpenedHand"
 DISTRO_PN_ALIAS_pn-ptest-runner = "OE-Core"
 DISTRO_PN_ALIAS_pn-puzzles = "Debian=sgt-puzzles Fedora=puzzles"
+DISTRO_PN_ALIAS_pn-python3-distribute = "Debian=python3-setuptools Fedora=python3-setuptools"
+DISTRO_PN_ALIAS_pn-python-ZSI = "OE-Core"
 DISTRO_PN_ALIAS_pn-python-argparse = "Fedora=python-argparse OpenSuSE=python-argparse"
-DISTRO_PN_ALIAS_pn-python-argparse-native = "Fedora=python-argparse OpenSuSE=python-argparse"
 DISTRO_PN_ALIAS_pn-python-dbus = "Ubuntu=python-dbus Debian=python-dbus Mandriva=python-dbus"
 DISTRO_PN_ALIAS_pn-python-git = "Debian=python-git Fedora=GitPython"
 DISTRO_PN_ALIAS_pn-python-gst = "OpenSuSE=python-gstreamer Ubuntu=gst0.10-python Debian=gst0.10-python"
@@ -370,18 +376,15 @@ DISTRO_PN_ALIAS_pn-python-pyrex = "Mandriva=python-pyrex Ubuntu=python-pyrex"
 DISTRO_PN_ALIAS_pn-python-scons = "Fedora=scons OpenSuSE=scons Ubuntu=scons Mandriva=scons Debian=scons"
 DISTRO_PN_ALIAS_pn-python-setuptools = "Mandriva=python-setup OpenSuSE=python-setup-git"
 DISTRO_PN_ALIAS_pn-python-smartpm = "Debian=smart OpenSuSE=smart"
-DISTRO_PN_ALIAS_pn-python-ZSI = "OE-Core"
 DISTRO_PN_ALIAS_pn-qemu-config = "OpenedHand"
 DISTRO_PN_ALIAS_pn-qemugl = "OpenedHand"
 DISTRO_PN_ALIAS_pn-qemu-helper = "OpenedHand"
-DISTRO_PN_ALIAS_pn-qemu-helper-native = "OpenedHand"
-DISTRO_PN_ALIAS_pn-qemu-helper-nativesdk = "OpenedHand"
 DISTRO_PN_ALIAS_pn-qemuwrapper-cross = "OE-Core"
 DISTRO_PN_ALIAS_pn-qmmp = "Fedora=qmmp Debian=qmmp"
+DISTRO_PN_ALIAS_pn-qt4 = "Mandriva=libqt4-devel Ubuntu=libqt4-dev"
 DISTRO_PN_ALIAS_pn-qt4e-demo-image = "OE-Core"
 DISTRO_PN_ALIAS_pn-qt4-embedded = "OSPDT"
 DISTRO_PN_ALIAS_pn-qt4-graphics-system = "OE-Core"
-DISTRO_PN_ALIAS_pn-qt4-native = "Mandriva=libqt4-devel Ubuntu=libqt4-dev"
 DISTRO_PN_ALIAS_pn-qt4-tools = "Mandriva=libqt4-devel Ubuntu=libqt4-dev"
 DISTRO_PN_ALIAS_pn-qt4-x11-free = "Ubuntu=qt-x11-free Debian=qt-x11-free"
 DISTRO_PN_ALIAS_pn-qt-demo-init = "OE-Core"
@@ -390,7 +393,6 @@ DISTRO_PN_ALIAS_pn-qt-mobility-x11 = "Ubuntu=qtmobility-dev Debian=qtmobility-de
 DISTRO_PN_ALIAS_pn-quicky = "OSPDT"
 DISTRO_PN_ALIAS_pn-randrproto = "Meego=xorg-x11-proto-randrproto"
 DISTRO_PN_ALIAS_pn-readline = "Fedora=readline Debian=readline-common"
-DISTRO_PN_ALIAS_pn-readline-native = "Fedora=readline Debian=readline-common"
 DISTRO_PN_ALIAS_pn-recordproto = "Meego=xorg-x11-proto-recordproto"
 DISTRO_PN_ALIAS_pn-remake = "Mandriva=remake Debian=remake"
 DISTRO_PN_ALIAS_pn-renderproto = "Meego=xorg-x11-proto-renderproto"
@@ -406,24 +408,23 @@ DISTRO_PN_ALIAS_pn-screenshot = "OpenedHand"
 DISTRO_PN_ALIAS_pn-scrnsaverproto = "Meego=xorg-x11-proto-scrnsaverproto Ubuntu=x11proto-scrnsaver-dev Debian=x11proto-scrnsaver-dev"
 DISTRO_PN_ALIAS_pn-settings-daemon = "OpenedHand"
 DISTRO_PN_ALIAS_pn-sgml-common = "OpenSuSE=sgml-common Fedora=sgml-common"
-DISTRO_PN_ALIAS_pn-sgml-common-native = "OpenSuSE=sgml-common Fedora=sgml-common"
 DISTRO_PN_ALIAS_pn-sgmlspl = "Debian=sgmlspl Ubuntu=sgmlspl"
 DISTRO_PN_ALIAS_pn-shadow-securetty = "Ubuntu=shadow Fedora=shadow"
 DISTRO_PN_ALIAS_pn-shadow-sysroot = "Ubuntu=shadow Fedora=shadow"
-DISTRO_PN_ALIAS_pn-shasum-native = "OE-Core"
+DISTRO_PN_ALIAS_pn-shasum = "OE-Core"
 DISTRO_PN_ALIAS_pn-shutdown-desktop = "OpenedHand"
-DISTRO_PN_ALIAS_pn-signgp-native = "OE-Core"
+DISTRO_PN_ALIAS_pn-signgp = "OE-Core"
 DISTRO_PN_ALIAS_pn-stat = "Debian=coreutils Fedora=coreutils"
-DISTRO_PN_ALIAS_pn-swabber-native = "OE-Core"
+DISTRO_PN_ALIAS_pn-swabber = "OE-Core"
 DISTRO_PN_ALIAS_pn-sysklogd = "Debian=sysklogd Mandriva=sysklogd"
 DISTRO_PN_ALIAS_pn-sysprof = "Fedora=sysprof Debian=sysprof"
 DISTRO_PN_ALIAS_pn-systemd-compat-units = "Fedora=systemd Ubuntu=systemd"
-DISTRO_PN_ALIAS_pn-systemd-systemctl-native = "OE-Core"
-DISTRO_PN_ALIAS_pn-systemd-systemdctl-native = "Fedora=systemd Ubuntu=systemd"
+DISTRO_PN_ALIAS_pn-systemd-systemctl = "OE-Core"
+DISTRO_PN_ALIAS_pn-systemd-systemdctl = "Fedora=systemd Ubuntu=systemd"
 DISTRO_PN_ALIAS_pn-systemtap-uprobes = "Ubuntu=systemtap Debian=systemtap"
 DISTRO_PN_ALIAS_pn-sysvinit-inittab = "OE-Core"
 DISTRO_PN_ALIAS_pn-table = "Intel"
-DISTRO_PN_ALIAS_pn-tar-replacement-native = "OE-Core"
+DISTRO_PN_ALIAS_pn-tar-replacement = "OE-Core"
 DISTRO_PN_ALIAS_pn-tcf-agent = "Windriver upstream=http://www.eclipse.org/dsdp/tm/"
 DISTRO_PN_ALIAS_pn-telepathy-python = "Debian=telepathy-python Ubuntu=telepathy-python"
 DISTRO_PN_ALIAS_pn-tiny-init = "OSPDT"
@@ -438,6 +439,7 @@ DISTRO_PN_ALIAS_pn-ubootchart = "OSPDT upstream=http://code.google.com/p/ubootch
 DISTRO_PN_ALIAS_pn-u-boot-fw-utils = "Ubuntu=u-boot-tools Debian=u-boot-tools"
 DISTRO_PN_ALIAS_pn-u-boot-mkimage = "Ubuntu=uboot-mkimage Debian=uboot-mkimage"
 DISTRO_PN_ALIAS_pn-udev-extraconf = "OE-Core"
+DISTRO_PN_ALIAS_pn-unfs3 = "Debian=unfs3 Fedora=unfs3"
 DISTRO_PN_ALIAS_pn-unfs-server = "OE-Core"
 DISTRO_PN_ALIAS_pn-update-alternatives-dpkg = "Opensuse=update-alternatives Mandriva=update-alternatives"
 DISTRO_PN_ALIAS_pn-update-rc.d = "OE-Core"
@@ -445,6 +447,7 @@ DISTRO_PN_ALIAS_pn-usbinit = "OE-Core"
 DISTRO_PN_ALIAS_pn-util-macros = "Meego=xorg-x11-util-macros Fedora=xorg-x11-util-macros Mandriva=x11-util-macros"
 DISTRO_PN_ALIAS_pn-v86d = "Debian=v86d Ubuntu=v86d"
 DISTRO_PN_ALIAS_pn-videoproto = "Meego=xorg-x11-proto-videoproto"
+DISTRO_PN_ALIAS_pn-waffle = "OE-Core"
 DISTRO_PN_ALIAS_pn-watchdog = "Debian=watchdog Ubuntu=watchdog Mandriva=watchdog"
 DISTRO_PN_ALIAS_pn-webkit-gtk = "Fedora=webkitgtk Ubuntu=libwebkit"
 DISTRO_PN_ALIAS_pn-web-webkit = "OpenedHand"

meta-yocto/conf/distro/poky.conf

@@ -1,7 +1,7 @@
 DISTRO = "poky"
 DISTRO_NAME = "Poky (Yocto Project Reference Distro)"
-DISTRO_VERSION = "1.5+snapshot-${DATE}"
-DISTRO_CODENAME = "next"
+DISTRO_VERSION = "1.6"
+DISTRO_CODENAME = "daisy"
 SDK_VENDOR = "-pokysdk"
 SDK_VERSION := "${@'${DISTRO_VERSION}'.replace('snapshot-${DATE}','snapshot')}"
 

meta/classes/toaster.bbclass

@@ -288,7 +288,15 @@ python toaster_buildhistory_dump() {
 
             for pname in images[target]:
                 if not pname in allpkgs:
-                    allpkgs[pname] = _toaster_load_pkgdatafile("%s/runtime-reverse/" % pkgdata_dir, pname)
+                    try:
+                        pkgdata = _toaster_load_pkgdatafile("%s/runtime-reverse/" % pkgdata_dir, pname)
+                    except IOError as err:
+                        if err.errno == 2:
+                            # We expect this e.g. for RRECOMMENDS that are unsatisfied at runtime
+                            continue
+                        else:
+                            raise
+                    allpkgs[pname] = pkgdata
 
 
     data = { 'pkgdata' : allpkgs, 'imgdata' : images, 'filedata' : files }

meta/recipes-bsp/u-boot/files/0001-am335x_evm.h-Add-use-DEFAULT_LINUX_BOOT_ENV-environm.patch

@@ -0,0 +1,74 @@
+From 5701384cea4a829b772bf7a96a74825b58c22385 Mon Sep 17 00:00:00 2001
+From: Denys Dmytriyenko <denys@ti.com>
+Date: Thu, 17 Apr 2014 12:25:40 -0400
+Subject: [PATCH] am335x_evm.h: Add, use DEFAULT_LINUX_BOOT_ENV environment
+ string
+
+Modified version of the patch currently being reviewed for mainline:
+http://patchwork.ozlabs.org/patch/334861/
+
+To deal with a reoccurring problem properly we need to specify addresses
+for the Linux kernel, Flatted Device Tree and ramdisk that obey the
+constraints within the kernel's Documentation/arm/Booting file but also
+make sure that we relocate things within a valid address range.
+
+Signed-off-by: Denys Dmytriyenko <denys@ti.com>
+Signed-off-by: Tom Rini <trini@ti.com>
+
+Upstream-Status: Pending
+---
+ include/configs/am335x_evm.h | 31 ++++++++++++++++++++++++++-----
+ 1 file changed, 26 insertions(+), 5 deletions(-)
+
+diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
+index c5a6d4b..01e32b3 100644
+--- a/include/configs/am335x_evm.h
++++ b/include/configs/am335x_evm.h
+@@ -54,10 +54,7 @@
+ #define CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
+ #ifndef CONFIG_SPL_BUILD
+ #define CONFIG_EXTRA_ENV_SETTINGS \
+-	"loadaddr=0x80200000\0" \
+-	"fdtaddr=0x80F80000\0" \
+-	"fdt_high=0xffffffff\0" \
+-	"rdaddr=0x81000000\0" \
++	DEFAULT_LINUX_BOOT_ENV \
+ 	"bootdir=/boot\0" \
+ 	"bootfile=uImage\0" \
+ 	"fdtfile=undefined\0" \
+@@ -197,7 +194,31 @@
+ #define CONFIG_SYS_MEMTEST_END		(CONFIG_SYS_MEMTEST_START \
+ 					+ (8 * 1024 * 1024))
+ 
+-#define CONFIG_SYS_LOAD_ADDR		0x81000000 /* Default load address */
++/*
++ * Our DDR memory always starts at 0x80000000 and U-Boot shall have
++ * relocated itself to higher in memory by the time this value is used.
++ * However, set this to a 32MB offset to allow for easier Linux kernel
++ * booting as the default is often used as the kernel load address.
++ */
++#define CONFIG_SYS_LOAD_ADDR		0x82000000 /* Default load address */
++
++/*
++ * We setup defaults based on constraints from the Linux kernel, which should
++ * also be safe elsewhere.  We have the default load at 32MB into DDR (for
++ * the kernel), FDT above 128MB (the maximum location for the end of the
++ * kernel), and the ramdisk 512KB above that (allowing for hopefully never
++ * seen large trees).  We say all of this must be within the first 256MB
++ * as that will normally be within the kernel lowmem and thus visible via
++ * bootm_size and we only run on platforms with 256MB or more of memory.
++ */
++#define DEFAULT_LINUX_BOOT_ENV \
++	"loadaddr=0x82000000\0" \
++	"kernel_addr_r=0x82000000\0" \
++	"fdtaddr=0x88000000\0" \
++	"fdt_addr_r=0x88000000\0" \
++	"rdaddr=0x88080000\0" \
++	"ramdisk_addr_r=0x88080000\0" \
++	"bootm_size=0x10000000\0"
+ 
+ #define CONFIG_MMC
+ #define CONFIG_GENERIC_MMC
+-- 
+1.9.2
+

meta/recipes-bsp/u-boot/u-boot_2013.07.bb

@@ -16,7 +16,9 @@ SRCREV = "62c175fbb8a0f9a926c88294ea9f7e88eb898f6c"
 
 PV = "v2013.07+git${SRCPV}"
 
-SRC_URI = "git://git.denx.de/u-boot.git;branch=master"
+SRC_URI = "git://git.denx.de/u-boot.git;branch=master \
+           file://0001-am335x_evm.h-Add-use-DEFAULT_LINUX_BOOT_ENV-environm.patch \
+"
 
 S = "${WORKDIR}/git"
 

meta/recipes-core/images/build-appliance-image_8.0.bb

@@ -21,8 +21,8 @@ IMAGE_FSTYPES = "vmdk"
 
 inherit core-image
 
-SRCREV ?= "ae938eba92b2c89a9fd91161e57c5dbc594ad4ad"
-SRC_URI = "git://git.yoctoproject.org/poky \
+SRCREV ?= "84d524c9386065d06e6b9c2368b93fc07dc1816f"
+SRC_URI = "git://git.yoctoproject.org/poky;branch=daisy \
            file://Yocto_Build_Appliance.vmx \
            file://Yocto_Build_Appliance.vmxf \
           "

scripts/send-error-report

@@ -77,4 +77,4 @@ if __name__ == '__main__':
     elif len(sys.argv) == 3:
         sendData(sys.argv[1], sys.argv[2])
     else:
-        sendData(sys.argv[1], "localhost:8000")
+        sendData(sys.argv[1], "errors.yoctoproject.org")