41 files changed, 16110 insertions, 0 deletions

diff --git a/documentation/ref-manual/TODO b/documentation/ref-manual/TODO
new file mode 100644
index 0000000..ee0db97
--- /dev/null
+++ b/documentation/ref-manual/TODO
@@ -0,0 +1,11 @@
+Handbook Todo List:
+
+  * Document adding a new IMAGE_FEATURE to the customising images section 
+  * Add instructions about using zaurus/openmoko emulation
+  * Add component overview/block diagrams
+  * Software Deevelopment intro should mention its software development for 
+    intended target and could be a different arch etc and thus special case. 
+  * Expand insane.bbclass documentation to cover tests
+  * Document remaining classes (see list in ref-classes)
+  * Document formfactor
+
diff --git a/documentation/ref-manual/closer-look.xml b/documentation/ref-manual/closer-look.xml
new file mode 100644
index 0000000..4883981
--- /dev/null
+++ b/documentation/ref-manual/closer-look.xml
@@ -0,0 +1,1224 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='closer-look'>
+<title>A Closer Look at the Yocto Project Development Environment</title>
+
+    <para>
+        This chapter takes a more detailed look at the Yocto Project
+        development environment.
+        The following diagram represents the development environment at a
+        high level.
+        The remainder of this chapter expands on the fundamental input, output,
+        process, and
+        <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>) blocks
+        in the Yocto Project development environment.
+    </para>
+
+    <para id='general-yocto-environment-figure'>
+        <imagedata fileref="figures/yocto-environment-ref.png" align="center" width="8in" depth="4.25in" />
+    </para>
+
+    <para>
+        The generalized Yocto Project Development Environment consists of
+        several functional areas:
+        <itemizedlist>
+            <listitem><para><emphasis>User Configuration:</emphasis>
+                Metadata you can use to control the build process.
+                </para></listitem>
+            <listitem><para><emphasis>Metadata Layers:</emphasis>
+                Various layers that provide software, machine, and
+                distro Metadata.</para></listitem>
+            <listitem><para><emphasis>Source Files:</emphasis>
+                Upstream releases, local projects, and SCMs.</para></listitem>
+            <listitem><para><emphasis>Build System:</emphasis>
+                Processes under the control of BitBake.
+                This block expands on how BitBake fetches source, applies
+                patches, completes compilation, analyzes output for package
+                generation, creates and tests packages, generates images, and
+                generates cross-development tools.</para></listitem>
+            <listitem><para><emphasis>Package Feeds:</emphasis>
+                Directories containing output packages (rpm, deb or ipk),
+                which are subsequently used in the construction of an image or
+                SDK, produced by the build system.
+                These feeds can also be copied and shared using a web server or
+                other means to facilitate extending or updating existing
+                images on devices at runtime if runtime package management is
+                enabled.</para></listitem>
+            <listitem><para><emphasis>Images:</emphasis>
+                Images produced by the development process.
+                Where do they go?
+                Can you mess with them (i.e. freely delete them or move them?).
+                </para></listitem>
+            <listitem><para><emphasis>Application Development SDK:</emphasis>
+                Cross-development tools that are produced along with an image
+                or separately with BitBake.</para></listitem>
+        </itemizedlist>
+    </para>
+
+    <section id="user-configuration">
+        <title>User Configuration</title>
+
+        <para>
+            User configuration helps define the build.
+            Through user configuration, you can tell BitBake the
+            target architecture for which you are building the image,
+            where to store downloaded source, and other build properties.
+        </para>
+
+        <para>
+            The following figure shows an expanded representation of the
+            "User Configuration" box of the
+            <link linkend='general-yocto-environment-figure'>general Yocto Project Development Environment figure</link>:
+        </para>
+
+        <para>
+            <imagedata fileref="figures/user-configuration.png" align="center" width="5.5in" depth="3.5in" />
+        </para>
+
+        <para>
+            BitBake needs some basic configuration files in order to complete
+            a build.
+            These files are <filename>*.conf</filename> files.
+            The minimally necessary ones reside as example files in the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+            For simplicity, this section refers to the Source Directory as
+            the "Poky Directory."
+        </para>
+
+        <para>
+            When you clone the <filename>poky</filename> Git repository or you
+            download and unpack a Yocto Project release, you can set up the
+            Source Directory to be named anything you want.
+            For this discussion, the cloned repository uses the default
+            name <filename>poky</filename>.
+            <note>
+                The Poky repository is primarily an aggregation of existing
+                repositories.
+                It is not a canonical upstream source.
+            </note>
+        </para>
+
+        <para>
+            The <filename>meta-yocto</filename> layer inside Poky contains
+            a <filename>conf</filename> directory that has example
+            configuration files.
+            These example files are used as a basis for creating actual
+            configuration files when you source the build environment
+            script
+            (i.e.
+            <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
+            or
+            <link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>).
+        </para>
+
+        <para>
+            Sourcing the build environment script creates a
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+            if one does not already exist.
+            BitBake uses the Build Directory for all its work during builds.
+            The Build Directory has a <filename>conf</filename> directory that
+            contains default versions of your <filename>local.conf</filename>
+            and <filename>bblayers.conf</filename> configuration files.
+            These default configuration files are created only if versions
+            do not already exist in the Build Directory at the time you
+            source the build environment setup script.
+        </para>
+
+        <para>
+            Because the Poky repository is fundamentally an aggregation of
+            existing repositories, some users might be familiar with running
+            the <filename>&OE_INIT_FILE;</filename> or
+            <filename>oe-init-build-env-memres</filename> script in the context
+            of separate OpenEmbedded-Core and BitBake repositories rather than a
+            single Poky repository.
+            This discussion assumes the script is executed from within a cloned
+            or unpacked version of Poky.
+        </para>
+
+        <para>
+            Depending on where the script is sourced, different sub-scripts
+            are called to set up the Build Directory (Yocto or OpenEmbedded).
+            Specifically, the script
+            <filename>scripts/oe-setup-builddir</filename> inside the
+            poky directory sets up the Build Directory and seeds the directory
+            (if necessary) with configuration files appropriate for the
+            Yocto Project development environment.
+            <note>
+                The <filename>scripts/oe-setup-builddir</filename> script
+                uses the <filename>$TEMPLATECONF</filename> variable to
+                determine which sample configuration files to locate.
+            </note>
+        </para>
+
+        <para>
+            The <filename>local.conf</filename> file provides many
+            basic variables that define a build environment.
+            Here is a list of a few.
+            To see the default configurations in a <filename>local.conf</filename>
+            file created by the build environment script, see the
+            <filename>local.conf.sample</filename> in the
+            <filename>meta-yocto</filename> layer:
+            <itemizedlist>
+                <listitem><para><emphasis>Parallelism Options:</emphasis>
+                    Controlled by the
+                    <link linkend='var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></link>
+                    and
+                    <link linkend='var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></link>
+                    variables.</para></listitem>
+                <listitem><para><emphasis>Target Machine Selection:</emphasis>
+                    Controlled by the
+                    <link linkend='var-MACHINE'><filename>MACHINE</filename></link>
+                    variable.</para></listitem>
+                <listitem><para><emphasis>Download Directory:</emphasis>
+                    Controlled by the
+                    <link linkend='var-DL_DIR'><filename>DL_DIR</filename></link>
+                    variable.</para></listitem>
+                <listitem><para><emphasis>Shared State Directory:</emphasis>
+                    Controlled by the
+                    <link linkend='var-SSTATE_DIR'><filename>SSTATE_DIR</filename></link>
+                    variable.</para></listitem>
+                <listitem><para><emphasis>Build Output:</emphasis>
+                    Controlled by the
+                    <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>
+                    variable.</para></listitem>
+            </itemizedlist>
+            <note>
+                Configurations set in the <filename>conf/local.conf</filename>
+                file can also be set in the
+                <filename>conf/site.conf</filename> and
+                <filename>conf/auto.conf</filename> configuration files.
+            </note>
+        </para>
+
+        <para>
+            The <filename>bblayers.conf</filename> file tells BitBake what
+            layers you want considered during the build.
+            By default, the layers listed in this file include layers
+            minimally needed by the build system.
+            However, you must manually add any custom layers you have created.
+            You can find more information on working with the
+            <filename>bblayers.conf</filename> file in the
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#enabling-your-layer'>Enabling Your Layer</ulink>"
+            section in the Yocto Project Development Manual.
+        </para>
+
+        <para>
+            The files <filename>site.conf</filename> and
+            <filename>auto.conf</filename> are not created by the environment
+            initialization script.
+            If you want these configuration files, you must create them
+            yourself:
+            <itemizedlist>
+                <listitem><para><emphasis><filename>site.conf</filename>:</emphasis>
+                    You can use the <filename>conf/site.conf</filename>
+                    configuration file to configure multiple build directories.
+                    For example, suppose you had several build environments and
+                    they shared some common features.
+                    You can set these default build properties here.
+                    A good example is perhaps the level of parallelism you want
+                    to use through the
+                    <link linkend='var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></link>
+                    and
+                    <link linkend='var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></link>
+                    variables.</para>
+                    <para>One useful scenario for using the
+                    <filename>conf/site.conf</filename> file is to extend your
+                    <link linkend='var-BBPATH'><filename>BBPATH</filename></link>
+                    variable to include the path to a
+                    <filename>conf/site.conf</filename>.
+                    Then, when BitBake looks for Metadata using
+                    <filename>BBPATH</filename>, it finds the
+                    <filename>conf/site.conf</filename> file and applies your
+                    common configurations found in the file.
+                    To override configurations in a particular build directory,
+                    alter the similar configurations within that build
+                    directory's <filename>conf/local.conf</filename> file.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>auto.conf</filename>:</emphasis>
+                    This file is not hand-created.
+                    Rather, the file is usually created and written to by
+                    an autobuilder.
+                    The settings put into the file are typically the same as
+                    you would find in the <filename>conf/local.conf</filename>
+                    or the <filename>conf/site.conf</filename> files.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+
+        <para>
+            You can edit all configuration files to further define
+            any particular build environment.
+            This process is represented by the "User Configuration Edits"
+            box in the figure.
+        </para>
+
+        <para>
+            When you launch your build with the
+            <filename>bitbake &lt;target&gt;</filename> command, BitBake
+            sorts out the configurations to ultimately define your build
+            environment.
+        </para>
+    </section>
+
+    <section id="metadata-machine-configuration-and-policy-configuration">
+        <title>Metadata, Machine Configuration, and Policy Configuration</title>
+
+        <para>
+            The previous section described the user configurations that
+            define BitBake's global behavior.
+            This section takes a closer look at the layers the build system
+            uses to further control the build.
+            These layers provide Metadata for the software, machine, and
+            policy.
+        </para>
+
+        <para>
+            In general, three types of layer input exist:
+            <itemizedlist>
+                <listitem><para><emphasis>Policy Configuration:</emphasis>
+                    Distribution Layers provide top-level or general
+                    policies for the image or SDK being built.
+                    For example, this layer would dictate whether BitBake
+                    produces RPM or IPK packages.</para></listitem>
+                <listitem><para><emphasis>Machine Configuration:</emphasis>
+                    Board Support Package (BSP) layers provide machine
+                    configurations.
+                    This type of information is specific to a particular
+                    target architecture.</para></listitem>
+                <listitem><para><emphasis>Metadata:</emphasis>
+                    Software layers contain user-supplied recipe files,
+                    patches, and append files.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+
+        <para>
+            The following figure shows an expanded representation of the
+            Metadata, Machine Configuration, and Policy Configuration input
+            (layers) boxes of the
+            <link linkend='general-yocto-environment-figure'>general Yocto Project Development Environment figure</link>:
+        </para>
+
+        <para>
+            <imagedata fileref="figures/layer-input.png" align="center" width="8in" depth="7.5in" />
+        </para>
+
+        <para>
+            In general, all layers have a similar structure.
+            They all contain a licensing file
+            (e.g. <filename>COPYING</filename>) if the layer is to be
+            distributed, a <filename>README</filename> file as good practice
+            and especially if the layer is to be distributed, a
+            configuration directory, and recipe directories.
+        </para>
+
+        <para>
+            The Yocto Project has many layers that can be used.
+            You can see a web-interface listing of them on the
+            <ulink url="http://git.yoctoproject.org/">Source Repositories</ulink>
+            page.
+            The layers are shown at the bottom categorized under
+            "Yocto Metadata Layers."
+            These layers are fundamentally a subset of the
+            <ulink url="http://layers.openembedded.org/layerindex/layers/">OpenEmbedded Metadata Index</ulink>,
+            which lists all layers provided by the OpenEmbedded community.
+            <note>
+                Layers exist in the Yocto Project Source Repositories that
+                cannot be found in the OpenEmbedded Metadata Index.
+                These layers are either deprecated or experimental in nature.
+            </note>
+        </para>
+
+        <para>
+            BitBake uses the <filename>conf/bblayers.conf</filename> file,
+            which is part of the user configuration, to find what layers it
+            should be using as part of the build.
+        </para>
+
+        <para>
+            For more information on layers, see the
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>"
+            section in the Yocto Project Development Manual.
+        </para>
+
+        <section id="distro-layer">
+            <title>Distro Layer</title>
+
+            <para>
+                The distribution layer provides policy configurations for your
+                distribution.
+                Best practices dictate that you isolate these types of
+                configurations into their own layer.
+                Settings you provide in
+                <filename>conf/&lt;distro&gt;.conf</filename> override similar
+                settings that BitBake finds in your
+                <filename>conf/local.conf</filename> file in the Build
+                Directory.
+            </para>
+
+            <para>
+                The following list provides some explanation and references
+                for what you typically find in the distribution layer:
+                <itemizedlist>
+                    <listitem><para><emphasis>classes:</emphasis>
+                        Class files (<filename>.bbclass</filename>) hold
+                        common functionality that can be shared among
+                        recipes in the distribution.
+                        When your recipes inherit a class, they take on the
+                        settings and functions for that class.
+                        You can read more about class files in the
+                        "<link linkend='ref-classes'>Classes</link>" section.
+                        </para></listitem>
+                    <listitem><para><emphasis>conf:</emphasis>
+                        This area holds configuration files for the
+                        layer (<filename>conf/layer.conf</filename>),
+                        the distribution
+                        (<filename>conf/distro/&lt;distro&gt;.conf</filename>),
+                        and any distribution-wide include files.
+                        </para></listitem>
+                    <listitem><para><emphasis>recipes-*:</emphasis>
+                        Recipes and append files that affect common
+                        functionality across the distribution.
+                        This area could include recipes and append files
+                        to add distribution-specific configuration,
+                        initialization scripts, custom image recipes,
+                        and so forth.</para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id="bsp-layer">
+            <title>BSP Layer</title>
+
+            <para>
+                The BSP Layer provides machine configurations.
+                Everything in this layer is specific to the machine for which
+                you are building the image or the SDK.
+                A common structure or form is defined for BSP layers.
+                You can learn more about this structure in the
+                <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink>.
+                <note>
+                    In order for a BSP layer to be considered compliant with the
+                    Yocto Project, it must meet some structural requirements.
+                </note>
+            </para>
+
+            <para>
+                The BSP Layer's configuration directory contains
+                configuration files for the machine
+                (<filename>conf/machine/&lt;machine&gt;.conf</filename>) and,
+                of course, the layer (<filename>conf/layer.conf</filename>).
+            </para>
+
+            <para>
+                The remainder of the layer is dedicated to specific recipes
+                by function: <filename>recipes-bsp</filename>,
+                <filename>recipes-core</filename>,
+                <filename>recipes-graphics</filename>, and
+                <filename>recipes-kernel</filename>.
+                Metadata can exist for multiple formfactors, graphics
+                support systems, and so forth.
+                <note>
+                    While the figure shows several <filename>recipes-*</filename>
+                    directories, not all these directories appear in all
+                    BSP layers.
+                </note>
+            </para>
+        </section>
+
+        <section id="software-layer">
+            <title>Software Layer</title>
+
+            <para>
+                The software layer provides the Metadata for additional
+                software packages used during the build.
+                This layer does not include Metadata that is specific to the
+                distribution or the machine, which are found in their
+                respective layers.
+            </para>
+
+            <para>
+                This layer contains any new recipes that your project needs
+                in the form of recipe files.
+            </para>
+        </section>
+    </section>
+
+    <section id="sources-dev-environment">
+        <title>Sources</title>
+
+        <para>
+            In order for the OpenEmbedded build system to create an image or
+            any target, it must be able to access source files.
+            The
+            <link linkend='general-yocto-environment-figure'>general Yocto Project Development Environment figure</link>
+            represents source files using the "Upstream Project Releases",
+            "Local Projects", and "SCMs (optional)" boxes.
+            The figure represents mirrors, which also play a role in locating
+            source files, with the "Source Mirror(s)" box.
+        </para>
+
+        <para>
+            The method by which source files are ultimately organized is
+            a function of the project.
+            For example, for released software, projects tend to use tarballs
+            or other archived files that can capture the state of a release
+            guaranteeing that it is statically represented.
+            On the other hand, for a project that is more dynamic or
+            experimental in nature, a project might keep source files in a
+            repository controlled by a Source Control Manager (SCM) such as
+            Git.
+            Pulling source from a repository allows you to control
+            the point in the repository (the revision) from which you want to
+            build software.
+            Finally, a combination of the two might exist, which would give the
+            consumer a choice when deciding where to get source files.
+        </para>
+
+        <para>
+            BitBake uses the
+            <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>
+            variable to point to source files regardless of their location.
+            Each recipe must have a <filename>SRC_URI</filename> variable
+            that points to the source.
+        </para>
+
+        <para>
+            Another area that plays a significant role in where source files
+            come from is pointed to by the
+            <link linkend='var-DL_DIR'><filename>DL_DIR</filename></link>
+            variable.
+            This area is a cache that can hold previously downloaded source.
+            You can also instruct the OpenEmbedded build system to create
+            tarballs from Git repositories, which is not the default behavior,
+            and store them in the <filename>DL_DIR</filename> by using the
+            <link linkend='var-BB_GENERATE_MIRROR_TARBALLS'><filename>BB_GENERATE_MIRROR_TARBALLS</filename></link>
+            variable.
+        </para>
+
+        <para>
+            Judicious use of a <filename>DL_DIR</filename> directory can
+            save the build system a trip across the Internet when looking
+            for files.
+            A good method for using a download directory is to have
+            <filename>DL_DIR</filename> point to an area outside of your
+            Build Directory.
+            Doing so allows you to safely delete the Build Directory
+            if needed without fear of removing any downloaded source file.
+        </para>
+
+        <para>
+            The remainder of this section provides a deeper look into the
+            source files and the mirrors.
+            Here is a more detailed look at the source file area of the
+            base figure:
+            <imagedata fileref="figures/source-input.png" align="center" width="7in" depth="7.5in" />
+        </para>
+
+        <section id='upstream-project-releases'>
+            <title>Upstream Project Releases</title>
+
+            <para>
+                Upstream project releases exist anywhere in the form of an
+                archived file (e.g. tarball or zip file).
+                These files correspond to individual recipes.
+                For example, the figure uses specific releases each for
+                BusyBox, Qt, and Dbus.
+                An archive file can be for any released product that can be
+                built using a recipe.
+            </para>
+        </section>
+
+        <section id='local-projects'>
+            <title>Local Projects</title>
+
+            <para>
+                Local projects are custom bits of software the user provides.
+                These bits reside somewhere local to a project - perhaps
+                a directory into which the user checks in items (e.g.
+                a local directory containing a development source tree
+                used by the group).
+            </para>
+
+            <para>
+                The canonical method through which to include a local project
+                is to use the
+                <link linkend='ref-classes-externalsrc'><filename>externalsrc.bbclass</filename></link>
+                class to include that local project.
+                You use either the <filename>local.conf</filename> or a
+                recipe's append file to override or set the
+                recipe to point to the local directory on your disk to pull
+                in the whole source tree.
+            </para>
+
+            <para>
+                For information on how to use the
+                <filename>externalsrc.bbclass</filename>, see the
+                "<link linkend='ref-classes-externalsrc'><filename>externalsrc.bbclass</filename></link>"
+                section.
+            </para>
+        </section>
+
+        <section id='scms'>
+            <title>Source Control Managers (Optional)</title>
+
+            <para>
+                Another place the build system can get source files from is
+                through an SCM such as Git or Subversion.
+                In this case, a repository is cloned or checked out.
+                The <filename>do_fetch</filename> task inside BitBake uses
+                the <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>
+                variable and the argument's prefix to determine the correct
+                fetcher module.
+            </para>
+
+            <note>
+                For information on how to have the OpenEmbedded build system
+                generate tarballs for Git repositories and place them in the
+                <link linkend='var-DL_DIR'><filename>DL_DIR</filename></link>
+                directory, see the
+                <link linkend='var-BB_GENERATE_MIRROR_TARBALLS'><filename>BB_GENERATE_MIRROR_TARBALLS</filename></link>
+                variable.
+            </note>
+
+            <para>
+                When fetching a repository, BitBake uses the
+                <link linkend='var-SRCREV'><filename>SRCREV</filename></link>
+                variable to determine the specific revision from which to
+                build.
+            </para>
+        </section>
+
+        <section id='source-mirrors'>
+            <title>Source Mirror(s)</title>
+
+            <para>
+                Two kinds of mirrors exist: pre-mirrors and regular mirrors.
+                The <link linkend='var-PREMIRRORS'><filename>PREMIRRORS</filename></link>
+                and
+                <link linkend='var-MIRRORS'><filename>MIRRORS</filename></link>
+                variables point to these, respectively.
+                BitBake checks pre-mirrors before looking upstream for any
+                source files.
+                Pre-mirrors are appropriate when you have a shared directory
+                that is not a directory defined by the
+                <link linkend='var-DL_DIR'><filename>DL_DIR</filename></link>
+                variable.
+                A Pre-mirror typically points to a shared directory that is
+                local to your organization.
+            </para>
+
+            <para>
+                Regular mirrors can be any site across the Internet that is
+                used as an alternative location for source code should the
+                primary site not be functioning for some reason or another.
+            </para>
+        </section>
+    </section>
+
+    <section id="package-feeds-dev-environment">
+        <title>Package Feeds</title>
+
+        <para>
+            When the OpenEmbedded build system generates an image or an SDK,
+            it gets the packages from a package feed area located in the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+            The
+            <link linkend='general-yocto-environment-figure'>general Yocto Project Development Environment figure</link>
+            shows this package feeds area in the upper-right corner.
+        </para>
+
+        <para>
+            This section looks a little closer into the package feeds area used
+            by the build system.
+            Here is a more detailed look at the area:
+            <imagedata fileref="figures/package-feeds.png" align="center" width="7in" depth="6in" />
+        </para>
+
+        <para>
+            Package feeds are an intermediary step in the build process.
+            BitBake generates packages whose type is defined by the
+            <link linkend='var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></link>
+            variable.
+            Before placing the packages into package feeds,
+            the build process validates them with generated output quality
+            assurance checks through the
+            <link linkend='ref-classes-insane'><filename>insane.bbclass</filename></link>
+            class.
+        </para>
+
+        <para>
+            The package feed area resides in
+            <filename>tmp/deploy</filename> of the Build Directory.
+            Folders are created that correspond to the package type
+            (IPK, DEB, or RPM) created.
+            Further organization is derived through the value of the
+            <link linkend='var-PACKAGE_ARCH'><filename>PACKAGE_ARCH</filename></link>
+            variable for each package.
+            For example, packages can exist for the i586 or qemux86
+            architectures.
+            The package files themselves reside within the appropriate
+            architecture folder.
+        </para>
+
+        <para>
+            BitBake uses the <filename>do_package_write_*</filename> task to
+            place generated packages into the package holding area (e.g.
+            <filename>do_package_write_ipk</filename> for IPK packages).
+        </para>
+    </section>
+
+    <section id='bitbake-dev-environment'>
+        <title>BitBake</title>
+
+        <para>
+            The OpenEmbedded build system uses BitBake to produce images.
+            You can see from the
+            <link linkend='general-yocto-environment-figure'>general Yocto Project Development Environment figure</link>,
+            the BitBake area consists of several functional areas.
+            This section takes a closer look at each of those areas.
+        </para>
+
+        <section id='source-fetching-dev-environment'>
+            <title>Source Fetching</title>
+
+            <para>
+                The first stages of building a recipe are to fetch and unpack
+                the source code:
+                <imagedata fileref="figures/source-fetching.png" align="center" width="6.5in" depth="5in" />
+            </para>
+
+            <para>
+                The <filename>do_fetch</filename> and
+                <filename>do_unpack</filename> tasks fetch the source files
+                and unpack them into a working directory.
+                By default, everything is accomplished in the
+                <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>,
+                which has a defined structure.
+                For additional general information on the Build Directory,
+                see the
+                "<link linkend='structure-core-build'><filename>build/</filename></link>"
+                section.
+            </para>
+
+            <para>
+                Unpacked source files are pointed to by the
+                <link linkend='var-S'><filename>S</filename></link> variable.
+                Each recipe has an area in the Build Directory where the
+                unpacked source code resides.
+                The name of that directory for any given recipe is defined from
+                several different variables.
+                You can see the variables that define these directories
+                by looking at the figure:
+                <itemizedlist>
+                    <listitem><para><link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>
+                        </para></listitem>
+                    <listitem><para><link linkend='var-PACKAGE_ARCH'><filename>PACKAGE_ARCH</filename></link>
+                        </para></listitem>
+                    <listitem><para><link linkend='var-TARGET_OS'><filename>TARGET_OS</filename></link>
+                        </para></listitem>
+                    <listitem><para><link linkend='var-PN'><filename>PN</filename></link>
+                        </para></listitem>
+                    <listitem><para><link linkend='var-PV'><filename>PV</filename></link>
+                        </para></listitem>
+                    <listitem><para><link linkend='var-PR'><filename>PR</filename></link>
+                        </para></listitem>
+                    <listitem><para><link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>
+                        </para></listitem>
+                    <listitem><para><link linkend='var-S'><filename>S</filename></link>
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+
+            <para>
+                Briefly, the <filename>S</filename> directory contains the
+                unpacked source files for a recipe.
+                The <filename>WORKDIR</filename> directory is where all the
+                building goes on for a given recipe.
+            </para>
+        </section>
+
+        <section id='patching-dev-environment'>
+            <title>Patching</title>
+
+            <para>
+                Once source code is fetched and unpacked, BitBake locates
+                patch files and applies them to the source files:
+                <imagedata fileref="figures/patching.png" align="center" width="6in" depth="5in" />
+            </para>
+
+            <para>
+                The <filename>do_patch</filename> task processes recipes by
+                using the
+                <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>
+                variable to locate applicable patch files, which by default
+                are <filename>*.patch</filename> or
+                <filename>*.diff</filename> files, or any file if
+                "apply=yes" is specified for the file in
+                <filename>SRC_URI</filename>.
+            </para>
+
+            <para>
+                BitBake finds and applies multiple patches for a single recipe
+                in the order in which it finds the patches.
+                Patches are applied to the recipe's source files located in the
+                <link linkend='var-S'><filename>S</filename></link> directory.
+            </para>
+
+            <para>
+                For more information on how the source directories are
+                created, see the
+                "<link linkend='source-fetching-dev-environment'>Source Fetching</link>"
+                section.
+            </para>
+        </section>
+
+        <section id='configuration-and-compilation-dev-environment'>
+            <title>Configuration and Compilation</title>
+
+            <para>
+                After source code is patched, BitBake executes tasks that
+                configure and compile the source code:
+                <imagedata fileref="figures/configuration-compile-autoreconf.png" align="center" width="7in" depth="5in" />
+            </para>
+
+            <para>
+                This step in the build process consists of three tasks:
+                <itemizedlist>
+                    <listitem><para><emphasis><filename>do_configure</filename>:</emphasis>
+                        This task configures the source by enabling and
+                        disabling any build-time and configuration options for
+                        the software being built.
+                        Configurations can come from the recipe itself as well
+                        as from an inherited class.
+                        Additionally, the software itself might configure itself
+                        depending on the target for which it is being built.
+                        </para>
+
+                        <para>The configurations handled by the
+                        <filename>do_configure</filename> task are specific
+                        to source code configuration for the source code
+                        being built by the recipe.</para>
+
+                        <para>If you are using
+                        <link linkend='ref-classes-autotools'><filename>autotools.bbclass</filename></link>,
+                        you can add additional configuration options by using
+                        the <link linkend='var-EXTRA_OECONF'><filename>EXTRA_OECONF</filename></link>
+                        variable.
+                        For information on how this variable works within
+                        that class, see the
+                        <filename>meta/classes/autotools.bbclass</filename> file.
+                        </para></listitem>
+                    <listitem><para><emphasis><filename>do_compile</filename>:</emphasis>
+                        Once a configuration task has been satisfied, BitBake
+                        compiles the source using the
+                        <filename>do_compile</filename> task.
+                        Compilation occurs in the directory pointed to by the
+                        <link linkend='var-B'><filename>B</filename></link>
+                        variable.
+                        Realize that the <filename>B</filename> directory is, by
+                        default, the same as the
+                        <link linkend='var-S'><filename>S</filename></link>
+                        directory.</para></listitem>
+                    <listitem><para><emphasis><filename>do_install</filename>:</emphasis>
+                        Once compilation is done, BitBake executes the
+                        <filename>do_install</filename> task.
+                        This task copies files from the <filename>B</filename>
+                        directory and places them in a holding area pointed to
+                        by the
+                        <link linkend='var-D'><filename>D</filename></link>
+                        variable.</para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='package-splitting-dev-environment'>
+            <title>Package Splitting</title>
+
+            <para>
+                After source code is configured and compiled, the
+                OpenEmbedded build system analyzes
+                the results and splits the output into packages:
+                <imagedata fileref="figures/analysis-for-package-splitting.png" align="center" width="7in" depth="7in" />
+            </para>
+
+            <para>
+                The <filename>do_package</filename> and
+                <filename>do_packagedata</filename> tasks combine to analyze
+                the files found in the
+                <link linkend='var-D'><filename>D</filename></link> directory
+                and split them into subsets based on available packages and
+                files.
+                The analyzing process involves the following as well as other
+                items: splitting out debugging symbols,
+                looking at shared library dependencies between packages,
+                and looking at package relationships.
+                The <filename>do_packagedata</filename> task creates package
+                metadata based on the analysis such that the
+                OpenEmbedded build system can generate the final packages.
+                Working, staged, and intermediate results of the analysis
+                and package splitting process use these areas:
+                <itemizedlist>
+                    <listitem><para><link linkend='var-PKGD'><filename>PKGD</filename></link>
+                        </para></listitem>
+                    <listitem><para><link linkend='var-PKGDATA_DIR'><filename>PKGDATA_DIR</filename></link>
+                        </para></listitem>
+                    <listitem><para><link linkend='var-PKGDESTWORK'><filename>PKGDESTWORK</filename></link>
+                        </para></listitem>
+                    <listitem><para><link linkend='var-PKGDEST'><filename>PKGDEST</filename></link>
+                        </para></listitem>
+                </itemizedlist>
+                The <link linkend='var-FILES'><filename>FILES</filename></link>
+                variable defines the files that go into each package in
+                <link linkend='var-PACKAGES'><filename>PACKAGES</filename></link>.
+                If you want details on how this is accomplished, you can
+                look at
+                <link linkend='ref-classes-package'><filename>package.bbclass</filename></link>.
+            </para>
+
+            <para>
+                Depending on the type of packages being created (RPM, DEB, or
+                IPK), the <filename>do_package_write_*</filename> task
+                creates the actual packages and places them in the
+                Package Feed area, which is
+                <filename>${TMPDIR}/deploy</filename>.
+                You can see the
+                "<link linkend='package-feeds-dev-environment'>Package Feeds</link>"
+                section for more detail on that part of the build process.
+                <note>
+                    Support for creating feeds directly from the
+                    <filename>deploy/*</filename> directories does not exist.
+                    Creating such feeds usually requires some kind of feed
+                    maintenance mechanism that would upload the new packages
+                    into an official package feed (e.g. the
+                    Ångström distribution).
+                    This functionality is highly distribution-specific
+                    and thus is not provided out of the box.
+                </note>
+            </para>
+        </section>
+
+        <section id='image-generation-dev-environment'>
+            <title>Image Generation</title>
+
+            <para>
+                Once packages are split and stored in the Package Feeds area,
+                the OpenEmbedded build system uses BitBake to generate the
+                root filesystem image:
+                <imagedata fileref="figures/image-generation.png" align="center" width="6in" depth="7in" />
+            </para>
+
+            <para>
+                The image generation process consists of several stages and
+                depends on many variables.
+                The <filename>do_rootfs</filename> task uses these key variables
+                to help create the list of packages to actually install:
+                <itemizedlist>
+                    <listitem><para><link linkend='var-IMAGE_INSTALL'><filename>IMAGE_INSTALL</filename></link>:
+                        Lists out the base set of packages to install from
+                        the Package Feeds area.</para></listitem>
+                    <listitem><para><link linkend='var-PACKAGE_EXCLUDE'><filename>PACKAGE_EXCLUDE</filename></link>:
+                        Specifies packages that should not be installed.
+                        </para></listitem>
+                    <listitem><para><link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>:
+                        Specifies features to include in the image.
+                        Most of these features map to additional packages for
+                        installation.</para></listitem>
+                    <listitem><para><link linkend='var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></link>:
+                        Specifies the package backend to use and consequently
+                        helps determine where to locate packages within the
+                        Package Feeds area.</para></listitem>
+                    <listitem><para><link linkend='var-IMAGE_LINGUAS'><filename>IMAGE_LINGUAS</filename></link>:
+                        Determines the language(s) for which additional
+                        language support packages are installed.
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+
+            <para>
+                Package installation is under control of the package manager
+                (e.g. smart/rpm, opkg, or apt/dpkg) regardless of whether or
+                not package management is enabled for the target.
+                At the end of the process, if package management is not
+                enabled for the target, the package manager's data files
+                are deleted from the root filesystem.
+            </para>
+
+            <para>
+                During image generation, the build system attempts to run
+                all post-installation scripts.
+                Any that fail to run on the build host are run on the
+                target when the target system is first booted.
+                If you are using a
+                <ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-read-only-root-filesystem'>read-only root filesystem</ulink>,
+                all the post installation scripts must succeed during the
+                package installation phase since the root filesystem cannot be
+                written into.
+            </para>
+
+            <para>
+                During Optimization, optimizing processes are run across
+                the image.
+                These processes include <filename>mklibs</filename> and
+                <filename>prelink</filename>.
+                The <filename>mklibs</filename> process optimizes the size
+                of the libraries.
+                A <filename>prelink</filename> process optimizes the dynamic
+                linking of shared libraries to reduce start up time of
+                executables.
+            </para>
+
+            <para>
+                Part of the image generation process includes compressing the
+                root filesystem image.
+                Compression is accomplished through several optimization
+                routines designed to reduce the overall size of the image.
+            </para>
+
+            <para>
+                After the root filesystem has been constructed, the image
+                generation process turns everything into an image file or
+                a set of image files.
+                The formats used for the root filesystem depend on the
+                <link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>
+                variable.
+            </para>
+
+            <note>
+                The entire image generation process is run under Pseudo.
+                Running under Pseudo ensures that the files in the root
+                filesystem have correct ownership.
+            </note>
+        </section>
+
+        <section id='sdk-generation-dev-environment'>
+            <title>SDK Generation</title>
+
+            <para>
+                The OpenEmbedded build system uses BitBake to generate the
+                Software Development Kit (SDK) installer script:
+                <imagedata fileref="figures/sdk-generation.png" align="center" width="6in" depth="7in" />
+            </para>
+
+            <note>
+                For more information on the cross-development toolchain
+                generation, see the
+                "<link linkend='cross-development-toolchain-generation'>Cross-Development Toolchain Generation</link>"
+                section.
+            </note>
+
+            <para>
+                Like image generation, the SDK script process consists of
+                several stages and depends on many variables.
+                The <filename>do_populate_sdk</filename> task uses these
+                key variables to help create the list of packages to actually
+                install.
+                For information on the variables listed in the figure, see the
+                "<link linkend='sdk-dev-environment'>Application Development SDK</link>"
+                section.
+            </para>
+
+            <para>
+                The <filename>do_populate_sdk</filename> task handles two
+                parts: a target part and a host part.
+                The target part is the part built for the target hardware and
+                includes libraries and headers.
+                The host part is the part of the SDK that runs on the
+                <link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>.
+            </para>
+
+            <para>
+                Once both parts are constructed, the
+                <filename>do_populate_sdk</filename> task performs some cleanup
+                on both parts.
+                After the cleanup, the task creates a cross-development
+                environment setup script and any configuration files that
+                might be needed.
+            </para>
+
+            <para>
+                The final output of the task is the Cross-development
+                toolchain installation script (<filename>.sh</filename> file),
+                which includes the environment setup script.
+            </para>
+        </section>
+    </section>
+
+    <section id='images-dev-environment'>
+        <title>Images</title>
+
+        <para>
+            The images produced by the OpenEmbedded build system
+            are compressed forms of the
+            root filesystem that are ready to boot on a target device.
+            You can see from the
+            <link linkend='general-yocto-environment-figure'>general Yocto Project Development Environment figure</link>
+            that BitBake output in part consists of images.
+            This section is going to look more closely at this output:
+            <imagedata fileref="figures/images.png" align="center" width="5.5in" depth="5.5in" />
+        </para>
+
+        <para>
+            For a list of example images that the Yocto Project provides,
+            see the
+            "<link linkend='ref-images'>Images</link>" chapter.
+        </para>
+
+        <para>
+            Images are written out to the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+            inside the <filename>tmp/deploy/images/&lt;machine&gt;/</filename>
+            folder as shown in the figure.
+            This folder contains any files expected to be loaded on the
+            target device.
+            The
+            <link linkend='var-DEPLOY_DIR'><filename>DEPLOY_DIR</filename></link>
+            variable points to the <filename>deploy</filename> directory,
+            while the
+            <link linkend='var-DEPLOY_DIR_IMAGE'><filename>DEPLOY_DIR_IMAGE</filename></link>
+            variable points to the appropriate directory containing images for
+            the current configuration.
+            <itemizedlist>
+                <listitem><para><filename>&lt;kernel-image&gt;</filename>:
+                    A kernel binary file.
+                    The <link linkend='var-KERNEL_IMAGETYPE'><filename>KERNEL_IMAGETYPE</filename></link>
+                    variable setting determines the naming scheme for the
+                    kernel image file.
+                    Depending on that variable, the file could begin with
+                    a variety of naming strings.
+                    The <filename>deploy/images/&lt;machine&gt;</filename>
+                    directory can contain multiple image files for the
+                    machine.</para></listitem>
+                <listitem><para><filename>&lt;root-filesystem-image&gt;</filename>:
+                    Root filesystems for the target device (e.g.
+                    <filename>*.ext3</filename> or <filename>*.bz2</filename>
+                    files).
+                    The <link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>
+                    variable setting determines the root filesystem image
+                    type.
+                    The <filename>deploy/images/&lt;machine&gt;</filename>
+                    directory can contain multiple root filesystems for the
+                    machine.</para></listitem>
+                <listitem><para><filename>&lt;kernel-modules&gt;</filename>:
+                    Tarballs that contain all the modules built for the kernel.
+                    Kernel module tarballs exist for legacy purposes and
+                    can be suppressed by setting the
+                    <link linkend='var-MODULE_TARBALL_DEPLOY'><filename>MODULE_TARBALL_DEPLOY</filename></link>
+                    variable to "0".
+                    The <filename>deploy/images/&lt;machine&gt;</filename>
+                    directory can contain multiple kernel module tarballs
+                    for the machine.</para></listitem>
+                <listitem><para><filename>&lt;bootloaders&gt;</filename>:
+                    Bootloaders supporting the image, if applicable to the
+                    target machine.
+                    The <filename>deploy/images/&lt;machine&gt;</filename>
+                    directory can contain multiple bootloaders for the
+                    machine.</para></listitem>
+                <listitem><para><filename>&lt;symlinks&gt;</filename>:
+                    The <filename>deploy/images/&lt;machine&gt;</filename>
+                    folder contains
+                    a symbolic link that points to the most recently built file
+                    for each machine.
+                    These links might be useful for external scripts that
+                    need to obtain the latest version of each file.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='sdk-dev-environment'>
+        <title>Application Development SDK</title>
+
+        <para>
+            In the
+            <link linkend='general-yocto-environment-figure'>general Yocto Project Development Environment figure</link>,
+            the output labeled "Application Development SDK" represents an
+            SDK.
+            This section is going to take a closer look at this output:
+            <imagedata fileref="figures/sdk.png" align="center" width="5in" depth="4in" />
+        </para>
+
+        <para>
+            The specific form of this output is a self-extracting
+            SDK installer (<filename>*.sh</filename>) that, when run,
+            installs the SDK, which consists of a cross-development
+            toolchain, a set of libraries and headers, and an SDK
+            environment setup script.
+            Running this installer essentially sets up your
+            cross-development environment.
+            You can think of the cross-toolchain as the "host"
+            part because it runs on the SDK machine.
+            You can think of the libraries and headers as the "target"
+            part because they are built for the target hardware.
+            The setup script is added so that you can initialize the
+            environment before using the tools.
+        </para>
+
+        <note>
+            <para>
+                The Yocto Project supports several methods by which you can
+                set up this cross-development environment.
+                These methods include downloading pre-built SDK installers,
+                building and installing your own SDK installer, or running
+                an Application Development Toolkit (ADT) installer to
+                install not just cross-development toolchains
+                but also additional tools to help in this type of
+                development.
+            </para>
+
+            <para>
+                For background information on cross-development toolchains
+                in the Yocto Project development environment, see the
+                "<link linkend='cross-development-toolchain-generation'>Cross-Development Toolchain Generation</link>"
+                section.
+                For information on setting up a cross-development
+                environment, see the
+                "<ulink url='&YOCTO_DOCS_ADT_URL;#installing-the-adt'>Installing the ADT and Toolchains</ulink>"
+                section in the Yocto Project Application Developer's Guide.
+            </para>
+        </note>
+
+        <para>
+            Once built, the SDK installers are written out to the
+            <filename>deploy/sdk</filename> folder inside the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+            as shown in the figure at the beginning of this section.
+            Several variables exist that help configure these files:
+            <itemizedlist>
+                <listitem><para><link linkend='var-DEPLOY_DIR'><filename>DEPLOY_DIR</filename></link>:
+                    Points to the <filename>deploy</filename>
+                    directory.</para></listitem>
+                <listitem><para><link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>:
+                    Specifies the architecture of the machine
+                    on which the cross-development tools are run to
+                    create packages for the target hardware.
+                    </para></listitem>
+                <listitem><para><link linkend='var-SDKIMAGE_FEATURES'><filename>SDKIMAGE_FEATURES</filename></link>:
+                    Lists the features to include in the "target" part
+                    of the SDK.
+                    </para></listitem>
+                <listitem><para><link linkend='var-TOOLCHAIN_HOST_TASK'><filename>TOOLCHAIN_HOST_TASK</filename></link>:
+                    Lists packages that make up the host
+                    part of the SDK (i.e. the part that runs on
+                    the <filename>SDKMACHINE</filename>).
+                    When you use
+                    <filename>bitbake -c populate_sdk &lt;imagename&gt;</filename>
+                    to create the SDK, a set of default packages
+                    apply.
+                    This variable allows you to add more packages.
+                    </para></listitem>
+                <listitem><para><link linkend='var-TOOLCHAIN_TARGET_TASK'><filename>TOOLCHAIN_TARGET_TASK</filename></link>:
+                    Lists packages that make up the target part
+                    of the SDK (i.e. the part built for the
+                    target hardware).
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/ref-manual/examples/hello-autotools/hello_2.3.bb b/documentation/ref-manual/examples/hello-autotools/hello_2.3.bb
new file mode 100644
index 0000000..5dfb0b3
--- /dev/null
+++ b/documentation/ref-manual/examples/hello-autotools/hello_2.3.bb
@@ -0,0 +1,8 @@
+DESCRIPTION = "GNU Helloworld application"
+SECTION = "examples"
+LICENSE = "GPLv3"
+LIC_FILES_CHKSUM = "file://COPYING;md5=adefda309052235aa5d1e99ce7557010"
+
+SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.bz2"
+
+inherit autotools
diff --git a/documentation/ref-manual/examples/hello-single/files/helloworld.c b/documentation/ref-manual/examples/hello-single/files/helloworld.c
new file mode 100644
index 0000000..fc7169b
--- /dev/null
+++ b/documentation/ref-manual/examples/hello-single/files/helloworld.c
@@ -0,0 +1,8 @@
+#include <stdio.h>
+
+int main(void)
+{
+        printf("Hello world!\n");
+
+        return 0;
+}
diff --git a/documentation/ref-manual/examples/hello-single/hello.bb b/documentation/ref-manual/examples/hello-single/hello.bb
new file mode 100644
index 0000000..0812743
--- /dev/null
+++ b/documentation/ref-manual/examples/hello-single/hello.bb
@@ -0,0 +1,17 @@
+DESCRIPTION = "Simple helloworld application"
+SECTION = "examples"
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
+
+SRC_URI = "file://helloworld.c"
+
+S = "${WORKDIR}"
+
+do_compile() {
+        ${CC} helloworld.c -o helloworld
+}
+
+do_install() {
+        install -d ${D}${bindir}
+        install -m 0755 helloworld ${D}${bindir}
+}
diff --git a/documentation/ref-manual/examples/libxpm/libxpm_3.5.6.bb b/documentation/ref-manual/examples/libxpm/libxpm_3.5.6.bb
new file mode 100644
index 0000000..b58d4d7
--- /dev/null
+++ b/documentation/ref-manual/examples/libxpm/libxpm_3.5.6.bb
@@ -0,0 +1,14 @@
+require xorg-lib-common.inc
+
+DESCRIPTION = "X11 Pixmap library"
+LICENSE = "X-BSD"
+LIC_FILES_CHKSUM = "file://COPYING;md5=3e07763d16963c3af12db271a31abaa5"
+DEPENDS += "libxext"
+PR = "r2"
+PE = "1"
+
+XORG_PN = "libXpm"
+
+PACKAGES =+ "sxpm cxpm"
+FILES_cxpm = "${bindir}/cxpm"
+FILES_sxpm = "${bindir}/sxpm"
diff --git a/documentation/ref-manual/examples/mtd-makefile/mtd-utils_1.0.0.bb b/documentation/ref-manual/examples/mtd-makefile/mtd-utils_1.0.0.bb
new file mode 100644
index 0000000..5d05a43
--- /dev/null
+++ b/documentation/ref-manual/examples/mtd-makefile/mtd-utils_1.0.0.bb
@@ -0,0 +1,15 @@
+DESCRIPTION = "Tools for managing memory technology devices."
+SECTION = "base"
+DEPENDS = "zlib"
+HOMEPAGE = "http://www.linux-mtd.infradead.org/"
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM = "file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \
+                    file://include/common.h;beginline=1;endline=17;md5=ba05b07912a44ea2bf81ce409380049c"
+
+SRC_URI = "ftp://ftp.infradead.org/pub/mtd-utils/mtd-utils-${PV}.tar.gz"
+
+CFLAGS_prepend = "-I ${S}/include "
+
+do_install() {
+        oe_runmake install DESTDIR=${D}
+}
diff --git a/documentation/ref-manual/faq.xml b/documentation/ref-manual/faq.xml
new file mode 100644
index 0000000..c7ccaaf
--- /dev/null
+++ b/documentation/ref-manual/faq.xml
@@ -0,0 +1,698 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='faq'>
+<title>FAQ</title>
+<qandaset>
+    <qandaentry>
+        <question>
+            <para>
+                How does Poky differ from <ulink url='&OE_HOME_URL;'>OpenEmbedded</ulink>?
+            </para>
+        </question>
+        <answer>
+            <para>
+                The term "<ulink url='&YOCTO_DOCS_DEV_URL;#poky'>Poky</ulink>"
+                refers to the specific reference build system that
+                the Yocto Project provides.
+                Poky is based on <ulink url='&YOCTO_DOCS_DEV_URL;#oe-core'>OE-Core</ulink>
+                and <ulink url='&YOCTO_DOCS_DEV_URL;#bitbake-term'>BitBake</ulink>.
+                Thus, the generic term used here for the build system is
+                the "OpenEmbedded build system."
+                Development in the Yocto Project using Poky is closely tied to OpenEmbedded, with
+                changes always being merged to OE-Core or BitBake first before being pulled back
+                into Poky.
+                This practice benefits both projects immediately.
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                My development system does not have Python 2.7.3 or greater,
+                which the Yocto Project requires.
+                Can I still use the Yocto Project?
+            </para>
+        </question>
+        <answer>
+            <para>
+                You can get the required tools on your host development
+                system a couple different ways (i.e. building a tarball or
+                downloading a tarball).
+                See the
+                "<link linkend='required-git-tar-and-python-versions'>Required Git, tar, and Python Versions</link>"
+                section for steps on how to update your build tools.
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                How can you claim Poky / OpenEmbedded-Core is stable?
+            </para>
+        </question>
+        <answer>
+            <para>
+                There are three areas that help with stability;
+                <itemizedlist>
+                    <listitem><para>The Yocto Project team keeps
+                        <ulink url='&YOCTO_DOCS_DEV_URL;#oe-core'>OE-Core</ulink> small
+                        and focused, containing around 830 recipes as opposed to the thousands
+                        available in other OpenEmbedded community layers.
+                        Keeping it small makes it easy to test and maintain.</para></listitem>
+                    <listitem><para>The Yocto Project team runs manual and automated tests
+                        using a small, fixed set of reference hardware as well as emulated
+                        targets.</para></listitem>
+                    <listitem><para>The Yocto Project uses an autobuilder,
+                        which provides continuous build and integration tests.</para></listitem>
+                </itemizedlist>
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                How do I get support for my board added to the Yocto Project?
+            </para>
+        </question>
+        <answer>
+            <para>
+                Support for an additional board is added by creating a
+                Board Support Package (BSP) layer for it.
+                For more information on how to create a BSP layer, see the
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>"
+                section in the Yocto Project Development Manual and the
+                <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink>.
+            </para>
+            <para>
+                Usually, if the board is not completely exotic, adding support in
+                the Yocto Project is fairly straightforward.
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                Are there any products built using the OpenEmbedded build system?
+            </para>
+        </question>
+        <answer>
+            <para>
+                The software running on the <ulink url='http://vernier.com/labquest/'>Vernier LabQuest</ulink>
+                is built using the OpenEmbedded build system.
+                See the <ulink url='http://www.vernier.com/products/interfaces/labq/'>Vernier LabQuest</ulink>
+                website for more information.
+                There are a number of pre-production devices using the OpenEmbedded build system
+                and the Yocto Project team
+                announces them as soon as they are released.
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                What does the OpenEmbedded build system produce as output?
+            </para>
+        </question>
+        <answer>
+            <para>
+                Because you can use the same set of recipes to create output of
+                various formats, the output of an OpenEmbedded build depends on
+                how you start it.
+                Usually, the output is a flashable image ready for the target
+                device.
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                How do I add my package to the Yocto Project?
+            </para>
+        </question>
+        <answer>
+            <para>
+                To add a package, you need to create a BitBake recipe.
+                For information on how to add a package, see the section
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#usingpoky-extend-addpkg'>Writing a Recipe to Add a Package to Your Image</ulink>"
+                in the Yocto Project Development Manual.
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                Do I have to reflash my entire board with a new Yocto Project image when recompiling
+                a package?
+            </para>
+        </question>
+        <answer>
+            <para>
+                The OpenEmbedded build system can build packages in various
+                formats such as IPK for OPKG, Debian package
+                (<filename>.deb</filename>), or RPM.
+                You can then upgrade the packages using the package tools on
+                the device, much like on a desktop distribution such as
+                Ubuntu or Fedora.
+                However, package management on the target is entirely optional.
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                What is GNOME Mobile and what is the difference between GNOME Mobile and GNOME?
+            </para>
+        </question>
+        <answer>
+            <para>
+                GNOME Mobile is a subset of the <ulink url='http://www.gnome.org'>GNOME</ulink>
+                platform targeted at mobile and embedded devices.
+                The main difference between GNOME Mobile and standard GNOME is that
+                desktop-orientated libraries have been removed, along with deprecated libraries,
+                creating a much smaller footprint.
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                I see the error '<filename>chmod: XXXXX new permissions are r-xrwxrwx, not r-xr-xr-x</filename>'.
+                What is wrong?
+            </para>
+        </question>
+        <answer>
+            <para>
+                You are probably running the build on an NTFS filesystem.
+                Use <filename>ext2</filename>, <filename>ext3</filename>, or <filename>ext4</filename> instead.
+            </para>
+        </answer>
+    </qandaentry>
+
+<!--    <qandaentry>
+        <question>
+            <para>
+                How do I make the Yocto Project work in RHEL/CentOS?
+            </para>
+        </question>
+        <answer>
+            <para>
+                To get the Yocto Project working under RHEL/CentOS 5.1 you need to first
+                install some required packages.
+                The standard CentOS packages needed are:
+                <itemizedlist>
+                    <listitem><para>"Development tools" (selected during installation)</para></listitem>
+                    <listitem><para><filename>texi2html</filename></para></listitem>
+                    <listitem><para><filename>compat-gcc-34</filename></para></listitem>
+                </itemizedlist>
+                On top of these, you need the following external packages:
+                <itemizedlist>
+                    <listitem><para><filename>python-sqlite2</filename> from
+                        <ulink url='http://dag.wieers.com/rpm/packages/python-sqlite2/'>DAG repository</ulink>
+                        </para></listitem>
+                    <listitem><para><filename>help2man</filename> from
+                        <ulink url='http://centos.karan.org/el4/extras/stable/x86_64/RPMS/repodata/repoview/help2man-0-1.33.1-2.html'>Karan repository</ulink></para></listitem>
+                </itemizedlist>
+            </para>
+
+            <para>
+                Once these packages are installed, the OpenEmbedded build system will be able
+                to build standard images.
+                However, there might be a problem with the QEMU emulator segfaulting.
+                You can either disable the generation of binary locales by setting
+                <filename><link linkend='var-ENABLE_BINARY_LOCALE_GENERATION'>ENABLE_BINARY_LOCALE_GENERATION</link>
+                </filename> to "0" or by removing the <filename>linux-2.6-execshield.patch</filename>
+                from the kernel and rebuilding it since that is the patch that causes the problems with QEMU.
+            </para>
+
+            <note>
+                <para>For information on distributions that the Yocto Project
+                uses during validation, see the
+                <ulink url='&YOCTO_WIKI_URL;/wiki/Distribution_Support'>Distribution Support</ulink>
+                Wiki page.</para>
+                <para>For notes about using the Yocto Project on a RHEL 4-based
+                host, see the
+                <ulink url='&YOCTO_WIKI_URL;/wiki/BuildingOnRHEL4'>Building on RHEL4</ulink>
+                Wiki page.</para>
+            </note>
+        </answer>
+    </qandaentry> -->
+
+    <qandaentry>
+        <question>
+            <para>
+                I see lots of 404 responses for files on
+                <filename>&YOCTO_HOME_URL;/sources/*</filename>. Is something wrong?
+            </para>
+        </question>
+        <answer>
+            <para>
+                Nothing is wrong.
+                The OpenEmbedded build system checks any configured source mirrors before downloading
+                from the upstream sources.
+                The build system does this searching for both source archives and
+                pre-checked out versions of SCM-managed software.
+                These checks help in large installations because it can reduce load on the SCM servers
+                themselves.
+                The address above is one of the default mirrors configured into the
+                build system.
+                Consequently, if an upstream source disappears, the team
+                can place sources there so builds continue to work.
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                I have machine-specific data in a package for one machine only but the package is
+                being marked as machine-specific in all cases, how do I prevent this?
+            </para>
+        </question>
+        <answer>
+            <para>
+                Set <filename><link linkend='var-SRC_URI_OVERRIDES_PACKAGE_ARCH'>SRC_URI_OVERRIDES_PACKAGE_ARCH</link>
+                </filename> = "0" in the <filename>.bb</filename> file but make sure the package is
+                manually marked as
+                machine-specific for the case that needs it.
+                The code that handles
+                <filename>SRC_URI_OVERRIDES_PACKAGE_ARCH</filename> is in
+                the <filename>meta/classes/base.bbclass</filename> file.
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                I'm behind a firewall and need to use a proxy server. How do I do that?
+            </para>
+        </question>
+        <answer>
+            <para>
+                Most source fetching by the OpenEmbedded build system is done by <filename>wget</filename>
+                and you therefore need to specify the proxy settings in a
+                <filename>.wgetrc</filename> file in your home directory.
+                Here are some example settings:
+                <literallayout class='monospaced'>
+     http_proxy = http://proxy.yoyodyne.com:18023/
+     ftp_proxy = http://proxy.yoyodyne.com:18023/
+                </literallayout>
+                The Yocto Project also includes a
+                <filename>site.conf.sample</filename> file that shows how to
+                configure CVS and Git proxy servers if needed.
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                What’s the difference between <filename>foo</filename> and <filename>foo-native</filename>?
+            </para>
+        </question>
+        <answer>
+            <para>
+                The <filename>*-native</filename> targets are designed to run on the system
+                being used for the build.
+                These are usually tools that are needed to assist the build in some way such as
+                <filename>quilt-native</filename>, which is used to apply patches.
+                The non-native version is the one that runs on the target device.
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                I'm seeing random build failures. Help?!
+            </para>
+        </question>
+        <answer>
+            <para>
+                If the same build is failing in totally different and random
+                ways, the most likely explanation is:
+                <itemizedlist>
+                    <listitem><para>The hardware you are running the build on
+                        has some problem.</para></listitem>
+                    <listitem><para>You are running the build under
+                        virtualization, in which case the virtualization
+                        probably has bugs.</para></listitem>
+                </itemizedlist>
+                The OpenEmbedded build system processes a massive amount of
+                data that causes lots of network, disk and CPU activity and
+                is sensitive to even single-bit failures in any of these areas.
+                True random failures have always been traced back to hardware
+                or virtualization issues.
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                What do we need to ship for license compliance?
+            </para>
+        </question>
+        <answer>
+            <para>
+                This is a difficult question and you need to consult your lawyer
+                for the answer for your specific case.
+                It is worth bearing in mind that for GPL compliance, there needs
+                to be enough information shipped to allow someone else to
+                rebuild and produce the same end result you are shipping.
+                This means sharing the source code, any patches applied to it,
+                and also any configuration information about how that package
+                was configured and built.
+            </para>
+
+            <para>
+                You can find more information on licensing in the
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#licensing'>Licensing</ulink>"
+                and "<ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle'>Maintaining Open Source License Compliance During Your Product's Lifecycle</ulink>"
+                sections, both of which are in the Yocto Project Development
+                Manual.
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                How do I disable the cursor on my touchscreen device?
+            </para>
+        </question>
+        <answer>
+            <para>
+                You need to create a form factor file as described in the
+                "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout-misc-recipes'>Miscellaneous BSP-Specific Recipe Files</ulink>"
+                section in the Yocto Project Board Support Packages (BSP)
+                Developer's Guide.
+                Set the <filename>HAVE_TOUCHSCREEN</filename> variable equal to
+                one as follows:
+                <literallayout class='monospaced'>
+     HAVE_TOUCHSCREEN=1
+                </literallayout>
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                How do I make sure connected network interfaces are brought up by default?
+            </para>
+        </question>
+        <answer>
+            <para>
+                The default interfaces file provided by the netbase recipe does not
+                automatically bring up network interfaces.
+                Therefore, you will need to add a BSP-specific netbase that includes an interfaces
+                file.
+                See the "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout-misc-recipes'>Miscellaneous BSP-Specific Recipe Files</ulink>"
+                section in the Yocto Project Board Support Packages (BSP)
+                Developer's Guide for information on creating these types of
+                miscellaneous recipe files.
+            </para>
+            <para>
+                For example, add the following files to your layer:
+                <literallayout class='monospaced'>
+     meta-MACHINE/recipes-bsp/netbase/netbase/MACHINE/interfaces
+     meta-MACHINE/recipes-bsp/netbase/netbase_5.0.bbappend
+                </literallayout>
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                How do I create images with more free space?
+            </para>
+        </question>
+        <answer>
+            <para>
+                By default, the OpenEmbedded build system creates images
+                that are 1.3 times the size of the populated root filesystem.
+                To affect the image size, you need to set various
+                configurations:
+                <itemizedlist>
+                    <listitem><para><emphasis>Image Size:</emphasis>
+                        The OpenEmbedded build system uses the
+                        <link linkend='var-IMAGE_ROOTFS_SIZE'><filename>IMAGE_ROOTFS_SIZE</filename></link>
+                        variable to define the size of the image in Kbytes.
+                        The build system determines the size by taking into
+                        account the initial root filesystem size before any
+                        modifications such as requested size for the image and
+                        any requested additional free disk space to be
+                        added to the image.</para></listitem>
+                    <listitem><para><emphasis>Overhead:</emphasis>
+                        Use the
+                        <link linkend='var-IMAGE_OVERHEAD_FACTOR'><filename>IMAGE_OVERHEAD_FACTOR</filename></link>
+                        variable to define the multiplier that the build system
+                        applies to the initial image size, which is 1.3 by
+                        default.</para></listitem>
+                    <listitem><para><emphasis>Additional Free Space:</emphasis>
+                        Use the
+                        <link linkend='var-IMAGE_ROOTFS_EXTRA_SPACE'><filename>IMAGE_ROOTFS_EXTRA_SPACE</filename></link>
+                        variable to add additional free space to the image.
+                        The build system adds this space to the image after
+                        it determines its
+                        <filename>IMAGE_ROOTFS_SIZE</filename>.
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                Why don't you support directories with spaces in the pathnames?
+            </para>
+        </question>
+        <answer>
+            <para>
+                The Yocto Project team has tried to do this before but too
+                many of the tools the OpenEmbedded build system depends on,
+                such as <filename>autoconf</filename>, break when they find
+                spaces in pathnames.
+                Until that situation changes, the team will not support spaces
+                in pathnames.
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                How do I use an external toolchain?
+            </para>
+        </question>
+        <answer>
+            <para>
+                The toolchain configuration is very flexible and customizable.
+                It is primarily controlled with the
+                <filename><link linkend='var-TCMODE'>TCMODE</link></filename>
+                variable.
+                This variable controls which <filename>tcmode-*.inc</filename>
+                file to include from the
+                <filename>meta/conf/distro/include</filename> directory within
+                the
+                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+            </para>
+
+            <para>
+                The default value of <filename>TCMODE</filename> is "default"
+                (i.e. <filename>tcmode-default.inc</filename>).
+                However, other patterns are accepted.
+                In particular, "external-*" refers to external toolchains of
+                which there are some basic examples included in the
+                OpenEmbedded Core (<filename>meta</filename>).
+                You can use your own custom toolchain definition in your own
+                layer (or as defined in the <filename>local.conf</filename>
+                file) at the location
+                <filename>conf/distro/include/tcmode-*.inc</filename>.
+            </para>
+
+            <para>
+                In addition to the toolchain configuration, you also need a
+                corresponding toolchain recipe file.
+                This recipe file needs to package up any pre-built objects in
+                the toolchain such as <filename>libgcc</filename>,
+                <filename>libstdcc++</filename>, any locales, and
+                <filename>libc</filename>.
+                An example is the
+                <filename>external-sourcery-toolchain.bb</filename>, which is
+                located in <filename>meta/recipes-core/meta/</filename> within
+                the Source Directory.
+            </para>
+
+            <para>
+                For information on installing and using cross-development
+                toolchains, see the
+                "<ulink url='&YOCTO_DOCS_ADT_URL;#installing-the-adt'>Installing the ADT and Toolchains</ulink>"
+                section in the Yocto Project Application Developer's Guide.
+                For general information on cross-development toolchains, see
+                the
+                "<link linkend='cross-development-toolchain-generation'>Cross-Development Toolchain Generation</link>"
+                section.
+            </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para id='how-does-the-yocto-project-obtain-source-code-and-will-it-work-behind-my-firewall-or-proxy-server'>
+                How does the OpenEmbedded build system obtain source code and
+                will it work behind my firewall or proxy server?
+            </para>
+        </question>
+        <answer>
+            <para>
+                The way the build system obtains source code is highly
+                configurable.
+                You can setup the build system to get source code in most
+                environments if HTTP transport is available.
+            </para>
+            <para>
+                When the build system searches for source code, it first
+                tries the local download directory.
+                If that location fails, Poky tries
+                <link linkend='var-PREMIRRORS'><filename>PREMIRRORS</filename></link>,
+                the upstream source, and then
+                <link linkend='var-MIRRORS'><filename>MIRRORS</filename></link>
+                in that order.
+            </para>
+            <para>
+                Assuming your distribution is "poky", the OpenEmbedded build
+                system uses the Yocto Project source
+                <filename>PREMIRRORS</filename> by default for SCM-based
+                sources, upstreams for normal tarballs, and then falls back
+                to a number of other mirrors including the Yocto Project
+                source mirror if those fail.
+            </para>
+            <para>
+                As an example, you could add a specific server for the
+                build system to attempt before any others by adding something
+                like the following to the <filename>local.conf</filename>
+                configuration file:
+                <literallayout class='monospaced'>
+     PREMIRRORS_prepend = "\
+     git://.*/.* http://www.yoctoproject.org/sources/ \n \
+     ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
+     http://.*/.* http://www.yoctoproject.org/sources/ \n \
+     https://.*/.* http://www.yoctoproject.org/sources/ \n"
+                </literallayout>
+            </para>
+            <para>
+                These changes cause the build system to intercept Git, FTP,
+                HTTP, and HTTPS requests and direct them to the
+                <filename>http://</filename> sources mirror.
+                You can use <filename>file://</filename> URLs to point to
+                local directories or network shares as well.
+            </para>
+            <para>
+                Aside from the previous technique, these options also exist:
+                <literallayout class='monospaced'>
+     BB_NO_NETWORK = "1"
+                </literallayout>
+                 This statement tells BitBake to issue an error instead of
+                 trying to access the Internet.
+                 This technique is useful if you want to ensure code builds
+                 only from local sources.
+             </para>
+             <para>
+                 Here is another technique:
+                 <literallayout class='monospaced'>
+     BB_FETCH_PREMIRRORONLY = "1"
+                 </literallayout>
+                 This statement limits the build system to pulling source
+                 from the <filename>PREMIRRORS</filename> only.
+                 Again, this technique is useful for reproducing builds.
+             </para>
+             <para>
+                 Here is another technique:
+                 <literallayout class='monospaced'>
+     BB_GENERATE_MIRROR_TARBALLS = "1"
+                 </literallayout>
+                 This statement tells the build system to generate mirror
+                 tarballs.
+                 This technique is useful if you want to create a mirror server.
+                 If not, however, the technique can simply waste time during
+                 the build.
+             </para>
+             <para>
+                 Finally, consider an example where you are behind an
+                 HTTP-only firewall.
+                 You could make the following changes to the
+                 <filename>local.conf</filename> configuration file as long as
+                 the <filename>PREMIRRORS</filename> server is current:
+                 <literallayout class='monospaced'>
+     PREMIRRORS_prepend = "\
+     ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
+     http://.*/.* http://www.yoctoproject.org/sources/ \n \
+     https://.*/.* http://www.yoctoproject.org/sources/ \n"
+     BB_FETCH_PREMIRRORONLY = "1"
+                 </literallayout>
+                 These changes would cause the build system to successfully
+                 fetch source over HTTP and any network accesses to anything
+                 other than the <filename>PREMIRRORS</filename> would fail.
+             </para>
+             <para>
+                 The build system also honors the standard shell environment
+                 variables <filename>http_proxy</filename>,
+                 <filename>ftp_proxy</filename>,
+                 <filename>https_proxy</filename>, and
+                 <filename>all_proxy</filename> to redirect requests through
+                 proxy servers.
+             </para>
+        </answer>
+    </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                Can I get rid of build output so I can start over?
+            </para>
+        </question>
+        <answer>
+            <para>
+                Yes - you can easily do this.
+                When you use BitBake to build an image, all the build output
+                goes into the directory created when you run the
+                build environment setup script (i.e.
+                <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
+                or
+                <link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>).
+                By default, this <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+                is named <filename>build</filename> but can be named
+                anything you want.
+            </para>
+
+            <para>
+                Within the Build Directory, is the <filename>tmp</filename>
+                directory.
+                To remove all the build output yet preserve any source code or
+                downloaded files from previous builds, simply remove the
+                <filename>tmp</filename> directory.
+            </para>
+        </answer>
+    </qandaentry>
+
+
+</qandaset>
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/ref-manual/figures/analysis-for-package-splitting.png b/documentation/ref-manual/figures/analysis-for-package-splitting.png
new file mode 100644
index 0000000..04f2794
--- /dev/null
+++ b/documentation/ref-manual/figures/analysis-for-package-splitting.png
diff --git a/documentation/ref-manual/figures/buildhistory-web.png b/documentation/ref-manual/figures/buildhistory-web.png
new file mode 100644
index 0000000..f6db86c
--- /dev/null
+++ b/documentation/ref-manual/figures/buildhistory-web.png
diff --git a/documentation/ref-manual/figures/buildhistory.png b/documentation/ref-manual/figures/buildhistory.png
new file mode 100644
index 0000000..edf98d9
--- /dev/null
+++ b/documentation/ref-manual/figures/buildhistory.png
diff --git a/documentation/ref-manual/figures/configuration-compile-autoreconf.png b/documentation/ref-manual/figures/configuration-compile-autoreconf.png
new file mode 100644
index 0000000..a07464f
--- /dev/null
+++ b/documentation/ref-manual/figures/configuration-compile-autoreconf.png
diff --git a/documentation/ref-manual/figures/cross-development-toolchains.png b/documentation/ref-manual/figures/cross-development-toolchains.png
new file mode 100644
index 0000000..d36670a
--- /dev/null
+++ b/documentation/ref-manual/figures/cross-development-toolchains.png
diff --git a/documentation/ref-manual/figures/image-generation.png b/documentation/ref-manual/figures/image-generation.png
new file mode 100644
index 0000000..5594658
--- /dev/null
+++ b/documentation/ref-manual/figures/image-generation.png
diff --git a/documentation/ref-manual/figures/images.png b/documentation/ref-manual/figures/images.png
new file mode 100644
index 0000000..d99eac1
--- /dev/null
+++ b/documentation/ref-manual/figures/images.png
diff --git a/documentation/ref-manual/figures/layer-input.png b/documentation/ref-manual/figures/layer-input.png
new file mode 100644
index 0000000..0a4f2e7
--- /dev/null
+++ b/documentation/ref-manual/figures/layer-input.png
diff --git a/documentation/ref-manual/figures/package-feeds.png b/documentation/ref-manual/figures/package-feeds.png
new file mode 100644
index 0000000..4bc311f
--- /dev/null
+++ b/documentation/ref-manual/figures/package-feeds.png
diff --git a/documentation/ref-manual/figures/patching.png b/documentation/ref-manual/figures/patching.png
new file mode 100644
index 0000000..8ecd018
--- /dev/null
+++ b/documentation/ref-manual/figures/patching.png
diff --git a/documentation/ref-manual/figures/poky-title.png b/documentation/ref-manual/figures/poky-title.png
new file mode 100644
index 0000000..2893d84
--- /dev/null
+++ b/documentation/ref-manual/figures/poky-title.png
diff --git a/documentation/ref-manual/figures/sdk-generation.png b/documentation/ref-manual/figures/sdk-generation.png
new file mode 100644
index 0000000..c37e274
--- /dev/null
+++ b/documentation/ref-manual/figures/sdk-generation.png
diff --git a/documentation/ref-manual/figures/sdk.png b/documentation/ref-manual/figures/sdk.png
new file mode 100644
index 0000000..a539cc5
--- /dev/null
+++ b/documentation/ref-manual/figures/sdk.png
diff --git a/documentation/ref-manual/figures/source-fetching.png b/documentation/ref-manual/figures/source-fetching.png
new file mode 100644
index 0000000..26aefb5
--- /dev/null
+++ b/documentation/ref-manual/figures/source-fetching.png
diff --git a/documentation/ref-manual/figures/source-input.png b/documentation/ref-manual/figures/source-input.png
new file mode 100644
index 0000000..f751505
--- /dev/null
+++ b/documentation/ref-manual/figures/source-input.png
diff --git a/documentation/ref-manual/figures/user-configuration.png b/documentation/ref-manual/figures/user-configuration.png
new file mode 100644
index 0000000..f2b3f8e
--- /dev/null
+++ b/documentation/ref-manual/figures/user-configuration.png
diff --git a/documentation/ref-manual/figures/yocto-environment-ref.png b/documentation/ref-manual/figures/yocto-environment-ref.png
new file mode 100644
index 0000000..650c6c8
--- /dev/null
+++ b/documentation/ref-manual/figures/yocto-environment-ref.png
diff --git a/documentation/ref-manual/introduction.xml b/documentation/ref-manual/introduction.xml
new file mode 100644
index 0000000..8232ba8
--- /dev/null
+++ b/documentation/ref-manual/introduction.xml
@@ -0,0 +1,439 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='intro'>
+<title>Introduction</title>
+
+<section id='intro-welcome'>
+    <title>Introduction</title>
+
+    <para>
+        This manual provides reference information for the current release of the Yocto Project.
+        The Yocto Project is an open-source collaboration project focused on embedded Linux
+        developers.
+        Amongst other things, the Yocto Project uses the OpenEmbedded build system, which
+        is based on the Poky project, to construct complete Linux images.
+        You can find complete introductory and getting started information on the Yocto Project
+        by reading the
+        <ulink url='&YOCTO_DOCS_QS_URL;'>Yocto Project Quick Start</ulink>.
+        For task-based information using the Yocto Project, see the
+        <ulink url='&YOCTO_DOCS_DEV_URL;'>Yocto Project Development Manual</ulink>
+        and the <ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;'>Yocto Project Linux Kernel Development Manual</ulink>.
+        For Board Support Package (BSP) structure information, see the
+        <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink>.
+        You can also find lots of Yocto Project information on the
+        <ulink url="&YOCTO_HOME_URL;">Yocto Project website</ulink>.
+    </para>
+</section>
+
+<section id='intro-manualoverview'>
+    <title>Documentation Overview</title>
+    <para>
+        This reference manual consists of the following:
+        <itemizedlist>
+            <listitem><para><emphasis>
+                <link linkend='usingpoky'>Using the Yocto Project</link>:</emphasis>
+                Provides an overview of the components that make up the Yocto Project
+                followed by information about debugging images created in the Yocto Project.
+                </para></listitem>
+            <listitem><para><emphasis>
+                <link linkend='technical-details'>Technical Details</link>:</emphasis>
+                Describes fundamental Yocto Project components as well as an explanation
+                behind how the Yocto Project uses shared state (sstate) cache to speed build time.
+                </para></listitem>
+            <listitem><para><emphasis>
+                <link linkend='ref-structure'>Directory Structure</link>:</emphasis>
+                Describes the
+                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink> created
+                either by unpacking a released Yocto Project tarball on your host development system,
+                or by cloning the upstream
+                <ulink url='&YOCTO_DOCS_DEV_URL;#poky'>Poky</ulink> Git repository.
+                </para></listitem>
+            <listitem><para><emphasis>
+                <link linkend='ref-bitbake'>BitBake</link>:</emphasis>
+                Provides an overview of the BitBake tool and its role within
+                the Yocto Project.</para></listitem>
+            <listitem><para><emphasis>
+                <link linkend='ref-classes'>Classes</link>:</emphasis>
+                Describes the classes used in the Yocto Project.</para></listitem>
+            <listitem><para><emphasis>
+                <link linkend='ref-images'>Images</link>:</emphasis>
+                Describes the standard images that the Yocto Project supports.
+                </para></listitem>
+            <listitem><para><emphasis>
+                <link linkend='ref-features'>Features</link>:</emphasis>
+                Describes mechanisms for creating distribution, machine, and image
+                features during the build process using the OpenEmbedded build system.</para></listitem>
+            <listitem><para><emphasis>
+                <link linkend='ref-variables-glos'>Variables Glossary</link>:</emphasis>
+                Presents most variables used by the OpenEmbedded build system, which
+                uses BitBake.
+                Entries describe the function of the variable and how to apply them.
+                </para></listitem>
+            <listitem><para><emphasis>
+                <link linkend='ref-varlocality'>Variable Context</link>:</emphasis>
+                Provides variable locality or context.</para></listitem>
+            <listitem><para><emphasis>
+                <link linkend='faq'>FAQ</link>:</emphasis>
+                Provides answers for commonly asked questions in the Yocto Project
+                development environment.</para></listitem>
+            <listitem><para><emphasis>
+                <link linkend='resources'>Contributing to the Yocto Project</link>:</emphasis>
+                Provides guidance on how you can contribute back to the Yocto
+                Project.</para></listitem>
+        </itemizedlist>
+    </para>
+</section>
+
+
+<section id='intro-requirements'>
+<title>System Requirements</title>
+    <para>
+        For general Yocto Project system requirements, see the
+        "<ulink url='&YOCTO_DOCS_QS_URL;#yp-resources'>What You Need and How You Get It</ulink>" section
+        in the Yocto Project Quick Start.
+        The remainder of this section provides details on system requirements
+        not covered in the Yocto Project Quick Start.
+    </para>
+
+    <section id='detailed-supported-distros'>
+        <title>Supported Linux Distributions</title>
+
+        <para>
+            Currently, the Yocto Project is supported on the following
+            distributions:
+            <note>
+                <para>
+                    Yocto Project releases are tested against the stable Linux
+                    distributions in the following list.
+                    The Yocto Project should work on other distributions but
+                    validation is not performed against them.
+                </para>
+
+                <para>
+                    In particular, the Yocto Project does not support
+                    and currently has no plans to support
+                    rolling-releases or development distributions due to their
+                    constantly changing nature.
+                    We welcome patches and bug reports, but keep in mind that
+                    our priority is on the supported platforms listed below.
+                </para>
+
+                <para>
+                    If you encounter problems, please go to
+                    <ulink url='&YOCTO_BUGZILLA_URL;'>Yocto Project Bugzilla</ulink>
+                    and submit a bug.
+                    We are interested in hearing about your experience.
+                </para>
+            </note>
+            <itemizedlist>
+<!--                <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>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>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>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>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>
+            </itemizedlist>
+        </para>
+
+        <note>
+            While the Yocto Project Team attempts to ensure all Yocto Project
+            releases are one hundred percent compatible with each officially
+            supported Linux distribution, instances might exist where you
+            encounter a problem while using the Yocto Project on a specific
+            distribution.
+            For example, the CentOS 6.4 distribution does not include the
+            Gtk+ 2.20.0 and PyGtk 2.21.0 (or higher) packages, which are
+            required to run
+            <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>Hob</ulink>.
+        </note>
+    </section>
+
+    <section id='required-packages-for-the-host-development-system'>
+    <title>Required Packages for the Host Development System</title>
+
+        <para>
+            The list of packages you need on the host development system can
+            be large when covering all build scenarios using the Yocto Project.
+            This section provides required packages according to
+            Linux distribution and function.
+        </para>
+
+        <section id='ubuntu-packages'>
+            <title>Ubuntu and Debian</title>
+
+            <para>
+                The following list shows the required packages by function
+                given a supported Ubuntu or Debian Linux distribution:
+                <itemizedlist>
+                    <listitem><para><emphasis>Essentials:</emphasis>
+                        Packages needed to build an image on a headless
+                        system:
+                        <literallayout class='monospaced'>
+     $ sudo apt-get install &UBUNTU_HOST_PACKAGES_ESSENTIAL;
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>Graphical Extras:</emphasis>
+                        Packages recommended if the host system has graphics support:
+                        <literallayout class='monospaced'>
+     $ sudo apt-get install libsdl1.2-dev xterm
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>Documentation:</emphasis>
+                        Packages needed if you are going to build out the
+                        Yocto Project documentation manuals:
+                        <literallayout class='monospaced'>
+     $ sudo apt-get install make xsltproc docbook-utils fop dblatex xmlto
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>ADT Installer Extras:</emphasis>
+                        Packages needed if you are going to be using the
+                        <ulink url='&YOCTO_DOCS_ADT_URL;#using-the-adt-installer'>Application Development Toolkit (ADT) Installer</ulink>:
+                        <literallayout class='monospaced'>
+     $ sudo apt-get install autoconf automake libtool libglib2.0-dev
+                        </literallayout></para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='fedora-packages'>
+            <title>Fedora Packages</title>
+
+            <para>
+                The following list shows the required packages by function
+                given a supported Fedora Linux distribution:
+                <itemizedlist>
+                    <listitem><para><emphasis>Essentials:</emphasis>
+                        Packages needed to build an image for a headless
+                        system:
+                        <literallayout class='monospaced'>
+     $ sudo yum install &FEDORA_HOST_PACKAGES_ESSENTIAL;
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>Graphical Extras:</emphasis>
+                        Packages recommended if the host system has graphics support:
+                        <literallayout class='monospaced'>
+     $ sudo yum install SDL-devel xterm
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>Documentation:</emphasis>
+                        Packages needed if you are going to build out the
+                        Yocto Project documentation manuals:
+                        <literallayout class='monospaced'>
+     $ sudo yum install make docbook-style-dsssl docbook-style-xsl \
+     docbook-dtds docbook-utils fop libxslt dblatex xmlto
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>ADT Installer Extras:</emphasis>
+                        Packages needed if you are going to be using the
+                        <ulink url='&YOCTO_DOCS_ADT_URL;#using-the-adt-installer'>Application Development Toolkit (ADT) Installer</ulink>:
+                        <literallayout class='monospaced'>
+     $ sudo yum install autoconf automake libtool glib2-devel
+                        </literallayout></para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='opensuse-packages'>
+            <title>openSUSE Packages</title>
+
+            <para>
+                The following list shows the required packages by function
+                given a supported openSUSE Linux distribution:
+                <itemizedlist>
+                    <listitem><para><emphasis>Essentials:</emphasis>
+                        Packages needed to build an image for a headless
+                        system:
+                        <literallayout class='monospaced'>
+     $ sudo zypper install &OPENSUSE_HOST_PACKAGES_ESSENTIAL;
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>Graphical Extras:</emphasis>
+                        Packages recommended if the host system has graphics support:
+                        <literallayout class='monospaced'>
+     $ sudo zypper install libSDL-devel xterm
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>Documentation:</emphasis>
+                        Packages needed if you are going to build out the
+                        Yocto Project documentation manuals:
+                        <literallayout class='monospaced'>
+     $ sudo zypper install make fop xsltproc dblatex xmlto
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>ADT Installer Extras:</emphasis>
+                        Packages needed if you are going to be using the
+                        <ulink url='&YOCTO_DOCS_ADT_URL;#using-the-adt-installer'>Application Development Toolkit (ADT) Installer</ulink>:
+                        <literallayout class='monospaced'>
+     $ sudo zypper install autoconf automake libtool glib2-devel
+                        </literallayout></para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='centos-packages'>
+            <title>CentOS Packages</title>
+
+            <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>
+                <itemizedlist>
+                    <listitem><para><emphasis>Essentials:</emphasis>
+                        Packages needed to build an image for a headless
+                        system:
+                        <literallayout class='monospaced'>
+     $ sudo yum install &CENTOS_HOST_PACKAGES_ESSENTIAL;
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>Graphical Extras:</emphasis>
+                        Packages recommended if the host system has graphics support:
+                        <literallayout class='monospaced'>
+     $ sudo yum install SDL-devel xterm
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>Documentation:</emphasis>
+                        Packages needed if you are going to build out the
+                        Yocto Project documentation manuals:
+                        <literallayout class='monospaced'>
+     $ sudo yum install make docbook-style-dsssl docbook-style-xsl \
+     docbook-dtds docbook-utils fop libxslt dblatex xmlto
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>ADT Installer Extras:</emphasis>
+                        Packages needed if you are going to be using the
+                        <ulink url='&YOCTO_DOCS_ADT_URL;#using-the-adt-installer'>Application Development Toolkit (ADT) Installer</ulink>:
+                        <literallayout class='monospaced'>
+     $ sudo yum install autoconf automake libtool glib2-devel
+                        </literallayout></para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+    </section>
+
+    <section id='required-git-tar-and-python-versions'>
+        <title>Required Git, tar, and Python Versions</title>
+
+        <para>
+            In order to use the build system, your host development system
+            must meet the following version requirements for Git, tar, and
+            Python:
+            <itemizedlist>
+                <listitem><para>Git 1.7.5 or greater</para></listitem>
+                <listitem><para>tar 1.24 or greater</para></listitem>
+                <listitem><para>Python 2.7.3 or greater not including
+                    Python 3.x, which is not supported.</para></listitem>
+            </itemizedlist>
+        </para>
+
+        <para>
+            If your host development system does not meet all these requirements,
+            you can resolve this by either downloading a pre-built tarball
+            containing these tools, or building such a tarball on another
+            system.
+            Regardless of the method, once you have the tarball, you simply
+            install it somewhere on your system, such as a directory in your
+            home directory, and then source the environment script provided,
+            which adds the tools into <filename>PATH</filename> and sets
+            any other environment variables required to run the tools.
+            Doing so gives you working versions of Git, tar, Python and
+            <filename>chrpath</filename>.
+        </para>
+
+        <para>
+            If downloading a pre-built tarball, locate the
+            <filename>*.sh</filename> at
+            <ulink url='&YOCTO_DL_URL;/releases/yocto/yocto-&DISTRO;/buildtools/'></ulink>.
+        </para>
+
+        <para>
+            If building your own tarball, do so using this command:
+            <literallayout class='monospaced'>
+     $ bitbake buildtools-tarball
+            </literallayout>
+            <note>
+                The <link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>
+                variable determines whether you build tools for a 32-bit
+                or 64-bit system.
+            </note>
+            Once the build completes, you can find the file that installs the
+            the tools in the <filename>tmp/deploy/sdk</filename> subdirectory
+            of the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+            The file used to install the tarball has the string "buildtools"
+            in the name.
+        </para>
+
+        <para>
+            After you have either built the tarball or downloaded it, you need
+            to install it.
+            Install the tools by executing the <filename>*.sh</filename> file.
+            During execution, a prompt appears that allows you to choose the
+            installation directory.
+            For example, you could choose the following:
+            <literallayout class='monospaced'>
+     /home/your-username/sdk
+            </literallayout>
+        </para>
+
+        <para>
+            The final step before you can actually use the tools is to source
+            the tools environment with a command like the following:
+            <literallayout class='monospaced'>
+     $ source /home/your-username/sdk/environment-setup-i586-poky-linux
+            </literallayout>
+            Of course, you need to supply your installation directory and be
+            sure to use the right file (i.e. i585 or x86-64).
+        </para>
+    </section>
+</section>
+
+<section id='intro-getit'>
+    <title>Obtaining the Yocto Project</title>
+    <para>
+        The Yocto Project development team makes the Yocto Project available through a number
+        of methods:
+        <itemizedlist>
+            <listitem><para><emphasis>Releases:</emphasis> Stable, tested releases are available through
+                <ulink url='&YOCTO_DL_URL;/releases/yocto/'/>.</para></listitem>
+            <listitem><para><emphasis>Nightly Builds:</emphasis> These releases are available at
+                <ulink url='http://autobuilder.yoctoproject.org/nightly'/>.
+                These builds include Yocto Project releases, meta-toolchain tarball installation scripts, and
+                experimental builds.</para></listitem>
+            <listitem><para><emphasis>Yocto Project Website:</emphasis> You can find releases
+                of the Yocto Project and supported BSPs at the
+                <ulink url='&YOCTO_HOME_URL;'>Yocto Project website</ulink>.
+                Along with these downloads, you can find lots of other information at this site.
+                </para></listitem>
+        </itemizedlist>
+    </para>
+</section>
+
+<section id='intro-getit-dev'>
+    <title>Development Checkouts</title>
+    <para>
+        Development using the Yocto Project requires a local
+        <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+        You can set up the Source Directory by downloading a Yocto Project release tarball and unpacking it,
+        or by cloning a copy of the upstream
+        <ulink url='&YOCTO_DOCS_DEV_URL;#poky'>Poky</ulink> Git repository.
+        For information on both these methods, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#getting-setup'>Getting Set Up</ulink>"
+        section in the Yocto Project Development Manual.
+    </para>
+</section>
+
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/ref-manual/migration.xml b/documentation/ref-manual/migration.xml
new file mode 100644
index 0000000..dc24628
--- /dev/null
+++ b/documentation/ref-manual/migration.xml
@@ -0,0 +1,1089 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='migration'>
+<title>Migrating to a Newer Yocto Project Release</title>
+
+    <para>
+        This chapter provides information you can use to migrate work to a
+        newer Yocto Project release.  You can find the same information in the
+        release notes for a given release.
+    </para>
+
+<section id='moving-to-the-yocto-project-1.3-release'>
+    <title>Moving to the Yocto Project 1.3 Release</title>
+
+    <para>
+        This section provides migration information for moving to the
+        Yocto Project 1.3 Release from the prior release.
+    </para>
+
+    <section id='1.3-local-configuration'>
+        <title>Local Configuration</title>
+
+        <para>
+            Differences include changes for
+            <link linkend='var-SSTATE_MIRRORS'><filename>SSTATE_MIRRORS</filename></link>
+            and <filename>bblayers.conf</filename>.
+        </para>
+
+        <section id='migration-1.3-sstate-mirrors'>
+            <title>SSTATE_MIRRORS</title>
+
+            <para>
+                The shared state cache (sstate-cache), as pointed to by
+                <link linkend='var-SSTATE_DIR'><filename>SSTATE_DIR</filename></link>, by default
+                now has two-character subdirectories to prevent issues arising
+                from too many files in the same directory.
+                Also, native sstate-cache packages will go into a subdirectory named using
+                the distro ID string.
+                If you copy the newly structured sstate-cache to a mirror location
+                (either local or remote) and then point to it in
+                <link linkend='var-SSTATE_MIRRORS'><filename>SSTATE_MIRRORS</filename></link>,
+                you need to append "PATH" to the end of the mirror URL so that
+                the path used by BitBake before the mirror substitution is
+                appended to the path used to access the mirror.
+                Here is an example:
+                <literallayout class='monospaced'>
+     SSTATE_MIRRORS = "file://.* http://someserver.tld/share/sstate/PATH"
+                </literallayout>
+            </para>
+        </section>
+
+        <section id='migration-1.3-bblayers-conf'>
+            <title>bblayers.conf</title>
+
+            <para>
+                The <filename>meta-yocto</filename> layer consists of two parts
+                that correspond to the Poky reference distribution and the
+                reference hardware Board Support Packages (BSPs), respectively:
+                <filename>meta-yocto</filename> and
+                <filename>meta-yocto-bsp</filename>.
+                When running BitBake or Hob for the first time after upgrading,
+                your <filename>conf/bblayers.conf</filename> file will be
+                updated to handle this change and you will be asked to
+                re-run or restart for the changes to take effect.
+            </para>
+        </section>
+    </section>
+
+    <section id='1.3-recipes'>
+        <title>Recipes</title>
+
+        <para>
+            Differences include changes for the following:
+            <itemizedlist>
+                <listitem><para>Python function whitespace</para></listitem>
+                <listitem><para><filename>proto=</filename> in <filename>SRC_URI</filename></para></listitem>
+                <listitem><para><filename>nativesdk</filename></para></listitem>
+                <listitem><para>Task recipes</para></listitem>
+                <listitem><para><filename>IMAGE_FEATURES</filename></para></listitem>
+                <listitem><para>Removed recipes</para></listitem>
+            </itemizedlist>
+        </para>
+
+        <section id='migration-1.3-python-function-whitespace'>
+            <title>Python Function Whitespace</title>
+
+            <para>
+                All Python functions must now use four spaces for indentation.
+                Previously, an inconsistent mix of spaces and tabs existed,
+                which made extending these functions using
+                <filename>_append</filename> or <filename>_prepend</filename>
+                complicated given that Python treats whitespace as
+                syntactically significant.
+                If you are defining or extending any Python functions (e.g.
+                <filename>populate_packages</filename>, <filename>do_unpack</filename>,
+                <filename>do_patch</filename> and so forth) in custom recipes
+                or classes, you need to ensure you are using consistent
+                four-space indentation.
+            </para>
+        </section>
+
+        <section id='migration-1.3-proto=-in-src-uri'>
+            <title>proto= in SRC_URI</title>
+
+            <para>
+                Any use of <filename>proto=</filename> in
+                <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>
+                needs to be changed to <filename>protocol=</filename>.
+                In particular, this applies to the following URIs:
+                <itemizedlist>
+                    <listitem><para><filename>svn://</filename></para></listitem>
+                    <listitem><para><filename>bzr://</filename></para></listitem>
+                    <listitem><para><filename>hg://</filename></para></listitem>
+                    <listitem><para><filename>osc://</filename></para></listitem>
+                </itemizedlist>
+                Other URIs were already using <filename>protocol=</filename>.
+                This change improves consistency.
+            </para>
+        </section>
+
+        <section id='migration-1.3-nativesdk'>
+            <title>nativesdk</title>
+
+            <para>
+                The suffix <filename>nativesdk</filename> is now implemented
+                as a prefix, which simplifies a lot of the packaging code for
+                <filename>nativesdk</filename> recipes.
+                All custom <filename>nativesdk</filename> recipes and any
+                references need to be updated to use
+                <filename>nativesdk-*</filename> instead of
+                <filename>*-nativesdk</filename>.
+            </para>
+        </section>
+
+        <section id='migration-1.3-task-recipes'>
+            <title>Task Recipes</title>
+
+            <para>
+                "Task" recipes are now known as "Package groups" and have
+                been renamed from <filename>task-*.bb</filename> to
+                <filename>packagegroup-*.bb</filename>.
+                Existing references to the previous <filename>task-*</filename>
+                names should work in most cases as there is an automatic
+                upgrade path for most packages.
+                However, you should update references in your own recipes and
+                configurations as they could be removed in future releases.
+                You should also rename any custom <filename>task-*</filename>
+                recipes to <filename>packagegroup-*</filename>, and change
+                them to inherit <filename>packagegroup</filename> instead of
+                <filename>task</filename>, as well as taking the opportunity
+                to remove anything now handled by
+                <filename>packagegroup.bbclass</filename>, such as providing
+                <filename>-dev</filename> and <filename>-dbg</filename>
+                packages, setting
+                <link linkend='var-LIC_FILES_CHKSUM'><filename>LIC_FILES_CHKSUM</filename></link>,
+                and so forth.
+                See the
+                "<link linkend='ref-classes-packagegroup'>Package Groups - packagegroup.bbclass</link>"
+                section for further details.
+            </para>
+        </section>
+
+        <section id='migration-1.3-image-features'>
+            <title>IMAGE_FEATURES</title>
+
+            <para>
+                Image recipes that previously included "apps-console-core"
+                in <link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>
+                should now include "splash" instead to enable the boot-up
+                splash screen.
+                Retaining "apps-console-core" will still include the splash
+                screen but generates a warning.
+                The "apps-x11-core" and "apps-x11-games"
+                <filename>IMAGE_FEATURES</filename> features have been removed.
+            </para>
+        </section>
+
+        <section id='migration-1.3-removed-recipes'>
+            <title>Removed Recipes</title>
+
+            <para>
+                The following recipes have been removed.
+                For most of them, it is unlikely that you would have any
+                references to them in your own
+                <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>.
+                However, you should check your metadata against this list to be sure:
+                <itemizedlist>
+                    <listitem><para><emphasis><filename>libx11-trim</filename></emphasis>:
+                        Replaced by <filename>libx11</filename>, which has a negligible
+                        size difference with modern Xorg.</para></listitem>
+                    <listitem><para><emphasis><filename>xserver-xorg-lite</filename></emphasis>:
+                        Use <filename>xserver-xorg</filename>, which has a negligible
+                        size difference when DRI and GLX modules are not installed.</para></listitem>
+                    <listitem><para><emphasis><filename>xserver-kdrive</filename></emphasis>:
+                        Effectively unmaintained for many years.</para></listitem>
+                    <listitem><para><emphasis><filename>mesa-xlib</filename></emphasis>:
+                        No longer serves any purpose.</para></listitem>
+                    <listitem><para><emphasis><filename>galago</filename></emphasis>:
+                        Replaced by telepathy.</para></listitem>
+                    <listitem><para><emphasis><filename>gail</filename></emphasis>:
+                        Functionality was integrated into GTK+ 2.13.</para></listitem>
+                    <listitem><para><emphasis><filename>eggdbus</filename></emphasis>:
+                        No longer needed.</para></listitem>
+                    <listitem><para><emphasis><filename>gcc-*-intermediate</filename></emphasis>:
+                        The build has been restructured to avoid the need for
+                        this step.</para></listitem>
+                    <listitem><para><emphasis><filename>libgsmd</filename></emphasis>:
+                        Unmaintained for many years.
+                        Functionality now provided by
+                        <filename>ofono</filename> instead.</para></listitem>
+                    <listitem><para><emphasis>contacts, dates, tasks, eds-tools</emphasis>:
+                        Largely unmaintained PIM application suite.
+                        It has been moved to <filename>meta-gnome</filename>
+                        in <filename>meta-openembedded</filename>.</para></listitem>
+                </itemizedlist>
+                In addition to the previously listed changes, the
+                <filename>meta-demoapps</filename> directory has also been removed
+                because the recipes in it were not being maintained and many
+                had become obsolete or broken.
+                Additionally, these recipes were not parsed in the default configuration.
+                Many of these recipes are already provided in an updated and
+                maintained form within the OpenEmbedded community layers such as
+                <filename>meta-oe</filename> and <filename>meta-gnome</filename>.
+                For the remainder, you can now find them in the
+                <filename>meta-extras</filename> repository, which is in the
+                Yocto Project
+                <ulink url='&YOCTO_DOCS_DEV_URL;#source-repositories'>Source Repositories</ulink>.
+            </para>
+        </section>
+    </section>
+
+    <section id='1.3-linux-kernel-naming'>
+        <title>Linux Kernel Naming</title>
+
+        <para>
+            The naming scheme for kernel output binaries has been changed to
+            now include
+            <link linkend='var-PE'><filename>PE</filename></link> as part of the
+            filename:
+            <literallayout class='monospaced'>
+     KERNEL_IMAGE_BASE_NAME ?= "${KERNEL_IMAGETYPE}-${PE}-${PV}-${PR}-${MACHINE}-${DATETIME}"
+            </literallayout>
+        </para>
+
+        <para>
+            Because the <filename>PE</filename> variable is not set by default,
+            these binary files could result with names that include two dash
+            characters.
+            Here is an example:
+            <literallayout class='monospaced'>
+     bzImage--3.10.9+git0+cd502a8814_7144bcc4b8-r0-qemux86-64-20130830085431.bin
+            </literallayout>
+        </para>
+    </section>
+</section>
+
+<section id='moving-to-the-yocto-project-1.4-release'>
+    <title>Moving to the Yocto Project 1.4 Release</title>
+
+    <para>
+        This section provides migration information for moving to the
+        Yocto Project 1.4 Release from the prior release.
+    </para>
+
+    <section id='migration-1.4-bitbake'>
+        <title>BitBake</title>
+
+        <para>
+            Differences include the following:
+            <itemizedlist>
+                <listitem><para><emphasis>Comment Continuation:</emphasis>
+                    If a comment ends with a line continuation (\) character,
+                    then the next line must also be a comment.
+                    Any instance where this is not the case, now triggers
+                    a warning.
+                    You must either remove the continuation character, or be
+                    sure the next line is a comment.
+                    </para></listitem>
+                <listitem><para><emphasis>Package Name Overrides:</emphasis>
+                    The runtime package specific 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-RPROVIDES'><filename>RPROVIDES</filename></link>,
+                    <link linkend='var-RCONFLICTS'><filename>RCONFLICTS</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>,
+                    and the pre, post, install, and uninstall script functions
+                    <filename>pkg_preinst</filename>,
+                    <filename>pkg_postinst</filename>,
+                    <filename>pkg_prerm</filename>, and
+                    <filename>pkg_postrm</filename> should always have a
+                    package name override.
+                    For example, use <filename>RDEPENDS_${PN}</filename> for
+                    the main package instead of <filename>RDEPENDS</filename>.
+                    BitBake uses more strict checks when it parses recipes.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-1.4-build-behavior'>
+        <title>Build Behavior</title>
+
+        <para>
+            Differences include the following:
+            <itemizedlist>
+                <listitem><para><emphasis>Shared State Code:</emphasis>
+                    The shared state code has been optimized to avoid running
+                    unnecessary tasks.
+                    For example,
+                    <filename>bitbake -c rootfs some-image</filename> from
+                    shared state no longer populates the target sysroot
+                    since that is not necessary.
+                    Instead, the system just needs to extract the output
+                    package contents, re-create the packages, and construct
+                    the root filesystem.
+                    This change is unlikely to cause any problems unless
+                    you have missing declared dependencies.
+                    </para></listitem>
+                <listitem><para><emphasis>Scanning Directory Names:</emphasis>
+                    When scanning for files in
+                    <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>,
+                    the build system now uses
+                    <link linkend='var-FILESOVERRIDES'><filename>FILESOVERRIDES</filename></link>
+                    instead of <link linkend='var-OVERRIDES'><filename>OVERRIDES</filename></link>
+                    for the directory names.
+                    In general, the values previously in
+                    <filename>OVERRIDES</filename> are now in
+                    <filename>FILESOVERRIDES</filename> as well.
+                    However, if you relied upon an additional value
+                    you previously added to <filename>OVERRIDES</filename>,
+                    you might now need to add it to
+                    <filename>FILESOVERRIDES</filename> unless you are already
+                    adding it through the
+                    <link linkend='var-MACHINEOVERRIDES'><filename>MACHINEOVERRIDES</filename></link>
+                    or <link linkend='var-DISTROOVERRIDES'><filename>DISTROOVERRIDES</filename></link>
+                    variables, as appropriate.
+                    For more related changes, see the
+                    "<link linkend='migration-1.4-variables'>Variables</link>"
+                    section.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+
+    <section id='migration-1.4-proxies-and-fetching-source'>
+        <title>Proxies and Fetching Source</title>
+
+        <para>
+            A new <filename>oe-git-proxy</filename> script has been added to
+            replace previous methods of handling proxies and fetching source
+            from Git.
+            See the <filename>meta-yocto/conf/site.conf.sample</filename> file
+            for information on how to use this script.
+        </para>
+    </section>
+
+    <section id='migration-1.4-custom-interfaces-file-netbase-change'>
+        <title>Custom Interfaces File (netbase change)</title>
+
+        <para>
+            If you have created your own custom
+            <filename>etc/network/interfaces</filename> file by creating
+            an append file for the <filename>netbase</filename> recipe,
+            you now need to create an append file for the
+            <filename>init-ifupdown</filename> recipe instead, which you can
+            find in the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+            at <filename>meta/recipes-core/init-ifupdown</filename>.
+            For information on how to use append files, see the
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#using-bbappend-files'>Using .bbappend Files</ulink>"
+            in the Yocto Project Development Manual.
+        </para>
+    </section>
+
+    <section id='migration-1.4-remote-debugging'>
+        <title>Remote Debugging</title>
+
+        <para>
+            Support for remote debugging with the Eclipse IDE is now
+            separated into an image feature
+            (<filename>eclipse-debug</filename>) that corresponds to the
+            <filename>packagegroup-core-eclipse-debug</filename> package group.
+            Previously, the debugging feature was included through the
+            <filename>tools-debug</filename> image feature, which corresponds
+            to the <filename>packagegroup-core-tools-debug</filename>
+            package group.
+        </para>
+    </section>
+
+    <section id='migration-1.4-variables'>
+        <title>Variables</title>
+
+        <para>
+            The following variables have changed:
+            <itemizedlist>
+                <listitem><para><emphasis><filename>SANITY_TESTED_DISTROS</filename>:</emphasis>
+                    This variable now uses a distribution ID, which is composed
+                    of the host distributor ID followed by the release.
+                    Previously,
+                    <link linkend='var-SANITY_TESTED_DISTROS'><filename>SANITY_TESTED_DISTROS</filename></link>
+                    was composed of the description field.
+                    For example, "Ubuntu 12.10" becomes "Ubuntu-12.10".
+                    You do not need to worry about this change if you are not
+                    specifically setting this variable, or if you are
+                    specifically setting it to "".
+                    </para></listitem>
+                <listitem><para><emphasis><filename>SRC_URI</filename>:</emphasis>
+                    The <filename>${</filename><link linkend='var-PN'><filename>PN</filename></link><filename>}</filename>,
+                    <filename>${</filename><link linkend='var-PF'><filename>PF</filename></link><filename>}</filename>,
+                    <filename>${</filename><link linkend='var-P'><filename>P</filename></link><filename>}</filename>,
+                    and <filename>FILE_DIRNAME</filename> directories have been
+                    dropped from the default value of the
+                    <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>
+                    variable, which is used as the search path for finding files
+                    referred to in
+                    <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>.
+                    If you have a recipe that relied upon these directories,
+                    which would be unusual, then you will need to add the
+                    appropriate paths within the recipe or, alternatively,
+                    rearrange the files.
+                    The most common locations are still covered by
+                    <filename>${BP}</filename>, <filename>${BPN}</filename>,
+                    and "files", which all remain in the default value of
+                    <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-target-package-management-with-rpm'>
+        <title>Target Package Management with RPM</title>
+
+        <para>
+            If runtime package management is enabled and the RPM backend
+            is selected, Smart is now installed for package download, dependency
+            resolution, and upgrades instead of Zypper.
+            For more information on how to use Smart, run the following command
+            on the target:
+            <literallayout class='monospaced'>
+     smart --help
+            </literallayout>
+        </para>
+    </section>
+
+    <section id='migration-1.4-recipes-moved'>
+        <title>Recipes Moved</title>
+
+        <para>
+            The following recipes were moved from their previous locations
+            because they are no longer used by anything in
+            the OpenEmbedded-Core:
+            <itemizedlist>
+                <listitem><para><emphasis><filename>clutter-box2d</filename>:</emphasis>
+                    Now resides in the <filename>meta-oe</filename> layer.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>evolution-data-server</filename>:</emphasis>
+                    Now resides in the <filename>meta-gnome</filename> layer.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>gthumb</filename>:</emphasis>
+                    Now resides in the <filename>meta-gnome</filename> layer.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>gtkhtml2</filename>:</emphasis>
+                    Now resides in the <filename>meta-oe</filename> layer.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>gupnp</filename>:</emphasis>
+                    Now resides in the <filename>meta-multimedia</filename> layer.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>gypsy</filename>:</emphasis>
+                    Now resides in the <filename>meta-oe</filename> layer.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>libcanberra</filename>:</emphasis>
+                    Now resides in the <filename>meta-gnome</filename> layer.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>libgdata</filename>:</emphasis>
+                    Now resides in the <filename>meta-gnome</filename> layer.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>libmusicbrainz</filename>:</emphasis>
+                    Now resides in the <filename>meta-multimedia</filename> layer.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>metacity</filename>:</emphasis>
+                    Now resides in the <filename>meta-gnome</filename> layer.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>polkit</filename>:</emphasis>
+                    Now resides in the <filename>meta-oe</filename> layer.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>zeroconf</filename>:</emphasis>
+                    Now resides in the <filename>meta-networking</filename> layer.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-1.4-removals-and-renames'>
+        <title>Removals and Renames</title>
+
+        <para>
+            The following list shows what has been removed or renamed:
+            <itemizedlist>
+                <listitem><para><emphasis><filename>evieext</filename>:</emphasis>
+                    Removed because it has been removed from
+                    <filename>xserver</filename> since 2008.
+                    </para></listitem>
+                <listitem><para><emphasis>Gtk+ DirectFB:</emphasis>
+                    Removed support because upstream Gtk+ no longer supports it
+                    as of version 2.18.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>libxfontcache / xfontcacheproto</filename>:</emphasis>
+                    Removed because they were removed from the Xorg server in 2008.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>libxp / libxprintapputil / libxprintutil / printproto</filename>:</emphasis>
+                    Removed because the XPrint server was removed from
+                    Xorg in 2008.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>libxtrap / xtrapproto</filename>:</emphasis>
+                    Removed because their functionality was broken upstream.
+                    </para></listitem>
+                <listitem><para><emphasis>linux-yocto 3.0 kernel:</emphasis>
+                    Removed with linux-yocto 3.8 kernel being added.
+                    The linux-yocto 3.2 and linux-yocto 3.4 kernels remain
+                    as part of the release.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>lsbsetup</filename>:</emphasis>
+                    Removed with functionality now provided by
+                    <filename>lsbtest</filename>.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>matchbox-stroke</filename>:</emphasis>
+                    Removed because it was never more than a proof-of-concept.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>matchbox-wm-2 / matchbox-theme-sato-2</filename>:</emphasis>
+                    Removed because they are not maintained.
+                    However, <filename>matchbox-wm</filename> and
+                    <filename>matchbox-theme-sato</filename> are still
+                    provided.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>mesa-dri</filename>:</emphasis>
+                    Renamed to <filename>mesa</filename>.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>mesa-xlib</filename>:</emphasis>
+                    Removed because it was no longer useful.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>mutter</filename>:</emphasis>
+                    Removed because nothing ever uses it and the recipe is
+                    very old.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>orinoco-conf</filename>:</emphasis>
+                    Removed because it has become obsolete.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>update-modules</filename>:</emphasis>
+                    Removed because it is no longer used.
+                    The kernel module <filename>postinstall</filename> and
+                    <filename>postrm</filename> scripts can now do the same
+                    task without the use of this script.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>web</filename>:</emphasis>
+                    Removed because it is not maintained.  Superseded by
+                    <filename>web-webkit</filename>.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>xf86bigfontproto</filename>:</emphasis>
+                    Removed because upstream it has been disabled by default
+                    since 2007.
+                    Nothing uses <filename>xf86bigfontproto</filename>.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>xf86rushproto</filename>:</emphasis>
+                    Removed because its dependency in
+                    <filename>xserver</filename> was spurious and it was
+                    removed in 2005.
+                    </para></listitem>
+                <listitem><para><emphasis><filename>zypper / libzypp / sat-solver</filename>:</emphasis>
+                    Removed and been functionally replaced with Smart
+                    (<filename>python-smartpm</filename>) when RPM packaging
+                    is used and package management is enabled on the target.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+</section>
+
+<section id='moving-to-the-yocto-project-1.5-release'>
+    <title>Moving to the Yocto Project 1.5 Release</title>
+
+    <para>
+        This section provides migration information for moving to the
+        Yocto Project 1.5 Release from the prior release.
+    </para>
+
+    <section id='migration-1.5-host-dependency-changes'>
+        <title>Host Dependency Changes</title>
+
+        <para>
+            The OpenEmbedded build system now has some additional requirements
+            on the host system:
+            <itemizedlist>
+                <listitem><para>Python 2.7.3+</para></listitem>
+                <listitem><para>Tar 1.24+</para></listitem>
+                <listitem><para>Git 1.7.5+</para></listitem>
+                <listitem><para>Patched version of Make if you are using
+                    3.82.
+                    Most distributions that provide Make 3.82 use the patched
+                    version.</para></listitem>
+            </itemizedlist>
+            If the Linux distribution you are using on your build host
+            does not provide packages for these, you can install and use
+            the Buildtools tarball, which provides an SDK-like environment
+            containing them.
+        </para>
+
+        <para>
+            For more information on this requirement, see the
+            "<link linkend='required-git-tar-and-python-versions'>Required Git, tar, and Python Versions</link>"
+            section.
+        </para>
+    </section>
+
+    <section id='migration-1.5-atom-pc-bsp'>
+        <title><filename>atom-pc</filename> Board Support Package (BSP)</title>
+
+        <para>
+            The <filename>atom-pc</filename> hardware reference BSP has been
+            replaced by a <filename>genericx86</filename> BSP.
+            This BSP is not necessarily guaranteed to work on all x86
+            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.
+            </note>
+        </para>
+    </section>
+
+    <section id='migration-1.5-bitbake'>
+        <title>BitBake</title>
+
+        <para>
+            The following changes have been made that relate to BitBake:
+            <itemizedlist>
+                <listitem><para>
+                    BitBake now supports a <filename>_remove</filename>
+                    operator.
+                    The addition of this operator means you will have to
+                    rename any items in recipe space (functions, variables)
+                    whose names currently contain
+                    <filename>_remove_</filename> or end with
+                    <filename>_remove</filename> to avoid unexpected behavior.
+                    </para></listitem>
+                <listitem><para>
+                    BitBake's global method pool has been removed.
+                    This method is not particularly useful and led to clashes
+                    between recipes containing functions that had the
+                    same name.</para></listitem>
+                <listitem><para>
+                    The "none" server backend has been removed.
+                    The "process" server backend has been serving well as the
+                    default for a long time now.</para></listitem>
+                <listitem><para>
+                    The <filename>bitbake-runtask</filename> script has been
+                    removed.</para></listitem>
+                <listitem><para>
+                    <filename>${</filename><link linkend='var-P'><filename>P</filename></link><filename>}</filename>
+                    and
+                    <filename>${</filename><link linkend='var-PF'><filename>PF</filename></link><filename>}</filename>
+                    are no longer added to
+                    <link linkend='var-PROVIDES'><filename>PROVIDES</filename></link>
+                    by default in <filename>bitbake.conf</filename>.
+                    These version-specific <filename>PROVIDES</filename>
+                    items were seldom used.
+                    Attempting to use them could result in two versions being
+                    built simultaneously rather than just one version due to
+                    the way BitBake resolves dependencies.</para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-1.5-qa-warnings'>
+        <title>QA Warnings</title>
+
+        <para>
+            The following changes have been made to the package QA checks:
+            <itemizedlist>
+                <listitem><para>
+                    If you have customized
+                    <link linkend='var-ERROR_QA'><filename>ERROR_QA</filename></link>
+                    or <link linkend='var-WARN_QA'><filename>WARN_QA</filename></link>
+                    values in your configuration, check that they contain all of
+                    the issues that you wish to be reported.
+                    Previous Yocto Project versions contained a bug that meant
+                    that any item not mentioned in <filename>ERROR_QA</filename>
+                    or <filename>WARN_QA</filename> would be treated as a
+                    warning.
+                    Consequently, several important items were not already in
+                    the default value of <filename>WARN_QA</filename>.
+                    All of the possible QA checks are now documented in the
+                    "<link linkend='ref-classes-insane'><filename>insane.bbclass</filename></link>"
+                    section.</para></listitem>
+                <listitem><para>
+                    An additional QA check has been added to check if
+                    <filename>/usr/share/info/dir</filename> is being installed.
+                    Your recipe should delete this file within
+                    <filename>do_install</filename> if "make install" is
+                    installing it.</para></listitem>
+                <listitem><para>
+                    If you are using the buildhistory class, the check for the
+                    package version going backwards is now controlled using a
+                    standard QA check.
+                    Thus, if you have customized your
+                    <filename>ERROR_QA</filename> or
+                    <filename>WARN_QA</filename> values and still wish to have
+                    this check performed, you should add
+                    "version-going-backwards" to your value for one or the
+                    other variables depending on how you wish it to be handled.
+                    See the documented QA checks in the
+                    "<link linkend='ref-classes-insane'><filename>insane.bbclass</filename></link>"
+                    section.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-1.5-directory-layout-changes'>
+        <title>Directory Layout Changes</title>
+
+        <para>
+            The following directory changes exist:
+            <itemizedlist>
+                <listitem><para>
+                    Output SDK installer files are now named to include the
+                    image name and tuning architecture through the
+                    <link linkend='var-SDK_NAME'><filename>SDK_NAME</filename></link>
+                    variable.</para></listitem>
+                <listitem><para>
+                    Images and related files are now installed into a directory
+                    that is specific to the machine, instead of a parent
+                    directory containing output files for multiple machines.
+                    The
+                    <link linkend='var-DEPLOY_DIR_IMAGE'><filename>DEPLOY_DIR_IMAGE</filename></link>
+                    variable continues to point to the directory containing
+                    images for the current
+                    <link linkend='var-MACHINE'><filename>MACHINE</filename></link>
+                    and should be used anywhere there is a need to refer to
+                    this directory.
+                    The <filename>runqemu</filename> script now uses this
+                    variable to find images and kernel binaries and will use
+                    BitBake to determine the directory.
+                    Alternatively, you can set the
+                    <filename>DEPLOY_DIR_IMAGE</filename> variable in the
+                    external environment.</para></listitem>
+                <listitem><para>
+                    When buildhistory is enabled, its output is now written
+                    under the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+                    rather than
+                    <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>.
+                    Doing so makes it easier to delete
+                    <filename>TMPDIR</filename> and preserve the build history.
+                    Additionally, data for produced SDKs is now split by
+                    <link linkend='var-IMAGE_NAME'><filename>IMAGE_NAME</filename></link>.
+                    </para></listitem>
+                <listitem><para>
+                    The <filename>pkgdata</filename> directory produced as
+                    part of the packaging process has been collapsed into a
+                    single machine-specific directory.
+                    This directory is located under
+                    <filename>sysroots</filename> and uses a machine-specific
+                    name (i.e.
+                    <filename>tmp/sysroots/&lt;machine&gt;/pkgdata</filename>).
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-1.5-shortened-git-srcrev-values'>
+        <title>Shortened Git <filename>SRCREV</filename> Values</title>
+
+        <para>
+            BitBake will now shorten revisions from Git repositories from the
+            normal 40 characters down to 10 characters within
+            <link linkend='var-SRCPV'><filename>SRCPV</filename></link>
+            for improved usability in path and file names.
+            This change should be safe within contexts where these revisions
+            are used because the chances of spatially close collisions
+            is very low.
+            Distant collisions are not a major issue in the way
+            the values are used.
+        </para>
+    </section>
+
+    <section id='migration-1.5-image-features'>
+        <title><filename>IMAGE_FEATURES</filename></title>
+
+        <para>
+            The following changes have been made that relate to
+            <link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>:
+            <itemizedlist>
+                <listitem><para>
+                    The value of
+                    <link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>
+                    is now validated to ensure invalid feature items are not
+                    added.
+                    Some users mistakenly add package names to this variable
+                    instead of using
+                    <link linkend='var-IMAGE_INSTALL'><filename>IMAGE_INSTALL</filename></link>
+                    in order to have the package added to the image, which does
+                    not work.
+                    This change is intended to catch those kinds of situations.
+                    Valid <filename>IMAGE_FEATURES</filename> are drawn from
+                    <link linkend='var-PACKAGE_GROUP'><filename>PACKAGE_GROUP</filename></link>
+                    definitions,
+                    <link linkend='var-COMPLEMENTARY_GLOB'><filename>COMPLEMENTARY_GLOB</filename></link>
+                    and a new "validitems" varflag on
+                    <filename>IMAGE_FEATURES</filename>.
+                    The "validitems" varflag change allows additional features
+                    to be added if they are not provided using the previous
+                    two mechanisms.
+                    </para></listitem>
+                <listitem><para>
+                    The previously deprecated "apps-console-core"
+                    <filename>IMAGE_FEATURES</filename> item is no longer
+                    supported.
+                    Add "splash" to <filename>IMAGE_FEATURES</filename> if you
+                    wish to have the splash screen enabled, since this is
+                    all that apps-console-core was doing.</para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-1.5-run'>
+        <title><filename>run</filename></title>
+
+        <para>
+            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>.
+            The change also means that recipes that install files to
+            <filename>/var/run</filename> must be changed.
+            You can find a guide on how to make these changes
+            <ulink url='http://permalink.gmane.org/gmane.comp.handhelds.openembedded/58530'>here</ulink>.
+        </para>
+    </section>
+
+    <section id='migration-1.5-removal-of-package-manager-database-within-image-recipes'>
+        <title>Removal of Package Manager Database Within Image Recipes</title>
+
+        <para>
+            The image <filename>core-image-minimal</filename> no longer adds
+            <filename>remove_packaging_data_files</filename> to
+            <link linkend='var-ROOTFS_POSTPROCESS_COMMAND'><filename>ROOTFS_POSTPROCESS_COMMAND</filename></link>.
+            This addition is now handled automatically when "package-management"
+            is not in
+            <link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>.
+            If you have custom image recipes that make this addition,
+            you should remove the lines, as they are not needed and might
+            interfere with correct operation of postinstall scripts.
+        </para>
+    </section>
+
+    <section id='migration-1.5-images-now-rebuild-only-on-changes-instead-of-every-time'>
+        <title>Images Now Rebuild Only on Changes Instead of Every Time</title>
+
+        <para>
+            The <filename>do_rootfs</filename> and other related image
+            construction tasks are no longer marked as "nostamp".
+            Consequently, they will only be re-executed when their inputs have
+            changed.
+            Previous versions of the OpenEmbedded build system always rebuilt
+            the image when requested rather when necessary.
+        </para>
+    </section>
+
+    <section id='migration-1.5-task-recipes'>
+        <title>Task Recipes</title>
+
+        <para>
+            The previously deprecated <filename>task.bbclass</filename> has
+            now been dropped.
+            For recipes that previously inherited from this task, you should
+            rename them from <filename>task-*</filename> to
+            <filename>packagegroup-*</filename> and inherit packagegroup
+            instead.
+        </para>
+
+        <para>
+            For more information, see the
+            "<link linkend='ref-classes-packagegroup'>Package Groups - <filename>packagegroup.bbclass</filename></link>"
+            section.
+        </para>
+    </section>
+
+    <section id='migration-1.5-busybox'>
+        <title>BusyBox</title>
+
+        <para>
+            By default, we now split BusyBox into two binaries:
+            one that is suid root for those components that need it, and
+            another for the rest of the components.
+            Splitting BusyBox allows for optimization that eliminates the
+            <filename>tinylogin</filename> recipe as recommended by upstream.
+            You can disable this split by setting
+            <link linkend='var-BUSYBOX_SPLIT_SUID'><filename>BUSYBOX_SPLIT_SUID</filename></link>
+            to "0".
+        </para>
+    </section>
+
+    <section id='migration-1.5-automated-image-testing'>
+        <title>Automated Image Testing</title>
+
+        <para>
+            A new automated image testing framework has been added
+            through the
+            <link linkend='ref-classes-testimage'><filename>testimage*.bbclass</filename></link>
+            class.
+            This framework replaces the older
+            <filename>imagetest-qemu</filename> framework.
+        </para>
+
+        <para>
+            You can learn more about performing automated image tests in the
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing'>Performing Automated Runtime Testing</ulink>"
+            section.
+        </para>
+    </section>
+
+    <section id='migration-1.5-build-history'>
+        <title>Build History</title>
+
+        <para>
+            Following are changes to Build History:
+            <itemizedlist>
+                <listitem><para>
+                     Installed package sizes:
+                     <filename>installed-package-sizes.txt</filename> for an
+                     image now records the size of the files installed by each
+                     package instead of the size of each compressed package
+                     archive file.</para></listitem>
+                <listitem><para>
+                    The dependency graphs (<filename>depends*.dot</filename>)
+                    now use the actual package names instead of replacing
+                    dashes, dots and plus signs with underscores.
+                    </para></listitem>
+                <listitem><para>
+                    The <filename>buildhistory-diff</filename> and
+                    <filename>buildhistory-collect-srcrevs</filename>
+                    utilities have improved command-line handling.
+                    Use the <filename>&dash;&dash;help</filename> option for
+                    each utility for more information on the new syntax.
+                    </para></listitem>
+            </itemizedlist>
+            For more information on Build History, see the
+            "<link linkend='maintaining-build-output-quality'>Maintaining Build Output Quality</link>"
+            section.
+        </para>
+    </section>
+
+    <section id='migration-1.5-udev'>
+        <title><filename>udev</filename></title>
+
+        <para>
+            Following are changes to <filename>udev</filename>:
+            <itemizedlist>
+                <listitem><para>
+                    <filename>udev</filename> no longer brings in
+                    <filename>udev-extraconf</filename> automatically
+                    through
+                    <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>,
+                    since this was originally intended to be optional.
+                    If you need the extra rules, then add
+                    <filename>udev-extraconf</filename> to your image.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>udev</filename> no longer brings in
+                    <filename>pciutils-ids</filename> or
+                    <filename>usbutils-ids</filename> through
+                    <filename>RRECOMMENDS</filename>.
+                    These are not needed by <filename>udev</filename> itself
+                    and removing them saves around 350KB.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='removed-renamed-recipes'>
+        <title>Removed and Renamed Recipes</title>
+
+        <itemizedlist>
+            <listitem><para>
+                The <filename>linux-yocto</filename> 3.2 kernel has been
+                removed.</para></listitem>
+            <listitem><para>
+                <filename>libtool-nativesdk</filename> has been renamed to
+                <filename>nativesdk-libtool</filename>.</para></listitem>
+            <listitem><para>
+                <filename>tinylogin</filename> has been removed.
+                It has been replaced by a suid portion of Busybox.
+                See the
+                "<link linkend='migration-1.5-busybox'>BusyBox</link>" section
+                for more information.</para></listitem>
+            <listitem><para>
+                <filename>external-python-tarball</filename> has been renamed
+                to <filename>buildtools-tarball</filename>.
+                </para></listitem>
+            <listitem><para>
+                <filename>web-webkit</filename> has been removed.
+                It has been functionally replaced by
+                <filename>midori</filename>.</para></listitem>
+            <listitem><para>
+                <filename>imake</filename> has been removed.
+                It is no longer needed by any other recipe.
+                </para></listitem>
+            <listitem><para>
+                <filename>transfig-native</filename> has been removed.
+                It is no longer needed by any other recipe.
+                </para></listitem>
+            <listitem><para>
+                <filename>anjuta-remote-run</filename> has been removed.
+                Anjuta IDE integration has not been officially supported for
+                several releases.</para></listitem>
+        </itemizedlist>
+    </section>
+
+    <section id='migration-1.5-other-changes'>
+        <title>Other Changes</title>
+
+        <para>
+            Following is a list of short entries describing other changes:
+            <itemizedlist>
+                <listitem><para>
+                    <filename>run-postinsts</filename>: Make this generic.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>base-files</filename>: Remove the unnecessary
+                    <filename>media/xxx</filename> directories.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>alsa-state</filename>: Provide an empty
+                    <filename>asound.conf</filename> by default.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>classes/image</filename>: Ensure
+                    <link linkend='var-BAD_RECOMMENDATIONS'><filename>BAD_RECOMMENDATIONS</filename></link>
+                    supports pre-renamed package names.</para></listitem>
+                <listitem><para>
+                    <filename>classes/rootfs_rpm</filename>: Implement
+                    <link linkend='var-BAD_RECOMMENDATIONS'><filename>BAD_RECOMMENDATIONS</filename></link>
+                    for RPM.</para></listitem>
+                <listitem><para>
+                    <filename>systemd</filename>: Remove
+                    <filename>systemd_unitdir</filename> if
+                    <filename>systemd</filename> is not in
+                    <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>systemd</filename>: Remove
+                    <filename>init.d</filename> dir if
+                    <filename>systemd</filename> unit file is present and
+                    <filename>sysvinit</filename> is not a distro feature.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>libpam</filename>: Deny all services for the
+                    <filename>OTHER</filename> entries.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>image.bbclass</filename>: Move
+                    <filename>runtime_mapping_rename</filename> to avoid
+                    conflict with <filename>multilib</filename>.
+                    See
+                    <ulink url='https://bugzilla.yoctoproject.org/show_bug.cgi?id=4993'><filename>YOCTO #4993</filename></ulink>
+                    in Bugzilla for more information.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>linux-dtb</filename>: Use kernel build system
+                    to generate the <filename>dtb</filename> files.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>kern-tools</filename>: Switch from guilt to
+                    new <filename>kgit-s2q</filename> tool.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+</section>
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/ref-manual/ref-bitbake.xml b/documentation/ref-manual/ref-bitbake.xml
new file mode 100644
index 0000000..e24ea45
--- /dev/null
+++ b/documentation/ref-manual/ref-bitbake.xml
@@ -0,0 +1,432 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='ref-bitbake'>
+
+    <title>BitBake</title>
+
+    <para>
+        BitBake is a program written in Python that interprets the
+        <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink> used by
+        the OpenEmbedded build system.
+        At some point, developers wonder what actually happens when you enter:
+        <literallayout class='monospaced'>
+     $ bitbake core-image-sato
+        </literallayout>
+    </para>
+
+    <para>
+        This chapter provides an overview of what happens behind the scenes from BitBake's perspective.
+    </para>
+
+    <note>
+        BitBake strives to be a generic "task" executor that is capable of handling complex dependency relationships.
+        As such, it has no real knowledge of what the tasks being executed actually do.
+        BitBake just considers a list of tasks with dependencies and handles
+        <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+        consisting of variables in a certain format that get passed to the tasks.
+    </note>
+
+    <section id='ref-bitbake-parsing'>
+        <title>Parsing</title>
+
+        <para>
+            BitBake parses configuration files, classes, and <filename>.bb</filename> files.
+        </para>
+
+        <para>
+            The first thing BitBake does is look for the <filename>bitbake.conf</filename> file.
+            This file resides in the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+            within the <filename>meta/conf/</filename> directory.
+            BitBake finds it by examining its
+            <link linkend='var-BBPATH'><filename>BBPATH</filename></link> environment
+            variable and looking for the <filename>meta/conf/</filename>
+            directory.
+        </para>
+
+        <para>
+            The <filename>bitbake.conf</filename> file lists other configuration
+            files to include from a <filename>conf/</filename>
+            directory below the directories listed in <filename>BBPATH</filename>.
+            In general, the most important configuration file from a user's perspective
+            is <filename>local.conf</filename>, which contains a user's customized
+            settings for the OpenEmbedded build environment.
+            Other notable configuration files are the distribution
+            configuration file (set by the
+            <filename><link linkend='var-DISTRO'>DISTRO</link></filename> variable)
+            and the machine configuration file
+            (set by the
+            <filename><link linkend='var-MACHINE'>MACHINE</link></filename> variable).
+            The <filename>DISTRO</filename> and <filename>MACHINE</filename> BitBake environment
+            variables are both usually set in
+            the <filename>local.conf</filename> file.
+            Valid distribution
+            configuration files are available in the <filename>meta/conf/distro/</filename> directory
+            and valid machine configuration
+            files in the <filename>meta/conf/machine/</filename> directory.
+            Within the <filename>meta/conf/machine/include/</filename>
+            directory are various <filename>tune-*.inc</filename> configuration files that provide common
+            "tuning" settings specific to and shared between particular architectures and machines.
+        </para>
+
+        <para>
+            After the parsing of the configuration files, some standard classes are included.
+            The <filename>base.bbclass</filename> file is always included.
+            Other classes that are specified in the configuration using the
+            <filename><link linkend='var-INHERIT'>INHERIT</link></filename>
+            variable are also included.
+            Class files are searched for in a <filename>classes</filename> subdirectory
+            under the paths in <filename>BBPATH</filename> in the same way as
+            configuration files.
+        </para>
+
+        <para>
+            After classes are included, the variable
+            <filename><link linkend='var-BBFILES'>BBFILES</link></filename>
+            is set, usually in
+            <filename>local.conf</filename>, and defines the list of places to search for
+            <filename>.bb</filename> files.
+            By default, the <filename>BBFILES</filename> variable specifies the
+            <filename>meta/recipes-*/</filename> directory within Poky.
+            Adding extra content to <filename>BBFILES</filename> is best achieved through the use of
+            BitBake layers as described in the
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and
+            Creating Layers</ulink>" section of the Yocto Project Development Manual.
+        </para>
+
+        <para>
+            BitBake parses each <filename>.bb</filename> file in <filename>BBFILES</filename> and
+            stores the values of various variables.
+            In summary, for each <filename>.bb</filename>
+            file the configuration plus the base class of variables are set, followed
+            by the data in the <filename>.bb</filename> file
+            itself, followed by any inherit commands that
+            <filename>.bb</filename> file might contain.
+        </para>
+
+        <para>
+            Because parsing <filename>.bb</filename> files is a time
+            consuming process, a cache is kept to speed up subsequent parsing.
+            This cache is invalid if the timestamp of the <filename>.bb</filename>
+            file itself changes, or if the timestamps of any of the include,
+            configuration files or class files on which the
+            <filename>.bb</filename> file depends change.
+        </para>
+    </section>
+
+    <section id='ref-bitbake-providers'>
+        <title>Preferences and Providers</title>
+
+        <para>
+            Once all the <filename>.bb</filename> files have been
+            parsed, BitBake starts to build the target (<filename>core-image-sato</filename>
+            in the previous section's example) and looks for providers of that target.
+            Once a provider is selected, BitBake resolves all the dependencies for
+            the target.
+            In the case of <filename>core-image-sato</filename>, it would lead to
+            <filename>packagegroup-core-x11-sato</filename>,
+            which in turn leads to recipes like <filename>matchbox-terminal</filename>,
+            <filename>pcmanfm</filename> and <filename>gthumb</filename>.
+            These recipes in turn depend on <filename>eglibc</filename> and the toolchain.
+        </para>
+
+        <para>
+            Sometimes a target might have multiple providers.
+            A common example is "virtual/kernel", which is provided by each kernel package.
+            Each machine often selects the best kernel provider by using a line similar to the
+            following in the machine configuration file:
+        </para>
+
+        <literallayout class='monospaced'>
+     PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
+        </literallayout>
+
+        <para>
+            The default <filename><link linkend='var-PREFERRED_PROVIDER'>PREFERRED_PROVIDER</link></filename>
+            is the provider with the same name as the target.
+        </para>
+
+        <para>
+            Understanding how providers are chosen is made complicated by the fact
+            that multiple versions might exist.
+            BitBake defaults to the highest version of a provider.
+            Version comparisons are made using the same method as Debian.
+            You can use the
+            <filename><link linkend='var-PREFERRED_VERSION'>PREFERRED_VERSION</link></filename>
+            variable to specify a particular version (usually in the distro configuration).
+            You can influence the order by using the
+            <filename><link linkend='var-DEFAULT_PREFERENCE'>DEFAULT_PREFERENCE</link></filename>
+            variable.
+            By default, files have a preference of "0".
+            Setting the <filename>DEFAULT_PREFERENCE</filename> to "-1" makes the
+            package unlikely to be used unless it is explicitly referenced.
+            Setting the <filename>DEFAULT_PREFERENCE</filename> to "1" makes it likely the package is used.
+            <filename>PREFERRED_VERSION</filename> overrides any <filename>DEFAULT_PREFERENCE</filename> setting.
+            <filename>DEFAULT_PREFERENCE</filename> is often used to mark newer and more experimental package
+            versions until they have undergone sufficient testing to be considered stable.
+        </para>
+
+        <para>
+            In summary, BitBake has created a list of providers, which is prioritized, for each target.
+        </para>
+    </section>
+
+    <section id='ref-bitbake-dependencies'>
+        <title>Dependencies</title>
+
+        <para>
+            Each target BitBake builds consists of multiple tasks such as
+            <filename>fetch</filename>, <filename>unpack</filename>,
+            <filename>patch</filename>, <filename>configure</filename>,
+            and <filename>compile</filename>.
+            For best performance on multi-core systems, BitBake considers each task as an independent
+            entity with its own set of dependencies.
+        </para>
+
+        <para>
+            Dependencies are defined through several variables.
+            You can find information about variables BitBake uses in the BitBake documentation,
+            which is found in the <filename>bitbake/doc/manual</filename> directory within the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+            At a basic level, it is sufficient to know that BitBake uses the
+            <filename><link linkend='var-DEPENDS'>DEPENDS</link></filename> and
+            <filename><link linkend='var-RDEPENDS'>RDEPENDS</link></filename> variables when
+            calculating dependencies.
+        </para>
+    </section>
+
+    <section id='ref-bitbake-tasklist'>
+        <title>The Task List</title>
+
+        <para>
+            Based on the generated list of providers and the dependency information,
+            BitBake can now calculate exactly what tasks it needs to run and in what
+            order it needs to run them.
+            The build now starts with BitBake forking off threads up to the limit set in the
+            <filename><link linkend='var-BB_NUMBER_THREADS'>BB_NUMBER_THREADS</link></filename> variable.
+            BitBake continues to fork threads as long as there are tasks ready to run,
+            those tasks have all their dependencies met, and the thread threshold has not been
+            exceeded.
+        </para>
+
+        <para>
+            It is worth noting that you can greatly speed up the build time by properly setting
+            the <filename>BB_NUMBER_THREADS</filename> variable.
+            See the
+            "<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>"
+            section in the Yocto Project Quick Start for more information.
+        </para>
+
+        <para>
+            As each task completes, a timestamp is written to the directory specified by the
+            <filename><link linkend='var-STAMP'>STAMP</link></filename> variable.
+            On subsequent runs, BitBake looks within the <filename>build/tmp/stamps</filename>
+            directory and does not rerun
+            tasks that are already completed unless a timestamp is found to be invalid.
+            Currently, invalid timestamps are only considered on a per
+            <filename>.bb</filename> file basis.
+            So, for example, if the configure stamp has a timestamp greater than the
+            compile timestamp for a given target, then the compile task would rerun.
+            Running the compile task again, however, has no effect on other providers
+            that depend on that target.
+            This behavior could change or become configurable in future versions of BitBake.
+        </para>
+
+        <note>
+            Some tasks are marked as "nostamp" tasks.
+            No timestamp file is created when these tasks are run.
+            Consequently, "nostamp" tasks are always rerun.
+        </note>
+    </section>
+
+    <section id='ref-bitbake-runtask'>
+        <title>Running a Task</title>
+
+        <para>
+            Tasks can either be a shell task or a Python task.
+            For shell tasks, BitBake writes a shell script to
+            <filename>${WORKDIR}/temp/run.do_taskname.pid</filename> and then executes the script.
+            The generated shell script contains all the exported variables, and the shell functions
+            with all variables expanded.
+            Output from the shell script goes to the file <filename>${WORKDIR}/temp/log.do_taskname.pid</filename>.
+            Looking at the expanded shell functions in the run file and the output in the log files
+            is a useful debugging technique.
+        </para>
+
+        <para>
+            For Python tasks, BitBake executes the task internally and logs information to the
+            controlling terminal.
+            Future versions of BitBake will write the functions to files similar to the way
+            shell tasks are handled.
+            Logging will be handled in a way similar to shell tasks as well.
+        </para>
+
+        <para>
+            Once all the tasks have been completed BitBake exits.
+        </para>
+
+        <para>
+            When running a task, BitBake tightly controls the execution environment
+            of the build tasks to make sure unwanted contamination from the build machine
+            cannot influence the build.
+            Consequently, if you do want something to get passed into the build
+            task's environment, you must take a few steps:
+            <orderedlist>
+                <listitem><para>Tell BitBake to load what you want from the environment
+                    into the data store.
+                    You can do so through the <filename>BB_ENV_EXTRAWHITE</filename>
+                    variable.
+                    For example, assume you want to prevent the build system from
+                    accessing your <filename>$HOME/.ccache</filename> directory.
+                    The following command tells BitBake to load
+                    <filename>CCACHE_DIR</filename> from the environment into the data
+                    store:
+                    <literallayout class='monospaced'>
+     export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE CCACHE_DIR"
+                    </literallayout></para></listitem>
+                <listitem><para>Tell BitBake to export what you have loaded into the
+                    environment store to the task environment of every running task.
+                    Loading something from the environment into the data store
+                    (previous step) only makes it available in the datastore.
+                    To export it to the task environment of every running task,
+                    use a command similar to the following in your
+                    <filename>local.conf</filename> or distro configuration file:
+                    <literallayout class='monospaced'>
+     export CCACHE_DIR
+                    </literallayout></para></listitem>
+            </orderedlist>
+        </para>
+
+        <note>
+            A side effect of the previous steps is that BitBake records the variable
+            as a dependency of the build process in things like the shared state
+            checksums.
+            If doing so results in unnecessary rebuilds of tasks, you can whitelist the
+            variable so that the shared state code ignores the dependency when it creates
+            checksums.
+            For information on this process, see the <filename>BB_HASHBASE_WHITELIST</filename>
+            example in the "<link linkend='checksums'>Checksums (Signatures)</link>" section.
+        </note>
+    </section>
+
+    <section id='ref-bitbake-commandline'>
+        <title>BitBake Command Line</title>
+
+        <para>
+            Following is the BitBake help output:
+        </para>
+
+        <screen>
+$ bitbake --help
+Usage: bitbake [options] [recipename/target ...]
+
+    Executes the specified task (default is 'build') for a given set of target recipes (.bb files).
+    It is assumed there is a conf/bblayers.conf available in cwd or in BBPATH which
+    will provide the layer, BBFILES and other configuration information.
+
+Options:
+  --version             show program's version number and exit
+  -h, --help            show this help message and exit
+  -b BUILDFILE, --buildfile=BUILDFILE
+                        Execute tasks from a specific .bb recipe directly.
+                        WARNING: Does not handle any dependencies from other
+                        recipes.
+  -k, --continue        Continue as much as possible after an error. While the
+                        target that failed and anything depending on it cannot
+                        be built, as much as possible will be built before
+                        stopping.
+  -a, --tryaltconfigs   Continue with builds by trying to use alternative
+                        providers where possible.
+  -f, --force           Force the specified targets/task to run (invalidating
+                        any existing stamp file).
+  -c CMD, --cmd=CMD     Specify the task to execute. The exact options
+                        available depend on the metadata. Some examples might
+                        be 'compile' or 'populate_sysroot' or 'listtasks' may
+                        give a list of the tasks available.
+  -C INVALIDATE_STAMP, --clear-stamp=INVALIDATE_STAMP
+                        Invalidate the stamp for the specified task such as
+                        'compile' and then run the default task for the
+                        specified target(s).
+  -r PREFILE, --read=PREFILE
+                        Read the specified file before bitbake.conf.
+  -R POSTFILE, --postread=POSTFILE
+                        Read the specified file after bitbake.conf.
+  -v, --verbose         Output more log message data to the terminal.
+  -D, --debug           Increase the debug level. You can specify this more
+                        than once.
+  -n, --dry-run         Don't execute, just go through the motions.
+  -S, --dump-signatures
+                        Don't execute, just dump out the signature
+                        construction information.
+  -p, --parse-only      Quit after parsing the BB recipes.
+  -s, --show-versions   Show current and preferred versions of all recipes.
+  -e, --environment     Show the global or per-package environment complete
+                        with information about where variables were
+                        set/changed.
+  -g, --graphviz        Save dependency tree information for the specified
+                        targets in the dot syntax.
+  -I EXTRA_ASSUME_PROVIDED, --ignore-deps=EXTRA_ASSUME_PROVIDED
+                        Assume these dependencies don't exist and are already
+                        provided (equivalent to ASSUME_PROVIDED). Useful to
+                        make dependency graphs more appealing
+  -l DEBUG_DOMAINS, --log-domains=DEBUG_DOMAINS
+                        Show debug logging for the specified logging domains
+  -P, --profile         Profile the command and save reports.
+  -u UI, --ui=UI        The user interface to use (e.g. knotty, hob, depexp).
+  -t SERVERTYPE, --servertype=SERVERTYPE
+                        Choose which server to use, process or xmlrpc.
+  --revisions-changed   Set the exit code depending on whether upstream
+                        floating revisions have changed or not.
+  --server-only         Run bitbake without a UI, only starting a server
+                        (cooker) process.
+  -B BIND, --bind=BIND  The name/address for the bitbake server to bind to.
+  --no-setscene         Do not run any setscene tasks. sstate will be ignored
+                        and everything needed, built.
+  --remote-server=REMOTE_SERVER
+                        Connect to the specified server.
+  -m, --kill-server     Terminate the remote server.
+  --observe-only        Connect to a server as an observing-only client.
+        </screen>
+    </section>
+
+    <section id='ref-bitbake-fetchers'>
+        <title>Fetchers</title>
+
+        <para>
+            BitBake also contains a set of "fetcher" modules that allow
+            retrieval of source code from various types of sources.
+            For example, BitBake can get source code from a disk with the metadata, from websites,
+            from remote shell accounts, or from Source Code Management (SCM) systems
+            like <filename>cvs/subversion/git</filename>.
+        </para>
+
+        <para>
+            Fetchers are usually triggered by entries in
+            <filename><link linkend='var-SRC_URI'>SRC_URI</link></filename>.
+            You can find information about the options and formats of entries for specific
+            fetchers in the BitBake manual located in the
+            <filename>bitbake/doc/manual</filename> directory of the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+        </para>
+
+        <para>
+            One useful feature for certain Source Code Manager (SCM) fetchers is the ability to
+            "auto-update" when the upstream SCM changes version.
+            Since this ability requires certain functionality from the SCM, not all
+            systems support it.
+            Currently Subversion, Bazaar and to a limited extent, Git support the ability to "auto-update".
+            This feature works using the <filename><link linkend='var-SRCREV'>SRCREV</link></filename>
+            variable.
+            See the
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-appdev-srcrev'>Using an External SCM</ulink>" section
+            in the Yocto Project Development Manual for more information.
+        </para>
+
+    </section>
+
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4 spell spelllang=en_gb
+-->
diff --git a/documentation/ref-manual/ref-classes.xml b/documentation/ref-manual/ref-classes.xml
new file mode 100644
index 0000000..27edfde
--- /dev/null
+++ b/documentation/ref-manual/ref-classes.xml
@@ -0,0 +1,1104 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='ref-classes'>
+<title>Classes</title>
+
+<para>
+    Class files are used to abstract common functionality and share it amongst multiple
+    <filename>.bb</filename> files.
+    Any <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink> usually
+    found in a <filename>.bb</filename> file can also be placed in a class
+    file.
+    Class files are identified by the extension <filename>.bbclass</filename> and are usually placed
+    in a <filename>classes/</filename> directory beneath the
+    <filename>meta*/</filename> directory found in the
+    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+    Class files can also be pointed to by
+    <link linkend='var-BUILDDIR'><filename>BUILDDIR</filename></link>
+    (e.g. <filename>build/</filename>) in the same way as
+    <filename>.conf</filename> files in the <filename>conf</filename> directory.
+    Class files are searched for in <link linkend='var-BBPATH'><filename>BBPATH</filename></link>
+    using the same method by which <filename>.conf</filename> files are searched.
+</para>
+
+<para>
+    In most cases inheriting the class is enough to enable its features, although
+    for some classes you might need to set variables or override some of the
+    default behavior.
+</para>
+
+<para>
+    This chapter discusses only the most useful and important classes.
+        Other classes do exist within the <filename>meta/classes</filename>
+        directory in the
+        <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+        You can reference the <filename>.bbclass</filename> files directly
+        for more information.
+</para>
+
+<section id='ref-classes-base'>
+    <title>The base Class - <filename>base.bbclass</filename></title>
+
+    <para>
+        The base class is special in that every <filename>.bb</filename>
+        file inherits it automatically.
+        This class contains definitions for standard basic
+        tasks such as fetching, unpacking, configuring (empty by default), compiling
+        (runs any <filename>Makefile</filename> present), installing (empty by default) and packaging
+        (empty by default).
+        These classes are often overridden or extended by other classes
+        such as <filename>autotools.bbclass</filename> or <filename>package.bbclass</filename>.
+        The class also contains some commonly used functions such as <filename>oe_runmake</filename>.
+    </para>
+</section>
+
+<section id='ref-classes-autotools'>
+    <title>Autotooled Packages - <filename>autotools.bbclass</filename></title>
+
+    <para>
+        Autotools (<filename>autoconf</filename>, <filename>automake</filename>,
+        and <filename>libtool</filename>) bring standardization.
+        This class defines a set of tasks (configure, compile etc.) that
+        work for all Autotooled packages.
+        It should usually be enough to define a few standard variables
+        and then simply <filename>inherit autotools</filename>.
+        This class can also work with software that emulates Autotools.
+        For more information, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#usingpoky-extend-addpkg-autotools'>Autotooled Package</ulink>"
+        section in the Yocto Project Development Manual.
+    </para>
+
+    <para>
+        It's useful to have some idea of how the tasks defined by this class work
+        and what they do behind the scenes.
+        <itemizedlist>
+            <listitem><para><filename>do_configure</filename> &dash; Regenerates the
+                configure script (using <filename>autoreconf</filename>) and then launches it
+                with a standard set of arguments used during cross-compilation.
+                You can pass additional parameters to <filename>configure</filename> through the
+                <filename><link linkend='var-EXTRA_OECONF'>EXTRA_OECONF</link></filename> variable.
+                </para></listitem>
+            <listitem><para><filename>do_compile</filename> &dash; Runs <filename>make</filename> with
+                arguments that specify the compiler and linker.
+                You can pass additional arguments through
+                the <filename><link linkend='var-EXTRA_OEMAKE'>EXTRA_OEMAKE</link></filename> variable.
+                </para></listitem>
+            <listitem><para><filename>do_install</filename> &dash; Runs <filename>make install</filename>
+                and passes in
+                <filename>${</filename><link linkend='var-D'><filename>D</filename></link><filename>}</filename>
+                as <filename>DESTDIR</filename>.
+                </para></listitem>
+        </itemizedlist>
+    </para>
+</section>
+
+<section id='ref-classes-update-alternatives'>
+    <title>Alternatives - <filename>update-alternatives.bbclass</filename></title>
+
+    <para>
+        This class helps the alternatives system when multiple sources provide
+        the same command.
+        This situation occurs when several programs that have the same or
+        similar function are installed with the same name.
+        For example, the <filename>ar</filename> command is available from the
+        <filename>busybox</filename>, <filename>binutils</filename> and
+        <filename>elfutils</filename> packages.
+        The <filename>update-alternatives.bbclass</filename> class handles
+        renaming the binaries so that multiple packages can be installed
+        without conflicts.
+        The <filename>ar</filename> command still works regardless of which
+        packages are installed or subsequently removed.
+        The class renames the conflicting binary in each package and symlinks
+        the highest priority binary during installation or removal of packages.
+    </para>
+
+    <para>
+        To use this class, you need to define a number of variables:
+        <itemizedlist>
+            <listitem><para><link linkend='var-ALTERNATIVE'><filename>ALTERNATIVE</filename></link>
+                </para></listitem>
+            <listitem><para><link linkend='var-ALTERNATIVE_LINK_NAME'><filename>ALTERNATIVE_LINK_NAME</filename></link>
+                </para></listitem>
+            <listitem><para><link linkend='var-ALTERNATIVE_TARGET'><filename>ALTERNATIVE_TARGET</filename></link>
+                </para></listitem>
+            <listitem><para><link linkend='var-ALTERNATIVE_PRIORITY'><filename>ALTERNATIVE_PRIORITY</filename></link>
+                </para></listitem>
+        </itemizedlist>
+        These variables list alternative commands needed by a package,
+        provide pathnames for links, default links for targets, and
+        so forth.
+        For details on how to use this class, see the comments in the
+        <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta/classes/update-alternatives.bbclass'><filename>update-alternatives.bbclass</filename></ulink>.
+    </para>
+
+    <note>
+        You can use the <filename>update-alternatives</filename> command
+        directly in your recipes.
+        However, this class simplifies things in most cases.
+    </note>
+</section>
+
+<section id='ref-classes-update-rc.d'>
+    <title>Initscripts - <filename>update-rc.d.bbclass</filename></title>
+
+    <para>
+        This class uses <filename>update-rc.d</filename> to safely install an
+        initialization script on behalf of the package.
+        The OpenEmbedded build system takes care of details such as making sure the script is stopped before
+        a package is removed and started when the package is installed.
+        Three variables control this class:
+        <filename><link linkend='var-INITSCRIPT_PACKAGES'>INITSCRIPT_PACKAGES</link></filename>,
+        <filename><link linkend='var-INITSCRIPT_NAME'>INITSCRIPT_NAME</link></filename> and
+        <filename><link linkend='var-INITSCRIPT_PARAMS'>INITSCRIPT_PARAMS</link></filename>.
+        See the variable links for details.
+    </para>
+</section>
+
+<section id='ref-classes-binconfig'>
+    <title><filename>binconfig.bbclass</filename></title>
+
+    <para>
+        This class helps to correct paths in shell scripts.
+    </para>
+
+    <para>
+        Before <filename>pkg-config</filename> had become widespread, libraries
+        shipped shell scripts to give information about the libraries and
+        include paths needed to build software (usually named
+        <filename>LIBNAME-config</filename>).
+        This class assists any recipe using such scripts.
+    </para>
+
+    <para>
+        During staging, the OpenEmbedded build system installs such scripts
+        into the <filename>sysroots/</filename> directory.
+        Inheriting this class results in all paths in these scripts being
+        changed to point into the <filename>sysroots/</filename> directory so
+        that all builds that use the script use the correct directories
+        for the cross compiling layout.
+        See the
+        <link linkend='var-BINCONFIG_GLOB'><filename>BINCONFIG_GLOB</filename></link>
+        variable for more information.
+    </para>
+</section>
+
+<section id='ref-classes-debian'>
+    <title>Debian Renaming - <filename>debian.bbclass</filename></title>
+
+    <para>
+        This class renames packages so that they follow the Debian naming
+        policy (i.e. <filename>eglibc</filename> becomes <filename>libc6</filename>
+        and <filename>eglibc-devel</filename> becomes <filename>libc6-dev</filename>.)
+    </para>
+</section>
+
+<section id='ref-classes-pkgconfig'>
+    <title>Pkg-config - <filename>pkgconfig.bbclass</filename></title>
+
+    <para>
+        <filename>pkg-config</filename> provides a standard way to get
+        header and library information.
+        This class aims to smooth integration of
+        <filename>pkg-config</filename> into libraries that use it.
+    </para>
+
+    <para>
+        During staging, BitBake installs <filename>pkg-config</filename> data into the
+        <filename>sysroots/</filename> directory.
+        By making use of sysroot functionality within <filename>pkg-config</filename>,
+        this class no longer has to manipulate the files.
+    </para>
+</section>
+
+<section id='ref-classes-archiver'>
+    <title>Archiving Sources - <filename>archive*.bbclass</filename></title>
+
+    <para>
+        Many software licenses require that source code and other materials be
+        released with the binaries.
+        To help with that task, the following classes are provided:
+        <itemizedlist>
+            <listitem><filename>archive-original-sources.bbclass</filename></listitem>
+            <listitem><filename>archive-patched-sources.bbclass</filename></listitem>
+            <listitem><filename>archive-configured-sources.bbclass</filename></listitem>
+            <listitem><filename>archiver.bbclass</filename></listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        For more details on the source archiver, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle'>Maintaining Open Source License Compliance During Your Product's Lifecycle</ulink>"
+        section in the Yocto Project Development Manual.
+    </para>
+</section>
+
+<section id='ref-classes-perl'>
+    <title>Perl Modules - <filename>cpan.bbclass</filename></title>
+
+    <para>
+        Recipes for Perl modules are simple.
+        These recipes usually only need to point to the source's archive and then inherit the
+        proper <filename>.bbclass</filename> file.
+        Building is split into two methods depending on which method the module authors used.
+        <itemizedlist>
+            <listitem><para>Modules that use old
+                <filename>Makefile.PL</filename>-based build system require
+                <filename>cpan.bbclass</filename> in their recipes.
+                </para></listitem>
+            <listitem><para>Modules that use
+                <filename>Build.PL</filename>-based build system require
+                using <filename>cpan_build.bbclass</filename> in their recipes.
+                </para></listitem>
+        </itemizedlist>
+    </para>
+</section>
+
+<section id='ref-classes-distutils'>
+    <title>Python Extensions - <filename>distutils.bbclass</filename></title>
+
+    <para>
+        Recipes for Python extensions are simple.
+        These recipes usually only need to point to the source's archive and then inherit
+        the proper <filename>.bbclass</filename> file.
+        Building is split into two methods depending on which method the module authors used.
+        <itemizedlist>
+            <listitem><para>Extensions that use an Autotools-based build system
+                require Autotools and
+                <filename>distutils</filename>-based
+                <filename>.bbclasse</filename> files in their recipes.
+                </para></listitem>
+            <listitem><para>Extensions that use
+                <filename>distutils</filename>-based build systems require
+                <filename>distutils.bbclass</filename> in their recipes.
+                </para></listitem>
+        </itemizedlist>
+    </para>
+</section>
+
+<section id='ref-classes-devshell'>
+    <title>Developer Shell - <filename>devshell.bbclass</filename></title>
+
+    <para>
+        This class adds the <filename>devshell</filename> task.
+        Distribution policy dictates whether to include this class.
+        See the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-appdev-devshell'>Using a Development Shell</ulink>" section
+        in the Yocto Project Development Manual for more information about using <filename>devshell</filename>.
+    </para>
+</section>
+
+<section id='ref-classes-packagegroup'>
+    <title>Package Groups - <filename>packagegroup.bbclass</filename></title>
+
+    <para>
+        This class sets default values appropriate for package group recipes (e.g.
+        <filename><link linkend='var-PACKAGES'>PACKAGES</link></filename>,
+        <filename><link linkend='var-PACKAGE_ARCH'>PACKAGE_ARCH</link></filename>,
+        <filename><link linkend='var-ALLOW_EMPTY'>ALLOW_EMPTY</link></filename>,
+        and so forth).
+        It is highly recommended that all package group recipes inherit this class.
+    </para>
+    <para>
+        For information on how to use this class, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#usingpoky-extend-customimage-customtasks'>Customizing Images Using Custom Package Groups</ulink>"
+        section in the Yocto Project Development Manual.
+    </para>
+    <para>
+        Previously, this class was named <filename>task.bbclass</filename>.
+    </para>
+</section>
+
+
+<section id='ref-classes-package'>
+    <title>Packaging - <filename>package*.bbclass</filename></title>
+
+    <para>
+        The packaging classes add support for generating packages from a build's
+        output.
+        The core generic functionality is in <filename>package.bbclass</filename>.
+        The code specific to particular package types is contained in various sub-classes such as
+        <filename>package_deb.bbclass</filename>, <filename>package_ipk.bbclass</filename>,
+        and <filename>package_rpm.bbclass</filename>.
+        Most users will want one or more of these classes.
+    </para>
+
+    <para>
+        You can control the list of resulting package formats by using the
+        <filename><link linkend='var-PACKAGE_CLASSES'>PACKAGE_CLASSES</link></filename>
+        variable defined in the <filename>local.conf</filename> configuration file,
+        which is located in the <filename>conf</filename> folder of the
+        <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+        When defining the variable, you can specify one or more package types.
+        Since images are generated from packages, a packaging class is
+        needed to enable image generation.
+        The first class listed in this variable is used for image generation.
+    </para>
+
+    <para>
+        If you take the optional step to set up a repository (package feed)
+        on the development host that can be used by Smart, you can
+        install packages from the feed while you are running the image
+        on the target (i.e. runtime installation of packages).
+        For more information, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#using-runtime-package-management'>Using Runtime Package Management</ulink>"
+         section in the Yocto Project Development Manual.
+    </para>
+
+    <para>
+        The package class you choose can affect build-time performance and has space
+        ramifications.
+        In general, building a package with IPK takes about thirty percent less
+        time as compared to using RPM to build the same or similar package.
+        This comparison takes into account a complete build of the package with
+        all dependencies previously built.
+        The reason for this discrepancy is because the RPM package manager
+        creates and processes more
+        <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink> than the
+        IPK package manager.
+        Consequently, you might consider setting <filename>PACKAGE_CLASSES</filename>
+        to "package_ipk" if you are building smaller systems.
+    </para>
+
+    <para>
+        Before making your decision on package manager, however, you should
+        consider some further things about using RPM:
+        <itemizedlist>
+            <listitem><para>
+                RPM starts to provide more abilities than IPK due to
+                the fact that it processes more metadata.
+                For example, this information includes individual file types,
+                file checksum generation and evaluation on install, sparse file
+                support, conflict detection and resolution for Multilib systems,
+                ACID style upgrade, and repackaging abilities for rollbacks.
+                </para></listitem>
+            <listitem><para>
+                For smaller systems, the extra space used for the Berkley
+                Database and the amount of metadata when using RPM can affect
+                your ability to perform on-device upgrades.
+                </para></listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        You can find additional information on the effects of the package
+        class at these two Yocto Project mailing list links:
+        <itemizedlist>
+            <listitem><para><ulink url='&YOCTO_LISTS_URL;/pipermail/poky/2011-May/006362.html'>
+                https://lists.yoctoproject.org/pipermail/poky/2011-May/006362.html</ulink></para></listitem>
+            <listitem><para><ulink url='&YOCTO_LISTS_URL;/pipermail/poky/2011-May/006363.html'>
+                https://lists.yoctoproject.org/pipermail/poky/2011-May/006363.html</ulink></para></listitem>
+        </itemizedlist>
+    </para>
+</section>
+
+<section id='ref-classes-kernel'>
+    <title>Building Kernels - <filename>kernel.bbclass</filename></title>
+
+    <para>
+        This class handles building Linux kernels.
+        The class contains code to build all kernel trees.
+        All needed headers are staged into the
+        <filename><link linkend='var-STAGING_KERNEL_DIR'>STAGING_KERNEL_DIR</link></filename>
+        directory to allow out-of-tree module builds using <filename>module.bbclass</filename>.
+    </para>
+
+    <para>
+        This means that each built kernel module is packaged separately and inter-module
+        dependencies are created by parsing the <filename>modinfo</filename> output.
+        If all modules are required, then installing the <filename>kernel-modules</filename>
+        package installs all packages with modules and various other kernel packages
+        such as <filename>kernel-vmlinux</filename>.
+    </para>
+
+    <para>
+        Various other classes are used by the kernel and module classes internally including
+        <filename>kernel-arch.bbclass</filename>, <filename>module_strip.bbclass</filename>,
+        <filename>module-base.bbclass</filename>, and <filename>linux-kernel-base.bbclass</filename>.
+    </para>
+</section>
+
+<section id='ref-classes-image'>
+    <title>Creating Images - <filename>image.bbclass</filename> and <filename>rootfs*.bbclass</filename></title>
+
+    <para>
+        These classes add support for creating images in several formats.
+        First, the root filesystem is created from packages using
+        one of the <filename>rootfs_*.bbclass</filename>
+        files (depending on the package format used) and then the image is created.
+        <itemizedlist>
+            <listitem><para>The
+                <filename><link linkend='var-IMAGE_FSTYPES'>IMAGE_FSTYPES</link></filename>
+                variable controls the types of images to generate.
+                </para></listitem>
+            <listitem><para>The
+                <filename><link linkend='var-IMAGE_INSTALL'>IMAGE_INSTALL</link></filename>
+                variable controls the list of packages to install into the
+                image.</para></listitem>
+        </itemizedlist>
+    </para>
+</section>
+
+<section id='ref-classes-sanity'>
+    <title>Host System Sanity Checks - <filename>sanity.bbclass</filename></title>
+
+    <para>
+        This class checks to see if prerequisite software is present on the host system
+        so that users can be notified of potential problems that might affect their build.
+        The class also performs basic user configuration checks from
+        the <filename>local.conf</filename> configuration file to
+        prevent common mistakes that cause build failures.
+        Distribution policy usually determines whether to include this class.
+    </para>
+</section>
+
+<section id='ref-classes-insane'>
+<title><filename>insane.bbclass</filename></title>
+
+    <para>
+        This class adds a step to the package generation process so that
+        output quality assurance checks are generated by the OpenEmbedded
+        build system.
+        A range of checks are performed that check the build's output
+        for common problems that show up during runtime.
+        Distribution policy usually dictates whether to include this class.
+    </para>
+
+    <para>
+        You can configure the sanity checks so that specific test failures
+        either raise a warning or an error message.
+        Typically, failures for new tests generate a warning.
+        Subsequent failures for the same test would then generate an error
+        message once the metadata is in a known and good condition.
+    </para>
+
+    <para>
+        Use the
+        <link linkend='var-WARN_QA'><filename>WARN_QA</filename></link> and
+        <link linkend='var-ERROR_QA'><filename>ERROR_QA</filename></link>
+         variables to control the behavior of
+        these checks at the global level (i.e. in your custom distro
+        configuration).
+        However, to skip one or more checks in recipes, you should use
+        <link linkend='var-INSANE_SKIP'><filename>INSANE_SKIP</filename></link>.
+        For example, to skip the check for symbolic link
+        <filename>.so</filename> files in the main package of a recipe,
+        add the following to the recipe.
+        You need to realize that the package name override, in this example
+        <filename>${PN}</filename>, must be used:
+        <literallayout class='monospaced'>
+     INSANE_SKIP_${PN} += "dev-so"
+        </literallayout>
+        Please keep in mind that the QA checks exist in order to detect real
+        or potential problems in the packaged output.
+        So exercise caution when disabling these checks.
+    </para>
+
+    <para>
+        The following list shows the tests you can list with the
+        <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.
+                It is common for upstream software projects to default to
+                stripping debug symbols for output binaries.
+                In order for debugging to work on the target using
+                <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.
+                </para></listitem>
+            <listitem><para><emphasis><filename>installed-vs-shipped:</filename></emphasis>
+                Reports when files have been installed within
+                <filename>do_install</filename> but have not been included in
+                any package by way of the
+                <link linkend='var-FILES'><filename>FILES</filename></link>
+                variable.
+                Files that do not appear in any package cannot be present in
+                an image later on in the build process.
+                Ideally, all installed files should be packaged or not
+                installed at all.
+                These files can be deleted at the end of
+                <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>libdir:</filename></emphasis>
+                Checks for libraries being installed into incorrect
+                (possibly hardcoded) installation paths.
+                For example, this test will catch recipes that install
+                <filename>/lib/bar.so</filename> when
+                <filename>${base_libdir}</filename> is "lib32".
+                Another example is when recipes install
+                <filename>/usr/lib64/foo.so</filename> when
+                <filename>${libdir}</filename> is "/usr/lib".
+                </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>
+                variable value.
+                Installing the package in this manner can cause errors during
+                packaging.
+                </para></listitem>
+            <listitem><para><emphasis><filename>perm-config:</filename></emphasis>
+                Reports lines in <filename>fs-perms.txt</filename> that have
+                an invalid format.
+                </para></listitem>
+            <listitem><para><emphasis><filename>perm-line:</filename></emphasis>
+                Reports lines in <filename>fs-perms.txt</filename> that have
+                an invalid format.
+                </para></listitem>
+            <listitem><para><emphasis><filename>perm-link:</filename></emphasis>
+                Reports lines in <filename>fs-perms.txt</filename> that
+                specify 'link' where the specified target already exists.
+                </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>pn-overrides:</filename></emphasis>
+                Checks that a recipe does not have a name
+                (<link linkend='var-PN'><filename>PN</filename></link>) value
+                that appears in
+                <link linkend='var-OVERRIDES'><filename>OVERRIDES</filename></link>.
+                If a recipe is named such that its <filename>PN</filename>
+                value matches something already in
+                <filename>OVERRIDES</filename> (e.g. <filename>PN</filename>
+                happens to be the same as
+                <link linkend='var-MACHINE'><filename>MACHINE</filename></link>
+                or
+                <link linkend='var-DISTRO'><filename>DISTRO</filename></link>),
+                it can have unexpected consequences.
+                For example, assignments such as
+                <filename>FILES_${PN} = "xyz"</filename> effectively turn into
+                <filename>FILES = "xyz"</filename>.
+                </para></listitem>
+            <listitem><para><emphasis><filename>unsafe-references-in-binaries:</filename></emphasis>
+                Reports when a binary installed in
+                <filename>${base_libdir}</filename>,
+                <filename>${base_bindir}</filename>, or
+                <filename>${base_sbindir}</filename>, depends on another
+                binary installed under <filename>${exec_prefix}</filename>.
+                This dependency is a concern if you want the system to remain
+                basically operable if <filename>/usr</filename> is mounted
+                separately and is not mounted.
+                <note>
+                    Defaults for binaries installed in
+                    <filename>${base_libdir}</filename>,
+                    <filename>${base_bindir}</filename>, and
+                    <filename>${base_sbindir}</filename> are
+                    <filename>/lib</filename>, <filename>/bin</filename>, and
+                    <filename>/sbin</filename>, respectively.
+                    The default for a binary installed
+                    under <filename>${exec_prefix}</filename> is
+                    <filename>/usr</filename>.
+                </note>
+                </para></listitem>
+            <listitem><para><emphasis><filename>unsafe-references-in-scripts:</filename></emphasis>
+                Reports when a script file installed in
+                <filename>${base_libdir}</filename>,
+                <filename>${base_bindir}</filename>, or
+                <filename>${base_sbindir}</filename>, depends on files
+                installed under <filename>${exec_prefix}</filename>.
+                This dependency is a concern if you want the system to remain
+                basically operable if <filename>/usr</filename> is mounted
+                separately and is not mounted.
+                <note>
+                    Defaults for binaries installed in
+                    <filename>${base_libdir}</filename>,
+                    <filename>${base_bindir}</filename>, and
+                    <filename>${base_sbindir}</filename> are
+                    <filename>/lib</filename>, <filename>/bin</filename>, and
+                    <filename>/sbin</filename>, respectively.
+                    The default for a binary installed
+                    under <filename>${exec_prefix}</filename> is
+                    <filename>/usr</filename>.
+                </note>
+                </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>,
+                <link linkend='var-DEPLOY_DIR'><filename>DEPLOY_DIR</filename></link>,
+                <link linkend='var-D'><filename>D</filename></link>,
+                <link linkend='var-PN'><filename>PN</filename></link>, and
+                <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
+                written package under the same name.
+                If you are placing output packages into a feed and
+                upgrading packages on a target system using that feed, the
+                version of a package going backwards can result in the target
+                system not correctly upgrading to the "new" version of the
+                package.
+                <note>
+                    If you are not using runtime package management on your
+                    target system, then you do not need to worry about
+                    this situation.
+                </note>
+                </para></listitem>
+        </itemizedlist>
+    </para>
+</section>
+
+<section id='ref-classes-rm-work'>
+    <title>Removing Work Files During the Build - <filename>rm_work.bbclass</filename></title>
+
+    <para>
+        The OpenEmbedded build system can use a substantial amount of disk
+        space during the build process.
+        A portion of this space is the work files under the
+        <filename>${TMPDIR}/work</filename> directory for each recipe.
+        Once the build system generates the packages for a recipe, the work
+        files for that recipe are no longer needed.
+        However, by default, the build system preserves these files
+        for inspection and possible debugging purposes.
+        If you would rather have these files deleted to save disk space
+        as the build progresses, you can enable <filename>rm_work</filename>
+        by adding the following to your <filename>local.conf</filename> file,
+        which is found in the
+        <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+        <literallayout class='monospaced'>
+    INHERIT += "rm_work"
+        </literallayout>
+        If you are modifying and building source code out of the work directory
+        for a recipe, enabling <filename>rm_work</filename> will potentially
+        result in your changes to the source being lost.
+        To exclude some recipes from having their work directories deleted by
+        <filename>rm_work</filename>, you can add the names of the recipe or
+        recipes you are working on to the <filename>RM_WORK_EXCLUDE</filename>
+        variable, which can also be set in your <filename>local.conf</filename>
+        file.
+        Here is an example:
+        <literallayout class='monospaced'>
+    RM_WORK_EXCLUDE += "busybox eglibc"
+        </literallayout>
+    </para>
+</section>
+
+
+<section id='ref-classes-siteinfo'>
+    <title>Autotools Configuration Data Cache - <filename>siteinfo.bbclass</filename></title>
+
+    <para>
+        Autotools can require tests that must execute on the target hardware.
+        Since this is not possible in general when cross compiling, site information is
+        used to provide cached test results so these tests can be skipped over but
+        still make the correct values available.
+        The <filename><link linkend='structure-meta-site'>meta/site directory</link></filename>
+        contains test results sorted into different categories such as architecture, endianness, and
+        the <filename>libc</filename> used.
+        Site information provides a list of files containing data relevant to
+        the current build in the
+        <filename><link linkend='var-CONFIG_SITE'>CONFIG_SITE</link></filename> variable
+        that Autotools automatically picks up.
+    </para>
+
+    <para>
+        The class also provides variables like
+        <filename><link linkend='var-SITEINFO_ENDIANNESS'>SITEINFO_ENDIANNESS</link></filename>
+        and <filename><link linkend='var-SITEINFO_BITS'>SITEINFO_BITS</link></filename>
+        that can be used elsewhere in the metadata.
+    </para>
+
+    <para>
+        Because this class is included from <filename>base.bbclass</filename>, it is always active.
+    </para>
+</section>
+
+<section id='ref-classes-useradd'>
+    <title>Adding Users - <filename>useradd.bbclass</filename></title>
+
+    <para>
+        If you have packages that install files that are owned by custom users or groups,
+        you can use this class to specify those packages and associate the users and groups
+        with those packages.
+        The <filename>meta-skeleton/recipes-skeleton/useradd/useradd-example.bb</filename>
+        recipe in the <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+        provides a simple example that shows how to add three
+        users and groups to two packages.
+        See the <filename>useradd-example.bb</filename> for more information on how to
+        use this class.
+    </para>
+</section>
+
+<section id='ref-classes-externalsrc'>
+    <title><filename>externalsrc.bbclass</filename></title>
+
+    <para>
+        You can use this class to build software from source code that is
+        external to the OpenEmbedded build system.
+        Building software from an external source tree means that the build
+        system's normal fetch, unpack, and patch process is not used.
+    </para>
+
+    <para>
+        By default, the OpenEmbedded build system uses the
+        <link linkend='var-S'><filename>S</filename></link> and
+        <link linkend='var-B'><filename>B</filename></link> variables to
+        locate unpacked recipe source code and to build it, respectively.
+        When your recipe inherits <filename>externalsrc.bbclass</filename>,
+        you use the
+        <link linkend='var-EXTERNALSRC'><filename>EXTERNALSRC</filename></link>
+        and
+        <link linkend='var-EXTERNALSRC_BUILD'><filename>EXTERNALSRC_BUILD</filename></link>
+        variables to ultimately define <filename>S</filename> and
+        <filename>B</filename>.
+    </para>
+
+    <para>
+        By default, this class expects the source code to support recipe builds
+        that use the <link linkend='var-B'><filename>B</filename></link>
+        variable to point to the directory in which the OpenEmbedded build
+        system places the generated objects built from the recipes.
+        By default, the <filename>B</filename> directory is set to the
+        following, which is separate from the source directory
+        (<filename>S</filename>):
+        <literallayout class='monospaced'>
+     ${WORKDIR}/${BPN}/{PV}/
+        </literallayout>
+        See the glossary entries for the
+        <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>,
+        <link linkend='var-BPN'><filename>BPN</filename></link>,
+        <link linkend='var-PV'><filename>PV</filename></link>,
+    </para>
+
+    <para>
+        For more information on
+        <filename>externalsrc.bbclass</filename>, see the comments in
+        <filename>meta/classes/externalsrc.bbclass</filename> in the
+        <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+        For information on how to use <filename>externalsrc.bbclass</filename>,
+        see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#building-software-from-an-external-source'>Building Software from an External Source</ulink>"
+        section in the Yocto Project Development Manual.
+    </para>
+</section>
+
+<section id='ref-classes-testimage'>
+    <title><filename>testimage.bbclass</filename></title>
+
+    <para>
+        You can use this class to enable running a series of automated tests
+        for images.
+        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>
+        To use the class, you need to perform steps to set up the
+        environment.
+        The tests are commands that run on the target system over
+        <filename>ssh</filename>.
+        they are written in Python and make use of the
+        <filename>unittest</filename> module.
+    </para>
+
+    <para>
+        For information on how to enable, run, and create new tests, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing'>Performing Automated Runtime Testing</ulink>"
+        section.
+    </para>
+</section>
+
+<section id='ref-classes-others'>
+    <title>Other Classes</title>
+
+    <para>
+        Thus far, this chapter has discussed only the most useful and important
+        classes.
+        However, other classes exist within the <filename>meta/classes</filename> directory
+        in the <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+        You can examine the <filename>.bbclass</filename> files directly for more
+        information.
+    </para>
+</section>
+
+<!-- Undocumented classes are:
+        allarch.bbclass
+        archive*.bbclass
+        binconfig.bbclass
+        bin_package.bbclass
+        blacklist.bbclass
+        bootimg.bbclass
+        boot-directdisk.bbclass
+        bugzilla.bbclass
+        buildhistory.bbclass
+        buildstats.bbclass
+        ccache.bbclass
+        chrpath.bbclass
+        clutter.bbclass
+        cmake.bbclass
+        cml1.bbclass
+        copyleft_compliance.bbclass
+        core-image.bbclass
+        cross.bbclass
+        cross-canadian.bbclass
+        crosssdk.bbclass
+        deploy.bbclass
+        distrodata.bbclass
+        distro_features_check.bbclass
+        dummy.bbclass
+        extrausers.bbclass
+        fontcache.bbclass
+        gconf.bbclass
+        gettext.bbclass
+        gnomebase.bbclass
+        gnome.bbclass
+        grub-efi.bbclass
+        gsettings.bbclass
+        gtk-doc.bbclass
+        gtk-icon-cache.bbclass
+        gtk-immodules-cache.bbclass
+        gzipnative.bbclass
+        icecc.bbclass
+        image-empty.bbclass
+        image-live.bbclass
+        image-vmdk.bbclass
+        image-mklibs.bbclass
+        image-prelink.bbclass
+        image-swab.bbclass
+        image_types.bbclass
+        image_types_uboot.bbclass
+        insserv.bbclass
+        kernel-arch.bbclass
+        kernel-module-split.bbclass
+        kernel-yocto.bbclass
+        lib_package.bbclass
+        linux-kernel-base.bbclass
+        license.bbclass
+        logging.bbclass
+        meta.bbclass
+        metadata_scm.bbclass
+        migrate_localcount.bbclass
+        mime.bbclass
+        mirrors.bbclass
+        multilib*.bbclass
+        native.bbclass
+        nativesdk.bbclass
+        oelint.bbclass
+        own-mirrors.bbclass
+        packagedata.bbclass
+        packageinfo.bbclass
+        patch.bbclass
+        perlnative.bbclass
+        pixbufcache.bbclass
+        pkg_distribute.bbclass
+        pkg_metainfo.bbclass
+        populate_sdk*.bbclass
+        prexport.bbclass
+        primport.bbclass
+        prserv.bbclass
+        ptest.bbclass
+        python-dir.bbclass
+        pythonnative.bbclass
+        qemu.bbclass
+        qmake*.bbclass
+        qt4*.bbclass
+        recipe_sanity.bbclass
+        relocatable.bbclass
+        scons.bbclass
+        sdl.bbclass
+        setuptools.bbclass
+        sip.bbclass
+        siteconfig.bbclass
+        sourcepkg.bbclass
+        spdx.bbclass
+        sstate.bbclass
+        staging.bbclass
+        syslinux.bbclass
+        systemd.bbclass
+        terminal.bbclass
+        tinderclient.bbclass
+        toolchain-scripts.bbclass
+        typecheck.bbclass
+        uboot-config.bbclass
+        utility-tasks.bbclass
+        utils.bbclass
+        vala.bbclass
+        waf.bbclass
+-->
+
+
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/ref-manual/ref-features.xml b/documentation/ref-manual/ref-features.xml
new file mode 100644
index 0000000..dedcf67
--- /dev/null
+++ b/documentation/ref-manual/ref-features.xml
@@ -0,0 +1,334 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='ref-features'>
+    <title>Reference: Features</title>
+
+    <para>
+        This chapter provides a reference of shipped machine and distro features
+        you can include as part of the image, a reference on image types you can
+        build, and a reference on feature backfilling.
+    </para>
+
+    <para>
+        Features provide a mechanism for working out which packages
+        should be included in the generated images.
+        Distributions can select which features they want to support through the
+        <filename><link linkend='var-DISTRO_FEATURES'>DISTRO_FEATURES</link></filename>
+        variable, which is set in the <filename>poky.conf</filename> distribution configuration file.
+        Machine features are set in the
+        <filename><link linkend='var-MACHINE_FEATURES'>MACHINE_FEATURES</link></filename>
+        variable, which is set in the machine configuration file and
+        specifies the hardware features for a given machine.
+    </para>
+
+    <para>
+        These two variables combine to work out which kernel modules,
+        utilities, and other packages to include.
+        A given distribution can support a selected subset of features so some machine features might not
+        be included if the distribution itself does not support them.
+    </para>
+
+    <para>
+        One method you can use to determine which recipes are checking to see if a
+        particular feature is contained or not is to <filename>grep</filename> through
+        the <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+        for the feature.
+        Here is an example that discovers the recipes whose build is potentially
+        changed based on a given feature:
+        <literallayout class='monospaced'>
+     $ cd poky
+     $ git grep 'contains.*MACHINE_FEATURES.*&lt;feature&gt;'
+        </literallayout>
+    </para>
+
+    <section id='ref-features-distro'>
+        <title>Distro</title>
+
+        <para>
+            The items below are features you can use with
+            <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>.
+            Features do not have a one-to-one correspondence to packages, and they can
+            go beyond simply controlling the installation of a package or packages.
+            Sometimes a feature can influence how certain recipes are built.
+            For example, a feature might determine whether a particular configure option
+            is specified within <filename>do_configure</filename> for a particular
+            recipe.
+        </para>
+
+        <para>
+            This list only represents features as shipped with the Yocto Project metadata:
+            <itemizedlist>
+                <listitem><para><emphasis>alsa:</emphasis> Include ALSA support
+                    (OSS compatibility kernel modules installed if available).
+                    </para></listitem>
+                <listitem><para><emphasis>bluetooth:</emphasis> Include
+                    bluetooth support (integrated BT only).</para></listitem>
+                <listitem><para><emphasis>cramfs:</emphasis> Include CramFS
+                    support.</para></listitem>
+                <listitem><para><emphasis>ext2:</emphasis> Include tools for
+                    supporting for devices with internal HDD/Microdrive for
+                    storing files (instead of Flash only devices).
+                    </para></listitem>
+                <listitem><para><emphasis>ipsec:</emphasis> Include IPSec
+                    support.</para></listitem>
+                <listitem><para><emphasis>ipv6:</emphasis> Include IPv6 support.
+                    </para></listitem>
+                <listitem><para><emphasis>irda:</emphasis> Include Irda support.
+                    </para></listitem>
+                <listitem><para><emphasis>keyboard:</emphasis> Include keyboard
+                    support (e.g. keymaps will be loaded during boot).
+                    </para></listitem>
+                <listitem><para><emphasis>nfs:</emphasis> Include NFS client
+                    support (for mounting NFS exports on device).
+                    </para></listitem>
+                <listitem><para><emphasis>opengl:</emphasis>
+                    Include the Open Graphics Library, which is a
+                    cross-language, multi-platform application programming
+                    interface used for rendering two and three-dimensional
+                    graphics.</para></listitem>
+                <listitem><para><emphasis>pci:</emphasis> Include PCI bus
+                    support.</para></listitem>
+                <listitem><para><emphasis>pcmcia:</emphasis> Include
+                    PCMCIA/CompactFlash support.</para></listitem>
+                <listitem><para><emphasis>ppp:</emphasis> Include PPP dialup
+                    support.</para></listitem>
+                <listitem><para><emphasis>smbfs:</emphasis> Include SMB networks
+                    client support (for mounting Samba/Microsoft Windows shares
+                    on device).</para></listitem>
+                <listitem><para><emphasis>systemd:</emphasis> Include support
+                    for this <filename>init</filename> manager, which is a full
+                    replacement of for <filename>init</filename> with parallel
+                    starting of services, reduced shell overhead, and other
+                    features.
+                    This <filename>init</filename> manager is used by many
+                    distributions.</para></listitem>
+                <listitem><para><emphasis>usbgadget:</emphasis> Include USB
+                    Gadget Device support (for USB networking/serial/storage).
+                    </para></listitem>
+                <listitem><para><emphasis>usbhost:</emphasis> Include USB Host
+                    support (allows to connect external keyboard, mouse,
+                    storage, network etc).</para></listitem>
+                <listitem><para><emphasis>wayland:</emphasis> Include the
+                    Wayland display server protocol and the library that
+                    supports it.</para></listitem>
+                <listitem><para><emphasis>wifi:</emphasis> Include WiFi support
+                    (integrated only).</para></listitem>
+                <listitem><para><emphasis>sdk-pms:</emphasis> Include Package
+                    Management Tools in the
+                    <filename>nativesdk</filename> toolchain tarball.
+                    Including these tools allows for easy sandbox use when
+                    creating the root filesystem while using the SDK tarball.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='ref-features-machine'>
+        <title>Machine</title>
+
+        <para>
+            The items below are features you can use with
+            <link linkend='var-MACHINE_FEATURES'><filename>MACHINE_FEATURES</filename></link>.
+            Features do not have a one-to-one correspondence to packages, and they can
+            go beyond simply controlling the installation of a package or packages.
+            Sometimes a feature can influence how certain recipes are built.
+            For example, a feature might determine whether a particular configure option
+            is specified within <filename>do_configure</filename> for a particular
+            recipe.
+        </para>
+
+        <para>
+            This feature list only represents features as shipped with the Yocto Project metadata:
+            <itemizedlist>
+                <listitem><para><emphasis>acpi:</emphasis> Hardware has ACPI (x86/x86_64 only)
+                    </para></listitem>
+                <listitem><para><emphasis>alsa:</emphasis> Hardware has ALSA audio drivers
+                    </para></listitem>
+                <listitem><para><emphasis>apm:</emphasis> Hardware uses APM (or APM emulation)
+                    </para></listitem>
+                <listitem><para><emphasis>bluetooth:</emphasis> Hardware has integrated BT
+                    </para></listitem>
+                <listitem><para><emphasis>ext2:</emphasis> Hardware HDD or Microdrive
+                    </para></listitem>
+                <listitem><para><emphasis>irda:</emphasis> Hardware has Irda support
+                    </para></listitem>
+                <listitem><para><emphasis>keyboard:</emphasis> Hardware has a keyboard
+                    </para></listitem>
+                <listitem><para><emphasis>pci:</emphasis> Hardware has a PCI bus
+                    </para></listitem>
+                <listitem><para><emphasis>pcmcia:</emphasis> Hardware has PCMCIA or CompactFlash sockets
+                    </para></listitem>
+                <listitem><para><emphasis>screen:</emphasis> Hardware has a screen
+                    </para></listitem>
+                <listitem><para><emphasis>serial:</emphasis> Hardware has serial support (usually RS232)
+                    </para></listitem>
+                <listitem><para><emphasis>touchscreen:</emphasis> Hardware has a touchscreen
+                    </para></listitem>
+                <listitem><para><emphasis>usbgadget:</emphasis> Hardware is USB gadget device capable
+                    </para></listitem>
+                <listitem><para><emphasis>usbhost:</emphasis> Hardware is USB Host capable
+                    </para></listitem>
+                <listitem><para><emphasis>wifi:</emphasis> Hardware has integrated WiFi
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='ref-features-image'>
+        <title>Images</title>
+
+        <para>
+            The contents of images generated by the OpenEmbedded build system can be controlled by the
+            <filename><link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></filename>
+            and <filename><link linkend='var-EXTRA_IMAGE_FEATURES'>EXTRA_IMAGE_FEATURES</link></filename>
+            variables that you typically configure in your image recipes.
+            Through these variables, you can add several different
+            predefined packages such as development utilities or packages with debug
+            information needed to investigate application problems or profile applications.
+        </para>
+
+        <para>
+            Current list of
+            <filename>IMAGE_FEATURES</filename> contains the following:
+            <itemizedlist>
+                <listitem><para><emphasis>dbg-pkgs:</emphasis> Installs debug symbol packages for all packages
+                    installed in a given image.</para></listitem>
+                <listitem><para><emphasis>dev-pkgs:</emphasis> Installs development packages (headers and
+                    extra library links) for all packages installed in a given image.</para></listitem>
+                <listitem><para><emphasis>doc-pkgs:</emphasis> Installs documentation packages for all packages
+                    installed in a given image.</para></listitem>
+                <listitem><para><emphasis>nfs-server:</emphasis> Installs an NFS server.</para></listitem>
+                <listitem><para><emphasis>read-only-rootfs:</emphasis> Creates
+                    an image whose root filesystem is read-only.
+                    See the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-read-only-root-filesystem'>Creating a Read-Only Root Filesystem</ulink>"
+                    section in the Yocto Project Development Manual for more
+                    information.</para></listitem>
+                <listitem><para><emphasis>splash:</emphasis> Enables showing a splash screen during boot.
+                    By default, this screen is provided by <filename>psplash</filename>, which does
+                    allow customization.
+                    If you prefer to use an alternative splash screen package, you can do so by
+                    setting the <filename>SPLASH</filename> variable
+                    to a different package name (or names) within the image recipe or at the distro
+                    configuration level.</para></listitem>
+                <listitem><para><emphasis>ssh-server-dropbear:</emphasis> Installs the Dropbear minimal
+                    SSH server.
+                    </para></listitem>
+                <listitem><para><emphasis>ssh-server-openssh:</emphasis> Installs the OpenSSH SSH server,
+                    which is more full-featured than Dropbear.
+                    Note that if both the OpenSSH SSH server and the Dropbear minimal SSH server
+                    are present in <filename>IMAGE_FEATURES</filename>, then OpenSSH will take
+                    precedence and Dropbear will not be installed.</para></listitem>
+                <listitem><para><emphasis>staticdev-pkgs:</emphasis> Installs static development
+                    packages (i.e. static libraries containing <filename>*.a</filename> files) for all
+                    packages installed in a given image.</para></listitem>
+                <listitem><para><emphasis>tools-debug:</emphasis> Installs debugging tools such as
+                    <filename>strace</filename> and <filename>gdb</filename>.
+                    For information on GDB, see the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-gdb-remotedebug'>Debugging With the GNU Project Debugger (GDB) Remotely</ulink>"
+                    section in the Yocto Project Development Manual.
+                    For information on tracing and profiling, see the
+                    <ulink url='&YOCTO_DOCS_PROF_URL;'>Yocto Project Profiling and Tracing Manual</ulink>.
+                    </para></listitem>
+                <listitem><para><emphasis>tools-profile:</emphasis> Installs profiling tools such as
+                    <filename>oprofile</filename>, <filename>exmap</filename>, and
+                    <filename>LTTng</filename>.
+                    For general information on user-space tools, see the
+                    "<ulink url='&YOCTO_DOCS_ADT_URL;#user-space-tools'>User-Space Tools</ulink>"
+                    section in the Yocto Project Application Developer's Guide.</para></listitem>
+                <listitem><para><emphasis>tools-sdk:</emphasis> Installs a full SDK that runs on the device.
+                    </para></listitem>
+                <listitem><para><emphasis>tools-testapps:</emphasis> Installs device testing tools (e.g.
+                    touchscreen debugging).</para></listitem>
+                <listitem><para><emphasis>x11:</emphasis> Installs the X server</para></listitem>
+                <listitem><para><emphasis>x11-base:</emphasis> Installs the X server with a
+                    minimal environment.</para></listitem>
+                <listitem><para><emphasis>x11-sato:</emphasis> Installs the OpenedHand Sato environment.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='ref-features-backfill'>
+        <title>Feature Backfilling</title>
+
+        <para>
+            Sometimes it is necessary in the OpenEmbedded build system to extend
+            <link linkend='var-MACHINE_FEATURES'><filename>MACHINE_FEATURES</filename></link>
+            or <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>
+            to control functionality that was previously enabled and not able
+            to be disabled.
+            For these cases, we need to add an
+            additional feature item to appear in one of these variables,
+            but we do not want to force developers who have existing values
+            of the variables in their configuration to add the new feature
+            in order to retain the same overall level of functionality.
+            Thus, the OpenEmbedded build system has a mechanism to
+            automatically "backfill" these added features into existing
+            distro or machine configurations.
+            You can see the list of features for which this is done by
+            finding the
+            <link linkend='var-DISTRO_FEATURES_BACKFILL'><filename>DISTRO_FEATURES_BACKFILL</filename></link>
+            and <link linkend='var-MACHINE_FEATURES_BACKFILL'><filename>MACHINE_FEATURES_BACKFILL</filename></link>
+            variables in the <filename>meta/conf/bitbake.conf</filename> file.
+        </para>
+
+        <para>
+            Because such features are backfilled by default into all
+            configurations as described in the previous paragraph, developers
+            who wish to disable the new features need to be able to selectively
+            prevent the backfilling from occurring.
+            They can do this by adding the undesired feature or features to the
+            <link linkend='var-DISTRO_FEATURES_BACKFILL_CONSIDERED'><filename>DISTRO_FEATURES_BACKFILL_CONSIDERED</filename></link>
+            or <link linkend='var-MACHINE_FEATURES_BACKFILL_CONSIDERED'><filename>MACHINE_FEATURES_BACKFILL_CONSIDERED</filename></link>
+            variables for distro features and machine features respectively.
+        </para>
+
+        <para>
+            Here are two examples to help illustrate feature backfilling:
+            <itemizedlist>
+                <listitem><para><emphasis>The "pulseaudio" distro feature option</emphasis>:
+                    Previously, PulseAudio support was enabled within the Qt and
+                    GStreamer frameworks.
+                    Because of this, the feature is backfilled and thus
+                    enabled for all distros through the
+                    <filename>DISTRO_FEATURES_BACKFILL</filename>
+                    variable in the <filename>meta/conf/bitbake.conf</filename> file.
+                    However, your distro needs to disable the feature.
+                    You can disable the feature without affecting
+                    other existing distro configurations that need PulseAudio support
+                    by adding "pulseaudio" to
+                    <filename>DISTRO_FEATURES_BACKFILL_CONSIDERED</filename>
+                    in your distro's <filename>.conf</filename> file.
+                    Adding the feature to this variable when it also
+                    exists in the <filename>DISTRO_FEATURES_BACKFILL</filename>
+                    variable prevents the build system from adding the feature to
+                    your configuration's <filename>DISTRO_FEATURES</filename>, effectively disabling
+                    the feature for that particular distro.</para></listitem>
+                <listitem><para><emphasis>The "rtc" machine feature option</emphasis>:
+                    Previously, real time clock (RTC) support was enabled for all
+                    target devices.
+                    Because of this, the feature is backfilled and thus enabled
+                    for all machines through the <filename>MACHINE_FEATURES_BACKFILL</filename>
+                    variable in the <filename>meta/conf/bitbake.conf</filename> file.
+                    However, your target device does not have this capability.
+                    You can disable RTC support for your device without
+                    affecting other machines that need RTC support
+                    by adding the feature to your machine's
+                    <filename>MACHINE_FEATURES_BACKFILL_CONSIDERED</filename>
+                    list in the machine's <filename>.conf</filename> file.
+                    Adding the feature to this variable when it also
+                    exists in the <filename>MACHINE_FEATURES_BACKFILL</filename>
+                    variable prevents the build system from adding the feature to
+                    your configuration's <filename>MACHINE_FEATURES</filename>, effectively
+                    disabling RTC support for that particular machine.</para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+</chapter>
+
+<!--
+vim: expandtab tw=80 ts=4 spell spelllang=en_gb
+-->
diff --git a/documentation/ref-manual/ref-images.xml b/documentation/ref-manual/ref-images.xml
new file mode 100644
index 0000000..37c8051
--- /dev/null
+++ b/documentation/ref-manual/ref-images.xml
@@ -0,0 +1,150 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='ref-images'>
+    <title>Images</title>
+
+    <para>
+        The OpenEmbedded build system provides several example
+        images to satisfy different needs.
+        When you issue the <filename>bitbake</filename> command you provide a “top-level” recipe
+        that essentially begins the build for the type of image you want.
+    </para>
+
+    <note>
+        Building an image without GNU General Public License Version 3 (GPLv3) components
+        is only supported for minimal and base images.
+        Furthermore, if you are going to build an image using non-GPLv3 components,
+        you must make the following changes in the <filename>local.conf</filename> file
+        before using the BitBake command to build the minimal or base image:
+        <literallayout class='monospaced'>
+     1. Comment out the EXTRA_IMAGE_FEATURES line
+     2. Set INCOMPATIBLE_LICENSE = "GPLv3"
+        </literallayout>
+    </note>
+
+    <para>
+        From within the <filename>poky</filename> Git repository, use the following command to list
+        the supported images:
+        <literallayout class='monospaced'>
+     $ ls meta*/recipes*/images/*.bb
+        </literallayout>
+        These recipes reside in the <filename>meta/recipes-core/images</filename>,
+        <filename>meta/recipes-extended/images</filename>,
+        <filename>meta/recipes-graphics/images</filename>,
+        <filename>meta/recipes-qt/images</filename>,
+        <filename>meta/recipes-rt/images</filename>,
+        <filename>meta/recipes-sato/images</filename>, and
+        <filename>meta-skeleton/recipes-multilib/images</filename> directories
+        within the <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+        Although the recipe names are somewhat explanatory, here is a list that describes them:
+    </para>
+
+    <itemizedlist>
+        <listitem><para><emphasis><filename>build-appliance-image</filename>:</emphasis>
+            An example virtual machine that contains all the pieces required to
+            run builds using the build system as well as the build system itself.
+            You can boot and run the image using either the
+            <ulink url='http://www.vmware.com/products/player/overview.html'>VMware Player</ulink>
+            or <ulink url='http://www.vmware.com/products/workstation/overview.html'>VMware Workstation</ulink>.
+            For more information on this image, see the
+            <ulink url='&YOCTO_HOME_URL;/documentation/build-appliance'>Build Appliance</ulink> page on
+            the Yocto Project website.</para></listitem>
+        <listitem><para><emphasis><filename>core-image-base</filename>:</emphasis>
+            A console-only image that fully supports the target device hardware.</para></listitem>
+        <listitem><para><emphasis><filename>core-image-minimal</filename>:</emphasis>
+            A small image just capable of allowing a device to boot.</para></listitem>
+        <listitem><para><emphasis><filename>core-image-minimal-dev</filename>:</emphasis>
+            A <filename>core-image-minimal</filename> image suitable for development work
+            using the host.
+            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>
+            A <filename>core-image-minimal</filename> image that has the Minimal RAM-based
+            Initial Root Filesystem (<filename>initramfs</filename>) as part of the kernel,
+            which allows the system to find the first “init” program more efficiently.
+            </para></listitem>
+        <listitem><para><emphasis><filename>core-image-minimal-mtdutils</filename>:</emphasis>
+            A <filename>core-image-minimal</filename> image that has support
+            for the Minimal MTD Utilities, which let the user interact with the
+            MTD subsystem in the kernel to perform operations on flash devices.
+            </para></listitem>
+        <listitem><para><emphasis><filename>core-image-basic</filename>:</emphasis>
+            A console-only image with more full-featured Linux system
+            functionality installed.</para></listitem>
+        <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-lsb-dev</filename>:</emphasis>
+            A <filename>core-image-lsb</filename> image that is suitable for development work
+            using the host.
+            The image includes headers and libraries you can use in a host development
+            environment.
+            </para></listitem>
+        <listitem><para><emphasis><filename>core-image-lsb-sdk</filename>:</emphasis>
+            A <filename>core-image-lsb</filename> that includes everything in meta-toolchain
+            but also includes development headers and libraries to form a complete standalone SDK.
+            This image is suitable for development using the target.</para></listitem>
+        <listitem><para><emphasis><filename>core-image-clutter</filename>:</emphasis>
+            An image with support for the Open GL-based toolkit Clutter, which enables development of
+            rich and animated graphical user interfaces.</para></listitem>
+        <listitem><para><emphasis><filename>core-image-gtk-directfb</filename>:</emphasis>
+            An image that uses <filename>gtk+</filename> over <filename>directfb</filename>
+            instead of X11.
+            In order to build, this image requires specific distro configuration that enables
+            <filename>gtk</filename> over <filename>directfb</filename>.</para></listitem>
+        <listitem><para><emphasis><filename>core-image-x11</filename>:</emphasis>
+            A very basic X11 image with a terminal.
+            </para></listitem>
+        <listitem><para><emphasis><filename>qt4e-demo-image</filename>:</emphasis>
+            An image that launches into the demo application for the embedded
+            (not based on X11) version of Qt.</para></listitem>
+        <listitem><para><emphasis><filename>core-image-rt</filename>:</emphasis>
+            A <filename>core-image-minimal</filename> image plus a real-time test suite and
+            tools appropriate for real-time use.</para></listitem>
+        <listitem><para><emphasis><filename>core-image-rt-sdk</filename>:</emphasis>
+            A <filename>core-image-rt</filename> image that includes everything in
+            <filename>meta-toolchain</filename>.
+            The image also includes development headers and libraries to form a complete
+            stand-alone SDK and is suitable for development using the target.
+            </para></listitem>
+        <listitem><para><emphasis><filename>core-image-sato</filename>:</emphasis>
+            An image with Sato support, a mobile environment and visual style that works well
+            with mobile devices.
+            The image supports X11 with a Sato theme and applications such as
+            a terminal, editor, file manager, media player, and so forth.
+            </para></listitem>
+        <listitem><para><emphasis><filename>core-image-sato-dev</filename>:</emphasis>
+            A <filename>core-image-sato</filename> image suitable for development
+            using the host.
+            The image includes libraries needed to build applications on the device itself,
+            testing and profiling tools, and debug symbols.
+            This image was formerly <filename>core-image-sdk</filename>.
+            </para></listitem>
+        <listitem><para><emphasis><filename>core-image-sato-sdk</filename>:</emphasis>
+            A <filename>core-image-sato</filename> image that includes everything in meta-toolchain.
+            The image also includes development headers and libraries to form a complete standalone SDK
+            and is suitable for development using the target.</para></listitem>
+        <listitem><para><emphasis><filename>core-image-multilib-example</filename>:</emphasis>
+            An example image that includes a <filename>lib32</filename> version
+            of Bash into an otherwise standard <filename>sato</filename> image.
+            The image assumes a "lib32" multilib has been enabled in the your
+            configuration.</para></listitem>
+    </itemizedlist>
+
+    <tip>
+        From the Yocto Project release 1.1 onwards, <filename>-live</filename> and
+        <filename>-directdisk</filename> images have been replaced by a "live"
+        option in <filename>IMAGE_FSTYPES</filename> that will work with any image to produce an
+        image file that can be
+        copied directly to a CD or USB device and run as is.
+        To build a live image, simply add
+        "live" to <filename>IMAGE_FSTYPES</filename> within the <filename>local.conf</filename>
+        file or wherever appropriate and then build the desired image as normal.
+    </tip>
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/ref-manual/ref-manual-customization.xsl b/documentation/ref-manual/ref-manual-customization.xsl
new file mode 100644
index 0000000..3ad3a31
--- /dev/null
+++ b/documentation/ref-manual/ref-manual-customization.xsl
@@ -0,0 +1,11 @@
+<?xml version='1.0'?>
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
+  
+  <xsl:import href="http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl" />
+
+  <xsl:param name="html.stylesheet" select="'ref-style.css'" />
+  <xsl:param name="chapter.autolabel" select="1" />
+  <xsl:param name="appendix.autolabel" select="A" />
+  <xsl:param name="section.autolabel" select="1" />
+  <xsl:param name="section.label.includes.component.label" select="1" />
+</xsl:stylesheet>
diff --git a/documentation/ref-manual/ref-manual-eclipse-customization.xsl b/documentation/ref-manual/ref-manual-eclipse-customization.xsl
new file mode 100644
index 0000000..4e6b799
--- /dev/null
+++ b/documentation/ref-manual/ref-manual-eclipse-customization.xsl
@@ -0,0 +1,27 @@
+<?xml version='1.0'?>
+<xsl:stylesheet
+        xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
+        xmlns="http://www.w3.org/1999/xhtml"
+        xmlns:fo="http://www.w3.org/1999/XSL/Format"
+        version="1.0">
+
+  <xsl:import
+          href="http://docbook.sourceforge.net/release/xsl/current/eclipse/eclipse3.xsl" />
+
+  <xsl:param name="chunker.output.indent" select="'yes'"/>
+  <xsl:param name="chunk.quietly" select="1"/>
+  <xsl:param name="chunk.first.sections" select="1"/>
+  <xsl:param name="chunk.section.depth" select="10"/>
+  <xsl:param name="use.id.as.filename" select="1"/>
+  <xsl:param name="ulink.target" select="'_self'" />
+  <xsl:param name="base.dir" select="'html/ref-manual/'"/>
+  <xsl:param name="html.stylesheet" select="'../book.css'"/>
+  <xsl:param name="eclipse.manifest" select="0"/>
+  <xsl:param name="create.plugin.xml" select="0"/>
+  <xsl:param name="suppress.navigation" select="1"/>
+  <xsl:param name="generate.index" select="0"/>
+  <xsl:param name="chapter.autolabel" select="1" />
+  <xsl:param name="appendix.autolabel">A</xsl:param>
+  <xsl:param name="section.autolabel" select="1" />
+  <xsl:param name="section.label.includes.component.label" select="1" />
+</xsl:stylesheet>
diff --git a/documentation/ref-manual/ref-manual.xml b/documentation/ref-manual/ref-manual.xml
new file mode 100644
index 0000000..7db880b
--- /dev/null
+++ b/documentation/ref-manual/ref-manual.xml
@@ -0,0 +1,138 @@
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<book id='ref-manual' lang='en'
+      xmlns:xi="http://www.w3.org/2003/XInclude"
+      xmlns="http://docbook.org/ns/docbook"
+      >
+    <bookinfo>
+
+        <mediaobject>
+            <imageobject>
+                <imagedata fileref='figures/poky-title.png'
+                    format='SVG'
+                    align='left' scalefit='1' width='100%'/>
+            </imageobject>
+        </mediaobject>
+
+        <title>
+            Yocto Project Reference Manual
+        </title>
+
+        <authorgroup>
+            <author>
+                <firstname>Richard</firstname> <surname>Purdie</surname>
+                <affiliation>
+                    <orgname>Linux Foundation</orgname>
+                </affiliation>
+                <email>richard.purdie@linuxfoundation.org</email>
+            </author>
+
+        </authorgroup>
+
+        <revhistory>
+            <revision>
+                <revnumber>4.0+git</revnumber>
+                <date>24 November 2010</date>
+                <revremark>Released with the Yocto Project 0.9 Release</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.0</revnumber>
+                <date>6 April 2011</date>
+                <revremark>Released with the Yocto Project 1.0 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.0.1</revnumber>
+                <date>23 May 2011</date>
+                <revremark>Released with the Yocto Project 1.0.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.1</revnumber>
+                <date>6 October 2011</date>
+                <revremark>Released with the Yocto Project 1.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.2</revnumber>
+                <date>April 2012</date>
+                <revremark>Released with the Yocto Project 1.2 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.3</revnumber>
+                <date>October 2012</date>
+                <revremark>Released with the Yocto Project 1.3 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.4</revnumber>
+                <date>April 2013</date>
+                <revremark>Released with the Yocto Project 1.4 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.5</revnumber>
+                <date>October 2013</date>
+                <revremark>Released with the Yocto Project 1.5 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.5.1</revnumber>
+                <date>Sometime in 2013</date>
+                <revremark>Released with the Yocto Project 1.5.1 Release.</revremark>
+            </revision>
+        </revhistory>
+
+    <copyright>
+      <year>&COPYRIGHT_YEAR;</year>
+      <holder>Linux Foundation</holder>
+    </copyright>
+
+    <legalnotice>
+      <para>
+        Permission is granted to copy, distribute and/or modify this document under
+        the terms of the <ulink type="http" url="http://creativecommons.org/licenses/by-sa/2.0/uk/">Creative Commons Attribution-Share Alike 2.0 UK: England &amp; Wales</ulink> as published by Creative Commons.
+      </para>
+      <note>
+          For the latest version of this manual associated with this
+          Yocto Project release, see the
+          <ulink url='&YOCTO_DOCS_REF_URL;'>Yocto Project Reference Manual</ulink>
+          from the Yocto Project website.
+      </note>
+    </legalnotice>
+
+    </bookinfo>
+
+    <xi:include href="introduction.xml"/>
+
+    <xi:include href="usingpoky.xml"/>
+
+    <xi:include href="closer-look.xml"/>
+
+    <xi:include href="technical-details.xml"/>
+
+    <xi:include href="migration.xml"/>
+
+    <xi:include href="ref-structure.xml"/>
+
+    <xi:include href="ref-bitbake.xml"/>
+
+    <xi:include href="ref-classes.xml"/>
+
+    <xi:include href="ref-images.xml"/>
+
+    <xi:include href="ref-features.xml"/>
+
+    <xi:include href="ref-variables.xml"/>
+
+    <xi:include href="ref-varlocality.xml"/>
+
+    <xi:include href="faq.xml"/>
+
+    <xi:include href="resources.xml"/>
+
+<!--    <index id='index'>
+      <title>Index</title>
+    </index>
+-->
+
+</book>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/ref-manual/ref-structure.xml b/documentation/ref-manual/ref-structure.xml
new file mode 100644
index 0000000..66e58f2
--- /dev/null
+++ b/documentation/ref-manual/ref-structure.xml
@@ -0,0 +1,942 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='ref-structure'>
+
+<title>Source Directory Structure</title>
+
+<para>
+    The <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink> consists of several components.
+    Understanding them and knowing where they are located is key to using the Yocto Project well.
+    This chapter describes the Source Directory and gives information about the various
+    files and directories.
+</para>
+
+<para>
+    For information on how to establish a local Source Directory on your development system, see the
+    "<ulink url='&YOCTO_DOCS_DEV_URL;#getting-setup'>Getting Set Up</ulink>"
+    section in the Yocto Project Development Manual.
+</para>
+
+<note>
+    The OpenEmbedded build system does not support file or directory names that
+    contain spaces.
+    Be sure that the Source Directory you use does not contain these types
+    of names.
+</note>
+
+<section id='structure-core'>
+    <title>Top-Level Core Components</title>
+
+    <para>
+        This section describes the top-level components of the
+        <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+    </para>
+
+    <section id='structure-core-bitbake'>
+        <title><filename>bitbake/</filename></title>
+
+        <para>
+            This directory includes a copy of BitBake for ease of use.
+            The copy usually matches the current stable BitBake release from
+            the BitBake project.
+            BitBake, a
+            <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+            interpreter, reads the Yocto Project Metadata and runs the tasks
+            defined by that data.
+            Failures are usually from the Metadata and not from BitBake itself.
+            Consequently, most users do not need to worry about BitBake.
+        </para>
+
+        <para>
+            When you run the <filename>bitbake</filename> command, the
+            main BitBake executable, which resides in the
+            <filename>bitbake/bin/</filename> directory, starts.
+            Sourcing an environment setup script (e.g.
+            <link linkend="structure-core-script"><filename>&OE_INIT_FILE;</filename></link>
+            or
+            <link linkend="structure-memres-core-script"><filename>oe-init-build-env-memres</filename></link>)
+            places the <filename>scripts</filename> and
+            <filename>bitbake/bin</filename> directories (in that order) into
+            the shell's <filename>PATH</filename> environment variable.
+        </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>.
+        </para>
+    </section>
+
+    <section id='structure-core-build'>
+        <title><filename>build/</filename></title>
+
+        <para>
+            This directory contains user configuration files and the output
+            generated by the OpenEmbedded build system in its standard configuration where
+            the source tree is combined with the output.
+            The <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+            is created initially when you <filename>source</filename>
+            the OpenEmbedded build environment setup script
+            (i.e.
+            <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
+            or
+            <link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>).
+        </para>
+
+        <para>
+            It is also possible to place output and configuration
+            files in a directory separate from the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+            by providing a directory name when you <filename>source</filename>
+            the setup script.
+            For information on separating output from your local
+            Source Directory files, see the
+            "<link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
+            and
+            "<link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>"
+            sections.
+        </para>
+    </section>
+
+    <section id='handbook'>
+        <title><filename>documentation/</filename></title>
+
+        <para>
+            This directory holds the source for the Yocto Project documentation
+            as well as templates and tools that allow you to generate PDF and HTML
+            versions of the manuals.
+            Each manual is contained in a sub-folder.
+            For example, the files for this manual reside in
+            the <filename>ref-manual/</filename> directory.
+        </para>
+    </section>
+
+    <section id='structure-core-meta'>
+        <title><filename>meta/</filename></title>
+
+        <para>
+            This directory contains the OpenEmbedded Core metadata.
+            The directory holds recipes, common classes, and machine
+            configuration for emulated targets (<filename>qemux86</filename>,
+            <filename>qemuarm</filename>, and so forth.)
+        </para>
+    </section>
+
+    <section id='structure-core-meta-yocto'>
+        <title><filename>meta-yocto/</filename></title>
+
+        <para>
+            This directory contains the configuration for the Poky
+            reference distribution.
+        </para>
+    </section>
+
+    <section id='structure-core-meta-yocto-bsp'>
+        <title><filename>meta-yocto-bsp/</filename></title>
+
+        <para>
+            This directory contains the Yocto Project reference
+            hardware Board Support Packages (BSPs).
+            For more information on BSPs, see the
+            <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support
+            Package (BSP) Developer's Guide</ulink>.
+        </para>
+    </section>
+
+    <section id='structure-meta-hob'>
+        <title><filename>meta-hob/</filename></title>
+
+        <para>
+            This directory contains template recipes used by Hob,
+            which is a Yocto Project build user interface.
+            For more information on the Hob, see the
+            <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>Hob Project</ulink>
+            web page.
+        </para>
+    </section>
+
+    <section id='structure-meta-skeleton'>
+        <title><filename>meta-skeleton/</filename></title>
+
+        <para>
+            This directory contains template recipes for BSP and kernel development.
+        </para>
+    </section>
+
+    <section id='structure-core-scripts'>
+        <title><filename>scripts/</filename></title>
+
+        <para>
+            This directory contains various integration scripts that implement
+            extra functionality in the Yocto Project environment (e.g. QEMU scripts).
+            The <link linkend="structure-core-script"><filename>&OE_INIT_FILE;</filename></link>
+            and
+            <link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>
+            scripts append this directory to the shell's
+            <filename>PATH</filename> environment variable.
+        </para>
+
+        <para>
+            The <filename>scripts</filename> directory has useful scripts that assist in contributing
+            back to the Yocto Project, such as <filename>create-pull-request</filename> and
+            <filename>send-pull-request</filename>.
+        </para>
+    </section>
+
+    <section id='structure-core-script'>
+        <title><filename>&OE_INIT_FILE;</filename></title>
+
+        <para>
+            This script is one of two scripts that set up the OpenEmbedded build
+            environment.
+            For information on the other script, see the
+            "<link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>"
+            section.
+        </para>
+
+        <para>
+            Running this script with the <filename>source</filename> command in
+            a shell makes changes to <filename>PATH</filename> and sets other
+            core BitBake variables based on the current working directory.
+            You need to run an environment setup script before running BitBake
+            commands.
+            The script uses other scripts within the
+            <filename>scripts</filename> directory to do the bulk of the work.
+        </para>
+
+        <para>
+            By default, running this script without a
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+            argument creates the <filename>build</filename> directory
+            in your current working directory.
+            If you provide a Build Directory argument when you
+            <filename>source</filename> the script, you direct the OpenEmbedded
+            build system to create a Build Directory of your choice.
+            For example, the following command creates a Build Directory named
+            <filename>mybuilds</filename> that is outside of the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>:
+            <literallayout class='monospaced'>
+     $ source &OE_INIT_FILE; ~/mybuilds
+            </literallayout>
+            <note>
+                The OpenEmbedded build system does not support file or directory names that
+                contain spaces.
+                If you attempt to run the <filename>&OE_INIT_FILE;</filename> script
+                from a Source Directory that contains spaces in either the filenames
+                or directory names, the script returns an error indicating no such
+                file or directory.
+                Be sure to use a Source Directory free of names containing spaces.
+            </note>
+        </para>
+    </section>
+
+    <section id='structure-memres-core-script'>
+        <title><filename>oe-init-build-env-memres</filename></title>
+
+        <para>
+            This script is one of two scripts that set up the OpenEmbedded
+            build environment.
+            Aside from setting up the environment, this script starts a
+            memory-resident BitBake server.
+            For information on the other setup script, see the
+            "<link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>"
+            section.
+        </para>
+
+        <para>
+            Memory-resident BitBake resides in memory until you specifically
+            remove it using the following BitBake command:
+            <literallayout class='monospaced'>
+     $ bitbake -m
+            </literallayout>
+        </para>
+
+        <para>
+            Running this script with the <filename>source</filename> command in
+            a shell makes changes to <filename>PATH</filename> and sets other
+            core BitBake variables based on the current working directory.
+            One of these variables is the
+            <link linkend='var-BBSERVER'><filename>BBSERVER</filename></link>
+            variable, which allows the OpenEmbedded build system to locate
+            the server that is running BitBake.
+        </para>
+
+        <para>
+            You need to run an environment setup script before using BitBake
+            commands.
+            Following is the script syntax:
+            <literallayout class='monospaced'>
+     $ source oe-init-build-env-memres &lt;port_number&gt; &lt;build_dir&gt;
+            </literallayout>
+            The script uses other scripts within the
+            <filename>scripts</filename> directory to do the bulk of the work.
+        </para>
+
+        <para>
+            If you do not provide a port number with the script, the
+            BitBake server at port "12345" is started.
+        </para>
+
+        <para>
+            By default, running this script without a
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+            argument creates a build directory named
+            <filename>build</filename>.
+            If you provide a Build Directory argument when you
+            <filename>source</filename> the script, the Build Directory is
+            created using that name.
+            For example, the following command starts the BitBake server using
+            the default port "12345" and creates a Build Directory named
+            <filename>mybuilds</filename> that is outside of the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>:
+            <literallayout class='monospaced'>
+     $ source oe-init-build-env-memres ~/mybuilds
+            </literallayout>
+            <note>
+                The OpenEmbedded build system does not support file or
+                directory names that contain spaces.
+                If you attempt to run the
+                <filename>oe-init-build-env-memres</filename> script
+                from a Source Directory that contains spaces in either the
+                filenames or directory names, the script returns an error
+                indicating no such file or directory.
+                Be sure to use a Source Directory free of names containing
+                spaces.
+            </note>
+        </para>
+    </section>
+
+    <section id='structure-basic-top-level'>
+        <title><filename>LICENSE, README, and README.hardware</filename></title>
+
+        <para>
+            These files are standard top-level files.
+        </para>
+    </section>
+</section>
+
+<section id='structure-build'>
+    <title>The Build Directory - <filename>build/</filename></title>
+
+    <para>
+        The OpenEmbedded build system creates the
+        <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+        during the build.
+        By default, this directory is named <filename>build</filename>.
+    </para>
+
+    <section id='structure-build-conf-local.conf'>
+        <title><filename>build/conf/local.conf</filename></title>
+
+        <para>
+            This configuration file contains all the local user configurations
+            for your build environment.
+            The <filename>local.conf</filename> file contains documentation on
+            the various configuration options.
+            Any variable set here overrides any variable set elsewhere within
+            the environment unless that variable is hard-coded within a file
+            (e.g. by using '=' instead of '?=').
+            Some variables are hard-coded for various reasons but these
+            variables are relatively rare.
+        </para>
+
+        <para>
+            Edit this file to set the
+            <filename><link linkend='var-MACHINE'>MACHINE</link></filename>
+            for which you want to build, which package types you wish to use
+            (<link linkend='var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></link>),
+            the location from which you want to access downloaded files
+            (<filename><link linkend='var-DL_DIR'>DL_DIR</link></filename>),
+            and how you want your host machine to use resources
+            (<link linkend='var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></link>
+            and
+            <link linkend='var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></link>).
+        </para>
+
+        <para>
+            If <filename>local.conf</filename> is not present when you
+            start the build, the OpenEmbedded build system creates it from
+            <filename>local.conf.sample</filename> when
+            you <filename>source</filename> the top-level build environment
+            setup script (i.e.
+            <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
+            or
+            <link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>).
+        </para>
+
+        <para>
+            The source <filename>local.conf.sample</filename> file used
+            depends on the <filename>$TEMPLATECONF</filename> script variable,
+            which defaults to <filename>meta-yocto/conf</filename>
+            when you are building from the Yocto Project development
+            environment and defaults to <filename>meta/conf</filename> when
+            you are building from the OpenEmbedded Core environment.
+            Because the script variable points to the source of the
+            <filename>local.conf.sample</filename> file, this implies that
+            you can configure your build environment from any layer by setting
+            the variable in the top-level build environment setup script as
+            follows:
+            <literallayout class='monospaced'>
+     TEMPLATECONF=&lt;your_layer&gt;/conf
+            </literallayout>
+            Once the build process gets the sample file, it uses
+            <filename>sed</filename> to substitute final
+            <filename>${</filename><link linkend='var-OEROOT'><filename>OEROOT</filename></link><filename>}</filename>
+            values for all <filename>##OEROOT##</filename> values.
+            <note>
+                You can see how the <filename>TEMPLATECONF</filename> variable
+                is used by looking at the
+                <filename>scripts/oe-setup-builddir</filename> script in the
+                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                You can find the Yocto Project version of the
+                <filename>local.conf.sample</filename> file in the
+                <filename>meta-yocto/conf</filename> directory.
+            </note>
+        </para>
+    </section>
+
+    <section id='structure-build-conf-bblayers.conf'>
+        <title><filename>build/conf/bblayers.conf</filename></title>
+
+        <para>
+            This configuration file defines
+            <ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>layers</ulink>,
+            which are directory trees, traversed (or walked) by BitBake.
+            The <filename>bblayers.conf</filename> file uses the
+            <link linkend='var-BBLAYERS'><filename>BBLAYERS</filename></link>
+            variable to list the layers BitBake tries to find, and uses the
+            <link linkend='var-BBLAYERS_NON_REMOVABLE'><filename>BBLAYERS_NON_REMOVABLE</filename></link>
+            variable to list layers that must not be removed.
+        </para>
+
+        <para>
+            If <filename>bblayers.conf</filename> is not present when you
+            start the build, the OpenEmbedded build system creates it from
+            <filename>bblayers.conf.sample</filename> when
+            you <filename>source</filename> the top-level build environment
+            setup script (i.e.
+            <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
+            or
+            <link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>).
+        </para>
+
+        <para>
+            The source <filename>bblayers.conf.sample</filename> file used
+            depends on the <filename>$TEMPLATECONF</filename> script variable,
+            which defaults to <filename>meta-yocto/conf</filename>
+            when you are building from the Yocto Project development
+            environment and defaults to <filename>meta/conf</filename> when
+            you are building from the OpenEmbedded Core environment.
+            Because the script variable points to the source of the
+            <filename>bblayers.conf.sample</filename> file, this implies that
+            you can base your build from any layer by setting the variable in
+            the top-level build environment setup script as follows:
+            <literallayout class='monospaced'>
+     TEMPLATECONF=&lt;your_layer&gt;/conf
+            </literallayout>
+            Once the build process gets the sample file, it uses
+            <filename>sed</filename> to substitute final
+            <filename>${</filename><link linkend='var-OEROOT'><filename>OEROOT</filename></link><filename>}</filename>
+            values for all <filename>##OEROOT##</filename> values.
+            <note>
+                You can see how the <filename>TEMPLATECONF</filename> variable
+                <filename>scripts/oe-setup-builddir</filename> script in the
+                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                You can find the Yocto Project version of the
+                <filename>bblayers.conf.sample</filename> file in the
+                <filename>meta-yocto/conf</filename> directory.
+            </note>
+        </para>
+    </section>
+
+    <section id='structure-build-conf-sanity_info'>
+        <title><filename>build/conf/sanity_info</filename></title>
+
+        <para>
+            This file indicates the state of the sanity checks and is created
+            during the build.
+        </para>
+    </section>
+
+    <section id='structure-build-downloads'>
+        <title><filename>build/downloads/</filename></title>
+
+        <para>
+            This directory contains downloaded upstream source tarballs.
+            You can reuse the directory for multiple builds or move
+            the directory to another location.
+            You can control the location of this directory through the
+            <filename><link linkend='var-DL_DIR'>DL_DIR</link></filename> variable.
+        </para>
+    </section>
+
+    <section id='structure-build-sstate-cache'>
+        <title><filename>build/sstate-cache/</filename></title>
+
+        <para>
+            This directory contains the shared state cache.
+            You can reuse the directory for multiple builds or move
+            the directory to another location.
+            You can control the location of this directory through the
+            <filename><link linkend='var-SSTATE_DIR'>SSTATE_DIR</link></filename> variable.
+        </para>
+    </section>
+
+    <section id='structure-build-tmp'>
+        <title><filename>build/tmp/</filename></title>
+
+        <para>
+            This directory receives all of the OpenEmbedded build system's output.
+            BitBake creates this directory if it does not exist.
+            As a last resort, to clean up a build and start it from scratch (other than the downloads),
+            you can remove everything in the <filename>tmp</filename> directory or get rid of the
+            directory completely.
+            If you do, you should also completely remove the
+            <filename>build/sstate-cache</filename> directory.
+        </para>
+    </section>
+
+    <section id='structure-build-tmp-buildstats'>
+        <title><filename>build/tmp/buildstats/</filename></title>
+
+        <para>
+            This directory stores the build statistics.
+        </para>
+    </section>
+
+    <section id='structure-build-tmp-cache'>
+        <title><filename>build/tmp/cache/</filename></title>
+
+        <para>
+            When BitBake parses the metadata, it creates a cache file of the result that can
+            be used when subsequently running commands.
+            BitBake stores these results here on a per-machine basis.
+        </para>
+    </section>
+
+    <section id='structure-build-tmp-deploy'>
+        <title><filename>build/tmp/deploy/</filename></title>
+
+        <para>
+            This directory contains any "end result" output from the
+            OpenEmbedded build process.
+            The <link linkend='var-DEPLOY_DIR'><filename>DEPLOY_DIR</filename></link>
+            variable points to this directory.
+            For more detail on the contents of the <filename>deploy</filename>
+            directory, see the
+            "<link linkend='images-dev-environment'>Images</link>" and
+            "<link linkend='sdk-dev-environment'>Application Development SDK</link>"
+            sections.
+        </para>
+    </section>
+
+    <section id='structure-build-tmp-deploy-deb'>
+        <title><filename>build/tmp/deploy/deb/</filename></title>
+
+        <para>
+            This directory receives any <filename>.deb</filename> packages produced by
+            the build process.
+            The packages are sorted into feeds for different architecture types.
+        </para>
+    </section>
+
+    <section id='structure-build-tmp-deploy-rpm'>
+        <title><filename>build/tmp/deploy/rpm/</filename></title>
+
+        <para>
+            This directory receives any <filename>.rpm</filename> packages produced by
+            the build process.
+            The packages are sorted into feeds for different architecture types.
+        </para>
+    </section>
+
+    <section id='structure-build-tmp-deploy-ipk'>
+        <title><filename>build/tmp/deploy/ipk/</filename></title>
+
+        <para>
+            This directory receives <filename>.ipk</filename> packages produced by
+            the build process.
+        </para>
+    </section>
+
+    <section id='structure-build-tmp-deploy-licenses'>
+        <title><filename>build/tmp/deploy/licenses/</filename></title>
+
+        <para>
+            This directory receives package licensing information.
+            For example, the directory contains sub-directories for <filename>bash</filename>,
+            <filename>busybox</filename>, and <filename>eglibc</filename> (among others) that in turn
+            contain appropriate <filename>COPYING</filename> license files with other licensing information.
+            For information on licensing, see the
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle'>Maintaining Open Source License Compliance During Your Product's Lifecycle</ulink>"
+            section.
+        </para>
+    </section>
+
+    <section id='structure-build-tmp-deploy-images'>
+        <title><filename>build/tmp/deploy/images/</filename></title>
+
+        <para>
+            This directory receives complete filesystem images.
+            If you want to flash the resulting image from a build onto a device, look here for the image.
+        </para>
+
+        <para>
+            Be careful when deleting files in this directory.
+            You can safely delete old images from this directory (e.g.
+            <filename>core-image-*</filename>, <filename>hob-image-*</filename>,
+            etc.).
+            However, the kernel (<filename>*zImage*</filename>, <filename>*uImage*</filename>, etc.),
+            bootloader and other supplementary files might be deployed here prior to building an
+            image.
+            Because these files are not directly produced from the image, if you
+            delete them they will not be automatically re-created when you build the image again.
+        </para>
+
+        <para>
+            If you do accidentally delete files here, you will need to force them to be
+            re-created.
+            In order to do that, you will need to know the target that produced them.
+            For example, these commands rebuild and re-create the kernel files:
+            <literallayout class='monospaced'>
+     $ bitbake -c clean virtual/kernel
+     $ bitbake virtual/kernel
+            </literallayout>
+        </para>
+    </section>
+
+    <section id='structure-build-tmp-sysroots'>
+        <title><filename>build/tmp/sysroots/</filename></title>
+
+        <para>
+            This directory contains shared header files and libraries as well as other shared
+            data.
+            Packages that need to share output with other packages do so within this directory.
+            The directory is subdivided by architecture so multiple builds can run within
+            the one Build Directory.
+        </para>
+    </section>
+
+    <section id='structure-build-tmp-stamps'>
+        <title><filename>build/tmp/stamps/</filename></title>
+
+        <para>
+            This directory holds information that BitBake uses for accounting purposes
+            to track what tasks have run and when they have run.
+            The directory is sub-divided by architecture, package name, and
+            version.
+            Following is an example:
+            <literallayout class='monospaced'>
+     stamps/all-poky-linux/distcc-config/1.0-r0.do_build-2fdd....2do
+            </literallayout>
+            Although the files in the directory are empty of data,
+            BitBake uses the filenames and timestamps for tracking purposes.
+        </para>
+    </section>
+
+    <section id='structure-build-tmp-log'>
+        <title><filename>build/tmp/log/</filename></title>
+
+        <para>
+            This directory contains general logs that are not otherwise placed using the
+            package's <filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>.
+            Examples of logs are the output from the <filename>check_pkg</filename> or
+            <filename>distro_check</filename> tasks.
+            Running a build does not necessarily mean this directory is created.
+        </para>
+    </section>
+
+    <section id='structure-build-tmp-work'>
+        <title><filename>build/tmp/work/</filename></title>
+
+        <para>
+            This directory contains architecture-specific work sub-directories
+            for packages built by BitBake.
+            All tasks execute from the appropriate work directory.
+            For example, the source for a particular package is unpacked,
+            patched, configured and compiled all within its own work directory.
+            Within the work directory, organization is based on the package group
+            and version for which the source is being compiled
+            as defined by the
+            <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>.
+        </para>
+
+        <para>
+            It is worth considering the structure of a typical work directory.
+            As an example, consider <filename>linux-yocto-kernel-3.0</filename>
+            on the machine <filename>qemux86</filename>
+            built within the Yocto Project.
+            For this package, a work directory of
+            <filename>tmp/work/qemux86-poky-linux/linux-yocto/3.0+git1+&lt;.....&gt;</filename>,
+            referred to as the
+            <filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>, is created.
+            Within this directory, the source is unpacked to
+            <filename>linux-qemux86-standard-build</filename> and then patched by Quilt.
+            (See the
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#using-a-quilt-workflow'>Using a Quilt Flow</ulink>"
+            section in the Yocto Project Development Manual for more information.)
+            Within the <filename>linux-qemux86-standard-build</filename> directory,
+            standard Quilt directories <filename>linux-3.0/patches</filename>
+            and <filename>linux-3.0/.pc</filename> are created,
+            and standard Quilt commands can be used.
+        </para>
+
+        <para>
+            There are other directories generated within <filename>WORKDIR</filename>.
+            The most important directory is <filename>WORKDIR/temp/</filename>,
+            which has log files for each task (<filename>log.do_*.pid</filename>)
+            and contains the scripts BitBake runs for each task
+            (<filename>run.do_*.pid</filename>).
+            The <filename>WORKDIR/image/</filename> directory is where "make
+            install" places its output that is then split into sub-packages
+            within <filename>WORKDIR/packages-split/</filename>.
+        </para>
+    </section>
+</section>
+
+<section id='structure-meta'>
+    <title>The Metadata - <filename>meta/</filename></title>
+
+    <para>
+        As mentioned previously,
+        <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink> is the core
+        of the Yocto Project.
+        Metadata has several important subdivisions:
+    </para>
+
+    <section id='structure-meta-classes'>
+        <title><filename>meta/classes/</filename></title>
+
+        <para>
+            This directory contains the <filename>*.bbclass</filename> files.
+            Class files are used to abstract common code so it can be reused by multiple
+            packages.
+            Every package inherits the <filename>base.bbclass</filename> file.
+            Examples of other important classes are <filename>autotools.bbclass</filename>, which
+            in theory allows any Autotool-enabled package to work with the Yocto Project with minimal effort.
+            Another example is <filename>kernel.bbclass</filename> that contains common code and functions
+            for working with the Linux kernel.
+            Functions like image generation or packaging also have their specific class files
+            such as <filename>image.bbclass</filename>, <filename>rootfs_*.bbclass</filename> and
+            <filename>package*.bbclass</filename>.
+        </para>
+
+        <para>
+            For reference information on classes, see the
+            "<link linkend='ref-classes'>Classes</link>" chapter.
+        </para>
+    </section>
+
+    <section id='structure-meta-conf'>
+        <title><filename>meta/conf/</filename></title>
+
+        <para>
+            This directory contains the core set of configuration files that start from
+            <filename>bitbake.conf</filename> and from which all other configuration
+            files are included.
+            See the include statements at the end of the
+            <filename>bitbake.conf</filename> file and you will note that even
+            <filename>local.conf</filename> is loaded from there.
+            While <filename>bitbake.conf</filename> sets up the defaults, you can often override
+            these by using the (<filename>local.conf</filename>) file, machine file or
+            the distribution configuration file.
+        </para>
+    </section>
+
+    <section id='structure-meta-conf-machine'>
+        <title><filename>meta/conf/machine/</filename></title>
+
+        <para>
+            This directory contains all the machine configuration files.
+            If you set <filename>MACHINE = "qemux86"</filename>,
+            the OpenEmbedded build system looks for a <filename>qemux86.conf</filename> file in this
+            directory.
+            The <filename>include</filename> directory contains various data common to multiple machines.
+            If you want to add support for a new machine to the Yocto Project, look in this directory.
+        </para>
+    </section>
+
+    <section id='structure-meta-conf-distro'>
+        <title><filename>meta/conf/distro/</filename></title>
+
+        <para>
+            The contents of this directory controls any distribution-specific
+            configurations.
+            For the Yocto Project, the <filename>defaultsetup.conf</filename> is the main file here.
+            This directory includes the versions and the
+            <filename>SRCDATE</filename> definitions for applications that are configured here.
+            An example of an alternative configuration might be <filename>poky-bleeding.conf</filename>.
+            Although this file mainly inherits its configuration from Poky.
+        </para>
+    </section>
+
+    <section id='structure-meta-files'>
+        <title><filename>meta/files/</filename></title>
+
+        <para>
+            This directory contains common license files and several text files
+            used by the build system.
+            The text files contain minimal device information and
+            lists of files and directories with knows permissions.
+        </para>
+    </section>
+
+    <section id='structure-meta-lib'>
+        <title><filename>meta/lib/</filename></title>
+
+        <para>
+            This directory contains OpenEmbedded Python library code
+            used during the build process.
+        </para>
+    </section>
+
+    <section id='structure-meta-recipes-bsp'>
+        <title><filename>meta/recipes-bsp/</filename></title>
+
+        <para>
+            This directory contains anything linking to specific hardware or hardware
+            configuration information such as "u-boot" and "grub".
+        </para>
+    </section>
+
+    <section id='structure-meta-recipes-connectivity'>
+        <title><filename>meta/recipes-connectivity/</filename></title>
+
+        <para>
+            This directory contains libraries and applications related to communication with other devices.
+        </para>
+    </section>
+
+    <section id='structure-meta-recipes-core'>
+        <title><filename>meta/recipes-core/</filename></title>
+
+        <para>
+            This directory contains what is needed to build a basic working Linux image
+            including commonly used dependencies.
+        </para>
+    </section>
+
+    <section id='structure-meta-recipes-devtools'>
+        <title><filename>meta/recipes-devtools/</filename></title>
+
+        <para>
+            This directory contains tools that are primarily used by the build system.
+            The tools, however, can also be used on targets.
+        </para>
+    </section>
+
+    <section id='structure-meta-recipes-extended'>
+        <title><filename>meta/recipes-extended/</filename></title>
+
+        <para>
+            This directory contains non-essential applications that add features compared to the
+            alternatives in core.
+            You might need this directory for full tool functionality or for Linux Standard Base (LSB)
+            compliance.
+        </para>
+    </section>
+
+    <section id='structure-meta-recipes-gnome'>
+        <title><filename>meta/recipes-gnome/</filename></title>
+
+        <para>
+            This directory contains all things related to the GTK+ application framework.
+        </para>
+    </section>
+
+    <section id='structure-meta-recipes-graphics'>
+        <title><filename>meta/recipes-graphics/</filename></title>
+
+        <para>
+            This directory contains X and other graphically related system libraries
+        </para>
+    </section>
+
+    <section id='structure-meta-recipes-kernel'>
+        <title><filename>meta/recipes-kernel/</filename></title>
+
+        <para>
+            This directory contains the kernel and generic applications and libraries that
+            have strong kernel dependencies.
+        </para>
+    </section>
+
+    <section id='structure-meta-recipes-lsb4'>
+        <title><filename>meta/recipes-lsb4/</filename></title>
+
+        <para>
+            This directory contains recipes specifically added to support
+            the Linux Standard Base (LSB) version 4.x.
+        </para>
+    </section>
+
+    <section id='structure-meta-recipes-multimedia'>
+        <title><filename>meta/recipes-multimedia/</filename></title>
+
+        <para>
+            This directory contains codecs and support utilities for audio, images and video.
+        </para>
+    </section>
+
+    <section id='structure-meta-recipes-qt'>
+        <title><filename>meta/recipes-qt/</filename></title>
+
+        <para>
+            This directory contains all things related to the Qt application framework.
+        </para>
+    </section>
+
+    <section id='structure-meta-recipes-rt'>
+        <title><filename>meta/recipes-rt/</filename></title>
+
+        <para>
+            This directory contains package and image recipes for using and testing
+            the <filename>PREEMPT_RT</filename> kernel.
+        </para>
+    </section>
+
+    <section id='structure-meta-recipes-sato'>
+        <title><filename>meta/recipes-sato/</filename></title>
+
+        <para>
+            This directory contains the Sato demo/reference UI/UX and its associated applications
+            and configuration data.
+        </para>
+    </section>
+
+    <section id='structure-meta-recipes-support'>
+        <title><filename>meta/recipes-support/</filename></title>
+
+        <para>
+            This directory contains recipes used by other recipes, but that are
+            not directly included in images (i.e. dependencies of other
+            recipes).
+        </para>
+    </section>
+
+    <section id='structure-meta-site'>
+        <title><filename>meta/site/</filename></title>
+
+        <para>
+            This directory contains a list of cached results for various architectures.
+            Because certain "autoconf" test results cannot be determined when cross-compiling due to
+            the tests not able to run on a live system, the information in this directory is
+            passed to "autoconf" for the various architectures.
+        </para>
+    </section>
+
+    <section id='structure-meta-recipes-txt'>
+        <title><filename>meta/recipes.txt</filename></title>
+
+        <para>
+            This file is a description of the contents of <filename>recipes-*</filename>.
+        </para>
+    </section>
+</section>
+
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/ref-manual/ref-style.css b/documentation/ref-manual/ref-style.css
new file mode 100644
index 0000000..e896a39
--- /dev/null
+++ b/documentation/ref-manual/ref-style.css
@@ -0,0 +1,979 @@
+/* 
+   Generic XHTML / DocBook XHTML CSS Stylesheet.
+   
+   Browser wrangling and typographic design by
+      Oyvind Kolas / pippin@gimp.org
+
+   Customised for Poky by
+      Matthew Allum / mallum@o-hand.com
+
+   Thanks to:
+     Liam R. E. Quin
+     William Skaggs
+     Jakub Steiner
+
+   Structure
+   ---------
+
+   The stylesheet is divided into the following sections:
+
+       Positioning
+          Margins, paddings, width, font-size, clearing.
+       Decorations
+          Borders, style
+       Colors
+          Colors
+       Graphics
+          Graphical backgrounds
+       Nasty IE tweaks
+          Workarounds needed to make it work in internet explorer,
+          currently makes the stylesheet non validating, but up until
+          this point it is validating.
+       Mozilla extensions
+          Transparency for footer
+          Rounded corners on boxes
+
+*/
+
+
+  /*************** /
+ /  Positioning   /
+/ ***************/
+
+body {
+  font-family: Verdana, Sans, sans-serif;
+ 
+  min-width: 640px;
+  width: 80%;
+  margin:  0em auto;
+  padding: 2em 5em 5em 5em;
+  color: #333;
+}
+
+h1,h2,h3,h4,h5,h6,h7 {
+  font-family: Arial, Sans;
+  color: #00557D;
+  clear: both;
+}
+
+h1 {
+  font-size: 2em;
+  text-align: left;
+  padding: 0em 0em 0em 0em;
+  margin: 2em 0em 0em 0em;
+}
+
+h2.subtitle {
+  margin: 0.10em 0em 3.0em 0em;
+  padding: 0em 0em 0em 0em;
+  font-size: 1.8em;
+  padding-left: 20%;
+  font-weight: normal;
+  font-style: italic;
+}
+
+h2 {
+  margin: 2em 0em 0.66em 0em;
+  padding: 0.5em 0em 0em 0em;
+  font-size: 1.5em;
+  font-weight: bold;
+}
+
+h3.subtitle {
+  margin: 0em 0em 1em 0em;
+  padding: 0em 0em 0em 0em;
+  font-size: 142.14%;
+  text-align: right;
+}
+
+h3 {
+  margin: 1em 0em 0.5em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 140%;
+  font-weight: bold;
+}
+
+h4 {
+  margin: 1em 0em 0.5em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 120%;
+  font-weight: bold;
+}
+
+h5 {
+  margin: 1em 0em 0.5em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 110%;
+  font-weight: bold;
+}
+
+h6 {
+  margin: 1em 0em 0em 0em;
+  padding: 1em 0em 0em 0em;
+  font-size: 110%;
+  font-weight: bold;
+}
+
+.authorgroup {
+  background-color: transparent;
+  background-repeat: no-repeat;
+  padding-top: 256px;
+  background-image: url("figures/poky-title.png");
+  background-position: left top;
+  margin-top: -256px;
+  padding-right: 50px;
+  margin-left: 0px;
+  text-align: right;
+  width: 740px;
+}
+
+h3.author {
+  margin: 0em 0me 0em 0em;
+  padding: 0em 0em 0em 0em;
+  font-weight: normal;
+  font-size: 100%;
+  color: #333;
+  clear: both;
+}
+
+.author tt.email {
+  font-size: 66%;
+}
+
+.titlepage hr {
+  width: 0em;
+  clear: both;
+}
+
+.revhistory {
+  padding-top: 2em;
+  clear: both;
+}
+
+.toc,
+.list-of-tables,
+.list-of-examples,
+.list-of-figures {
+  padding: 1.33em 0em 2.5em 0em;
+  color: #00557D;
+}
+
+.toc p,
+.list-of-tables p,
+.list-of-figures p,
+.list-of-examples p {
+  padding: 0em 0em 0em 0em;
+  padding: 0em 0em 0.3em;
+  margin: 1.5em 0em 0em 0em;
+}
+
+.toc p b,
+.list-of-tables p b,
+.list-of-figures p b,
+.list-of-examples p b{
+  font-size: 100.0%;
+  font-weight: bold;
+}
+
+.toc dl,
+.list-of-tables dl,
+.list-of-figures dl,
+.list-of-examples dl {
+  margin: 0em 0em 0.5em 0em;
+  padding: 0em 0em 0em 0em;
+}
+
+.toc dt {
+  margin: 0em 0em 0em 0em;
+  padding: 0em 0em 0em 0em;
+}
+
+.toc dd {
+  margin: 0em 0em 0em 2.6em;
+  padding: 0em 0em 0em 0em;
+}
+
+div.glossary dl,
+div.variablelist dl {
+}
+
+.glossary dl dt,
+.variablelist dl dt,
+.variablelist dl dt span.term {
+  font-weight: normal;
+  width: 20em;
+  text-align: right;
+}
+
+.variablelist dl dt {
+  margin-top: 0.5em;
+}
+
+.glossary dl dd,
+.variablelist dl dd {
+  margin-top: -1em;
+  margin-left: 25.5em;
+}
+
+.glossary dd p,
+.variablelist dd p {
+  margin-top: 0em;
+  margin-bottom: 1em;
+}
+
+
+div.calloutlist table td {
+  padding: 0em 0em 0em 0em;
+  margin: 0em 0em 0em 0em;
+}
+
+div.calloutlist table td p {
+  margin-top: 0em;
+  margin-bottom: 1em;
+}
+
+div p.copyright {
+  text-align: left;
+}
+
+div.legalnotice p.legalnotice-title {
+  margin-bottom: 0em;
+}
+
+p {
+  line-height: 1.5em;
+  margin-top: 0em;
+  
+}
+
+dl {
+  padding-top: 0em;
+}
+
+hr {
+  border: solid 1px;
+}
+
+
+.mediaobject,
+.mediaobjectco {
+  text-align: center;
+}
+
+img {
+  border: none;
+}
+
+ul {
+  padding: 0em 0em 0em 1.5em;
+}
+
+ul li {
+  padding: 0em 0em 0em 0em;
+}
+
+ul li p {
+  text-align: left;
+}
+
+table {
+  width :100%;
+}
+
+th {
+  padding: 0.25em;
+  text-align: left;
+  font-weight: normal;
+  vertical-align: top;
+}
+
+td {
+  padding: 0.25em;
+  vertical-align: top;
+}
+
+p a[id] {
+  margin: 0px;
+  padding: 0px;
+  display: inline;
+  background-image: none;
+} 
+
+a {
+  text-decoration: underline;
+  color: #444;
+}
+
+pre {
+    overflow: auto;
+}
+
+a:hover {
+  text-decoration: underline;
+  /*font-weight: bold;*/
+}
+
+
+div.informalfigure,
+div.informalexample,
+div.informaltable,
+div.figure,
+div.table,
+div.example {
+  margin: 1em 0em;
+  padding: 1em;
+  page-break-inside: avoid;
+}
+
+
+div.informalfigure p.title b,
+div.informalexample p.title b,
+div.informaltable p.title b,
+div.figure p.title b,
+div.example p.title b,
+div.table p.title b{
+    padding-top: 0em;
+    margin-top: 0em;
+    font-size: 100%;
+    font-weight: normal;
+}
+
+.mediaobject .caption, 
+.mediaobject .caption p  {
+  text-align: center;
+  font-size: 80%;  
+  padding-top: 0.5em;
+  padding-bottom: 0.5em;
+}
+
+.epigraph {
+  padding-left: 55%;
+  margin-bottom: 1em;
+}
+
+.epigraph p {
+  text-align: left;
+}
+
+.epigraph .quote {
+  font-style: italic;
+}
+.epigraph .attribution {
+  font-style: normal;
+  text-align: right;
+}
+
+span.application {
+  font-style: italic;
+}
+
+.programlisting {
+  font-family: monospace;
+  font-size: 80%;
+  white-space: pre;
+  margin: 1.33em 0em;
+  padding: 1.33em;
+}
+
+.tip,
+.warning,
+.caution,
+.note {
+  margin-top: 1em;
+  margin-bottom: 1em;
+
+}
+
+/* force full width of table within div */
+.tip table,
+.warning table,
+.caution table,
+.note table {
+  border: none;
+  width: 100%;
+}
+
+
+.tip table th,
+.warning table th,
+.caution table th,
+.note table th {
+  padding: 0.8em 0.0em 0.0em 0.0em;
+  margin : 0em 0em 0em 0em;
+}
+
+.tip p,
+.warning p,
+.caution p,
+.note p {
+  margin-top: 0.5em;
+  margin-bottom: 0.5em;
+  padding-right: 1em;
+  text-align: left;
+}
+
+.acronym {
+  text-transform: uppercase;
+}
+
+b.keycap,
+.keycap {
+  padding: 0.09em 0.3em;
+  margin: 0em;
+}
+
+.itemizedlist li {
+  clear: none;
+}
+
+.filename {
+  font-size: medium;
+  font-family: Courier, monospace;
+}
+
+
+div.navheader, div.heading{
+  position: absolute;
+  left: 0em;
+  top: 0em;
+  width: 100%;
+  background-color: #cdf;
+  width: 100%;
+}
+
+div.navfooter, div.footing{
+  position: fixed;
+  left: 0em;
+  bottom: 0em;
+  background-color: #eee;
+  width: 100%;
+}
+
+
+div.navheader td,
+div.navfooter td {
+  font-size: 66%;
+}
+
+div.navheader table th {
+  /*font-family: Georgia, Times, serif;*/
+  /*font-size: x-large;*/
+  font-size: 80%;
+}
+
+div.navheader table {
+  border-left: 0em;
+  border-right: 0em;
+  border-top: 0em;
+  width: 100%;
+}
+
+div.navfooter table {
+  border-left: 0em;
+  border-right: 0em;
+  border-bottom: 0em;
+  width: 100%;
+}
+
+div.navheader table td a,
+div.navfooter table td a {
+  color: #777;
+  text-decoration: none;
+}
+
+/* normal text in the footer */
+div.navfooter table td {
+  color: black;
+}
+
+div.navheader table td a:visited,
+div.navfooter table td a:visited {
+  color: #444;
+}
+
+
+/* links in header and footer */
+div.navheader table td a:hover,
+div.navfooter table td a:hover {
+  text-decoration: underline;
+  background-color: transparent;
+  color: #33a;
+}
+
+div.navheader hr,
+div.navfooter hr {
+  display: none;
+}
+
+
+.qandaset tr.question td p {
+  margin: 0em 0em 1em 0em;
+  padding: 0em 0em 0em 0em;
+}
+
+.qandaset tr.answer td p {
+  margin: 0em 0em 1em 0em;
+  padding: 0em 0em 0em 0em;
+}
+.answer td {
+  padding-bottom: 1.5em;
+}
+
+.emphasis {
+  font-weight: bold;
+}
+
+
+  /************* /
+ / decorations  /
+/ *************/
+
+.titlepage {
+}
+
+.part .title {
+}
+
+.subtitle {
+    border: none;
+}
+
+/*
+h1 {
+  border: none;
+}
+
+h2 {
+  border-top: solid 0.2em;
+  border-bottom: solid 0.06em;
+}
+
+h3 {
+  border-top: 0em;
+  border-bottom: solid 0.06em;
+}
+
+h4 {
+  border: 0em;
+  border-bottom: solid 0.06em;
+}
+
+h5 {
+  border: 0em;
+}
+*/
+
+.programlisting {
+  border: solid 1px;
+}
+
+div.figure,
+div.table,
+div.informalfigure,
+div.informaltable,
+div.informalexample,
+div.example {
+  border: 1px solid;
+}
+
+
+
+.tip,
+.warning,
+.caution,
+.note {
+  border: 1px solid;
+}
+
+.tip table th,
+.warning table th,
+.caution table th,
+.note table th {
+  border-bottom: 1px solid;
+}
+
+.question td {
+  border-top: 1px solid black;
+}
+
+.answer {
+}
+
+
+b.keycap,
+.keycap {
+  border: 1px solid;
+}
+  
+
+div.navheader, div.heading{
+  border-bottom: 1px solid;
+}
+
+
+div.navfooter, div.footing{
+  border-top: 1px solid;
+}
+
+  /********* /
+ /  colors  /
+/ *********/
+
+body {
+  color: #333;
+  background: white;
+}
+
+a {
+  background: transparent;
+}
+
+a:hover {
+  background-color: #dedede;
+}
+
+
+h1,
+h2,
+h3,
+h4,
+h5,
+h6,
+h7,
+h8 {
+  background-color: transparent;
+}
+
+hr {
+  border-color: #aaa;
+}
+
+
+.tip, .warning, .caution, .note {
+  border-color: #fff;
+}
+
+
+.tip table th,
+.warning table th,
+.caution table th,
+.note table th {
+  border-bottom-color: #fff;
+}
+
+
+.warning {
+  background-color: #f0f0f2;
+}
+
+.caution {
+  background-color: #f0f0f2;
+}
+
+.tip {
+  background-color: #f0f0f2;
+}
+
+.note {
+  background-color: #f0f0f2; 
+}
+
+.glossary dl dt, 
+.variablelist dl dt,
+.variablelist dl dt span.term {
+  color: #044;
+}
+
+div.figure,
+div.table,
+div.example,
+div.informalfigure,
+div.informaltable,
+div.informalexample {
+  border-color: #aaa;
+}
+
+pre.programlisting {
+  color: black;
+  background-color: #fff;
+  border-color: #aaa;
+  border-width: 2px;
+}
+
+.guimenu,
+.guilabel,
+.guimenuitem {
+  background-color: #eee;
+}
+
+
+b.keycap,
+.keycap {
+  background-color: #eee;
+  border-color: #999;
+}
+
+
+div.navheader {
+  border-color: black;
+}
+
+
+div.navfooter {
+  border-color: black;
+}
+
+
+  /*********** /
+ /  graphics  /
+/ ***********/
+
+/*
+body {
+  background-image: url("images/body_bg.jpg");
+  background-attachment: fixed;
+}
+
+.navheader,
+.note,
+.tip {
+  background-image: url("images/note_bg.jpg");
+  background-attachment: fixed;
+}
+
+.warning,
+.caution {
+  background-image: url("images/warning_bg.jpg");
+  background-attachment: fixed;
+}
+
+.figure,
+.informalfigure,
+.example,
+.informalexample,
+.table,
+.informaltable {
+  background-image: url("images/figure_bg.jpg");
+  background-attachment: fixed;
+}
+
+*/
+h1,
+h2,
+h3,
+h4,
+h5,
+h6,
+h7{
+}
+
+/*
+Example of how to stick an image as part of the title.
+
+div.article .titlepage .title
+{
+  background-image: url("figures/white-on-black.png");
+  background-position: center;
+  background-repeat: repeat-x;
+}
+*/
+
+div.preface .titlepage .title, 
+div.colophon .title, 
+div.chapter .titlepage .title,
+div.article .titlepage .title 
+{
+}
+
+div.section div.section .titlepage .title,
+div.sect2 .titlepage .title {
+    background: none;
+}
+
+
+h1.title {
+  background-color: transparent;
+  background-image: url("figures/poky-title.png");
+  background-repeat: no-repeat;
+  height: 256px;
+  text-indent: -9000px;
+  overflow:hidden;
+}
+
+h2.subtitle {
+  background-color: transparent;
+  text-indent: -9000px;
+  overflow:hidden;
+  width: 0px;
+  display: none;
+}
+
+  /*************************************** /
+ /  pippin.gimp.org specific alterations  /
+/ ***************************************/
+
+/*
+div.heading, div.navheader {
+  color: #777;
+  font-size: 80%;
+  padding: 0;
+  margin: 0;
+  text-align: left;
+  position: absolute;
+  top: 0px;
+  left: 0px;
+  width: 100%;
+  height: 50px;
+  background: url('/gfx/heading_bg.png') transparent;
+  background-repeat: repeat-x;
+  background-attachment: fixed;
+  border: none;
+}
+
+div.heading a {
+  color: #444;
+}
+
+div.footing, div.navfooter {
+  border: none;
+  color: #ddd;
+  font-size: 80%;
+  text-align:right;
+
+  width: 100%;
+  padding-top: 10px;
+  position: absolute;
+  bottom: 0px;
+  left: 0px;
+
+  background: url('/gfx/footing_bg.png') transparent;
+}
+*/
+
+
+
+  /****************** /
+ /  nasty ie tweaks  /
+/ ******************/
+
+/*
+div.heading, div.navheader {
+  width:expression(document.body.clientWidth + "px");
+}
+
+div.footing, div.navfooter {
+  width:expression(document.body.clientWidth + "px");
+  margin-left:expression("-5em");
+}
+body {
+  padding:expression("4em 5em 0em 5em");
+}
+*/
+
+  /**************************************** /
+ / mozilla vendor specific css extensions  /
+/ ****************************************/
+/*
+div.navfooter, div.footing{
+  -moz-opacity: 0.8em;
+}
+
+div.figure,
+div.table,
+div.informalfigure,
+div.informaltable,
+div.informalexample,
+div.example,
+.tip,
+.warning,
+.caution,
+.note {
+  -moz-border-radius: 0.5em;
+}
+
+b.keycap,
+.keycap {
+  -moz-border-radius: 0.3em;
+}
+*/
+
+table tr td table tr td {
+  display: none;
+}
+
+
+hr {
+  display: none;
+}
+
+table {
+  border: 0em;
+}
+
+ .photo {
+  float: right;
+  margin-left:   1.5em;
+  margin-bottom: 1.5em;
+  margin-top: 0em;
+  max-width:      17em;
+  border:     1px solid gray;
+  padding:    3px;
+  background: white;
+}
+ .seperator {
+   padding-top: 2em;
+   clear: both;
+  }
+
+  #validators {
+      margin-top: 5em;
+      text-align: right;
+      color: #777;
+  }
+  @media print {
+      body {
+          font-size: 8pt;
+      }
+      .noprint {
+          display: none;
+      }
+  }
+
+
+.tip,
+.note {
+   background: #f0f0f2; 
+   color: #333;   
+   padding: 20px;
+   margin: 20px;
+}
+
+.tip h3,
+.note h3 {
+   padding: 0em;
+   margin: 0em;
+   font-size: 2em;
+   font-weight: bold;
+   color: #333;   
+}
+
+.tip a,
+.note a {
+   color: #333;   
+   text-decoration: underline;
+}
+
+.footnote {
+   font-size: small;
+   color: #333;
+}
+
+/* Changes the announcement text */
+.tip h3,
+.warning h3,
+.caution h3,
+.note h3 {
+   font-size:large;
+   color: #00557D;
+}
+
diff --git a/documentation/ref-manual/ref-variables.xml b/documentation/ref-manual/ref-variables.xml
new file mode 100644
index 0000000..2b0e890
--- /dev/null
+++ b/documentation/ref-manual/ref-variables.xml
@@ -0,0 +1,5929 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<!-- Dummy chapter -->
+<chapter id='ref-variables-glos'>
+
+<title>Variables Glossary</title>
+
+<para>
+    This chapter lists common variables used in the OpenEmbedded build system and gives an overview
+    of their function and contents.
+</para>
+
+<glossary id='ref-variables-glossary'>
+
+
+    <para>
+       <link linkend='var-ALLOW_EMPTY'>A</link>
+       <link linkend='var-B'>B</link>
+       <link linkend='var-CFLAGS'>C</link>
+       <link linkend='var-D'>D</link>
+       <link linkend='var-ENABLE_BINARY_LOCALE_GENERATION'>E</link>
+       <link linkend='var-FEED_DEPLOYDIR_BASE_URI'>F</link>
+<!--               <link linkend='var-glossary-g'>G</link> -->
+       <link linkend='var-HOMEPAGE'>H</link>
+       <link linkend='var-IMAGE_BASENAME'>I</link>
+<!--               <link linkend='var-glossary-j'>J</link> -->
+       <link linkend='var-KARCH'>K</link>
+       <link linkend='var-LAYERDEPENDS'>L</link>
+       <link linkend='var-MACHINE'>M</link>
+<!--               <link linkend='var-glossary-n'>N</link> -->
+       <link linkend='var-OE_BINCONFIG_EXTRA_MANGLE'>O</link>
+       <link linkend='var-P'>P</link>
+<!--               <link linkend='var-glossary-q'>Q</link> -->
+       <link linkend='var-RCONFLICTS'>R</link>
+       <link linkend='var-S'>S</link>
+       <link linkend='var-T'>T</link>
+       <link linkend='var-UBOOT_ENTRYPOINT'>U</link>
+<!--               <link linkend='var-glossary-v'>V</link> -->
+       <link linkend='var-WARN_QA'>W</link>
+<!--               <link linkend='var-glossary-x'>X</link> -->
+<!--               <link linkend='var-glossary-y'>Y</link> -->
+<!--               <link linkend='var-glossary-z'>Z</link>-->
+    </para>
+
+    <glossdiv id='var-glossary-a'><title>A</title>
+
+         <glossentry id='var-ALLOW_EMPTY'><glossterm>ALLOW_EMPTY</glossterm>
+            <glossdef>
+                <para>
+                   Specifies if an output package should still be produced if it is empty.
+                   By default, BitBake does not produce empty packages.
+                   This default behavior can cause issues when there is an
+                   <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link> or
+                   some other hard runtime requirement on the existence of the package.
+                </para>
+
+                <para>
+                   Like all package-controlling variables, you must always use them in
+                   conjunction with a package name override, as in:
+                   <literallayout class='monospaced'>
+     ALLOW_EMPTY_${PN} = "1"
+     ALLOW_EMPTY_${PN}-dev = "1"
+     ALLOW_EMPTY_${PN}-staticdev = "1"
+                   </literallayout>
+                </para>
+            </glossdef>
+         </glossentry>
+
+         <glossentry id='var-ALTERNATIVE'><glossterm>ALTERNATIVE</glossterm>
+            <glossdef>
+                <para>
+                    Lists commands in a package that need an alternative
+                    binary naming scheme.
+                    Sometimes the same command is provided in multiple packages.
+                    When this occurs, the OpenEmbedded build system needs to
+                    use the alternatives system to create a different binary
+                    naming scheme so the commands can co-exist.
+                </para>
+
+                <para>
+                    To use the variable, list out the package's commands
+                    that also exist as part of another package.
+                    For example, if the <filename>busybox</filename> package
+                    has four commands that also exist as part of another
+                    package, you identify them as follows:
+                    <literallayout class='monospaced'>
+     ALTERNATIVE_busybox = "sh sed test bracket"
+                    </literallayout>
+                    For more information on the alternatives system, see the
+                    "<link linkend='ref-classes-update-alternatives'>Alternatives - <filename>update-alternatives.bbclass</filename></link>"
+                    section.
+                </para>
+            </glossdef>
+         </glossentry>
+
+         <glossentry id='var-ALTERNATIVE_LINK_NAME'><glossterm>ALTERNATIVE_LINK_NAME</glossterm>
+            <glossdef>
+                <para>
+                    Used by the alternatives system to map duplicated commands
+                    to actual locations.
+                    For example, if the <filename>bracket</filename> command
+                    provided by the <filename>busybox</filename> package is
+                    duplicated through another package, you must use the
+                    <filename>ALTERNATIVE_LINK_NAME</filename> variable to
+                    specify the actual location:
+                    <literallayout class='monospaced'>
+     ALTERNATIVE_LINK_NAME[bracket] = "/usr/bin/["
+                    </literallayout>
+                    In this example, the binary for the
+                    <filename>bracket</filename> command (i.e.
+                    <filename>[</filename>) from the
+                    <filename>busybox</filename> package resides in
+                    <filename>/usr/bin/</filename>.
+                    <note>
+                        If <filename>ALTERNATIVE_LINK_NAME</filename> is not
+                        defined, it defaults to
+                        <filename>${bindir}/&lt;name&gt;</filename>.
+                    </note>
+                </para>
+
+                <para>
+                    For more information on the alternatives system, see the
+                    "<link linkend='ref-classes-update-alternatives'>Alternatives - <filename>update-alternatives.bbclass</filename></link>"
+                    section.
+                </para>
+            </glossdef>
+         </glossentry>
+
+         <glossentry id='var-ALTERNATIVE_PRIORITY'><glossterm>ALTERNATIVE_PRIORITY</glossterm>
+            <glossdef>
+                <para>
+                    Used by the alternatives system to create default
+                    priorities for duplicated commands.
+                    You can use the variable to create a single default
+                    regardless of the command name or package, a default for
+                    specific duplicated commands regardless of the package, or
+                    a default for specific commands tied to particular packages.
+                    Here are the available syntax forms:
+                    <literallayout class='monospaced'>
+     ALTERNATIVE_PRIORITY = "&lt;priority&gt;"
+     ALTERNATIVE_PRIORITY[&lt;name&gt;] = "&lt;priority&gt;"
+     ALTERNATIVE_PRIORITY_&lt;pkg&gt;[&lt;name&gt;] = "&lt;priority&gt;"
+                    </literallayout>
+                </para>
+
+                <para>
+                    For more information on the alternatives system, see the
+                    "<link linkend='ref-classes-update-alternatives'>Alternatives - <filename>update-alternatives.bbclass</filename></link>"
+                    section.
+                </para>
+            </glossdef>
+         </glossentry>
+
+         <glossentry id='var-ALTERNATIVE_TARGET'><glossterm>ALTERNATIVE_TARGET</glossterm>
+            <glossdef>
+                <para>
+                    Used by the alternatives system to create default link
+                    locations for duplicated commands.
+                    You can use the variable to create a single default
+                    location for all duplicated commands regardless of the
+                    command name or package, a default for
+                    specific duplicated commands regardless of the package, or
+                    a default for specific commands tied to particular packages.
+                    Here are the available syntax forms:
+                    <literallayout class='monospaced'>
+     ALTERNATIVE_TARGET = "&lt;target&gt;"
+     ALTERNATIVE_TARGET[&lt;name&gt;] = "&lt;target&gt;"
+     ALTERNATIVE_TARGET_&lt;pkg&gt;[&lt;name&gt;] = "&lt;target&gt;"
+                    </literallayout>
+                    <note>
+                        <para>
+                            If <filename>ALTERNATIVE_TARGET</filename> is not
+                            defined, it inherits the value from the
+                            <link linkend='var-ALTERNATIVE_LINK_NAME'><filename>ALTERNATIVE_LINK_NAME</filename></link>
+                            variable.
+                        </para>
+
+                        <para>
+                            If <filename>ALTERNATIVE_LINK_NAME</filename> and
+                            <filename>ALTERNATIVE_TARGET</filename> are the
+                            same, the target for
+                            <filename>ALTERNATIVE_TARGET</filename>
+                            has "<filename>.{BPN}</filename>" appended to it.
+                        </para>
+
+                        <para>
+                            Finally, if the file referenced has not been
+                            renamed, the alternatives system will rename it to
+                            avoid the need to rename alternative files in the
+                            <filename>do_install</filename> task while
+                            retaining support for the command if necessary.
+                        </para>
+                    </note>
+                </para>
+
+                <para>
+                    For more information on the alternatives system, see the
+                    "<link linkend='ref-classes-update-alternatives'>Alternatives - <filename>update-alternatives.bbclass</filename></link>"
+                    section.
+                </para>
+            </glossdef>
+         </glossentry>
+
+         <glossentry id='var-AUTHOR'><glossterm>AUTHOR</glossterm>
+            <glossdef>
+                <para>The email address used to contact the original author
+                    or authors in order to send patches and forward bugs.</para>
+            </glossdef>
+         </glossentry>
+
+        <glossentry id='var-AUTOREV'><glossterm>AUTOREV</glossterm>
+            <glossdef>
+                <para>When <filename><link linkend='var-SRCREV'>SRCREV</link></filename>
+                    is set to the value of this variable, it specifies to use the latest
+                    source revision in the repository.
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     SRCREV = "${AUTOREV}"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+    </glossdiv>
+
+    <glossdiv id='var-glossary-b'><title>B</title>
+
+        <glossentry id='var-B'><glossterm>B</glossterm>
+            <glossdef>
+                <para>
+                    The directory within the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+                    in which the OpenEmbedded build system places generated
+                    objects during a recipe's build process.
+                    By default, this directory is the same as the <link linkend='var-S'><filename>S</filename></link>
+                    directory, which is defined as:
+                    <literallayout class='monospaced'>
+     S = "${WORKDIR}/${BP}/"
+                    </literallayout>
+                    You can separate the (<filename>S</filename>) directory
+                    and the directory pointed to by the <filename>B</filename>
+                    variable.
+                    Most Autotools-based recipes support separating these
+                    directories.
+                    The build system defaults to using separate directories for
+                    <filename>gcc</filename> and some kernel recipes.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BAD_RECOMMENDATIONS'><glossterm>BAD_RECOMMENDATIONS</glossterm>
+            <glossdef>
+                <para>
+                    Lists "recommended-only" packages to not install.
+                    Recommended-only packages are packages installed only
+                    through the
+                    <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>
+                    variable.
+                    You can prevent any of these "recommended" packages from
+                    being installed by listing them with the
+                    <filename>BAD_RECOMMENDATIONS</filename> variable:
+                    <literallayout class='monospaced'>
+     BAD_RECOMMENDATIONS = "&lt;package_name&gt; &lt;package_name&gt; &lt;package_name&gt; ..."
+                    </literallayout>
+                    You can set this variable globally in your
+                    <filename>local.conf</filename> file or you can attach it to
+                    a specific image recipe by using the recipe name override:
+                    <literallayout class='monospaced'>
+     BAD_RECOMMENDATIONS_pn-&lt;target_image&gt; = "&lt;package_name&gt;"
+                    </literallayout>
+                </para>
+
+                <para>
+                    It is important to realize that if you choose to not install
+                    packages using this variable and some other packages are
+                    dependent on them (i.e. listed in a recipe's
+                    <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>
+                    variable), the OpenEmbedded build system ignores your
+                    request and will install the packages to avoid dependency
+                    errors.
+                </para>
+
+                <para>
+                    Support for this variable exists only when using the
+                    IPK and RPM packaging backend.
+                    Support does not exist for DEB.
+                </para>
+
+                <para>
+                    See the
+                    <link linkend='var-NO_RECOMMENDATIONS'><filename>NO_RECOMMENDATIONS</filename></link>
+                    and the
+                    <link linkend='var-PACKAGE_EXCLUDE'><filename>PACKAGE_EXCLUDE</filename></link>
+                    variables for related information.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BB_DANGLINGAPPENDS_WARNONLY'><glossterm>BB_DANGLINGAPPENDS_WARNONLY</glossterm>
+            <glossdef>
+                <para>
+                    Defines how BitBake handles situations where an append
+                    file (<filename>.bbappend</filename>) has no
+                    corresponding recipe file (<filename>.bb</filename>).
+                    This condition often occurs when layers get out of sync
+                    (e.g. <filename>oe-core</filename> bumps a
+                    recipe version and the old recipe no longer exists and the
+                    other layer has not been updated to the new version
+                    of the recipe yet).
+                </para>
+
+                <para>
+                    The default fatal behavior is safest because it is
+                    the sane reaction given something is out of sync.
+                    It is important to realize when your changes are no longer
+                    being applied.
+                </para>
+
+                <para>
+                    You can change the default behavior by setting this
+                    variable to "1" in the <filename>local.conf</filename>
+                    file in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+                    as follows:
+                    <literallayout class='monospaced'>
+     BB_DANGLINGAPPENDS_WARNONLY = "1"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BB_DISKMON_DIRS'><glossterm>BB_DISKMON_DIRS</glossterm>
+            <glossdef>
+                <para>
+                    Monitors disk space and available inodes during the build
+                    and allows you to control the build based on these
+                    parameters.
+                </para>
+
+                <para>
+                    Disk space monitoring is disabled by default.
+                    To enable monitoring, add the <filename>BB_DISKMON_DIRS</filename>
+                    variable to your <filename>conf/local.conf</filename> file found in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+                    Use the following form:
+                    <literallayout class='monospaced'>
+     BB_DISKMON_DIRS = "&lt;action&gt;,&lt;dir&gt;,&lt;threshold&gt; [...]"
+
+     where:
+
+        &lt;action&gt; is:
+           ABORT:     Immediately abort the build when
+                      a threshold is broken.
+           STOPTASKS: Stop the build after the currently
+                      executing tasks have finished when
+                      a threshold is broken.
+           WARN:      Issue a warning but continue the
+                      build when a threshold is broken.
+                      Subsequent warnings are issued as
+                      defined by the
+                      <link linkend='var-BB_DISKMON_WARNINTERVAL'>BB_DISKMON_WARNINTERVAL</link> variable,
+                      which must be defined in the
+                      conf/local.conf file.
+
+        &lt;dir&gt; is:
+           Any directory you choose. You can specify one or
+           more directories to monitor by separating the
+           groupings with a space.  If two directories are
+           on the same device, only the first directory
+           is monitored.
+
+        &lt;threshold&gt; is:
+           Either the minimum available disk space,
+           the minimum number of free inodes, or
+           both.  You must specify at least one.  To
+           omit one or the other, simply omit the value.
+           Specify the threshold using G, M, K for Gbytes,
+           Mbytes, and Kbytes, respectively. If you do
+           not specify G, M, or K, Kbytes is assumed by
+           default.  Do not use GB, MB, or KB.
+                    </literallayout>
+                </para>
+
+                <para>
+                    Here are some examples:
+                    <literallayout class='monospaced'>
+     BB_DISKMON_DIRS = "ABORT,${TMPDIR},1G,100K WARN,${SSTATE_DIR},1G,100K"
+     BB_DISKMON_DIRS = "STOPTASKS,${TMPDIR},1G"
+     BB_DISKMON_DIRS = "ABORT,${TMPDIR},,100K"
+                    </literallayout>
+                    The first example works only if you also provide
+                    the <link linkend='var-BB_DISKMON_WARNINTERVAL'><filename>BB_DISKMON_WARNINTERVAL</filename></link> variable
+                    in the <filename>conf/local.conf</filename>.
+                    This example causes the build system to immediately
+                    abort when either the disk space in <filename>${TMPDIR}</filename> drops
+                    below 1 Gbyte or the available free inodes drops below
+                    100 Kbytes.
+                    Because two directories are provided with the variable, the
+                    build system also issue a
+                    warning when the disk space in the
+                    <filename>${SSTATE_DIR}</filename> directory drops
+                    below 1 Gbyte or the number of free inodes drops
+                    below 100 Kbytes.
+                    Subsequent warnings are issued during intervals as
+                    defined by the <filename>BB_DISKMON_WARNINTERVAL</filename>
+                    variable.
+                </para>
+
+                <para>
+                    The second example stops the build after all currently
+                    executing tasks complete when the minimum disk space
+                    in the <filename>${<link linkend='var-TMPDIR'>TMPDIR</link>}</filename>
+                    directory drops below 1 Gbyte.
+                    No disk monitoring occurs for the free inodes in this case.
+                </para>
+
+                <para>
+                    The final example immediately aborts the build when the
+                    number of free inodes in the <filename>${TMPDIR}</filename> directory
+                    drops below 100 Kbytes.
+                    No disk space monitoring for the directory itself occurs
+                    in this case.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BB_DISKMON_WARNINTERVAL'><glossterm>BB_DISKMON_WARNINTERVAL</glossterm>
+            <glossdef>
+                <para>
+                    Defines the disk space and free inode warning intervals.
+                    To set these intervals, define the variable in your
+                    <filename>conf/local.conf</filename> file in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+                </para>
+
+                <para>
+                    If you are going to use the
+                    <filename>BB_DISKMON_WARNINTERVAL</filename> variable, you must
+                    also use the
+                    <link linkend='var-BB_DISKMON_DIRS'><filename>BB_DISKMON_DIRS</filename></link> variable
+                    and define its action as "WARN".
+                    During the build, subsequent warnings are issued each time
+                    disk space or number of free inodes further reduces by
+                    the respective interval.
+                </para>
+
+                <para>
+                    If you do not provide a <filename>BB_DISKMON_WARNINTERVAL</filename>
+                    variable and you do use <filename>BB_DISKMON_DIRS</filename> with
+                    the "WARN" action, the disk monitoring interval defaults to
+                    the following:
+                    <literallayout class='monospaced'>
+     BB_DISKMON_WARNINTERVAL = "50M,5K"
+                    </literallayout>
+                </para>
+
+                <para>
+                    When specifying the variable in your configuration file,
+                    use the following form:
+                    <literallayout class='monospaced'>
+     BB_DISKMON_WARNINTERVAL = "&lt;disk_space_interval&gt;,&lt;disk_inode_interval&gt;"
+
+     where:
+
+        &lt;disk_space_interval&gt; is:
+           An interval of memory expressed in either
+           G, M, or K for Gbytes, Mbytes, or Kbytes,
+           respectively. You cannot use GB, MB, or KB.
+
+        &lt;disk_inode_interval&gt; is:
+           An interval of free inodes expressed in either
+           G, M, or K for Gbytes, Mbytes, or Kbytes,
+           respectively. You cannot use GB, MB, or KB.
+                    </literallayout>
+                </para>
+
+                <para>
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     BB_DISKMON_DIRS = "WARN,${SSTATE_DIR},1G,100K"
+     BB_DISKMON_WARNINTERVAL = "50M,5K"
+                    </literallayout>
+                    These variables cause the OpenEmbedded build system to
+                    issue subsequent warnings each time the available
+                    disk space further reduces by 50 Mbytes or the number
+                    of free inodes further reduces by 5 Kbytes in the
+                    <filename>${SSTATE_DIR}</filename> directory.
+                    Subsequent warnings based on the interval occur each time
+                    a respective interval is reached beyond the initial warning
+                    (i.e. 1 Gbytes and 100 Kbytes).
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BB_GENERATE_MIRROR_TARBALLS'><glossterm>BB_GENERATE_MIRROR_TARBALLS</glossterm>
+            <glossdef>
+                <para>
+                    Causes tarballs of the Git repositories to be placed in the
+                    <link linkend='var-DL_DIR'><filename>DL_DIR</filename></link>
+                    directory.
+                    For performance reasons, creating and placing tarballs of
+                    the Git repositories is not the default action by the
+                    OpenEmbedded build system.
+                    <literallayout class='monospaced'>
+     BB_GENERATE_MIRROR_TARBALLS = "1"
+                    </literallayout>
+                    Set this variable in your <filename>local.conf</filename>
+                    file in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BB_NUMBER_THREADS'><glossterm>BB_NUMBER_THREADS</glossterm>
+            <glossdef>
+                <para>The maximum number of tasks BitBake should run in parallel at any one time.
+                    If your host development system supports multiple cores, a good rule of thumb
+                    is to set this variable to twice the number of cores.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BBCLASSEXTEND'><glossterm>BBCLASSEXTEND</glossterm>
+            <glossdef>
+                <para>
+                    Allows you to extend a recipe so that it builds variants of the software.
+                    Common variants for recipes exist such as "natives" like <filename>quilt-native</filename>,
+                    which is a copy of Quilt built to run on the build system;
+                    "crosses" such as <filename>gcc-cross</filename>,
+                    which is a compiler built to run on the build machine but produces binaries
+                    that run on the target <link linkend='var-MACHINE'><filename>MACHINE</filename></link>;
+                    "nativesdk", which targets the SDK machine instead of <filename>MACHINE</filename>;
+                    and "mulitlibs" in the form "<filename>multilib:&lt;multilib_name&gt;</filename>".
+                </para>
+
+                <para>
+                    To build a different variant of the recipe with a minimal amount of code, it usually
+                    is as simple as adding the following to your recipe:
+                    <literallayout class='monospaced'>
+     BBCLASSEXTEND =+ "native nativesdk"
+     BBCLASSEXTEND =+ "multilib:&lt;multilib_name&gt;"
+                    </literallayout>
+                </para>
+             </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BBFILE_COLLECTIONS'><glossterm>BBFILE_COLLECTIONS</glossterm>
+            <glossdef>
+                <para>Lists the names of configured layers.
+                    These names are used to find the other <filename>BBFILE_*</filename>
+                    variables.
+                    Typically, each layer will append its name to this variable in its
+                    <filename>conf/layer.conf</filename> file.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BBFILE_PATTERN'><glossterm>BBFILE_PATTERN</glossterm>
+            <glossdef>
+                <para>Variable that expands to match files from
+                    <link linkend='var-BBFILES'><filename>BBFILES</filename></link>
+                    in a particular layer.
+                    This variable is used in the <filename>conf/layer.conf</filename> file and must
+                    be suffixed with the name of the specific layer (e.g.
+                    <filename>BBFILE_PATTERN_emenlow</filename>).</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BBFILE_PRIORITY'><glossterm>BBFILE_PRIORITY</glossterm>
+            <glossdef>
+                <para>Assigns the priority for recipe files in each layer.</para>
+                <para>This variable is useful in situations where the same recipe appears in
+                    more than one layer.
+                    Setting this variable allows you to prioritize a
+                    layer against other layers that contain the same recipe - effectively
+                    letting you control the precedence for the multiple layers.
+                    The precedence established through this variable stands regardless of a
+                    recipe's version
+                    (<link linkend='var-PV'><filename>PV</filename></link> variable).
+                    For example, a layer that has a recipe with a higher <filename>PV</filename> value but for
+                    which the <filename>BBFILE_PRIORITY</filename> is set to have a lower precedence still has a
+                    lower precedence.</para>
+                <para>A larger value for the <filename>BBFILE_PRIORITY</filename> variable results in a higher
+                    precedence.
+                    For example, the value 6 has a higher precedence than the value 5.
+                    If not specified, the <filename>BBFILE_PRIORITY</filename> variable is set based on layer
+                    dependencies (see the
+                    <filename><link linkend='var-LAYERDEPENDS'>LAYERDEPENDS</link></filename> variable for
+                    more information.
+                    The default priority, if unspecified
+                    for a layer with no dependencies, is the lowest defined priority + 1
+                    (or 1 if no priorities are defined).</para>
+                <tip>
+                    You can use the command <filename>bitbake-layers show-layers</filename> to list
+                    all configured layers along with their priorities.
+                </tip>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BBFILES'><glossterm>BBFILES</glossterm>
+            <glossdef>
+                <para>List of recipe files used by BitBake to build software.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BBINCLUDELOGS'><glossterm>BBINCLUDELOGS</glossterm>
+            <glossdef>
+                <para>Variable that controls how BitBake displays logs on build failure.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BBLAYERS'><glossterm>BBLAYERS</glossterm>
+            <glossdef>
+                <para>Lists the layers to enable during the build.
+                    This variable is defined in the <filename>bblayers.conf</filename> configuration
+                    file in the <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     BBLAYERS = " \
+       /home/scottrif/poky/meta \
+       /home/scottrif/poky/meta-yocto \
+       /home/scottrif/poky/meta-yocto-bsp \
+       /home/scottrif/poky/meta-mykernel \
+       "
+
+     BBLAYERS_NON_REMOVABLE ?= " \
+       /home/scottrif/poky/meta \
+       /home/scottrif/poky/meta-yocto \
+       "
+                    </literallayout>
+                    This example enables four layers, one of which is a custom, user-defined layer
+                    named <filename>meta-mykernel</filename>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BBLAYERS_NON_REMOVABLE'><glossterm>BBLAYERS_NON_REMOVABLE</glossterm>
+            <glossdef>
+                <para>Lists core layers that cannot be removed from the
+                    <filename>bblayers.conf</filename> file during a build
+                    using the
+                    <ulink url='https://www.yoctoproject.org/tools-resources/projects/hob'>Hob</ulink>.
+                    <note>
+                        When building an image outside of Hob, this variable
+                        is ignored.
+                    </note>
+                    In order for BitBake to build your image using Hob, your
+                    <filename>bblayers.conf</filename> file must include the
+                    <filename>meta</filename> and <filename>meta-yocto</filename>
+                    core layers.
+                    Here is an example that shows these two layers listed in
+                    the <filename>BBLAYERS_NON_REMOVABLE</filename> statement:
+                    <literallayout class='monospaced'>
+     BBLAYERS = " \
+       /home/scottrif/poky/meta \
+       /home/scottrif/poky/meta-yocto \
+       /home/scottrif/poky/meta-yocto-bsp \
+       /home/scottrif/poky/meta-mykernel \
+       "
+
+     BBLAYERS_NON_REMOVABLE ?= " \
+       /home/scottrif/poky/meta \
+       /home/scottrif/poky/meta-yocto \
+       "
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BBMASK'><glossterm>BBMASK</glossterm>
+            <glossdef>
+                <para>
+                    Prevents BitBake from processing recipes and recipe
+                    append files.
+                    Use the <filename>BBMASK</filename> variable from within the
+                    <filename>conf/local.conf</filename> file found
+                    in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+                </para>
+
+                <para>
+                    You can use the <filename>BBMASK</filename> variable
+                    to "hide" these <filename>.bb</filename> and
+                    <filename>.bbappend</filename> files.
+                    BitBake ignores any recipe or recipe append files that
+                    match the expression.
+                    It is as if BitBake does not see them at all.
+                    Consequently, matching files are not parsed or otherwise
+                    used by BitBake.</para>
+                <para>
+                    The value you provide is passed to Python's regular
+                    expression compiler.
+                    The expression is compared against the full paths to
+                    the files.
+                    For complete syntax information, see Python's
+                    documentation at
+                    <ulink url='http://docs.python.org/release/2.3/lib/re-syntax.html'></ulink>.
+                </para>
+
+                <para>
+                    The following example uses a complete regular expression
+                    to tell BitBake to ignore all recipe and recipe append
+                    files in the <filename>meta-ti/recipes-misc/</filename>
+                    directory:
+                    <literallayout class='monospaced'>
+     BBMASK = "meta-ti/recipes-misc/"
+                    </literallayout>
+                    If you want to mask out multiple directories or recipes,
+                    use the vertical bar to separate the regular expression
+                    fragments.
+                    This next example masks out multiple directories and
+                    individual recipes:
+                    <literallayout class='monospaced'>
+     BBMASK = "meta-ti/recipes-misc/|meta-ti/recipes-ti/packagegroup/"
+     BBMASK .= "|.*meta-oe/recipes-support/"
+     BBMASK .= "|.*openldap"
+     BBMASK .= "|.*opencv"
+     BBMASK .= "|.*lzma"
+                    </literallayout>
+                    Notice how the vertical bar is used to append the fragments.
+                    <note>
+                        When specifying a directory name, use the trailing
+                        slash character to ensure you match just that directory
+                        name.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BBPATH'><glossterm>BBPATH</glossterm>
+            <glossdef>
+                <para>
+                    Used by BitBake to locate
+                    <filename>.bbclass</filename> and configuration files.
+                    This variable is analogous to the
+                    <filename>PATH</filename> variable.
+                    <note>
+                        If you run BitBake from a directory outside of the
+                        <ulink url='&YOCTO_DOCS_DEV_URL;build-directory'>Build Directory</ulink>,
+                        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>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BBSERVER'><glossterm>BBSERVER</glossterm>
+            <glossdef>
+                <para>
+                    Points to the server that runs memory-resident BitBake.
+                    This variable is set by the
+                    <link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>
+                    setup script and should not be hand-edited.
+                    The variable is only used when you employ memory-resident
+                    BitBake.
+                    The setup script exports the value as follows:
+                    <literallayout class='monospaced'>
+     export BBSERVER=localhost:$port
+                    </literallayout>
+                    For more information on how the
+                    <filename>BBSERVER</filename> is used, see the
+                    <filename>oe-init-build-env-memres</filename> script, which
+                    is located in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BINCONFIG_GLOB'><glossterm>BINCONFIG_GLOB</glossterm>
+            <glossdef>
+                <para>
+                    When inheriting <filename>binconfig.bbclass</filename>
+                    from a recipe, this variable specifies a wildcard for
+                    configuration scripts that need editing.
+                    The scripts are edited to correct any paths that have been
+                    set up during compilation so that they are correct for
+                    use when installed into the sysroot and called by the
+                    build processes of other recipes.
+                </para>
+
+                <para>
+                    For more information on how this variable works, see
+                    <filename>meta/classes/binconfig.bbclass</filename> in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                    You can also find general information on the class in the
+                    "<link linkend='ref-classes-binconfig'><filename>binconfig.bbclass</filename></link>"
+                    section.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BP'><glossterm>BP</glossterm>
+            <glossdef>
+                <para>The base recipe name and version but without any special
+                    recipe name suffix (i.e. <filename>-native</filename>, <filename>lib64-</filename>,
+                    and so forth).
+                    <filename>BP</filename> is comprised of the following:
+                    <literallayout class="monospaced">
+     ${BPN}-${PV}
+                    </literallayout></para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BPN'><glossterm>BPN</glossterm>
+            <glossdef>
+                <para>The bare name of the recipe.
+                    This variable is a version of the <link linkend='var-PN'><filename>PN</filename></link> variable
+                    but removes common suffixes such as "-native" and "-cross" as well
+                    as removes common prefixes such as multilib's "lib64-" and "lib32-".
+                    The exact list of suffixes removed is specified by the
+                    <link linkend='var-SPECIAL_PKGSUFFIX'><filename>SPECIAL_PKGSUFFIX</filename></link> variable.
+                    The exact list of prefixes removed is specified by the
+                    <link linkend='var-MLPREFIX'><filename>MLPREFIX</filename></link> variable.
+                    Prefixes are removed for <filename>multilib</filename>
+                    and <filename>nativesdk</filename> cases.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BUILDDIR'><glossterm>BUILDDIR</glossterm>
+            <glossdef>
+                <para>
+                    Points to the location of the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+                    You can define this directory indirectly through the
+                    <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
+                    and
+                    <link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>
+                    scripts by passing in a Build Directory path when you run
+                    the scripts.
+                    If you run the scripts and do not provide a Build Directory
+                    path, the <filename>BUILDDIR</filename> defaults to
+                    <filename>build</filename> in the current directory.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-BUSYBOX_SPLIT_SUID'><glossterm>BUSYBOX_SPLIT_SUID</glossterm>
+            <glossdef>
+                <para>
+                    For the BusyBox recipe, specifies whether to split the
+                    output executable file into two parts: one for features
+                    that require <filename>setuid root</filename>, and one for
+                    the remaining features (i.e. those that do not require
+                    <filename>setuid root</filename>).
+                </para>
+
+                <para>
+                    The <filename>BUSYBOX_SPLIT_SUID</filename> variable
+                    defaults to "1", which results in a single output
+                    executable file.
+                    Set the variable to "0" to split the output file.
+                </para>
+            </glossdef>
+        </glossentry>
+
+    </glossdiv>
+
+    <glossdiv id='var-glossary-c'><title>C</title>
+
+        <glossentry id='var-CFLAGS'><glossterm>CFLAGS</glossterm>
+            <glossdef>
+                <para>
+                    Flags passed to the C compiler for the target system.
+                    This variable evaluates to the same as
+                    <filename><link linkend='var-TARGET_CFLAGS'>TARGET_CFLAGS</link></filename>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-COMBINED_FEATURES'><glossterm>COMBINED_FEATURES</glossterm>
+            <glossdef>
+                <para>A set of features common between
+                    <link linkend='var-MACHINE_FEATURES'><filename>MACHINE_FEATURES</filename></link>
+                    and <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>.
+                    See the glossary descriptions for these variables for more information.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-COMMON_LICENSE_DIR'><glossterm>COMMON_LICENSE_DIR</glossterm>
+            <glossdef>
+                <para>
+                    Points to <filename>meta/files/common-licenses</filename>
+                    in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>,
+                    which is where generic license files reside.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-COMPATIBLE_HOST'><glossterm>COMPATIBLE_HOST</glossterm>
+            <glossdef>
+                <para>A regular expression that resolves to one or more hosts
+                    (when the recipe is native) or one or more targets (when
+                    the recipe is non-native) with which a recipe is compatible.
+                    The regular expression is matched against
+                    <link linkend="var-HOST_SYS"><filename>HOST_SYS</filename></link>.
+                    You can use the variable to stop recipes from being built
+                    for classes of systems with which the recipes are not
+                    compatible.
+                    Stopping these builds is particularly useful with kernels.
+                    The variable also helps to increase parsing speed
+                    since the build system skips parsing recipes not
+                    compatible with the current system.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-COMPATIBLE_MACHINE'><glossterm>COMPATIBLE_MACHINE</glossterm>
+            <glossdef>
+                <para>A regular expression that resolves to one or more
+                    target machines with which a recipe is compatible.
+                    The regular expression is matched against
+                    <link linkend="var-MACHINEOVERRIDES"><filename>MACHINEOVERRIDES</filename></link>.
+                    You can use the variable to stop recipes from being built
+                    for machines with which the recipes are not compatible.
+                    Stopping these builds is particularly useful with kernels.
+                    The variable also helps to increase parsing speed
+                    since the build system skips parsing recipes not
+                    compatible with the current machine.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-COMPLEMENTARY_GLOB'><glossterm>COMPLEMENTARY_GLOB</glossterm>
+            <glossdef>
+                <para>
+                    Defines wildcards to match when installing a list of
+                    complementary packages for all the packages explicitly
+                    (or implicitly) installed in an image.
+                    The resulting list of complementary packages is associated
+                    with an item that can be added to
+                    <link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>.
+                    An example usage of this is the "dev-pkgs" item that when
+                    added to <filename>IMAGE_FEATURES</filename> will
+                    install -dev packages (containing headers and other
+                    development files) for every package in the image.
+                </para>
+
+                <para>
+                    To add a new feature item pointing to a wildcard, use a
+                    variable flag to specify the feature item name and
+                    use the value to specify the wildcard.
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     COMPLEMENTARY_GLOB[dev-pkgs] = '*-dev'
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-CONFFILES'><glossterm>CONFFILES</glossterm>
+            <glossdef>
+                <para>
+                    Identifies editable or configurable files that are part of a package.
+                    If the Package Management System (PMS) is being used to update
+                    packages on the target system, it is possible that
+                    configuration files you have changed after the original installation
+                    and that you now want to remain unchanged are overwritten.
+                    In other words, editable files might exist in the package that you do not
+                    want reset as part of the package update process.
+                    You can use the <filename>CONFFILES</filename> variable to list the files in the
+                    package that you wish to prevent the PMS from overwriting during this update process.
+                </para>
+
+                <para>
+                    To use the <filename>CONFFILES</filename> variable, provide a package name
+                    override that identifies the resulting package.
+                    Then, provide a space-separated list of files.
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     CONFFILES_${PN} += "${sysconfdir}/file1 \
+        ${sysconfdir}/file2 ${sysconfdir}/file3"
+                    </literallayout>
+                </para>
+
+                <para>
+                    A relationship exists between the <filename>CONFFILES</filename> and
+                    <filename><link linkend='var-FILES'>FILES</link></filename> variables.
+                    The files listed within <filename>CONFFILES</filename> must be a subset of
+                    the files listed within <filename>FILES</filename>.
+                    Because the configuration files you provide with <filename>CONFFILES</filename>
+                    are simply being identified so that the PMS will not overwrite them,
+                    it makes sense that
+                    the files must already be included as part of the package through the
+                    <filename>FILES</filename> variable.
+                </para>
+
+                <note>
+                    When specifying paths as part of the <filename>CONFFILES</filename> variable,
+                    it is good practice to use appropriate path variables.
+                    For example, <filename>${sysconfdir}</filename> rather than
+                    <filename>/etc</filename> or <filename>${bindir}</filename> rather
+                    than <filename>/usr/bin</filename>.
+                    You can find a list of these variables at the top of the
+                    <filename>meta/conf/bitbake.conf</filename> file in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                </note>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-CONFIG_SITE'><glossterm>CONFIG_SITE</glossterm>
+            <glossdef>
+                <para>
+                    A list of files that contains <filename>autoconf</filename> test results relevant
+                    to the current build.
+                    This variable is used by the Autotools utilities when running
+                    <filename>configure</filename>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-CORE_IMAGE_EXTRA_INSTALL'><glossterm>CORE_IMAGE_EXTRA_INSTALL</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the list of packages to be added to the image.
+                    You should only set this variable in the
+                    <filename>local.conf</filename> configuration file found
+                    in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+                </para>
+
+                <para>
+                    This variable replaces <filename>POKY_EXTRA_INSTALL</filename>, which is no longer supported.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-COREBASE'><glossterm>COREBASE</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the parent directory of the OpenEmbedded
+                    Core Metadata layer (i.e. <filename>meta</filename>).
+                </para>
+
+                <para>
+                    It is an important distinction that
+                    <filename>COREBASE</filename> points to the parent of this
+                    layer and not the layer itself.
+                    Consider an example where you have cloned the Poky Git
+                    repository and retained the <filename>poky</filename>
+                    name for your local copy of the repository.
+                    In this case, <filename>COREBASE</filename> points to
+                    the <filename>poky</filename> folder because it is the
+                    parent directory of the <filename>poky/meta</filename>
+                    layer.
+                </para>
+            </glossdef>
+        </glossentry>
+
+    </glossdiv>
+
+    <glossdiv id='var-glossary-d'><title>D</title>
+
+        <glossentry id='var-D'><glossterm>D</glossterm>
+            <glossdef>
+                <para>The destination directory.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DATETIME'><glossterm>DATETIME</glossterm>
+            <glossdef>
+                <para>
+                    The date and time on which the current build started.
+                    The format is suitable for timestamps.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DEBUG_BUILD'><glossterm>DEBUG_BUILD</glossterm>
+            <glossdef>
+                <para>
+                    Specifies to build packages with debugging information.
+                    This influences the value of the
+                    <filename><link linkend='var-SELECTED_OPTIMIZATION'>SELECTED_OPTIMIZATION</link></filename>
+                    variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DEBUG_OPTIMIZATION'><glossterm>DEBUG_OPTIMIZATION</glossterm>
+            <glossdef>
+                <para>
+                    The options to pass in
+                    <filename><link linkend='var-TARGET_CFLAGS'>TARGET_CFLAGS</link></filename>
+                    and <filename><link linkend='var-CFLAGS'>CFLAGS</link></filename> when compiling
+                    a system for debugging.
+                    This variable defaults to "-O -fno-omit-frame-pointer ${DEBUG_FLAGS} -pipe".
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DEFAULT_PREFERENCE'><glossterm>DEFAULT_PREFERENCE</glossterm>
+            <glossdef>
+                <para>
+                    Specifies a weak bias for recipe selection priority.
+                </para>
+                <para>
+                    The most common usage of this is variable is to set
+                    it to "-1" within a recipe for a development version of a
+                    piece of software.
+                    Using the variable in this way causes the stable version
+                    of the recipe to build by default in the absence of
+                    <filename><link linkend='var-PREFERRED_VERSION'>PREFERRED_VERSION</link></filename>
+                    being used to build the development version.
+                </para>
+                <note>
+                    The bias provided by <filename>DEFAULT_PREFERENCE</filename>
+                    is weak and is overridden by
+                    <filename><link linkend='var-BBFILE_PRIORITY'>BBFILE_PRIORITY</link></filename>
+                    if that variable is different between two layers
+                    that contain different versions of the same recipe.
+                </note>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DEPENDS'><glossterm>DEPENDS</glossterm>
+            <glossdef>
+                <para>
+                    Lists a recipe's build-time dependencies
+                    (i.e. other recipe files).
+                    The system ensures that all the dependencies listed
+                    have been built and have their contents in the appropriate
+                    sysroots before the recipe's configure task is executed.
+                </para>
+
+                <para>
+                    Consider this simple example for two recipes named "a" and
+                    "b" that produce similarly named packages.
+                    In this example, the <filename>DEPENDS</filename>
+                    statement appears in the "a" recipe:
+                    <literallayout class='monospaced'>
+     DEPENDS = "b"
+                    </literallayout>
+                    Here, the dependency is such that the
+                    <filename>do_configure</filename> task for recipe "a"
+                    depends on the <filename>do_populate_sysroot</filename>
+                    task of recipe "b".
+                    This means anything that recipe "b" puts into sysroot
+                    is available when recipe "a" is configuring itself.
+                </para>
+
+                <para>
+                    For information on runtime dependencies, see the
+                    <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>
+                    variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DEPLOY_DIR'><glossterm>DEPLOY_DIR</glossterm>
+            <glossdef>
+                <para>
+                    Points to the general area that the OpenEmbedded build
+                    system uses to place images, packages, SDKs and other output
+                    files that are ready to be used outside of the build system.
+                    By default, this directory resides within the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+                    as <filename>${TMPDIR}/deploy</filename>.
+                </para>
+
+                <para>
+                    For more information on the structure of the Build
+                    Directory, see
+                    "<link linkend='structure-build'>The Build Directory - <filename>build/</filename></link>"
+                    section.
+                    For more detail on the contents of the
+                    <filename>deploy</filename> directory, see the
+                    "<link linkend='images-dev-environment'>Images</link>" and
+                    "<link linkend='sdk-dev-environment'>Application Development SDK</link>"
+                    sections.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DEPLOY_DIR_IMAGE'><glossterm>DEPLOY_DIR_IMAGE</glossterm>
+            <glossdef>
+                <para>
+                    Points to the area that the OpenEmbedded build system uses
+                    to place images and other associated output files that are
+                    ready to be deployed onto the target machine.
+                    The directory is machine-specific as it contains the
+                    <filename>${MACHINE}</filename> name.
+                    By default, this directory resides within the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+                    as <filename>${DEPLOY_DIR}/images/${MACHINE}/</filename>.
+                </para>
+
+                <para>
+                    For more information on the structure of the Build
+                    Directory, see
+                    "<link linkend='structure-build'>The Build Directory - <filename>build/</filename></link>"
+                    section.
+                    For more detail on the contents of the
+                    <filename>deploy</filename> directory, see the
+                    "<link linkend='images-dev-environment'>Images</link>" and
+                    "<link linkend='sdk-dev-environment'>Application Development SDK</link>"
+                    sections.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DESCRIPTION'><glossterm>DESCRIPTION</glossterm>
+            <glossdef>
+                <para>The package description used by package managers.
+                      If not set, <filename>DESCRIPTION</filename> takes
+                      the value of the
+                      <link linkend='var-SUMMARY'><filename>SUMMARY</filename></link>
+                      variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DISTRO'><glossterm>DISTRO</glossterm>
+            <glossdef>
+                <para>
+                    The short name of the distribution.
+                    This variable corresponds to a file with the
+                    extension <filename>.conf</filename>
+                    located in a <filename>conf/distro</filename> directory
+                    within the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+                    that contains the distribution configuration.
+                    The value must not contain spaces, and is typically all lower-case.
+                </para>
+                <para>
+                    If the variable is blank, a set of default configuration
+                    will be used, which is specified
+                    within <filename>meta/conf/distro/defaultsetup.conf</filename>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DISTRO_EXTRA_RDEPENDS'><glossterm>DISTRO_EXTRA_RDEPENDS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies a list of distro-specific packages to add to all images.
+                    This variable takes affect through
+                    <filename>packagegroup-base</filename> so the
+                    variable only really applies to the more full-featured
+                    images that include <filename>packagegroup-base</filename>.
+                    You can use this variable to keep distro policy out of
+                    generic images.
+                    As with all other distro variables, you set this variable
+                    in the distro <filename>.conf</filename> file.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DISTRO_EXTRA_RRECOMMENDS'><glossterm>DISTRO_EXTRA_RRECOMMENDS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies a list of distro-specific packages to add to all images
+                    if the packages exist.
+                    The packages might not exist or be empty (e.g. kernel modules).
+                    The list of packages are automatically installed but you can
+                    remove them.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DISTRO_FEATURES'><glossterm>DISTRO_FEATURES</glossterm>
+            <glossdef>
+                <para>The features enabled for the distribution.
+                    For a list of supported features that ship with the
+                    Yocto Project, see the
+                    "<link linkend='ref-features-distro'>Distro</link>"
+                    section.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DISTRO_FEATURES_BACKFILL'><glossterm>DISTRO_FEATURES_BACKFILL</glossterm>
+            <glossdef>
+                <para>Features to be added to
+                    <filename><link linkend='var-DISTRO_FEATURES'>DISTRO_FEATURES</link></filename>
+                    if not also present in
+                    <filename><link linkend='var-DISTRO_FEATURES_BACKFILL_CONSIDERED'>DISTRO_FEATURES_BACKFILL_CONSIDERED</link></filename>.
+                </para>
+
+                <para>
+                    This variable is set in the <filename>meta/conf/bitbake.conf</filename> file.
+                    It is not intended to be user-configurable.
+                    It is best to just reference the variable to see which distro features are
+                    being backfilled for all distro configurations.
+                    See the <link linkend='ref-features-backfill'>Feature backfilling</link> section for
+                    more information.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DISTRO_FEATURES_BACKFILL_CONSIDERED'><glossterm>DISTRO_FEATURES_BACKFILL_CONSIDERED</glossterm>
+            <glossdef>
+                <para>Features from
+                    <filename><link linkend='var-DISTRO_FEATURES_BACKFILL'>DISTRO_FEATURES_BACKFILL</link></filename>
+                    that should not be backfilled (i.e. added to
+                    <filename><link linkend='var-DISTRO_FEATURES'>DISTRO_FEATURES</link></filename>)
+                    during the build.
+                    See the "<link linkend='ref-features-backfill'>Feature Backfilling</link>" section for
+                    more information.
+                    </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DISTRO_NAME'><glossterm>DISTRO_NAME</glossterm>
+            <glossdef>
+                <para>The long name of the distribution.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DISTRO_PN_ALIAS'><glossterm>DISTRO_PN_ALIAS</glossterm>
+            <glossdef>
+                <para>Alias names used for the recipe in various Linux distributions.</para>
+                <para>See the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#usingpoky-configuring-DISTRO_PN_ALIAS'>Handling
+                    a Package Name Alias</ulink>" section in the Yocto Project Development
+                    Manual for more information.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DISTRO_VERSION'><glossterm>DISTRO_VERSION</glossterm>
+            <glossdef>
+                <para>The version of the distribution.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DISTROOVERRIDES'><glossterm>DISTROOVERRIDES</glossterm>
+            <glossdef>
+                <para>
+                    This variable lists overrides specific to the current
+                    distribution.
+                    By default, the variable list includes the value of the
+                    <filename><link linkend='var-DISTRO'>DISTRO</link></filename>
+                    variable.
+                    You can extend the variable to apply any variable overrides
+                    you want as part of the distribution and are not
+                    already in <filename>OVERRIDES</filename> through
+                    some other means.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DL_DIR'><glossterm>DL_DIR</glossterm>
+            <glossdef>
+                <para>
+                    The central download directory used by the build process to
+                    store downloads.
+                    By default, <filename>DL_DIR</filename> gets files
+                    suitable for mirroring for everything except Git
+                    repositories.
+                    If you want tarballs of Git repositories, use the
+                    <link linkend='var-BB_GENERATE_MIRROR_TARBALLS'><filename>BB_GENERATE_MIRROR_TARBALLS</filename></link>
+                    variable.
+                </para>
+
+                <para>
+                    You can set this directory by defining the
+                    <filename>DL_DIR</filename> variable in the
+                    <filename>conf/local.conf</filename> file.
+                    This directory is self-maintaining and you should not have
+                    to touch it.
+                    By default, the directory is <filename>downloads</filename>
+                    in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+                    <literallayout class='monospaced'>
+     #DL_DIR ?= "${TOPDIR}/downloads"
+                    </literallayout>
+                    To specify a different download directory, simply remove
+                    the comment from the line and provide your directory.
+                </para>
+
+                <para>
+                    During a first build, the system downloads many different
+                    source code tarballs from various upstream projects.
+                    Downloading can take a while, particularly if your network
+                    connection is slow.
+                    Tarballs are all stored in the directory defined by
+                    <filename>DL_DIR</filename> and the build system looks there
+                    first to find source tarballs.
+                    <note>
+                        When wiping and rebuilding, you can preserve this
+                        directory to speed up this part of subsequent
+                        builds.
+                    </note>
+                </para>
+
+                <para>
+                    You can safely share this directory between multiple builds
+                    on the same development machine.
+                    For additional information on how the build process gets
+                    source files when working behind a firewall or proxy server,
+                    see this specific question in the
+                    "<link linkend='how-does-the-yocto-project-obtain-source-code-and-will-it-work-behind-my-firewall-or-proxy-server'>FAQ</link>"
+                    chapter.
+                </para>
+            </glossdef>
+
+        </glossentry>
+    </glossdiv>
+
+    <glossdiv id='var-glossary-e'><title>E</title>
+
+        <glossentry id='var-ENABLE_BINARY_LOCALE_GENERATION'><glossterm>ENABLE_BINARY_LOCALE_GENERATION</glossterm>
+            <glossdef>
+                <para></para>
+                <para>Variable that controls which locales for
+                    <filename>eglibc</filename> are generated during the
+                    build (useful if the target device has 64Mbytes
+                    of RAM or less).</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-ERROR_QA'><glossterm>ERROR_QA</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the quality assurance checks whose failures are
+                    reported as errors by the OpenEmbedded build system.
+                    You set this variable in your distribution configuration
+                    file.
+                    For a list of the checks you can control with this variable,
+                    see the
+                    "<link linkend='ref-classes-insane'><filename>insane.bbclass</filename></link>"
+                    section.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-EXCLUDE_FROM_WORLD'><glossterm>EXCLUDE_FROM_WORLD</glossterm>
+            <glossdef>
+                <para>
+                    Directs BitBake to exclude a recipe from world builds (i.e.
+                    <filename>bitbake world</filename>).
+                    During world builds, BitBake locates, parses and builds all
+                    recipes found in every layer exposed in the
+                    <filename>bblayers.conf</filename> configuration file.
+                </para>
+
+                <para>
+                    To exclude a recipe from a world build using this variable,
+                    set the variable to "1" in the recipe.
+                </para>
+
+                <note>
+                    Recipes added to <filename>EXCLUDE_FROM_WORLD</filename>
+                    may still be built during a world build in order to satisfy
+                    dependencies of other recipes.
+                    Adding a recipe to <filename>EXCLUDE_FROM_WORLD</filename>
+                    only ensures that the recipe is not explicitly added
+                    to the list of build targets in a world build.
+                </note>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-EXTENDPE'><glossterm>EXTENDPE</glossterm>
+            <glossdef>
+                <para>
+                    Used with file and pathnames to create a prefix for a recipe's
+                    version based on the recipe's
+                    <link linkend='var-PE'><filename>PE</filename></link> value.
+                    If <filename>PE</filename> is set and greater than zero for a recipe,
+                    <filename>EXTENDPE</filename> becomes that value (e.g if
+                    <filename>PE</filename> is equal to "1" then <filename>EXTENDPE</filename>
+                    becomes "1_").
+                    If a recipe's <filename>PE</filename> is not set (the default) or is equal to
+                    zero, <filename>EXTENDPE</filename> becomes "".</para>
+                    <para>See the <link linkend='var-STAMP'><filename>STAMP</filename></link>
+                    variable for an example.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-EXTENDPKGV'><glossterm>EXTENDPKGV</glossterm>
+            <glossdef>
+                <para>
+                    The full package version specification as it appears on the
+                    final packages produced by a recipe.
+                    The variable's value is normally used to fix a runtime
+                    dependency to the exact same version of another package
+                    in the same recipe:
+                    <literallayout class='monospaced'>
+     RDEPENDS_${PN}-additional-module = "${PN} (= ${EXTENDPKGV})"
+                    </literallayout>
+                </para>
+
+                <para>
+                    The dependency relationships are intended to force the
+                    package manager to upgrade these types of packages in
+                    lock-step.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-EXTERNALSRC'><glossterm>EXTERNALSRC</glossterm>
+            <glossdef>
+                <para>
+                    If <filename>externalsrc.bbclass</filename> is inherited,
+                    this variable points to the source tree, which is
+                    outside of the OpenEmbedded build system.
+                    When set, this variable sets the
+                    <link linkend='var-S'><filename>S</filename></link>
+                    variable, which is what the OpenEmbedded build system uses
+                    to locate unpacked recipe source code.
+                </para>
+
+                <para>
+                    For more information on
+                    <filename>externalsrc.bbclass</filename>, see the
+                    "<link linkend='ref-classes-externalsrc'><filename>externalsrc.bbclass</filename></link>"
+                    section.
+                    You can also find information on how to use this variable
+                    in the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#building-software-from-an-external-source'>Building Software from an External Source</ulink>"
+                    section in the Yocto Project Development Manual.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-EXTERNALSRC_BUILD'><glossterm>EXTERNALSRC_BUILD</glossterm>
+            <glossdef>
+                <para>
+                    If <filename>externalsrc.bbclass</filename> is inherited,
+                    this variable points to the directory in which the recipe's
+                    source code is built,
+                    which is outside of the OpenEmbedded build system.
+                    When set, this variable sets the
+                    <link linkend='var-B'><filename>B</filename></link>
+                    variable, which is what the OpenEmbedded build system uses
+                    to locate the Build Directory.
+                </para>
+
+                <para>
+                    For more information on
+                    <filename>externalsrc.bbclass</filename>, see the
+                    "<link linkend='ref-classes-externalsrc'><filename>externalsrc.bbclass</filename></link>"
+                    section.
+                    You can also find information on how to use this variable
+                    in the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#building-software-from-an-external-source'>Building Software from an External Source</ulink>"
+                    section in the Yocto Project Development Manual.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-EXTRA_IMAGE_FEATURES'><glossterm>EXTRA_IMAGE_FEATURES</glossterm>
+            <glossdef>
+                <para>
+                    The list of additional features to include in an image.
+                    Typically, you configure this variable in your
+                    <filename>local.conf</filename> file, which is found in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+                    Although you can use this variable from within a recipe,
+                    best practices dictate that you do not.
+                    <note>
+                        To enable primary features from within the image
+                        recipe, use the
+                        <link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>
+                        variable.
+                    </note>
+                </para>
+
+                <para>
+                    Here are some examples of features you can add:
+                    <literallayout class='monospaced'>
+"dbg-pkgs" - Adds -dbg packages for all installed packages
+             including symbol information for debugging and
+             profiling.
+
+"debug-tweaks" - Makes an image suitable for development.
+                 For example, ssh root access has a blank
+                 password.  You should remove this feature
+                 before you produce a production image.
+
+"dev-pkgs" - Adds -dev packages for all installed packages.
+             This is useful if you want to develop against
+             the libraries in the image.
+
+"read-only-rootfs" - Creates an image whose root
+                     filesystem is read-only. See the
+                     "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-read-only-root-filesystem'>Creating a Read-Only Root Filesystem</ulink>"
+                     section in the Yocto Project
+                     Development Manual for more
+                     information
+
+"tools-debug" - Adds debugging tools such as gdb and
+                strace.
+
+"tools-profile" - Adds profiling tools such as oprofile,
+                  exmap, lttng and valgrind (x86 only).
+
+"tools-sdk" - Adds development tools such as gcc, make,
+              pkgconfig and so forth.
+
+"tools-testapps" - Adds useful testing tools such as
+                   ts_print, aplay, arecord and so
+                   forth.
+
+                    </literallayout>
+                </para>
+
+                <para>
+                    For a complete list of image features that ships with the
+                    Yocto Project, see the
+                    "<link linkend="ref-features-image">Images</link>"
+                    section.
+                </para>
+
+                <para>
+                    For an example that shows how to customize your image by
+                    using this variable, see the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#usingpoky-extend-customimage-imagefeatures'>Customizing Images Using Custom <filename>IMAGE_FEATURES</filename> and <filename>EXTRA_IMAGE_FEATURES</filename></ulink>"
+                    section in the Yocto Project Development Manual.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-EXTRA_IMAGEDEPENDS'><glossterm>EXTRA_IMAGEDEPENDS</glossterm>
+            <glossdef>
+                <para>A list of recipes to build that do not provide packages
+                    for installing into the root filesystem.
+                </para>
+                <para>Sometimes a recipe is required to build the final image but is not
+                    needed in the root filesystem.
+                    You can use the <filename>EXTRA_IMAGEDEPENDS</filename> variable to
+                    list these recipes and thus specify the dependencies.
+                    A typical example is a required bootloader in a machine configuration.
+                </para>
+                <note>
+                    To add packages to the root filesystem, see the various
+                    <filename>*<link linkend='var-RDEPENDS'>RDEPENDS</link></filename>
+                    and <filename>*<link linkend='var-RRECOMMENDS'>RRECOMMENDS</link></filename>
+                    variables.
+                </note>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-EXTRA_OECMAKE'><glossterm>EXTRA_OECMAKE</glossterm>
+            <glossdef>
+                <para>Additional <filename>cmake</filename> options.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-EXTRA_OECONF'><glossterm>EXTRA_OECONF</glossterm>
+            <glossdef>
+                <para>Additional <filename>configure</filename> script options.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-EXTRA_OEMAKE'><glossterm>EXTRA_OEMAKE</glossterm>
+            <glossdef>
+                <para>Additional GNU <filename>make</filename> options.</para>
+            </glossdef>
+        </glossentry>
+
+    </glossdiv>
+
+    <glossdiv id='var-glossary-f'><title>F</title>
+
+        <glossentry id='var-FEED_DEPLOYDIR_BASE_URI'><glossterm>FEED_DEPLOYDIR_BASE_URI</glossterm>
+            <glossdef>
+                <para>
+                    Points to the base URL of the server and location within
+                    the document-root that provides the metadata and
+                    packages required by OPKG to support runtime package
+                    management of IPK packages.
+                    You set this variable in your
+                    <filename>local.conf</filename> file.
+                </para>
+
+                <para>
+                    Consider the following example:
+                    <literallayout class='monospaced'>
+     FEED_DEPLOYDIR_BASE_URI = "http://192.168.7.1/BOARD-dir"
+                    </literallayout>
+                    This example assumes you are serving your packages over
+                    HTTP and your databases are located in a directory
+                    named <filename>BOARD-dir</filename>, which is underneath
+                    your HTTP server's document-root.
+                    In this case, the OpenEmbedded build system generates a set
+                    of configuration files for you in your target that work
+                    with the feed.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-FILES'><glossterm>FILES</glossterm>
+            <glossdef>
+                <para>
+                    The list of directories or files that are placed in packages.
+                </para>
+
+                <para>
+                    To use the <filename>FILES</filename> variable, provide a package name
+                    override that identifies the resulting package.
+                    Then, provide a space-separated list of files or paths that identifies the
+                    files you want included as part of the resulting package.
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     FILES_${PN} += "${bindir}/mydir1/ ${bindir}/mydir2/myfile"
+                    </literallayout>
+                </para>
+
+                <note>
+                    When specifying paths as part of the <filename>FILES</filename> variable,
+                    it is good practice to use appropriate path variables.
+                    For example, use <filename>${sysconfdir}</filename> rather than
+                    <filename>/etc</filename>, or <filename>${bindir}</filename> rather
+                    than <filename>/usr/bin</filename>.
+                    You can find a list of these variables at the top of the
+                    <filename>meta/conf/bitbake.conf</filename> file in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                </note>
+
+                <para>
+                    If some of the files you provide with the <filename>FILES</filename> variable
+                    are editable and you know they should not be
+                    overwritten during the package update process by the Package Management
+                    System (PMS), you can identify these files so that the PMS will not
+                    overwrite them.
+                    See the <filename><link linkend='var-CONFFILES'>CONFFILES</link></filename>
+                    variable for information on how to identify these files to the PMS.
+                </para>
+
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-FILESEXTRAPATHS'><glossterm>FILESEXTRAPATHS</glossterm>
+            <glossdef>
+                <para>
+                    Extends the search path the OpenEmbedded build system uses
+                    when looking for files and patches as it processes recipes
+                    and append files.
+                    The default directories BitBake uses when it processes
+                    recipes are initially defined by the
+                    <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>
+                    variable.
+                    You can extend <filename>FILESPATH</filename> variable
+                    by using <filename>FILESEXTRAPATHS</filename>.
+                </para>
+
+                <para>
+                    Best practices dictate that you accomplish this by using
+                    <filename>FILESEXTRAPATHS</filename> from within a
+                    <filename>.bbappend</filename> file and that you prepend
+                    paths as follows:
+                    <literallayout class='monospaced'>
+     FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+                    </literallayout>
+                    In the above example, the build system first looks for files
+                    in a directory that has the same name as the corresponding
+                    append file.
+                    <note>
+                        <para>When extending <filename>FILESEXTRAPATHS</filename>,
+                        be sure to use the immediate expansion
+                        (<filename>:=</filename>) operator.
+                        Immediate expansion makes sure that BitBake evaluates
+                        <link linkend='var-THISDIR'><filename>THISDIR</filename></link>
+                        at the time the directive is encountered rather than at
+                        some later time when expansion might result in a
+                        directory that does not contain the files you need.
+                        </para>
+                        <para>Also, include the trailing separating colon
+                        character if you are prepending.
+                        The trailing colon character is necessary because you
+                        are directing BitBake to extend the path by prepending
+                        directories to the search path.</para>
+                    </note>
+                    Here is another common use:
+                    <literallayout class='monospaced'>
+     FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+                    </literallayout>
+                    In this example, the build system extends the
+                    <filename>FILESPATH</filename> variable to include a
+                    directory named <filename>files</filename> that is in the
+                    same directory as the corresponding append file.
+                </para>
+
+                <para>
+                    Here is a final example that specifically adds three paths:
+                    <literallayout class='monospaced'>
+     FILESEXTRAPATHS_prepend := "path_1:path_2:path_3:"
+                    </literallayout>
+                </para>
+
+                <para>
+                    By prepending paths in <filename>.bbappend</filename>
+                    files, you allow multiple append files that reside in
+                    different layers but are used for the same recipe to
+                    correctly extend the path.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-FILESOVERRIDES'><glossterm>FILESOVERRIDES</glossterm>
+            <glossdef>
+                <para>
+                    A subset of <link linkend='var-OVERRIDES'><filename>OVERRIDES</filename></link>
+                    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>.
+                </para>
+
+                <para>
+                    By default, the <filename>FILESOVERRIDES</filename>
+                    variable is defined as:
+                    <literallayout class='monospaced'>
+     FILESOVERRIDES = "${TRANSLATED_TARGET_ARCH}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}"
+                    </literallayout>
+
+                    <note>
+                        Do not hand-edit the <filename>FILESOVERRIDES</filename>
+                        variable.
+                        The values match up with expected overrides and are
+                        used in an expected manner by the build system.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-FILESPATH'><glossterm>FILESPATH</glossterm>
+            <glossdef>
+                <para>
+                    The default set of directories the OpenEmbedded build system
+                    uses when searching for patches and files.
+                    During the build process, BitBake searches each directory in
+                    <filename>FILESPATH</filename> in the specified order when
+                    looking for files and patches specified by each
+                    <filename>file://</filename> URI in a recipe.
+                </para>
+
+                <para>
+                    The default value for the <filename>FILESPATH</filename>
+                    variable is defined in the <filename>base.bbclass</filename>
+                    class found in <filename>meta/classes</filename> in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>:
+                    <literallayout class='monospaced'>
+     FILESPATH = "${@base_set_filespath(["${FILE_DIRNAME}/${BP}", \
+        "${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}"
+                    </literallayout>
+                    <note>
+                        Do not hand-edit the <filename>FILESPATH</filename>
+                        variable.
+                        If you want the build system to look in directories
+                        other than the defaults, extend the
+                        <filename>FILESPATH</filename> variable by using the
+                        <link linkend='var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></link>
+                        variable.
+                    </note>
+                    Be aware that the default <filename>FILESPATH</filename>
+                    directories do not map to directories in custom layers
+                    where append files (<filename>.bbappend</filename>)
+                    are used.
+                    If you want the build system to find patches or files
+                    that reside with your append files, you need to extend
+                    the <filename>FILESPATH</filename> variable by using
+                    the
+                    <link linkend='var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></link>
+                    variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-FILESYSTEM_PERMS_TABLES'><glossterm>FILESYSTEM_PERMS_TABLES</glossterm>
+            <glossdef>
+                <para>Allows you to define your own file permissions settings table as part of
+                    your configuration for the packaging process.
+                    For example, suppose you need a consistent set of custom permissions for
+                    a set of groups and users across an entire work project.
+                    It is best to do this in the packages themselves but this is not always
+                    possible.
+                </para>
+                <para>
+                    By default, the OpenEmbedded build system uses the <filename>fs-perms.txt</filename>, which
+                    is located in the <filename>meta/files</filename> folder in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                    If you create your own file permissions setting table, you should place it in your
+                    layer or the distro's layer.
+                </para>
+                <para>
+                    You define the <filename>FILESYSTEM_PERMS_TABLES</filename> variable in the
+                    <filename>conf/local.conf</filename> file, which is found in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>, to
+                    point to your custom <filename>fs-perms.txt</filename>.
+                    You can specify more than a single file permissions setting table.
+                    The paths you specify to these files must be defined within the
+                    <link linkend='var-BBPATH'><filename>BBPATH</filename></link> variable.
+                </para>
+                <para>
+                    For guidance on how to create your own file permissions settings table file,
+                    examine the existing <filename>fs-perms.txt</filename>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-FULL_OPTIMIZATION'><glossterm>FULL_OPTIMIZATION</glossterm>
+            <glossdef>
+                <para>
+                    The options to pass in
+                    <filename><link linkend='var-TARGET_CFLAGS'>TARGET_CFLAGS</link></filename>
+                    and <filename><link linkend='var-CFLAGS'>CFLAGS</link></filename>
+                    when compiling an optimized system.
+                    This variable defaults to
+                    "-O2 -pipe ${DEBUG_FLAGS}".
+                </para>
+            </glossdef>
+        </glossentry>
+
+    </glossdiv>
+
+<!--            <glossdiv id='var-glossary-g'><title>G</title>-->
+<!--            </glossdiv>-->
+
+    <glossdiv id='var-glossary-h'><title>H</title>
+
+        <glossentry id='var-HOMEPAGE'><glossterm>HOMEPAGE</glossterm>
+            <glossdef>
+                <para>Website where more information about the software the recipe is building
+                    can be found.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-HOST_SYS'><glossterm>HOST_SYS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the system, including the architecture and the
+                    operating system, for with the build is occurring
+                    in the context of the current
+                    recipe.
+                    The OpenEmbedded build system automatically sets this
+                    variable.
+                    You do not need to set the variable yourself.
+                </para>
+
+                <para>
+                    Here are two examples:
+                    <itemizedlist>
+                        <listitem><para>Given a native recipe on a 32-bit
+                            x86 machine running Linux, the value is
+                            "i686-linux".
+                            </para></listitem>
+                        <listitem><para>Given a recipe being built for a
+                            little-endian MIPS target running Linux,
+                            the value might be "mipsel-linux".
+                            </para></listitem>
+                    </itemizedlist>
+                </para>
+            </glossdef>
+        </glossentry>
+
+    </glossdiv>
+
+    <glossdiv id='var-glossary-i'><title>I</title>
+
+        <glossentry id='var-IMAGE_BASENAME'><glossterm>IMAGE_BASENAME</glossterm>
+            <glossdef>
+                <para>
+                    The base name of image output files.
+                    This variable defaults to the recipe name
+                    (<filename>${</filename><link linkend='var-PN'><filename>PN</filename></link><filename>}</filename>).
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-IMAGE_CLASSES'><glossterm>IMAGE_CLASSES</glossterm>
+            <glossdef>
+                <para>
+                    A list of classes that all images should inherit.
+                    You typically use this variable to specify the list of
+                    classes that register the different types of images
+                    the OpenEmbedded build system creates.
+                </para>
+
+                <para>
+                    The default value for <filename>IMAGE_CLASSES</filename> is
+                    <filename>image_types</filename>.
+                    You can set this variable in your
+                    <filename>local.conf</filename> or in a distribution
+                    configuration file.
+                </para>
+
+                <para>
+                    For more information, see
+                    <filename>meta/classes/image_types.bbclass</filename> in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-IMAGE_FEATURES'><glossterm>IMAGE_FEATURES</glossterm>
+            <glossdef>
+                <para>
+                    The primary list of features to include in an image.
+                    Typically, you configure this variable in an image recipe.
+                    Although you can use this variable from your
+                    <filename>local.conf</filename> file, which is found in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>,
+                    best practices dictate that you do not.
+                    <note>
+                        To enable extra features from outside the image recipe,
+                        use the
+                        <filename><link linkend='var-EXTRA_IMAGE_FEATURES'>EXTRA_IMAGE_FEATURES</link></filename> variable.
+                    </note>
+                    For a list of image features that ships with the Yocto
+                    Project, see the
+                    "<link linkend="ref-features-image">Images</link>"
+                    section.
+                </para>
+
+                <para>
+                    For an example that shows how to customize your image by
+                    using this variable, see the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#usingpoky-extend-customimage-imagefeatures'>Customizing Images Using Custom <filename>IMAGE_FEATURES</filename> and <filename>EXTRA_IMAGE_FEATURES</filename></ulink>"
+                    section in the Yocto Project Development Manual.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-IMAGE_FSTYPES'><glossterm>IMAGE_FSTYPES</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the formats the OpenEmbedded build system uses
+                    during the build when creating the root filesystem.
+                    For example, setting <filename>IMAGE_FSTYPES</filename>
+                    as follows causes the build system to create root
+                    filesystems using two formats: <filename>.ext3</filename>
+                    and <filename>.tar.bz2</filename>:
+                    <literallayout class='monospaced'>
+     IMAGE_FSTYPES = "ext3 tar.bz2"
+                    </literallayout>
+                    For the complete list of supported image formats from which
+                    you can choose, see
+                    <link linkend='var-IMAGE_TYPES'><filename>IMAGE_TYPES</filename></link>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-IMAGE_INSTALL'><glossterm>IMAGE_INSTALL</glossterm>
+            <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.
+                </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.
+                </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
+                    <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.
+                </para>
+
+                <para>
+                    When you use this variable, it is best to use it as follows:
+                    <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.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-IMAGE_LINGUAS'><glossterm>IMAGE_LINGUAS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the list of locales to install into the image
+                    during the root filesystem construction process.
+                    The OpenEmbedded build system automatically splits locale
+                    files, which are used for localization, into separate
+                    packages.
+                    Setting the <filename>IMAGE_LINGUAS</filename> variable
+                    ensures that any locale packages that correspond to packages
+                    already selected for installation into the image are also
+                    installed.
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     IMAGE_LINGUAS = "pt-br de-de"
+                    </literallayout>
+                    In this example, the build system ensures any Brazilian
+                    Portuguese and German locale files that correspond to
+                    packages in the image are installed (i.e.
+                    <filename>*-locale-pt-br</filename>
+                    and <filename>*-locale-de-de</filename> as well as
+                    <filename>*-locale-pt</filename>
+                    and <filename>*-locale-de</filename>, since some software
+                    packages only provide locale files by language and not by
+                    country-specific language).
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-IMAGE_NAME'><glossterm>IMAGE_NAME</glossterm>
+            <glossdef>
+                <para>
+                    The name of the output image files minus the extension.
+                    This variable is derived using the
+                    <link linkend='var-IMAGE_BASENAME'><filename>IMAGE_BASENAME</filename></link>,
+                    <link linkend='var-MACHINE'><filename>MACHINE</filename></link>,
+                    and
+                    <link linkend='var-DATETIME'><filename>DATETIME</filename></link>
+                    variables:
+                    <literallayout class='monospaced'>
+     IMAGE_NAME = "${IMAGE_BASENAME}-${MACHINE}-${DATETIME}"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-IMAGE_OVERHEAD_FACTOR'><glossterm>IMAGE_OVERHEAD_FACTOR</glossterm>
+            <glossdef>
+                <para>
+                    Defines a multiplier that the build system applies to the initial image
+                    size for cases when the multiplier times the returned disk usage value
+                    for the image is greater than the sum of
+                    <filename><link linkend='var-IMAGE_ROOTFS_SIZE'>IMAGE_ROOTFS_SIZE</link></filename>
+                    and
+                    <filename><link linkend='var-IMAGE_ROOTFS_EXTRA_SPACE'>IMAGE_ROOTFS_EXTRA_SPACE</link></filename>.
+                    The result of the multiplier applied to the initial image size creates
+                    free disk space in the image as overhead.
+                    By default, the build process uses a multiplier of 1.3 for this variable.
+                    This default value results in 30% free disk space added to the image when this
+                    method is used to determine the final generated image size.
+                    You should be aware that post install scripts and the package management
+                    system uses disk space inside this overhead area.
+                    Consequently, the multiplier does not produce an image with
+                    all the theoretical free disk space.
+                    See <filename><link linkend='var-IMAGE_ROOTFS_SIZE'>IMAGE_ROOTFS_SIZE</link></filename>
+                    for information on how the build system determines the overall image size.
+                </para>
+
+                <para>
+                    The default 30% free disk space typically gives the image enough room to boot
+                    and allows for basic post installs while still leaving a small amount of
+                    free disk space.
+                    If 30% free space is inadequate, you can increase the default value.
+                    For example, the following setting gives you 50% free space added to the image:
+                    <literallayout class='monospaced'>
+     IMAGE_OVERHEAD_FACTOR = "1.5"
+                    </literallayout>
+                </para>
+
+                <para>
+                    Alternatively, you can ensure a specific amount of free disk space is added
+                    to the image by using the
+                    <filename><link linkend='var-IMAGE_ROOTFS_EXTRA_SPACE'>IMAGE_ROOTFS_EXTRA_SPACE</link></filename>
+                    variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-IMAGE_POSTPROCESS_COMMAND'><glossterm>IMAGE_POSTPROCESS_COMMAND</glossterm>
+            <glossdef>
+                <para>
+                    Added by classes to run post processing commands once the
+                    OpenEmbedded build system has created the image.
+                    You can specify shell commands separated by semicolons:
+                    <literallayout class='monospaced'>
+     IMAGE_POSTPROCESS_COMMAND += "&lt;shell_command&gt;; ... "
+                    </literallayout>
+                    If you need to pass the path to the root filesystem within
+                    the command, you can use
+                    <filename>${IMAGE_ROOTFS}</filename>, which points to
+                    the root filesystem image.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-IMAGE_ROOTFS'><glossterm>IMAGE_ROOTFS</glossterm>
+            <glossdef>
+                <para>
+                    The location of the root filesystem while it is under
+                    construction (i.e. during <filename>do_rootfs</filename>).
+                    This variable is not configurable.
+                    Do not change it.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-IMAGE_ROOTFS_EXTRA_SPACE'><glossterm>IMAGE_ROOTFS_EXTRA_SPACE</glossterm>
+            <glossdef>
+                <para>
+                    Defines additional free disk space created in the image in Kbytes.
+                    By default, this variable is set to "0".
+                    This free disk space is added to the image after the build system determines
+                    the image size as described in
+                    <filename><link linkend='var-IMAGE_ROOTFS_SIZE'>IMAGE_ROOTFS_SIZE</link></filename>.
+                </para>
+
+                <para>
+                    This variable is particularly useful when you want to ensure that a
+                    specific amount of free disk space is available on a device after an image
+                    is installed and running.
+                    For example, to be sure 5 Gbytes of free disk space is available, set the
+                    variable as follows:
+                    <literallayout class='monospaced'>
+     IMAGE_ROOTFS_EXTRA_SPACE = "5242880"
+                    </literallayout>
+                </para>
+
+                <para>
+                    For example, the Yocto Project Build Appliance specifically requests 40 Gbytes
+                    of extra space with the line:
+                    <literallayout class='monospaced'>
+     IMAGE_ROOTFS_EXTRA_SPACE = "41943040"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-IMAGE_ROOTFS_SIZE'><glossterm>IMAGE_ROOTFS_SIZE</glossterm>
+            <glossdef>
+                <para>
+                    Defines the size in Kbytes for the generated image.
+                    The OpenEmbedded build system determines the final size for the generated
+                    image using an algorithm that takes into account the initial disk space used
+                    for the generated image, a requested size for the image, and requested
+                    additional free disk space to be added to the image.
+                    Programatically, the build system determines the final size of the
+                    generated image as follows:
+                    <literallayout class='monospaced'>
+    if (image-du * overhead) &lt; rootfs-size:
+        internal-rootfs-size = rootfs-size + xspace
+    else:
+        internal-rootfs-size = (image-du * overhead) + xspace
+
+    where:
+
+      image-du = Returned value of the du command on
+                 the image.
+
+      overhead = IMAGE_OVERHEAD_FACTOR
+
+      rootfs-size = IMAGE_ROOTFS_SIZE
+
+      internal-rootfs-size = Initial root filesystem
+                             size before any modifications.
+
+      xspace = IMAGE_ROOTFS_EXTRA_SPACE
+                    </literallayout>
+                    See the <link linkend='var-IMAGE_OVERHEAD_FACTOR'><filename>IMAGE_OVERHEAD_FACTOR</filename></link>
+                    and <link linkend='var-IMAGE_ROOTFS_EXTRA_SPACE'><filename>IMAGE_ROOTFS_EXTRA_SPACE</filename></link>
+                    variables for related information.
+<!--                    In the above example, <filename>overhead</filename> is defined by the
+                    <filename><link linkend='var-IMAGE_OVERHEAD_FACTOR'>IMAGE_OVERHEAD_FACTOR</link></filename>
+                    variable, <filename>xspace</filename> is defined by the
+                    <filename><link linkend='var-IMAGE_ROOTFS_EXTRA_SPACE'>IMAGE_ROOTFS_EXTRA_SPACE</link></filename>
+                    variable, and <filename>du</filename> is the results of the disk usage command
+                    on the initially generated image. -->
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-IMAGE_TYPES'><glossterm>IMAGE_TYPES</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the complete list of supported image types
+                    by default:
+                    <literallayout class='monospaced'>
+     jffs2
+     sum.jffs2
+     cramfs
+     ext2
+     ext2.gz
+     ext2.bz2
+     ext3
+     ext3.gz
+     ext2.lzma
+     btrfs
+     live
+     squashfs
+     squashfs-xz
+     ubi
+     ubifs
+     tar
+     tar.gz
+     tar.bz2
+     tar.xz
+     cpio
+     cpio.gz
+     cpio.xz
+     cpio.lzma
+     vmdk
+     elf
+                    </literallayout>
+                    For more information on how these types of images, see
+                    <filename>meta/classes/image_types*.bbclass</filename>
+                    in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-INC_PR'><glossterm>INC_PR</glossterm>
+            <glossdef>
+                <para>Helps define the recipe revision for recipes that share
+                    a common <filename>include</filename> file.
+                    You can think of this variable as part of the recipe revision
+                    as set from within an include file.</para>
+                <para>Suppose, for example, you have a set of recipes that
+                    are used across several projects.
+                    And, within each of those recipes the revision
+                    (its <link linkend='var-PR'><filename>PR</filename></link>
+                    value) is set accordingly.
+                    In this case, when the revision of those recipes changes,
+                    the burden is on you to find all those recipes and
+                    be sure that they get changed to reflect the updated
+                    version of the recipe.
+                    In this scenario, it can get complicated when recipes
+                    that are used in many places and provide common functionality
+                    are upgraded to a new revision.</para>
+                <para>A more efficient way of dealing with this situation is
+                    to set the <filename>INC_PR</filename> variable inside
+                    the <filename>include</filename> files that the recipes
+                    share and then expand the <filename>INC_PR</filename>
+                    variable within the recipes to help
+                    define the recipe revision.
+                    </para>
+                <para>
+                    The following provides an example that shows how to use
+                    the <filename>INC_PR</filename> variable
+                    given a common <filename>include</filename> file that
+                    defines the variable.
+                    Once the variable is defined in the
+                    <filename>include</filename> file, you can use the
+                    variable to set the <filename>PR</filename> values in
+                    each recipe.
+                    You will notice that when you set a recipe's
+                    <filename>PR</filename> you can provide more granular
+                    revisioning by appending values to the
+                    <filename>INC_PR</filename> variable:
+                    <literallayout class='monospaced'>
+recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR = "r2"
+recipes-graphics/xorg-font/encodings_1.0.4.bb:PR = "${INC_PR}.1"
+recipes-graphics/xorg-font/font-util_1.3.0.bb:PR = "${INC_PR}.0"
+recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
+                    </literallayout>
+                    The first line of the example establishes the baseline
+                    revision to be used for all recipes that use the
+                    <filename>include</filename> file.
+                    The remaining lines in the example are from individual
+                    recipes and show how the <filename>PR</filename> value
+                    is set.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-INCOMPATIBLE_LICENSE'><glossterm>INCOMPATIBLE_LICENSE</glossterm>
+            <glossdef>
+                <para>
+                    Specifies a space-separated list of license names
+                    (as they would appear in
+                    <link linkend='var-LICENSE'><filename>LICENSE</filename></link>)
+                    that should be excluded from the build.
+                    Recipes that provide no alternatives to listed incompatible
+                    licenses are not built.
+                    Packages that are individually licensed with the specified
+                    incompatible licenses will be deleted.
+                </para>
+
+                <note>
+                    This functionality is only regularly tested using
+                    the following setting:
+                    <literallayout class='monospaced'>
+     INCOMPATIBLE_LICENSE = "GPLv3"
+                    </literallayout>
+                    Although you can use other settings, you might be required
+                    to remove dependencies on or provide alternatives to
+                    components that are required to produce a functional system
+                    image.
+                </note>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-INHIBIT_DEFAULT_DEPS'><glossterm>INHIBIT_DEFAULT_DEPS</glossterm>
+            <glossdef>
+                <para>
+                    Prevents the default dependencies, namely the C compiler
+                    and standard C library (libc), from being added to
+                    <link linkend='var-DEPENDS'><filename>DEPENDS</filename></link>.
+                    This variable is usually used within recipes that do not
+                    require any compilation using the C compiler.
+                </para>
+
+                <para>
+                    Set the variable to "1" to prevent the default dependencies
+                    from being added.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-INHIBIT_PACKAGE_STRIP'><glossterm>INHIBIT_PACKAGE_STRIP</glossterm>
+            <glossdef>
+                <para>
+                    If set to "1", causes the build to not strip binaries in resulting packages.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-INHERIT'><glossterm>INHERIT</glossterm>
+            <glossdef>
+                <para>
+                    Causes the named class to be inherited at
+                    this point during parsing.
+                    The variable is only valid in configuration files.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-INITRAMFS_FSTYPES'><glossterm>INITRAMFS_FSTYPES</glossterm>
+            <glossdef>
+                <para>
+                    Defines the format for the output image of an initial
+                    RAM disk (initramfs), which is used during boot.
+                    Supported formats are the same as those supported by the
+                    <link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>
+                    variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-INITSCRIPT_NAME'><glossterm>INITSCRIPT_NAME</glossterm>
+            <glossdef>
+                <para>
+                    The filename of the initialization script as installed to
+                    <filename>${sysconfdir}/init.d</filename>.
+                </para>
+                <para>
+                    This variable is used in recipes when using <filename>update-rc.d.bbclass</filename>.
+                    The variable is mandatory.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-INITSCRIPT_PACKAGES'><glossterm>INITSCRIPT_PACKAGES</glossterm>
+            <glossdef>
+                <para>
+                    A list of the packages that contain initscripts.
+                    If multiple packages are specified, you need to append the package name
+                    to the other <filename>INITSCRIPT_*</filename> as an override.</para>
+                 <para>
+                    This variable is used in recipes when using <filename>update-rc.d.bbclass</filename>.
+                    The variable is optional and defaults to the
+                    <link linkend='var-PN'><filename>PN</filename></link> variable.
+                </para>
+           </glossdef>
+        </glossentry>
+
+        <glossentry id='var-INITSCRIPT_PARAMS'><glossterm>INITSCRIPT_PARAMS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the options to pass to <filename>update-rc.d</filename>.
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     INITSCRIPT_PARAMS = "start 99 5 2 . stop 20 0 1 6 ."
+                    </literallayout>
+                    In this example, the script has a runlevel of 99,
+                    starts the script in initlevels 2 and 5, and
+                    stops the script in levels 0, 1 and 6.
+                </para>
+                <para>
+                    The variable is mandatory and is used in recipes when using
+                    <filename>update-rc.d.bbclass</filename>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-INSANE_SKIP'><glossterm>INSANE_SKIP</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the QA checks to skip for a specific package
+                    within a recipe.
+                    For example, to skip the check for symbolic link
+                    <filename>.so</filename> files in the main package of a
+                    recipe, add the following to the recipe.
+                    The package name override must be used, which in this
+                    example is <filename>${PN}</filename>:
+                    <literallayout class='monospaced'>
+     INSANE_SKIP_${PN} += "dev-so"
+                    </literallayout>
+                </para>
+                <para>
+                    See the "<link linkend='ref-classes-insane'><filename>insane.bbclass</filename></link>"
+                    section for a list of the valid QA checks you can
+                    specify using this variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-IPK_FEED_URIS'><glossterm>IPK_FEED_URIS</glossterm>
+            <glossdef>
+                <para>
+                    When the IPK backend is in use and package management
+                    is enabled on the target, you can use this variable to
+                    set up <filename>opkg</filename> in the target image
+                    to point to package feeds on a nominated server.
+                    Once the feed is established, you can perform
+                    installations or upgrades using the package manager
+                    at runtime.
+                </para>
+            </glossdef>
+        </glossentry>
+
+<!--
+        <glossentry id='var-INTERCEPT_DIR'><glossterm>INTERCEPT_DIR</glossterm>
+            <glossdef>
+                <para>
+                    An environment variable that defines the directory where
+                    post installation hooks are installed for the
+                    post install environment.
+                    This variable is fixed as follows:
+                    <literallayout class='monospaced'>
+     ${WORKDIR}/intercept_scripts
+                    </literallayout>
+                </para>
+
+                <para>
+                    After installation of a target's root filesystem,
+                    post installation scripts, which are essentially bash scripts,
+                    are all executed just a single time.
+                    Limiting execution of these scripts minimizes installation
+                    time that would be lengthened due to  certain packages
+                    triggering redundant operations.
+                    For example, consider the installation of font packages
+                    as a common example.
+                    Without limiting the execution of post installation scripts,
+                    all font directories would be rescanned to create the
+                    cache after each individual font package was installed.
+                </para>
+
+                <para>
+                    Do not edit the <filename>INTERCEPT_DIR</filename>
+                    variable.
+                </para>
+            </glossdef>
+        </glossentry>
+-->
+
+    </glossdiv>
+
+<!--            <glossdiv id='var-glossary-j'><title>J</title>-->
+<!--            </glossdiv>-->
+
+   <glossdiv id='var-glossary-k'><title>K</title>
+
+        <glossentry id='var-KARCH'><glossterm>KARCH</glossterm>
+            <glossdef>
+                <para>
+                    Defines the kernel architecture used when assembling
+                    the configuration.
+                    Architectures supported for this release are:
+                    <literallayout class='monospaced'>
+     powerpc
+     i386
+     x86_64
+     arm
+     qemu
+     mips
+                    </literallayout>
+                </para>
+
+                <para>
+                    You define the <filename>KARCH</filename> variable in the
+                    <ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#bsp-descriptions'>BSP Descriptions</ulink>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <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.
+                    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.
+                </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:
+                    <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>.
+                </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.
+                    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>.
+                    Here are the related statements from the append file:
+                    <literallayout class='monospaced'>
+     COMPATIBLE_MACHINE_crownbay = "crownbay"
+     KMACHINE_crownbay  = "crownbay"
+     KBRANCH_crownbay  = "standard/crownbay"
+
+     COMPATIBLE_MACHINE_crownbay-noemgd = "crownbay-noemgd"
+     KMACHINE_crownbay-noemgd  = "crownbay"
+     KBRANCH_crownbay-noemgd  = "standard/crownbay"
+                    </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.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-KBRANCH_DEFAULT'><glossterm>KBRANCH_DEFAULT</glossterm>
+            <glossdef>
+                <para>
+                    Defines the Linux kernel source repository's default
+                    branch used to build the Linux kernel.
+                    The <filename>KBRANCH_DEFAULT</filename> value is
+                    the default value for
+                    <link linkend='var-KBRANCH'><filename>KBRANCH</filename></link>.
+                    Unless you specify otherwise,
+                    <filename>KBRANCH_DEFAULT</filename> initializes to
+                    "master".
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-KERNEL_EXTRA_ARGS'><glossterm>KERNEL_EXTRA_ARGS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies additional <filename>make</filename>
+                    command-line arguments the OpenEmbedded build system
+                    passes on when compiling the kernel.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-KERNEL_FEATURES'><glossterm>KERNEL_FEATURES</glossterm>
+            <glossdef>
+                <para>Includes additional metadata from the Yocto Project kernel Git repository.
+                    In the OpenEmbedded build system, the default Board Support Packages (BSPs)
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+                    is provided through
+                    the <link linkend='var-KMACHINE'><filename>KMACHINE</filename></link>
+                    and <link linkend='var-KBRANCH'><filename>KBRANCH</filename></link> variables.
+                    You can use the <filename>KERNEL_FEATURES</filename> variable to further
+                    add metadata for all BSPs.</para>
+                <para>The metadata you add through this variable includes config fragments and
+                    features descriptions,
+                    which usually includes patches as well as config fragments.
+                    You typically override the <filename>KERNEL_FEATURES</filename> variable
+                    for a specific machine.
+                    In this way, you can provide validated, but optional, sets of kernel
+                    configurations and features.</para>
+                <para>For example, the following adds <filename>netfilter</filename> to all
+                    the Yocto Project kernels and adds sound support to the <filename>qemux86</filename>
+                    machine:
+                    <literallayout class='monospaced'>
+     # Add netfilter to all linux-yocto kernels
+     KERNEL_FEATURES="features/netfilter"
+
+     # Add sound support to the qemux86 machine
+     KERNEL_FEATURES_append_qemux86=" cfg/sound"
+                    </literallayout></para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-KERNEL_IMAGETYPE'><glossterm>KERNEL_IMAGETYPE</glossterm>
+            <glossdef>
+                <para>The type of kernel to build for a device, usually set by the
+                    machine configuration files and defaults to "zImage".
+                    This variable is used
+                    when building the kernel and is passed to <filename>make</filename> as the target to
+                    build.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-KERNEL_PATH'><glossterm>KERNEL_PATH</glossterm>
+            <glossdef>
+                <para>
+                    The location of the kernel sources.
+                    This variable is set to the value of the
+                    <link linkend='var-STAGING_KERNEL_DIR'><filename>STAGING_KERNEL_DIR</filename></link>
+                    within the <filename>module.bbclass</filename> class.
+                    For information on how this variable is used, see the
+                    "<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#incorporating-out-of-tree-modules'>Incorporating Out-of-Tree Modules</ulink>"
+                    section.
+                </para>
+
+                <para>
+                    The <link linkend='var-KERNEL_SRC'><filename>KERNEL_SRC</filename></link>
+                    variable is identical to the <filename>KERNEL_PATH</filename>
+                    variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-KERNEL_SRC'><glossterm>KERNEL_SRC</glossterm>
+            <glossdef>
+                <para>
+                    The location of the kernel sources.
+                    This variable is set to the value of the
+                    <link linkend='var-STAGING_KERNEL_DIR'><filename>STAGING_KERNEL_DIR</filename></link>
+                    within the <filename>module.bbclass</filename> class.
+                    For information on how this variable is used, see the
+                    "<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#incorporating-out-of-tree-modules'>Incorporating Out-of-Tree Modules</ulink>"
+                    section.
+                </para>
+
+                <para>
+                    The <link linkend='var-KERNEL_PATH'><filename>KERNEL_PATH</filename></link>
+                    variable is identical to the <filename>KERNEL_SRC</filename>
+                    variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-KFEATURE_DESCRIPTION'><glossterm>KFEATURE_DESCRIPTION</glossterm>
+            <glossdef>
+                <para>
+                    Provides a short description of a configuration fragment.
+                    You use this variable in the <filename>.scc</filename>
+                    file that describes a configuration fragment file.
+                    Here is the variable used in a file named
+                    <filename>smp.scc</filename> to describe SMP being
+                    enabled:
+                    <literallayout class='monospaced'>
+     define KFEATURE_DESCRIPTION "Enable SMP"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-KMACHINE'><glossterm>KMACHINE</glossterm>
+            <glossdef>
+                <para>
+                    The machine as known by the kernel.
+                    Sometimes the machine name used by the kernel does not match the machine name
+                    used by the OpenEmbedded build system.
+                    For example, the machine name that the OpenEmbedded build system understands as
+                    <filename>qemuarm</filename> goes by a different name in the Linux Yocto kernel.
+                    The kernel understands that machine as <filename>arm_versatile926ejs</filename>.
+                    For cases like these, the <filename>KMACHINE</filename> variable maps the
+                    kernel machine name to the OpenEmbedded build system machine name.
+                </para>
+
+                <para>
+                    Kernel machine names are initially defined in the
+                    Yocto Linux Kernel's <filename>meta</filename> branch.
+                    From the <filename>meta</filename> branch, look in
+                    the <filename>meta/cfg/kernel-cache/bsp/&lt;bsp_name&gt;/&lt;bsp-name&gt;-&lt;kernel-type&gt;.scc</filename> file.
+                    For example, from the <filename>meta</filename> branch in the
+                    <filename>linux-yocto-3.0</filename> kernel, the
+                    <filename>meta/cfg/kernel-cache/bsp/cedartrail/cedartrail-standard.scc</filename> file
+                    has the following:
+                    <literallayout class='monospaced'>
+     define KMACHINE cedartrail
+     define KTYPE standard
+     define KARCH i386
+
+     include ktypes/standard
+     branch cedartrail
+
+     include cedartrail.scc
+                    </literallayout>
+                    You can see that the kernel understands the machine name for
+                    the Cedar Trail Board Support Package (BSP) as
+                    <filename>cedartrail</filename>.
+                </para>
+
+                <para>
+                    If you look in the Cedar Trail BSP layer in the
+                    <filename>meta-intel</filename>
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-repositories'>Source Repositories</ulink>
+                    at <filename>meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend</filename>,
+                    you will find the following statements among others:
+                    <literallayout class='monospaced'>
+     COMPATIBLE_MACHINE_cedartrail = "cedartrail"
+     KMACHINE_cedartrail  = "cedartrail"
+     KBRANCH_cedartrail  = "yocto/standard/cedartrail"
+     KERNEL_FEATURES_append_cedartrail += "bsp/cedartrail/cedartrail-pvr-merge.scc"
+     KERNEL_FEATURES_append_cedartrail += "cfg/efi-ext.scc"
+
+     COMPATIBLE_MACHINE_cedartrail-nopvr = "cedartrail"
+     KMACHINE_cedartrail-nopvr  = "cedartrail"
+     KBRANCH_cedartrail-nopvr  = "yocto/standard/cedartrail"
+     KERNEL_FEATURES_append_cedartrail-nopvr += " cfg/smp.scc"
+                    </literallayout>
+                    The <filename>KMACHINE</filename> statements in the kernel's append file make sure that
+                    the OpenEmbedded build system and the Yocto Linux kernel understand the same machine
+                    names.
+                </para>
+
+                <para>
+                    This append file uses two <filename>KMACHINE</filename> statements.
+                    The first is not really necessary but does ensure that the machine known to the
+                    OpenEmbedded build system as <filename>cedartrail</filename> maps to the machine
+                    in the kernel also known as <filename>cedartrail</filename>:
+                    <literallayout class='monospaced'>
+     KMACHINE_cedartrail  = "cedartrail"
+                    </literallayout>
+                </para>
+
+                <para>
+                    The second statement is a good example of why the <filename>KMACHINE</filename> variable
+                    is needed.
+                    In this example, the OpenEmbedded build system uses the <filename>cedartrail-nopvr</filename>
+                    machine name to refer to the Cedar Trail BSP that does not support the proprietary
+                    PowerVR driver.
+                    The kernel, however, uses the machine name <filename>cedartrail</filename>.
+                    Thus, the append file must map the <filename>cedartrail-nopvr</filename> machine name to
+                    the kernel's <filename>cedartrail</filename> name:
+                    <literallayout class='monospaced'>
+     KMACHINE_cedartrail-nopvr  = "cedartrail"
+                    </literallayout>
+                </para>
+
+                <para>
+                    BSPs that ship with the Yocto Project release provide all mappings between the Yocto
+                    Project kernel machine names and the OpenEmbedded machine names.
+                    Be sure to use the <filename>KMACHINE</filename> if you create a BSP and the machine
+                    name you use is different than that used in the kernel.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-KTYPE'><glossterm>KTYPE</glossterm>
+            <glossdef>
+                <para>
+                    Defines the kernel type to be used in assembling the
+                    configuration.
+                    The linux-yocto recipes define "standard", "tiny",
+                    and "preempt-rt" kernel types.
+                    See the
+                    "<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#kernel-types'>Kernel Types</ulink>"
+                    section in the Yocto Project Linux Kernel Development
+                    Manual for more information on kernel types.
+                </para>
+
+                <para>
+                    You define the <filename>KTYPE</filename> variable in the
+                    <ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#bsp-descriptions'>BSP Descriptions</ulink>.
+                    The value you use must match the value used for the
+                    <link linkend='var-LINUX_KERNEL_TYPE'><filename>LINUX_KERNEL_TYPE</filename></link>
+                    value used by the kernel recipe.
+                </para>
+            </glossdef>
+        </glossentry>
+   </glossdiv>
+
+    <glossdiv id='var-glossary-l'><title>L</title>
+
+        <glossentry id='var-LAYERDEPENDS'><glossterm>LAYERDEPENDS</glossterm>
+            <glossdef>
+                <para>Lists the layers that this recipe depends upon, separated by spaces.
+                    Optionally, you can specify a specific layer version for a dependency
+                    by adding it to the end of the layer name with a colon, (e.g. "anotherlayer:3"
+                    to be compared against
+                    <link linkend='var-LAYERVERSION'><filename>LAYERVERSION</filename></link><filename>_anotherlayer</filename>
+                    in this case).
+                    An error will be produced if any dependency is missing or
+                    the version numbers do not match exactly (if specified).
+                    This variable is used in the <filename>conf/layer.conf</filename> file
+                    and must be suffixed with the name of the specific layer (e.g.
+                    <filename>LAYERDEPENDS_mylayer</filename>).</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-LAYERDIR'><glossterm>LAYERDIR</glossterm>
+            <glossdef>
+                <para>When used inside the <filename>layer.conf</filename> configuration
+                    file, this variable provides the path of the current layer.
+                    This variable is not available outside of <filename>layer.conf</filename>
+                    and references are expanded immediately when parsing of the file completes.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-LAYERVERSION'><glossterm>LAYERVERSION</glossterm>
+            <glossdef>
+                <para>Optionally specifies the version of a layer as a single number.
+                    You can use this within
+                    <link linkend='var-LAYERDEPENDS'><filename>LAYERDEPENDS</filename></link>
+                    for another layer in order to depend on a specific version
+                    of the layer.
+                    This variable is used in the <filename>conf/layer.conf</filename> file
+                    and must be suffixed with the name of the specific layer (e.g.
+                    <filename>LAYERVERSION_mylayer</filename>).</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-LIC_FILES_CHKSUM'><glossterm>LIC_FILES_CHKSUM</glossterm>
+            <glossdef>
+                <para>Checksums of the license text in the recipe source code.</para>
+                <para>This variable tracks changes in license text of the source
+                    code files.
+                    If the license text is changed, it will trigger a build
+                    failure, which gives the developer an opportunity to review any
+                    license change.</para>
+                <para>
+                    This variable must be defined for all recipes (unless
+                    <link linkend='var-LICENSE'><filename>LICENSE</filename></link>
+                    is set to "CLOSED")</para>
+                <para>For more information, see the
+                    <link linkend='usingpoky-configuring-LIC_FILES_CHKSUM'>
+                    Tracking License Changes</link> section</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-LICENSE'><glossterm>LICENSE</glossterm>
+            <glossdef>
+                <para>
+                    The list of source licenses for the recipe.
+                    Follow these rules:
+                    <itemizedlist>
+                        <listitem><para>Do not use spaces within individual
+                            license names.</para></listitem>
+                        <listitem><para>Separate license names using
+                            | (pipe) when there is a choice between licenses.
+                            </para></listitem>
+                        <listitem><para>Separate license names using
+                            &amp; (ampersand) when multiple licenses exist
+                            that cover different parts of the source.
+                            </para></listitem>
+                        <listitem><para>You can use spaces between license
+                            names.</para></listitem>
+                    </itemizedlist>
+                </para>
+
+                <para>
+                    Here are some examples:
+                    <literallayout class='monospaced'>
+     LICENSE = "LGPLv2.1 | GPLv3"
+     LICENSE = "MPL-1 &amp; LGPLv2.1"
+     LICENSE = "GPLv2+"
+                    </literallayout>
+                    The first example is from the recipes for Qt, which the user
+                    may choose to distribute under either the LGPL version
+                    2.1 or GPL version 3.
+                    The second example is from Cairo where two licenses cover
+                    different parts of the source code.
+                    The final example is from <filename>sysstat</filename>,
+                    which presents a single license.
+                </para>
+
+                <para>
+                    You can also specify licenses on a per-package basis to
+                    handle situations where components of the output have
+                    different licenses.
+                    For example, a piece of software whose code is
+                    licensed under GPLv2 but has accompanying documentation
+                    licensed under the GNU Free Documentation License 1.2 could
+                    be specified as follows:
+                    <literallayout class='monospaced'>
+     LICENSE = "GFDL-1.2 &amp; GPLv2"
+     LICENSE_${PN} = "GPLv2"
+     LICENSE_${PN}-doc = "GFDL-1.2"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-LICENSE_PATH'><glossterm>LICENSE_PATH</glossterm>
+            <glossdef>
+                <para>Path to additional licenses used during the build.
+                    By default, the OpenEmbedded build system uses <filename>COMMON_LICENSE_DIR</filename>
+                    to define the directory that holds common license text used during the build.
+                    The <filename>LICENSE_PATH</filename> variable allows you to extend that
+                    location to other areas that have additional licenses:
+                    <literallayout class='monospaced'>
+     LICENSE_PATH += "/path/to/additional/common/licenses"
+                    </literallayout></para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-LINUX_KERNEL_TYPE'><glossterm>LINUX_KERNEL_TYPE</glossterm>
+            <glossdef>
+                <para>
+                    Defines the kernel type to be used in assembling the
+                    configuration.
+                    The linux-yocto recipes define "standard", "tiny", and
+                    "preempt-rt" kernel types.
+                    See the
+                    "<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#kernel-types'>Kernel Types</ulink>"
+                    section in the Yocto Project Linux Kernel Development
+                    Manual for more information on kernel types.
+                </para>
+
+                <para>
+                    If you do not specify a
+                    <filename>LINUX_KERNEL_TYPE</filename>, it defaults to
+                    "standard".
+                    Together with
+                    <link linkend='var-KMACHINE'><filename>KMACHINE</filename></link>,
+                    the <filename>LINUX_KERNEL_TYPE</filename> variable
+                    defines the search
+                    arguments used by the kernel tools to find the appropriate
+                    description within the kernel
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+                    with which to build out the sources and configuration.
+                    </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-LINUX_VERSION'><glossterm>LINUX_VERSION</glossterm>
+            <glossdef>
+                <para>The Linux version from <filename>kernel.org</filename>
+                    on which the Linux kernel image being built using the
+                    OpenEmbedded build system is based.
+                    You define this variable in the kernel recipe.
+                    For example, the <filename>linux-yocto-3.4.bb</filename>
+                    kernel recipe found in
+                    <filename>meta/recipes-kernel/linux</filename>
+                    defines the variables as follows:
+                    <literallayout class='monospaced'>
+     LINUX_VERSION ?= "3.4.24"
+                    </literallayout>
+                    The <filename>LINUX_VERSION</filename> variable is used to
+                    define <link linkend='var-PV'><filename>PV</filename></link>
+                    for the recipe:
+                    <literallayout class='monospaced'>
+     PV = "${LINUX_VERSION}+git${SRCPV}"
+                    </literallayout></para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-LINUX_VERSION_EXTENSION'><glossterm>LINUX_VERSION_EXTENSION</glossterm>
+            <glossdef>
+                <para>A string extension compiled into the version
+                    string of the Linux kernel built with the OpenEmbedded
+                    build system.
+                    You define this variable in the kernel recipe.
+                    For example, the linux-yocto kernel recipes all define
+                    the variable as follows:
+                    <literallayout class='monospaced'>
+     LINUX_VERSION_EXTENSION ?= "-yocto-${<link linkend='var-LINUX_KERNEL_TYPE'>LINUX_KERNEL_TYPE</link>}"
+                    </literallayout>
+                    Defining this variable essentially sets the
+                    Linux kernel configuration item
+                    <filename>CONFIG_LOCALVERSION</filename>, which is visible
+                    through the <filename>uname</filename> command.
+                    Here is an example that shows the extension assuming it
+                    was set as previously shown:
+                    <literallayout class='monospaced'>
+     $ uname -r
+     3.7.0-rc8-custom
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-LOG_DIR'><glossterm>LOG_DIR</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the directory to which the OpenEmbedded build
+                    system writes overall log files.
+                    The default directory is <filename>${TMPDIR}/log</filename>.
+                </para>
+                <para>
+                    For the directory containing logs specific to each task,
+                    see the <link linkend='var-T'><filename>T</filename></link>
+                    variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
+    </glossdiv>
+
+    <glossdiv id='var-glossary-m'><title>M</title>
+
+         <glossentry id='var-MACHINE'><glossterm>MACHINE</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the target device for which the image is built.
+                    You define <filename>MACHINE</filename> in the
+                    <filename>local.conf</filename> file found in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+                    By default, <filename>MACHINE</filename> is set to
+                    "qemux86", which is an x86-based architecture machine to
+                    be emulated using QEMU:
+                    <literallayout class='monospaced'>
+     MACHINE ?= "qemux86"
+                    </literallayout>
+                    The variable corresponds to a machine configuration file of the
+                    same name, through which machine-specific configurations are set.
+                    Thus, when <filename>MACHINE</filename> is set to "qemux86" there
+                    exists the corresponding <filename>qemux86.conf</filename> machine
+                    configuration file, which can be found in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+                    in <filename>meta/conf/machine</filename>.
+                </para>
+
+                <para>
+                    The list of machines supported by the Yocto Project as
+                    shipped include the following:
+                    <literallayout class='monospaced'>
+     MACHINE ?= "qemuarm"
+     MACHINE ?= "qemumips"
+     MACHINE ?= "qemuppc"
+     MACHINE ?= "qemux86"
+     MACHINE ?= "qemux86-64"
+     MACHINE ?= "genericx86"
+     MACHINE ?= "genericx86-64"
+     MACHINE ?= "beagleboard"
+     MACHINE ?= "mpc8315e-rdb"
+     MACHINE ?= "routerstationpro"
+                    </literallayout>
+                    The last five are Yocto Project reference hardware boards, which
+                    are provided in the <filename>meta-yocto-bsp</filename> layer.
+                    <note>Adding additional Board Support Package (BSP) layers
+                        to your configuration adds new possible settings for
+                        <filename>MACHINE</filename>.
+                    </note>
+                </para>
+            </glossdef>
+         </glossentry>
+
+         <glossentry id='var-MACHINE_ESSENTIAL_EXTRA_RDEPENDS'><glossterm>MACHINE_ESSENTIAL_EXTRA_RDEPENDS</glossterm>
+            <glossdef>
+                <para></para>
+                <para>
+                    A list of required machine-specific packages to install as part of
+                    the image being built.
+                    The build process depends on these packages being present.
+                    Furthermore, because this is a "machine essential" variable, the list of
+                    packages are essential for the machine to boot.
+                    The impact of this variable affects images based on
+                    <filename>packagegroup-core-boot</filename>,
+                    including the <filename>core-image-minimal</filename> image.
+                </para>
+                <para>
+                    This variable is similar to the
+                    <filename><link linkend='var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS'>MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</link></filename>
+                    variable with the exception that the image being built has a build
+                    dependency on the variable's list of packages.
+                    In other words, the image will not build if a file in this list is not found.
+                </para>
+                <para>
+                    As an example, suppose the machine for which you are building requires
+                    <filename>example-init</filename> to be run during boot to initialize the hardware.
+                    In this case, you would use the following in the machine's
+                    <filename>.conf</filename> configuration file:
+                    <literallayout class='monospaced'>
+     MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "example-init"
+                    </literallayout>
+                </para>
+            </glossdef>
+         </glossentry>
+
+         <glossentry id='var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS'><glossterm>MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</glossterm>
+            <glossdef>
+                <para></para>
+                <para>
+                    A list of recommended machine-specific packages to install as part of
+                    the image being built.
+                    The build process does not depend on these packages being present.
+                    However, because this is a "machine essential" variable, the list of
+                    packages are essential for the machine to boot.
+                    The impact of this variable affects images based on
+                    <filename>packagegroup-core-boot</filename>,
+                    including the <filename>core-image-minimal</filename> image.
+                </para>
+                <para>
+                    This variable is similar to the
+                    <filename><link linkend='var-MACHINE_ESSENTIAL_EXTRA_RDEPENDS'>MACHINE_ESSENTIAL_EXTRA_RDEPENDS</link></filename>
+                    variable with the exception that the image being built does not have a build
+                    dependency on the variable's list of packages.
+                    In other words, the image will still build if a package in this list is not found.
+                    Typically, this variable is used to handle essential kernel modules, whose
+                    functionality may be selected to be built into the kernel rather than as a module,
+                    in which case a package will not be produced.
+                </para>
+                <para>
+                    Consider an example where you have a custom kernel where a specific touchscreen
+                    driver is required for the machine to be usable.
+                    However, the driver can be built as a module or
+                    into the kernel depending on the kernel configuration.
+                    If the driver is built as a module, you want it to be installed.
+                    But, when the driver is built into the kernel, you still want the
+                    build to succeed.
+                    This variable sets up a "recommends" relationship so that in the latter case,
+                    the build will not fail due to the missing package.
+                    To accomplish this, assuming the package for the module was called
+                    <filename>kernel-module-ab123</filename>, you would use the
+                    following in the machine's <filename>.conf</filename> configuration
+                    file:
+                    <literallayout class='monospaced'>
+     MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-module-ab123"
+                    </literallayout>
+                </para>
+                <para>
+                    Some examples of these machine essentials are flash, screen, keyboard, mouse,
+                    or touchscreen drivers (depending on the machine).
+                </para>
+            </glossdef>
+        </glossentry>
+
+         <glossentry id='var-MACHINE_EXTRA_RDEPENDS'><glossterm>MACHINE_EXTRA_RDEPENDS</glossterm>
+            <glossdef>
+                <para>
+                    A list of machine-specific packages to install as part of the
+                    image being built that are not essential for the machine to boot.
+                    However, the build process for more fully-featured images
+                    depends on the packages being present.
+                </para>
+                <para>
+                    This variable affects all images based on
+                    <filename>packagegroup-base</filename>, which does not include the
+                    <filename>core-image-minimal</filename> or <filename>core-image-basic</filename>
+                    images.
+                </para>
+                <para>
+                    The variable is similar to the
+                    <filename><link linkend='var-MACHINE_EXTRA_RRECOMMENDS'>MACHINE_EXTRA_RRECOMMENDS</link></filename>
+                    variable with the exception that the image being built has a build
+                    dependency on the variable's list of packages.
+                    In other words, the image will not build if a file in this list is not found.
+                </para>
+                <para>
+                    An example is a machine that has WiFi capability but is not
+                    essential for the machine to boot the image.
+                    However, if you are building a more fully-featured image, you want to enable
+                    the WiFi.
+                    The package containing the firmware for the WiFi hardware is always
+                    expected to exist, so it is acceptable for the build process to depend upon
+                    finding the package.
+                    In this case, assuming the package for the firmware was called
+                    <filename>wifidriver-firmware</filename>, you would use the following in the
+                    <filename>.conf</filename> file for the machine:
+                    <literallayout class='monospaced'>
+     MACHINE_EXTRA_RDEPENDS += "wifidriver-firmware"
+                    </literallayout>
+                </para>
+            </glossdef>
+         </glossentry>
+
+         <glossentry id='var-MACHINE_EXTRA_RRECOMMENDS'><glossterm>MACHINE_EXTRA_RRECOMMENDS</glossterm>
+            <glossdef>
+                <para></para>
+                <para>
+                    A list of machine-specific packages to install as part of the
+                    image being built that are not essential for booting the machine.
+                    The image being built has no build dependency on this list of packages.
+                </para>
+                <para>
+                    This variable affects only images based on
+                    <filename>packagegroup-base</filename>, which does not include the
+                    <filename>core-image-minimal</filename> or <filename>core-image-basic</filename>
+                    images.
+                </para>
+                <para>
+                    This variable is similar to the
+                    <filename><link linkend='var-MACHINE_EXTRA_RDEPENDS'>MACHINE_EXTRA_RDEPENDS</link></filename>
+                    variable with the exception that the image being built does not have a build
+                    dependency on the variable's list of packages.
+                    In other words, the image will build if a file in this list is not found.
+                </para>
+                <para>
+                    An example is a machine that has WiFi capability but is not essential
+                    For the machine to boot the image.
+                    However, if you are building a more fully-featured image, you want to enable
+                    WiFi.
+                    In this case, the package containing the WiFi kernel module will not be produced
+                    if the WiFi driver is built into the kernel, in which case you still want the
+                    build to succeed instead of failing as a result of the package not being found.
+                    To accomplish this, assuming the package for the module was called
+                    <filename>kernel-module-examplewifi</filename>, you would use the
+                    following in the <filename>.conf</filename> file for the machine:
+                    <literallayout class='monospaced'>
+     MACHINE_EXTRA_RRECOMMENDS += "kernel-module-examplewifi"
+                    </literallayout>
+                </para>
+            </glossdef>
+         </glossentry>
+
+         <glossentry id='var-MACHINE_FEATURES'><glossterm>MACHINE_FEATURES</glossterm>
+            <glossdef>
+                <para>Specifies the list of hardware features the
+                    <link linkend='var-MACHINE'>MACHINE</link> supports.
+                    For example, including the "bluetooth" feature causes the
+                    <filename>bluez</filename> bluetooth daemon to be built and
+                    added to the image.
+                    It also causes the <filename>connman</filename> recipe
+                    to look at <filename>MACHINE_FEATURES</filename> and when it
+                    finds "bluetooth" there it enables the bluetooth
+                    support in ConnMan.
+                </para>
+
+                <para>
+                    For a list of features supported by the Yocto Project as shipped,
+                    see the "<link linkend='ref-features-machine'>Machine</link>" section.
+                </para>
+            </glossdef>
+         </glossentry>
+
+        <glossentry id='var-MACHINE_FEATURES_BACKFILL'><glossterm>MACHINE_FEATURES_BACKFILL</glossterm>
+            <glossdef>
+                <para>Features to be added to
+                    <filename><link linkend='var-MACHINE_FEATURES'>MACHINE_FEATURES</link></filename>
+                    if not also present in
+                    <filename><link linkend='var-MACHINE_FEATURES_BACKFILL_CONSIDERED'>MACHINE_FEATURES_BACKFILL_CONSIDERED</link></filename>.
+                </para>
+
+                <para>
+                    This variable is set in the <filename>meta/conf/bitbake.conf</filename> file.
+                    It is not intended to be user-configurable.
+                    It is best to just reference the variable to see which machine features are
+                    being backfilled for all machine configurations.
+                    See the "<link linkend='ref-features-backfill'>Feature backfilling</link>" section for
+                    more information.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-MACHINE_FEATURES_BACKFILL_CONSIDERED'><glossterm>MACHINE_FEATURES_BACKFILL_CONSIDERED</glossterm>
+            <glossdef>
+                <para>Features from
+                    <filename><link linkend='var-MACHINE_FEATURES_BACKFILL'>MACHINE_FEATURES_BACKFILL</link></filename>
+                    that should not be backfilled (i.e. added to
+                    <filename><link linkend='var-MACHINE_FEATURES'>MACHINE_FEATURES</link></filename>)
+                    during the build.
+                    See the "<link linkend='ref-features-backfill'>Feature backfilling</link>" section for
+                    more information.
+                    </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-MACHINEOVERRIDES'><glossterm>MACHINEOVERRIDES</glossterm>
+            <glossdef>
+                <para>
+                    Lists overrides specific to the current machine.
+                    By default, this list includes the value
+                    of <filename><link linkend='var-MACHINE'>MACHINE</link></filename>.
+                    You can extend the list to apply variable overrides for
+                    classes of machines.
+                    For example, all QEMU emulated machines (e.g. qemuarm,
+                    qemux86, and so forth) include a common file named
+                    <filename>meta/conf/machine/include/qemu.inc</filename>
+                    that prepends <filename>MACHINEOVERRIDES</filename> with
+                    the following variable override:
+                    <literallayout class='monospaced'>
+    MACHINEOVERRIDES =. "qemuall:"
+                    </literallayout>
+                    Applying an override like <filename>qemuall</filename>
+                    affects all QEMU emulated machines elsewhere.
+                    Here is an example from the
+                    <filename>connman-conf</filename> recipe:
+                    <literallayout class='monospaced'>
+    SRC_URI_append_qemuall = "file://wired.config \
+                              file://wired-setup \
+                             "
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-MAINTAINER'><glossterm>MAINTAINER</glossterm>
+            <glossdef>
+                <para>The email address of the distribution maintainer.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-MIRRORS'><glossterm>MIRRORS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies additional paths from which the OpenEmbedded
+                    build system gets source code.
+                    When the build system searches for source code, it first
+                    tries the local download directory.
+                    If that location fails, the build system tries locations
+                    defined by
+                    <link linkend='var-PREMIRRORS'><filename>PREMIRRORS</filename></link>,
+                    the upstream source, and then locations specified by
+                    <filename>MIRRORS</filename> in that order.
+                </para>
+
+                <para>
+                    Assuming your distribution
+                    (<link linkend='var-DISTRO'><filename>DISTRO</filename></link>)
+                    is "poky", the default value for
+                    <filename>MIRRORS</filename> is defined in the
+                    <filename>conf/distro/poky.conf</filename> file in the
+                    <filename>meta-yocto</filename> Git repository.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-MLPREFIX'><glossterm>MLPREFIX</glossterm>
+            <glossdef>
+                <para>
+                    Specifies a prefix has been added to
+                    <link linkend='var-PN'><filename>PN</filename></link> to create a special version
+                    of a recipe or package, such as a Multilib version.
+                    The variable is used in places where the prefix needs to be
+                    added to or removed from a the name (e.g. the
+                    <link linkend='var-BPN'><filename>BPN</filename></link> variable).
+                    <filename>MLPREFIX</filename> gets set when a prefix has been
+                    added to <filename>PN</filename>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-MODULE_TARBALL_DEPLOY'><glossterm>MODULE_TARBALL_DEPLOY</glossterm>
+            <glossdef>
+                <para>
+                    Controls creation of the <filename>modules-*.tgz</filename>
+                    file.
+                    Set this variable to "0" to disable creation of this
+                    file, which contains all of the kernel modules resulting
+                    from a kernel build.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-MULTIMACH_TARGET_SYS'><glossterm>MULTIMACH_TARGET_SYS</glossterm>
+            <glossdef>
+                <para>
+                    Separates files for different machines such that you can build
+                    for multiple target machines using the same output directories.
+                    See the <link linkend='var-STAMP'><filename>STAMP</filename></link> variable
+                    for an example.
+                </para>
+            </glossdef>
+        </glossentry>
+
+    </glossdiv>
+
+    <glossdiv id='var-glossary-n'><title>N</title>
+
+        <glossentry id='var-NATIVELSBSTRING'><glossterm>NATIVELSBSTRING</glossterm>
+            <glossdef>
+                <para>
+                    A string identifying the host distribution.
+                    Strings consist of the host distributor ID
+                    followed by the release, as reported by the
+                    <filename>lsb_release</filename> tool
+                    or as read from <filename>/etc/lsb-release</filename>.
+                    For example, when running a build on Ubuntu 12.10, the value
+                    is "Ubuntu-12.10".
+                    If this information is unable to be determined, the value
+                    resolves to "Unknown".
+                </para>
+                <para>
+                    This variable is used by default to isolate native shared
+                    state packages for different distributions (e.g. to avoid
+                    problems with <filename>glibc</filename> version
+                    incompatibilities).
+                    Additionally, the variable is checked against
+                    <link linkend='var-SANITY_TESTED_DISTROS'><filename>SANITY_TESTED_DISTROS</filename></link>
+                    if that variable is set.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-NO_RECOMMENDATIONS'><glossterm>NO_RECOMMENDATIONS</glossterm>
+            <glossdef>
+                <para>
+                    Prevents installation of all "recommended-only" packages.
+                    Recommended-only packages are packages installed only
+                    through the
+                    <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>
+                    variable).
+                    Setting the <filename>NO_RECOMMENDATIONS</filename> variable
+                    to "1" turns this feature on:
+                    <literallayout class='monospaced'>
+     NO_RECOMMENDATIONS = "1"
+                    </literallayout>
+                    You can set this variable globally in your
+                    <filename>local.conf</filename> file or you can attach it to
+                    a specific image recipe by using the recipe name override:
+                    <literallayout class='monospaced'>
+     NO_RECOMMENDATIONS_pn-&lt;target_image&gt; = "&lt;package_name&gt;"
+                    </literallayout>
+                </para>
+
+                <para>
+                    It is important to realize that if you choose to not install
+                    packages using this variable and some other packages are
+                    dependent on them (i.e. listed in a recipe's
+                    <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>
+                    variable), the OpenEmbedded build system ignores your
+                    request and will install the packages to avoid dependency
+                    errors.
+                    <note>
+                        Some recommended packages might be required for certain
+                        system functionality, such as kernel modules.
+                        It is up to you to add packages with the
+                        <link linkend='var-IMAGE_INSTALL'><filename>IMAGE_INSTALL</filename></link>
+                        variable.
+                    </note>
+                </para>
+
+                <para>
+                    Support for this variable exists only when using the
+                    IPK and RPM packaging backend.
+                    Support does not exist for DEB.
+                </para>
+
+                <para>
+                    See the
+                    <link linkend='var-BAD_RECOMMENDATIONS'><filename>BAD_RECOMMENDATIONS</filename></link>
+                    and the
+                    <link linkend='var-PACKAGE_EXCLUDE'><filename>PACKAGE_EXCLUDE</filename></link>
+                    variables for related information.
+                </para>
+            </glossdef>
+        </glossentry>
+    </glossdiv>
+
+    <glossdiv id='var-glossary-o'><title>O</title>
+
+        <glossentry id='var-OE_BINCONFIG_EXTRA_MANGLE'><glossterm>OE_BINCONFIG_EXTRA_MANGLE</glossterm>
+            <glossdef>
+                <para>
+                    When a recipe inherits the
+                    <filename>binconfig.bbclass</filename> class, this variable
+                    specifies additional arguments passed to the "sed" command.
+                    The sed command alters any paths in configuration scripts
+                    that have been set up during compilation.
+                    Inheriting this class results in all paths in these scripts
+                    being changed to point into the
+                    <filename>sysroots/</filename> directory so that all builds
+                    that use the script will use the correct directories
+                    for the cross compiling layout.
+                </para>
+
+                <para>
+                    See the <filename>meta/classes/binconfig.bbclass</filename>
+                    in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+                    for details on how this class applies these additional
+                    sed command arguments.
+                    For general information on the
+                    <filename>binconfig.bbclass</filename> class, see the
+                    "<link linkend='ref-classes-binconfig'>Binary Configuration Scripts - <filename>binconfig.bbclass</filename></link>"
+                    section.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-OE_IMPORTS'><glossterm>OE_IMPORTS</glossterm>
+            <glossdef>
+                <para>
+                    An internal variable used to tell the OpenEmbedded build
+                    system what Python modules to import for every Python
+                    function run by the system.
+                </para>
+
+                <note>
+                    Do not set this variable.
+                    It is for internal use only.
+                </note>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-OE_TERMINAL'><glossterm>OE_TERMINAL</glossterm>
+            <glossdef>
+                <para>
+                    Controls how the OpenEmbedded build system spawns
+                    interactive terminals on the host development system
+                    (e.g. using the BitBake command with the
+                    <filename>-c devshell</filename> command-line option).
+                    For more information, see the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-appdev-devshell'>Using a Development Shell</ulink>" section
+                    in the Yocto Project Development Manual.
+                 </para>
+
+                 <para>
+                    You can use the following values for the
+                    <filename>OE_TERMINAL</filename> variable:
+                    <literallayout class='monospaced'>
+     auto
+     gnome
+     xfce
+     rxvt
+     screen
+     konsole
+     none
+                    </literallayout>
+                    <note>Konsole support only works for KDE 3.x.
+                        Also, "auto" is the default behavior for
+                        <filename>OE_TERMINAL</filename></note>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-OEROOT'><glossterm>OEROOT</glossterm>
+            <glossdef>
+                <para>
+                    The directory from which the top-level build environment
+                    setup script is sourced.
+                    The Yocto Project makes two top-level build environment
+                    setup scripts available:
+                    <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
+                    and
+                    <link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>.
+                    When you run one of these scripts, the
+                    <filename>OEROOT</filename> variable resolves to the
+                    directory that holds the script.
+                </para>
+
+                <para>
+                    For additional information on how this variable is used,
+                    see the initialization scripts.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-OLDEST_KERNEL'><glossterm>OLDEST_KERNEL</glossterm>
+            <glossdef>
+                <para>
+                    Declares the oldest version of the Linux kernel that the
+                    produced binaries must support.
+                    This variable is passed into the build of the Embedded
+                    GNU C Library (<filename>eglibc</filename>).
+                </para>
+
+                <para>
+                    The default for this variable comes from the
+                    <filename>meta/conf/bitbake.conf</filename> configuration
+                    file.
+                    You can override this default by setting the variable
+                    in a custom distribution configuration file.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-OVERRIDES'><glossterm>OVERRIDES</glossterm>
+            <glossdef>
+                <para>
+                    BitBake uses <filename>OVERRIDES</filename> to control
+                    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>.
+                </para>
+            </glossdef>
+        </glossentry>
+    </glossdiv>
+
+    <glossdiv id='var-glossary-p'><title>P</title>
+
+        <glossentry id='var-P'><glossterm>P</glossterm>
+            <glossdef>
+                <para>The recipe name and version.
+                    <filename>P</filename> is comprised of the following:
+                    <literallayout class='monospaced'>
+     ${PN}-${PV}
+                    </literallayout></para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PACKAGE_ARCH'><glossterm>PACKAGE_ARCH</glossterm>
+            <glossdef>
+                <para>The architecture of the resulting package or packages.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PACKAGE_BEFORE_PN'><glossterm>PACKAGE_BEFORE_PN</glossterm>
+            <glossdef>
+                <para>Enables easily adding packages to
+                <filename><link linkend='var-PACKAGES'>PACKAGES</link></filename>
+                before <filename>${<link linkend='var-PN'>PN</link>}</filename>
+                so that those added packages can pick up files that would normally be
+                included in the default package.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PACKAGE_CLASSES'><glossterm>PACKAGE_CLASSES</glossterm>
+            <glossdef>
+                <para>This variable, which is set in the <filename>local.conf</filename> configuration
+                    file found in the <filename>conf</filename> folder of the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>,
+                    specifies the package manager to use when packaging data.
+                    You can provide one or more arguments for the variable with the first
+                    argument being the package manager used to create images:
+                    <literallayout class='monospaced'>
+     PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk"
+                    </literallayout>
+                    For information on build performance effects as a result of the
+                    package manager use, see
+                    <link linkend='ref-classes-package'>Packaging - <filename>package*.bbclass</filename></link>
+                    in this manual.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PACKAGE_EXCLUDE'><glossterm>PACKAGE_EXCLUDE</glossterm>
+            <glossdef>
+                <para>
+                    Lists packages that should not be installed into an image.
+                    For example:
+                    <literallayout class='monospaced'>
+     PACKAGE_EXCLUDE = "&lt;package_name&gt; &lt;package_name&gt; &lt;package_name&gt; ..."
+                    </literallayout>
+                    You can set this variable globally in your
+                    <filename>local.conf</filename> file or you can attach it to
+                    a specific image recipe by using the recipe name override:
+                    <literallayout class='monospaced'>
+     PACKAGE_EXCLUDE_pn-&lt;target_image&gt; = "&lt;package_name&gt;"
+                    </literallayout>
+                </para>
+
+                <para>
+                    If you choose to not install
+                    a package using this variable and some other package is
+                    dependent on it (i.e. listed in a recipe's
+                    <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>
+                    variable), the OpenEmbedded build system generates a fatal
+                    installation error.
+                    Because the build system halts the process with a fatal
+                    error, you can use the variable with an iterative
+                    development process to remove specific components from a
+                    system.
+                </para>
+
+                <para>
+                    Support for this variable exists only when using the
+                    IPK and RPM packaging backend.
+                    Support does not exist for DEB.
+                </para>
+
+                <para>
+                    See the
+                    <link linkend='var-NO_RECOMMENDATIONS'><filename>NO_RECOMMENDATIONS</filename></link>
+                    and the
+                    <link linkend='var-BAD_RECOMMENDATIONS'><filename>BAD_RECOMMENDATIONS</filename></link>
+                    variables for related information.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PACKAGE_EXTRA_ARCHS'><glossterm>PACKAGE_EXTRA_ARCHS</glossterm>
+            <glossdef>
+                <para>Specifies the list of architectures compatible with the device CPU.
+                    This variable is useful when you build for several different devices that use
+                    miscellaneous processors such as XScale and ARM926-EJS).</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PACKAGE_GROUP'><glossterm>PACKAGE_GROUP</glossterm>
+            <glossdef>
+                <para>
+                    Defines one or more packages to include in an image when
+                    a specific item is included in
+                    <link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>.
+                    When setting the value, <filename>PACKAGE_GROUP</filename>
+                    should have the name of the feature item as an override.
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     PACKAGE_GROUP_widget = "package1 package2"
+                    </literallayout>
+                    In this example, if "widget" were added to
+                    <filename>IMAGE_FEATURES</filename>, "package1" and
+                    "package2" would be included in the image.
+                    <note>
+                        Packages installed by features defined through
+                        <filename>PACKAGE_GROUP</filename> are often package
+                        groups.
+                        While similarly named, you should not confuse the
+                        <filename>PACKAGE_GROUP</filename> variable with
+                        package groups, which are discussed elsewhere in the
+                        documentation.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PACKAGE_INSTALL'><glossterm>PACKAGE_INSTALL</glossterm>
+            <glossdef>
+                <para>
+                    The final list of packages passed to the package manager
+                    for installation into the image.
+                    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
+                    <link linkend='var-IMAGE_INSTALL'><filename>IMAGE_INSTALL</filename></link>
+                    variable to specify packages for installation.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PACKAGECONFIG'><glossterm>PACKAGECONFIG</glossterm>
+            <glossdef>
+                <para>
+                    This variable provides a means of enabling or disabling
+                    features of a recipe on a per-recipe basis.
+                    <filename>PACKAGECONFIG</filename> blocks are defined
+                    in recipes when you specify features and then arguments
+                    that define feature behaviors.
+                    Here is the basic block structure:
+                    <literallayout class='monospaced'>
+     PACKAGECONFIG ??= "f1 f2 f3 ..."
+     PACKAGECONFIG[f1] = "--with-f1,--without-f1,build-deps-f1,rt-deps-f1"
+     PACKAGECONFIG[f2] = "--with-f2,--without-f2,build-deps-f2,rt-deps-f2"
+     PACKAGECONFIG[f3] = "--with-f3,--without-f3,build-deps-f3,rt-deps-f3"
+                    </literallayout>
+                    The <filename>PACKAGECONFIG</filename>
+                    variable itself specifies a space-separated list of the
+                    features to enable.
+                    Following the features, you can determine the behavior of
+                    each feature by providing up to four order-dependent
+                    arguments, which are separated by commas.
+                    You can omit any argument you like but must retain the
+                    separating commas.
+                    The order is important and specifies the following:
+                    <orderedlist>
+                        <listitem><para>Extra arguments
+                            that should be added to the configure script
+                            argument list
+                            (<link linkend='var-EXTRA_OECONF'><filename>EXTRA_OECONF</filename></link>)
+                            if the feature is enabled.</para></listitem>
+                        <listitem><para>Extra arguments
+                            that should be added to <filename>EXTRA_OECONF</filename>
+                            if the feature is disabled.
+                            </para></listitem>
+                        <listitem><para>Additional build dependencies
+                            (<link linkend='var-DEPENDS'><filename>DEPENDS</filename></link>)
+                            that should be added if the feature is enabled.
+                            </para></listitem>
+                        <listitem><para>Additional runtime dependencies
+                            (<link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>)
+                            that should be added if the feature is enabled.
+                            </para></listitem>
+                    </orderedlist>
+                </para>
+
+                <para>
+                    Consider the following
+                    <filename>PACKAGECONFIG</filename> block taken from the
+                    <filename>librsvg</filename> recipe.
+                    In this example the feature is <filename>croco</filename>,
+                    which has three arguments that determine the feature's
+                    behavior.
+                    <literallayout class='monospaced'>
+     PACKAGECONFIG ??= "croco"
+     PACKAGECONFIG[croco] = "--with-croco,--without-croco,libcroco"
+                    </literallayout>
+                    The <filename>--with-croco</filename> and
+                    <filename>libcroco</filename> arguments apply only if
+                    the feature is enabled.
+                    In this case, <filename>--with-croco</filename> is
+                    added to the configure script argument list and
+                    <filename>libcroco</filename> is added to
+                    <filename><link linkend='var-DEPENDS'>DEPENDS</link></filename>.
+                    On the other hand, if the feature is disabled say through
+                    a <filename>.bbappend</filename> file in another layer, then
+                    the second argument <filename>--without-croco</filename> is
+                    added to the configure script rather than
+                    <filename>--with-croco</filename>.
+                </para>
+
+                <para>
+                    The basic <filename>PACKAGECONFIG</filename> structure
+                    previously described holds true regardless of whether you
+                    are creating a block or changing a block.
+                    When creating a block, use the structure inside your
+                    recipe.
+                </para>
+
+                <para>
+                    If you want to change an existing
+                    <filename>PACKAGECONFIG</filename> block, you can do so
+                    one of two ways:
+                    <itemizedlist>
+                        <listitem><para><emphasis>Append file:</emphasis>
+                            Create an append file named
+                            <filename>&lt;recipename&gt;.bbappend</filename> in your
+                            layer and override the value of
+                            <filename>PACKAGECONFIG</filename>.
+                            You can either completely override the variable:
+                            <literallayout class='monospaced'>
+     PACKAGECONFIG="f4 f5"
+                            </literallayout>
+                            Or, you can just append the variable:
+                            <literallayout class='monospaced'>
+     PACKAGECONFIG_append = " f4"
+                            </literallayout></para></listitem>
+                        <listitem><para><emphasis>Configuration file:</emphasis>
+                            This method is identical to changing the block
+                            through an append file except you edit your
+                            <filename>local.conf</filename> or
+                            <filename>&lt;mydistro&gt;.conf</filename> file.
+                            As with append files previously described,
+                            you can either completely override the variable:
+                            <literallayout class='monospaced'>
+     PACKAGECONFIG_pn-&lt;recipename&gt;="f4 f5"
+                            </literallayout>
+                            Or, you can just amended the variable:
+                            <literallayout class='monospaced'>
+     PACKAGECONFIG_append_pn-&lt;recipename&gt; = " f4"
+                            </literallayout></para></listitem>
+                    </itemizedlist>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PACKAGES'><glossterm>PACKAGES</glossterm>
+            <glossdef>
+                <para>The list of packages to be created from the recipe.
+                    The default value is the following:
+                    <literallayout class='monospaced'>
+     ${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}
+                    </literallayout></para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PACKAGES_DYNAMIC'><glossterm>PACKAGES_DYNAMIC</glossterm>
+            <glossdef>
+                <para>
+                    A promise that your recipe satisfies runtime dependencies
+                    for optional modules that are found in other recipes.
+                    <filename>PACKAGES_DYNAMIC</filename>
+                    does not actually satisfy the dependencies, it only states that
+                    they should be satisfied.
+                    For example, if a hard, runtime dependency
+                    (<link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>)
+                    of another package is satisfied
+                    at build time through the <filename>PACKAGES_DYNAMIC</filename>
+                    variable, but a package with the module name is never actually
+                    produced, then the other package will be broken.
+                    Thus, if you attempt to include that package in an image,
+                    you will get a dependency failure from the packaging system
+                    during <filename>do_rootfs</filename>.
+                </para>
+                <para>
+                    Typically, if there is a chance that such a situation can
+                    occur and the package that is not created is valid
+                    without the dependency being satisfied, then you should use
+                    <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>
+                    (a soft runtime dependency) instead of
+                    <filename>RDEPENDS</filename>.
+                </para>
+
+                <para>
+                    For an example of how to use the <filename>PACKAGES_DYNAMIC</filename>
+                    variable when you are splitting packages, see the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#handling-optional-module-packaging'>Handling Optional Module Packaging</ulink>" section
+                    in the Yocto Project Development Manual.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PARALLEL_MAKE'><glossterm>PARALLEL_MAKE</glossterm>
+            <glossdef>
+                <para>
+                    Extra options that are passed to the
+                    <filename>make</filename> command during the
+                    <filename>do_compile</filename> task in order to specify
+                    parallel compilation.
+                    This variable is usually in the form
+                    <filename>-j 4</filename>, where the number
+                    represents the maximum number of parallel threads make can
+                    run.
+                    If you development host supports multiple cores a good
+                    rule of thumb is to set this variable to twice the number
+                    of cores on the host.
+                    <note>
+                        Individual recipes might clear out this variable if
+                        the software being built has problems running its
+                        <filename>make</filename> process in parallel.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PARALLEL_MAKEINST'><glossterm>PARALLEL_MAKEINST</glossterm>
+            <glossdef>
+                <para>
+                    Extra options passed to the
+                    <filename>make install</filename> command during the
+                    <filename>do_install</filename> task in order to specify
+                    parallel installation.
+                    This variable defaults to the value of
+                    <link linkend='var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></link>.
+                    <note>
+                        Individual recipes might clear out this variable if
+                        the software being built has problems running its
+                        <filename>make install</filename> process in parallel.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PATCHRESOLVE'><glossterm>PATCHRESOLVE</glossterm>
+            <glossdef>
+                <para>
+                    Determines the action to take when a patch fails.
+                    You can set this variable to one of two values: "noop" and
+                    "user".
+                </para>
+
+                <para>
+                    The default value of "noop" causes the build to simply fail
+                    when the OpenEmbedded build system cannot successfully
+                    apply a patch.
+                    Setting the value to "user" causes the build system to
+                    launch a shell and places you in the right location so that
+                    you can manually resolve the conflicts.
+                </para>
+
+                <para>
+                    Set this variable in your
+                    <filename>local.conf</filename> file.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PATCHTOOL'><glossterm>PATCHTOOL</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the utility used to apply patches for a recipe
+                    during <filename>do_patch</filename>.
+                    You can specify one of three utilities: "patch", "quilt", or
+                    "git".
+                    The default utility used is "quilt" except for the
+                    quilt-native recipe itself.
+                    Because the quilt tool is not available at the
+                    time quilt-native is being patched, it uses "patch".
+                </para>
+
+                <para>
+                    If you wish to use an alternative patching tool, set the
+                    variable in the recipe using one of the following:
+                    <literallayout class='monospaced'>
+     PATCHTOOL = "patch"
+     PATCHTOOL = "quilt"
+     PATCHTOOL = "git"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PE'><glossterm>PE</glossterm>
+            <glossdef>
+                <para>
+                    the epoch of the recipe.
+                    By default, this variable is unset.
+                    The field is used to make upgrades possible when the
+                    versioning scheme changes in some backwards incompatible
+                    way.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PF'><glossterm>PF</glossterm>
+            <glossdef>
+                <para>Specifies the recipe or package name and includes all version and revision
+                    numbers (i.e. <filename>eglibc-2.13-r20+svnr15508/</filename> and
+                    <filename>bash-4.2-r1/</filename>).
+                    This variable is comprised of the following:
+                    <literallayout class='monospaced'>
+     ${<link linkend='var-PN'>PN</link>}-${<link linkend='var-EXTENDPE'>EXTENDPE</link>}${<link linkend='var-PV'>PV</link>}-${<link linkend='var-PR'>PR</link>}
+                    </literallayout></para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PKGD'><glossterm>PKGD</glossterm>
+            <glossdef>
+                <para>
+                    Points to the destination directory for files to be
+                    packaged before they are split into individual packages.
+                    This directory defaults to the following:
+                    <literallayout class='monospaced'>
+     ${WORKDIR}/package
+                    </literallayout>
+                    Do not change this default.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PKGDATA_DIR'><glossterm>PKGDATA_DIR</glossterm>
+            <glossdef>
+                <para>
+                    Points to a shared, global-state directory that holds data
+                    generated during the packaging process.
+                    During the packaging process, the
+                    <filename>do_packagedata</filename> task packages
+                    data for each recipe and installs it into this temporary,
+                    shared area.
+                    This directory defaults to the following:
+                    <literallayout class='monospaced'>
+     ${STAGING_DIR_HOST}/pkgdata
+                    </literallayout>
+                    Do not change this default.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PKGDEST'><glossterm>PKGDEST</glossterm>
+            <glossdef>
+                <para>
+                    Points to the parent directory for files to be packaged
+                    after they have been split into individual packages.
+                    This directory defaults to the following:
+                    <literallayout class='monospaced'>
+     ${WORKDIR}/packages-split
+                    </literallayout>
+                    Under this directory, the build system creates
+                    directories for each package specified in
+                    <link linkend='var-PACKAGES'><filename>PACKAGES</filename></link>.
+                    Do not change this default.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PKGDESTWORK'><glossterm>PKGDESTWORK</glossterm>
+            <glossdef>
+                <para>
+                    Points to a temporary work area used by the
+                    <filename>do_package</filename> task to write output
+                    from the <filename>do_packagedata</filename> task.
+                    The <filename>PKGDESTWORK</filename> location defaults to
+                    the following:
+                    <literallayout class='monospaced'>
+     ${WORKDIR}/pkgdata
+                    </literallayout>
+                    The <filename>do_packagedata</filename> task then packages
+                    the data in the temporary work area and installs it into a
+                    shared directory pointed to by
+                    <link linkend='var-PKGDATA_DIR'><filename>PKGDATA_DIR</filename></link>.
+                </para>
+
+                <para>
+                    Do not change this default.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PN'><glossterm>PN</glossterm>
+            <glossdef>
+                <para>This variable can have two separate functions depending on the context: a recipe
+                    name or a resulting package name.</para>
+                <para><filename>PN</filename> refers to a recipe name in the context of a file used
+                    by the OpenEmbedded build system as input to create a package.
+                    The name is normally extracted from the recipe file name.
+                    For example, if the recipe is named
+                    <filename>expat_2.0.1.bb</filename>, then the default value of <filename>PN</filename>
+                    will be "expat".</para>
+                <para>
+                    The variable refers to a package name in the context of a file created or produced by the
+                    OpenEmbedded build system.</para>
+                <para>If applicable, the <filename>PN</filename> variable also contains any special
+                    suffix or prefix.
+                    For example, using <filename>bash</filename> to build packages for the native
+                    machine, <filename>PN</filename> is <filename>bash-native</filename>.
+                    Using <filename>bash</filename> to build packages for the target and for Multilib,
+                    <filename>PN</filename> would be <filename>bash</filename> and
+                    <filename>lib64-bash</filename>, respectively.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PR'><glossterm>PR</glossterm>
+            <glossdef>
+                <para>The revision of the recipe.
+                    The default value for this variable is "r0".
+                    </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PREFERRED_PROVIDER'><glossterm>PREFERRED_PROVIDER</glossterm>
+            <glossdef>
+                <para>
+                    If multiple recipes provide an item, this variable
+                    determines which recipe should be given preference.
+                    You should always suffix the variable with the name of the
+                    provided item, and you should set it to the
+                    <link linkend='var-PN'><filename>PN</filename></link>
+                    of the recipe to which you want to give precedence.
+                    Some examples:
+                    <literallayout class='monospaced'>
+     PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
+     PREFERRED_PROVIDER_virtual/xserver = "xserver-xf86"
+     PREFERRED_PROVIDER_virtual/libgl ?= "mesa"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PREFERRED_VERSION'><glossterm>PREFERRED_VERSION</glossterm>
+            <glossdef>
+                <para>
+                    If there are multiple versions of recipes available, this
+                    variable determines which recipe should be given preference.
+                    You must always suffix the variable with the
+                    <link linkend='var-PN'><filename>PN</filename></link>
+                    you want to select, and you should set the
+                    <link linkend='var-PV'><filename>PV</filename></link>
+                    accordingly for precedence.
+                    You can use the "<filename>%</filename>" character as a
+                    wildcard to match any number of characters, which can be
+                    useful when specifying versions that contain long revision
+                    numbers that could potentially change.
+                    Here are two examples:
+                    <literallayout class='monospaced'>
+     PREFERRED_VERSION_python = "2.7.3"
+     PREFERRED_VERSION_linux-yocto = "3.10%"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PREMIRRORS'><glossterm>PREMIRRORS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies additional paths from which the OpenEmbedded
+                    build system gets source code.
+                    When the build system searches for source code, it first
+                    tries the local download directory.
+                    If that location fails, the build system tries locations
+                    defined by <filename>PREMIRRORS</filename>, the upstream
+                    source, and then locations specified by
+                    <link linkend='var-MIRRORS'><filename>MIRRORS</filename></link>
+                    in that order.
+                </para>
+
+                <para>
+                    Assuming your distribution
+                    (<link linkend='var-DISTRO'><filename>DISTRO</filename></link>)
+                    is "poky", the default value for
+                    <filename>PREMIRRORS</filename> is defined in the
+                    <filename>conf/distro/poky.conf</filename> file in the
+                    <filename>meta-yocto</filename> Git repository.
+                </para>
+
+                <para>
+                    Typically, you could add a specific server for the
+                    build system to attempt before any others by adding
+                    something like the following to the
+                    <filename>local.conf</filename> configuration file in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>:
+                    <literallayout class='monospaced'>
+     PREMIRRORS_prepend = "\
+     git://.*/.* http://www.yoctoproject.org/sources/ \n \
+     ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
+     http://.*/.* http://www.yoctoproject.org/sources/ \n \
+     https://.*/.* http://www.yoctoproject.org/sources/ \n"
+                    </literallayout>
+                    These changes cause the build system to intercept
+                    Git, FTP, HTTP, and HTTPS requests and direct them to
+                    the <filename>http://</filename> sources mirror.
+                    You can use <filename>file://</filename> URLs to point
+                    to local directories or network shares as well.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PRINC'><glossterm>PRINC</glossterm>
+            <glossdef>
+                <para>Causes the <link linkend='var-PR'><filename>PR</filename></link>
+                    variable of <filename>.bbappend</filename> files to
+                    dynamically increment.
+                    This increment minimizes the impact of layer ordering.</para>
+                <para>In order to ensure multiple <filename>.bbappend</filename> files can co-exist,
+                    <filename>PRINC</filename> should be self-referencing.
+                    This variable defaults to 0.</para>
+                <para>Following is an example that increments <filename>PR</filename> by two:
+                    <literallayout class='monospaced'>
+     PRINC := "${@int(PRINC) + 2}"
+                    </literallayout>
+                    It is advisable not to use strings such as ".= '.1'" with the variable because
+                    this usage is very sensitive to layer ordering.
+                    You should avoid explicit assignments as they cannot
+                    adequately represent multiple
+                    <filename>.bbappend</filename> files.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PROVIDES'><glossterm>PROVIDES</glossterm>
+            <glossdef>
+                <para>
+                    A list of aliases that a recipe also provides.
+                    These aliases are useful for satisfying dependencies of
+                    other recipes during the build (as specified by
+                    <filename><link linkend='var-DEPENDS'>DEPENDS</link></filename>).
+                    <note>
+                        A recipe's own
+                        <filename><link linkend='var-PN'>PN</link></filename>
+                        is implicitly already in its
+                        <filename>PROVIDES</filename> list.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PV'><glossterm>PV</glossterm>
+            <glossdef>
+                <para>The version of the recipe.
+                    The version is normally extracted from the recipe filename.
+                    For example, if the recipe is named
+                    <filename>expat_2.0.1.bb</filename>, then the default value of <filename>PV</filename>
+                    will be "2.0.1".
+                    <filename>PV</filename> is generally not overridden within
+                    a recipe unless it is building an unstable (i.e. development) version from a source code repository
+                    (e.g. Git or Subversion).
+                 </para>
+            </glossdef>
+        </glossentry>
+
+    </glossdiv>
+
+<!--            <glossdiv id='var-glossary-q'><title>Q</title>-->
+<!--            </glossdiv>-->
+
+    <glossdiv id='var-glossary-r'><title>R</title>
+
+        <glossentry id='var-RCONFLICTS'><glossterm>RCONFLICTS</glossterm>
+            <glossdef>
+                <para>
+                    The list of packages that conflict with packages.
+                    Note that packages will not be installed if conflicting
+                    packages are not first removed.
+                </para>
+
+                <para>
+                   Like all package-controlling variables, you must always use
+                   them in conjunction with a package name override.
+                   Here is an example:
+                   <literallayout class='monospaced'>
+     RCONFLICTS_${PN} = "another-conflicting-package-name"
+                   </literallayout>
+                </para>
+
+                <para>
+                    BitBake, which the OpenEmbedded build system uses, supports
+                    specifying versioned dependencies.
+                    Although the syntax varies depending on the packaging
+                    format, BitBake hides these differences from you.
+                    Here is the general syntax to specify versions with
+                    the <filename>RCONFLICTS</filename> variable:
+                    <literallayout class='monospaced'>
+     RCONFLICTS_${PN} = "&lt;package&gt; (&lt;operator&gt; &lt;version&gt;)"
+                    </literallayout>
+                    For <filename>operator</filename>, you can specify the
+                    following:
+                    <literallayout class='monospaced'>
+     =
+     &lt;
+     &gt;
+     &lt;=
+     &gt;=
+                    </literallayout>
+                    For example, the following sets up a dependency on version
+                    1.2 or greater of the package <filename>foo</filename>:
+                    <literallayout class='monospaced'>
+     RCONFLICTS_${PN} = "foo (>= 1.2)"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-RDEPENDS'><glossterm>RDEPENDS</glossterm>
+            <glossdef>
+                <para>
+                    Lists a package's runtime dependencies (i.e. other packages)
+                    that must be installed in order for the built package to run
+                    correctly.
+                    If a package in this list cannot be found during the build,
+                    you will get a build error.
+                </para>
+
+                <para>
+                    When you use the <filename>RDEPENDS</filename> variable
+                    in a recipe, you are essentially stating that the recipe's
+                    <filename>do_build</filename> task depends on the existence
+                    of a specific package.
+                    Consider this simple example for two recipes named "a" and
+                    "b" that produce similarly named packages.
+                    In this example, the <filename>RDEPENDS</filename>
+                    statement appears in the "a" recipe:
+                    <literallayout class='monospaced'>
+     RDEPENDS_${PN} = "b"
+                    </literallayout>
+                    Here, the dependency is such that the
+                    <filename>do_build</filename> task for recipe "a" depends
+                    on the <filename>do_package_write</filename> task
+                    of recipe "b".
+                    This means the package file for "b" must be available when
+                    the output for recipe "a" has been completely built.
+                    More importantly, package "a" will be marked as depending
+                    on package "b" in a manner that is understood by the
+                    package manager in use (i.e. rpm, opkg, or dpkg).
+                </para>
+
+                <para>
+                    The names of the packages you list within
+                    <filename>RDEPENDS</filename> must be the names of other
+                    packages - they cannot be recipe names.
+                    Although package names and recipe names usually match,
+                    the important point here is that you are
+                    providing package names within the
+                    <filename>RDEPENDS</filename> variable.
+                    For an example of the default list of packages created from
+                    a recipe, see the
+                    <link linkend='var-PACKAGES'><filename>PACKAGES</filename></link>
+                    variable.
+                </para>
+
+                <para>
+                    Because the <filename>RDEPENDS</filename> variable applies
+                    to packages being built, you should always use the variable
+                    in a form with an attached package name.
+                    For example, suppose you are building a development package
+                    that depends on the <filename>perl</filename> package.
+                    In this case, you would use the following
+                    <filename>RDEPENDS</filename> statement:
+                    <literallayout class='monospaced'>
+     RDEPENDS_${PN}-dev += "perl"
+                    </literallayout>
+                    In the example, the development package depends on
+                    the <filename>perl</filename> package.
+                    Thus, the <filename>RDEPENDS</filename> variable has the
+                    <filename>${PN}-dev</filename> package name as part of the
+                    variable.
+                </para>
+
+                <para>
+                    The package name you attach to the
+                    <filename>RDEPENDS</filename> variable must appear
+                    as it would in the <filename>PACKAGES</filename>
+                    namespace before any renaming of the output package by
+                    classes like <filename>debian.bbclass</filename>.
+                </para>
+
+                <para>
+                    In many cases you do not need to explicitly add
+                    runtime dependencies using
+                    <filename>RDEPENDS</filename> since some automatic
+                    handling occurs:
+                    <itemizedlist>
+                        <listitem><para><emphasis><filename>shlibdeps</filename></emphasis>:  If
+                            a runtime package contains a shared library
+                            (<filename>.so</filename>), the build
+                            processes the library in order to determine other
+                            libraries to which it is dynamically linked.
+                            The build process adds these libraries to
+                            <filename>RDEPENDS</filename> when creating the runtime
+                            package.</para></listitem>
+                        <listitem><para><emphasis><filename>pcdeps</filename></emphasis>:  If
+                            the package ships a <filename>pkg-config</filename>
+                            information file, the build process uses this file
+                            to add items to the <filename>RDEPENDS</filename>
+                            variable to create the runtime packages.
+                            </para></listitem>
+                    </itemizedlist>
+                </para>
+
+                <para>
+                    BitBake, which the OpenEmbedded build system uses, supports
+                    specifying versioned dependencies.
+                    Although the syntax varies depending on the packaging
+                    format, BitBake hides these differences from you.
+                    Here is the general syntax to specify versions with
+                    the <filename>RDEPENDS</filename> variable:
+                    <literallayout class='monospaced'>
+     RDEPENDS_${PN} = "&lt;package&gt; (&lt;operator&gt; &lt;version&gt;)"
+                    </literallayout>
+                    For <filename>operator</filename>, you can specify the
+                    following:
+                    <literallayout class='monospaced'>
+     =
+     &lt;
+     &gt;
+     &lt;=
+     &gt;=
+                    </literallayout>
+                    For example, the following sets up a dependency on version
+                    1.2 or greater of the package <filename>foo</filename>:
+                    <literallayout class='monospaced'>
+     RDEPENDS_${PN} = "foo (>= 1.2)"
+                    </literallayout>
+                </para>
+
+                <para>
+                    For information on build-time dependencies, see the
+                    <link linkend='var-DEPENDS'><filename>DEPENDS</filename></link>
+                    variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-RM_OLD_IMAGE'><glossterm>RM_OLD_IMAGE</glossterm>
+            <glossdef>
+                <para>
+                    Reclaims disk space by removing previously built
+                    versions of the same image from the
+                    <filename>images</filename> directory pointed to by the
+                    <link linkend='var-DEPLOY_DIR'><filename>DEPLOY_DIR</filename></link>
+                    variable.
+                </para>
+
+                <para>
+                    Set this variable to "1" in your
+                    <filename>local.conf</filename> file to remove these
+                    images.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-RM_WORK_EXCLUDE'><glossterm>RM_WORK_EXCLUDE</glossterm>
+            <glossdef>
+                <para>
+                    With <filename>rm_work</filename> enabled, this
+                    variable specifies a list of recipes whose work directories
+                    should not be removed.
+                    See the "<link linkend='ref-classes-rm-work'>Removing Work Files During the Build - <filename>rm_work.bbclass</filename></link>"
+                    section for more details.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-ROOTFS_POSTPROCESS_COMMAND'><glossterm>ROOTFS_POSTPROCESS_COMMAND</glossterm>
+            <glossdef>
+                <para>
+                    Added by classes to run post processing commands once the
+                    OpenEmbedded build system has created the root filesystem.
+                    You can specify shell commands separated by semicolons:
+                    <literallayout class='monospaced'>
+     ROOTFS_POSTPROCESS_COMMAND += "&lt;shell_command&gt;; ... "
+                    </literallayout>
+                    If you need to pass the path to the root filesystem within
+                    the command, you can use
+                    <filename>${IMAGE_ROOTFS}</filename>, which points to
+                    the root filesystem image.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-RPROVIDES'><glossterm>RPROVIDES</glossterm>
+            <glossdef>
+                <para>
+                    A list of package name aliases that a package also provides.
+                    These aliases are useful for satisfying runtime dependencies
+                    of other packages both during the build and on the target
+                    (as specified by
+                    <filename><link linkend='var-RDEPENDS'>RDEPENDS</link></filename>).
+                    <note>
+                        A package's own name is implicitly already in its
+                        <filename>RPROVIDES</filename> list.
+                    </note>
+                </para>
+                <para>
+                   As with all package-controlling variables, you must always
+                   use the variable in conjunction with a package name override.
+                   Here is an example:
+                   <literallayout class='monospaced'>
+     RPROVIDES_${PN} = "widget-abi-2"
+                   </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-RRECOMMENDS'><glossterm>RRECOMMENDS</glossterm>
+            <glossdef>
+                <para>
+                    A list of packages that extends the usability of a package
+                    being built.
+                    The package being built does not depend on this list of
+                    packages in order to successfully build, but needs them for
+                    the extended usability.
+                    To specify runtime dependencies for packages, see the
+                    <filename><link linkend='var-RDEPENDS'>RDEPENDS</link></filename>
+                    variable.
+                </para>
+
+                <para>
+                    The OpenEmbedded build process automatically installs the
+                    list of packages as part of the built package.
+                    However, you can remove these packages later if you want.
+                    If, during the build, a package from the
+                    <filename>RRECOMMENDS</filename> list cannot be
+                    found, the build process continues without an error.
+                </para>
+
+                <para>
+                    You can also prevent packages in the list from being
+                    installed by using several variables.
+                    See the
+                    <link linkend='var-BAD_RECOMMENDATIONS'><filename>BAD_RECOMMENDATIONS</filename></link>,
+                    <link linkend='var-NO_RECOMMENDATIONS'><filename>NO_RECOMMENDATIONS</filename></link>,
+                    and
+                    <link linkend='var-PACKAGE_EXCLUDE'><filename>PACKAGE_EXCLUDE</filename></link>
+                    variables for more information.
+                </para>
+
+                <para>
+                    Because the <filename>RRECOMMENDS</filename> variable
+                    applies to packages being built, you should always attach
+                    an override to the variable to specify the particular
+                    package whose usability is being extended.
+                    For example, suppose you are building a development package
+                    that is extended to support wireless functionality.
+                    In this case, you would use the following:
+                    <literallayout class='monospaced'>
+     RRECOMMENDS_${PN}-dev += "&lt;wireless_package_name&gt;"
+                    </literallayout>
+                    In the example, the package name
+                    (<filename>${<link linkend='var-PN'>PN</link>}-dev</filename>)
+                    must appear as it would in the
+                    <filename><link linkend='var-PACKAGES'>PACKAGES</link></filename>
+                    namespace before any renaming of the output package by
+                    classes such as <filename>debian.bbclass</filename>.
+                </para>
+
+                <para>
+                    BitBake, which the OpenEmbedded build system uses, supports
+                    specifying versioned recommends.
+                    Although the syntax varies depending on the packaging
+                    format, BitBake hides these differences from you.
+                    Here is the general syntax to specify versions with
+                    the <filename>RRECOMMENDS</filename> variable:
+                    <literallayout class='monospaced'>
+     RRECOMMENDS_${PN} = "&lt;package&gt; (&lt;operator&gt; &lt;version&gt;)"
+                    </literallayout>
+                    For <filename>operator</filename>, you can specify the
+                    following:
+                    <literallayout class='monospaced'>
+     =
+     &lt;
+     &gt;
+     &lt;=
+     &gt;=
+                    </literallayout>
+                    For example, the following sets up a recommend on version
+                    1.2 or greater of the package <filename>foo</filename>:
+                    <literallayout class='monospaced'>
+     RRECOMMENDS_${PN} = "foo (>= 1.2)"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-RREPLACES'><glossterm>RREPLACES</glossterm>
+            <glossdef>
+                <para>
+                    A list of packages replaced by a package.
+                    The package manager uses this variable to determine which
+                    package should be installed to replace other package(s)
+                    during an upgrade.
+                    In order to also have the other package(s) removed at the
+                    same time, you must add the name of the other
+                    package to the
+                    <filename><link linkend='var-RCONFLICTS'>RCONFLICTS</link></filename> variable.
+                </para>
+                <para>
+                   As with all package-controlling variables, you must use
+                   this variable in conjunction with a package name
+                   override.
+                   Here is an example:
+                   <literallayout class='monospaced'>
+     RREPLACES_${PN} = "other-package-being-replaced"
+                   </literallayout>
+                </para>
+
+                <para>
+                    BitBake, which the OpenEmbedded build system uses, supports
+                    specifying versioned replacements.
+                    Although the syntax varies depending on the packaging
+                    format, BitBake hides these differences from you.
+                    Here is the general syntax to specify versions with
+                    the <filename>RREPLACES</filename> variable:
+                    <literallayout class='monospaced'>
+     RREPLACES_${PN} = "&lt;package&gt; (&lt;operator&gt; &lt;version&gt;)"
+                    </literallayout>
+                    For <filename>operator</filename>, you can specify the
+                    following:
+                    <literallayout class='monospaced'>
+     =
+     &lt;
+     &gt;
+     &lt;=
+     &gt;=
+                    </literallayout>
+                    For example, the following sets up a replacement using
+                    version 1.2 or greater of the package
+                    <filename>foo</filename>:
+                    <literallayout class='monospaced'>
+     RREPLACES_${PN} = "foo (>= 1.2)"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-RSUGGESTS'><glossterm>RSUGGESTS</glossterm>
+            <glossdef>
+                <para>
+                    A list of additional packages that you can suggest for
+                    installation by the package manager at the time a package
+                    is installed.
+                    Not all package managers support this functionality.
+                </para>
+                <para>
+                   As with all package-controlling variables, you must always
+                   use this variable in conjunction with a package name
+                   override.
+                   Here is an example:
+                   <literallayout class='monospaced'>
+     RSUGGESTS_${PN} = "useful-package another-package"
+                   </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+    </glossdiv>
+
+    <glossdiv id='var-glossary-s'><title>S</title>
+
+        <glossentry id='var-S'><glossterm>S</glossterm>
+            <glossdef>
+                <para>
+                    The location in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+                    where unpacked recipe source code resides.
+                    This location is within the working directory
+                    (<filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>),
+                    which is not static.
+                    The unpacked source location depends on the recipe name
+                    (<filename><link linkend='var-PN'>PN</link></filename>) and
+                    recipe version
+                    (<filename><link linkend='var-PV'>PV</link></filename>) as
+                    follows:
+                    <literallayout class='monospaced'>
+     ${WORKDIR}/${PN}-${PV}
+                    </literallayout>
+                    As an example, assume a
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+                    top-level folder named <filename>poky</filename> and a
+                    default Build Directory at <filename>poky/build</filename>.
+                    In this case, the working directory the build system uses
+                    to keep the unpacked recipe for <filename>db</filename>
+                    is the following:
+                    <literallayout class='monospaced'>
+     poky/build/tmp/work/qemux86-poky-linux/db/5.1.19-r3/db-5.1.19
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SANITY_TESTED_DISTROS'><glossterm>SANITY_TESTED_DISTROS</glossterm>
+            <glossdef>
+                <para>
+                    A list of the host distribution identifiers that the
+                    build system has been tested against.
+                    Identifiers consist of the host distributor ID
+                    followed by the release,
+                    as reported by the <filename>lsb_release</filename> tool
+                    or as read from <filename>/etc/lsb-release</filename>.
+                    Separate the list items with explicit newline
+                    characters (<filename>\n</filename>).
+                    If <filename>SANITY_TESTED_DISTROS</filename> is not empty
+                    and the current value of
+                    <link linkend='var-NATIVELSBSTRING'><filename>NATIVELSBSTRING</filename></link>
+                    does not appear in the list, then the build system reports
+                    a warning that indicates the current host distribution has
+                    not been tested as a build host.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SDK_ARCH'><glossterm>SDK_ARCH</glossterm>
+            <glossdef>
+                <para>
+                    The target architecture for the SDK.
+                    Typically, you do not directly set this variable.
+                    Instead, use
+                    <link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SDK_NAME'><glossterm>SDK_NAME</glossterm>
+            <glossdef>
+                <para>
+                    The base name for SDK output files.
+                    The name is derived from the
+                    <link linkend='var-DISTRO'><filename>DISTRO</filename></link>,
+                    <link linkend='var-TCLIBC'><filename>TCLIBC</filename></link>,
+                    <link linkend='var-SDK_ARCH'><filename>SDK_ARCH</filename></link>,
+                    <link linkend='var-IMAGE_BASENAME'><filename>IMAGE_BASENAME</filename></link>,
+                    and
+                    <link linkend='var-TUNE_PKGARCH'><filename>TUNE_PKGARCH</filename></link>
+                    variables:
+                    <literallayout class='monospaced'>
+     SDK_NAME = "${DISTRO}-${TCLIBC}-${SDK_ARCH}-${IMAGE_BASENAME}-${TUNE_PKGARCH}"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SDKIMAGE_FEATURES'><glossterm>SDKIMAGE_FEATURES</glossterm>
+            <glossdef>
+                <para>Equivalent to
+                    <filename><link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></filename>.
+                    However, this variable applies to the SDK generated from an
+                    image using the following command:
+                    <literallayout class='monospaced'>
+     $ bitbake -c populate_sdk imagename
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SDKMACHINE'><glossterm>SDKMACHINE</glossterm>
+            <glossdef>
+                <para>
+                    The architecture of the machine that runs Application
+                    Development Toolkit (ADT) items.
+                    In other words, packages are built so that they will run
+                    on the target you specify with the argument.
+                    This implies that you can build out ADT/SDK items that
+                    run on an architecture other than that of your build host.
+                    For example, you can use an x86_64-based build host to
+                    create packages that will run on an i686-based
+                    SDK Machine.
+                </para>
+
+                <para>
+                    You can use "i686" and "x86_64" as possible values for this
+                    variable.
+                    The variable defaults to "i686" and is set in the
+                    <filename>local.conf</filename> file in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+                    <literallayout class='monospaced'>
+     SDKMACHINE ?= "i686"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SECTION'><glossterm>SECTION</glossterm>
+            <glossdef>
+                <para>The section in which packages should be categorized.
+                    Package management utilities can make use of this variable.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SELECTED_OPTIMIZATION'><glossterm>SELECTED_OPTIMIZATION</glossterm>
+            <glossdef>
+                <para>
+                    The variable takes the value of
+                    <filename><link linkend='var-FULL_OPTIMIZATION'>FULL_OPTIMIZATION</link></filename>
+                    unless <filename><link linkend='var-DEBUG_BUILD'>DEBUG_BUILD</link></filename> = "1".
+                    In this case the value of
+                    <filename><link linkend='var-DEBUG_OPTIMIZATION'>DEBUG_OPTIMIZATION</link></filename> is used.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SERIAL_CONSOLE'><glossterm>SERIAL_CONSOLE</glossterm>
+            <glossdef>
+                <para>
+                    Defines a serial console (TTY) to enable using getty.
+                    Provide a value that specifies the baud rate followed by
+                    the TTY device name separated by a space.
+                    You cannot specify more than one TTY device:
+                    <literallayout class='monospaced'>
+     SERIAL_CONSOLE = "115200 ttyS0"
+                    </literallayout>
+                    <note>
+                        The <filename>SERIAL_CONSOLE</filename> variable
+                        is deprecated.
+                        Please use the
+                        <link linkend='var-SERIAL_CONSOLES'><filename>SERIAL_CONSOLES</filename></link>
+                        variable.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SERIAL_CONSOLES'><glossterm>SERIAL_CONSOLES</glossterm>
+            <glossdef>
+                <para>
+                    Defines the serial consoles (TTYs) to enable using getty.
+                    Provide a value that specifies the baud rate followed by
+                    the TTY device name separated by a semicolon.
+                    Use spaces to separate multiple devices:
+                    <literallayout class='monospaced'>
+     SERIAL_CONSOLES = "115200;ttyS0 115200;ttyS1"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SERIAL_CONSOLES_CHECK'><glossterm>SERIAL_CONSOLES_CHECK</glossterm>
+            <glossdef>
+                <para>
+                    Similar to
+                    <link linkend='var-SERIAL_CONSOLES'><filename>SERIAL_CONSOLES</filename></link>
+                    except the device is checked for existence before attempting
+                    to enable it.
+                    This variable is currently only supported with SysVinit
+                    (i.e. not with systemd).
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS'><glossterm>SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS</glossterm>
+            <glossdef>
+                <para>
+                    A list of recipe dependencies that should not be used to
+                    determine signatures of tasks from one recipe when they
+                    depend on tasks from another recipe.
+                    For example:
+                    <literallayout class='monospaced'>
+    SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += "intone->mplayer2"
+                    </literallayout>
+                    In this example, <filename>intone</filename> depends on
+                    <filename>mplayer2</filename>.
+                </para>
+
+                <para>
+                    Use of this variable is one mechanism to remove dependencies
+                    that affect task signatures and thus force rebuilds when a
+                    recipe changes.
+                    <note><title>Caution</title>
+                        If you add an inappropriate dependency for a recipe
+                        relationship, the software might break during
+                        runtime if the interface of the second recipe was
+                        changed after the first recipe had been built.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SIGGEN_EXCLUDERECIPES_ABISAFE'><glossterm>SIGGEN_EXCLUDERECIPES_ABISAFE</glossterm>
+            <glossdef>
+                <para>
+                    A list of recipes that are completely stable and will
+                    never change.
+                    The ABI for the recipes in the list are presented by
+                    output from the tasks run to build the recipe.
+                    Use of this variable is one way to remove dependencies from
+                    one recipe on another that affect task signatures and
+                    thus force rebuilds when the recipe changes.
+                    <note><title>Caution</title>
+                        If you add an inappropriate variable to this list,
+                        the software might break at runtime if the
+                        interface of the recipe was changed after the other
+                        had been built.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SITEINFO_BITS'><glossterm>SITEINFO_BITS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the number of bits for the target system CPU.
+                    The value should be either "32" or "64".
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SITEINFO_ENDIANNESS'><glossterm>SITEINFO_ENDIANNESS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the endian byte order of the target system.
+                    The value should be either "le" for little-endian or "be" for big-endian.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SOC_FAMILY'><glossterm>SOC_FAMILY</glossterm>
+            <glossdef>
+                <para>
+                    Groups together machines based upon the same family
+                    of SOC (System On Chip).
+                    You typically set this variable in a common
+                    <filename>.inc</filename> file that you include in the
+                    configuration files of all the machines.
+                    <note>
+                        You must include
+                        <filename>conf/machine/include/soc-family.inc</filename>
+                        for this variable to appear in
+                    <link linkend='var-MACHINEOVERRIDES'><filename>MACHINEOVERRIDES</filename></link>.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SOLIBS'><glossterm>SOLIBS</glossterm>
+            <glossdef>
+                <para>
+                    Defines the suffix for shared libraries used on the
+                    target platform.
+                    By default, this suffix is ".so.*" for all Linux-based
+                    systems and is defined in the
+                    <filename>meta/conf/bitbake.conf</filename> configuration
+                    file.
+                </para>
+
+                <para>
+                    You will see this variable referenced in the default values
+                    of <filename>FILES_${PN}</filename>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SOLIBSDEV'><glossterm>SOLIBSDEV</glossterm>
+            <glossdef>
+                <para>
+                    Defines the suffix for the development symbolic link
+                    (symlink) for shared libraries on the target platform.
+                    By default, this suffix is ".so" for Linux-based
+                    systems and is defined in the
+                    <filename>meta/conf/bitbake.conf</filename> configuration
+                    file.
+                </para>
+
+                <para>
+                    You will see this variable referenced in the default values
+                    of <filename>FILES_${PN}-dev</filename>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SPECIAL_PKGSUFFIX'><glossterm>SPECIAL_PKGSUFFIX</glossterm>
+            <glossdef>
+                <para>
+                    A list of prefixes for <link linkend='var-PN'><filename>PN</filename></link> used by the
+                    OpenEmbedded build system to create variants of recipes or packages.
+                    The list specifies the prefixes to strip off during certain circumstances
+                    such as the generation of the <link linkend='var-BPN'><filename>BPN</filename></link> variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SRC_URI'><glossterm>SRC_URI</glossterm>
+            <glossdef>
+                <para>The list of source files - local or remote.
+                    This variable tells the OpenEmbedded build system which bits
+                    to pull in for the build and how to pull them in.
+                    For example, if the recipe or append file only needs to
+                    fetch a tarball from the Internet, the recipe or
+                    append file uses a single <filename>SRC_URI</filename>
+                    entry.
+                    On the other hand, if the recipe or append file needs to
+                    fetch a tarball, apply two patches, and include a custom
+                    file, the recipe or append file would include four
+                    instances of the variable.</para>
+                <para>The following list explains the available URI protocols:
+                    <itemizedlist>
+                        <listitem><para><emphasis><filename>file://</filename> -</emphasis>
+                            Fetches files, which are usually files shipped with
+                            the
+                            <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>,
+                            from the local machine.
+                            The path is relative to the
+                            <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>
+                            variable.
+                            Thus, the build system searches, in order, from the
+                            following directories, which are assumed to be a
+                            subdirectories of the directory in which the
+                            recipe file (<filename>.bb</filename>) or
+                            append file (<filename>.bbappend</filename>)
+                            resides:
+                            <itemizedlist>
+                                <listitem><para><emphasis><filename>${BPN}</filename> -</emphasis>
+                                    The base recipe name without any special
+                                    suffix or version numbers.
+                                    </para></listitem>
+                                <listitem><para><emphasis><filename>${BP}</filename> -</emphasis>
+                                    <filename>${<link linkend='var-BPN'>BPN</link>}-${PV}</filename>.
+                                    The base recipe name and version but without
+                                    any special package name suffix.
+                                    </para></listitem>
+                                <listitem><para><emphasis>files -</emphasis>
+                                    Files within a directory, which is named
+                                    <filename>files</filename> and is also
+                                    alongside the recipe or append file.
+                                    </para></listitem>
+                            </itemizedlist>
+                            <note>
+                                If you want the build system to pick up files
+                                specified through a
+                                <filename>SRC_URI</filename>
+                                statement from your append file, you need to be
+                                sure to extend the
+                                <filename>FILESPATH</filename>
+                                variable by also using the
+                                <link linkend='var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></link>
+                                variable from within your append file.
+                            </note>
+                            </para></listitem>
+                        <listitem><para><emphasis><filename>bzr://</filename> -</emphasis> Fetches files from a
+                            Bazaar revision control repository.</para></listitem>
+                        <listitem><para><emphasis><filename>git://</filename> -</emphasis> Fetches files from a
+                            Git revision control repository.</para></listitem>
+                        <listitem><para><emphasis><filename>osc://</filename> -</emphasis> Fetches files from
+                            an OSC (OpenSUSE Build service) revision control repository.</para></listitem>
+                        <listitem><para><emphasis><filename>repo://</filename> -</emphasis> Fetches files from
+                            a repo (Git) repository.</para></listitem>
+                        <listitem><para><emphasis><filename>svk://</filename> -</emphasis> Fetches files from
+                            an SVK revision control repository.</para></listitem>
+                        <listitem><para><emphasis><filename>http://</filename> -</emphasis> Fetches files from
+                            the Internet using <filename>http</filename>.</para></listitem>
+                        <listitem><para><emphasis><filename>https://</filename> -</emphasis> Fetches files
+                            from the Internet using <filename>https</filename>.</para></listitem>
+                        <listitem><para><emphasis><filename>ftp://</filename> -</emphasis> Fetches files
+                            from the Internet using <filename>ftp</filename>.</para></listitem>
+                        <listitem><para><emphasis><filename>cvs://</filename> -</emphasis> Fetches files from
+                            a CVS revision control repository.</para></listitem>
+                        <listitem><para><emphasis><filename>hg://</filename> -</emphasis> Fetches files from
+                            a Mercurial (<filename>hg</filename>) revision control repository.</para></listitem>
+                        <listitem><para><emphasis><filename>p4://</filename> -</emphasis> Fetches files from
+                            a Perforce (<filename>p4</filename>) revision control repository.</para></listitem>
+                        <listitem><para><emphasis><filename>ssh://</filename> -</emphasis> Fetches files from
+                            a secure shell.</para></listitem>
+                        <listitem><para><emphasis><filename>svn://</filename> -</emphasis> Fetches files from
+                            a Subversion (<filename>svn</filename>) revision control repository.</para></listitem>
+                    </itemizedlist>
+                </para>
+                <para>Standard and recipe-specific options for <filename>SRC_URI</filename> exist.
+                    Here are standard options:
+                    <itemizedlist>
+                        <listitem><para><emphasis><filename>apply</filename> -</emphasis> Whether to apply
+                            the patch or not.
+                            The default action is to apply the patch.</para></listitem>
+                        <listitem><para><emphasis><filename>striplevel</filename> -</emphasis> Which
+                            striplevel to use when applying the patch.
+                            The default level is 1.</para></listitem>
+                        <listitem><para><emphasis><filename>patchdir</filename> -</emphasis> Specifies
+                            the directory in which the patch should be applied.
+                            The default is <filename>${</filename><link linkend='var-S'><filename>S</filename></link><filename>}</filename>.
+                            </para></listitem>
+                    </itemizedlist>
+                </para>
+                <para>Here are options specific to recipes building code from a revision control system:
+                    <itemizedlist>
+                        <listitem><para><emphasis><filename>mindate</filename> -</emphasis>
+                            Apply the patch only if
+                            <link linkend='var-SRCDATE'><filename>SRCDATE</filename></link>
+                            is equal to or greater than <filename>mindate</filename>.
+                            </para></listitem>
+                        <listitem><para><emphasis><filename>maxdate</filename> -</emphasis>
+                            Apply the patch only if <filename>SRCDATE</filename>
+                            is not later than <filename>mindate</filename>.
+                            </para></listitem>
+                        <listitem><para><emphasis><filename>minrev</filename> -</emphasis>
+                            Apply the patch only if <filename>SRCREV</filename>
+                            is equal to or greater than <filename>minrev</filename>.
+                            </para></listitem>
+                        <listitem><para><emphasis><filename>maxrev</filename> -</emphasis>
+                            Apply the patch only if <filename>SRCREV</filename>
+                            is not later than <filename>maxrev</filename>.
+                            </para></listitem>
+                        <listitem><para><emphasis><filename>rev</filename> -</emphasis>
+                            Apply the patch only if <filename>SRCREV</filename>
+                            is equal to <filename>rev</filename>.
+                            </para></listitem>
+                        <listitem><para><emphasis><filename>notrev</filename> -</emphasis>
+                            Apply the patch only if <filename>SRCREV</filename>
+                            is not equal to <filename>rev</filename>.
+                            </para></listitem>
+                    </itemizedlist>
+                </para>
+                <para>Here are some additional options worth mentioning:
+                    <itemizedlist>
+                        <listitem><para><emphasis><filename>unpack</filename> -</emphasis> Controls
+                            whether or not to unpack the file if it is an archive.
+                            The default action is to unpack the file.</para></listitem>
+                        <listitem><para><emphasis><filename>subdir</filename> -</emphasis> Places the file
+                            (or extracts its contents) into the specified
+                            subdirectory of <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>.
+                            This option is useful for unusual tarballs or other archives that
+                            do not have their files already in a subdirectory within the archive.
+                            </para></listitem>
+                        <listitem><para><emphasis><filename>name</filename> -</emphasis> Specifies a
+                            name to be used for association with <filename>SRC_URI</filename> checksums
+                            when you have more than one file specified in <filename>SRC_URI</filename>.
+                            </para></listitem>
+                        <listitem><para><emphasis><filename>downloadfilename</filename> -</emphasis> Specifies
+                            the filename used when storing the downloaded file.</para></listitem>
+                    </itemizedlist>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SRC_URI_OVERRIDES_PACKAGE_ARCH'><glossterm>SRC_URI_OVERRIDES_PACKAGE_ARCH</glossterm>
+            <glossdef>
+                <para></para>
+                <para>
+                    By default, the OpenEmbedded build system automatically detects whether
+                    <filename><link linkend='var-SRC_URI'>SRC_URI</link></filename>
+                    contains files that are machine-specific.
+                    If so, the build system automatically changes
+                    <filename><link linkend='var-PACKAGE_ARCH'>PACKAGE_ARCH</link></filename>.
+                    Setting this variable to "0" disables this behavior.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SRCDATE'><glossterm>SRCDATE</glossterm>
+            <glossdef>
+                <para>
+                    The date of the source code used to build the package.
+                    This variable applies only if the source was fetched from a Source Code Manager (SCM).
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SRCPV'><glossterm>SRCPV</glossterm>
+            <glossdef>
+                <para>
+                    Returns the version string of the current package.
+                    This string is used to help define the value of
+                    <link linkend='var-PV'><filename>PV</filename></link>.
+                </para>
+
+                <para>
+                    The <filename>SRCPV</filename> variable is defined in the
+                    <filename>meta/conf/bitbake.conf</filename> configuration
+                    file in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+                    as follows:
+                    <literallayout class='monospaced'>
+     SRCPV = "${@bb.fetch2.get_srcrev(d)}"
+                    </literallayout>
+                </para>
+
+                <para>
+                    Recipes that need to define <filename>PV</filename> do so
+                    with the help of the <filename>SRCPV</filename>.
+                    For example, the <filename>ofono</filename> recipe
+                    (<filename>ofono_git.bb</filename>) located in
+                    <filename>meta/recipes-connectivity</filename> in the
+                    Source Directory defines <filename>PV</filename> as
+                    follows:
+                    <literallayout class='monospaced'>
+     PV = "0.12-git${SRCPV}"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SRCREV'><glossterm>SRCREV</glossterm>
+            <glossdef>
+                <para>
+                    The revision of the source code used to build the package.
+                    This variable applies to Subversion, Git, Mercurial and Bazaar
+                    only.
+                    Note that if you wish to build a fixed revision and you wish
+                    to avoid performing a query on the remote repository every time
+                    BitBake parses your recipe, you should specify a <filename>SRCREV</filename> that is a
+                    full revision identifier and not just a tag.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SSTATE_DIR'><glossterm>SSTATE_DIR</glossterm>
+            <glossdef>
+                <para>The directory for the shared state cache.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SSTATE_MIRRORS'><glossterm>SSTATE_MIRRORS</glossterm>
+            <glossdef>
+                <para>
+                    Configures the OpenEmbedded build system to search other
+                    mirror locations for prebuilt cache data objects before
+                    building out the data.
+                    This variable works like fetcher
+                    <link linkend='var-MIRRORS'><filename>MIRRORS</filename></link>
+                    and <link linkend='var-PREMIRRORS'><filename>PREMIRRORS</filename></link>
+                    and points to the cache locations to check for the shared
+                    objects.
+                </para>
+
+                <para>
+                    You can specify a filesystem directory or a remote URL such
+                    as HTTP or FTP.
+                    The locations you specify need to contain the shared state
+                    cache (sstate-cache) results from previous builds.
+                    The sstate-cache you point to can also be from builds on
+                    other machines.
+                </para>
+
+                <para>
+                    If a mirror uses the same structure as
+                    <link linkend='var-SSTATE_DIR'><filename>SSTATE_DIR</filename></link>,
+                    you need to add
+                    "PATH" at the end as shown in the examples below.
+                    The build system substitutes the correct path within the
+                    directory structure.
+                    <literallayout class='monospaced'>
+     SSTATE_MIRRORS ?= "\
+     file://.* http://someserver.tld/share/sstate/PATH \n \
+     file://.* file:///some/local/dir/sstate/PATH"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-STAGING_KERNEL_DIR'><glossterm>STAGING_KERNEL_DIR</glossterm>
+            <glossdef>
+                <para>
+                    The directory with kernel headers that are required to build out-of-tree
+                    modules.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-STAMP'><glossterm>STAMP</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the base path used to create recipe stamp files.
+                    The path to an actual stamp file is constructed by evaluating this
+                    string and then appending additional information.
+                    Currently, the default assignment for <filename>STAMP</filename>
+                    as set in the <filename>meta/conf/bitbake.conf</filename> file
+                    is:
+                    <literallayout class='monospaced'>
+     STAMP = "${STAMPS_DIR}/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}"
+                    </literallayout>
+                    See <link linkend='var-STAMPS_DIR'><filename>STAMPS_DIR</filename></link>,
+                    <link linkend='var-MULTIMACH_TARGET_SYS'><filename>MULTIMACH_TARGET_SYS</filename></link>,
+                    <link linkend='var-PN'><filename>PN</filename></link>,
+                    <link linkend='var-EXTENDPE'><filename>EXTENDPE</filename></link>,
+                    <link linkend='var-PV'><filename>PV</filename></link>, and
+                    <link linkend='var-PR'><filename>PR</filename></link> for related variable
+                    information.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-STAMPS_DIR'><glossterm>STAMPS_DIR</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the base directory in which the OpenEmbedded
+                    build system places stamps.
+                    The default directory is
+                    <filename>${TMPDIR}/stamps</filename>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SUMMARY'><glossterm>SUMMARY</glossterm>
+            <glossdef>
+                <para>The short (72 characters or less) summary of the binary package for packaging
+                    systems such as <filename>opkg</filename>, <filename>rpm</filename> or
+                    <filename>dpkg</filename>.
+                    By default, <filename>SUMMARY</filename> is used to define
+                    the <link linkend='var-DESCRIPTION'><filename>DESCRIPTION</filename></link>
+                    variable if <filename>DESCRIPTION</filename> is not set
+                    in the recipe.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SYSROOT_PREPROCESS_FUNCS'><glossterm>SYSROOT_PREPROCESS_FUNCS</glossterm>
+            <glossdef>
+                <para>
+                    A list of functions to execute after files are staged into
+                    the sysroot.
+                    These functions are usually used to apply additional
+                    processing on the staged files, or to stage additional
+                    files.
+                </para>
+            </glossdef>
+        </glossentry>
+
+    </glossdiv>
+
+    <glossdiv id='var-glossary-t'><title>T</title>
+
+        <glossentry id='var-T'><glossterm>T</glossterm>
+            <glossdef>
+                <para>This variable points to a directory were BitBake places
+                    temporary files, which consist mostly of task logs and
+                    scripts, when building a particular recipe.
+                    The variable is typically set as follows:
+                    <literallayout class='monospaced'>
+     T = "${WORKDIR}/temp"
+                    </literallayout>
+                    The <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>
+                    is the directory into which BitBake unpacks and builds the
+                    recipe.
+                    The default <filename>bitbake.conf</filename> file sets this variable.</para>
+                    <para>The <filename>T</filename> variable is not to be confused with
+                    the <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link> variable,
+                    which points to the root of the directory tree where BitBake
+                    places the output of an entire build.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TARGET_ARCH'><glossterm>TARGET_ARCH</glossterm>
+            <glossdef>
+                <para>
+                    The target machine's architecture.
+                    The OpenEmbedded build system supports many
+                    architectures.
+                    Here is an example list of architectures supported.
+                    This list is by no means complete as the architecture
+                    is configurable:
+                    <literallayout class='monospaced'>
+     arm
+     i586
+     x86_64
+     powerpc
+     powerpc64
+     mips
+     mipsel
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TARGET_CFLAGS'><glossterm>TARGET_CFLAGS</glossterm>
+            <glossdef>
+                <para>
+                    Flags passed to the C compiler for the target system.
+                    This variable evaluates to the same as
+                    <filename><link linkend='var-CFLAGS'>CFLAGS</link></filename>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+
+        <glossentry id='var-TARGET_FPU'><glossterm>TARGET_FPU</glossterm>
+            <glossdef>
+                <para>Specifies the method for handling FPU code.
+                    For FPU-less targets, which include most ARM CPUs, the variable must be
+                    set to "soft".
+                    If not, the kernel emulation gets used, which results in a performance penalty.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TARGET_OS'><glossterm>TARGET_OS</glossterm>
+            <glossdef>
+                <para>Specifies the target's operating system.
+                    The variable can be set to "linux" for <filename>eglibc</filename>-based systems and
+                    to "linux-uclibc" for <filename>uclibc</filename>.
+                    For ARM/EABI targets, there are also "linux-gnueabi" and
+                    "linux-uclibc-gnueabi" values possible.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TCLIBC'><glossterm>TCLIBC</glossterm>
+            <glossdef>
+                <para>
+                    Specifies which variant of the GNU standard C library (<filename>libc</filename>)
+                    to use during the build process.
+                    This variable replaces <filename>POKYLIBC</filename>, which is no longer
+                    supported.
+                </para>
+                <para>
+                    You can select <filename>eglibc</filename> or <filename>uclibc</filename>.
+                    <note>
+                        This release of the Yocto Project does not support the
+                        <filename>glibc</filename> implementation of <filename>libc</filename>.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TCMODE'><glossterm>TCMODE</glossterm>
+            <glossdef>
+                <para>
+                    The toolchain selector.
+                    This variable replaces <filename>POKYMODE</filename>, which is no longer
+                    supported.
+                </para>
+                <para>
+                    The <filename>TCMODE</filename> variable selects the external toolchain
+                    built using the OpenEmbedded build system or a few supported combinations of
+                    the upstream GCC or CodeSourcery Labs toolchain.
+                    The variable identifies the <filename>tcmode-*</filename> files used in
+                    the <filename>meta/conf/distro/include</filename> directory, which is found in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                </para>
+                <para>
+                    By default, <filename>TCMODE</filename> is set to "default", which
+                    chooses the <filename>tcmode-default.inc</filename> file.
+                    The variable is similar to
+                    <link linkend='var-TCLIBC'><filename>TCLIBC</filename></link>, which controls
+                    the variant of the GNU standard C library (<filename>libc</filename>)
+                    used during the build process: <filename>eglibc</filename> or <filename>uclibc</filename>.
+                </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>
+                    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
+                    <filename>ssh</filename>.
+                    You can set this variable to "1" in your
+                    <filename>local.conf</filename> file in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+                    to have the OpenEmbedded build system automatically run
+                    these tests after an image successfully builds:
+                    <literallayout class='monospaced'>
+     TEST_IMAGE = "1"
+                    </literallayout>
+                    For more information on enabling, running, and writing
+                    these tests, see the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing'>Performing Automated Runtime Testing</ulink>"
+                    section in the Yocto Project Development Manual and the
+                    "<link linkend='ref-classes-testimage'><filename>testimage.bbclass</filename></link>"
+                    section.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TEST_QEMUBOOT_TIMEOUT'><glossterm>TEST_QEMUBOOT_TIMEOUT</glossterm>
+            <glossdef>
+                <para>
+                    The time in seconds allowed for an image to boot before
+                    automated runtime tests begin to run against an
+                    image.
+                    The default timeout period to allow the boot process to
+                    reach the login prompt is 500 seconds.
+                    You can specify a different value in the
+                    <filename>local.conf</filename> file.
+                </para>
+
+                <para>
+                    For more information on testing images, see the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing'>Performing Automated Runtime Testing</ulink>"
+                    section in the Yocto Project Development Manual.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TEST_SUITES'><glossterm>TEST_SUITES</glossterm>
+            <glossdef>
+                <para>
+                    An ordered list of tests (modules) to run against
+                    an image when performing automated runtime testing.
+                </para>
+
+                <para>
+                    The OpenEmbedded build system provides a core set of tests
+                    that can be used against images.
+                    <note>
+                        Currently, there is only support for running these tests
+                        under QEMU.
+                    </note>
+                    Tests include <filename>ping</filename>,
+                    <filename>ssh</filename>, <filename>df</filename> among
+                    others.
+                    You can add your own tests to the list of tests by
+                    appending <filename>TEST_SUITES</filename> as follows:
+                    <literallayout class='monospaced'>
+     TEST_SUITES_append = " mytest"
+                    </literallayout>
+                    Alternatively, you can provide the "auto" option to
+                    have all applicable tests run against the image.
+                    <literallayout class='monospaced'>
+     TEST_SUITES_append = " auto"
+                    </literallayout>
+                    Using this option causes the build system to automatically
+                    run tests that are applicable to the image.
+                    Tests that are not applicable are skipped.
+                </para>
+
+                <para>
+                    The order in which tests are run is important.
+                    Tests that depend on another test must appear later in the
+                    list than the test on which they depend.
+                    For example, if you append the list of tests with two
+                    tests (<filename>test_A</filename> and
+                    <filename>test_B</filename>) where
+                    <filename>test_B</filename> is dependent on
+                    <filename>test_A</filename>, then you must order the tests
+                    as follows:
+                    <literallayout class='monospaced'>
+     TEST_SUITES = " test_A test_B"
+                    </literallayout>
+                </para>
+
+                <para>
+                    For more information on testing images, see the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing'>Performing Automated Runtime Testing</ulink>"
+                    section in the Yocto Project Development Manual.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-THISDIR'><glossterm>THISDIR</glossterm>
+            <glossdef>
+                <para>
+                    The directory in which the file BitBake is currently
+                    parsing is located.
+                    Do not manually set this variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TMPDIR'><glossterm>TMPDIR</glossterm>
+            <glossdef>
+                <para>
+                    This variable is the base directory the OpenEmbedded
+                    build system uses for all build output and intermediate
+                    files (other than the shared state cache).
+                    By default, the <filename>TMPDIR</filename> variable points
+                    to <filename>tmp</filename> within the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+                </para>
+
+                <para>
+                    If you want to establish this directory in a location other
+                    than the default, you can uncomment and edit the following
+                    statement in the
+                    <filename>conf/local.conf</filename> file in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>:
+                    <literallayout class='monospaced'>
+     #TMPDIR = "${TOPDIR}/tmp"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TOOLCHAIN_HOST_TASK'><glossterm>TOOLCHAIN_HOST_TASK</glossterm>
+            <glossdef>
+                <para>
+                    This variable lists packages the OpenEmbedded build system
+                    uses when building an SDK, which contains a
+                    cross-development environment.
+                    The packages specified by this variable are part of the
+                    toolchain set that runs on the
+                    <link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>,
+                    and each package should usually have the prefix
+                    "nativesdk-".
+                    When building an SDK using
+                    <filename>bitbake -c populate_sdk &lt;imagename&gt;</filename>,
+                    a default list of packages is set in this variable, but
+                    you can add additional packages to the list.
+                </para>
+
+                <para>
+                    For background information on cross-development toolchains
+                    in the Yocto Project development environment, see the
+                    "<link linkend='cross-development-toolchain-generation'>Cross-Development Toolchain Generation</link>"
+                    section.
+                    For information on setting up a cross-development
+                    environment, see the
+                    "<ulink url='&YOCTO_DOCS_ADT_URL;#installing-the-adt'>Installing the ADT and Toolchains</ulink>"
+                    section in the Yocto Project Application Developer's Guide.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TOOLCHAIN_TARGET_TASK'><glossterm>TOOLCHAIN_TARGET_TASK</glossterm>
+            <glossdef>
+                <para>
+                    This variable lists packages the OpenEmbedded build system
+                    uses when it creates the target part of an SDK
+                    (i.e. the part built for the target hardware), which
+                    includes libraries and headers.
+                </para>
+
+                <para>
+                    For background information on cross-development toolchains
+                    in the Yocto Project development environment, see the
+                    "<link linkend='cross-development-toolchain-generation'>Cross-Development Toolchain Generation</link>"
+                    section.
+                    For information on setting up a cross-development
+                    environment, see the
+                    "<ulink url='&YOCTO_DOCS_ADT_URL;#installing-the-adt'>Installing the ADT and Toolchains</ulink>"
+                    section in the Yocto Project Application Developer's Guide.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TOPDIR'><glossterm>TOPDIR</glossterm>
+            <glossdef>
+                <para>
+                    This variable points to the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+                    BitBake automatically sets this variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TRANSLATED_TARGET_ARCH'><glossterm>TRANSLATED_TARGET_ARCH</glossterm>
+            <glossdef>
+                <para>
+                    A sanitized version of
+                    <link linkend='var-TARGET_ARCH'><filename>TARGET_ARCH</filename></link>.
+                    This variable is used where the architecture is needed in
+                    a value where underscores are not allowed, for example
+                    within package filenames.
+                    In this case, dash characters replace any underscore
+                    characters used in TARGET_ARCH.
+                </para>
+
+                <para>
+                    Do not edit this variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-TUNE_PKGARCH'><glossterm>TUNE_PKGARCH</glossterm>
+            <glossdef>
+                <para>
+                    The package architecture understood by the packaging
+                    system to define the architecture, ABI, and tuning of
+                    output packages.
+                </para>
+            </glossdef>
+        </glossentry>
+
+    </glossdiv>
+
+    <glossdiv id='var-glossary-u'><title>U</title>
+
+        <glossentry id='var-UBOOT_ENTRYPOINT'><glossterm>UBOOT_ENTRYPOINT</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the entry point for the U-Boot image.
+                    During U-Boot image creation, the
+                    <filename>UBOOT_ENTRYPOINT</filename> variable is passed
+                    as a command-line parameter to the
+                    <filename>uboot-mkimage</filename> utility.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-UBOOT_LOADADDRESS'><glossterm>UBOOT_LOADADDRESS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the load address for the U-Boot image.
+                    During U-Boot image creation, the
+                    <filename>UBOOT_LOADADDRESS</filename> variable is passed
+                    as a command-line parameter to the
+                    <filename>uboot-mkimage</filename> utility.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-UBOOT_MACHINE'><glossterm>UBOOT_MACHINE</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the value passed on the
+                    <filename>make</filename> command line when building
+                    a U-Boot image.
+                    The value indicates the target platform configuration.
+                    You typically set this variable from the machine
+                    configuration file (i.e.
+                    <filename>conf/machine/&lt;machine_name&gt;.conf</filename>).
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-UBOOT_TARGET'><glossterm>UBOOT_TARGET</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the target used for building U-Boot.
+                    The target is passed directly as part of the "make" command
+                    (e.g. SPL and AIS).
+                    If you do not specifically set this variable, the
+                    OpenEmbedded build process passes and uses "all" for the
+                    target during the U-Boot building process.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-USER_CLASSES'><glossterm>USER_CLASSES</glossterm>
+            <glossdef>
+                <para>
+                    A list of classes to globally inherit.
+                    These classes are used by the OpenEmbedded build system
+                    to enable extra features (e.g.
+                    <filename>buildstats</filename>,
+                    <filename>image-mklibs</filename>, and so forth).
+                </para>
+
+                <para>
+                    The default list is set in your
+                    <filename>local.conf</filename> file:
+                    <literallayout class='monospaced'>
+     USER_CLASSES ?= "buildstats image-mklibs image-prelink"
+                    </literallayout>
+                    For more information, see
+                    <filename>meta-yocto/conf/local.conf.sample</filename> in
+                    the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+    </glossdiv>
+
+<!--            <glossdiv id='var-glossary-v'><title>V</title>-->
+<!--            </glossdiv>-->
+
+    <glossdiv id='var-glossary-w'><title>W</title>
+
+        <glossentry id='var-WARN_QA'><glossterm>WARN_QA</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the quality assurance checks whose failures are
+                    reported as warnings by the OpenEmbedded build system.
+                    You set this variable in your distribution configuration
+                    file.
+                    For a list of the checks you can control with this variable,
+                    see the
+                    "<link linkend='ref-classes-insane'><filename>insane.bbclass</filename></link>"
+                    section.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-WORKDIR'><glossterm>WORKDIR</glossterm>
+            <glossdef>
+                <para>
+                    The pathname of the working directory in which the OpenEmbedded build system
+                    builds a recipe.
+                    This directory is located within the
+                    <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link> directory structure and changes
+                    as different packages are built.
+                </para>
+
+                <para>
+                    The actual <filename>WORKDIR</filename> directory depends on several things:
+                    <itemizedlist>
+                        <listitem>The temporary directory - <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link></listitem>
+                        <listitem>The package architecture - <link linkend='var-PACKAGE_ARCH'><filename>PACKAGE_ARCH</filename></link></listitem>
+                        <listitem>The target machine - <link linkend='var-MACHINE'><filename>MACHINE</filename></link></listitem>
+                        <listitem>The target operating system - <link linkend='var-TARGET_OS'><filename>TARGET_OS</filename></link></listitem>
+                        <listitem>The recipe name - <link linkend='var-PN'><filename>PN</filename></link></listitem>
+                        <listitem>The recipe version - <link linkend='var-PV'><filename>PV</filename></link></listitem>
+                        <listitem>The recipe revision - <link linkend='var-PR'><filename>PR</filename></link></listitem>
+                    </itemizedlist>
+                </para>
+
+                <para>
+                    For packages that are not dependent on a particular machine,
+                    <filename>WORKDIR</filename> is defined as follows:
+                    <literallayout class='monospaced'>
+     ${TMPDIR}/work/${PACKAGE_ARCH}-poky-${TARGET_OS}/${PN}/${PV}-${PR}
+                    </literallayout>
+                    As an example, assume a
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink> top-level
+                    folder name <filename>poky</filename> and a default
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+                    at <filename>poky/build</filename>.
+                    In this case, the working directory the build system uses to build
+                    the <filename>v86d</filename> package is the following:
+                    <literallayout class='monospaced'>
+     poky/build/tmp/work/qemux86-poky-linux/v86d/01.9-r0
+                    </literallayout>
+                </para>
+
+                <para>
+                    For packages that are dependent on a particular machine, <filename>WORKDIR</filename>
+                    is defined slightly differently:
+                    <literallayout class='monospaced'>
+     ${TMPDIR}/work/${MACHINE}-poky-${TARGET_OS}/${PN}/${PV}-${PR}
+                    </literallayout>
+                    As an example, again assume a Source Directory top-level folder
+                    named <filename>poky</filename> and a default Build Directory
+                    at <filename>poky/build</filename>.
+                    In this case, the working directory the build system uses to build
+                    the <filename>acl</filename> recipe, which is being built for a
+                    MIPS-based device, is the following:
+                    <literallayout class='monospaced'>
+     poky/build/tmp/work/mips-poky-linux/acl/2.2.51-r2
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+    </glossdiv>
+
+<!--            <glossdiv id='var-glossary-x'><title>X</title>-->
+<!--            </glossdiv>-->
+
+<!--            <glossdiv id='var-glossary-y'><title>Y</title>-->
+<!--            </glossdiv>-->
+
+<!--            <glossdiv id='var-glossary-z'><title>Z</title>-->
+<!--            </glossdiv>-->
+
+</glossary>
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/ref-manual/ref-varlocality.xml b/documentation/ref-manual/ref-varlocality.xml
new file mode 100644
index 0000000..d3f8732
--- /dev/null
+++ b/documentation/ref-manual/ref-varlocality.xml
@@ -0,0 +1,196 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='ref-varlocality'>
+    <title>Variable Context</title>
+
+    <para>
+        While you can use most variables in almost any context such as
+        <filename>.conf</filename>, <filename>.bbclass</filename>,
+        <filename>.inc</filename>, and <filename>.bb</filename> files,
+        some variables are often associated with a particular locality or context.
+        This chapter describes some common associations.
+    </para>
+
+    <section id='ref-varlocality-configuration'>
+        <title>Configuration</title>
+
+        <para>
+            The following subsections provide lists of variables whose context is
+            configuration: distribution, machine, and local.
+        </para>
+
+        <section id='ref-varlocality-config-distro'>
+            <title>Distribution (Distro)</title>
+
+            <para>
+               This section lists variables whose configuration context is the
+               distribution, or distro.
+               <itemizedlist>
+                   <listitem><para><filename><link linkend='var-DISTRO'>DISTRO</link></filename></para></listitem>
+                   <listitem><para><filename><link linkend='var-DISTRO_NAME'>DISTRO_NAME</link></filename>
+                       </para></listitem>
+                   <listitem><para><filename><link linkend='var-DISTRO_VERSION'>DISTRO_VERSION</link>
+                       </filename></para></listitem>
+                   <listitem><para><filename><link linkend='var-MAINTAINER'>MAINTAINER</link></filename>
+                       </para></listitem>
+                   <listitem><para><filename><link linkend='var-PACKAGE_CLASSES'>PACKAGE_CLASSES</link>
+                       </filename></para></listitem>
+                   <listitem><para><filename><link linkend='var-TARGET_OS'>TARGET_OS</link></filename>
+                       </para></listitem>
+                   <listitem><para><filename><link linkend='var-TARGET_FPU'>TARGET_FPU</link></filename>
+                       </para></listitem>
+                   <listitem><para><filename><link linkend='var-TCMODE'>TCMODE</link></filename>
+                       </para></listitem>
+                   <listitem><para><filename><link linkend='var-TCLIBC'>TCLIBC</link></filename>
+                       </para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='ref-varlocality-config-machine'>
+            <title>Machine</title>
+
+            <para>
+                This section lists variables whose configuration context is the
+                machine.
+                <itemizedlist>
+                    <listitem><para><filename><link linkend='var-TARGET_ARCH'>TARGET_ARCH</link></filename>
+                        </para></listitem>
+                    <listitem><para><filename><link linkend='var-SERIAL_CONSOLES'>SERIAL_CONSOLES</link>
+                        </filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-PACKAGE_EXTRA_ARCHS'>PACKAGE_EXTRA_ARCHS</link>
+                        </filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-IMAGE_FSTYPES'>IMAGE_FSTYPES</link>
+                        </filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-MACHINE_FEATURES'>MACHINE_FEATURES</link>
+                        </filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-MACHINE_EXTRA_RDEPENDS'>MACHINE_EXTRA_RDEPENDS
+                        </link></filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-MACHINE_EXTRA_RRECOMMENDS'>MACHINE_EXTRA_RRECOMMENDS
+                        </link></filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-MACHINE_ESSENTIAL_EXTRA_RDEPENDS'>MACHINE_ESSENTIAL_EXTRA_RDEPENDS
+                        </link></filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS'>
+                        MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</link></filename></para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='ref-varlocality-config-local'>
+            <title>Local</title>
+
+            <para>
+                This section lists variables whose configuration context is the
+                local configuration through the <filename>local.conf</filename>
+                file.
+                <itemizedlist>
+                    <listitem><para><filename><link linkend='var-DISTRO'>DISTRO</link></filename>
+                        </para></listitem>
+                    <listitem><para><filename><link linkend='var-MACHINE'>MACHINE</link></filename>
+                        </para></listitem>
+                    <listitem><para><filename><link linkend='var-DL_DIR'>DL_DIR</link></filename>
+                        </para></listitem>
+                    <listitem><para><filename><link linkend='var-BBFILES'>BBFILES</link></filename>
+                        </para></listitem>
+                    <listitem><para><filename><link linkend='var-EXTRA_IMAGE_FEATURES'>EXTRA_IMAGE_FEATURES
+                        </link></filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-PACKAGE_CLASSES'>PACKAGE_CLASSES</link>
+                        </filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-BB_NUMBER_THREADS'>BB_NUMBER_THREADS</link>
+                        </filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-BBINCLUDELOGS'>BBINCLUDELOGS</link>
+                        </filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-ENABLE_BINARY_LOCALE_GENERATION'>
+                        ENABLE_BINARY_LOCALE_GENERATION</link></filename></para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+    </section>
+
+    <section id='ref-varlocality-recipes'>
+        <title>Recipes</title>
+
+        <para>
+            The following subsections provide lists of variables whose context is
+            recipes: required, dependencies, path, and extra build information.
+        </para>
+
+        <section id='ref-varlocality-recipe-required'>
+            <title>Required</title>
+
+            <para>
+                This section lists variables that are required for recipes.
+                <itemizedlist>
+                    <listitem><para><filename><link linkend='var-LICENSE'>LICENSE</link>
+                        </filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-LIC_FILES_CHKSUM'>LIC_FILES_CHKSUM</link>
+                        </filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-SRC_URI'>SRC_URI</link></filename> - used
+                        in recipes that fetch local or remote files.
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='ref-varlocality-recipe-dependencies'>
+            <title>Dependencies</title>
+
+            <para>
+                This section lists variables that define recipe dependencies.
+                <itemizedlist>
+                    <listitem><para><filename><link linkend='var-DEPENDS'>DEPENDS</link>
+                        </filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-RDEPENDS'>RDEPENDS</link>
+                        </filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-RRECOMMENDS'>RRECOMMENDS</link>
+                        </filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-RCONFLICTS'>RCONFLICTS</link>
+                        </filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-RREPLACES'>RREPLACES</link>
+                        </filename></para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='ref-varlocality-recipe-paths'>
+            <title>Paths</title>
+
+            <para>
+                This section lists variables that define recipe paths.
+                <itemizedlist>
+                    <listitem><para><filename><link linkend='var-WORKDIR'>WORKDIR</link>
+                        </filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-S'>S</link>
+                        </filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-FILES'>FILES</link>
+                        </filename></para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='ref-varlocality-recipe-build'>
+            <title>Extra Build Information</title>
+
+            <para>
+                This section lists variables that define extra build information for recipes.
+                <itemizedlist>
+                    <listitem><para><filename><link linkend='var-EXTRA_OECMAKE'>EXTRA_OECMAKE</link>
+                        </filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-EXTRA_OECONF'>EXTRA_OECONF</link>
+                        </filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-EXTRA_OEMAKE'>EXTRA_OEMAKE</link>
+                        </filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-PACKAGES'>PACKAGES</link></filename>
+                        </para></listitem>
+                    <listitem><para><filename><link linkend='var-DEFAULT_PREFERENCE'>DEFAULT_PREFERENCE
+                        </link></filename></para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+    </section>
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4 spell spelllang=en_gb
+-->
diff --git a/documentation/ref-manual/resources.xml b/documentation/ref-manual/resources.xml
new file mode 100644
index 0000000..c48951f
--- /dev/null
+++ b/documentation/ref-manual/resources.xml
@@ -0,0 +1,128 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='resources'>
+<title>Contributing to the Yocto Project</title>
+
+<section id='resources-intro'>
+    <title>Introduction</title>
+    <para>
+        The Yocto Project team is happy for people to experiment with the Yocto Project.
+        A number of places exist to find help if you run into difficulties or find bugs.
+        To find out how to download source code,
+        see the "<ulink url='&YOCTO_DOCS_DEV_URL;#local-yp-release'>Yocto Project Release</ulink>"
+        section in the Yocto Project Development Manual.
+    </para>
+</section>
+
+<section id='resources-bugtracker'>
+    <title>Tracking Bugs</title>
+
+    <para>
+        If you find problems with the Yocto Project, you should report them using the
+        Bugzilla application at <ulink url='&YOCTO_BUGZILLA_URL;'></ulink>.
+    </para>
+</section>
+
+<section id='resources-mailinglist'>
+    <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, 
+        patch submission and announcements.
+        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> -
+                General Yocto Project discussion mailing list. </para></listitem>
+            <listitem><para><ulink url='&OE_LISTS_URL;/listinfo/openembedded-core'></ulink> -
+                Discussion mailing list about OpenEmbedded-Core (the core metadata).</para></listitem>
+            <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 
+                <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 
+                <ulink url='&YOCTO_DOCS_DEV_URL;#poky'>Poky</ulink>.
+                </para></listitem>
+            <listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo/yocto-announce'></ulink> -
+                Mailing list to receive official Yocto Project release and milestone
+                announcements.</para></listitem>
+        </itemizedlist>
+    </para>
+</section>
+
+<section id='resources-irc'>
+    <title>Internet Relay Chat (IRC)</title>
+
+    <para>
+        Two IRC channels on freenode are available for the Yocto Project and Poky discussions:
+        <itemizedlist>
+            <listitem><para><filename>#yocto</filename></para></listitem>
+            <listitem><para><filename>#poky</filename></para></listitem>
+        </itemizedlist>
+    </para>
+</section>
+
+<section id='resources-links'>
+    <title>Links</title>
+
+    <para>
+        Here is a list of resources you will find helpful:
+        <itemizedlist>
+            <listitem><para><emphasis>
+                <ulink url='&YOCTO_HOME_URL;'>The Yocto Project website</ulink>:
+                </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 
+                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 
+                for the build system in the Yocto Project.
+                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>
+                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>.
+                </para></listitem>
+            <listitem><para><emphasis>
+                <ulink url='http://wiki.qemu.org/Index.html'>QEMU</ulink>:
+                </emphasis> An open source machine emulator and virtualizer.
+                </para></listitem>
+        </itemizedlist>
+    </para>
+</section>
+
+<section id='resources-contributions'>
+    <title>Contributions</title>
+
+    <para>
+        The Yocto Project gladly accepts contributions.
+        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
+        to find out who is the maintainer for areas of code, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#how-to-submit-a-change'>How to Submit a Change</ulink>"
+        section in the Yocto Project Development Manual.
+    </para>
+</section>
+
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/ref-manual/technical-details.xml b/documentation/ref-manual/technical-details.xml
new file mode 100644
index 0000000..6d4c6b7
--- /dev/null
+++ b/documentation/ref-manual/technical-details.xml
@@ -0,0 +1,1358 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='technical-details'>
+<title>Technical Details</title>
+
+    <para>
+        This chapter provides technical details for various parts of the Yocto Project.
+        Currently, topics include Yocto Project components,
+        shared state (sstate) cache, x32, and Licenses.
+    </para>
+
+<section id='usingpoky-components'>
+    <title>Yocto Project Components</title>
+
+    <para>
+        The BitBake task executor together with various types of configuration files form the
+        OpenEmbedded Core.
+        This section overviews these by describing what they are used for
+        and how they interact.
+    </para>
+
+    <para>
+        BitBake handles the parsing and execution of the data files.
+        The data itself is of various types:
+    <itemizedlist>
+        <listitem><para><emphasis>Recipes:</emphasis>  Provides details about particular
+            pieces of software.</para></listitem>
+        <listitem><para><emphasis>Class Data:</emphasis>  Abstracts common build
+            information (e.g. how to build a Linux kernel).</para></listitem>
+        <listitem><para><emphasis>Configuration Data:</emphasis>  Defines machine-specific settings,
+            policy decisions, and so forth.
+            Configuration data acts as the glue to bind everything together.</para></listitem>
+    </itemizedlist>
+        For more information on data, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-terms'>Yocto Project Terms</ulink>"
+        section in the Yocto Project Development Manual.
+    </para>
+
+    <para>
+        BitBake knows how to combine multiple data sources together and refers to each data source
+        as a layer.
+        For information on layers, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and
+        Creating Layers</ulink>" section of the Yocto Project Development Manual.
+    </para>
+
+    <para>
+        Following are some brief details on these core components.
+        For more detailed information on these components, see the
+        "<link linkend='ref-structure'>Source Directory Structure</link>" chapter.
+    </para>
+
+    <section id='usingpoky-components-bitbake'>
+        <title>BitBake</title>
+
+        <para>
+            BitBake is the tool at the heart of the OpenEmbedded build system
+            and is responsible for parsing the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>,
+            generating a list of tasks from it, and then executing those tasks.
+            To see a list of the options BitBake supports, use either of
+            the following commands:
+            <literallayout class='monospaced'>
+     $ bitbake -h
+     $ bitbake --help
+            </literallayout>
+        </para>
+
+        <para>
+            The most common usage for BitBake is <filename>bitbake &lt;packagename&gt;</filename>, where
+            <filename>packagename</filename> is the name of the package you want to build
+            (referred to as the "target" in this manual).
+            The target often equates to the first part of a <filename>.bb</filename> filename.
+            So, to process the <filename>matchbox-desktop_1.2.3.bb</filename> recipe file, you
+            might type the following:
+            <literallayout class='monospaced'>
+     $ bitbake matchbox-desktop
+            </literallayout>
+            Several different versions of <filename>matchbox-desktop</filename> might exist.
+            BitBake chooses the one selected by the distribution configuration.
+            You can get more details about how BitBake chooses between different
+            target versions and providers in the
+            "<link linkend='ref-bitbake-providers'>Preferences and Providers</link>" section.
+        </para>
+
+        <para>
+            BitBake also tries to execute any dependent tasks first.
+            So for example, before building <filename>matchbox-desktop</filename>, BitBake
+            would build a cross compiler and <filename>eglibc</filename> if they had not already
+            been built.
+            <note>This release of the Yocto Project does not support the <filename>glibc</filename>
+                GNU version of the Unix standard C library.  By default, the OpenEmbedded build system
+                builds with <filename>eglibc</filename>.</note>
+        </para>
+
+        <para>
+            A useful BitBake option to consider is the <filename>-k</filename> or
+            <filename>--continue</filename> option.
+            This option instructs BitBake to try and continue processing the job as much
+            as possible even after encountering an error.
+            When an error occurs, the target that
+            failed and those that depend on it cannot be remade.
+            However, when you use this option other dependencies can still be processed.
+        </para>
+    </section>
+
+    <section id='usingpoky-components-metadata'>
+        <title>Metadata (Recipes)</title>
+
+        <para>
+            The <filename>.bb</filename> files are usually referred to as "recipes."
+            In general, a recipe contains information about a single piece of software.
+            This information includes the location from which to download the
+            unaltered source, any source patches to be applied to that source
+            (if needed), which special configuration options to apply,
+            how to compile the source files, and how to package the compiled output.
+        </para>
+
+        <para>
+            The term "package" is sometimes used to refer to recipes. However,
+            since the word "package" is used for the packaged output from the OpenEmbedded
+            build system (i.e. <filename>.ipk</filename> or <filename>.deb</filename> files),
+            this document avoids using the term "package" when referring to recipes.
+        </para>
+    </section>
+
+    <section id='usingpoky-components-classes'>
+        <title>Classes</title>
+
+        <para>
+            Class files (<filename>.bbclass</filename>) contain information that
+            is useful to share between
+            <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink> files.
+            An example is the Autotools class, which contains
+            common settings for any application that Autotools uses.
+            The "<link linkend='ref-classes'>Classes</link>" chapter provides details
+            about common classes and how to use them.
+        </para>
+    </section>
+
+    <section id='usingpoky-components-configuration'>
+        <title>Configuration</title>
+
+        <para>
+            The configuration files (<filename>.conf</filename>) define various configuration variables
+            that govern the OpenEmbedded build process.
+            These files fall into several areas that define machine configuration options,
+            distribution configuration options, compiler tuning options, general common configuration
+            options, and user configuration options in <filename>local.conf</filename>, which is found
+            in the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+        </para>
+    </section>
+</section>
+
+<section id="cross-development-toolchain-generation">
+    <title>Cross-Development Toolchain Generation</title>
+
+    <para>
+        The Yocto Project does most of the work for you when it comes to
+        creating
+        <ulink url='&YOCTO_DOCS_DEV_URL;#cross-development-toolchain'>cross-development toolchains</ulink>.
+        This section provides some technical background information on how
+        cross-development toolchains are created and used.
+        For more information on toolchains, you can also see the
+        <ulink url='&YOCTO_DOCS_ADT_URL;'>the Yocto Project Application Developer's Guide</ulink>.
+    </para>
+
+    <para>
+        In the Yocto Project development environment, cross-development
+        toolchains are used to build the image and applications that run on the
+        target hardware.
+        With just a few commands, the OpenEmbedded build system creates
+        these necessary toolchains for you.
+    </para>
+
+    <para>
+        The following figure shows a high-level build environment regarding
+        toolchain construction and use.
+    </para>
+
+    <para>
+        <imagedata fileref="figures/cross-development-toolchains.png" width="8in" depth="6in" align="center" />
+    </para>
+
+    <para>
+        Most of the work occurs on the Build Host.
+        This is the machine used to build images and generally work within the
+        the Yocto Project environment.
+        When you run BitBake to create an image, the OpenEmbedded build system
+        uses the host <filename>gcc</filename> compiler to bootstrap a
+        cross-compiler named <filename>gcc-cross</filename>.
+        The <filename>gcc-cross</filename> compiler is what BitBake uses to
+        compile source files when creating the target image.
+        You can think of <filename>gcc-cross</filename> simply as an
+        automatically generated cross-compiler that is used internally within
+        BitBake only.
+    </para>
+
+    <para>
+        The chain of events that occurs when <filename>gcc-cross</filename> is
+        bootstrapped is as follows:
+        <literallayout class='monospaced'>
+     gcc -> binutils-cross -> gcc-cross-initial -> linux-libc-headers -> eglibc-initial -> eglibc -> gcc-cross -> gcc-runtime
+        </literallayout>
+        <itemizedlist>
+            <listitem><para><filename>gcc</filename>:
+                The build host's GNU Compiler Collection (GCC).
+                </para></listitem>
+            <listitem><para><filename>binutils-cross</filename>:
+                The bare minimum binary utilities needed in order to run
+                the <filename>gcc-cross-initial</filename> phase of the
+                bootstrap operation.
+                </para></listitem>
+            <listitem><para><filename>gcc-cross-initial</filename>:
+                An early stage of the bootstrap process for creating
+                the cross-compiler.
+                This stage builds enough of the <filename>gcc-cross</filename>,
+                the C library, and other pieces needed to finish building the
+                final cross-compiler in later stages.
+                This tool is a "native" package (i.e. it is designed to run on
+                the build host).
+                </para></listitem>
+            <listitem><para><filename>linux-libc-headers</filename>:
+                Headers needed for the cross-compiler.
+                </para></listitem>
+            <listitem><para><filename>eglibc-initial</filename>:
+                An initial version of the Embedded GLIBC needed to bootstrap
+                <filename>eglibc</filename>.
+                </para></listitem>
+            <listitem><para><filename>gcc-cross</filename>:
+                The final stage of the bootstrap process for the
+                cross-compiler.
+                This stage results in the actual cross-compiler that
+                BitBake uses when it builds an image for a targeted
+                device.
+                <note>
+                    If you are replacing this cross compiler toolchain
+                    with a custom version, you must replace
+                    <filename>gcc-cross</filename>.
+                </note>
+                This tool is also a "native" package (i.e. it is
+                designed to run on the build host).
+                </para></listitem>
+            <listitem><para><filename>gcc-runtime</filename>:
+                Runtime libraries resulting from the toolchain bootstrapping
+                process.
+                This tool produces a binary that consists of the
+                runtime libraries need for the targeted device.
+                </para></listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        You can use the OpenEmbedded build system to build an installer for
+        the relocatable SDK used to develop applications.
+        When you run the installer, it installs the toolchain, which contains
+        the development tools (e.g., the
+        <filename>gcc-cross-canadian</filename>),
+        <filename>binutils-cross-canadian</filename>, and other
+        <filename>nativesdk-*</filename> tools you need to cross-compile and
+        test your software.
+        The figure shows the commands you use to easily build out this
+        toolchain.
+        This cross-development toolchain is built to execute on the
+        <link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>,
+        which might or might not be the same
+        machine as the Build Host.
+        <note>
+            If your target architecture is supported by the Yocto Project,
+            you can take advantage of pre-built images that ship with the
+            Yocto Project and already contain cross-development toolchain
+            installers.
+        </note>
+    </para>
+
+    <para>
+        Here is the bootstrap process for the relocatable toolchain:
+        <literallayout class='monospaced'>
+     gcc -> binutils-crosssdk -> gcc-crosssdk-initial -> linux-libc-headers -> eglibc-initial -> nativesdk-eglibc -> gcc-crosssdk -> gcc-cross-canadian
+        </literallayout>
+        <itemizedlist>
+            <listitem><para><filename>gcc</filename>:
+                The build host's GNU Compiler Collection (GCC).
+                </para></listitem>
+            <listitem><para><filename>binutils-crosssdk</filename>:
+                The bare minimum binary utilities needed in order to run
+                the <filename>gcc-crosssdk-initial</filename> phase of the
+                bootstrap operation.
+                </para></listitem>
+            <listitem><para><filename>gcc-crosssdk-initial</filename>:
+                An early stage of the bootstrap process for creating
+                the cross-compiler.
+                This stage builds enough of the
+                <filename>gcc-crosssdk</filename> and supporting pieces so that
+                the final stage of the bootstrap process can produce the
+                finished cross-compiler.
+                This tool is a "native" binary that runs on the build host.
+                </para></listitem>
+            <listitem><para><filename>linux-libc-headers</filename>:
+                Headers needed for the cross-compiler.
+                </para></listitem>
+            <listitem><para><filename>eglibc-initial</filename>:
+                An initial version of the Embedded GLIBC needed to bootstrap
+                <filename>nativesdk-eglibc</filename>.
+                </para></listitem>
+            <listitem><para><filename>nativesdk-eglibc</filename>:
+                The Embedded GLIBC needed to bootstrap the
+                <filename>gcc-crosssdk</filename>.
+                </para></listitem>
+            <listitem><para><filename>gcc-crosssdk</filename>:
+                The final stage of the bootstrap process for the
+                relocatable cross-compiler.
+                The <filename>gcc-crosssdk</filename> is a transitory compiler
+                and never leaves the build host.
+                Its purpose is to help in the bootstrap process to create the
+                eventual relocatable <filename>gcc-cross-canadian</filename>
+                compiler, which is relocatable.
+                This tool is also a "native" package (i.e. it is
+                designed to run on the build host).
+                </para></listitem>
+            <listitem><para><filename>gcc-cross-canadian</filename>:
+                The final relocatable cross-compiler.
+                When run on the
+                <link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>,
+                this tool
+                produces executable code that runs on the target device.
+                </para></listitem>
+        </itemizedlist>
+    </para>
+</section>
+
+<section id="shared-state-cache">
+    <title>Shared State Cache</title>
+
+    <para>
+        By design, the OpenEmbedded build system builds everything from scratch unless
+        BitBake can determine that parts do not need to be rebuilt.
+        Fundamentally, building from scratch is attractive as it means all parts are
+        built fresh and there is no possibility of stale data causing problems.
+        When developers hit problems, they typically default back to building from scratch
+        so they know the state of things from the start.
+    </para>
+
+    <para>
+        Building an image from scratch is both an advantage and a disadvantage to the process.
+        As mentioned in the previous paragraph, building from scratch ensures that
+        everything is current and starts from a known state.
+        However, building from scratch also takes much longer as it generally means
+        rebuilding things that do not necessarily need to be rebuilt.
+    </para>
+
+    <para>
+        The Yocto Project implements shared state code that supports incremental builds.
+        The implementation of the shared state code answers the following questions that
+        were fundamental roadblocks within the OpenEmbedded incremental build support system:
+        <itemizedlist>
+            <listitem><para>What pieces of the system have changed and what pieces have
+                not changed?</para></listitem>
+            <listitem><para>How are changed pieces of software removed and replaced?</para></listitem>
+            <listitem><para>How are pre-built components that do not need to be rebuilt from scratch
+                used when they are available?</para></listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        For the first question, the build system detects changes in the "inputs" to a given task by
+        creating a checksum (or signature) of the task's inputs.
+        If the checksum changes, the system assumes the inputs have changed and the task needs to be
+        rerun.
+        For the second question, the shared state (sstate) code tracks which tasks add which output
+        to the build process.
+        This means the output from a given task can be removed, upgraded or otherwise manipulated.
+        The third question is partly addressed by the solution for the second question
+        assuming the build system can fetch the sstate objects from remote locations and
+        install them if they are deemed to be valid.
+    </para>
+
+    <note>
+        The OpenEmbedded build system does not maintain
+        <link linkend='var-PR'><filename>PR</filename></link> information
+        as part of the shared state packages.
+        Consequently, considerations exist that affect maintaining shared
+        state feeds.
+        For information on how the OpenEmbedded works with packages and can
+        track incrementing <filename>PR</filename> information, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#incrementing-a-package-revision-number'>Incrementing a Package Revision Number</ulink>"
+        section.
+    </note>
+
+    <para>
+        The rest of this section goes into detail about the overall incremental build
+        architecture, the checksums (signatures), shared state, and some tips and tricks.
+    </para>
+
+    <section id='overall-architecture'>
+        <title>Overall Architecture</title>
+
+        <para>
+            When determining what parts of the system need to be built, BitBake
+            works on a per-task basis rather than a per-recipe basis.
+            You might wonder why using a per-task basis is preferred over a per-recipe basis.
+            To help explain, consider having the IPK packaging backend enabled and then switching to DEB.
+            In this case, <filename>do_install</filename> and <filename>do_package</filename>
+            outputs are still valid.
+            However, with a per-recipe approach, the build would not include the
+            <filename>.deb</filename> files.
+            Consequently, you would have to invalidate the whole build and rerun it.
+            Rerunning everything is not the best solution.
+            Also, in this case, the core must be "taught" much about specific tasks.
+            This methodology does not scale well and does not allow users to easily add new tasks
+            in layers or as external recipes without touching the packaged-staging core.
+        </para>
+    </section>
+
+    <section id='checksums'>
+        <title>Checksums (Signatures)</title>
+
+        <para>
+            The shared state code uses a checksum, which is a unique signature of a task's
+            inputs, to determine if a task needs to be run again.
+            Because it is a change in a task's inputs that triggers a rerun, the process
+            needs to detect all the inputs to a given task.
+            For shell tasks, this turns out to be fairly easy because
+            the build process generates a "run" shell script for each task and
+            it is possible to create a checksum that gives you a good idea of when
+            the task's data changes.
+        </para>
+
+        <para>
+            To complicate the problem, there are things that should not be included in
+            the checksum.
+            First, there is the actual specific build path of a given task -
+            the <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>.
+            It does not matter if the working directory changes because it should not
+            affect the output for target packages.
+            Also, the build process has the objective of making native or cross packages relocatable.
+            The checksum therefore needs to exclude <filename>WORKDIR</filename>.
+            The simplistic approach for excluding the working directory is to set
+            <filename>WORKDIR</filename> to some fixed value and create the checksum
+            for the "run" script.
+        </para>
+
+        <para>
+            Another problem results from the "run" scripts containing functions that
+            might or might not get called.
+            The incremental build solution contains code that figures out dependencies
+            between shell functions.
+            This code is used to prune the "run" scripts down to the minimum set,
+            thereby alleviating this problem and making the "run" scripts much more
+            readable as a bonus.
+        </para>
+
+        <para>
+            So far we have solutions for shell scripts.
+            What about Python tasks?
+            The same approach applies even though these tasks are more difficult.
+            The process needs to figure out what variables a Python function accesses
+            and what functions it calls.
+            Again, the incremental build solution contains code that first figures out
+            the variable and function dependencies, and then creates a checksum for the data
+            used as the input to the task.
+        </para>
+
+        <para>
+            Like the <filename>WORKDIR</filename> case, situations exist where dependencies
+            should be ignored.
+            For these cases, you can instruct the build process to ignore a dependency
+            by using a line like the following:
+            <literallayout class='monospaced'>
+     PACKAGE_ARCHS[vardepsexclude] = "MACHINE"
+            </literallayout>
+            This example ensures that the <filename>PACKAGE_ARCHS</filename> variable does not
+            depend on the value of <filename>MACHINE</filename>, even if it does reference it.
+        </para>
+
+        <para>
+            Equally, there are cases where we need to add dependencies BitBake is not able to find.
+            You can accomplish this by using a line like the following:
+            <literallayout class='monospaced'>
+      PACKAGE_ARCHS[vardeps] = "MACHINE"
+            </literallayout>
+            This example explicitly adds the <filename>MACHINE</filename> variable as a
+            dependency for <filename>PACKAGE_ARCHS</filename>.
+        </para>
+
+        <para>
+            Consider a case with in-line Python, for example, where BitBake is not
+            able to figure out dependencies.
+            When running in debug mode (i.e. using <filename>-DDD</filename>), BitBake
+            produces output when it discovers something for which it cannot figure out
+            dependencies.
+            The Yocto Project team has currently not managed to cover those dependencies
+            in detail and is aware of the need to fix this situation.
+        </para>
+
+        <para>
+            Thus far, this section has limited discussion to the direct inputs into a task.
+            Information based on direct inputs is referred to as the "basehash" in the
+            code.
+            However, there is still the question of a task's indirect inputs - the
+            things that were already built and present in the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+            The checksum (or signature) for a particular task needs to add the hashes
+            of all the tasks on which the particular task depends.
+            Choosing which dependencies to add is a policy decision.
+            However, the effect is to generate a master checksum that combines the basehash
+            and the hashes of the task's dependencies.
+        </para>
+
+        <para>
+            At the code level, there are a variety of ways both the basehash and the
+            dependent task hashes can be influenced.
+            Within the BitBake configuration file, we can give BitBake some extra information
+            to help it construct the basehash.
+            The following statement effectively results in a list of global variable
+            dependency excludes - variables never included in any checksum:
+            <literallayout class='monospaced'>
+     BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH DL_DIR \
+         SSTATE_DIR THISDIR FILESEXTRAPATHS FILE_DIRNAME HOME LOGNAME SHELL TERM \
+         USER FILESPATH STAGING_DIR_HOST STAGING_DIR_TARGET COREBASE PRSERV_HOST \
+         PRSERV_DUMPDIR PRSERV_DUMPFILE PRSERV_LOCKDOWN PARALLEL_MAKE \
+         CCACHE_DIR EXTERNAL_TOOLCHAIN CCACHE CCACHE_DISABLE LICENSE_PATH SDKPKGSUFFIX"
+            </literallayout>
+            The previous example excludes
+            <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>
+            since that variable is actually constructed as a path within
+            <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>, which is on
+            the whitelist.
+        </para>
+
+        <para>
+            The rules for deciding which hashes of dependent tasks to include through
+            dependency chains are more complex and are generally accomplished with a
+            Python function.
+            The code in <filename>meta/lib/oe/sstatesig.py</filename> shows two examples
+            of this and also illustrates how you can insert your own policy into the system
+            if so desired.
+            This file defines the two basic signature generators <filename>OE-Core</filename>
+            uses:  "OEBasic" and "OEBasicHash".
+            By default, there is a dummy "noop" signature handler enabled in BitBake.
+            This means that behavior is unchanged from previous versions.
+            <filename>OE-Core</filename> uses the "OEBasicHash" signature handler by default
+            through this setting in the <filename>bitbake.conf</filename> file:
+            <literallayout class='monospaced'>
+     BB_SIGNATURE_HANDLER ?= "OEBasicHash"
+            </literallayout>
+            The "OEBasicHash" <filename>BB_SIGNATURE_HANDLER</filename> is the same as the
+            "OEBasic" version but adds the task hash to the stamp files.
+            This results in any
+            <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+            change that changes the task hash, automatically
+            causing the task to be run again.
+            This removes the need to bump <link linkend='var-PR'><filename>PR</filename></link>
+            values, and changes to Metadata automatically ripple across the build.
+        </para>
+
+        <para>
+            It is also worth noting that the end result of these signature generators is to
+            make some dependency and hash information available to the build.
+            This information includes:
+            <literallayout class='monospaced'>
+     BB_BASEHASH_task-&lt;taskname&gt; - the base hashes for each task in the recipe
+     BB_BASEHASH_&lt;filename:taskname&gt; - the base hashes for each dependent task
+     BBHASHDEPS_&lt;filename:taskname&gt; - The task dependencies for each task
+     BB_TASKHASH - the hash of the currently running task
+            </literallayout>
+        </para>
+    </section>
+
+    <section id='shared-state'>
+        <title>Shared State</title>
+
+        <para>
+            Checksums and dependencies, as discussed in the previous section, solve half the
+            problem of supporting a shared state.
+            The other part of the problem is being able to use checksum information during the build
+            and being able to reuse or rebuild specific components.
+        </para>
+
+        <para>
+            The shared state class (<filename>sstate.bbclass</filename>)
+            is a relatively generic implementation of how to "capture" a snapshot of a given task.
+            The idea is that the build process does not care about the source of a task's output.
+            Output could be freshly built or it could be downloaded and unpacked from
+            somewhere - the build process does not need to worry about its origin.
+        </para>
+
+        <para>
+            There are two types of output, one is just about creating a directory
+            in <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>.
+            A good example is the output of either <filename>do_install</filename> or
+            <filename>do_package</filename>.
+            The other type of output occurs when a set of data is merged into a shared directory
+            tree such as the sysroot.
+        </para>
+
+        <para>
+            The Yocto Project team has tried to keep the details of the implementation hidden in
+            <filename>sstate.bbclass</filename>.
+            From a user's perspective, adding shared state wrapping to a task
+            is as simple as this <filename>do_deploy</filename> example taken from
+            <filename>deploy.bbclass</filename>:
+            <literallayout class='monospaced'>
+     DEPLOYDIR = "${WORKDIR}/deploy-${PN}"
+     SSTATETASKS += "do_deploy"
+     do_deploy[sstate-name] = "deploy"
+     do_deploy[sstate-inputdirs] = "${DEPLOYDIR}"
+     do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}"
+
+     python do_deploy_setscene () {
+         sstate_setscene(d)
+     }
+     addtask do_deploy_setscene
+     do_deploy[dirs] = "${DEPLOYDIR} ${B}"
+            </literallayout>
+            In this example, we add some extra flags to the task, a name field ("deploy"), an
+            input directory where the task sends data, and the output
+            directory where the data from the task should eventually be copied.
+            We also add a <filename>_setscene</filename> variant of the task and add the task
+            name to the <filename>SSTATETASKS</filename> list.
+        </para>
+
+        <para>
+            If you have a directory whose contents you need to preserve, you can do this with
+            a line like the following:
+            <literallayout class='monospaced'>
+     do_package[sstate-plaindirs] = "${PKGD} ${PKGDEST}"
+            </literallayout>
+            This method, as well as the following example, also works for multiple directories.
+            <literallayout class='monospaced'>
+     do_package[sstate-inputdirs] = "${PKGDESTWORK} ${SHLIBSWORKDIR}"
+     do_package[sstate-outputdirs] = "${PKGDATA_DIR} ${SHLIBSDIR}"
+     do_package[sstate-lockfile] = "${PACKAGELOCK}"
+            </literallayout>
+            These methods also include the ability to take a lockfile when manipulating
+            shared state directory structures since some cases are sensitive to file
+            additions or removals.
+        </para>
+
+        <para>
+            Behind the scenes, the shared state code works by looking in
+            <link linkend='var-SSTATE_DIR'><filename>SSTATE_DIR</filename></link> and
+            <link linkend='var-SSTATE_MIRRORS'><filename>SSTATE_MIRRORS</filename></link>
+            for shared state files.
+            Here is an example:
+            <literallayout class='monospaced'>
+     SSTATE_MIRRORS ?= "\
+     file://.* http://someserver.tld/share/sstate/PATH \n \
+     file://.* file:///some/local/dir/sstate/PATH"
+            </literallayout>
+            <note>
+                The shared state directory (<filename>SSTATE_DIR</filename>) is
+                organized into two-character subdirectories, where the subdirectory
+                names are based on the first two characters of the hash.
+                If the shared state directory structure for a mirror has the
+                same structure as <filename>SSTATE_DIR</filename>, you must
+                specify "PATH" as part of the URI to enable the build system
+                to map to the appropriate subdirectory.
+            </note>
+        </para>
+
+        <para>
+            The shared state package validity can be detected just by looking at the
+            filename since the filename contains the task checksum (or signature) as
+            described earlier in this section.
+            If a valid shared state package is found, the build process downloads it
+            and uses it to accelerate the task.
+        </para>
+
+        <para>
+            The build processes use the <filename>*_setscene</filename> tasks
+            for the task acceleration phase.
+            BitBake goes through this phase before the main execution code and tries
+            to accelerate any tasks for which it can find shared state packages.
+            If a shared state package for a task is available, the shared state
+            package is used.
+            This means the task and any tasks on which it is dependent are not
+            executed.
+        </para>
+
+        <para>
+            As a real world example, the aim is when building an IPK-based image,
+            only the <filename>do_package_write_ipk</filename> tasks would have their
+            shared state packages fetched and extracted.
+            Since the sysroot is not used, it would never get extracted.
+            This is another reason why a task-based approach is preferred over a
+            recipe-based approach, which would have to install the output from every task.
+        </para>
+    </section>
+
+    <section id='tips-and-tricks'>
+        <title>Tips and Tricks</title>
+
+        <para>
+            The code in the build system that supports incremental builds is not
+            simple code.
+            This section presents some tips and tricks that help you work around
+            issues related to shared state code.
+        </para>
+
+        <section id='debugging'>
+            <title>Debugging</title>
+
+            <para>
+                When things go wrong, debugging needs to be straightforward.
+                Because of this, the Yocto Project team included strong debugging
+                tools:
+                <itemizedlist>
+                    <listitem><para>Whenever a shared state package is written out, so is a
+                        corresponding <filename>.siginfo</filename> file.
+                        This practice results in a pickled Python database of all
+                        the metadata that went into creating the hash for a given shared state
+                        package.</para></listitem>
+                    <listitem><para>If you run BitBake with the <filename>--dump-signatures</filename>
+                        (or <filename>-S</filename>) option, BitBake dumps out
+                        <filename>.siginfo</filename> files in
+                        the stamp directory for every task it would have executed instead of
+                        building the specified target package.</para></listitem>
+                    <listitem><para>There is a <filename>bitbake-diffsigs</filename> command that
+                        can process <filename>.siginfo</filename> files.
+                        If you specify one of these files, BitBake dumps out the dependency
+                        information in the file.
+                        If you specify two files, BitBake compares the two files and dumps out
+                        the differences between the two.
+                        This more easily helps answer the question of "What
+                        changed between X and Y?"</para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='invalidating-shared-state'>
+            <title>Invalidating Shared State</title>
+
+            <para>
+                The OpenEmbedded build system uses checksums and shared state
+                cache to avoid unnecessarily rebuilding tasks.
+                Collectively, this scheme is known as "shared state code."
+            </para>
+
+            <para>
+                As with all schemes, this one has some drawbacks.
+                It is possible that you could make implicit changes to your
+                code that the checksum calculations do not take into
+                account (i.e. implicit changes).
+                These implicit changes affect a task's output but do not trigger
+                the shared state code into rebuilding a recipe.
+                Consider an example during which a tool changes its output.
+                Assume that the output of <filename>rpmdeps</filename> changes.
+                The result of the change should be that all the
+                <filename>package</filename> and
+                <filename>package_write_rpm</filename> shared state cache
+                items become invalid.
+                However, because the change to the output is
+                external to the code and therefore implicit,
+                the associated shared state cache items do not become
+                invalidated.
+                In this case, the build process uses the cached items rather
+                than running the task again.
+                Obviously, these types of implicit changes can cause problems.
+            </para>
+
+            <para>
+                To avoid these problems during the build, you need to
+                understand the effects of any changes you make.
+                Realize that changes you make directly to a function
+                are automatically factored into the checksum calculation.
+                Thus, these explicit changes invalidate the associated area of
+                sstate cache.
+                However, you need to be aware of any implicit changes that
+                are not obvious changes to the code and could affect the output
+                of a given task.
+            </para>
+
+            <para>
+                When you identify an implicit change, you can easily take steps
+                to invalidate the cache and force the tasks to run.
+                The steps you can take are as simple as changing a function's
+                comments in the source code.
+                For example, to invalidate package shared state files, change
+                the comment statements of <filename>do_package</filename> or
+                the comments of one of the functions it calls.
+                Even though the change is purely cosmetic, it causes the
+                checksum to be recalculated and forces the OpenEmbedded build
+                system to run the task again.
+            </para>
+
+            <note>
+                For an example of a commit that makes a cosmetic change to
+                invalidate shared state, see this
+                <ulink url='&YOCTO_GIT_URL;/cgit.cgi/poky/commit/meta/classes/package.bbclass?id=737f8bbb4f27b4837047cb9b4fbfe01dfde36d54'>commit</ulink>.
+            </note>
+        </section>
+    </section>
+</section>
+
+<section id='x32'>
+    <title>x32</title>
+
+    <para>
+        x32 is a processor-specific Application Binary Interface (psABI) for x86_64.
+        An ABI defines the calling conventions between functions in a processing environment.
+        The interface determines what registers are used and what the sizes are for various C data types.
+    </para>
+
+    <para>
+        Some processing environments prefer using 32-bit applications even when running
+        on Intel 64-bit platforms.
+        Consider the i386 psABI, which is a very old 32-bit ABI for Intel 64-bit platforms.
+        The i386 psABI does not provide efficient use and access of the Intel 64-bit processor resources,
+        leaving the system underutilized.
+        Now consider the x86_64 psABI.
+        This ABI is newer and uses 64-bits for data sizes and program pointers.
+        The extra bits increase the footprint size of the programs, libraries,
+        and also increases the memory and file system size requirements.
+        Executing under the x32 psABI enables user programs to utilize CPU and system resources
+        more efficiently while keeping the memory footprint of the applications low.
+        Extra bits are used for registers but not for addressing mechanisms.
+    </para>
+
+    <section id='support'>
+        <title>Support</title>
+
+        <para>
+            While the x32 psABI specifications are not fully finalized, this Yocto Project
+            release supports current development specifications of x32 psABI.
+            As of this release of the Yocto Project, x32 psABI support exists as follows:
+            <itemizedlist>
+                <listitem><para>You can create packages and images in x32 psABI format on x86_64 architecture targets.
+                    </para></listitem>
+                <listitem><para>You can successfully build many recipes with the x32 toolchain.</para></listitem>
+                <listitem><para>You can create and boot <filename>core-image-minimal</filename> and
+                    <filename>core-image-sato</filename> images.</para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='stabilizing-and-completing-x32'>
+        <title>Stabilizing and Completing x32</title>
+
+        <para>
+            As of this Yocto Project release, the x32 psABI kernel and library
+            interfaces specifications are not finalized.
+        </para>
+
+        <para>
+            Future Plans for the x32 psABI in the Yocto Project include the following:
+            <itemizedlist>
+                <listitem><para>Enhance and fix the few remaining recipes so they
+                    work with and support x32 toolchains.</para></listitem>
+                <listitem><para>Enhance RPM Package Manager (RPM) support for x32 binaries.</para></listitem>
+                <listitem><para>Support larger images.</para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='using-x32-right-now'>
+        <title>Using x32 Right Now</title>
+
+        <para>
+            Follow these steps to use the x32 spABI:
+            <itemizedlist>
+                <listitem><para>Enable the x32 psABI tuning file for <filename>x86_64</filename>
+                    machines by editing the <filename>conf/local.conf</filename> like this:
+                    <literallayout class='monospaced'>
+      MACHINE = "qemux86-64"
+      DEFAULTTUNE = "x86-64-x32"
+      baselib = "${@d.getVar('BASE_LIB_tune-' + (d.getVar('DEFAULTTUNE', True) \
+         or 'INVALID'), True) or 'lib'}"
+      #MACHINE = "genericx86"
+      #DEFAULTTUNE = "core2-64-x32"
+                    </literallayout></para></listitem>
+                <listitem><para>As usual, use BitBake to build an image that supports the x32 psABI.
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     $ bitbake core-image-sato
+                    </literallayout></para></listitem>
+                <listitem><para>As usual, run your image using QEMU:
+                    <literallayout class='monospaced'>
+     $ runqemu qemux86-64 core-image-sato
+                    </literallayout></para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+</section>
+
+<section id="wayland">
+    <title>Wayland</title>
+
+    <para>
+        <ulink url='http://en.wikipedia.org/wiki/Wayland_(display_server_protocol)#Weston'>Wayland</ulink>
+        is a computer display server protocol that
+        provides a method for compositing window managers to communicate
+        directly with applications and video hardware and expects them to
+        communicate with input hardware using other libraries.
+        Using Wayland with supporting targets can result in better control
+        over graphics frame rendering than an application might otherwise
+        achieve.
+    </para>
+
+    <para>
+        The Yocto Project provides the Wayland protocol libraries and the
+        reference Weston compositor as part of its release.
+        This section describes what you need to do to implement Wayland and
+        use the compositor when building an image for a supporting target.
+    </para>
+
+    <section id="wayland-support">
+        <title>Support</title>
+
+        <para>
+            The Wayland protocol libraries and the reference Weston compositor
+            ship as integrated packages in the <filename>meta</filename> layer
+            of the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+            Specifically, you can find the recipes that build both Wayland
+            and Weston at <filename>meta/recipes-graphics/wayland</filename>.
+        </para>
+
+        <para>
+            You can build both the Wayland and Weston packages for use only
+            with targets that accept the
+            <ulink url='http://dri.freedesktop.org/wiki/'>Mesa 3D and Direct Rendering Infrastructure</ulink>,
+            which is also known as Mesa DRI.
+            This implies that you cannot build and use the packages if your
+            target uses, for example, the
+            <trademark class='registered'>Intel</trademark> Embedded Media and
+            Graphics Driver (<trademark class='registered'>Intel</trademark>
+            EMGD) that overrides Mesa DRI.
+        </para>
+
+        <note>
+            Due to lack of EGL support, Weston 1.0.3 will not run directly on
+            the emulated QEMU hardware.
+            However, this version of Weston will run under X emulation without
+            issues.
+        </note>
+    </section>
+
+    <section id="enabling-wayland-in-an-image">
+        <title>Enabling Wayland in an Image</title>
+
+        <para>
+            To enable Wayland, you need to enable it to be built and enable
+            it to be included in the image.
+        </para>
+
+        <section id="enable-building">
+            <title>Building</title>
+
+            <para>
+                To cause Mesa to build the <filename>wayland-egl</filename>
+                platform and Weston to build Wayland with Kernel Mode
+                Setting
+                (<ulink url='https://wiki.archlinux.org/index.php/Kernel_Mode_Setting'>KMS</ulink>)
+                support, include the "wayland" flag in the
+                <link linkend="var-DISTRO_FEATURES"><filename>DISTRO_FEATURES</filename></link>
+                statement in your <filename>local.conf</filename> file:
+                <literallayout class='monospaced'>
+     DISTRO_FEATURES_append = " wayland"
+                </literallayout>
+            </para>
+
+            <note>
+                If X11 has been enabled elsewhere, Weston will build Wayland
+                with X11 support
+            </note>
+        </section>
+
+        <section id="enable-installation-in-an-image">
+            <title>Installing</title>
+
+            <para>
+                To install the Wayland feature into an image, you must
+                include the following
+                <link linkend='var-CORE_IMAGE_EXTRA_INSTALL'><filename>CORE_IMAGE_EXTRA_INSTALL</filename></link>
+                statement in your <filename>local.conf</filename> file:
+                <literallayout class='monospaced'>
+     CORE_IMAGE_EXTRA_INSTALL += "wayland weston"
+                </literallayout>
+            </para>
+        </section>
+    </section>
+
+    <section id="running-weston">
+        <title>Running Weston</title>
+
+        <para>
+            To run Weston inside X11, enabling it as described earlier and
+            building a Sato image is sufficient.
+            If you are running your image under Sato, a Weston Launcher appears
+            in the "Utility" category.
+        </para>
+
+        <para>
+            Alternatively, you can run Weston through the command-line
+            interpretor (CLI), which is better suited for development work.
+            To run Weston under the CLI, you need to do the following after
+            your image is built:
+            <orderedlist>
+                <listitem><para>Run these commands to export
+                    <filename>XDG_RUNTIME_DIR</filename>:
+                    <literallayout class='monospaced'>
+     mkdir -p /tmp/$USER-weston
+     chmod 0700 /tmp/$USER-weston
+     export XDG_RUNTIME_DIR=/tmp/$USER=weston
+                    </literallayout></para></listitem>
+                <listitem><para>Launch Weston in the shell:
+                    <literallayout class='monospaced'>
+     weston
+                    </literallayout></para></listitem>
+            </orderedlist>
+        </para>
+    </section>
+</section>
+
+<section id="licenses">
+    <title>Licenses</title>
+
+    <para>
+        This section describes the mechanism by which the OpenEmbedded build system
+        tracks changes to licensing text.
+        The section also describes how to enable commercially licensed recipes,
+        which by default are disabled.
+    </para>
+
+    <para>
+        For information that can help you maintain compliance with various open
+        source licensing during the lifecycle of the product, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle'>Maintaining Open Source License Compliance During Your Project's Lifecycle</ulink>" section
+        in the Yocto Project Development Manual.
+    </para>
+
+    <section id="usingpoky-configuring-LIC_FILES_CHKSUM">
+        <title>Tracking License Changes</title>
+
+        <para>
+            The license of an upstream project might change in the future.
+            In order to prevent these changes going unnoticed, the
+            <filename><link linkend='var-LIC_FILES_CHKSUM'>LIC_FILES_CHKSUM</link></filename>
+            variable tracks changes to the license text. The checksums are validated at the end of the
+            configure step, and if the checksums do not match, the build will fail.
+        </para>
+
+        <section id="usingpoky-specifying-LIC_FILES_CHKSUM">
+            <title>Specifying the <filename>LIC_FILES_CHKSUM</filename> Variable</title>
+
+            <para>
+                The <filename>LIC_FILES_CHKSUM</filename>
+                variable contains checksums of the license text in the source code for the recipe.
+                Following is an example of how to specify <filename>LIC_FILES_CHKSUM</filename>:
+                <literallayout class='monospaced'>
+     LIC_FILES_CHKSUM = "file://COPYING;md5=xxxx \
+                         file://licfile1.txt;beginline=5;endline=29;md5=yyyy \
+                         file://licfile2.txt;endline=50;md5=zzzz \
+                         ..."
+                </literallayout>
+            </para>
+
+            <para>
+                The build system uses the
+                <filename><link linkend='var-S'>S</link></filename> variable as
+                the default directory used when searching files listed in
+                <filename>LIC_FILES_CHKSUM</filename>.
+                The previous example employs the default directory.
+            </para>
+
+            <para>
+                Consider this next example:
+                <literallayout class='monospaced'>
+     LIC_FILES_CHKSUM = "file://src/ls.c;beginline=5;endline=16;\
+                                         md5=bb14ed3c4cda583abc85401304b5cd4e"
+     LIC_FILES_CHKSUM = "file://${WORKDIR}/license.html;md5=5c94767cedb5d6987c902ac850ded2c6"
+                </literallayout>
+            </para>
+
+            <para>
+                The first line locates a file in
+                <filename>${S}/src/ls.c</filename>.
+                The second line refers to a file in
+                <filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>.
+            </para>
+            <para>
+                Note that <filename>LIC_FILES_CHKSUM</filename> variable is
+                mandatory for all recipes, unless the
+                <filename>LICENSE</filename> variable is set to "CLOSED".
+            </para>
+        </section>
+
+        <section id="usingpoky-LIC_FILES_CHKSUM-explanation-of-syntax">
+            <title>Explanation of Syntax</title>
+            <para>
+                As mentioned in the previous section, the
+                <filename>LIC_FILES_CHKSUM</filename> variable lists all the
+                important files that contain the license text for the source code.
+                It is possible to specify a checksum for an entire file, or a specific section of a
+                file (specified by beginning and ending line numbers with the "beginline" and "endline"
+                parameters, respectively).
+                The latter is useful for source files with a license notice header,
+                README documents, and so forth.
+                If you do not use the "beginline" parameter, then it is assumed that the text begins on the
+                first line of the file.
+                Similarly, if you do not use the "endline" parameter, it is assumed that the license text
+                ends with the last line of the file.
+            </para>
+
+            <para>
+                The "md5" parameter stores the md5 checksum of the license text.
+                If the license text changes in any way as compared to this parameter
+                then a mismatch occurs.
+                This mismatch triggers a build failure and notifies the developer.
+                Notification allows the developer to review and address the license text changes.
+                Also note that if a mismatch occurs during the build, the correct md5
+                checksum is placed in the build log and can be easily copied to the recipe.
+            </para>
+
+            <para>
+                There is no limit to how many files you can specify using the
+                <filename>LIC_FILES_CHKSUM</filename> variable.
+                Generally, however, every project requires a few specifications for license tracking.
+                Many projects have a "COPYING" file that stores the license information for all the source
+                code files.
+                This practice allows you to just track the "COPYING" file as long as it is kept up to date.
+            </para>
+
+            <tip>
+                If you specify an empty or invalid "md5" parameter, BitBake returns an md5 mis-match
+                error and displays the correct "md5" parameter value during the build.
+                The correct parameter is also captured in the build log.
+            </tip>
+
+            <tip>
+                If the whole file contains only license text, you do not need to use the "beginline" and
+                "endline" parameters.
+            </tip>
+        </section>
+    </section>
+
+    <section id="enabling-commercially-licensed-recipes">
+        <title>Enabling Commercially Licensed Recipes</title>
+
+        <para>
+            By default, the OpenEmbedded build system disables
+            components that have commercial or other special licensing
+            requirements.
+            Such requirements are defined on a
+            recipe-by-recipe basis through the <filename>LICENSE_FLAGS</filename> variable
+            definition in the affected recipe.
+            For instance, the
+            <filename>poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly</filename>
+            recipe contains the following statement:
+            <literallayout class='monospaced'>
+     LICENSE_FLAGS = "commercial"
+            </literallayout>
+            Here is a slightly more complicated example that contains both an
+            explicit recipe name and version (after variable expansion):
+            <literallayout class='monospaced'>
+     LICENSE_FLAGS = "license_${PN}_${PV}"
+            </literallayout>
+                In order for a component restricted by a <filename>LICENSE_FLAGS</filename>
+                definition to be enabled and included in an image, it
+                needs to have a matching entry in the global
+                <filename>LICENSE_FLAGS_WHITELIST</filename> variable, which is a variable
+                typically defined in your <filename>local.conf</filename> file.
+            For example, to enable
+                the <filename>poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly</filename>
+                package, you could add either the string
+                "commercial_gst-plugins-ugly" or the more general string
+                "commercial" to <filename>LICENSE_FLAGS_WHITELIST</filename>.
+            See the
+            "<link linkend='license-flag-matching'>License Flag Matching</link>" section
+            for a full explanation of how <filename>LICENSE_FLAGS</filename> matching works.
+            Here is the example:
+            <literallayout class='monospaced'>
+     LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly"
+            </literallayout>
+                Likewise, to additionally enable the package built from the recipe containing
+                <filename>LICENSE_FLAGS = "license_${PN}_${PV}"</filename>, and assuming
+                that the actual recipe name was <filename>emgd_1.10.bb</filename>,
+                the following string would enable that package as well as
+                the original <filename>gst-plugins-ugly</filename> package:
+            <literallayout class='monospaced'>
+     LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly license_emgd_1.10"
+            </literallayout>
+                As a convenience, you do not need to specify the complete license string
+                in the whitelist for every package.
+            You can use an abbreviated form, which consists
+                of just the first portion or portions of the license string before
+                the initial underscore character or characters.
+            A partial string will match
+                any license that contains the given string as the first
+                portion of its license.
+            For example, the following
+                whitelist string will also match both of the packages
+                previously mentioned as well as any other packages that have
+                licenses starting with "commercial" or "license".
+            <literallayout class='monospaced'>
+     LICENSE_FLAGS_WHITELIST = "commercial license"
+            </literallayout>
+        </para>
+
+        <section id="license-flag-matching">
+            <title>License Flag Matching</title>
+
+            <para>
+                        License flag matching allows you to control what recipes the
+                OpenEmbedded build system includes in the build.
+                Fundamentally, the build system attempts to match
+                <filename>LICENSE_FLAGS</filename> strings found in
+                recipes against <filename>LICENSE_FLAGS_WHITELIST</filename>
+                strings found in the whitelist.
+                A match causes the build system to include a recipe in the
+                build, while failure to find a match causes the build system to
+                exclude a recipe.
+            </para>
+
+            <para>
+                In general, license flag matching is simple.
+                However, understanding some concepts will help you
+                correctly and effectively use matching.
+            </para>
+
+            <para>
+                Before a flag
+                defined by a particular recipe is tested against the
+                contents of the whitelist, the expanded string
+                <filename>_${PN}</filename> is appended to the flag.
+                This expansion makes each <filename>LICENSE_FLAGS</filename>
+                value recipe-specific.
+                After expansion, the string is then matched against the
+                whitelist.
+                Thus, specifying
+                <filename>LICENSE_FLAGS = "commercial"</filename>
+                in recipe "foo", for example, results in the string
+                <filename>"commercial_foo"</filename>.
+                And, to create a match, that string must appear in the
+                whitelist.
+            </para>
+
+            <para>
+                Judicious use of the <filename>LICENSE_FLAGS</filename>
+                strings and the contents of the
+                <filename>LICENSE_FLAGS_WHITELIST</filename> variable
+                allows you a lot of flexibility for including or excluding
+                recipes based on licensing.
+                For example, you can broaden the matching capabilities by
+                using license flags string subsets in the whitelist.
+                <note>When using a string subset, be sure to use the part of
+                    the expanded string that precedes the appended underscore
+                    character (e.g. <filename>usethispart_1.3</filename>,
+                    <filename>usethispart_1.4</filename>, and so forth).
+                </note>
+                For example, simply specifying the string "commercial" in
+                the whitelist matches any expanded
+                <filename>LICENSE_FLAGS</filename> definition that starts with
+                the string "commercial" such as "commercial_foo" and
+                "commercial_bar", which are the strings the build system
+                automatically generates for hypothetical recipes named
+                "foo" and "bar" assuming those recipes simply specify the
+                following:
+                <literallayout class='monospaced'>
+     LICENSE_FLAGS = "commercial"
+                </literallayout>
+                Thus, you can choose to exhaustively
+                enumerate each license flag in the whitelist and
+                allow only specific recipes into the image, or
+                you can use a string subset that causes a broader range of
+                matches to allow a range of recipes into the image.
+            </para>
+
+            <para>
+                This scheme works even if the
+                <filename>LICENSE_FLAGS</filename> string already
+                has <filename>_${PN}</filename> appended.
+                For example, the build system turns the license flag
+                "commercial_1.2_foo" into "commercial_1.2_foo_foo" and would
+                match both the general "commercial" and the specific
+                "commercial_1.2_foo" strings found in the whitelist, as
+                expected.
+            </para>
+
+            <para>
+                Here are some other scenarios:
+                <itemizedlist>
+                    <listitem><para>You can specify a versioned string in the
+                        recipe such as "commercial_foo_1.2" in a "foo" recipe.
+                        The build system expands this string to
+                        "commercial_foo_1.2_foo".
+                        Combine this license flag with a whitelist that has
+                        the string "commercial" and you match the flag along
+                        with any other flag that starts with the string
+                        "commercial".</para></listitem>
+                    <listitem><para>Under the same circumstances, you can
+                        use "commercial_foo" in the whitelist and the
+                        build system not only matches "commercial_foo_1.2" but
+                        also matches any license flag with the string
+                        "commercial_foo", regardless of the version.
+                        </para></listitem>
+                    <listitem><para>You can be very specific and use both the
+                        package and version parts in the whitelist (e.g.
+                        "commercial_foo_1.2") to specifically match a
+                        versioned recipe.</para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id="other-variables-related-to-commercial-licenses">
+            <title>Other Variables Related to Commercial Licenses</title>
+
+            <para>
+                Other helpful variables related to commercial
+                license handling exist and are defined in the
+                <filename>poky/meta/conf/distro/include/default-distrovars.inc</filename> file:
+                <literallayout class='monospaced'>
+     COMMERCIAL_AUDIO_PLUGINS ?= ""
+     COMMERCIAL_VIDEO_PLUGINS ?= ""
+     COMMERCIAL_QT = ""
+                </literallayout>
+                If you want to enable these components, you can do so by making sure you have
+                statements similar to the following
+                in your <filename>local.conf</filename> configuration file:
+                <literallayout class='monospaced'>
+     COMMERCIAL_AUDIO_PLUGINS = "gst-plugins-ugly-mad \
+        gst-plugins-ugly-mpegaudioparse"
+     COMMERCIAL_VIDEO_PLUGINS = "gst-plugins-ugly-mpeg2dec \
+        gst-plugins-ugly-mpegstream gst-plugins-bad-mpegvideoparse"
+     COMMERCIAL_QT ?= "qmmp"
+     LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly commercial_gst-plugins-bad commercial_qmmp"
+                </literallayout>
+                Of course, you could also create a matching whitelist
+                for those components using the more general "commercial"
+                in the whitelist, but that would also enable all the
+                other packages with <filename>LICENSE_FLAGS</filename> containing
+                "commercial", which you may or may not want:
+                <literallayout class='monospaced'>
+     LICENSE_FLAGS_WHITELIST = "commercial"
+                </literallayout>
+            </para>
+
+            <para>
+                Specifying audio and video plug-ins as part of the
+                <filename>COMMERCIAL_AUDIO_PLUGINS</filename> and
+                <filename>COMMERCIAL_VIDEO_PLUGINS</filename> statements
+                or commercial Qt components as part of
+                the <filename>COMMERCIAL_QT</filename> statement (along
+                with the enabling <filename>LICENSE_FLAGS_WHITELIST</filename>) includes the
+                plug-ins or components into built images, thus adding
+                support for media formats or components.
+            </para>
+        </section>
+    </section>
+</section>
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->
diff --git a/documentation/ref-manual/usingpoky.xml b/documentation/ref-manual/usingpoky.xml
new file mode 100644
index 0000000..b9df733
--- /dev/null
+++ b/documentation/ref-manual/usingpoky.xml
@@ -0,0 +1,859 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
+<chapter id='usingpoky'>
+<title>Using the Yocto Project</title>
+
+    <para>
+        This chapter describes common usage for the Yocto Project.
+        The information is introductory in nature as other manuals in the Yocto Project
+        documentation set provide more details on how to use the Yocto Project.
+    </para>
+
+<section id='usingpoky-build'>
+    <title>Running a Build</title>
+
+    <para>
+        This section provides a summary of the build process and provides information
+        for less obvious aspects of the build process.
+        For general information on how to build an image using the OpenEmbedded build
+        system, see the
+        "<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>"
+        section of the Yocto Project Quick Start.
+    </para>
+
+    <section id='build-overview'>
+        <title>Build Overview</title>
+
+        <para>
+            The first thing you need to do is set up the OpenEmbedded build
+            environment by sourcing an environment setup script
+            (i.e.
+            <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
+            or
+            <link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>).
+            Here is an example:
+            <literallayout class='monospaced'>
+     $ source &OE_INIT_FILE; [&lt;build_dir&gt;]
+            </literallayout>
+        </para>
+
+        <para>
+            The <filename>build_dir</filename> argument is optional and specifies the directory the
+            OpenEmbedded build system uses for the build -
+            the <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+            If you do not specify a Build Directory, it defaults to a directory
+            named <filename>build</filename> in your current working directory.
+            A common practice is to use a different Build Directory for different targets.
+            For example, <filename>~/build/x86</filename> for a <filename>qemux86</filename>
+            target, and <filename>~/build/arm</filename> for a <filename>qemuarm</filename> target.
+            See the "<link linkend="structure-core-script"><filename>&OE_INIT_FILE;</filename></link>"
+            section for more information on this script.
+        </para>
+
+        <para>
+            Once the build environment is set up, you can build a target using:
+            <literallayout class='monospaced'>
+     $ bitbake &lt;target&gt;
+            </literallayout>
+        </para>
+
+        <para>
+            The <filename>target</filename> is the name of the recipe you want to build.
+            Common targets are the images in <filename>meta/recipes-core/images</filename>,
+            <filename>meta/recipes-sato/images</filename>, etc. all found in the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+            Or, the target can be the name of a recipe for a specific piece of software such as
+            BusyBox.
+            For more details about the images the OpenEmbedded build system supports, see the
+            "<link linkend="ref-images">Images</link>" chapter.
+        </para>
+
+        <note>
+            Building an image without GNU General Public License Version 3 (GPLv3) components
+            is supported for only minimal and base images.
+            See the "<link linkend='ref-images'>Images</link>" chapter for more information.
+        </note>
+    </section>
+
+    <section id='building-an-image-using-gpl-components'>
+        <title>Building an Image Using GPL Components</title>
+
+        <para>
+            When building an image using GPL components, you need to maintain your original
+            settings and not switch back and forth applying different versions of the GNU
+            General Public License.
+            If you rebuild using different versions of GPL, dependency errors might occur
+            due to some components not being rebuilt.
+        </para>
+    </section>
+</section>
+
+<section id='usingpoky-install'>
+    <title>Installing and Using the Result</title>
+
+    <para>
+        Once an image has been built, it often needs to be installed.
+        The images and kernels built by the OpenEmbedded build system are placed in the
+        <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink> in
+        <filename class="directory">tmp/deploy/images</filename>.
+        For information on how to run pre-built images such as <filename>qemux86</filename>
+        and <filename>qemuarm</filename>, see the
+        "<ulink url='&YOCTO_DOCS_QS_URL;#using-pre-built'>Using Pre-Built Binaries and QEMU</ulink>"
+        section in the Yocto Project Quick Start.
+        For information about how to install these images, see the documentation for your
+        particular board or machine.
+    </para>
+</section>
+
+<section id='usingpoky-debugging'>
+    <title>Debugging Build Failures</title>
+
+    <para>
+        The exact method for debugging build failures depends on the nature of the
+        problem and on the system's area from which the bug originates.
+        Standard debugging practices such as comparison against the last
+        known working version with examination of the changes and the re-application of steps
+        to identify the one causing the problem are
+        valid for the Yocto Project just as they are for any other system.
+        Even though it is impossible to detail every possible potential failure,
+        this section provides some general tips to aid in debugging.
+    </para>
+
+    <para>
+        For discussions on debugging, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-gdb-remotedebug'>Debugging With the GNU Project Debugger (GDB) Remotely</ulink>"
+        and
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#adt-eclipse'>Working within Eclipse</ulink>"
+        sections in the Yocto Project Development Manual.
+    </para>
+
+    <section id='usingpoky-debugging-taskfailures'>
+        <title>Task Failures</title>
+
+        <para>The log file for shell tasks is available in
+            <filename>${WORKDIR}/temp/log.do_taskname.pid</filename>.
+            For example, the <filename>compile</filename> task for the QEMU minimal image for the x86
+            machine (<filename>qemux86</filename>) might be
+            <filename>tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/temp/log.do_compile.20830</filename>.
+            To see what BitBake runs to generate that log, look at the corresponding
+            <filename>run.do_taskname.pid</filename> file located in the same directory.
+        </para>
+
+        <para>
+            Presently, the output from Python tasks is sent directly to the console.
+        </para>
+    </section>
+
+    <section id='usingpoky-debugging-taskrunning'>
+        <title>Running Specific Tasks</title>
+
+        <para>
+            Any given package consists of a set of tasks.
+            The standard BitBake behavior in most cases is: <filename>fetch</filename>,
+            <filename>unpack</filename>,
+            <filename>patch</filename>, <filename>configure</filename>,
+            <filename>compile</filename>, <filename>install</filename>, <filename>package</filename>,
+            <filename>package_write</filename>, and <filename>build</filename>.
+            The default task is <filename>build</filename> and any tasks on which it depends
+            build first.
+            Some tasks, such as <filename>devshell</filename>, are not part of the
+            default build chain.
+            If you wish to run a task that is not part of the default build chain, you can use the
+            <filename>-c</filename> option in BitBake.
+            Here is an example:
+            <literallayout class='monospaced'>
+     $ bitbake matchbox-desktop -c devshell
+            </literallayout>
+        </para>
+
+        <para>
+            If you wish to rerun a task, use the <filename>-f</filename> force option.
+            For example, the following sequence forces recompilation after changing files in the
+            working directory.
+            <literallayout class='monospaced'>
+     $ bitbake matchbox-desktop
+               .
+               .
+        [make some changes to the source code in the working directory]
+               .
+               .
+     $ bitbake matchbox-desktop -c compile -f
+     $ bitbake matchbox-desktop
+            </literallayout>
+        </para>
+
+        <para>
+            This sequence first builds and then recompiles
+            <filename>matchbox-desktop</filename>.
+            The last command reruns all tasks (basically the packaging tasks) after the compile.
+            BitBake recognizes that the <filename>compile</filename> task was rerun and therefore
+            understands that the other tasks also need to be run again.
+        </para>
+
+        <para>
+            You can view a list of tasks in a given package by running the
+            <filename>listtasks</filename> task as follows:
+            <literallayout class='monospaced'>
+     $ bitbake matchbox-desktop -c listtasks
+            </literallayout>
+            The results are in the file <filename>${WORKDIR}/temp/log.do_listtasks</filename>.
+        </para>
+    </section>
+
+    <section id='usingpoky-debugging-dependencies'>
+        <title>Dependency Graphs</title>
+
+        <para>
+            Sometimes it can be hard to see why BitBake wants to build some other packages before a given
+            package you have specified.
+            The <filename>bitbake -g targetname</filename> command creates the
+            <filename>depends.dot</filename>, <filename>package-depends.dot</filename>,
+            and <filename>task-depends.dot</filename> files in the current directory.
+            These files show the package and task dependencies and are useful for debugging problems.
+            You can use the <filename>bitbake -g -u depexp targetname</filename> command to
+            display the results in a more human-readable form.
+        </para>
+    </section>
+
+    <section id='usingpoky-debugging-bitbake'>
+        <title>General BitBake Problems</title>
+
+        <para>
+            You can see debug output from BitBake by using the <filename>-D</filename> option.
+            The debug output gives more information about what BitBake
+            is doing and the reason behind it.
+            Each <filename>-D</filename> option you use increases the logging level.
+            The most common usage is <filename>-DDD</filename>.
+        </para>
+
+        <para>
+            The output from <filename>bitbake -DDD -v targetname</filename> can reveal why
+            BitBake chose a certain version of a package or why BitBake
+            picked a certain provider.
+            This command could also help you in a situation where you think BitBake did something
+            unexpected.
+        </para>
+    </section>
+
+    <section id='development-host-system-issues'>
+        <title>Development Host System Issues</title>
+
+        <para>
+            Sometimes issues on the host development system can cause your
+            build to fail.
+            Following are known, host-specific problems.
+            Be sure to always consult the
+            <ulink url='&YOCTO_RELEASE_NOTES;'>Release Notes</ulink>
+            for a look at all release-related issues.
+            <itemizedlist>
+                <listitem><para><emphasis><filename>eglibc-initial</filename> fails to build</emphasis>:
+                    If your development host system has the unpatched
+                    <filename>GNU Make 3.82</filename>,
+                    the <filename>do_install</filename> task
+                    fails for <filename>eglibc-initial</filename> during the
+                    build.</para>
+                    <para>Typically, every distribution that ships
+                    <filename>GNU Make 3.82</filename> as
+                    the default already has the patched version.
+                    However, some distributions, such as Debian, have
+                    <filename>GNU Make 3.82</filename> as an option, which
+                    is unpatched.
+                    You will see this error on these types of distributions.
+                    Switch to <filename>GNU Make 3.81</filename> or patch
+                    your <filename>make</filename> to solve the problem.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='usingpoky-debugging-buildfile'>
+        <title>Building with No Dependencies</title>
+        <para>
+            To build a specific recipe (<filename>.bb</filename> file),
+            you can use the following command form:
+            <literallayout class='monospaced'>
+     $ bitbake -b &lt;somepath/somerecipe.bb&gt;
+            </literallayout>
+            This command form does not check for dependencies.
+            Consequently, you should use it
+            only when you know dependencies already exist.
+            <note>
+                You can also specify fragments of the filename.
+                In this case, BitBake checks for a unique match.
+            </note>
+        </para>
+    </section>
+
+    <section id='usingpoky-debugging-variables'>
+        <title>Variables</title>
+        <para>
+            You can use the <filename>-e</filename> BitBake option to
+            display the parsing environment for a configuration.
+            The following displays the general parsing environment:
+            <literallayout class='monospaced'>
+     $ bitbake -e
+            </literallayout>
+            This next example shows the parsing environment for a specific
+            recipe:
+            <literallayout class='monospaced'>
+     $ bitbake -e &lt;recipename&gt;
+            </literallayout>
+        </para>
+    </section>
+
+    <section id='recipe-logging-mechanisms'>
+        <title>Recipe Logging Mechanisms</title>
+        <para>
+            Best practices exist while writing recipes that both log build progress and
+            act on build conditions such as warnings and errors.
+            Both Python and Bash language bindings exist for the logging mechanism:
+            <itemizedlist>
+                <listitem><para><emphasis>Python:</emphasis> For Python functions, BitBake
+                    supports several loglevels: <filename>bb.fatal</filename>,
+                    <filename>bb.error</filename>, <filename>bb.warn</filename>,
+                    <filename>bb.note</filename>, <filename>bb.plain</filename>,
+                    and <filename>bb.debug</filename>.</para></listitem>
+                <listitem><para><emphasis>Bash:</emphasis> For Bash functions, the same set
+                    of loglevels exist and are accessed with a similar syntax:
+                    <filename>bbfatal</filename>, <filename>bberror</filename>,
+                    <filename>bbwarn</filename>, <filename>bbnote</filename>,
+                    <filename>bbplain</filename>, and <filename>bbdebug</filename>.</para></listitem>
+            </itemizedlist>
+        </para>
+
+        <para>
+            For guidance on how logging is handled in both Python and Bash recipes, see the
+            <filename>logging.bbclass</filename> file in the
+            <filename>meta/classes</filename> folder of the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+        </para>
+
+        <section id='logging-with-python'>
+            <title>Logging With Python</title>
+            <para>
+                When creating recipes using Python and inserting code that handles build logs,
+                keep in mind the goal is to have informative logs while keeping the console as
+                "silent" as possible.
+                Also, if you want status messages in the log, use the "debug" loglevel.
+            </para>
+
+            <para>
+                Following is an example written in Python.
+                The code handles logging for a function that determines the number of tasks
+                needed to be run:
+                <literallayout class='monospaced'>
+     python do_listtasks() {
+         bb.debug(2, "Starting to figure out the task list")
+         if noteworthy_condition:
+             bb.note("There are 47 tasks to run")
+         bb.debug(2, "Got to point xyz")
+         if warning_trigger:
+             bb.warn("Detected warning_trigger, this might be a problem later.")
+         if recoverable_error:
+             bb.error("Hit recoverable_error, you really need to fix this!")
+         if fatal_error:
+             bb.fatal("fatal_error detected, unable to print the task list")
+         bb.plain("The tasks present are abc")
+         bb.debug(2, "Finished figuring out the tasklist")
+     }
+                </literallayout>
+            </para>
+        </section>
+
+        <section id='logging-with-bash'>
+            <title>Logging With Bash</title>
+            <para>
+                When creating recipes using Bash and inserting code that handles build
+                logs, you have the same goals - informative with minimal console output.
+                The syntax you use for recipes written in Bash is similar to that of
+                recipes written in Python described in the previous section.
+            </para>
+
+            <para>
+                Following is an example written in Bash.
+                The code logs the progress of the <filename>do_my_function</filename> function.
+                <literallayout class='monospaced'>
+     do_my_function() {
+         bbdebug 2 "Running do_my_function"
+         if [ exceptional_condition ]; then
+             bbnote "Hit exceptional_condition"
+         fi
+         bbdebug 2  "Got to point xyz"
+         if [ warning_trigger ]; then
+             bbwarn "Detected warning_trigger, this might cause a problem later."
+         fi
+         if [ recoverable_error ]; then
+             bberror "Hit recoverable_error, correcting"
+         fi
+         if [ fatal_error ]; then
+             bbfatal "fatal_error detected"
+         fi
+         bbdebug 2 "Completed do_my_function"
+     }
+                </literallayout>
+            </para>
+        </section>
+    </section>
+
+    <section id='usingpoky-debugging-others'>
+        <title>Other Tips</title>
+
+        <para>
+            Here are some other tips that you might find useful:
+            <itemizedlist>
+                <listitem><para>When adding new packages, it is worth watching for
+                    undesirable items making their way into compiler command lines.
+                    For example, you do not want references to local system files like
+                    <filename>/usr/lib/</filename> or <filename>/usr/include/</filename>.
+                    </para></listitem>
+                <listitem><para>If you want to remove the <filename>psplash</filename>
+                    boot splashscreen,
+                    add <filename>psplash=false</filename> to  the kernel command line.
+                    Doing so prevents <filename>psplash</filename> from loading
+                    and thus allows you to see the console.
+                    It is also possible to switch out of the splashscreen by
+                    switching the virtual console (e.g. Fn+Left or Fn+Right on a Zaurus).
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+</section>
+
+<section id='maintaining-build-output-quality'>
+    <title>Maintaining Build Output Quality</title>
+
+    <para>
+        Many factors can influence the quality of a build.
+        For example, if you upgrade a recipe to use a new version of an upstream software
+        package or you experiment with some new configuration options, subtle changes
+        can occur that you might not detect until later.
+        Consider the case where your recipe is using a newer version of an upstream package.
+        In this case, a new version of a piece of software might introduce an optional
+        dependency on another library, which is auto-detected.
+        If that library has already been built when the software is building,
+        the software will link to the built library and that library will be pulled
+        into your image along with the new software even if you did not want the
+        library.
+    </para>
+
+    <para>
+        The <filename>buildhistory</filename> class exists to help you maintain
+        the quality of your build output.
+        You can use the class to highlight unexpected and possibly unwanted
+        changes in the build output.
+        When you enable build history, it records information about the contents of
+        each package and image and then commits that information to a local Git
+        repository where you can examine the information.
+    </para>
+
+    <para>
+        The remainder of this section describes the following:
+        <itemizedlist>
+           <listitem><para>How you can enable and disable
+               build history</para></listitem>
+           <listitem><para>How to understand what the build history contains
+               </para></listitem>
+           <listitem><para>How to limit the information used for build history
+               </para></listitem>
+           <listitem><para>How to examine the build history from both a
+               command-line and web interface</para></listitem>
+       </itemizedlist>
+    </para>
+
+    <section id='enabling-and-disabling-build-history'>
+        <title>Enabling and Disabling Build History</title>
+
+        <para>
+            Build history is disabled by default.
+            To enable it, add the following statements to the end of your
+            <filename>conf/local.conf</filename> file found in the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>:
+            <literallayout class='monospaced'>
+     INHERIT += "buildhistory"
+     BUILDHISTORY_COMMIT = "1"
+            </literallayout>
+            Enabling build history as previously described
+            causes the build process to collect build
+            output information and commit it to a local
+            <ulink url='&YOCTO_DOCS_DEV_URL;#git'>Git</ulink> repository.
+            <note>
+                Enabling build history increases your build times slightly,
+                particularly for images, and increases the amount of disk
+                space used during the build.
+            </note>
+        </para>
+
+        <para>
+            You can disable build history by removing the previous statements
+            from your <filename>conf/local.conf</filename> file.
+            However, you should realize that enabling and disabling
+            build history in this manner can change the
+            <filename>do_package</filename> task checksums which, if you
+            are using the OEBasicHash signature generator (the default
+            for many current distro configurations including
+            <filename>DISTRO = "poky"</filename> and
+            <filename>DISTRO = ""</filename>) will result in the packaging
+            tasks being re-run during the subsequent build.
+        </para>
+
+        <para>
+            To disable the build history functionality without causing the
+            packaging tasks to be re-run, add this statement to your
+            <filename>conf/local.conf</filename> file:
+            <literallayout class='monospaced'>
+     BUILDHISTORY_FEATURES = ""
+            </literallayout>
+        </para>
+    </section>
+
+    <section id='understanding-what-the-build-history-contains'>
+        <title>Understanding What the Build History Contains</title>
+
+        <para>
+            Build history information is kept in
+            <filename>$</filename><link linkend='var-TMPDIR'><filename>TMPDIR</filename></link><filename>/buildhistory</filename>
+            in the Build Directory.
+            The following is an example abbreviated listing:
+            <imagedata fileref="figures/buildhistory.png" align="center" width="6in" depth="4in" />
+        </para>
+
+        <para>
+            At the top level, there is a <filename>metadata-revs</filename> file
+            that lists the revisions of the repositories for the layers enabled
+            when the build was produced.
+            The rest of the data splits into separate
+            <filename>packages</filename>, <filename>images</filename> and
+            <filename>sdk</filename> directories, the contents of which are
+            described below.
+        </para>
+
+        <section id='build-history-package-information'>
+            <title>Build History Package Information</title>
+
+            <para>
+                The history for each package contains a text file that has
+                name-value pairs with information about the package.
+                For example, <filename>buildhistory/packages/core2-poky-linux/busybox/busybox/latest</filename>
+                contains the following:
+                <literallayout class='monospaced'>
+     PV = 1.19.3
+     PR = r3
+     RDEPENDS = update-rc.d eglibc (>= 2.13)
+     RRECOMMENDS = busybox-syslog busybox-udhcpc
+     PKGSIZE = 564701
+     FILES = /usr/bin/* /usr/sbin/* /usr/libexec/* /usr/lib/lib*.so.* \
+        /etc /com /var /bin/* /sbin/* /lib/*.so.* /usr/share/busybox \
+        /usr/lib/busybox/* /usr/share/pixmaps /usr/share/applications \
+        /usr/share/idl /usr/share/omf /usr/share/sounds /usr/lib/bonobo/servers
+     FILELIST = /etc/busybox.links /etc/init.d/hwclock.sh /bin/busybox /bin/sh
+                </literallayout>
+                Most of these name-value pairs correspond to variables used
+                to produce the package.
+                The exceptions are <filename>FILELIST</filename>, which is the
+                actual list of files in the package, and
+                <filename>PKGSIZE</filename>, which is the total size of files
+                in the package in bytes.
+            </para>
+
+            <para>
+                There is also a file corresponding to the recipe from which the
+                package came (e.g.
+                <filename>buildhistory/packages/core2-poky-linux/busybox/latest</filename>):
+                <literallayout class='monospaced'>
+     PV = 1.19.3
+     PR = r3
+     DEPENDS = virtual/i586-poky-linux-gcc virtual/i586-poky-linux-compilerlibs \
+        virtual/libc update-rc.d-native
+     PACKAGES = busybox-httpd busybox-udhcpd busybox-udhcpc busybox-syslog \
+        busybox-mdev busybox-dbg busybox busybox-doc busybox-dev \
+        busybox-staticdev busybox-locale
+                </literallayout>
+            </para>
+
+            <para>
+                Finally, for those recipes fetched from a version control
+                system (e.g., Git), a file exists that lists source revisions
+                that are specified in the recipe and lists the actual revisions
+                used during the build.
+                Listed and actual revisions might differ when
+                <link linkend='var-SRCREV'><filename>SRCREV</filename></link>
+                is set to
+                <filename>${<link linkend='var-AUTOREV'>AUTOREV</link>}</filename>.
+                Here is an example assuming
+                <filename>buildhistory/packages/emenlow-poky-linux/linux-yocto/latest_srcrev</filename>):
+                <literallayout class='monospaced'>
+     # SRCREV_machine = "b5c37fe6e24eec194bb29d22fdd55d73bcc709bf"
+     SRCREV_machine = "b5c37fe6e24eec194bb29d22fdd55d73bcc709bf"
+     # SRCREV_emgd = "caea08c988e0f41103bbe18eafca20348f95da02"
+     SRCREV_emgd = "caea08c988e0f41103bbe18eafca20348f95da02"
+     # SRCREV_meta = "c2ed0f16fdec628242a682897d5d86df4547cf24"
+     SRCREV_meta = "c2ed0f16fdec628242a682897d5d86df4547cf24"
+                </literallayout>
+                You can use the <filename>buildhistory-collect-srcrevs</filename>
+                command to collect the stored <filename>SRCREV</filename> values
+                from build history and report them in a format suitable for use in
+                global configuration (e.g., <filename>local.conf</filename>
+                or a distro include file) to override floating
+                <filename>AUTOREV</filename> values to a fixed set of revisions.
+                Here is some example output from this command:
+                <literallayout class='monospaced'>
+     # emenlow-poky-linux
+     SRCREV_machine_pn-linux-yocto = "b5c37fe6e24eec194bb29d22fdd55d73bcc709bf"
+     SRCREV_emgd_pn-linux-yocto = "caea08c988e0f41103bbe18eafca20348f95da02"
+     SRCREV_meta_pn-linux-yocto = "c2ed0f16fdec628242a682897d5d86df4547cf24"
+     # core2-poky-linux
+     SRCREV_pn-kmod = "62081c0f68905b22f375156d4532fd37fa5c8d33"
+     SRCREV_pn-blktrace = "d6918c8832793b4205ed3bfede78c2f915c23385"
+     SRCREV_pn-opkg = "649"
+                </literallayout>
+                <note>
+                    Here are some notes on using the
+                    <filename>buildhistory-collect-srcrevs</filename> command:
+                    <itemizedlist>
+                        <listitem><para>By default, only values where the
+                            <filename>SRCREV</filename> was
+                            not hardcoded (usually when <filename>AUTOREV</filename>
+                            was used) are reported.
+                            Use the <filename>-a</filename> option to see all
+                            <filename>SRCREV</filename> values.
+                            </para></listitem>
+                        <listitem><para>The output statements might not have any effect
+                            if overrides are applied elsewhere in the build system
+                            configuration.
+                            Use the <filename>-f</filename> option to add the
+                            <filename>forcevariable</filename> override to each output line
+                            if you need to work around this restriction.
+                            </para></listitem>
+                        <listitem><para>The script does apply special handling when
+                            building for multiple machines.
+                            However, the script does place a
+                            comment before each set of values that specifies
+                            which triplet to which they belong as shown above
+                            (e.g., <filename>emenlow-poky-linux</filename>).
+                            </para></listitem>
+                    </itemizedlist>
+                </note>
+            </para>
+        </section>
+
+        <section id='build-history-image-information'>
+            <title>Build History Image Information</title>
+
+            <para>
+                The files produced for each image are as follows:
+                <itemizedlist>
+                    <listitem><para><filename>image-files:</filename>
+                        A directory containing selected files from the root
+                        filesystem.
+                        The files are defined by
+                        <filename>BUILDHISTORY_IMAGE_FILES</filename>.
+                        </para></listitem>
+                    <listitem><para><filename>build-id:</filename>
+                        Human-readable information about the build configuration
+                        and metadata source revisions.</para></listitem>
+                    <listitem><para><filename>*.dot:</filename>
+                        Dependency graphs for the image that are
+                        compatible with <filename>graphviz</filename>.
+                        </para></listitem>
+                    <listitem><para><filename>files-in-image.txt:</filename>
+                            A list of files in the image with permissions,
+                        owner, group, size, and symlink information.
+                        </para></listitem>
+                    <listitem><para><filename>image-info.txt:</filename>
+                        A text file containing name-value pairs with information
+                        about the image.
+                        See the following listing example for more information.
+                        </para></listitem>
+                    <listitem><para><filename>installed-package-names.txt:</filename>
+                        A list of installed packages by name only.</para></listitem>
+                    <listitem><para><filename>installed-package-sizes.txt:</filename>
+                        A list of installed packages ordered by size.
+                        </para></listitem>
+                    <listitem><para><filename>installed-packages.txt:</filename>
+                        A list of installed packages with full package
+                        filenames.</para></listitem>
+                </itemizedlist>
+                <note>
+                    Installed package information is able to be gathered and
+                    produced even if package management is disabled for the final
+                    image.
+                </note>
+            </para>
+
+            <para>
+                Here is an example of <filename>image-info.txt</filename>:
+                <literallayout class='monospaced'>
+     DISTRO = poky
+     DISTRO_VERSION = 1.1+snapshot-20120207
+     USER_CLASSES = image-mklibs image-prelink
+     IMAGE_CLASSES = image_types
+     IMAGE_FEATURES = debug-tweaks x11-base apps-x11-core \
+        package-management ssh-server-dropbear package-management
+     IMAGE_LINGUAS = en-us en-gb
+     IMAGE_INSTALL = task-core-boot task-base-extended
+     BAD_RECOMMENDATIONS =
+     ROOTFS_POSTPROCESS_COMMAND = buildhistory_get_image_installed ;   rootfs_update_timestamp ;
+     IMAGE_POSTPROCESS_COMMAND = buildhistory_get_imageinfo ;
+     IMAGESIZE = 171816
+                </literallayout>
+                Other than <filename>IMAGESIZE</filename>, which is the
+                total size of the files in the image in Kbytes, the
+                name-value pairs are variables that may have influenced the
+                content of the image.
+                This information is often useful when you are trying to determine
+                why a change in the package or file listings has occurred.
+            </para>
+        </section>
+
+        <section id='using-build-history-to-gather-image-information-only'>
+            <title>Using Build History to Gather Image Information Only</title>
+
+            <para>
+                As you can see, build history produces image information,
+                including dependency graphs, so you can see why something
+                was pulled into the image.
+                If you are just interested in this information and not
+                interested in collecting history or any package information,
+                you can enable writing only image information without
+                any history by adding the following
+                to your <filename>conf/local.conf</filename> file found in the
+                <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>:
+                <literallayout class='monospaced'>
+     INHERIT += "buildhistory"
+     BUILDHISTORY_COMMIT = "0"
+     BUILDHISTORY_FEATURES = "image"
+                </literallayout>
+            </para>
+        </section>
+
+        <section id='build-history-sdk-information'>
+            <title>Build History SDK Information</title>
+            <para>
+                Build history collects similar information on the contents
+                of SDKs (e.g., <filename>meta-toolchain</filename>
+                or <filename>bitbake -c populate_sdk imagename</filename>)
+                as compared to information it collects for images.
+                The following list shows the files produced for each SDK:
+                <itemizedlist>
+                    <listitem><para><filename>files-in-sdk.txt:</filename>
+                        A list of files in the SDK with permissions,
+                        owner, group, size, and symlink information.
+                        This list includes both the host and target parts
+                        of the SDK.
+                        </para></listitem>
+                    <listitem><para><filename>sdk-info.txt:</filename>
+                        A text file containing name-value pairs with information
+                        about the SDK.
+                        See the following listing example for more information.
+                        </para></listitem>
+                    <listitem><para>The following information appears under
+                        each of the <filename>host</filename>
+                        and <filename>target</filename> directories
+                        for the portions of the SDK that run on the host and
+                        on the target, respectively:
+                        <itemizedlist>
+                            <listitem><para><filename>depends.dot:</filename>
+                                Dependency graph for the SDK that is
+                                compatible with <filename>graphviz</filename>.
+                                </para></listitem>
+                            <listitem><para><filename>installed-package-names.txt:</filename>
+                                A list of installed packages by name only.
+                                </para></listitem>
+                            <listitem><para><filename>installed-package-sizes.txt:</filename>
+                                A list of installed packages ordered by size.
+                                </para></listitem>
+                            <listitem><para><filename>installed-packages.txt:</filename>
+                                A list of installed packages with full package
+                                filenames.</para></listitem>
+                            </itemizedlist>
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+
+            <para>
+                Here is an example of <filename>sdk-info.txt</filename>:
+                <literallayout class='monospaced'>
+     DISTRO = poky
+     DISTRO_VERSION = 1.3+snapshot-20130327
+     SDK_NAME = poky-eglibc-i686-arm
+     SDK_VERSION = 1.3+snapshot
+     SDKMACHINE =
+     SDKIMAGE_FEATURES = dev-pkgs dbg-pkgs
+     BAD_RECOMMENDATIONS =
+     SDKSIZE = 352712
+                </literallayout>
+                Other than <filename>SDKSIZE</filename>, which is the
+                total size of the files in the SDK in Kbytes, the
+                name-value pairs are variables that might have influenced the
+                content of the SDK.
+                This information is often useful when you are trying to
+                determine why a change in the package or file listings
+                has occurred.
+            </para>
+        </section>
+
+        <section id='examining-build-history-information'>
+            <title>Examining Build History Information</title>
+
+            <para>
+                You can examine build history output from the command line or
+                from a web interface.
+            </para>
+
+            <para>
+                To see any changes that have occurred (assuming you have
+                <filename>BUILDHISTORY_COMMIT = "1"</filename>), you can simply
+                use any Git command that allows you to view the history of
+                a repository.
+                Here is one method:
+                <literallayout class='monospaced'>
+      $ git log -p
+                </literallayout>
+                You need to realize, however, that this method does show
+                changes that are not significant (e.g. a package's size
+                changing by a few bytes).
+            </para>
+
+            <para>
+                A command-line tool called <filename>buildhistory-diff</filename>
+                does exist, though, that queries the Git repository and prints just
+                the differences that might be significant in human-readable form.
+                Here is an example:
+                <literallayout class='monospaced'>
+     $ ~/poky/poky/scripts/buildhistory-diff . HEAD^
+     Changes to images/qemux86_64/eglibc/core-image-minimal (files-in-image.txt):
+        /etc/anotherpkg.conf was added
+        /sbin/anotherpkg was added
+        * (installed-package-names.txt):
+        *   anotherpkg was added
+     Changes to images/qemux86_64/eglibc/core-image-minimal (installed-package-names.txt):
+        anotherpkg was added
+     packages/qemux86_64-poky-linux/v86d: PACKAGES: added "v86d-extras"
+        * PR changed from "r0" to "r1"
+        * PV changed from "0.1.10" to "0.1.12"
+     packages/qemux86_64-poky-linux/v86d/v86d: PKGSIZE changed from 110579 to 144381 (+30%)
+        * PR changed from "r0" to "r1"
+        * PV changed from "0.1.10" to "0.1.12"
+                </literallayout>
+            </para>
+
+            <para>
+                To see changes to the build history using a web interface, follow
+                the instruction in the <filename>README</filename> file here.
+                <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/buildhistory-web/'></ulink>.
+            </para>
+
+            <para>
+                Here is a sample screenshot of the interface:
+                <imagedata fileref="figures/buildhistory-web.png" align="center" scalefit="1" width="130%" contentdepth="130%" />
+            </para>
+        </section>
+    </section>
+</section>
+
+</chapter>
+<!--
+vim: expandtab tw=80 ts=4
+-->