How to report bugs on Debian 2.2

ArticleCategory: [Artikel Kategorie]


AuthorImage:[Bild des Autors]

[Photo of the Author]

TranslationInfo:[Author and translation history]

original in en Egon Willighagen 

AboutTheAuthor:[Über den Autor]

Joined the Dutch LF team in 1999 and became second editor earlier this year. Is an informational chemistry student at the University of Nijmegen. Plays basketball and enjoys hiking.


This article describes what Debian users can do back for the community: report bugs they find. Explained is how to do this and why one should report bugs.

ArticleIllustration:[Titelbild des Artikels]


ArticleBody:[Der eigentliche Artikel]

Debian community

Debian is first of all a Linux distribution, but is also a community that tries to make the best operating system (OS) freely available. But who is part of this community? Of course the developers are important members, but users are also very important. When Debian would not be used, developers would stop developing. What's the fun of porting software when no one uses it?

These developers, however, are all volunteers. In contrast with Red Hat and Suse developers, where a company (RH and Suse) employs a number of developers, Debian developers do not get paid. And this means they do not have unlimited time resources. "OK", you might ask, "but what has that to do with me?" As a user you can help these developers by summiting bugs you found.

Debian packages can have two classes of bugs. One class is a real software bug. Since the Debian developer is often not the writer of the software itself (he just made a Debian package for it), he will sometimes tries to solve them but often send them to the software author.

The second class of bugs, consist of bugs in the Debian package or bugs in the installation setup for the software in he package on the Debian system. And these bugs are to be solved by the Debian developer. And finding these bugs is a very time consuming business.

Finding Bugs

Bugs are very common in software. But developers need to develop a stable Debian system, and bugs are not part of that. But bugs are not easily found. Otherwise, they would have been eliminated. Bugs can be found in several ways:

Of these the system crash is easily found, though it might be more difficult to solve the bug. But the second type of bug is much harder to find. The reason is that the author/developer cannot test the software for all possible output. An example: consider a calculator program. The author can test several behavioral aspects: 1+1 must give 2, 2*5 must give 10, etc. But he cannot test all possible summations and multiplications. He will not test 3456733256677*77782882355.

But a user will. Users do things with (and to) the software the author had never anticipated. Since the amount of users exceed the number of software authors and Debian developers they are expected to stumble upon far more bugs. But all these bugs will not be severe bugs. You're system will not crash, your data will not be corrupted. In most cases these bugs will not even cause inconvenience, as in many times they can be circumvented.

And as a member of the community you almost have the moral obligation to post the bug to the Debian developer, so that the software can be made even more stable. And this article is a plea for doing just this. (Of course you will not find many bugs on a Debian system :)

How to report bugs on Debian 2.2?

What is so special about reporting a bug on Debian? One aspect is that Debian has an extensive bug report system. Submitted bugs will be stored on a central debugs server. The program reportbug facilitate this bugs submission and has several handy tools.

Consider you found a bug in the program dia (my favorite diagram editor). Let's go through the process of submitting a bug to this package. (The actual bug found was not a Debian bug, but bug in the real software, so expect the Debian developer will forward it to the authors.)

I type (at the prompt. I did not find a nice GUI to this program.):
egonw > reportbug
Please enter the name of the package in which you have found a problem,
or type one of these bug categories:

