diff --git a/poky/documentation/sdk-manual/appendix-customizing.rst b/poky/documentation/sdk-manual/appendix-customizing.rst
index 66218fc..2be7687 100644
--- a/poky/documentation/sdk-manual/appendix-customizing.rst
+++ b/poky/documentation/sdk-manual/appendix-customizing.rst
@@ -44,14 +44,12 @@
    :term:`ESDK_LOCALCONF_ALLOW` overrides either of the previous two
    filters. The default value is blank.
 
--  Classes inherited globally with
-   :term:`INHERIT` that are listed in
-   :term:`ESDK_CLASS_INHERIT_DISABLE`
-   are disabled. Using :term:`ESDK_CLASS_INHERIT_DISABLE` to disable these
-   classes is the typical method to disable classes that are problematic
-   or unnecessary in the SDK context. The default value disables the
-   :ref:`buildhistory <ref-classes-buildhistory>`
-   and :ref:`icecc <ref-classes-icecc>` classes.
+-  Classes inherited globally with :term:`INHERIT` that are listed in
+   :term:`ESDK_CLASS_INHERIT_DISABLE` are disabled. Using
+   :term:`ESDK_CLASS_INHERIT_DISABLE` to disable these classes is the typical
+   method to disable classes that are problematic or unnecessary in the SDK
+   context. The default value disables the
+   :ref:`ref-classes-buildhistory` and :ref:`ref-classes-icecc` classes.
 
 Additionally, the contents of ``conf/sdk-extra.conf``, when present, are
 appended to the end of ``conf/local.conf`` within the produced SDK,
@@ -74,8 +72,7 @@
 
    .. note::
 
-      The default value of
-      ESDK_CLASS_INHERIT_DISABLE
+      The default value of :term:`ESDK_CLASS_INHERIT_DISABLE`
       is set using the "?=" operator. Consequently, you will need to
       either define the entire list by using the "=" operator, or you
       will need to append a value using either ":append" or the "+="
@@ -175,12 +172,12 @@
 the installed SDKs to update the installed SDKs by using the
 ``devtool sdk-update`` command:
 
-1. Create a directory that can be shared over HTTP or HTTPS. You can do
+#. Create a directory that can be shared over HTTP or HTTPS. You can do
    this by setting up a web server such as an :wikipedia:`Apache HTTP Server
    <Apache_HTTP_Server>` or :wikipedia:`Nginx <Nginx>` server in the cloud
    to host the directory. This directory must contain the published SDK.
 
-2. Set the
+#. Set the
    :term:`SDK_UPDATE_URL`
    variable to point to the corresponding HTTP or HTTPS URL. Setting
    this variable causes any SDK built to default to that URL and thus,
@@ -189,10 +186,10 @@
    ":ref:`sdk-manual/extensible:applying updates to an installed extensible sdk`"
    section.
 
-3. Build the extensible SDK normally (i.e., use the
+#. Build the extensible SDK normally (i.e., use the
    ``bitbake -c populate_sdk_ext`` imagename command).
 
-4. Publish the SDK using the following command::
+#. Publish the SDK using the following command::
 
       $ oe-publish-sdk some_path/sdk-installer.sh path_to_shared_http_directory
 
@@ -247,7 +244,7 @@
 items to the SDK without requiring the users to build the items from
 source, you need to do a number of things:
 
-1. Ensure the additional items you want the user to be able to install
+#. Ensure the additional items you want the user to be able to install
    are already built:
 
    -  Build the items explicitly. You could use one or more "meta"
@@ -259,12 +256,12 @@
       :term:`EXCLUDE_FROM_WORLD`
       variable for additional information.
 
-2. Expose the ``sstate-cache`` directory produced by the build.
+#. Expose the ``sstate-cache`` directory produced by the build.
    Typically, you expose this directory by making it available through
    an :wikipedia:`Apache HTTP Server <Apache_HTTP_Server>` or
    :wikipedia:`Nginx <Nginx>` server.
 
-3. Set the appropriate configuration so that the produced SDK knows how
+#. Set the appropriate configuration so that the produced SDK knows how
    to find the configuration. The variable you need to set is
    :term:`SSTATE_MIRRORS`::
 
