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.
||17 years ago|
|debian||17 years ago|
|README.developers||18 years ago|
|TODO||18 years ago|
|build-stamp||18 years ago|
|checkbuildd.py||18 years ago|
|checkversions.py||18 years ago|
|debianbts.py||18 years ago|
|handle_bugscript||18 years ago|
|hiermatch.py||18 years ago|
|install-stamp||18 years ago|
|presubj||18 years ago|
|querybts||18 years ago|
|querybts.1||18 years ago|
|rbtempfile.py||18 years ago|
|reportbug||17 years ago|
|reportbug.1||18 years ago|
|reportbug.conf||17 years ago|
|reportbug.el||18 years ago|
|reportbug.fr.1||17 years ago|
|reportbug.py||18 years ago|
|reportbug_exceptions.py||18 years ago|
|reportbug_submit.py||17 years ago|
|reportbug_ui_gnome.py||18 years ago|
|reportbug_ui_newt.py||18 years ago|
|reportbug_ui_text.py||18 years ago|
|script||18 years ago|
|test_hiermatch.py||18 years ago|
|urllib2.py||18 years ago|
|urlutils.py||18 years ago|
This file is lifted, almost verbatim, from "bug".
BUG'S Features for Developers
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
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
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
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.
The package maintainer can control to which packages are the bug reports
submitted to (i.e. the Package: field of the 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:
Note that bug will not check if the $new-package exists as a valid package.
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.)
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
report-with: foo libfoo foo-common foo-data
Package information will be added to the bug report for each extra package
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++.