X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;ds=sidebyside;f=pkgs.dbk;h=d628f6664207ebe8af8668147393ffec5b24c39d;hb=9013cb0bebd7ad1b15fa45b091fa7a62e64bc43e;hp=6eaed078459bffaa9e884bbe7053e93451def3b3;hpb=0118327fd29813955cacb89825955bfb6e47576c;p=developers-reference.git

diff --git a/pkgs.dbk b/pkgs.dbk
index 6eaed07..d628f66 100644
--- a/pkgs.dbk
+++ b/pkgs.dbk
@@ -1344,6 +1344,10 @@ should either be reassigned to another package in the case where the actual
 code has evolved into another package (e.g.  <literal>libfoo12</literal> was
 removed because <literal>libfoo13</literal> supersedes it) or closed if the
 software is simply no longer part of Debian.
+When closing the bugs,
+to avoid marking the bugs as fixed in versions of the packages
+in previous Debian releases, they should be marked as fixed
+in the version <literal>&lt;most-recent-version-ever-in-Debian&gt;+rm</literal>.
 </para>
 <section id="s5.9.2.1">
 <title>Removing packages from <filename>Incoming</filename></title>
@@ -1787,17 +1791,15 @@ flavor of Debian built with <command>gcc</command> bounds checking).  It will
 also enable Debian to recompile entire distributions quickly.
 </para>
 <para>
-The buildds admins of each arch can be contacted at the mail address
-<literal><replaceable>arch</replaceable>@buildd.debian.org</literal>.
+The wanna-build team, in charge of the buildds,
+can be reached at <literal>debian-wb-team@lists.debian.org</literal>.
+To determine who (wanna-build team, release team) and how (mail, BTS)
+to contact, refer to <ulink url="&url-wb-team;"></ulink>.
 </para>
 
 <para>
-Since the Release team also has access to wanna-build,
-it has become common practice to ask them to perform actions such as
-the recompilation of packages (binNMUs, see <xref linkend="binary-only-nmu"/>)
-or the retry of failed builds (give-backs).
-The format to use when requesting such actions is described at
-<ulink url="&url-release-wb;"/>.
+When requesting binNMUs or give-backs (retries after a failed build),
+please use the format described at <ulink url="&url-release-wb;"/>.
 </para>
 
 </section>
@@ -1999,18 +2001,33 @@ upload.  The first line of this entry must explicitely mention that this upload
 </screen>
 
 <para>
-The version must be the version of the last maintainer upload, plus
+The way to version NMUs differs for native and non-native packages.
+</para>
+<para>
+If the package is a native package (without a debian revision in the version number), 
+the version must be the version of the last maintainer upload, plus
 <literal>+nmu<replaceable>X</replaceable></literal>, where
-<replaceable>X</replaceable> is a counter starting at <literal>1</literal>.  If
+<replaceable>X</replaceable> is a counter starting at <literal>1</literal>.
+If
 the last upload was also an NMU, the counter should be increased.  For example,
-if the current version is <literal>1.5-1</literal>, then an NMU would get
-version <literal>1.5-1+nmu1</literal>.  If the current version is
-<literal>1.5+nmu3</literal> (a native package which has already been NMUed), the
-NMU would get version <literal>1.5+nmu4</literal>.  If a new upstream version
+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
+to the debian revision part of the version number (the portion after the last
+hyphen). This extra number must start at 1.  For example,
+if the current version is <literal>1.5-2</literal>, then an NMU would get
+version <literal>1.5-2.1</literal>. If a new upstream version
 is packaged in the NMU, the debian revision is set to <literal>0</literal>, for
-example <literal>1.6-0+nmu1</literal>.
+example <literal>1.6-0.1</literal>.
+</para>
+<para>
+In both cases, if the last upload was also an NMU, the counter should
+be increased. For example, if the current version is
+<literal>1.5+nmu3</literal> (a native package which has already been
+NMUed), the NMU would get version <literal>1.5+nmu4</literal>.  .
 </para>
-
 <para>
 A special versioning scheme is needed to avoid disrupting the maintainer's
 work, since using an integer for the Debian revision will potentially