X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=developers-reference.sgml;h=a00cabd3ace8f97d7fcf6ee63b1a026c12149ca0;hb=0705951199dd03a594900f56aa58225d68314ba6;hp=b3d286bfd7072cb5b9bd30dd77270d4a0567a4e4;hpb=bbe91d7848d48378def4176216b52d4d04ccf8b5;p=developers-reference.git diff --git a/developers-reference.sgml b/developers-reference.sgml index b3d286b..a00cabd 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,24 +124,51 @@ 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
+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.
+
+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 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
+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 maintainer 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
@@ -171,12 +210,12 @@ 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
person to get your key signed. There's a
If you do not have an OpenPGP key yet, generate one. Every developer
@@ -193,13 +232,39 @@ 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.
+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 defailt.
+
+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 public key servers such as &pgp-keyserv;,
please read the documentation available locally in &file-keyservs;.
@@ -211,8 +276,7 @@ Some countries restrict the use of cryptographic software by their
citizens. This need not impede one's activities as a Debian package
maintainer however, as it may be perfectly legal to use cryptographic
products for authentication, rather than encryption purposes.
-&debian-formal; does not require the use of cryptography qua
-cryptography in any manner. If you live in a country where use of
+If you live in a country where use of
cryptography even for authentication is forbidden
then please contact us so we can make special arrangements.
@@ -240,27 +304,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
-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,7 +434,7 @@ 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.
@@ -399,7 +463,7 @@ the following steps:
-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 +588,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,
@@ -541,12 +605,23 @@ 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 +687,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 +710,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 +752,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
+
+
@@ -705,7 +794,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
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
@@ -817,7 +906,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.
@@ -863,7 +952,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 +971,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 +1014,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 +1047,8 @@ distribution.
These are the
If there is a chance that the software could do grave damage to a system,
@@ -1029,14 +1078,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 (number needs to be determined), "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 +1152,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 +1271,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.
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 +1470,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 +1556,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.
@@ -1490,8 +1587,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 +1625,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 +1636,10 @@ 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 ).
There are a number of reasons why we ask maintainers to announce their
intentions:
@@ -1617,6 +1729,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.
-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
-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
@@ -1781,44 +1875,10 @@ and the Debian package .
-Note: non-us is currently not processed any more.
-
-As discussed above, export controlled software should not be uploaded
-to ftp-master. Instead, upload the package with anonymous FTP
-to
-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.
+Note: non-us was discontinued with release of sarge.
-
Delayed uploads are done for the moment via the delayed queue at
gluck. The upload-directory is
@@ -1848,14 +1908,14 @@ For details, please see section .
-The scp queues on ftp-master, non-us and security are mostly unuseable
+The scp queues on ftp-master, and security are mostly unusable
due to the login restrictions on those hosts.
The anonymous queues on ftp.uni-erlangen.de and ftp.uk.debian.org are
currently down. Work is underway to resurrect those.
-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
+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.
@@ -1885,7 +1945,7 @@ The installation notification also includes information on what
section the package was inserted into. If there is a disparity, you
will receive a separate email notifying you of that. Read on below.
-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.
For more information about override files, see
Note that the Section field describes both the section as
@@ -1931,10 +1991,10 @@ tracking system" id="&url-bts;">. This includes knowing how to file bug
reports properly (see ), how to update them and
reorder them, and how to process and close them.
-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
@@ -1995,7 +2055,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.
@@ -2019,7 +2079,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.
@@ -2033,9 +2093,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
@@ -2043,6 +2105,17 @@ 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.
-As bugs and problems are fixed your packages, it is your
-responsibility as the package maintainer to close the bug. However,
-you should not close the bug until the package which fixes the bug has
+As bugs and problems are fixed in your packages, it is your
+responsibility as the package maintainer to close these bugs. However,
+you should not close a bug until the package which fixes the bug has
been accepted into the Debian archive. Therefore, once you get
notification that your updated package has been installed into the
archive, you can and should close the bug in the BTS.
@@ -2107,6 +2180,17 @@ We prefer the closes: #XXX syntax, as it is the
most concise entry and the easiest to integrate with the text of the
+If an upload is identified as
If you happen to mistype a bug number or forget a bug in the changelog
entries, don't hesitate to undo any damage the error caused. To reopen
wrongly closed bugs, send an reopen XXX command to
@@ -2177,10 +2261,10 @@ case depends on the nature of the problem and corresponding fix, and
whether it is already a matter of public knowledge.
-There are a few ways a developer can learn of a security problem:
+There are a few ways developers can learn of a security problem:
Once an upload to the security queue has been accepted, the package
@@ -2411,7 +2495,7 @@ cases.
Sometimes a package will change its section. For instance, a
package from the `non-free' section might be GPL'd in a later version,
-in which case, the package should be moved to `main' or
+in which case the package should be moved to `main' or
`contrib'.
The first and most important thing is to respond quickly to bug or
issues raised by porters. Please treat porters with courtesy, as if
-they were in fact co-maintainers of your package (which in a way, they
-are). Please be tolerant of succinct or even unclear bug reports,
-doing your best to hunt down whatever the problem is.
+they were in fact co-maintainers of your package (which, in a way, they
+are). Please be tolerant of succinct or even unclear bug reports;
+do your best to hunt down whatever the problem is.
By far, most of the problems encountered by porters are caused by
packaging bugs in the source packages. Here is a checklist
@@ -2634,7 +2720,7 @@ or programs. For instance, you should never be calling programs in
being setup in a special way. Try building your package on another
machine, even if it's the same architecture.
+If you are working on a Debian machine for your porting efforts and you
+need to sign your upload locally for its acceptance in the archive, you
+can run
+You have to make sure that your binary-only NMU doesn't render the package
+uninstallable. This could happen when a source package generates
+arch-dependent and arch-independent packages that depend on each other via
+$(Source-Version).
+
+Despite the
required modification of the changelog, these are called binary-only NMUs
— there is no need in this case to trigger all other architectures
to consider themselves out of date or requiring recompilation.
@@ -2690,12 +2789,26 @@ new Debian version, there is no corresponding source update. If you
get this wrong, the archive maintainers will reject your upload (due
to lack of corresponding source code).
-The ``magic'' for a recompilation-only NMU is triggered by using the
-third-level number on the Debian part of the version. For instance,
-if the latest version you are recompiling against was version
-``2.9-3'', your NMU should carry a version of ``2.9-3.0.1''. If the
-latest version was ``3.4-2.1'', your NMU should have a version number
-of ``3.4-2.1.1''.
+The ``magic'' for a recompilation-only NMU is triggered by using a
+suffix appended to the package version number,
+following the form b<number>.
+For instance, if the latest version you are
+recompiling against was version ``2.9-3'', your NMU should carry a
+version of ``2.9-3+b1''. If the latest version was ``3.4+b1'' (i.e, a
+native package with a previous recompilation NMU), your NMU should have
+a version number of ``3.4+b2''.
+
+
+Similar to initial porter uploads, the correct way of invoking
+
-However, if you are a porter doing an NMU for `unstable', the above
+If you are a porter doing an NMU for `unstable', the above
guidelines for porting should be followed, with two variations.
Firstly, the acceptable waiting period — the time between when the
bug is submitted to the BTS and when it is OK to do an NMU — is seven
@@ -2725,6 +2832,8 @@ days for porters working on the unstable distribution. This period
can be shortened if the problem is critical and imposes hardship on
the porting effort, at the discretion of the porter group. (Remember,
none of this is Policy, just mutually agreed upon guidelines.)
+For uploads to stable or testing, please coordinate with the appropriate
+release team first.
Secondly, porters doing source NMUs should make sure that the bug they
submit to the BTS should be of severity `serious' or greater. This
@@ -2736,7 +2845,7 @@ architecture in order to comply with many licenses.
Porters should try to avoid patches which simply kludge around bugs in
the current version of the compile environment, kernel, or libc.
Sometimes such kludges can't be helped. If you have to kludge around
-compilers bugs and the like, make sure you #ifdef your work
+compiler bugs and the like, make sure you #ifdef your work
properly; also, document your kludge so that people know to remove it
once the external problems have been fixed.
@@ -2806,92 +2915,107 @@ different sub-flavors of Debian, which may or may not really be of
general interest (for instance, a flavor of Debian built with
+The buildds admins of each arch can be contacted by the mail address
+$arch@buildd.debian.org.
+
+
+Some packages still have issues with building and/or working on some
+of the architectures supported by Debian, and cannot be ported at all,
+or not within a reasonable amount of time. An example is a package that
+is SVGA-specific (only i386), or uses other hardware-specific features
+not supported on all architectures.
+
+In order to prevent broken packages from being uploaded to the archive, and
+wasting buildd time, you need to do a few things:
+
+
+First, make sure your package does fail to build on
+architectures that it cannot support.
+There are a few ways to achieve this.
+The preferred way is to have a small testsuite during build time
+that will test the functionality, and fail if it doesn't work.
+This is a good idea anyway,
+as this will prevent (some) broken uploads on all architectures,
+and also will allow the package to build
+as soon as the required functionality is available.
+
+Additionally, if you believe the list of supported architectures is
+pretty constant, you should change 'any' to a list of supported
+architectures in debian/control. This way, the build will fail also,
+and indicate this to a human reader without actually trying.
+
+In order to prevent autobuilders from needlessly trying to build your
+package, it must be included in
+Please note that it is insufficient to only add your package to
+Packages-arch-specific
+without making it fail to build on unsupported architectures:
+A porter or any other person trying to build your package might
+accidently upload it without noticing it doesn't work.
+If in the past some binary packages were uploaded on unsupported architectures,
+request their removal by filing a bug against
+
Under certain circumstances it is necessary for someone other than the
-official package maintainer to make a release of a package. This is
+official package maintainer to make a release of a package. This is
called a non-maintainer upload, or NMU.
-Debian porters, who compile packages for different architectures,
-occasionally do binary-only NMUs as part of their porting activity
-(see ). Another reason why NMUs are done is when a
-Debian developer needs to fix another developer's packages in order to
-address serious security problems or crippling bugs, especially during
-the freeze, or when the package maintainer is unable to release a fix
+This section handles only source NMUs, i.e. NMUs which upload a new
+version of the package. For binary-only NMUs by porters or QA members,
+please see .
+If a buildd builds and uploads a package,
+that too is strictly speaking a binary NMU.
+See for some more information.
+
+The main reason why NMUs are done is when a
+developer needs to fix another developer's packages in order to
+address serious problems or crippling bugs
+or when the package maintainer is unable to release a fix
in a timely fashion.
-
-This chapter contains information providing guidelines for when and
-how NMUs should be done. A fundamental distinction is made between
-source and binary-only NMUs, which is explained in the next section.
-
-
-There are two new terms used throughout this section: ``binary-only NMU''
-and ``source NMU''. These terms are used with specific technical
-meaning 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
-non-maintainer upload.
-
-A source NMU is an upload of a package by a developer who is not the
-official maintainer, for the purposes of fixing a bug in the package.
-Source NMUs always involves changes to the source (even if it is just
-a change to
-A binary-only NMU is a recompilation and upload of a binary package
-for a given architecture. As such, it is usually part of a porting
-effort. A binary-only NMU is a non-maintainer uploaded binary version
-of a package, with no source changes required. There are many cases
-where porters must fix problems in the source in order to get them to
-compile for their target architecture; that would be considered a
-source NMU rather than a binary-only NMU. As you can see, we don't
-distinguish in terminology between porter NMUs and non-porter NMUs.
-Both classes of NMUs, source and binary-only, can be lumped by the
-term ``NMU''. However, this often leads to confusion, since most
-people think ``source NMU'' when they think ``NMU''. So it's best to
-be careful. In this chapter, if we use the unqualified term ``NMU'',
-we refer to any type of non-maintainer upload NMUs, whether source and
-binary, or binary-only.
-
-
-
-Only official, registered Debian maintainers can do binary or source
-NMUs. An official maintainer is someone who has their key in the
-Debian key ring. Non-developers, however, are encouraged to download
-the source package and start hacking on it to fix problems; however,
-rather than doing an NMU, they should just submit worthwhile patches
-to the Bug Tracking System. Maintainers almost always appreciate
-quality patches and bug reports.
+And please remember the Hippocratic Oath: "Above all, do no harm." It
+is better to leave a package with an open grave bug than applying a
+non-functional patch, or one that hides the bug instead of resolving
+it.
-
-Guidelines for when to do a source NMU depend on the target
-distribution, i.e., stable, unstable, or experimental. Porters have
-slightly different rules than non-porters, due to their unique
-circumstances (see ).
+
-When a security bug is detected, the security team may do an NMU.
-Please refer to for more information.
+NMUs which fix important, serious or higher severity bugs are encouraged
+and accepted.
+You should endeavor to reach the current maintainer of the package; they
+might be just about to upload a fix for the problem, or have a better
+solution present.
-During the release cycle (see ), NMUs which fix
-serious or higher severity bugs are encouraged and accepted. Even
-during this window, however, you should endeavor to reach the current
-maintainer of the package; they might be just about to upload a fix
-for the problem. As with any source NMU, the guidelines found in need to be followed. Special exceptions are made
-for .
+NMUs should be made to assist a package's maintainer in resolving bugs.
+Maintainers should be thankful for that help, and NMUers should respect
+the decisions of maintainers, and try to personally help the maintainer by
+their work.
-Uploading bug fixes to unstable by non-maintainers should only be done
-by following this protocol:
+A NMU should follow all conventions, written down in this section.
+For an upload to testing or unstable, this order of steps is recommended:
-The following applies to porters insofar as they are playing the dual
-role of being both package bug-fixers and package porters. If a
-porter has to change the Debian source archive, their upload is
-automatically a source NMU and is subject to its rules. If a porter is
-simply uploading a recompiled binary package, the rules are different;
-see .
+For the testing distribution, the rules may be changed by the release
+managers. Please take additional care, and acknowledge that the usual way
+for a package to enter testing is through unstable.
-First and foremost, it is critical that NMU patches to source should
-be as non-disruptive as possible. Do not do housekeeping tasks, do
-not change the name of modules or files, do not move directories; in
-general, do not fix things which are not broken. Keep the patch as
-small as possible. If things bother you aesthetically, talk to the
-Debian maintainer, talk to the upstream maintainer, or submit a bug.
-However, aesthetic changes must not be made in a non-maintainer
-upload.
+For the stable distribution, please take extra care. Of course, the release
+managers may also change the rules here. Please verify before you upload that
+all your changes are OK for inclusion into the next stable release by the
+release manager.
+
+When a security bug is detected, the security team may do an NMU, using
+their own rules. Please refer to for more
+information.
+
-
-
-
@@ -2380,7 +2464,7 @@ Once you have created and tested the new package and it has been
approved by the security team, it needs to be uploaded so that it can
be installed in the archives. For security uploads, the place to
upload to is
-ftp://security.debian.org/pub/SecurityUploadQueue/ .
+ftp://security-master.debian.org/pub/SecurityUploadQueue/ .
+
+