Remove all p elements below dd.

Where necessary, use multiple dd elements instead.

Signed-off-by: Ulrich Müller <ulm@gentoo.org>

8 files changed, 31 insertions, 85 deletions

diff --git a/appendices/common-problems/text.xml b/appendices/common-problems/text.xml
index 3af479b..430e74b 100644
--- a/appendices/common-problems/text.xml
+++ b/appendices/common-problems/text.xml
@@ -56,36 +56,30 @@ in use, there are various alternatives:
     <c>sed</c>, <c>awk</c>, <c>grep</c>, <c>egrep</c>, <c>cut</c> etc
   </dt>
   <dd>
-    <p>
     Usually when any of the above are used in global scope, it is to manipulate
     a version or program name string. These should be avoided in favour of
     pure <c>bash</c> constructs. The <c>eapi7-ver</c> eclass is often of use here.
     See <uri link="::ebuild-writing/variables/#Version and Name Formatting Issues"/>,
     <c>man eapi7-ver.eclass</c> and <uri
     link="::tools-reference/bash/#Bash Variable Manipulation"/>.
-    </p>
   </dd>
   <dt>
     <c>has_version</c>, <c>best_version</c>
   </dt>
   <dd>
-    <p>
     Calls to either of these globally indicates a serious problem. You must <b>not</b>
     have metadata varying based upon system-dependent information <d/> see
     <uri link="::general-concepts/portage-cache/"/>. You should rewrite your ebuilds
     to correctly use dependencies.
-    </p>
   </dd>
   <dt>
     <c>python</c>, <c>perl</c> etc
   </dt>
   <dd>
-    <p>
     Ebuilds are <c>bash</c> scripts. Offloading anything you don't know how to do
     in <c>bash</c> onto another language is not acceptable <d/> if nothing else,
     because not all users will always have a full system when ebuilds are
     sourced.
-    </p>
   </dd>
 </dl>
 
diff --git a/appendices/contributing/text.xml b/appendices/contributing/text.xml
index 4b65c41..d17205a 100644
--- a/appendices/contributing/text.xml
+++ b/appendices/contributing/text.xml
@@ -81,34 +81,29 @@ really should first examine the GuideXML guide in a reasonable amount of depth.
     Indentation
   </dt>
   <dd>
-    <p>
-      Indent when needed <d/> you should not indent any section flow elements such as
-      <c>&lt;subsection&gt;</c> but do indent tables, lists and definition lists.
-      Do <e>not</e> indent text in ordinary paragraph blocks.
-    </p>
+    Indent when needed <d/> you should not indent any section flow elements
+    such as <c>&lt;subsection&gt;</c> but do indent tables, lists and
+    definition lists. Do <e>not</e> indent text in ordinary paragraph blocks.
   </dd>
   <dt>
     Code Samples
   </dt>
   <dd>
-    <p>
-      You can use the normal GuideXML tag <c>&lt;pre&gt;</c> when you need no syntax
-      highlighting. When you need syntax highlighting use the <c>&lt;codesample&gt;</c>
-      tag along with a <c>lang</c> attribute <d/> usually you want this to be set to
-      <c>ebuild</c> to syntax highlight ebuild code snippets.
-    </p>
+    You can use the normal GuideXML tag <c>&lt;pre&gt;</c> when you need
+    no syntax highlighting. When you need syntax highlighting use the
+    <c>&lt;codesample&gt;</c> tag along with a <c>lang</c> attribute <d/>
+    usually you want this to be set to <c>ebuild</c> to syntax highlight ebuild
+    code snippets.
   </dd>
   <dt>
     Hierarchy
   </dt>
   <dd>
-    <p>
-      The whole document is organized as a tree. Each directory can contain one
-      document. Each document can inherit multiple sub-documents using the
-      <c>&lt;include&gt;</c> flag. You <b>must</b> ensure that the <c>self</c> tag
-      in each document correctly points to the relative path of the document from
-      the root node so that the tree-walking algorithms work correctly.
-    </p>
+    The whole document is organized as a tree. Each directory can contain
+    one document. Each document can inherit multiple sub-documents using the
+    <c>&lt;include&gt;</c> flag. You <b>must</b> ensure that the <c>self</c>
+    tag in each document correctly points to the relative path of the document
+    from the root node so that the tree-walking algorithms work correctly.
   </dd>
 </dl>
 
