In addition to the mailserver on request\@$gEmailDomain
which allows the retrieval of $gBug data and documentation by email,
there is another server on control\@$gEmailDomain
which
also allows $gBug 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.
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.
reassign
bugnumber package
reopen
bugnumber
[ originator-address | =
| !
]
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 $gBug is not closed then reopen won't do anything, not even
change the originator. To change the originator of an open $gBug report,
use the submitter
command; note that this will inform the
original submitter of the change.
submitter
bugnumber
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
notforwarded
bugnumber
retitle
bugnumber new-title
Subject
mail header from the original report).
Unlike most of the other $gBug-manipulation commands when used on one of a set of merged reports this will change the title of only the individual $gBug requested, and not all those with which it is merged.
severity
bugnumber severity
For their meanings please consult the general developers' documentation for the $gBug system.
clone
bugnumber [ new IDs ]
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 ...
Before $gBugs 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 $gBug 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
.
If any of the $gBugs listed in a merge
command is already
merged with another $gBug 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 includes links to the other $gBugs.
Merged reports are all expired simultaneously, and only when all of the reports each separately meet the criteria for expiry.
unmerge
bugnumber
If many $gBug 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 $gBug simply include
several unmerge
commands in your message.
tags
bugnumber [ +
| -
| =
] tag
+
means adding, -
means subtracting, and
=
means ignoring the current tags and setting them afresh.
The default action is adding.
Available tags currently include patch
, wontfix
,
moreinfo
, unreproducible
, help
,
pending
, fixed
, security
,
upstream
, potato
, woody
,
sarge
,
sid
and experimental
.
For their meanings please consult the general developers' documentation for the $gBug system.
close
bugnumber
A notification is sent to the user who reported the $gBug, but (in
contrast to mailing bugnumber-done@$gEmailDomain
) the
text of the mail which caused the $gBug 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 $gBug knows why it is being closed.
The use of this command is therefore deprecated.
package
[ packagename ... ]
Example usage:
package foo reassign 123456 bar package bar retitle 123456 bar: bar sucks severity 123456 normal package severity 234567 wishlist
owner
bugnumber address | !
If you wish to become the owner of the $gBug yourself, you can use the
!
shorthand or specify your own email address.
noowner
bugnumber
quit
stop
thank
...
--
...
#
...
#
must be at the start of the line.
Other pages: