<!entity % commondata SYSTEM "common.ent" > %commondata;
<!-- CVS revision of this document -->
- <!entity cvs-rev "$Revision: 1.121 $">
+ <!entity cvs-rev "$Revision: 1.141 $">
<!-- if you are translating this document, please notate the CVS
revision of the developers reference here -->
<!--
<title>Debian Developer's Reference
<author>Adam Di Carlo, current maintainer <email>aph@debian.org</email>
+ <author>Raphaël Hertzog, co-maintainer <email>hertzog@debian.org</email>
<author>Christian Schwarz <email>schwarz@debian.org</email>
<author>Ian Jackson <email>ijackson@gnu.ai.mit.edu</email>
<version>ver. &version;, &date-en;
<copyrightsummary>
copyright ©1998—2002 Adam Di Carlo</copyrightsummary>
<copyrightsummary>
+copyright ©2002 Raphaël Hertzog</copyrightsummary>
+ <copyrightsummary>
copyright ©1997, 1998 Christian Schwarz</copyrightsummary>
<p>
This manual is free software; you may redistribute it and/or modify it
to work on something to avoid duplicated effort.
<p>
Another good list to subscribe to is &email-debian-mentors;. See <ref
-id="mentors"> for details. The IRC channel <tt>#debian</tt> on the
-Linux People IRC network (e.g., <tt>irc.debian.org</tt>) can also be
+id="mentors"> for details. The IRC channel <tt>#debian</tt> can also be
helpful.
<p>
<sect id="rc-bugs">Managing release-critical bugs
<p>
-Release-critical bugs (RCB) are all bugs that have severity
-<em>critical</em>, <em>grave</em> or <em>serious</em>.
+Generally you should deal with bug reports on your packages as described in
+<ref id="bug-handling">. However, there's a special category of bugs that
+you need to take care of -- the so-called release-critical bugs (RC bugs).
+All bug reports that have severity <em>critical</em>, <em>grave</em> or
+<em>serious</em> 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
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. You must be
-aware that some developers who are part of the <url
-id="&url-debian-qa;" name="Debian Quality Assurance"> effort are
-following those bugs and try to help you whenever they are able. But if
-you can't fix such bugs within 2 weeks, you should either ask for help
+these bugs need to be corrected as quickly as possible.
+ <p>
+Developers who are part of the <url id="&url-debian-qa;"
+name="Quality Assurance"> group are following all such bugs, and trying
+to help whenever possible. If, for any reason, you aren't able fix an
+RC bug in a package of yours within 2 weeks, you should either ask for help
by sending a mail to the Quality Assurance (QA) group
&email-debian-qa;, or explain your difficulties and present a plan to fix
-them by sending a mail to the proper bug report. Otherwise, people
+them by sending a mail to the bug report. Otherwise, people
from the QA group may want to do a Non-Maintainer Upload (see
<ref id="nmu">) after trying to contact you (they might not wait as long as
usual before they do their NMU if they have seen no recent activity from you
there's one at <url id="&url-debian-lists-subscribe;">.
<p>
You can download the current list of mailing lists and basic usage
-instructions from <url id="&url-debian-lists;">
+instructions from <url id="&url-debian-lists-txt;">
or install the <package>doc-debian</package> package and have it
locally in &file-mail-lists;.
<sect id="irc-channels">IRC channels
<p>
-Several IRC channels are dedicated to Debian's development. They are all
-hosted on the <url id="&url-openprojects;" name="OpenProjects"> network.
-The <tt>irc.debian.org</tt> DNS entry is just an alias to
+Several IRC channels are dedicated to Debian's development. They are mainly
+hosted on the <url id="&url-openprojects;" name="freenode"> network
+(previously known as Open Projects Network).
+The <tt>irc.debian.org</tt> DNS entry is an alias to
<tt>irc.openprojects.net</tt>.
<p>
-The main channel <em>#debian-devel</em> is very active since more
-than 150 persons are always logged in. It's a channel for people who work
+The main channel for Debian in general is <em>#debian</em>. This is a large,
+general-purpose channel where users can find recent news in the topic and
+served by bots. <em>#debian</em> is for English speakers; there are also
+<em>#debian.de</em>, <em>#debian-fr</em>, <em>#debian-br</em> and other
+similarly named channels for speakers of other languages.
+ <p>
+The main channel for Debian development is <em>#debian-devel</em>.
+It is a very active channel since usually over 150 people are always
+logged in. It's a channel for people who work
on Debian, it's not a support channel (there's <em>#debian</em> for that).
It is however open to anyone who wants to lurk (and learn). Its topic is
-always full of interesting information. Since it's an open channel, you
+commonly full of interesting information for developers.
+ <p>
+Since <em>#debian-devel</em> it's an open channel, you
should not speak there of issues that are discussed in
-&email-debian-private;. There's a key protected channel
-<em>#debian-private</em> for that purpose. The key is available
-in the archives of debian-private in
+&email-debian-private;. There's another channel for this purpose,
+it's called <em>#debian-private</em> and it's protected by a key.
+This key is available in the archives of debian-private in
<file>master.debian.org:&file-debian-private-archive;</file>,
just <prgn>zgrep</prgn> for <em>#debian-private</em> in
all the files.
<em>#debian-bugs</em> is used for coordinating bug squash parties.
<em>#debian-boot</em> is used to coordinate the work on the boot
floppies (i.e. the installer). <em>#debian-doc</em> is
-occasionally used to work on documentation like the one you are
+occasionally used to talk about documentation, like the document you are
reading. Other channels are dedicated to an architecture or a set of
-packages: <em>#debian-bsd</em>, <em>#debian-kde</em>,
+packages: <em>#debian-bsd</em>, <em>#debian-kde</em>, <em>#debian-jr</em>,
+<em>#debian-edu</em>,
<em>#debian-sf</em> (SourceForge package), <em>#debian-oo</em> (OpenOffice
package) ...
<p>
-Some non-English channels exist, for example <em>#debian-devel-fr</em> for
+Some non-English developers' channels exist as well, for example
+<em>#debian-devel-fr</em> for
French speaking people interested in Debian's development.
Generally speaking, you can use these machines for Debian-related purposes
as you see fit. Please be kind to system administrators, and do not use
up tons and tons of disk space, network bandwidth, or CPU without first
-getting the approval of the admins. Usually these machines are run by
+getting the approval of the system administrators. Usually these machines are run by
volunteers.
<p>
Please take care to protect your Debian passwords and SSH keys installed on
keeping your entry the developer database up-to-date, see <ref
id="user-maint">. Part of this information is also available through
the finger service on Debian servers, try
-<prgn>finger yourlogin@debian.org</prgn> to see what it reports.
-
+<prgn>finger yourlogin@db.debian.org</prgn> to see what it reports.
+ <p>
+This database lets you register some other information like public SSH
+keys that will be automatically installed on the official debian machines
+or like *.debian.net DNS entry. Those features are documented
+at <url id="&url-debian-db-mail-gw;">.
<sect id="servers-mirrors">Mirrors of Debian servers
<p>
that newer push mirroring techniques ensure that mirrors are as
up-to-date as they can be.
<p>
-The main web page listing the available public FTP (and, usually,
-HTTP) servers can be found at <url id="&url-debian-mirrors;">. More
+The main web page listing the available public FTP/HTTP
+servers can be found at <url id="&url-debian-mirrors;">. More
information concerning Debian mirrors can be found at <url
id="&url-debian-mirroring;">. This useful page includes information
and tools which can be helpful if you are interested in setting up
to make sure everything in this distribution is working properly, it is
sometimes literally unstable.
<p>
-The testing distribution is generated automatically by taking
+<ref id="testing"> is generated automatically by taking
packages from unstable if they satisfy certain criteria. Those
criteria should ensure a good quality for packages within testing.
-<ref id="testing-scripts"> are launched each day after the
+The update to testing is launched each day after the
new packages have been installed.
<p>
After a period of development, once the release manager deems fit, the
<em>testing</em> distribution is frozen, meaning that the policies
-which control how packages move from <em>unstable</em> to testing are
+which control how packages move from <em>unstable</em> to <em>testing</em> are
tightened. Packages which are too buggy are removed. No changes are
allowed into <em>testing</em> except for bug fixes. After some time
has elapsed, depending on progress, the <em>testing</em> distribution
and <tt>&non-us-host;</tt>.
<p>
Packages are uploaded by all the maintainers into a directory called
-<file>unchecked</file>. This directory is scanned every 15 minutes by the katie script
-that verifies the integrity of the uploaded packages and the cryptographic
+<file>unchecked</file>. This directory is scanned every 15 minutes by
+the <prgn>katie</prgn> script, which verifies the integrity of the uploaded packages and the cryptographic
signatures. If the package is considered ready to be installed, it
is moved into the <file>accepted</file> directory. If this is the first upload of
the package, it is moved in the <file>new</file> directory, where it waits
for an approval of the ftpmasters. If the package contains files to be installed
-"by-hand" is is moved in the <file>byhand</file> directory, where it waits
+"by-hand" it is moved in the <file>byhand</file> directory, where it waits
for a manual installation by the ftpmasters. Otherwise, if any error has been detected,
the package is refused and is moved in the <file>reject</file> directory.
<p>
easily upload a package in one of the delayed directories:
<example>DELAY=5 dupload --to delayed <changes-file></example>
- <sect id="testing-scripts">
- <heading>The testing scripts</heading>
+ <sect id="testing">
+ <heading>The "testing" distribution</heading>
<p>
-The testing scripts are run each day after the installation of the
+The scripts that update the <em>testing</em> distribution are run each day
+after the installation of the
updated packages. They generate the <file>Packages</file> files for
the <em>testing</em> distribution, but they do so in an intelligent manner
trying to avoid any inconsistency and trying to use only
The scripts are generating some output files to explain why some packages
are kept out of testing. They are available at <url
id="&url-testing-maint;">. Alternatively, it is possible to use
-the <prgn>grep-excuses</prgn> program part of the
-<package>devscripts</package> package. It can be easily put in a crontab
-to keep someone informed of the progression of his packages in testing.
+the <prgn>grep-excuses</prgn> program which is in the
+<package>devscripts</package> package. It can be easily put in a
+<manref name="crontab" section="5">
+to keep someone informed of the progression of his packages in <em>testing</em>.
<p>
The <file>update_excuses</file> file does not always give the precise reason
why the package is refused, one may have to find it on their own by looking
what would break with the inclusion of the package. The <url
-id="&url-testing-faq;" name="testing FAQ"> gives some more information
+id="&url-testing-maint;" name="testing overview"> gives some more information
about the usual problems which may be causing such troubles.
<p>
-Sometimes, some packages never enter testing because the set of
+Sometimes, some packages never enter <em>testing</em> because the set of
inter-relationship is too complicated and can not be sorted out
by the scripts. In that case, the release manager must be
contacted, and he will force the inclusion of the packages.
- <sect id="pkg-info">Package's information
+ <sect id="pkg-info">Package information
<p>
<sect1 id="pkg-info-web">On the web
<p>
-Each package has several dedicated web pages that contain a lot of
-information. <tt>http://&packages-host;/<var>package-name</var></tt>
-will display each version of the package
-available in the various distributions. The per-version detailed
-information includes the package description,
-the dependencies and links to download the package.
+Each package has several dedicated web pages.
+<tt>http://&packages-host;/<var>package-name</var></tt>
+displays each version of the package
+available in the various distributions. Each version links to a page
+which provides information, including the package description,
+the dependencies and package download links.
<p>
-The bug tracking system sorts the bugs by package, you can
-watch the bugs of each package at
+The bug tracking system track bugs for each package. You can
+view the bugs of a given package at the URL
<tt>http://&bugs-host;/<var>package-name</var></tt>.
<sect1 id="madison">The <prgn>madison</prgn> utility
libdbd-mysql-perl | 1.2219-1 | unstable | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
</example>
<p>
-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
+In this example, you can see that the version in <em>unstable</em> differs from
+the version in <em>testing</em> and that there has been a binary-only NMU of the
package for the alpha architecture. Each time the package has been
recompiled on most of the architectures.
<item>
In the future, you may receive regular summary mails to keep you
informed of the package's status (bug statistics, porting overview,
-progression in testing, ...).
+progression in <em>testing</em>, ...).
</taglist>
<p>
You can also decide to receive some more information:
to <tt><var>srcpackage</var>_cvs@&pts-host;</tt>. Only people who
accepts the <em>cvs</em> keyword will receive the notifications.
+ <sect id="ddpo">Developer's packages overview
+ <p>
+A QA (quality assurance) web portal is available at <url
+ id="&url-ddpo;"> which displays a table listing all the packages
+of a single developer (including those where the party is listed as
+a co-maintainer). The table gives a good summary about the developer's
+packages: number of bugs by severity, list of available versions in each
+distribution, testing status and much more including links to any other
+useful information.
+ <p>
+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.
+
<chapt id="pkgs">Managing Packages
<p>
<p>
The <tt>Distribution</tt> field, which originates from the first line of
the <file>debian/changelog</file> file, indicates which distribution the
-package is intended for.
+package is intended for.
<p>
-There are three possible values for this field: `stable', `unstable',
-and `experimental'. Normally, packages are uploaded into
-<em>unstable</em>.
- <p>
-You should avoid combining `stable' with others because of potential
-problems with library dependencies (for your package and for the package
-built by the build daemons for other architecture).
-See <ref id="upload-stable"> for more information on when and how to
-upload to <em>stable</em>.
+There are several possible values for this field: `stable', `unstable',
+`testing-proposed-updates' and `experimental'. Normally, packages are uploaded into
+<em>unstable</em>. Actually, there are two other possible distributions:
+`stable-security' and `testing-security'. However they are used by the
+security team; do not upload there without their agreement.
<p>
-It never makes sense to combine the <em>experimental</em> distribution
-with anything else.
-
-<!--
- <sect2 id="upload-frozen">Uploading to <em>frozen</em>
- <p>
-The Debian freeze is a crucial time for Debian. It is our chance to
-synchronize and stabilize our distribution as a whole. Therefore,
-care must be taken when uploading to <em>frozen</em>.
- <p>
-It is tempting to always try to get the newest release of software
-into the release. However, it's much more important that the system
-as a whole is stable and works as expected.
- <p>
-The watchword for uploading to <em>frozen</em> is <strong>no new
-code</strong>. This is a difficult thing to quantify, so here are
-some guidelines:
- <p>
-<list>
- <item>
-Fixes for bugs of severity <em>critical</em>, <em>grave</em>, or
-<em>serious</em> severity are always allowed for those packages that
-must exist in the final release
- <item>
-<em>critical</em>, <em>grave</em>, and <em>serious</em> bug fixes are
-allowed for non-necessary packages but only if they don't add any new
-features
- <item>
-important, normal and minor bug fixes are allowed (though discouraged)
-on all packages if and only if there are no new features
- <item>
-wishlist fixes are not allowed (they are, after all, not really bugs)
- <item>
-documentation bug fixes are allowed, since good documentation is
-important
- </list>
- <p>
-Experience has shown that there is statistically a 15% chance that
-every bug fix will introduce a new bug. The introduction and
-discovery of new bugs either delays release or weakens the final
-product. There is little correlation between the severity of the
-original bug fixed and the severity of the bug newly introduced by the
-fix.
-
- -->
+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 <em>experimental</em>
+distribution with anything else.
<sect3 id="upload-stable">Uploading to <em>stable</em>
<p>
Uploading to <em>stable</em> means that the package will be placed into the
-<file>proposed-updates</file> directory of the Debian archive for further
+<file>stable-proposed-updates</file> directory of the Debian archive for further
testing before it is actually included in <em>stable</em>.
<p>
Extra care should be taken when uploading to <em>stable</em>. Basically, a
those other packages uninstallable, is strongly discouraged.
<p>
The Release Team (which can be reached at &email-debian-release;) will
-regularly evaluate the uploads in <em>proposed-updates</em> and decide if
+regularly evaluate the uploads in <em>stable-proposed-updates</em> and decide if
your package can be included in <em>stable</em>. Please be clear (and
verbose, if necessary) in your changelog entries for uploads to
<em>stable</em>, because otherwise the package won't be considered for
inclusion.
-
+ <sect3 id="upload-t-p-u">Uploading to <em>testing-proposed-updates</em>
+ <p>
+The testing distribution is fed with packages from unstable according to the rules
+explained in <ref id="testing">. 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 <em>testing-proposed-updates</em> to provide fixed packages during the freeze.
+ <p>
+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;.
+ <p>
+You should not upload to <em>testing-proposed-updates</em> when you can update your
+packages through <em>unstable</em>. 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.
<sect1 id="uploading">Uploading a package
slightly different rules than non-porters, due to their unique
circumstances (see <ref id="source-nmu-when-porter">).
<p>
-When a security bug is detected, a fixed package should be uploaded
-as soon as possible. In this case, the Debian security officers get in
-contact with the package maintainer to make sure a fixed package is
-uploaded within a reasonable time (less than 48 hours). If the package
-maintainer cannot provide a fixed package fast enough or if he/she
-cannot be reached in time, a security officer may upload a fixed
-package (i.e., do a source NMU).
+When a security bug is detected, the security team may do an NMU.
+Please refer to <ref id="bug-security"> for more information.
<p>
During the release cycle (see <ref id="sec-dists">), 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 <ref
-id="nmu-guidelines"> need to be followed.
+id="nmu-guidelines"> need to be followed. Special exceptions are made
+for <ref id="qa-bsp">.
<p>
-Bug fixes to unstable by non-maintainers are also acceptable, but only
-as a last resort or with permission. The following protocol should
-be respected to do an NMU:
+Uploading bug fixes to unstable by non-maintainers should only be done
+by following this protocol:
<p>
<list>
<item>
-Make sure that the package's bug is in the Debian Bug Tracking System
-(BTS). If not, submit a bug.
+Make sure that the package's bugs that the NMU is meant to address are all
+filed in the Debian Bug Tracking System (BTS).
+If they are not, submit them immediately.
<item>
Wait a few days the response from the maintainer. If you don't get
any response, you may want to help him by sending the patch that fixes
Follow what happens, you're responsible for any bug that you introduced
with your NMU. You should probably use <ref id="pkg-tracking-system"> (PTS)
to stay informed of the state of the package after your NMU.
- </list>
+</list>
+ <p>
+At times, the release manager or an organized group of developers can
+announce a certain period of time in which the NMU rules are relaxed.
+This usually involves shortening the period during which one is to wait
+before uploading the fixes, and shortening the DELAYED period. It is
+important to notice that even in these so-called "bug squashing party"
+times, the NMU'er has to file bugs and contact the developer first,
+and act later.
<sect1 id="nmu-guidelines">How to do a source NMU
<p>
<sect1 id="ack-nmu">Acknowledging an NMU
<p>
-If one of your packages has been NMUed, you have to incorporate the
+If one of your packages has been NMU'ed, you have to incorporate the
changes in your copy of the sources. This is easy, you just have
to apply the patch that has been sent to you. Once this is done, you
have to close the bugs that have been tagged fixed by the NMU. You
<p>
"Collaborative maintenance" is a term describing the sharing of Debian
package maintenance duties by several people. This collaboration is
-almost a good idea, since it generally results in higher quality and
+almost always a good idea, since it generally results in higher quality and
faster bug fix turnaround time. It is strongly recommended that
packages in which a priority of <tt>Standard</tt> or which are part of
the base set have co-maintainers.</p>
<p>
Add the co-maintainer's correct maintainer name and address to the
<tt>Uploaders</tt> field in the global part of the
-<file>debian/control</file> file.</p>
+<file>debian/control</file> file.
+<example>
+Uploaders: John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org>
+</example>
+</p>
</item>
<item>
<p>
your <file>debian/control</file> file to replace and conflict with the
obsolete name of the package (see the <url id="&url-debian-policy;"
name="Debian Policy Manual"> for details). Once you've uploaded
-that package, and the package has moved into the archive, file a bug
+the package and the package has moved into the archive, file a bug
against <tt>ftp.debian.org</tt> asking to remove the package with the
obsolete name. Do not forget to properly reassign the package's bugs
at the same time.
+ <p>
+At other times, you may make a mistake in constructing your package and
+wish to replace it. The only way to do this is to increase the version
+number and upload a new version. The old version will be expired in
+the usual manner. Note that this applies to each part of your package,
+including the sources: if you wish to replace the upstream source tarball
+of your package, you will need to upload it with a different version. An
+easy possibility is to replace <file>foo_1.00.orig.tar.gz</file> with
+<file>foo_1.00+0.orig.tar.gz</file>. This restriction gives each file
+on the ftp site a unique name, which helps to ensure consistency across the
+mirror network.
<sect1 id="orphaning">Orphaning a package
<p>
bug log (that means you don't need to send a copy of the mail to
<email>123@bugs.debian.org</email>).
<p>
+Once you've dealt with a bug report (e.g. fixed it), mark it as
+<em>done</em> (close it) by sending an explanation message to
+<email>123-done@bugs.debian.org</email>. If you're fixing a bug by
+changing and uploading the package, you can automate bug closing as
+described in <ref id="upload-bugfix">.
+ <p>
You should <em>never</em> close bugs via the bug server <tt>close</tt>
command sent to &email-bts-control;. If you do so, the original
submitter will not receive any information about why the bug was
<p>
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 <url id="&url-bts-control;" name="BTS
-instructions"> document the technical operations of the BTS, such as
-how to file, reassign, merge, and tag bugs. This section contains
+other packages. The bug tracking system's features interesting to developers
+are described in the <url id="&url-bts-devel;" name="BTS documentation for
+Debian developers">. Operations such as reassigning, merging, and tagging
+bug reports are described in the <url id="&url-bts-control;" name="BTS
+control bot documentation">. This section contains
some guidelines for managing your own bugs, based on the collective
Debian developer experience.
<p>
Filing bugs for problems that you find in other packages is one of
the "civic obligations" of maintainership, see <ref id="submit-bug">
-for details. However handling the bugs on your own packages is
+for details. However, handling the bugs in your own packages is
even more important.
<p>
Here's a list of steps that you may follow to handle a bug report:
If this situation is unacceptable, you (or the submitter) may want to
require a decision of the technical committee by reassigning the bug
to <package>tech-ctte</package> (you may use the clone command of
-the BTS if you wish to keep it reported against your package).
-<!-- FIXME: Follow the procedure described at
- tech-ctte-url (there's no such url yet). -->
+the BTS if you wish to keep it reported against your package). Before
+doing so, please read the <url id="&url-tech-ctte;" name="recommended procedure">.
<item>
If the bug is real but it's caused by another package, just reassign
the bug the right package. If you don't know which package it should
read <ref id="upload-bugfix">.
</enumlist>
+ <sect1 id="bug-security">Handling security-related bugs
+ <p>
+Due to their sensitive nature, security-related bugs must be handled
+carefully. The Debian Security Team exists to coordinate this
+activity, keeping track of outstanding security problems, helping
+maintainers with security problems or fix them themselves, sending
+security advisories, and maintaining security.debian.org.
+
+<!-- information about the security database goes here once it's ready -->
+<!-- (mdz) -->
+
+ <sect2 id="bug-security-you">What to do when you learn of a
+ security problem
+ <p>
+When you become aware of a security-related bug in a Debian package,
+whether or not you are the maintainer, collect pertinent information
+about the problem, and promptly contact the security team at
+&email-security-team;.
+Useful information includes, for example:
+
+<list compact>
+ <item>What versions of the package are known to be affected by the
+ bug. Check each version that is present in a supported Debian
+ release, as well as testing and unstable.
+
+ <item>The nature of the fix, if any is available (patches are
+ especially helpful)
+
+ <item>Any fixed packages that you have prepared yourself (send only
+ the <tt>.diff.gz</tt> and <tt>.dsc</tt> files)
+
+ <item>Any information needed for the advisory (see <ref
+ id="bug-security-advisories">)
+
+</list>
+
+ <sect2 id="bug-security-confidentiality">Confidentiality
+ <p>
+Unlike most other activities within Debian, information about security
+issues must sometimes be kept private for a time. Whether this is the
+case depends on the nature of the problem and corresponding fix, and
+whether it is already a matter of public knowledge.
+<p>
+There are a few ways a developer can learn of a security problem:
+
+<list compact>
+ <item>he notices it on a public forum (mailing list, web site, etc.)
+ <item>someone files a bug report
+ <item>someone informs him via private email
+</list>
+
+ In the first two cases, the information is public and it is important
+ to have a fix as soon as possible. In the last case, however, it
+ might not be public information. In that case there are a few
+ possible options for dealing with the problem:
+
+<list>
+ <item>if it is a trivial problem (like insecure temporary files)
+ there is no need to keep the problem a secret and a fix should be
+ made and released.
+
+ <item>if the problem is severe (remotely exploitable, possibility to
+ gain root privileges) it is preferable to share the information with
+ other vendors and coordinate a release. The security team keeps
+ contacts with the various organizations and individuals and can take
+ care of that.
+</list>
+
+<p>
+ In all cases if the person who reports the problem asks to not
+ disclose the information that should be respected, with the obvious
+ exception of informing the security team (make sure you tell the
+ security team that the information can not be disclosed).
+
+<p>
+Please note that if secrecy is needed you can also not upload a fix to
+unstable (or anywhere else), since the changelog and diff information
+for unstable is public.
+
+<p>
+There are two reasons for releasing information even though secrecy is
+requested: the problem has been known for a while, or that the problem
+or exploit has become public.
+
+ <sect2 id="bug-security-advisories">Security Advisories
+ <p>
+Security advisories are only issued for the current, released stable
+distribution, not for testing or unstable. When released, advisories
+are sent to the &email-debian-security-announce;
+mailing list and posted on <url
+id="&url-debian-security-advisories;" name="the security web page">.
+Security advisories are written and posted by the security
+team. However they certainly do not mind if a maintainer can supply
+some of the information for them, or write part of the
+text. Information that should be in an advisory includes:
+
+<list compact>
+ <item>A description of the problem and its scope, including:
+ <list>
+ <item>The type of problem (privilege escalation, denial of
+ service, etc.)
+ <item>How it can be exploited
+ <item>Whether it is remotely or locally exploitable
+ <item>How the problem was fixed
+ </list>
+ <item>Version numbers of affected packages
+ <item>Version numbers of fixed packages
+ <item>Information on where to obtain the updated packages
+ <item>References to upstream advisories, <url
+ id="http://cve.mitre.org" name="CVE"> identifiers, and any other
+ information useful in cross-referencing the vulnerability
+</list>
+
+ <sect2 id="bug-security-building">
+ <heading>Preparing packages to address security issues</heading>
+ <p>
+One way that you can assist the security team in their duties is to
+provide fixed packages suitable for a security advisory for the stable
+Debian release.
+ <p>
+ When an update is made to the stable release, care must be taken to
+ avoid changing system behavior or introducing new bugs. In order to
+ do this, make as few changes as possible to fix the bug. Users and
+ administrators rely on the exact behavior of a release once it is
+ made, so any change that is made might break someone's system.
+ This is especially true of libraries: make sure you never change the
+ API or ABI, no matter how small the change.
+<p>
+This means that moving to a new upstream version is not a good
+solution. Instead, the relevant changes should be back-ported to the
+version present in the current stable Debian release. Generally,
+upstream maintainers are willing to help if needed. If not, the
+Debian security team may be able to help.
+<p>
+In some cases, it is not possible to back-port a security fix, for
+example when large amounts of source code need to be modified or
+rewritten. If this happens, it may be necessary to move to a new
+upstream version. However, you must always coordinate that with the
+security team beforehand.
+<p>
+Related to this is another important guideline: always test your
+changes. If you have an exploit available, try it and see if it
+indeed succeeds on the unpatched package and fails on the fixed
+package. Test other, normal actions as well, as sometimes a security
+fix can break seemingly unrelated features in subtle ways.
+<p>
+Review and test your changes as much as possible. Check the
+differences from the previous version repeatedly
+(<prgn>interdiff</prgn> and <prgn>debdiff</prgn> are useful tools for
+this).
+
+When packaging the fix, keep the following points in mind:
+
+<list>
+ <item>Make sure you target the right distribution in your
+ <file>debian/changelog</file>. For stable this is <tt>stable-security</tt> and for
+ testing this is <tt>testing-security</tt>, and for the previous
+ stable release, this is <tt>oldstable-security</tt>. Do not target
+ <var>distribution</var>-proposed-updates!
+
+ <item>Make sure the version number is proper. It must be greater
+ than the current package, but less than package versions in later
+ distributions. If in doubt, test it with <tt>dpkg
+ --compare-versions</tt>. For <em>testing</em>, there must be
+ a higher version in <em>unstable</em>. If there is none yet (for example,
+ if <em>testing</em> and <em>unstable</em> have the same version) you must upload a
+ new version to unstable first.
+
+ <item>Do not make source-only uploads if your package has any
+ binary-all packages (do not use the <tt>-S</tt> option to
+ <prgn>dpkg-buildpackage</prgn>). The <prgn>buildd</prgn> infrastructure will
+ not build those. This point applies to normal package uploads as
+ well.
+
+ <item>If the upstream source has been uploaded to
+ security.debian.org before (by a previous security update), build
+ the upload without the upstream source (<tt>dpkg-buildpackage
+ -sd</tt>). Otherwise, build with full source
+ (<tt>dpkg-buildpackage -sa</tt>).
+
+ <item>Be sure to use the exact same <file>*.orig.tar.gz</file> as used in the
+ normal archive, otherwise it is not possible to move the security
+ fix into the main archives later.
+
+ <item>Be sure, when compiling a package, to compile on a clean
+ system which only has packages installed from the distribution you
+ are building for. If you do not have such a system yourself, you
+ can use a debian.org machine (see <ref id="server-machines">)
+ or setup a chroot (see <ref id="pbuilder"> and
+ <ref id="debootstrap">).
+</list>
+
+ <sect2 id="bug-security-upload">Uploading the fixed package
+<p>
+<em>DO NOT</em> upload a package to the security upload queue 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.
+<p>
+<em>DO NOT</em> upload your fix to proposed-updates without
+coordinating with the security team. Packages from
+security.debian.org will be copied into the proposed-updates directory
+automatically. If a package with the same or a higher version number
+is already installed into the archive, the security update will be
+rejected by the archive system. That way, the stable distribution
+will end up without a security update for this package instead.
+<p>
+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
+<tt>ftp://security.debian.org/pub/SecurityUploadQueue/</tt> .
+
+<p>
+Once an upload to the security queue has been accepted, the package
+will automatically be rebuilt for all architectures and stored for
+verification by the security team.
+
+<p>
+Uploads which are waiting for acceptance or verification are only
+accessible by the security team. This is necessary since there might
+be fixes for security problems that cannot be disclosed yet.
+
+<p>
+If a member of the security team accepts a package, it will be
+installed on security.debian.org as well as the proper
+<var>distribution</var>-proposed-updates on ftp-master or in the non-US
+archive.
<sect1 id="upload-bugfix">When bugs are closed by new uploads
<p>
notification that your updated package has been installed into the
archive, you can and should close the bug in the BTS.
<p>
-If you are using a new version of <package>dpkg-dev</package> and you do
-your changelog entry properly, the archive maintenance software will close
-the bugs automatically. All you have to do is follow a certain syntax in
-your <file>debian/changelog</file> file:
+However, it's possible to avoid having to manually close bugs after the
+upload -- just list the fixed bugs in your <file>debian/changelog</file>
+file, following a certain syntax, and the archive maintenance software
+will close the bugs for you. For example:
+
<example>
acme-cannon (3.1415) unstable; urgency=low
one of the most concise and easiest to integrate with the text of the
<file>changelog</file>.
<p>
-If you want to close bugs the old fashioned, manual way, it is usually
-sufficient to mail the <file>.changes</file> file to
+If you happen to mistype a bug number or forget one in the changelog file,
+don't hesitate to undo any damage the error caused. To reopen wrongly closed
+bugs, send an <tt>reopen <var>XXX</var></tt> command in the bug tracking
+system's control bot. To close any remaining bugs that were fixed by your
+upload, email the <file>.changes</file> file to
<email>XXX-done@bugs.debian.org</email>, where <var>XXX</var> is your
bug number.
+ <p>
+Bear in mind that it is not obligatory to close bugs using the changelog
+like described above -- if you simply want to close bugs that don't have
+anything to do with an upload of yours, do it simply by emailing an
+explanation to <email>XXX-done@bugs.debian.org</email>.
<sect1 id="lintian-reports">Lintian reports
offers enough flexibility to be able to use it in conjunction with
some hand crafted shell invocations within the <file>rules</file> file.
<p>
-You can however decide to not use any helper script, and still write
-some very good <file>rules</file> file. Many examples are available
+You can however decide to not use any helper script and still write
+excellent <file>rules</file> file. Many examples are available
at <url id="&url-rules-files;">.
<!--
<sect1 id="handling-debconf-translations">Handling debconf translations
<p>
-Like porters, translators have a difficult task. Since they work on many
-packages, they cannot keep track of every change in packages in order to
-be informed when a translated string is outdated. Fortunately
-<package>debconf</package> can automatically report outdated translations,
-if package maintainers follow some basic guidelines described below.
- <p>
-Translators can use <prgn>debconf-getlang</prgn> (package
-<package>debconf-utils</package>) to write a <file>templates.xx</file>
-file containing both English and localized fields (where <em>xx</em> is
-the language code, may be followed by a country code). This file can be
-put into the <file>debian</file> subdirectory without any change.
- <p>
-When building a binary package, <file>debian/templates.xx</file> files are
-merged along with <file>debian/templates</file> to generate the
-<file>templates</file> file contained in the binary package. This is
-automatically done by <prgn>dh_installdebconf</prgn> (package
-<package>debhelper</package>). If you do not use debhelper, you can
-do the same with <prgn>debconf-mergetemplate</prgn>
-(package <package>debconf-utils</package>).
- <p>
-When the package maintainer needs to update the templates file, they only
-change <file>debian/templates</file>. When English strings in this file
-and in <file>debian/templates.xx</file> differ, translators do know that
-their translation is outdated.
- <p>
-Please see the page about
-<url id="&url-debconf-l10n-help;" name="localizing debconf templates files">
-at the Debian web site, it contains more detailed instructions, including a
-full example.
-
+Like porters, translators have a difficult task. They work on many
+packages and must collaborate with many different
+maintainers. Moreover, most of the time, they are not native English
+speaker, so you may need to be particularly patient with them.
+ <p>
+The goal of <package>debconf</package> was to make packages
+configuration easier for maintainers and for users. Originally,
+translation of debconf templates was handled with
+<prgn>debconf-mergetemplate</prgn> from the
+<package>debconf-utils</package> package. Since
+<package>debconf</package> version 1.2.9,
+<prgn>debconf-mergetemplate</prgn> has been deprecated and a new
+system called <package>po-debconf</package> is strongly
+encouraged. This new method is much easier both for the maintainer and
+the translators, and you should upgrade your packages to use it.
+Transition scripts are provided.
+ <p>
+Using <package>po-debconf</package>, the translation is stored in
+<file>po</file> files (drawing from <prgn>gettext</prgn> translation
+techniques). Special template files contain the original messages and
+mark which fields should be translated. When you change the original,
+calling the <prgn>debconf-updatepo</prgn> script with no argument is
+enough to mark the translation as needing attention from the
+translators. Then, at build time, use the
+<prgn>dh_installdebconf</prgn> program take care of all the needed
+magic to add the template along with the up-to-date translations into
+the binary packages. Refer to the <manref name="po-debconf"
+section="7"> manual page for details.
<sect id="specific-practices">
<heading>Specific packaging practices</heading>
/etc/modutils/ for module configuration.
-->
+ <sect1 id="bpp-autotools">
+ <heading>Packages using
+ <prgn>autoconf</prgn>/<prgn>automake</prgn></heading>
+ <p>
+Some very good packaging practices for packages using
+<prgn>autoconf</prgn> and/or <prgn>automake</prgn> have been
+synthesized in &file-bpp-autotools;. You're strongly encouraged to
+read this file and to follow the given recommendations.
+
+
<sect1 id="bpp-libraries">Libraries
<p>
Libraries are always difficult to package for various reasons. The policy
imposes many constraints to ease their maintenance and to make sure
upgrades are as simple as possible when a new upstream version comes out.
-A breakage in a library can result in dozens of dependent packages to
-break...
+A breakage in a library can result in dozens of dependent packages
+breaking.
<p>
Good practices for library packaging have been grouped in
<url id="&url-libpkg-guide;" name="the library packaging guide">.
packaging rules and practices:
<list>
<item>
-Perl related packages have a <url name="perl policy" id="&url-perl-policy;">,
+Perl related packages have a <url name="Perl policy" id="&url-perl-policy;">,
some examples of packages following that policy are
<package>libdbd-pg-perl</package> (binary perl module) or
<package>libmldbm-perl</package> (arch independent perl module).
Java related packages have their <url id="&url-java-policy;"
name="java policy">.
<item>
-Ocaml related packages have their ocaml policy: &file-ocaml-policy; (in
+Ocaml related packages have their Ocaml policy: &file-ocaml-policy; (in
the <package>ocaml</package> package). A good example is the <package>camlzip</package>
source package.
</list>
<sect id="config-mgmt">
<heading>Configuration management</heading>
- <sect1 id="config-wise-debconf">The wise use of debconf
- <p>
-Debconf is a configuration management system, it is used by all the
-various packaging scripts (postinst mainly) to request feedback from the
-user concerning how to configure the package. Direct user interactions
-must now be avoided in favor of debconf interaction. This will enable
-non-interactive installations in the future.
+ <sect1 id="config-wise-debconf">
+ <heading>Proper use of <package>debconf</package></heading>
+ <p>
+<package>Debconf</package> is a configuration management system which
+can be used by all the various packaging scripts
+(<file>postinst</file> mainly) to request feedback from the user
+concerning how to configure the package. Direct user interactions must
+now be avoided in favor of <package>debconf</package>
+interaction. This will enable non-interactive installations in the
+future.
<p>
-Debconf is a great tool but it is often badly used ... many common mistakes
+Debconf is a great tool but it is often poorly used. Many common mistakes
are listed in the <manref name="debconf-devel" section="8"> man page.
It is something that you must read if you decide to use debconf.
mistakes. Ensure that you spell check it.
<prgn>ispell</prgn> has a special option (<tt>-g</tt>) for that:
<example>ispell -d american -g debian/control</example>.
-
+If you want someone to proofread the description that you
+intend to use you may ask on &email-debian-l10n-english;.
simply creating and maintaining packages.
<p>
As a volunteer organization, Debian relies on the discretion of its
-members in choosing what they want to work on, and choosing what is
+members in choosing what they want to work on and in choosing
the most critical thing to spend their time on.
<sect id="submit-bug">
<sect id="qa-effort">Quality Assurance effort
+
+ <sect1 id="qa-daily-work">Daily work
<p>
Even though there is a dedicated group of people for Quality
Assurance, QA duties are not reserved solely for them. You can
orphaning some of your packages (see <ref
id="orphaning">). Alternatively, you may ask the help of other people
in order to catch up the backlog of bugs that you have (you can ask
-for help on &email-debian-qa; or &email-debian-devel;).
+for help on &email-debian-qa; or &email-debian-devel;). At the same
+time, you can look for co-maintainers (see <ref id="collaborative-maint">).
+
+ <sect1 id="qa-bsp">Bug Squashing Parties
+ <p>
+From time to time the QA group organizes bug squashing parties to get rid of
+as many problems as possible. They are announced on &email-debian-devel-announce;
+and the announce explains what area will be focused on during the party:
+usually they focus on release critical bugs but it may happen that they
+decide to help finish a major upgrade going on (like a new perl version
+which requires recompilation of all the binary modules).
+ <p>
+The rules for non-maintainer uploads differ during the parties because
+the announce of the party is considered like a prior notice for NMU. If
+you have packages that may be affected by the party (because they have
+release critical bugs for example), you should send an update to each of
+the corresponding bug to explain their current status and what you expect
+from the party. If you don't want an NMU, or if you're only interested in a
+patch, or if you will deal yourself with the bug, please explain that in
+the BTS.
+ <p>
+People participating in the party have special rules for NMU, they can
+NMU without prior notice if they upload their NMU to
+DELAYED/3-day at least. All other NMU rules applies as usually, they
+should send the patch of the NMU in the BTS (in one of the open bugs
+fixed by the NMU or in a new bug tagged fixed). They should
+also respect the maintainer's wishes if he expressed some.
+ <p>
+If someone doesn't feel confident with an NMU, he should just send a patch
+to the BTS. It's far better than a broken NMU.
<sect id="mia-qa">Dealing with unreachable maintainers
<p>
must build and test the package on your own system before uploading.
<p>
You can not simply upload a binary <file>.deb</file> from the sponsoree. In
-theory, you should only ask only for the diff file, and the location of the
+theory, you should only ask for the diff file and the location of the
original source tarball, and then you should download the source and apply
the diff yourself. In practice, you may want to use the source package
built by your sponsoree. In that case, you have to check that they haven't
<p>
Once the package meets Debian standards, build the package with
<example>dpkg-buildpackage -us -uc</example> and sign it
-with <example>debsign -m <your-email-addr> <changes-file></example>
+with <example>debsign -m"<var>FULLNAME</var> <var>email-addr</var>" <var>changes-file</var></example>
before uploading it to the incoming directory.
<p>
The Maintainer field of the <file>control</file> file and the
<p>
These utilities provide an infrastructure to facilitate the use of CVS
by Debian maintainers. This allows one to keep separate CVS branches
-of a package for <em>stable</em>, <em>unstable</em>, and possibly
+of a package for <em>stable</em>, <em>unstable</em> and possibly
<em>experimental</em> distributions, along with the other benefits of
a version control system.