diff --git a/documentation/ref-manual/closer-look.xml b/documentation/ref-manual/closer-look.xml
index 27f674a..45dcd9b 100644
--- a/documentation/ref-manual/closer-look.xml
+++ b/documentation/ref-manual/closer-look.xml
@@ -1059,7 +1059,7 @@
                 the root filesystem image that lists out, line-by-line, the
                 installed packages.
                 This manifest file is useful for the
-                <link linkend='ref-classes-testimage'><filename>testimage</filename></link>
+                <link linkend='ref-classes-testimage*'><filename>testimage</filename></link>
                 class, for example, to determine whether or not to run
                 specific tests.
                 See the
diff --git a/documentation/ref-manual/introduction.xml b/documentation/ref-manual/introduction.xml
index 5250e26..0b16544 100644
--- a/documentation/ref-manual/introduction.xml
+++ b/documentation/ref-manual/introduction.xml
@@ -154,11 +154,14 @@
                 <listitem><para>Ubuntu 13.10</para></listitem> -->
                 <listitem><para>Ubuntu 14.04 (LTS)</para></listitem>
                 <listitem><para>Ubuntu 14.10</para></listitem>
+                <listitem><para>Ubuntu 15.04</para></listitem>
+                <listitem><para>Ubuntu 15.10</para></listitem>
 <!--                <listitem><para>Fedora 16 (Verne)</para></listitem>
                 <listitem><para>Fedora 17 (Spherical)</para></listitem>
                 <listitem><para>Fedora release 19 (Schrödinger's Cat)</para></listitem>
                 <listitem><para>Fedora release 20 (Heisenbug)</para></listitem> -->
                 <listitem><para>Fedora release 21</para></listitem>
+                <listitem><para>Fedora release 22</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>
@@ -250,8 +253,15 @@
                         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
+     $ sudo apt-get install autoconf automake libtool libglib2.0-dev libarchive-dev
                         </literallayout></para></listitem>
+                    <listitem><para><emphasis>OpenEmbedded Self-Test (<filename>oe-selftest</filename>):</emphasis>
+                        Packages needed if you are going to run
+                        <filename>oe-selftest</filename>:
+                        <literallayout class='monospaced'>
+     $ sudo apt-get install python-git
+                        </literallayout>
+                        </para></listitem>
                 </itemizedlist>
             </para>
         </section>
@@ -267,28 +277,35 @@
                         Packages needed to build an image for a headless
                         system:
                         <literallayout class='monospaced'>
-     $ sudo yum install &FEDORA_HOST_PACKAGES_ESSENTIAL;
+     $ sudo dnf install &FEDORA_HOST_PACKAGES_ESSENTIAL;
                         </literallayout></para></listitem>
                     <listitem><para><emphasis>Graphical and Eclipse Plug-In Extras:</emphasis>
                         Packages recommended if the host system has graphics
                         support or if you are going to use the Eclipse
                         IDE:
                         <literallayout class='monospaced'>
-     $ sudo yum install SDL-devel xterm perl-Thread-Queue
+     $ sudo dnf 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 \
+     $ sudo dnf install make docbook-style-dsssl docbook-style-xsl \
      docbook-dtds docbook-utils fop libxslt dblatex xmlto xsltproc
                         </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
+     $ sudo dnf install autoconf automake libtool glib2-devel libarchive-devel
                         </literallayout></para></listitem>
+                    <listitem><para><emphasis>OpenEmbedded Self-Test (<filename>oe-selftest</filename>):</emphasis>
+                        Packages needed if you are going to run
+                        <filename>oe-selftest</filename>:
+                        <literallayout class='monospaced'>
+     $ sudo dnf install GitPython
+                        </literallayout>
+                        </para></listitem>
                 </itemizedlist>
             </para>
         </section>
@@ -323,7 +340,13 @@
                         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
+     $ sudo zypper install autoconf automake libtool glib2-devel libarchive-devel
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>OpenEmbedded Self-Test (<filename>oe-selftest</filename>):</emphasis>
+                        Packages needed if you are going to run
+                        <filename>oe-selftest</filename>:
+                        <literallayout class='monospaced'>
+     $ sudo zypper install python-GitPython
                         </literallayout></para></listitem>
                 </itemizedlist>
             </para>
@@ -336,14 +359,14 @@
                 The following list shows the required packages by function
                 given a supported CentOS Linux distribution:
                 <note>
-                    For CentOS 6.x, some of the versions of the components
-                    provided by the distribution are too old (e.g. Git, Python,
-                    and tar).
-                    It is recommended that you install the buildtools in order
-                    to provide versions that will work with the OpenEmbedded
-                    build system.
-                    For information on how to install the buildtools tarball,
-                    see the
+                    For CentOS 6.x, some of the versions
+                    of the components provided by the distribution are
+                    too old (e.g. Git, Python, and tar).
+                    It is recommended that you install the buildtools
+                    in order to provide versions that will work with
+                    the OpenEmbedded build system.
+                    For information on how to install the buildtools
+                    tarball, see the
                     "<link linkend='required-git-tar-and-python-versions'>Required Git, Tar, and Python Versions</link>"
                     section.
                 </note>
@@ -372,8 +395,24 @@
                         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>
+     $ sudo yum install autoconf automake libtool glib2-devel libarchive-devel
+                        </literallayout>
+                        <note>
+                            For CentOS 6.x, in order for the
+                            ADT installer script to work, you must have
+                            installed the <filename>liblzma5</filename>,
+                            <filename>libarchive3.x</filename>, and
+                            <filename>libarchive-devel-3.1.3</filename>
+                            (or older) packages, in that order.
+                        </note>
+                        </para></listitem>
+                    <listitem><para><emphasis>OpenEmbedded Self-Test (<filename>oe-selftest</filename>):</emphasis>
+                        Packages needed if you are going to run
+                        <filename>oe-selftest</filename>:
+                        <literallayout class='monospaced'>
+     $ sudo yum install GitPython
+                        </literallayout>
+                        </para></listitem>
                 </itemizedlist>
             </para>
         </section>
diff --git a/documentation/ref-manual/migration.xml b/documentation/ref-manual/migration.xml
index dc75eb8..21763e3 100644
--- a/documentation/ref-manual/migration.xml
+++ b/documentation/ref-manual/migration.xml
@@ -980,7 +980,7 @@
         <para>
             A new automated image testing framework has been added
             through the
-            <link linkend='ref-classes-testimage'><filename>testimage*.bbclass</filename></link>
+            <link linkend='ref-classes-testimage*'><filename>testimage.bbclass</filename></link>
             class.
             This framework replaces the older
             <filename>imagetest-qemu</filename> framework.
@@ -1254,7 +1254,7 @@
                     <listitem><para><filename>bb.MalformedUrl</filename>:
                         Use <filename>bb.fetch.MalformedUrl</filename>.
                         </para></listitem>
-                    <listitem><para><filename>bb.fetch.encodeurl</filename>:
+                    <listitem><para><filename>bb.encodeurl</filename>:
                         Use <filename>bb.fetch.encodeurl</filename>.
                         </para></listitem>
                     <listitem><para><filename>bb.decodeurl</filename>:
@@ -1485,8 +1485,9 @@
             Recipes building Autotools-based
             software that fails to build with a separate build directory
             should be changed to inherit from the
-            <link linkend='ref-classes-autotools-brokensep'><filename>autotools-brokensep</filename></link>
-            class instead of the <filename>autotools</filename> class.
+            <link linkend='ref-classes-autotools'><filename>autotools-brokensep</filename></link>
+            class instead of the <filename>autotools</filename> or
+            <filename>autotools_stage</filename>classes.
         </para>
     </section>
 
@@ -1794,8 +1795,9 @@
                     need to either patch the software so that it can build
                     separately, or you will need to change the recipe to
                     inherit the
-                    <link linkend='ref-classes-autotools-brokensep'><filename>autotools-brokensep</filename></link>
-                    class instead of the <filename>autotools</filename> class.
+                    <link linkend='ref-classes-autotools'><filename>autotools-brokensep</filename></link>
+                    class instead of the <filename>autotools</filename> or
+                    <filename>autotools_stage</filename> classes.
                     </para></listitem>
                 <listitem><para><emphasis>
                     The <filename>--foreign</filename> option is
@@ -2313,6 +2315,427 @@
     </section>
 </section>
 
+<section id='moving-to-the-yocto-project-2.0-release'>
+    <title>Moving to the Yocto Project 2.0 Release</title>
+
+    <para>
+        This section provides migration information for moving to the
+        Yocto Project 2.0 Release from the prior release.
+    </para>
+
+    <section id='migration-2.0-gcc-5'>
+        <title>GCC 5</title>
+
+        <para>
+            The default compiler is now GCC 5.2.
+            This change has required fixes for compilation errors in a number
+            of other recipes.
+        </para>
+
+        <para>
+            One important example is a fix for when the Linux kernel freezes at
+            boot time on ARM when built with GCC 5.
+            If you are using your own kernel recipe or source tree and
+            building for ARM, you will likely need to apply this
+            <ulink url='https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=a077224fd35b2f7fbc93f14cf67074fc792fbac2'>patch</ulink>.
+            The standard <filename>linux-yocto</filename> kernel source tree
+            already has a workaround for the same issue.
+        </para>
+
+        <para>
+            For further details, see
+            <ulink url='https://gcc.gnu.org/gcc-5/changes.html'></ulink> and
+            the porting guide at
+            <ulink url='https://gcc.gnu.org/gcc-5/porting_to.html'></ulink>.
+        </para>
+
+        <para>
+            Alternatively, you can switch back to GCC 4.9 or 4.8 by
+            setting <filename>GCCVERSION</filename> in your configuration,
+            as follows:
+            <literallayout class='monospaced'>
+     GCCVERSION = "4.9%"
+            </literallayout>
+        </para>
+    </section>
+
+    <section id='migration-2.0-Gstreamer-0.10-removed'>
+        <title>Gstreamer 0.10 Removed</title>
+
+        <para>
+            Gstreamer 0.10 has been removed in favor of Gstreamer 1.x.
+            As part of the change, recipes for Gstreamer 0.10 and related
+            software are now located
+            in <filename>meta-multimedia</filename>.
+            This change results in Qt4 having Phonon and Gstreamer
+            support in QtWebkit disabled by default.
+        </para>
+    </section>
+
+    <section id='migration-2.0-removed-recipes'>
+        <title>Removed Recipes</title>
+
+        <para>
+            The following recipes have been moved or removed:
+            <itemizedlist>
+                <listitem><para>
+                    <filename>bluez4</filename>: The recipe is obsolete and
+                    has been moved due to <filename>bluez5</filename>
+                    becoming fully integrated.
+                    The <filename>bluez4</filename> recipe now resides in
+                    <filename>meta-oe</filename>.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>gamin</filename>: The recipe is obsolete and
+                    has been removed.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>gnome-icon-theme</filename>: The recipe's
+                    functionally has been replaced by
+                    <filename>adwaita-icon-theme</filename>.
+                    </para></listitem>
+                <listitem><para>
+                    Gstreamer 0.10 Recipes: Recipes for Gstreamer 0.10 have
+                    been removed in favor of the recipes for Gstreamer 1.x.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>insserv</filename>: The recipe is obsolete and
+                    has been removed.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>libunique</filename>: The recipe is no longer
+                    used and has been moved to <filename>meta-oe</filename>.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>midori</filename>: The recipe's functionally
+                    has been replaced by <filename>epiphany</filename>.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>python-gst</filename>: The recipe is obsolete
+                    and has been removed since it only contains bindings for
+                    Gstreamer 0.10.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>qt-mobility</filename>: The recipe is obsolete and
+                    has been removed since it requires
+                    <filename>Gstreamer 0.10</filename>, which has been
+                    replaced.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>subversion</filename>: All 1.6.x versions of this
+                    recipe have been removed.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>webkit-gtk</filename>: The older 1.8.3 version
+                    of this recipe has been removed in favor of
+                    <filename>webkitgtk</filename>.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-2.0-bitbake-datastore-improvements'>
+        <title>BitBake datastore improvements</title>
+
+        <para>
+            The method by which BitBake's datastore handles overrides has
+            changed.
+            Overrides are now applied dynamically and
+            <filename>bb.data.update_data()</filename> is now a no-op.
+            Thus, <filename>bb.data.update_data()</filename> is no longer
+            required in order to apply the correct overrides.
+            In practice, this change is unlikely to require any changes to
+            Metadata.
+            However, these minor changes in behavior exist:
+            <itemizedlist>
+                <listitem><para>
+                    All potential overrides are now visible in the variable
+                    history as seen when you run the following:
+                    <literallayout class='monospaced'>
+     $ bitbake -e
+                    </literallayout>
+                    </para></listitem>
+                <listitem><para>
+                    <filename>d.delVar('VARNAME')</filename> and
+                    <filename>d.setVar('VARNAME', None)</filename> result
+                    in the variable and all of its overrides being cleared out.
+                    Before the change, only the non-overridden values
+                    were cleared.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-2.0-shell-message-function-changes'>
+        <title>Shell Message Function Changes</title>
+
+        <para>
+            The shell versions of the BitBake message functions (i.e.
+            <filename>bbdebug</filename>, <filename>bbnote</filename>,
+            <filename>bbwarn</filename>, <filename>bbplain</filename>,
+            <filename>bberror</filename>, and <filename>bbfatal</filename>)
+            are now connected through to their BitBake equivalents
+            <filename>bb.debug()</filename>, <filename>bb.note()</filename>,
+            <filename>bb.warn()</filename>, <filename>bb.plain()</filename>,
+            <filename>bb.error()</filename>, and
+            <filename>bb.fatal()</filename>, respectively.
+            Thus, those message functions that you would expect to be printed
+            by the BitBake UI are now actually printed.
+            In practice, this change means two things:
+            <itemizedlist>
+                <listitem><para>
+                    If you now see messages on the console that you did not
+                    previously see as a result of this change, you might
+                    need to clean up the calls to
+                    <filename>bbwarn</filename>, <filename>bberror</filename>,
+                    and so forth.
+                    Or, you might want to simply remove the calls.
+                    </para></listitem>
+                <listitem><para>
+                    The <filename>bbfatal</filename> message function now
+                    suppresses the full error log in the UI, which means any
+                    calls to <filename>bbfatal</filename> where you still
+                    wish to see the full error log should be replaced by
+                    <filename>die</filename> or
+                    <filename>bbfatal_log</filename>.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-2.0-extra-development-debug-package-cleanup'>
+        <title>Extra Development/Debug Package Cleanup</title>
+
+        <para>
+            The following recipes have had extra
+            <filename>dev/dbg</filename> packages removed:
+            <itemizedlist>
+                <listitem><para>
+                    <filename>acl</filename>
+                    </para></listitem>
+                <listitem><para>
+                    <filename>apmd</filename>
+                    </para></listitem>
+                <listitem><para>
+                    <filename>aspell</filename>
+                    </para></listitem>
+                <listitem><para>
+                    <filename>attr</filename>
+                    </para></listitem>
+                <listitem><para>
+                    <filename>augeas</filename>
+                    </para></listitem>
+                <listitem><para>
+                    <filename>bzip2</filename>
+                    </para></listitem>
+                <listitem><para>
+                    <filename>cogl</filename>
+                    </para></listitem>
+                <listitem><para>
+                    <filename>curl</filename>
+                    </para></listitem>
+                <listitem><para>
+                    <filename>elfutils</filename>
+                    </para></listitem>
+                <listitem><para>
+                    <filename>gcc-target</filename>
+                    </para></listitem>
+                <listitem><para>
+                    <filename>libgcc</filename>
+                    </para></listitem>
+                <listitem><para>
+                    <filename>libtool</filename>
+                    </para></listitem>
+                <listitem><para>
+                    <filename>libxmu</filename>
+                    </para></listitem>
+                <listitem><para>
+                    <filename>opkg</filename>
+                    </para></listitem>
+                <listitem><para>
+                    <filename>pciutils</filename>
+                    </para></listitem>
+                <listitem><para>
+                    <filename>rpm</filename>
+                    </para></listitem>
+                <listitem><para>
+                    <filename>sysfsutils</filename>
+                    </para></listitem>
+                <listitem><para>
+                    <filename>tiff</filename>
+                    </para></listitem>
+                <listitem><para>
+                    <filename>xz</filename>
+                    </para></listitem>
+            </itemizedlist>
+            All of the above recipes now conform to the standard packaging
+            scheme where a single <filename>-dev</filename>,
+            <filename>-dbg</filename>, and <filename>-staticdev</filename>
+            package exists per recipe.
+        </para>
+    </section>
+
+    <section id='migration-2.0-recipe-maintenance-tracking-data-moved-to-oe-core'>
+        <title>Recipe Maintenance Tracking Data Moved to OE-Core</title>
+
+        <para>
+            Maintenance tracking data for recipes that was previously part
+            of <filename>meta-yocto</filename> has been moved to OE-Core.
+            The change includes <filename>package_regex.inc</filename> and
+            <filename>distro_alias.inc</filename>, which are typically enabled
+            when using the
+            <link linkend='ref-classes-distrodata'><filename>distrodata</filename></link>
+            class.
+            Additionally, the contents of
+            <filename>upstream_tracking.inc</filename> has now been split out
+            to the relevant recipes.
+        </para>
+    </section>
+
+    <section id='migration-2.0-automatic-stale-sysroot-file-cleanup'>
+        <title>Automatic Stale Sysroot File Cleanup</title>
+
+        <para>
+            Stale files from recipes that no longer exist in the current
+            configuration are now automatically removed from
+            sysroot as well as removed from
+            any other place managed by shared state.
+            This automatic cleanup means that the build system now properly
+            handles situations such as renaming the build system side of
+            recipes, removal of layers from
+            <filename>bblayers.conf</filename>, and
+            <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>
+            changes.
+        </para>
+
+        <para>
+            Additionally, work directories for old versions of recipes are
+            now pruned.
+            If you wish to disable pruning old work directories, you can set
+            the following variable in your configuration:
+            <literallayout class='monospaced'>
+     SSTATE_PRUNE_OBSOLETEWORKDIR = "0"
+            </literallayout>
+        </para>
+    </section>
+
+    <section id='migration-2.0-linux-yocto-kernel-metadata-repository-now-split-from-source'>
+        <title><filename>linux-yocto</filename> Kernel Metadata Repository Now Split from Source</title>
+
+        <para>
+            The <filename>linux-yocto</filename> tree has up to now been a
+            combined set of kernel changes and configuration (meta) data
+            carried in a single tree.
+            While this format is effective at keeping kernel configuration and
+            source modifications synchronized, it is not always obvious to
+            developers how to manipulate the Metadata as compared to the
+            source.
+        </para>
+
+        <para>
+            Metadata processing has now been removed from the
+            <link linkend='ref-classes-kernel-yocto'><filename>kernel-yocto</filename></link>
+            class and the external Metadata repository
+            <filename>yocto-kernel-cache</filename>, which has always been used
+            to seed the <filename>linux-yocto</filename> "meta" branch.
+            This separate <filename>linux-yocto</filename> cache repository
+            is now the primary location for this data.
+            Due to this change, <filename>linux-yocto</filename> is no longer
+            able to process combined trees.
+            Thus, if you need to have your own combined kernel repository,
+            you must do the split there as well and update your recipes
+            accordingly.
+            See the <filename>meta/recipes-kernel/linux/linux-yocto_4.1.bb</filename>
+            recipe for an example.
+        </para>
+    </section>
+
+    <section id='migration-2.0-additional-qa-checks'>
+        <title>Additional QA checks</title>
+
+        <para>
+            The following QA checks have been added:
+            <itemizedlist>
+                <listitem><para>
+                    Added a "host-user-contaminated" check for ownership
+                    issues for packaged files outside of
+                    <filename>/home</filename>.
+                    The check looks for files that are incorrectly owned by the
+                    user that ran BitBake instead of owned by a valid user in
+                    the target system.
+                    </para></listitem>
+                <listitem><para>
+                    Added an "invalid-chars" check for invalid (non-UTF8)
+                    characters in recipe metadata variable values
+                    (i.e.
+                    <link linkend='var-DESCRIPTION'><filename>DESCRIPTION</filename></link>,
+                    <link linkend='var-SUMMARY'><filename>SUMMARY</filename></link>,
+                    <link linkend='var-LICENSE'><filename>LICENSE</filename></link>,
+                    and
+                    <link linkend='var-SECTION'><filename>SECTION</filename></link>).
+                    Some package managers do not support these characters.
+                    </para></listitem>
+                <listitem><para>
+                    Added an "invalid-packageconfig" check for any options
+                    specified in
+                    <link linkend='var-PACKAGECONFIG'><filename>PACKAGECONFIG</filename></link>
+                    that do not match any <filename>PACKAGECONFIG</filename>
+                    option defined for the recipe.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-2.0-miscellaneous'>
+        <title>Miscellaneous Changes</title>
+
+        <para>
+            These additional changes exist:
+            <itemizedlist>
+                <listitem><para>
+                    <filename>gtk-update-icon-cache</filename> has been
+                    renamed to <filename>gtk-icon-utils</filename>.
+                    </para></listitem>
+                <listitem><para>
+                    The <filename>tools-profile</filename>
+                    <link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>
+                    item as well as its corresponding packagegroup and
+                    <filename>packagegroup-core-tools-profile</filename> no
+                    longer bring in <filename>oprofile</filename>.
+                    Bringing in <filename>oprofile</filename> was originally
+                    added to aid compilation on resource-constrained
+                    targets.
+                    However, this aid has not been widely used and is not
+                    likely to be used going forward due to the more powerful
+                    target platforms and the existence of better
+                    cross-compilation tools.
+                    </para></listitem>
+                <listitem><para>
+                    The
+                    <link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>
+                    variable's default value now specifies
+                    <filename>ext4</filename> instead of
+                    <filename>ext3</filename>.
+                    </para></listitem>
+                <listitem><para>
+                    All support for the <filename>PRINC</filename>
+                    variable has been removed.
+                    </para></listitem>
+                <listitem><para>
+                    The <filename>packagegroup-core-full-cmdline</filename>
+                    packagegroup no longer brings in
+                    <filename>lighttpd</filename> due to the fact that
+                    bringing in <filename>lighttpd</filename> is not really in
+                    line with the packagegroup's purpose, which is to add full
+                    versions of command-line tools that by default are
+                    provided by <filename>busybox</filename>.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+</section>
+
+
 </chapter>
 <!--
 vim: expandtab tw=80 ts=4
diff --git a/documentation/ref-manual/ref-classes.xml b/documentation/ref-manual/ref-classes.xml
index d87c9ff..b2941b8 100644
--- a/documentation/ref-manual/ref-classes.xml
+++ b/documentation/ref-manual/ref-classes.xml
@@ -52,20 +52,22 @@
         and a C library as pre-requisites, and splitting out of debug symbols
         during packaging).
         <note>
