* About Debian
* Getting Debian
* Developers' Corner
Debian bug tracking system / Debian BTS — developer info
Information regarding the bug processing system for package maintainers and
Initially, a bug report is submitted by a user as an ordinary mail
message to email@example.com which must include a Package line
(see Bug Reporting Instructions for more information). This will then
be given a number, acknowledged to the user, and forwarded to
debian-bugs-dist. If the Package line contains a package which has a
known maintainer, the maintainer will get a copy too.
The Subject line will have Bug#nnn: added, and the Reply-To will be set
to include both the submitter of the report and firstname.lastname@example.org.
* Closing bug reports
* Followup messages
* Severity levels
* Tags for bug reports
* Recording that you have passed on a bug report
* Changing bug ownership
* Incorrectly listed package maintainers
* Reopening, reassigning and manipulating bugs
* Subscribing to bugs
* More-or-less obsolete subject-scanning feature
* Obsolete X-Debian-PR: quiet feature
Closing bug reports
Debian bug reports should be closed when the problem is fixed. Problems
in packages can only be considered fixed once a package that includes
the bug fix enters the Debian archive.
Normally, the only people that should close a bug report are the
submitter of the bug and the maintainer(s) of the package against which
the bug is filed. There are exceptions to this rule, for example, the
bugs filed against unknown packages or certain generic pseudo-packages.
When in doubt, don't close bugs, first ask for advice on the
debian-devel mailing list.
Bug reports should be closed by sending email to
email@example.com. The message body needs to contain an
explanation of how the bug was fixed.
With the emails received from the bug tracking system, all you need to
do to close the bug is to make a Reply in your mail reader program and
edit the To field to say firstname.lastname@example.org instead of
email@example.com (nnn-close is provided as an alias for nnn-done).
Where applicable, please supply a Version line in the pseudo-header of
your message when closing a bug, so that the bug tracking system knows
which releases of the package contain the fix.
The person closing the bug, the person who submitted it and the
debian-bugs-closed mailing list will each get a notification about the
change in status of the report. The submitter and the mailing list will
also receive the contents of the message sent to nnn-done.
The bug tracking system will include the submitter's address and the
bug address (firstname.lastname@example.org) in the Reply-To header after
forwarding the bug report. Please note that these are two distinct
Any developer wishing to reply to a bug report should simply reply to
the message, respecting the Reply-To header. This will not close the
Do not use the "reply to all recipients" or "followup" feature of your
mailer unless you intend to edit down the recipients substantially. In
particular, see that you don't send followup messages to
Messages can be sent to the following addresses in order to be filed in
the bug tracking system:
* email@example.com — such messages are also sent to the package
maintainer and forwarded to debian-bugs-dist, but not to the
* firstname.lastname@example.org — these are also sent to the
submitter and forwarded to debian-bugs-dist, but not to the package
* email@example.com — these are only sent to the package
maintainer, not to the submitter or debian-bugs-dist;
* firstname.lastname@example.org — these are only filed in the bug
tracking system (as are all the above), not sent to anyone else.
For more information about headers to suppress ACK messages and how to
send carbon copies using the Bug Tracking System, see the instructions
for reporting bugs.
The bug system records a severity level with each bug report. This is
set to normal by default, but can be overridden either by supplying a
Severity line in the pseudo-header when the bug is submitted (see the
instructions for reporting bugs), or by using the severity command with
the control request server.
The severity levels are:
makes unrelated software on the system (or the whole system)
break, or causes serious data loss, or introduces a security
hole on systems where you install the package.
makes the package in question unusable or mostly so, or causes
data loss, or introduces a security hole allowing access to the
accounts of users who use the package.
is a severe violation of Debian policy (roughly, it violates a
"must" or "required" directive), or, in the package maintainer's
or release manager's opinion, makes the package unsuitable for
a bug which has a major effect on the usability of a package,
without rendering it completely unusable to everyone.
the default value, applicable to most bugs.
a problem which doesn't affect the package's usefulness, and is
presumably trivial to fix.
for any feature request, and also for any bugs that are very
difficult to fix due to major design considerations.
Certain severities are considered release-critical, meaning the bug
will have an impact on releasing the package with the stable release of
Debian. Currently, these are critical, grave and serious. For complete
and canonical rules on what issues merit these severities, see the list
of release-critical issues for the next release.
Tags for bug reports
Each bug can have zero or more of a set of given tags. These tags are
displayed in the list of bugs when you look at a package's page, and
when you look at the full bug log.
Tags can be set by supplying a Tags line in the pseudo-header when the
bug is submitted (see the instructions for reporting bugs), or by using
the tags command with the control request server. Separate multiple
tags with commas, spaces, or both.
The current bug tags are: patch, wontfix, moreinfo, unreproducible,
help, newcomer, pending, security, upstream, confirmed, fixed,
fixed-upstream, fixed-in-experimental, d-i, ipv6, lfs, l10n, a11y,
potato, woody, sarge, etch, lenny, squeeze, wheezy, jessie, stretch,
buster, bullseye, sid, experimental, sarge-ignore, etch-ignore,
lenny-ignore, squeeze-ignore, wheezy-ignore, jessie-ignore,
stretch-ignore, buster-ignore, bullseye-ignore . Here is some detailed
info about the tags:
A patch or some other easy procedure for fixing the bug is
included in the bug logs. If there's a patch, but it doesn't
resolve the bug adequately or causes some other problems, this
tag should not be used.
This bug won't be fixed. Possibly because this is a choice
between two arbitrary ways of doing things and the maintainer
and submitter prefer different ways of doing things, possibly
because changing the behaviour will cause other, worse, problems
for others, or possibly for other reasons.
This bug cHTTP/1.1 403 Forbidden
Content-Type: text/html; charset=UTF-8
Access to this website is restricted by NUS
Computer Centre is putting additional security control to protect your computer as well as NUS systems from cyber security threats. We detected that the website you have attempted to visit may contain harmful content and could potentially damage your computer or other NUS systems.