Debian/Ubuntu Packages for PostgreSQL 9.2 Beta 1

The first Beta of the upcoming PostgreSQL 9.2 was released yesterday (see announcement). Your humble maintainer has now created packages for you to test. Please give them a whirl, and report any problems/regressions that you may see to the PostgreSQL developers, so that we can have a rock solid 9.2 release.

Remember, with the postgresql-common infrastructure you can use pg_upgradecluster to create a 9.2 cluster from your existing 8.4/9.1 cluster and run them both in parallel without endangering your data.

For Debian the package is currently waiting in the NEW queue, I expect them to go into experimental in a day or two. For Ubuntu 12.04 LTS you can get packages from my usual PostgreSQL backports PPA. Note that you need at least postgresql-common version 0.130, which is available in Debian unstable and the PPA now.

I (or rather, the postgresql-common test suite) found one regression: Upgrades do not keep the current value of sequences, but reset them to their default value. I reported this upstream and will provide updated packages as soon as this is fixed.

Tags: , , , ,

PyGObject 3.3.1 released

This announcement comes very late (a week after release), but better late than never..

The first PyGObject 3.3 series release is now out, with lots of yummy fixes and improvements. Dieter, Sebastian, and I went through a round of bugzilla spring cleaning to clean up old bugs, fix simple bugs, and apply good patches that were waiting, so as a result the patch queue is now almost empty and PyGObject works better than ever.

There was also quite some work on the test suite: it became a lot stricter and robust, and now also enforces PEP8 compatibility and absence of pyflake errors of the code.