diff --git a/poky/documentation/sdk-manual/appendix-obtain.rst b/poky/documentation/sdk-manual/appendix-obtain.rst
index b90247d..ba84450 100644
--- a/poky/documentation/sdk-manual/appendix-obtain.rst
+++ b/poky/documentation/sdk-manual/appendix-obtain.rst
@@ -28,14 +28,14 @@
 
 Follow these steps to locate and hand-install the toolchain:
 
-1. *Go to the Installers Directory:* Go to
+#. *Go to the Installers Directory:* Go to
    :yocto_dl:`/releases/yocto/yocto-&DISTRO;/toolchain/`
 
-2. *Open the Folder for Your Build Host:* Open the folder that matches
+#. *Open the Folder for Your Build Host:* Open the folder that matches
    your :term:`Build Host` (i.e.
    ``i686`` for 32-bit machines or ``x86_64`` for 64-bit machines).
 
-3. *Locate and Download the SDK Installer:* You need to find and
+#. *Locate and Download the SDK Installer:* You need to find and
    download the installer appropriate for your build host, target
    hardware, and image type.
 
@@ -72,7 +72,7 @@
 
       poky-glibc-x86_64-core-image-sato-core2-64-toolchain-ext-&DISTRO;.sh
 
-4. *Run the Installer:* Be sure you have execution privileges and run
+#. *Run the Installer:* Be sure you have execution privileges and run
    the installer. Following is an example from the ``Downloads``
    directory::
 
@@ -91,13 +91,13 @@
 As an alternative to locating and downloading an SDK installer, you can
 build the SDK installer. Follow these steps:
 
-1. *Set Up the Build Environment:* Be sure you are set up to use BitBake
+#. *Set Up the Build Environment:* Be sure you are set up to use BitBake
    in a shell. See the ":ref:`dev-manual/start:preparing the build host`" section
    in the Yocto Project Development Tasks Manual for information on how
    to get a build host ready that is either a native Linux machine or a
    machine that uses CROPS.
 
-2. *Clone the ``poky`` Repository:* You need to have a local copy of the
+#. *Clone the ``poky`` Repository:* You need to have a local copy of the
    Yocto Project :term:`Source Directory`
    (i.e. a local
    ``poky`` repository). See the ":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`" and
@@ -107,12 +107,11 @@
    how to clone the ``poky`` repository and check out the appropriate
    branch for your work.
 
-3. *Initialize the Build Environment:* While in the root directory of
+#. *Initialize the Build Environment:* While in the root directory of
    the Source Directory (i.e. ``poky``), run the
    :ref:`structure-core-script` environment
    setup script to define the OpenEmbedded build environment on your
-   build host.
-   ::
+   build host::
 
       $ source oe-init-build-env
 
@@ -121,12 +120,12 @@
    the script runs, your current working directory is set to the ``build``
    directory.
 
-4. *Make Sure You Are Building an Installer for the Correct Machine:*
+#. *Make Sure You Are Building an Installer for the Correct Machine:*
    Check to be sure that your :term:`MACHINE` variable in the ``local.conf``
    file in your :term:`Build Directory` matches the architecture
    for which you are building.
 
-5. *Make Sure Your SDK Machine is Correctly Set:* If you are building a
+#. *Make Sure Your SDK Machine is Correctly Set:* If you are building a
    toolchain designed to run on an architecture that differs from your
    current development host machine (i.e. the build host), be sure that
    the :term:`SDKMACHINE` variable in the ``local.conf`` file in your
@@ -146,7 +145,7 @@
          different from the architecture of the build machine (``x86_64``).
 
 
-6. *Build the SDK Installer:* To build the SDK installer for a standard
+#. *Build the SDK Installer:* To build the SDK installer for a standard
    SDK and populate the SDK image, use the following command form. Be
    sure to replace ``image`` with an image (e.g. "core-image-sato")::
 
@@ -176,7 +175,7 @@
          static development libraries: TOOLCHAIN_TARGET_TASK:append = "
          libc-staticdev"
 
-7. *Run the Installer:* You can now run the SDK installer from
+#. *Run the Installer:* You can now run the SDK installer from
    ``tmp/deploy/sdk`` in the :term:`Build Directory`. Following is an example::
 
       $ cd poky/build/tmp/deploy/sdk
