Bughelper + Clue Files

June 1, 2007

Ubuntu has a lot of open bugs. According to the latest Ubuntu Weekly Newsletter there are over 30450 open bugs. Gheez, that is a lot. So I have written a very long blag about a bug tool we have, bughelper and its practical applications in the world of bugsquashing.

New in Feisty was the Apport tool. Apport catches a program when it is crashing, why it crashed and all the things developers need to process a crash. This included system information and is a very neat tool. So Apport gives us crash information in a real useful way.

Well then comes Bughelper, a tool which also helps us triage bugs. It’ll run and help us search for duplicates using a string, search based on bug title summaries, search based on tags, search based on number of duplicates (Fix Committed ATM), or print out the number of bugs in a package (among other things). Some useful commands (and explanations):

  • bugnumbers -p kubuntu-docs > kubuntu-docs.buglist

This is by far one of the coolest one. I know there are some devs who just look at thebugs in the packages they maintain. They can then open kubuntu-docs.buglist (or whatever you call your list) in and editor and look at all the bugs by number.

The -p flag is for the package so you can do something like: bugnumbers – p adept to print out all the numbers in your terminal. It just seems a bit easier to use “>” and name “yourlist”. Much more readable.

One more example. bugnumbers -p ubiquity > ubiquitybugs.txt. We now have a list of bugs in the Ubuntu installer, Kubuntu docs, and a package manager.

  • bughelper -p knetworkmanager -T knetworkmanager “feisty” “a feisty bug”

The above command will list all the bugs in knetwork manager. In this case, it will look for all the bugs with the string “feisty” in the bug report (includes comment but does not include attachments which use the -A flag). The output will look something like this. A basic search for a string would look like this: bughelper -p <package> -T <package> <search string> <output string>.

  • bughelper -T audacity “XFreeFont” “possible duplicate of 87434” -A -U -p audacity

The reason I ran bughelper in this way is because I had seen Apport reports from audacity crashing in the same place. This bug report seems to have many duplicates and they all happen at XFreeFont, specifically with the output of “Font.c:160” There may be multiple places were XFreeFont crashes, so we must be aware (from reading the stacktrace.txt) that it crashes at the point “Font.c:160”. As mentione before the -A flag searches attachments (very important as this reads the stacktraces which are done with the help of Apport), while the – U flag considers upstream sources. The output should read something like this which pulls up two likely duplicates. In fact, in reading the two similar bugs, it seems some of the duplicates of bug #89485 are actually duplicates of bug #87434. Had I not searched the stacktrace of one bug in bughelper, I may not have caught this.

Now that I know audacity crashes in a particular pattern (based on stacktraces), I can then write a clue file for audacity (or Firefox or Amarok or Ubiquity etc). Clue files allow us to make a smart patterned search in a XML formated document. For example the audacity clue file reads something like this (with proper indentation which refuses to show up on my blog):

<?xml version=”1.0″?>
<clues version=”0.1″>
<info>A likely bug dup of #87434</info>

There are multiple <clue>s so each clue begins with a <clue> and ends with a </clue>, the whole thing is wrapped in <clues>. Fair enough. We use the <dontlist> so that when bughelper runs, it doesn not like the <bug> which we already know is the master bug report. We are looking for the possible duplicates not listing the master bug. The <contains> field is everything that is in the bug report that can lead you toward it being a know issue. Skipping ahead a bit, the <op> are the strings / conditions that are searched for. You see that XFreeFont is there, as well as the location Font.c:160. Since bug #87434 has both of those strings, to find a bug as duplicate it requires both of these conditions. Therefore, we can use the <and> to wrap it around these to <op>s. The <info> is the output bughelper spits out, this is whatever the clue file writer needs.

