build-appliance-image: Update to daisy head revision

(From OE-Core rev: 09f7ef16bbfbdfee25f0be3fd829924a6042fae9)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

bitbake/bin/bitbake-diffsigs

@@ -118,5 +118,5 @@ else:
             logger.error('Invalid signature data - ensure you are specifying sigdata/siginfo files')
             sys.exit(1)
 
-    if output:
-        print '\n'.join(output)
+        if output:
+            print '\n'.join(output)

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>

bitbake/lib/bb/data_smart.py

@@ -610,7 +610,7 @@ class DataSmart(MutableMapping):
             else:
                 cachename = var + "[" + flag + "]"
             value = self.expand(value, cachename)
-        if value is not None and flag == "_content" and local_var is not None and "_removeactive" in local_var:
+        if value and flag == "_content" and local_var is not None and "_removeactive" in local_var:
             filtered = filter(lambda v: v not in local_var["_removeactive"],
                               value.split(" "))
             value = " ".join(filtered)

bitbake/lib/bb/fetch2/__init__.py

@@ -1255,7 +1255,7 @@ class FetchMethod(object):
                         destdir = destdir.strip('/')
                     if destdir != "." and not os.access("%s/%s" % (rootdir, destdir), os.F_OK):
                         os.makedirs("%s/%s" % (rootdir, destdir))
-                    cmd = 'cp -pPR %s %s/%s/' % (file, rootdir, destdir)
+                    cmd = 'cp -fpPR %s %s/%s/' % (file, rootdir, destdir)
                     #cmd = 'tar -cf - -C "%d" -ps . | tar -xf - -C "%s/%s/"' % (file, rootdir, destdir)
                 else:
                     # The "destdir" handling was specifically done for FILESPATH
@@ -1265,7 +1265,7 @@ class FetchMethod(object):
                     else:
                        destdir = "."
                     bb.utils.mkdirhier("%s/%s" % (rootdir, destdir))
-                    cmd = 'cp %s %s/%s/' % (file, rootdir, destdir)
+                    cmd = 'cp -f %s %s/%s/' % (file, rootdir, destdir)
 
         if not cmd:
             return

bitbake/lib/bb/fetch2/hg.py

@@ -110,7 +110,10 @@ class Hg(FetchMethod):
             options.append("-r %s" % ud.revision)
 
         if command == "fetch":
-            cmd = "%s clone %s %s://%s/%s %s" % (basecmd, " ".join(options), proto, hgroot, ud.module, ud.module)
+            if ud.user and ud.pswd:
+                cmd = "%s --config auth.default.prefix=* --config auth.default.username=%s --config auth.default.password=%s --config \"auth.default.schemes=%s\" clone %s %s://%s/%s %s" % (basecmd, ud.user, ud.pswd, proto, " ".join(options), proto, hgroot, ud.module, ud.module)
+            else:
+                cmd = "%s clone %s %s://%s/%s %s" % (basecmd, " ".join(options), proto, hgroot, ud.module, ud.module)	      
         elif command == "pull":
             # do not pass options list; limiting pull to rev causes the local
             # repo not to contain it and immediately following "update" command
@@ -120,7 +123,7 @@ class Hg(FetchMethod):
             else:
                 cmd = "%s pull" % (basecmd)
         elif command == "update":
-            cmd = "%s update -C %s" % (basecmd, " ".join(options))
+            cmd = "%s update --config auth.default.prefix=* --config auth.default.username=%s --config auth.default.password=%s --config \"auth.default.schemes=%s\" -C %s" % (basecmd, ud.user, ud.pswd, proto, " ".join(options))
         else:
             raise FetchError("Invalid hg command %s" % command, ud.url)
 

bitbake/lib/bb/fetch2/perforce.py

@@ -48,7 +48,7 @@ class Perforce(FetchMethod):
             (user, pswd, host, port) = path.split('@')[0].split(":")
             path = path.split('@')[1]
         else:
-            (host, port) = data.getVar('P4PORT', d).split(':')
+            (host, port) = d.getVar('P4PORT').split(':')
             user = ""
             pswd = ""
 
@@ -81,7 +81,7 @@ class Perforce(FetchMethod):
         if host:
             p4opt += " -p %s" % (host)
 
-        p4date = data.getVar("P4DATE", d, True)
+        p4date = d.getVar("P4DATE", True)
         if "revision" in parm:
             depot += "#%s" % (parm["revision"])
         elif "label" in parm:
@@ -89,7 +89,7 @@ class Perforce(FetchMethod):
         elif p4date:
             depot += "@%s" % (p4date)
 
-        p4cmd = data.getVar('FETCHCMD_p4', d, True)
+        p4cmd = d.getVar('FETCHCMD_p4', True) or "p4"
         logger.debug(1, "Running %s%s changes -m 1 %s", p4cmd, p4opt, depot)
         p4file, errors = bb.process.run("%s%s changes -m 1 %s" % (p4cmd, p4opt, depot))
         cset = p4file.strip()
@@ -145,7 +145,7 @@ class Perforce(FetchMethod):
         if host:
             p4opt += " -p %s" % (host)
 
-        p4cmd = data.getVar('FETCHCMD_p4', d, True)
+        p4cmd = d.getVar('FETCHCMD_p4', True) or "p4"
 
         # create temp directory
         logger.debug(2, "Fetch: creating temporary directory")

bitbake/lib/bb/runqueue.py

@@ -139,7 +139,7 @@ class RunQueueScheduler(object):
         bestprio = None
         for taskid in self.buildable:
             prio = self.rev_prio_map[taskid]
-            if not bestprio or bestprio > prio:
+            if bestprio is None or bestprio > prio:
                 stamp = self.stamps[taskid]
                 if stamp in self.rq.build_stamps.itervalues():
                     continue
@@ -370,11 +370,11 @@ class RunQueueData:
 
         for listid in xrange(numTasks):
             task_done.append(False)
-            weight.append(0)
+            weight.append(1)
             deps_left.append(len(self.runq_revdeps[listid]))
 
         for listid in endpoints:
-            weight[listid] = 1
+            weight[listid] = 10
             task_done[listid] = True
 
         while True:

bitbake/lib/bb/tests/data.py

@@ -253,6 +253,11 @@ class TestConcatOverride(unittest.TestCase):
         bb.data.update_data(self.d)
         self.assertEqual(self.d.getVar("TEST_TEST", True), "bar bar")
 
+    def test_empty_remove(self):
+        self.d.setVar("TEST", "")
+        self.d.setVar("TEST_remove", "val")
+        bb.data.update_data(self.d)
+        self.assertEqual(self.d.getVar("TEST", True), "")
 
 class TestOverrides(unittest.TestCase):
     def setUp(self):

bitbake/lib/toaster/orm/models.py

@@ -166,9 +166,18 @@ class Task(models.Model):
     def get_related_setscene(self):
         return Task.objects.related_setscene(self)
 
+    def get_outcome_text(self):
+        return Task.TASK_OUTCOME[self.outcome + 1][1]
+
     def get_outcome_help(self):
         return Task.TASK_OUTCOME_HELP[self.outcome][1]
 
+    def get_sstate_text(self):
+        if self.sstate_result==Task.SSTATE_NA:
+            return ''
+        else:
+            return Task.SSTATE_RESULT[self.sstate_result][1]
+
     def get_executed_display(self):
         if self.task_executed:
             return "Executed"
@@ -200,6 +209,9 @@ class Task(models.Model):
     message = models.CharField(max_length=240)
     logfile = models.FilePathField(max_length=255, blank=True)
 
+    outcome_text = property(get_outcome_text)
+    sstate_text  = property(get_sstate_text)
+
     class Meta:
         ordering = ('order', 'recipe' ,)
         unique_together = ('build', 'recipe', 'task_name', )

bitbake/lib/toaster/toastergui/templates/basetable_top.html

@@ -1,18 +1,43 @@
 {% load projecttags %}
 <!-- component to display a generic table -->
     <script>
-    function showhideTableColumn(clname, sh) {
-        if (sh) $('.' + clname).show(100);
-        else $('.' + clname).hide(100);
 
-	// save cookie for all checkboxes
-	save = '';
-	$('.chbxtoggle').each(function() { if ($(this).attr('id') != undefined) { save += ';' + $(this).attr('id') +':'+ $(this).is(':checked')} })
-	$.cookie('_displaycols_{{objectname}}',  save);
-	save = '';
+    //
+    // most of the following javascript is for managing the 'Edit Columns'
+    // pop-up dialog and actions. the idea is that there are 2 types
+    // of actions: immediate - performed while the dialog is still
+    // visible - hide/show columns, and delayed - performed when the
+    // dialog becomes invisible - any resorting if necessary.
+    //
+    // When the dialog is open, an interval timer is set up to
+    // determine if the dialog is still visible. when the dialog
+    // closes - goes invisible, the delayed actions are performed.
+    //
+    // the interval timer and interrupt handler is a way of simulating
+    // an onclose event. there is probably a simpler way to do this
+    // however the pop-up window id was elusive.
+    //
+
+    var editColTimer;
+    var editColAction;
+
+    //
+    // this is the target function of the interval timeout.
+    // check to see if the dialog is visible. if the dialog
+    // has gone invisible since the last check, take any delayed
+    // actions indicated in the action list and clear the timer.
+    //
+
+    function checkVisible( ) {
+        editcol = document.getElementById( 'editcol' );
+        if ( editcol.offsetWidth <= 0 ) {
+            clearInterval( editColTimer );
+            editColTimer = false;
+            hideshowColumns( );
+            editColAction = [ ];
+        }
     }
 
-
     function filterTableRows(test) {
         if (test.length > 0) {
             var r = test.split(/[ ,]+/).map(function (e) { return new RegExp(e, 'i') });
@@ -24,6 +49,113 @@
             $('tr.data').show();
         }
     }
+
+    //
+    // determine the value of the indicated url arg.
+    // this is needed to determine whether a resort
+    // is necessary. it looks like a lot of gorp stuff
+    // but its actually pretty simple.
+    //
+
+    function getURLParameter( name ) {
+        return decodeURIComponent((new RegExp('[?|&]' + name + '=' +
+          '([^&;]+?)(&|#|;|$)').exec(location.search)||[,""])[1].replace(/\+/g,
+          '%20'))||null
+    }
+
+    //
+    // when the dialog box goes invisible
+    // this function is called to interpret
+    // the action list and take any delayed actions necessary.
+    // the editColAction list is a hash table with
+    // the column name as the hash key, the hash value
+    // is a 2 element list. the first element is a flag
+    // indicating whether the column is on or off. the
+    // 2nd element is the sort order indicator for the column.
+    //
+
+    function hideshowColumns( ) {
+        for( var k in editColAction ) {
+            showhideDelayedTableAction( k, editColAction[ k ][ 0 ], editColAction[ k ][ 1 ]);
+        }
+    }
+
+    //
+    // this function actually performs the delayed table actions
+    // namely any resorting if necessary
+    //
+
+    function showhideDelayedTableAction( clname, sh, orderkey ) {
+        if ( !sh ) {
+            p = getURLParameter( "orderby" ).split( ":" )[ 0 ];
+            if ( p == orderkey ) {
+                reload_params({ 'orderby' : '{{default_orderby}}'});
+            }
+        }
+    }
+
+    //
+    // this function actually performs the immediate table actions
+    // namely any colums that need to be hidden/shown
+    //
+
+    function showhideImmediateTableAction( clname, sh, orderkey ) {
+        if ( sh ) {
+            $( '.' + clname ).show( 100 );
+        }
+        else {
+            $( '.' + clname ).hide( 100 );
+        }
+
+	// save cookie for all checkboxes
+	save = '';
+	$( '.chbxtoggle' ).each(function( ) {
+            if ( $( this ).attr( 'id' ) != undefined ) {
+                save += ';' + $( this ).attr( 'id' ) +':'+ $( this ).is( ':checked' )
+            }
+        });
+	$.cookie( '_displaycols_{{objectname}}', save );
+	save = '';
+    }
+
+    //
+    // this is the onclick handler for all of the check box
+    // items in edit columns dialog
+    //
+
+    function showhideTableColumn( clname, sh, orderkey ) {
+        editcol = document.getElementById( 'editcol' );
+        if ( editcol.offsetWidth <= 0 ) {
+
+            //
+            // this path is taken when the page is first
+            // getting initialized - no dialog visible,
+            // perform both the immediate and delayed actions
+            //
+
+            showhideImmediateTableAction( clname, sh, orderkey );
+            showhideDelayedTableAction( clname, sh, orderkey );
+            return;
+        }
+        if ( !editColTimer ) {
+
+            //
+            // we don't have a timer active so set one up
+            // and clear the action list
+            //
+
+            editColTimer = setInterval( checkVisible, 250 );
+            editColAction = [ ];
+        }
+
+        //
+        // save the action to be taken when the dialog closes
+        //
+
+        editColAction[ clname ] = [ sh, orderkey ];
+        showhideImmediateTableAction( clname, sh, orderkey );
+    }
+
     </script>
 
 <!-- control header -->
@@ -33,7 +165,6 @@
             <input class="input-xxlarge" id="search" name="search" type="text" placeholder="Search {%if object_search_display %}{{object_search_display}}{%else%}{{objectname}}{%endif%}" value="{{request.GET.search}}"/>{% if request.GET.search %}<a href="javascript:$('#search').val('');searchform.submit()" class="add-on btn" tabindex="-1"><i class="icon-remove"></i></a>{%endif%}
             <input type="hidden" name="orderby" value="{{request.GET.orderby}}">
             <input type="hidden" name="page" value="1">
-            <input type="hidden" name="count" value="{{request.GET.count}}">
             <button class="btn" type="submit" value="Search">Search</button>
         </form>
         <div class="pull-right">
@@ -45,12 +176,27 @@
 <!--
 	{{tablecols|sortcols}}
 -->
-                <ul class="dropdown-menu">{% for i in tablecols|sortcols %}
+                <ul id='editcol' class="dropdown-menu">
+                  {% for i in tablecols|sortcols %}
                     <li>
                         <label {% if not i.clclass %} class="checkbox muted" {%else%} class="checkbox" {%endif%}>
-                            <input type="checkbox" class="chbxtoggle" {% if i.clclass %}id="{{i.clclass}}" value="ct{{i.name}}" {% if not i.hidden %}checked="checked"{%endif%} onchange="showhideTableColumn($(this).attr('id'), $(this).is(':checked'))" {%else%} checked disabled {% endif %}/>   {{i.name}}
+                            <input type="checkbox" class="chbxtoggle"
+                                   {% if i.clclass %}
+                                       id="{{i.clclass}}"
+                                       value="ct{{i.name}}"
+                                       {% if not i.hidden %}
+                                           checked="checked"
+                                       {%endif%}
+                                       onclick="showhideTableColumn(
+                                           $(this).attr('id'),
+                                           $(this).is(':checked'),
+                                           '{{i.orderkey}}' )"
+                                   {%else%}
+                                       checked disabled
+                                   {% endif %}/>   {{i.name}}
                         </label>
-                    </li>{% endfor %}
+                    </li>
+                  {% endfor %}
                 </ul>
             </div>
 {% endif %}

bitbake/lib/toaster/toastergui/templates/builddashboard.html

@@ -83,9 +83,27 @@
 			<dd><a href="{% url 'target' build.pk target.target.pk %}">{{target.npkg}}</a></dd>
 			<dt>Total package size</dt>
 			<dd>{{target.pkgsz|filtered_filesizeformat}}</dd>
