[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ next ]
In addition to the mailserver on [email protected] which allows the retrieval of bug data and documentation by email, there is another server on [email protected] which also 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.
Here is a list of available commands:
Close bug report `#bugnumber.'
A notification is sent to the user who reported the bug, but (in contrast to mailing bugnumber-done@bugs) the text of the mail which caused the bug to be closed is not included in that notification. The maintainer who closes a report should ensure, probably by sending a separate message, that the user who reported the bug knows why it is being closed.
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).
Reopens `#bugnumber' if it is closed.
By default you are recorded as the originator of the report, so that you will get the ack when it is closed again. This is to avoid flooding potentially-naive users with many notifications about the same report.
If you supply an originator-address the originator will be set to the address you supply; you can use `=' to keep the originator the same as it was before. 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. There is no way to change the originator of an open bug report (this is deliberate, so that you can't have a bug be closed and then deleted 28 days later without someone being told about it).
Notes that bugnumber has been forwarded to the upstream maintainer at address. This does not actually forward the report. This can be used to change an existing incorrect forwarded-to address, or to record a new one for a bug that wasn't previously noted as having been forwarded.
Forgets any idea that bugnumber has been forwarded to any upstream maintainer. If the bug was not recorded as having been forwarded then this will do nothing.
Changes the title of a bug report to that specified (the default is the Subject mail header from the original report.
Unlike most of the other bug-manipulation commands when used on one of a set of merged reports this will change the title of only the individual bug requested, and not all those with which it is merged.
Merges two or more bug reports. When reports are merged opening, closing, marking or unmarking as forwarded and reassigning any of the bugs to a new package will have an identical effect on all of the merged reports.
Before bugs can be merged they must be in exactly the same state: either all open or all closed, with the same forwarded-to upstream author address or all not marked as forwarded, and all assigned to the same package or package(s) (an exact string comparison is done on the package to which the bug is assigned). If they don't start out in the same state you should use reassign, reopen and so forth to make sure that they are before using merge.
If any of the bugs listed in a merge command is already merged with another bug then all the reports merged with any of the ones listed will all be merged together. Merger is like equality: it is reflexive, transitive and symmetric.
Merging reports causes a note to appear on each report's logs; on the WWW pages this is includes links to the other bugs.
Merged reports are all expired simultaneously, and only when all of the reports each separately meet the criteria for expiry.
Disconnects a bug report from any other reports with which it may have been merged. If the report listed is merged with several others then they are all left merged with each other; only their associations with the bug explicitly named are removed.
If many bug reports are merged and you wish to split them into two separate groups of merged reports you must unmerge each report in one of the new groups separately and then merge them into the required new group.
You can only unmerge one report with each unmerge command; if you want to disconnect more than one bug simply include several unmerge commands in your message.
send bugnumber
send-detail bugnumber
index [full]
index-summary by-package
index-summary by-number
index-maint
index maint maintainer-substring
send-unmatched [this|0]
send-unmatched last|-1
send-unmatched old|-2
getinfo filename (see below)
help
refcard
quit|stop|thank...|--...
#... _(comment)_
debug level
maintainers
override.stable
override.development
override.contrib
override.non-free
override.experimental
override.codeword
pseudo-packages.description
pseudo-packages.maintainers
close bugnumber (you must separately tell originator why)
reassign bugnumber package
reopen bugnumber [originator-address|=]
forwarded bugnumber address
notforwarded bugnumber
retitle bugnumber new-title
merge bugnumber bugnumber ...
unmerge bugnumber
[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ next ]
Debian's Bug Tracking System
[email protected][email protected]