One small but handy new feature is that the freeze_notify() and handler_block() methods are now context managers, i. e. they automatically call the corresponding thaw_notify()/handler_unblock() at the end of the with statement in an exception-safe way. ((#672324)

There are almost no API changes in this release, so it should work fine with GNOME 3.4 and applications developed with pygobject 3.2. The one exception is the removal of the Gobject.get_data() and Gobject.set_data() methods. They were prone to errors and crashes as they are not safely bindable, and in Python you can and should just use normal Python object attributes instead.

Complete list of changes:

  • GSettings: allow extra keyword arguments (Giovanni Campagna) (#675105)
  • pygtkcompat: Correct Userlist module use (Jose Rostagno) (#675084)
  • Add release-news make rule (Martin Pitt)
  • Add “make check.nemiver” target (Martin Pitt)
  • Test flags and enums in GHash values (Martin Pitt) (#637466)
  • tests: Activate test_hash_in and apply workaround (Martin Pitt) (#666636)
  • Add special case for Gdk.Atom array entries from Python (Martin Pitt) (#661709)
  • test_gdbus: Call GetConnectionUnixProcessID() with correct signature (Martin Pitt) (#667954)
  • Add test case for Gtk.ListStore custom sort (Martin Pitt) (#674475)
  • GTK overrides: Add missing keyword arguments (Martin Pitt) (#660018)
  • Add missing override for TreeModel.iter_previous() (Martin Pitt) (#660018)
  • pygi-convert.py: Drop obsolete drag method conversions (Martin Pitt) (#652860)
  • tests: Replace deprecated assertEquals() with assertEqual() (Martin Pitt)
  • Plug tiny leak in constant_info_get_value (Paolo Borelli) (#642754)
  • Fix len_arg_index for array arguments (Bastian Winkler) (#674271)
  • Support defining GType properties from Python (Martin Pitt) (#674351)
  • Handle GType properties correctly (Bastian Winkler) (#674351)
  • Add missing GObject.TYPE_GTYPE (Martin Pitt)
  • Fix test_mainloop.py for Python 3 (Martin Pitt)
  • Make callback exception propagation test stricter (Martin Pitt) (#616279)
  • Add context management to freeze_notify() and handler_block(). (Simon Feltman) (#672324)
  • Add support for GFlags properties (Martin Pitt) (#620943)
  • Wrap GLib.Source.is_destroyed() method (Martin Pitt) (#524719)
  • Fix error message when trying to override a non-GI class (Martin Pitt) (#646667)
  • Fix segfault when accessing __grefcount__ before creating the GObject (Steve Frécinaux) (#640434)
  • Do not bind gobject_get_data() and gobject_set_data() (Steve Frécinaux) (#641944)
  • Add test case for multiple GLib.MainLoop instances (Martin Pitt) (#663068)
  • Add a ccallback type which is used to invoke callbacks passed to a vfunc (John (J5) Palmieri) (#644926)
  • Regression test: marshalling GValues in GHashTable (Alberto Mardegan) (#668903)
  • Update .gitignore (Martin Pitt)
  • Fix “distcheck” and tests with out-of-tree builds (Martin Pitt)
  • Add a pep8 check to the makefile (Johan Dahlin) (#672627)
  • PEP8 whitespace fixes (Johan Dahlin) (#672627)
  • PEP8: Remove trailing ; (Johan Dahlin) (#672627)
  • tests: Replace deprecated Python API (Martin Pitt)
  • Fail tests if they use or encounter deprecations (Martin Pitt)
  • Do not run tests in two phases any more (Martin Pitt)
  • test_overrides: Find local gsettings schema with current glib (Martin Pitt)
  • Add GtkComboBoxEntry compatibility (Paolo Borelli) (#672589)
  • Correct review comments from Martin (Johan Dahlin) (#672578)
  • Correct pyflakes warnings/errors (Johan Dahlin) (#672578)
  • Make tests fail on CRITICAL logs, too, and apply to all tests (Martin Pitt)
  • Support marshalling GI_TYPE_TAG_INTERFACE (Alberto Mardegan) (#668903)
  • Fix warnings on None values in added tree/list store rows (Martin Pitt) (#672463)
  • pygtkcompat test: Properly clean up PixbufLoader (Martin Pitt)

Tags: , , ,

QA changes for Ubuntu 12.04

Half a year ago I blogged about the changed expectancies and processes to improve quality of the development release which we discussed at the UDS in Orlando: A promise that we don’t break the development version, regressions are not to be tolerated, acceptance criteria for Canonical upstreams. For that we introduced the Stable+1 team, actually did some reversions of broken packages, our QA team set up rigorous daily installation image and upgrade tests, and the code development process for Unity and related project was changed to enforce buildability and passing automatic tests with each and every change to trunk.

To be honest I was still a tad sceptic back then when this was planned. These were a lot of changes for one cycle, the stable+1 team was a considerable resource investment (starting with three people fulltime in the first few months), and not to the least our friends in the DX team felt thwarted because they had to sit down for a long time developing tests, and then changing their habits and practices for development.

So was all that effort worth it?

One word: OMGCRYOUTLOUDYES!!!!

Just a random sample of goodness that this brought:

  • It was nice to not have to sit down for an hour every cople of days to figure out how to get back my desktop after the daily dist-upgrade bricked it.
  • Unity, compiz, and friends were remarkably stable. I still remember the previous cycles where every new version got differently crashy, broke virtual workspaces, and what not. The worst thing that happened this cycle is eternally breaking keybindings (or changing them around), but at least those usually had obvious workarounds.
  • As a result of those, I think we had at least one, maybe two magnitudes more testers of the daily development release than in previous cycles. So we got a lot of good bug reports and also patch contributions for smaller issues in Precise which we otherwise would not have discovered.
  • The daily dist-upgrade tests tremendously helped to uncover packaging problems which would break real-world upgrades out there by the dozens. It took months to fix the hardest one: upgrading 10.04 LTS to 12.04 LTS with all universe packages offered in software-center. This beast takes 13 hours to run, so nobody really did manual tests like that in the past cycles.
  • Due to the daily automatic CD image builds we dramatically reduced both the cost of fixing regressions as well as the emergency hackathons during milestone preparations. It is a lot easier to unbreak e. g. LVM setup or OEM install modes on our images when the regression happened just a day before than discovering it two days before a milestone is due, as again nobody tests these less common modes very often.
  • So as a result, I really think the investments into QA and the stable+1 teams already paid off twofold by giving us more time to work on the less critical fixes, avoiding lots of user frustration about broken upgrades, and generally making the daily development a lot more enjoyable. Or, as Rick Spencer puts it: Velocity, velocity, velocity!

    Despite these improvements, there are still some improvements I’m looking forward to in the next cycles: Thanks to Colin Watson we can now use -proposed as a proper staging area, and used this feature rather extensively in the past month. From my point of view, 90% of the remaining daily dist-upgrade failures were due to packages building on different architectures at vastly different times, or failing on some, but not all architectures (“arch skew”). This is something you cannot really predict or guard against as a developer when you upload large and potentially harmful packages directly to the development release, so uploading them to the staging area and letting everything build there will reduce the breakage to zero. This was successfully demonstrated with Unity, GTK, and other packages where arch skew pretty much always causes people to hose their desktop, as well as daily CD images not working.

    I’m also looking forward to combining the staging area with lots of automatic tests against reverse dependencies (e. g. testing the installer against a new GTK or pygobject before it lands), something we just barely tipped our toes in.

    I can’t imagine how we were ever able to develop our new releases the old way. :-)

    Precise Pangolin^W^WUbuntu 12.04, I’m proud of you! Go out and amaze people!

    Tags: , , ,

PyGObject 3.1.92 released

I just released a new pygobject version 3.1.92, for this week’s GNOME 3.3.92. This was my first-ever GNOME release (yay!), so please bear with me.

One highlight of this release is the new pygtkcompat module, contributed by Johan Dahlin. It provides backwards compatibility to pygtk far beyond to what the Gtk overrrides do, and also includes some shims for the old static webkit, gudev, and other modules. You can, and have to, enable them individually:

import gi.pygtkcompat

# enable "gobject" and "glib" modules
gi.pygtkcompat.enable()
gi.pygtkcompat.enable_gtk(version='3.0')

import glib
import gtk

Now you can use gtk.Window(), glib.timeout_add() etc. as before, and these will be transparently be converted into their modern GI counterparts. Please note that this is still in its infancy, and also mostly meant to ease the porting to GI. It’s not something we’ll keep forever.

Thanks to Michel Dänzer this release now also works properly on big-endian machines.

I mostly worked on fixing the calls of methods which take a list of GValues as arguments, such as Gtk.ListStore.insert_with_valuesv() and similar functions, and made the override API for tree models (append() etc. with providing row data) atomic wrt. the signals it sends out.

I want to thank Johan and Paolo for the nice teamwork with reviewing each other’s patches. That’s open source at its best!

Complete list of changes:

  • Correct Gtk.TreePath.__iter__ to work with Python 3 (Johan Dahlin)
  • Fix test_everything.TestSignals.test_object_param_signal test case (Martin Pitt)
  • Add a PyGTK compatibility layer (Johan Dahlin)
  • pygtkcompat: Remove first argument for get_origin() (Johan Dahlin)
  • Fix pygtkcompat.py to work with Python 3 (Martin Pitt)
  • GtkViewport: Add a default values for the adjustment constructor parameters (Johan Dahlin)
  • GtkIconSet: Add a default value for the pixbuf constructor parameter (Johan Dahlin)
  • PangoLayout: Add a default value for set_markup() (Johan Dahlin)
  • Gtk[HV]Scrollbar: Add a default value for the adjustment constructor parameter (Johan Dahlin)
  • GtkToolButton: Add a default value for the stock_id constructor parameter (Johan Dahlin)
  • GtkIconView: Add a default value for the model constructor parameter (Johan Dahlin)
  • Add a default value for column in Gtk.TreeView.get_cell_area() (Johan Dahlin)
  • Atomic inserts in Gtk.{List,Tree}Store overrides (Martin Pitt)
  • Fix Gtk.Button constructor to accept use_stock parameter (Martin Pitt)
  • Correct bad rebase, remove duplicate Window (Johan Dahlin)
  • Add bw-compatible arguments to Gtk.Adjustment (Johan Dahlin)
  • GtkTreePath: make it iterable (Johan Dahlin)
  • Add a default argument to TreeModelFilter.set_visible_func() (Johan Dahlin)
  • Add a default argument to Gtk.TreeView.set_cursor (Johan Dahlin)
  • Add a default argument to Pango.Context.get_metrics() (Johan Dahlin)
  • Fix double-freeing GValues in arrays (Martin Pitt)
  • Renamed “property” class to “Property” (Simon Feltman)
  • Fix Python to C marshalling of GValue arrays (Martin Pitt)
  • Correct the Gtk.Window hierarchy (Johan Dahlin)
  • Renamed getter/setter instance attributes to fget/fset respectively. (Simon Feltman)
  • Add Gtk.Arrow/Gtk.Window constructor override (Johan Dahlin)
  • Fix marshalling to/from Python to work on big endian machines. (Michel Dänzer)
  • Use gi_cclosure_marshal_generic instead of duplicating it. (Michel Dänzer)
  • Override Gtk.TreeView.get_visible_range to fix return (René Stadler)
  • Plug memory leak in _is_union_member (Paolo Borelli)
  • tests: Split TestInterfaces into separate tests (Sebastian Pölsterl)
  • README: Update current maintainers (Martin Pitt)

Tags: , , ,

power-usage-report: Find power drain causes

Part of our efforts to reduce power consumption in Ubuntu is to provide an easy tool to hunt down which programs and devices are to blame for inordinate power consumption. powertop’s interactive mode is pretty good for this if you are sitting in a train and want to tweak some knobs to max out battery life, but we need something more reproducible and noninteractive for developers who want to file proper bug reports.

So I wrote a little script power-usage-report which calls fatrace for measuring file access activity from programs, and powertop-1.13 to measure process and device wakeups, clean up and sort their ouput, and generate a report which is appropriate to attach to bug reports, send around, put into Jenkins for measuring daily progress, etc. It is now part of fatrace version 0.4, so today’s Precise upgrades will have it.

The output has several sections for disk access (which prevent the disk from spinning down), wakeups (causing CPU power usage), and device activity. Disk/wakeups are sorted in descending order by process:

$ sudo power-usage-report
Measurement will begin in 5 seconds. Please make sure that the
computer is idle, i. e. do not press keys, start or operate programs, and that
programs are not busy with active tasks other than the one you want to examine.
Starting measurement for 60 seconds...
Measurement complete. Generating report...
======= unity-panel-ser: 5 file access events ======
/usr/share/zoneinfo/UTC: 1 reads
/etc/timezone:
/usr/share/zoneinfo/posix/Europe/Berlin: 1 reads
/etc/localtime: 3 reads

======= gnome-settings-: 1 file access events ======
/etc/fstab: 1 reads

======= telepathy-gabbl: 1 file access events ======
/home/martin/.cache/wocky/caps/caps-cache.db: 1 reads

====== Wakeups ======
  30,9% ( 52,0)   compiz
  16,3% ( 27,4)   [iwlwifi] 
  12,5% ( 21,0)   [i915] 
   3,7% (  6,3)   [ahci] 
   2,3% (  3,9)   swapper/3
   1,2% (  2,0)   gvfs-afc-volume
[...]

====== Devices ======
An audio device is active 100,0% of the time:
hwC0D0 Conexant CX20585 

Recent USB suspend statistics
Active  Device name
100,0%	USB device 1-1.5.4.4 : USB Mouse (A4Tech)
100,0%	/sys/bus/usb/devices/1-1.5.4.2
100,0%	USB device 1-1.5.4 : Kinesis Keyboard Hub (PI Engineering)
  0,0%	USB device 1-1.5.2 : USB2.0 Hub Controller (NEC Corporation)

[...]

You can redirect output to a file, of course. The top header (“Starting measurement..” etc.) will go to stderr and thus not be part of the redirected output.

Tags: , , , , , , ,

fatrace: report system wide file access events

Part of our efforts to reduce power consumption is to identify processes which keep waking up the disk even when the computer is idle. This already resulted in a few bug reports (and some fixes, too), but we only really just began with this.

Unfortunately there is no really good tool to trace file access events system-wide. powertop claims to, but its output is both very incomplete, and also wrong (e. g. it claims that read accesses are writes). strace gives you everything you do and don’t want to know about what’s going on, but is per-process, and attaching strace to all running and new processes is cumbersome. blktrace is system-wide, but operates at a way too low level for this task: its output has nothing to do any more with files or even inodes, just raw block numbers which are impossible to convert back to an inode and file path.

So I created a little tool called fatrace (“file access trace”, not “fat race” :-) ) which uses fanotify, a couple of /proc lookups and some glue to provide this. By default it monitors the whole system, i. e. all mounts (except the virtual ones like /proc, tmpfs, etc.), but you can also tell it to just consider the mount of the current directory. You can write the log into a file (stdout by default), and run it for a specified number of seconds. Optional time stamps and PID filters are also provided.

$ sudo fatrace
rsyslogd(967): W /var/log/auth.log
notify-osd(2264): O /usr/share/pixmaps/weechat.xpm
compiz(2001): R device 8:2 inode 658203
[...]

It shows the process name and pid, the event type (Rread, Write, Open, or Close), and the path. Sometimes its’ not possible to determine a path (usually because it’s a temporary file which already got deleted, and I suspect mmaps as well), in that case it shows the device and inode number; such programs then need closer inspection with strace.

If you run this in gnome-terminal, there is an annoying feedback loop, as gnome-terminal causes a disk access with each output line, which then causes another output line, ad infinitum. To fix this, you can either redirect output to a file (-o /tmp/trace) or ignore the PID of gnome-terminal (-p `pidof gnome-terminal`).

So to investigate which programs are keeping your disk spinning, run something like

  $ sudo fatrace -o /tmp/trace -s 60

and then do nothing until it finishes.

My next task will be to write an integration program which calls fatrace and powertop, and creates a nice little report out of that raw data, sorted by number of accesses and process name, and all that. But it might already help some folks as it is right now.

The code lives in bzr branch lp:fatrace (web view), you can just run make and sudo ./fatrace. I also uploaded a package to Ubuntu Precise, but it still needs to go through the NEW queue. I also made a 0.1 release, so you can just grab the release tarball if you prefer. Have a look at the manpage and --help, it should be pretty self-explanatory.

Tags: , , , , , , , ,

PackageKit/aptdaemon “what-provides” plugin support

PackageKit has a “WhatProvides” API for mapping distribution independent concepts to particular package names. For example, you could ask “which packages provide a decoder for AC3 audio files?

$ pkcon what-provides  "gstreamer0.10(decoder-audio/ac3)"
[...]
Installed   	gstreamer0.10-plugins-good-0.10.30.2-2ubuntu2.amd64	GStreamer plugins from the "good" set
Available  	gstreamer0.10-plugins-ugly-0.10.18-3ubuntu4.amd64	GStreamer plugins from the "ugly" set

This is the kind of question your video player would ask the system if it encounters a video it cannot play. In reality they of course use the D-BUS or the library API, but it’s easier to demonstrate with the PackageKit command line client.

PackageKit provides a fair number of those concepts; I recently added LANGUAGE_SUPPORT for packages which provide dictionaries, spell checkers, and other language support for a given language or locale code.

However, PackageKit’s apt backend does not actually implement a lot of these (only CODEC and MODALIAS), and aptdaemons’s PackageKit compatibility API does not implement any. That might be because their upstreams do not know enough how to do the mapping for a particular distro/backend, because doing so involves distro specific code which should not go into upstreams, or simply because of the usual chicken-egg problem of app developers rather doing their own thing instead of using generic APIs.

So this got discussed between Sebastian Heinlein and me, and voila, there it is: it is now very easy to provide Python plugins for “what-provides” to implement any of the existing types. For example, language-selector now ships a plugin which implements LANGUAGE_SUPPORT, so you can ask “which packages do I need for Chinese in China” (i. e. simplified Chinese)?

$ pkcon what-provides "locale(zh_CN)"
[...]
Available   	firefox-locale-zh-hans-10.0+build1-0ubuntu1.all	Simplified Chinese language pack for Firefox
Available   	ibus-sunpinyin-2.0.3-2.amd64            	sunpinyin engine for ibus
Available   	language-pack-gnome-zh-hans-1:12.04+20120130.all	GNOME translation updates for language Simplified Chinese
Available   	ttf-arphic-ukai-0.2.20080216.1-1.all    	"AR PL UKai" Chinese Unicode TrueType font collection Kaiti style
[...]

Rodrigo Moya is currently working on implementing the control-center region panel redesign in a branch. This uses exactly this feature.

In Ubuntu we usually do not use PackageKit itself, but aptdaemon and its PackageKit API compatibility shim python-aptdaemon.pkcompat. So I ported that plugin support for aptdaemon-pkcompat as well, so plugins work with either now. Ubuntu Precise got the new aptdaemon (0.43+bzr769-0ubuntu1) and language-selector (0.63) versions today, so you can start playing around with this now.

So how can you write your own plugins? This is a trivial, although rather nonsense example:

from packagekit import enums

def my_what_provides(apt_cache, provides_type, search):
    if provides_type in (enums.PROVIDES_CODEC, enums.PROVIDES_ANY):
        return [apt_cache["gstreamer-moo"]]
    else:
        raise NotImplementedError('cannot handle type ' + str(provides_type))

The function gets an apt.Cache object, one of enums.PROVIDES_* and the actual search type as described in the documentation (above dummy example does not actually use it). It then decides whether it can handle the request and return a list of apt.package.Package objects (i. e. values in an apt.Cache map), or raise a NotImplementedError otherwise.

You register the plugin through Python pkg-resources in your setup.py (this needs setuptools):

   setup(
       [....]

       entry_points="""[packagekit.apt.plugins]
what_provides=my_plugin_module_name:my_what_provides
""",
       [...])

You can register arbitrarily many plugins, they will be all called and their resulting package lists joined.

All this will hopefully help a bit to push distro specifics to the lowest possible levels, and use upstream friendly and distribution agnostic APIs in your applications.

Tags: , , , , , ,

software-center now installs language support automatically

Suppose you install Ubuntu and select a language other than English (it’s known to happen!). This will install the general and the GNOME language packs, translated LibreOffice help, and so on. Now, install a KDE package or GIMP. You’ll notice that the new application is not translated and has no help available for your language. The next time you open the language selector from control-center it would tell you that you miss some language support and offer to install it, but this has been pretty indiscoverable, and we really can do better.

Today’s language-selector upload provides an aptdaemon plugin which automatically marks corresponding language support packages (translated help, dictionaries, spell checker modules, and translations themselves) for installation for any newly installed package, for all languages that are configured on your system.

For example, I have German and English locales on my system, and no KDE packages. Before, installing GIMP got me just that:

$ aptdcon -i gimp
The following NEW package will be installed (1):
gimp

Now it automatically installs the corresponding localized help:


$ aptdcon -i gimp
The following NEW packages will be installed (4):
gimp gimp-help-common gimp-help-de gimp-help-en

I am using aptdcon here as it points out the effect better than software-center doing all this in the background, but both use aptdaemon, so the effect will be the same.

Likewise, installing the first KDE-ish package will automatically install the KDE language packs:


$ aptdcon -i kate
The following NEW packages will be installed (71):
kate kate-data [...] kdelibs5-data [...] language-pack-kde-de language-pack-kde-en [...]

This is now possible because I rewrote the check-language-support logic from scratch; the old code was very slow, hard to read and a nightmare to maintain, and also depended on a lot of data files. The new code is very fast (figuring out all missing language support packages for all installed packages for all available locales takes 8 ms on my system), and has full test coverage.

While the check-language-support program still works (I rewrote it using the new API), it is easier and probably a lot faster to just use the new API now, e. g. in our Ubiquity installer.

Say goodbye to this 2.5 year old bug!

Tags: , , , ,

libxklavier is now introspectable

On my 8 hour train ride to Budapest last Sunday I finally worked on making libxklavier introspectable. Thanks to Sergey’s fast review the code now landed in trunk. I sent a couple of refinements to the bug report still, but those are mostly just icing on the cake, the main functionality of getting and setting keyboard layouts is working nicely now (see the example script).

Tags: , , , , ,

Precise’s QA improvements for Alpha-1

I’m the release engineer in charge for Precise Alpha 1 which is currently being prepared. I must say, this has been a real joy! The fruits of the new QA paradigm and strategy and the new Stable+1 maintenance team have already achieved remarkable results:

  • The archive consistency reports like component-mismatches, uninstallability, etc. now appear about 20 minutes earlier than in oneiric.
  • CD image builds can now happen 30 minutes earlier after the publisher start, and are much quicker now due to moving to newer machines. We can now build an i386 or amd64 CD image in 8 minutes! Currently they still need to wait for the slow powerpc buildd, but moving to a faster machine there is in progress. These improvements lead to much faster image rebuild turnarounds.
  • Candidate CDs now get automatically posted to the new ISO tracker as soon as they appear.
  • Whenever a new Ubuntu image is built (daily or candidate), they automatically get smoke-tested, so we know that the installer works under some standard scenarios and produces an install which actually boots.
  • Due to the new discipline and the stable+1 team, we had working daily ISOs pretty much every day. In previous Alphas, the release engineer(s) pretty much had to work fulltime for a day or two to fix the worst uninstallability etc., all of this now went away.

All this meant that as a release engineer almost all of the hectic and rather dull work like watching for finished ISO builds and posting them or getting the archive into a releasable state completely went away. We only had to decide when it was a good time for building a set of candidate images, and trigger them, which is just copy&pasting some standard commands.

So I could fully concentrate on the interesting bits like actually investigating and debugging bug reports and regressions. As the Law of Conservation of Breakage dictates, taking away work from the button pushing side just caused the actual bugs to be much harder and earned us e. g. this little gem which took Jean-Baptiste, Andy, and me days to even reproduce properly, and will take much more to debug and fix.

In summary, I want to say a huge “Thank you!” to the Canonical QA team, in particular Jean-Baptiste Lallement for setting up the auto-testing and Jenkins integration, and the stable+1 team (Colin Watson, Mike Terry, and Mathieu Trudel-Lapierre in November) for keeping the archive in such excellent shape and improving our tools!

Tags: , , ,