</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>
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>
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
<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>.
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>
</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>