2007-09-23 08:04:20 +00:00
|
|
|
|
Introduction to the bug control and manipulation mailserver
|
|
|
|
|
|
|
|
|
|
|
|
In addition to the mailserver on request@bugs.debian.org which allows
|
|
|
|
|
|
the retrieval of bug data and documentation by email, there is another
|
|
|
|
|
|
server on control@bugs.debian.org 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.
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
2007-09-23 08:04:50 +00:00
|
|
|
|
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 the version which was last marked fixed. (If you
|
|
|
|
|
|
are certain that you want the bug marked as not done, use
|
|
|
|
|
|
reopen in conjunction with found.)
|
|
|
|
|
|
|
2007-09-23 08:04:20 +00:00
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
2007-09-23 08:04:50 +00:00
|
|
|
|
fixed bugnumber version
|
|
|
|
|
|
Indicate that bug #bugnumber was fixed in the given version of
|
|
|
|
|
|
the package to which it is assigned.
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
particular version.
|
|
|
|
|
|
|
|
|
|
|
|
notfixed bugnumber version
|
|
|
|
|
|
Remove the record that bug #bugnumber has been fixed in the
|
|
|
|
|
|
given version.
|
|
|
|
|
|
|
|
|
|
|
|
This command is equivalent to found followed by notfound (the
|
|
|
|
|
|
found removes the fixed at a particular version, and notfound
|
|
|
|
|
|
removes the found.)
|
|
|
|
|
|
|
2007-09-23 08:04:20 +00:00
|
|
|
|
submitter bugnumber originator-address | !
|
|
|
|
|
|
Changes the originator of #bugnumber to originator-address.
|
|
|
|
|
|
|
|
|
|
|
|
If you wish to become the new originator of the report you can
|
|
|
|
|
|
use the ! shorthand or specify your own email address.
|
|
|
|
|
|
|
|
|
|
|
|
While the reopen command changes the originator of other bugs
|
|
|
|
|
|
merged with the one being reopened, submitter does not affect
|
|
|
|
|
|
merged bugs.
|
|
|
|
|
|
|
|
|
|
|
|
forwarded bugnumber address
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
notforwarded bugnumber
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
retitle bugnumber new-title
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
severity bugnumber severity
|
|
|
|
|
|
Set the severity level for bug report #bugnumber to severity.
|
|
|
|
|
|
No notification is sent to the user who reported the bug.
|
|
|
|
|
|
|
|
|
|
|
|
Severities are critical, grave, serious, important, normal,
|
|
|
|
|
|
minor, and wishlist.
|
|
|
|
|
|
|
|
|
|
|
|
For their meanings please consult the general developers'
|
|
|
|
|
|
documentation for the bug system.
|
|
|
|
|
|
|
|
|
|
|
|
clone bugnumber NewID [ new IDs ... ]
|
|
|
|
|
|
The clone control command allows you to duplicate a bug report.
|
|
|
|
|
|
It is useful in the case where a single report actually
|
|
|
|
|
|
indicates that multiple distinct bugs have occurred. "New IDs"
|
|
|
|
|
|
are negative numbers, separated by spaces, which may be used in
|
|
|
|
|
|
subsequent control commands to refer to the newly duplicated
|
|
|
|
|
|
bugs. A new report is generated for each new ID.
|
|
|
|
|
|
|
|
|
|
|
|
Example usage:
|
|
|
|
|
|
|
|
|
|
|
|
clone 12345 -1 -2
|
|
|
|
|
|
reassign -1 foo
|
|
|
|
|
|
retitle -1 foo: foo sucks
|
|
|
|
|
|
reassign -2 bar
|
|
|
|
|
|
retitle -2 bar: bar sucks when used with foo
|
|
|
|
|
|
severity -2 wishlist
|
|
|
|
|
|
clone 123456 -3
|
|
|
|
|
|
reassign -3 foo
|
|
|
|
|
|
retitle -3 foo: foo sucks
|
|
|
|
|
|
merge -1 -3
|
|
|
|
|
|
|
|
|
|
|
|
merge bugnumber bugnumber ...
|
|
|
|
|
|
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, all assigned to the same package or package(s) (an
|
|
|
|
|
|
exact string comparison is done on the package to which the bug
|
|
|
|
|
|
is assigned), and all of the same severity. 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. Titles are
|
|
|
|
|
|
not required to match, and will not be affected by the merge.
|
|
|
|
|
|
Tags are not required to match, either, they will be joined.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
forcemerge bugnumber bugnumber ...
|
|
|
|
|
|
Forcibly merges two or more bug reports. The first bug listed
|
|
|
|
|
|
is the master bug, and its settings (the settings which must be
|
|
|
|
|
|
equal in a normal merge) are assigned to the bugs listed next.
|
|
|
|
|
|
To avoid typos erroneously merging bugs, bugs must be in the
|
|
|
|
|
|
same package. See the text above for a description of what
|
|
|
|
|
|
merging means.
|
|
|
|
|
|
|
|
|
|
|
|
Note that this makes it possible to close bugs by merging; you
|
|
|
|
|
|
are responsible for notifying submitters with an appropriate
|
|
|
|
|
|
close message if you do this.
|
|
|
|
|
|
|
|
|
|
|
|
unmerge bugnumber
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
tags bugnumber [ + | - | = ] tag [ tag ... ]
|
|
|
|
|
|
Sets tags for the bug report #bugnumber. No notification is
|
|
|
|
|
|
sent to the user who reported the bug. Setting the action to +
|
|
|
|
|
|
means to add each given tag, - means to remove each given tag,
|
|
|
|
|
|
and = means to ignore the current tags and set them afresh to
|
|
|
|
|
|
the list provided. The default action is adding.
|
|
|
|
|
|
|
|
|
|
|
|
Example usage:
|
|
|
|
|
|
|
|
|
|
|
|
# same as 'tags 123456 + patch'
|
|
|
|
|
|
tags 123456 patch
|
|
|
|
|
|
|
|
|
|
|
|
# same as 'tags 123456 + help security'
|
|
|
|
|
|
tags 123456 help security
|
|
|
|
|
|
|
|
|
|
|
|
# add 'fixed' and 'pending' tags
|
|
|
|
|
|
tags 123456 + fixed pending
|
|
|
|
|
|
|
|
|
|
|
|
# remove 'unreproducible' tag
|
|
|
|
|
|
tags 123456 - unreproducible
|
|
|
|
|
|
|
|
|
|
|
|
# set tags to exactly 'moreinfo' and 'unreproducible'
|
|
|
|
|
|
tags 123456 = moreinfo unreproducible
|
|
|
|
|
|
|
|
|
|
|
|
Available tags currently include patch, wontfix, moreinfo,
|
|
|
|
|
|
unreproducible, help, pending, fixed, fixed-in-experimental,
|
|
|
|
|
|
fixed-upstream, security, upstream, confirmed, d-i, ipv6, lfs,
|
|
|
|
|
|
l10n, potato, woody, sarge, sarge-ignore, etch, etch-ignore,
|
|
|
|
|
|
sid, and experimental.
|
|
|
|
|
|
|
|
|
|
|
|
For their meanings please consult the general developers'
|
|
|
|
|
|
documentation for the bug system.
|
|
|
|
|
|
|
|
|
|
|
|
block bugnumber by bug ...
|
2007-09-23 08:04:50 +00:00
|
|
|
|
Note that the fix for the first bug is blocked by the other
|
2007-09-23 08:04:20 +00:00
|
|
|
|
listed bugs.
|
|
|
|
|
|
|
|
|
|
|
|
unblock bugnumber by bug ...
|
2007-09-23 08:04:50 +00:00
|
|
|
|
Note that the fix for the first bug is no longer blocked by the
|
|
|
|
|
|
other listed bugs.
|
2007-09-23 08:04:20 +00:00
|
|
|
|
|
|
|
|
|
|
close bugnumber [ fixed-version ] (deprecated)
|
|
|
|
|
|
Close bug report #bugnumber.
|
|
|
|
|
|
|
|
|
|
|
|
A notification is sent to the user who reported the bug, but
|
|
|
|
|
|
(in contrast to mailing bugnumber-done@bugs.debian.org) the
|
|
|
|
|
|
text of the mail which caused the bug to be closed is not
|
|
|
|
|
|
included in that notification. The maintainer who closes a
|
|
|
|
|
|
report needs to ensure, probably by sending a separate message,
|
|
|
|
|
|
that the user who reported the bug knows why it is being
|
|
|
|
|
|
closed. The use of this command is therefore deprecated. See
|
|
|
|
|
|
the developer's information about how to close a bug properly.
|
|
|
|
|
|
|
|
|
|
|
|
If you supply a fixed-version, the bug tracking system will
|
|
|
|
|
|
note that the bug was fixed in that version of the package.
|
|
|
|
|
|
|
|
|
|
|
|
package [ packagename ... ]
|
|
|
|
|
|
Limits the following commands so that they will only apply to
|
|
|
|
|
|
bugs filed against the listed packages. You can list one or
|
|
|
|
|
|
more packages. If you don't list any packages, the following
|
|
|
|
|
|
commands will apply to all bugs. You're encouraged to use this
|
|
|
|
|
|
as a safety feature in case you accidentally use the wrong bug
|
|
|
|
|
|
numbers.
|
|
|
|
|
|
|
|
|
|
|
|
Example usage:
|
|
|
|
|
|
|
|
|
|
|
|
package foo
|
|
|
|
|
|
reassign 123456 bar 1.0-1
|
|
|
|
|
|
|
|
|
|
|
|
package bar
|
|
|
|
|
|
retitle 123456 bar: bar sucks
|
|
|
|
|
|
severity 123456 normal
|
|
|
|
|
|
|
|
|
|
|
|
package
|
|
|
|
|
|
severity 234567 wishlist
|
|
|
|
|
|
|
|
|
|
|
|
owner bugnumber address | !
|
|
|
|
|
|
Sets address to be the "owner" of #bugnumber. The owner of a
|
2007-09-23 08:04:50 +00:00
|
|
|
|
bug claims responsibility for fixing it. This is useful to
|
|
|
|
|
|
share out work in cases where a package has a team of
|
|
|
|
|
|
maintainers.
|
2007-09-23 08:04:20 +00:00
|
|
|
|
|
|
|
|
|
|
If you wish to become the owner of the bug yourself, you can
|
|
|
|
|
|
use the ! shorthand or specify your own email address.
|
|
|
|
|
|
|
|
|
|
|
|
noowner bugnumber
|
|
|
|
|
|
Forgets any idea that the bug has an owner other than the usual
|
|
|
|
|
|
maintainer. If the bug had no owner recorded then this will do
|
|
|
|
|
|
nothing.
|
|
|
|
|
|
|
|
|
|
|
|
#...
|
|
|
|
|
|
One-line comment. The # must be at the start of the line. The
|
|
|
|
|
|
text of comments will be included in the acknowledgement sent
|
|
|
|
|
|
to the sender and to affected maintainers, so you can use this
|
|
|
|
|
|
to document the reasons for your commands.
|
|
|
|
|
|
|
|
|
|
|
|
quit
|
|
|
|
|
|
stop
|
2007-09-23 08:04:50 +00:00
|
|
|
|
thank
|
|
|
|
|
|
thanks
|
|
|
|
|
|
thankyou
|
|
|
|
|
|
thank you
|
|
|
|
|
|
--
|
|
|
|
|
|
On a line by itself, in any case, possibly followed by
|
|
|
|
|
|
whitespace, tells the control server to stop processing the
|
|
|
|
|
|
message; the remainder of the message can include explanations,
|
|
|
|
|
|
signatures or anything else, none of it will be detected by the
|
|
|
|
|
|
control server.
|
2007-09-23 08:04:20 +00:00
|
|
|
|
_________________________________________________________________
|
|
|
|
|
|
|
|
|
|
|
|
Debian BTS administrators <owner@bugs.debian.org>
|
|
|
|
|
|
|
|
|
|
|
|
Debian bug tracking system
|
|
|
|
|
|
Copyright <20> 1999 Darren O. Benham, 1997, 2003 nCipher Corporation Ltd,
|
|
|
|
|
|
1994-1997 Ian Jackson.
|
|
|
|
|
|
_________________________________________________________________
|
|
|
|
|
|
|
