diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml b/documentation/dev-manual/dev-manual-common-tasks.xml
index abecc74547..834e0a4040 100644
--- a/documentation/dev-manual/dev-manual-common-tasks.xml
+++ b/documentation/dev-manual/dev-manual-common-tasks.xml
@@ -4104,18 +4104,23 @@
This section describes a few tasks that involve packages:
- Excluding packages from an image
+
+ Excluding packages from an image
- Incrementing a package revision number
+
+ Incrementing a package revision number
- Handling a package name alias
+
+ Handling a package name alias
- Handling optional module packaging
+
+ Handling optional module packaging
- Using Runtime Package Management
+
+ Using Runtime Package Management
- Setting up and running package test
- (ptest)
+
+ Setting up and running package test (ptest)
@@ -4203,7 +4208,7 @@
As mentioned, attempting to maintain revision numbers in the
Metadata
- is error prone, inaccurate and causes problems for people
+ is error prone, inaccurate, and causes problems for people
submitting recipes.
Conversely, the PR Service automatically generates
increasing numbers, particularly the revision field,
@@ -4222,7 +4227,7 @@
PE,
PV, and
PR
- for epoch, version and revision, respectively).
+ for epoch, version, and revision, respectively).
The values are highly dependent on the policies and
procedures of a given distribution and package feed.
@@ -4257,7 +4262,7 @@
r0.2 and so forth.
This scheme allows existing PR values
to be used for whatever reasons, which include manual
- PR bumps should it be necessary.
+ PR bumps, should it be necessary.
@@ -4302,7 +4307,7 @@
- It is also recommended you use Build History, which adds
+ It is also recommended you use build history, which adds
some sanity checks to package versions, in conjunction with
the server that is running the PR Service.
To enable build history, add the following to each building
@@ -4312,7 +4317,7 @@
INHERIT += "buildhistory"
BUILDHISTORY_COMMIT = "1"
- For information on Build History, see the
+ For information on build history, see the
"Maintaining Build Output Quality"
section in the Yocto Project Reference Manual.
@@ -4454,9 +4459,9 @@
To handle optional module packaging, you need to do two things:
Ensure the module packaging is actually
- done
+ done.
Ensure that any dependencies on optional
- modules from other recipes are satisfied by your recipe
+ modules from other recipes are satisfied by your recipe.
@@ -4494,7 +4499,7 @@
A directory within the files installed
by your recipe through do_install
in which to search.
- A regular expression to match module
+ A regular expression used to match module
files in that directory.
In the example, note the parentheses () that mark
the part of the expression from which the module
@@ -4759,7 +4764,7 @@
When BitBake generates packages it needs to know
- what format(s) to use.
+ what format or formats to use.
In your configuration, you use the
PACKAGE_CLASSES
variable to specify the format.
@@ -5092,7 +5097,9 @@
- A recipe is "ptest-enabled" if it inherits ptest.
+ A recipe is "ptest-enabled" if it inherits the
+ ptest
+ class.
@@ -5140,7 +5147,9 @@
Here is what you have to do for each recipe:
Be sure the recipe
- inherits ptest:
+ inherits the
+ ptest
+ class:
Include the following line in each recipe:
inherit ptest
@@ -5216,7 +5225,7 @@
Install the test
suite:
- The ptest.bbclass class
+ The ptest class
automatically copies the file
run-ptest to the target and
then runs make install-ptest