base              General bugs in the base system
boot-floppies     Bugs in the boot and root disks   The bug tracking system,    Problems with the main FTP site (or mirrors)
general           Widespread problems (e.g., that many man pages are mode 

kernel            Problems with the kernel in general (otherwise: 
list archives      The mailing list archives.  The mailing lists (debian-*
manual            Bugs in the manual  Problems with the non-us FTP site (or mirrors)
project           Problems related to Project administration    Problems with the website (or mirrors)                 

Enter a package:

Let us do a proper job and not give one of these categories, but the actual package. For this we terminate this reportbug session with ^C (ctrl-C). We need to find the package which contains the executable "dia". We do this by:
egonw > whereis dia
dia: /usr/lib/dia /usr/X11R6/bin/dia /usr/bin/X11/dia /usr/share/dia
egonw > dpkg -S /usr/bin/X11/dia
dpkg: /usr/bin/X11/dia not found.
egonw > dpkg -S /usr/X11R6/bin/dia
dia: /usr/X11R6/bin/dia

With the last command we see that the executable is contained in the package dia (if you're not sure, check it with: "dpkg -l dia"). Note that whereis gives four files. The first file is a library. The last one is a directory and the middle two are executables. The package dia only supplies the second dia executable, and the origin of the first executable is unknown to me.

Now that we know the package with the bug, we can also quickly check where this package was downloaded (ftp/http) or taken (CD/floppy) from:
egonw > apt-cache showpkg dia
Versions: 0.86-helix1(/var/state/apt/lists/spidermonkey.helixcode.com_dis
Reverse Depends: 
0.86-helix1 - gdk-imlib1 (2 libart2 (2 1.2.0) libaudiofile0 (0 
(null)) libc6 (2 2.1.2) libdb2 (2 1:2.4.14-7) libesd0 (18 0.2.16) 
libesd-alsa0 (2 0.2.16) libgdk-pixbuf2 (0 (null)) libglib1.2 (2 1.2.0) 
libgnome32 (2 1.2.0) libgnomesupport0 (2 1.2.0) libgnomeui32 (2 1.2.0) 
libgtk1.2 (2 1.2.0) libpng2 (0 (null)) libpopt0 (0 (null)) libxml1 (0 
(null)) xlib6g (2 3.3.6-4) zlib1g (2 1:1.1.3) gsfonts-x11 (0 (null)) 
0.83-2 - gdk-imlib1 (2 1.9.8-2) libc6 (2 2.1.2) libglib1.2 (2 1.2.0) 
libgtk1.2 (2 1.2.6-1) libpopt0 (0 (null)) libxml1 (0 (null)) libz1 (0 
(null)) xlib6g (2 3.3.5) gsfonts-x11 (0 (null)) 
0.86-helix1 - 
0.83-2 - 
Reverse Provides:

With this we see that the current version (0.86-helix1) was installed from HelixCode (To install HelixGnome, type 'echo "#HelixGnome Update\ndeb tions/debian unstable main" >> /etc/apt/sources.list; apt-get update; apt-get install task-helix-gnome'). This bug should this not be sended to the Debian developer but to the HelixGnome Debian packager instead which is not done with the reportbug tool. For the sake of this article, let's assume that version 0.83-2 is installed which is the Debian 2.2 package for dia and (in my case) was downloaded from a Dutch FTP mirror.

Ok, so we know the bug is in the dia-0.83-2.deb package which was downloaded from a Debian FTP site. We now continue with submitting the bug. If you're not online you can add the '-b' option, so the program will not search the Debian Bug Tracking System (BTS). By checking BTS you can check whether the same bug was not already submitted before. So checking BTS is highly preferred.

After entering the package name and consulting BTS, it will check package dependencies. Checking dependencies is important. The software depends on libraries and bugs might have their origin in a version conflict. Actually, this is one major source for bugs. No user input is needed for this check.

The next question it will ask, is you to provide a brief description of the bug. This description will be used as a title and must be complete and short. Later on the bug can be described in high detail. In my case this title is "dia file format incorrectly uses dia namespace". Details and the explanation will follow later.

Now you must give a qualification of the bug. Five classes are available:

critical 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 package.
grave makes the package 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 package.
important any other bug which makes the package unsuitable for release.
normal the default value, used for more 'benign' bugs
wishlist for any feature request, and also for any bugs that are very difficult to fix due to major design considerations.

Choose an appropriate severity. Normal is the default qualification, and most bugs in Debian 2.2 will have this severity. This is because Debian uses several extensive test cycles in which the complete system is tested before the distribution is released to the public. Note also that you can submit wishes for new features with reportbug, though these are clearly not bugs.

After choosing the classification an editor will be started with all information which was gathered until now:
Subject: dia file format incorrectly uses dia namespace
Package: dia
Version: 0.86-helix1
Severity: normal

-- System Information
Debian Release: 2.2
Architecture: i386
Kernel: Linux george 2.2.17 #1 Sun Jun 25 09:24:41 EST 2000 i586

Versions of packages dia depends on:
ii  gdk-imlib1       Gdk-Imlib is an imaging 
library fo
ii  libart2               1.2.4-helix3       The Gnome canvas widget
ii  libaudiofile0         0.1.9-0.1          The Audiofile Library
ii  libc6                 2.1.3-10           GNU C Library: Shared 
libraries an
ii  libdb2                2:2.4.14- The Berkeley database 
routines (ru
ii  libesd0               0.2.17-7           Enlightened Sound Daemon - 
ii  libgdk-pixbuf2        0.8.0-helix2       The GNOME GdkPixBuf 
ii  libglib1.2            1.2.8-helix1       The GLib library of C 
ii  libgnome32            1.2.4-helix3       The Gnome libraries
ii  libgnomesupport0      1.2.4-helix3       The Gnome libraries 

This is the time when you can elaborate on the title you entered earlier. Between the "Severity: normal" and "-- System Information" lines you can add more details and conditions when the bug occurred. Try to reproduce the same bug and closely describe the steps you took to achieve to bug. This helps the developers trace the bug to a part of the malfunctioning programming code. In more complex situations you also might want to give the expected output or behavior.

Finally, the programs ask you if you want to bug be emailed to the bug list. Sending it, will end the process for now. You just did something back for the community.

What's next?

You can trace the bug's status by visiting the Debian Bug Track System and choosing the package to which you filed a bug. (Do not expect you're bug to show up in the list within 24 hours.) And then you wait. And hopefully the bug gets fixed.

It is to bad that there is no graphical user interface to reportbug yet, but now any Debian user can submit bugs, independent of system functionality. And an interface is easily build nowadays. Sure hope to see one soon!