@@ -204,7 +203,7 @@
 
 Follow these steps to extract the root filesystem:
 
-1. *Locate and Download the Tarball for the Pre-Built Root Filesystem
+#. *Locate and Download the Tarball for the Pre-Built Root Filesystem
    Image File:* You need to find and download the root filesystem image
    file that is appropriate for your target system. These files are kept
    in machine-specific folders in the
@@ -242,7 +241,7 @@
 
       core-image-sato-sdk-beaglebone-yocto.tar.bz2
 
-2. *Initialize the Cross-Development Environment:* You must ``source``
+#. *Initialize the Cross-Development Environment:* You must ``source``
    the cross-development environment setup script to establish necessary
    environment variables.
 
@@ -254,7 +253,7 @@
 
       $ source poky_sdk/environment-setup-core2-64-poky-linux
 
-3. *Extract the Root Filesystem:* Use the ``runqemu-extract-sdk``
+#. *Extract the Root Filesystem:* Use the ``runqemu-extract-sdk``
    command and provide the root filesystem image.
 
    Following is an example command that extracts the root filesystem
diff --git a/poky/documentation/sdk-manual/extensible.rst b/poky/documentation/sdk-manual/extensible.rst
index ed38ac3..7c7ceb6 100644
--- a/poky/documentation/sdk-manual/extensible.rst
+++ b/poky/documentation/sdk-manual/extensible.rst
@@ -47,7 +47,7 @@
 Extensible SDK can be installed in two different ways, and both have
 their own pros and cons:
 
-1. *Setting up the Extensible SDK environment directly in a Yocto build*. This
+#. *Setting up the Extensible SDK environment directly in a Yocto build*. This
 avoids having to produce, test, distribute and maintain separate SDK installer
 archives, which can get very large. There is only one environment for the regular
 Yocto build and the SDK and less code paths where things can go not according to plan.
@@ -56,7 +56,7 @@
 second option: just run ``bitbake`` again to add more things to the sysroot, or add layers
 if even more things are required.
 
-2. *Setting up the Extensible SDK from a standalone installer*. This has the benefit of
+#. *Setting up the Extensible SDK from a standalone installer*. This has the benefit of
 having a single, self-contained archive that includes all the needed binary artifacts.
 So nothing needs to be rebuilt, and there is no need to provide a well-functioning
 binary artefact cache over the network for developers with underpowered laptops.
@@ -64,10 +64,10 @@
 Setting up the Extensible SDK environment directly in a Yocto build
 -------------------------------------------------------------------
 
-1. Set up all the needed layers and a Yocto :term:`Build Directory`, e.g. a regular Yocto
+#. Set up all the needed layers and a Yocto :term:`Build Directory`, e.g. a regular Yocto
    build where ``bitbake`` can be executed.
 
-2. Run:
+#. Run:
     $ bitbake meta-ide-support
     $ bitbake -c populate_sysroot gtk+3
     (or any other target or native item that the application developer would need)
@@ -138,16 +138,7 @@
 The following command shows how to run the installer given a toolchain
 tarball for a 64-bit x86 development host system and a 64-bit x86 target
 architecture. The example assumes the SDK installer is located in
-``~/Downloads/`` and has execution rights.
-
-.. note::
-
-   If you do not have write permissions for the directory into which you
-   are installing the SDK, the installer notifies you and exits. For
-   that case, set up the proper permissions in the directory and run the
-   installer again.
-
-::
+``~/Downloads/`` and has execution rights::
 
    $ ./Downloads/poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-ext-2.5.sh
    Poky (Yocto Project Reference Distro) Extensible SDK installer version 2.5
@@ -168,6 +159,13 @@
    Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g.
     $ . /home/scottrif/poky_sdk/environment-setup-core2-64-poky-linux
 
+.. note::
+
+   If you do not have write permissions for the directory into which you
+   are installing the SDK, the installer notifies you and exits. For
+   that case, set up the proper permissions in the directory and run the
+   installer again.
+
 Running the Extensible SDK Environment Setup Script
 ===================================================
 
@@ -281,7 +279,7 @@
 .. image:: figures/sdk-devtool-add-flow.png
    :width: 100%
 
