5 files changed, 64 insertions, 64 deletions

diff --git a/documentation/sdk-manual/appendix-customizing.rst b/documentation/sdk-manual/appendix-customizing.rst
index 45ad54fd76..c1a36c471d 100644
--- a/documentation/sdk-manual/appendix-customizing.rst
+++ b/documentation/sdk-manual/appendix-customizing.rst
@@ -173,12 +173,12 @@ perform additional steps. These steps make it possible for anyone using
 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,
@@ -187,10 +187,10 @@ the installed SDKs to update the installed SDKs by using the
    ":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
 
@@ -245,7 +245,7 @@ If you want the users of an extensible SDK you build to be able to add
 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"
@@ -257,12 +257,12 @@ source, you need to do a number of things:
       :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/documentation/sdk-manual/appendix-obtain.rst b/documentation/sdk-manual/appendix-obtain.rst
index fa82af5c22..ba844507d3 100644
--- a/documentation/sdk-manual/appendix-obtain.rst
+++ b/documentation/sdk-manual/appendix-obtain.rst
@@ -28,14 +28,14 @@ and then run the script to hand-install the toolchain.
 
 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 @@ Follow these steps to locate and hand-install the toolchain:
 
       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 @@ Building an SDK Installer
 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,7 +107,7 @@ build the SDK installer. Follow these steps:
    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
@@ -120,12 +120,12 @@ build the SDK installer. Follow these steps:
    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
@@ -145,7 +145,7 @@ build the SDK installer. Follow these steps:
          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")::
 
@@ -175,7 +175,7 @@ build the SDK installer. Follow these steps:
          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
@@ -203,7 +203,7 @@ separately extract a root filesystem:
 
 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
@@ -241,7 +241,7 @@ Follow these steps to extract the root filesystem:
 
       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.
 
@@ -253,7 +253,7 @@ Follow these steps to extract the root filesystem:
 
       $ 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/documentation/sdk-manual/extensible.rst b/documentation/sdk-manual/extensible.rst
index 7ab43e0a9d..e8a0a5b3ce 100644
--- a/documentation/sdk-manual/extensible.rst
+++ b/documentation/sdk-manual/extensible.rst
@@ -47,7 +47,7 @@ Two ways to install the Extensible SDK
 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 @@ git fetch or layer management tooling. The SDK extensibility is better than in t
 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 @@ binary artefact cache over the network for developers with underpowered laptops.
 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)
@@ -279,7 +279,7 @@ command:
 .. 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.
 
@@ -352,7 +352,7 @@ command:
       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::
 
@@ -362,7 +362,7 @@ command:
    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
@@ -378,7 +378,7 @@ 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 the target hardware.
 
@@ -400,7 +400,7 @@ command:
    ``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
@@ -446,7 +446,7 @@ command:
 .. 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:
 
@@ -555,11 +555,11 @@ command:
       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
@@ -572,7 +572,7 @@ command:
    (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.
 
@@ -597,7 +597,7 @@ command:
    ``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
@@ -664,7 +664,7 @@ The following diagram shows the common development flow used with the
 .. 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:
 
@@ -716,7 +716,7 @@ The following diagram shows the common development flow used with the
    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
@@ -727,7 +727,7 @@ The following diagram shows the common development flow used with the
    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
@@ -742,7 +742,7 @@ The following diagram shows the common development flow used with the
 
       $ 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.
 
@@ -764,7 +764,7 @@ The following diagram shows the common development flow used with the
    ``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
@@ -1054,17 +1054,17 @@ Working With Recipes
 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
@@ -1322,15 +1322,15 @@ those customers need an SDK that has custom libraries. In such a case,
 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/documentation/sdk-manual/intro.rst b/documentation/sdk-manual/intro.rst
index ce00538b2a..49aa921e70 100644
--- a/documentation/sdk-manual/intro.rst
+++ b/documentation/sdk-manual/intro.rst
@@ -164,11 +164,11 @@ image.
 
 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 @@ You just need to follow these general steps:
       ":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/documentation/sdk-manual/working-projects.rst b/documentation/sdk-manual/working-projects.rst
index beec1dd09a..9a0db0099d 100644
--- a/documentation/sdk-manual/working-projects.rst
+++ b/documentation/sdk-manual/working-projects.rst
@@ -31,7 +31,7 @@ project:
    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::
 
@@ -74,7 +74,7 @@ project:
          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
@@ -92,7 +92,7 @@ project:
 
       $ 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
@@ -108,7 +108,7 @@ project:
       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
@@ -129,7 +129,7 @@ project:
 
      $ ./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
@@ -149,7 +149,7 @@ project:
 
       $ 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::
 
@@ -227,7 +227,7 @@ established through the script::
 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::
 
@@ -266,7 +266,7 @@ example:
              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
@@ -284,7 +284,7 @@ example:
 
       $ 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
@@ -302,7 +302,7 @@ example:
         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::
@@ -387,7 +387,7 @@ example:
    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