1 NOTES ON THE EMACS BUG TRACKER -*- outline -*-
3 The Emacs Bug Tracker can be found at http://debbugs.gnu.org/
5 For a list of all bugs, see http://debbugs.gnu.org/db/pa/lemacs.html
6 This is a static page, updated once a day. There is also a dynamic
7 list, generated on request, but since there are many bug reports this
8 is slow and not recommended.
10 ** How do I report a bug in Emacs now?
11 The same way as you always did. Send mail to bug-gnu-emacs@gnu.org,
12 or use M-x report-emacs-bug.
14 The only differences are:
16 i) Your report will be assigned a number and generate an automatic reply.
18 ii) Optionally, you can set some database parameters when you first
19 report a bug (see "Setting bug parameters" below).
21 iii) If you want to CC: someone, use X-Debbugs-CC: (this is important;
24 Once your report is filed and assigned a number, it is sent out to the
25 bug mailing list. In some cases, it may be appropriate to just file a
26 bug, without sending out a copy. To do this, send mail to
27 quiet@debbugs.gnu.org.
29 ** How do I reply to an existing bug report?
30 Reply to 123@debbugs.gnu.org, replacing 123 with the number
31 of the bug you are interested in. NB this only sends mail to the
32 bug-list, it does NOT (?) send a CC to the original bug submitter.
33 So you need to explicitly CC him/her (and anyone else you like).
35 (Many people think the submitter SHOULD be automatically subscribed
36 to subsequent discussion, but this does not seem to be implemented.
37 See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=37078)
38 See also http://debbugs.gnu.org/5439
40 Do NOT send a separate copy to the bug list, since this may generate a
41 new report. The only time to send mail to the bug list is to create a
44 Gnus users can add the following to message-dont-reply-to-names;
45 similarly with Rmail and rmail-dont-reply-to-names:
47 "\\(emacs-pretest-bug\\|bug-gnu-emacs\\)@gnu\\.org\\|\
48 \\(submit\\|control\\|owner\\)@debbugs\\.gnu\\.org"
50 The "owner@debbugs.gnu.org" entry is there because it appears in the
51 "Resent-To" header. For a long time Rmail erroneously included such
52 headers in replies. If you correspond with an Rmail user on a bug,
53 these addresses may end up in the Cc. Mailing to them does nothing
54 but create duplicates and errors. (It is possible you might want to
55 have a dialog with the owner address, outside of normal bug
58 ** When reporting a bug, to send a Cc to another address
59 (e.g. bug-cc-mode@gnu.org), do NOT just use a Cc: header.
60 Instead, use "X-Debbugs-CC:". This ensures the Cc address will get a
61 mail with the bug report number in. If you do not do this, each reply
62 in the subsequent discussion will end up creating a new bug. This is
65 If a new report contains X-Debbugs-CC in the input, this is
66 converted to a real Cc header in the output. (See Bug#1720).
67 It is also merged into the Resent-CC header (see below).
69 ** How does Debbugs send out mails?
71 The mails are sent out to the bug list with From: and To: unchanged.
72 Eg if you file a bug with "submit@debbugs.gnu.org", that
73 remains in the To: address. They reach the bug list by being resent.
75 Mails arriving at the bug list have the following Resent-* headers:
77 Resent-From: person who submitted the bug
78 Resent-To: owner@debbugs.gnu.org
79 Resent-CC: maintainer email address, plus any X-Debbugs-CC: entries
81 The "maintainer email address" is "bug-gnu-emacs@gnu.org" in most cases.
83 In a new report, any "bug-gnu-emacs", "emacs-pretest-bug", or
84 "submit@debbugs" address in the original To or Cc is replaced by
85 123@debbugs in the mail that gets sent out to the bug list.
87 ** To not get acknowledgement mail from the tracker,
88 add an "X-Debbugs-No-Ack:" header (with any value). If you use Gnus,
89 you can add an element to gnus-posting-styles to do this automatically, eg:
91 ("gnu-emacs\\(-pretest\\)?-bug"
92 ("X-Debbugs-No-Ack" "yes"))
94 (adjust the regexp according to the name you use for the bug lists)
96 ** To record a bug in the tracker without sending mail to the bug list.
97 This can be useful to make a note of something discussed on
98 emacs-devel that needs fixing. In other words, this can be the
99 equivalent of adding something to FOR-RELEASE.
101 To: quiet@debbugs.gnu.org
107 Remember to fix FOO, as discussed on emacs-devel at http://... .
109 ** Not interested in tracker control messages (tags being set, etc)?
110 Discard mails matching:
112 ^X-Emacs-PR-Message: transcript
114 When you close a bug, you get a message matching:
116 ^X-Emacs-PR-Message: closed
118 ** How to avoid multiple copies of mails.
119 If you reply to reports in the normal way, this should work fine.
120 Basically, reply only to the numbered bug address (and any individual
121 people's addresses). Do not send mail direct to bug-gnu-emacs or
122 emacs-pretest-bug unless you are reporting a new bug.
124 ** To close bug #123 (for example), send mail
126 To: 123-done@debbugs.gnu.org
128 with a brief explanation in the body as to why the bug was closed.
129 There is no need to cc the address without the "-done" part or the
130 submitter; they get copies anyway so this will just result in more
133 ** Setting bug parameters.
134 There are two ways to set the parameters of bugs in the database
135 (tags, severity level, etc). When you report a new bug, you can
136 provide a "pseudo-header" at the start of the report, eg:
142 Optionally, add a sub-package, eg Package: emacs,calendar.
143 This can include tags. Some things (e.g. submitter) don't seem to
146 Otherwise, send mail to the control server, control@debbugs.gnu.org.
147 At the start of the message body, supply the desired commands, one per
150 command bug-number [arguments]
152 quit|stop|thank|thanks|thankyou|thank you
154 The control server ignores anything after the last line above. So you
155 can place control commands at the beginning of a reply to a bug
156 report, and Bcc: the control server (note the commands have no effect
157 if you just send them to the bug-report number). Bcc: is better than Cc:
158 in case people use Reply-to-All in response.
160 Some useful control commands:
162 *** To reopen a closed bug:
165 *** Bugs can be tagged in various ways (eg wontfix, patch, etc).
166 The available tags are:
167 patch wontfix moreinfo unreproducible fixed notabug
168 See http://debbugs.gnu.org/Developer#tags
169 The list of tags can be prefixed with +, - or =, meaning to add (the
170 default), remove, or reset the tags. E.g.:
176 http://debbugs.gnu.org/...
178 123 # given bug number
179 123;mbox=yes # mbox version of given bug
180 package # bugs in given package (don't use "emacs" - too many bugs!)
181 from:submitter@email.address
182 severity:severity # all bugs of given severity
183 tag:tag # all bugs with given tag
187 See <http://wiki.debian.org/bugs.debian.org/usertags>
189 "Usertags" are very similar to tags: a set of labels that can be added
190 to a bug. There are two differences between normal tags and user
193 1) Anyone can define any valid usertag they like. In contrast, only a
194 limited, predefined set of normal tags are available (see above).
196 2) A usertag is associated with a specific email address.
198 You set usertags in the same way as tags, by talking to the control
199 server. One difference is that you can also specify the associated
200 email address. If you don't explicitly specify an address, then it
201 will use the one from which you send the control message. The address
202 must have the form of an email address (with an "@" sign and least 4
203 characters after the "@").
207 a) In a control message:
209 user bug-gnu-emacs@gnu.org
210 usertags 1234 any-tag-you-like
212 This will add a usertag "any-tag-you-like" to bug 1234. The tag will
213 be associated with the address "bug-gnu-emacs@gnu.org". If you omit
214 the first line, the tag will be associated with your email address.
216 The syntax of the usertags command is the same as that of tags (eg wrt
217 the optional [=+-] argument).
219 b) In an initial submission, in the pseudo-header:
221 User: bug-gnu-emacs@gnu.org
224 Again, the "User" is optional.
226 *** Searching by usertags
228 The search interface is not as advanced as for normal tags. You need
229 to construct the relevant url yourself rather than just typing in a
230 search box. The only piece you really need to add is the "users"
231 portion, the rest has the same syntax as normal.
233 **** To find all bugs usertagged by a given email address:
235 http://debbugs.gnu.org/cgi/pkgreport.cgi?users=bug-gnu-emacs@gnu.org
237 (Supposedly, the "users" field can be a comma-separated list of more
238 than one email address, but it does not seem to work for me.)
240 **** To find bugs tagged with a specific usertag:
242 This works just like a normal tags search, but with the addition of a
245 http://debbugs.gnu.org/cgi/pkgreport.cgi?users=bug-gnu-emacs@gnu.org;tag=calendar
248 Eg when bad replies create a bunch of new bugs for the same report.
249 Bugs must all be in the same state (e.g. same package(s) and severity
250 -- see `reassign' and `severity' below), but need not have the same
251 tags (tags are merged). E.g.:
253 merge 123 124 125 ...
255 Note that merging does not affect titles. In particular, a "retitle"
256 of merged bugs only affects individual bugs, not all of them.
259 Like `merge', but bugs need not be in the same state. The packages
260 must still match though (see `reassign' below). The first one listed
263 forcemerge 123 124 125 ...
265 Note: you cannot merge with an archived bug - you must unarchive it first.
268 To disconnect a bug from all bugs it is merged with:
272 This command accepts only one bug number.
275 Useful when one report refers to more than one bug.
277 clone 123 -1 [-2 ...]
278 retitle -1 second bug
281 The negative numbers provide a way to refer to the cloned bugs (which
282 will be assigned proper numbers).
284 NB you cannot clone a merged bug. You'd think that trying to do so
285 would just give you an unmerged copy of the specified bug number, but no:
287 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=474742
289 You must unmerge, clone, then re-merge.
292 severity 123 critical|grave|serious|important|normal|minor|wishlist
294 See http://debbugs.gnu.org/Developer#severities for the meanings.
296 *** To set the owner of a bug:
297 owner 123 A Hacker <none@example.com>
299 The shorthand `!' means your own address.
301 *** To remove the owner of a bug:
304 *** To mark a bug as fixed in a particular version:
307 *** To remove a "fixed" mark:
310 *** To assign or reassign a bug to a package or list of packages:
311 reassign 1234 emacs,cc-mode
313 ** To remove spam from the tracker, move it to the `spam' pseudo-package:
316 ** To change the title of a bug:
317 retitle 123 Some New Title
319 ** To change the submitter address:
320 submitter 123 none@example.com
322 Note that it does not seem to work to specify "Submitter:" in the
323 pseudo-header when first reporting a bug.
325 ** How does archiving work?
326 You can still send mail to a bug after it is closed. After 28 days with
327 no activity, the bug is archived, at which point no more changes can
328 be made. If you try to send mail to the bug after that (or merge with
329 it), it will be rejected. To make any changes, you must unarchive it first:
333 The bug will be re-archived after the next 28 day period of no activity.
335 ** The web-page with the list of bugs is slow to load
337 It's a function of the number of displayed bugs. You can speed things
338 up by only looking at the newest 100 bugs:
339 http://debbugs.gnu.org/cgi-bin/pkgreport.cgi?newest=100;package=emacs
341 Or use the static index:
342 http://debbugs.gnu.org/db/ix/full.html
346 *** When you fix a bug, it can be helpful to put the bug number in the
347 ChangeLog entry, for example:
349 * foo.el (foofunc): Fix the `foo' case. (Bug#123)
351 Then the relevant bug can be found for easy reference. If it's an
352 obvious fix (e.g. a typo), there's no need to clutter the log with the
355 Similarly, when you close a bug, it can be helpful to include the
356 relevant ChangeLog entry in the message to the bug tracker, so people
357 can see exactly what the fix was.
359 *** bug-reference-mode
361 Activate `bug-reference-mode' in ChangeLogs to get clickable links to
366 http://lists.gnu.org/archive/html/emacs-devel/2009-11/msg00440.html
370 *** You can use the commit --fixes emacs:123 to mark that a commit fixes
371 Emacs bug 123. You will first need to add a line to your bazaar.conf
374 bugtracker_emacs_url = http://debbugs.gnu.org/{id}
376 Note that all this does is add some metadata to the commit, it doesn't
377 actually mark the bug as closed in the tracker.
379 ** Gnus-specific voodoo
381 *** Put point on a bug-number and try: M-x gnus-read-ephemeral-emacs-bug-group
383 *** If the above is not available:
384 (add-hook 'gnus-article-mode-hook
386 (setq bug-reference-url-format "http://debbugs.gnu.org/%s")
387 (bug-reference-mode 1)))
389 and you can click on the bug number in the subject header.
394 The following are technical notes on how it works. These are just for
395 reference, you don't need to read these as a user of the system.
397 Getting mail from the Emacs bug list into the tracker requires the
398 assistance of sysadmin at gnu.org. The test tracker set-up was, I
399 think, [gnu.org #359140]:
400 http://lists.gnu.org/archive/html/savannah-hackers/2008-03/msg00074.html
401 http://lists.gnu.org/archive/html/savannah-hackers/2008-04/msg00034.html
403 ** The debbugs.gnu.org setup was handled in [gnu.org #510605].
404 There are two pieces (replace AT with @ in the following):
406 i) fencepost has an /etc/aliases entry:
407 emacs-pretest-bug: submit AT debbugs.gnu.org
412 senders = !Debian-debbugs AT debbugs.gnu.org
413 local_parts = bug-gnu-emacs
415 data = submit AT debbugs.gnu.org
417 This says, for mail arriving at bug-gnu-emacs, only allow it through
418 to the list if it was sent from debbugs.gnu.org. Otherwise, send
419 it to the submit address at the bug-tracker.
421 FIXME There's probably an issue with the mail-news gateway here that
422 still needs to be addressed (bug#936).
424 ** fencepost's /etc/exim4/local_domains configuration needs a line
425 !debbugs.gnu.org adding [gnu.org #503532]. Otherwise people on
426 fencepost can't report bugs, since *.gnu.org addresses are assumed to
427 be handled locally on fencepost, unless otherwise specified.
429 ** All mail arriving at debbugs.gnu.org is first run through SpamAssassin.
430 Obvious spam is rejected, the rest is sent on to the moderated list
431 debbugs-submit. Approved mail is passed on to the tracker.
432 (Note this means that messages may appear out of sequence in the
433 tracker, since mail from whitelisted senders goes straight through.)
435 NOTE: An alternative to this would be to use listhelper AT nongnu.org
436 as a moderator address. Eg the emacs-bug-tracker list uses this.
437 It does basic spam processing on the moderator requests and
438 automatically rejects the obviously bogus ones. Someone still has to
439 accept the good ones though. The advantage of this would not be having
440 to run and tune our own spam filter. See
441 http://savannah.nongnu.org/projects/listhelper
443 An "X-Debbugs-Envelope-To" header is used to keep track of where the
444 mail was actually bound for:
445 http://lists.gnu.org/archive/html/emacs-devel/2009-11/msg01211.html
447 ** Mailing list recipient/sender filters.
448 The following mailman filters are useful to stop messages being
449 needlessly held for moderation:
452 (quiet|control|submit)@(debbugs\.gnu\.org|emacsbugs\.donarmstrong\.com)
453 [0-9]+(-done|-quiet|-subscribe)?@(debbugs\.gnu\.org|emacsbugs\.donarmstrong\.com)
454 (bug-gnu-emacs|emacs-pretest-bug)@gnu\.org
456 *** emacs-bug-tracker
457 sender: bug-gnu-emacs AT gnu.org
458 recipient: emacs-bug-tracker AT debbugs\.gnu\.org
460 The latter is because that is the address that debbugs actually sends to.
461 An /etc/aliases entry redirects it to the real emacs-bug-tracker address.
465 The debbugs-submit list should have the administrivia option off,
466 else it can by mistake filter out requests to subscribe to bugs.
467 But, this feature doesn't work anyway (see bug#5439).
469 ** How to test changes
471 Add an entry to /etc/debbugs/Maintainers like:
473 mytest my.email.address
475 Then if you do all your testing with 'Package: mytest', the resulting
476 mails should only go to your email address.