If you want to use the system, you need to supply the following information:
If you are using a lists.gnu.org bug mailing list (or if you have control over the routing for your mail domain), the system can optionally "take over" your bug list, such that messages sent to the list that are not replies to existing topics automatically create new bug reports. This is the recommended mode of operation (so-called "exclusive" mode; see technical details below).
In this case, your bug mailing list address effectively becomes an alias for submit AT debbugs.gnu.org. You will need to provide a list of all the aliases (if any) by which your bug mailing list is known (for example: bug-gnu-emacs, emacs-pretest-bug, bug-emacs, bug-gnumacs). This is because we use the recipient address to identify the package if one is not explicitly specified in a pseudo-header. You may find there are more aliases than you think - check /etc/aliases on fencepost!
We define a package for your project (eg emacs) and an associated maintainer email address. Normally this would be your bug mailing list address (eg bug-gnu-emacs AT gnu.org), but if you want to test it out first you could use your personal email address. Then there are two ways you can use it:
The advantage of this mode is that your bug submitters do not need to do anything special. They just report bugs to your bug mailing list in the normal way, and numbered bug reports are automatically created.
You will want to warn people before turning this on, since replies to older discussions will create new bug numbers the first time they are processed by the system.
This mode is achieved by turning on a router rule (a simple alias is not enough) for your mailing list address, so that any mails that do not come from debbugs.gnu.org are first redirected to that machine. This is implemented automatically: there is a config file on debbugs.gnu.org that defines the lists to be routed in this way, and it is periodically checked for new lists.
If debbugs has exclusive control of your bug mailing list, you should find the bug mailing list itself no longer needs any explicit moderation, and you might want to turn that off. The one exception may be if your bug mailing list is gatewayed to a newsgroup. This doesn't seem to work right - mails originally sent to the newsgroup seem to end up straight on the bug mailing list without going through the tracker. There seems to be no prospect of fixing that. You can add a Mailman spam filter that traps anything with a "Newsgroups" header.
Supply a package name and maintainer address (eg your personal address), then test the system out. Tests bugs can be completely deleted from the database once you are done.
I'm not aware of any tools that do this. You could send a summary of each existing bug as a separate mail to quiet@debbugs, in order to get old bugs in the tracker. If your previous bugs take the form of emails, you could just resend each mail involved in a given report to debbugs (with a small amount of care).
A bug report is basically just an mbox file. On the web-page for every bug report are links to download mbox folders containing all the mails involved in every bug report.
Internally, debbugs stores everything as plain text files. The main file is a collection of mail messages, with small "format" sections inbetween each mail. There are a couple of small files that summarize the status. It would be easy to tar up all the files relating to a given package and provide them to the maintainer of that package, if say you wanted to move your bugs somewhere else.
/var/www/Packages.html, and to the following files in
Lists, and (if using exclusive mode)
exim(for a nongnu.org mailing list, use
exim.nongnuinstead). Run the script
If you have any questions, contact help-debbugs AT gnu.org.
Back to index.
Debbugs bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.