Ubuntu Bug Reporting

Canonical does some things quite well.  Obviously, or Ubuntu would not have captured approximately 57% of the Linux desktop market share (according to Google's search insights tool). But there is at least one area for some major improvement:  bug reporting/tracking.  

In a previous LJ article I noted that an apparent long term bug had again resurfaced in Ubuntu 10.10.  This is a problem in the driver for some of the Atheros wireless chipsets which essentially renders those machines unusable.  What I did not discuss in that article was the incredible frustration involved with attempting to submit a bug report to the Ubuntu developers.  I’ll describe that process here.

Let’s say that you have discovered a problem in Ubuntu:  what do you do?  Well, I went to http://www.ubuntu.com/ to look for their bug reporting system.  So far, so good, there is a “Get support” link right in the middle of the page.  Click.  Now I’m on a page that offers to point me in the direction of free support from on-line forums, or to sell me “professional support services”.  Fair enough, everybody expects Canonical should be able to make a Krugerrand or two out of their distro business.  Down at the bottom of the page under the “Community” section there is a “Report a problem” link.  


We are now at a page that describes how to report a problem, including a link to a bug reporting tutorial.  Click.  Aha! Now we are on a page which actually has a link to Ubuntu’s launchpad.net bug reporting site.  This tutorial page suggests that you search for any existing reports of your bug before submitting a new report.  So far, so good still, if a bit convoluted.

Now, as a reminder of what led us here, a few days ago I had found a bug in the driver for the Atheros AR9285 wireless chipset in my Acer Aspire One N450 netbook.  The bug being that the netbook would not stay connected via wireless for more than a minute at a time.  So I clicked on the search link.  Down at the bottom of my screen appeared the message “Waiting on launchpad.net...”  Get used to that, you will be seeing it a lot if you are trying to research or report a bug.  Their launchpad bug reporting site is horribly slow.  You’ll also be seeing this message more often than you would probably care for:

Timeout error

Sorry, something just went wrong in Launchpad.

We’ve recorded what happened, and we’ll fix it as soon as possible. Apologies for the inconvenience.

Trying again in a couple of minutes might work.

(Error ID: OOPS-1752E1761)

In fact, this error message was all I was able to get out of launchpad when trying to do a search on “Atheros AR9258” using the “newest first” search option.  The site is almost always broken when you try to use that search option.  Finally after 6 tries the site returned 21 bug reports, many of which described a problem very similar to what I had observed, i.e. the wireless connection was useless with certain Atheros chipsets. Doing a more general search on "Atheros" "newest first" (only three launchpad error timeouts) returned 189 results.

So, just to be certain that Canonical was aware of the problem in their brand new Maverick Meerkat 10.10 release, I filed my own bug report: bug number 660864, if you want launchpad to find it for you.  A bit of additional research brought to light the fact that this problem with the Atheros drivers has been a recurrent one in Ubuntu dating all the way back to 7.04.  It certainly did not exist in the previous 10.04 Ubuntu Netbook Edition. Well, it did exist in the "out of the box" install, but installing the linux-backports-modules fixed the problem.

This experience leads me to conclude that Canonical has two significant areas for improvement:

  1. They could provide a less byzantine, convoluted, and painfully slow pathway to bug reporting.
  2. They should strengthen their regression testing procedures to help prevent previous bugs from re-entering their distributions.

Don’t misunderstand me, I like Ubuntu -- I’ve used it for years.  However, it is definitely time for Canonical to mature their QA process a bit.




Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Mark Shuttleworth.

Andydread's picture

As much as I love using Ubuntu and installing it on anything I can for everyone I can I have to say that I agree with this article. TOO MANY REGRESSIONS. TOO MANY REGRESSIONS. Ubuntu's QA needs a review.

Look here:

And here:
Developer says he is overworked. he says to tell Mark to hire him some help.

Then there is this:

Has anyone heard from Mark Shuttleworth about what Canonical is doing to improve QA?
It is time for more focus on QA as Ubuntu becomes more popular. Bugs are one thing. There will always be bugs. However, obvious show stopping bugs should be fixed before releasing to the public.

go upstream; don't report to Ubuntu unless necessary

Kristian Hermansen's picture

Bugs specific to packages included in many distributions should be reported upstream and NOT to Ubuntu. Too many people make this mistake because it is the "easy route". Avoid the Ubuntu patch and instead report your next bug in Chromium, for example, or other projects to the actual core developers of that software...

Yes, it is Canonical

carlfink's picture

Two of the bugs I reported were specifically in Canonical's implementation, not in the kernel or other packages. I tested, and they don't exist in Debian, which is generally Ubuntu's upstream. Still ignored.

In any case, Canonical can and should do what Debian does, and pass real bug reports upstream themselves. Going limp is not that helpful.


Doug.Roberts's picture

Canonical needs to learn to be more conscientious in the distributions they release. That means a more rigorous regression testing process needs to be put in place by them. It is their release. The average user isn't going to know where the buggy software originated, nor should (s)he. Letting this particular bug back into the 10.10 release after it had been (sort of) fixed in 10.04 was just plain sloppy.


Ok...reported a bug, now? A lot of bugs are ignored...

Geordi LaForge's picture

One example, bug 385545 on smbind:
This package is a web manager for bind zone and depends on a php template system, smarty. As i founded the smarty package on ubuntu is different from the debian package. Ubuntu decide to change the file position of smarty...

Bug opened 10/06/2009, because smbind not found the smarty include file.
I post a comment on 02/04/2010 to know when the bug will be resolved.
On the 01/10/2010 a security update for smbind generate a new package, ubuntu release a new package, but WITH THE SAME ERROR...
On the 06/10/2010 i posted a comment about this bug and about the package update without the resolution of the bug...
After some test,i verified that the problem was on 9.10/10.04/10.10RC...
The problem is very simple to resolve by changing a line in a config file...proposed with a bug comment...

After a year and half, no response on the bug; no solution on the bug and three release of ubuntu with the same bug...for a problem depending of a change in ubuntu package. I can understand that smbind isn't a software supported by Ububtu...but the comunity isn't good.

Simple description: you can insert a bug, most of these are ignored.

Solution for me? Creating a my repo to adjust this kind of "ubuntu ignore problem".

*-buntu troubles and "paid" support

Saint DanBert's picture

I'm someone who is paying (has paid) for Canonical support. Sadly, I must report that all of the troubles mentioned here apply to paid support as well.
In fairness, the folks who respond to support requests are all helpful and courteous and genuinely interested in help to find a solution.

As mentioned in these comments, Canonical per se, lacks direct control over most of the code that they are called to support. As a minimum, I expect their support folks to have far better understanding of where answers are available than my efforts can possibly accomplish alone. I don't expect then to arrive at stone cold dead resolution to whatever might trouble my workstations. I do expect them to identify the troubled component(s) after a modest effort. I also expect them to guide me to and through any known work around or similar resolution to my troubles. That includes, "apply this patch" or similar if they exist.

In my 30+ year career slinging bits, I've spent almost as much time providing as I have consuming technical support. I give Canonical Support a solid grade B. Third-party support is tough at best, but Canonical could certainly afford to spend some time and effort to make things better.

DISCLAIMER -- The opinions are my own. I welcome the opportunity to discuss my experiences with responsible persons having alternate points of view.

~~~ 0;-Dan

re: Ubuntu bug reporting...

Saint DanBert's picture

I have always used the command ubuntu-bug {options} or sudo ubuntu-bug {options} when reporting troubles with *-buntu.

The man-page takes you to an application called apport-bug. The ubuntu-bug command is simply a sym-link to apport-bug executable script.
YES, Virginia, its a script that you can review.

I'm not denying or refuting anything that you are saying, but I write because
there is another, maybe better, way to report troubles.

~~~ 0;-Dan

Have you considered paying

Anonymous's picture

Have you considered paying for support? It'll probably be much faster.

A fair question

Doug.Roberts's picture

And this answer is "No!". Not for the driver problem that was re-introduced into Ubuntu version 10.10 after having been fixed in Ubuntu 10.04. I don't believe in paying to fix someone else's mistakes. Canonical's regression testing process is flawed.

However, if I had a business that required me to be running enterprise-class Ubuntu based critical business systems, then I'd consider paying for support.


Canonical doesn't do kernel development

Anonymous's picture

The problem is that launchpad is a bit of a lie. The atheros modules are not maintained by canonical; Canonical has not said that they will fix bugs in this.

The person who maintains teh module is a free software developer -- an independant person, who probably doesn't even read launchpad bug reports, because it has nothing to do with their commitment to develop the system.

However, the problem is that there is simply not enough engineers to fix these things -- and thus submitting to a complaint to the correct location -- the kernel mailing list -- will probably get you flamed for wasting the dev's time (which to be fair, unless you know exactly what the problem is, and not "it doesn't work", but rather the code paths that are problematic)

Canonical would do well to hire some kernel engineers to fix these things, or some people to do preliminary debugging to aid kernel devs, or to communicate with them as to what groups of people are being hit hardest by kernel bugs.

These are tricky problems that don't go away. Expecting to be able to solve these problems by submitting a "it doesn't work for me" to a website is not realistic.

bug reporting

Bobvanderpoel's picture

Oh, and I thought I was the only one not intelligent enough to handle ubuntu bug reporting. Frankly, I've given up even trying to work my way though the maze ... not to mention that when you do manage to log a bug and submit the various other requirements ... nothing happens.

I think the bug is fixed somewhere ... but the fixes don't appear to get into the current distribution unless they have some kind of "important" flag. But, in the next distribution ... they usually are fixed. Don't know how it works :)

