Complete Guide To Bug Reporting In Debian Linux

Things to consider before installing 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.


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

Welcome to reportbug! Since it looks like this is the first time you have used reportbug, we are configuring its behavior. These settings will be saved to the file "/home/shirish/.reportbugrc", which you will be free to edit further.</code>
Please choose the default operating mode for reportbug.
1 novice Offer simple prompts, bypassing technical questions.
2 standard Offer more extensive prompts, including asking about things that a moderately sophisticated user would be expected to know about Debian.
3 advanced Like standard, but assumes you know a bit more about Debian, including "incoming".</code>
4 expert Bypass most handholding measures and preliminary triage routines. This mode should not be used by people unfamiliar with Debian's policies and operating procedures.</code>
Select mode: [novice] 2</code>
Please choose the default interface for reportbug.
1 text A text-oriented console user interface
2 gtk2 A graphical (GTK+) user interface.
Select interface: 1
Will reportbug often have direct Internet access? (You should answer yes to this question unless you know what you are doing and plan to check whether duplicate reports have been filed via some other channel.) [Y|n|q|?]? n
What real name should be used for sending bug reports?
>Which of your email addresses should be used when sending bug reports? (Note that this address will be visible in the bug tracking system, so you may want to use a webmail address or another address with good spam filtering capabilities.)
[[email protected]]&gt;[email protected]

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 [email protected] 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:

Do you have a "mail transport agent" (MTA) like Exim, Postfix or SSMTP configured on this computer to send mail to the Internet? [y|N|q|?]?n
Please enter the name of your SMTP host. Usually it's called something like "" or "". If you need to use a different port than default, use the : alternative format. Just press ENTER if you don't have one or don't know, and so a Debian SMTP host will be used.
Please enter the name of your proxy server. It should only use this parameter if you are behind a firewall. The PROXY argument should be formatted as a valid HTTP URL, including (if necessary) a port number; for example, Just press ENTER if you don't have one or don't know.

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 –

aiselriot but known as sol as can be seen.

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:

[$] reportbug piuparts –severity=normal
*** Welcome to reportbug. Use ? for help at prompts. ***
Note: bug reports are publicly archived (including the email address of the submitter).
Detected character set: UTF-8
Please change your locale if this is incorrect.
Using 'shirish ' as your from address.
Getting status for piuparts…
Verifying package integrity…
Will send report to Debian (per lsb_release).
Maintainer for piuparts is 'piuparts developers team '.
Looking up dependencies of piuparts…
Getting changed configuration files…
Briefly describe the problem (max. 100 characters allowed). This will be the bug email subject, so keep the summary as concise as possible, for
example: "fails to send email" or "does not start with -q option specified" (enter Ctrl+c to exit reportbug without reporting a bug)
> Adequate reports obsolete-conffile for piuparts
Rewriting subject to 'piuparts: Adequate reports obsolete-conffile for piuparts'?
Do any of the following apply to this report
1 d-i This bug is relevant to the development of debian-installer.
2 ipv6 This bug affects support for Internet Protocol version 6.
3 l10n This bug reports a localization/internationalization issue.
4 lfs This bug affects support for large files (over 2 gigabytes).
5 newcomer This bug has a known solution but the maintainer requests someone else implement it.
6 patch You are including a patch to fix this problem.
7 upstream This bug applies to the upstream part of the package.
8 none
Please select tags: (one at a time) [none]

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:

Subject: piuparts: adequate reports obsolete conffile for piuparts
Package: piuparts
Version: 0.75
Severity: normal
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
* What was the outcome of this action?
* What outcome did you expect instead?
** End of the template – remove these template lines **
— System Information:
Debian Release: 9.0
APT prefers testing
APT policy: (600, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (1, 'experimental-debug'), (1, 'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages piuparts depends on:
ii debootstrap 1.0.87
ii debsums 2.2
ii dpkg 1.18.18
ii lsb-release 9.20161125
ii lsof 4.89+dfsg-0.1
ii piuparts-common 0.75
ii python-debian 0.1.30
pn python:any
Versions of packages piuparts recommends:
ii adequate 0.15.1
Versions of packages piuparts suggests:
ii schroot 1.6.10-3
— no debconf information

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:

Subject:piuparts: adequate reports obsolete conffile for piuparts
Package: piuparts
Version: 0.75
Severity: normal
User: [email protected]
Usertags: obsolete-conffile adequate
Dear Maintainer,
Adequate reports broken obsolete-conffile –
[$] adequate piuparts
piuparts: obsolete-conffile /etc/piuparts/scripts/post_setup_experimental
Maybe you could use what pabs (Paul Wise) did in #815563, in that the
proper thing to do would be –
Use the dpkg-maintscript-helper support provided by dh_installdeb to remove such similar obsolete conffiles on upgrade
You can also see manpage of dh_installdeb via debhelper package which is the same thing.
I ran the same command as he did –
[$] pkg=piuparts ; adequate $pkg ; dpkg-query -W -f='${Conffiles}\n' $pkg | grep obsolete
piuparts: obsolete-conffile /etc/piuparts/scripts/post_setup_experimental
f7a1f3d45dc43106d1cd9b124b7c1ca8 obsolete
Please fix the above.
— System Information:
Debian Release: 9.0
APT prefers testing
APT policy: (600, 'testing'), (500, 'unstable-debug'), (500,
'testing-debug'), (1, 'experimental-debug'), (1, 'experimental'), (1,
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages piuparts depends on:
ii debootstrap 1.0.87
ii debsums 2.2
ii dpkg 1.18.18
ii lsb-release 9.20161125
ii lsof 4.89+dfsg-0.1
ii piuparts-common 0.75
ii python-debian 0.1.30
pn python:any
Versions of packages piuparts recommends:
ii adequate 0.15.1
Versions of packages piuparts suggests:
ii schroot 1.6.10-3
— no debconf information
view raw gistfile1.txt hosted with ❤ by GitHub

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 . If you have enabled MTA (Mail Transfer Agent) and don’t have a 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 –

mail-to-debian-bts-about-piuparts via

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.

Similar Posts

  • Hi, I am following in your foot steps and rather share your sentiments regarding Debian however I am floundering about in trying check to see if a bug is already reported and if it has been fixed in a later release. This seems more difficult than filing a bug with the help of your handy guide.
    I just wondered if you had found an existing guide or if you were disposed to write one?