Ubuntu18 Jan 2013 12:15 pm

I’ve recently started working on the Ubuntu error tracker code base and I’ve recently rolled out one feature that I’m excited about and hope that you find useful.

Errors are recorded about binary packages and when you look at the most common problems table you are seeing the names of binary packages. Being a long time Launchpad bugs user I found this somewhat confusing at first and as an Ubuntu developer I work with source code so I’m curious about the crashes regarding source packages that I work on. Subsequently, I’ve added the ability to search by source packages on errors.ubuntu.com and find all the errors about the binary packages created by that source package.

You can do this by entering the name of a source package, usb-creator for example, in the text box (which is prefilled with ‘all binary packages’) on the errors home page. Another way to perform the search is using the url parameter that the text box sets e.g. ‘package=usb-creator’. Using that our complete url becomes https://errors.ubuntu.com/?package=usb-creator.

Now we see crashes in usb-creator-gtk, usb-creator-kde and usb-creator-common. The ability to search by source package is an important part of another change I am working that will allow you to view errors about the packages to which a Launchpad user is subscribed.

One other change that I’ve made is showing the release a version of a package is from on a bucket page.

Package Versions

This allows you to quickly tell how many of the instances of the problem are affecting the latest version of the package. In this particular case 666!

Launchpad and Ubuntu18 Jun 2012 03:47 pm

Somewhat recently I was looking at the Ubuntu Foundations team’s bugs with the most duplicates. In a couple of cases I wanted to find out more information about the properties of the duplicate bug reports. For example, I was looking at one package installation failure and searching for duplicates of the same issue and wasn’t finding any at all which seemed rather strange to me. I looked at a couple of the 48 duplicates of this bug report and noticed they were reported by the same person. It occurred to me that I really wanted to check all the the duplicates and see who the reporter was, so I wrote a tool to do just that.

./lp-bug-dupe-properties --reporter --bug 1234567

LP: #1234567 has 40 duplicates
brian-murray: 2345678 3456789 …

So bug 1234567, a fake example, isn’t as important as the duplicate count would have led you to believe, but there are more things it would be good to know about duplicate bugs. Like when they were reported:

./lp-bug-dupe-properties --bug 902603 --day

LP: #902603 has 250 duplicates
2011-12-10: 902605 902606 902607 902608
2011-12-11: 902775 902776 …

Or the release tags that the duplicates possess.

./lp-bug-dupe-properties --bug 902603 --rtags

LP: #902603 has 250 duplicates
precise: 902605 902606 …

Finally one thing specific to Ubuntu that would be quite helpful are the values of apport keys that appear in the bug description. For example:

./lp-bug-dupe-properties --bug 708517 -D Package

LP: #708517 has 52 duplicates
plymouth 0.8.2-2ubuntu17: 725753 725754 730377 734480
plymouth 0.8.2-2ubuntu18: 738127 738374 739290 739712 740071

Here we’ve checked the bug description of every duplicate to see what value appears in the Package key of the description that was created by apport. This was useful to tell what the latest version of the package the bug was reported about.

lp-bug-dupe-properties was just merged into the bzr branch of lptools. I hope you find it useful.

Ubuntu23 May 2012 04:33 pm

I’d mentioned to some people at the Ubuntu Developer Summit in Oakland that I am currently training to climb Mount Saint Helens in Washington and they seemed somewhat interested in my plan hence this post. The climb is actually a non-technical hike to the rim of the crater on the south side of the mountain. I did this hike before in September of 2006, but this time I talked one friend, Kees Cook, and my family to do it with me. We bought our permits for August 24th, 2012 to allow us plenty of time to train and for the snow to melt. While I made it last time I was rather slow and remember being quite sore so this year I thought we’d train more than I did last time. Well that and I like hiking.

I tried searching the internet for training schedules and didn’t find anything right away other than a post on a geocaching forum. They’d suggested climbing points, hills or mountains that increase in elevation change in increments of about 500 feet. That seemed fairly reasonable to me so I scoured hiking books and sites, particularly the great nwhiker.com, to come up with a list of things to hike. Luckily, I live in the Columbia River Gorge which provides a wide variety of prominent peaks which are right next to major highways.

Kees and I came up with the following schedule.

training schedule

The first column is the tentative date, the second the elevation change, and the third the point or hike’s name. You might notice we didn’t include the distance of the hikes at all, this was a rather large oversight which ended up hurthing my dog the most. I ended up having to carry her up and down stairs in the house! Cooper Spur has a question mark next to it as it is a special hike. That hike is at a similar elevation to Mount Saint Helens and we thought it might be interesting to see if anything is different about hiking at those higher heights. Depending on snow levels the date for that particular hike will change.

