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
|
Developers' information regarding the bug processing system
Initially, a bug report is submitted by a user as an ordinary mail
message to submit@bugs.debian.org. This will then be given a number,
acknowledged to the user, and forwarded to debian-bugs-dist. If the
submitter included a Package line listing a package with a known
maintainer the maintainer will get a copy too.
The Subject line will have Bug#nnn: added, and the Reply-To will be
set to include both the submitter of the report and
nnn@bugs.debian.org.
_________________________________________________________________
* Closing bug reports
* Followup messages
* Severity levels
* Tags for bug reports
* Recording that you have passed on a bug report
* Changing bug ownership
* Incorrectly listed package maintainers
* Reopening, reassigning and manipulating bugs
* Subscribing to bugs
* More-or-less obsolete subject-scanning feature
* Obsolete X-Debian-PR: quiet feature
_________________________________________________________________
Closing bug reports
Debian bug reports should be closed when the problem is fixed.
Problems in packages can only be considered fixed once a package that
includes the bug fix enters the Debian archive.
Normally, the only people that should close a bug report are the
submitter of the bug and the maintainer(s) of the package against
which the bug is filed. There are exceptions to this rule, for
example, the bugs filed against unknown packages or certain generic
pseudo-packages. When in doubt, don't close bugs, first ask for advice
on the debian-devel mailing list.
Bug reports should be closed by sending email to
nnn-done@bugs.debian.org. The message body needs to contain an
explanation of how the bug was fixed.
With the emails received from the bug tracking system, all you need to
do to close the bug is to make a Reply in your mail reader program and
edit the To field to say nnn-done@bugs.debian.org instead of
nnn@bugs.debian.org (nnn-close is provided as an alias for nnn-done).
Where applicable, please supply a Version line in the pseudo-header of
your message when closing a bug, so that the bug tracking system knows
which releases of the package contain the fix.
The person closing the bug, the person who submitted it and the
debian-bugs-closed mailing list will each get a notification about the
change in status of the report. The submitter and the mailing list
will also receive the contents of the message sent to nnn-done.
Followup messages
The bug tracking system will include the submitter's address and the
bug address (nnn@bugs.debian.org) in the Reply-To header after
forwarding the bug report. Please note that these are two distinct
addresses.
If a developer wishes to reply to a bug report they should simply
reply to the message, respecting the Reply-To header. This will not
close the bug.
The bug tracking system will receive the message at
nnn@bugs.debian.org, pass it on to the package maintainer, file the
reply with the rest of the logs for that bug report and forward it to
debian-bugs-dist.
Sending a message to nnn-submitter@bugs.debian.org will explicitly
email the submitter of the bug and place a copy in the Bug tracking
system. The message will not be sent to package maintainer.
If you wish to send a followup message which is not appropriate for
debian-bugs-dist you can do so by sending it to
nnn-quiet@bugs.debian.org or nnn-maintonly@bugs.debian.org. Mail to
nnn-quiet@bugs.debian.org is filed in the Bug Tracking System but is
not delivered to any individuals or mailing lists. Mail to
nnn-maintonly@bugs.debian.org is filed in the Bug Tracking System and
is delivered only to the maintainer of the package in question.
Do not use the `reply to all recipients' or `followup' feature of your
mailer unless you intend to edit down the recipients substantially. In
particular, see that you don't send followup messages to
submit@bugs.debian.org.
For more information about headers to suppress ACK messages and how to
send carbon copies using the Bug Tracking System, see the instructions
for reporting bugs.
Severity levels
The bug system records a severity level with each bug report. This is
set to normal by default, but can be overridden either by supplying a
Severity line in the pseudo-header when the bug is submitted (see the
instructions for reporting bugs), or by using the severity command
with the control request server.
The severity levels are:
critical
makes unrelated software on the system (or the whole system)
break, or causes serious data loss, or introduces a security
hole on systems where you install the package.
grave
makes the package in question unusable or mostly so, or causes
data loss, or introduces a security hole allowing access to the
accounts of users who use the package.
serious
is a severe violation of Debian policy (roughly, it violates a
"must" or "required" directive), or, in the package
maintainer's opinion, makes the package unsuitable for release.
important
a bug which has a major effect on the usability of a package,
without rendering it completely unusable to everyone.
normal
the default value, applicable to most bugs.
minor
a problem which doesn't affect the package's usefulness, and is
presumably trivial to fix.
wishlist
for any feature request, and also for any bugs that are very
difficult to fix due to major design considerations.
Certain severities are considered release-critical, meaning the bug
will have an impact on releasing the package with the stable release
of Debian. Currently, these are critical, grave and serious. For
complete and canonical rules on what issues merit these severities,
see the list of Release-Critical Issues for Etch.
Tags for bug reports
Each bug can have zero or more of a set of given tags. These tags are
displayed in the list of bugs when you look at a package's page, and
when you look at the full bug log.
Tags can be set by supplying a Tags line in the pseudo-header when the
bug is submitted (see the instructions for reporting bugs), or by
using the tags command with the control request server. Separate
multiple tags with commas, spaces, or both.
The current bug tags are:
patch
A patch or some other easy procedure for fixing the bug is
included in the bug logs. If there's a patch, but it doesn't
resolve the bug adequately or causes some other problems, this
tag should not be used.
wontfix
This bug won't be fixed. Possibly because this is a choice
between two arbitrary ways of doing things and the maintainer
and submitter prefer different ways of doing things, possibly
because changing the behaviour will cause other, worse,
problems for others, or possibly for other reasons.
moreinfo
This bug can't be addressed until more information is provided
by the submitter. The bug will be closed if the submitter
doesn't provide more information in a reasonable (few months)
timeframe. This is for bugs like "It doesn't work". What
doesn't work?
unreproducible
This bug can't be reproduced on the maintainer's system.
Assistance from third parties is needed in diagnosing the cause
of the problem.
help
The maintainer is requesting help with dealing with this bug.
pending
A solution to this bug has been found and an upload will be
made soon.
fixed
This bug is fixed or worked around (by a non-maintainer upload,
for example), but there's still an issue that needs to be
resolved. This tag replaces the old "fixed" severity.
security
This bug describes a security problem in a package (e.g., bad
permissions allowing access to data that shouldn't be
accessible; buffer overruns allowing people to control a system
in ways they shouldn't be able to; denial of service attacks
that should be fixed, etc). Most security bugs should also be
set at critical or grave severity.
upstream
This bug applies to the upstream part of the package.
confirmed
The maintainer has looked at, understands, and basically agrees
with the bug, but has yet to fix it. (Use of this tag is
optional; it is intended mostly for maintainers who need to
manage large numbers of open bugs.)
fixed-upstream
The bug has been fixed by the upstream maintainer, but not yet
in the package (for whatever reason: perhaps it is too
complicated to backport the change or too minor to be worth
bothering).
fixed-in-experimental
The bug has been fixed in the package of the experimental
distribution, but not yet in the unstable distribution.
d-i
This bug is relevant to the development of debian-installer. It
is expected that this will be used when the bug affects
installer development but is not filed against a package that
forms a direct part of the installer itself.
ipv6
This bug affects support for Internet Protocol version 6.
lfs
This bug affects support for large files (over 2 gigabytes).
l10n
This bug is relevant to the localisation of the package.
potato
This bug particularly applies to the potato release of Debian.
woody
This bug particularly applies to the woody distribution.
sarge
This bug should not be archived until it is fixed in sarge.
sarge-ignore
This release-critical bug is to be ignored for the purposes of
releasing sarge. This tag should only be used by the release
manager; do not set it yourself without explicit authorization
from them.
etch
This bug should not be archived until it is fixed in etch.
etch-ignore
This release-critical bug is to be ignored for the purposes of
releasing etch. This tag should only be used by the release
manager; do not set it yourself without explicit authorization
from them.
sid
This bug should not be archived until it is fixed in sid.
experimental
This bug should not be archived until it is fixed in
experimental.
The meanings of the latter 6 tags have changed recently; the ignore
tags ignore the bug for the purpose of a testing propagation. The
release tags, which used to indicate which bugs affected a specific
release now indicate when a bug can be archived.
Recording that you have passed on a bug report
When a developer forwards a bug report to the developer of the
upstream source package from which the Debian package is derived, they
should note this in the bug tracking system as follows:
Make sure that the To field of your message to the author has only the
author(s) address(es) in it; put the person who reported the bug,
nnn-forwarded@bugs.debian.org and nnn@bugs.debian.org in the CC field.
Ask the author to preserve the CC to nnn-forwarded@bugs.debian.org
when they reply, so that the bug tracking system will file their reply
with the original report. These messages are only filed and are not
sent on; to send a message as normal, send them to nnn@bugs.debian.org
as well.
When the bug tracking system gets a message at nnn-forwarded it will
mark the relevant bug as having been forwarded to the address(es) in
the To field of the message it gets, if the bug is not already marked
as forwarded.
You can also manipulate the `forwarded to' information by sending
messages to control@bugs.debian.org.
Changing bug ownership
In cases where the person responsible for fixing a bug is not the
assigned maintainer for the associated package (for example, when the
package is maintained by a team), it may be useful to record this fact
in the bug tracking system. To help with this, each bug may optionally
have an owner.
The owner can be set by supplying an Owner line in the pseudo-header
when the bug is submitted (see the instructions for reporting bugs),
or by using the owner and noowner commands with the control request
server.
Incorrectly listed package maintainers
If the maintainer of a package is listed incorrectly, this is usually
because the maintainer has changed recently, and the new maintainer
hasn't yet uploaded a new version of the package with a changed
Maintainer control file field. This will be fixed when the package is
uploaded; alternatively, the archive maintainers can override the
maintainer record of a package manually, for example if a rebuild and
reupload of the package is not expected to be needed soon. Contact
override-change@debian.org for changes to the override file.
Reopening, reassigning and manipulating bugs
It is possible to reassign bug reports to other packages, to reopen
erroneously-closed ones, to modify the information saying to where, if
anywhere, a bug report has been forwarded, to change the severities
and titles of reports, to set the ownership of bugs, to merge and
unmerge bug reports, and to record the versions of packages in which
bugs were found and in which they were fixed. This is done by sending
mail to control@bugs.debian.org.
The format of these messages is described in another document
available on the World Wide Web or in the file
bug-maint-mailcontrol.txt. A plain text version can also be obtained
by mailing the word help to the server at the address above.
Subscribing to bugs
The bug tracking system also allows bug submitters, developers and
other interested third parties to subscribe to individual bugs. This
feature can be used by those wishing to keep an eye on a bug, without
having to subscribe to a package through the PTS. All messages that
are received at nnn@debian.org, are sent to subscribers.
Subscribing to a bug can be done by sending an email to
nnn-subscribe@bugs.debian.org. The subject and body of the email are
ignored by the BTS. Once this message is processed, users are sent a
confirmation message that they will need to reply to before they are
sent the messages relating to that bug.
It is also possible to unsubscribe from a bug. Unsubscribing can be
done by sending an email to nnn-unsubscribe@bugs.debian.org. The
subject and body of the email are again ignored by the BTS. Users will
be sent a confirmation message which they must reply to if they wish
to be unsubscribed from the bug.
By default, the address subscribed is the one found in the From
header. If you wish to subscribe another address to a bug, you will
need to encode the address to be subscribed into the subscription
message. This takes the form of:
nnn-subscribe-localpart=example.com@bugs.debian.org. That example
would send localpart@example.com a subscription message for bug nnn.
The @ sign must be encoded by changing it to an = sign. Similarly, an
unsubscription takes the form
nnn-unsubscribe-localpart=example.com@bugs.debian.org. In both cases,
the subject and body of the email will be forwarded to the email
address within the request for confirmation.
More-or-less obsolete subject-scanning feature
Messages that arrive at submit or bugs whose Subject starts Bug#nnn
will be treated as having been sent to nnn@bugs.debian.org. This is
both for backwards compatibility with mail forwarded from the old
addresses, and to catch followup mail sent to submit by mistake (for
example, by using reply to all recipients).
A similar scheme operates for maintonly, done, quiet and forwarded,
which treat mail arriving with a Subject tag as having been sent to
the corresponding nnn-whatever@bugs.debian.org address.
Messages arriving at plain forwarded and done - ie, with no bug report
number in the address - and without a bug number in the Subject will
be filed under `junk' and kept for a few weeks, but otherwise ignored.
Obsolete X-Debian-PR: quiet feature
It used to be possible to prevent the bug tracking system from
forwarding anywhere messages it received at debian-bugs, by putting an
X-Debian-PR: quiet line in the actual mail header.
This header line is now ignored. Instead, send your message to quiet
or nnn-quiet (or maintonly or nnn-maintonly).
_________________________________________________________________
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.
_________________________________________________________________
|
