If you want to be a good maintainer, you should periodically check the Debian bug tracking system (BTS)
for your packages. The BTS contains all the open bugs against your packages.
Maintainers interact with the BTS via email addresses at
bugs.debian.org. Documentation on available commands can be found
at http://www.debian.org/Bugs/, or,
if you have installed the doc-debian package, you can look at the
local files /usr/share/doc/debian/bug-*.
Some find it useful to get periodic reports on open bugs. You can add a cron
job such as the following if you want to get a weekly email outlining all the
open bugs against your packages:
# ask for weekly reports of bugs in my packages
0 17 * * fri echo "index maint address" | mail email@example.com
Replace address with you official Debian maintainer address.
10.2 Submitting Bugs
Often as a package maintainer, you find bugs in other packages or else have
bugs reported to your packages which need to be reassigned. The BTS
instructions can tell you how to do this.
We encourage you to file bugs when there are problems. Try to submit the bug
from a normal user account at which you are likely to receive mail. Do not
submit bugs as root.
Make sure the bug is not already filed against a package. Try to do a good job
reporting a bug and redirecting it to the proper location. For extra credit,
you can go through other packages, merging bugs which are reported more than
once, or setting bug severities to `fixed' when they have already been fixed.
Note that when you are neither the bug submitter nor the package maintainer,
you should not actually close the bug (unless you secure permission from the
10.3 Responding to Bugs
Make sure that any discussions you have about bugs are sent both to the
original submitter of the bug, and the bug itself (e.g., firstname.lastname@example.org).
You should never close bugs via the bug server `close' command sent to
you do so, the original submitter will not receive any feedback on why the bug
10.4 When bugs are closed by new uploads
If you fix a bug in your packages, it is your responsibility as the package
maintainer to close the bug when it has been fixed. However, you should not
close the bug until the package which fixes the bug has been accepted into the
Debian archive. Therefore, once you get notification that your updated package
has been installed into the archive, you can and should close the bug in the
If you are using a new version of dpkg-dev and you do your
changelog entry properly, the archive maintenance software will close the bugs
automatically. All you have to do is follow a certain syntax in your
The author prefers the (closes: Bug#XXX) syntax, since
it stands out from the rest of the changelog entries.
If you want to close bugs the old fashioned, manual way, it is usually
sufficient to mail the .changes file to XXXemail@example.com,
where XXX is your bug number.
10.5 Lintian reports
You should periodically get the new lintian from `unstable' and
check over all your packages. Alternatively you can check for your maintainer
email address at the online lintian
report. That report, which is updated automatically, contains
lintian reports against the latest version of the distribution
(usually from 'unstable') using the latest lintian.
10.6 Reporting lots of bugs at once
Reporting a great number of bugs for the same problem on a great number of
different packages — i.e., more than 10 — is a deprecated practice.
Take all possible steps to avoid submitting bulk bugs at all. For instance, if
checking for the problem can be automated, add a new check to
lintian so that an error or warning is emitted.
If you report more than 10 bugs on the same topic at once, it is recommended
that you send a message to firstname.lastname@example.org
describing your intention before submitting the report. This will allow other
developers to verify that the bug is a real problem. In addition, it will help
prevent a situation in which several maintainers start filing the same bug
Note that when sending lots of bugs on the same subject, you should send the
bug report to email@example.com so
that the bug report is not forwarded to the bug distribution mailing list.