1 files changed, 11 insertions, 11 deletions

diff --git a/documentation/dev-manual/debugging.rst b/documentation/dev-manual/debugging.rst
index f433e8e6a9..921022475f 100644
--- a/documentation/dev-manual/debugging.rst
+++ b/documentation/dev-manual/debugging.rst
@@ -297,11 +297,11 @@ If you are unsure whether a variable dependency is being picked up
 automatically for a given task, you can list the variable dependencies
 BitBake has determined by doing the following:
 
-1. Build the recipe containing the task::
+#. Build the recipe containing the task::
 
    $ bitbake recipename
 
-2. Inside the :term:`STAMPS_DIR`
+#. Inside the :term:`STAMPS_DIR`
    directory, find the signature data (``sigdata``) file that
    corresponds to the task. The ``sigdata`` files contain a pickled
    Python database of all the metadata that went into creating the input
@@ -319,7 +319,7 @@ BitBake has determined by doing the following:
    the cached task output. The ``siginfo`` files contain exactly the
    same information as ``sigdata`` files.
 
-3. Run ``bitbake-dumpsig`` on the ``sigdata`` or ``siginfo`` file. Here
+#. Run ``bitbake-dumpsig`` on the ``sigdata`` or ``siginfo`` file. Here
    is an example::
 
       $ bitbake-dumpsig ${BUILDDIR}/tmp/stamps/i586-poky-linux/db/6.0.30-r1.do_fetch.sigdata.7c048c18222b16ff0bcee2000ef648b1
@@ -992,7 +992,7 @@ site <https://sourceware.org/gdb/documentation/>`__.
 The following steps show you how to debug using the GNU project
 debugger.
 
-1. *Configure your build system to construct the companion debug
+#. *Configure your build system to construct the companion debug
    filesystem:*
 
    In your ``local.conf`` file, set the following::
@@ -1012,7 +1012,7 @@ debugger.
    the full filesystem for debugging. Subsequent steps in this procedure
    show how to combine the partial filesystem with the full filesystem.
 
-2. *Configure the system to include gdbserver in the target filesystem:*
+#. *Configure the system to include gdbserver in the target filesystem:*
 
    Make the following addition in your ``local.conf`` file::
 
@@ -1021,7 +1021,7 @@ debugger.
    The change makes
    sure the ``gdbserver`` package is included.
 
-3. *Build the environment:*
+#. *Build the environment:*
 
    Use the following command to construct the image and the companion
    Debug Filesystem::
@@ -1057,7 +1057,7 @@ debugger.
       the actual image (e.g. ``gdb-cross-i586``). The suggestion is usually the
       actual name you want to use.
 
-4. *Set up the* ``debugfs``\ *:*
+#. *Set up the* ``debugfs``\ *:*
 
    Run the following commands to set up the ``debugfs``::
 
@@ -1066,7 +1066,7 @@ debugger.
       $ tar xvfj build-dir/tmp/deploy/images/machine/image.rootfs.tar.bz2
       $ tar xvfj build-dir/tmp/deploy/images/machine/image-dbg.rootfs.tar.bz2
 
-5. *Set up GDB:*
+#. *Set up GDB:*
 
    Install the SDK (if you built one) and then source the correct
    environment file. Sourcing the environment file puts the SDK in your
@@ -1075,7 +1075,7 @@ debugger.
    If you are using the build system, Gdb is located in
    `build-dir`\ ``/tmp/sysroots/``\ `host`\ ``/usr/bin/``\ `architecture`\ ``/``\ `architecture`\ ``-gdb``
 
-6. *Boot the target:*
+#. *Boot the target:*
 
    For information on how to run QEMU, see the `QEMU
    Documentation <https://wiki.qemu.org/Documentation/GettingStartedDevelopers>`__.
@@ -1084,7 +1084,7 @@ debugger.
 
       Be sure to verify that your host can access the target via TCP.
 
-7. *Debug a program:*
+#. *Debug a program:*
 
    Debugging a program involves running gdbserver on the target and then
    running Gdb on the host. The example in this step debugs ``gzip``:
@@ -1116,7 +1116,7 @@ debugger.
       users ``~/.gdbinit`` file. Upon starting, Gdb automatically runs whatever
       commands are in that file.
 
-8. *Deploying without a full image rebuild:*
+#. *Deploying without a full image rebuild:*
 
    In many cases, during development you want a quick method to deploy a
    new binary to the target and debug it, without waiting for a full