original in en Egon Willighagen
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.
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.
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 :)
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 bugs.debian.org The bug tracking system, @bugs.debian.org ftp.debian.org Problems with the main FTP site (or mirrors) general Widespread problems (e.g., that many man pages are mode 755) kernel Problems with the kernel in general (otherwise: kernel-image) list archives The mailing list archives. lists.debian.org The mailing lists (firstname.lastname@example.org) manual Bugs in the manual nonus.debian.org Problems with the non-us FTP site (or mirrors) project Problems related to Project administration www.debian.org 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 ributions_debian_dists_unstable_main_binary-i386_Packages)(/var/lib/dpkg/ tatus),0.83-2(/var/state/apt/lists/ftp.nl.uu.net_pub_linux_debian_dists_s able_main_binary-i386_Packages), Reverse Depends: task-helix-gnome,dia Dependencies: 0.86-helix1 - gdk-imlib1 (2 184.108.40.206) 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)) Provides: 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 http://spidermonkey.helixcode.com/distrib 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:
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 220.127.116.11-helix4 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-18.104.22.168.c The Berkeley database routines (ru ii libesd0 0.2.17-7 Enlightened Sound Daemon - Shared ii libgdk-pixbuf2 0.8.0-helix2 The GNOME GdkPixBuf library. ii libglib1.2 1.2.8-helix1 The GLib library of C routines 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.
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!