diff --git a/yocto-poky/documentation/ref-manual/closer-look.xml b/yocto-poky/documentation/ref-manual/closer-look.xml
index 45dcd9b..84ff584 100644
--- a/yocto-poky/documentation/ref-manual/closer-look.xml
+++ b/yocto-poky/documentation/ref-manual/closer-look.xml
@@ -73,7 +73,7 @@
         </para>
 
         <para>
-            <imagedata fileref="figures/user-configuration.png" align="center" width="5.5in" depth="3.5in" />
+            <imagedata fileref="figures/user-configuration.png" align="center" />
         </para>
 
         <para>
@@ -100,7 +100,7 @@
         </para>
 
         <para>
-            The <filename>meta-yocto</filename> layer inside Poky contains
+            The <filename>meta-poky</filename> layer inside Poky contains
             a <filename>conf</filename> directory that has example
             configuration files.
             These example files are used as a basis for creating actual
@@ -158,7 +158,7 @@
             To see the default configurations in a <filename>local.conf</filename>
             file created by the build environment script, see the
             <filename>local.conf.sample</filename> in the
-            <filename>meta-yocto</filename> layer:
+            <filename>meta-poky</filename> layer:
             <itemizedlist>
                 <listitem><para><emphasis>Parallelism Options:</emphasis>
                     Controlled by the
@@ -208,8 +208,10 @@
             The files <filename>site.conf</filename> and
             <filename>auto.conf</filename> are not created by the environment
             initialization script.
-            If you want these configuration files, you must create them
-            yourself:
+            If you want the <filename>site.conf</filename> file, you need to
+            create that yourself.
+            The <filename>auto.conf</filename> file is typically created by
+            an autobuilder:
             <itemizedlist>
                 <listitem><para><emphasis><filename>site.conf</filename>:</emphasis>
                     You can use the <filename>conf/site.conf</filename>
@@ -235,8 +237,7 @@
                     directory's <filename>conf/local.conf</filename> file.
                     </para></listitem>
                 <listitem><para><emphasis><filename>auto.conf</filename>:</emphasis>
-                    This file is not hand-created.
-                    Rather, the file is usually created and written to by
+                    The file is usually created and written to by
                     an autobuilder.
                     The settings put into the file are typically the same as
                     you would find in the <filename>conf/local.conf</filename>
@@ -254,9 +255,24 @@
 
         <para>
             When you launch your build with the
-            <filename>bitbake <replaceable>target</replaceable></filename> command, BitBake
-            sorts out the configurations to ultimately define your build
-            environment.
+            <filename>bitbake <replaceable>target</replaceable></filename>
+            command, BitBake sorts out the configurations to ultimately
+            define your build environment.
+            It is important to understand that the OpenEmbedded build system
+            reads the configuration files in a specific order:
+            <filename>site.conf</filename>, <filename>auto.conf</filename>,
+            and <filename>local.conf</filename>.
+            And, the build system applies the normal assignment statement
+            rules.
+            Because the files are parsed in a specific order, variable
+            assignments for the same variable could be affected.
+            For example, if the <filename>auto.conf</filename> file and
+            the <filename>local.conf</filename> set
+            <replaceable>variable1</replaceable> to different values, because
+            the build system parses <filename>local.conf</filename> after
+            <filename>auto.conf</filename>,
+            <replaceable>variable1</replaceable> is assigned the value from
+            the <filename>local.conf</filename> file.
         </para>
     </section>
 
@@ -992,11 +1008,13 @@
 
             <para>
                 The image generation process consists of several stages and
-                depends on many variables.
+                depends on several tasks and variables.
                 The
                 <link linkend='ref-tasks-rootfs'><filename>do_rootfs</filename></link>
-                task uses these key variables
-                to help create the list of packages to actually install:
+                task creates the root filesystem (file and directory structure)
+                for an image.
+                This task uses several key variables to help create the list
+                of packages to actually install:
                 <itemizedlist>
                     <listitem><para><link linkend='var-IMAGE_INSTALL'><filename>IMAGE_INSTALL</filename></link>:
                         Lists out the base set of packages to install from
@@ -1016,23 +1034,34 @@
                         Determines the language(s) for which additional
                         language support packages are installed.
                         </para></listitem>
+                    <listitem><para><link linkend='var-PACKAGE_INSTALL'><filename>PACKAGE_INSTALL</filename></link>:
+                        The final list of packages passed to the package manager
+                        for installation into the image.
+                        </para></listitem>
                 </itemizedlist>
             </para>
 
             <para>
+                With
+                <link linkend='var-IMAGE_ROOTFS'><filename>IMAGE_ROOTFS</filename></link>
+                pointing to the location of the filesystem under construction and
+                the <filename>PACKAGE_INSTALL</filename> variable providing the
+                final list of packages to install, the root file system is
+                created.
+            </para>
+
+            <para>
                 Package installation is under control of the package manager
                 (e.g. smart/rpm, opkg, or apt/dpkg) regardless of whether or
                 not package management is enabled for the target.
                 At the end of the process, if package management is not
                 enabled for the target, the package manager's data files
                 are deleted from the root filesystem.
-            </para>
-
-            <para>
-                During image generation, the build system attempts to run
-                all post-installation scripts.
-                Any that fail to run on the build host are run on the
-                target when the target system is first booted.
+                As part of the final stage of package installation, postinstall
+                scripts that are part of the packages are run.
+                Any scripts that fail to run
+                on the build host are run on the target when the target system
+                is first booted.
                 If you are using a
                 <ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-read-only-root-filesystem'>read-only root filesystem</ulink>,
                 all the post installation scripts must succeed during the
@@ -1041,24 +1070,17 @@
             </para>
 
             <para>
-                During Optimization, optimizing processes are run across
-                the image.
-                These processes include <filename>mklibs</filename> and
-                <filename>prelink</filename>.
-                The <filename>mklibs</filename> process optimizes the size
-                of the libraries.
-                A <filename>prelink</filename> process optimizes the dynamic
-                linking of shared libraries to reduce start up time of
-                executables.
+                The final stages of the <filename>do_rootfs</filename> task
+                handle post processing.
+                Post processing includes creation of a manifest file and
+                optimizations.
             </para>
 
             <para>
-                Along with writing out the root filesystem image, the
-                <filename>do_rootfs</filename> task creates a manifest file
-                (<filename>.manifest</filename>) in the same directory as
-                the root filesystem image that lists out, line-by-line, the
-                installed packages.
-                This manifest file is useful for the
+                The manifest file (<filename>.manifest</filename>) resides
+                in the same directory as the root filesystem image.
+                This file lists out, line-by-line, the installed packages.
+                The manifest file is useful for the
                 <link linkend='ref-classes-testimage*'><filename>testimage</filename></link>
                 class, for example, to determine whether or not to run
                 specific tests.
@@ -1068,21 +1090,54 @@
             </para>
 
             <para>
-                Part of the image generation process includes compressing the
-                root filesystem image.
-                Compression is accomplished through several optimization
-                routines designed to reduce the overall size of the image.
+                Optimizing processes run across the image include
+                <filename>mklibs</filename>, <filename>prelink</filename>,
+                and any other post-processing commands as defined by the
+                <link linkend='var-ROOTFS_POSTPROCESS_COMMAND'><filename>ROOTFS_POSTPROCESS_COMMAND</filename></link>
+                variable.
+                The <filename>mklibs</filename> process optimizes the size
+                of the libraries, while the
+                <filename>prelink</filename> process optimizes the dynamic
+                linking of shared libraries to reduce start up time of
+                executables.
             </para>
 
             <para>
-                After the root filesystem has been constructed, the image
-                generation process turns everything into an image file or
-                a set of image files.
+                After the root filesystem is built, processing begins on
+                the image through the <filename>do_image</filename> task.
+                The build system runs any pre-processing commands as defined
+                by the
+                <link linkend='var-IMAGE_PREPROCESS_COMMAND'><filename>IMAGE_PREPROCESS_COMMAND</filename></link>
+                variable.
+                This variable specifies a list of functions to call before
+                the OpenEmbedded build system creates the final image output
+                files.
+            </para>
+
+            <para>
+                The <filename>do_image</filename> task dynamically creates
+                other <filename>do_image_*</filename> tasks as needed, which
+                include compressing the root filesystem image to reduce the
+                overall size of the image.
+                The process turns everything into an image file or a set of
+                image files.
                 The formats used for the root filesystem depend on the
                 <link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>
                 variable.
             </para>
 
+            <para>
+                The final task involved in image creation is the
+                <filename>do_image_complete</filename> task.
+                This task completes the image by applying any image
+                post processing as defined through the
+                <link linkend='var-IMAGE_POSTPROCESS_COMMAND'><filename>IMAGE_POSTPROCESS_COMMAND</filename></link>
+                variable.
+                The variable specifies a list of functions to call once the
+                OpenEmbedded build system has created the final image output
+                files.
+            </para>
+
             <note>
                 The entire image generation process is run under Pseudo.
                 Running under Pseudo ensures that the files in the root
@@ -1095,8 +1150,9 @@
 
             <para>
                 The OpenEmbedded build system uses BitBake to generate the
-                Software Development Kit (SDK) installer script:
-                <imagedata fileref="figures/sdk-generation.png" align="center" width="6in" depth="7in" />
+                Software Development Kit (SDK) installer script for both the
+                standard and extensible SDKs:
+                <imagedata fileref="figures/sdk-generation.png" align="center" />
             </para>
 
             <note>
@@ -1108,14 +1164,16 @@
                 cross-development toolchain using the
                 <link linkend='ref-tasks-populate_sdk'><filename>do_populate_sdk</filename></link>
                 task, see the
-                "<ulink url='&YOCTO_DOCS_ADT_URL;#optionally-building-a-toolchain-installer'>Optionally Building a Toolchain Installer</ulink>"
-                section in the Yocto Project Application Developer's Guide.
+                "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-building-an-sdk-installer'>Building an SDK Installer</ulink>"
+                section in the Yocto Project Software Development Kit (SDK)
+                Developer's Guide.
             </note>
 
             <para>
                 Like image generation, the SDK script process consists of
                 several stages and depends on many variables.
-                The <filename>do_populate_sdk</filename> task uses these
+                The <filename>do_populate_sdk</filename> and
+                <filename>do_populate_sdk_ext</filename> tasks use these
                 key variables to help create the list of packages to actually
                 install.
                 For information on the variables listed in the figure, see the
@@ -1124,8 +1182,9 @@
             </para>
 
             <para>
-                The <filename>do_populate_sdk</filename> task handles two
-                parts: a target part and a host part.
+                The <filename>do_populate_sdk</filename> task helps create
+                the standard SDK and handles two parts: a target part and a
+                host part.
                 The target part is the part built for the target hardware and
                 includes libraries and headers.
                 The host part is the part of the SDK that runs on the
@@ -1133,16 +1192,19 @@
             </para>
 
             <para>
-                Once both parts are constructed, the
-                <filename>do_populate_sdk</filename> task performs some cleanup
-                on both parts.
-                After the cleanup, the task creates a cross-development
-                environment setup script and any configuration files that
-                might be needed.
+                The <filename>do_populate_sdk_ext</filename> task helps create
+                the extensible SDK and handles host and target parts
+                differently than its counter part does for the standard SDK.
+                For the extensible SDK, the task encapsulates the build system,
+                which includes everything needed (host and target) for the SDK.
             </para>
 
             <para>
-                The final output of the task is the Cross-development
+                Regardless of the type of SDK being constructed, the
+                tasks perform some cleanup after which a cross-development
+                environment setup script and any needed configuration files
+                are created.
+                The final output is the Cross-development
                 toolchain installation script (<filename>.sh</filename> file),
                 which includes the environment setup script.
             </para>
@@ -1239,8 +1301,13 @@
             <link linkend='general-yocto-environment-figure'>general Yocto Project Development Environment figure</link>,
             the output labeled "Application Development SDK" represents an
             SDK.
+            The SDK generation process differs depending on whether you build
+            a standard SDK
+            (e.g. <filename>bitbake -c populate_sdk</filename> <replaceable>imagename</replaceable>)
+            or an extensible SDK
+            (e.g. <filename>bitbake -c populate_sdk_ext</filename> <replaceable>imagename</replaceable>).
             This section is going to take a closer look at this output:
-            <imagedata fileref="figures/sdk.png" align="center" width="5in" depth="4in" />
+            <imagedata fileref="figures/sdk.png" align="center" width="9in" depth="7.25in" />
         </para>
 
         <para>
@@ -1255,20 +1322,16 @@
             part because it runs on the SDK machine.
             You can think of the libraries and headers as the "target"
             part because they are built for the target hardware.
-            The setup script is added so that you can initialize the
-            environment before using the tools.
+            The environment setup script is added so that you can initialize
+            the environment before using the tools.
         </para>
 
         <note>
             <para>
                 The Yocto Project supports several methods by which you can
                 set up this cross-development environment.
-                These methods include downloading pre-built SDK installers,
-                building and installing your own SDK installer, or running
-                an Application Development Toolkit (ADT) installer to
-                install not just cross-development toolchains
-                but also additional tools to help in this type of
-                development.
+                These methods include downloading pre-built SDK installers
+                or building and installing your own SDK installer.
             </para>
 
             <para>
@@ -1278,8 +1341,7 @@
                 section.
                 For information on setting up a cross-development
                 environment, see the
-                "<ulink url='&YOCTO_DOCS_ADT_URL;#installing-the-adt'>Installing the ADT and Toolchains</ulink>"
-                section in the Yocto Project Application Developer's Guide.
+                <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-manual'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>.
             </para>
         </note>
 
@@ -1288,7 +1350,10 @@
             <filename>deploy/sdk</filename> folder inside the
             <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
             as shown in the figure at the beginning of this section.
-            Several variables exist that help configure these files:
+            Depending on the type of SDK, several variables exist that help
+            configure these files.
+            The following list shows the variables associated with a standard
+            SDK:
             <itemizedlist>
                 <listitem><para><link linkend='var-DEPLOY_DIR'><filename>DEPLOY_DIR</filename></link>:
                     Points to the <filename>deploy</filename>
@@ -1322,6 +1387,36 @@
                     installation script.
                     </para></listitem>
             </itemizedlist>
+            This next list, shows the variables associated with an extensible
+            SDK:
+            <itemizedlist>
+                <listitem><para><link linkend='var-DEPLOY_DIR'><filename>DEPLOY_DIR</filename></link>:
+                    Points to the <filename>deploy</filename> directory.
+                    </para></listitem>
+                <listitem><para><link linkend='var-SDK_EXT_TYPE'><filename>SDK_EXT_TYPE</filename></link>:
+                    Controls whether or not shared state artifacts are copied
+                    into the extensible SDK.
+                    By default, all required shared state artifacts are copied
+                    into the SDK.
+                    </para></listitem>
+                <listitem><para><link linkend='var-SDK_INCLUDE_PKGDATA'><filename>SDK_INCLUDE_PKGDATA</filename></link>:
+                    Specifies whether or not packagedata will be included in
+                    the extensible SDK for all recipes in the "world" target.
+                    </para></listitem>
+                <listitem><para><link linkend='var-SDK_LOCAL_CONF_WHITELIST'><filename>SDK_LOCAL_CONF_WHITELIST</filename></link>:
+                    A list of variables allowed through from the build system
+                    configuration into the extensible SDK configuration.
+                    </para></listitem>
+                <listitem><para><link linkend='var-SDK_LOCAL_CONF_BLACKLIST'><filename>SDK_LOCAL_CONF_BLACKLIST</filename></link>:
+                    A list of variables not allowed through from the build
+                    system configuration into the extensible SDK configuration.
+                    </para></listitem>
+                <listitem><para><link linkend='var-SDK_INHERIT_BLACKLIST'><filename>SDK_INHERIT_BLACKLIST</filename></link>:
+                    A list of classes to remove from the
+                    <link linkend='var-INHERIT'><filename>INHERIT</filename></link>
+                    value globally within the extensible SDK configuration.
+                    </para></listitem>
+            </itemizedlist>
         </para>
     </section>
 
diff --git a/yocto-poky/documentation/ref-manual/faq.xml b/yocto-poky/documentation/ref-manual/faq.xml
index 197d490..d2e4e8e 100644
--- a/yocto-poky/documentation/ref-manual/faq.xml
+++ b/yocto-poky/documentation/ref-manual/faq.xml
@@ -280,23 +280,42 @@
 
     <qandaentry>
         <question>
-            <para>
+            <para id='i-am-behind-a-firewall-and-need-to-use-a-proxy-server'>
                 I'm behind a firewall and need to use a proxy server. How do I do that?
             </para>
         </question>
         <answer>
             <para>
-                Most source fetching by the OpenEmbedded build system is done by <filename>wget</filename>
-                and you therefore need to specify the proxy settings in a
-                <filename>.wgetrc</filename> file in your home directory.
-                Here are some example settings:
+                Most source fetching by the OpenEmbedded build system is done
+                by <filename>wget</filename> and you therefore need to specify
+                the proxy settings in a <filename>.wgetrc</filename> file,
+                which can be in your home directory if you are a single user
+                or can be in <filename>/usr/local/etc/wgetrc</filename> as
+                a global user file.
+            </para>
+
+            <para>
+                Following is the applicable code for setting various proxy
+                types in the <filename>.wgetrc</filename> file.
+                By default, these settings are disabled with comments.
+                To use them, remove the comments:
                 <literallayout class='monospaced'>
-     http_proxy = http://proxy.yoyodyne.com:18023/
-     ftp_proxy = http://proxy.yoyodyne.com:18023/
+     # You can set the default proxies for Wget to use for http, https, and ftp.
+     # They will override the value in the environment.
+     #https_proxy = http://proxy.yoyodyne.com:18023/
+     #http_proxy = http://proxy.yoyodyne.com:18023/
+     #ftp_proxy = http://proxy.yoyodyne.com:18023/
+
+     # If you do not want to use proxy at all, set this to off.
+     #use_proxy = on
                 </literallayout>
                 The Yocto Project also includes a