+                        {% if target.targetHasNoImages %}
+				</dl>
+				<div class="row-fluid">
+					<div class="alert alert-info span7">
+                    <p>
+                                    <b>This build did not create any image files</b>
+                                  </p>
+                                  <p>
+                                    This is probably because valid image and license manifest
+                                    files from a previous build already exist in your
+                                    <code>.../poky/build/tmp/deploy</code>
+                                    directory. You can
+                                    also <a href="{% url 'targetpkg' build.pk target.target.pk %}">view the
+                                      license manifest information</a> in Toaster.
+                                  </p>
+                    </div>
+				</div>
+                        {% else %}
 			<dt>
 				<i class="icon-question-sign get-help" title="The location in disk of the license manifest, a document listing all packages installed in your image and their licenses"></i>
-				<a href="{% url 'target' build.pk target.target.pk %}">License manifest</a>
+				<a href="{% url 'targetpkg' build.pk target.target.pk %}">License manifest</a>
 			</dt>
 			<dd><code>{{target.target.license_manifest_path}}</code></dd>
 			<dt>
@@ -101,9 +119,11 @@
 				</ul>
 			</dd>
 		</dl>
+                        {% endif %}
 	</div>
         {% endif %}
 	{% endfor %}
+
   {% endif %}
 </div>
 
@@ -125,7 +145,7 @@
     <div class="well span4 dashboard-section">
         <h4><a href="{%url 'tasks' build.pk%}">Tasks</a></h4>
             <dl>
-        <dt>Total number of tasks</dt><dd><a href="{% url 'tasks' build.pk %}">{{build.task_build.all.count}}</a></dd>
+        <dt>Total number of tasks</dt><dd><a href="{% url 'tasks' build.pk %}">{% query build.task_build order__gt=0 as alltasks %}{{alltasks.count}}</a></dd>
         <dt>
             Tasks executed
             <i class="icon-question-sign get-help" title="'Executed' tasks are those that need to be run in order to generate the task output"></i>

bitbake/lib/toaster/toastergui/templates/recipes.html

@@ -45,31 +45,39 @@
         <td><a href="{% url "recipe" build.pk recipe.pk %}">{{recipe.version}}</a></td>
         <!-- Depends -->
         <td class="depends_on">
-            {% if recipe.r_dependencies_recipe.all.count %}
+            {% with deps=recipe_deps|get_dict_value:recipe.pk %}
+            {% with count=deps|length %}
+            {% if count %}
             <a class="btn"
                 title="<a href='{% url "recipe" build.pk recipe.pk %}#dependencies'>{{recipe.name}}</a> dependencies"
                 data-content="<ul class='unstyled'>
-                  {% for i in recipe.r_dependencies_recipe.all|dictsort:"depends_on.name"%}
+                  {% for i in deps|dictsort:"depends_on.name"%}
                     <li><a href='{% url "recipe" build.pk i.depends_on.pk %}'>{{i.depends_on.name}}</a></li>
                   {% endfor %}
                 </ul>">
-                {{recipe.r_dependencies_recipe.all.count}}
+                {{count}}
             </a>
             {% endif %}
+            {% endwith %}
+            {% endwith %}
         </td>
         <!--  Brought in by -->
         <td class="depends_by">
-            {% if recipe.r_dependencies_depends.all.count %}
+            {% with revs=recipe_revs|get_dict_value:recipe.pk %}
+            {% with count=revs|length %}
+            {% if count %}
             <a class="btn"
                 title="<a href='{% url "recipe" build.pk recipe.pk %}#brought-in-by'>{{recipe.name}}</a> reverse dependencies"
                 data-content="<ul class='unstyled'>
-                  {% for i in recipe.r_dependencies_depends.all|dictsort:"recipe.name"%}
+                  {% for i in revs|dictsort:"recipe.name" %}
                     <li><a href='{% url "recipe" build.pk i.recipe.pk %}'>{{i.recipe.name}}</a></li>
                   {% endfor %}
                 </ul>">
-                {{recipe.r_dependencies_depends.all.count}}
+                {{count}}
             </a>
             {% endif %}
+            {% endwith %}
+            {% endwith %}
         </td>
         <!-- Recipe file -->
         <td class="recipe_file">{{recipe.file_path}}</td>

bitbake/lib/toaster/toastergui/templates/target.html

@@ -79,7 +79,7 @@
             {{package.version|filtered_packageversion:package.revision}}
             </a>
         </td>
-        <td class="package-size sizecol">
+        <td class="size sizecol">
             {{package.size|filtered_installedsize:package.installed_size|filtered_filesizeformat}}
         </td>
         <td class="size_over_total sizecol">

bitbake/lib/toaster/toastergui/urls.py

