Complete Guide To Bug Reporting In Debian Linux

Reporting bugs is one the many ways you can help Linux grow. All free software distributions, projects have different systems in which bugs are collected, analyzed, labeled and fixed depending on number of people who know the source-code.

Since I love Debian, I’ll show you how to file bug reports in Debian.

How to report bugs in Debian Linux

The goto tool in Debian to report bugs is Reportbug.  I wish I had known about it when I started with bug-reporting, would have avoided quite a bit of heartburn for myself as well as the maintainer.

Let’s see how can we use Reportbug for bug reporting in Debian Linux.

Step 1. Reportbug Installation

Use the command below to install Reportbug:

sudo aptitude install reportbug

Step 2. Reportbug: The first run

Once you have installed Reportbug, on the first run, you need to configure it so that it can be used to file bug reports.

Use the command below to run it.

reportbug

And then a bunch of queries as can be seen as below:

Notes on Reportbug first-run:

a. As I have been using Debian for quite some time, I can toggle between 2 and 3. For people who are extremely new to bug reporting, they could stick to [1] which is shown novice and the default, just press Enter.

b. Between the text UI and the gtk2/3 interface , I find the gtk2/3 interface unappealing and also taking a bit of memory, hence I choose 1 all the time. If you chose the gtk2/3 editor the instructions below are still the same for you, only you will see the gtk-editor showing the same thing in a slightly more beautiful manner.

c. The part where Reportbug asks for net access I always deny it for practical, as well as, security view-point. A bit more explanation for the reasons I do so would be shared below.

d. Lastly, when it asks for the name, if you like the existing name (takes from the username@hostname variable) press Enter, in case you want it to be something else, give the name by which you want it to appear.

Step 3. Handling Gmail quirks

The first time Reportbug would be run, it would ask for mail setup:

The first question it’s asking if you have some software which will enable it to send emails automatically.

If you have setup a desktop email client such as Evolution or Thunderbird, choose yes. Else, go for no.

Once the default preferences file is written, it is saved at /home/shirish/.reportbugrc. You can change the configuration later by editing this file.

On the console, you can use CTRL+C to exit Reportbug at any point in time.

Step 5. Figuring out an application package name from a binary

Let me take the example of Aiselriot. It is one of the GTK Card games that my mum plays a lot. Now if there is a problem with the game how do I found out under what package should I file a bug-report ?

So the first thing I do when trying to troubleshoot a GUI application is to take its icon and put it on the panel and see its properties just like I am showing here –

Now I know that the name of the app. is not Aiselriot but sol and the path where the application is put up is at /usr/games/sol.

Now let’s try finding what the package is called –

dpkg -S /usr/games/sol

The output is:

aisleriot: /usr/games/sol

We are fortunate that the package is also called aiselriot but this doesn’t happen all the time.

Moving on, let us now report our first bug-report. As I’m using Debian testing/stretch/soon to be stable in few months, will be putting a bug-report through there.

Step 6. Using Reportbug to make a bug report

Now we need a package which has an issue/bug that we need to report to the Debian community.

I have a package piuparts which showed symptoms of an issue for which I turned to Reportbug as being shown in the gist:

Now let me explain how things are working. I use a tool called adequate (which is a Debian package checking tool) when installing packages. I will talk about adequate in detail in some future blog post.

What Reportbug does, is to get and parse all the information it has about the package so it knows whether to proceed ahead or not.

Now, the tool adequate runs in background all the time. One of its main jobs occurs right at the very end of a package installation, for e.g. for piuparts it shares/showed me this –

adequate found packaging bugs
 -----------------------------
piuparts: obsolete-conffile /etc/piuparts/scripts/post_setup_experimental

which told me that the the piuparts package had an obsolete conffile. Conffile stands for Configuration file.

So the first command I do whenever I find a bug worth reporting is I do this –

reportbug piuparts --severity=normal

Gives/tells about the package which has the issue, in this case piuparts.

Putting severity to any bug is a tricky business. Unless I have pretty strong feelings about a package and know beyond a doubt that the bug is indeed severe, I don’t raise the severity. This is my own personal ethic, also a bit less work for a maintainer.

That being said most maintainers would look at a bug inspite of whatever severity you give. I have had maintainers respond me to me quickly even when I have filed wishlist bugs and I have maintainers not getting back. MIA (Missing-In-Action) even after filing severe bugs. Filing and having a healthy conversation with the maintainer is a technical as well as a social activity.