-                <filename>site.conf.sample</filename> file that shows how to
-                configure CVS and Git proxy servers if needed.
+                <filename>meta-poky/conf/site.conf.sample</filename> file that
+                shows how to configure CVS and Git proxy servers if needed.
+                For more information on setting up various proxy types and
+                configuring proxy servers, see the
+                "<ulink url='&YOCTO_WIKI_URL;/wiki/Working_Behind_a_Network_Proxy'>Working Behind a Network Proxy</ulink>"
+                Wiki page.
             </para>
         </answer>
     </qandaentry>
@@ -367,7 +386,7 @@
 
             <para>
                 This issue is just a single manifestation of "system
-                leakage" issues caused when the OpenEbedded build system
+                leakage" issues caused when the OpenEmbedded build system
                 finds and uses previously installed files during a native
                 build.
                 This type of issue might not be limited to
@@ -782,7 +801,7 @@
     <qandaentry>
         <question>
             <para>
-                The files provided by my <filename>-native</filename> recipe do
+                The files provided by my <filename>*-native</filename> recipe do
                 not appear to be available to other recipes.
                 Files are missing from the native sysroot, my recipe is
                 installing to the wrong place, or I am getting permissions
diff --git a/yocto-poky/documentation/ref-manual/figures/image-generation.png b/yocto-poky/documentation/ref-manual/figures/image-generation.png
index ab96258..71a48dc 100644
--- a/yocto-poky/documentation/ref-manual/figures/image-generation.png
+++ b/yocto-poky/documentation/ref-manual/figures/image-generation.png
Binary files differ
diff --git a/yocto-poky/documentation/ref-manual/figures/sdk-generation.png b/yocto-poky/documentation/ref-manual/figures/sdk-generation.png
old mode 100644
new mode 100755
index c37e274..adbe1f4
--- a/yocto-poky/documentation/ref-manual/figures/sdk-generation.png
+++ b/yocto-poky/documentation/ref-manual/figures/sdk-generation.png
Binary files differ
diff --git a/yocto-poky/documentation/ref-manual/figures/sdk.png b/yocto-poky/documentation/ref-manual/figures/sdk.png
index a539cc5..5c36b75 100644
--- a/yocto-poky/documentation/ref-manual/figures/sdk.png
+++ b/yocto-poky/documentation/ref-manual/figures/sdk.png
Binary files differ
diff --git a/yocto-poky/documentation/ref-manual/figures/user-configuration.png b/yocto-poky/documentation/ref-manual/figures/user-configuration.png
old mode 100644
new mode 100755
index f2b3f8e..c298401
--- a/yocto-poky/documentation/ref-manual/figures/user-configuration.png
+++ b/yocto-poky/documentation/ref-manual/figures/user-configuration.png
Binary files differ
diff --git a/yocto-poky/documentation/ref-manual/introduction.xml b/yocto-poky/documentation/ref-manual/introduction.xml
index 0b16544..ce8fa5c 100644
--- a/yocto-poky/documentation/ref-manual/introduction.xml
+++ b/yocto-poky/documentation/ref-manual/introduction.xml
@@ -9,19 +9,26 @@
     <title>Introduction</title>
 
     <para>
-        This manual provides reference information for the current release of the Yocto Project.
-        The Yocto Project is an open-source collaboration project focused on embedded Linux
-        developers.
-        Amongst other things, the Yocto Project uses the OpenEmbedded build system, which
-        is based on the Poky project, to construct complete Linux images.
-        You can find complete introductory and getting started information on the Yocto Project
-        by reading the
+        This manual provides reference information for the current release
+        of the Yocto Project.
+        The Yocto Project is an open-source collaboration project focused
+        on embedded Linux developers.
+        Amongst other things, the Yocto Project uses the OpenEmbedded build
+        system, which is based on the Poky project, to construct complete
+        Linux images.
+        You can find complete introductory and getting started information
+        on the Yocto Project by reading the
         <ulink url='&YOCTO_DOCS_QS_URL;'>Yocto Project Quick Start</ulink>.
+    </para>
+
+    <para>
         For task-based information using the Yocto Project, see the
         <ulink url='&YOCTO_DOCS_DEV_URL;'>Yocto Project Development Manual</ulink>
         and the <ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;'>Yocto Project Linux Kernel Development Manual</ulink>.
         For Board Support Package (BSP) structure information, see the
         <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink>.
+        For information on how to use a Software Development Kit, (SDK), see the
+        <ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>.
         You can find information on tracing and profiling in the
         <ulink url='&YOCTO_DOCS_PROF_URL;'>Yocto Project Profiling and Tracing Manual</ulink>.
         For information on BitBake, which is the task execution tool the
@@ -40,7 +47,7 @@
             <listitem><para><emphasis>
                 <link linkend='usingpoky'>Using the Yocto Project</link>:</emphasis>
                 Provides an overview of the components that make up the Yocto Project
-                followed by information about debugging images created in the Yocto Project.
+                followed by information about debugng images created in the Yocto Project.
                 </para></listitem>
             <listitem><para><emphasis>
                 <link linkend='closer-look'>A Closer Look at the Yocto Project Development Environment</link>:</emphasis>
@@ -192,10 +199,6 @@
             supported Linux distribution, instances might exist where you
             encounter a problem while using the Yocto Project on a specific
             distribution.
-            For example, the CentOS 6.4 distribution does not include the
-            Gtk+ 2.20.0 and PyGtk 2.21.0 (or higher) packages, which are
-            required to run
-            <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>Hob</ulink>.
         </note>
     </section>
 
@@ -249,9 +252,9 @@
                         <literallayout class='monospaced'>
      $ sudo apt-get install make xsltproc docbook-utils fop dblatex xmlto
                         </literallayout></para></listitem>
-                    <listitem><para><emphasis>ADT Installer Extras:</emphasis>
+                    <listitem><para><emphasis>SDK 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>:
+                        the standard or extensible SDK:
                         <literallayout class='monospaced'>
      $ sudo apt-get install autoconf automake libtool libglib2.0-dev libarchive-dev
                         </literallayout></para></listitem>
@@ -293,9 +296,9 @@
      $ 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>
+                    <listitem><para><emphasis>SDK 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>:
+                        standard or extensible SDK:
                         <literallayout class='monospaced'>
      $ sudo dnf install autoconf automake libtool glib2-devel libarchive-devel
                         </literallayout></para></listitem>
@@ -336,9 +339,9 @@
                         <literallayout class='monospaced'>
      $ sudo zypper install make fop xsltproc dblatex xmlto
                         </literallayout></para></listitem>
-                    <listitem><para><emphasis>ADT Installer Extras:</emphasis>
+                    <listitem><para><emphasis>SDK 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>:
+                        standard or extensible SDK:
                         <literallayout class='monospaced'>
      $ sudo zypper install autoconf automake libtool glib2-devel libarchive-devel
                         </literallayout></para></listitem>
@@ -359,14 +362,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>
@@ -391,21 +394,12 @@
      $ sudo yum 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>
+                    <listitem><para><emphasis>SDK 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>:
+                        standard or extensible SDK:
                         <literallayout class='monospaced'>
      $ 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>
+                        </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>:
@@ -426,7 +420,7 @@
             must meet the following version requirements for Git, tar, and
             Python:
             <itemizedlist>
-                <listitem><para>Git 1.7.8 or greater</para></listitem>
+                <listitem><para>Git 1.8.3.1 or greater</para></listitem>
                 <listitem><para>tar 1.24 or greater</para></listitem>
                 <listitem><para>Python 2.7.3 or greater not including
                     Python 3.x, which is not supported.</para></listitem>
@@ -597,8 +591,8 @@
             <listitem><para><emphasis>Nightly Builds:</emphasis> These
                 tarball releases are available at
                 <ulink url='&YOCTO_AB_NIGHTLY_URL;'/>.
-                These builds include Yocto Project releases, meta-toolchain
-                tarball installation scripts, and experimental builds.
+                These builds include Yocto Project releases, SDK installation
+                scripts, and experimental builds.
                 </para></listitem>
             <listitem><para><emphasis>Yocto Project Website:</emphasis> You can
                 find tarball releases of the Yocto Project and supported BSPs
diff --git a/yocto-poky/documentation/ref-manual/migration.xml b/yocto-poky/documentation/ref-manual/migration.xml
index 21763e3..e6c0aa3 100644
--- a/yocto-poky/documentation/ref-manual/migration.xml
+++ b/yocto-poky/documentation/ref-manual/migration.xml
@@ -97,13 +97,14 @@
 
             <para>
                 The shared state cache (sstate-cache), as pointed to by
-                <link linkend='var-SSTATE_DIR'><filename>SSTATE_DIR</filename></link>, by default
-                now has two-character subdirectories to prevent issues arising
-                from too many files in the same directory.
-                Also, native sstate-cache packages will go into a subdirectory named using
+                <link linkend='var-SSTATE_DIR'><filename>SSTATE_DIR</filename></link>,
+                by default now has two-character subdirectories to prevent
+                issues arising from too many files in the same directory.
+                Also, native sstate-cache packages, which are built to run
+                on the host system, will go into a subdirectory named using
                 the distro ID string.
-                If you copy the newly structured sstate-cache to a mirror location
-                (either local or remote) and then point to it in
+                If you copy the newly structured sstate-cache to a mirror
+                location (either local or remote) and then point to it in
                 <link linkend='var-SSTATE_MIRRORS'><filename>SSTATE_MIRRORS</filename></link>,
                 you need to append "PATH" to the end of the mirror URL so that
                 the path used by BitBake before the mirror substitution is
@@ -124,7 +125,7 @@
                 reference hardware Board Support Packages (BSPs), respectively:
                 <filename>meta-yocto</filename> and
                 <filename>meta-yocto-bsp</filename>.
-                When running BitBake or Hob for the first time after upgrading,
+                When running BitBake for the first time after upgrading,
                 your <filename>conf/bblayers.conf</filename> file will be
                 updated to handle this change and you will be asked to
                 re-run or restart for the changes to take effect.
@@ -191,8 +192,10 @@
                 The suffix <filename>nativesdk</filename> is now implemented
                 as a prefix, which simplifies a lot of the packaging code for
                 <filename>nativesdk</filename> recipes.
-                All custom <filename>nativesdk</filename> recipes and any
-                references need to be updated to use
+                All custom <filename>nativesdk</filename> recipes, which are
+                relocatable packages that are native to
+                <link linkend='var-SDK_ARCH'><filename>SDK_ARCH</filename></link>,
+                and any references need to be updated to use
                 <filename>nativesdk-*</filename> instead of
                 <filename>*-nativesdk</filename>.
             </para>
@@ -1443,18 +1446,6 @@
         </section>
     </section>
 
-    <section id='migration-1.6-directory-layout-changes'>
-        <title>Directory Layout Changes</title>
-
-        <para>
-            The <filename>meta-hob</filename> layer has been removed from
-            the top-level of the
-            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
-            The contents of this layer are no longer needed by the Hob
-            user interface for building images and toolchains.
-        </para>
-    </section>
-
     <section id='migration-1.6-package-test-ptest'>
         <title>Package Test (ptest)</title>
 
@@ -2456,9 +2447,10 @@
                     </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.
