From fd33305f4875ecb7266063a04b549aad9532ecce Mon Sep 17 00:00:00 2001
From: lucas <lucas@313b444b-1b9f-4f58-a734-7bb04f332e8d>
Date: Sat, 7 Jun 2008 22:36:10 +0000
Subject: [PATCH] Fix some typos in tag names.

Note that 'make index.html' allows to regenerate only the HTML version, which
is quite handy for a pre-commit test ;)



git-svn-id: svn://anonscm.debian.org/ddp/manuals/trunk/developers-reference@5222 313b444b-1b9f-4f58-a734-7bb04f332e8d
---
 pkgs.dbk | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/pkgs.dbk b/pkgs.dbk
index 7c6b32d..f6206d0 100644
--- a/pkgs.dbk
+++ b/pkgs.dbk
@@ -270,7 +270,7 @@ The package build process extracts this information from the first line of the
 </para>
 <para>
 There are several possible values for this field: <literal>stable</literal>,
-<literal>unstable</literal>, <litersl>testing-proposed-updates</literal> and
+<literal>unstable</literal>, <literal>testing-proposed-updates</literal> and
 <literal>experimental</literal>.  Normally, packages are uploaded into
 <literal>unstable</literal>.
 </para>
@@ -1110,7 +1110,7 @@ uploads as well.
 Unless the upstream source has been uploaded to <literal>security.debian.org
 </literal> before (by a previous security update), build the upload with full
 upstream source (<literal>dpkg-buildpackage -sa</literal>).  If there has been
-a previous upload to </literal>security.debian.org</literal> with the same
+a previous upload to <literal>security.debian.org</literal> with the same
 upstream version, you may upload without upstream source (<literal>
 dpkg-buildpackage -sd</literal>).
 </para>
@@ -1227,7 +1227,7 @@ against <literal>ftp.debian.org</literal> asking that the package be removed;
 as all bugs, this bug should normally have normal severity.
 The bug title should be in the form <literal>RM: <replaceable>package
 </replaceable> <replaceable>[architecture list]</replaceable> -- 
-<replaceable>reason</replaceable>, where <replaceable>package</replaceable>
+<replaceable>reason</replaceable></literal>, where <replaceable>package</replaceable>
 is the package to be removed and <replaceable>reason</replaceable> is a
 short summary of the reason for the removal request. 
 <replaceable>[architecture list]</replaceable> is optional and only needed
@@ -1610,9 +1610,9 @@ source code).
 <para>
 The ``magic'' for a recompilation-only NMU is triggered by using a suffix
 appended to the package version number, following the form <literal>
-b<replaceable>number<replaceable>.
+b<replaceable>number</replaceable></literal>.
 For instance, if the latest version you are recompiling against was version
-<literal>2.9-3<literal>, your binary-only NMU should carry a version of 
+<literal>2.9-3</literal>, your binary-only NMU should carry a version of 
 <literal>2.9-3+b1</literal>.  If the latest version was <literal>3.4+b1
 </literal> (i.e, a native package with a previous recompilation NMU), your
 binary-only NMU should have a version number of <literal>3.4+b2</literal>.
@@ -2221,7 +2221,7 @@ after they have undergone some degree of <literal>testing</literal> in
 They must be in sync on all architectures and mustn't have dependencies that
 make them uninstallable; they also have to have generally no known
 release-critical bugs at the time they're installed into <literal>testing
-<literal>.  This way, <literal>testing</literal> should always be close to
+</literal>.  This way, <literal>testing</literal> should always be close to
 being a release candidate.  Please see below for details.
 </para>
 </section>
@@ -2347,7 +2347,7 @@ Consider this example:
 </informaltable>
 <para>
 The package is out of date on alpha in <literal>unstable</literal>, and will
-not go to <literal>testing. Removing the package would not help at all, the
+not go to <literal>testing</literal>. Removing the package would not help at all, the
 package is still out of date on <literal>alpha</literal>, and will not 
 propagate to testing.
 </para>
-- 
2.30.2