diff --git a/appendices/further-reading/text.xml b/appendices/further-reading/text.xml
index d48277c..0a658f6 100644
--- a/appendices/further-reading/text.xml
+++ b/appendices/further-reading/text.xml
@@ -19,12 +19,10 @@ recommendations, not padding designed to make this document look important.
     Mastering Regular Expressions
   </dt>
   <dd>
-    <p>
     "Mastering Regular Expressions" by Jeffrey E. F. Friedl (O'Reilly,
     ISBN 0-596-00289-0) is <b>the</b> book on regular expressions. Very readable and
     devoid of the usual mathematical jargon that tends to fill up these kinds of
     books. <uri link="http://www.oreilly.com/catalog/regex2/">Publisher's page</uri>
-    </p>
   </dd>
 </dl>
 
@@ -40,21 +38,17 @@ recommendations, not padding designed to make this document look important.
     Making Packager-Friendly Software
   </dt>
   <dd>
-    <p>
     <uri link="http://www.onlamp.com/pub/a/onlamp/2005/03/31/packaging.html">Making
     Packager-Friendly Software</uri> by Julio M. Merino Vidal describes various things
     that can be done by upstream software providers to make life easy for the
     distribution people (that means you).
-    </p>
   </dd>
   <dt>
     How to Report Bugs Effectively
   </dt>
   <dd>
-    <p>
     <uri link="https://www.chiark.greenend.org.uk/~sgtatham/bugs.html">How to Report Bugs
     Effectively</uri> by Simon Tatham is a good overview of effective bug reporting.
-    </p>
   </dd>
 </dl>
 
diff --git a/archs/amd64/text.xml b/archs/amd64/text.xml
index 392999b..0f75426 100644
--- a/archs/amd64/text.xml
+++ b/archs/amd64/text.xml
@@ -269,25 +269,19 @@ configurations.
     d
   </dt>
   <dd>
-    <p>
-      Directory containing mixed-bit objects
-    </p>
+    Directory containing mixed-bit objects
   </dd>
   <dt>
     dXX
   </dt>
   <dd>
-    <p>
-      Directory containing XXbit objects
-    </p>
+    Directory containing XXbit objects
   </dd>
   <dt>
     l->foo
   </dt>
   <dd>
-    <p>
-      Link to foo
-    </p>
+    Link to foo
   </dd>
 </dl>
 
diff --git a/ebuild-writing/eapi/text.xml b/ebuild-writing/eapi/text.xml
index 3f9590d..cb49e35 100644
--- a/ebuild-writing/eapi/text.xml
+++ b/ebuild-writing/eapi/text.xml
@@ -624,17 +624,17 @@ src_install() {
 		</p>
 			<dl>
 				<dt><c>source</c></dt>
-				<dd><p>
+				<dd>
 					if building and installing a package from source,
-				</p></dd>
+				</dd>
 				<dt><c>binary</c></dt>
-				<dd><p>
+				<dd>
 					if installing a binary package,
-				</p></dd>
+				</dd>
 				<dt><c>buildonly</c></dt>
-				<dd><p>
+				<dd>
 					if building a binary package without installing it.
-				</p></dd>
+				</dd>
 			</dl>
 	</li>
 	<li>
diff --git a/general-concepts/tree/text.xml b/general-concepts/tree/text.xml
index 4afd8d5..4d2bf64 100644
--- a/general-concepts/tree/text.xml
+++ b/general-concepts/tree/text.xml
@@ -113,87 +113,70 @@ Software-wise, in general all of the following should be met in order for a pack
 <dl>
 <dt>Active, Cooperative Upstream</dt>
 <dd>
-  <p>
   If a package is undeveloped or unmaintained upstream, it can be extremely
   difficult to get problems fixed. If a package does not have an active
   upstream, the developers who add the package to the tree must ensure that
   they are able to fix any issues which may arise.
-  </p>
-  <p>
+</dd>
+<dd>
   Sometimes upstream may have a reason for not wanting their package included
   in the tree. This should be respected.
-  </p>
 </dd>
 
 <dt>Reasonably Stable</dt>
 <dd>
-  <p>
   Keep super-experimental things out of the tree. If you must commit them,
   consider using <c>package.mask</c> until things calm down, or better yet make
   them available as overlay ebuilds.
-  </p>
 </dd>
 
 <dt>Reasonably Useful</dt>
 <dd>
-  <p>
   Don't feel obliged to include "Joe's '1337 XMMS Skinz Collection" or "Hans'
   Super Cool Fast File System" in the tree just because a few users ask for
   it. Stick to things that might actually be of use.
-  </p>
 </dd>
 
 <dt>Properly Packaged</dt>
 <dd>
-  <p>
   If something is only available in live CVS or dodgy autopackage format,
   don't include it until upstream can come up with a decent source package.
   Similarly, avoid things that don't have a proper build system (where
   relevant) <d/> these are very tricky to maintain.
