Ubuntu


Ubuntu19 Jul 2017 02:52 pm

I’ve recently made some changes to how do-release-upgrade, called by update-manager when you choose to upgrade releases, behaves and thought it’d be a good time to clarify how things work and the changes made.

When do-release-upgrade is called it reads a meta-release file from changelogs.ubuntu.com to determine what releases are supported and to which release to upgrade. The exact meta-release file changes depending on what arguments, –proposed or –devel-release, are passed to do-release-upgrade. The meta-release file is used to determine which tarball to download and use to actually perform the upgrade. So if you are upgrading from Ubuntu 17.04 to Artful then you are actually using the the ubuntu-release-upgrader code from Artful.

One change implemented some time ago was support for the release upgrade process to skip unsupported releases if you are running a supported release. For example, when Ubuntu 16.10 (Yakkety Yak) becomes end of life and you upgrade from Ubuntu 16.04 (Xenial Xerus) with “Prompt=normal” (found in /etc/update-manager/release-upgrades) then Ubuntu 16.10 will be skipped and you will be upgraded to Ubuntu 17.04 (Zesty Zapus). This ensures that you are running a supported release and helps to test the next LTS upgrade path i.e. from Ubuntu 16.04 to Ubuntu 18.04. Similarly, when Ubuntu 17.04 becomes end of life an upgrade from Ubuntu 16.04, with “Prompt=normal”, will upgrade you to Ubuntu 17.10.

I’ve also just modified the documentation regarding the ‘-d’ switch for ubuntu-release-upgrader and update-manager to make it clear that ‘-d’ is from upgrading from the latest supported release (Ubuntu 17.04 right now) to the development release of Ubuntu. The documentation used to incorrectly imply that any release could be updated to the development release, something that would be an unsafe upgrade path. Additionally, the meta-release-development and meta-release-lts-development files were modified to only contain information about releases relevant to the upgrade path. So meta-release-lts-development is currently empty and meta-release-development only contains information about Ubuntu 17.04 and Artful Aadrvark which will become Ubuntu 17.10.

I hope this makes things a bit clearer!

Ubuntu12 Jul 2017 10:48 am

The Ubuntu Error Tracker is really good at presenting information about the versions of packages affected by a crash. Additionally, it has current information about crashes regarding stable releases of Ubuntu in addition to the development release. Subsequently, it can be a great resource for verifying that a crash is fixed for the development release or for stable releases.

As a member of the Stable Release Updates team I am excited to see an SRU which includes a bug report either generated from a crash in the Ubuntu Error Tracker (identifiable by either the bug description or errors.ubuntu.com being in the list of subscribers) or with a link to a crash in the Ubuntu Error Tracker.

One example of this is a systemd-resolved crash which while the bug report was not created by the bug bridge does contain a link to a bucket in the Error Tracer. Using the bucket in the Error Tracker we were able to confirm that new version of the package did not appear there and subsequently was no longer experiencing the same crash.

Two crashes about libgweather, bug 1688208 and bug 1695567, are less perfect examples because libgweather ended up causing gnome-shell to crash and the Error Tracker buckets for these crashes only show the version of gnome-shell. But fortunately apport gathers information about the package’s (gnome-shell in this case) dependencies and as the maintainer of the Error Tracker I can query its database. Using that ability I was able to confirm, by querying individual instances in the bucket, that the new version of libgweather did in fact fix both crashes.

So whether you are fixing crashes in the development release of Ubuntu or a stable release keep in mind that its possible to use the Error Tracker to verify that your fix works.

Ubuntu21 Jun 2017 10:40 am

The other day some of my fellow Ubuntu developers and I were looking at bug 1692981 and trying to figure out what was going on. While we don’t have an answer yet, we did use some helpful tools (at least one of which somebody hadn’t heard of) to gather more information about the bug.

One such tool is lp-bug-dupe-properties from the lptools package in Ubuntu. With this it is possible to quickly find out information about all the duplicates, 36 in this case, of a bug report. For example, if we wanted to know which releases are affected we can use:

lp-bug-dupe-properties -D DistroRelease -b 1692981

