Report Information

The options which show up here vary according to which of the drop-down options you select. Sometimes it is much more helpful to add information to an existing report than to start a new one. (And sometimes you realise you forgot something in one of your earlier reports, and you want to add it.) You can search the bug trackers for GNOME, KDE, Debian or Helix Code to find a relevant bug report and note down the number.

If you select Add more information to existing report then you will be prompted for the bug number of the existing report.

If you select Create a new bug report then you will be prompted for the package number, the package version, the bug severity and the class of bug:

Bug tracking system

bug-buddy can send reports to several different places. A drop-down list is available here. Currently you can report bugs to the bug-trackers of KDE, GNOME, Debian GNU/Linux, Helix Code, and to independent projects if they use a bug-tracking system that bug-buddy understands.

Package

You can search through the drop-down list for the correct package to assign this bug to. If you know the exact filename of the program you ran, and you use rpms, you can use the command rpm -qf /full/path/to/file to verify which package it came from. If you use Debian, you can use the command dpkg -S /full/path/to/file. To find out the full pathname to, say, gnome-terminal, or kfloppy, you can use the command which: which gnome-terminal or which kfloppy.

If you are still not sure which package to assign a bug to, searching the bug-trackers on the web by keyword to find out where other people have assigned it in the past can be very helpful.

Because there are so many possible packages, the drop-down list is split alphabetically. Clicking on a package beginning with 'a', for example, will give you a further selection of several other apps beginning with 'a'. So you will need to double-click on a package and then look at the sub-categories to find some packages.

If you do not select a package, it will be left as 'general'. This will get through to the bug-tracking system, but someone there will have to manually assign it a package, which slows its progress down.

Caution

If you do not put a package name here, many bug-trackers send back automatic "Please assign a package next time" responses. Some of them will drop the report.

Version

Once you have decided on a package, checking its version number is much simpler. For GNOME and KDE programs, it will often be in the 'About' box of a program.

Severity

There are different severities of bugs you can assign. If you are not sure, normal is fine. There should not be that many critical or grave bugs in software which is in daily use. They tend to get fixed fast. So it is probably unlike you will need those two categories. Before assigning bugs to those two, you really should get the latest stable version and check it has not already been fixed.

These descriptions are adapted from the Debian bug tracker severity definitions:

Critical

This bug makes unrelated software on the system (or the whole system) break, or causes serious data loss, or introduces a security hole on systems where you install the software. Examples would be hanging the entire machine or overwriting files it should not even touch.

Grave

This bug makes the software in question unusable or mostly so, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the software. A program which consistently crashes on startup or produces files called core in your home directory might well be grave.

Normal

This is what you will usually want: the default value.

Wishlist

This is a useful category for two things: very hard to fix bugs; and requests for features or enhancements. ("It would be nice if...")

Class

The default class of a bug is a software bug: "there is something wrong with the program". This is almost always the class to select. Sometimes this is not quite what you need. You can change the class to a few other things: the most common alternative to need is a documentation bug: anything from typos to absent or out of date documentation.