<!entity % commondata SYSTEM "common.ent" > %commondata;
<!-- CVS revision of this document -->
- <!entity cvs-rev "$Revision: 1.133 $">
+ <!entity cvs-rev "$Revision: 1.139 $">
<!-- 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
<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
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
+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 <em>testing</em> because the set of
<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>
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:
<list compact>
<item>What versions of the package are known to be affected by the
- bug.
-
- <item>The nature of the exposure (root compromise, user compromise,
- remote/local attack)
+ 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
<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">
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>. Do not target
+ 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
not build those. This point applies to normal package uploads as
well.
- <item>Always build with full source (use the <tt>-sa</tt> option
- for <prgn>dpkg-buildpackage</prgn>).
+ <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
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
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
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
~ianmdlvl / developers-reference.git / blobdiff