<title>Uploading to <literal>ftp-master</literal></title>
<para>
To upload a package, you should upload the files (including the signed changes
-and dsc-file) with anonymous ftp to <literal>&ftp-master-host;</literal> in
+and dsc-file) with anonymous ftp to <literal>&ftp-upload-host;</literal> in
the directory <ulink
-url="ftp://&ftp-master-host;&upload-queue;">&upload-queue;</ulink>.
+url="ftp://&ftp-upload-host;&upload-queue;">&upload-queue;</ulink>.
To get the files processed there, they need to be signed with a key in the
Debian Developers keyring or the Debian Maintainers keyring
(see <ulink url="&url-wiki-dm;"></ulink>).
automate the process of uploading packages into Debian.
</para>
<para>
-For removing packages, please see the README file in that ftp directory, and
+For removing packages, please see
+<ulink url="ftp://&ftp-upload-host;&upload-queue;/README"/> and
the Debian package <xref linkend="dcut"/> .
</para>
</section>
When the specified waiting time is over, the package is moved into
the regular incoming directory for processing.
This is done through automatic uploading to
-<literal>&ftp-master-host;</literal> in upload-directory
+<literal>&ftp-upload-host;</literal> in upload-directory
<literal>DELAYED/[012345678]-day</literal>. 0-day is uploaded
-multiple times per day to <literal>&ftp-master-host;</literal>.
+multiple times per day to <literal>&ftp-upload-host;</literal>.
</para>
<para>
With dput, you can use the <literal>--delayed <replaceable>DELAY</replaceable></literal>
<para>
The queues on master.debian.org, samosa.debian.org, master.debian.or.jp, and
ftp.chiark.greenend.org.uk are down permanently, and will not be resurrected.
-The queue in Japan will be replaced with a new queue on hp.debian.or.jp some
-day.
</para>
</section>
<para>
To alter the actual section that a package is put in, you need to first make
sure that the <filename>debian/control</filename> file in your package is
-accurate. Next, send an email &email-override; or submit a
+accurate. Next, submit a
bug against <systemitem role="package">ftp.debian.org</systemitem> requesting
that the section or priority for your package be changed from the old section
-or priority to the new one. Be sure to explain your reasoning.
+or priority to the new one. Use a Subject like
+<literal>override: PACKAGE1:section/priority, [...],
+ PACKAGEX:section/priority</literal>, and include the justification for the
+change in the body of the bug report.
</para>
<para>
For more information about <literal>override files</literal>, see
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