diff --git a/documentation/Makefile b/documentation/Makefile
index 9197a40..99adea2 100644
--- a/documentation/Makefile
+++ b/documentation/Makefile
@@ -333,7 +333,7 @@
 TARFILES = toaster-manual.html toaster-manual-style.css \
 	   figures/toaster-title.png figures/simple-configuration.png \
 	   figures/hosted-service.png
-MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf
+MANUALS = $(DOC)/$(DOC).html
 FIGURES = figures
 STYLESHEET = $(DOC)/*.css
 endif
diff --git a/documentation/adt-manual/adt-manual.xml b/documentation/adt-manual/adt-manual.xml
index 6ce62c9..67b330a 100644
--- a/documentation/adt-manual/adt-manual.xml
+++ b/documentation/adt-manual/adt-manual.xml
@@ -87,9 +87,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/adt-manual/adt-package.xml b/documentation/adt-manual/adt-package.xml
index f3ffa06..68eee9b 100644
--- a/documentation/adt-manual/adt-package.xml
+++ b/documentation/adt-manual/adt-package.xml
@@ -27,7 +27,7 @@
                 information about OPKG.</para></listitem>
             <listitem><para><emphasis>RPM:</emphasis> A more widely known PMS intended for GNU/Linux
                 distributions.
-                This PMS works with files packaged in an <filename>.rms</filename> format.
+                This PMS works with files packaged in an <filename>.rpm</filename> format.
                 The build system currently installs through this PMS by default.
                 See <ulink url='http://en.wikipedia.org/wiki/RPM_Package_Manager'></ulink>
                 for more information about RPM.</para></listitem>
diff --git a/documentation/adt-manual/adt-prepare.xml b/documentation/adt-manual/adt-prepare.xml
index 01f569f..65df1d0 100644
--- a/documentation/adt-manual/adt-prepare.xml
+++ b/documentation/adt-manual/adt-prepare.xml
@@ -364,6 +364,10 @@
                     Comments within the <filename>local.conf</filename> file
                     list the values you can use for the
                     <filename>MACHINE</filename> variable.
+                    If you do not change the <filename>MACHINE</filename>
+                    variable, the OpenEmbedded build system uses
+                    <filename>qemux86</filename> as the default target
+                    machine when building the cross-toolchain.
                     <note>
                         You can populate the Build Directory with the
                         cross-toolchains for more than a single architecture.
@@ -371,6 +375,17 @@
                         variable in the <filename>local.conf</filename> file and
                         re-run the <filename>bitbake</filename> command.
                     </note></para></listitem>
+                <listitem><para><emphasis>Make Sure Your Layers are Enabled:</emphasis>
+                    Examine the <filename>conf/bblayers.conf</filename> file
+                    and make sure that you have enabled all the compatible
+                    layers for your target machine.
+                    The OpenEmbedded build system needs to be aware of each
+                    layer you want included when building images and
+                    cross-toolchains.
+                    For information on how to enable a layer, see the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#enabling-your-layer'>Enabling Your Layer</ulink>"
+                    section in the Yocto Project Development Manual.
+                    </para></listitem>
                 <listitem><para><emphasis>Generate the Cross-Toolchain:</emphasis>
                     Run <filename>bitbake meta-ide-support</filename> to
                     complete the cross-toolchain generation.
diff --git a/documentation/bsp-guide/bsp-guide.xml b/documentation/bsp-guide/bsp-guide.xml
index 5477ca8..d9bcc3f 100644
--- a/documentation/bsp-guide/bsp-guide.xml
+++ b/documentation/bsp-guide/bsp-guide.xml
@@ -99,9 +99,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>
 
@@ -113,7 +113,7 @@
     <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-nc-sa/2.0/uk/">Creative Commons Attribution-Non-Commercial-Share Alike 2.0 UK: England &amp; Wales</ulink> as published by Creative Commons.
+        the terms of the <ulink type="http" url="http://creativecommons.org/licenses/by-nc-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
diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml b/documentation/dev-manual/dev-manual-common-tasks.xml
index e927a89..f0836e8 100644
--- a/documentation/dev-manual/dev-manual-common-tasks.xml
+++ b/documentation/dev-manual/dev-manual-common-tasks.xml
@@ -2249,6 +2249,19 @@
                 Typically, setting these options is accomplished by running a
                 configure script with some options, or by modifying a build
                 configuration file.
+                <note>
+                    As of Yocto Project Release 7.1, some of the core recipes
+                    that package binary configuration scripts now disable the
+                    scripts due to the scripts previously requiring error-prone
+                    path substitution.
+                    The OpenEmbedded build system uses
+                    <filename>pkg-config</filename> now, which is much more
+                    robust.
+                    You can find a list of the <filename>*-config</filename>
+                    scripts that are disabled list in the
+                    "<ulink url='&YOCTO_DOCS_REF_URL;#migration-1.7-binary-configuration-scripts-disabled'>Binary Configuration Scripts Disabled</ulink>"
+                    section in the Yocto Project Reference Manual.
+                </note>
             </para>
 
             <para>
@@ -2364,7 +2377,16 @@
             <para>
                 However, if the compile step fails, you need to diagnose the
                 failure.
-                Here are some common issues that cause failures:
+                Here are some common issues that cause failures.
+                <note>
+                    For cases where improper paths are detected for
+                    configuration files or for when libraries/headers cannot
+                    be found, be sure you are using the more robust
+                    <filename>pkg-config</filename>.
+                    See the note in section
+                    "<link linkend='new-recipe-configuring-the-recipe'>Configuring the Recipe</link>"
+                    for additional information.
+                </note>
                 <itemizedlist>
                     <listitem><para><emphasis>Parallel build failures:</emphasis>
                         These failures manifest themselves as intermittent
@@ -2708,23 +2730,20 @@
                         is configured, it might be important to mark the
                         packages produced as being specific to a particular
                         machine, or to mark them as not being specific to
-                        a particular machine or architecture at all.
-                        By default, packages produced for the target are
-                        marked as being specific to the architecture of the
-                        target machine because that is usually the desired
-                        result.
-                        However, if the recipe configures the software to be
-                        built specific to the target machine (e.g. the
+                        a particular machine or architecture at all.</para>
+                        <para>By default, packages apply to any machine with the
+                        same architecture as the target machine.
+                        When a recipe produces packages that are
+                        machine-specific (e.g. the
                         <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
                         value is passed into the configure script or a patch
-                        is applied only for a particular machine), then you
-                        should mark the packages produced as being
-                        machine-specific by adding the following to the
+                        is applied only for a particular machine), you should
+                        mark them as such by adding the following to the
                         recipe:
                         <literallayout class='monospaced'>
      PACKAGE_ARCH = "${MACHINE_ARCH}"
-                        </literallayout>
-                        On the other hand, if the recipe produces packages
+                        </literallayout></para>
+                        <para>On the other hand, if the recipe produces packages
                         that do not contain anything specific to the target
                         machine or architecture at all (e.g. recipes
                         that simply package script files or configuration
@@ -3554,7 +3573,7 @@
      require conf/multilib.conf
      MULTILIBS = "multilib:lib32"
      DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
-     IMAGE_INSTALL = "lib32-connman"
+     IMAGE_INSTALL_append = " lib32-glib-2.0"
                     </literallayout>
                     This example enables an
                     additional library named <filename>lib32</filename> alongside the
@@ -3565,7 +3584,7 @@
                 </para>
 
                 <para>
-                    The example then includes <filename>lib32-connman</filename>
+                    The example then includes <filename>lib32-glib-2.0</filename>
                     in all the images, which illustrates one method of including a
                     multiple library dependency.
                     You can use a normal image build to include this dependency,
@@ -3575,7 +3594,7 @@
                     </literallayout>
                     You can also build Multilib packages specifically with a command like this:
                     <literallayout class='monospaced'>
-     $ bitbake lib32-connman
+     $ bitbake lib32-glib-2.0
                     </literallayout>
                 </para>
             </section>
@@ -4307,18 +4326,18 @@
 	            A source plugin is created as a subclass of
 	            <filename>SourcePlugin</filename>.
                 The plugin file containing it is added to
-	            <filename>scripts/lib/mic/plugins/source/</filename> to
+	            <filename>scripts/lib/wic/plugins/source/</filename> to
 	            make the plugin implementation available to the
 	            <filename>wic</filename> implementation.
                 For more information, see
-	            <filename>scripts/lib/mic/pluginbase.py</filename>.
+	            <filename>scripts/lib/wic/pluginbase.py</filename>.
             </para>
 
             <para>
 	            Source plugins can also be implemented and added by
 	            external layers.
                 As such, any plugins found in a
-	            <filename>scripts/lib/mic/plugins/source/</filename>
+	            <filename>scripts/lib/wic/plugins/source/</filename>
 	            directory in an external layer are also made
 	            available.
             </para>
@@ -4539,9 +4558,17 @@
                             option or the equivalent rootfs derived from the
 			                <filename>-e</filename> command-line
 			                option.
-                            Exactly what those contents and
-			                filesystem type end up being are dependent
-			                on the given plugin implementation.
+                            Exactly what those contents and filesystem type end
+                            up being are dependent on the given plugin
+                            implementation.
+                            </para>
+                            <para>If you do not use the
+                            <filename>--source</filename> option, the
+                            <filename>wic</filename> command creates an empty
+                            partition.
+                            Consequently, you must use the
+                            <filename>--size</filename> option to specify the
+                            size of the empty partition.
                             </para></listitem>
                         <listitem><para><emphasis><filename>--ondisk</filename> or <filename>--ondrive</filename>:</emphasis>
                             Forces the partition to be created on a particular
@@ -4585,6 +4612,49 @@
                             This option is a <filename>wic</filename>-specific
                             option that says to start a partition on an
                             x KBytes boundary.</para></listitem>
+                        <listitem><para><emphasis><filename>--no-table</filename>:</emphasis>
+                            This option is a <filename>wic</filename>-specific
+                            option.
+                            Using the option reserves space for the partition
+                            and causes it to become populated.
+                            However, the partition is not added to the
+                            partition table.
+                            </para></listitem>
+                        <listitem><para><emphasis><filename>--extra-space</filename>:</emphasis>
+                            This option is a <filename>wic</filename>-specific
+                            option that adds extra space after the space
+                            filled by the content of the partition.
+                            The final size can go beyond the size specified
+                            by the <filename>--size</filename> option.
+                            The default value is 10 Mbytes.
+                            </para></listitem>
+                        <listitem><para><emphasis><filename>--overhead-factor</filename>:</emphasis>
+                            This option is a <filename>wic</filename>-specific
+                            option that multiplies the size of the partition by
+                            the option's value.
+                            You must supply a value greater than or equal to
+                            "1".
+                            The default value is "1.3".
+                            </para></listitem>
+                        <listitem><para><emphasis><filename>--part-type</filename>:</emphasis>
+                            This option is a <filename>wic</filename>-specific
+                            option that specifies the partition type globally
+                            unique identifier (GUID) for GPT partitions.
+                            You can find the list of partition type GUIDs
+                            at
+                            <ulink url='http://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs'></ulink>.
+                            </para></listitem>
+                        <listitem><para><emphasis><filename>--use-uuid</filename>:</emphasis>
+                            This option is a <filename>wic</filename>-specific
+                            option that causes <filename>wic</filename> to
+                            generate a random GUID for the partition.
+                            The generated identifier is used in the bootloader
+                            configuration to specify the root partition.
+                            </para></listitem>
+                        <listitem><para><emphasis><filename>--uuid</filename>:</emphasis>
+                            This option is a <filename>wic</filename>-specific
+                            option that specifies the partition UUID.
+                            </para></listitem>
                     </itemizedlist>
                 </para>
             </section>
@@ -8166,6 +8236,29 @@
                             must accept incoming connections from 192.168.7.0/24,
                             which is the default IP range used for tap devices
                             by <filename>runqemu</filename>.</para></listitem>
+                        <listitem><para><emphasis>Be sure your host has the
+                            correct packages installed:</emphasis>
+                            Depending your host's distribution, you need
+                            to have the following packages installed:
+                            <itemizedlist>
+                                <listitem><para>Ubuntu and Debian:
+                                    <filename>sysstat</filename> and
+                                    <filename>iproute2</filename>
+                                    </para></listitem>
+                                <listitem><para>OpenSUSE:
+                                    <filename>sysstat</filename> and
+                                    <filename>iproute2</filename>
+                                    </para></listitem>
+                                <listitem><para>Fedora:
+                                    <filename>sysstat</filename> and
+                                    <filename>iproute</filename>
+                                    </para></listitem>
+                                <listitem><para>CentOS:
+                                    <filename>sysstat</filename> and
+                                    <filename>iproute</filename>
+                                    </para></listitem>
+                            </itemizedlist>
+                        </para></listitem>
                     </itemizedlist>
                 </para>
 
@@ -8563,7 +8656,7 @@
                         </literallayout></para></listitem>
                     <listitem><para><emphasis>Manually running tests:</emphasis>
                         To manually run the tests, first globally inherit the
-                        <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-testimage'><filename>testimage</filename></ulink>
+                        <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-testimage*'><filename>testimage</filename></ulink>
                         class by editing your <filename>local.conf</filename>
                         file:
                         <literallayout class='monospaced'>
diff --git a/documentation/dev-manual/dev-manual-model.xml b/documentation/dev-manual/dev-manual-model.xml
index 6e0ded2..6e42c7b 100644
--- a/documentation/dev-manual/dev-manual-model.xml
+++ b/documentation/dev-manual/dev-manual-model.xml
@@ -939,14 +939,14 @@
                                 For example, if you are using Luna, do the
                                 following:
                                 <literallayout class='monospaced'>
-     $ git checkout luna/yocto-1.8
+     $ git checkout luna/yocto-&DISTRO;
                                 </literallayout>
                                 This puts you in a detached HEAD state, which
                                 is fine since you are only going to be building
                                 and not developing.
                                 <note>
                                     If you are building kepler, checkout the
-                                    <filename>kepler/yocto-1.8</filename>
+                                    <filename>kepler/yocto-&DISTRO;</filename>
                                     branch.
                                 </note>
                                 </para></listitem>
@@ -975,13 +975,13 @@
                                 Be sure to provide the tag name, documentation
                                 branch, and a release name.
                                 Here is an example that uses the
-                                <filename>luna/yocto-1.8</filename> tag, the
+                                <filename>luna/yocto-&DISTRO;</filename> tag, the
                                 <filename>master</filename> documentation
                                 branch, and
                                 <filename>&DISTRO_NAME;</filename> for the
                                 release name:
                                 <literallayout class='monospaced'>
-     $ ECLIPSE_HOME=/home/scottrif/eclipse-poky/scripts/eclipse ./build.sh luna/yocto-1.8 master &DISTRO_NAME; 2>&amp;1 | tee -a build.log
+     $ ECLIPSE_HOME=/home/scottrif/eclipse-poky/scripts/eclipse ./build.sh luna/yocto-&DISTRO; master &DISTRO_NAME; 2>&amp;1 | tee -a build.log
                                 </literallayout>
                                 After running the script, the file
                                 <filename>org.yocto.sdk-</filename><replaceable>release</replaceable><filename>-</filename><replaceable>date</replaceable><filename>-archive.zip</filename>
@@ -1340,6 +1340,40 @@
                 "Project" menu.
                 The console should update and you can note the cross-compiler
                 you are using.
+                <note>
+                    When building "Yocto Project ADT Autotools" projects, the Eclipse
+                    IDE might display error messages for Functions/Symbols/Types
+                    that cannot be "resolved", even when the related include file
+                    is listed at the project navigator and when the project is
+                    able to build.
+                    For these cases only, it is recommended to add a new linked
+                    folder to the appropriate sysroot.
+                    Use these steps to add the linked folder:
+                    <orderedlist>
+                        <listitem><para>
+                            Select the project.
+                            </para></listitem>
+                        <listitem><para>
+                            Select "Folder" from the
+                            <filename>File > New</filename> menu.
+                            </para></listitem>
+                        <listitem><para>
+                            In the "New Folder" Dialog, select "Link to alternate
+                            location (linked folder)".
+                            </para></listitem>
+                        <listitem><para>
+                            Click "Browse" to navigate to the include folder inside
+                            the same sysroot location selected in the Yocto Project
+                            configuration preferences.
+                            </para></listitem>
+                        <listitem><para>
+                            Click "OK".
+                            </para></listitem>
+                        <listitem><para>
+                            Click "Finish" to save the linked folder.
+                            </para></listitem>
+                    </orderedlist>
+                </note>
             </para>
         </section>
 
@@ -2183,7 +2217,7 @@
                 </literallayout>
                 <note>
                     For complete syntax, use the
-                    <filename>devtool update-recipe --help</filename> command.
+                    <filename>devtool build --help</filename> command.
                 </note>
                 Building your software using <filename>devtool build</filename>
                 is identical to using BitBake to build the software.
diff --git a/documentation/dev-manual/dev-manual-qemu.xml b/documentation/dev-manual/dev-manual-qemu.xml
index ccc915f..903028f 100644
--- a/documentation/dev-manual/dev-manual-qemu.xml
+++ b/documentation/dev-manual/dev-manual-qemu.xml
@@ -197,14 +197,14 @@
                     but also is not as easy to use or comprehensive
                     as the default.
                     </para></listitem>
-                <listitem><para><filename>kvm</filename>:
+                <listitem><para id='kvm-cond'><filename>kvm</filename>:
                     Enables KVM when running "qemux86" or "qemux86-64"
                     QEMU architectures.
                     For KVM to work, all the following conditions must be met:
                     <itemizedlist>
                         <listitem><para>
                             Your <replaceable>MACHINE</replaceable> must be either
-                            "qemux86" or "qemux86-64".
+qemux86" or "qemux86-64".
                             </para></listitem>
                         <listitem><para>
                             Your build host has to have the KVM modules
@@ -212,13 +212,25 @@
                             <filename>/dev/kvm</filename>.
                             </para></listitem>
                         <listitem><para>
-                            Your build host has to have virtio net device, which
-                            are <filename>/dev/vhost-net</filename>.
-                            </para></listitem>
-                        <listitem><para>
                             The  build host <filename>/dev/kvm</filename>
                             directory has to be both writable and readable.
                             </para></listitem>
+                    </itemizedlist>
+                    </para></listitem>
+                <listitem><para><filename>kvm-vhost</filename>:
+                    Enables KVM with VHOST support when running "qemux86" or "qemux86-64"
+                    QEMU architectures.
+                    For KVM with VHOST to work, the following conditions must
+                    be met:
+                    <itemizedlist>
+                        <listitem><para>
+                            <link linkend='kvm-cond'>kvm</link> option
+                            conditions must be met.
+                            </para></listitem>
+                        <listitem><para>
+                            Your build host has to have virtio net device, which
+                            are <filename>/dev/vhost-net</filename>.
+                            </para></listitem>
                         <listitem><para>
                             The build host <filename>/dev/vhost-net</filename>
                             directory has to be either readable or writable
diff --git a/documentation/dev-manual/dev-manual.xml b/documentation/dev-manual/dev-manual.xml
index 608d3a9..3ddd01f 100644
--- a/documentation/dev-manual/dev-manual.xml
+++ b/documentation/dev-manual/dev-manual.xml
@@ -26,7 +26,7 @@
                 <affiliation>
                     <orgname>Intel Corporation</orgname>
                 </affiliation>
-                <email>scott.m.rifenbark@intel.com</email>
+                <email>srifenbark@gmail.com</email>
             </author>
         </authorgroup>
 
@@ -77,9 +77,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/kernel-dev/kernel-dev-common.xml b/documentation/kernel-dev/kernel-dev-common.xml
index 27c82ce..ab7f80f 100644
--- a/documentation/kernel-dev/kernel-dev-common.xml
+++ b/documentation/kernel-dev/kernel-dev-common.xml
@@ -389,6 +389,10 @@
                 You can use the entire <filename>.config</filename> file as the
                 <filename>defconfig</filename> file as described in the
                 "<link linkend='changing-the-configuration'>Changing the Configuration</link>" section.
+                For more information on the <filename>.config</filename> file,
+                see the
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#using-menuconfig'>Using <filename>menuconfig</filename></ulink>"
+                section in the Yocto Project Development Manual.
             </para>
 
             <para>
diff --git a/documentation/kernel-dev/kernel-dev.xml b/documentation/kernel-dev/kernel-dev.xml
index e3df2cc..38850fa 100644
--- a/documentation/kernel-dev/kernel-dev.xml
+++ b/documentation/kernel-dev/kernel-dev.xml
@@ -62,9 +62,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/mega-manual/figures/add-variable.png b/documentation/mega-manual/figures/add-variable.png
new file mode 100644
index 0000000..6bdcca7
--- /dev/null
+++ b/documentation/mega-manual/figures/add-variable.png
Binary files differ
diff --git a/documentation/mega-manual/figures/bash-oecore.png b/documentation/mega-manual/figures/bash-oecore.png
new file mode 100644
index 0000000..801a5d9
--- /dev/null
+++ b/documentation/mega-manual/figures/bash-oecore.png
Binary files differ
diff --git a/documentation/mega-manual/figures/set-variable.png b/documentation/mega-manual/figures/set-variable.png
new file mode 100644
index 0000000..d36b527
--- /dev/null
+++ b/documentation/mega-manual/figures/set-variable.png
Binary files differ
diff --git a/documentation/mega-manual/figures/variable-added.png b/documentation/mega-manual/figures/variable-added.png
new file mode 100644
index 0000000..518f25f
--- /dev/null
+++ b/documentation/mega-manual/figures/variable-added.png
Binary files differ
diff --git a/documentation/mega-manual/mega-manual.xml b/documentation/mega-manual/mega-manual.xml
index a75ebf1..5c1faec 100644
--- a/documentation/mega-manual/mega-manual.xml
+++ b/documentation/mega-manual/mega-manual.xml
@@ -35,7 +35,7 @@
                 <affiliation>
                     <orgname>Intel Corporation</orgname>
                 </affiliation>
-                <email>scott.m.rifenbark@intel.com</email>
+                <email>srifenbark@gmail.com</email>
             </author>
         </authorgroup>
 
@@ -46,9 +46,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/poky.ent b/documentation/poky.ent
index 07c4f6d..33d52c0 100644
--- a/documentation/poky.ent
+++ b/documentation/poky.ent
@@ -1,7 +1,7 @@
-<!ENTITY DISTRO "1.9">
-<!ENTITY DISTRO_COMPRESSED "19">
-<!ENTITY DISTRO_NAME "tbd">
-<!ENTITY YOCTO_DOC_VERSION "1.9">
+<!ENTITY DISTRO "2.0">
+<!ENTITY DISTRO_COMPRESSED "20">
+<!ENTITY DISTRO_NAME "jethro">
+<!ENTITY YOCTO_DOC_VERSION "2.0">
 <!ENTITY POKYVERSION "14.0.0">
 <!ENTITY POKYVERSION_COMPRESSED "1400">
 <!ENTITY YOCTO_POKY "poky-&DISTRO_NAME;-&POKYVERSION;">
@@ -67,4 +67,5 @@
 <!ENTITY OPENSUSE_HOST_PACKAGES_ESSENTIAL "python gcc gcc-c++ git chrpath make wget python-xml \
      diffstat makeinfo python-curses patch socat">
 <!ENTITY CENTOS_HOST_PACKAGES_ESSENTIAL "gawk make wget tar bzip2 gzip python unzip perl patch \
-     diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath socat">
+     diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath socat \
+     perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue">
diff --git a/documentation/profile-manual/profile-manual.xml b/documentation/profile-manual/profile-manual.xml
index 38620df..7f9b2c4 100644
--- a/documentation/profile-manual/profile-manual.xml
+++ b/documentation/profile-manual/profile-manual.xml
@@ -62,9 +62,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/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>
diff --git a/documentation/toaster-manual/figures/add-variable.png b/documentation/toaster-manual/figures/add-variable.png
new file mode 100644
index 0000000..6bdcca7
--- /dev/null
+++ b/documentation/toaster-manual/figures/add-variable.png
Binary files differ
diff --git a/documentation/toaster-manual/figures/bash-oecore.png b/documentation/toaster-manual/figures/bash-oecore.png
new file mode 100644
index 0000000..801a5d9
--- /dev/null
+++ b/documentation/toaster-manual/figures/bash-oecore.png
Binary files differ
diff --git a/documentation/toaster-manual/figures/set-variable.png b/documentation/toaster-manual/figures/set-variable.png
new file mode 100644
index 0000000..d36b527
--- /dev/null
+++ b/documentation/toaster-manual/figures/set-variable.png
Binary files differ
diff --git a/documentation/toaster-manual/figures/variable-added.png b/documentation/toaster-manual/figures/variable-added.png
new file mode 100644
index 0000000..518f25f
--- /dev/null
+++ b/documentation/toaster-manual/figures/variable-added.png
Binary files differ
diff --git a/documentation/toaster-manual/toaster-manual-intro.xml b/documentation/toaster-manual/toaster-manual-intro.xml
index ad9e08b..9f4c38b 100644
--- a/documentation/toaster-manual/toaster-manual-intro.xml
+++ b/documentation/toaster-manual/toaster-manual-intro.xml
@@ -39,7 +39,7 @@
         <para>
             You can use Toaster in Analysis Mode or Build Mode:
             <itemizedlist>
-                <listitem><para><emphasis>Analysis Mode:</emphasis>
+                <listitem><para id='toaster-analysis-mode'><emphasis>Analysis Mode:</emphasis>
                     In Analysis Mode, you can record builds and statistics.
                     In this Mode, you directly access the
                     <filename>bitbake</filename> command, which you then use to
@@ -82,7 +82,7 @@
                             </para></listitem>
                     </itemizedlist>
                     </para></listitem>
-                <listitem><para><emphasis>Build Mode:</emphasis>
+                <listitem><para id='toaster-build-mode'><emphasis>Build Mode:</emphasis>
                     In Build Mode, Toaster handles the build configuration,
                     scheduling and execution.
                     In this mode, all your interaction with the build system
diff --git a/documentation/toaster-manual/toaster-manual-reference.xml b/documentation/toaster-manual/toaster-manual-reference.xml
index 0c9401f..faca4ca 100644
--- a/documentation/toaster-manual/toaster-manual-reference.xml
+++ b/documentation/toaster-manual/toaster-manual-reference.xml
@@ -214,48 +214,48 @@
                         In the file, you will find a section for layer sources
                         such as the following:
                         <literallayout class='monospaced'>
-     "layersources": [
-         {
-             "name": "Local Yocto Project",
-             "sourcetype": "local",
-             "apiurl": "../../",
-             "branches": ["HEAD", "master", "fido", "dizzy"],
-             "layers": [
-                 {
-                     "name": "openembedded-core",
-                     "local_path": "meta",
-                     "vcs_url": "remote:origin",
-                     "dirpath": "meta"
-                 },
-                 {
-                     "name": "meta-yocto",
-                     "local_path": "meta-yocto",
-                     "vcs_url": "remote:origin",
-                     "dirpath": "meta-yocto"
-                 },
-                 {
-                     "name": "meta-yocto-bsp",
-                     "local_path": "meta-yocto-bsp",
-                     "vcs_url": "remote:origin",
-                     "dirpath": "meta-yocto-bsp"
-                 }
+    "layersources": [
+        {
+            "name": "Local Yocto Project",
+            "sourcetype": "local",
+            "apiurl": "../../",
+            "branches": ["HEAD" ],
+            "layers": [
+                {
+                    "name": "openembedded-core",
+                    "local_path": "meta",
+                    "vcs_url": "remote:origin",
+                    "dirpath": "meta"
+                },
+                {
+                    "name": "meta-yocto",
+                    "local_path": "meta-yocto",
+                    "vcs_url": "remote:origin",
+                    "dirpath": "meta-yocto"
+                },
+                {
+                    "name": "meta-yocto-bsp",
+                    "local_path": "meta-yocto-bsp",
+                    "vcs_url": "remote:origin",
+                    "dirpath": "meta-yocto-bsp"
+                }
 
-             ]
-         },
-         {
-             "name": "OpenEmbedded",
-             "sourcetype": "layerindex",
-             "apiurl": "http://layers.openembedded.org/layerindex/api/",
-             "branches": ["master", "fido", "dizzy"]
-         },
-         {
-             "name": "Imported layers",
-             "sourcetype": "imported",
-             "apiurl": "",
-             "branches": ["master", "fido", "dizzy", "HEAD"]
+            ]
+        },
+        {
+            "name": "OpenEmbedded",
+            "sourcetype": "layerindex",
+            "apiurl": "http://layers.openembedded.org/layerindex/api/",
+            "branches": ["master", "jethro" ,"fido"]
+        },
+        {
+            "name": "Imported layers",
+            "sourcetype": "imported",
+            "apiurl": "",
+            "branches": ["master", "jethro","fido", "HEAD"]
 
-         }
-     ],
+        }
+    ],
                         </literallayout>
                         You should add your own layer source to this section by
                         following the same format used for the "OpenEmbedded"
@@ -268,7 +268,7 @@
                         indicate which branches from your layer source you want
                         to make available through Toaster.
                         For example, the OpenEmbedded layer source makes
-                        available only its "master", "fido", and "dizzy"
+                        available only its "master", "fido", and "jethro"
                         branches.
                     </para>
 
@@ -373,12 +373,12 @@
                 As shipped, Toaster is configured to work with the following
                 releases:
                 <itemizedlist>
-                    <listitem><para><emphasis>Yocto Project 1.7 "Dizzy" or OpenEmbedded "Dizzy":</emphasis>
+                    <listitem><para><emphasis>Yocto Project 2.0 "Jethro" or OpenEmbedded "Jethro":</emphasis>
                         This release causes your Toaster projects to
-                        build against the head of the dizzy branch at
-                        <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/log/?h=dizzy'></ulink>
+                        build against the head of the jethro branch at
+                        <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/log/?h=jethro'></ulink>
                         or
-                        <ulink url='http://git.openembedded.org/openembedded-core/commit/?h=dizzy'></ulink>.
+                        <ulink url='http://git.openembedded.org/openembedded-core/commit/?h=jethro'></ulink>.
                         </para></listitem>
                     <listitem><para><emphasis>Yocto Project 1.8 "Fido" or OpenEmbedded "Fido":</emphasis>
                         This release causes your Toaster projects to
@@ -489,7 +489,7 @@
                         The branch for the layer source
                         (<filename>branch</filename>) used with the release.
                         For example, for the OpenEmbedded layer source, the
-                        "master", "fido", and "dizzy" branches are available.
+                        "master", "fido", and "jethro" branches are available.
                         </para></listitem>
                     <listitem><para><emphasis>Default Layers:</emphasis>
                         The set of default layers
@@ -538,7 +538,7 @@
              "branch": "master",
              "defaultlayers": [ "openembedded-core" ],
              "layersourcepriority": { "Imported layers": 99, "Local OpenEmbedded" : 10, "OpenEmbedded" :  0 },
-             "helptext": "Toaster will run your builds using the OpenEmbedded master branch, where active development takes place. This is not a stable branch, so your builds might not work as expected."
+             "helptext": "Toaster will run your builds using the tip of the &lt;a href=\"http://git.yoctoproject.org/cgit/cgit.cgi/poky/log/\"&gt;Yocto Project master branch&lt;/a&gt;, where active development takes place. This is not a stable branch, so your builds might not work as expected."
          }
      ]
                 </literallayout>
@@ -662,7 +662,6 @@
          "IMAGE_FSTYPES": "ext3 jffs2 tar.bz2",
          "IMAGE_INSTALL_append": "",
          "PACKAGE_CLASSES": "package_rpm",
-         "SDKMACHINE"   : "x86_64"
      },
                     </literallayout>
                 </para>
@@ -710,48 +709,48 @@
                 <para>
                     Here is the default <filename>layersources</filename> area:
                     <literallayout class='monospaced'>
-     "layersources": [
-         {
-             "name": "Local Yocto Project",
-             "sourcetype": "local",
-             "apiurl": "../../",
-             "branches": ["HEAD", "master", "fido", "dizzy"],
-             "layers": [
-                 {
-                     "name": "openembedded-core",
-                     "local_path": "meta",
-                     "vcs_url": "remote:origin",
-                     "dirpath": "meta"
-                 },
-                 {
-                     "name": "meta-yocto",
-                     "local_path": "meta-yocto",
-                     "vcs_url": "remote:origin",
-                     "dirpath": "meta-yocto"
-                 },
-                 {
-                     "name": "meta-yocto-bsp",
-                     "local_path": "meta-yocto-bsp",
-                     "vcs_url": "remote:origin",
-                     "dirpath": "meta-yocto-bsp"
-                 }
+    "layersources": [
+        {
+            "name": "Local Yocto Project",
+            "sourcetype": "local",
+            "apiurl": "../../",
+            "branches": ["HEAD" ],
+            "layers": [
+                {
+                    "name": "openembedded-core",
+                    "local_path": "meta",
+                    "vcs_url": "remote:origin",
+                    "dirpath": "meta"
+                },
+                {
+                    "name": "meta-yocto",
+                    "local_path": "meta-yocto",
+                    "vcs_url": "remote:origin",
+                    "dirpath": "meta-yocto"
+                },
+                {
+                    "name": "meta-yocto-bsp",
+                    "local_path": "meta-yocto-bsp",
+                    "vcs_url": "remote:origin",
+                    "dirpath": "meta-yocto-bsp"
+                }
 
-             ]
-         },
-         {
-             "name": "OpenEmbedded",
-             "sourcetype": "layerindex",
-             "apiurl": "http://layers.openembedded.org/layerindex/api/",
-             "branches": ["master", "fido", "dizzy"]
-         },
-         {
-             "name": "Imported layers",
-             "sourcetype": "imported",
-             "apiurl": "",
-             "branches": ["master", "fido", "dizzy", "HEAD"]
+            ]
+        },
+        {
+            "name": "OpenEmbedded",
+            "sourcetype": "layerindex",
+            "apiurl": "http://layers.openembedded.org/layerindex/api/",
+            "branches": ["master", "jethro" ,"fido"]
+        },
+        {
+            "name": "Imported layers",
+            "sourcetype": "imported",
+            "apiurl": "",
+            "branches": ["master", "jethro","fido", "HEAD"]
 
-         }
-     ],
+        }
+    ],
                     </literallayout>
                 </para>
             </section>
@@ -763,7 +762,7 @@
                     This area of the JSON file defines the version of
                     BitBake Toaster uses.
                     As shipped, Toaster is configured to recognize four
-                    versions of BitBake: master, fido, dizzy, and HEAD.
+                    versions of BitBake: master, fido, jethro, and HEAD.
                     <note>
                         HEAD is a special option that builds whatever is
                         available on disk, without checking out any remote
@@ -781,18 +780,18 @@
              "branch": "master",
              "dirpath": "bitbake"
          },
+        {
+             "name": "jethro",
+             "giturl": "remote:origin",
+             "branch": "jethro",
+             "dirpath": "bitbake"
+         },
          {
              "name": "fido",
              "giturl": "remote:origin",
              "branch": "fido",
             "dirpath": "bitbake"
         },
-        {
-             "name": "dizzy",
-             "giturl": "remote:origin",
-             "branch": "dizzy",
-             "dirpath": "bitbake"
-         },
          {
              "name": "HEAD",
              "giturl": "remote:origin",
@@ -848,6 +847,15 @@
              "helptext": "Toaster will run your builds using the tip of the &lt;a href=\"http://git.yoctoproject.org/cgit/cgit.cgi/poky/log/\"&gt;Yocto Project master branch&lt;/a&gt;, where active development takes place. This is not a stable branch, so your builds might not work as expected."
          },
          {
+             "name": "jethro",
+             "description": "Yocto Project 2.0 Jethro",
+             "bitbake": "jethro",
+             "branch": "jethro",
+             "defaultlayers": [ "openembedded-core", "meta-yocto", "meta-yocto-bsp"],
+             "layersourcepriority": { "Imported layers": 99, "Local Yocto Project" : 10, "OpenEmbedded" :  0 },
+             "helptext": "Toaster will run your builds with the tip of the &lt;a href=\"http://git.yoctoproject.org/cgit/cgit.cgi/poky/log/?h=jethro\"&gt;Yocto Project 2.0 \"Jethro\"&lt;/a&gt; branch."
+         },
+         {
              "name": "fido",
              "description": "Yocto Project 1.8 Fido",
              "bitbake": "fido",
@@ -857,15 +865,6 @@
              "helptext": "Toaster will run your builds with the tip of the &lt;a href=\"http://git.yoctoproject.org/cgit/cgit.cgi/poky/log/?h=fido\"&gt;Yocto Project 1.8 \"Fido\"&lt;/a&gt; branch."
          },
          {
-             "name": "dizzy",
-             "description": "Yocto Project 1.7 Dizzy",
-             "bitbake": "dizzy",
-             "branch": "dizzy",
-             "defaultlayers": [ "openembedded-core", "meta-yocto", "meta-yocto-bsp"],
-             "layersourcepriority": { "Imported layers": 99, "Local Yocto Project" : 10, "OpenEmbedded" :  0 },
-             "helptext": "Toaster will run your builds with the tip of the &lt;a href=\"http://git.yoctoproject.org/cgit/cgit.cgi/poky/log/?h=dizzy\"&gt;Yocto Project 1.7 \"Dizzy\"&lt;/a&gt; branch."
-         },
-         {
              "name": "local",
              "description": "Local Yocto Project",
              "bitbake": "HEAD",
diff --git a/documentation/toaster-manual/toaster-manual-setup-and-use.xml b/documentation/toaster-manual/toaster-manual-setup-and-use.xml
index 869d249..2693569 100644
--- a/documentation/toaster-manual/toaster-manual-setup-and-use.xml
+++ b/documentation/toaster-manual/toaster-manual-setup-and-use.xml
@@ -6,9 +6,488 @@
 
 <title>Setting Up and Using Toaster</title>
 
-    <section id='using-toaster-in-analysis-mode'>
+    <section id='starting-toaster-for-local-development'>
+        <title>Starting Toaster for Local Development</title>
+
+        <para>
+            Once you have set up the Yocto Project and installed the
+            Toaster system dependencies as described in
+            "<link linkend='toaster-manual-start'>Preparing to Use Toaster</link>",
+            you are ready to start Toaster.
+        </para>
+
+        <para>
+            If you want to configure and start your builds using the
+            Toaster web interface
+            (i.e. "<link linkend='toaster-build-mode'>Build Mode</link>"),
+            navigate to the root of your
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+            (e.g. <filename>poky</filename>):
+            <literallayout class='monospaced'>
+     $ cd poky
+            </literallayout>
+            Next, start Toaster:
+            <literallayout class='monospaced'>
+     $ bitbake/bin/toaster
+            </literallayout>
+            Open your favourite browser and enter the following:
+            <literallayout class='monospaced'>
+     http://127.0.0.1:8000
+            </literallayout>
+            If you would rather configure and start your builds
+            using the command line
+            (i.e. <link linkend='toaster-analysis-mode'>Analysis Mode</link>),
+            you can get Toaster to "listen"
+            to your builds and collect information about them.
+            To do that, navigate to the root of your Source Directory:
+            <literallayout class='monospaced'>
+     $ cd poky
+            </literallayout>
+            Once in that directory, source the build environment script:
+            <literallayout class='monospaced'>
+     $ source oe-init-build-env
+            </literallayout>
+            Next, from the build directory (e.g.
+            <filename>poky/build</filename>), start Toaster using this
+            command:
+            <literallayout class='monospaced'>
+     $ source ../bitbake/bin/toaster
+            </literallayout>
+            You can now run builds normally.
+        </para>
+
+        <para>
+            To see the build information provided by Toaster, open your
+            favorite browser and enter the following:
+            <literallayout class='monospaced'>
+     http://127.0.0.1:8000
+            </literallayout>
+        </para>
+    </section>
+
+    <section id='setting-a-different-port'>
+        <title>Setting a Different Port</title>
+
+        <para>
+            By default, Toaster starts on port 8000.
+            You can use the <filename>WEBPORT</filename> parameter to
+            set a different port.
+            For example, either of the following commands sets the
+            port to "8400":
+            <literallayout class='monospaced'>
+     $ bitbake/bin/toaster webport=8400
+            </literallayout>
+            or
+            <literallayout class='monospaced'>
+     $ source ../bitbake/bin/toaster webport=8400
+            </literallayout>
+        </para>
+    </section>
+
+    <section id='the-directory-for-cloning-layers'>
+        <title>The Directory for Cloning Layers</title>
+
+        <para>
+            If you are running Toaster in
+            <link linkend='toaster-build-mode'>Build Mode</link>,
+            Toaster creates a <filename>_toaster_clones</filename>
+            directory inside your Source Directory
+            (i.e. <filename>poky</filename>).
+            For example, suppose you use this command to start Toaster:
+            <literallayout class='monospaced'>
+     poky/bitbake/bin/toaster
+            </literallayout>
+            In this example, Toaster creates and uses the
+            <filename>poky/_toaster_clones</filename>
+            directory to clone any layers needed for your builds.
+        </para>
+
+        <para>
+            Alternatively, if you would like all of your Toaster related
+            files and directories to be in a particular location other than
+            the default, you can set the <filename>TOASTER_DIR</filename>
+            environment variable, which takes precedence over your current
+            working directory.
+            Setting this environment variable causes Toaster to create and use
+            <filename>$TOASTER_DIR./_toaster_clones</filename>.
+        </para>
+    </section>
+
+    <section id='toaster-the-build-directory'>
+        <title>The Build Directory</title>
+
+        <para>
+            If you are running Toaster in
+            <link linkend='toaster-build-mode'>Build Mode</link>,
+            Toaster creates a build directory within your Source
+            Directory (e.g. <filename>poky</filename>).
+            For example, suppose you use this command to start Toaster:
+            <literallayout class='monospaced'>
+     poky/bitbake/bin/toaster
+            </literallayout>
+            In this example, Toaster creates and uses the
+            <filename>poky/build</filename>
+            directory to execute the builds.
+        </para>
+
+        <para>
+            Alternatively, if you would like all of your Toaster related files
+            and directories to be in a particular location, you can set
+            the <filename>TOASTER_DIR</filename> environment variable,
+            which takes precedence over your current working directory.
+            Setting this environment variable causes Toaster to use
+            <filename>$TOASTER_DIR./build</filename> as the build directory.
+        </para>
+    </section>
+
+    <section id='toaster-creating-a-django-super-user'>
+        <title>Creating a Django Superuser</title>
+
+        <para>
+            Toaster is built on the
+            <ulink url='https://www.djangoproject.com/'>Django framework</ulink>.
+            Django provides an administration interface you can use
+            to edit Toaster configuration parameters.
+        </para>
+
+        <para>
+            To access the Django administration interface, you must
+            create a superuser by following these steps:
+            <orderedlist>
+                <listitem><para>
+                    If you used <filename>virtualenv</filename>, which is
+                    recommended, to set up the Toaster system dependencies,
+                    you need be sure the virtual environment is activated.
+                    To activate this environment, use the following:
+                    <literallayout class='monospaced'>
+     $ source venv/bin/activate
+                    </literallayout>
+                    </para></listitem>
+                <listitem><para>
+                    From the root of your checkout directory, invoke the
+                    following command from <filename>manage.py</filename>:
+                    <literallayout class='monospaced'>
+     $ ./bitbake/lib/toaster/manage.py createsuperuser
+                    </literallayout>
+                    </para></listitem>
+                <listitem><para>
+                    Django prompts you for the username, which you need to
+                    provide.
+                    </para></listitem>
+                <listitem><para>
+                    Django prompts you for an email address, which is
+                    optional.
+                    </para></listitem>
+                <listitem><para>
+                    Django prompts you for a password, which you must provide.
+                    </para></listitem>
+                <listitem><para>
+                    Django prompts you to re-enter your password for verification.
+                    </para></listitem>
+            </orderedlist>
+            After completing these steps, the following confirmation message
+            appears:
+            <literallayout class='monospaced'>
+     Superuser created successfully.
+            </literallayout>
+        </para>
+
+        <para>
+            Creating a superuser allows you to access the Django administration
+            interface through a browser.
+            The URL for this interface is the same as the URL used for the
+            Toaster instance with "/admin" on the end.
+            For example, if you are running Toaster locally, use the
+            following URL:
+            <literallayout class='monospaced'>
+     http://127.0.0.1:8000/admin
+            </literallayout>
+            You can use the Django administration interface to set Toaster
+            configuration parameters such as the build directory, layer sources,
+            default variable values, and BitBake versions.
+        </para>
+    </section>
+
+    <section id='toaster-setting-up-a-production-instance-of-toaster'>
+        <title>Setting Up a Production Instance of Toaster</title>
+
+        <para>
+            You can use a production instance of Toaster to share the
+            Toaster instance with remote users, multiple users, or both.
+            The production instance is also the setup that can cope with
+            heavier loads on the web service.
+            Use the instructions in the following sections to set up
+            Toaster in
+            <link linkend='toaster-build-mode'>Build Mode</link>
+            where builds and projects are run,
+            viewed, and defined through the Toaster web interface.
+        </para>
+
+        <section id='toaster-production-instance-requirements'>
+            <title>Requirements</title>
+
+            <para>
+                Be sure you meet the following requirements:
+                <note>
+                    You must comply with all Apache,
+                    <filename>mod-wsgi</filename>, and Mysql requirements.
+                </note>
+                <itemizedlist>
+                    <listitem><para>
+                        Have all the build requirements as described in
+                        "<link linkend='toaster-setting-up-the-basic-system-requirements'>Setting Up the Basic System Requirements</link>"
+                        chapter.
+                        </para></listitem>
+                    <listitem><para>
+                        Have an Apache webserver.
+                        </para></listitem>
+                    <listitem><para>
+                        Have <filename>mod-wsgi</filename> for the Apache
+                        webserver.
+                        </para></listitem>
+                    <listitem><para>
+                        Use the Mysql database server.
+                        </para></listitem>
+                    <listitem><para>
+                        If you are using Ubuntu 14.04.3, run the following:
+                        <literallayout class='monospaced'>
+     $ sudo apt-get install apache2 libapache2-mod-wsgi mysql-server virtualenv libmysqlclient-dev
+                        </literallayout>
+                        </para></listitem>
+                    <listitem><para>
+                        If you are using Fedora 22 or a RedHat distribution, run
+                        the following:
+                        <literallayout class='monospaced'>
+     $ sudo dnf install httpd mod_wsgi python-virtualenv gcc mysql-devel
+                        </literallayout>
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='toaster-installation-steps'>
+            <title>Installation</title>
+
+            <para>
+                Perform the following steps to install Toaster:
+                <orderedlist>
+                    <listitem><para>
+                        Checkout a copy of <filename>poky</filename>
+                        into the web server directory.
+                        You will be using <filename>/var/www/toaster</filename>:
+                        <literallayout class='monospaced'>
+     $ mkdir -p /var/www/toaster
+     $ cd /var/www/toaster/
+     $ git clone git://git.yoctoproject.org/poky
+     $ git checkout &DISTRO_NAME;
+                        </literallayout>
+                        </para></listitem>
+                    <listitem><para>
+                        Initialize a virtual environment and install Toaster
+                        dependencies.
+                        Using a virtual environment keeps the Python packages
+                        isolated from your system-provided packages:
+                        <literallayout class='monospaced'>
+     $ cd /var/www/toaster/
+     $ virtualenv venv
+     $ source ./venv/bin/activate
+     $ pip install -r ./poky/bitbake/toaster-requirements.txt
+     $ pip install mysql
+     $ pip install MySQL-python
+                        </literallayout>
+                        <note>
+                            Isolating these packages is not required but is
+                            recommended.
+                            Alternatively, you can use your operating system's
+                            package manager to install the packages.
+                        </note>
+                        </para></listitem>
+                    <listitem><para>
+                        Configure Toaster by editing
+                        <filename>/var/www/toaster/poky/bitbake/lib/toaster/toastermain/settings.py</filename>
+                        as follows:
+                        <itemizedlist>
+                            <listitem><para>
+                                Edit the <filename>DATABASE</filename> settings:
+                                <literallayout class='monospaced'>
+     DATABASES = {
+         'default': {
+             'ENGINE': 'django.db.backends.mysql',
+             'NAME': 'toaster_data',
+             'USER': 'toaster',
+             'PASSWORD': 'yourpasswordhere',
+             'HOST': 'localhost',
+             'PORT': '3306',
+        }
+     }
+                                </literallayout>
+                                </para></listitem>
+                            <listitem><para>
+                                Edit the <filename>SECRET_KEY</filename>:
+                                <literallayout class='monospaced'>
+     SECRET_KEY = '<replaceable>your_secret_key</replaceable>'
+                                </literallayout>
+                                </para></listitem>
+                            <listitem><para>
+                                Edit the <filename>STATIC_ROOT</filename>:
+                                <literallayout class='monospaced'>
+     STATIC_ROOT = '/var/www/toaster/static_files/'
+                                </literallayout>
+                                </para></listitem>
+                            <listitem><para>
+                                Enable Build Mode by adding the following
+                                line to <filename>settings.py</filename>:
+                                <literallayout class='monospaced'>
+     BUILD_MODE=True
+                                </literallayout>
+                                </para></listitem>
+                        </itemizedlist>
+                        </para></listitem>
+                    <listitem><para>
+                        Add the database and user to the <filename>mysql</filename>
+                        server defined earlier:
+                        <literallayout class='monospaced'>
+     $ mysql -u root -p
+     mysql> CREATE DATABASE toaster_data;
+     mysql> CREATE USER 'toaster'@'localhost' identified by 'yourpasswordhere';
+     mysql> GRANT all on toaster_data.* to 'toaster'@'localhost';
+     mysql> quit
+                        </literallayout>
+                        </para></listitem>
+                    <listitem><para>
+                        Get Toaster to create the database schema,
+                        default data, and gather the statically-served files:
+                        <literallayout class='monospaced'>
+     $ cd  /var/www/toaster/poky/
+     $ ./bitbake/lib/toaster/manage.py syncdb
+     $ ./bitbake/lib/toaster/manage.py migrate
+     $ TOASTER_DIR=`pwd` TOASTER_CONF=./meta-yocto/conf/toasterconf.json ./bitbake/lib/toaster/manage.py checksettings
+     $ ./bitbake/lib/toaster/manage.py collectstatic
+                        </literallayout>
+                        </para>
+
+                        <para>
+                            For the above set of commands, after moving to the
+                            <filename>poky</filename> directory,
+                            the <filename>syncdb</filename> and <filename>migrate</filename>
+                            commands ensure the database
+                            schema has had changes propagated correctly (i.e.
+                            migrations).
+                        </para>
+
+                        <para>
+                            The next line sets the Toaster root directory
+                            <filename>TOASTER_DIR</filename> and the location of
+                            the Toaster configuration file
+                            <filename>TOASTER_CONF</filename>, which is
+                            relative to the Toaster root directory
+                            <filename>TOASTER_DIR</filename>.
+                            For more information on the Toaster configuration file
+                            <filename>TOASTER_CONF</filename>, see the
+                            <link linkend='toaster-json-files'>JSON Files</link>
+                            section of this manual.
+                        </para>
+
+                        <para>
+                            This line also runs the <filename>checksettings</filename>
+                            command, which configures the location of the Toaster
+                            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build directory</ulink>.
+                            The Toaster root directory <filename>TOASTER_DIR</filename>
+                            determines where the Toaster build directory
+                            is created on the file system.
+                            In the example above,
+                            <filename>TOASTER_DIR</filename> is set as follows:
+                            <literallayout class="monospaced">
+     /var/www/toaster/poky
+                            </literallayout>
+                            This setting causes the Toaster build directory to be:
+                            <literallayout class="monospaced">
+     /var/www/toaster/poky/build
+                            </literallayout>
+                        </para>
+
+                        <para>
+                            Finally, the <filename>collectstatic</filename> command
+                            is a Django framework command that collects all the
+                            statically served files into a designated directory to
+                            be served up by the Apache web server.
+                        </para></listitem>
+                    <listitem><para>
+                        Add an Apache configuration file for Toaster to your Apache web
+                        server's configuration directory.
+                        If you are using Ubuntu or Debian, put the file here:
+                        <literallayout class='monospaced'>
+     /etc/apache2/conf-available/toaster.conf
+                        </literallayout>
+                        If you are using Fedora or RedHat, put it here:
+                        <literallayout class='monospaced'>
+     /etc/httpd/conf.d/toaster.conf
+                        </literallayout>
+                        Following is a sample Apache configuration for Toaster
+                        you can follow:
+                        <literallayout class='monospaced'>
+     Alias /static /var/www/toaster/static_files
+     &lt;Directory /var/www/toaster/static_files&gt;
+             Order allow,deny
+             Allow from all
+             Require all granted
+     &lt;/Directory&gt;
+
+     WSGIDaemonProcess toaster_wsgi python-path=/var/www/toaster/poky/bitbake/lib/toaster:/var/www/toaster/venv/lib/python2.7/site-packages
+
+     WSGIScriptAlias / "/var/www/toaster/poky/bitbake/lib/toaster/toastermain/wsgi.py"
+     &lt;Location /&gt;
+         WSGIProcessGroup toastern_wsgi
+     &lt;/Location&gt;
+                        </literallayout>
+                        If you are using Ubuntu or Debian,
+                        you will need to enable the config and module for Apache:
+                        <literallayout class='monospaced'>
+     $ sudo a2enmod wsgi
+     $ sudo a2enconf toaster
+     $ chmod +x bitbake/lib/toaster/toastermain/wsgi.py
+                        </literallayout>
+                        Finally, restart Apache to make sure all new configuration
+                        is loaded.
+                        For Ubuntu and Debian use:
+                        <literallayout class='monospaced'>
+     $ sudo service apache2 restart
+                        </literallayout>
+                        For Fedora and RedHat use:
+                        <literallayout class='monospaced'>
+     $ sudo service httpd restart
+                        </literallayout>
+                        </para></listitem>
+                    <listitem><para>
+                        Install the build runner service.
+                        This service needs to be running in order to dispatch
+                        builds.
+                        Use this command:
+                        <literallayout class='monospaced'>
+     /var/www/toaster/poky/bitbake/lib/toaster/manage.py runbuilds
+                        </literallayout>
+                        Here is an example:
+                        <literallayout class='monospaced'>
+     #!/bin/sh
+     # toaster run builds dispatcher
+     cd /var/www/toaster/
+     source ./venv/bin/activate
+     ./bitbake/lib/toaster/manage.py runbuilds
+                        </literallayout>
+                        </para></listitem>
+                </orderedlist>
+                You can now open up a browser and start using Toaster.
+            </para>
+        </section>
+    </section>
+
+
+
+
+<!--    <section id='using-toaster-in-analysis-mode'>
         <title>Using Toaster in Analysis Mode</title>
 
+
         <para>
             This section describes how to use Toaster in Analysis Mode
             after setting Toaster up as a local instance or as a hosted
@@ -324,14 +803,14 @@
                     <listitem><para><emphasis>Start the BitBake Server:</emphasis>
                         Start the BitBake server using the following command:
                         <literallayout class='monospaced'>
-     $ bitbake --postread conf/toaster.conf --server-only -t xmlrpc -B localhost:0 &amp;&amp; export BBSERVER=localhost:-1
+     $ bitbake &dash;&dash;postread conf/toaster.conf &dash;&dash;server-only -t xmlrpc -B localhost:0 &amp;&amp; export BBSERVER=localhost:-1
                         </literallayout>
                         </para></listitem>
                     <listitem><para><emphasis>Start the Logging Server:</emphasis>
                         Start the Toaster Logging Interface using the following
                         command:
                         <literallayout class='monospaced'>
-     $ nohup bitbake --observe-only -u toasterui >toaster_ui.log &amp;
+     $ nohup bitbake &dash;&dash;observe-only -u toasterui >toaster_ui.log &amp;
                         </literallayout>
                         <note>
                             No hard-coded ports are used in the BitBake options
@@ -810,6 +1289,7 @@
             </para>
         </section>
     </section>
+-->
 
     <section id='using-the-toaster-web-interface'>
         <title>Using the Toaster Web Interface</title>
@@ -867,58 +1347,119 @@
                     CPU usage, and disk I/O.
                     </para></listitem>
             </itemizedlist>
-            Following are several videos that show how to use the Toaster GUI:
-            <itemizedlist>
-                <listitem><para><emphasis>Build Configuration:</emphasis>
-                    This
-                    <ulink url='https://www.youtube.com/watch?v=qYgDZ8YzV6w'>video</ulink>
-                    overviews and demonstrates build configuration for Toaster.
-                    </para></listitem>
-                <listitem><para><emphasis>Toaster Homepage and Table Controls:</emphasis>
-                    This
-                    <ulink url='https://www.youtube.com/watch?v=QEARDnrR1Xw'>video</ulink>
-                    goes over the Toaster entry page, and provides
-                    an overview of the data manipulation capabilities of
-                    Toaster, which include search, sorting and filtering by
-                    different criteria.
-                    </para></listitem>
-                <listitem><para><emphasis>Build Dashboard:</emphasis>
-                    This
-                    <ulink url='https://www.youtube.com/watch?v=KKqHYcnp2gE'>video</ulink>
-                    shows you the build dashboard, a page providing an
-                    overview of the information available for a selected build.
-                    </para></listitem>
-                <listitem><para><emphasis>Image Information:</emphasis>
-                    This
-                    <ulink url='https://www.youtube.com/watch?v=XqYGFsmA0Rw'>video</ulink>
-                    walks through the information Toaster provides
-                    about images: packages installed and root file system.
-                    </para></listitem>
-                <listitem><para><emphasis>Configuration:</emphasis>
-                    This
-                    <ulink url='https://www.youtube.com/watch?v=UW-j-T2TzIg'>video</ulink>
-                    provides Toaster build configuration information.
-                    </para></listitem>
-                <listitem><para><emphasis>Tasks:</emphasis>
-                    This
-                    <ulink url='https://www.youtube.com/watch?v=D4-9vGSxQtw'>video</ulink>
-                    shows the information Toaster provides about the
-                    tasks run by the build system.
-                    </para></listitem>
-                <listitem><para><emphasis>Recipes and Packages Built:</emphasis>
-                    This
-                    <ulink url='https://www.youtube.com/watch?v=x-6dx4huNnw'>video</ulink>
-                    shows the information Toaster provides about recipes
-                    and packages built.
-                    </para></listitem>
-                <listitem><para><emphasis>Performance Data:</emphasis>
-                    This
-                    <ulink url='https://www.youtube.com/watch?v=qWGMrJoqusQ'>video</ulink>
-                    shows the build performance data provided by
-                    Toaster.
-                    </para></listitem>
-            </itemizedlist>
         </para>
+
+        <section id='web-interface-videos'>
+            <title>Toaster Web Interface Videos</title>
+
+            <para>
+                Following are several videos that show how to use the Toaster GUI:
+                <itemizedlist>
+                    <listitem><para><emphasis>Build Configuration:</emphasis>
+                        This
+                        <ulink url='https://www.youtube.com/watch?v=qYgDZ8YzV6w'>video</ulink>
+                        overviews and demonstrates build configuration for Toaster.
+                        </para></listitem>
+                    <listitem><para><emphasis>Build Custom Layers:</emphasis>
+                        This
+                        <ulink url='https://www.youtube.com/watch?v=QJzaE_XjX5c'>video</ulink>
+                        shows you how to build custom layers that are used with
+                        Toaster.
+                        </para></listitem>
+                    <listitem><para><emphasis>Toaster Homepage and Table Controls:</emphasis>
+                        This
+                        <ulink url='https://www.youtube.com/watch?v=QEARDnrR1Xw'>video</ulink>
+                        goes over the Toaster entry page, and provides
+                        an overview of the data manipulation capabilities of
+                        Toaster, which include search, sorting and filtering by
+                        different criteria.
+                        </para></listitem>
+                    <listitem><para><emphasis>Build Dashboard:</emphasis>
+                        This
+                        <ulink url='https://www.youtube.com/watch?v=KKqHYcnp2gE'>video</ulink>
+                        shows you the build dashboard, a page providing an
+                        overview of the information available for a selected build.
+                        </para></listitem>
+                    <listitem><para><emphasis>Image Information:</emphasis>
+                        This
+                        <ulink url='https://www.youtube.com/watch?v=XqYGFsmA0Rw'>video</ulink>
+                        walks through the information Toaster provides
+                        about images: packages installed and root file system.
+                        </para></listitem>
+                    <listitem><para><emphasis>Configuration:</emphasis>
+                        This
+                        <ulink url='https://www.youtube.com/watch?v=UW-j-T2TzIg'>video</ulink>
+                        provides Toaster build configuration information.
+                        </para></listitem>
+                    <listitem><para><emphasis>Tasks:</emphasis>
+                        This
+                        <ulink url='https://www.youtube.com/watch?v=D4-9vGSxQtw'>video</ulink>
+                        shows the information Toaster provides about the
+                        tasks run by the build system.
+                        </para></listitem>
+                    <listitem><para><emphasis>Recipes and Packages Built:</emphasis>
+                        This
+                        <ulink url='https://www.youtube.com/watch?v=x-6dx4huNnw'>video</ulink>
+                        shows the information Toaster provides about recipes
+                        and packages built.
+                        </para></listitem>
+                    <listitem><para><emphasis>Performance Data:</emphasis>
+                        This
+                        <ulink url='https://www.youtube.com/watch?v=qWGMrJoqusQ'>video</ulink>
+                        shows the build performance data provided by
+                        Toaster.
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='toaster-web-interface-preferred-version'>
+            <title>Building a Specific Recipe Given Multiple Versions</title>
+
+            <para>
+                Occasionally, a layer might provide more than one version of
+                the same recipe.
+                For example, the <filename>openembedded-core</filename> layer
+                provides two versions of the <filename>bash</filename> recipe
+                (i.e. 3.2.48 and 4.3.30-r0) and two versions of the
+                <filename>which</filename> recipe (i.e. 2.21 and 2.18).
+                The following figure shows this exact scenario:
+                <imagedata fileref="figures/bash-oecore.png" align="center" width="9in" depth="6in" />
+            </para>
+
+            <para>
+                By default, the OpenEmbedded build system builds one of the
+                two recipes.
+                For the <filename>bash</filename> case, version 4.3.30-r0 is
+                built by default.
+                Unfortunately, Toaster as it exists, is not able to override
+                the default recipe version.
+                If you would like to build bash 3.2.48, you need to set the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-PREFERRED_VERSION'><filename>PREFERRED_VERSION</filename></ulink>
+                variable.
+                You can do so from Toaster, using the "Add variable" form,
+                which is available in the "BitBake variables" page of the
+                project configuration section as shown in the following screen:
+                <imagedata fileref="figures/add-variable.png" align="center" width="9in" depth="6in" />
+            </para>
+
+            <para>
+                To specify <filename>bash</filename> 3.2.48 as the version to build,
+                enter "PREFERRED_VERSION_bash" in the "Variable" field, and "3.2.48"
+                in the "Value" field.
+                Next, click the "Add variable" button:
+                <imagedata fileref="figures/set-variable.png" align="center" width="9in" depth="6in" />
+            </para>
+
+            <para>
+                After clicking the "Add variable" button, the settings for
+                <filename>PREFERRED_VERSION</filename> are added to the bottom
+                of the BitBake variables list.
+                With these settings, the OpenEmbedded build system builds the
+                desired version of the recipe rather than the default version:
+                <imagedata fileref="figures/variable-added.png" align="center" width="9in" depth="6in" />
+            </para>
+        </section>
     </section>
 
 <!--
diff --git a/documentation/toaster-manual/toaster-manual-start.xml b/documentation/toaster-manual/toaster-manual-start.xml
index fbdb5ec..daefa79 100644
--- a/documentation/toaster-manual/toaster-manual-start.xml
+++ b/documentation/toaster-manual/toaster-manual-start.xml
@@ -15,12 +15,13 @@
         <title>Setting Up the Basic System Requirements</title>
 
         <para>
-            You first need to be sure your build system is set up to run
-            the Yocto Project.
-            See the
-            "<ulink url='&YOCTO_DOCS_QS_URL;#yp-resources'>Setting Up to Use the Yocto Project</ulink>"
-            section in the Yocto Project Quick Start for information on how
-            to set up your system for the Yocto Project.
+            Before you can use Toaster, you need to first set up your
+            build system to run the Yocto Project.
+            To do this, follow the instructions in the
+            "<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Build Host Packages</ulink>"
+            and
+            "<ulink url='&YOCTO_DOCS_QS_URL;#releases'>Yocto Project Release</ulink>"
+            sections in the Yocto Project Quick Start.
         </para>
     </section>
 
@@ -41,16 +42,21 @@
             install-compatible format.
         </para>
 
-        <section id='toaster-optional-virtual-environment'>
-            <title>Optionally Setting Up a Python Virtual Environment</title>
+        <section id='toaster-virtual-environment'>
+            <title>Set Up a Python Virtual Environment</title>
 
             <para>
-                It is highly recommended that you use a Python virtual
-                environment that allows you to maintain a dedicated Python
-                executable and its own set of installed modules.
-                Doing so separates the executable from the Python and modules
-                provided by the operating system and therefore avoids any
-                version conflicts.
+                Set up a Python virtual environment that allows you
+                to maintain a dedicated Python executable and its own
+                set of installed modules.
+                Doing so separates the executable from Python and the
+                modules provided by the operating system.
+                This separation avoids any version conflicts.
+                <note>
+                    Creating a virtual environment is not absolutely
+                    necessary.
+                    However, doing so is highly recommended.
+                </note>
             </para>
 
             <para>
@@ -73,7 +79,7 @@
                         </para></listitem>
                 </orderedlist>
                 <note>
-                    If you do choose to set up a virtual environment in
+                    After setting up a virtual environment in
                     which to run Toaster, you must initialize that
                     virtual environment each time you want to start
                     Toaster.
diff --git a/documentation/toaster-manual/toaster-manual.xml b/documentation/toaster-manual/toaster-manual.xml
index 9dac6d9..59dca8f 100644
--- a/documentation/toaster-manual/toaster-manual.xml
+++ b/documentation/toaster-manual/toaster-manual.xml
@@ -26,7 +26,7 @@
                 <affiliation>
                     <orgname>Intel Corporation</orgname>
                 </affiliation>
-                <email>scott.m.rifenbark@intel.com</email>
+                <email>srifenbark@gmail.com</email>
             </author>
         </authorgroup>
 
@@ -37,9 +37,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/tools/mega-manual.sed b/documentation/tools/mega-manual.sed
index bec40b3..088a99b 100644
--- a/documentation/tools/mega-manual.sed
+++ b/documentation/tools/mega-manual.sed
@@ -2,32 +2,32 @@
 # This style is for manual folders like "yocto-project-qs" and "poky-ref-manual".
 # This is the old way that did it.  Can't do that now that we have "bitbake-user-manual" strings
 # in the mega-manual.
-# s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.9\/[a-z]*-[a-z]*-[a-z]*\/[a-z]*-[a-z]*-[a-z]*.html#/\"link\" href=\"#/g
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.9\/yocto-project-qs\/yocto-project-qs.html#/\"link\" href=\"#/g
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.9\/poky-ref-manual\/poky-ref-manual.html#/\"link\" href=\"#/g
+# s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.0\/[a-z]*-[a-z]*-[a-z]*\/[a-z]*-[a-z]*-[a-z]*.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.0\/yocto-project-qs\/yocto-project-qs.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.0\/poky-ref-manual\/poky-ref-manual.html#/\"link\" href=\"#/g
 
 # Processes all other manuals (<word>-<word> style) except for the BitBake User Manual because
 # it is not included in the mega-manual.
 # This style is for manual folders that use two word, which is the standard now (e.g. "ref-manual").
 # This was the one-liner that worked before we introduced the BitBake User Manual, which is
 # not in the mega-manual.
-# s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.9\/[a-z]*-[a-z]*\/[a-z]*-[a-z]*.html#/\"link\" href=\"#/g
+# s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.0\/[a-z]*-[a-z]*\/[a-z]*-[a-z]*.html#/\"link\" href=\"#/g
 
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.9\/adt-manual\/adt-manual.html#/\"link\" href=\"#/g
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.9\/bsp-guide\/bsp-guide.html#/\"link\" href=\"#/g
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.9\/dev-manual\/dev-manual.html#/\"link\" href=\"#/g
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.9\/kernel-dev\/kernel-dev.html#/\"link\" href=\"#/g
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.9\/profile-manual\/profile-manual.html#/\"link\" href=\"#/g
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.9\/ref-manual\/ref-manual.html#/\"link\" href=\"#/g
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.9\/toaster-manual\/toaster-manual.html#/\"link\" href=\"#/g
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.9\/yocto-project-qs\/yocto-project-qs.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.0\/adt-manual\/adt-manual.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.0\/bsp-guide\/bsp-guide.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.0\/dev-manual\/dev-manual.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.0\/kernel-dev\/kernel-dev.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.0\/profile-manual\/profile-manual.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.0\/ref-manual\/ref-manual.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.0\/toaster-manual\/toaster-manual.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.0\/yocto-project-qs\/yocto-project-qs.html#/\"link\" href=\"#/g
 
 # Process cases where just an external manual is referenced without an id anchor
-s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.9\/yocto-project-qs\/yocto-project-qs.html\" target=\"_top\">Yocto Project Quick Start<\/a>/Yocto Project Quick Start/g
-s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.9\/dev-manual\/dev-manual.html\" target=\"_top\">Yocto Project Development Manual<\/a>/Yocto Project Development Manual/g
-s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.9\/adt-manual\/adt-manual.html\" target=\"_top\">Yocto Project Application Developer's Guide<\/a>/Yocto Project Application Developer's Guide/g
-s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.9\/bsp-guide\/bsp-guide.html\" target=\"_top\">Yocto Project Board Support Package (BSP) Developer's Guide<\/a>/Yocto Project Board Support Package (BSP) Developer's Guide/g
-s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.9\/profile-manual\/profile-manual.html\" target=\"_top\">Yocto Project Profiling and Tracing Manual<\/a>/Yocto Project Profiling and Tracing Manual/g
-s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.9\/kernel-dev\/kernel-dev.html\" target=\"_top\">Yocto Project Linux Kernel Development Manual<\/a>/Yocto Project Linux Kernel Development Manual/g
-s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.9\/ref-manual\/ref-manual.html\" target=\"_top\">Yocto Project Reference Manual<\/a>/Yocto Project Reference Manual/g
-s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.9\/toaster-manual\/toaster-manual.html\" target=\"_top\">Toaster User Manual<\/a>/Toaster User Manual/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.0\/yocto-project-qs\/yocto-project-qs.html\" target=\"_top\">Yocto Project Quick Start<\/a>/Yocto Project Quick Start/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.0\/dev-manual\/dev-manual.html\" target=\"_top\">Yocto Project Development Manual<\/a>/Yocto Project Development Manual/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.0\/adt-manual\/adt-manual.html\" target=\"_top\">Yocto Project Application Developer's Guide<\/a>/Yocto Project Application Developer's Guide/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.0\/bsp-guide\/bsp-guide.html\" target=\"_top\">Yocto Project Board Support Package (BSP) Developer's Guide<\/a>/Yocto Project Board Support Package (BSP) Developer's Guide/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.0\/profile-manual\/profile-manual.html\" target=\"_top\">Yocto Project Profiling and Tracing Manual<\/a>/Yocto Project Profiling and Tracing Manual/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.0\/kernel-dev\/kernel-dev.html\" target=\"_top\">Yocto Project Linux Kernel Development Manual<\/a>/Yocto Project Linux Kernel Development Manual/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.0\/ref-manual\/ref-manual.html\" target=\"_top\">Yocto Project Reference Manual<\/a>/Yocto Project Reference Manual/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.0\/toaster-manual\/toaster-manual.html\" target=\"_top\">Toaster User Manual<\/a>/Toaster User Manual/g
diff --git a/documentation/yocto-project-qs/yocto-project-qs.xml b/documentation/yocto-project-qs/yocto-project-qs.xml
index 5da7314..5315dfe 100644
--- a/documentation/yocto-project-qs/yocto-project-qs.xml
+++ b/documentation/yocto-project-qs/yocto-project-qs.xml
@@ -308,7 +308,7 @@
                         </para></listitem>
                     <listitem><para><emphasis>Fedora</emphasis>
                         <literallayout class='monospaced'>
-     $ sudo yum install &FEDORA_HOST_PACKAGES_ESSENTIAL; SDL-devel xterm
+     $ sudo dnf install &FEDORA_HOST_PACKAGES_ESSENTIAL; SDL-devel xterm
                         </literallayout>
                         </para></listitem>
                     <listitem><para><emphasis>OpenSUSE</emphasis>