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><most-recent-version-ever-in-Debian>+rm</literal>.
</para>
<section id="s5.9.2.1">
<title>Removing packages from <filename>Incoming</filename></title>
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>
</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
~ianmdlvl / developers-reference.git / blobdiff