-1. *Generating the New Recipe*: The top part of the flow shows three
+#. *Generating the New Recipe*: The top part of the flow shows three
    scenarios by which you could use ``devtool add`` to generate a recipe
    based on existing source code.
 
@@ -354,7 +352,7 @@
       Aside from a recipe folder, the command also creates an associated
       append folder and places an initial ``*.bbappend`` file within.
 
-2. *Edit the Recipe*: You can use ``devtool edit-recipe`` to open up the
+#. *Edit the Recipe*: You can use ``devtool edit-recipe`` to open up the
    editor as defined by the ``$EDITOR`` environment variable and modify
    the file::
 
@@ -364,7 +362,7 @@
    can make modifications to the recipe that take effect when you build
    it later.
 
-3. *Build the Recipe or Rebuild the Image*: The next step you take
+#. *Build the Recipe or Rebuild the Image*: The next step you take
    depends on what you are going to do with the new code.
 
    If you need to eventually move the build output to the target
@@ -380,7 +378,7 @@
 
       $ devtool build-image image
 
-4. *Deploy the Build Output*: When you use the ``devtool build`` command
+#. *Deploy the Build Output*: When you use the ``devtool build`` command
    to build out your recipe, you probably want to see if the resulting
    build output works as expected on the target hardware.
 
@@ -402,12 +400,11 @@
    ``devtool`` does not provide a specific command that allows you to
    deploy the image to actual hardware.
 
-5. *Finish Your Work With the Recipe*: The ``devtool finish`` command
+#. *Finish Your Work With the Recipe*: The ``devtool finish`` command
    creates any patches corresponding to commits in the local Git
    repository, moves the new recipe to a more permanent layer, and then
    resets the recipe so that the recipe is built normally rather than
-   from the workspace.
-   ::
+   from the workspace::
 
       $ devtool finish recipe layer
 
@@ -449,7 +446,7 @@
 .. image:: figures/sdk-devtool-modify-flow.png
    :width: 100%
 
-1. *Preparing to Modify the Code*: The top part of the flow shows three
+#. *Preparing to Modify the Code*: The top part of the flow shows three
    scenarios by which you could use ``devtool modify`` to prepare to
    work on source files. Each scenario assumes the following:
 
@@ -558,11 +555,11 @@
       append file for the recipe in the ``devtool`` workspace. The
       recipe and the source code remain in their original locations.
 
-2. *Edit the Source*: Once you have used the ``devtool modify`` command,
+#. *Edit the Source*: Once you have used the ``devtool modify`` command,
    you are free to make changes to the source files. You can use any
    editor you like to make and save your source code modifications.
 
-3. *Build the Recipe or Rebuild the Image*: The next step you take
+#. *Build the Recipe or Rebuild the Image*: The next step you take
    depends on what you are going to do with the new code.
 
    If you need to eventually move the build output to the target
@@ -575,7 +572,7 @@
    (e.g. for testing purposes), you can use the ``devtool build-image``
    command: $ devtool build-image image
 
-4. *Deploy the Build Output*: When you use the ``devtool build`` command
+#. *Deploy the Build Output*: When you use the ``devtool build`` command
    to build out your recipe, you probably want to see if the resulting
    build output works as expected on target hardware.
 
@@ -600,13 +597,12 @@
    ``devtool`` does not provide a specific command to deploy the image
    to actual hardware.
 
-5. *Finish Your Work With the Recipe*: The ``devtool finish`` command
+#. *Finish Your Work With the Recipe*: The ``devtool finish`` command
    creates any patches corresponding to commits in the local Git
    repository, updates the recipe to point to them (or creates a
    ``.bbappend`` file to do so, depending on the specified destination
    layer), and then resets the recipe so that the recipe is built
-   normally rather than from the workspace.
-   ::
+   normally rather than from the workspace::
 
       $ devtool finish recipe layer
 
@@ -652,7 +648,7 @@
    ``devtool upgrade``
    happens to be one. You can read about all the methods by which you
    can upgrade recipes in the
-   :ref:`dev-manual/common-tasks:upgrading recipes` section
+   :ref:`dev-manual/upgrading-recipes:upgrading recipes` section
    of the Yocto Project Development Tasks Manual.
 
 The ``devtool upgrade`` command is flexible enough to allow you to
