dev-manual: Updated the "Making Images More Secure" section.

Fixes [YOCTO #5482]

I did some significant re-writing and re-organization of this
section.  It now includes a bit about securing an image in general,
provides general considerations, considerations specific to the
OpenEmbedded build system, pointers to some tools in meta-security
layer, and some other items.

I added some key references to the section on considerations
specific to the OpenEmbedded build system.  In particular, I
provided some cross-linking back to the extrausers.bbclass
section to reference an example of adding a user account.  I
also split out the topics of adding an extra user and setting
a password on the image in the bulleted list.

Updated the setting root and extra user's passwords.  Also,
permanently removed the reference to the wiki that showed the
less optimal way of setting a root password.

Added a cross-reference to the meta-selinux layer in the section
that describes how to make images more secure.

(From yocto-docs rev: 812bf8e2c91c4dd14a2245509ea7008a24e90835)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
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/codeparser.py

@@ -35,7 +35,7 @@ def check_indent(codestr):
 
 class CodeParserCache(MultiProcessCache):
     cache_file_name = "bb_codeparser.dat"
-    CACHE_VERSION = 4
+    CACHE_VERSION = 6
 
     def __init__(self):
         MultiProcessCache.__init__(self)
@@ -102,7 +102,7 @@ class BufferedLogger(Logger):
         self.buffer = []
 
 class PythonParser():
-    getvars = ("d.getVar", "bb.data.getVar", "data.getVar", "d.appendVar", "d.prependVar")
+    getvars = (".getVar", ".appendVar", ".prependVar")
     containsfuncs = ("bb.utils.contains", "base_contains", "oe.utils.contains")
     execfuncs = ("bb.build.exec_func", "bb.build.exec_task")
 
@@ -122,7 +122,7 @@ class PythonParser():
 
     def visit_Call(self, node):
         name = self.called_node_name(node.func)
-        if name in self.getvars or name in self.containsfuncs:
+        if name and name.endswith(self.getvars) or name in self.containsfuncs:
             if isinstance(node.args[0], ast.Str):
                 varname = node.args[0].s
                 if name in self.containsfuncs and isinstance(node.args[1], ast.Str):
@@ -217,6 +217,15 @@ class ShellParser():
             self.execs = codeparsercache.shellcacheextras[h]["execs"]
             return self.execs
 
+        self._parse_shell(value)
+        self.execs = set(cmd for cmd in self.allexecs if cmd not in self.funcdefs)
+
+        codeparsercache.shellcacheextras[h] = {}
+        codeparsercache.shellcacheextras[h]["execs"] = self.execs
+
+        return self.execs
+
+    def _parse_shell(self, value):
         try:
             tokens, _ = pyshyacc.parse(value, eof=True, debug=False)
         except pyshlex.NeedMore:
@@ -224,12 +233,6 @@ class ShellParser():
 
         for token in tokens:
             self.process_tokens(token)
-        self.execs = set(cmd for cmd in self.allexecs if cmd not in self.funcdefs)
-
-        codeparsercache.shellcacheextras[h] = {}
-        codeparsercache.shellcacheextras[h]["execs"] = self.execs
-
-        return self.execs
 
     def process_tokens(self, tokens):
         """Process a supplied portion of the syntax tree as returned by
@@ -303,7 +306,7 @@ class ShellParser():
 
                 if part[0] in ('`', '$('):
                     command = pyshlex.wordtree_as_string(part[1:-1])
-                    self.parse_shell(command)
+                    self._parse_shell(command)
 
                     if word[0] in ("cmd_name", "cmd_word"):
                         if word in words:
@@ -322,7 +325,7 @@ class ShellParser():
                     self.log.debug(1, self.unhandled_template % cmd)
                 elif cmd == "eval":
                     command = " ".join(word for _, word in words[1:])
-                    self.parse_shell(command)
+                    self._parse_shell(command)
                 else:
                     self.allexecs.add(cmd)
                 break

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,19 @@
             </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>
+            <revision>
+                <revnumber>1.6.2</revnumber>
+                <date>November 2014</date>
+                <revremark>Released with the Yocto Project 1.6.2 Release.</revremark>
+            </revision>
        </revhistory>
 
     <copyright>

documentation/bsp-guide/bsp-guide.xml

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

documentation/kernel-dev/kernel-dev.xml

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

documentation/poky.ent

@@ -1,9 +1,9 @@
-<!ENTITY DISTRO "1.6">
-<!ENTITY DISTRO_COMPRESSED "16">
+<!ENTITY DISTRO "1.6.2">
+<!ENTITY DISTRO_COMPRESSED "162">
 <!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.2">
+<!ENTITY POKYVERSION "11.0.2">
+<!ENTITY POKYVERSION_COMPRESSED "1102">
 <!ENTITY YOCTO_POKY "poky-&DISTRO_NAME;-&POKYVERSION;">
 <!ENTITY COPYRIGHT_YEAR "2010-2014">
 <!ENTITY YOCTO_DL_URL "http://downloads.yoctoproject.org">
@@ -14,7 +14,7 @@
 <!ENTITY YOCTO_AB_URL "http://autobuilder.yoctoproject.org">
 <!ENTITY YOCTO_GIT_URL "http://git.yoctoproject.org">
 <!ENTITY YOCTO_ADTREPO_URL "http://adtrepo.yoctoproject.org">
-<!ENTITY YOCTO_RELEASE_NOTES "&YOCTO_HOME_URL;/download/yocto-project-&DISTRO_COMPRESSED;-poky-&POKYVERSION_COMPRESSED;">
+<!ENTITY YOCTO_RELEASE_NOTES "&YOCTO_HOME_URL;/downloads/core/&DISTRO_NAME;&DISTRO_COMPRESSED;">
 <!ENTITY OE_HOME_URL "http://www.openembedded.org">
 <!ENTITY OE_LISTS_URL "http://lists.openembedded.org/mailman">
 <!ENTITY OE_DOCS_URL "http://docs.openembedded.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-usage.xml

@@ -842,7 +842,7 @@
                 idea.  One of the first projects to do this was IBM's DProbes
                 dpcc compiler, an ANSI C compiler which targeted a low-level
                 assembly language running on an in-kernel interpreter on the
-                target system.  This is exactly analagous to what Sun's DTrace
+                target system.  This is exactly analogous to what Sun's DTrace
                 did, except that DTrace invented its own language for the purpose.
                 Systemtap, heavily inspired by DTrace, also created its own
                 one-off language, but rather than running the product on an
@@ -1275,7 +1275,7 @@
             </para>
 
             <informalexample>
-                <emphasis>Tying it Together:</emphasis> The trace events subsystem accomodate static
+                <emphasis>Tying it Together:</emphasis> The trace events subsystem accommodate static
                 and dynamic tracepoints in exactly the same way - there's no
                 difference as far as the infrastructure is concerned.  See the
                 ftrace section for more details on the trace event subsystem.
@@ -3257,15 +3257,25 @@
         <title>Documentation</title>
 
         <para>
-            There doesn't seem to be any current documentation covering
-            LTTng 2.0, but maybe that's because the project is in transition.
-            The LTTng 2.0 website, however, is here:
-            <ulink url='http://lttng.org/lttng2.0'>LTTng Project</ulink>
+            You can find the primary LTTng Documentation on the
+            <ulink url='https://lttng.org/docs/'>LTTng Documentation</ulink>
+            site.
+            The documentation on this site is appropriate for intermediate to
+            advanced software developers who are working in a Linux environment
+            and are interested in efficient software tracing.
         </para>
 
         <para>
-            You can access extensive help information on how to use the
-            LTTng plug-in to search and analyze captured traces via the
+            For information on LTTng in general, visit the
+            <ulink url='http://lttng.org/lttng2.0'>LTTng Project</ulink>
+            site.
+            You can find a "Getting Started" link on this site that takes
+            you to an LTTng Quick Start.
+        </para>
+
+        <para>
+            Finally, you can access extensive help information on how to use
+            the LTTng plug-in to search and analyze captured traces via the
             Eclipse help system:
             <literallayout class='monospaced'>
      Help | Help Contents | LTTng Plug-in User Guide

documentation/profile-manual/profile-manual.xml

@@ -48,9 +48,19 @@
             </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>
+            <revision>
+                <revnumber>1.6.2</revnumber>
+                <date>November 2014</date>
+                <revremark>Released with the Yocto Project 1.6.2 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>
 
@@ -302,11 +306,17 @@
             <para>
                 The following list shows the required packages by function
                 given a supported CentOS Linux distribution:
-                <note>Depending on the CentOS version you are using, other requirements
-                    and dependencies might exist.
-                    For details, you should look at the CentOS sections on the
-                    <ulink url='https://wiki.yoctoproject.org/wiki/Poky/GettingStarted/Dependencies'>Poky/GettingStarted/Dependencies</ulink>
-                    wiki page.
+                <note>
+                    For CentOS 6.x, some of the versions of the components
+                    provided by the distribution are too old (e.g. Git, Python,
+                    and tar).
+                    It is recommended that you install the buildtools in order
+                    to provide versions that will work with the OpenEmbedded
+                    build system.
+                    For information on how to install the buildtools tarball,
+                    see the
+                    "<link linkend='required-git-tar-and-python-versions'>Required Git, Tar, and Python Versions</link>"
+                    section.
                 </note>
                 <itemizedlist>
                     <listitem><para><emphasis>Essentials:</emphasis>

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,19 @@
             </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>
+            <revision>
+                <revnumber>1.6.2</revnumber>
+                <date>November 2014</date>
+                <revremark>Released with the Yocto Project 1.6.2 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>

documentation/ref-manual/ref-structure.xml

@@ -63,9 +63,8 @@
         </para>
 
         <para>
-            For more information on BitBake, see the BitBake documentation
-            included in the <filename>bitbake/doc/manual</filename> directory of the
-            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+            For more information on BitBake, see the
+            <ulink url='&YOCTO_DOCS_BB_URL;'>BitBake User Manual</ulink>.
         </para>
     </section>
 

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>
@@ -2373,9 +2431,8 @@
                     used by the OpenEmbedded build system for creating
                     <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>.
                     You can find more information on how overrides are handled
-                    in the BitBake Manual that is located at
-                    <filename>bitbake/doc/manual</filename> in the
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                    in the
+                    <ulink url='&YOCTO_DOCS_BB_URL;'>BitBake Manual</ulink>.
                 </para>
 
                 <para>
@@ -2920,33 +2977,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 +3030,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 +3767,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 +4689,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>
@@ -4887,9 +5068,8 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     what variables are overridden after BitBake parses
                     recipes and configuration files.
                     You can find more information on how overrides are handled
-                    in the BitBake Manual that is located at
-                    <filename>bitbake/doc/manual</filename> in the
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                    in the
+                    <ulink url='&YOCTO_DOCS_BB_URL;'>BitBake Manual</ulink>.
                 </para>
             </glossdef>
         </glossentry>
@@ -5049,18 +5229,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 +7360,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 +7385,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 +7406,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 +7562,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 +7619,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 +7654,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,31 @@
-# 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
+# Processes poky-ref-manual and yocto-project-qs manual (<word>-<word>-<word> style).
+# This style is for manual folders like "yocto-project-qs" and "poky-ref-manual".
+# This is the old way that did it.  Can't do that now that we have "bitbake-user-manual" strings
+# in the mega-manual.
+# s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.6.2\/[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.2\/yocto-project-qs\/yocto-project-qs.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.6.2\/poky-ref-manual\/poky-ref-manual.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
+# Processes all other manuals (<word>-<word> style) except for the BitBake User Manual because
+# it is not included in the mega-manual.
+# This style is for manual folders that use two word, which is the standard now (e.g. "ref-manual").
+# This was the one-liner that worked before we introduced the BitBake User Manual, which is
+# not in the mega-manual.
+# s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.6.2\/[a-z]*-[a-z]*\/[a-z]*-[a-z]*.html#/\"link\" href=\"#/g
+
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.6.2\/adt-manual\/adt-manual.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.6.2\/bsp-guide\/bsp-guide.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.6.2\/dev-manual\/dev-manual.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.6.2\/kernel-dev\/kernel-dev.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.6.2\/profile-manual\/profile-manual.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.6.2\/ref-manual\/ref-manual.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.6.2\/yocto-project-qs\/yocto-project-qs.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.2\/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.2\/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.2\/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.2\/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.2\/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.2\/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.2\/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

@@ -528,7 +528,7 @@
              <filename>bitbake --help</filename> command, see the
              "<ulink url='&YOCTO_DOCS_REF_URL;#usingpoky-components-bitbake'>BitBake</ulink>"
              section in the Yocto Project Reference Manual, or see the
-             "<ulink url='&YOCTO_DOCS_BB_URL;#user-manual-command'>BitBake Command</ulink>"
+             "<ulink url='&YOCTO_DOCS_BB_URL;#bitbake-user-manual-command'>BitBake Command</ulink>"
              section in the BitBake User Manual.
              <literallayout class='monospaced'>
      $ bitbake -k core-image-sato
@@ -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.2"
+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/crosssdk.bbclass

@@ -1,6 +1,7 @@
 inherit cross
 
 CLASSOVERRIDE = "class-crosssdk"
+MACHINEOVERRIDES = ""
 PACKAGE_ARCH = "${SDK_ARCH}"
 python () {
 	# set TUNE_PKGARCH to SDK_ARCH

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 -name "*.so.dbg" -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}"
@@ -100,6 +104,7 @@ PKG_CONFIG_SYSROOT_DIR = ""
 # we dont want libc-uclibc or libc-glibc to kick in for native recipes
 LIBCOVERRIDE = ""
 CLASSOVERRIDE = "class-native"
+MACHINEOVERRIDES = ""
 
 PATH_prepend = "${COREBASE}/scripts/native-intercept:"
 

meta/classes/nativesdk.bbclass

@@ -8,6 +8,7 @@ STAGING_BINDIR_TOOLCHAIN = "${STAGING_DIR_NATIVE}${bindir_native}/${SDK_ARCH}${S
 NATIVESDKLIBC ?= "libc-glibc"
 LIBCOVERRIDE = ":${NATIVESDKLIBC}"
 CLASSOVERRIDE = "class-nativesdk"
+MACHINEOVERRIDES = ""
 
 #
 # Update PACKAGE_ARCH and PACKAGE_ARCHS

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/populate_sdk_base.bbclass

@@ -284,7 +284,7 @@ done
 
 # find out all perl scripts in $native_sysroot and modify them replacing the
 # host perl with SDK perl.
-for perl_script in $($SUDO_EXEC grep "^#!.*perl" -rl $native_sysroot); do
+for perl_script in $($SUDO_EXEC find $native_sysroot -type f -exec grep "^#!.*perl" -l '{}' \;); do
 	$SUDO_EXEC sed -i -e "s:^#! */usr/bin/perl.*:#! /usr/bin/env perl:g" -e \
 		"s: /usr/bin/perl: /usr/bin/env perl:g" $perl_script
 done

meta/classes/populate_sdk_deb.bbclass

@@ -1,11 +1,16 @@
 do_populate_sdk[depends] += "dpkg-native:do_populate_sysroot apt-native:do_populate_sysroot bzip2-native:do_populate_sysroot"
 
-DEB_SDK_ARCH = "${@[d.getVar('SDK_ARCH', True), "i386"]\
-                [d.getVar('SDK_ARCH', True) in \
-                ["x86", "i486", "i586", "i686", "pentium"]]}"
+python () {
+    # Map TARGET_ARCH to Debian's ideas about architectures
+    darch = d.getVar('SDK_ARCH', True)
+    if darch in ["x86", "i486", "i586", "i686", "pentium"]:
+         d.setVar('DEB_SDK_ARCH', 'i386')
+    elif darch == "x86_64":
+         d.setVar('DEB_SDK_ARCH', 'amd64')
+    elif darch == "arm":
+         d.setVar('DEB_SDK_ARCH', 'armel')
+}
 
-DEB_SDK_ARCH = "${@[d.getVar('SDK_ARCH', True), "amd64"]\
-                [d.getVar('SDK_ARCH', True) == "x86_64"]}"
 
 do_populate_sdk[lockfiles] += "${DEPLOY_DIR_DEB}/deb.lock"
 

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/systemd.bbclass

@@ -55,6 +55,7 @@ fi
 
 
 systemd_populate_packages[vardeps] += "systemd_prerm systemd_postinst"
+systemd_populate_packages[vardepsexclude] += "OVERRIDES"
 
 python systemd_populate_packages() {
     if not oe.utils.contains('DISTRO_FEATURES', 'systemd', True, False, d):

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,8 +68,10 @@ 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"
+populate_packages_updatercd[vardepsexclude] += "OVERRIDES"
 
 python populate_packages_updatercd () {
     def update_rcd_auto_depend(pkg):

meta/classes/useradd-staticids.bbclass

@@ -58,7 +58,9 @@ def update_useradd_static_config(d):
 
         newparams = []
         for param in re.split('''[ \t]*;[ \t]*(?=(?:[^'"]|'[^']*'|"[^"]*")*$)''', params):
-            param=param.strip()
+            param = param.strip()
+            if not param:
+                continue
             try:
                 uaargs = parser.parse_args(re.split('''[ \t]*(?=(?:[^'"]|'[^']*'|"[^"]*")*$)''', param))
             except:
@@ -194,7 +196,9 @@ def update_useradd_static_config(d):
 
         newparams = []
         for param in re.split('''[ \t]*;[ \t]*(?=(?:[^'"]|'[^']*'|"[^"]*")*$)''', params):
-            param=param.strip()
+            param = param.strip()
+            if not param:
+                continue
             try:
                 # If we're processing multiple lines, we could have left over values here...
                 gaargs = parser.parse_args(re.split('''[ \t]*(?=(?:[^'"]|'[^']*'|"[^"]*")*$)''', param))

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/conf/layer.conf

@@ -14,6 +14,7 @@ LAYERVERSION_core = "4"
 # Set a variable to get to the top of the metadata location
 COREBASE = '${@os.path.normpath("${LAYERDIR}/../")}'
 
+# opkg-utils is for update-altnernatives :(
 SIGGEN_EXCLUDERECIPES_ABISAFE += " \
   sysvinit-inittab \
   shadow-securetty \
@@ -30,4 +31,9 @@ SIGGEN_EXCLUDERECIPES_ABISAFE += " \
   udev-extraconf \
   packagegroup-x11-xserver \
   systemd-serialgetty \
+  initscripts \                                                                                                                                                                                                                                    
+  shadow \
+  shadow-sysroot \
+  base-passwd \
+  opkg-utils \
 "

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/sshd@.service

@@ -8,3 +8,4 @@ ExecStart=-@SBINDIR@/sshd -i
 ExecReload=@BASE_BINDIR@/kill -HUP $MAINPID
 StandardInput=socket
 StandardError=syslog
+KillMode=process

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.inc

@@ -9,6 +9,7 @@ LICENSE = "openssl"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=f9a8f968107345e0b75aa8c2ecaa7ec8"
 
 DEPENDS = "perl-native-runtime"
+DEPENDS_append_class-target = " openssl-native"
 
 SRC_URI = "http://www.openssl.org/source/openssl-${PV}.tar.gz \
           "
@@ -30,14 +31,14 @@ export DIRS = "crypto ssl apps"
 export EX_LIBS = "-lgcc -ldl"
 export AS = "${CC} -c"
 
-inherit pkgconfig siteinfo multilib_header
+inherit pkgconfig siteinfo multilib_header ptest
 
 PACKAGES =+ "libcrypto libssl ${PN}-misc openssl-conf"
 FILES_libcrypto = "${base_libdir}/libcrypto${SOLIBS}"
 FILES_libssl = "${libdir}/libssl.so.*"
 FILES_${PN} =+ " ${libdir}/ssl/*"
 FILES_${PN}-misc = "${libdir}/ssl/misc ${bindir}/c_rehash"
-RDEPENDS_${PN}-misc = "${@base_contains('PACKAGECONFIG', 'perl', 'perl', '', d)}"
+RDEPENDS_${PN}-misc = "${@bb.utils.contains('PACKAGECONFIG', 'perl', 'perl', '', d)}"
 FILES_${PN}-dev += "${base_libdir}/libcrypto${SOLIBSDEV}"
 
 # Add the openssl.cnf file to the openssl-conf package.  Make the libcrypto
@@ -47,6 +48,7 @@ FILES_${PN}-dev += "${base_libdir}/libcrypto${SOLIBSDEV}"
 FILES_openssl-conf = "${libdir}/ssl/openssl.cnf"
 CONFFILES_openssl-conf = "${libdir}/ssl/openssl.cnf"
 RRECOMMENDS_libcrypto += "openssl-conf"
+RDEPENDS_${PN}-ptest += "${PN}-misc make perl perl-module-filehandle bc"
 
 do_configure_prepend_darwin () {
 	sed -i -e '/version-script=openssl\.ld/d' Configure
@@ -59,17 +61,18 @@ do_configure () {
 	ln -sf apps/openssl.pod crypto/crypto.pod ssl/ssl.pod doc/
 
 	os=${HOST_OS}
-	if [ "x$os" = "xlinux-uclibc" ]; then
+	case $os in
+	linux-uclibc |\
+	linux-uclibceabi |\
+	linux-gnueabi |\
+	linux-uclibcspe |\
+	linux-gnuspe |\
+	linux-musl*)
 		os=linux
-	elif [ "x$os" = "xlinux-uclibceabi" ]; then
-		os=linux
-	elif [ "x$os" = "xlinux-uclibcspe" ]; then
-		os=linux
-	elif [ "x$os" = "xlinux-gnuspe" ]; then
-		os=linux
-	elif [ "x$os" = "xlinux-gnueabi" ]; then
-		os=linux
-	fi
+		;;
+		*)
+		;;
+	esac
 	target="$os-${HOST_ARCH}"
 	case $target in
 	linux-arm)
@@ -136,10 +139,18 @@ do_configure () {
 	perl ./Configure ${EXTRA_OECONF} shared --prefix=$useprefix --openssldir=${libdir}/ssl --libdir=`basename ${libdir}` $target
 }
 
+do_compile_prepend_class-target () {
+    sed -i 's/\((OPENSSL=\)".*"/\1"openssl"/' Makefile
+}
+
 do_compile () {
 	oe_runmake
 }
 
+do_compile_ptest () {
+	oe_runmake buildtest
+}
+
 do_install () {
 	oe_runmake INSTALL_PREFIX="${D}" MANDIR="${mandir}" install
 
@@ -157,7 +168,7 @@ do_install () {
 	cp --dereference -R include/openssl ${D}${includedir}
 
 	oe_multilib_header openssl/opensslconf.h
-	if [ "${@base_contains('PACKAGECONFIG', 'perl', 'perl', '', d)}" = "perl" ]; then
+	if [ "${@bb.utils.contains('PACKAGECONFIG', 'perl', 'perl', '', d)}" = "perl" ]; then
 		install -m 0755 ${S}/tools/c_rehash ${D}${bindir}
 		sed -i -e '1s,.*,#!${bindir}/env perl,' ${D}${bindir}/c_rehash
 		sed -i -e '1s,.*,#!${bindir}/env perl,' ${D}${libdir}/ssl/misc/CA.pl
@@ -169,5 +180,18 @@ do_install () {
 	fi
 }
 
+do_install_ptest () {
+	cp -r Makefile test ${D}${PTEST_PATH}
+	cp -r certs ${D}${PTEST_PATH}
+	mkdir -p ${D}${PTEST_PATH}/apps
+	ln -sf /usr/lib/ssl/misc/CA.sh  ${D}${PTEST_PATH}/apps
+	ln -sf /usr/lib/ssl/openssl.cnf ${D}${PTEST_PATH}/apps
+	ln -sf /usr/bin/openssl         ${D}${PTEST_PATH}/apps
+	cp apps/server2.pem             ${D}${PTEST_PATH}/apps
+	mkdir -p ${D}${PTEST_PATH}/util
+	install util/opensslwrap.sh    ${D}${PTEST_PATH}/util
+	install util/shlib_wrap.sh     ${D}${PTEST_PATH}/util
+}
+
 BBCLASSEXTEND = "native nativesdk"