You should set the subject of the bug to ``ITP: <replaceable>foo</replaceable>
-- <replaceable>short description</replaceable>'', substituting the name of the
new package for <replaceable>foo</replaceable>. The severity of the bug report
-must be set to <emphasis>wishlist</emphasis>. If you feel it's necessary, send
+must be set to <literal>wishlist</literal>. If you feel it's necessary, send
a copy to &email-debian-devel; by putting the address in the
<literal>X-Debbugs-CC:</literal> header of the message (no, don't use
<literal>CC:</literal>, because that way the message's subject won't indicate
<para>
The <filename>debian/changelog</filename> file conforms to a certain structure,
with a number of different fields. One field of note, the
-<emphasis>distribution</emphasis>, is described in <xref
+<literal>distribution</literal>, is described in <xref
linkend="distribution"/> . More information about the structure of this file
can be found in the Debian Policy section titled
<filename>debian/changelog</filename>.
<itemizedlist>
<listitem>
<para>
-the so-called <emphasis>native</emphasis> packages, where there is no
+the so-called <literal>native</literal> packages, where there is no
distinction between the original sources and the patches applied for Debian
</para>
</listitem>
<para>
There are several possible values for this field: `stable', `unstable',
`testing-proposed-updates' and `experimental'. Normally, packages are uploaded
-into <emphasis>unstable</emphasis>.
+into <literal>unstable</literal>.
</para>
<para>
Actually, there are two other possible distributions: `stable-security' and
time.
</para>
<section id="upload-stable">
-<title>Special case: uploads to the <emphasis>stable</emphasis> distribution</title>
+<title>Special case: uploads to the <literal>stable</literal> distribution</title>
<para>
-Uploading to <emphasis>stable</emphasis> means that the package will transfered
-to the <emphasis>p-u-new</emphasis>-queue for review by the stable release
-managers, and if approved will be installed in
+Uploading to <literal>stable</literal> means that the package will transfered
+to the <literal>proposed-updates-new</literal>-queue for review by the stable
+release managers, and if approved will be installed in
<filename>stable-proposed-updates</filename> directory of the Debian archive.
-From there, it will be included in <emphasis>stable</emphasis> with the next
+From there, it will be included in <literal>stable</literal> with the next
point release.
</para>
<para>
-Extra care should be taken when uploading to <emphasis>stable</emphasis>.
+Extra care should be taken when uploading to <literal>stable</literal>.
Basically, a package should only be uploaded to stable if one of the following
happens:
</para>
</listitem>
</itemizedlist>
<para>
-In the past, uploads to <emphasis>stable</emphasis> were used to address
+In the past, uploads to <literal>stable</literal> were used to address
security problems as well. However, this practice is deprecated, as uploads
used for Debian security advisories are automatically copied to the appropriate
<filename>proposed-updates</filename> archive when the advisory is released.
because even trivial fixes can cause bugs later on.
</para>
<para>
-Packages uploaded to <emphasis>stable</emphasis> need to be compiled on systems
-running <emphasis>stable</emphasis>, so that their dependencies are limited to
-the libraries (and other packages) available in <emphasis>stable</emphasis>;
-for example, a package uploaded to <emphasis>stable</emphasis> that depends on
+Packages uploaded to <literal>stable</literal> need to be compiled on systems
+running <literal>stable</literal>, so that their dependencies are limited to
+the libraries (and other packages) available in <literal>stable</literal>;
+for example, a package uploaded to <literal>stable</literal> that depends on
a library package that only exists in unstable will be rejected. Making
changes to dependencies of other packages (by messing with
<literal>Provides</literal> or shlibs files), possibly making those other
</para>
<para>
The Release Team (which can be reached at
-&email-debian-release;) will regularly evaluate the uploads To
-<emphasis>stable-proposed-updates</emphasis> and decide if your package can be
-included in <emphasis>stable</emphasis>. Please be clear (and verbose, if
+&email-debian-release;) will regularly evaluate the uploads to
+<literal>stable-proposed-updates</literal> and decide if your package can be
+included in <literal>stable</literal>. Please be clear (and verbose, if
necessary) in your changelog entries for uploads to
-<emphasis>stable</emphasis>, because otherwise the package won't be considered
+<literal>stable</literal>, because otherwise the package won't be considered
for inclusion.
</para>
<para>
It's best practice to speak with the stable release manager
<emphasis>before</emphasis> uploading to
-<emphasis>stable</emphasis>/<emphasis>stable-proposed-updates</emphasis>, so
+<literal>stable</literal>/<literal>stable-proposed-updates</literal>, so
that the uploaded package fits the needs of the next point release.
</para>
</section>
<section id="upload-t-p-u">
-<title>Special case: uploads to <emphasis>testing/testing-proposed-updates</emphasis></title>
+<title>Special case: uploads to <literal>testing/testing-proposed-updates</literal></title>
<para>
Please see the information in the <link linkend="t-p-u">testing
section</link> for details.
the directory <ulink
url="ftp://&ftp-master-host;&upload-queue;">&upload-queue;</ulink>.
To get the files processed there, they need to be signed with a key in the
-debian keyring.
+Debian Developers keyring or the Debian Maintainers keyring
+(see <ulink url="&url-wiki-dm;"></ulink>).
</para>
<para>
Please note that you should transfer the changes file last. Otherwise, your
<section id="delayed-incoming">
<title>Delayed uploads</title>
<para>
-Delayed uploads are done for the moment via the delayed queue at gluck. The
-upload-directory is <literal>gluck:~tfheen/DELAYED/[012345678]-day</literal>.
-0-day is uploaded multiple times per day to ftp-master.
+Delayed uploads are done for the moment via the delayed queue at <literal>gluck
+</literal>. The upload-directory is
+<literal>gluck:~tfheen/DELAYED/[012345678]-day</literal>. 0-day is uploaded
+multiple times per day to <literal>&ftp-master-host;</literal>.
</para>
<para>
With a fairly recent dput, this section
incoming = ~tfheen
</screen>
<para>
-in ~/.dput.cf should work fine for uploading to the DELAYED queue.
+in <filename>~/.dput.cf</filename> should work fine for uploading to the
+<literal>DELAYED</literal> queue.
</para>
<para>
<emphasis>Note:</emphasis> Since this upload queue goes to
-<literal>ftp-master</literal>, the prescription found in <xref
+<literal>&ftp-master-host;</literal>, the prescription found in <xref
linkend="upload-ftp-master"/> applies here as well.
</para>
</section>
<section id="s5.6.5">
<title>Other upload queues</title>
<para>
-The scp queues on ftp-master, and security are mostly unusable due to the login
-restrictions on those hosts.
+The scp queues on <literal>&ftp-master-host;</literal>, and security are mostly
+unusable due to the login restrictions on those hosts.
</para>
<para>
The anonymous queues on ftp.uni-erlangen.de and ftp.uk.debian.org are currently
The queue in Japan will be replaced with a new queue on hp.debian.or.jp some
day.
</para>
-<para>
-For the time being, the anonymous ftp queue on auric.debian.org (the former
-ftp-master) works, but it is deprecated and will be removed at some point in
-the future.
-</para>
</section>
<section id="upload-notification">
</para>
<para>
The archive maintainers keep track of the canonical sections and priorities for
-packages in the <emphasis>override file</emphasis>. If there is a disparity
-between the <emphasis>override file</emphasis> and the package's fields as
+packages in the <literal>override file</literal>. If there is a disparity
+between the <literal>override file</literal> and the package's fields as
indicated in <filename>debian/control</filename>, then you will receive an
email noting the divergence when the package is installed into the archive.
You can either correct your <filename>debian/control</filename> file for your
-next upload, or else you may wish to make a change in the <emphasis>override
-file</emphasis>.
+next upload, or else you may wish to make a change in the <literal>override
+file</literal>.
</para>
<para>
To alter the actual section that a package is put in, you need to first make
or priority to the new one. Be sure to explain your reasoning.
</para>
<para>
-For more information about <emphasis>override files</emphasis>, see
+For more information about <literal>override files</literal>, see
<citerefentry> <refentrytitle>dpkg-scanpackages</refentrytitle>
<manvolnum>1</manvolnum> </citerefentry> and <ulink
url="&url-bts-devel;#maintincorrect"></ulink>.
</para>
<para>
Once you've dealt with a bug report (e.g. fixed it), mark it as
-<emphasis>done</emphasis> (close it) by sending an explanation message to
+<literal>done</literal> (close it) by sending an explanation message to
<email>123-done@&bugs-host;</email>. If you're fixing a bug by changing
and uploading the package, you can automate bug closing as described in <xref
linkend="upload-bugfix"/> .
</listitem>
<listitem>
<para>
-Once a corrected package is available in the <emphasis>unstable</emphasis>
+Once a corrected package is available in the <literal>unstable</literal>
distribution, you can close the bug. This can be done automatically, read
<xref linkend="upload-bugfix"/> .
</para>
For stable this is <literal>stable-security</literal> and for testing this is
<literal>testing-security</literal>, and for the previous stable release, this
is <literal>oldstable-security</literal>. Do not target
-<replaceable>distribution</replaceable>-proposed-updates or
+<replaceable>distribution</replaceable><literal>-proposed-updates</literal> or
<literal>stable</literal>!
</para>
</listitem>
package, but less than package versions in later distributions. If in doubt,
test it with <literal>dpkg --compare-versions</literal>. Be careful not to
re-use a version number that you have already used for a previous upload. For
-<emphasis>testing</emphasis>, there must be a higher version in
-<emphasis>unstable</emphasis>. If there is none yet (for example, if
-<emphasis>testing</emphasis> and <emphasis>unstable</emphasis> have the same
+<literal>testing</literal>, there must be a higher version in
+<literal>unstable</literal>. If there is none yet (for example, if
+<literal>testing</literal> and <literal>unstable</literal> have the same
version) you must upload a new version to unstable first.
</para>
</listitem>
<para>
If a member of the security team accepts a package, it will be installed on
security.debian.org as well as proposed for the proper
-<replaceable>distribution</replaceable>-proposed-updates on ftp-master.
+<replaceable>distribution</replaceable><literal>-proposed-updates</literal>
+on <literal>&ftp-master-host;</literal>.
</para>
</section>
understand what happened.
</para>
<para>
-If, on the other hand, you need to change the <emphasis>subsection</emphasis>
+If, on the other hand, you need to change the <literal>subsection</literal>
of one of your packages (e.g., ``devel'', ``admin''), the procedure is slightly
different. Correct the subsection as found in the control file of the package,
and re-upload that. Also, you'll need to get the override file updated, as
against <literal>ftp.debian.org</literal> asking that the package be removed;
as all bugs, this bug should normally have normal severity. Make sure you
indicate which distribution the package should be removed from. Normally, you
-can only have packages removed from <emphasis>unstable</emphasis> and
-<emphasis>experimental</emphasis>. Packages are not removed from
-<emphasis>testing</emphasis> directly. Rather, they will be removed
+can only have packages removed from <literal>unstable</literal> and
+<literal>experimental</literal>. Packages are not removed from
+<literal>testing</literal> directly. Rather, they will be removed
automatically after the package has been removed from
-<emphasis>unstable</emphasis> and no package in <emphasis>testing</emphasis>
+<literal>unstable</literal> and no package in <literal>testing</literal>
depends on it.
</para>
<para>
incoming system, this is no longer possible. Instead, you have to upload a new
revision of your package with a higher version than the package you want to
replace. Both versions will be installed in the archive but only the higher
-version will actually be available in <emphasis>unstable</emphasis> since the
+version will actually be available in <literal>unstable</literal> since the
previous version will immediately be replaced by the higher. However, if you
do proper testing of your packages, the need to replace a package should not
occur too often anyway.
<replaceable>package</replaceable> -- <replaceable>short
description</replaceable></literal> indicating that the package is now
orphaned. The severity of the bug should be set to
-<emphasis>normal</emphasis>; if the package has a priority of standard or
+<literal>normal</literal>; if the package has a priority of standard or
higher, it should be set to important. If you feel it's necessary, send a copy
to &email-debian-devel; by putting the address in the
X-Debbugs-CC: header of the message (no, don't use CC:, because that way the
role="package">wnpp</systemitem> and title it <literal>RFA:
<replaceable>package</replaceable> -- <replaceable>short
description</replaceable></literal>. <literal>RFA</literal> stands for
-<emphasis>Request For Adoption</emphasis>.
+<literal>Request For Adoption</literal>.
</para>
<para>
More information is on the <ulink url="&url-wnpp;">WNPP
different from the original architecture of the package maintainer's binary
package. It is a unique and essential activity. In fact, porters do most of
the actual compiling of Debian packages. For instance, for a single
-<emphasis>i386</emphasis> binary package, there must be a recompile for each
+<literal>i386</literal> binary package, there must be a recompile for each
architecture, which amounts to &number-of-arches; more builds.
</para>
<section id="kind-to-porters">
<para>
The <systemitem role="package">buildd</systemitem> system is used as a
distributed, client-server build distribution system. It is usually used in
-conjunction with <emphasis>auto-builders</emphasis>, which are ``slave'' hosts
+conjunction with <literal>build daemons</literal>, which are ``slave'' hosts
which simply check out and attempt to auto-build packages which need to be
ported. There is also an email interface to the system, which allows porters
to ``check out'' a source package (usually one which cannot yet be auto-built)
throughout this document. Both binary-only and source NMUs are similar, since
they involve an upload of a package by a developer who is not the official
maintainer of that package. That is why it's a
-<emphasis>non-maintainer</emphasis> upload.
+<literal>non-maintainer</literal> upload.
</para>
<para>
A source NMU is an upload of a package by a developer who is not the official
Generally there is a primary maintainer and one or more co-maintainers. The
primary maintainer is the person whose name is listed in the
<literal>Maintainer</literal> field of the <filename>debian/control</filename>
-file. Co-maintainers are all the other maintainers.
+file. Co-maintainers are all the other maintainers,
+usually listed in the <literal>Uploaders</literal> field of the
+<filename>debian/control</filename> file.
</para>
<para>
In its most basic form, the process of adding a new co-maintainer is quite
<listitem>
<para>
Add the co-maintainer's correct maintainer name and address to the
-<literal>Uploaders</literal> field in the global part of the
+<literal>Uploaders</literal> field in the first paragraph of the
<filename>debian/control</filename> file.
</para>
<screen>
<section id="testing-unstable">
<title>Updates from unstable</title>
<para>
-The scripts that update the <emphasis>testing</emphasis> distribution are run
+The scripts that update the <literal>testing</literal> distribution are run
each day after the installation of the updated packages; these scripts are
-called <emphasis>britney</emphasis>. They generate the
-<filename>Packages</filename> files for the <emphasis>testing</emphasis>
+called <literal>britney</literal>. They generate the
+<filename>Packages</filename> files for the <literal>testing</literal>
distribution, but they do so in an intelligent manner; they try to avoid any
inconsistency and to use only non-buggy packages.
</para>
<para>
-The inclusion of a package from <emphasis>unstable</emphasis> is conditional on
+The inclusion of a package from <literal>unstable</literal> is conditional on
the following:
</para>
<itemizedlist>
<listitem>
<para>
-The package must have been available in <emphasis>unstable</emphasis> for 2, 5
+The package must have been available in <literal>unstable</literal> for 2, 5
or 10 days, depending on the urgency (high, medium or low). Please note that
the urgency is sticky, meaning that the highest urgency uploaded since the
previous testing transition is taken into account. Those delays may be doubled
</listitem>
<listitem>
<para>
-It must have the same number or fewer release-critical bugs than the version
-currently available in <emphasis>testing</emphasis>;
+It must not have new release-critical bugs (RC bugs affecting the version
+available in <literal>unstable</literal>, but not affecting the version in
+<literal>testing</literal>);
</para>
</listitem>
<listitem>
<listitem>
<para>
It must not break any dependency of a package which is already available in
-<emphasis>testing</emphasis>;
+<literal>testing</literal>;
</para>
</listitem>
<listitem>
<para>
The packages on which it depends must either be available in
-<emphasis>testing</emphasis> or they must be accepted into
-<emphasis>testing</emphasis> at the same time (and they will be if they fulfill
+<literal>testing</literal> or they must be accepted into
+<literal>testing</literal> at the same time (and they will be if they fulfill
all the necessary criteria);
</para>
</listitem>
utility can easily be used in a <citerefentry>
<refentrytitle>crontab</refentrytitle> <manvolnum>5</manvolnum> </citerefentry>
to keep yourself informed of the progression of your packages into
-<emphasis>testing</emphasis>.
+<literal>testing</literal>.
</para>
<para>
The <filename>update_excuses</filename> file does not always give the precise
more information about the usual problems which may be causing such troubles.
</para>
<para>
-Sometimes, some packages never enter <emphasis>testing</emphasis> because the
+Sometimes, some packages never enter <literal>testing</literal> because the
set of inter-relationship is too complicated and cannot be sorted out by the
scripts. See below for details.
</para>
<para>
Sometimes, a package is removed to allow another package in: This happens only
to allow <emphasis>another</emphasis> package to go in if it's ready in every
-other sense. Suppose e.g. that <emphasis>a</emphasis> cannot be installed
-with the new version of <emphasis>b</emphasis>; then <emphasis>a</emphasis> may
-be removed to allow <emphasis>b</emphasis> in.
+other sense. Suppose e.g. that <literal>a</literal> cannot be installed
+with the new version of <literal>b</literal>; then <literal>a</literal> may
+be removed to allow <literal>b</literal> in.
</para>
<para>
Of course, there is another reason to remove a package from testing: It's just
<title>circular dependencies</title>
<para>
A situation which is not handled very well by britney is if package
-<emphasis>a</emphasis> depends on the new version of package
-<emphasis>b</emphasis>, and vice versa.
+<literal>a</literal> depends on the new version of package
+<literal>b</literal>, and vice versa.
</para>
<para>
An example of this is:
</tgroup>
</informaltable>
<para>
-Neither package <emphasis>a</emphasis> nor package <emphasis>b</emphasis> is
+Neither package <literal>a</literal> nor package <literal>b</literal> is
considered for update.
</para>
<para>
The testing distribution is fed with packages from unstable according to the
rules explained above. However, in some cases, it is necessary to upload
packages built only for testing. For that, you may want to upload to
-<emphasis>testing-proposed-updates</emphasis>.
+<literal>testing-proposed-updates</literal>.
</para>
<para>
Keep in mind that packages uploaded there are not automatically processed, they
give on &email-debian-devel-announce;.
</para>
<para>
-You should not upload to <emphasis>testing-proposed-updates</emphasis> when you
-can update your packages through <emphasis>unstable</emphasis>. If you can't
+You should not upload to <literal>testing-proposed-updates</literal> when you
+can update your packages through <literal>unstable</literal>. If you can't
(for example because you have a newer development version in unstable), you may
use this facility, but it is recommended that you ask for authorization from
the release manager first. Even if a package is frozen, updates through
<para>
Version numbers are usually selected by adding the codename of the testing
distribution and a running number, like 1.2sarge1 for the first upload through
-testing-proposed-updates of package version 1.2.
+<literal>testing-proposed-updates</literal> of package version 1.2.
</para>
<para>
Please make sure you didn't miss any of these items in your upload:
<listitem>
<para>
Make sure that your package really needs to go through
-<emphasis>testing-proposed-updates</emphasis>, and can't go through unstable;
+<literal>testing-proposed-updates</literal>, and can't go through unstable;
</para>
</listitem>
<listitem>
</listitem>
<listitem>
<para>
-Make sure that you've written <emphasis>testing</emphasis> or
-<emphasis>testing-proposed-updates</emphasis> into your target distribution;
+Make sure that you've written <literal>testing</literal> or
+<literal>testing-proposed-updates</literal> into your target distribution;
</para>
</listitem>
<listitem>
<para>
Make sure that you've built and tested your package in
-<emphasis>testing</emphasis>, not in <emphasis>unstable</emphasis>;
+<literal>testing</literal>, not in <literal>unstable</literal>;
</para>
</listitem>
<listitem>
<para>
Make sure that your version number is higher than the version in
-<emphasis>testing</emphasis> and <emphasis>testing-proposed-updates</emphasis>,
-and lower than in <emphasis>unstable</emphasis>;
+<literal>testing</literal> and <literal>testing-proposed-updates</literal>,
+and lower than in <literal>unstable</literal>;
</para>
</listitem>
<listitem>
~ianmdlvl / developers-reference.git / blobdiff