Ubuntu04 Dec 2013 06:13 pm

One thing I remember being excited about when moving from Windows to Linux was using my middle mouse button to paste. I somewhat recently got a Apple Wireless Trackpad and lost this ability as there is no middle mouse button. (As far as I knew at the time, but it looks like the upper right corner is a middle click.) I discovered that I could set a three finger tap to middle click and subsequently paste by the following:

/usr/bin/xinput set-prop "Apple Wireless Trackpad" "Synaptics Tap Action" 2 3 0 0 1 3 2

However, running that on every reboot, and battery change in the trackpad was rather annoying. With the advent of upstart user jobs (the real point of this post) I thought one would be a good way to set this functionality.

I put the following in a file named magicpad-paste.conf in my ~/.config/upstart/ directory:

description "Enable three finger middle click with an Apple Trackpad"
author "Brian Murray

start on :sys:input-device-added NAME='"Apple Wireless Trackpad"'

script

DATE=$(date)
echo "$DATE Apple Wireless Trackpad detected"
# it seems that a sleep is needed for the device to become fully available
sleep 5
/usr/bin/xinput set-prop "Apple Wireless Trackpad" "Synaptics Tap Action" 2 3 0 0 1 3 2

end script

The hardest part was figuring out that a sleep was necessary for the device to become fully registered so that xinput would work.

Ubuntu07 Aug 2013 01:56 pm

For some time we’ve wanted to phase, gradually roll out, updates to expanding subsets of Ubuntu users so that we may monitor for regressions and stop the update process if there are any. The support for phased updates has existed in update-manager for a while, but we did not have the server side part implemented. Thanks to the work of Colin Watson, Evan Dandrea, and myself this is now done.

Who is participating?

Users of Ubuntu 13.04 who install updates with update-manager are automatically participating in this process. For every package, in -updates, update-manager will generate a random number and if that number is less than the Phased-Update-Percentage the package will be installed. One can opt out of the Phased Update process by adding ‘Update-Manager::Never-Include-Phased-Updates “True”;’ to the configuration file “/etc/apt/apt.conf”.

How does the Phased Update process work?

When a Stable Release Update is released to 13.04 it will have its phased update percentage initially set to 10%. A job is run, every 6 hours, in the data center that checks to see if there are any regression about the package, and if there are none then the phased update percentage will be incremented by 10%. The phased update percentage for a binary package is available at the publishing history page for it. Here is an example with apport. If there is no value for “Phased updates” then the update is fully phased at 100%.

What are the regression checks?

The Ubuntu Error Tracker (errors.ubuntu.com) has been modified to help us determine if there are any regressions about the package. We do this by checking to see if there are any crashes reported about the new version of the package that were not reported about the previous version of the package. (You can actually check this yourself using a query like: https://errors.ubuntu.com/api/1.0/package-version-new-buckets/?format=json&package=unattended-upgrades&previous_version=0.76&new_version=0.76ubuntu1) Additionally, we check the error tracker to see if there is an increased rate of crashes about the package. This is done by examining the quantity of errors reported today and comparing it to the average number of crashes per day for the past two weeks multiplied by the portion of the day that has passed.

If either of these types of regressions are detected then the phasing of the update is stopped by setting it to 0. This will prevent other users from receiving the updated version of the package. There is also a report of packages currently undergoing phasing that displays the phased update percentage for the package and any detected regressions. Additionally, an email is sent to the signer of the package (uploader) and its creator (uploader or sponsee). The email notifies them of the problem and that phasing of the update has been stopped.

There is support in the phased-updater for overriding specific problems, for example if we determine that a regression was not introduced in a specific version of a package. It also keeps track of emails sent so that we do not send an email about the same problem more than once.

If you encounter any issues as a user installing updates or as a developer who has uploaded packages please let me know.

Ubuntu24 May 2013 10:50 am

One of the earliest things I did when becoming involved in Ubuntu community was to participate in the Stable Release Update verification process. Many Stable Release Updates are easy to verify and once the verification is done the package is quickly released to -updates and Ubuntu users everywhere.

Let’s look at a specific example:

The application youtube-dl no longer works on Ubuntu 12.04 due to a change in the format of urls for videos. This is terrible as who doesn’t like to download videos! Looking at the bug report we can see that the test case is quite simple, on an Ubuntu 12.04 system (for this bug you could even use a virtual machine or a chroot) with youtube-dl installed try downloading something and it will fail. It is important that we also verify that we are impacted by the bug, because something may be different about our configuration, setup, or hardware.

Once we have verified the failure we then enable the -proposed repository and install the proposed version of youtube-dl. We want to only install that package from proposed as it is possible that other packages in proposed may affect the behavior of the package we are testing. Then we run through the test case and verify that the bug is fixed. It is also helpful to test the package some and ensure that no new bugs were introduced. However, we (the Ubuntu SRU team) also have errors.ubuntu.com to facilitate finding these regressions.

If the bug is fixed we then change the bug tags from ‘verfication-needed’ to ‘verification-done’. For bugs with SRUs for multiple releases we want to use ‘verification-done-precise’ or whatever the release code name is. Then after the package has been in -proposed for 7 days, a member of the Stable Release Updates team will release the package from -proposed to -updates. At which point the fix will be available to Ubuntu users everywhere!

You can find Stable Release Update bugs needing verification by searching for bugs tagged ‘verification-needed’ about the release of Ubuntu you are using, or by viewing the Pending SRU report. Bugs in blue or golden need verification. If you happen to verify any bugs and think a package is ready to be released ping me, bdmurray, on #ubuntu-bugs on Freenode and I’ll have a look and release the package for you.

Ubuntu11 Mar 2013 09:58 am

As I previously mentioned I’ve been working some on the Ubuntu Error Tracker. A bit ago, I added the ability to search for crashes about a source package using a url like http://errors.ubuntu.com/?package=usb-creator. A source package can also be selected by choosing the package in the package selection drop down box and then entering the specific package name.

In addition to this there is now a selection for ‘packages subscribed to by’. This selection allows you to input a Launchpad user name, for example brian-murray, and see package’s bug listing page to subscribe to bugs about that package. If you don’t want more bug mail but still desire this functionality of errors.ubuntu.com consider setting up a subscription for bug reports that only have the tag ‘bugs-will-never-ever-ever-have-this-tag’.

Just as with the package parameter, you can append ‘user=brian-murray’ to the errors.ubuntu.com url which makes it easier to share queries. Naturally, this also works for teams in Launchpad, like the Foundations Bugs team. However, because this particular team is subscribed to hundreds of packages, we’ve created a table in the database for caching the packages for some teams instead of querying Launchpad for the list of packages every time.

During vUDS I gave a lightning talk where you can see this new feature in action and some of my comic book collection!

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.

Next Page »