If I have a bug now I tell the guy down the street about it. He's on XP and fully understands.

great post

attosecond's picture

I've been thinking the same thing for the past few weeks, I filed a couple of bugs against 10.10 which is a million times better than earlier Ubuntu releases - I haven't gotten a single response on the bugs I opened. Not to mention it was a total hassle opening the bugs, as you explained above. It's unfortunate, because Ubuntu is so awesome but filing bugs is a pain in the butt.

The power of not trying

carlfink's picture

I have submitted multiple bugs for Ubuntu, which Canonical has then totally ignored. I gave up, and I'm back on Debian now. Not flashy, maybe, but they do try to fix bugs.

Ubuntu doesn't needs bug reports

Anony@mous.org's picture

You've got it all wrong,

Ubuntu doesn't needs bug reports, its objective is
- to have as many users as possible (ala MS)
- to have as many fanboys as possible (ala Mac)

Don't bother telling Ubuntu
- what users want (remember the UI thingy?)
- that they have bugs (just look at the long outstanding bug list)

If fact, Ubuntu is generating more and more bugs, probably hoping others will pick up the tab LOL

Usefulness of Comment

silvari's picture

This didn't exactly add a lot of value to the discussion.

Ubuntu bug reproting

Scrubby Creek's picture

Hi there,

In general terms I have to agree with you on this issue. I have come across regressions in the past which had dumb founded me. I also have been to the launchpad site and found useful solutions and workarounds. I have resisted making a report though, because of the complexity of what is required.

I do understand however, (taking Canonical's side of a moment), the bug reporting process does need to be rigid and disciplined to sort out real bugs from ordinary difficulties that arise from users fiddling around with their installation.

In short, I agree an more streamlined process is needed.


about ubuntu

Galatasaray's picture

i think ubuntu is the best system

bug repporting fails

crlsgms's picture

Im waiting since ubuntu 7.04 for pessulous + sabayon start working. Tired to fire up bug reports, openned new ones... but it seems that is not interesting for users with ubuntu to be able to create a simple lockup up station, wich this combination of apps (should be) can easily handle.

for now, i have to do a bunch of hand crafting tuning to let a 9.04 station locked up so the user can only use some apps, besides i couldnt lock the hability to change the screensaver / desktop image, but the users arent that nerdy to mess with the station they use to work.

too bad that this simple kit that microsoft has (gpolicies + steady state) is forgotten by cannonical. We at schools / libraries / universities would have a very nice weapon to argue about buying m$ licenses just to settle locked terminals. And bug reporting dont quite get cannonical attention.