After asking the subject, reportbug asks/gives various options if one of the conditions apply. You could use any if you think your bug is affected or affects one of the above things on the list . For instance if you are going to share a patch to fix the problem, you will choose 6 or one of the others. If none of them are needed, simply Enter and move ahead.

Once the above is done, it takes a few moments and we get something similar to this shared gist:

Now what this does is, it gives an idea to the maintainer of the state of your system. As you all know, almost all GNU/Linux distributions and the packages therein are based on a complex set of relationships with other packages. The maintainer needs to know what version of the package you were using, which other packages were there, what version were they at, apart from knowing that the integrity of the package hasn’t been tampered with in any way.

Now you need to fill in the banks –

I usually remove/delete cut the following, if you are a new user you could just answer the questions below and your bug report would be ready.

Step 7. The final changes made to spend the report

And in its place, I put the details as being shared right here:

Some more info. now – These two tags signal/tell the maintainers few things –

 User: [email protected]

The first tag is signaling that the bug being raised is part of debian-qa efforts.

Usertags: obsolete-conffile adequate

The second tag is telling the tool we have used and one of the common issues under which it has come -in this case obsolete-conffile.

There are few common and uncommon use-cases that adequate looks into. As shared before, will need another blog post to share about it in detail.

The other thing I’m telling/sharing the maintainer is s/he should be looking into debhelper (a toolkit for debian/rules) and to look for specific bits therein.

Tip – Paul Wise, better known as pabs in Debian community. He is a prolific contributor to Debian. As you can see from his wiki page and the secondary apps. He always has a never-ending list of applications, packages that would be interesting to package alongwith things that could be/need to be improved. I dunno if he has done any mentoring or not, do see signs of a good and goofy mentor in him. I sometimes ask, sometimes steal his ideas to help in Debian QA :)

Now, that the bug-report is complete, I have to send it via gmail.com . If you have enabled MTA (Mail Transfer Agent) and don’t have a gmail.com you can just send and it will be done. If on the other hand, you haven’t enabled MTA (like me) and like to do things yourself, log on to your gmail account, hit compose and then –

Step 8. The final step

To - [email protected]
 Subject - piuparts: adequate reports obsolete conffile for piuparts

Body of your mail should start with Package

something like this –

You might have noticed some labels, they are just to help me be somewhat organized as after you have reported some bugs it can become chaotic to know what’s going on. Gmail’s labels and filters make things somewhat sanish with the amount of mail I receive.

At that point, make sure to recheck the mail once more before clicking the send mail button. I usually click on save draft, review it once or twice before sending it over.

If you are satisfied click send and your bug-report will be sent to Debian BTS .

Step 9. Getting acknowledgment from Debian BTS server saying the bug has reached them.

Usually, within minutes I get a short acknowledgment mail from the Debian BTS, like in the gist being shared

Look at the time-stamp given, just 3 minutes apart from when the mail was sent. I sent the bug mail on 05:03 and got the automated reply saying everything went fine on 05:06 itself.

What I look for into the acknowledgment mail is the bug number as that is how I come to know how things are going with the bug. #854317

Post bug-reporting cycle.

Coincidentally, as can be seen, the package maintainer somehow was around the time when I filed the bug. I do know the importance of piuparts in the debian ecosystem but I didn’t think Andreas will act so quickly, so now probably the next point release or even bug-fix release will have the fix. As can be seen though, Andreas seems to be a busy bee seeing the number of packages he’s maintaining/co-maintaining, besides uploading Non-Maintainer Uploads (NMU) and QA uploads.

I hope I have given enough insight so you know what to do as and when things go wrong.

Tip – Nowadays, I usually follow couple of rules before filing a bug. First check the bts for existing list of bugs, for e.g. piuparts bugs page (as also shared by Simon Tatham above). If the bug is not listed there, more often than not, it the package has not too many dependencies, and I know there aren’t any configuration files that I might have to recreate then I usually purge the package and install the package afresh. If adequate still finds a fault, I usually report it. I don’t do that though for obsolete conffiles as they usually happen when you are upgrading from version x.1 to x.2 or something like that.

Using such simple tips I save time and energy for myself as well as the maintainer of a package.

At first, it may take sometime, after a while, the whole thing may take 10-15 minutes or even less, depending on the package in which the bug is found, the bug itself, replication of the bug etc.

That’s about it to make a bug-report in Debian using Reportbug.

Hopefully, you have gotten some idea the steps to finding bugs and reporting them. Please post any queries you have in the comments below and I’ll try my best to answer/share whatever little I know.