mirrors/poky
1
0
Fork 0
mirror of https://git.yoctoproject.org/poky synced 2026-05-02 18:32:15 +02:00
Code Issues Packages Projects Releases Wiki Activity

manuals: define proper numbered lists

Browse Source 
Using "#." instead of "1.", "2.", "3.", etc.

(From yocto-docs rev: 11c2585acd0fa6c330702af2359ce5a9e47cde1f)

Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Reported-by: Quentin Schulz <foss+yocto@0leil.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Michael Opdenacker
2022-12-09 19:01:55 +01:00
committed by Richard Purdie
parent 474e071608
commit 6846d4d00b
28 changed files with 347 additions and 347 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
documentation/migration-guides/migration-general.rst
View File

@@ -81,11 +81,11 @@ any new Yocto Project release.
the migration (e.g. added/removed packages, added/removed files, size
changes etc.). To do this, follow these steps:
1. Enable :ref:`buildhistory <ref-classes-buildhistory>` before the migration
#. Enable :ref:`buildhistory <ref-classes-buildhistory>` before the migration
2. Run a pre-migration build
#. Run a pre-migration build
3. Capture the :ref:`buildhistory <ref-classes-buildhistory>` output (as
#. Capture the :ref:`buildhistory <ref-classes-buildhistory>` output (as
specified by :term:`BUILDHISTORY_DIR`) and ensure it is preserved for
subsequent builds. How you would do this depends on how you are running
your builds - if you are doing this all on one workstation in the same
@@ -93,15 +93,15 @@ any new Yocto Project release.
deleting the :ref:`buildhistory <ref-classes-buildhistory>` output
directory. For builds in a pipeline it may be more complicated.
4. Set a tag in the :ref:`buildhistory <ref-classes-buildhistory>` output (which is a git repository) before
#. Set a tag in the :ref:`buildhistory <ref-classes-buildhistory>` output (which is a git repository) before
migration, to make the commit from the pre-migration build easy to find
as you may end up running multiple builds during the migration.
5. Perform the migration
#. Perform the migration
6. Run a build
#. Run a build
7. Check the output changes between the previously set tag and HEAD in the
#. Check the output changes between the previously set tag and HEAD in the
:ref:`buildhistory <ref-classes-buildhistory>` output using ``git diff`` or ``buildhistory-diff``.
For more information on using :ref:`buildhistory <ref-classes-buildhistory>`, see