We just reached the 2600 level with our hike on the 20th of Indian Point. Every hike we go on I bring my Garmin GPS with us to record a track of where we’ve been. I then import the gpx file into two great pieces of software in Ubuntu.

I use gpsprune for editing the gpx track and removing bad data points for example when the gps is first receiving a signal. It is also handy for those times where I leave the gps on while driving to the hike as I can then split the gpx file into to two separate ones. gpsprune is also good for generating a 3D model of your hike which was helpful confirming that we had hiked a trail on the opposite side of a canyon we thought we’d hiked on but weren’t positive.

gpsprune 3d view

And I use pytrainer for keeping a ledger of hikes that we’ve made, the dates that we did them and comparing our hikes.

pytrainer ledger

One interesting thing to note is the difference in elevation changes and ascents. Indian Point is listed as an elevation change of about 2600 feet as that is the difference between the elevation at the start of the hike and the end of the hike. However, pytrainer tells us that we ascended 3600 feet! This is of course due to ups and downs on the trail.

Next up is Dog Mountain but my dog won’t be joining us⸮

Ubuntu21 May 2012 04:03 pm

In Ubuntu we receive a multitude of package installation failures due to people misconfiguring their /etc/default/grub file. During this release cycle we plan on putting some work into helping people resolve these misconfigurations and subsequently we need to understand what changes people make to /etc/default/grub.

Fortunately, the grub apport package hook includes /etc/default/grub in the information that it gathers and uploads to Launchpad. So we just need to get all those attachments from Launchpad. Sometime ago I did this for the X org team with xorg.conf files and used the Launchpad API directly. However, now we have lp-grab-attachments, part of the lpltools package, which can make this much easier:

lp-grab-attachments --package grub2

Now I have a bunch of /etc/default/grub files on my local system and I can use grep to search them locally. The most common errors all related to quoting as we had expected. People either neglect one of the quotes in the pair or use unicode quotes instead of ASCII ones.

Ubuntu01 May 2012 03:56 pm

A short time ago I ran across a couple of bugs with the same title reported by the same Launchpad user something like:

package xyz failed to install/upgrade: subprocess post-installation script returned error exit status 139

Upon further investigation I discovered that those two bugs were duplicates but it made me wonder how many other Launchpad users had reported the same bug more than once.

I figured that the easiest way to query this information would be to use the Ultimate Debian Database, which also helpfully contains Ubuntu bug information. Using my local copy, I queried for Ubuntu bugs with the same title and reported by the same user about the same source package. The vast majority of these were package installation failures, some of which actually had consecutive bug numbers and others where the user just kept trying to upgrade over time without resolving the original issue.

I didn’t keep great stats but the quantity of apport-package bugs decreased by at least 175 when I got through marking duplicates.

Ubuntu26 Mar 2012 02:23 pm

I find bug heat a useful way to determine the impact of a bug as it takes into account the number of duplicates, number of subscribers and quantity of people affected by the bug.  Additionally, as a defect analyst for a team that is interested in bug reports about a large number of packages, I’d like to be able find out which of our bugs (across all our packages) have the greatest heat in Launchpad. It would be helpful to see this data in a chart so I can visually distinguish differences in heat and also have the bugs grouped by package rather than having them in a list ordered only by bug heat. (The chart will also help because Launchpad times out when creating the report for the foundations-bugs team.)

To this end I’ve collected data on the five hottest bugs for each package to which my team is subscribed. I’ve used it to make following chart which only displays packages where the package’s hottest bug is greater than 10% of the hottest bug overall.

Foundations’s Hottest Bugs

The chart will display the bug number and title when you mouse over a point on it. It is also possible to control which of the five hottest bugs are shown. Again, I’ve created these for the desktop, server, foundations and ubuntu-x-swat teams. There are also charts for every package set in Precise.

Launchpad and Ubuntu09 Mar 2012 03:45 pm

In the Ubuntu Bug Squad we frequently talk about how to perform tasks on IRC but for some people it is a lot easier to learn something by seeing it done. Subsequently, I’ve created a video of how to confirm a bug task in Launchpad. There are actually three different ways to do it and the best is the last one in the video.

I created the video mostly following the instructions at the Canonical design blog. I recorded separate screencasts for each way of confirming the task, that way they can be easily replaced if Launchpad changes. Text slides, instead of audio, were used to make production easier and also to allow for easy translations.