-            Unlike e.g. Debian, OpenEmbedded recipes that produce packages
-            which
+            <para>Unlike some distro recipes (e.g. Debian), OpenEmbedded recipes
+            that produce packages that depend on tunings through use of the
             <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>
-            on
+            and
             <link linkend='var-TUNE_PKGARCH'><filename>TUNE_PKGARCH</filename></link>
-            packages should never be made <filename>allarch</filename>, even
-            if they do not produce architecture-specific output. This would
-            cause the do_package_write_* tasks to have different signatures
-            for
-            <link linkend='var-MACHINE'><filename>MACHINE</filename></link>s
-            with different
-            <link linkend='var-TUNE_PKGARCH'><filename>TUNE_PKGARCH</filename></link>,
-            thus unnecessary rebuilds every single time an image for a different
-            MACHINE is built (even without any change to the recipe).
+            variables, should never be configured for all architectures
+            using <filename>allarch</filename>.
+            This is the case even if the recipes do not produce
+            architecture-specific output.</para>
+            <para>Configuring such recipes for all architectures causes the
+            <link linkend='ref-tasks-package_write_deb'><filename>do_package_write_*</filename></link>
+            tasks to have different signatures for the machines with different
+            tunings.
+            Additionally, unnecessary rebuilds occur every time an
+            image for a different <filename>MACHINE</filename> is built
+            even when the recipe never changes.</para>
         </note>
     </para>
 
