X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=developers-reference.sgml;h=a6713b2451e7ad133223cf3fb21f666934d2de53;hb=736008ae11b85d30f13565f36c74edbf7e3e90d6;hp=ad13458ffb2f7eb1590992fa4df66fee3a82aa8c;hpb=14f5c5a7d104199df70ed7ca5e59f2a073276534;p=developers-reference.git diff --git a/developers-reference.sgml b/developers-reference.sgml index ad13458..a6713b2 100644 --- a/developers-reference.sgml +++ b/developers-reference.sgml @@ -2,11 +2,12 @@ %versiondata; - + %commondata; + %dynamicdata; - + @@ -21,7 +22,8 @@
It should be clear that this reference does not discuss the technical
-details of the Debian package nor how to generate Debian packages.
+details of Debian packages nor how to generate them.
Nor does this reference detail the standards to which Debian software
must comply. All of such information can be found in the
Furthermore, this document is not an expression of formal
policy. It contains documentation for the Debian system and
-generally agreed-upon best practices. Thus, it is what is called a
+generally agreed-upon best practices. Thus, it is not what is called a
``normative'' document.
@@ -113,31 +124,63 @@ to work on something to avoid duplicated effort.
Another good list to subscribe to is &email-debian-mentors;. See for details. The IRC channel #debian can also be
-helpful.
+helpful; see .
When you know how you want to contribute to &debian-formal;, you
should get in contact with existing Debian maintainers who are working
on similar tasks. That way, you can learn from experienced developers.
For example, if you are interested in packaging existing software for
-Debian you should try to get a sponsor. A sponsor will work together
+Debian, you should try to get a sponsor. A sponsor will work together
with you on your package and upload it to the Debian archive once they
are happy with the packaging work you have done. You can find a sponsor
by mailing the &email-debian-mentors; mailing list, describing your
package and yourself and asking for a sponsor (see
-for more information on sponsoring). On the other hand, if you are
+and
+One pitfall could be a too-generic local part in your mailadress:
+Terms like mail, admin, root, master should be avoided, please
+see
+The mailing list &email-debian-mentors; has been set up for novice
+maintainers who seek help with initial packaging and other
+developer-related issues. Every new developer is invited to subscribe
+to that list (see for details).
+
+Those who prefer one-on-one help (e.g., via private email) should also
+post to that list and an experienced developer will volunteer to help.
+
+In addition, if you have some packages ready for inclusion in Debian,
+but are waiting for your new maintainer application to go through, you
+might be able find a sponsor to upload your package for you. Sponsors
+are people who are official Debian Developers, and who are willing to
+criticize and upload your packages for you.
+
+Please read the
+unofficial debian-mentors FAQ at
+If you wish to be a mentor and/or sponsor, more information is
+available in .
Before you decide to register with &debian-formal;, you will need to
read all the information available at the
Before you actually register you should have shown that you can do
-competent work and will be a good contributor. You can show this by
-submitting patches through the Bug Tracking System or having a package
-sponsored by an existing maintainer for a while. Also, we expect that
+competent work and will be a good contributor.
+You show this by submitting patches through the Bug Tracking System
+and having a package
+sponsored by an existing Debian Developer for a while.
+Also, we expect that
contributors are interested in the whole project and not just in
maintaining their own packages. If you can help other maintainers by
providing further information on a bug or even a patch, then do so!
@@ -168,19 +213,19 @@ providing further information on a bug or even a patch, then do so!
Registration requires that you are familiar with Debian's philosophy
and technical documentation. Furthermore, you need a GnuPG key which
has been signed by an existing Debian maintainer. If your GnuPG key
-is not signed yet, you should try to meet a Debian maintainer in
+is not signed yet, you should try to meet a Debian Developer in
person to get your key signed. There's a
If you do not have an OpenPGP key yet, generate one. Every developer
-needs a OpenPGP key in order to sign and verify package uploads. You
+needs an OpenPGP key in order to sign and verify package uploads. You
should read the manual for the software you are using, since it has
much important information which is critical to its security. Many
more security failures are due to human error than to software failure
@@ -193,16 +238,43 @@ You can use some other implementation of OpenPGP as well. Note that
OpenPGP is an open standard based on
-The recommended public key algorithm for use in Debian development
-work is DSA (sometimes call ``DSS'' or ``DH/ElGamal''). Other key
-types may be used however. Your key length must be at least 1024
+You need a version 4 key for use in Debian Development.
+Your key length must be at least 1024
bits; there is no reason to use a smaller key, and doing so would be
-much less secure. Your key must be signed with at least your own user
-ID; this prevents user ID tampering.
-If your public key isn't on public key servers such as &pgp-keyserv;,
-please read the documentation available locally in &file-keyservs;.
+much less secure.
+
+Version 4 (primary) keys can either use the RSA or the DSA algorithms,
+so this has nothing to do with GnuPG's question about "which kind
+of key do you want: (1) DSA and Elgamal, (2) DSA (sign only), (5)
+RSA (sign only)". If you don't have any special requirements just pick
+the default.
+
+The easiest way to tell whether an existing key is a v4 key or a v3
+(or v2) key is to look at the fingerprint:
+Fingerprints of version 4 keys are the SHA-1 hash of some key matieral,
+so they are 40 hex digits, usually grouped in blocks of 4. Fingerprints
+of older key format versions used MD5 and are generally shown in blocks
+of 2 hex digits. For example if your fingerprint looks like
+5B00 C96D 5D54 AEE1 206B AF84 DE7A AF6E 94C0 9C7F
+then it's a v4 key.
+
+Another possibility is to pipe the key into
+Also note that your key must be self-signed (i.e. it has to sign
+all its own user IDs; this prevents user ID tampering). All
+modern OpenPGP software does that automatically, but if you
+have an older key you may have to manually add those signatures.
+
+If your public key isn't on a public key server such as &pgp-keyserv;,
+please read the documentation available at
+
-To apply as a new maintainer, you need an existing Debian maintainer
-to verify your application (an advocate). After you have
+To apply as a new maintainer, you need an existing Debian Developer
+to support your application (an advocate). After you have
contributed to Debian for a while, and you want to apply to become a
registered developer, an existing developer with whom you
have worked over the past months has to express their belief that you
@@ -240,27 +311,6 @@ before actually applying. If you are well prepared, you can save
a lot of time later on.
-
-The mailing list &email-debian-mentors; has been set up for novice
-maintainers who seek help with initial packaging and other
-developer-related issues. Every new developer is invited to subscribe
-to that list (see for details).
-
-Those who prefer one-on-one help (e.g., via private email) should also
-post to that list and an experienced developer will volunteer to help.
-
-In addition, if you have some packages ready for inclusion in Debian,
-but are waiting for your new maintainer application to go through, you
-might be able find a sponsor to upload your package for you. Sponsors
-are people who are official Debian maintainers, and who are willing to
-criticize and upload your packages for you. Those who are seeking a
-sponsor can request one at
-If you wish to be a mentor and/or sponsor, more information is
-available in .
-
-
+You need to ensure not only that your key is secure against being stolen,
+but also that it is secure against being lost. Generate and make a copy
+(best also in paper form) of your revocation certificate; this is needed if
+your key is lost.
+
If you add signatures to your public key, or add user identities, you
can update the Debian key ring by sending your key to the key server at
-&keyserver-host;. If you need to add a completely new key,
-or remove an old key, send mail to &email-debian-keyring;. The same
-key extraction routines discussed in apply.
+&keyserver-host;.
+
+If you need to add a completely new key or remove an old key, you need
+to get the new key signed by another developer.
+If the old key is compromised or invalid, you
+also have to add the revocation certificate. If there is no real
+reason for a new key, the Keyring Maintainers might reject the new key.
+Details can be found at
+
+The same key extraction routines discussed in
+apply.
You can find a more in-depth discussion of Debian key maintenance in
the documentation of the
-The list of all the proposals (past and current) is available on the
+The list of all proposals (past and current) is available on the
It is common for developers to have periods of absence, whether those are
planned vacations or simply being buried in other work. The important thing
-to notice is that the other developers need to know that you're on vacation
+to notice is that other developers need to know that you're on vacation
so that they can do whatever is needed if a problem occurs with your
packages or other duties in the project.
Usually this means that other developers are allowed to NMU (see
-) your package if a big problem (release critical bugs,
+) your package if a big problem (release critical bug,
security update, etc.) occurs while you're on vacation. Sometimes it's
-nothing as critical as that, but it's still appropriate to let the others
+nothing as critical as that, but it's still appropriate to let others
know that you're unavailable.
-In order to inform the other developers, there's two things that you should do.
+In order to inform the other developers, there are two things that you should do.
First send a mail to &email-debian-private; with "[VAC] " prepended to the
subject of your message
+Ideally, you should sign up at the
+
If you need to modify the upstream sources in order to build a policy
@@ -370,11 +441,11 @@ need, always try not to fork from the upstream sources.
Generally you should deal with bug reports on your packages as described in
. However, there's a special category of bugs that
-you need to take care of -- the so-called release-critical bugs (RC bugs).
+you need to take care of — the so-called release-critical bugs (RC bugs).
All bug reports that have severity critical, grave or
serious are considered to have an impact on whether the package can
be released in the next stable release of Debian.
-Those bugs can delay the Debian release
+These bugs can delay the Debian release
and/or can justify the removal of a package at freeze time. That's why
these bugs need to be corrected as quickly as possible.
@@ -399,11 +470,13 @@ the following steps:
Several IRC channels are dedicated to Debian's development. They are mainly
-hosted on the
The main channel for Debian in general is #debian. This is a large,
general-purpose channel where users can find recent news in the topic and
@@ -514,7 +586,7 @@ on Debian, it's not a support channel (there's #debian for that).
It is however open to anyone who wants to lurk (and learn). Its topic is
commonly full of interesting information for developers.
-Since #debian-devel it's an open channel, you
+Since #debian-devel is an open channel, you
should not speak there of issues that are discussed in
&email-debian-private;. There's another channel for this purpose,
it's called #debian-private and it's protected by a key.
@@ -524,9 +596,9 @@ just
There are other additional channels dedicated to specific subjects.
-#debian-bugs is used for coordinating bug squash parties.
-#debian-boot is used to coordinate the work on the boot
-floppies (i.e., the installer). #debian-doc is
+#debian-bugs is used for coordinating bug squashing parties.
+#debian-boot is used to coordinate the work on the debian-installer.
+#debian-doc is
occasionally used to talk about documentation, like the document you are
reading. Other channels are dedicated to an architecture or a set of
packages: #debian-bsd, #debian-kde, #debian-jr,
@@ -539,14 +611,25 @@ Some non-English developers' channels exist as well, for example
French speaking people interested in Debian's development.
Channels dedicated to Debian also exist on other IRC networks, notably on
-the
+To get a cloak on freenode, you send Jörg Jaspert <joerg@debian.org>
+a signed mail where you tell what your nick is.
+Put "cloak" somewhere in the Subject: header.
+The nick should be registered:
+
-This document contains a lot of information very useful to Debian developers,
-but it can not contain everything. Most of the other interesting documents
+This document contains a lot of information
+which is useful to Debian developers,
+but it cannot contain everything. Most of the other interesting documents
are linked from
+Some of the core servers are restricted, but the information from there
+is mirrored to another server.
&bugs-host; is the canonical location for the Bug Tracking
-System (BTS). If you plan on doing some statistical analysis or
+System (BTS).
+
+It is restricted; a mirror is available on merkel.
+
+If you plan on doing some statistical analysis or
processing of Debian bugs, this would be the place to do it. Please
describe your plans on &email-debian-devel; before implementing
anything, however, to reduce unnecessary duplication of effort or
wasted processing time.
-
-All Debian developers have accounts on &bugs-host;.
@@ -607,6 +695,8 @@ The ftp-master.debian.org server holds the canonical copy of the Debian
archive (excluding the non-US packages). Generally, package uploads
go to this server; see .
+It is restricted; a mirror is available on merkel.
+
Problems with the Debian FTP archive generally need to be reported as
bugs against the
-The non-US server, non-us.debian.org,
-holds the canonical copy of the non-US part of the Debian archive.
-If you need to upload a package into one of the non-US sections, upload it
-to this server; see .
-
-Problems with the non-US package archive should generally be submitted as
-bugs against the
@@ -635,7 +718,7 @@ of Debian for most newbies.
If you find a problem with the Debian web server, you should generally
submit a bug against the pseudo-package,
Usually the only reason to use a different host is when you need to publish
materials subject to the U.S. export restrictions, in which case you can use
-one of the other servers located outside the United States, such as the
-aforementioned non-us.debian.org.
+one of the other servers located outside the United States.
Send mail to &email-debian-devel; if you have any questions.
Our CVS server is located on cvs.debian.org.
@@ -677,6 +760,20 @@ To request a CVS area, send a request via email to
&email-debian-admin;. Include the name of the requested CVS area,
the Debian account that should own the CVS root area, and why you need it.
+
+On some machines, there are chroots to different distributions available.
+You can use them like this:
+
+
@@ -705,7 +802,7 @@ Most of the information is not accessible to the public, naturally.
For more information please read the online documentation that you can find
at
-One can also submit their SSH keys to be used for authorization on the
+Developers can also submit their SSH keys to be used for authorization on the
official Debian machines, and even add new *.debian.net DNS entries.
Those features are documented at
The main section of the Debian archive is what makes up the
official &debian-formal; distribution. The
@@ -784,10 +881,10 @@ commercial distribution, for example.
On the other hand, a CD-ROM vendor could easily check the individual
package licenses of the packages in non-free and include as
-many on the CD-ROMs as he's allowed to. (Since this varies greatly from
+many on the CD-ROMs as it's allowed to. (Since this varies greatly from
vendor to vendor, this job can't be done by the Debian developers.)
-Note also that the term "section" is also used to refer to categories
+Note that the term "section" is also used to refer to categories
which simplify the organization and browsing of available packages, e.g.
admin, net, utils etc. Once upon a time, these
sections (subsections, rather) existed in the form of subdirectories within
@@ -797,8 +894,8 @@ fields of packages.
-In the first days, the Linux kernel was only available for the Intel
-i386 (or greater) platforms, and so was Debian. But when Linux became
+In the first days, the Linux kernel was only available for Intel
+i386 (or greater) platforms, and so was Debian. But as Linux became
more and more popular, the kernel was ported to other architectures,
too.
@@ -817,7 +914,7 @@ also have ports underway to non-Linux kernels. Aside from
shipped for i386 and m68k architectures. Debian 2.1
ships for the i386, m68k, alpha, and
sparc architectures. Debian 2.2 added support for the
-powerpc and arm architectures. Debian 3.0 adds
+powerpc and arm architectures. Debian 3.0 added
support of five new architectures: ia64, hppa,
s390, mips and mipsel.
@@ -841,7 +938,7 @@ outside of Debian, there is just one
@@ -863,7 +960,7 @@ server. For instance, at the mirror site,
contained in
-A distribution is comprised of Debian source and binary packages, and the
+A distribution comprises Debian source and binary packages, and the
respective
There are always distributions called stable (residing in
-
@@ -882,11 +979,12 @@ Active development is done in the unstable distribution
(that's why this distribution is sometimes called the development
distribution). Every Debian developer can update his or her
packages in this distribution at any time. Thus, the contents of this
-distribution changes from day-to-day. Since no special effort is done
+distribution change from day to day. Since no special effort is made
to make sure everything in this distribution is working properly, it is
sometimes literally unstable.
-
This development cycle is based on the assumption that the
unstable distribution becomes stable after passing a
@@ -921,66 +1022,22 @@ batch into the stable distribution and the revision level of the
stable distribution is incremented (e.g., ‘3.0’ becomes
‘3.0r1’, ‘2.2r4’ becomes ‘2.2r5’, and
so forth).
+Please refer to
+
Note that development under unstable continues during the
freeze period, since the unstable distribution remains in
place in parallel with testing.
-
+Packages are usually installed into the `testing' distribution after they
+have undergone some degree of testing in unstable.
-The scripts that update the testing distribution are run each
-day after the installation of the updated packages. They generate the
-
-The inclusion of a package from unstable is conditional on
-the following:
-
-To find out whether a package is progressing into testing or not, see the
-testing script output on the
-The
-Sometimes, some packages never enter testing because the set of
-inter-relationship is too complicated and cannot be sorted out
-by the scripts. In that case, the release manager must be
-contacted, and he will force the inclusion of the packages.
-
-In general, please refer to the
@@ -998,8 +1055,8 @@ distribution.
These are the
If there is a chance that the software could do grave damage to a system,
@@ -1029,14 +1086,19 @@ New software which isn't likely to damage your system can go directly into
An alternative to experimental is to use your personal web space
on people.debian.org.
-
+
+When uploading to unstable a package which had bugs fixed in experimental,
+please consider using the option -v to
Every released Debian distribution has a code name: Debian
1.1 is called `buzz'; Debian 1.2, `rex'; Debian 1.3, `bo'; Debian 2.0,
-`hamm'; Debian 2.1, `slink'; Debian 2.2, `potato'; and Debian 3.0, `woody'. There is also
-a ``pseudo-distribution'', called `sid', which is the current
+`hamm'; Debian 2.1, `slink'; Debian 2.2, `potato'; Debian 3.0, `woody';
+Debian 3.1, "sarge";
+Debian 4.0, "etch".
+There is also a ``pseudo-distribution'', called `sid', which is the current
`unstable' distribution; since packages are moved from `unstable' to
`testing' as they approach stability, `sid' itself is never released.
As well as the usual contents of a Debian distribution, `sid' contains
@@ -1098,27 +1160,37 @@ have accounts on these machines.
The Incoming system is responsible for collecting updated packages and
installing them in the Debian archive. It consists of a set of
-directories and scripts that are installed both on &ftp-master-host;
-and &non-us-host;.
+directories and scripts that are installed on &ftp-master-host;.
Packages are uploaded by all the maintainers into a directory called
-
-Once the package is accepted the system sends a confirmation
-mail to the maintainer, closes all the bugs marked as fixed by the upload
+the package (or it has new binary packages),
+it is moved to the
+Once the package is accepted, the system sends a confirmation
+mail to the maintainer and closes all the bugs marked as fixed by the upload,
and the auto-builders may start recompiling it. The package is now publicly
-accessible at
+Though ftp-master is restricted, a copy of the installation is available
+to all developers on &ftp-master-mirror;.
+
The bug tracking system tracks bugs for each package.
You can view the bugs of a given package at the URL
@@ -1199,7 +1279,8 @@ You can view the bugs of a given package at the URL
In this example, you can see that the version in unstable differs from
the version in testing and that there has been a binary-only NMU of the
-package for the alpha architecture. Each time the package has been
+package for the alpha architecture. Each version of the package has been
recompiled on most of the architectures.
@@ -1284,12 +1365,17 @@ maintainer has set up forwarding commit notifications to the PTS.
You can control your subscription(s) to the PTS by sending
-various commands to
+The
Once you are subscribed to a package, you will get the mails sent to
@@ -1373,7 +1478,7 @@ X-Unsubscribe: echo 'unsubscribe dpkg' | mail pts@qa.debian.org
If you use a publicly accessible CVS repository for maintaining
-your Debian package you may want to forward the commit notification
+your Debian package, you may want to forward the commit notification
to the PTS so that the subscribers (and possible co-maintainers) can
closely follow the package's evolution.
@@ -1459,7 +1564,7 @@ everything here:
Think twice before adding a news item to the PTS because you won't be able
-to remove it later and you wan't be able to edit it either. The only thing
+to remove it later and you won't be able to edit it either. The only thing
that you can do is send a second news item that will deprecate the
information contained in the previous one.
@@ -1474,8 +1579,8 @@ distribution, testing status and much more including links to any other
useful information.
It is a good idea to look up your own data regularly so that
-you don't forget any open bug, and so that you don't forget which
-packages are under your responsibility.
+you don't forget any open bugs, and so that you don't forget which
+packages are your responsibility.
@@ -1490,8 +1595,23 @@ by Debian, facilitate contributions from external developers to projects
started by Debian, and help projects whose goals are the promotion of Debian
or its derivatives.
+All Debian developers automatically have an account on Alioth.
+They can activate it by using the recover password facility.
+External developers can request guest accounts on Alioth.
+
For more information please visit
+
+Since October of 2002, HP has sponsored a subscription to LWN for all
+interested Debian developers.
+
+Details on how to get access to this benefit are in
+
@@ -1513,7 +1633,7 @@ you must then submit a bug report () against the
pseudo-package
You should set the subject of the bug to ``ITP: foo
@@ -1524,10 +1644,19 @@ to wishlist. If you feel it's necessary, send a copy to
of the message (no, don't use CC:, because that way the message's subject
won't indicate the bug number).
-Please include a Closes: bug#nnnnn entry on the
+Please include a Closes: bug#nnnnn entry in the
changelog of the new package in order for the bug report to be
-automatically closed once the new package is installed on the archive
-().
+automatically closed once the new package is installed in the archive
+(see ).
+
+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 the historical changelog entry with the next upload.
+Even in this case, please include all available pointers to background
+information in the original changelog entry.
+
There are a number of reasons why we ask maintainers to announce their
intentions:
@@ -1550,7 +1679,9 @@ line of testers). We should encourage these people.
The announcements give maintainers and other interested parties a
better feel of what is going on, and what is new, in the project.
-
+
+Please see
@@ -1617,6 +1748,11 @@ Downgrade the package to the previous version (if one exists) — this
tests the
+Please notice that, in non-native packages, permissions on files that are not
+present in the .orig.tar.gz will not be preserved, as diff does not store file
+permissions in the patch.
-It is technically possible to upload a package into several distributions
-at the same time but it usually doesn't make sense to use that feature
-because the dependencies of the package may vary with the distribution.
-In particular, it never makes sense to combine the experimental
-distribution with anything else (see ).
+It is not possible to upload a package into several distributions
+at the same time.
-Uploading to stable means that the package will be placed into the
-
Extra care should be taken when uploading to stable. Basically, a
package should only be uploaded to stable if one of the following happens:
@@ -1716,182 +1855,95 @@ packages (by messing with Provides or shlibs files), possibly making
those other packages uninstallable, is strongly discouraged.
The Release Team (which can be reached at &email-debian-release;) will
-regularly evaluate the uploads in stable-proposed-updates and decide if
+regularly evaluate the uploads To stable-proposed-updates and decide if
your package can be included in stable. Please be clear (and
verbose, if necessary) in your changelog entries for uploads to
stable, because otherwise the package won't be considered for
inclusion.
+
+It's best practice to speak with the stable release manager before
+uploading to stable/stable-proposed-updates, so that the
+uploaded package fits the needs of the next point release.
-The testing distribution is fed with packages from unstable according to the rules
-explained in . However, the release manager may stop the testing
-scripts when he wants to freeze the distribution. In that case, you may want to
-upload to testing-proposed-updates to provide fixed packages during the freeze.
-
-Keep in mind that packages uploaded there are not automatically processed, they
-have to go through the hands of the release manager. So you'd better have a good
-reason to upload there. In order to know what a good reason is in the
-release manager's eyes, you should read the instructions that he regularly
-gives on &email-debian-devel-announce;.
+
-You should not upload to testing-proposed-updates when you can update your
-packages through unstable. If you can't (for example because you have a
-newer development version in unstable), you may use it but it is recommended to ask
-the authorization of the release manager before.
+Please see the information in the
-To upload a package, you need a personal account on
-
-If you want to use the feature described in ,
-you'll have to upload to ftp-master. It is the only upload
-point that supports delayed incoming.
+To upload a package, you should upload the files (including the signed
+changes and dsc-file) with anonymous ftp to
+
Please note that you should transfer
the changes file last. Otherwise, your upload may be rejected because the
archive maintenance software will parse the changes file and see that not
-all files have been uploaded. If you don't want to bother with transferring
-the changes file last, you can simply copy your files to a temporary
-directory on ftp-master and then move them to
-&us-upload-dir;.
-
-Note: Do not upload to ftp-master cryptographic
-packages which belong to contrib or non-free. Uploads of
-such software should go to non-us (see ). Furthermore packages containing code that is
-patent-restricted by the United States government can not be uploaded to
-ftp-master; depending on the case they may still be uploaded to
-
You may also find the Debian packages or
useful
-when uploading packages. These handy programs help automate the
+when uploading packages. These handy programs help automate the
process of uploading packages into Debian.
-After uploading your package, you can check how the archive
-maintenance software will process it by running
-Note that
-As discussed above, export controlled software should not be uploaded
-to ftp-master. Instead, upload the package to
-
-You can check your upload the same way it's done on ftp-master,
-with:
-
-Note that U.S. residents or citizens are subject to restrictions on
-export of cryptographic software. As of this writing, U.S. citizens
-are allowed to export some cryptographic software, subject to
-notification rules by the U.S. Department of Commerce. However, this
-restriction has been waived for software which is already available
-outside the U.S. Therefore, any cryptographic software which belongs
-in the main section of the Debian archive and does not depend
-on any package outside of main (e.g., does not depend on
-anything in non-US/main) can be uploaded to ftp-master
-or its queues, described above.
-
-Debian policy does not prevent upload to non-US by U.S. residents or
-citizens, but care should be taken in doing so. It is recommended that
-developers take all necessary steps to ensure that they are not
-breaking current US law by doing an upload to non-US, including
-consulting a lawyer.
-
-For packages in non-US/main, non-US/contrib,
-developers should at least follow the
-This section is for information only and does not constitute legal
-advice. Again, it is strongly recommended that U.S. citizens and
-residents consult a lawyer before doing uploads to non-US.
-
-
-
-If you have a slow network connection to ftp-master, there are
-alternatives. One is to upload files to
-Note: Do not upload packages containing software that is
-export-controlled by the United States government to the queue on
-chiark. Since this upload queue goes to ftp-master, the
-prescription found in applies here as well.
-
-The program
-Another upload queue is available in Germany: just upload the files
-via anonymous FTP to
-The upload must be a complete Debian upload, as you would put it into
-ftp-master's
-There's no need to move your files into a second directory after the
-upload, as on chiark. And, in any case, you should get a
-mail reply from the queue daemon explaining what happened to your
-upload. Hopefully it should have been moved to ftp-master, but in
-case of errors you're notified, too.
+With a fairly recent dput, this section
+
-Note: Do not upload packages containing software that is
-export-controlled by the United States government to the queue on
-erlangen. Since this upload queue goes to ftp-master, the
+Note:
+Since this upload queue goes to ftp-master, the
prescription found in applies here as well.
-
-The program
+Do NOT upload a package to the security upload queue
+(oldstable-security,
+stable-security, etc.) without prior authorization from the security
+team. If the package does not exactly meet the team's requirements, it
+will cause many problems and delays in dealing with the unwanted upload.
+For details, please see section .
-Another upload queue is available which is based in the US, and is a
-good backup when there are problems reaching ftp-master. You can
-upload files, just as in erlangen, to
-An upload queue is available in Japan: just upload the files via
-anonymous FTP to
+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.
+
+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.
-Note also that if you upload via queues, the queue daemon software will
+Note that if you upload via queues, the queue daemon software will
also send you a notification by email.
-
The
To alter the actual section that a package is put in, you need to
-first make sure that the
For more information about override files, see
-Note also that the term "section" is used for the separation of packages
-according to their licensing, e.g. main, contrib and
-non-free. This is described in another section, .
+Note that the Section field describes both the section as
+well as the subsection, which are described in . If the section is "main", it should be
+omitted. The list of allowable subsections can be found in
-The bug tracking system's features interesting to developers are described
+The bug tracking system's features are described
in the
Operations such as reassigning bugs to other packages, merging separate
bug reports about the same issue, or reopening bugs when they are
prematurely closed, are handled using the so-called control mail server.
-All of the commands available in this server are described in the
+All of the commands available on this server are described in the
-If you get a bug which mentions "FTBFS", that means "Fails to build
+If you get a bug which mentions "FTBFS", this means "Fails to build
from source". Porters frequently use this acronym.
Once you've dealt with a bug report (e.g. fixed it), mark it as
@@ -2023,7 +2077,7 @@ closed.
As a package maintainer, you will often find bugs in other packages or
have bugs reported against your packages which are actually bugs in
-other packages. The bug tracking system's features interesting to developers
+other packages. The bug tracking system's features
are described in the
-Filing bugs for problems that you find in other packages is one of
+Filing bugs for problems that you find in other packages is one of
the "civic obligations" of maintainership, see
for details. However, handling the bugs in your own packages is
even more important.
@@ -2047,7 +2101,7 @@ to the good documentation and so on). If the same report comes up
again and again you may ask yourself if the documentation is good
enough or if the program shouldn't detect its misuse in order to
give an informative error message. This is an issue that may need
-to be brought to the upstream author.
+to be brought up with the upstream author.
If the bug submitter disagrees with your decision to close the bug,
they may reopen it until you find an agreement on how to handle it.
@@ -2061,9 +2115,11 @@ doing so, please read the
Sometimes you also have to adjust the severity of the bug so that it
matches our definition of the severity. That's because people tend to
@@ -2071,8 +2127,19 @@ inflate the severity of bugs to make sure their bugs are fixed quickly.
Some bugs may even be dropped to wishlist severity when the requested
change is just cosmetic.
-
-