Ubuntu22 Feb 2012 04:41 pm

I work with a team, the Ubuntu Foundations team, that has an interest in a lot of source packages and naturally bugs reported about those packages. To track all these packages we have setup a team in Launchpad, the foundations-bugs team, and subscribed them to the packages we care for and setup a mailing list to receive bug mail. Launchpad also provides us with a report that shows us some bug numbers, but this just shows information about where the bug tasks are as a whole. I wanted to find out which packages are receiving bug tasks right now and if that bug volume is abnormal for the package. (Some packages will always be receiving lots of bug reports.)

To this end I’ve created created a chart, using the packages the foundations-bugs team are subscribed to, that displays the quantity of bug tasks opened in the past 7 days and the past 14 days. Additionally, the bug tasks for a package are classified by their reporting method. (When a bug is reported by apport it is tagged differently depending on the type e.g. if it is a crash the bug is tagged apport-crash.) This information allows us to tell if a particular package is receiving a lot of crashes or package installation failures, which is more important than a lot of tasks tagged ubuntu-bug.

Screenshot of chart

Looking at the above screenshot we can see that casper is having a spike in bug reporting activity as the bar length for the 7 day and the 14 day period are equal. This likely has something to do with the 10.04.4 testing that was going on but is worth investigating. grub2 also seems to have a large number of apport-package bugs which also should be investigated. The chart makes this really easy as each section of the bar takes you to a Launchpad search for all bug tasks about that package with the relevant tag. Additionally, the package name is also a link for all the bugs about the package.

I’ve made the same chart for the desktop, server and ubuntu-x-swat teams. If you have a team that is subscribed to Ubuntu packages I’m happy to make one for you too. Additionally, there are also charts for every package set in Precise so one of those might have a list of packages in which you are interested.

Ubuntu14 Nov 2011 05:36 pm

As an Ubuntu user I end up encountering some bugs and as I’ve been using Ubuntu for some time now I’ve reported quite a few of them, 83, which are still open.

As a defect analyst and bug triager I know developers and triagers can’t get get to every bug report and some may end up sitting in one state or another. However, one way I can improve this situation as a bug reporter is by reviewing the bugs I’ve reported after a new version of Ubuntu has been released.

For example, today I looked at the bugs I reported and discovered that some were about packages no longer available in Ubuntu, they also were not eligible for a Stable Release Update, so I set those bug reports to Invalid. I also found a bug report that was fixed in Ubuntu 11.10 and a bug report with new information from upstream that I added to the Ubuntu bug report.

You can find bugs you’ve reported about Ubuntu by going to bug reports about Ubuntu in Launchpad and clicking on “Bugs reported by me” in the portlet on the right hand side. I encourage you to review the bugs you’ve reported and see if they are still relevant (are they fixed or no longer valid?) or could benefit from more information (updated steps to recreate the bug?). Additionally, if the bug’s status is New you could ask a fellow Ubuntu user to recreate the bug and set it to Confirmed.

Ubuntu08 Sep 2011 08:38 am

I’ve talked about preventing bugs from being reported by apport and creating duplicate signatures so the apport retracer can mark bugs as duplicates of another. There is another process for preventing bugs from being reported and that is writing bug patterns something I’ve given a class on.

When apport begins the bug reporting process it first checks to see if the bug being reported matches a pattern and if the bug does it redirects the reporter to the bug, or wiki page, matching that pattern. Additionally, the apport retracer helps us identify bug reports that would benefit from a pattern (those with 10 duplicates) by tagging them bugpattern-needed and subscribing the Ubuntu Bug Control team to the bug report.

After we write a bug pattern we should do three things to the bug report:

1) Remove the tag bugpattern-needed
2) Add the tag bugpattern-written
3) Unsubscribe Ubuntu Bug Control

While modifying the tag is essentially one operation in the Launchpad web interface there are still two steps involved here. This was two too many in my opinion! I wanted to write a bazaar plugin to modify the Launchpad bug report appropriately after the bzr branch with the pattern was pushed to Launchpad. I became extremely motivated yesterday when I saw about a dozen merge proposals from Vadim Rutkovsky (thanks!) for bug patterns.

So now there is a bazaar plugin in the bug patterns branch that will properly take care of a bug report once a pattern is written for it. To use it you need to have python-launchpadlib-toolkit installed, for working with the Launchpad API, and create a symlink to bugpattern_written.py in your ‘~/.bazaar/plugins/’ directory. Enjoy!

« Previous PageNext Page »