1
Developers' information regarding the bug processing system
3
Initially, a bug report is submitted by a user as an ordinary mail
4
message to submit@bugs.debian.org. This will then be given a number,
5
acknowledged to the user, and forwarded to debian-bugs-dist. If the
6
submitter included a Package line listing a package with a known
7
maintainer the maintainer will get a copy too.
9
The Subject line will have Bug#nnn: added, and the Reply-To will be
10
set to include both the submitter of the report and
12
_________________________________________________________________
17
* Tags for bug reports
18
* Recording that you have passed on a bug report
19
* Changing bug ownership
20
* Incorrectly listed package maintainers
21
* Reopening, reassigning and manipulating bugs
23
* More-or-less obsolete subject-scanning feature
24
* Obsolete X-Debian-PR: quiet feature
25
_________________________________________________________________
29
Debian bug reports should be closed when the problem is fixed.
30
Problems in packages can only be considered fixed once a package that
31
includes the bug fix enters the Debian archive.
33
Normally, the only people that should close a bug report are the
34
submitter of the bug and the maintainer(s) of the package against
35
which the bug is filed. There are exceptions to this rule, for
36
example, the bugs filed against unknown packages or certain generic
37
pseudo-packages. When in doubt, don't close bugs, first ask for advice
38
on the debian-devel mailing list.
40
Bug reports should be closed by sending email to
41
nnn-done@bugs.debian.org. The message body needs to contain an
42
explanation of how the bug was fixed.
44
With the emails received from the bug tracking system, all you need to
45
do to close the bug is to make a Reply in your mail reader program and
46
edit the To field to say nnn-done@bugs.debian.org instead of
47
nnn@bugs.debian.org (nnn-close is provided as an alias for nnn-done).
49
Where applicable, please supply a Version line in the pseudo-header of
50
your message when closing a bug, so that the bug tracking system knows
51
which releases of the package contain the fix.
53
The person closing the bug, the person who submitted it and the
54
debian-bugs-closed mailing list will each get a notification about the
55
change in status of the report. The submitter and the mailing list
56
will also receive the contents of the message sent to nnn-done.
60
The bug tracking system will include the submitter's address and the
61
bug address (nnn@bugs.debian.org) in the Reply-To header after
62
forwarding the bug report. Please note that these are two distinct
65
If a developer wishes to reply to a bug report they should simply
66
reply to the message, respecting the Reply-To header. This will not
69
The bug tracking system will receive the message at
70
nnn@bugs.debian.org, pass it on to the package maintainer, file the
71
reply with the rest of the logs for that bug report and forward it to
74
Sending a message to nnn-submitter@bugs.debian.org will explicitly
75
email the submitter of the bug and place a copy in the Bug tracking
76
system. The message will not be sent to package maintainer.
78
If you wish to send a followup message which is not appropriate for
79
debian-bugs-dist you can do so by sending it to
80
nnn-quiet@bugs.debian.org or nnn-maintonly@bugs.debian.org. Mail to
81
nnn-quiet@bugs.debian.org is filed in the Bug Tracking System but is
82
not delivered to any individuals or mailing lists. Mail to
83
nnn-maintonly@bugs.debian.org is filed in the Bug Tracking System and
84
is delivered only to the maintainer of the package in question.
86
Do not use the `reply to all recipients' or `followup' feature of your
87
mailer unless you intend to edit down the recipients substantially. In
88
particular, see that you don't send followup messages to
89
submit@bugs.debian.org.
91
For more information about headers to suppress ACK messages and how to
92
send carbon copies using the Bug Tracking System, see the instructions
97
The bug system records a severity level with each bug report. This is
98
set to normal by default, but can be overridden either by supplying a
99
Severity line in the pseudo-header when the bug is submitted (see the
100
instructions for reporting bugs), or by using the severity command
101
with the control request server.
103
The severity levels are:
106
makes unrelated software on the system (or the whole system)
107
break, or causes serious data loss, or introduces a security
108
hole on systems where you install the package.
111
makes the package in question unusable or mostly so, or causes
112
data loss, or introduces a security hole allowing access to the
113
accounts of users who use the package.
116
is a severe violation of Debian policy (roughly, it violates a
117
"must" or "required" directive), or, in the package
118
maintainer's opinion, makes the package unsuitable for release.
121
a bug which has a major effect on the usability of a package,
122
without rendering it completely unusable to everyone.
125
the default value, applicable to most bugs.
128
a problem which doesn't affect the package's usefulness, and is
129
presumably trivial to fix.
132
for any feature request, and also for any bugs that are very
133
difficult to fix due to major design considerations.
135
Certain severities are considered release-critical, meaning the bug
136
will have an impact on releasing the package with the stable release
137
of Debian. Currently, these are critical, grave and serious. For
138
complete and canonical rules on what issues merit these severities,
139
see the list of Release-Critical Issues for Etch.
143
Each bug can have zero or more of a set of given tags. These tags are
144
displayed in the list of bugs when you look at a package's page, and
145
when you look at the full bug log.
147
Tags can be set by supplying a Tags line in the pseudo-header when the
148
bug is submitted (see the instructions for reporting bugs), or by
149
using the tags command with the control request server. Separate
150
multiple tags with commas, spaces, or both.
152
The current bug tags are:
155
A patch or some other easy procedure for fixing the bug is
156
included in the bug logs. If there's a patch, but it doesn't
157
resolve the bug adequately or causes some other problems, this
158
tag should not be used.
161
This bug won't be fixed. Possibly because this is a choice
162
between two arbitrary ways of doing things and the maintainer
163
and submitter prefer different ways of doing things, possibly
164
because changing the behaviour will cause other, worse,
165
problems for others, or possibly for other reasons.
168
This bug can't be addressed until more information is provided
169
by the submitter. The bug will be closed if the submitter
170
doesn't provide more information in a reasonable (few months)
171
timeframe. This is for bugs like "It doesn't work". What
175
This bug can't be reproduced on the maintainer's system.
176
Assistance from third parties is needed in diagnosing the cause
180
The maintainer is requesting help with dealing with this bug.
183
A solution to this bug has been found and an upload will be
187
This bug is fixed or worked around (by a non-maintainer upload,
188
for example), but there's still an issue that needs to be
189
resolved. This tag replaces the old "fixed" severity.
192
This bug describes a security problem in a package (e.g., bad
193
permissions allowing access to data that shouldn't be
194
accessible; buffer overruns allowing people to control a system
195
in ways they shouldn't be able to; denial of service attacks
196
that should be fixed, etc). Most security bugs should also be
197
set at critical or grave severity.
200
This bug applies to the upstream part of the package.
203
The maintainer has looked at, understands, and basically agrees
204
with the bug, but has yet to fix it. (Use of this tag is
205
optional; it is intended mostly for maintainers who need to
206
manage large numbers of open bugs.)
209
The bug has been fixed by the upstream maintainer, but not yet
210
in the package (for whatever reason: perhaps it is too
211
complicated to backport the change or too minor to be worth
214
fixed-in-experimental
215
The bug has been fixed in the package of the experimental
216
distribution, but not yet in the unstable distribution.
219
This bug is relevant to the development of debian-installer. It
220
is expected that this will be used when the bug affects
221
installer development but is not filed against a package that
222
forms a direct part of the installer itself.
225
This bug affects support for Internet Protocol version 6.
228
This bug affects support for large files (over 2 gigabytes).
231
This bug is relevant to the localisation of the package.
234
This bug particularly applies to the potato release of Debian.
237
This bug particularly applies to the woody distribution.
240
This bug should not be archived until it is fixed in sarge.
243
This release-critical bug is to be ignored for the purposes of
244
releasing sarge. This tag should only be used by the release
245
manager; do not set it yourself without explicit authorization
249
This bug should not be archived until it is fixed in etch.
252
This release-critical bug is to be ignored for the purposes of
253
releasing etch. This tag should only be used by the release
254
manager; do not set it yourself without explicit authorization
258
This bug should not be archived until it is fixed in sid.
261
This bug should not be archived until it is fixed in
264
The meanings of the latter 6 tags have changed recently; the ignore
265
tags ignore the bug for the purpose of a testing propagation. The
266
release tags, which used to indicate which bugs affected a specific
267
release now indicate when a bug can be archived.
269
Recording that you have passed on a bug report
271
When a developer forwards a bug report to the developer of the
272
upstream source package from which the Debian package is derived, they
273
should note this in the bug tracking system as follows:
275
Make sure that the To field of your message to the author has only the
276
author(s) address(es) in it; put the person who reported the bug,
277
nnn-forwarded@bugs.debian.org and nnn@bugs.debian.org in the CC field.
279
Ask the author to preserve the CC to nnn-forwarded@bugs.debian.org
280
when they reply, so that the bug tracking system will file their reply
281
with the original report. These messages are only filed and are not
282
sent on; to send a message as normal, send them to nnn@bugs.debian.org
285
When the bug tracking system gets a message at nnn-forwarded it will
286
mark the relevant bug as having been forwarded to the address(es) in
287
the To field of the message it gets, if the bug is not already marked
290
You can also manipulate the `forwarded to' information by sending
291
messages to control@bugs.debian.org.
293
Changing bug ownership
295
In cases where the person responsible for fixing a bug is not the
296
assigned maintainer for the associated package (for example, when the
297
package is maintained by a team), it may be useful to record this fact
298
in the bug tracking system. To help with this, each bug may optionally
301
The owner can be set by supplying an Owner line in the pseudo-header
302
when the bug is submitted (see the instructions for reporting bugs),
303
or by using the owner and noowner commands with the control request
306
Incorrectly listed package maintainers
308
If the maintainer of a package is listed incorrectly, this is usually
309
because the maintainer has changed recently, and the new maintainer
310
hasn't yet uploaded a new version of the package with a changed
311
Maintainer control file field. This will be fixed when the package is
312
uploaded; alternatively, the archive maintainers can override the
313
maintainer record of a package manually, for example if a rebuild and
314
reupload of the package is not expected to be needed soon. Contact
315
override-change@debian.org for changes to the override file.
317
Reopening, reassigning and manipulating bugs
319
It is possible to reassign bug reports to other packages, to reopen
320
erroneously-closed ones, to modify the information saying to where, if
321
anywhere, a bug report has been forwarded, to change the severities
322
and titles of reports, to set the ownership of bugs, to merge and
323
unmerge bug reports, and to record the versions of packages in which
324
bugs were found and in which they were fixed. This is done by sending
325
mail to control@bugs.debian.org.
327
The format of these messages is described in another document
328
available on the World Wide Web or in the file
329
bug-maint-mailcontrol.txt. A plain text version can also be obtained
330
by mailing the word help to the server at the address above.
334
The bug tracking system also allows bug submitters, developers and
335
other interested third parties to subscribe to individual bugs. This
336
feature can be used by those wishing to keep an eye on a bug, without
337
having to subscribe to a package through the PTS. All messages that
338
are received at nnn@debian.org, are sent to subscribers.
340
Subscribing to a bug can be done by sending an email to
341
nnn-subscribe@bugs.debian.org. The subject and body of the email are
342
ignored by the BTS. Once this message is processed, users are sent a
343
confirmation message that they will need to reply to before they are
344
sent the messages relating to that bug.
346
It is also possible to unsubscribe from a bug. Unsubscribing can be
347
done by sending an email to nnn-unsubscribe@bugs.debian.org. The
348
subject and body of the email are again ignored by the BTS. Users will
349
be sent a confirmation message which they must reply to if they wish
350
to be unsubscribed from the bug.
352
By default, the address subscribed is the one found in the From
353
header. If you wish to subscribe another address to a bug, you will
354
need to encode the address to be subscribed into the subscription
355
message. This takes the form of:
356
nnn-subscribe-localpart=example.com@bugs.debian.org. That example
357
would send localpart@example.com a subscription message for bug nnn.
358
The @ sign must be encoded by changing it to an = sign. Similarly, an
359
unsubscription takes the form
360
nnn-unsubscribe-localpart=example.com@bugs.debian.org. In both cases,
361
the subject and body of the email will be forwarded to the email
362
address within the request for confirmation.
364
More-or-less obsolete subject-scanning feature
366
Messages that arrive at submit or bugs whose Subject starts Bug#nnn
367
will be treated as having been sent to nnn@bugs.debian.org. This is
368
both for backwards compatibility with mail forwarded from the old
369
addresses, and to catch followup mail sent to submit by mistake (for
370
example, by using reply to all recipients).
372
A similar scheme operates for maintonly, done, quiet and forwarded,
373
which treat mail arriving with a Subject tag as having been sent to
374
the corresponding nnn-whatever@bugs.debian.org address.
376
Messages arriving at plain forwarded and done - ie, with no bug report
377
number in the address - and without a bug number in the Subject will
378
be filed under `junk' and kept for a few weeks, but otherwise ignored.
380
Obsolete X-Debian-PR: quiet feature
382
It used to be possible to prevent the bug tracking system from
383
forwarding anywhere messages it received at debian-bugs, by putting an
384
X-Debian-PR: quiet line in the actual mail header.
386
This header line is now ignored. Instead, send your message to quiet
387
or nnn-quiet (or maintonly or nnn-maintonly).
388
_________________________________________________________________
390
Debian BTS administrators <owner@bugs.debian.org>
392
Debian bug tracking system
393
Copyright � 1999 Darren O. Benham, 1997, 2003 nCipher Corporation Ltd,
394
1994-1997 Ian Jackson.
395
_________________________________________________________________
added
removed
includes/etch/install/doc/bug-maint-info.txt