@@ -101,70 +103,44 @@
 </section>
 
 <section id='ref-classes-autotools'>
-    <title><filename>autotools.bbclass</filename></title>
+    <title><filename>autotools*.bbclass</filename></title>
 
     <para>
-        The <filename>autotools</filename> class supports Autotooled
+        The <filename>autotools*</filename> classes support Autotooled
         packages.
     </para>
 
     <para>
         The <filename>autoconf</filename>, <filename>automake</filename>,
-        and <filename>libtool</filename> bring standardization.
-        This class defines a set of tasks (configure, compile etc.) that
+        and <filename>libtool</filename> packages bring standardization.
+        This class defines a set of tasks (e.g.
+        <filename>configure</filename>, <filename>compile</filename> and
+        so forth) 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.
+        These classes can also work with software that emulates Autotools.
         For more information, see the
         "<ulink url='&YOCTO_DOCS_DEV_URL;#new-recipe-autotooled-package'>Autotooled Package</ulink>"
         section in the Yocto Project Development Manual.
     </para>
 
     <para>
-        By default, the <filename>autotools</filename> class
-        uses out-of-tree builds
+        By default, the <filename>autotools*</filename> classes
+        use out-of-tree builds (i.e.
+        <filename>autotools.bbclass</filename> and
+        <filename>autotools_stage.bbclass</filename>).
         (<link linkend='var-B'><filename>B</filename></link> <filename>!=</filename>
         <link linkend='var-S'><filename>S</filename></link>).