@@ -668,7 +664,7 @@
 .. image:: figures/sdk-devtool-upgrade-flow.png
    :width: 100%
 
-1. *Initiate the Upgrade*: The top part of the flow shows the typical
+#. *Initiate the Upgrade*: The top part of the flow shows the typical
    scenario by which you use the ``devtool upgrade`` command. The
    following conditions exist:
 
@@ -720,7 +716,7 @@
    are incorporated into the build the next time you build the software
    just as are other changes you might have made to the source.
 
-2. *Resolve any Conflicts created by the Upgrade*: Conflicts could happen
+#. *Resolve any Conflicts created by the Upgrade*: Conflicts could happen
    after upgrading the software to a new version. Conflicts occur
    if your recipe specifies some patch files in :term:`SRC_URI` that
    conflict with changes made in the new version of the software. For
@@ -731,7 +727,7 @@
    conflicts created through use of a newer or different version of the
    software.
 
-3. *Build the Recipe or Rebuild the Image*: The next step you take
+#. *Build the Recipe or Rebuild the Image*: The next step you take
    depends on what you are going to do with the new code.
 
    If you need to eventually move the build output to the target
@@ -746,7 +742,7 @@
 
       $ devtool build-image image
 
-4. *Deploy the Build Output*: When you use the ``devtool build`` command
+#. *Deploy the Build Output*: When you use the ``devtool build`` command
    or ``bitbake`` to build your recipe, you probably want to see if the
    resulting build output works as expected on target hardware.
 
@@ -768,7 +764,7 @@
    ``devtool`` does not provide a specific command that allows you to do
    this.
 
-5. *Finish Your Work With the Recipe*: The ``devtool finish`` command
+#. *Finish Your Work With the Recipe*: The ``devtool finish`` command
    creates any patches corresponding to commits in the local Git
    repository, moves the new recipe to a more permanent layer, and then
    resets the recipe so that the recipe is built normally rather than
@@ -780,8 +776,7 @@
 
    If you specify a destination layer that is the same as the original
    source, then the old version of the recipe and associated files are
-   removed prior to adding the new version.
-   ::
+   removed prior to adding the new version::
 
       $ devtool finish recipe layer
 
@@ -1059,17 +1054,17 @@
 When building a recipe using the ``devtool build`` command, the typical
 build progresses as follows:
 
-1. Fetch the source
+#. Fetch the source
 
-2. Unpack the source
+#. Unpack the source
 
-3. Configure the source
+#. Configure the source
 
-4. Compile the source
+#. Compile the source
 
-5. Install the build output
+#. Install the build output
 
-6. Package the installed output
+#. Package the installed output
 
 For recipes in the workspace, fetching and unpacking is disabled as the
 source tree has already been prepared and is persistent. Each of these
@@ -1084,9 +1079,8 @@
 Instead, common functionality is encapsulated in classes inherited with
 the ``inherit`` directive. This technique leaves the recipe to describe
 just the things that are specific to the software being built. There is
-a :ref:`base <ref-classes-base>` class that
-is implicitly inherited by all recipes and provides the functionality
-that most recipes typically need.
+a :ref:`ref-classes-base` class that is implicitly inherited by all recipes
+and provides the functionality that most recipes typically need.
 
 The remainder of this section presents information useful when working
 with recipes.
@@ -1114,7 +1108,7 @@
    -  ``sysroot-destdir/``: Contains a subset of files installed within
       :ref:`ref-tasks-install` that have been put into the shared sysroot. For
       more information, see the
-      ":ref:`dev-manual/common-tasks:sharing files between recipes`" section.
+      ":ref:`dev-manual/new-recipe:sharing files between recipes`" section.
 
    -  ``packages-split/``: Contains subdirectories for each package
       produced by the recipe. For more information, see the
@@ -1327,15 +1321,15 @@
 you can produce a derivative SDK based on the currently installed SDK
 fairly easily by following these steps:
 
-1. If necessary, install an extensible SDK that you want to use as a
+#. If necessary, install an extensible SDK that you want to use as a
    base for your derivative SDK.
 
-2. Source the environment script for the SDK.
+#. Source the environment script for the SDK.
 
