You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

5.8 KiB

reportbug's Features for Developers

(Adapted from original "bug" documentation.)

Bug allows maintainers to control the bug reporting process by placing
files in special places.

Template Information & Interaction with the user

If /usr/share/bug/$package is executable, then bug executes it and
takes what comes out from the file descriptor 3 and puts it in the bug

The maintainer can then ask questions to the user or run whatever
information gathering script he likes, and echo all the content to fd 3.


read -p 'color? '
echo "Color: $REPLY" >&3
system-information-tool >&3

If /usr/share/bug/$package is a directory, then
/usr/share/bug/$package/script is executed.

While the script is executed, the following shell functions are
available ONLY IF IT IS RUN UNDER /bin/bash::

getkey - asks for a key
yesno <prompt> "yep"|"nop" - ask for a yes/no answer (with i18n)
leaves response as yep or nop
in REPLY. The second argument is
the default.

If the file /usr/share/bug/$package/presubj exists, its content is
shown to the user before asking him for the bug's subject.

Note: It's your responsibility to check if the information included
in the template can put the user in any security risk.

Package redirection

The package maintainer can control to which packages bug reports are
submitted, by setting the Package: field of the bug report. This will
be mainly used to redirect bugs in packages coming from a single
source to where the maintainer likes to have them.

This is done by having this line in /usr/share/bug/$package/control::

Submit-As: $new-package

Note that bug will not check if the $new-package exists as a valid package.

BTS selection

Packages not distributed by Debian can take advantage of this utility too.
They just need to add a "send-to" header to the control file


`bug' will add `submit@' `quiet@' or `maintonly@' to form the address the
bug report mail is send to.

(Note: you probably should use dpkg's support for Origin and Bugs tags
in lieu of this support.)

Nicolás Lichtmaier.-

Related packages

Often programs are distributed across several different packages, for
example an upstream package 'foo' may be packaged in Debian as foo, libfoo,
foo-common and foo-data. In such cases it can be useful to include related
package information in bugreports, to minimise the need for 'moreinfo' requests
to the submitter :) This is done by adding a "report-with" header to the
control file::

report-with: foo libfoo foo-common foo-data

Package information will be added to the bug report for each extra package

You can also request that the status information for other packages
(that are not dependencies or recommendations) be included with the
report using the "package-status" header::

package-status: bar baz

Addendum: Languages other than SH

The script in /usr/share/bug/reportbug/script is an example of a bug
handling script written in Python. You can also write bug handlers in
many other languages that allow direct access to file descriptors,
including Perl and C/C++.

Note that the getkey and yesno functions are only available in scripts
written using /bin/bash as their interpreter; for other shells or
languages, you will need to write your own input parsing functions.

Unit testing framework

The reportbug source package now has a unit testing framework.

The directory ``test/`` contains unit test modules and supporting
files. New unit test modules should be added to this directory and
named ``test_*.py``.

The unit test suite depends on the `python-nose` package being
installed, to make the ``nosetests`` command available. The unit tests
themselves can be written using either the `unittest` or `doctest`
modules in the standard Python library.

The `scaffold` module (from the ``test/`` file) contains
some helper functionality for unit tests, including an extended
`TestCase` class.

``make`` targets for testing and quality checks

The following ``make`` targets are useful for testing and related

* ``make test`` runs the unit test suite, preceded by a timestamp
banner, and reports any test failures or "OK" if all tests pass.

* ``make test-continuous`` starts a loop which clears the screen, runs
``make test``, then waits for any of the tests or source code to
change, and starts the loop again.

This is useful to run in a separate terminal during a development
session, so that whenever a change is made the test suite will be
run automatically. You might want to keep the window hidden while
actually editing files, and only look at it when you've created or
modified a file and want to check its effect on the test run.

This uses the ``inotifywait`` command from the `inotify-tools`
package to wait for `create` and `modify` events.

* ``make coverage`` runs the test suite and collects test coverage
information, then reports the current statement coverage of the test

This requires the `python-coverage` package to be installed. See its
documentation for more about its operation.

* ``make pyflakes`` runs the `pyflakes` static code checker on all
Python files found in the project tree.

This requires the `pyflakes` package to be installed. See its
documentation for more about its operation.

* ``make pylint`` runs the `pylint` code checker on all code modules
and programs.

This requires the `pylint` package to be installed. See its
documentation for more about its operation.

Local Variables:
coding: utf-8
mode: rst
vim: filetype=rst :