+                    <filename>d.delVar('</filename><replaceable>varname</replaceable><filename>')</filename> and
+                    <filename>d.setVar('</filename><replaceable>varname</replaceable><filename>', 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>
@@ -2735,6 +2727,558 @@
     </section>
 </section>
 
+<section id='moving-to-the-yocto-project-2.1-release'>
+    <title>Moving to the Yocto Project 2.1 Release</title>
+
+    <para>
+        This section provides migration information for moving to the
+        Yocto Project 2.1 Release from the prior release.
+    </para>
+
+    <section id='migration-2.1-variable-expansion-in-python-functions'>
+        <title>Variable Expansion in Python Functions</title>
+
+        <para>
+            Variable expressions, such as
+            <filename>${</filename><replaceable>varname</replaceable><filename>}</filename>
+            no longer expand automatically within Python functions.
+            Suppressing expansion was done to allow Python functions to
+            construct shell scripts or other code for situations in which you
+            do not want such expressions expanded.
+            For any existing code that relies on these expansions, you need to
+            change the expansions to either expand the value of individual
+            variables through <filename>d.getVar()</filename>.
+            To alternatively expand more complex expressions,
+            use <filename>d.expand()</filename>.
+        </para>
+    </section>
+
+    <section id='migration-2.1-overrides-must-now-be-lower-case'>
+        <title>Overrides Must Now be Lower-Case</title>
+
+        <para>
+            The convention for overrides has always been for them to be
+            lower-case characters.
+            This practice is now a requirement as BitBake's datastore now
+            assumes lower-case characters in order to give a slight performance
+            boost during parsing.
+            In practical terms, this requirement means that anything that ends
+            up in
+            <link linkend='var-OVERRIDES'><filename>OVERRIDES</filename></link>
+            must now appear in lower-case characters (e.g. values for
+            <filename>MACHINE</filename>, <filename>TARGET_ARCH</filename>,
+            <filename>DISTRO</filename>, and also recipe names if
+            <filename>_pn-</filename><replaceable>recipename</replaceable>
+            overrides are to be effective).
+        </para>
+    </section>
+
+    <section id='migration-2.1-expand-parameter-to-getvar-and-getvarflag-now-mandatory'>
+        <title>Expand Parameter to <filename>getVar()</filename> and
+            <filename>getVarFlag()</filename> is Now Mandatory</title>
+
+        <para>
+            The expand parameter to <filename>getVar()</filename> and
+            <filename>getVarFlag()</filename> previously defaulted to
+            False if not specified.
+            Now, however, no default exists so one must be specified.
+            You must change any <filename>getVar()</filename> calls that
+            do not specify the final expand parameter to calls that do specify
+            the parameter.
+            You can run the following <filename>sed</filename> command at the
+            base of a layer to make this change:
+            <literallayout class='monospaced'>
+     sed -e 's:\(\.getVar([^,()]*\)):\1, False):g' -i `grep -ril getVar *`
+     sed -e 's:\(\.getVarFlag([^,()]*, [^,()]*\)):\1, False):g' -i `grep -ril getVarFlag *`
+            </literallayout>
+            <note>
+                The reason for this change is that it prepares the way for
+                changing the default to True in a future Yocto Project release.
+                This future change is a much more sensible default than False.
+                However, the change needs to be made gradually as a sudden
+                change of the default would potentially cause side-effects
+                that would be difficult to detect.
+            </note>
+        </para>
+    </section>
+
+    <section id='migration-2.1-makefile-environment-changes'>
+        <title>Makefile Environment Changes</title>
+
+        <para>
+            <link linkend='var-EXTRA_OEMAKE'><filename>EXTRA_OEMAKE</filename></link>
+            now defaults to "" instead of "-e MAKEFLAGS=".
+            Setting <filename>EXTRA_OEMAKE</filename> to "-e MAKEFLAGS=" by
+            default was a historical accident that has required many classes
+            (e.g. <filename>autotools</filename>, <filename>module</filename>)
+            and recipes to override this default in order to work with
+            sensible build systems.
+            When upgrading to the release, you must edit any recipe that
+            relies upon this old default by either setting
+            <filename>EXTRA_OEMAKE</filename> back to "-e MAKEFLAGS=" or by
+            explicitly setting any required variable value overrides using
+            <filename>EXTRA_OEMAKE</filename>, which is typically only needed
+            when a Makefile sets a default value for a variable that is
+            inappropriate for cross-compilation using the "=" operator rather
+            than the "?=" operator.
+        </para>
+    </section>
+
+    <section id='migration-2.1-libexecdir-reverted-to-prefix-libexec'>
+        <title><filename>libexecdir</filename> Reverted to <filename>${prefix}/libexec</filename></title>
+
+        <para>
+            The use of <filename>${libdir}/${BPN}</filename> as
+            <filename>libexecdir</filename> is different as compared to all
+            other mainstream distributions, which either uses
+            <filename>${prefix}/libexec</filename> or
+            <filename>${libdir}</filename>.
+            The use is also contrary to the GNU Coding Standards
+            (i.e. <ulink url='https://www.gnu.org/prep/standards/html_node/Directory-Variables.html'></ulink>)
+            that suggest <filename>${prefix}/libexec</filename> and also
+            notes that any package-specific nesting should be done by the
+            package itself.
+            Finally, having <filename>libexecdir</filename> change between
+            recipes makes it very difficult for different recipes to invoke
+            binaries that have been installed into
+            <filename>libexecdir</filename>.
+            The Filesystem Hierarchy Standard
+            (i.e. <ulink url='http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html'></ulink>)
+            now recognizes the use of <filename>${prefix}/libexec/</filename>,
+            giving distributions the choice between
+            <filename>${prefix}/lib</filename> or
+            <filename>${prefix}/libexec</filename> without breaking FHS.
+        </para>
+    </section>
+
+    <section id='migration-2.1-ac-cv-sizeof-off-t-no-longer-cached-in-site-files'>
+        <title><filename>ac_cv_sizeof_off_t</filename> is No Longer Cached in Site Files</title>
+
+        <para>
+            For recipes inheriting the
+            <link linkend='ref-classes-autotools'><filename>autotools</filename></link>
+            class, <filename>ac_cv_sizeof_off_t</filename> is no longer cached
+            in the site files for <filename>autoconf</filename>.
+            The reason for this change is because the
+            <filename>ac_cv_sizeof_off_t</filename> value is not necessarily
+            static per architecture as was previously assumed.
+            Rather, the value changes based on whether large file support is
+            enabled.
+            For most software that uses <filename>autoconf</filename>, this
+            change should not be a problem.
+            However, if you have a recipe that bypasses the standard
+            <link linkend='ref-tasks-configure'><filename>do_configure</filename></link>
+            task from the <filename>autotools</filename> class and the software
+            the recipe is building uses a very old version of
+            <filename>autoconf</filename>, the recipe might be incapable of
+            determining the correct size of <filename>off_t</filename> during
+            <filename>do_configure</filename>.
+        </para>
+
+        <para>
+            The best course of action is to patch the software as necessary
+            to allow the default implementation from the
+            <filename>autotools</filename> class to work such that
+            <filename>autoreconf</filename> succeeds and produces a working
+            configure script), and to remove the
+            overridden <filename>do_configure</filename> task such that the
+            default implementation does get used.
+        </para>
+    </section>
+
+    <section id='migration-2.1-image-generation-split-out-from-filesystem-generation'>
+        <title>Image Generation is Now Split Out from Filesystem Generation</title>
+
+        <para>
+            Previously, for image recipes the
+            <link linkend='ref-tasks-rootfs'><filename>do_rootfs</filename></link>
+            task assembled the filesystem and then from that filesystem
+            generated images.
+            With this Yocto Project release, image generation is split into
+            separate
+            <link linkend='ref-tasks-image'><filename>do_image_*</filename></link>
+            tasks for clarity both in operation and in the code.
+        </para>
+
+        <para>
+            For most cases, this change does not present any problems.
+            However, if you have made customizations that directly modify the
+            <filename>do_rootfs</filename> task or that mention
+            <filename>do_rootfs</filename>, you might need to update those
+            changes.
+            In particular, if you had added any tasks after
+            <filename>do_rootfs</filename>, you should make edits so that
+            those tasks are after the
+            <link linkend='ref-tasks-image-complete'><filename>do_image_complete</filename></link>
+            task rather than before the task so that the your added tasks
+            run at the correct time.
+        </para>
+
+        <para>
+            A minor part of this restructuring is that the post-processing
+            definitions and functions have been moved from the
+            <link linkend='ref-classes-image'><filename>image</filename></link>
+            class to the
+            <link linkend='ref-classes-rootfs*'><filename>rootfs-postcommands</filename></link>
+            class.
+            Functionally, however, they remain unchanged.
+        </para>
+    </section>
+
+    <section id='migration-2.1-removed-recipes'>
+        <title>Removed Recipes</title>
+
+        <para>
+            The following recipes have been removed in the 2.1 release:
+            <itemizedlist>
+                <listitem><para><filename>gcc</filename> version 4.8:
+                    Versions 4.9 and 5.3 remain.
+                    </para></listitem>
+                <listitem><para><filename>qt4</filename>:
+                    All support for Qt 4.x has been moved out to a separate
+                    <filename>meta-qt4</filename> layer because Qt 4 is no
+                    longer supported upstream.
+                    </para></listitem>
+                <listitem><para><filename>x11vnc</filename>:
+                    Moved to the <filename>meta-oe</filename> layer.
+                    </para></listitem>
+                <listitem><para><filename>linux-yocto-3.14</filename>:
+                    No longer supported.
+                    </para></listitem>
+                <listitem><para><filename>linux-yocto-3.19</filename>:
+                    No longer supported.
+                    </para></listitem>
+                <listitem><para><filename>libjpeg</filename>:
+                    Replaced by the <filename>libjpeg-turbo</filename> recipe.
+                    </para></listitem>
+                <listitem><para><filename>pth</filename>:
+                    Became obsolete.
+                    </para></listitem>
+                <listitem><para><filename>liboil</filename>:
+                    Recipe is no longer needed and has been moved to the
+                    <filename>meta-multimedia</filename> layer.
+                    </para></listitem>
+                <listitem><para><filename>gtk-theme-torturer</filename>:
+                    Recipe is no longer needed and has been moved to the
+                    <filename>meta-gnome</filename> layer.
+                    </para></listitem>
+                <listitem><para><filename>gnome-mime-data</filename>:
+                    Recipe is no longer needed and has been moved to the
+                    <filename>meta-gnome</filename> layer.
+                    </para></listitem>
+                <listitem><para><filename>udev</filename>:
+                    Replaced by the <filename>eudev</filename> recipe for
+                    compatibility when using <filename>sysvinit</filename>
+                    with newer kernels.
+                    </para></listitem>
+                <listitem><para><filename>python-pygtk</filename>:
+                    Recipe became obsolete.
+                    </para></listitem>
+                <listitem><para><filename>adt-installer</filename>:
+                    Recipe became obsolete.
+                    See the
+                    "<link linkend='migration-2.1-adt-removed'>ADT Removed</link>"
+                    section for more information.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-2.1-class-changes'>
+        <title>Class Changes</title>
+
+        <para>
+            The following classes have changed:
+            <itemizedlist>
+                <listitem><para><filename>autotools_stage</filename>:
+                    Removed because the
+                    <link linkend='ref-classes-autotools'><filename>autotools</filename></link>
+                    class now provides its functionality.
+                    Recipes that inherited from
+                    <filename>autotools_stage</filename> should now inherit
+                    from <filename>autotools</filename> instead.
+                    </para></listitem>
+                <listitem><para><filename>boot-directdisk</filename>:
+                    Merged into the
+                    <link linkend='ref-classes-image-vm'><filename>image-vm</filename></link>
+                    class.
+                    The <filename>boot-directdisk</filename> class was rarely
+                    directly used.
+                    Consequently, this change should not cause any issues.
+                    </para></listitem>
+                <listitem><para><filename>bootimg</filename>:
+                    Merged into the
+                    <link linkend='ref-classes-image-live'><filename>image-live</filename></link>
+                    class.
+                    The <filename>bootimg</filename> class was rarely
+                    directly used.
+                    Consequently, this change should not cause any issues.
+                    </para></listitem>
+                <listitem><para><filename>packageinfo</filename>:
+                    Removed due to its limited use by the Hob UI, which has
+                    itself been removed.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-2.1-build-system-ui-changes'>
+        <title>Build System User Interface Changes</title>
+
+        <para>
+            The following changes have been made to the build system user
+            interface:
+            <itemizedlist>
+                <listitem><para><emphasis>Hob GTK+-based UI</emphasis>:
+                    Removed because it is unmaintained and based on the
+                    outdated GTK+ 2 library.
+                    The Toaster web-based UI is much more capable and is
+                    actively maintained.
+                    See the
+                    "<ulink url='&YOCTO_DOCS_TOAST_URL;#using-the-toaster-web-interface'>Using the Toaster Web Interface</ulink>"
+                    section in the Yocto Project Toaster User Manual for more
+                    information on this interface.
+                    </para></listitem>
+                <listitem><para><emphasis>"puccho" BitBake UI</emphasis>:
+                    Removed because is unmaintained and no longer useful.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-2.1-adt-removed'>
+        <title>ADT Removed</title>
+
+        <para>
+            The Application Development Toolkit (ADT) has been removed
+            because its functionality almost completely overlapped with the
+            <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-using-the-standard-sdk'>standard SDK</ulink>
+            and the
+            <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-extensible'>extensible SDK</ulink>.
+            For information on these SDKs and how to build and use them, see the
+            <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-intro'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>.
+        </para>
+    </section>
+
+    <section id='migration-2.1-poky-reference-distribution-changes'>
+        <title>Poky Reference Distribution Changes</title>
+
+        <para>
+            The following changes have been made for the Poky distribution:
+            <itemizedlist>
+                <listitem><para>
+                    The <filename>meta-yocto</filename> layer has been renamed
+                    to <filename>meta-poky</filename> to better match its
+                    purpose, which is to provide the Poky reference
+                    distribution.
+                    The <filename>meta-yocto-bsp</filename> layer retains its
+                    original name since it provides reference machines for
+                    the Yocto Project and it is otherwise unrelated to Poky.
+                    References to <filename>meta-yocto</filename> in your
+                    <filename>conf/bblayers.conf</filename> should
+                    automatically be updated, so you should not need to change
+                    anything unless you are relying on this naming elsewhere.
+                    </para></listitem>
+                <listitem><para>
+                    The
+                    <link linkend='ref-classes-uninative'><filename>uninative</filename></link>
+                    class is now enabled by default in Poky.
+                    This class attempts to isolate the build system from the
+                    host distribution's C library and makes re-use of native
+                    shared state artifacts across different host distributions
+                    practical.
+                    With this class enabled, a tarball containing a pre-built
+                    C library is downloaded at the start of the build.</para>
+
+                    <para>The <filename>uninative</filename> class is enabled
+                    through the
+                    <filename>meta/conf/distro/include/yocto-uninative.inc</filename>
+                    file, which for those not using the Poky distribution, can
+                    include to easily enable the same functionality.</para>
+
+                    <para>Alternatively, if you wish to build your own
+                    <filename>uninative</filename> tarball, you can do so by
+                    building the <filename>uninative-tarball</filename> recipe,
+                    making it available to your build machines
+                    (e.g. over HTTP/HTTPS) and setting a similar configuration
+                    as the one set by <filename>yocto-uninative.inc</filename>.
+                    </para></listitem>
+                <listitem><para>
+                    Static library generation, for most cases, is now disabled
+                    by default in the Poky distribution.
+                    Disabling this generation saves some build time as well
+                    as the size used for build output artifacts.</para>
+
+                    <para>Disabling this library generation is accomplished
+                    through a
+                    <filename>meta/conf/distro/include/no-static-libs.inc</filename>,
+                    which for those not using the Poky distribution can
+                    easily include to enable the same functionality.</para>
+
+                    <para>Any recipe that needs to opt-out of having the
+                    "--disable-static" option specified on the configure
+                    command line either because it is not a supported option
+                    for the configure script or because static libraries are
+                    needed should set the following variable:
+                    <literallayout class='monospaced'>
+     DISABLE_STATIC = ""
+                    </literallayout>
+                    </para></listitem>
+                <listitem><para>
+                    The separate <filename>poky-tiny</filename> distribution
+                    now uses the musl C library instead of a heavily pared
+                    down <filename>glibc</filename>.
+                    Using <filename>glibc</filename> results in a smaller
+                    distribution and facilitates much greater maintainability
+                    because musl is designed to have a small footprint.</para>
+
+                    <para>If you have used <filename>poky-tiny</filename> and
+                    have customized the <filename>glibc</filename>
+                    configuration you will need to redo those customizations
+                    with musl when upgrading to the new release.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-2.1-packaging-changes'>
+        <title>Packaging Changes</title>
+
+        <para>
+            The following changes have been made to packaging:
+            <itemizedlist>
+                <listitem><para>
+                    The <filename>runuser</filename> and
+                    <filename>mountpoint</filename> binaries, which were
+                    previously in the main <filename>util-linux</filename>
+                    package, have been split out into the
+                    <filename>util-linux-runuser</filename> and
+                    <filename>util-linux-mountpoint</filename> packages,
+                    respectively.
+                    </para></listitem>
+                <listitem><para>
+                    The <filename>python-elementtree</filename> package has
+                    been merged into the <filename>python-xml</filename>
+                    package.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-2.1-tuning-file-changes'>
+        <title>Tuning File Changes</title>
+
+        <para>
+            The following changes have been made to the tuning files:
+            <itemizedlist>
+                <listitem><para>
+                    The "no-thumb-interwork" tuning feature has been dropped
+                    from the ARM tune include files.
+                    Because interworking is required for ARM EABI, attempting
+                    to disable it through a tuning feature no longer makes
+                    sense.
+                    <note>
+                        Support for ARM OABI was deprecated in gcc 4.7.
+                    </note>
+                    </para></listitem>
+                <listitem><para>
+                    The <filename>tune-cortexm*.inc</filename> and
+                    <filename>tune-cortexr4.inc</filename> files have been
+                    removed because they are poorly tested.
+                    Until the OpenEmbedded build system officially gains
+                    support for CPUs without an MMU, these tuning files would
+                    probably be better maintained in a separate layer
+                    if needed.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-2.1-miscellaneous-changes'>
+        <title>Miscellaneous Changes</title>
+
+        <para>
+            These additional changes exist:
+            <itemizedlist>
+                <listitem><para>
+                    The minimum Git version has been increased to 1.8.3.1.
+                    If your host distribution does not provide a sufficiently
+                    recent version, you can install the buildtools, which
+                    will provide it.
+                    </para></listitem>
+                <listitem><para>
+                    The buggy and incomplete support for the RPM version 4
+                    package manager has been removed.
+                    The well-tested and maintained support for RPM version 5
+                    remains.
+                    </para></listitem>
+                <listitem><para>
+                    The
+                    <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-devtool-use-devtool-modify-to-modify-the-source-of-an-existing-component'><filename>devtool modify</filename></ulink>
+                    command now defaults to extracting the source since that
+                    is most commonly expected.
+                    The "-x" or "--extract" options are now no-ops.
+                    If you wish to provide your own existing source tree, you
+                    will now need to specify either the "-n" or
+                    "--no-extract" option when running
+                    <filename>devtool modify</filename>.
+                    </para></listitem>
+                <listitem><para>
+                    If the formfactor for a machine is either not supplied
+                    or does not specify whether a keyboard is attached, then
+                    the default is to assume a keyboard is attached rather
+                    than assume no keyboard.
+                    <note>
+                        This change primarily affects the Sato UI.
+                    </note>
+                    </para></listitem>
+                <listitem><para>
+                    The <filename>.debug</filename> directory packaging is
+                    now automatic.
+                    If your recipe builds software that installs binaries into
+                    directories other than the standard ones, you no longer
+                    need to take care of setting
+                    <filename>FILES_${PN}-dbg</filename> to pick up the
+                    resulting <filename>.debug</filename> directories as these
+                    directories are automatically found and added.
+                    </para></listitem>
+                <listitem><para>
+                    Inaccurate disk and CPU percentage data has been dropped
+                    from <filename>buildstats</filename> output.
+                    This data has been replaced with
+                    <filename>getrusage()</filename> data and corrected IO
+                    statistics.
+                    You will probably need to update code that reads the
+                    <filename>buildstats</filename> data.
+                    </para></listitem>
+                <listitem><para>
+                    The
+                    <filename>meta/conf/distro/include/package_regex.inc</filename>
+                    is now deprecated.
+                    The contents of this file have been moved to individual
+                    recipes.
+                    <note><title>Tip</title>
+                        Because this file will likely be removed in a future
+                        Yocto Project release, it is suggested that you remove
+                        any references to the file that might be in your
+                        configuration.
+                    </note>
+                    </para></listitem>
+                <listitem><para>
+                    The <filename>v86d/uvesafb</filename> has been removed from
+                    the <filename>genericx86</filename> and
+                    <filename>genericx86-64</filename> reference machines,
+                    which are provided by the
+                    <filename>meta-yocto-bsp</filename> layer.
+                    Most modern x86 boards do not rely on this file and it only
+                    adds kernel error messages during startup.
+                    If you do still need the file, you can simply add
+                    <filename>v86d</filename> to your image.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+</section>
 
 </chapter>
 <!--
diff --git a/yocto-poky/documentation/ref-manual/ref-bitbake.xml b/yocto-poky/documentation/ref-manual/ref-bitbake.xml
index dc402db..1de1148 100644
--- a/yocto-poky/documentation/ref-manual/ref-bitbake.xml
+++ b/yocto-poky/documentation/ref-manual/ref-bitbake.xml
@@ -414,7 +414,7 @@
   -l DEBUG_DOMAINS, --log-domains=DEBUG_DOMAINS
                         Show debug logging for the specified logging domains
   -P, --profile         Profile the command and save reports.
-  -u UI, --ui=UI        The user interface to use (e.g. knotty, hob, depexp).
+  -u UI, --ui=UI        The user interface to use (e.g. knotty and depexp).
   -t SERVERTYPE, --servertype=SERVERTYPE
                         Choose which server to use, process or xmlrpc.
   --revisions-changed   Set the exit code depending on whether upstream
diff --git a/yocto-poky/documentation/ref-manual/ref-classes.xml b/yocto-poky/documentation/ref-manual/ref-classes.xml
index b2941b8..e919bd7 100644
--- a/yocto-poky/documentation/ref-manual/ref-classes.xml
+++ b/yocto-poky/documentation/ref-manual/ref-classes.xml
@@ -128,8 +128,7 @@
     <para>
         By default, the <filename>autotools*</filename> classes
         use out-of-tree builds (i.e.
-        <filename>autotools.bbclass</filename> and
-        <filename>autotools_stage.bbclass</filename>).
+        <filename>autotools.bbclass</filename>).
         (<link linkend='var-B'><filename>B</filename></link> <filename>!=</filename>
         <link linkend='var-S'><filename>S</filename></link>).
     </para>
@@ -139,8 +138,7 @@
         using out-of-tree builds, you should have the recipe inherit the
         <filename>autotools-brokensep</filename> class.
         The <filename>autotools-brokensep</filename> class behaves the same
-        as the <filename>autotools</filename> and
-        <filename>autotools_stage</filename> classes but builds with
+        as the <filename>autotools</filename> class 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
@@ -201,6 +199,15 @@
     </para>
 </section>
 
+<section id='ref-classes-bash-completion'>
+    <title><filename>bash-completion.bbclass</filename></title>
+
+    <para>
+        Sets up packaging and dependencies appropriate for recipes that
+        build software that includes bash-completion data.
+    </para>
+</section>
+
 <section id='ref-classes-bin-package'>
     <title><filename>bin_package.bbclass</filename></title>
 
@@ -319,64 +326,6 @@
     </para>
 </section>
 