+    </para>
+
+    <para>
         If the software being built by a recipe does not support
         using out-of-tree builds, you should have the recipe inherit the
-        <link linkend='ref-classes-autotools-brokensep'><filename>autotools-brokensep</filename></link>
-        class.
-    </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><link linkend='ref-tasks-configure'><filename>do_configure</filename></link> -
-                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><link linkend='ref-tasks-compile'><filename>do_compile</filename></link> - 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><link linkend='ref-tasks-install'><filename>do_install</filename></link> - 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-autotools-brokensep'>
-    <title><filename>autotools-brokensep.bbclass</filename></title>
-
-    <para>
+        <filename>autotools-brokensep</filename> class.
         The <filename>autotools-brokensep</filename> class behaves the same
-        as the
-        <link linkend='ref-classes-autotools'><filename>autotools</filename></link>
-        class but builds with
+        as the <filename>autotools</filename> and
+        <filename>autotools_stage</filename> classes but builds with
         <link linkend='var-B'><filename>B</filename></link> ==
         <link linkend='var-S'><filename>S</filename></link>.
         This method is useful when out-of-tree build support is either not
@@ -174,6 +150,34 @@
             if at all possible.
         </note>
     </para>
+
+    <para>
+        It's useful to have some idea of how the tasks defined by
+        the <filename>autotools*</filename> classes work and what they do
+        behind the scenes.
+        <itemizedlist>
+            <listitem><para><link linkend='ref-tasks-configure'><filename>do_configure</filename></link> -
+                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><link linkend='ref-tasks-compile'><filename>do_compile</filename></link> -
+                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><link linkend='ref-tasks-install'><filename>do_install</filename></link> -
+                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-base'>
@@ -211,14 +215,22 @@
         use for this class.
         <note>
             For RPMs and other packages that do not contain a subdirectory,
