** How do I report a bug?
Use M-x report-emacs-bug, or send mail to bug-gnu-emacs@gnu.org.
-If you want to Cc someone, use an "X-Debbugs-CC" header instead.
+If you want to Cc someone, use an "X-Debbugs-CC" header (or
+pseudo-header, see below) instead.
** How do I comment on a bug?
Reply to a mail on the bug-gnu-emacs list in the normal way.
ii) Optionally, you can set some database parameters when you first
report a bug (see "Setting bug parameters" below).
-iii) If you want to CC: someone, use X-Debbugs-CC: (this is important;
-see below).
+iii) If you want to CC: someone, use X-Debbugs-CC: (note this only
+applies to _new_ reports, not followups).
Once your report is filed and assigned a number, it is sent out to the
bug mailing list. In some cases, it may be appropriate to just file a
** How do I reply to an existing bug report?
Reply to 123@debbugs.gnu.org, replacing 123 with the number
of the bug you are interested in. NB this only sends mail to the
-bug-list, it does NOT (?) send a CC to the original bug submitter.
+bug-list, it does NOT send a CC to the original bug submitter.
So you need to explicitly CC him/her (and anyone else you like).
+(This works the same way as all the Emacs mailing lists. We generally
+don't assume anyone who posts to a list is subscribed to it, so we
+cc everyone on replies.)
(Many people think the submitter SHOULD be automatically subscribed
to subsequent discussion, but this does not seem to be implemented.
-See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=37078)
-See also http://debbugs.gnu.org/5439
+See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=37078
+See also http://debbugs.gnu.org/5439 )
Do NOT send a separate copy to the bug list address, since this may
generate a new report. The only time to send mail to the bug list
"Resent-To" header. For a long time Rmail erroneously included such
headers in replies. If you correspond with an Rmail user on a bug,
these addresses may end up in the Cc. Mailing to them does nothing
-but create duplicates and errors. (It is possible you might want to
-have a dialog with the owner address, outside of normal bug
-reporting.)
+but create duplicates and errors. (It is possible, but unlikely, that
+you might want to have a dialog with the owner address, outside of
+normal bug reporting.)
-** When reporting a bug, to send a Cc to another address
+** When reporting a new bug, to send a Cc to another address
(e.g. bug-cc-mode@gnu.org), do NOT just use a Cc: header.
Instead, use "X-Debbugs-CC:". This ensures the Cc address will get a
mail with the bug report number in. If you do not do this, each reply
-in the subsequent discussion will end up creating a new bug.
-This is annoying.
+in the subsequent discussion might end up creating a new bug.
+This is annoying. (So annoying that a form of message-id tracking has
+been implemented to hopefully stop this happening, but it is still
+better to use X-Debbugs-CC.)
-(So annoying that a form of message-id tracking has been implemented
-to hopefully stop this happening, but it is still better to use X-Debbugs-CC.)
+Like any X-Debbugs- header, this one can also be specified in the
+pseudo-header (see below), if your mail client does not let you add
+"X-" headers.
If a new report contains X-Debbugs-CC in the input, this is
-converted to a real Cc header in the output. (See Bug#1720).
+converted to a real Cc header in the output. (See Bug#1780,5384)
It is also merged into the Resent-CC header (see below).
** How does Debbugs send out mails?
The "maintainer email address" is "bug-gnu-emacs@gnu.org" in most cases.
-** To not get acknowledgement mail from the tracker,
+** To not get acknowledgment mail from the tracker,
add an "X-Debbugs-No-Ack:" header (with any value). If you use Gnus,
you can add an element to gnus-posting-styles to do this automatically, eg:
** To record a bug in the tracker without sending mail to the bug list.
This can be useful to make a note of something discussed on
-emacs-devel that needs fixing. In other words, this can be the
-equivalent of adding something to FOR-RELEASE.
+emacs-devel that needs fixing.
To: quiet@debbugs.gnu.org
[headers end]
Version: 23.0.60
Severity: minor
-This can also include tags. Some things (e.g. submitter) don't seem to
-work here.
+This can also include tags, or any X-Debbugs- setting.
+Some things (e.g. submitter) don't seem to work here.
Otherwise, send mail to the control server, control@debbugs.gnu.org.
At the start of the message body, supply the desired commands, one per
1) Anyone can define any valid usertag they like. In contrast, only a
limited, predefined set of normal tags are available (see above).
-2) A usertag is associated with a specific email address.
+2) A usertag is associated with a specific user. This is normally
+an email address (with an "@" sign and least 4 characters after the "@"),
+but on debbugs.gnu.org, the definition is less strict - anything with
+5 or more alphanumeric characters will work. For personal tags,
+using an email address is still recommended. Please only use the
+"emacs" user, or other short users, for "official" tags.
-You set usertags in the same way as tags, by talking to the control
-server. One difference is that you can also specify the associated
-email address. If you don't explicitly specify an address, then it
-will use the one from which you send the control message. The address
-must have the form of an email address (with an "@" sign and least 4
-characters after the "@").
+You set usertags in the same way as tags, by talking to the control server.
+One difference is that you can also specify the associated user.
+If you don't explicitly specify a user, then it will use the email
+address from which you send the control message.
*** Setting usertags
a) In a control message:
-user bug-gnu-emacs@gnu.org
+user emacs # or email@example.com
usertags 1234 any-tag-you-like
This will add a usertag "any-tag-you-like" to bug 1234. The tag will
-be associated with the address "bug-gnu-emacs@gnu.org". If you omit
-the first line, the tag will be associated with your email address.
+be associated with the user "emacs". If you omit the first line,
+the tag will be associated with your email address.
The syntax of the usertags command is the same as that of tags (eg wrt
the optional [=+-] argument).
b) In an initial submission, in the pseudo-header:
-User: bug-gnu-emacs@gnu.org
+User: emacs
Usertags: a-new-tag
Again, the "User" is optional.
**** To find all bugs usertagged by a given email address:
-http://debbugs.gnu.org/cgi/pkgreport.cgi?users=bug-gnu-emacs@gnu.org
+http://debbugs.gnu.org/cgi/pkgreport.cgi?users=emacs
(Supposedly, the "users" field can be a comma-separated list of more
than one email address, but it does not seem to work for me.)
This works just like a normal tags search, but with the addition of a
"users" field. Eg:
-http://debbugs.gnu.org/cgi/pkgreport.cgi?users=bug-gnu-emacs@gnu.org;tag=calendar
+http://debbugs.gnu.org/cgi/pkgreport.cgi?users=emacs;tag=calendar
*** To merge bugs:
Eg when bad replies create a bunch of new bugs for the same report.
Bugs must all be in the same state (e.g. same package(s) and severity
--- see `reassign' and `severity' below), but need not have the same
+-- see 'reassign' and 'severity' below), but need not have the same
tags (tags are merged). E.g.:
merge 123 124 125 ...
of merged bugs only affects individual bugs, not all of them.
*** Forcing a merge:
-Like `merge', but bugs need not be in the same state. The packages
-must still match though (see `reassign' below). The first one listed
+Like 'merge', but bugs need not be in the same state. The packages
+must still match though (see 'reassign' below). The first one listed
is the master. E.g.:
forcemerge 123 124 125 ...
*** To set the owner of a bug:
owner 123 A Hacker <none@example.com>
-The shorthand `!' means your own address.
+The shorthand '!' means your own address.
*** To remove the owner of a bug:
noowner 123
Note that reassigning clears the list of found versions, even if the
new packages includes the original one.
-** To remove spam from the tracker, move it to the `spam' pseudo-package:
+** To remove spam from the tracker, move it to the 'spam' pseudo-package:
reassign 123 spam
(Should not be necessary any more, now that the input is moderated.)
"raw" = ?
-** ChangeLog issues
+** Change log issues
*** When you fix a bug, it can be helpful to put the bug number in the
-ChangeLog entry, for example:
+change log entry, for example:
- * foo.el (foofunc): Fix the `foo' case. (Bug#123)
+ * lisp/menu-bar.el (menu-set-font): Doc fix. (Bug#21303)
Then the relevant bug can be found for easy reference. If it's an
-obvious fix (e.g. a typo), there's no need to clutter the log with the
+obvious fix (e.g., a typo), there's no need to clutter the log with the
bug number.
Similarly, when you close a bug, it can be helpful to include the
-relevant ChangeLog entry in the message to the bug tracker, so people
+relevant change log entry in the message to the bug tracker, so people
can see exactly what the fix was.
*** bug-reference-mode
-Activate `bug-reference-mode' in ChangeLogs to get clickable links to
+Activate 'bug-reference-mode' in ChangeLogs to get clickable links to
the bug web-pages.
*** Debian stuff
http://lists.gnu.org/archive/html/emacs-devel/2009-11/msg00440.html
-** Bazaar stuff
-
-*** You can use `bzr commit --fixes debbugs:123' to mark that a commit fixes
-Emacs bug 123. You will first need to add a line to one of your
-configuration files, ~/.bazaar/bazaar.conf or ~/.bazaar/locations.conf:
-
-bugtracker_debbugs_url = http://debbugs.gnu.org/{id}
-
-Here "{id}" is a literal string, a placeholder that will be replaced
-by the bug number you specify after `--fixes debbugs:' in the bzr
-command line (123 in the example above).
-
-In the bazaar.conf file, this setting should go into the [DEFAULT]
-section.
-
-In the locations.conf file, it should go into the branch-specific
-configuration section for the branch where you want this to be in
-effect. For example, if you want this to be in effect for the branch
-located at `/home/projects/emacs/trunk', you need to have this in your
-~/.bazaar/locations.conf file:
-
-[/home/projects/emacs/trunk]
-bugtracker_debbugs_url = http://debbugs.gnu.org/{id}
-
-If you want to use this in all Emacs branches whose common parent is
-`/home/projects/emacs', put the setting in the [/home/projects/emacs]
-section. See "bzr help configuration" for more information about
-the *.conf files, their location and formats. See "bzr help bugs" for
-more information about the bugtracker_debbugs_url setting.
-
-See also log-edit-rewrite-fixes in .dir-locals.el.
-
-Note that all this does is add some metadata to the commit, it doesn't
-actually mark the bug as closed in the tracker. You can see this
-information with `bzr log', and it will show up as a link in a recent
-loggerhead installation, or with some of the graphical frontends to
-`bzr log'.
-
** Gnus-specific voodoo
*** Put point on a bug-number and try: M-x gnus-read-ephemeral-emacs-bug-group
All discarded messages are stored in /var/lib/mailman/spam.
If a non-spam message accidentally gets discarded, just do:
-cat /var/lib/mailman/spam/not-really-spam.msg | /usr/lib/debbugs/receive
+/usr/lib/debbugs/receive < /var/lib/mailman/spam/not-really-spam.msg
chown Debian-debbugs:Debian-debbugs /var/lib/debbugs/spool/incoming/*
... check it works ...
mv /var/lib/mailman/spam/not-really-spam.msg /var/lib/mailman/not-spam/
Also check that the sender was not added to the auto-discard/reject list
in the debbugs-submit Mailman interface.
+If you don't have the actual mail, just the mailman moderation mail
+version of it, you need to extract the original mail, and add the
+following headers:
+
+1) The leading envelope From line.
+2) Message-ID (get it from /var/log/mailman/vette).
+3) X-Debbugs-Envelope-To: xxx
+For a new report, xxx = submit; for a control message, xxx = control;
+for a reply to bug#123, xxx = 123
+
+Then pipe it to receive as above.
+
** Administrivia
The debbugs-submit list should have the administrivia option off,
Then if you do all your testing with 'Package: mytest', the resulting
mails should only go to your email address.
+
+** Adding new tags
+
+Add them to @gTags in /etc/debbugs/config.
+I think you also have to add them to 'tags' and 'tags_single_letter'
+in /usr/share/perl5/Debbugs/Config.pm.
+And update /var/www/Developer.html with a description of what the tag means.
+And the "valid tags" list in /var/www/index.html.
+
+** Backups
+
+The FSF sysadmins handle multi-generational backups of the filesystem
+on debbugs.gnu.org. But if you really want to have your own backup of
+the bug database, you can use rsync (this requires login access to
+debbugs.gnu.org):
+
+ rsync -azvv -e ssh USER@debbugs.gnu.org:/var/lib/debbugs/ DEST
+
+Note that this occupies well over 1G of disk space.