-<section id='ref-classes-boot-directdisk'>
-    <title><filename>boot-directdisk.bbclass</filename></title>
-
-    <para>
-        The <filename>boot-directdisk</filename> class
-        creates an image that can be placed directly onto a hard disk using
-        <filename>dd</filename> and then booted.
-        The image uses SYSLINUX.
-    </para>
-
-    <para>
-        The end result is a 512 boot sector populated with a
-        Master Boot Record (MBR) and partition table followed by an MSDOS
-        FAT16 partition containing SYSLINUX and a Linux kernel completed by
-        the <filename>ext2</filename> and <filename>ext3</filename>
-        root filesystems.
-    </para>
-</section>
-
-<section id='ref-classes-bootimg'>
-    <title><filename>bootimg.bbclass</filename></title>
-
-    <para>
-        The <filename>bootimg</filename> class creates a bootable
-        image using SYSLINUX, your kernel, and an optional initial RAM disk
-        (<filename>initrd</filename>).
-    </para>
-
-    <para>
-        When you use this class, two things happen:
-        <itemizedlist>
-            <listitem><para>
-                A <filename>.hddimg</filename> file is created.
-                This file is an MSDOS filesystem that contains SYSLINUX,
-                a kernel, an <filename>initrd</filename>, and a root filesystem
-                image.
-                All three of these can be written to hard drives directly and
-                also booted on a USB flash disks using <filename>dd</filename>.
-                </para></listitem>
-            <listitem><para>
-                A CD <filename>.iso</filename> image is created.
-                When this file is booted, the <filename>initrd</filename>
-                boots and processes the label selected in SYSLINUX.
-                Actions based on the label are then performed (e.g. installing
-                to a hard drive).</para></listitem>
-        </itemizedlist>
-    </para>
-
-    <para>
-        The <filename>bootimg</filename> class supports the
-        <link linkend='var-INITRD'><filename>INITRD</filename></link>,
-        <link linkend='var-NOISO'><filename>NOISO</filename></link>,
-        <link linkend='var-NOHDD'><filename>NOHDD</filename></link>, and
-        <link linkend='var-ROOTFS'><filename>ROOTFS</filename></link>
-        variables.
-    </para>
-</section>
-
 <section id='ref-classes-bugzilla'>
     <title><filename>bugzilla.bbclass</filename></title>
 
@@ -714,7 +663,9 @@
         provides for automatic checking for upstream recipe updates.
         The class creates a comma-separated value (CSV) spreadsheet that
         contains information about the recipes.
-        The information provides the <filename>do_distrodata</filename> and
+        The information provides the
+        <link linkend='ref-tasks-distrodata'><filename>do_distrodata</filename></link>
+        and
         <filename>do_distro_check</filename> tasks, which do upstream checking
         and also verify if a package is used in multiple major distributions.
     </para>
@@ -728,6 +679,13 @@
      INHERIT+= "distrodata"
         </literallayout>
     </para>
+
+    <para>
+        The <filename>distrodata</filename> class also provides the
+        <link linkend='ref-tasks-checkpkg'><filename>do_checkpkg</filename></link>
+        task, which can be used against a simple recipe or against an
+        image to get all its recipe information.
+    </para>
 </section>
 
 <section id='ref-classes-distutils'>
@@ -999,6 +957,28 @@
     </para>
 </section>
 
+<section id='ref-classes-gobject-introspection'>
+    <title><filename>gobject-introspection.bbclass</filename></title>
+
+    <para>
+        Provides support for recipes building software that
+        supports GObject introspection.
+        This functionality is only enabled if the
+        "gobject-introspection-data" feature is in
+        <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>
+        as well as "qemu-usermode" being in
+        <link linkend='var-MACHINE_FEATURES'><filename>MACHINE_FEATURES</filename></link>.
+        <note>
+            This functionality is backfilled by default and,
+            if not applicable, should be disabled through
+            <link linkend='var-DISTRO_FEATURES_BACKFILL_CONSIDERED'><filename>DISTRO_FEATURES_BACKFILL_CONSIDERED</filename></link>
+            or
+            <link linkend='var-MACHINE_FEATURES_BACKFILL_CONSIDERED'><filename>MACHINE_FEATURES_BACKFILL_CONSIDERED</filename></link>,
+            respectively.
+        </note>
+    </para>
+</section>
+
 <section id='ref-classes-grub-efi'>
     <title><filename>grub-efi.bbclass</filename></title>
 
@@ -1146,8 +1126,8 @@
     <title><filename>gzipnative.bbclass</filename></title>
 
     <para>
-        The <filename>gzipnative</filename>
-        class enables the use of native versions of <filename>gzip</filename>
+        The <filename>gzipnative</filename> class enables the use of
+        different native versions of <filename>gzip</filename>
         and <filename>pigz</filename> rather than the versions of these tools
         from the build host.
     </para>
@@ -2284,6 +2264,29 @@
     </para>
 </section>
 
+<section id='ref-classes-nopackages'>
+    <title><filename>nopackages.bbclass</filename></title>
+
+    <para>
+        Disables packaging tasks for those recipes and classes where
+        packaging is not needed.
+    </para>
+</section>
+
+<section id='ref-classes-npm'>
+    <title><filename>npm.bbclass</filename></title>
+
+    <para>
+        Provides support for building Node.js software fetched using the npm
+        package manager.
+        <note>
+            Currently, recipes inheriting this class must use the
+            <filename>npm://</filename> fetcher to have dependencies fetched
+            and packaged automatically.
+        </note>
+    </para>
+</section>
+
 <section id='ref-classes-oelint'>
     <title><filename>oelint.bbclass</filename></title>
 
@@ -2558,22 +2561,6 @@
     </para>
 </section>
 
-<section id='ref-classes-packageinfo'>
-    <title><filename>packageinfo.bbclass</filename></title>
-
-    <para>
-        The <filename>packageinfo</filename> class
-        gives a BitBake user interface the ability to retrieve information
-        about output packages from the <filename>pkgdata</filename> files.
-    </para>
-
-    <para>
-        This class is enabled automatically when using the
-        <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>Hob</ulink>
-        user interface.
-    </para>
-</section>
-
 <section id='ref-classes-patch'>
     <title><filename>patch.bbclass</filename></title>
 
@@ -2654,8 +2641,8 @@
         toolchain using the
         <link linkend='ref-tasks-populate_sdk'><filename>do_populate_sdk</filename></link>
         task, see the
-        "<ulink url='&YOCTO_DOCS_ADT_URL;#optionally-building-a-toolchain-installer'>Optionally Building a Toolchain Installer</ulink>"
-        section in the Yocto Project Application Developer's Guide.
+        "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-building-an-sdk-installer'>Building an SDK Installer</ulink>"
+        section in the Yocto Project Software Development Kit (SDK) Developer's Guide.
     </para>
 </section>
 
@@ -2734,8 +2721,9 @@
         cross-development toolchain using the
         <link linkend='ref-tasks-populate_sdk'><filename>do_populate_sdk</filename></link>
         task, see the
-        "<ulink url='&YOCTO_DOCS_ADT_URL;#optionally-building-a-toolchain-installer'>Optionally Building a Toolchain Installer</ulink>"
-        section in the Yocto Project Application Developer's Guide.
+        "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-building-an-sdk-installer'>Building an SDK Installer</ulink>"
+        section in the Yocto Project Software Development Kit (SDK) Developer's
+        Guide.
     </para>
 </section>
 
@@ -2869,66 +2857,6 @@
     </para>
 </section>
 
-<section id='ref-classes-qmake*'>
-    <title><filename>qmake*.bbclass</filename></title>
-
-    <para>
-        The <filename>qmake*</filename> classes support recipes that
-        need to build software that uses Qt's <filename>qmake</filename>
-        build system and are comprised of the following:
-        <itemizedlist>
-            <listitem><para><emphasis><filename>qmake_base</filename>:</emphasis>
-                Provides base functionality for all versions of
-                <filename>qmake</filename>.</para></listitem>
-            <listitem><para><emphasis><filename>qmake2</filename>:</emphasis>
-                Extends base functionality for <filename>qmake</filename> 2.x as
-                used by Qt 4.x.</para></listitem>
-        </itemizedlist>
-    </para>
-
-    <para>
-        If you need to set any configuration variables or pass any options to
-        <filename>qmake</filename>, you can add these to the
-        <link linkend='var-EXTRA_QMAKEVARS_PRE'><filename>EXTRA_QMAKEVARS_PRE</filename></link>
-        or
-        <link linkend='var-EXTRA_QMAKEVARS_POST'><filename>EXTRA_QMAKEVARS_POST</filename></link>
-        variables, depending on whether the arguments need to be before or
-        after the <filename>.pro</filename> file list on the command line,
-        respectively.
-    </para>
-
-    <para>
-        By default, all <filename>.pro</filename> files are built.
-        If you want to specify your own subset of <filename>.pro</filename>
-        files to be built, specify them in the
-        <link linkend='var-QMAKE_PROFILES'><filename>QMAKE_PROFILES</filename></link>
-        variable.
-    </para>
-</section>
-
-<section id='ref-classes-qt4*'>
-    <title><filename>qt4*.bbclass</filename></title>
-
-    <para>
-        The <filename>qt4*</filename> classes support recipes that need to
-        build software that uses the Qt development framework version 4.x
-        and consist of the following:
-        <itemizedlist>
-            <listitem><para><emphasis><filename>qt4e</filename>:</emphasis>
-                Supports building against Qt/Embedded, which uses the
-                framebuffer for graphical output.</para></listitem>
-            <listitem><para><emphasis><filename>qt4x11</filename>:</emphasis>
-                Supports building against Qt/X11.</para></listitem>
-        </itemizedlist>
-    </para>
-
-    <para>
-        The classes inherit the
-        <link linkend='ref-classes-qmake*'><filename>qmake2</filename></link>
-        class.
-    </para>
-</section>
-
 <section id='ref-classes-recipe_sanity'>
     <title><filename>recipe_sanity.bbclass</filename></title>
 
@@ -2958,6 +2886,33 @@
     </para>
 </section>
 
+<section id='ref-classes-remove-libtool'>
+    <title><filename>remove-libtool.bbclass</filename></title>
+
+    <para>
+        The <filename>remove-libtool</filename> class adds a post function
+        to the
+        <link linkend='ref-tasks-install'><filename>do_install</filename></link>
+        task to remove all <filename>.la</filename> files installed by
+        <filename>libtool</filename>.
+        Removing these files results in them being absent from both the
+        sysroot and target packages.
+    </para>
+
+    <para>
+        If a recipe needs the <filename>.la</filename> files to be installed,
+        then the recipe can override the removal by setting
+        <filename>REMOVE_LIBTOOL_LA</filename> to "0" as follows:
+        <literallayout class='monospaced'>
+     REMOVE_LIBTOOL_LA = "0"
+        </literallayout>
+        <note>
+            The <filename>remove-libtool</filename> class is not enabled by
+            default.
+        </note>
+    </para>
+</section>
+
 <section id='ref-classes-report-error'>
     <title><filename>report-error.bbclass</filename></title>
 
@@ -3026,6 +2981,10 @@
         the root filesystem for an image and consist of the following classes:
         <itemizedlist>
             <listitem><para>
+                The <filename>rootfs-postcommands</filename> class, which
+                defines filesystem post-processing functions for image recipes.
+                </para></listitem>
+            <listitem><para>
                 The <filename>rootfs_deb</filename> class, which supports
                 creation of root filesystems for images built using
                 <filename>.deb</filename> packages.</para></listitem>
@@ -3225,10 +3184,10 @@
     <title><filename>staging.bbclass</filename></title>
 
     <para>
-        The <filename>staging</filename> class provides support for staging
-        files into the sysroot during the
+        The <filename>staging</filename> class provides the
         <link linkend='ref-tasks-populate_sysroot'><filename>do_populate_sysroot</filename></link>
-        task.
+        task, which stages files into the sysroot to make them available to
+        other recipes at build time.
         The class is enabled by default because it is inherited by the
         <link linkend='ref-classes-base'><filename>base</filename></link>
         class.
@@ -3398,6 +3357,20 @@
     </para>
 </section>
 
+<section id='ref-classes-testsdk'>
+    <title><filename>testsdk.bbclass</filename></title>
+
+    <para>
+        This class supports running automated tests against
+        software development kits (SDKs).
+        The <filename>testsdk</filename> class runs tests on an SDK when
+        called using the following:
+        <literallayout class='monospaced'>
+     $ bitbake -c testsdk image
+        </literallayout>
+    </para>
+</section>
+
 <section id='ref-classes-texinfo'>
     <title><filename>texinfo.bbclass</filename></title>
 
@@ -3498,14 +3471,23 @@
     <title><filename>uninative.bbclass</filename></title>
 
     <para>
-        Provides a means of reusing <filename>native/cross</filename> over
-        multiple distros.
-        <note>
-            Currently, the method used by the <filename>uninative</filename>
-            class is experimental.
-        </note>
-        For more information, see the commit message
-        <ulink url='http://cgit.openembedded.org/openembedded-core/commit/?id=e66c96ae9c7ba21ebd04a4807390f0031238a85a'>here</ulink>.
+        Attempts to isolate the build system from the host
+        distribution's C library in order to make re-use of native shared state
+        artifacts across different host distributions practical.
+        With this class enabled, a tarball containing a pre-built C library
+        is downloaded at the start of the build.
+        In the Poky reference distribution this is enabled by default
+        through
+        <filename>meta/conf/distro/include/yocto-uninative.inc</filename>.
+        Other distributions that do not derive from poky can also
+        "<filename>require conf/distro/include/yocto-uninative.inc</filename>"
+        to use this.
+        Alternatively if you prefer, you can build the uninative-tarball recipe
+        yourself, publish the resulting tarball (e.g. via HTTP) and set
+        <filename>UNINATIVE_URL</filename> and
+        <filename>UNINATIVE_CHECKSUM</filename> appropriately.
+        For an example, see the
+        <filename>meta/conf/distro/include/yocto-uninative.inc</filename>.
     </para>
 </section>
 
diff --git a/yocto-poky/documentation/ref-manual/ref-features.xml b/yocto-poky/documentation/ref-manual/ref-features.xml
index 798e0a2..fd76935 100644
--- a/yocto-poky/documentation/ref-manual/ref-features.xml
+++ b/yocto-poky/documentation/ref-manual/ref-features.xml
@@ -308,8 +308,12 @@
                 <listitem><para><emphasis>nfs-server:</emphasis>
                     Installs an NFS server.
                     </para></listitem>
-                <listitem><para><emphasis>qt4-pkgs:</emphasis>
-                    Supports Qt4/X11 and demo applications.
+                <listitem><para><emphasis>perf:</emphasis>
+                    Installs profiling tools such as
+                    <filename>perf</filename>, <filename>systemtap</filename>,
+                    and <filename>LTTng</filename>.
+                    For general information on user-space tools, see the
+                    <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-manual'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>.
                     </para></listitem>
                 <listitem><para><emphasis>ssh-server-dropbear:</emphasis>
                     Installs the Dropbear minimal SSH server.
@@ -331,15 +335,6 @@
                     For information on tracing and profiling, see the
                     <ulink url='&YOCTO_DOCS_PROF_URL;'>Yocto Project Profiling and Tracing Manual</ulink>.
                     </para></listitem>
-                <listitem><para><emphasis>tools-profile:</emphasis>
-                    Installs profiling tools such as
-                    <filename>oprofile</filename>, <filename>exmap</filename>,
-                    and <filename>LTTng</filename>.
-                    For general information on user-space tools, see the
-                    "<ulink url='&YOCTO_DOCS_ADT_URL;#user-space-tools'>User-Space Tools</ulink>"
-                    section in the Yocto Project Application Developer's
-                    Guide.
-                    </para></listitem>
                 <listitem><para><emphasis>tools-sdk:</emphasis>
                     Installs a full SDK that runs on the device.
                     </para></listitem>
diff --git a/yocto-poky/documentation/ref-manual/ref-images.xml b/yocto-poky/documentation/ref-manual/ref-images.xml
index d15ca5b..69b58f6 100644
--- a/yocto-poky/documentation/ref-manual/ref-images.xml
+++ b/yocto-poky/documentation/ref-manual/ref-images.xml
@@ -80,7 +80,7 @@
                 </para></listitem>
             <listitem><para><filename>core-image-lsb-sdk</filename>:
                 A <filename>core-image-lsb</filename> that includes everything in
-                meta-toolchain but also includes development headers and libraries
+                the cross-toolchain but also includes development headers and libraries
                 to form a complete standalone SDK.
                 This image requires a distribution configuration that
                 enables LSB compliance (e.g. <filename>poky-lsb</filename>).
@@ -114,7 +114,7 @@
                 tools appropriate for real-time use.</para></listitem>
             <listitem><para><filename>core-image-rt-sdk</filename>:
                 A <filename>core-image-rt</filename> image that includes everything in
-                <filename>meta-toolchain</filename>.
+                the cross-toolchain.
                 The image also includes development headers and libraries to form a complete
                 stand-alone SDK and is suitable for development using the target.
                 </para></listitem>
@@ -132,7 +132,8 @@
                 This image was formerly <filename>core-image-sdk</filename>.
                 </para></listitem>
             <listitem><para><filename>core-image-sato-sdk</filename>:
-                A <filename>core-image-sato</filename> image that includes everything in meta-toolchain.
+                A <filename>core-image-sato</filename> image that includes everything in
+                the cross-toolchain.
                 The image also includes development headers and libraries to form a complete standalone SDK
                 and is suitable for development using the target.</para></listitem>
             <listitem><para><filename>core-image-testmaster</filename>:
@@ -158,9 +159,6 @@
             <listitem><para><filename>core-image-x11</filename>:
                 A very basic X11 image with a terminal.
                 </para></listitem>
-            <listitem><para><filename>qt4e-demo-image</filename>:
-                An image that launches into the demo application for the embedded
-                (not based on X11) version of Qt.</para></listitem>
         </itemizedlist>
     </para>
 </chapter>