-3. Add the extra libraries or other components you want by using the
+#. Add the extra libraries or other components you want by using the
    ``devtool add`` command.
 
-4. Run the ``devtool build-sdk`` command.
+#. Run the ``devtool build-sdk`` command.
 
 The previous steps take the recipes added to the workspace and construct
 a new SDK installer that contains those recipes and the resulting binary
diff --git a/poky/documentation/sdk-manual/intro.rst b/poky/documentation/sdk-manual/intro.rst
index ce00538..49aa921 100644
--- a/poky/documentation/sdk-manual/intro.rst
+++ b/poky/documentation/sdk-manual/intro.rst
@@ -164,11 +164,11 @@
 
 You just need to follow these general steps:
 
-1. *Install the SDK for your target hardware:* For information on how to
+#. *Install the SDK for your target hardware:* For information on how to
    install the SDK, see the ":ref:`sdk-manual/using:installing the sdk`"
    section.
 
-2. *Download or Build the Target Image:* The Yocto Project supports
+#. *Download or Build the Target Image:* The Yocto Project supports
    several target architectures and has many pre-built kernel images and
    root filesystem images.
 
@@ -195,7 +195,7 @@
       ":ref:`sdk-manual/appendix-obtain:extracting the root filesystem`"
       section for information on how to do this extraction.
 
-3. *Develop and Test your Application:* At this point, you have the
+#. *Develop and Test your Application:* At this point, you have the
    tools to develop your application. If you need to separately install
    and use the QEMU emulator, you can go to `QEMU Home
    Page <https://wiki.qemu.org/Main_Page>`__ to download and learn about
diff --git a/poky/documentation/sdk-manual/using.rst b/poky/documentation/sdk-manual/using.rst
index 3016278..f1ff0c7 100644
--- a/poky/documentation/sdk-manual/using.rst
+++ b/poky/documentation/sdk-manual/using.rst
@@ -52,8 +52,7 @@
 
 The names of the tarball installer scripts are such that a string
 representing the host system appears first in the filename and then is
-immediately followed by a string representing the target architecture.
-::
+immediately followed by a string representing the target architecture::
 
    poky-glibc-host_system-image_type-arch-toolchain-release_version.sh
 
@@ -97,16 +96,7 @@
 The following command shows how to run the installer given a toolchain
 tarball for a 64-bit x86 development host system and a 64-bit x86 target
 architecture. The example assumes the SDK installer is located in
-``~/Downloads/`` and has execution rights.
-
-.. note::
-
-   If you do not have write permissions for the directory into which you
-   are installing the SDK, the installer notifies you and exits. For
-   that case, set up the proper permissions in the directory and run the
-   installer again.
-
-::
+``~/Downloads/`` and has execution rights::
 
    $ ./Downloads/poky-glibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh
    Poky (Yocto Project Reference Distro) SDK installer version &DISTRO;
@@ -119,6 +109,13 @@
    Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g.
     $ . /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
 
+.. note::
+
+   If you do not have write permissions for the directory into which you
+   are installing the SDK, the installer notifies you and exits. For
+   that case, set up the proper permissions in the directory and run the
+   installer again.
+
 Again, reference the
 ":ref:`sdk-manual/appendix-obtain:installed standard sdk directory structure`"
 section for more details on the resulting directory structure of the installed
diff --git a/poky/documentation/sdk-manual/working-projects.rst b/poky/documentation/sdk-manual/working-projects.rst
index 0eddee0..9a0db00 100644
--- a/poky/documentation/sdk-manual/working-projects.rst
+++ b/poky/documentation/sdk-manual/working-projects.rst
@@ -31,10 +31,9 @@
    GNOME Developer
    site.
 
-1. *Create a Working Directory and Populate It:* Create a clean
+#. *Create a Working Directory and Populate It:* Create a clean
    directory for your project and then make that directory your working
-   location.
-   ::
+   location::
 
       $ mkdir $HOME/helloworld
       $ cd $HOME/helloworld
@@ -75,7 +74,7 @@
          bin_PROGRAMS = hello
          hello_SOURCES = hello.c
 