Some clue files are a bit more complex than others. Take for example, Firefox’s clue file. (Note: The clue file for bug #71712 will be take out at some point). The Mozilla Team uses the clue file to search for bugs reports in Firefox that are not tagged according to our tag policy. Also, it searches for Master crash reports so that we have a running list of all master crashes so we can build clues for all crash cases. However, the clue files are not particularly labor intensive. I whipped up the Audacity one in about 15 minutes at a Loco meeting while explaining what I was doing to the members present. Once you are familiar with the syntax you are golden to start writing some (I would suggest having someone look over your clue files before committing them to the bazaar branch). The hardest part will be reading stacktraces and seeing a pattern (hint: bugs with many duplicates are a great place to start). I will see what I can do about starting one from scratch and posting it on the planet.

Please note that clue files and bughelper are in active development and the Bughelper Development team is always looking for ways to improve it. Consequently, some feature may change. Feel free to ask questions about it in #ubuntu-bugs or feel free to ask me.

Useful links:






  1. Hi. Great Post. I would like to leave as a comment the following questions, which to me really need to be addressed in Ubuntu.
    (1) is enough development time assigned for Quality&Assurance in Ubuntu?
    (judging by the type of open bugs, no. Oh well, by the amount of bugs too:-) )
    (2) should you always be introducing new features in the distribution when they are not fully debugged and tested? (in my opinion, the importance of debugging and testing is totally underrated. I know that a lot of effort is put into this. But, is not enough! Have a look at restricted driver manager or network-manager for example. In most situations they don’t work. They give a bad reputation to Ubuntu. I know Mark (sabdfl) hates things that look the same from one distro release to the other ๐Ÿ™‚ I agree with him too. But the amount of bugs is really becoming a usability problem!)
    (4) Don’t you feel that bug fixing nowadays is slightly scattered and random? (perhaps is just my impression but I’ve seen average bugs being fixed by core developers just because they fancy those applications. But to be honest, those applications are not a priority for most users.)
    (5) It’s great to tell users. File a bug a report and we will have a look into it. But, the bug doesn’t get fixed by itself ๐Ÿ™‚ Don’t you think that a timeframe for the bug fix is clearly relevant for the user satisfaction? I’ve seen a specification on this line of thought, but I can’t find it now.

    Don’t take the comment with a negative tone. It’s just that I’ve been wondering about these issues for a while now.

    Continue your great job ๐Ÿ™‚

  2. @anonymous

    (1) Are there more resources available? Volunteers are working hard for free to fix bugs. Anything that you can do to make their work more efficient so they can save time and be happier would be welcome. Getting more contributors would be great as well. Are you assigning enough of your time to Q&A? It is an unfair question when directed to anyone that is not receiving anything (money, code,…) from the questioner.

    (2) Software has bugs. More software has more bugs. Ubuntu is still growing in size. Missing features are considered by some users bugs itself. If network-manager didn’t work most of the time as you said, it won’t be so popular and used so widely. The small group of people that suffer a bug tend to do more noise than the ones that cannot reproduce it.

    (3) There was not (3) question. Even your list has a bug.

    (4) The priorities of volunteer developers are dictated by themselves. The priorities of paid developers are dictated by the entity that pays them. If you didn’t give any incentive to a volunteer developer or you didn’t pay to get a bug fixed, then the best you can hope is that those priorities match with yours. The beauty of libre software is that when they do match, you will benefit from it. In a proprietary environment the changes won’t propagate to the community.

    (5) You fail to ask two important questions: Who is going to invest time/money in fixing this? Why are they going to do that?

    It is good to think about all this but I think you still need to consider the issues more. Take into account the perspective of a paid developer that has to do their job (and their job is not to fix the most popular bugs but to fix the ones interesting to his/her employer). More importantly, take into account the perspective of the volunteer, who is putting aside leisure time, time with their family, time with their friends, sometimes even work / studying time just to work on something. That they are willing to put just 1 minute to fix a bug that doesn’t affect them at all, it is truly amazing. Try to understand why someone will do this and how you can motivate them to keep doing it.

    The best way is to become a developer yourself. You don’t need to know anything to start. Most developers learn as they go. Choose a package from sourceforget.net that is not in Ubuntu and try to package it. Ask in IRC or mailing lists how to start. It may take you months and you may just give up but in the process you will get a lot of more perspective. If you say: “I don’t have time to do that”. Then, why you assume other people have time to do everything that you do plus everything that they are already doing that you don’t have time to do plus fixing even more bugs?

  3. Freddy,
    a bit of OT comment. Can you change your theme such that the main content is a bit wider? It is a bit short of width and I have to scroll a lot. It is also a bit pain-for-the-eyes to read this ๐Ÿ™‚

  4. am afraid i was wrong, i first read it within akregator where the middle content was short of width. It is ok in FF :-S

  5. 30450! Next version Ubuntu 7.10 aka Bugs Bunny?

  6. Very cool article. I like. I like.

  7. Need to remember, a lot of those bugs reported really aren’t bugs either. Some people tend to put support type issues as a bug report. There are still quite a few bugs that need to be closed as they have been fixed already. Also, you need to remember that a lot of the bugs reported are against upstream applications, and it is always nice to get the fix from upstream as well. There is a lot of QA within Ubuntu. 34k isn’t that bad of a number if you consider other projects have over 100k. Well I shouldn’t say that is isn’t that bad of a number because it really is, it is just less than a lot of others.

  8. Nice, Freddy. I can see why you would want to implement a GUI for this as a Chi-Ubuntu team project.

  9. Great writeup up Freddy, hopefully it raises awareness of some of the bugs that are still outstanding in Ubuntu. A fact I’m constantly reminded of by hanging out on #ubuntu-bugs and seeing ubotu always announcing the newest bugs. It would be cool if he announced closed/rejected bugs as well.
    Anyways great write up on bughelper, I’ve used the first copy of the program but am amazed at how quickly it has matured and grown up. A GUI for bughelper would be great and very useful.

  10. Oh and btw added you to my blogroll

  11. @anonymous
    (1) is enough development time assigned for Quality&Assurance in Ubuntu?
    i would say for the most part, yes. We have quite a few people that do things like ISO testing, syncing, testing packages and what not.
    (2) should you always be introducing new features in the distribution when they are not fully debugged and tested? I would think so. Take a look at Windows Migration Assistant. Its a relatively new tool but it is quite useful. It draws people in and some of those people are developers. There is the argument that 6 month time based release are important because it gives developers time to create a new feature, but at the same time “forces” people to put code out. The last thing people need is to have people develop and develop but not put anything out.
    (4) Donโ€™t you feel that bug fixing nowadays is slightly scattered and random? It really depends on the developer. Myself, I try to help out with Mozilla and Kubuntu related bugs. This is for several reasons: 1. Firefox is a very popular package with a lot of duplicate bugs. 2. I am familiar with these environments. 3. I can’t really look at bugs that don’t interest me, if I do too much it will burn me out on bugs. 4. Since I am a volunteer, I really have to prioritize my time in looking at bugs.

  12. @1052
    The best way is to become a developer yourself.
    Very true. I learn as I go and try to pass the knowledge on. I see great potential in something like bughelper and feel a need to pass the love on to the masses.

  13. @nixternal
    > Need to remember, a lot of those bugs reported really arenโ€™t bugs either.
    Yes very true. That is a reason why we need more people looking at these bug reports and making sure that they are really bugs.
    > There are still quite a few bugs that need to be closed as they have been fixed already.
    It is sad to see an older issue fixed but not closed, it is an unfortunate side effects of building a new image of the latest and greatest.
    > 34k isnโ€™t that bad of a number if you consider other projects have over 100k. Right, but I think these projects are much older than us. Considering that Ubuntu is released in 2004 and a company like RedHat has 10+ years on us.

  14. @ Jonathan.
    > It would be cool if he announced closed/rejected bugs as well.
    I think the bot used to do that before but had to stop doing that due to flooding. Not sure about the history of the bot.
    > A GUI for bughelper would be great and very useful.
    We have discussed this on the ML for the Chicago LoCo and I think with something like Glade it would be possible. The only issue I see is keeping bughelper (which is under rapid dev) and the GUI updated. Also, I’m not sure if the GUI would be the correct direction the bughelper dev team wants it to go in. You are also now on my blog roll.

  15. If you want to hear a reader’s feedback ๐Ÿ™‚ , I rate this post for 4/5. Decent info, but I have to go to that damn google to find the missed bits. Thank you, anyway!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: