1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
|
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
tag
retitle
submitter
affects
summary
found | notfound
fixed | notfixed
reopen
merge | unmerge
forcemerge
clone
thanks
#
forwarded | notforwarded
owner | noowner
block | unblock
archive | unarchive
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
particular version.
notfixed bugnumber version
Remove the record that bug #bugnumber has been fixed in the
given version. version may be a fully qualified version, of the
form sourcepackagename/version.
This command is equivalent to found followed by notfound (the
found removes the fixed at a particular version, and notfound
removes the found) with the exception that the bug is not
reopened if the found version is greater than any existing fixed
version. It is intended for fixing mistakes in the record of
when a bug was fixed; in most cases, you actually want found,
not notfixed.
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. address should
generally be a URI, or possibly an email address. Using a URI
where possible allows tools to query a remote bug tracking
system (such as bugzilla) for a bug's status.
Example usage:
forwarded 12345 http://bugz.illa.foo/cgi/54321
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). Will also
change the titles of all bug reports which this bug is merged
with.
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.
affects bugnumber [ + | - | = ] package [ package ... ]
Indicates that a bug affects another package. In the case where
bugnumber causes breakage in package even though the bug is
actually present in the package to which it is assigned, this
causes the bug to be listed by default in the package list of
package. This should generally be used where the bug is severe
enough to cause multiple reports from users to be assigned to
the wrong package.
summary bugnumber [message number]
Selects a message to use as a summary of a bug. The first
non-pseudoheader paragraph of that message is parsed and set as
the summary of the bug which is displayed on the top of the bug
report page. This is useful in cases where the original report
doesn't correctly describe the problem or the bug has many
messages which make it difficult to identify the actual problem.
If message number is not given, clears the summary. message
number is the message number as listed in the bugreport cgi
script output.
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 settings of the
first bug listed 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 ... ] [ + | - | = 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 tag following, - means to remove each tag following,
and = means to set the following tags to the list provided.
Intervening +, -, or = change the action for the tags following.
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
# remove the moreinfo tag and add a patch tag
tags 123456 - moreinfo + patch
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,
lenny, lenny-ignore, squeeze, squeeze-ignore, sid, and
experimental.
For their meanings please consult the general developers'
documentation for the bug system.
block bugnumber by bug ...
Note that the fix for the first bug is blocked by the other
listed bugs.
unblock bugnumber by bug ...
Note that the fix for the first bug is no longer blocked by the
other listed bugs.
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 bug
claims responsibility for fixing it. This is useful to share out
work in cases where a package has a team of maintainers.
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.
archive bugnumber
Archives a bug that had been archived at some point in the past
but is currently not archived if the bug fulfills the
requirements for archival, ignoring time.
unarchive bugnumber
Unarchives a bug that was previously archived. Unarchival should
generally be coupled with reopen and found/fixed as appropriate.
Bugs that have been unarchived can be archived using archive
assuming the non-time based archival requirements are met. You
should not be using unarchive to make trivial changes to
archived bugs, such as changing the submitter; its primary
purpose is to allow for the reopening of bugs which have been
archived without the intervention of BTS administrators.
#...
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
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.
__________________________________________________________________
Debian BTS administrators <owner@bugs.debian.org>
Debian bug tracking system
Copyright © 1999 Darren O. Benham, 1997, 2003 nCipher Corporation Ltd,
1994-1997 Ian Jackson.
__________________________________________________________________
|