-2. *Source the Cross-Toolchain Environment Setup File:* As described
+#. *Source the Cross-Toolchain Environment Setup File:* As described
    earlier in the manual, installing the cross-toolchain creates a
    cross-toolchain environment setup script in the directory that the
    SDK was installed. Before you can use the tools to develop your
@@ -93,7 +92,7 @@
 
       $ source tmp/deploy/images/qemux86-64/environment-setup-core2-64-poky-linux
 
-3. *Create the configure Script:* Use the ``autoreconf`` command to
+#. *Create the configure Script:* Use the ``autoreconf`` command to
    generate the ``configure`` script::
 
       $ autoreconf
@@ -109,7 +108,7 @@
       which ensures missing auxiliary files are copied to the build
       host.
 
-4. *Cross-Compile the Project:* This command compiles the project using
+#. *Cross-Compile the Project:* This command compiles the project using
    the cross-compiler. The
    :term:`CONFIGURE_FLAGS`
    environment variable provides the minimal arguments for GNU
@@ -130,7 +129,7 @@
 
      $ ./configure --host=armv5te-poky-linux-gnueabi --with-libtool-sysroot=sysroot_dir
 
-5. *Make and Install the Project:* These two commands generate and
+#. *Make and Install the Project:* These two commands generate and
    install the project into the destination directory::
 
       $ make
@@ -146,12 +145,11 @@
    This next command is a simple way to verify the installation of your
    project. Running the command prints the architecture on which the
    binary file can run. This architecture should be the same
-   architecture that the installed cross-toolchain supports.
-   ::
+   architecture that the installed cross-toolchain supports::
 
       $ file ./tmp/usr/local/bin/hello
 
-6. *Execute Your Project:* To execute the project, you would need to run
+#. *Execute Your Project:* To execute the project, you would need to run
    it on your target hardware. If your target hardware happens to be
    your build host, you could run the project as follows::
 
@@ -210,8 +208,7 @@
 In a new shell environment variables are not established for the SDK
 until you run the setup script. For example, the following commands show
 a null value for the compiler variable (i.e.
-:term:`CC`).
-::
+:term:`CC`)::
 
    $ echo ${CC}
 
@@ -230,10 +227,9 @@
 To illustrate variable use, work through this simple "Hello World!"
 example:
 
-1. *Create a Working Directory and Populate It:* Create a clean
+#. *Create a Working Directory and Populate It:* Create a clean
    directory for your project and then make that directory your working
-   location.
-   ::
+   location::
 
       $ mkdir $HOME/helloworld
       $ cd $HOME/helloworld
@@ -270,7 +266,7 @@
              printf("\n");
          }
 
-2. *Source the Cross-Toolchain Environment Setup File:* As described
+#. *Source the Cross-Toolchain Environment Setup File:* As described
    earlier in the manual, installing the cross-toolchain creates a
    cross-toolchain environment setup script in the directory that the
    SDK was installed. Before you can use the tools to develop your
@@ -288,7 +284,7 @@
 
       $ source tmp/deploy/images/qemux86-64/environment-setup-core2-64-poky-linux
 
-3. *Create the Makefile:* For this example, the Makefile contains
+#. *Create the Makefile:* For this example, the Makefile contains
    two lines that can be used to set the :term:`CC` variable. One line is
    identical to the value that is set when you run the SDK environment
    setup script, and the other line sets :term:`CC` to "gcc", the default
@@ -306,7 +302,7 @@
       	rm -rf *.o
       	rm target_bin
 
-4. *Make the Project:* Use the ``make`` command to create the binary
+#. *Make the Project:* Use the ``make`` command to create the binary
    output file. Because variables are commented out in the Makefile, the
    value used for :term:`CC` is the value set when the SDK environment setup
    file was run::
@@ -322,8 +318,7 @@
 
    You can override the :term:`CC` environment variable with the same
    variable as set from the Makefile by uncommenting the line in the
-   Makefile and running ``make`` again.
-   ::
+   Makefile and running ``make`` again::
 
       $ make clean
       rm -rf *.o
@@ -392,7 +387,7 @@
    use the SDK environment variables regardless of the values in the
    Makefile.
 
-5. *Execute Your Project:* To execute the project (i.e. ``target_bin``),
+#. *Execute Your Project:* To execute the project (i.e. ``target_bin``),
    use the following command::
 
       $ ./target_bin