Skip Quicknav * About Debian * Getting Debian * Support * Developers' Corner Debian bug tracking system / Debian BTS — control server Introduction to the bug control and manipulation mailserver Just as request@bugs.debian.org allows the retrieval of bug data and documentation by email, control@bugs.debian.org allows bug reports to be manipulated in various ways. The control server works just like the request server, except that it has some additional commands; in fact, it's the same program. The two addresses are only separated to avoid users making mistakes and causing problems while merely trying to request information. Since the commands specific to the control server actually change the status of a bug, a notification about processing the commands is sent to the maintainer of the package(s) the changed bugs are assigned to. Additionally the mail to the server and the resulting changes are logged in the bug report and thereby available in the WWW pages. Please see the introduction to the request server available on the World Wide Web, in the file bug-log-mailserver.txt, or by sending help to either mailserver, for details of the basics of operating the mailservers and the common commands available when mailing either address. The reference card for the mailservers is available via the WWW, in bug-mailserver-refcard.txt or by email using the refcard command. Commands available at the control mailserver General Versioning Duplicates Misc. * reassign * severity * tags * retitle * submitter * affects * summary * outlook * found | notfound * fixed | notfixed * reopen * merge | unmerge * forcemerge * clone * thanks * # * forwarded | notforwarded * owner | noowner * block | unblock * archive | unarchive * user | usertag | usercategory reassign bugnumber package [ version ] Records that bug #bugnumber is a bug in package. This can be used to set the package if the user forgot the pseudo-header, or to change an earlier assignment. No notifications are sent to anyone (other than the usual information in the processing transcript). If you supply a version, the bug tracking system will note that the bug affects that version of the newly-assigned package. You can assign a bug to two packages at once by separating the package names with a comma. However, you should only do this if the bug can be fixed by a change to either package. If this is not the case, you should clone the bug and reassign the clone to the other package. reopen bugnumber [ originator-address | = | ! ] Reopens #bugnumber if it is closed. By default, or if you specify =, the original submitter is still as the originator of the report, so that they will get the ack when it is closed again. If you supply an originator-address the originator will be set to the address you supply. If you wish to become the new originator of the reopened report you can use the ! shorthand or specify your own email address. It is usually a good idea to tell the person who is about to be recorded as the originator that you're reopening the report, so that they will know to expect the ack which they'll get when it is closed again. If the bug is not closed then reopen won't do anything, not even change the originator. To change the originator of an open bug report, use the submitter command; note that this will inform the original submitter of the change. If the bug was recorded as being closed in a particular version of a package but recurred in a later version, it is better to use the found command instead. found bugnumber [ version ] Record that #bugnumber has been encountered in the given version of the package to which it is assigned. version may be a fully qualified version, of the form sourcepackagename/version. The bug tracking system uses this information, in conjunction with fixed versions recorded when closing bugs, to display lists of bugs open in various versions of each package. It considers a bug to be open when it has no fixed version, or when it has been found more recently than it has been fixed. If no version is given, then the list of fixed versions for the bug is cleared. This is identical to the behaviour of reopen. version may be a fully qualified version, of the form sourcepackagename/version. This command will only cause a bug to be marked as not done if no version is specified, or if the version being marked found is equal to or greater than the highest version marked fixed. (If you are certain that you want the bug marked as not done, use reopen in conjunction with found.) This command was introduced in preference to reopen because it was difficult to add a version to that command's syntax without suffering ambiguity. notfound bugnumber version Remove the record that #bugnumber was encountered in the given version of the package to which it is assigned. version may be a fully qualified version, of the form sourcepackagename/version. This differs from closing the bug at that version in that the bug is not listed as fixed in that version either; no information about that version will be known. It is intended for fixing mistakes in the record of when a bug was found. fixed bugnumber version Indicate that bug #bugnumber was fixed in the given version of the package to which it is assigned. version may be a fully qualified version, of the form sourcepackagename/version. This does not cause the bug to be marked as closed, it merely adds another version in which the bug was fixed. Use the bugnumber-done address to close a bug and mark it fixed in a partHTTP/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.