Bumped debhelper compat level to 5 (4 was deprecated)

[developers-reference.git] / pkgs.dbk

diff --git a/pkgs.dbk b/pkgs.dbk
index e9b058a3e2486f6fa535671aedb3705c08bfad3c..160fa5b11a08fdd1a80ebd4e05bad81eb3e3c6f4 100644 (file)
--- a/pkgs.dbk
+++ b/pkgs.dbk
@@ -48,6 +48,12 @@ new package in order for the bug report to be automatically closed once the new
 package is installed in the archive (see <xref linkend="upload-bugfix"/> ).
 </para>
 <para>
 package is installed in the archive (see <xref linkend="upload-bugfix"/> ).
 </para>
 <para>

+If you think your package needs some explanations for the administrators of the
+NEW package queue, include them in your changelog, send to ftpmaster@debian.org
+a reply to the email you receive as a maintainer after your upload, or reply to
+the rejection email in case you are already re-uploading.
+</para>
+<para>

 When closing security bugs include CVE numbers as well as the Closes: #nnnnn.
 This is useful for the security team to track vulnerabilities.  If an upload is
 made to fix the bug before the advisory ID is known, it is encouraged to modify
 When closing security bugs include CVE numbers as well as the Closes: #nnnnn.
 This is useful for the security team to track vulnerabilities.  If an upload is
 made to fix the bug before the advisory ID is known, it is encouraged to modify


@@ -1784,6 +1790,16 @@ also enable Debian to recompile entire distributions quickly.
 The buildds admins of each arch can be contacted at the mail address
 <literal><replaceable>arch</replaceable>@buildd.debian.org</literal>.
 </para>
 The buildds admins of each arch can be contacted at the mail address
 <literal><replaceable>arch</replaceable>@buildd.debian.org</literal>.
 </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;"/>.
+</para>
+

 </section>
 
 </section>
 </section>
 
 </section>


@@ -1983,18 +1999,33 @@ upload.  The first line of this entry must explicitely mention that this upload
 </screen>
 
 <para>
 </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
 <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,
 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
 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>

-

 <para>
 A special versioning scheme is needed to avoid disrupting the maintainer's
 work, since using an integer for the Debian revision will potentially
 <para>
 A special versioning scheme is needed to avoid disrupting the maintainer's
 work, since using an integer for the Debian revision will potentially