diff --git a/yocto-poky/documentation/ref-manual/ref-manual.xml b/yocto-poky/documentation/ref-manual/ref-manual.xml
index a296b9b..6834d5f 100644
--- a/yocto-poky/documentation/ref-manual/ref-manual.xml
+++ b/yocto-poky/documentation/ref-manual/ref-manual.xml
@@ -97,6 +97,11 @@
                 <date>October 2015</date>
                 <revremark>Released with the Yocto Project 2.0 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>2.1</revnumber>
+                <date>April 2016</date>
+                <revremark>Released with the Yocto Project 2.1 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>
diff --git a/yocto-poky/documentation/ref-manual/ref-qa-checks.xml b/yocto-poky/documentation/ref-manual/ref-qa-checks.xml
index 38689b9..4fcf1db 100644
--- a/yocto-poky/documentation/ref-manual/ref-qa-checks.xml
+++ b/yocto-poky/documentation/ref-manual/ref-qa-checks.xml
@@ -81,11 +81,13 @@
 
                 <para>
                     The specified package contains files in
-                    <filename>/usr/libexec</filename>.
-                    By default, <filename>libexecdir</filename> is set to
-                    "${libdir}/${BPN}" rather than to "/usr/libexec".
-                    Thus, installing to <filename>/usr/libexec</filename>
-                    is likely not desirable.
+                    <filename>/usr/libexec</filename> when the distro
+                    configuration uses a different path for
+                    <filename>&lt;libexecdir&gt;</filename>
+                    By default, <filename>&lt;libexecdir&gt;</filename> is
+                    <filename>$prefix/libexec</filename>.
+                    However, this default can be changed (e.g.
+                    <filename>${libdir}</filename>).
                 </para>
 
                 <para>
diff --git a/yocto-poky/documentation/ref-manual/ref-structure.xml b/yocto-poky/documentation/ref-manual/ref-structure.xml
index 48e3921..e51ceb1 100644
--- a/yocto-poky/documentation/ref-manual/ref-structure.xml
+++ b/yocto-poky/documentation/ref-manual/ref-structure.xml
@@ -123,8 +123,8 @@
         </para>
     </section>
 
-    <section id='structure-core-meta-yocto'>
-        <title><filename>meta-yocto/</filename></title>
+    <section id='structure-core-meta-poky'>
+        <title><filename>meta-poky/</filename></title>
 
         <para>
             This directory contains the configuration for the Poky
@@ -227,14 +227,13 @@
          core-image-minimal
          core-image-sato
          meta-toolchain
-         adt-installer
          meta-ide-support
 
      You can also run generated qemu images with a command like 'runqemu qemux86'
             </literallayout>
             The script gets its default list of common targets from the
             <filename>conf-notes.txt</filename> file, which is found in the
-            <filename>meta-yocto</filename> directory within the
+            <filename>meta-poky</filename> directory within the
             <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
             Should you have custom distributions, it is very easy to modify
             this configuration file to include your targets for your
@@ -261,7 +260,7 @@
             </literallayout>
             The OpenEmbedded build system uses the template configuration
             files, which are found by default in the
-            <filename>meta-yocto/conf</filename> directory in the
+            <filename>meta-poky/conf</filename> directory in the
             <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
             See the
             "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-custom-template-configuration-directory'>Creating a Custom Template Configuration Directory</ulink>"
@@ -366,7 +365,6 @@
          core-image-minimal
          core-image-sato
          meta-toolchain
-         adt-installer
          meta-ide-support
 
      You can also run generated qemu images with a command like 'runqemu qemux86'
@@ -375,7 +373,7 @@
             </literallayout>
             The script gets its default list of common targets from the
             <filename>conf-notes.txt</filename> file, which is found in the
-            <filename>meta-yocto</filename> directory within the
+            <filename>meta-poky</filename> directory within the
             <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
             Should you have custom distributions, it is very easy to modify
             this configuration file to include your targets for your
@@ -411,7 +409,7 @@
         <para>
             The OpenEmbedded build system uses the template configuration
             files, which are found by default in the
-            <filename>meta-yocto/conf</filename> directory in the
+            <filename>meta-poky/conf</filename> directory in the
             <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
             See the
             "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-custom-template-configuration-directory'>Creating a Custom Template Configuration Directory</ulink>"
@@ -515,7 +513,7 @@
         <para>
             The source <filename>local.conf.sample</filename> file used
             depends on the <filename>$TEMPLATECONF</filename> script variable,
-            which defaults to <filename>meta-yocto/conf</filename>
+            which defaults to <filename>meta-poky/conf</filename>
             when you are building from the Yocto Project development
             environment and defaults to <filename>meta/conf</filename> when
             you are building from the OpenEmbedded Core environment.
@@ -538,7 +536,7 @@
                 <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
                 You can find the Yocto Project version of the
                 <filename>local.conf.sample</filename> file in the
-                <filename>meta-yocto/conf</filename> directory.
+                <filename>meta-poky/conf</filename> directory.
             </note>
         </para>
     </section>
@@ -569,7 +567,7 @@
         <para>
             The source <filename>bblayers.conf.sample</filename> file used
             depends on the <filename>$TEMPLATECONF</filename> script variable,
-            which defaults to <filename>meta-yocto/conf</filename>
+            which defaults to <filename>meta-poky/conf</filename>
             when you are building from the Yocto Project development
             environment and defaults to <filename>meta/conf</filename> when
             you are building from the OpenEmbedded Core environment.
@@ -590,7 +588,7 @@
                 <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
                 You can find the Yocto Project version of the
                 <filename>bblayers.conf.sample</filename> file in the
-                <filename>meta-yocto/conf</filename> directory.
+                <filename>meta-poky/conf</filename> directory.
             </note>
         </para>
     </section>
@@ -738,8 +736,7 @@
         <para>
             Be careful when deleting files in this directory.
             You can safely delete old images from this directory (e.g.
-            <filename>core-image-*</filename>, <filename>hob-image-*</filename>,
-            etc.).
+            <filename>core-image-*</filename>).
             However, the kernel (<filename>*zImage*</filename>, <filename>*uImage*</filename>, etc.),
             bootloader and other supplementary files might be deployed here prior to building an
             image.
@@ -767,8 +764,8 @@
             toolchain installer scripts, which when executed, install the
             sysroot that matches your target hardware.
             You can find out more about these installers in the
-            "<ulink url='&YOCTO_DOCS_ADT_URL;#optionally-building-a-toolchain-installer'>Optionally Building a Toolchain Installer</ulink>"
-            section in the Yocto Project Application Developer's Guide.
+            "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-building-an-sdk-installer'>Building an SDK Installer</ulink>"
+            section in the Yocto Project Software Development Kit (SDK) Developer's Guide.
         </para>
     </section>
 
@@ -1091,14 +1088,6 @@
         </para>
     </section>
 
-    <section id='structure-meta-recipes-qt'>
-        <title><filename>meta/recipes-qt/</filename></title>
-
-        <para>
-            This directory contains all things related to the Qt application framework.
-        </para>
-    </section>
-
     <section id='structure-meta-recipes-rt'>
         <title><filename>meta/recipes-rt/</filename></title>
 
diff --git a/yocto-poky/documentation/ref-manual/ref-tasks.xml b/yocto-poky/documentation/ref-manual/ref-tasks.xml
index 21403c0..c46debb 100644
--- a/yocto-poky/documentation/ref-manual/ref-tasks.xml
+++ b/yocto-poky/documentation/ref-manual/ref-tasks.xml
@@ -31,6 +31,36 @@
         </para>
     </section>
 
+    <section id='ref-tasks-checkpkg'>
+        <title><filename>do_checkpkg</filename></title>
+
+        <para>
+            Provides information about the recipe including its upstream
+            version and status.
+            The upstream version and status reveals whether or not a version
+            of the recipe exists upstream and a status of not updated, updated,
+            or unknown.
+        </para>
+
+        <para>
+            The <filename>checkpkg</filename> task is included as part of the
+            <link linkend='ref-classes-distrodata'><filename>distrodata</filename></link>
+            class.
+        </para>
+
+        <para>
+            To build the <filename>checkpkg</filename> task, use the
+            <filename>bitbake</filename> command with the "-c" option and
+            task name:
+            <literallayout class='monospaced'>
+     $ bitbake core-image-minimal -c checkpkg
+            </literallayout>
+            By default, the results are stored in
+            <link linkend='var-LOG_DIR'><filename>$LOG_DIR</filename></link>
+            (e.g. <filename>$BUILD_DIR/tmp/log</filename>).
+        </para>
+    </section>
+
     <section id='ref-tasks-compile'>
         <title><filename>do_compile</filename></title>
 
@@ -87,6 +117,32 @@
         </para>
     </section>
 
+    <section id='ref-tasks-distrodata'>
+        <title><filename>do_distrodata</filename></title>
+
+        <para>
+            Provides information about the recipe.
+        </para>
+
+        <para>
+            The <filename>distrodata</filename> task is included as part of the
+            <link linkend='ref-classes-distrodata'><filename>distrodata</filename></link>
+            class.
+        </para>
+
+        <para>
+            To build the <filename>distrodata</filename> task, use the
+            <filename>bitbake</filename> command with the "-c" option and
+            task name:
+            <literallayout class='monospaced'>
+     $ bitbake core-image-minimal -c distrodata
+            </literallayout>
+            By default, the results are stored in
+            <link linkend='var-LOG_DIR'><filename>$LOG_DIR</filename></link>
+            (e.g. <filename>$BUILD_DIR/tmp/log</filename>).
+        </para>
+    </section>
+
     <section id='ref-tasks-fetch'>
         <title><filename>do_fetch</filename></title>
 
@@ -99,6 +155,60 @@
         </para>
     </section>
 
+    <section id='ref-tasks-image'>
+        <title><filename>do_image</filename></title>
+
+        <para>
+            Starts the image generation process.
+            The <filename>do_image</filename> task runs after the
+            OpenEmbedded build system has run the
+            <link linkend='ref-tasks-rootfs'><filename>do_rootfs</filename></link>
+            task during which packages are identified for installation into
+            the image and the root filesystem is created, complete with
+            post-processing.
+        </para>
+
+        <para>
+            The <filename>do_image</filename> task performs pre-processing
+            on the image through the
+            <link linkend='var-IMAGE_PREPROCESS_COMMAND'><filename>IMAGE_PREPROCESS_COMMAND</filename></link>
+            and dynamically generates supporting
+            <filename>do_image_*</filename> tasks as needed.
+        </para>
+
+        <para>
+            For more information on image creation, see the
+            "<link linkend='image-generation-dev-environment'>Image Generation</link>"
+            section.
+        </para>
+    </section>
+
+    <section id='ref-tasks-image-complete'>
+        <title><filename>do_image_complete</filename></title>
+
+        <para>
+            Completes the image generation process.
+            The <filename>do_image_complete</filename> task runs after the
+            OpenEmbedded build system has run the
+            <link linkend='ref-tasks-rootfs'><filename>do_image</filename></link>
+            task during which image pre-processing occurs and through
+            dynamically generated <filename>do_image_*</filename> tasks the
+            image is constructed.
+        </para>
+
+        <para>
+            The <filename>do_image_complete</filename> task performs
+            post-processing on the image through the
+            <link linkend='var-IMAGE_POSTPROCESS_COMMAND'><filename>IMAGE_POSTPROCESS_COMMAND</filename></link>.
+        </para>
+
+        <para>
+            For more information on image creation, see the
+            "<link linkend='image-generation-dev-environment'>Image Generation</link>"
+            section.
+        </para>
+    </section>
+
     <section id='ref-tasks-install'>
         <title><filename>do_install</filename></title>
 
@@ -239,10 +349,16 @@
         <title><filename>do_populate_sysroot</filename></title>
 
         <para>
-            Copies a subset of files installed by the
+            Copies a subset of the files installed by the
             <link linkend='ref-tasks-install'><filename>do_install</filename></link>
-            task into the sysroot in order to make them available to other
-            recipes.
+            task into the sysroot to make them available to other recipes.
+            Files that would typically not be needed by other recipes at build
+            time are skipped.
+            Skipped files include files installed into
+            <filename>/etc.</filename>
+            For information on what files are copied, see the
+            <link linkend='ref-classes-staging'><filename>staging</filename></link>
+            class.
         </para>
 
         <para>
@@ -700,15 +816,6 @@
         The following sections describe miscellaneous tasks.
     </para>
 
-    <section id='ref-tasks-generate_qt_config_file'>
-        <title><filename>do_generate_qt_config_file</filename></title>
-
-        <para>
-            Writes a <filename>qt.conf</filename> configuration
-            file used for building a Qt-based application.
-        </para>
-    </section>
-
     <section id='ref-tasks-spdx'>
         <title><filename>do_spdx</filename></title>
 
diff --git a/yocto-poky/documentation/ref-manual/ref-variables.xml b/yocto-poky/documentation/ref-manual/ref-variables.xml
index 0b2c426..d55bccd 100644
--- a/yocto-poky/documentation/ref-manual/ref-variables.xml
+++ b/yocto-poky/documentation/ref-manual/ref-variables.xml
@@ -32,7 +32,7 @@
 <!--               <link linkend='var-glossary-n'>N</link> -->
        <link linkend='var-OBJCOPY'>O</link>
        <link linkend='var-P'>P</link>
-       <link linkend='var-QMAKE_PROFILES'>Q</link>
+<!--               <link linkend='var-glossary-q'>Q</link> -->
        <link linkend='var-RANLIB'>R</link>
        <link linkend='var-S'>S</link>
        <link linkend='var-T'>T</link>
@@ -1130,24 +1130,11 @@
                     <literallayout class='monospaced'>
      BBLAYERS = " \
        /home/scottrif/poky/meta \
-       /home/scottrif/poky/meta-yocto \
+       /home/scottrif/poky/meta-poky \
        /home/scottrif/poky/meta-yocto-bsp \
        /home/scottrif/poky/meta-mykernel \
        "
-
-     BBLAYERS_NON_REMOVABLE ?= " \
-       /home/scottrif/poky/meta \
-       /home/scottrif/poky/meta-yocto \
-       "
                     </literallayout>
-                    <note>
-                        The
-                        <link linkend='var-BBLAYERS_NON_REMOVABLE'><filename>BBLAYERS_NON_REMOVABLE</filename></link>
-                        variable exists only for
-                        <ulink url='https://www.yoctoproject.org/tools-resources/projects/hob'>Hob</ulink>.
-                        The OpenEmbedded build system does not use this
-                        variable.
-                    </note>
                 </para>
 
                 <para>
@@ -1157,60 +1144,15 @@
             </glossdef>
         </glossentry>
 
-        <glossentry id='var-BBLAYERS_NON_REMOVABLE'><glossterm>BBLAYERS_NON_REMOVABLE</glossterm>
-            <info>
-                BBLAYERS_NON_REMOVABLE[doc] = "Lists core layers that cannot be removed from the bblayers.conf file."
-            </info>
-            <glossdef>
-                <para role="glossdeffirst">
-<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
-                    Lists core layers that cannot be removed from the
-                    <filename>bblayers.conf</filename> file during a build
-                    using the
-                    <ulink url='https://www.yoctoproject.org/tools-resources/projects/hob'>Hob</ulink>.
-                    <note>
-                        When building an image outside of Hob, the OpenEmbedded
-                        build system ignores this variable.
-                    </note>
-                </para>
-
-                <para>
-                    In order for BitBake to build your image using Hob, your
-                    <filename>bblayers.conf</filename> file must include the
-                    <filename>meta</filename> and <filename>meta-yocto</filename>
-                    core layers.
-                    Here is an example that shows these two layers listed in
-                    the <filename>BBLAYERS_NON_REMOVABLE</filename> statement:
-                    <literallayout class='monospaced'>
-     BBLAYERS = " \
-       /home/scottrif/poky/meta \
-       /home/scottrif/poky/meta-yocto \
-       /home/scottrif/poky/meta-yocto-bsp \
-       /home/scottrif/poky/meta-mykernel \
-       "
-
-     BBLAYERS_NON_REMOVABLE ?= " \
-       /home/scottrif/poky/meta \
-       /home/scottrif/poky/meta-yocto \
-       "
-                    </literallayout>
-                </para>
-            </glossdef>
-        </glossentry>
-
         <glossentry id='var-BBMASK'><glossterm>BBMASK</glossterm>
             <info>
-                BBMASK[doc] = "Prevents BitBake from processing specific recipes or recipe append files. Use the BBMASK variable from within conf/local.conf."
+                BBMASK[doc] = "Prevents BitBake from processing specific recipes or recipe append files."
             </info>
             <glossdef>
                 <para role="glossdeffirst">
 <!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
                     Prevents BitBake from processing recipes and recipe
                     append files.
-                    Use the <filename>BBMASK</filename> variable from within the
-                    <filename>conf/local.conf</filename> file found
-                    in the
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
                 </para>
 
                 <para>
@@ -1218,14 +1160,14 @@
                     to "hide" these <filename>.bb</filename> and
                     <filename>.bbappend</filename> files.
                     BitBake ignores any recipe or recipe append files that
-                    match the expression.
+                    match any of the expressions.
                     It is as if BitBake does not see them at all.
                     Consequently, matching files are not parsed or otherwise
                     used by BitBake.</para>
                 <para>
-                    The value you provide is passed to Python's regular
+                    The values you provide are passed to Python's regular
                     expression compiler.
-                    The expression is compared against the full paths to
+                    The expressions are compared against the full paths to
                     the files.
                     For complete syntax information, see Python's
                     documentation at
@@ -1241,18 +1183,16 @@
      BBMASK = "meta-ti/recipes-misc/"
                     </literallayout>
                     If you want to mask out multiple directories or recipes,
-                    use the vertical bar to separate the regular expression
-                    fragments.
+                    you can specify multiple regular expression fragments.
                     This next example masks out multiple directories and
                     individual recipes:
                     <literallayout class='monospaced'>
