[dev-ref] POT and PO updates — trivial unfuzzy for the last consistency fixes

[developers-reference.git] / pkgs.dbk

diff --git a/pkgs.dbk b/pkgs.dbk
index 4982194d41cbbf2d0f9dcb28a036b4b288f773b2..af8bcf072d20967664854fee780ef36ae61f2f02 100644 (file)
--- a/pkgs.dbk
+++ b/pkgs.dbk
@@ -311,8 +311,9 @@ point release.
 </para>
 <para>
 To ensure that your upload will be accepted, you should discuss the changes
-with the stable release team before you upload. For that, send a mail to
-the &email-debian-release; mailing list, including the patch you want to
+with the stable release team before you upload. For that, file a bug against
+the <systemitem role="package">release.debian.org</systemitem> pseudo-package
+using <command>reportbug</command>, including the patch you want to
 apply to the package version currently in <literal>stable</literal>. Always
 be verbose and detailed in your changelog entries for uploads to the
 <literal>stable</literal> distribution.
@@ -1277,7 +1278,7 @@ described in <xref linkend="override-file"/>.
 <para>
 If for some reason you want to completely remove a package (say, if it is an
 old compatibility library which is no longer required), you need to file a bug
-against <literal>ftp.debian.org</literal> asking that the package be removed;
+against <systemitem role="package">&ftp-debian-org;</systemitem> 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> --
@@ -1288,7 +1289,7 @@ short summary of the reason for the removal request.
 if the removal request only applies to some architectures, not all. Note
 that the <command>reportbug</command> will create a title conforming
 to these rules when you use it to report a bug against the
-<literal>ftp.debian.org</literal> pseudo-package.
+<systemitem role="package">&ftp-debian-org;</systemitem> pseudo-package.
 </para>
 
 <para>
@@ -1393,7 +1394,7 @@ Policy Manual</ulink> for details).  Please note that you
 should only add a <literal>Provides</literal> relation if all
 packages depending on the obsolete package name continue to work
 after the renaming. Once you've uploaded the package and the package
-has moved into the archive, file a bug against <literal>ftp.debian.org</literal>
+has moved into the archive, file a bug against <systemitem role="package">&ftp-debian-org;</systemitem>
 asking to remove the package with the
 obsolete name (see <xref linkend="removing-pkgs"/>).  Do not forget
 to properly reassign the package's bugs at the same time.
@@ -2061,7 +2062,7 @@ if the current version is <literal>1.5</literal>, then an NMU would get
 version <literal>1.5+nmu1</literal>.
 </para>
 <para>
-If the package is a not a native package, you should add a minor version number
+If the package is not a native package, you should add a minor version number
 to the Debian revision part of the version number (the portion after the last
 hyphen). This extra number must start at <literal>1</literal>.  For example,
 if the current version is <literal>1.5-2</literal>, then an NMU would get