-            you should specify a "subdir" parameter.
+            you should specify an appropriate fetcher parameter to point to
+            the subdirectory.
+            For example, if BitBake is using the Git fetcher
+            (<filename>git://</filename>), the "subpath" parameter limits
+            the checkout to a specific subpath of the tree.
             Here is an example where <filename>${BP}</filename> is used so that
             the files are extracted into the subdirectory expected by the
             default value of
             <link linkend='var-S'><filename>S</filename></link>:
             <literallayout class='monospaced'>
-     SRC_URI = "http://example.com/downloads/somepackage.rpm;subdir=${BP}"
+     SRC_URI = "git://example.com/downloads/somepackage.rpm;subpath=${BP}"
             </literallayout>
+            See the
+            "<ulink url='&YOCTO_DOCS_BB_URL;#bb-fetchers'>Fetchers</ulink>"
+            section in the BitBake User Manual for more information on
+            supported BitBake Fetchers.
         </note>
     </para>
 </section>
@@ -552,10 +564,10 @@
 </section>
 
 <section id='ref-classes-cpan'>
-    <title><filename>cpan.bbclass</filename></title>
+    <title><filename>cpan*.bbclass</filename></title>
 
     <para>
-        The <filename>cpan</filename> class supports Perl modules.
+        The <filename>cpan*</filename> classes support Perl modules.
     </para>
 
     <para>
@@ -574,6 +586,8 @@
                 using <filename>cpan_build.bbclass</filename> in their recipes.
                 </para></listitem>
         </itemizedlist>
+        Both build methods inherit the <filename>cpan-base</filename> class
+        for basic Perl support.
     </para>
 </section>
 
@@ -707,25 +721,20 @@
 
     <para>
         The class is not included by default.
-        To use it, you must include the following files and set the
+        To use it, you must set the
         <link linkend='var-INHERIT'><filename>INHERIT</filename></link>
         variable:
         <literallayout class='monospaced'>
-     include conf/distro/include/distro_alias.inc
-     include conf/distro/include/recipe_color.inc
-     include conf/distro/include/maintainers.inc
-     include conf/distro/include/upstream_tracking.inc
-     include conf/distro/include/package_regex.inc
      INHERIT+= "distrodata"
         </literallayout>
     </para>
 </section>
 
 <section id='ref-classes-distutils'>
-    <title><filename>distutils.bbclass</filename></title>
+    <title><filename>distutils*.bbclass</filename></title>
 
     <para>
-        The <filename>distutils</filename> class supports recipes for Python
+        The <filename>distutils*</filename> classes support recipes for Python
         version 2.x extensions, which are simple.
         These recipes usually only need to point to the source's archive and
         then inherit the proper class.
@@ -733,8 +742,8 @@
         module authors used.
         <itemizedlist>
             <listitem><para>Extensions that use an Autotools-based build system
-                require Autotools and
-                <filename>distutils</filename>-based classes in their recipes.
+                require Autotools and the classes based on
+                <filename>distutils</filename> in their recipes.
                 </para></listitem>
             <listitem><para>Extensions that use build systems based on
                 <filename>distutils</filename> require
@@ -746,18 +755,26 @@
                 class in their recipes.
                 </para></listitem>
         </itemizedlist>
+        The <filename>distutils-common-base</filename> class is required by
+        some of the <filename>distutils*</filename> classes to provide common
+        Python2 support.
+    </para>
+
+    <para>
+	    The <filename>distutils-tools</filename> class supports recipes for
+        additional "distutils" tools.
     </para>
 </section>
 
 <section id='ref-classes-distutils3'>
-    <title><filename>distutils3.bbclass</filename></title>
+    <title><filename>distutils3*.bbclass</filename></title>
 
     <para>
-        The <filename>distutils3</filename> class supports recipes for Python
+        The <filename>distutils3*</filename> classes support recipes for Python
         version 3.x extensions, which are simple.
         These recipes usually only need to point to the source's archive and
         then inherit the proper class.
-        Building is split into two methods depending on which method the
+        Building is split into three methods depending on which method the
         module authors used.
         <itemizedlist>
             <listitem><para>Extensions that use an Autotools-based build system
@@ -774,6 +791,14 @@
                 class in their recipes.
                 </para></listitem>
         </itemizedlist>
+        The <filename>distutils3*</filename> classes either inherit their
+        corresponding <filename>distutils*</filename> class or replicate them
+        using a Python3 version instead (e.g.
+        <filename>distutils3-base</filename> inherits
+        <filename>distutils-common-base</filename>, which is the same as
+        <filename>distutils-base</filename> but inherits
+        <filename>python3native</filename> instead of
+        <filename>pythonnative</filename>).
     </para>
 </section>
 
@@ -905,6 +930,19 @@
     </para>
 </section>
 
+<section id='ref-classes-fs-uuid'>
+    <title><filename>fs-uuid.bbclass</filename></title>
+
+    <para>
+        The <filename>fs-uuid</filename> class extracts UUID from
+        <filename>${</filename><link linkend='var-ROOTFS'><filename>ROOTFS</filename></link><filename>}</filename>,
+        which must have been built by the time that this function gets called.
+        The <filename>fs-uuid</filename> class only works on
+        <filename>ext</filename> file systems and depends on
+        <filename>tune2fs</filename>.
+    </para>
+</section>
+
 <section id='ref-classes-gconf'>
     <title><filename>gconf.bbclass</filename></title>
 
@@ -1255,6 +1293,15 @@
     </para>
 </section>
 
+<section id='ref-classes-image-buildinfo'>
+    <title><filename>image-buildinfo.bbclass</filename></title>
+
+    <para>
+        The <filename>image-buildinfo</filename> class writes information
+        to the target filesystem on <filename>/etc/build</filename>.
+    </para>
+</section>
+
 <section id='ref-classes-image_types'>
     <title><filename>image_types.bbclass</filename></title>
 
@@ -1364,10 +1411,21 @@
         the OpenEmbedded build process.
         <note>
             This class is currently unmaintained.
+            The <filename>strace</filename> package needs to be installed
+            in the build host as a dependency for this tool.
         </note>
     </para>
 </section>
 
+<section id='ref-classes-image-vm'>
+    <title><filename>image-vm.bbclass</filename></title>
+
+    <para>
+        The <filename>image-vm</filename> class supports building VM
+        images.
+    </para>
+</section>
+
 <section id='ref-classes-image-vmdk'>
     <title><filename>image-vmdk.bbclass</filename></title>
 
@@ -1868,6 +1926,25 @@
     </para>
 </section>
 
+<section id='ref-classes-kernel-fitimage'>
+    <title><filename>kernel-fitimage.bbclass</filename></title>
+
+    <para>
+        The <filename>kernel-fitimage</filename> class provides support to
+        pack zImages.
+    </para>
+</section>
+
+<section id='ref-classes-kernel-grub'>
+    <title><filename>kernel-grub.bbclass</filename></title>
+
+    <para>
+        The <filename>kernel-grub</filename> class updates the boot area and
+        the boot menu with the kernel as the priority boot mechanism while
+        installing a RPM to update the kernel on a deployed target.
+    </para>
+</section>
+
 <section id='ref-classes-kernel-module-split'>
     <title><filename>kernel-module-split.bbclass</filename></title>
 
@@ -1878,6 +1955,24 @@
     </para>
 </section>
 
+<section id='ref-classes-kernel-uboot'>
+    <title><filename>kernel-uboot.bbclass</filename></title>
+
+    <para>
+        The <filename>kernel-uboot</filename> class provides support for
+        building from vmlinux-style kernel sources.
+    </para>
+</section>
+
+<section id='ref-classes-kernel-uimage'>
+    <title><filename>kernel-uimage.bbclass</filename></title>
+
+    <para>
+        The <filename>kernel-uimage</filename> class provides support to
+        pack uImage.
+    </para>
+</section>
+
 <section id='ref-classes-kernel-yocto'>
     <title><filename>kernel-yocto.bbclass</filename></title>
 
@@ -1888,6 +1983,15 @@
     </para>
 </section>
 
+<section id='ref-classes-kernelsrc'>
+    <title><filename>kernelsrc.bbclass</filename></title>
+
+    <para>
+        The <filename>kernelsrc</filename> class sets the Linux kernel
+        source and version.
+    </para>
+</section>
+
 <section id='ref-classes-lib_package'>
     <title><filename>lib_package.bbclass</filename></title>
 
@@ -1902,6 +2006,25 @@
     </para>
 </section>
 
+<section id='ref-classes-libc*'>
+    <title><filename>libc*.bbclass</filename></title>
+
+    <para>
+        The <filename>libc*</filename> classes support recipes that build
+        packages with <filename>libc</filename>:
+        <itemizedlist>
+            <listitem><para>The <filename>libc-common</filename> class
+                provides common support for building with
+                <filename>libc</filename>.
+                </para></listitem>
+            <listitem><para>The <filename>libc-package</filename> class
+                supports packaging up <filename>glibc</filename> and
+                <filename>eglibc</filename>.
+                </para></listitem>
+        </itemizedlist>
+    </para>
+</section>
+
 <section id='ref-classes-license'>
     <title><filename>license.bbclass</filename></title>
 
@@ -1926,6 +2049,16 @@
     </para>
 </section>
 
+<section id='ref-classes-linuxloader'>
+    <title><filename>linuxloader.bbclass</filename></title>
+
+    <para>
+        Provides the function <filename>linuxloader()</filename>, which gives
+        the value of the dynamic loader/linker provided on the platform.
+        This value is used by a number of other classes.
+    </para>
+</section>
+
 <section id='ref-classes-logging'>
     <title><filename>logging.bbclass</filename></title>
 
@@ -1971,6 +2104,15 @@
     </para>
 </section>
 
+<section id='ref-classes-migrate_localcount'>
+    <title><filename>migrate_localcount.bbclass</filename></title>
+
+    <para>
+        The <filename>migrate_localcount</filename> class verifies a recipe's
+        localcount data and increments it appropriately.
+    </para>
+</section>
+
 <section id='ref-classes-mime'>
     <title><filename>mime.bbclass</filename></title>
 
@@ -2487,17 +2629,18 @@
     <title><filename>pkgconfig.bbclass</filename></title>
 
     <para>
-        The <filename>pkg-config</filename> class provides a standard way to get
-        header and library information.
+        The <filename>pkgconfig</filename> class provides a standard way to get
+        header and library information by using <filename>pkg-config</filename>.
         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.
+        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>, the <filename>pkgconfig</filename>
+        class no longer has to manipulate the files.
     </para>
 </section>
 
@@ -2536,6 +2679,9 @@
                 Supports creation of the SDK given the opkg (IPK format)
                 package manager.
                 </para></listitem>
+            <listitem><para><emphasis><filename>populate_sdk_ext</filename>:</emphasis>
+                Supports extensible SDK creation under all package managers.
+                </para></listitem>
         </itemizedlist>
     </para>
 
@@ -2692,6 +2838,16 @@
     </para>
 </section>
 
+<section id='ref-classes-python3native'>
+    <title><filename>python3native.bbclass</filename></title>
+
+    <para>
+        The <filename>python3native</filename> class supports using the
+        native version of Python 3 built by the build system rather than
+        support of the version provided by the build host.
+    </para>
+</section>
+
 <section id='ref-classes-pythonnative'>
     <title><filename>pythonnative.bbclass</filename></title>
 
@@ -2773,6 +2929,16 @@
     </para>
 </section>
 
+<section id='ref-classes-recipe_sanity'>
+    <title><filename>recipe_sanity.bbclass</filename></title>
+
+    <para>
+        The <filename>recipe_sanity</filename> class checks for the presence
+        of any host system recipe prerequisites that might affect the
+        build (e.g. variables that are set or software that is present).
+    </para>
+</section>
+
 <section id='ref-classes-relocatable'>
     <title><filename>relocatable.bbclass</filename></title>
 
@@ -2871,6 +3037,11 @@
                 The <filename>rootfs_ipk</filename> class, which supports
                 creation of root filesystems for images built using
                 <filename>.ipk</filename> packages.</para></listitem>
+            <listitem><para>
+                The <filename>rootfsdebugfiles</filename> class, which installs
+                additional files found on the build host directly into the
+                root filesystem.
+                </para></listitem>
         </itemizedlist>
     </para>
 
@@ -2948,6 +3119,15 @@
     </para>
 </section>
 
+<section id='ref-classes-sign_rpm'>
+    <title><filename>sign_rpm.bbclass</filename></title>
+
+    <para>
+        The <filename>sign_rpm</filename> class supports generating signed
+        RPM packages.
+    </para>
+</section>
+
 <section id='ref-classes-sip'>
     <title><filename>sip.bbclass</filename></title>
 
@@ -3181,28 +3361,40 @@
     </para>
 </section>
 
-<section id='ref-classes-testimage'>
-    <title><filename>testimage.bbclass</filename></title>
+<section id='ref-classes-testimage*'>
+    <title><filename>testimage*.bbclass</filename></title>
 
     <para>
-        The <filename>testimage</filename> class supports running automated
-        tests against images using QEMU and on actual hardware.
-        The class handles loading the tests and starting the image.
+        The <filename>testimage*</filename> classes support running
+        automated tests against images using QEMU and on actual hardware.
+        The classes handle loading the tests and starting the image.
+        To use the classes, you need to perform steps to set up the
+        environment.
     </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
+        Each test is written in Python and makes use of the
         <filename>unittest</filename> module.
     </para>
 
     <para>
+        The <filename>testimage.bbclass</filename> runs tests on an image
+        when called using the following:
+        <literallayout class='monospaced'>
+     $ bitbake -c testimage <replaceable>image</replaceable>
+        </literallayout>
+        The <filename>testimage-auto</filename> class runs tests on an image
+        after the image is constructed (i.e.
+        <link linkend='var-TEST_IMAGE'><filename>TEST_IMAGE</filename></link>
+        must be set to "1").
+    </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.
+        section in the Yocto Project Development Manual.
     </para>
 </section>
 
@@ -3385,24 +3577,29 @@
 </section>
 
 <section id='ref-classes-useradd'>
-    <title><filename>useradd.bbclass</filename></title>
+    <title><filename>useradd*.bbclass</filename></title>
 
     <para>
-        The <filename>useradd</filename> class supports the addition of users
+        The <filename>useradd*</filename> classes support the addition of users
         or groups for usage by the package on the target.
         For example, if you have packages that contain system services that
-        should be run under their own user or group, you can use this class to
-        enable creation of the user or group.
+        should be run under their own user or group, you can use these classes
+        to enable creation of the user or group.
         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> recipe for more
-        information on how to use this class.
+        information on how to use these classes.
     </para>
 
     <para>
-        The <filename>useradd</filename> class supports the
+        The <filename>useradd_base</filename> class provides basic
+        functionality for user or groups settings.
+    </para>
+
+    <para>
+        The <filename>useradd*</filename> classes support the
         <link linkend='var-USERADD_PACKAGES'><filename>USERADD_PACKAGES</filename></link>,
         <link linkend='var-USERADD_PARAM'><filename>USERADD_PARAM</filename></link>,
         <link linkend='var-GROUPADD_PARAM'><filename>GROUPADD_PARAM</filename></link>,
@@ -3410,10 +3607,6 @@
         <link linkend='var-GROUPMEMS_PARAM'><filename>GROUPMEMS_PARAM</filename></link>
         variables.
     </para>
-</section>
-
-<section id='ref-classes-useradd-staticids'>
-    <title><filename>useradd-staticids.bbclass</filename></title>
 
     <para>
         The <filename>useradd-staticids</filename> class supports the addition
@@ -3457,7 +3650,8 @@
     </para>
 
     <note><title>Notes</title>
-        You do not use this class directly.
+        You do not use the <filename>useradd-staticids</filename>
+        class directly.
         You either enable or disable the class by setting the
         <filename>USERADDEXTENSION</filename> variable.
         If you enable or disable the class in a configured system,
diff --git a/documentation/ref-manual/ref-manual.xml b/documentation/ref-manual/ref-manual.xml
index 0b4eddf..a296b9b 100644
--- a/documentation/ref-manual/ref-manual.xml
+++ b/documentation/ref-manual/ref-manual.xml
@@ -93,9 +93,9 @@
                 <revremark>Released with the Yocto Project 1.8 Release.</revremark>
             </revision>
             <revision>
-                <revnumber>1.9</revnumber>
+                <revnumber>2.0</revnumber>
                 <date>October 2015</date>
-                <revremark>Released with the Yocto Project 1.9 Release.</revremark>
+                <revremark>Released with the Yocto Project 2.0 Release.</revremark>
             </revision>
         </revhistory>
 
diff --git a/documentation/ref-manual/ref-tasks.xml b/documentation/ref-manual/ref-tasks.xml
index 59b4d96..21403c0 100644
--- a/documentation/ref-manual/ref-tasks.xml
+++ b/documentation/ref-manual/ref-tasks.xml
@@ -619,6 +619,15 @@
         </para>
     </section>
 
+    <section id='ref-tasks-kernel_metadata'>
+        <title><filename>do_kernel_metadata</filename></title>
+
+        <para>
+            Collects kernel metadata for a
+            <filename>linux-yocto</filename> style kernel.
+        </para>
+    </section>
+
     <section id='ref-tasks-menuconfig'>
         <title><filename>do_menuconfig</filename></title>
 
@@ -638,6 +647,14 @@
         </para>
     </section>
 
+    <section id='ref-tasks-shared_workdir'>
+        <title><filename>do_shared_workdir</filename></title>
+
+        <para>
+            Creates the shared working directory for the kernel.
+        </para>
+    </section>
+
     <section id='ref-tasks-sizecheck'>
         <title><filename>do_sizecheck</filename></title>
 
diff --git a/documentation/ref-manual/ref-variables.xml b/documentation/ref-manual/ref-variables.xml
index 4c4fc22..0b2c426 100644
--- a/documentation/ref-manual/ref-variables.xml
+++ b/documentation/ref-manual/ref-variables.xml
@@ -3533,6 +3533,45 @@
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-EXCLUDE_FROM_SHLIBS'><glossterm>EXCLUDE_FROM_SHLIBS</glossterm>
+            <info>
+                EXCLUDE_FROM_SHLIBS[doc] = "Causes the OpenEmbedded build system's shared libraries resolver to exclude an entire package when scanning for shared libraries."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    Triggers the OpenEmbedded build system's shared libraries
+                    resolver to exclude an entire package when scanning for
+                    shared libraries.
+                    <note>
+                        The shared libraries resolver's functionality results
+                        in part from the internal function
+                        <filename>package_do_shlibs</filename>, which is part of
+                        the
+                        <link linkend='ref-tasks-package'><filename>do_package</filename></link>
+                        task.
+                        You should be aware that the shared libraries resolver
+                        might implicitly define some dependencies between
+                        packages.
+                    </note>
+                    The <filename>EXCLUDE_FROM_SHLIBS</filename> variable is
+                    similar to the
+                    <link linkend='var-PRIVATE_LIBS'><filename>PRIVATE_LIBS</filename></link>
+                    variable, which excludes a package's particular libraries
+                    only and not the whole package.
+                </para>
+
+                <para>
+                    Use the
+                    <filename>EXCLUDE_FROM_SHLIBS</filename> variable by
+                    setting it to "1" for a particular package:
+                    <literallayout class='monospaced'>
+     EXCLUDE_FROM_SHLIBS = "1"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-EXCLUDE_FROM_WORLD'><glossterm>EXCLUDE_FROM_WORLD</glossterm>
             <info>
                 EXCLUDE_FROM_WORLD[doc] = "Directs BitBake to exclude a recipe from world builds (i.e. bitbake world)."
@@ -5532,6 +5571,9 @@
                     within the function, you can use
                     <filename>${IMAGE_ROOTFS}</filename>, which points to
                     the directory that becomes the root filesystem image.
+                    See the
+                    <link linkend='var-IMAGE_ROOTFS'><filename>IMAGE_ROOTFS</filename></link>
+                    variable for more information.
                 </para>
             </glossdef>
         </glossentry>
@@ -5557,6 +5599,9 @@
                     within the function, you can use
                     <filename>${IMAGE_ROOTFS}</filename>, which points to
                     the directory that becomes the root filesystem image.
+                    See the
+                    <link linkend='var-IMAGE_ROOTFS'><filename>IMAGE_ROOTFS</filename></link>
+                    variable for more information.
                 </para>
             </glossdef>
         </glossentry>
@@ -5723,32 +5768,45 @@
                     Specifies the complete list of supported image types
                     by default:
                     <literallayout class='monospaced'>
-     jffs2
-     jffs2.sum
-     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.lz4
      cpio.lzma
+     cpio.xz
+     cramfs
+     elf
+     ext2
+     ext2.bz2
+     ext2.gz
+     ext2.lzma
+     ext3
+     ext3.gz
+     ext4
+     ext4.gz
+     hdddirect
+     hddimg
+     iso
+     jffs2
+     jffs2.sum
+     multiubi
+     qcow2
+     squashfs
+     squashfs-lzo
+     squashfs-xz
+     tar
+     tar.bz2
+     tar.gz
+     tar.lz4
+     tar.xz
+     ubi
+     ubifs
      vdi
      vmdk
-     elf
+     wic
+     wic.bz2
+     wic.gz
+     wic.lzma
                     </literallayout>
                 </para>
 
@@ -6409,6 +6467,21 @@
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-KERNEL_ALT_IMAGETYPE'><glossterm>KERNEL_ALT_IMAGETYPE</glossterm>
+            <info>
+                KERNEL_ALT_IMAGETYPE[doc] = "Specifies an alternate kernel image type for creation."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    Specifies an alternate kernel image type for creation in
+                    addition to the kernel image type specified using the
+                    <link linkend='var-KERNEL_IMAGETYPE'><filename>KERNEL_IMAGETYPE</filename></link>
+                    variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-KERNEL_CLASSES'><glossterm>KERNEL_CLASSES</glossterm>
             <info>
                 KERNEL_CLASSES[doc] = "A list of classes defining kernel image types that kernel class should inherit."
@@ -6430,6 +6503,34 @@
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-KERNEL_DEVICETREE'><glossterm>KERNEL_DEVICETREE</glossterm>
+            <info>
+                KERNEL_DEVICETREE[doc] = "Specifies the name of the generated Linux kernel device tree (i.e. the <filename>.dtb</filename>) file."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    Specifies the name of the generated Linux kernel device tree
+                    (i.e. the <filename>.dtb</filename>) file.
+                    <note>
+                        Legacy support exists for specifying the full path
+                        to the device tree.
+                        However, providing just the <filename>.dtb</filename>
+                        file is preferred.
+                    </note>
+                    In order to use this variable, you must have the include
+                    files in your kernel recipe:
+                    <literallayout class='monospaced'>
+     require recipes-kernel/linux/linux-dtb.inc
+                    </literallayout>
+                    or
+                    <literallayout class='monospaced'>
+     require recipes-kernel/linux/linux-yocto.inc
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-KERNEL_EXTRA_ARGS'><glossterm>KERNEL_EXTRA_ARGS</glossterm>
             <info>
                 KERNEL_EXTRA_ARGS[doc] = "Specifies additional make command-line arguments the OpenEmbedded build system passes on when compiling the kernel."
@@ -6559,6 +6660,12 @@
                     when building the kernel and is passed to <filename>make</filename> as the target to
                     build.
                 </para>
+
+                <para>
+                    If you want to build an alternate kernel image type, use the
+                    <link linkend='var-KERNEL_ALT_IMAGETYPE'><filename>KERNEL_ALT_IMAGETYPE</filename></link>
+                    variable.
+                </para>
             </glossdef>
         </glossentry>
 
@@ -6697,6 +6804,46 @@
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-KERNEL_VERSION'><glossterm>KERNEL_VERSION</glossterm>
+            <info>
+                KERNEL_VERSION[doc] = "Specifies the version of the kernel as extracted from version.h or utsrelease.h within the kernel sources."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    Specifies the version of the kernel as extracted from
+                    <filename>version.h</filename> or
+                    <filename>utsrelease.h</filename> within the kernel sources.
+                    Effects of setting this variable do not take affect until
+                    the kernel has been configured.
+                    Consequently, attempting to refer to this variable in
+                    contexts prior to configuration will not work.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-KERNELDEPMODDEPEND'><glossterm>KERNELDEPMODDEPEND</glossterm>
+            <info>
+                KERNELDEPMODDEPEND[doc] = "Specifies whether or not to use the data referenced through the PKGDATA_DIR directory."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    Specifies whether the data referenced through
+                    <link linkend='var-PKGDATA_DIR'><filename>PKGDATA_DIR</filename></link>
+                    is needed or not.
+                    The <filename>KERNELDEPMODDEPEND</filename> does not
+                    control whether or not that data exists,
+                    but simply whether or not it is used.
+                    If you do not need to use the data, set the
+                    <filename>KERNELDEPMODDEPEND</filename> variable in your
+                    <filename>initramfs</filename> recipe.
+                    Setting the variable there when the data is not needed
+                    avoids a potential dependency loop.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-KFEATURE_DESCRIPTION'><glossterm>KFEATURE_DESCRIPTION</glossterm>
             <info>
                 KFEATURE_DESCRIPTION[doc] = "Provides a short description of a configuration fragment. You use this variable in the .scc file that describes a configuration fragment file."
@@ -7376,6 +7523,16 @@
                     <literallayout class='monospaced'>
      MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-module-ab123"
                     </literallayout>
+                    <note>
+                        In this example, the
+                        <filename>kernel-module-ab123</filename> recipe
+                        needs to explicitly set its
+                        <link linkend='var-PACKAGES'><filename>PACKAGES</filename></link>
+                        variable to ensure that BitBake does not use the
+                        kernel recipe's
+                        <link linkend='var-PACKAGES_DYNAMIC'><filename>PACKAGES_DYNAMIC</filename></link>
+                        variable to satisfy the dependency.
+                    </note>
                 </para>
 
                 <para>
@@ -8311,6 +8468,32 @@
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-PACKAGE_EXCLUDE_COMPLEMENTARY'><glossterm>PACKAGE_EXCLUDE_COMPLEMENTARY</glossterm>
+            <info>
+                PACKAGE_EXCLUDE_COMPLEMENTARY[doc] = "Prevents specific packages from being installed when you are installing complementary packages."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    Prevents specific packages from being installed when
+                    you are installing complementary packages.
+                </para>
+
+                <para>
+                    You might find that you want to prevent installing certain
+                    packages when you are installing complementary packages.
+                    For example, if you are using
+                    <link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>
+                    to install <filename>dev-pkgs</filename>, you might not want
+                    to install all packages from a particular multilib.
+                    If you find yourself in this situation, you can use the
+                    <filename>PACKAGE_EXCLUDE_COMPLEMENTARY</filename> variable
+                    to specify regular expressions to match the packages you
+                    want to exclude.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-PACKAGE_EXCLUDE'><glossterm>PACKAGE_EXCLUDE</glossterm>
             <info>
                 PACKAGE_EXCLUDE[doc] = "Packages to exclude from the installation. If a listed package is required, an error is generated."
@@ -8377,6 +8560,144 @@
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-PACKAGE_FEED_ARCHS'><glossterm>PACKAGE_FEED_ARCHS</glossterm>
+            <info>
+                PACKAGE_FEED_ARCHS[doc] = "Specifies user-defined package architectures when constructing package feed URIs."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    Specifies the package architectures used as part of the
+                    package feed URIs during the build.
+                    The <filename>PACKAGE_FEED_ARCHS</filename> variable is
+                    appended to the final package feed URI, which is constructed
+                    using the
+                    <link linkend='var-PACKAGE_FEED_URIS'><filename>PACKAGE_FEED_URIS</filename></link>
+                    and
+                    <link linkend='var-PACKAGE_FEED_BASE_PATHS'><filename>PACKAGE_FEED_BASE_PATHS</filename></link>
+                    variables.
+                </para>
+
+                <para>
+                    Consider the following example where the
+                    <filename>PACKAGE_FEED_URIS</filename>,
+                    <filename>PACKAGE_FEED_BASE_PATHS</filename>, and
+                    <filename>PACKAGE_FEED_ARCHS</filename> variables are
+                    defined in your <filename>local.conf</filename> file:
+                    <literallayout class='monospaced'>
+     PACKAGE_FEED_URIS = "https://example.com/packagerepos/release \
+                          https://example.com/packagerepos/updates"
+     PACKAGE_FEED_BASE_PATHS = "rpm rpm-dev"
+     PACKAGE_FEED_ARCHS = "all core2-64"
+                    </literallayout>
+                    Given these settings, the resulting package feeds are
+                    as follows:
+                    <literallayout class='monospaced'>
+     https://example.com/packagerepos/release/rpm/all
+     https://example.com/packagerepos/release/rpm/core2-64
+     https://example.com/packagerepos/release/rpm-dev/all
+     https://example.com/packagerepos/release/rpm-dev/core2-64
+     https://example.com/packagerepos/updates/rpm/all
+     https://example.com/packagerepos/updates/rpm/core2-64
+     https://example.com/packagerepos/updates/rpm-dev/all
+     https://example.com/packagerepos/updates/rpm-dev/core2-64
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PACKAGE_FEED_BASE_PATHS'><glossterm>PACKAGE_FEED_BASE_PATHS</glossterm>
+            <info>
+                PACKAGE_FEED_BASE_PATHS[doc] = "Specifies base path used when constructing package feed URIs."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    Specifies the base path used when constructing package feed
+                    URIs.
+                    The <filename>PACKAGE_FEED_BASE_PATHS</filename> variable
+                    makes up the middle portion of a package feed URI used
+                    by the OpenEmbedded build system.
+                    The base path lies between the
+                    <link linkend='var-PACKAGE_FEED_URIS'><filename>PACKAGE_FEED_URIS</filename></link>
+                    and
+                    <link linkend='var-PACKAGE_FEED_ARCHS'><filename>PACKAGE_FEED_ARCHS</filename></link>
+                    variables.
+                </para>
+
+                <para>
+                    Consider the following example where the
+                    <filename>PACKAGE_FEED_URIS</filename>,
+                    <filename>PACKAGE_FEED_BASE_PATHS</filename>, and
+                    <filename>PACKAGE_FEED_ARCHS</filename> variables are
+                    defined in your <filename>local.conf</filename> file:
+                    <literallayout class='monospaced'>
+     PACKAGE_FEED_URIS = "https://example.com/packagerepos/release \
+                          https://example.com/packagerepos/updates"
+     PACKAGE_FEED_BASE_PATHS = "rpm rpm-dev"
+     PACKAGE_FEED_ARCHS = "all core2-64"
+                    </literallayout>
+                    Given these settings, the resulting package feeds are
+                    as follows:
+                    <literallayout class='monospaced'>
+     https://example.com/packagerepos/release/rpm/all
+     https://example.com/packagerepos/release/rpm/core2-64
+     https://example.com/packagerepos/release/rpm-dev/all
+     https://example.com/packagerepos/release/rpm-dev/core2-64
+     https://example.com/packagerepos/updates/rpm/all
+     https://example.com/packagerepos/updates/rpm/core2-64
+     https://example.com/packagerepos/updates/rpm-dev/all
+     https://example.com/packagerepos/updates/rpm-dev/core2-64
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PACKAGE_FEED_URIS'><glossterm>PACKAGE_FEED_URIS</glossterm>
+            <info>
+                PACKAGE_FEED_URIS[doc] = "Specifies the front portion of the package feed URI used by the OpenEmbedded build system."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    Specifies the front portion of the package feed URI
+                    used by the OpenEmbedded build system.
+                    Each final package feed URI is comprised of
+                    <filename>PACKAGE_FEED_URIS</filename>,
+                    <link linkend='var-PACKAGE_FEED_BASE_PATHS'><filename>PACKAGE_FEED_BASE_PATHS</filename></link>,
+                    and
+                    <link linkend='var-PACKAGE_FEED_ARCHS'><filename>PACKAGE_FEED_ARCHS</filename></link>
+                    variables.
+                </para>
+
+                <para>
+                    Consider the following example where the
+                    <filename>PACKAGE_FEED_URIS</filename>,
+                    <filename>PACKAGE_FEED_BASE_PATHS</filename>, and
+                    <filename>PACKAGE_FEED_ARCHS</filename> variables are
+                    defined in your <filename>local.conf</filename> file:
+                    <literallayout class='monospaced'>
+     PACKAGE_FEED_URIS = "https://example.com/packagerepos/release \
+                          https://example.com/packagerepos/updates"
+     PACKAGE_FEED_BASE_PATHS = "rpm rpm-dev"
+     PACKAGE_FEED_ARCHS = "all core2-64"
+                    </literallayout>
+                    Given these settings, the resulting package feeds are
+                    as follows:
+                    <literallayout class='monospaced'>
+     https://example.com/packagerepos/release/rpm/all
+     https://example.com/packagerepos/release/rpm/core2-64
+     https://example.com/packagerepos/release/rpm-dev/all
+     https://example.com/packagerepos/release/rpm-dev/core2-64
+     https://example.com/packagerepos/updates/rpm/all
+     https://example.com/packagerepos/updates/rpm/core2-64
+     https://example.com/packagerepos/updates/rpm-dev/all
+     https://example.com/packagerepos/updates/rpm-dev/core2-64
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-PACKAGE_GROUP'><glossterm>PACKAGE_GROUP</glossterm>
             <info>
                 PACKAGE_GROUP[doc] = "Defines one or more packages to include in an image when a specific item is included in IMAGE_FEATURES."
@@ -10865,6 +11186,34 @@
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-SKIP_FILEDEPS'><glossterm>SKIP_FILEDEPS</glossterm>
+            <info>
+                SKIP_FILEDEPS[doc] = "Enables you to remove all files from
+                the "Provides" section of an RPM package."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    Enables removal of all files from the "Provides" section of
+                    an RPM package.
+                    Removal of these files is required for packages containing
+                    prebuilt binaries and libraries such as
+                    <filename>libstdc++</filename> and
+                    <filename>glibc</filename>.
+                </para>
+
+                <para>
+                    To enable file removal, set the variable to "1" in your
+                    <filename>conf/local.conf</filename> configuration file
+                    in your:
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+                    <literallayout class='monospaced'>
+     SKIP_FILEDEPS = "1"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-SOC_FAMILY'><glossterm>SOC_FAMILY</glossterm>
             <info>
                 SOC_FAMILY[doc] = "Groups together machines based upon the same family of SOC (System On Chip). You typically set this variable in a common .inc file that you include in the configuration files of all the machines."
@@ -11052,7 +11401,14 @@
                 </para>
 
                 <para>
-                    The following list explains the available URI protocols:
+                    The following list explains the available URI protocols.
+                    URI protocols are highly dependent on particular BitBake
+                    Fetcher submodules.
+                    Depending on the fetcher BitBake uses, various URL
+                    parameters are employed.
+                    For specifics on the supported Fetchers, see the
+                    "<ulink url='&YOCTO_DOCS_BB_URL;#bb-fetchers'>Fetchers</ulink>"
+                    section in the BitBake User Manual.
                     <itemizedlist>
                         <listitem><para><emphasis><filename>file://</filename> -</emphasis>
                             Fetches files, which are usually files shipped with
@@ -11180,11 +11536,25 @@
                         <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>destsuffix</filename> -</emphasis> Places the file
+                            (or extracts its contents) into the specified
+                            subdirectory of <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>
+                            when the Git fetcher is used.
+                            </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.
+                            subdirectory of <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>
+                            when the local (<filename>file://</filename>)
+                            fetcher is used.
+                            </para></listitem>
+                        <listitem><para><emphasis><filename>localdir</filename> -</emphasis> Places the file
+                            (or extracts its contents) into the specified
+                            subdirectory of <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>
+                            when the CVS fetcher is used.
+                            </para></listitem>
+                        <listitem><para><emphasis><filename>subpath</filename> -</emphasis>
+                            Limits the checkout to a specific subpath of the
+                            tree when using the Git fetcher is used.
                             </para></listitem>
                         <listitem><para><emphasis><filename>name</filename> -</emphasis> Specifies a
                             name to be used for association with <filename>SRC_URI</filename> checksums
@@ -11636,6 +12006,25 @@
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-STAGING_KERNEL_BUILDDIR'><glossterm>STAGING_KERNEL_BUILDDIR</glossterm>
+            <info>
+                STAGING_KERNEL_BUILDDIR[doc] = "Points to the directory containing the kernel build artifacts."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    Points to the directory containing the kernel build
+                    artifacts.
+                    Recipes building software that needs to access kernel
+                    build artifacts
+                    (e.g. <filename>systemtap-uprobes</filename>) can look in
+                    the directory specified with the
+                    <filename>STAGING_KERNEL_BUILDDIR</filename> variable to
+                    find these artifacts after the kernel has been built.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-STAGING_KERNEL_DIR'><glossterm>STAGING_KERNEL_DIR</glossterm>
             <info>
                 STAGING_KERNEL_DIR[doc] = "The directory with kernel headers that are required to build out-of-tree modules."
@@ -12569,7 +12958,7 @@
                     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>"
+                    "<link linkend='ref-classes-testimage*'><filename>testimage*.bbclass</filename></link>"
                     section.
                 </para>
             </glossdef>
@@ -13948,7 +14337,7 @@
                         <filename>uid</filename> and <filename>gid</filename>
                         values causes the OpenEmbedded build system to employ
                         the
-                        <link linkend='ref-classes-useradd-staticids'><filename>useradd-staticids</filename></link>
+                        <link linkend='ref-classes-useradd'><filename>useradd-staticids</filename></link>
                         class.
                     </note>
                 </para>