1
Introduction to the bug control and manipulation mailserver
3
In addition to the mailserver on request@bugs.debian.org which allows
4
the retrieval of bug data and documentation by email, there is another
5
server on control@bugs.debian.org which also allows bug reports to be
6
manipulated in various ways.
8
The control server works just like the request server, except that it
9
has some additional commands; in fact, it's the same program. The two
10
addresses are only separated to avoid users making mistakes and
11
causing problems while merely trying to request information.
13
Since the commands specific to the control server actually change the
14
status of a bug, a notification about processing the commands is sent
15
to the maintainer of the package(s) the changed bugs are assigned to.
16
Additionally the mail to the server and the resulting changes are
17
logged in the bug report and thereby available in the WWW pages.
19
Please see the introduction to the request server available on the
20
World Wide Web, in the file bug-log-mailserver.txt, or by sending help
21
to either mailserver, for details of the basics of operating the
22
mailservers and the common commands available when mailing either
25
The reference card for the mailservers is available via the WWW, in
26
bug-mailserver-refcard.txt or by email using the refcard command.
28
Commands available at the control mailserver
30
reassign bugnumber package [ version ]
31
Records that bug #bugnumber is a bug in package. This can be
32
used to set the package if the user forgot the pseudo-header,
33
or to change an earlier assignment. No notifications are sent
34
to anyone (other than the usual information in the processing
37
If you supply a version, the bug tracking system will note that
38
the bug affects that version of the newly-assigned package.
40
reopen bugnumber [ originator-address | = | ! ]
41
Reopens #bugnumber if it is closed.
43
By default, or if you specify =, the original submitter is
44
still as the originator of the report, so that they will get
45
the ack when it is closed again.
47
If you supply an originator-address the originator will be set
48
to the address you supply. If you wish to become the new
49
originator of the reopened report you can use the ! shorthand
50
or specify your own email address.
52
It is usually a good idea to tell the person who is about to be
53
recorded as the originator that you're reopening the report, so
54
that they will know to expect the ack which they'll get when it
57
If the bug is not closed then reopen won't do anything, not
58
even change the originator. To change the originator of an open
59
bug report, use the submitter command; note that this will
60
inform the original submitter of the change.
62
If the bug was recorded as being closed in a particular version
63
of a package but recurred in a later version, it is better to
64
use the found command instead.
66
found bugnumber [ version ]
67
Record that #bugnumber has been encountered in the given
68
version of the package to which it is assigned.
70
The bug tracking system uses this information, in conjunction
71
with fixed versions recorded when closing bugs, to display
72
lists of bugs open in various versions of each package. It
73
considers a bug to be open when it has no fixed version, or
74
when it has been found more recently than it has been fixed.
76
If no version is given, then the list of fixed versions for the
77
bug is cleared. This is identical to the behaviour of reopen.
79
This command will only cause a bug to be marked as not done if
80
no version is specified, or if the version being marked found
81
is equal to the version which was last marked fixed. (If you
82
are certain that you want the bug marked as not done, use
83
reopen in conjunction with found.)
85
This command was introduced in preference to reopen because it
86
was difficult to add a version to that command's syntax without
89
notfound bugnumber version
90
Remove the record that #bugnumber was encountered in the given
91
version of the package to which it is assigned.
93
This differs from closing the bug at that version in that the
94
bug is not listed as fixed in that version either; no
95
information about that version will be known. It is intended
96
for fixing mistakes in the record of when a bug was found.
98
fixed bugnumber version
99
Indicate that bug #bugnumber was fixed in the given version of
100
the package to which it is assigned.
102
This does not cause the bug to be marked as closed, it merely
103
adds another version in which the bug was fixed. Use the
104
bugnumber-done address to close a bug and mark it fixed in a
107
notfixed bugnumber version
108
Remove the record that bug #bugnumber has been fixed in the
111
This command is equivalent to found followed by notfound (the
112
found removes the fixed at a particular version, and notfound
115
submitter bugnumber originator-address | !
116
Changes the originator of #bugnumber to originator-address.
118
If you wish to become the new originator of the report you can
119
use the ! shorthand or specify your own email address.
121
While the reopen command changes the originator of other bugs
122
merged with the one being reopened, submitter does not affect
125
forwarded bugnumber address
126
Notes that bugnumber has been forwarded to the upstream
127
maintainer at address. This does not actually forward the
128
report. This can be used to change an existing incorrect
129
forwarded-to address, or to record a new one for a bug that
130
wasn't previously noted as having been forwarded.
132
notforwarded bugnumber
133
Forgets any idea that bugnumber has been forwarded to any
134
upstream maintainer. If the bug was not recorded as having been
135
forwarded then this will do nothing.
137
retitle bugnumber new-title
138
Changes the title of a bug report to that specified (the
139
default is the Subject mail header from the original report).
141
Unlike most of the other bug-manipulation commands when used on
142
one of a set of merged reports this will change the title of
143
only the individual bug requested, and not all those with which
146
severity bugnumber severity
147
Set the severity level for bug report #bugnumber to severity.
148
No notification is sent to the user who reported the bug.
150
Severities are critical, grave, serious, important, normal,
153
For their meanings please consult the general developers'
154
documentation for the bug system.
156
clone bugnumber NewID [ new IDs ... ]
157
The clone control command allows you to duplicate a bug report.
158
It is useful in the case where a single report actually
159
indicates that multiple distinct bugs have occurred. "New IDs"
160
are negative numbers, separated by spaces, which may be used in
161
subsequent control commands to refer to the newly duplicated
162
bugs. A new report is generated for each new ID.
168
retitle -1 foo: foo sucks
170
retitle -2 bar: bar sucks when used with foo
174
retitle -3 foo: foo sucks
177
merge bugnumber bugnumber ...
178
Merges two or more bug reports. When reports are merged
179
opening, closing, marking or unmarking as forwarded and
180
reassigning any of the bugs to a new package will have an
181
identical effect on all of the merged reports.
183
Before bugs can be merged they must be in exactly the same
184
state: either all open or all closed, with the same
185
forwarded-to upstream author address or all not marked as
186
forwarded, all assigned to the same package or package(s) (an
187
exact string comparison is done on the package to which the bug
188
is assigned), and all of the same severity. If they don't start
189
out in the same state you should use reassign, reopen and so
190
forth to make sure that they are before using merge. Titles are
191
not required to match, and will not be affected by the merge.
192
Tags are not required to match, either, they will be joined.
194
If any of the bugs listed in a merge command is already merged
195
with another bug then all the reports merged with any of the
196
ones listed will all be merged together. Merger is like
197
equality: it is reflexive, transitive and symmetric.
199
Merging reports causes a note to appear on each report's logs;
200
on the WWW pages this is includes links to the other bugs.
202
Merged reports are all expired simultaneously, and only when
203
all of the reports each separately meet the criteria for
206
forcemerge bugnumber bugnumber ...
207
Forcibly merges two or more bug reports. The first bug listed
208
is the master bug, and its settings (the settings which must be
209
equal in a normal merge) are assigned to the bugs listed next.
210
To avoid typos erroneously merging bugs, bugs must be in the
211
same package. See the text above for a description of what
214
Note that this makes it possible to close bugs by merging; you
215
are responsible for notifying submitters with an appropriate
216
close message if you do this.
219
Disconnects a bug report from any other reports with which it
220
may have been merged. If the report listed is merged with
221
several others then they are all left merged with each other;
222
only their associations with the bug explicitly named are
225
If many bug reports are merged and you wish to split them into
226
two separate groups of merged reports you must unmerge each
227
report in one of the new groups separately and then merge them
228
into the required new group.
230
You can only unmerge one report with each unmerge command; if
231
you want to disconnect more than one bug simply include several
232
unmerge commands in your message.
234
tags bugnumber [ + | - | = ] tag [ tag ... ]
235
Sets tags for the bug report #bugnumber. No notification is
236
sent to the user who reported the bug. Setting the action to +
237
means to add each given tag, - means to remove each given tag,
238
and = means to ignore the current tags and set them afresh to
239
the list provided. The default action is adding.
243
# same as 'tags 123456 + patch'
246
# same as 'tags 123456 + help security'
247
tags 123456 help security
249
# add 'fixed' and 'pending' tags
250
tags 123456 + fixed pending
252
# remove 'unreproducible' tag
253
tags 123456 - unreproducible
255
# set tags to exactly 'moreinfo' and 'unreproducible'
256
tags 123456 = moreinfo unreproducible
258
Available tags currently include patch, wontfix, moreinfo,
259
unreproducible, help, pending, fixed, fixed-in-experimental,
260
fixed-upstream, security, upstream, confirmed, d-i, ipv6, lfs,
261
l10n, potato, woody, sarge, sarge-ignore, etch, etch-ignore,
262
sid, and experimental.
264
For their meanings please consult the general developers'
265
documentation for the bug system.
267
block bugnumber by bug ...
268
Note that the fix for the first bug is blocked by the other
271
unblock bugnumber by bug ...
272
Note that the fix for the first bug is no longer blocked by the
275
close bugnumber [ fixed-version ] (deprecated)
276
Close bug report #bugnumber.
278
A notification is sent to the user who reported the bug, but
279
(in contrast to mailing bugnumber-done@bugs.debian.org) the
280
text of the mail which caused the bug to be closed is not
281
included in that notification. The maintainer who closes a
282
report needs to ensure, probably by sending a separate message,
283
that the user who reported the bug knows why it is being
284
closed. The use of this command is therefore deprecated. See
285
the developer's information about how to close a bug properly.
287
If you supply a fixed-version, the bug tracking system will
288
note that the bug was fixed in that version of the package.
290
package [ packagename ... ]
291
Limits the following commands so that they will only apply to
292
bugs filed against the listed packages. You can list one or
293
more packages. If you don't list any packages, the following
294
commands will apply to all bugs. You're encouraged to use this
295
as a safety feature in case you accidentally use the wrong bug
301
reassign 123456 bar 1.0-1
304
retitle 123456 bar: bar sucks
305
severity 123456 normal
308
severity 234567 wishlist
310
owner bugnumber address | !
311
Sets address to be the "owner" of #bugnumber. The owner of a
312
bug claims responsibility for fixing it. This is useful to
313
share out work in cases where a package has a team of
316
If you wish to become the owner of the bug yourself, you can
317
use the ! shorthand or specify your own email address.
320
Forgets any idea that the bug has an owner other than the usual
321
maintainer. If the bug had no owner recorded then this will do
325
One-line comment. The # must be at the start of the line. The
326
text of comments will be included in the acknowledgement sent
327
to the sender and to affected maintainers, so you can use this
328
to document the reasons for your commands.
337
On a line by itself, in any case, possibly followed by
338
whitespace, tells the control server to stop processing the
339
message; the remainder of the message can include explanations,
340
signatures or anything else, none of it will be detected by the
342
_________________________________________________________________
344
Debian BTS administrators <owner@bugs.debian.org>
346
Debian bug tracking system
347
Copyright � 1999 Darren O. Benham, 1997, 2003 nCipher Corporation Ltd,
348
1994-1997 Ian Jackson.
349
_________________________________________________________________
added
removed
includes/sid/install/doc/bug-maint-mailcontrol.txt
