Skip Quicknav * About Debian * Getting Debian * Support * Developers' Corner Debian bug tracking system / Debian BTS — developer info Information regarding the bug processing system for package maintainers and bug triagers Initially, a bug report is submitted by a user as an ordinary mail message to 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 * 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 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 instead of (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. Followup messages The bug tracking system will include the submitter's address and the bug address ( in the Reply-To header after forwarding the bug report. Please note that these are two distinct addresses. 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 bug. 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: * — such messages are also sent to the package maintainer and forwarded to debian-bugs-dist, but not to the submitter; * — these are also sent to the submitter and forwarded to debian-bugs-dist, but not to the package maintainer; * — these are only sent to the package maintainer, not to the submitter or debian-bugs-dist; * — 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. Severity levels 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: critical 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. grave 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. serious 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 release. important a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone. normal the default value, applicable to most bugs. minor a problem which doesn't affect the package's usefulness, and is presumably trivial to fix. wishlist 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: patch 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. wontfix 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. moreinfo This bug cHTTP/1.1 403 Forbidden Connection: close Content-Length: 1807 Content-Type: text/html; charset=UTF-8 Restricted Content

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.