-     BBMASK = "meta-ti/recipes-misc/|meta-ti/recipes-ti/packagegroup/"
-     BBMASK .= "|.*meta-oe/recipes-support/"
-     BBMASK .= "|.*openldap"
-     BBMASK .= "|.*opencv"
-     BBMASK .= "|.*lzma"
+     BBMASK += "/meta-ti/recipes-misc/ meta-ti/recipes-ti/packagegroup/"
+     BBMASK += "/meta-oe/recipes-support/"
+     BBMASK += "/meta-foo/.*/openldap"
+     BBMASK += "opencv.*\.bbappend"
+     BBMASK += "lzma"
                     </literallayout>
-                    Notice how the vertical bar is used to append the fragments.
                     <note>
                         When specifying a directory name, use the trailing
                         slash character to ensure you match just that directory
@@ -1402,15 +1342,22 @@
                 <para role="glossdeffirst">
 <!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
                     The bare name of the recipe.
-                    This variable is a version of the <link linkend='var-PN'><filename>PN</filename></link> variable
-                    but removes common suffixes such as "-native" and "-cross" as well
-                    as removes common prefixes such as multilib's "lib64-" and "lib32-".
+                    This variable is a version of the
+                    <link linkend='var-PN'><filename>PN</filename></link>
+                    variable but removes common suffixes such as
+                    <filename>-native</filename> and
+                    <filename>-cross</filename> as well
+                    as removes common prefixes such as multilib's
+                    <filename>lib64-</filename> and
+                    <filename>lib32-</filename>.
                     The exact list of suffixes removed is specified by the
-                    <link linkend='var-SPECIAL_PKGSUFFIX'><filename>SPECIAL_PKGSUFFIX</filename></link> variable.
+                    <link linkend='var-SPECIAL_PKGSUFFIX'><filename>SPECIAL_PKGSUFFIX</filename></link>
+                    variable.
                     The exact list of prefixes removed is specified by the
-                    <link linkend='var-MLPREFIX'><filename>MLPREFIX</filename></link> variable.
+                    <link linkend='var-MLPREFIX'><filename>MLPREFIX</filename></link>
+                    variable.
                     Prefixes are removed for <filename>multilib</filename>
-                    and <filename>nativesdk</filename> cases.
+                    and <filename>nativesdk-</filename> cases.
                 </para>
             </glossdef>
         </glossentry>
@@ -1473,7 +1420,7 @@
                     Specifies the flags to pass to the C pre-processor
                     (i.e. to both the C and the C++ compilers) when building
                     for the build host.
-                    When building in the <filename>native</filename> context,
+                    When building in the <filename>-native</filename> context,
                     <link linkend='var-CPPFLAGS'><filename>CPPFLAGS</filename></link>
                     is set to the value of this variable by default.
                 </para>
@@ -1489,7 +1436,7 @@
 <!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
                     Specifies the flags to pass to the C++ compiler when
                     building for the build host.
-                    When building in the <filename>native</filename> context,
+                    When building in the <filename>-native</filename> context,
                     <link linkend='var-CXXFLAGS'><filename>CXXFLAGS</filename></link>
                     is set to the value of this variable by default.
                 </para>
@@ -1564,7 +1511,7 @@
                     The OpenEmbedded build system uses the
                     <filename>BUILD_PREFIX</filename> value to set the
                     <link linkend='var-TARGET_PREFIX'><filename>TARGET_PREFIX</filename></link>
-                    when building for native recipes.
+                    when building for <filename>native</filename> recipes.
                 </para>
             </glossdef>
         </glossentry>
@@ -1845,7 +1792,7 @@
 <!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
                     Specifies the flags to pass to the C compiler when building
                     for the SDK.
-                    When building in the <filename>nativesdk</filename>
+                    When building in the <filename>nativesdk-</filename>
                     context,
                     <link linkend='var-CFLAGS'><filename>CFLAGS</filename></link>
                     is set to the value of this variable by default.
@@ -1863,7 +1810,7 @@
                     Specifies the flags to pass to the C pre-processor
                     (i.e. to both the C and the C++ compilers) when building
                     for the SDK.
-                    When building in the <filename>nativesdk</filename>
+                    When building in the <filename>nativesdk-</filename>
                     context,
                     <link linkend='var-CPPFLAGS'><filename>CPPFLAGS</filename></link>
                     is set to the value of this variable by default.
@@ -1880,7 +1827,7 @@
 <!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
                     Specifies the flags to pass to the C++ compiler when
                     building for the SDK.
-                    When building in the <filename>nativesdk</filename>
+                    When building in the <filename>nativesdk-</filename>
                     context,
                     <link linkend='var-CXXFLAGS'><filename>CXXFLAGS</filename></link>
                     is set to the value of this variable by default.
@@ -2037,7 +1984,7 @@
                     and then can be used as an override.
                     Here is an example where "python-native" is added to
                     <link linkend='var-DEPENDS'><filename>DEPENDS</filename></link>
-                    only when building for the native case:
+                    only when building for the <filename>-native</filename> case:
                     <literallayout class='monospaced'>
      DEPENDS_append_class-native = " python-native"
                     </literallayout>
@@ -2354,7 +2301,20 @@
                     <filename>/usr/share/common-licenses</filename>,
                     for each package.
                     The license files are placed
-                    in directories within the image itself.
+                    in directories within the image itself during build time.
+                    <note>
+                        The <filename>COPY_LIC_DIRS</filename> does not
+                        offer a path for adding licenses for newly installed
+                        packages to an image, which might be most suitable
+                        for read-only filesystems that cannot be upgraded.
+                        See the
+                        <link linkend='var-LICENSE_CREATE_PACKAGE'><filename>LICENSE_CREATE_PACKAGE</filename></link>
+                        variable for additional information.
+                        You can also reference the
+                        "<ulink url='&YOCTO_DOCS_DEV_URL;#providing-license-text'>Providing License Text</ulink>"
+                        section in the Yocto Project Development Manual for
+                        information on providing license text.
+                    </note>
                 </para>
             </glossdef>
         </glossentry>
@@ -2369,7 +2329,20 @@
                     If set to "1", the OpenEmbedded build system copies
                     the license manifest for the image to
                     <filename>/usr/share/common-licenses/license.manifest</filename>
-                    within the image itself.
+                    within the image itself during build time.
+                    <note>
+                        The <filename>COPY_LIC_MANIFEST</filename> does not
+                        offer a path for adding licenses for newly installed
+                        packages to an image, which might be most suitable
+                        for read-only filesystems that cannot be upgraded.
+                        See the
+                        <link linkend='var-LICENSE_CREATE_PACKAGE'><filename>LICENSE_CREATE_PACKAGE</filename></link>
+                        variable for additional information.
+                        You can also reference the
+                        "<ulink url='&YOCTO_DOCS_DEV_URL;#providing-license-text'>Providing License Text</ulink>"
+                        section in the Yocto Project Development Manual for
+                        information on providing license text.
+                    </note>
                 </para>
             </glossdef>
         </glossentry>
@@ -2420,6 +2393,35 @@
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-COREBASE_FILES'><glossterm>COREBASE_FILES</glossterm>
+            <info>
+                COREBASE_FILES[doc] = "Lists files from the COREBASE directory that should be copied other than the layers listed in the bblayers.conf file."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    Lists files from the
+                    <link linkend='var-COREBASE'><filename>COREBASE</filename></link>
+                    directory that should be copied other than the layers
+                    listed in the <filename>bblayers.conf</filename> file.
+                    The <filename>COREBASE_FILES</filename> variable exists
+                    for the purpose of copying metadata from the
+                    OpenEmbedded build system into the extensible
+                    SDK.
+                </para>
+
+                <para>
+                    Explicitly listing files in <filename>COREBASE</filename>
+                    is needed because it typically contains build
+                    directories and other files that should not normally
+                    be copied into the extensible SDK.
+                    Consequently, the value of
+                    <filename>COREBASE_FILES</filename> is used in order to
+                    only copy the files that are actually needed.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-CPP'><glossterm>CPP</glossterm>
             <info>
                 CPP[doc] = "Minimum command and arguments to run the C preprocessor."
@@ -2547,7 +2549,7 @@
                         <listitem><para>
                             <link linkend='var-BUILDSDK_CXXFLAGS'><filename>BUILDSDK_CXXFLAGS</filename></link>
                             when building for an SDK (i.e.
-                            <filename>nativesdk</filename>)
+                            <filename>nativesdk-</filename>)
                             </para></listitem>
                     </itemizedlist>
                 </para>
@@ -3110,7 +3112,7 @@
                     For example, the distribution configuration file for the
                     Poky distribution is named <filename>poky.conf</filename>
                     and resides in the
-                    <filename>meta-yocto/conf/distro</filename> directory of
+                    <filename>meta-poky/conf/distro</filename> directory of
                     the
                     <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
                 </para>
@@ -3413,6 +3415,9 @@
                     see this specific question in the
                     "<link linkend='how-does-the-yocto-project-obtain-source-code-and-will-it-work-behind-my-firewall-or-proxy-server'>FAQ</link>"
                     chapter.
+                    You can also refer to the
+                    "<ulink url='&YOCTO_WIKI_URL;/wiki/Working_Behind_a_Network_Proxy'>Working Behind a Network Proxy</ulink>"
+                    Wiki page.
                 </para>
             </glossdef>
         </glossentry>
@@ -3814,9 +3819,6 @@
 "tools-debug" - Adds debugging tools such as gdb and
                 strace.
 
-"tools-profile" - Adds profiling tools such as oprofile,
-                  exmap, lttng and valgrind (x86 only).
-
 "tools-sdk" - Adds development tools such as gcc, make,
               pkgconfig and so forth.
 
@@ -3924,6 +3926,12 @@
 <!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
                     Additional GNU <filename>make</filename> options.
                 </para>
+
+                <para>
+                    Because the <filename>EXTRA_OEMAKE</filename> defaults to
+                    "", you need to set the variable to specify any required
+                    GNU options.
+                </para>
             </glossdef>
         </glossentry>
 
@@ -3943,50 +3951,6 @@
             </glossdef>
         </glossentry>
 
-        <glossentry id='var-EXTRA_QMAKEVARS_POST'><glossterm>EXTRA_QMAKEVARS_POST</glossterm>
-            <info>
-                EXTRA_QMAKEVARS_POST[doc] = "Configuration variables or options you want to pass to qmake when the arguments need to be after the .pro file list on the command line."
-            </info>
-            <glossdef>
-                <para role="glossdeffirst">
-<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
-                    Configuration variables or options you want to pass to
-                    <filename>qmake</filename>.
-                    Use this variable when the arguments need to be after the
-                    <filename>.pro</filename> file list on the command line.
-                </para>
-
-                <para>
-                    This variable is used with recipes that inherit the
-                    <link linkend='ref-classes-qmake*'><filename>qmake_base</filename></link>
-                    class or other classes that inherit
-                    <filename>qmake_base</filename>.
-                </para>
-            </glossdef>
-        </glossentry>
-
-       <glossentry id='var-EXTRA_QMAKEVARS_PRE'><glossterm>EXTRA_QMAKEVARS_PRE</glossterm>
-            <info>
-                EXTRA_QMAKEVARS_PRE[doc] = "Configuration variables or options you want to pass to qmake when the arguments need to be before the .pro file list on the command line."
-            </info>
-            <glossdef>
-                <para role="glossdeffirst">
-<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
-                    Configuration variables or options you want to pass to
-                    <filename>qmake</filename>.
-                    Use this variable when the arguments need to be before the
-                    <filename>.pro</filename> file list on the command line.
-                </para>
-
-                <para>
-                    This variable is used with recipes that inherit the
-                    <link linkend='ref-classes-qmake*'><filename>qmake_base</filename></link>
-                    class or other classes that inherit
-                    <filename>qmake_base</filename>.
-                </para>
-            </glossdef>
-        </glossentry>
-
         <glossentry id='var-EXTRA_USERS_PARAMS'><glossterm>EXTRA_USERS_PARAMS</glossterm>
             <info>
                 EXTRA_USERS_PARAMS[doc] = "When a recipe inherits the extrausers class, this variable provides image level user and group operations."
@@ -4760,12 +4724,12 @@
                         <listitem><para>
                             <filename>BUILD_CC_ARCH</filename>
                             when building for the build host (i.e.
-                            <filename>native</filename>)
+                            <filename>-native</filename>)
                             </para></listitem>
                         <listitem><para>
                             <filename>BUILDSDK_CC_ARCH</filename>
                             when building for an SDK (i.e.
-                            <filename>nativesdk</filename>)
+                            <filename>nativesdk-</filename>)
                             </para></listitem>
                     </itemizedlist>
                 </para>
@@ -5523,7 +5487,7 @@
 
                 <para>
                     The
-                    <link linkend='ref-classes-populate-sdk-*'><filename>package_sdk_base</filename></link>
+                    <link linkend='ref-classes-populate-sdk-*'><filename>populate_sdk_*</filename></link>
                     and
                     <link linkend='ref-classes-image'><filename>image</filename></link>
                     classes use the <filename>IMAGE_PKGTYPE</filename> for
@@ -5916,6 +5880,43 @@
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-INHERIT'><glossterm>INHERIT</glossterm>
+            <info>
+                INHERIT[doc] = "Causes the named class to be inherited at this point during parsing. The variable is only valid in configuration files."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    Causes the named class to be inherited at
+                    this point during parsing.
+                    The variable is only valid in configuration files.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-INHERIT_DISTRO'><glossterm>INHERIT_DISTRO</glossterm>
+            <info>
+                INHERIT_DISTRO[doc] = "Lists classes that will be inherited at the distribution level. It is unlikely that you want to edit this variable."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    Lists classes that will be inherited at the
+                    distribution level.
+                    It is unlikely that you want to edit this variable.
+                </para>
+
+                <para>
+                    The default value of the variable is set as follows in the
+                    <filename>meta/conf/distro/defaultsetup.conf</filename>
+                    file:
+                    <literallayout class='monospaced'>
+     INHERIT_DISTRO ?= "debian devshell sstate license"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-INHIBIT_DEFAULT_DEPS'><glossterm>INHIBIT_DEFAULT_DEPS</glossterm>
             <info>
                 INHIBIT_DEFAULT_DEPS[doc] = "Prevents the default dependencies, namely the C compiler and standard C library (libc), from being added to DEPENDS."
@@ -5980,43 +5981,6 @@
             </glossdef>
         </glossentry>
 
-        <glossentry id='var-INHERIT'><glossterm>INHERIT</glossterm>
-            <info>
-                INHERIT[doc] = "Causes the named class to be inherited at this point during parsing. The variable is only valid in configuration files."
-            </info>
-            <glossdef>
-                <para role="glossdeffirst">
-<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
-                    Causes the named class to be inherited at
-                    this point during parsing.
-                    The variable is only valid in configuration files.
-                </para>
-            </glossdef>
-        </glossentry>
-
-        <glossentry id='var-INHERIT_DISTRO'><glossterm>INHERIT_DISTRO</glossterm>
-            <info>
-                INHERIT_DISTRO[doc] = "Lists classes that will be inherited at the distribution level. It is unlikely that you want to edit this variable."
-            </info>
-            <glossdef>
-                <para role="glossdeffirst">
-<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
-                    Lists classes that will be inherited at the
-                    distribution level.
-                    It is unlikely that you want to edit this variable.
-                </para>
-
-                <para>
-                    The default value of the variable is set as follows in the
-                    <filename>meta/conf/distro/defaultsetup.conf</filename>
-                    file:
-                    <literallayout class='monospaced'>
-     INHERIT_DISTRO ?= "debian devshell sstate license"
-                    </literallayout>
-                </para>
-            </glossdef>
-        </glossentry>
-
         <glossentry id='var-INITRAMFS_FSTYPES'><glossterm>INITRAMFS_FSTYPES</glossterm>
             <info>
                 INITRAMFS_FSTYPES[doc] = "Defines the format for the output image of an initial RAM disk (initramfs), which is used during boot."
@@ -6071,7 +6035,7 @@
 
                 <para>
                     See the
-                    <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta-yocto/conf/local.conf.sample.extended'><filename>local.conf.sample.extended</filename></ulink>
+                    <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta-poky/conf/local.conf.sample.extended'><filename>local.conf.sample.extended</filename></ulink>
                     file for additional information.
                     You can also reference the
                     <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta/classes/kernel.bbclass'><filename>kernel.bbclass</filename></ulink>
@@ -6125,7 +6089,7 @@
                         You cannot set the variable in a recipe file.
                     </note>
                     See the
-                    <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta-yocto/conf/local.conf.sample.extended'><filename>local.conf.sample.extended</filename></ulink>
+                    <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta-poky/conf/local.conf.sample.extended'><filename>local.conf.sample.extended</filename></ulink>
                     file for additional information.
                 </para>
             </glossdef>
@@ -6145,7 +6109,7 @@
                 <para>
                     The <filename>INITRD</filename> variable is an optional
                     variable used with the
-                    <link linkend='ref-classes-bootimg'><filename>bootimg</filename></link>
+                    <link linkend='ref-classes-image-live'><filename>image-live</filename></link>
                     class.
                 </para>
             </glossdef>
@@ -6277,6 +6241,22 @@
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-INSTALL_TIMEZONE_FILE'><glossterm>INSTALL_TIMEZONE_FILE</glossterm>
+            <info>
+                INSTALL_TIMEZONE_FILE[doc] = "Enables installation of the /etc/timezone file."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    By default, the <filename>tzdata</filename> recipe packages
+                    an <filename>/etc/timezone</filename> file.
+                    Set the <filename>INSTALL_TIMEZONE_FILE</filename>
+                    variable to "0" at the configuration level to disable this
+                    behavior.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-IPK_FEED_URIS'><glossterm>IPK_FEED_URIS</glossterm>
             <info>
                 IPK_FEED_URIS[doc] = "List of ipkg feed records to put into generated image."