@@ -46,6 +46,7 @@ urlpatterns = patterns('toastergui.views',
 
         # images are known as targets in the internal model
         url(r'^build/(?P<build_id>\d+)/target/(?P<target_id>\d+)$', 'target', name='target'),
+        url(r'^build/(?P<build_id>\d+)/target/(?P<target_id>\d+)/targetpkg$', 'targetpkg', name='targetpkg'),
         url(r'^dentries/build/(?P<build_id>\d+)/target/(?P<target_id>\d+)$', 'dirinfo_ajax', name='dirinfo_ajax'),
         url(r'^build/(?P<build_id>\d+)/target/(?P<target_id>\d+)/dirinfo$', 'dirinfo', name='dirinfo'),
         url(r'^build/(?P<build_id>\d+)/target/(?P<target_id>\d+)/dirinfo_filepath/(?P<file_path>(?:/[^/\n]+)*)$', 'dirinfo', name='dirinfo_filepath'),

bitbake/lib/toaster/toastergui/views.py

@@ -230,11 +230,10 @@ def builds(request):
             b.completeper = tf.exclude(order__isnull=True).count()*100/tf.count()
         else:
             b.completeper = 0
-        b.eta = timezone.now()
+
+        b.eta = 0
         if b.completeper > 0:
-            b.eta += ((timezone.now() - b.started_on)*100/b.completeper)
-        else:
-            b.eta = 0
+            b.eta = timezone.now() + ((timezone.now() - b.started_on)*(100-b.completeper)/b.completeper)
 
     # set up list of fstypes for each build
     fstypes_map = {};
@@ -262,6 +261,7 @@ def builds(request):
             # TODO: common objects for all table views, adapt as needed
                 'objects' : build_info,
                 'objectname' : "builds",
+                'default_orderby' : 'completed_on:-',
                 'fstypes' : fstypes_map,
                 'search_term' : search_term,
                 'total_count' : queryset_with_search.count(),
@@ -311,6 +311,7 @@ def builds(request):
                  'qhelp': "The date and time the build finished",
                  'orderfield': _get_toggle_order(request, "completed_on", True),
                  'ordericon':_get_toggle_order_icon(request, "completed_on"),
+                 'orderkey' : 'completed_on',
                  'filter' : {'class' : 'completed_on',
                              'label': 'Show:',
                              'options' : [
@@ -334,6 +335,7 @@ def builds(request):
                  'qhelp': "How many errors were encountered during the build (if any)",
                  'orderfield': _get_toggle_order(request, "errors_no", True),
                  'ordericon':_get_toggle_order_icon(request, "errors_no"),
+                 'orderkey' : 'errors_no',
                  'filter' : {'class' : 'errors_no',
                              'label': 'Show:',
                              'options' : [
@@ -346,6 +348,7 @@ def builds(request):
                  'qhelp': "How many warnings were encountered during the build (if any)",
                  'orderfield': _get_toggle_order(request, "warnings_no", True),
                  'ordericon':_get_toggle_order_icon(request, "warnings_no"),
+                 'orderkey' : 'warnings_no',
                  'filter' : {'class' : 'warnings_no',
                              'label': 'Show:',
                              'options' : [
@@ -358,6 +361,7 @@ def builds(request):
                  'qhelp': "How long it took the build to finish",
                  'orderfield': _get_toggle_order(request, "timespent", True),
                  'ordericon':_get_toggle_order_icon(request, "timespent"),
+                 'orderkey' : 'timespent',
                 },
                 {'name': 'Log',
                  'dclass': "span4",
@@ -365,6 +369,7 @@ def builds(request):
                  'clclass': 'log', 'hidden': 1,
                  'orderfield': _get_toggle_order(request, "cooker_log_path"),
                  'ordericon':_get_toggle_order_icon(request, "cooker_log_path"),
+                 'orderkey' : 'cooker_log_path',
                 },
                 {'name': 'Output', 'clclass': 'output',
                  'qhelp': "The root file system types produced by the build. You can find them in your <code>/build/tmp/deploy/images/</code> directory",
@@ -397,6 +402,7 @@ def builddashboard( request, build_id ):
     targets = [ ]
     ntargets = 0
     hasImages = False
+    targetHasNoImages = False
     for t in tgts:
         elem = { }
         elem[ 'target' ] = t
@@ -423,7 +429,11 @@ def builddashboard( request, build_id ):
                 ndx = 0;
             f = i.file_name[ ndx + 1: ]
             imageFiles.append({ 'path': f, 'size' : i.file_size })
+        if ( t.is_image and 
+             (( len( imageFiles ) <= 0 ) or ( len( t.license_manifest_path ) <= 0 ))):
+            targetHasNoImages = True
         elem[ 'imageFiles' ] = imageFiles
+        elem[ 'targetHasNoImages' ] = targetHasNoImages
         targets.append( elem )
 
     ##
@@ -502,7 +512,7 @@ def task( request, build_id, task_id ):
             'log_head'        : log_head,
             'log_body'        : log_body,
             'showing_matches' : False,
-			'uri_list'        : uri_list,
+            'uri_list'        : uri_list,
     }
     if request.GET.get( 'show_matches', "" ):
         context[ 'showing_matches' ] = True
@@ -535,123 +545,174 @@ def recipe(request, build_id, recipe_id):
     }
     return render(request, template, context)
 
-def target(request, build_id, target_id):
+def target_common( request, build_id, target_id, variant ):
     template = "target.html"
+    default_orderby = 'name:+';
     mandatory_parameters = { 'count': 25,  'page' : 1, 'orderby':'name:+'};
     retval = _verify_parameters( request.GET, mandatory_parameters )
     if retval:
-        return _redirect_parameters( 'target', request.GET, mandatory_parameters, build_id = build_id, target_id = target_id)
-    (filter_string, search_term, ordering_string) = _search_tuple(request, Package)
+        return _redirect_parameters( 
+                    variant, request.GET, mandatory_parameters, 
+                    build_id = build_id, target_id = target_id )
+    ( filter_string, search_term, ordering_string ) = _search_tuple( request, Package )
 
     # FUTURE:  get rid of nested sub-queries replacing with ManyToMany field
-    queryset = Package.objects.filter(size__gte=0, id__in=Target_Installed_Package.objects.filter(target_id=target_id).values('package_id'))
-    packages_sum =  queryset.aggregate(Sum('installed_size'))
-    queryset = _get_queryset(Package, queryset, filter_string, search_term, ordering_string, 'name')
-    packages = _build_page_range(Paginator(queryset, request.GET.get('count', 25)),request.GET.get('page', 1))
+    queryset = Package.objects.filter(
+                    size__gte = 0, 
+                    id__in = Target_Installed_Package.objects.filter(
+                        target_id=target_id ).values( 'package_id' ))
+    packages_sum =  queryset.aggregate( Sum( 'installed_size' ))
+    queryset = _get_queryset(
+            Package, queryset, filter_string, search_term, ordering_string, 'name' )
+    packages = _build_page_range( Paginator(
+            queryset, request.GET.get( 'count', 25 )),request.GET.get( 'page', 1 ))
 
     # bring in package dependencies
     for p in packages.object_list:
-        p.runtime_dependencies = p.package_dependencies_source.filter(target_id = target_id, dep_type=Package_Dependency.TYPE_TRDEPENDS)
-        p.reverse_runtime_dependencies = p.package_dependencies_target.filter(target_id = target_id, dep_type=Package_Dependency.TYPE_TRDEPENDS)
-
-    context = { 'build': Build.objects.filter(pk=build_id)[0],
-                'target': Target.objects.filter(pk=target_id)[0],
-                'objects': packages,
-                'packages_sum' : packages_sum['installed_size__sum'],
-                'object_search_display': "packages included",
-                'tablecols':[
-                {
-                    'name':'Package',
-                    'qhelp':'Packaged output resulting from building a recipe and included in this image',
-                    'orderfield': _get_toggle_order(request, "name"),
-                    'ordericon':_get_toggle_order_icon(request, "name"),
-                },
-                {
-                    'name':'Package version',
-                    'qhelp':'The package version and revision',
-                },
-                {
-                    'name':'Size',
-                    'qhelp':'The size of the package',
-                    'orderfield': _get_toggle_order(request, "size", True),
-                    'ordericon':_get_toggle_order_icon(request, "size"),
-                    'clclass': 'package_size span2',
-                    'hidden' : 0,
-                },
-                {
-                    'name':'Size over total (%)',
-                    'qhelp':'Proportion of the overall included package size represented by this package',
-                    'clclass': 'size_over_total span2',
-                    'hidden' : 1,
-                },
-                {
-                    'name':'License',
-                    'qhelp':'The license under which the package is distributed. Multiple license names separated by the pipe character indicates a choice between licenses. Multiple license names separated by the ampersand character indicates multiple licenses exist that cover different parts of the source',
-                    'orderfield': _get_toggle_order(request, "license"),
-                    'ordericon':_get_toggle_order_icon(request, "license"),
-                    'clclass': 'license',
-                    'hidden' : 1,
-                },
-                {
-                    'name':'Dependencies',
-                    'qhelp':"Package runtime dependencies (i.e. other packages)",
-                    'clclass': 'depends',
-                    'hidden' : 0,
-                },
-                {
-                    'name':'Reverse dependencies',
-                    'qhelp':'Package run-time reverse dependencies (i.e. other packages that depend on this package)',
-                    'clclass': 'brought_in_by',
-                    'hidden' : 0,
-                },
-                {
-                    'name':'Recipe',
-                    'qhelp':'The name of the recipe building the package',
-                    'orderfield': _get_toggle_order(request, "recipe__name"),
-                    'ordericon':_get_toggle_order_icon(request, "recipe__name"),
-                    'clclass': 'recipe_name',
-                    'hidden' : 0,
-                },
-                {
-                    'name':'Recipe version',
-                    'qhelp':'Version and revision of the recipe building the package',
-                    'clclass': 'recipe_version',
-                    'hidden' : 1,
-                },
-                {
-                    'name':'Layer',
-                    'qhelp':'The name of the layer providing the recipe that builds the package',
-                    'orderfield': _get_toggle_order(request, "recipe__layer_version__layer__name"),
-                    'ordericon':_get_toggle_order_icon(request, "recipe__layer_version__layer__name"),
-                    'clclass': 'layer_name',
-                    'hidden' : 1,
-                },
-                {
-                    'name':'Layer branch',
-                    'qhelp':'The Git branch of the layer providing the recipe that builds the package',
-                    'orderfield': _get_toggle_order(request, "recipe__layer_version__branch"),
-                    'ordericon':_get_toggle_order_icon(request, "recipe__layer_version__branch"),
-                    'clclass': 'layer_branch',
-                    'hidden' : 1,
-                },
-                {
-                    'name':'Layer commit',
-                    'qhelp':'The Git commit of the layer providing the recipe that builds the package',
-                    'clclass': 'layer_commit',
-                    'hidden' : 1,
-                },
-                {
-                    'name':'Layer directory',
-                    'qhelp':'Path to the layer providing the recipe that builds the package',
-                    'orderfield': _get_toggle_order(request, "recipe__layer_version__layer__local_path"),
-                    'ordericon':_get_toggle_order_icon(request, "recipe__layer_version__layer__local_path"),
-                    'clclass': 'layer_directory',
-                    'hidden' : 1,
-                },
+        p.runtime_dependencies = p.package_dependencies_source.filter(
+            target_id = target_id, dep_type=Package_Dependency.TYPE_TRDEPENDS )
+        p.reverse_runtime_dependencies = p.package_dependencies_target.filter(
+            target_id = target_id, dep_type=Package_Dependency.TYPE_TRDEPENDS )
+    tc_package = {
+        'name'       : 'Package',
+        'qhelp'      : 'Packaged output resulting from building a recipe included in this image',
+        'orderfield' : _get_toggle_order( request, "name" ),
+        'ordericon'  : _get_toggle_order_icon( request, "name" ),
+        }
+    tc_packageVersion = {
+        'name'       : 'Package version',
+        'qhelp'      : 'The package version and revision',
+        }
+    tc_size = {
+        'name'       : 'Size',
+        'qhelp'      : 'The size of the package',
+        'orderfield' : _get_toggle_order( request, "size", True ),
+        'ordericon'  : _get_toggle_order_icon( request, "size" ),
+        'orderkey'   : 'size',
+        'clclass'    : 'size',
+        'dclass'     : 'span2',
+        }
+    if ( variant == 'target' ):
+        tc_size[ "hidden" ] = 0
+    else:
+        tc_size[ "hidden" ] = 1
+    tc_sizePercentage = {
+        'name'       : 'Size over total (%)',
+        'qhelp'      : 'Proportion of the overall size represented by this package',
+        'orderfield' : _get_toggle_order( request, "size" ),
+        'ordericon'  : _get_toggle_order_icon( request, "size" ),
+        'clclass'    : 'size_over_total',
+        'hidden'     : 1,
+        }
+    tc_license = {
+        'name'       : 'License',
+        'qhelp'      : 'The license under which the package is distributed. Separate license names u\
+sing | (pipe) means there is a choice between licenses. Separate license names using & (ampersand) m\
+eans multiple licenses exist that cover different parts of the source',
+        'orderfield' : _get_toggle_order( request, "license" ),
+        'ordericon'  : _get_toggle_order_icon( request, "license" ),
+        'orderkey'   : 'license',
+        'clclass'    : 'license',
+        }
+    if ( variant == 'target' ):
+        tc_license[ "hidden" ] = 1
+    else:
+        tc_license[ "hidden" ] = 0
+    tc_dependencies = {
+        'name'       : 'Dependencies',
+        'qhelp'      : "Package runtime dependencies (other packages)",
+        'clclass'    : 'depends',
+        }
+    if ( variant == 'target' ):
+        tc_dependencies[ "hidden" ] = 0
+    else:
+        tc_dependencies[ "hidden" ] = 1
+    tc_rdependencies = {
+        'name'       : 'Reverse dependencies',
+        'qhelp'      : 'Package run-time reverse dependencies (i.e. which other packages depend on t\
+his package',
+        'clclass'    : 'brought_in_by',
+        }
+    if ( variant == 'target' ):
+        tc_rdependencies[ "hidden" ] = 0
+    else:
+        tc_rdependencies[ "hidden" ] = 1
+    tc_recipe = {
+        'name'       : 'Recipe',
+        'qhelp'      : 'The name of the recipe building the package',
+        'orderfield' : _get_toggle_order( request, "recipe__name" ),
+        'ordericon'  : _get_toggle_order_icon( request, "recipe__name" ),
+        'clclass'    : 'recipe_name',
+        'hidden'     : 0,
+        }
+    tc_recipeVersion = {
+        'name'       : 'Recipe version',
+        'qhelp'      : 'Version and revision of the recipe building the package',
+        'clclass'    : 'recipe_version',
+        'hidden'     : 1,
+        }
+    tc_layer = {
+        'name'       : 'Layer',
+        'qhelp'      : 'The name of the layer providing the recipe that builds the package',
+        'orderfield' : _get_toggle_order( request, "recipe__layer_version__layer__name" ),
+        'ordericon'  : _get_toggle_order_icon( request, "recipe__layer_version__layer__name" ),
+        'clclass'    : 'layer_name',
+        'hidden'     : 1,
+        }
+    tc_layerBranch = {
+        'name'       : 'Layer branch',
+        'qhelp'      : 'The Git branch of the layer providing the recipe that builds the package',
+        'orderfield' : _get_toggle_order( request, "recipe__layer_version__branch" ),
+        'ordericon'  : _get_toggle_order_icon( request, "recipe__layer_version__branch" ),
+        'clclass'    : 'layer_branch',
+        'hidden'     : 1,
+        }
+    tc_layerCommit = {
+        'name'       : 'Layer commit',
+        'qhelp'      : 'The Git commit of the layer providing the recipe that builds the package',
+        'clclass'    : 'layer_commit',
+        'hidden'     : 1,
+        }
+    tc_layerDir = {
+        'name':'Layer directory',
+        'qhelp':'Location in disk of the layer providing the recipe that builds the package',
+        'orderfield' : _get_toggle_order( request, "recipe__layer_version__layer__local_path" ),
+        'ordericon'  : _get_toggle_order_icon( request, "recipe__layer_version__layer__local_path" )\
+,
+        'clclass'    : 'layer_directory',
+        'hidden'     : 1,
+        }
+    context = { 
+        'objectname': variant,
+        'build'                : Build.objects.filter( pk = build_id )[ 0 ],
+        'target'               : Target.objects.filter( pk = target_id )[ 0 ],
+        'objects'              : packages,
+        'packages_sum'         : packages_sum[ 'installed_size__sum' ],
+        'object_search_display': "packages included",
+        'default_orderby'      : default_orderby,
+        'tablecols'            : [
+                    tc_package,
+                    tc_packageVersion,
+                    tc_license,
+                    tc_size,
+                    tc_sizePercentage,
+                    tc_dependencies,
+                    tc_rdependencies,
+                    tc_recipe,
+                    tc_recipeVersion,
+                    tc_layer,
+                    tc_layerBranch,
+                    tc_layerCommit,
+                    tc_layerDir,
                 ]
         }
+    return( render( request, template, context ))
 
-    return render(request, template, context)
+def target( request, build_id, target_id ):
+    return( target_common( request, build_id, target_id, "target" ))
+
+def targetpkg( request, build_id, target_id ):
+    return( target_common( request, build_id, target_id, "targetpkg" ))
 
 from django.core.serializers.json import DjangoJSONEncoder
 from django.http import HttpResponse
@@ -828,21 +889,25 @@ def tasks_common(request, build_id, variant, task_anchor):
         object_search_display="time data"
         filter_search_display="tasks"
         mandatory_parameters = { 'count': 25,  'page' : 1, 'orderby':'elapsed_time:-'};
+        default_orderby = 'elapsed_time:-';
     elif 'diskio'    == variant:
         title_variant='Disk I/O'
         object_search_display="disk I/O data"
         filter_search_display="tasks"
         mandatory_parameters = { 'count': 25,  'page' : 1, 'orderby':'disk_io:-'};
+        default_orderby = 'disk_io:-';
     elif 'cpuusage'  == variant:
         title_variant='CPU usage'
         object_search_display="CPU usage data"
         filter_search_display="tasks"
         mandatory_parameters = { 'count': 25,  'page' : 1, 'orderby':'cpu_usage:-'};
+        default_orderby = 'cpu_usage:-';
     else :
         title_variant='Tasks'
         object_search_display="tasks"
         filter_search_display="tasks"
         mandatory_parameters = { 'count': 25,  'page' : 1, 'orderby':'order:+'};
+        default_orderby = 'order:+';
 
     template = 'tasks.html'
     retval = _verify_parameters( request.GET, mandatory_parameters )
@@ -853,7 +918,14 @@ def tasks_common(request, build_id, variant, task_anchor):
     (filter_string, search_term, ordering_string) = _search_tuple(request, Task)
     queryset_all = Task.objects.filter(build=build_id).exclude(order__isnull=True).exclude(outcome=Task.OUTCOME_NA)
     queryset_with_search = _get_queryset(Task, queryset_all, None , search_term, ordering_string, 'order')
-    queryset = _get_queryset(Task, queryset_all, filter_string, search_term, ordering_string, 'order')
+    if ordering_string.startswith('outcome'):
+        queryset = _get_queryset(Task, queryset_all, filter_string, search_term, 'order:+', 'order')
+        queryset = sorted(queryset, key=lambda ur: (ur.outcome_text), reverse=ordering_string.endswith('-'))
+    elif ordering_string.startswith('sstate_result'):
+        queryset = _get_queryset(Task, queryset_all, filter_string, search_term, 'order:+', 'order')
+        queryset = sorted(queryset, key=lambda ur: (ur.sstate_text), reverse=ordering_string.endswith('-'))
+    else:
+        queryset = _get_queryset(Task, queryset_all, filter_string, search_term, ordering_string, 'order')
 
 	# compute the anchor's page
     if anchor:
@@ -877,12 +949,14 @@ def tasks_common(request, build_id, variant, task_anchor):
         'name':'Order',
         'qhelp':'The running sequence of each task in the build',
         'clclass': 'order', 'hidden' : 1,
+        'orderkey' : 'order',
         'orderfield':_get_toggle_order(request, "order"),
         'ordericon':_get_toggle_order_icon(request, "order")}
     if 'tasks' == variant: tc_order['hidden']='0'; del tc_order['clclass']
     tc_recipe={
         'name':'Recipe',
         'qhelp':'The name of the recipe to which each task applies',
+        'orderkey' : 'recipe__name',
         'orderfield': _get_toggle_order(request, "recipe__name"),
         'ordericon':_get_toggle_order_icon(request, "recipe__name"),
     }
@@ -896,6 +970,7 @@ def tasks_common(request, build_id, variant, task_anchor):
         'qhelp':'The name of the task',
         'orderfield': _get_toggle_order(request, "task_name"),
         'ordericon':_get_toggle_order_icon(request, "task_name"),
+        'orderkey' : 'task_name',
     }
     tc_executed={
         'name':'Executed',
@@ -903,6 +978,7 @@ def tasks_common(request, build_id, variant, task_anchor):
         'clclass': 'executed', 'hidden' : 0,
         'orderfield': _get_toggle_order(request, "task_executed"),
         'ordericon':_get_toggle_order_icon(request, "task_executed"),
+        'orderkey' : 'task_executed',
         'filter' : {
                    'class' : 'executed',
                    'label': 'Show:',
@@ -919,6 +995,7 @@ def tasks_common(request, build_id, variant, task_anchor):
         'clclass': 'outcome', 'hidden' : 0,
         'orderfield': _get_toggle_order(request, "outcome"),
         'ordericon':_get_toggle_order_icon(request, "outcome"),
+        'orderkey' : 'outcome',
         'filter' : {
                    'class' : 'outcome',
                    'label': 'Show:',
@@ -928,7 +1005,7 @@ def tasks_common(request, build_id, variant, task_anchor):
                                ('Cached Tasks', 'outcome:%d'%Task.OUTCOME_CACHED, queryset_with_search.filter(outcome=Task.OUTCOME_CACHED).count(), 'Cached tasks restore output from the <code>sstate-cache</code> directory or mirrors'),
                                ('Prebuilt Tasks', 'outcome:%d'%Task.OUTCOME_PREBUILT, queryset_with_search.filter(outcome=Task.OUTCOME_PREBUILT).count(),'Prebuilt tasks didn\'t need to run because their output was reused from a previous build'),
                                ('Covered Tasks', 'outcome:%d'%Task.OUTCOME_COVERED, queryset_with_search.filter(outcome=Task.OUTCOME_COVERED).count(), 'Covered tasks didn\'t need to run because their output is provided by another task in this build'),
-                               ('Empty Tasks', 'outcome:%d'%Task.OUTCOME_EMPTY, queryset_with_search.filter(outcome=Task.OUTCOME_NA).count(), 'Empty tasks have no executable content'),
+                               ('Empty Tasks', 'outcome:%d'%Task.OUTCOME_EMPTY, queryset_with_search.filter(outcome=Task.OUTCOME_EMPTY).count(), 'Empty tasks have no executable content'),
                                ]
                    }
 
@@ -938,6 +1015,7 @@ def tasks_common(request, build_id, variant, task_anchor):
         'qhelp':'Path to the task log file',
         'orderfield': _get_toggle_order(request, "logfile"),
         'ordericon':_get_toggle_order_icon(request, "logfile"),
+        'orderkey' : 'logfile',
         'clclass': 'task_log', 'hidden' : 1,
     }
     tc_cache={
@@ -946,6 +1024,7 @@ def tasks_common(request, build_id, variant, task_anchor):
         'clclass': 'cache_attempt', 'hidden' : 0,
         'orderfield': _get_toggle_order(request, "sstate_result"),
         'ordericon':_get_toggle_order_icon(request, "sstate_result"),
+        'orderkey' : 'sstate_result',
         'filter' : {
                    'class' : 'cache_attempt',
                    'label': 'Show:',
@@ -964,6 +1043,7 @@ def tasks_common(request, build_id, variant, task_anchor):
         'qhelp':'How long it took the task to finish in seconds',
         'orderfield': _get_toggle_order(request, "elapsed_time", True),
         'ordericon':_get_toggle_order_icon(request, "elapsed_time"),
+        'orderkey' : 'elapsed_time',
         'clclass': 'time_taken', 'hidden' : 1,
     }
     if   'buildtime' == variant: tc_time['hidden']='0'; del tc_time['clclass']; tc_cache['hidden']='1';
@@ -972,6 +1052,7 @@ def tasks_common(request, build_id, variant, task_anchor):
         'qhelp':'The percentage of task CPU utilization',
         'orderfield': _get_toggle_order(request, "cpu_usage", True),
         'ordericon':_get_toggle_order_icon(request, "cpu_usage"),
+        'orderkey' : 'cpu_usage',
         'clclass': 'cpu_used', 'hidden' : 1,
     }
     if   'cpuusage' == variant: tc_cpu['hidden']='0'; del tc_cpu['clclass']; tc_cache['hidden']='1';
@@ -980,6 +1061,7 @@ def tasks_common(request, build_id, variant, task_anchor):
         'qhelp':'Number of miliseconds the task spent doing disk input and output',
         'orderfield': _get_toggle_order(request, "disk_io", True),
         'ordericon':_get_toggle_order_icon(request, "disk_io"),
+        'orderkey' : 'disk_io',
         'clclass': 'disk_io', 'hidden' : 1,
     }
     if   'diskio' == variant: tc_diskio['hidden']='0'; del tc_diskio['clclass']; tc_cache['hidden']='1';
@@ -991,6 +1073,7 @@ def tasks_common(request, build_id, variant, task_anchor):
                 'title': title_variant,
                 'build': Build.objects.filter(pk=build_id)[0],
                 'objects': tasks,
+                'default_orderby' : default_orderby,
                 'search_term': search_term,
                 'total_count': queryset_with_search.count(),
                 'tablecols':[
@@ -1037,10 +1120,26 @@ def recipes(request, build_id):
 
     recipes = _build_page_range(Paginator(queryset, request.GET.get('count', 100)),request.GET.get('page', 1))
 
+    # prefetch the forward and reverse recipe dependencies
+    deps = { }; revs = { }
+    queryset_dependency=Recipe_Dependency.objects.filter(recipe__layer_version__build_id = build_id)
+    for recipe in recipes:
+        deplist = [ ]
+        for recipe_dep in [x for x in queryset_dependency if x.recipe_id == recipe.id]:
+            deplist.append(recipe_dep)
+        deps[recipe.id] = deplist
+        revlist = [ ]
+        for recipe_dep in [x for x in queryset_dependency if x.depends_on_id == recipe.id]:
+            revlist.append(recipe_dep)
+        revs[recipe.id] = revlist
+
     context = {
         'objectname': 'recipes',
         'build': Build.objects.filter(pk=build_id)[0],
         'objects': recipes,
+        'default_orderby' : 'name:+',
+        'recipe_deps' : deps,
+        'recipe_revs' : revs,
         'tablecols':[
             {
                 'name':'Recipe',
@@ -1067,6 +1166,7 @@ def recipes(request, build_id):
                 'qhelp':'Path to the recipe .bb file',
                 'orderfield': _get_toggle_order(request, "file_path"),
                 'ordericon':_get_toggle_order_icon(request, "file_path"),
+                'orderkey' : 'file_path',
                 'clclass': 'recipe_file', 'hidden': 0,
             },
             {
@@ -1074,6 +1174,7 @@ def recipes(request, build_id):
                 'qhelp':'The section in which recipes should be categorized',
                 'orderfield': _get_toggle_order(request, "section"),
                 'ordericon':_get_toggle_order_icon(request, "section"),
+                'orderkey' : 'section',
                 'clclass': 'recipe_section', 'hidden': 0,
             },
             {
@@ -1081,6 +1182,7 @@ def recipes(request, build_id):
                 'qhelp':'The list of source licenses for the recipe. Multiple license names separated by the pipe character indicates a choice between licenses. Multiple license names separated by the ampersand character indicates multiple licenses exist that cover different parts of the source',
                 'orderfield': _get_toggle_order(request, "license"),
                 'ordericon':_get_toggle_order_icon(request, "license"),
+                'orderkey' : 'license',
                 'clclass': 'recipe_license', 'hidden': 0,
             },
             {
@@ -1088,6 +1190,7 @@ def recipes(request, build_id):
                 'qhelp':'The name of the layer providing the recipe',
                 'orderfield': _get_toggle_order(request, "layer_version__layer__name"),
                 'ordericon':_get_toggle_order_icon(request, "layer_version__layer__name"),
+                'orderkey' : 'layer_version__layer__name',
                 'clclass': 'layer_version__layer__name', 'hidden': 0,
             },
             {
@@ -1095,6 +1198,7 @@ def recipes(request, build_id):
                 'qhelp':'The Git branch of the layer providing the recipe',
                 'orderfield': _get_toggle_order(request, "layer_version__branch"),
                 'ordericon':_get_toggle_order_icon(request, "layer_version__branch"),
+                'orderkey' : 'layer_version__branch',
                 'clclass': 'layer_version__branch', 'hidden': 1,
             },
             {
@@ -1107,6 +1211,7 @@ def recipes(request, build_id):
                 'qhelp':'Path to the layer prodiving the recipe',
                 'orderfield': _get_toggle_order(request, "layer_version__layer__local_path"),
                 'ordericon':_get_toggle_order_icon(request, "layer_version__layer__local_path"),
+                'orderkey' : 'layer_version__layer__local_path',
                 'clclass': 'layer_version__layer__local_path', 'hidden': 1,
             },
             ]
@@ -1189,6 +1294,7 @@ def configvars(request, build_id):
                 'build': Build.objects.filter(pk=build_id)[0],
                 'objects' : variables,
                 'total_count':queryset_with_search.count(),
+                'default_orderby' : 'variable_name:+',
                 'search_term':search_term,
             # Specifies the display of columns for the table, appearance in "Edit columns" box, toggling default show/hide, and specifying filters for columns
                 'tablecols' : [
@@ -1204,6 +1310,7 @@ def configvars(request, build_id):
                 {'name': 'Set in file',
                  'qhelp': "The last configuration file that touched the variable value",
                  'clclass': 'file', 'hidden' : 0,
+                 'orderkey' : 'vhistory__file_name',
                  'filter' : {
                     'class' : 'vhistory__file_name',
                     'label': 'Show:',
@@ -1250,6 +1357,7 @@ def bpackage(request, build_id):
         'objectname': 'packages built',
         'build': Build.objects.filter(pk=build_id)[0],
         'objects' : packages,
+        'default_orderby' : 'name:+',
         'tablecols':[
             {
                 'name':'Package',
@@ -1266,13 +1374,16 @@ def bpackage(request, build_id):
                 'qhelp':'The size of the package',
                 'orderfield': _get_toggle_order(request, "size", True),
                 'ordericon':_get_toggle_order_icon(request, "size"),
-                'clclass': 'size span2', 'hidden': 0,
+                'orderkey' : 'size',
+                'clclass': 'size', 'hidden': 0,
+                'dclass' : 'span2',
             },
             {
                 'name':'License',
                 'qhelp':'The license under which the package is distributed. Multiple license names separated by the pipe character indicates a choice between licenses. Multiple license names separated by the ampersand character indicates multiple licenses exist that cover different parts of the source',
                 'orderfield': _get_toggle_order(request, "license"),
                 'ordericon':_get_toggle_order_icon(request, "license"),
+                'orderkey' : 'license',
                 'clclass': 'license', 'hidden': 1,
             },
             {
@@ -1280,6 +1391,7 @@ def bpackage(request, build_id):
                 'qhelp':'The name of the recipe building the package',
                 'orderfield': _get_toggle_order(request, "recipe__name"),
                 'ordericon':_get_toggle_order_icon(request, "recipe__name"),
+                'orderkey' : 'recipe__name',
                 'clclass': 'recipe__name', 'hidden': 0,
             },
             {
@@ -1292,6 +1404,7 @@ def bpackage(request, build_id):
                 'qhelp':'The name of the layer providing the recipe that builds the package',
                 'orderfield': _get_toggle_order(request, "recipe__layer_version__layer__name"),
                 'ordericon':_get_toggle_order_icon(request, "recipe__layer_version__layer__name"),
+                'orderkey' : 'recipe__layer_version__layer__name',
                 'clclass': 'recipe__layer_version__layer__name', 'hidden': 1,
             },
             {
@@ -1299,6 +1412,7 @@ def bpackage(request, build_id):
                 'qhelp':'The Git branch of the layer providing the recipe that builds the package',
                 'orderfield': _get_toggle_order(request, "recipe__layer_version__branch"),
                 'ordericon':_get_toggle_order_icon(request, "recipe__layer_version__branch"),
+                'orderkey' : 'recipe__layer_version__layer__branch',
                 'clclass': 'recipe__layer_version__branch', 'hidden': 1,
             },
             {
@@ -1311,6 +1425,7 @@ def bpackage(request, build_id):
                 'qhelp':'Path to the layer providing the recipe that builds the package',
                 'orderfield': _get_toggle_order(request, "recipe__layer_version__layer__local_path"),
                 'ordericon':_get_toggle_order_icon(request, "recipe__layer_version__layer__local_path"),
+                'orderkey' : 'recipe__layer_version__layer__local_path',
                 'clclass': 'recipe__layer_version__layer__local_path', 'hidden': 1,
             },
             ]

bitbake/lib/toaster/toastermain/management/commands/perf.py

@@ -0,0 +1,53 @@
+from django.core.management.base import BaseCommand
+from django.test.client import Client
+import os, sys, re
+import requests
+import toastermain.settings as settings
+
+class Command(BaseCommand):
+    help    = "Test the response time for all toaster urls"
+
+    def handle(self, *args, **options):
+	root_urlconf = __import__(settings.ROOT_URLCONF)
+	patterns = root_urlconf.urls.urlpatterns
+	global full_url
+	for pat in patterns:
+	    if pat.__class__.__name__ == 'RegexURLResolver':
+		url_root_res = str(pat).split('^')[1].replace('>', '')
+		if 'gui' in url_root_res:
+		    for url_patt in pat.url_patterns:
+			full_url = self.get_full_url(url_patt, url_root_res)
+			info = self.url_info(full_url)
+			status_code = info[0]
+			load_time = info[1]
+			print 'Trying \'' + full_url + '\', ' + str(status_code) + ', ' + str(load_time)
+
+    def get_full_url(self, url_patt, url_root_res):
+	full_url = str(url_patt).split('^')[1].replace('$>', '').replace('(?P<file_path>(?:/[', '/bin/busybox').replace('.*', '')
+	full_url = str(url_root_res + full_url)
+	full_url = re.sub('\(\?P<.*?>\\\d\+\)', '1', full_url)
+	full_url = 'http://localhost:8000/' + full_url
+	return full_url
+
+    def url_info(self, full_url):
+	client = Client()
+	info = []
+	try:
+	    resp = client.get(full_url, follow = True)
+	except Exception as e_status_code:
+            self.error('Url: %s, error: %s' % (full_url, e_status_code))
+            resp = type('object', (), {'status_code':0, 'content': str(e_status_code)})
+	status_code = resp.status_code
+	info.append(status_code)
+	try:
+	    req = requests.get(full_url)
+	except Exception as e_load_time:
+            self.error('Url: %s, error: %s' % (full_url, e_load_time))
+	load_time = req.elapsed
+	info.append(load_time)
+	return info
+
+    def error(self, *args):
+	for arg in args:
+	    print >>sys.stderr, arg,
+	print >>sys.stderr

documentation/adt-manual/adt-manual.xml

@@ -73,9 +73,14 @@
             </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>
+            <revision>
+                <revnumber>1.6.1</revnumber>
+                <date>July 2014</date>
+                <revremark>Released with the Yocto Project 1.6.1 Release.</revremark>
+            </revision>
        </revhistory>
 
     <copyright>

documentation/bsp-guide/bsp-guide.xml

@@ -85,9 +85,14 @@
             </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>
+            <revision>
+                <revnumber>1.6.1</revnumber>
+                <date>July 2014</date>
+                <revremark>Released with the Yocto Project 1.6.1 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>

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

@@ -1278,7 +1278,7 @@
                     <literallayout class='monospaced'>
      cups_1.7.0.bb
      gawk_4.0.2.bb
-     xdg-utils_1.1.0-rc1.bb
+     irssi_0.8.16-rc1.bb
                     </literallayout></para></listitem>
             </itemizedlist>
         </section>
@@ -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>
@@ -2151,6 +2147,43 @@
             </para>
         </section>
 
+        <section id='properly-versioning-pre-release-recipes'>
+            <title>Properly Versioning Pre-Release Recipes</title>
+
+            <para>
+                Sometimes the name of a recipe can lead to versioning
+                problems when the recipe is upgraded to a final release.
+                For example, consider the
+                <filename>irssi_0.8.16-rc1.bb</filename> recipe file in
+                the list of example recipes in the
+                "<link linkend='new-recipe-storing-and-naming-the-recipe'>Storing and Naming the Recipe</link>"
+                section.
+                This recipe is at a release candidate stage (i.e.
+                "rc1").
+                When the recipe is released, the recipe filename becomes
+                <filename>irssi_0.8.16.bb</filename>.
+                The version change from <filename>0.8.16-rc1</filename>
+                to <filename>0.8.16</filename> is seen as a decrease by the
+                build system and package managers, so the resulting packages
+                will not correctly trigger an upgrade.
+            </para>
+
+            <para>
+                In order to ensure the versions compare properly, the
+                recommended convention is to set
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink>
+                within the recipe to
+                "&lt;previous version&gt;+&lt;current version&gt;".
+                You can use an additional variable so that you can use the
+                current version elsewhere.
+                Here is an example:
+                <literallayout class='monospaced'>
+     REALPV = "0.8.16-rc1"
+     PV = "0.8.15+${REALPV}"
+                </literallayout>
+            </para>
+        </section>
+
         <section id='new-recipe-post-installation-scripts'>
             <title>Post-Installation Scripts</title>
 
@@ -5345,7 +5378,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 +5387,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 +5410,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 +5425,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 +5436,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 +5472,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 +5685,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 +5738,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 +6023,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 +6045,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 +6052,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 +6126,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 +6243,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 +6252,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 +6288,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 +6695,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 +6745,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 +6787,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 +7321,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-model.xml

@@ -18,8 +18,7 @@
              "<ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-yocto-bsp-script'>Creating a New BSP Layer Using the yocto-bsp Script</ulink>"
              section in the Yocto Project Board Support Package (BSP) Developer's Guide.
              For more complete information on how to work with the kernel, see the
-             <ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;'>Yocto Project Linux Kernel
-             Development Manual</ulink>.
+             <ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;'>Yocto Project Linux Kernel Development Manual</ulink>.
              </para></listitem>
          <listitem><para><emphasis>User Application Development:</emphasis>
              User Application Development covers development of applications that you intend

documentation/dev-manual/dev-manual.xml

@@ -63,9 +63,14 @@
             </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>
+            <revision>
+                <revnumber>1.6.1</revnumber>
+                <date>July 2014</date>
+                <revremark>Released with the Yocto Project 1.6.1 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>

documentation/kernel-dev/kernel-dev.xml

@@ -48,9 +48,14 @@
             </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>
+            <revision>
+                <revnumber>1.6.1</revnumber>
+                <date>July 2014</date>
+                <revremark>Released with the Yocto Project 1.6.1 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>

documentation/poky.ent

@@ -1,9 +1,9 @@
-<!ENTITY DISTRO "1.6">
-<!ENTITY DISTRO_COMPRESSED "16">
+<!ENTITY DISTRO "1.6.1">
+<!ENTITY DISTRO_COMPRESSED "161">
 <!ENTITY DISTRO_NAME "daisy">
-<!ENTITY YOCTO_DOC_VERSION "1.6">
-<!ENTITY POKYVERSION "11.0.0">
-<!ENTITY POKYVERSION_COMPRESSED "1100">
+<!ENTITY YOCTO_DOC_VERSION "1.6.1">
+<!ENTITY POKYVERSION "11.0.1">
+<!ENTITY POKYVERSION_COMPRESSED "1101">
 <!ENTITY YOCTO_POKY "poky-&DISTRO_NAME;-&POKYVERSION;">
 <!ENTITY COPYRIGHT_YEAR "2010-2014">
 <!ENTITY YOCTO_DL_URL "http://downloads.yoctoproject.org">
@@ -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-intro.xml

@@ -4,7 +4,7 @@
 
 <chapter id='profile-manual-intro'>
 
-<title>Yocto Project Tracing and Profiling Manual</title>
+<title>Yocto Project Profiling and Tracing Manual</title>
     <section id='intro'>
         <title>Introduction</title>
 

documentation/profile-manual/profile-manual.xml

@@ -48,9 +48,14 @@
             </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>
+            <revision>
+                <revnumber>1.6.1</revnumber>
+                <date>July 2014</date>
+                <revremark>Released with the Yocto Project 1.6.1 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>

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

@@ -627,8 +627,8 @@
             hardware, but it will run on a wider range of systems than the
             <filename>atom-pc</filename> did.
             <note>
-                Additionally, a <filename>genericx86-64</filename> BSP has been
-                added for 64-bit systems.
+                Additionally, a <filename>genericx86-64</filename> BSP has
+                been added for 64-bit Atom systems.
             </note>
         </para>
     </section>
@@ -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>
 
@@ -1325,6 +1359,20 @@
         </para>
     </section>
 
+    <section id='migration-1.6-package-test-ptest'>
+        <title>Package Test (ptest)</title>
+
+        <para>
+            Package Tests (ptest) are built but not installed by default.
+            For information on using Package Tests, see the
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#testing-packages-with-ptest'>Setting up and running package test (ptest)</ulink>"
+            section in the Yocto Project Development Manual.
+            For information on the <filename>ptest</filename> class, see the
+            "<link linkend='ref-classes-ptest'><filename>ptest.bbclass</filename></link>"
+            section.
+        </para>
+    </section>
+
     <section id='migration-1.6-build-changes'>
         <title>Build Changes</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,9 +79,14 @@
             </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>
+            <revision>
+                <revnumber>1.6.1</revnumber>
+                <date>July 2014</date>
+                <revremark>Released with the Yocto Project 1.6.1 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>

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/ref-manual/resources.xml

@@ -29,10 +29,10 @@
     <title>Mailing lists</title>
 
     <para>
-        A number of mailing lists maintained by the Yocto Project exist 
-        as well as related OpenEmbedded mailing lists for discussion, 
+        A number of mailing lists maintained by the Yocto Project exist
+        as well as related OpenEmbedded mailing lists for discussion,
         patch submission and announcements.
-        To subscribe to one of the following mailing lists, click on the 
+        To subscribe to one of the following mailing lists, click on the
         appropriate URL in the following list and follow the instructions:
         <itemizedlist>
             <listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo/yocto'></ulink> -
@@ -42,11 +42,11 @@
             <listitem><para><ulink url='&OE_LISTS_URL;/listinfo/openembedded-devel'></ulink> -
                 Discussion mailing list about OpenEmbedded.</para></listitem>
             <listitem><para><ulink url='&OE_LISTS_URL;/listinfo/bitbake-devel'></ulink> -
-                Discussion mailing list about the 
+                Discussion mailing list about the
                 <ulink url='&YOCTO_DOCS_DEV_URL;#bitbake-term'>BitBake</ulink>
                 build tool.</para></listitem>
             <listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo/poky'></ulink> -
-                Discussion mailing list about 
+                Discussion mailing list about
                 <ulink url='&YOCTO_DOCS_DEV_URL;#poky'>Poky</ulink>.
                 </para></listitem>
             <listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo/yocto-announce'></ulink> -
@@ -76,28 +76,28 @@
         <itemizedlist>
             <listitem><para><emphasis>
                 <ulink url='&YOCTO_HOME_URL;'>The Yocto Project website</ulink>:
-                </emphasis> The home site for the Yocto 
+                </emphasis> The home site for the Yocto
                 Project.</para></listitem>
             <listitem><para><emphasis>
                 <ulink url='http://www.intel.com/'>Intel Corporation</ulink>:</emphasis>
-                The company who acquired OpenedHand in 2008 and began 
+                The company who acquired OpenedHand in 2008 and began
                 development on the Yocto Project.</para></listitem>
             <listitem><para><emphasis>
                 <ulink url='&OE_HOME_URL;'>OpenEmbedded</ulink>:</emphasis>
-                The upstream, generic, embedded distribution used as the basis 
+                The upstream, generic, embedded distribution used as the basis
                 for the build system in the Yocto Project.
-                Poky derives from and contributes back to the OpenEmbedded 
+                Poky derives from and contributes back to the OpenEmbedded
                 project.</para></listitem>
             <listitem><para><emphasis>
                 <ulink url='http://developer.berlios.de/projects/bitbake/'>
                 BitBake</ulink>:</emphasis> The tool used to process metadata.</para></listitem>
             <listitem><para><emphasis>
-                BitBake User Manual:</emphasis>
+                <ulink url='&YOCTO_DOCS_BB_URL;'>BitBake User Manual</ulink>:</emphasis>
                 A comprehensive guide to the BitBake tool.
-                You can find the BitBake User Manual in the 
-                <filename>bitbake/doc/manual</filename> directory, which is 
-                found in the
-                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                In the
+                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>,
+                you can find the BitBake User Manual in the
+                <filename>bitbake/doc/bitbake-user-manual</filename> directory.
                 </para></listitem>
             <listitem><para><emphasis>
                 <ulink url='http://wiki.qemu.org/Index.html'>QEMU</ulink>:
@@ -112,7 +112,7 @@
 
     <para>
         The Yocto Project gladly accepts contributions.
-        You can submit changes to the project either by creating and sending 
+        You can submit changes to the project either by creating and sending
         pull requests,
         or by submitting patches through email.
         For information on how to do both as well as information on how

documentation/tools/mega-manual.sed

@@ -1,13 +1,14 @@
 # Processes ref-manual and yocto-project-qs manual (<word>-<word>-<word> style)
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.6\/[a-z]*-[a-z]*-[a-z]*\/[a-z]*-[a-z]*-[a-z]*.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.6.1\/[a-z]*-[a-z]*-[a-z]*\/[a-z]*-[a-z]*-[a-z]*.html#/\"link\" href=\"#/g
 
 # Processes all other manuals (<word>-<word> style)
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.6\/[a-z]*-[a-z]*\/[a-z]*-[a-z]*.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.6.1\/[a-z]*-[a-z]*\/[a-z]*-[a-z]*.html#/\"link\" href=\"#/g
 
 # Process cases where just an external manual is referenced without an id anchor
-s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.6\/yocto-project-qs\/yocto-project-qs.html\" target=\"_top\">Yocto Project Quick Start<\/a>/Yocto Project Quick Start/g
-s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.6\/dev-manual\/dev-manual.html\" target=\"_top\">Yocto Project Development Manual<\/a>/Yocto Project Development Manual/g
-s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.6\/adt-manual\/adt-manual.html\" target=\"_top\">Yocto Project Application Developer's Guide<\/a>/Yocto Project Application Developer's Guide/g
-s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.6\/bsp-guide\/bsp-guide.html\" target=\"_top\">Yocto Project Board Support Package (BSP) Developer's Guide<\/a>/Yocto Project Board Support Package (BSP) Developer's Guide/g
-s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.6\/kernel-dev\/kernel-dev.html\" target=\"_top\">Yocto Project Linux Kernel Development Manual<\/a>/Yocto Project Linux Kernel Development Manual/g
-s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.6\/ref-manual\/ref-manual.html\" target=\"_top\">Yocto Project Reference Manual<\/a>/Yocto Project Reference Manual/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.6.1\/yocto-project-qs\/yocto-project-qs.html\" target=\"_top\">Yocto Project Quick Start<\/a>/Yocto Project Quick Start/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.6.1\/dev-manual\/dev-manual.html\" target=\"_top\">Yocto Project Development Manual<\/a>/Yocto Project Development Manual/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.6.1\/adt-manual\/adt-manual.html\" target=\"_top\">Yocto Project Application Developer's Guide<\/a>/Yocto Project Application Developer's Guide/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.6.1\/bsp-guide\/bsp-guide.html\" target=\"_top\">Yocto Project Board Support Package (BSP) Developer's Guide<\/a>/Yocto Project Board Support Package (BSP) Developer's Guide/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.6.1\/profile-manual\/profile-manual.html\" target=\"_top\">Yocto Project Profiling and Tracing Manual<\/a>/Yocto Project Profiling and Tracing Manual/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.6.1\/kernel-dev\/kernel-dev.html\" target=\"_top\">Yocto Project Linux Kernel Development Manual<\/a>/Yocto Project Linux Kernel Development Manual/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.6.1\/ref-manual\/ref-manual.html\" target=\"_top\">Yocto Project Reference Manual<\/a>/Yocto Project Reference Manual/g

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,9 +1,9 @@
 DISTRO = "poky"
 DISTRO_NAME = "Poky (Yocto Project Reference Distro)"
-DISTRO_VERSION = "1.5+snapshot-${DATE}"
-DISTRO_CODENAME = "next"
+DISTRO_VERSION = "1.6.1"
+DISTRO_CODENAME = "daisy"
 SDK_VENDOR = "-pokysdk"
-SDK_VERSION := "${@'${DISTRO_VERSION}'.replace('snapshot-${DATE}','snapshot')}"
+SDK_VERSION := "${@'${DISTRO_VERSION}'}"
 
 MAINTAINER = "Poky <poky@yoctoproject.org>"
 

meta-yocto/conf/local.conf.sample

@@ -243,6 +243,7 @@ BB_DISKMON_DIRS = "\
 # seen. The two lines below enable the SDL backend too. This assumes there is a
 # libsdl library available on your build system.
 PACKAGECONFIG_pn-qemu-native = "sdl"
+PACKAGECONFIG_pn-nativesdk-qemu = "sdl"
 ASSUME_PROVIDED += "libsdl-native"
 
 

meta-yocto/recipes-core/busybox/busybox_%.bbappend

@@ -1,2 +1,2 @@
-FILESEXTRAPATHS_prepend_poky := "${THISDIR}/${P}:"
+FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}:"
 

meta/classes/distro_features_check.bbclass

@@ -15,8 +15,8 @@ python () {
         for f in required_distro_features:
             if f in distro_features:
                 break
-        else:
-            raise bb.parse.SkipPackage("missing required distro feature %s (not in DISTRO_FEATURES)" % required_distro_features)
+            else:
+                raise bb.parse.SkipPackage("missing required distro feature %s (not in DISTRO_FEATURES)" % required_distro_features)
 
     conflict_distro_features = d.getVar('CONFLICT_DISTRO_FEATURES', True)
     if conflict_distro_features:

meta/classes/distrodata.bbclass

@@ -352,29 +352,14 @@ python do_checkpkg() {
         We don't want to exit whole build due to one recipe error. So handle all exceptions 
         gracefully w/o leaking to outer. 
         """
-        def internal_fetch_wget(url, d, tmpf):
+        def internal_fetch_wget(url, ud, d, tmpf):
                 status = "ErrFetchUnknown"
-                """
-                Clear internal url cache as it's a temporary check. Not doing so will have 
-                bitbake check url multiple times when looping through a single url
-                """
-                fn = d.getVar('FILE', True)
-                bb.fetch2.urldata_cache[fn] = {}
-
-                """
-                To avoid impacting bitbake build engine, this trick is required for reusing bitbake
-                interfaces. bb.fetch.go() is not appliable as it checks downloaded content in ${DL_DIR}
-                while we don't want to pollute that place. So bb.fetch2.checkstatus() is borrowed here
-                which is designed for check purpose but we override check command for our own purpose
-                """
-                ld = bb.data.createCopy(d)
-                d.setVar('CHECKCOMMAND_wget', "/usr/bin/env wget -t 1 --passive-ftp -O %s --user-agent=\"Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Ubuntu/9.10 (karmic) Firefox/3.6.12\" '${URI}'" \
-                                        % tmpf.name)
-                bb.data.update_data(ld)
 
+                agent = "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Ubuntu/9.10 (karmic) Firefox/3.6.12"
+                fetchcmd = "/usr/bin/env wget -t 1 --passive-ftp -O %s --user-agent=\"%s\" '%s'" % (tmpf.name, agent, url)
                 try:
-                        fetcher = bb.fetch2.Fetch([url], ld)
-                        fetcher.checkstatus()
+                        fetcher = bb.fetch2.wget.Wget(d)
+                        fetcher._runwget(ud, d, fetchcmd, True)
                         status = "SUCC"
                 except bb.fetch2.BBFetchException, e:
                         status = "ErrFetch"
@@ -388,10 +373,10 @@ python do_checkpkg() {
                 'curver' - current version
         Return new version if success, or else error in "Errxxxx" style
         """
-        def check_new_dir(url, curver, d):
+        def check_new_dir(url, curver, ud, d):
                 pn = d.getVar('PN', True)
                 f = tempfile.NamedTemporaryFile(delete=False, prefix="%s-1-" % pn)
-                status = internal_fetch_wget(url, d, f)
+                status = internal_fetch_wget(url, ud, d, f)
                 fhtml = f.read()
                 if status == "SUCC" and len(fhtml):
                         newver = parse_inter(curver)
@@ -447,14 +432,14 @@ python do_checkpkg() {
                 'curname' - current package name
         Return new version if success, or else error in "Errxxxx" style
         """
-        def check_new_version(url, curname, d):
+        def check_new_version(url, curname, ud, d):
                 """possible to have no version in pkg name, such as spectrum-fw"""
                 if not re.search("\d+", curname):
                         return pcurver
                 pn = d.getVar('PN', True)
                 newver_regex = d.getVar('REGEX', True)
                 f = tempfile.NamedTemporaryFile(delete=False, prefix="%s-2-" % pn)
-                status = internal_fetch_wget(url, d, f)
+                status = internal_fetch_wget(url, ud, d, f)
                 fhtml = f.read()
 
                 if status == "SUCC" and len(fhtml):
@@ -605,6 +590,7 @@ python do_checkpkg() {
 
 
         if type in ['http', 'https', 'ftp']:
+                ud = bb.fetch2.FetchData(uri, d)
                 newver = pcurver
                 altpath = path
                 dirver = "-"
@@ -629,7 +615,7 @@ python do_checkpkg() {
                             else:
                                     newver = d.getVar('PV', True)
                         else:
-                            newver = check_new_dir(alturi, dirver, d)
+                            newver = check_new_dir(alturi, dirver, ud, d)
                         altpath = path
                         if not re.match("Err", newver) and dirver != newver:
                                 altpath = altpath.replace(dirver, newver, True)
@@ -650,13 +636,13 @@ python do_checkpkg() {
                                 alturi = bb.fetch.encodeurl([type, host, altpath, user, pswd, {}])
                         else:
                                 alturi = chk_uri
-                        newver = check_new_version(alturi, curname, d)
+                        newver = check_new_version(alturi, curname, ud, d)
                         while(newver == "ErrHostNoDir"):
                                 if alturi == "/download":
                                         break
                                 else:
                                         alturi = "/".join(alturi.split("/")[0:-2]) + "/download"
-                                        newver = check_new_version(alturi, curname, d)
+                                        newver = check_new_version(alturi, curname, ud, d)
                 if not re.match("Err", newver):
                         pupver = newver
                         if pupver != pcurver:

meta/classes/distutils.bbclass

@@ -43,7 +43,10 @@ distutils_do_install() {
 
         # support filenames with *spaces*
         find ${D} -name "*.py" -print0 | while read -d $'\0' i ; do \
-            sed -i -e s:${D}::g "$i"
+            # only modify file if it contains path to avoid recompilation on the target
+            if grep -q "${D}" "$i"; then
+                sed -i -e s:${D}::g "$i"
+            fi
         done
 
         if test -e ${D}${bindir} ; then	

meta/classes/icecc.bbclass

@@ -28,7 +28,7 @@
 #Error checking is kept to minimum so double check any parameters you pass to the class
 ###########################################################################################
 
-BB_HASHBASE_WHITELIST += "ICECC_PARALLEL_MAKE ICECC_DISABLED ICECC_USER_PACKAGE_BL ICECC_USER_CLASS_BL ICECC_USER_PACKAGE_WL"
+BB_HASHBASE_WHITELIST += "ICECC_PARALLEL_MAKE ICECC_DISABLED ICECC_USER_PACKAGE_BL ICECC_USER_CLASS_BL ICECC_USER_PACKAGE_WL ICECC_PATH ICECC_ENV_EXEC"
 
 ICECC_ENV_EXEC ?= "${STAGING_BINDIR_NATIVE}/icecc-create-env"
 
@@ -148,6 +148,10 @@ def icc_is_native(bb, d):
 # Don't pollute allarch signatures with TARGET_FPU
 icc_version[vardepsexclude] += "TARGET_FPU"
 def icc_version(bb, d):
+    if d.getVar('ICECC_DISABLED') == "1":
+        # don't even try it, when explicitly disabled
+        return ""
+
     if use_icc(bb, d) == "no":
         return ""
 
@@ -175,6 +179,10 @@ def icc_version(bb, d):
     return tar_file
 
 def icc_path(bb,d):
+    if d.getVar('ICECC_DISABLED') == "1":
+        # don't create unnecessary directories when icecc is disabled
+        return
+
     if icc_is_kernel(bb, d):
         return create_path( [get_cross_kernel_cc(bb,d), ], bb, d)
 
@@ -238,7 +246,7 @@ def set_icecc_env():
     return
 
 set_icecc_env() {
-    if [ "x${ICECC_DISABLED}" != "x" ]
+    if [ "${ICECC_DISABLED}" = "1" ]
     then
         return
     fi

meta/classes/image_types.bbclass

@@ -93,7 +93,8 @@ IMAGE_CMD_ubi () {
 	echo vol_type=dynamic >> ubinize.cfg 
 	echo vol_name=${UBI_VOLNAME} >> ubinize.cfg 
 	echo vol_flags=autoresize >> ubinize.cfg
-	mkfs.ubifs -r ${IMAGE_ROOTFS} -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ubifs ${MKUBIFS_ARGS} && ubinize -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ubi ${UBINIZE_ARGS} ubinize.cfg
+	mkfs.ubifs -r ${IMAGE_ROOTFS} -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ubifs ${MKUBIFS_ARGS}
+	ubinize -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ubi ${UBINIZE_ARGS} ubinize.cfg
 }
 IMAGE_CMD_ubifs = "mkfs.ubifs -r ${IMAGE_ROOTFS} -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ubifs ${MKUBIFS_ARGS}"
 

meta/classes/kernel.bbclass

@@ -232,7 +232,7 @@ kernel_do_install() {
 	# dir. This ensures the original Makefiles are used and not the
 	# redirecting Makefiles in the build directory.
 	#
-	find . -depth -not -name "*.cmd" -not -name "*.o" -not -path "./Documentation*" -not -path "./.*" -print0 | cpio --null -pdlu $kerneldir
+	find . -depth -not -name "*.cmd" -not -name "*.o" -not -path "./Documentation*" -not -path "./source*" -not -path "./.*" -print0 | cpio --null -pdlu $kerneldir
 	cp .config $kerneldir
 	if [ "${S}" != "${B}" ]; then
 		pwd="$PWD"

meta/classes/native.bbclass

@@ -26,6 +26,10 @@ TARGET_PREFIX = "${BUILD_PREFIX}"
 TARGET_CC_ARCH = "${BUILD_CC_ARCH}"
 TARGET_LD_ARCH = "${BUILD_LD_ARCH}"
 TARGET_AS_ARCH = "${BUILD_AS_ARCH}"
+TARGET_CPPFLAGS = "${BUILD_CPPFLAGS}"
+TARGET_CFLAGS = "${BUILD_CFLAGS}"
+TARGET_CXXFLAGS = "${BUILD_CXXFLAGS}"
+TARGET_LDFLAGS = "${BUILD_LDFLAGS}"
 TARGET_FPU = ""
 
 HOST_ARCH = "${BUILD_ARCH}"

meta/classes/pixbufcache.bbclass

@@ -46,14 +46,16 @@ python populate_packages_append() {
 }
 
 #
-# Add a sstate postinst hook to update the cache for native packages
+# Add an sstate postinst hook to update the cache for native packages.
+# An error exit during populate_sysroot_setscene allows bitbake to
+# try to recover by re-building the package.
 #
 SSTATEPOSTINSTFUNCS_append_class-native = " pixbufcache_sstate_postinst"
 
 pixbufcache_sstate_postinst() {
 	if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ]
 	then
-		GDK_PIXBUF_FATAL_LOADER=1 gdk-pixbuf-query-loaders --update-cache
+		GDK_PIXBUF_FATAL_LOADER=1 gdk-pixbuf-query-loaders --update-cache || exit 1
 	fi
 }
 

meta/classes/ptest.bbclass

@@ -13,7 +13,7 @@ PTEST_ENABLED_class-cross-canadian = ""
 RDEPENDS_${PN}-ptest_class-native = ""
 RDEPENDS_${PN}-ptest_class-nativesdk = ""
 
-PACKAGES =+ "${@base_contains('DISTRO_FEATURES', 'ptest', '${PN}-ptest', '', d)}"
+PACKAGES =+ "${@bb.utils.contains('PTEST_ENABLED', '1', '${PN}-ptest', '', d)}"
 
 do_configure_ptest() {
     :

meta/classes/recipe_sanity.bbclass

@@ -59,7 +59,6 @@ def can_use_autotools_base(cfgdata, d):
 
 def can_delete_FILESPATH(cfgdata, d):
     expected = cfgdata.get("FILESPATH")
-    #expected = "${@':'.join([os.path.normpath(os.path.join(fp, p, o)) for fp in d.getVar('FILESPATHBASE', True).split(':') for p in d.getVar('FILESPATHPKG', True).split(':') for o in (d.getVar('OVERRIDES', True) + ':').split(':') if os.path.exists(os.path.join(fp, p, o))])}:${FILESDIR}"
     expectedpaths = d.expand(expected)
     unexpanded = d.getVar("FILESPATH", 0)
     filespath = d.getVar("FILESPATH", True).split(":")

meta/classes/report-error.bbclass

@@ -60,6 +60,7 @@ python errorreport_handler () {
                 filename = "error_report_" + e.data.getVar("BUILDNAME")+".txt"
                 datafile = errorreport_savedata(e, jsondata, filename)
                 bb.note("The errors of this build are stored in: %s. You can send the errors to an upstream server by running: send-error-report %s [server]" % (datafile, datafile))
+                bb.note("The contents of these logs will be posted in public if you use the above script. Please ensure you remove any identifying or propriety information before sending.")
 }
 
 addhandler errorreport_handler

meta/classes/sanity.bbclass

@@ -550,6 +550,10 @@ def check_sanity_version_change(status, d):
         if not check_app_exists("qemu-arm", d):
             status.addresult("qemu-native was in ASSUME_PROVIDED but the QEMU binaries (qemu-arm) can't be found in PATH")
 
+    if "libsdl-native" in assume_provided:
+        if not check_app_exists("sdl-config", d):
+            status.addresult("libsdl-native is set to be ASSUME_PROVIDED but sdl-config can't be found in PATH. Please either install it, or configure qemu not to require sdl.")
+
     (result, message) = check_gcc_march(d)
     if result and message:
         status.addresult("Your gcc version is older than 4.5, please add the following param to local.conf\n \

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/classes/update-rc.d.bbclass

@@ -1,6 +1,7 @@
 UPDATERCPN ?= "${PN}"
 
 DEPENDS_append = " update-rc.d-native"
+DEPENDS_append_class-target = " initscripts"
 UPDATERCD = "update-rc.d"
 UPDATERCD_class-cross = ""
 UPDATERCD_class-native = ""
@@ -67,6 +68,7 @@ python __anonymous() {
 }
 
 PACKAGESPLITFUNCS_prepend = "populate_packages_updatercd "
+PACKAGESPLITFUNCS_remove_class-nativesdk = "populate_packages_updatercd "
 
 populate_packages_updatercd[vardeps] += "updatercd_prerm updatercd_postrm updatercd_preinst updatercd_postinst"
 

meta/classes/useradd.bbclass

@@ -4,7 +4,7 @@ inherit useradd_base
 # target sysroot, and shadow -native and -sysroot provide the utilities
 # and support files needed to add and modify user and group accounts
 DEPENDS_append = "${USERADDDEPENDS}"
-USERADDDEPENDS = " base-passwd shadow-native shadow-sysroot shadow"
+USERADDDEPENDS = " base-files base-passwd shadow-native shadow-sysroot shadow"
 USERADDDEPENDS_class-cross = ""
 USERADDDEPENDS_class-native = ""
 USERADDDEPENDS_class-nativesdk = ""

meta/conf/distro/defaultsetup.conf

@@ -18,6 +18,7 @@ CACHE = "${TMPDIR}/cache/${TCMODE}-${TCLIBC}${@['', '/' + str(d.getVar('MACHINE'
 
 USER_CLASSES ?= ""
 PACKAGE_CLASSES ?= "package_ipk"
+INHERIT_BLACKLIST = "blacklist"
 INHERIT_DISTRO ?= "debian devshell sstate license"
-INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO}"
+INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO} ${INHERIT_BLACKLIST}"
 

meta/lib/oe/classextend.py

@@ -9,6 +9,8 @@ class ClassExtender(object):
             return name
         if name.startswith("rtld"):
             return name
+        if name.endswith("-crosssdk"):
+            return name
         if name.endswith("-" + self.extname):
             name = name.replace("-" + self.extname, "")
         if name.startswith("virtual/"):

meta/lib/oe/package_manager.py

@@ -6,6 +6,7 @@ import shutil
 import multiprocessing
 import re
 import bb
+import tempfile
 
 
 # this can be used by all PM backends to create the index files in parallel
@@ -411,16 +412,22 @@ class DpkgPkgsList(PkgsList):
             output = tmp_output
         elif format == "deps":
             opkg_query_cmd = bb.utils.which(os.getenv('PATH'), "opkg-query-helper.py")
+            file_out = tempfile.NamedTemporaryFile()
+            file_out.write(output)
+            file_out.flush()
 
             try:
-                output = subprocess.check_output("echo -e '%s' | %s" %
-                                                 (output, opkg_query_cmd),
+                output = subprocess.check_output("cat %s | %s" %
+                                                 (file_out.name, opkg_query_cmd),
                                                  stderr=subprocess.STDOUT,
                                                  shell=True)
             except subprocess.CalledProcessError as e:
+                file_out.close()
                 bb.fatal("Cannot compute packages dependencies. Command '%s' "
                          "returned %d:\n%s" % (e.cmd, e.returncode, e.output))
 
+            file_out.close()
+
         return output
 
 
@@ -1637,7 +1644,8 @@ class DpkgPM(PackageManager):
 
                 priority += 5
 
-            for pkg in self.d.getVar('PACKAGE_EXCLUDE', True).split():
+            pkg_exclude = self.d.getVar('PACKAGE_EXCLUDE', True) or ""
+            for pkg in pkg_exclude:
                 prefs_file.write(
                     "Package: %s\n"
                     "Pin: release *\n"

meta/lib/oe/rootfs.py

@@ -130,11 +130,19 @@ class Rootfs(object):
         self._cleanup()
 
     def _uninstall_uneeded(self):
+        # Remove unneeded init script symlinks
+        delayed_postinsts = self._get_delayed_postinsts()
+        if delayed_postinsts is None:
+            if os.path.exists(self.d.expand("${IMAGE_ROOTFS}${sysconfdir}/init.d/run-postinsts")):
+                self._exec_shell_cmd(["update-rc.d", "-f", "-r",
+                                      self.d.getVar('IMAGE_ROOTFS', True),
+                                      "run-postinsts", "remove"])
+
+        # Remove unneeded package-management related components
         if base_contains("IMAGE_FEATURES", "package-management",
                          True, False, self.d):
             return
 
-        delayed_postinsts = self._get_delayed_postinsts()
         if delayed_postinsts is None:
             installed_pkgs_dir = self.d.expand('${WORKDIR}/installed_pkgs.txt')
             pkgs_to_remove = list()
@@ -154,10 +162,6 @@ class Rootfs(object):
                 # Update installed_pkgs.txt
                 open(installed_pkgs_dir, "w+").write('\n'.join(pkgs_installed))
 
-            if os.path.exists(self.d.expand("${IMAGE_ROOTFS}${sysconfdir}/init.d/run-postinsts")):
-                self._exec_shell_cmd(["update-rc.d", "-f", "-r",
-                                      self.d.getVar('IMAGE_ROOTFS', True),
-                                      "run-postinsts", "remove"])
         else:
             self._save_postinsts()
 

meta/lib/oe/sdk.py

@@ -52,6 +52,7 @@ class Sdk(object):
         # Link the ld.so.cache file into the hosts filesystem
         link_name = os.path.join(self.sdk_output, self.sdk_native_path,
                                  self.sysconfdir, "ld.so.cache")
+        bb.utils.mkdirhier(os.path.dirname(link_name))
         os.symlink("/etc/ld.so.cache", link_name)
 
         execute_pre_post_process(self.d, self.d.getVar('SDK_POSTPROCESS_COMMAND', True))

meta/lib/oe/terminal.py

@@ -60,19 +60,9 @@ class Mate(XTerminal):
     priority = 2
 
 class Xfce(XTerminal):
-    command = 'Terminal -T "{title}" -e "{command}"'
+    command = 'xfce4-terminal -T "{title}" -e "{command}"'
     priority = 2
 
-    def __init__(self, command, title=None, env=None, d=None):
-        # Upstream binary name is Terminal but Debian/Ubuntu use
-        # xfce4-terminal to avoid possible(?) conflicts
-        distro = distro_name()
-        if distro == 'ubuntu' or distro == 'debian':
-            cmd = 'xfce4-terminal -T "{title}" -e "{command}"'
-        else:
-            cmd = command
-        XTerminal.__init__(self, cmd, title, env, d)
-
 class Konsole(XTerminal):
     command = 'konsole -T "{title}" -e {command}'
     priority = 2

meta/recipes-bsp/grub/grub-efi_2.00.bb

@@ -70,12 +70,14 @@ do_install_class-native() {
 	install -m 755 grub-mkimage ${D}${bindir}
 }
 
+GRUB_BUILDIN ?= "boot linux ext2 fat serial part_msdos part_gpt normal efi_gop iso9660 search"
+
 do_deploy() {
 	# Search for the grub.cfg on the local boot media by using the
 	# built in cfg file provided via this recipe
 	grub-mkimage -c ../cfg -p /EFI/BOOT -d ./grub-core/ \
 	               -O ${GRUB_TARGET}-efi -o ./${GRUB_IMAGE} \
-	               boot linux ext2 fat serial part_msdos part_gpt normal efi_gop iso9660 search
+	               ${GRUB_BUILDIN}
 	install -m 644 ${B}/${GRUB_IMAGE} ${DEPLOYDIR}
 }
 

meta/recipes-bsp/grub/grub/asciih-fix-build-warning-error.patch

@@ -0,0 +1,34 @@
+util/grub-gen-asciih.c: fix build warning->error
+
+A potential problem is flagged by the compiler and generates a warning. This
+warning is promoted to an error via -Werror. This patch fixes the original
+issue, avoids the warning, and therefore avoids the build error.
+
+Upstream-Status: Pending
+
+Index: git/util/grub-gen-asciih.c
+===================================================================
+--- git.orig/util/grub-gen-asciih.c
++++ git/util/grub-gen-asciih.c
+@@ -131,6 +131,8 @@ write_font_ascii_bitmap (FILE *file, FT_
+   struct grub_glyph_info glyph;
+   int char_code;
+ 
++  memset (&glyph, 0, sizeof(glyph));
++
+   fprintf (file, "/* THIS CHUNK OF BYTES IS AUTOMATICALLY GENERATED */\n");
+   fprintf (file, "unsigned char ascii_bitmaps[] =\n");
+   fprintf (file, "{\n");
+@@ -144,6 +146,12 @@ write_font_ascii_bitmap (FILE *file, FT_
+ 	return;
+       add_glyph (glyph_idx, face, char_code, &glyph);
+ 
++      if (glyph.bitmap == 0)
++        {
++          fprintf (stderr, "grub-gen-asciih: add_glyph not successful");
++          exit (1);
++        }
++
+       if (glyph.width == 8 && glyph.height == 16
+ 	  && glyph.x_ofs == 0 && glyph.y_ofs == 0)
+ 	{

meta/recipes-bsp/grub/grub_git.bb

@@ -22,6 +22,7 @@ SRC_URI = "git://git.savannah.gnu.org/grub.git \
            file://40_custom \
            file://autogen.sh-exclude-pc.patch \
            file://grub-2.00-add-oe-kernel.patch \
+           file://asciih-fix-build-warning-error.patch \
           "
 
 S = "${WORKDIR}/git"
@@ -53,8 +54,12 @@ do_configure_prepend() {
 do_install_append () {
     install -d ${D}${sysconfdir}/grub.d
     install -m 0755 ${WORKDIR}/40_custom ${D}${sysconfdir}/grub.d/40_custom
+ 
 }
 
+# debugedit chokes on bare metal binaries
+INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
+
 RDEPENDS_${PN} = "diffutils freetype"
 FILES_${PN}-dbg += "${libdir}/${BPN}/*/.debug"
 

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-bsp/v86d/v86d_0.1.10.bb

@@ -7,9 +7,10 @@ LIC_FILES_CHKSUM = "file://README;md5=94ac1971e4f2309dc322d598e7b1f7dd"
 
 DEPENDS = "virtual/kernel"
 RRECOMMENDS_${PN} = "kernel-module-uvesafb"
-PR = "r1"
+PR = "r2"
 
 SRC_URI = "http://distfiles.gentoo.org/distfiles/${BP}.tar.bz2 \
+           file://Update-x86emu-from-X.org.patch \
            file://fbsetup \
            file://ar-from-env.patch"
 

meta/recipes-connectivity/bind/bind/init.d-add-support-for-read-only-rootfs.patch

@@ -0,0 +1,65 @@
+Subject: init.d: add support for read-only rootfs
+
+Upstream-Status: Inappropriate [oe specific]
+
+Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
+---
+ init.d |   40 ++++++++++++++++++++++++++++++++++++++++
+ 1 file changed, 40 insertions(+)
+
+diff --git a/init.d b/init.d
+index 0111ed4..24677c8 100644
+--- a/init.d
++++ b/init.d
+@@ -6,8 +6,48 @@ PATH=/sbin:/bin:/usr/sbin:/usr/bin
+ # Don't modify this line, change or create /etc/default/bind9.
+ OPTIONS=""
+ 
++test -f /etc/default/rcS && . /etc/default/rcS
+ test -f /etc/default/bind9 && . /etc/default/bind9
+ 
++# This function is here because it's possible that /var and / are on different partitions.
++is_on_read_only_partition () {
++    DIRECTORY=$1
++    dir=`readlink -f $DIRECTORY`
++    while true; do
++	if [ ! -d "$dir" ]; then
++	    echo "ERROR: $dir is not a directory"
++	    exit 1
++	else
++	    for flag in `awk -v dir=$dir '{ if ($2 == dir) { print "FOUND"; split($4,FLAGS,",") } }; \
++		END { for (f in FLAGS) print FLAGS[f] }' < /proc/mounts`; do
++		[ "$flag" = "FOUND" ] && partition="read-write"
++		[ "$flag" = "ro" ] && { partition="read-only"; break; }
++	    done
++	    if [ "$dir" = "/" -o -n "$partition" ]; then
++		break
++	    else
++		dir=`dirname $dir`
++	    fi
++	fi
++    done
++    [ "$partition" = "read-only" ] && echo "yes" || echo "no"
++}
++
++bind_mount () {
++    olddir=$1
++    newdir=$2
++    mkdir -p $olddir
++    cp -a $newdir/* $olddir
++    mount --bind $olddir $newdir
++}
++
++# Deal with read-only rootfs
++if [ "$ROOTFS_READ_ONLY" = "yes" ]; then
++    [ "$VERBOSE" != "no" ] && echo "WARN: start bind service in read-only rootfs"
++    [ `is_on_read_only_partition /etc/bind` = "yes" ] && bind_mount /var/volatile/bind/etc /etc/bind
++    [ `is_on_read_only_partition /var/named` = "yes" ] && bind_mount /var/volatile/bind/named /var/named
++fi
++
+ test -x /usr/sbin/rndc || exit 0
+ 
+ case "$1" in
+-- 
+1.7.9.5
+

meta/recipes-connectivity/bind/bind_9.9.5.bb

@@ -13,6 +13,7 @@ SRC_URI = "ftp://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.gz \
            file://make-etc-initd-bind-stop-work.patch \
            file://mips1-not-support-opcode.diff \
            file://dont-test-on-host.patch \
+           file://init.d-add-support-for-read-only-rootfs.patch \
 	   "
 
 SRC_URI[md5sum] = "e676c65cad5234617ee22f48e328c24e"
@@ -45,6 +46,7 @@ do_install_append() {
 	rm "${D}${mandir}/man1/nslookup.1"
 	rmdir "${D}${localstatedir}/run"
 	rmdir --ignore-fail-on-non-empty "${D}${localstatedir}"
+	install -d "${D}${localstatedir}/cache/bind"
 	install -d "${D}${sysconfdir}/bind"
 	install -d "${D}${sysconfdir}/init.d"
 	install -m 644 ${S}/conf/* "${D}${sysconfdir}/bind/"

meta/recipes-connectivity/openssh/openssh/openssh-CVE-2014-2532.patch

@@ -0,0 +1,22 @@
+Upstream-Status: Backport
+
+Fix for CVE-2014-2532
+
+Backported from openssh-6.6p1.tar.gz
+
+Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
+---
+--- a/session.c
++++ b/session.c
+@@ -955,6 +955,11 @@
+ 	u_int envsize;
+ 	u_int i, namelen;
+ 
++	if (strchr(name, '=') != NULL) {
++		error("Invalid environment variable \"%.100s\"", name);
++		return;
++	}
++
+ 	/*
+ 	 * If we're passed an uninitialized list, allocate a single null
+ 	 * entry before continuing.

meta/recipes-connectivity/openssh/openssh/openssh-CVE-2014-2653.patch

@@ -0,0 +1,114 @@
+Upstream-Status: Backport
+
+This CVE could be removed if openssh is upgrade to 6.6 or higher.
+Below are some details.
+
+Attempt SSHFP lookup even if server presents a certificate
+
+Reference:
+https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742513
+
+If an ssh server presents a certificate to the client, then the client
+does not check the DNS for SSHFP records. This means that a malicious
+server can essentially disable DNS-host-key-checking, which means the
+client will fall back to asking the user (who will just say "yes" to
+the fingerprint, sadly).
+
+This patch means that the ssh client will, if necessary, extract the
+server key from the proffered certificate, and attempt to verify it
+against the DNS. The patch was written by Mark Wooding
+<mdw@distorted.org.uk>. I modified it to add one debug2 call, reviewed
+it, and tested it.
+
+Signed-off-by: Matthew Vernon <matthew@debian.org>
+Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
+---
+--- a/sshconnect.c
++++ b/sshconnect.c
+@@ -1210,36 +1210,63 @@ fail:
+ 	return -1;
+ }
+ 
++static int
++check_host_key_sshfp(char *host, struct sockaddr *hostaddr, Key *host_key)
++{
++	int rc = -1;
++	int flags = 0;
++	Key *raw_key = NULL;
++
++	if (!options.verify_host_key_dns)
++		goto done;
++
++	/* XXX certs are not yet supported for DNS; try looking the raw key
++	 * up in the DNS anyway.
++	 */
++	if (key_is_cert(host_key)) {
++		debug2("Extracting key from cert for SSHFP lookup");
++		raw_key = key_from_private(host_key);
++		if (key_drop_cert(raw_key))
++			fatal("Couldn't drop certificate");
++		host_key = raw_key;
++	}
++
++	if (verify_host_key_dns(host, hostaddr, host_key, &flags))
++		goto done;
++
++	if (flags & DNS_VERIFY_FOUND) {
++
++		if (options.verify_host_key_dns == 1 &&
++				flags & DNS_VERIFY_MATCH &&
++				flags & DNS_VERIFY_SECURE) {
++			rc = 0;
++		} else if (flags & DNS_VERIFY_MATCH) {
++			matching_host_key_dns = 1;
++		} else {
++			warn_changed_key(host_key);
++			error("Update the SSHFP RR in DNS with the new "
++					"host key to get rid of this message.");
++		}
++	}
++
++done:
++	if (raw_key)
++		key_free(raw_key);
++	return rc;
++}
++
+ /* returns 0 if key verifies or -1 if key does NOT verify */
+ int
+ verify_host_key(char *host, struct sockaddr *hostaddr, Key *host_key)
+ {
+-	int flags = 0;
+ 	char *fp;
+ 
+ 	fp = key_fingerprint(host_key, SSH_FP_MD5, SSH_FP_HEX);
+ 	debug("Server host key: %s %s", key_type(host_key), fp);
+ 	free(fp);
+ 
+-	/* XXX certs are not yet supported for DNS */
+-	if (!key_is_cert(host_key) && options.verify_host_key_dns &&
+-	    verify_host_key_dns(host, hostaddr, host_key, &flags) == 0) {
+-		if (flags & DNS_VERIFY_FOUND) {
+-
+-			if (options.verify_host_key_dns == 1 &&
+-			    flags & DNS_VERIFY_MATCH &&
+-			    flags & DNS_VERIFY_SECURE)
+-				return 0;
+-
+-			if (flags & DNS_VERIFY_MATCH) {
+-				matching_host_key_dns = 1;
+-			} else {
+-				warn_changed_key(host_key);
+-				error("Update the SSHFP RR in DNS with the new "
+-				    "host key to get rid of this message.");
+-			}
+-		}
+-	}
++	if (check_host_key_sshfp(host, hostaddr, host_key) == 0)
++		return 0;
+ 
+ 	return check_host_key(host, hostaddr, options.port, host_key, RDRW,
+ 	    options.user_hostfiles, options.num_user_hostfiles,
+-- 
+1.7.9.5
+

meta/recipes-connectivity/openssh/openssh/volatiles.99_sshd

@@ -1 +1,2 @@
 d root root 0755 /var/run/sshd none
+f root root 0644 /var/log/lastlog none

meta/recipes-connectivity/openssh/openssh_6.5p1.bb

@@ -7,7 +7,6 @@ SECTION = "console/network"
 LICENSE = "BSD"
 LIC_FILES_CHKSUM = "file://LICENCE;md5=e326045657e842541d3f35aada442507"
 
-
 DEPENDS = "zlib openssl"
 DEPENDS += "${@base_contains('DISTRO_FEATURES', 'pam', 'libpam', '', d)}"
 
@@ -28,7 +27,9 @@ SRC_URI = "ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-${PV}.tar.
            file://sshd.socket \
            file://sshd@.service \
            file://sshdgenkeys.service \
-           file://volatiles.99_sshd "
+           file://volatiles.99_sshd \
+           file://openssh-CVE-2014-2532.patch \
+           file://openssh-CVE-2014-2653.patch"
 
 PAM_SRC_URI = "file://sshd"
 
@@ -55,7 +56,9 @@ inherit autotools-brokensep
 CFLAGS += "-D__FILE_OFFSET_BITS=64"
 export LD = "${CC}"
 
-EXTRA_OECONF = "${@base_contains('DISTRO_FEATURES', 'pam', '--with-pam', '--without-pam', d)} \
+# login path is hardcoded in sshd
+EXTRA_OECONF = "'LOGIN_PROGRAM=${base_bindir}/login' \
+                ${@base_contains('DISTRO_FEATURES', 'pam', '--with-pam', '--without-pam', d)} \
                 --without-zlib-version-check \
                 --with-privsep-path=/var/run/sshd \
                 --sysconfdir=${sysconfdir}/ssh \
@@ -64,9 +67,11 @@ EXTRA_OECONF = "${@base_contains('DISTRO_FEATURES', 'pam', '--with-pam', '--with
 # Since we do not depend on libbsd, we do not want configure to use it
 # just because it finds libutil.h.  But, specifying --disable-libutil
 # causes compile errors, so...
-#
 CACHED_CONFIGUREVARS += "ac_cv_header_bsd_libutil_h=no ac_cv_header_libutil_h=no"
 
+# passwd path is hardcoded in sshd
+CACHED_CONFIGUREVARS += "ac_cv_path_PATH_PASSWD_PROG=${bindir}/passwd"
+
 # This is a workaround for uclibc because including stdio.h
 # pulls in pthreads.h and causes conflicts in function prototypes.
 # This results in compilation failure, so unless this is fixed,
@@ -97,7 +102,7 @@ do_install_append () {
 	install -d ${D}/${sysconfdir}/default/volatiles
 	install -m 644 ${WORKDIR}/volatiles.99_sshd ${D}/${sysconfdir}/default/volatiles/99_sshd
 
-        # Create config files for read-only rootfs
+	# Create config files for read-only rootfs
 	install -d ${D}${sysconfdir}/ssh
 	install -m 644 ${D}${sysconfdir}/ssh/sshd_config ${D}${sysconfdir}/ssh/sshd_config_readonly
 	sed -i '/HostKey/d' ${D}${sysconfdir}/ssh/sshd_config_readonly
@@ -130,7 +135,6 @@ FILES_${PN}-keygen = "${bindir}/ssh-keygen"
 RDEPENDS_${PN} += "${PN}-scp ${PN}-ssh ${PN}-sshd ${PN}-keygen"
 RDEPENDS_${PN}-sshd += "${PN}-keygen ${@base_contains('DISTRO_FEATURES', 'pam', 'pam-plugin-keyinit pam-plugin-loginuid', '', d)}"
 
-
 CONFFILES_${PN}-sshd = "${sysconfdir}/ssh/sshd_config"
 CONFFILES_${PN}-ssh = "${sysconfdir}/ssh/ssh_config"
 

meta/recipes-connectivity/openssl/cryptodev-linux_1.6.bb

@@ -1,22 +0,0 @@
-SUMMARY = "A /dev/crypto device driver"
-HOMEPAGE = "http://cryptodev-linux.org/"
-
-LICENSE = "GPLv2"
-LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
-
-SRC_URI = "http://download.gna.org/cryptodev-linux/${BPN}-${PV}.tar.gz"
-
-SRC_URI[md5sum] = "eade38998313c25fd7934719cdf8a2ea"
-SRC_URI[sha256sum] = "75f1425c8ea1f8cae523905a5a046a35092327a6152800b0b86efc4e56fb3e2f"
-
-do_compile() {
-	:
-}
-
-# Just install cryptodev.h which is the only header file needed to be exported
-do_install() {
-	install -D ${S}/crypto/cryptodev.h ${D}${includedir}/crypto/cryptodev.h
-}
-
-ALLOW_EMPTY_${PN} = "1"
-BBCLASSEXTEND = "native nativesdk"

meta/recipes-connectivity/openssl/openssl/openssl-1.0.1e-cve-2014-0195.patch

@@ -0,0 +1,40 @@
+commit 208d54db20d58c9a5e45e856a0650caadd7d9612
+Author: Dr. Stephen Henson <steve@openssl.org>
+Date:   Tue May 13 18:48:31 2014 +0100
+
+    Fix for CVE-2014-0195
+    
+    A buffer overrun attack can be triggered by sending invalid DTLS fragments
+    to an OpenSSL DTLS client or server. This is potentially exploitable to
+    run arbitrary code on a vulnerable client or server.
+    
+    Fixed by adding consistency check for DTLS fragments.
+    
+    Thanks to Jüri Aedla for reporting this issue.
+
+Patch borrowed from Fedora
+Upstream-Status: Backport
+Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
+
+diff --git a/ssl/d1_both.c b/ssl/d1_both.c
+index 2e8cf68..07f67f8 100644
+--- a/ssl/d1_both.c
++++ b/ssl/d1_both.c
+@@ -627,7 +627,16 @@ dtls1_reassemble_fragment(SSL *s, struct hm_header_st* msg_hdr, int *ok)
+ 		frag->msg_header.frag_off = 0;
+ 		}
+ 	else
++		{
+ 		frag = (hm_fragment*) item->data;
++		if (frag->msg_header.msg_len != msg_hdr->msg_len)
++			{
++			item = NULL;
++			frag = NULL;
++			goto err;
++			}
++		}
++
+ 
+ 	/* If message is already reassembled, this must be a
+ 	 * retransmit and can be dropped.
+

meta/recipes-connectivity/openssl/openssl/openssl-1.0.1e-cve-2014-0198.patch

@@ -0,0 +1,38 @@
+From: Matt Caswell <matt@openssl.org>
+Date: Sun, 11 May 2014 23:38:37 +0000 (+0100)
+Subject: Fixed NULL pointer dereference. See PR#3321
+X-Git-Url: https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff_plain;h=b107586
+
+Fixed NULL pointer dereference. See PR#3321
+
+Patch borrowed from Fedora
+Upstream-Status: Backport
+Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
+
+---
+
+diff --git a/ssl/s3_pkt.c b/ssl/s3_pkt.c
+index 40eb0dd..d961d12 100644
+--- a/ssl/s3_pkt.c
++++ b/ssl/s3_pkt.c
+@@ -657,9 +657,6 @@ static int do_ssl3_write(SSL *s, int type, const unsigned char *buf,
+ 	SSL3_BUFFER *wb=&(s->s3->wbuf);
+ 	SSL_SESSION *sess;
+ 
+- 	if (wb->buf == NULL)
+-		if (!ssl3_setup_write_buffer(s))
+-			return -1;
+ 
+ 	/* first check if there is a SSL3_BUFFER still being written
+ 	 * out.  This will happen with non blocking IO */
+@@ -675,6 +672,10 @@ static int do_ssl3_write(SSL *s, int type, const unsigned char *buf,
+ 		/* if it went, fall through and send more stuff */
+ 		}
+ 
++ 	if (wb->buf == NULL)
++		if (!ssl3_setup_write_buffer(s))
++			return -1;
++
+ 	if (len == 0 && !create_empty_fragment)
+ 		return 0;
+ 

meta/recipes-connectivity/openssl/openssl/openssl-1.0.1e-cve-2014-0221.patch

@@ -0,0 +1,38 @@
+commit d30e582446b027868cdabd0994681643682045a4
+Author: Dr. Stephen Henson <steve@openssl.org>
+Date:   Fri May 16 13:00:45 2014 +0100
+
+    Fix CVE-2014-0221
+    
+    Unnecessary recursion when receiving a DTLS hello request can be used to
+    crash a DTLS client. Fixed by handling DTLS hello request without recursion.
+    
+    Thanks to Imre Rad (Search-Lab Ltd.) for discovering this issue.
+
+Patch borrowed from Fedora
+Upstream-Status: Backport
+Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
+
+diff --git a/ssl/d1_both.c b/ssl/d1_both.c
+index 07f67f8..4c2fd03 100644
+--- a/ssl/d1_both.c
++++ b/ssl/d1_both.c
+@@ -793,6 +793,7 @@ dtls1_get_message_fragment(SSL *s, int st1, int stn, long max, int *ok)
+ 	int i,al;
+ 	struct hm_header_st msg_hdr;
+ 
++	redo:
+ 	/* see if we have the required fragment already */
+ 	if ((frag_len = dtls1_retrieve_buffered_fragment(s,max,ok)) || *ok)
+ 		{
+@@ -851,8 +852,7 @@ dtls1_get_message_fragment(SSL *s, int st1, int stn, long max, int *ok)
+ 					s->msg_callback_arg);
+ 			
+ 			s->init_num = 0;
+-			return dtls1_get_message_fragment(s, st1, stn,
+-				max, ok);
++			goto redo;
+ 			}
+ 		else /* Incorrectly formated Hello request */
+ 			{
+

meta/recipes-connectivity/openssl/openssl/openssl-1.0.1e-cve-2014-0224.patch

@@ -0,0 +1,103 @@
+Fix for CVE-2014-0224
+
+Only accept change cipher spec when it is expected instead of at any
+time. This prevents premature setting of session keys before the master
+secret is determined which an attacker could use as a MITM attack.
+
+Thanks to KIKUCHI Masashi (Lepidum Co. Ltd.) for reporting this issue
+and providing the initial fix this patch is based on.
+
+
+Patch borrowed from Fedora
+Upstream-Status: Backport
+Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
+
+
+diff -up openssl-1.0.1e/ssl/ssl3.h.keying-mitm openssl-1.0.1e/ssl/ssl3.h
+--- openssl-1.0.1e/ssl/ssl3.h.keying-mitm	2014-06-02 19:48:04.518100562 +0200
++++ openssl-1.0.1e/ssl/ssl3.h	2014-06-02 19:48:04.642103429 +0200
+@@ -388,6 +388,7 @@ typedef struct ssl3_buffer_st
+ #define TLS1_FLAGS_TLS_PADDING_BUG		0x0008
+ #define TLS1_FLAGS_SKIP_CERT_VERIFY		0x0010
+ #define TLS1_FLAGS_KEEP_HANDSHAKE		0x0020
++#define SSL3_FLAGS_CCS_OK			0x0080
+  
+ /* SSL3_FLAGS_SGC_RESTART_DONE is set when we
+  * restart a handshake because of MS SGC and so prevents us
+diff -up openssl-1.0.1e/ssl/s3_clnt.c.keying-mitm openssl-1.0.1e/ssl/s3_clnt.c
+--- openssl-1.0.1e/ssl/s3_clnt.c.keying-mitm	2013-02-11 16:26:04.000000000 +0100
++++ openssl-1.0.1e/ssl/s3_clnt.c	2014-06-02 19:49:57.042701985 +0200
+@@ -559,6 +559,7 @@ int ssl3_connect(SSL *s)
+ 		case SSL3_ST_CR_FINISHED_A:
+ 		case SSL3_ST_CR_FINISHED_B:
+ 
++			s->s3->flags |= SSL3_FLAGS_CCS_OK;
+ 			ret=ssl3_get_finished(s,SSL3_ST_CR_FINISHED_A,
+ 				SSL3_ST_CR_FINISHED_B);
+ 			if (ret <= 0) goto end;
+@@ -916,6 +917,7 @@ int ssl3_get_server_hello(SSL *s)
+ 		SSLerr(SSL_F_SSL3_GET_SERVER_HELLO,SSL_R_ATTEMPT_TO_REUSE_SESSION_IN_DIFFERENT_CONTEXT);
+ 		goto f_err;
+ 		}
++	    s->s3->flags |= SSL3_FLAGS_CCS_OK;
+ 	    s->hit=1;
+ 	    }
+ 	else	/* a miss or crap from the other end */
+diff -up openssl-1.0.1e/ssl/s3_pkt.c.keying-mitm openssl-1.0.1e/ssl/s3_pkt.c
+--- openssl-1.0.1e/ssl/s3_pkt.c.keying-mitm	2014-06-02 19:48:04.640103383 +0200
++++ openssl-1.0.1e/ssl/s3_pkt.c	2014-06-02 19:48:04.643103452 +0200
+@@ -1298,6 +1298,15 @@ start:
+ 			goto f_err;
+ 			}
+ 
++		if (!(s->s3->flags & SSL3_FLAGS_CCS_OK))
++			{
++			al=SSL_AD_UNEXPECTED_MESSAGE;
++			SSLerr(SSL_F_SSL3_READ_BYTES,SSL_R_CCS_RECEIVED_EARLY);
++			goto f_err;
++			}
++
++		s->s3->flags &= ~SSL3_FLAGS_CCS_OK;
++
+ 		rr->length=0;
+ 
+ 		if (s->msg_callback)
+@@ -1432,7 +1441,7 @@ int ssl3_do_change_cipher_spec(SSL *s)
+ 
+ 	if (s->s3->tmp.key_block == NULL)
+ 		{
+-		if (s->session == NULL) 
++		if (s->session == NULL || s->session->master_key_length == 0)
+ 			{
+ 			/* might happen if dtls1_read_bytes() calls this */
+ 			SSLerr(SSL_F_SSL3_DO_CHANGE_CIPHER_SPEC,SSL_R_CCS_RECEIVED_EARLY);
+diff -up openssl-1.0.1e/ssl/s3_srvr.c.keying-mitm openssl-1.0.1e/ssl/s3_srvr.c
+--- openssl-1.0.1e/ssl/s3_srvr.c.keying-mitm	2014-06-02 19:48:04.630103151 +0200
++++ openssl-1.0.1e/ssl/s3_srvr.c	2014-06-02 19:48:04.643103452 +0200
+@@ -673,6 +673,7 @@ int ssl3_accept(SSL *s)
+ 		case SSL3_ST_SR_CERT_VRFY_A:
+ 		case SSL3_ST_SR_CERT_VRFY_B:
+ 
++			s->s3->flags |= SSL3_FLAGS_CCS_OK;
+ 			/* we should decide if we expected this one */
+ 			ret=ssl3_get_cert_verify(s);
+ 			if (ret <= 0) goto end;
+@@ -700,6 +701,7 @@ int ssl3_accept(SSL *s)
+ 
+ 		case SSL3_ST_SR_FINISHED_A:
+ 		case SSL3_ST_SR_FINISHED_B:
++			s->s3->flags |= SSL3_FLAGS_CCS_OK;
+ 			ret=ssl3_get_finished(s,SSL3_ST_SR_FINISHED_A,
+ 				SSL3_ST_SR_FINISHED_B);
+ 			if (ret <= 0) goto end;
+@@ -770,7 +772,10 @@ int ssl3_accept(SSL *s)
+ 				s->s3->tmp.next_state=SSL3_ST_SR_FINISHED_A;
+ #else
+ 				if (s->s3->next_proto_neg_seen)
++					{
++					s->s3->flags |= SSL3_FLAGS_CCS_OK;
+ 					s->s3->tmp.next_state=SSL3_ST_SR_NEXT_PROTO_A;
++					}
+ 				else
+ 					s->s3->tmp.next_state=SSL3_ST_SR_FINISHED_A;
+ #endif

meta/recipes-connectivity/openssl/openssl/openssl-1.0.1e-cve-2014-3470.patch

@@ -0,0 +1,31 @@
+commit 4ad43d511f6cf064c66eb4bfd0fb0919b5dd8a86
+Author: Dr. Stephen Henson <steve@openssl.org>
+Date:   Thu May 29 15:00:05 2014 +0100
+
+    Fix CVE-2014-3470
+    
+    Check session_cert is not NULL before dereferencing it.
+
+Patch borrowed from Fedora
+Upstream-Status: Backport
+Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
+
+
+diff --git a/ssl/s3_clnt.c b/ssl/s3_clnt.c
+index d35376d..4324f8d 100644
+--- a/ssl/s3_clnt.c
++++ b/ssl/s3_clnt.c
+@@ -2511,6 +2511,13 @@ int ssl3_send_client_key_exchange(SSL *s)
+ 			int ecdh_clnt_cert = 0;
+ 			int field_size = 0;
+ 
++			if (s->session->sess_cert == NULL) 
++				{
++				ssl3_send_alert(s,SSL3_AL_FATAL,SSL_AD_UNEXPECTED_MESSAGE);
++				SSLerr(SSL_F_SSL3_SEND_CLIENT_KEY_EXCHANGE,SSL_R_UNEXPECTED_MESSAGE);
++				goto err;
++				}
++
+ 			/* Did we send out the client's
+ 			 * ECDH share for use in premaster
+ 			 * computation as part of client certificate?

meta/recipes-connectivity/openssl/openssl/openssl-CVE-2010-5298.patch

@@ -0,0 +1,24 @@
+openssl fix for CVE-2010-5298
+
+Upstream-Status: Backport
+
+Race condition in the ssl3_read_bytes function in s3_pkt.c in OpenSSL
+through 1.0.1g, when SSL_MODE_RELEASE_BUFFERS is enabled, allows remote
+attackers to inject data across sessions or cause a denial of service
+(use-after-free and parsing error) via an SSL connection in a
+multithreaded environment.
+
+http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-5298
+
+Signed-off-by: Yue Tao <Yue.Tao@windriver.com>
+--- a/ssl/s3_pkt.c
++++ b/ssl/s3_pkt.c
+@@ -1013,7 +1013,7 @@ start:
+ 				{
+ 				s->rstate=SSL_ST_READ_HEADER;
+ 				rr->off=0;
+-				if (s->mode & SSL_MODE_RELEASE_BUFFERS)
++				if (s->mode & SSL_MODE_RELEASE_BUFFERS && s->s3->rbuf.left == 0)
+ 					ssl3_release_read_buffer(s);
+ 				}
+ 			}

meta/recipes-connectivity/openssl/openssl_1.0.1g.bb

@@ -34,6 +34,12 @@ SRC_URI += "file://configure-targets.patch \
             file://initial-aarch64-bits.patch \
             file://find.pl \
             file://openssl-fix-des.pod-error.patch \
+            file://openssl-1.0.1e-cve-2014-0195.patch \
+            file://openssl-1.0.1e-cve-2014-0198.patch \
+            file://openssl-1.0.1e-cve-2014-0221.patch \
+            file://openssl-1.0.1e-cve-2014-0224.patch \
+            file://openssl-1.0.1e-cve-2014-3470.patch \
+            file://openssl-CVE-2010-5298.patch \
            "
 
 SRC_URI[md5sum] = "de62b43dfcd858e66a74bee1c834e959"

meta/recipes-connectivity/wpa-supplicant/wpa-supplicant.inc

@@ -6,7 +6,7 @@ LICENSE = "BSD"
 LIC_FILES_CHKSUM = "file://COPYING;md5=ab87f20cd7e8c0d0a6539b34d3791d0e \
                     file://README;beginline=1;endline=56;md5=a07250b28e857455336bb59fc31cb845 \
                     file://wpa_supplicant/wpa_supplicant.c;beginline=1;endline=12;md5=e8e021e30f3a6ab7c341b66b86626a5a"
-DEPENDS = "gnutls dbus libnl openssl"
+DEPENDS = "gnutls dbus libnl openssl libgcrypt"
 RRECOMMENDS_${PN} = "wpa-supplicant-passphrase wpa-supplicant-cli"
 
 inherit systemd

meta/recipes-core/console-tools/console-tools-0.3.2/no-dep-on-libfl.patch

@@ -0,0 +1,19 @@
+No reason to link with libfl since 'loadkeys' implements
+its own yywrap()/yylex() functions.
+
+Upstream-Status: Pending
+Signed-off-by: Jacob Kroon <jacob.kroon@mikrodidakt.se>
+
+Index: console-tools-0.3.2/kbdtools/Makefile.am
+===================================================================
+--- console-tools-0.3.2.orig/kbdtools/Makefile.am
++++ console-tools-0.3.2/kbdtools/Makefile.am
+@@ -19,8 +19,6 @@ LDADD = ../lib/ctlocal/libctlocal.a ../l
+ 	../lib/cfont/libcfont.la \
+ 	../lib/console/libconsole.la ../lib/generic/libctgeneric.la
+ 
+-loadkeys_LDADD = $(LDADD) @LEXLIB@
+-
+ bin_SCRIPTS = mk_modmap
+ 
+ noinst_HEADERS = loadkeys.h

meta/recipes-core/console-tools/console-tools_0.3.2.bb

@@ -13,6 +13,7 @@ SRC_URI = "${SOURCEFORGE_MIRROR}/lct/console-tools-${PV}.tar.gz \
            file://uclibc-fileno.patch \
            file://nodocs.patch \
            file://fix-libconsole-linking.patch \
+           file://no-dep-on-libfl.patch \
            file://lcmessage.m4 \
            file://Makevars"
 

meta/recipes-core/dbus/dbus.inc

@@ -6,9 +6,11 @@ LICENSE = "AFL-2 | GPLv2+"
 LIC_FILES_CHKSUM = "file://COPYING;md5=10dded3b58148f3f1fd804b26354af3e \
                     file://dbus/dbus.h;beginline=6;endline=20;md5=7755c9d7abccd5dbd25a6a974538bb3c"
 DEPENDS = "expat virtual/libintl"
-RDEPENDS_dbus = "${@base_contains('DISTRO_FEATURES', 'ptest', 'dbus-ptest-ptest', '', d)}"
 RDEPENDS_dbus_class-native = ""
 RDEPENDS_dbus_class-nativesdk = ""
+PACKAGES += "${@bb.utils.contains('PTEST_ENABLED', '1', 'dbus-ptest', '', d)}"
+ALLOW_EMPTY_dbus-ptest = "1"
+RDEPENDS_dbus-ptest_class-target = "dbus-test-ptest"
 
 SRC_URI = "http://dbus.freedesktop.org/releases/dbus/dbus-${PV}.tar.gz \
            file://tmpdir.patch \