LP: #1692981 has 36 duplicates
Ubuntu 16.04: 1583463 1657243 1696799 1696827 1696863 1696930 1696940
1697011 1697016 1697068 1697099 1697121 1697280 1697290 1697313 1697335
1697356 1697597 1697801 1697838 1697911 1698097 1698100 1698104 1698113
1698150 1698171 1698244 1698292 1698303 1698324 1698670 1699329
Ubuntu 16.10: 1697072 1698098 1699356

While lp-bug-dupe-properites is useful, in this case it’d be helpful to search the bug’s attachments for more information. Luckily there is a tool, lp-grab-attachments (also part of lptools), which will download all the attachments of a bug report and its duplicates if you want. Having done that you can then use grep to search those files.

lp-grab-attachments -dD 1692981

The ‘-d’ switch indicates I want to get the attachments from duplicate bug reports and the ‘-D’ switch indicates that I want to have the bug description saved as Description.txt. While saving the description provides some of the same capability as lp-bug-dupe-properties it ends up being quicker. Now with the attachments saved I can do something like:

for desc in $(find . -name Description.txt); do grep "dpkg 1.18.[4|10]" $desc;
done

...
dpkg 1.18.4ubuntu1.2
dpkg 1.18.10ubuntu2
dpkg 1.18.10ubuntu1.1
dpkg 1.18.4ubuntu1.2
...

and find out that a variety of dpkg versions are in use when this is encountered.

I hope you find these tools useful and I’d be interested to hear how you use them!

Ubuntu20 Mar 2015 09:27 am

As I hinted at in my last post, apport-noui, which will enable automatic crash reporting, is now available in the -proposed repository for Trusty. If you want to test it follow the instructions in the SRU bug report. Otherwise, it will be made available in -updates next week.

Ubuntu20 Feb 2015 02:53 pm

Now that apport-noui, a package to automatically report crashes to the Ubuntu Error Tracker without user interaction, has been proven to work well on Ubuntu devices I was wondering what it would take to get it running on my Mythbuntu 14.04 install as I was tired of getting the occasional apport dialog when I was trying to watch TV.

I had to backport a couple of apport fixes and also backported one whoopsie fix that will log the OOPS ID of any reported crashes to /var/log/syslog. I’ve put these updated versions of apport and whoopsie in my PPA, however they are acceptable for a Stable Release Update and depending on the interest I will upload them to the SRU queue.

I added my PPA to my 14.04 system:

sudo add-apt-repository ppa:brian-murray/ppa

I then installed the apport-noui package on it.

sudo apt-get install apport-noui

I’ve been running it for about a week now and looked in my /var/crash/ directory on my Mythtv system to discover a .crash and a correpsonding .uploaded file. The .uploaded file means that the crash was sent to the Ubuntu Error Tracker.

While I could inspect the .crash file on my system to see what it is about let’s look for the OOPS ID in /var/log/syslog.


Feb 20 10:38:54 flash whoopsie[8223]: Parsing
/var/crash/_usr_share_mythtv_metadata_Movie_tmdb3.py.110.crash.
Feb 20 10:38:54 flash whoopsie[8223]: Uploading
/var/crash/_usr_share_mythtv_metadata_Movie_tmdb3.py.110.crash.
Feb 20 10:38:56 flash whoopsie[8223]: Sent; server replied with: No error
Feb 20 10:38:56 flash whoopsie[8223]: Response code: 200
Feb 20 10:38:56 flash whoopsie[8223]: Reported OOPS ID
2ad9d3f0-b6b8-11e4-bf61-fa163e707a72

The crash can be found at the Error Tracker at https://errors.ubuntu.com/oops/2ad9d3f0-b6b8-11e4-bf61-fa163e707a72. On the problem instance page we can see a line labelled Problem and that is a link to the bucket for these crashes. These crashes seem to occur pretty frequently, so I’ve opened a Launchpad bug report corresponding to the crash.

Let me know if you think this is useful (or if you have any issues) and I’ll work on getting this into the Trusty and Utopic SRU queues.

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!

Next Page »