@@ -7179,6 +7159,49 @@
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-LICENSE_CREATE_PACKAGE'><glossterm>LICENSE_CREATE_PACKAGE</glossterm>
+            <info>
+                LICENSE_CREATE_PACKAGE[doc] = "Creates an extra package (i.e. ${PN}-lic) for each recipe and adds that package to the RRECOMMENDS+${PN}."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                        Setting <filename>LICENSE_CREATE_PACKAGE</filename>
+                        to "1" causes the OpenEmbedded build system to create
+                        an extra package (i.e.
+                        <filename>${</filename><link linkend='var-PN'><filename>PN</filename></link><filename>}-lic</filename>)
+                        for each recipe and to add those packages to the
+                        <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link><filename>_${PN}</filename>.
+                </para>
+
+                <para>
+                    The <filename>${PN}-lic</filename> package installs a
+                    directory in <filename>/usr/share/licenses</filename>
+                    named <filename>${PN}</filename>, which is the recipe's
+                    base name, and installs files in that directory that
+                    contain license and copyright information (i.e. copies of
+                    the appropriate license files from
+                    <filename>meta/common-licenses</filename> that match the
+                    licenses specified in the
+                    <link linkend='var-LICENSE'><filename>LICENSE</filename></link>
+                    variable of the recipe metadata and copies of files marked
+                    in
+                    <link linkend='var-LIC_FILES_CHKSUM'><filename>LIC_FILES_CHKSUM</filename></link>
+                    as containing license text).
+                </para>
+
+                <para>
+                    For related information on providing license text, see the
+                    <link linkend='var-COPY_LIC_DIRS'><filename>COPY_LIC_DIRS</filename></link>
+                    variable, the
+                    <link linkend='var-COPY_LIC_MANIFEST'><filename>COPY_LIC_MANIFEST</filename></link>
+                    variable, and the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#providing-license-text'>Providing License Text</ulink>"
+                    section in the Yocto Project Development Manual.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-LICENSE_FLAGS'><glossterm>LICENSE_FLAGS</glossterm>
             <info>
                 LICENSE_FLAGS[doc] = "Specifies additional flags for a recipe you must whitelist through LICENSE_FLAGS_WHITELIST in order to allow the recipe to be built."
@@ -7774,7 +7797,7 @@
                     is "poky", the default value for
                     <filename>MIRRORS</filename> is defined in the
                     <filename>conf/distro/poky.conf</filename> file in the
-                    <filename>meta-yocto</filename> Git repository.
+                    <filename>meta-poky</filename> Git repository.
                 </para>
             </glossdef>
         </glossentry>
@@ -8066,7 +8089,7 @@
                     Causes the OpenEmbedded build system to skip building the
                     <filename>.hddimg</filename> image.
                     The <filename>NOHDD</filename> variable is used with the
-                    <link linkend='ref-classes-bootimg'><filename>bootimg</filename></link>
+                    <link linkend='ref-classes-image-live'><filename>image-live</filename></link>
                     class.
                     Set the variable to "1" to prevent the
                     <filename>.hddimg</filename> image from being built.
@@ -8084,7 +8107,7 @@
                     Causes the OpenEmbedded build system to skip building the
                     ISO image.
                     The <filename>NOISO</filename> variable is used with the
-                    <link linkend='ref-classes-bootimg'><filename>bootimg</filename></link>
+                    <link linkend='ref-classes-image-live'><filename>image-live</filename></link>
                     class.
                     Set the variable to "1" to prevent the ISO image from
                     being built.
@@ -8176,6 +8199,28 @@
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-OE_INIT_ENV_SCRIPT'><glossterm>OE_INIT_ENV_SCRIPT</glossterm>
+            <info>
+                OE_INIT_ENV_SCRIPT[doc] = "The name of the build environment setup script for the purposes of setting up the environment within the extensible SDK."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    The name of the build environment setup script for the
+                    purposes of setting up the environment within the
+                    extensible SDK.
+                    The default value is "oe-init-build-env".
+                </para>
+
+                <para>
+                    If you use a custom script to set up your build
+                    environment, set the
+                    <filename>OE_INIT_ENV_SCRIPT</filename> variable to its
+                    name.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-OE_TERMINAL'><glossterm>OE_TERMINAL</glossterm>
             <info>
                 OE_TERMINAL[doc] = "Controls how the OpenEmbedded build system spawns interactive terminals on the host development system."
@@ -9539,6 +9584,17 @@
      PREFERRED_PROVIDER_virtual/xserver = "xserver-xf86"
      PREFERRED_PROVIDER_virtual/libgl ?= "mesa"
                     </literallayout>