-  </p>
 </dd>
 
 <dt>Patching and Distribution Permitted</dt>
 <dd>
-  <p>
   If we can't patch packages as necessary ourselves, we end up relying
   entirely upon upstream for support. This can be problematic, especially if
   upstream are slow at fixing things. We don't want to be in the situation
   where we can't stable a critical package because we're still waiting for a
   closed-source vendor to get their act together.
-  </p>
-
-  <p>
+</dd>
+<dd>
   Similarly, not being able to mirror and distribute tarballs ourselves makes
   us rely entirely upon upstream mirrors. Experience has shown that these are
   often extremely unreliable, with files changing, moving or vanishing at
   random.
-  </p>
 </dd>
 
 <dt>Working Ebuilds</dt>
 <dd>
-  <p>
   If you don't have a <e>working</e> ebuild, don't include it.
-  </p>
 </dd>
 
 <dt>Portable</dt>
 <dd>
-  <p>
   If software is unportable, it's generally because it's badly written.
   Remember that although x86 has a market majority <e>now</e>, it probably won't in
   the not too distant future once x86-64 catches on.
-  </p>
 </dd>
 
 <dt>Reasonable Security Record</dt>
 <dd>
-  <p>
   Don't include software that has a terrible security record. Each
   vulnerability is a <e>lot</e> of work for a lot of people (security teams, arch
   teams and package maintainers).
-  </p>
 </dd>
 </dl>
 
diff --git a/keywording/text.xml b/keywording/text.xml
index 2149f2d..a1dbed1 100644
--- a/keywording/text.xml
+++ b/keywording/text.xml
@@ -41,41 +41,33 @@ The different levels of keyword are:
     <c>arch</c> (<c>x86</c>, <c>ppc-macos</c>)
   </dt>
   <dd>
-    <p>
     Both the package version <e>and</e> the ebuild are widely tested, known to work
     and not have any serious issues on the indicated platform.
-    </p>
   </dd>
   <dt>
     <c>~arch</c> (<c>~x86</c>, <c>~ppc-macos</c>)
   </dt>
   <dd>
-    <p>
     The package version and the ebuild are believed to work and do not have any
     known serious bugs, but more testing is required before the package version
     is considered suitable for <c>arch</c>.
-    </p>
   </dd>
   <dt>
     No keyword
   </dt>
   <dd>
-    <p>
     If a package has no keyword for a given arch, it means it is not known
     whether the package will work, or that insufficient testing has occurred for
     <c>~arch</c>.
-    </p>
   </dd>
   <dt>
     <c>-arch</c> (<c>-x86</c>, <c>-ppc-macos</c>)
   </dt>
   <dd>
-    <p>
     The package version will not work on the arch. This could be caused by badly
     written code (for example, non-64-bit or endian clean code), relying upon
     particular hardware (for example, a BIOS querying tool would not work on
     non-BIOS architectures) or binary only packages.
-    </p>
   </dd>
 </dl>
 
diff --git a/tools-reference/tr/text.xml b/tools-reference/tr/text.xml
index e7002e1..8a1a236 100644
--- a/tools-reference/tr/text.xml
+++ b/tools-reference/tr/text.xml
@@ -26,27 +26,21 @@ and only writes to standard output. Therefore, you will have to use
     Deleting characters
   </dt>
   <dd>
-    <p>
-      To delete all occurrences of certain characters, use <c>tr -d asdf</c>.
-    </p>
+    To delete all occurrences of certain characters, use <c>tr -d asdf</c>.
   </dd>
   <dt>
     Deleting repeated characters
   </dt>
   <dd>
-    <p>
-      To replace repeated characters with a single character ('squeeze'), use
-      <c>tr -s asdf</c>.
-    </p>
+    To replace repeated characters with a single character ('squeeze'), use
+    <c>tr -s asdf</c>.
   </dd>
   <dt>
     Transliterating characters
   </dt>
   <dd>
-    <p>
-      To replace all 'a' characters with '1', all 'b' with '2' and all 'c' with
-      '3', use <c>tr abc 123</c>.
-    </p>
+    To replace all 'a' characters with '1', all 'b' with '2' and all 'c' with
+    '3', use <c>tr abc 123</c>.
   </dd>
 </dl>