+                    <note>
+                        If you set <filename>PREFERRED_PROVIDER</filename>
+                        for a <filename>virtual/*</filename> item, then any
+                        recipe that
+                        <link linkend='var-PROVIDES'><filename>PROVIDES</filename></link>
+                        that item that is not selected by
+                        <filename>PREFERRED_PROVIDER</filename> is prevented
+                        from building, which is usually desirable since this
+                        mechanism is designed to select between mutually
+                        exclusive alternative providers.
+                    </note>
                 </para>
             </glossdef>
         </glossentry>
@@ -9566,6 +9622,23 @@
      PREFERRED_VERSION_python = "2.7.3"
      PREFERRED_VERSION_linux-yocto = "3.19%"
                     </literallayout>
+                    Sometimes the <filename>PREFERRED_VERSION</filename>
+                    variable can be set by configuration files in a way that
+                    is hard to change.
+                    You can use
+                    <link linkend='var-OVERRIDES'><filename>OVERRIDES</filename></link>
+                    to set a machine-specific override.
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     PREFERRED_VERSION_linux-yocto_qemux86 = "3.4%"
+                    </literallayout>
+                    Although not recommended, worst case, you can also use the
+                    "forcevariable" override, which is the strongest override
+                    possible.
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     PREFERRED_VERSION_linux-yocto_forcevariable = "3.4%"
+                    </literallayout>
                 </para>
             </glossdef>
         </glossentry>
@@ -9594,7 +9667,7 @@
                     is "poky", the default value for
                     <filename>PREMIRRORS</filename> is defined in the
                     <filename>conf/distro/poky.conf</filename> file in the
-                    <filename>meta-yocto</filename> Git repository.
+                    <filename>meta-poky</filename> Git repository.
                 </para>
 
                 <para>
@@ -9854,35 +9927,6 @@
 
     </glossdiv>
 
-    <glossdiv id='var-glossary-q'><title>Q</title>
-
-        <glossentry id='var-QMAKE_PROFILES'><glossterm>QMAKE_PROFILES</glossterm>
-            <info>
-                QMAKE_PROFILES[doc] = "Specifies your own subset of .pro files to be built for use with qmake."
-            </info>
-            <glossdef>
-                <para role="glossdeffirst">
-<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
-                    Specifies your own subset of <filename>.pro</filename>
-                    files to be built for use with
-                    <filename>qmake</filename>.
-                    If you do not set this variable, all
-                    <filename>.pro</filename> files in the directory pointed to
-                    by <link linkend='var-S'><filename>S</filename></link>
-                    will be built by default.
-                </para>
-
-                <para>
-                    This variable is used with recipes that inherit the
-                    <link linkend='ref-classes-qmake*'><filename>qmake_base</filename></link>
-                    class or other classes that inherit
-                    <filename>qmake_base</filename>.
-                </para>
-            </glossdef>
-        </glossentry>
-
-    </glossdiv>
-
     <glossdiv id='var-glossary-r'><title>R</title>
 
         <glossentry id='var-RANLIB'><glossterm>RANLIB</glossterm>
@@ -10195,7 +10239,7 @@
                 <para>
                     The <filename>ROOTFS</filename> variable is an optional
                     variable used with the
-                    <link linkend='ref-classes-bootimg'><filename>bootimg</filename></link>
+                    <link linkend='ref-classes-image-live'><filename>image-live</filename></link>
                     class.
                 </para>
             </glossdef>
@@ -10532,17 +10576,16 @@
                     The location in the
                     <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
                     where unpacked recipe source code resides.
-                    This location is within the work directory
-                    (<filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>),
-                    which is not static.
-                    The unpacked source location depends on the recipe name
-                    (<filename><link linkend='var-PN'>PN</link></filename>) and
-                    recipe version
-                    (<filename><link linkend='var-PV'>PV</link></filename>) as
-                    follows:
-                    <literallayout class='monospaced'>
-     ${WORKDIR}/${PN}-${PV}
-                    </literallayout>
+                    By default, this directory is
+                    <filename>${</filename><link linkend='var-WORKDIR'><filename>WORKDIR</filename></link><filename>}/${</filename><link linkend='var-BPN'><filename>BPN</filename></link><filename>}-${</filename><link linkend='var-PV'><filename>PV</filename></link><filename>}</filename>,
+                    where <filename>${BPN}</filename> is the base recipe name
+                    and <filename>${PV}</filename> is the recipe version.
+                    If the source tarball extracts the code to a directory
+                    named anything other than <filename>${BPN}-${PV}</filename>,
+                    or if the source code if fetched from an SCM such as
+                    Git or Subversion, then you must set <filename>S</filename>
+                    in the recipe so that the OpenEmbedded build system
+                    knows where to find the unpacked source.
                 </para>
 
                 <para>
@@ -10556,6 +10599,22 @@
                     <literallayout class='monospaced'>
      poky/build/tmp/work/qemux86-poky-linux/db/5.1.19-r3/db-5.1.19
                     </literallayout>
+                    The unpacked source code resides in the
+                    <filename>db-5.1.19</filename> folder.
+                </para>
+
+                <para>
+                    This next example assumes a Git repository.
+                    By default, Git repositories are cloned to
+                    <filename>${WORKDIR}/git</filename> during
+                    <link linkend='ref-tasks-fetch'><filename>do_fetch</filename></link>.
+                    Since this path is different from the default value of
+                    <filename>S</filename>, you must set it specifically
+                    so the source can be located:
+                    <literallayout class='monospaced'>
+     SRC_URI = "git://path/to/repo.git"
+     S = "${WORKDIR}/git"
+                    </literallayout>
                 </para>
             </glossdef>
         </glossentry>
@@ -10661,6 +10720,30 @@
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-SDK_EXT_TYPE'><glossterm>SDK_EXT_TYPE</glossterm>
+            <info>
+                SDK_EXT_TYPE[doc] = "Controls whether or not shared state artifacts are copied into the extensible SDK."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    Controls whether or not shared state artifacts are copied
+                    into the extensible SDK.
+                    The default value of "full" copies all of the required
+                    shared state artifacts into the extensible SDK.
+                    The value "minimal" leaves these artifacts out of the
+                    SDK.
+                    <note>
+                        If you set the variable to "minimal", you need to
+                        ensure
+                        <link linkend='var-SSTATE_MIRRORS'><filename>SSTATE_MIRRORS</filename></link>
+                        is set in the SDK's configuration to enable the
+                        artifacts to be fetched as needed.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-SDK_HOST_MANIFEST'><glossterm>SDK_HOST_MANIFEST</glossterm>
             <info>
                 SDK_HOST_MANIFEST[doc] = "The manifest file for the host part of the SDK. This file lists all the installed packages that make up the host part of the SDK."
@@ -10694,6 +10777,88 @@
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-SDK_INCLUDE_PKGDATA'><glossterm>SDK_INCLUDE_PKGDATA</glossterm>
+            <info>
+                SDK_INCLUDE_PKGDATA[doc] = "When set to "1", specifies to include the packagedata for all recipes in the "world" target in the extensible SDK."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    When set to "1", specifies to include the packagedata for
+                    all recipes in the "world" target in the extensible SDK.
+                    Including this data allows the
+                    <filename>devtool search</filename> command to find these
+                    recipes in search results, as well as allows the
+                    <filename>devtool add</filename> command to map
+                    dependencies more effectively.
+                    <note>
+                        Enabling the <filename>SDK_INCLUDE_PKGDATA</filename>
+                        variable significantly increases build time because
+                        all of world needs to be built.
+                        Enabling the variable also slightly increases the size
+                        of the extensible SDK.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SDK_INHERIT_BLACKLIST'><glossterm>SDK_INHERIT_BLACKLIST</glossterm>
+            <info>
+                SDK_INHERIT_BLACKLIST[doc] = "A list of classes to remove from the INHERIT value globally within the extensible SDK configuration."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    A list of classes to remove from the
+                    <link linkend='var-INHERIT'><filename>INHERIT</filename></link>
+                    value globally within the extensible SDK configuration.
+                    The default value is "buildhistory icecc".
+                </para>
+
+                <para>
+                    Some classes are not generally applicable within
+                    the extensible SDK context and you can use this variable
+                    to disable them.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SDK_LOCAL_CONF_BLACKLIST'><glossterm>SDK_LOCAL_CONF_BLACKLIST</glossterm>
+            <info>
+                SDK_LOCAL_CONF_BLACKLIST[doc] = "A list of variables not allowed through from the build system configuration into the extensible SDK configuration."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    A list of variables not allowed through from the build
+                    system configuration into the extensible SDK configuration.
+                    Usually, these are variables that are specific to the
+                    machine on which the build system is running and thus
+                    would be potentially problematic within the extensible SDK.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SDK_LOCAL_CONF_WHITELIST'><glossterm>SDK_LOCAL_CONF_WHITELIST</glossterm>
+            <info>
+                SDK_LOCAL_CONF_WHITELIST[doc] = "A list of variables allowed through from the build system configuration into the extensible SDK configuration."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    A list of variables allowed through from the build system
+                    configuration into the extensible SDK configuration.
+                    This list overrides the variables specified using the
+                    <link linkend='var-SDK_LOCAL_CONF_BLACKLIST'><filename>SDK_LOCAL_CONF_BLACKLIST</filename></link>
+                    variable as well as any variables identified by automatic
+                    blacklisting due to the "/" character being found at the
+                    start of the value, which is usually indicative of being a
+                    path and thus might not be valid on the system where the
+                    SDK is installed.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-SDK_NAME'><glossterm>SDK_NAME</glossterm>
             <info>
                 SDK_NAME[doc] = "The base name for SDK output files."
@@ -10814,7 +10979,8 @@
             <glossdef>
                 <para role="glossdeffirst">
 <!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
-                    The toolchain binary prefix used for nativesdk recipes.
+                    The toolchain binary prefix used for
+                    <filename>nativesdk</filename> recipes.
                     The OpenEmbedded build system uses the
                     <filename>SDK_PREFIX</filename> value to set the
                     <link linkend='var-TARGET_PREFIX'><filename>TARGET_PREFIX</filename></link>
@@ -10824,6 +10990,33 @@
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-SDK_RECRDEP_TASKS'><glossterm>SDK_RECRDEP_TASKS</glossterm>
+            <info>
+                SDK_RECRDEP_TASKS[doc] = "A list of shared state tasks added to the extensible SDK."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    A list of shared state tasks added to the extensible SDK.
+                    By default, the following tasks are added:
+                    <literallayout class='monospaced'>
+     do_populate_lic
+     do_package_qa
+     do_populate_sysroot
+     do_deploy
+                    </literallayout>
+                    Despite the default value of "" for the
+                    <filename>SDK_RECRDEP_TASKS</filename> variable, the
+                    above four tasks are always added to the SDK.
+                    To specify tasks beyond these four, you need to use
+                    the <filename>SDK_RECRDEP_TASKS</filename> variable (e.g.
+                    you are defining additional tasks that are needed in
+                    order to build
+                    <link linkend='var-SDK_TARGETS'><filename>SDK_TARGETS</filename></link>).
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-SDK_SYS'><glossterm>SDK_SYS</glossterm>
             <info>
                 SDK_SYS[doc] = "Specifies the system, including the architecture and the operating system, for which the SDK will be built."
@@ -10881,6 +11074,64 @@
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-SDK_TARGETS'><glossterm>SDK_TARGETS</glossterm>
+            <info>
+                SDK_TARGETS[doc] = "A list of targets to install from shared state as part of the standard or extensible SDK installation."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    A list of targets to install from shared state as part of
+                    the standard or extensible SDK installation.
+                    The default value is "${PN}" (i.e. the image from which
+                    the SDK is built).
+                </para>
+
+                <para>
+                    The <filename>SDK_TARGETS</filename> variable is an
+                    internal variable and typically would not be changed.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SDK_TITLE'><glossterm>SDK_TITLE</glossterm>
+            <info>
+                SDK_TITLE[doc] = "Specifies a title to be printed when running the SDK installer."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    Specifies a title to be printed when running the SDK
+                    installer.
+                    The <filename>SDK_TITLE</filename> variable defaults to
+                    "<replaceable>distro</replaceable> SDK" for the standard
+                    SDK and "<replaceable>distro</replaceable> Extensible SDK"
+                    for the extensible SDK, where
+                    <replaceable>distro</replaceable> is the first one of
+                    <link linkend='var-DISTRO_NAME'><filename>DISTRO_NAME</filename></link>
+                    or
+                    <link linkend='var-DISTRO'><filename>DISTRO</filename></link>
+                    that is set in your configuration.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SDK_UPDATE_URL'><glossterm>SDK_UPDATE_URL</glossterm>
+            <info>
+                SDK_UPDATE_URL[doc] = "An optional URL for an update server for the extensible SDK."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    An optional URL for an update server for the extensible
+                    SDK.
+                    If set, the value is used as the default update server when
+                    running <filename>devtool sdk-update</filename> within the
+                    extensible SDK.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-SDK_VENDOR'><glossterm>SDK_VENDOR</glossterm>
             <info>
                 SDK_VENDOR[doc] = "Specifies the name of the SDK vendor."
@@ -10902,7 +11153,7 @@
 <!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
                     Specifies the version of the SDK.
                     The distribution configuration file (e.g.
-                    <filename>/meta-yocto/conf/distro/poky.conf</filename>)
+                    <filename>/meta-poky/conf/distro/poky.conf</filename>)
                     defines the <filename>SDK_VERSION</filename> as follows:
                     <literallayout class='monospaced'>
      SDK_VERSION := "${@'${DISTRO_VERSION}'.replace('snapshot-${DATE}','snapshot')}"
@@ -10939,14 +11190,13 @@
 
         <glossentry id='var-SDKMACHINE'><glossterm>SDKMACHINE</glossterm>
             <info>
-                SDKMACHINE[doc] = "Specifies the architecture (i.e. i686 or x86_64) for which to build SDK and ADT items."
+                SDKMACHINE[doc] = "Specifies the architecture (i.e. i686 or x86_64) for which to build SDK items."
             </info>
             <glossdef>
                 <para role="glossdeffirst">
 <!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
-                    The machine for which the Application Development Toolkit
-                    (ADT) or SDK is built.
-                    In other words, the SDK or ADT is built such that it
+                    The machine for which the SDK is built.
+                    In other words, the SDK is built such that it
                     runs on the target you specify with the
                     <filename>SDKMACHINE</filename> value.
                     The value points to a corresponding
@@ -11892,14 +12142,14 @@
                         <listitem><para>For recipes building for the target
                            machine, the value is "${STAGING_DIR}/${MACHINE}".
                            </para></listitem>
-                        <listitem><para>For <filename>native</filename>
-                           recipes building
+                        <listitem><para>For native recipes building
                            for the build host, the value is empty given the
                            assumption that when building for the build host,
                            the build host's own directories should be used.
                            </para></listitem>
-                        <listitem><para>For <filename>nativesdk</filename>
-                           recipes that build for the SDK, the value is
+                        <listitem><para>For native SDK
+                           recipes that build for the SDK
+                           (<filename>nativesdk</filename>), the value is
                            "${STAGING_DIR}/${MULTIMACH_HOST_SYS}".
                            </para></listitem>
                     </itemizedlist>
@@ -12707,12 +12957,13 @@
                             "${<link linkend='var-TARGET_SYS'>TARGET_SYS</link>}-".
                             </para></listitem>
                         <listitem><para>
-                            For <filename>native</filename> recipes, the build
-                            system sets the variable to the value of
+                            For native recipes, the build system sets the
+                            variable to the value of
                             <filename>BUILD_PREFIX</filename>.
                             </para></listitem>
                         <listitem><para>
-                            For <filename>nativesdk</filename> recipes, the
+                            For native SDK recipes
+                            (<filename>nativesdk</filename>), the
                             build system sets the variable to the value of
                             <filename>SDK_PREFIX</filename>.
                             </para></listitem>
@@ -12751,9 +13002,8 @@
                     Consider these two examples:
                     <itemizedlist>
                         <listitem><para>
-                            Given a <filename>native</filename> recipe on a
-                            32-bit, x86 machine running Linux, the value is
-                            "i686-linux".
+                            Given a native recipe on a 32-bit, x86 machine
+                            running Linux, the value is "i686-linux".
                             </para></listitem>
                         <listitem><para>
                             Given a recipe being built for a little-endian,
@@ -13359,11 +13609,14 @@
                     toolchain set that runs on the
                     <link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>,
                     and each package should usually have the prefix
-                    "nativesdk-".
-                    When building an SDK using
-                    <filename>bitbake -c populate_sdk &lt;imagename&gt;</filename>,
-                    a default list of packages is set in this variable, but
-                    you can add additional packages to the list.
+                    <filename>nativesdk-</filename>.
+                    For example, consider the following command when
+                    building an SDK:
+                    <literallayout class='monospaced'>
+     $ bitbake -c populate_sdk <replaceable>imagename</replaceable>
+                    </literallayout>
+                    In this case, a default list of packages is set in this
+                    variable, but you can add additional packages to the list.
                 </para>
 
                 <para>
@@ -13373,8 +13626,7 @@
                     section.
                     For information on setting up a cross-development
                     environment, see the
-                    "<ulink url='&YOCTO_DOCS_ADT_URL;#installing-the-adt'>Installing the ADT and Toolchains</ulink>"
-                    section in the Yocto Project Application Developer's Guide.
+                    <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-manual'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>.
                 </para>
             </glossdef>
         </glossentry>
@@ -13425,8 +13677,7 @@
                     section.
                     For information on setting up a cross-development
                     environment, see the
-                    "<ulink url='&YOCTO_DOCS_ADT_URL;#installing-the-adt'>Installing the ADT and Toolchains</ulink>"
-                    section in the Yocto Project Application Developer's Guide.
+                    <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-manual'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>.
                 </para>
             </glossdef>
         </glossentry>
@@ -14121,7 +14372,7 @@
      USER_CLASSES ?= "buildstats image-mklibs image-prelink"
                     </literallayout>
                     For more information, see
-                    <filename>meta-yocto/conf/local.conf.sample</filename> in
+                    <filename>meta-poky/conf/local.conf.sample</filename> in
                     the
                     <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
                 </para>
diff --git a/yocto-poky/documentation/ref-manual/technical-details.xml b/yocto-poky/documentation/ref-manual/technical-details.xml
index 2df3652..f06382a 100644
--- a/yocto-poky/documentation/ref-manual/technical-details.xml
+++ b/yocto-poky/documentation/ref-manual/technical-details.xml
@@ -187,7 +187,7 @@
         This section provides some technical background on how
         cross-development toolchains are created and used.
         For more information on toolchains, you can also see the
-        <ulink url='&YOCTO_DOCS_ADT_URL;'>Yocto Project Application Developer's Guide</ulink>.
+        <ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>.
     </para>
 
     <para>
@@ -219,6 +219,12 @@
         You can think of <filename>gcc-cross</filename> simply as an
         automatically generated cross-compiler that is used internally within
         BitBake only.
+        <note>
+            The extensible SDK does not use
+            <filename>gcc-cross-canadian</filename> since this SDK
+            ships a copy of the OpenEmbedded build system and the sysroot
+            within it contains <filename>gcc-cross</filename>.
+        </note>
     </para>
 
     <para>
@@ -282,8 +288,10 @@
         the development tools (e.g., the
         <filename>gcc-cross-canadian</filename>),
         <filename>binutils-cross-canadian</filename>, and other
-        <filename>nativesdk-*</filename> tools you need to cross-compile and
-        test your software.
+        <filename>nativesdk-*</filename> tools,
+        which are tools native to the SDK (i.e. native to
+        <link linkend='var-SDK_ARCH'><filename>SDK_ARCH</filename></link>),
+        you need to cross-compile and test your software.
         The figure shows the commands you use to easily build out this
         toolchain.
         This cross-development toolchain is built to execute on the
@@ -363,8 +371,9 @@
     <note>
         For information on advantages gained when building a
         cross-development toolchain installer, see the
-        "<ulink url='&YOCTO_DOCS_ADT_URL;#optionally-building-a-toolchain-installer'>Optionally Building a Toolchain Installer</ulink>"
-        section in the Yocto Project Application Developer's Guide.
+        "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-building-an-sdk-installer'>Building an SDK Installer</ulink>"
+        section in the Yocto Project Software Development Kit (SDK) Developer's
+        Guide.
     </note>
 </section>
 
@@ -470,17 +479,24 @@
         </para>
 
         <para>
-            To complicate the problem, there are things that should not be included in
-            the checksum.
+            To complicate the problem, there are things that should not be
+            included in the checksum.
             First, there is the actual specific build path of a given task -
             the <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>.
-            It does not matter if the work directory changes because it should not
-            affect the output for target packages.
-            Also, the build process has the objective of making native or cross packages relocatable.
-            The checksum therefore needs to exclude <filename>WORKDIR</filename>.
+            It does not matter if the work directory changes because it should
+            not affect the output for target packages.
+            Also, the build process has the objective of making native
+            or cross packages relocatable.
+            <note>
+                Both native and cross packages run on the build host.
+                However, cross packages generate output for the target
+                architecture.
+            </note>
+            The checksum therefore needs to exclude
+            <filename>WORKDIR</filename>.
             The simplistic approach for excluding the work directory is to set
-            <filename>WORKDIR</filename> to some fixed value and create the checksum
-            for the "run" script.
+            <filename>WORKDIR</filename> to some fixed value and create the
+            checksum for the "run" script.
         </para>
 
         <para>
@@ -665,7 +681,6 @@
             <literallayout class='monospaced'>
      DEPLOYDIR = "${WORKDIR}/deploy-${PN}"
      SSTATETASKS += "do_deploy"
-     do_deploy[sstate-name] = "deploy"
      do_deploy[sstate-inputdirs] = "${DEPLOYDIR}"
      do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}"
 
@@ -770,22 +785,49 @@
                 Because of this, the Yocto Project includes strong debugging
                 tools:
                 <itemizedlist>
-                    <listitem><para>Whenever a shared state package is written out, so is a
-                        corresponding <filename>.siginfo</filename> file.
-                        This practice results in a pickled Python database of all
-                        the metadata that went into creating the hash for a given shared state
-                        package.</para></listitem>
-                    <listitem><para>If you run BitBake with the <filename>--dump-signatures</filename>
-                        (or <filename>-S</filename>) option, BitBake dumps out
-                        <filename>.siginfo</filename> files in
-                        the stamp directory for every task it would have executed instead of
-                        building the specified target package.</para></listitem>
-                    <listitem><para>There is a <filename>bitbake-diffsigs</filename> command that
-                        can process <filename>.siginfo</filename> files.
-                        If you specify one of these files, BitBake dumps out the dependency
-                        information in the file.
-                        If you specify two files, BitBake compares the two files and dumps out
-                        the differences between the two.
+                    <listitem><para>Whenever a shared state package is written
+                        out into the
+                        <link linkend='var-SSTATE_DIR'><filename>SSTATE_DIR</filename></link>,
+                        a corresponding <filename>.siginfo</filename> file is
+                        also written.
+                        This file contains a pickled Python database of all
+                        the Metadata that went into creating the hash for a
+                        given shared state package.
+                        Whenever a stamp is written into the stamp directory
+                        <link linkend='var-STAMP'><filename>STAMP</filename></link>,
+                        a corresponding <filename>.sigdata</filename> file
+                        is created that contains the same hash data that
+                        represented the executed task.
+                        </para></listitem>
+                    <listitem><para>You can use BitBake to dump out the
+                        signature construction information without executing
+                        tasks by using either of the following BitBake
+                        command-line options:
+                        <literallayout class='monospaced'>
+     &dash;&dash;dump-signatures=<replaceable>SIGNATURE_HANDLER</replaceable>
+     -S <replaceable>SIGNATURE_HANDLER</replaceable>
+                        </literallayout>
+                        <note>
+                            Two common values for
+                            <replaceable>SIGNATURE_HANDLER</replaceable> are
+                            "none" and "printdiff" to only dump the signature
+                            or to compare the dumped signature with the
+                            cached one, respectively.
+                        </note>
+                        Using BitBake with either of these options causes
+                        BitBake to dump out <filename>.sigdata</filename> files
+                        in the stamp directory for every task it would have
+                        executed instead of building the specified target
+                        package.
+                        </para></listitem>
+                    <listitem><para>There is a
+                        <filename>bitbake-diffsigs</filename> command that
+                        can process <filename>.sigdata</filename> and
+                        <filename>.siginfo</filename> files.
+                        If you specify one of these files, BitBake dumps out
+                        the dependency information in the file.
+                        If you specify two files, BitBake compares the two
+                        files and dumps out the differences between the two.
                         This more easily helps answer the question of "What
                         changed between X and Y?"</para></listitem>
                 </itemizedlist>
@@ -1378,7 +1420,6 @@
                 <literallayout class='monospaced'>
      COMMERCIAL_AUDIO_PLUGINS ?= ""
      COMMERCIAL_VIDEO_PLUGINS ?= ""
-     COMMERCIAL_QT = ""
                 </literallayout>
                 If you want to enable these components, you can do so by making sure you have
                 statements similar to the following
@@ -1388,7 +1429,6 @@
         gst-plugins-ugly-mpegaudioparse"
      COMMERCIAL_VIDEO_PLUGINS = "gst-plugins-ugly-mpeg2dec \
         gst-plugins-ugly-mpegstream gst-plugins-bad-mpegvideoparse"
-     COMMERCIAL_QT ?= "qmmp"
      LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly commercial_gst-plugins-bad commercial_qmmp"
                 </literallayout>
                 Of course, you could also create a matching whitelist
@@ -1406,9 +1446,8 @@
                 Specifying audio and video plug-ins as part of the
                 <filename>COMMERCIAL_AUDIO_PLUGINS</filename> and
                 <filename>COMMERCIAL_VIDEO_PLUGINS</filename> statements
-                or commercial Qt components as part of
-                the <filename>COMMERCIAL_QT</filename> statement (along
-                with the enabling <filename>LICENSE_FLAGS_WHITELIST</filename>) includes the
+                (along with the enabling
+                <filename>LICENSE_FLAGS_WHITELIST</filename>) includes the
                 plug-ins or components into built images, thus adding
                 support for media formats or components.
             </para>
diff --git a/yocto-poky/documentation/ref-manual/usingpoky.xml b/yocto-poky/documentation/ref-manual/usingpoky.xml
index ca87962..a7bf32d 100644
--- a/yocto-poky/documentation/ref-manual/usingpoky.xml
+++ b/yocto-poky/documentation/ref-manual/usingpoky.xml
@@ -113,8 +113,7 @@
         <filename class="directory">tmp/deploy/images</filename>.
         For information on how to run pre-built images such as <filename>qemux86</filename>
         and <filename>qemuarm</filename>, see the
-        "<ulink url='&YOCTO_DOCS_QS_URL;#using-pre-built'>Example Using Pre-Built Binaries and QEMU</ulink>"
-        section in the Yocto Project Application Developer's Guide.
+        <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-manual'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>.
         For information about how to install these images, see the documentation for your
         particular board or machine.
     </para>
@@ -150,10 +149,11 @@
 
     <para>
         For discussions on debugging, see the
-        "<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-gdb-remotedebug'>Debugging With the GNU Project Debugger (GDB) Remotely</ulink>"
-        and
-        "<ulink url='&YOCTO_DOCS_DEV_URL;#adt-eclipse'>Working within Eclipse</ulink>"
-        sections in the Yocto Project Development Manual.
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-gdb-remotedebug'>Debugging With the GNU Project Debugger (GDB) Remotely</ulink>" section
+        in the Yocto Project Developer's Manual
+        and the
+        "<ulink url='&YOCTO_DOCS_SDK_URL;#adt-eclipse'>Working within Eclipse</ulink>"
+        section in the Yocto Project Software Development Kit (SDK) Developer's Guide.
     </para>
 
     <note>
@@ -799,12 +799,18 @@
 
         <section id='build-history-sdk-information'>
             <title>Build History SDK Information</title>
+
             <para>
                 Build history collects similar information on the contents
-                of SDKs (e.g. <filename>meta-toolchain</filename>
-                or <filename>bitbake -c populate_sdk imagename</filename>)
+                of SDKs
+                (e.g. <filename>bitbake -c populate_sdk imagename</filename>)
                 as compared to information it collects for images.
-                The following list shows the files produced for each SDK:
+                Furthermore, this information differs depending on whether an
+                extensible or standard SDK is being produced.
+            </para>
+
+            <para>
+                The following list shows the files produced for SDKs:
                 <itemizedlist>
                     <listitem><para><filename>files-in-sdk.txt:</filename>
                         A list of files in the SDK with permissions,
@@ -817,11 +823,49 @@
                         about the SDK.
                         See the following listing example for more information.
                         </para></listitem>
+                    <listitem><para><filename>sstate-task-sizes.txt:</filename>
+                        A text file containing name-value pairs with information
+                        about task group sizes
+                        (e.g. <filename>do_populate_sysroot</filename> tasks
+                        have a total size).
+                        The <filename>sstate-task-sizes.txt</filename> file
+                        exists only when an extensible SDK is created.
+                        </para></listitem>
+                    <listitem><para><filename>sstate-package-sizes.txt:</filename>
+                        A text file containing name-value pairs with information
+                        for the shared-state packages and sizes in the SDK.
+                        The <filename>sstate-package-sizes.txt</filename> file
+                        exists only when an extensible SDK is created.
+                        </para></listitem>
+                    <listitem><para><filename>sdk-files:</filename>
+                        A folder that contains copies of the files mentioned in
+                        <filename>BUILDHISTORY_SDK_FILES</filename> if the
+                        files are present in the output.
+                        Additionally, the default value of
+                        <filename>BUILDHISTORY_SDK_FILES</filename> is specific
+                        to the extensible SDK although you can set it
+                        differently if you would like to pull in specific files
+                        from the standard SDK.</para>
+                        <para>The default files are
+                        <filename>conf/local.conf</filename>,
+                        <filename>conf/bblayers.conf</filename>,
+                        <filename>conf/auto.conf</filename>,
+                        <filename>conf/locked-sigs.inc</filename>, and
+                        <filename>conf/devtool.conf</filename>.
+                        Thus, for an extensible SDK, these files get copied
+                        into the <filename>sdk-files</filename> directory.
+                        </para></listitem>
                     <listitem><para>The following information appears under
                         each of the <filename>host</filename>
                         and <filename>target</filename> directories
                         for the portions of the SDK that run on the host and
                         on the target, respectively:
+                        <note>
+                            The following files for the most part are empty
+                            when producing an extensible SDK because this
+                            type of SDK is not constructed from packages as is
+                            the standard SDK.
+                        </note>
                         <itemizedlist>
                             <listitem><para><filename>depends.dot:</filename>
                                 Dependency graph for the SDK that is