I’ve heard all this fuss about Unity and I’ve no real idea what it’s all about, so I thought I’d give it a try.  Today will be my first full day of using it (and the last for 2 weeks since I am heading out on vacation) and I will attempt to write up my experiences.  It’s a bit of a brain dump, but here follows day one!

First impressions

My initial impression is that it looks pretty slick, but not as pretty as KDE4.  I’m clicking around a bit to see what’s what and I’ve immediately noticed a few things that I will miss from KDE:

• There doesn’t seem to be a way to put widgets on the panel – I want my CPU/MEM/SWAP meter! (Some time later I found “indicators” in the Software Centre, there’s a system load indicator, but after installing there’s no obvious way of using it)
• I am used to ctrl-F<N> to switch virtual desktops, I can’t see a way of emulating that.  (Ok I found the setting an hour later, great)

Visual differences

One of the drivers for me to learn more about it is to be able to maintain the Launchpad Build Farm manager, which is written mostly using Twisted events.  When it was first put together by Celso to replace the old slave scanner, it was quite a tough task to slot it into the existing Launchpad code base without too much disruption.  He did a pretty good job, but now the code is in need of an overhaul as it scales quite badly.

There’s three main reasons that it scales badly:

1. It scans each builder in turn once per “cycle” that it wakes up to do its scan
2. It synchronously uploads build results, blocking further progress until the upload completes
3. It synchronously polls the builders before setting up Twisted Deferreds to do the actual dispatch in parallel.

Jelmer is currently tackling (2) above, and I plan on sprinting with Jono in a couple of weeks to tackle (3).

I started tackling (1) a while ago now as it was obvious there was a better way.  So now instead of polling each builder in turn, it sets up a separate Deferred event for each builder in the system and lets it fire independently of all the others.  Because the code is not really threaded, there are no race conditions or exclusivity to worry about and we get a couple of really big wins from this approach:

• If there’s any kind of exception during the scan, it only takes out the current scan cycle on a single builder, not all of them.  Other builders continue to dispatch quite happily.
• We can now overlap events better.  Previously, we did all the dispatching at the same time and that involves mostly sat waiting for the reset scripts to finish on the virtual builders (which sometimes take up to 30 seconds).  Now, we can kick that off and poll another builder or upload a build at the same time.  Throughput has increased slightly but the overall effect is dramatic on the build farm page as you no longer see builders idle for long periods even though there’s a big queue.

This code went live in production a month ago and we had a massive problem with it immediately that I had not thought of.  Because the builder reset events (which are a sub process) now happen in parallel with other non-Twisted events they get interrupted with SIGCHLD when the sub process finishes – this manifests itself as an EINTR exception in the middle of a comms operation with another builder.  We added some code to retry the operation in this case and it finally worked!  I’m really happy that this was the only problem.

However, the really, really big win in scalability will come with Jelmer’s fix which will land Real Soon Now.  This will remove the blocking that happens when uploading builds – a block that can last for over a minute for large uploads.  I can’t wait to see this branch land.

Here’s to more Twisted!

It also has the bonus that it doesn’t suffer from the bug where uploads sometimes hang with 1k to go, as on the regular FTP server.

Configure your dput.cf with these changes for Ubuntu:

method = sftp
incoming = ubuntu/
login = <your LP account name here>

For PPAs it’s similar, just make sure your fqdn and incoming are set appropriately.

Let me know in the comments how you get on.

At the end of the day I was feeling really unproductive and anxious about time wasted – I’d sit back and think, what did I do today?  I felt really busy but I can’t remember what the heck I’ve been doing! Even worse, I’d leave my office at the end of the day in a bad mood and the 30 seconds it takes to get back into the house is not enough to ease the tensions, which made it hard to interact with my wife and kids.  I want to reclaim that precious hour between finishing work and the kids going to bed!

So, what can I do about this?

Three things:

1. I made a conscious effort to finish my major work items 30 minutes before leaving the office and to spend those 30 minutes doing all the simple tasks that you know you need to sort out but never get around to doing.  This has had a dramatic affect on not only how I feel when I finish, but also I get the warm fuzzy feeling of having cleared out stuff that was niggling me at the back of my brain.

2. I have eschewed technology in favour of the classic pen and paper!  I used to keep TODO lists electronically, but I found this hard to keep up with as they were always hidden by other windows on another virtual desktop somewhere.  So now,  each week I start on a fresh piece of paper and write down all the things I know I need to do, with a little box next to them.  When I’ve done that task, I can put a great big satisfying tick next to it.  At the end of each day I can see visible progress.  This is very uplifting!  I start a new sheet each week so that the TODO list is not cluttered, and it also forces me to think of anything I missed.

3. Take regular breaks.  I know, this is easier said than done.  Michael Nelson put me on to the Pomodoro Technique which while I don’t follow religiously, does give some effective tips on how to time-box your activities.

If you’ve got any more tips, or used mine and found them useful, I’d love to hear about it!  Please leave a comment.

It turns out that this is quite hard because you need a secure environment to run the Bazaar recipe builder in.  Fortunately we already have the Launchpad Build Farm!  So, on January 11th the Soyuz and Codehosting teams, plus Launchpad Strategist Jono Lange and community contributor William Grant all met at the West Plaza Hotel in Wellington, New Zealand for a week-long coding sprint with the goal of getting a recipe build job through the build farm before the week was out.

The team hard at work

The amount of work was pretty sizeable, but we’d already done quite a lot of preparatory work before leaving so that non-Soyuz developers could get involved from day one.

We split the task into a few areas:

• Writing the code that runs on the build slave itself
• Job dispatching
• Job collection
• Job candidate selection
• Creating a generalised build infrastructure to make it easy to plug in new job types

The team split into coding pairs that mostly lasted the week and there were no bloodied noses!  We had a strict rule that no pair could contain two people from the same Launchpad team, so that we could spread the knowledge around better.  This worked out really well.

The local coffee shop certainly had plenty of custom that week!  But by the end of it, on Friday afternoon at about 5:45pm, we finally got a recipe build job to run through a local Launchpad instance on William’s laptop and eventually turned into a binary package.  Success!

We’ll be building on this work in the next couple of months so that it has a UI that will allow a user to click on a branch and get it built and uploaded to their PPA.  It’s all very cool!

Finally, huge thanks to everyone involved, including the hotel.  It was the best wifi/internet anyone had ever had at any hotel, ever.

Bjorn, William and Michael

The team celebrates after a long week

New features

• Multiple PPAs per person – split your packages into different repositories without the hassle of creating new LP users
• Karma for uploads! Distro and PPA uploaders (and the package creator if different) will be recognised for their work and get karma.
• Massively improved webservice APIs to control various operations, such as copying packages, manipulating builds, inspecting PPAs etc.  Allows script-based control of many soyuz-related operations.
• Hugely faster build farm scanner, builds are dispatched a LOT quicker now.  That means there’s less waiting around for your packages to get built.
• Private PPA subscriptions / tokens.  People can now control who is able to download their PPA software.
• Package sets and their upload ACLs implemented for Ubuntu.  Karmic and onwards will be using package sets for upload permissioning.
• Security in Soyuz. Complete support for the Canonical security team to use a private PPA and directly unembargo packages from it

3.0 UI

We also did a lot of complete page redesigns for 3.0:

• PPA page split into two pages; one user-focused, one developer-focused
• New build page, with a cleaner look
• New global /builders page; sortable table data and a time-based estimate of the queue sizes
• New distribution source package release page; much better presentation of data
• New distribution source package page; makes more use of upstream package description/logo etc.
• Distro series source package release page gets a new layout
• Builder +admin and builder +edit collapsed into a single page
• New builder page

But the work doesn’t stop here.  We’re already thinking about 4.0!

Many of the changes were complete page re-designs based on better knowledge of use-cases that has been gathered over the years.  There was certainly a lot of dust on some of them!

There are still some minor tweaks to be made, but all feedback is most welcome.

I know pretty much nothing about VMs so I was pretty pleased to come across this JeOS VMBuilder resource!  I got my first VM built pretty quick with it, but then, what next?  The instructions don’t tell me how to actually run up my new VM.

So, I had a little chuckle to myself when I saw this blog post from Dustin Kirkland just appear!  I’m going to try his suggestions out now and see how it works out, but it looks like just what I need.

It’s trivial to use:

>>> ubuntu = launchpad.distributions['ubuntu']
>>> main_archive = ubuntu.main_archive
>>> sources = main_archive.getPublishedSources(source_name='my_package_name')
>>> builds = sources[0].getBuilds()
>>> for build in builds:
...     build.rescore(score=1000)
...     build.retry()

`rescore` requires that you have buildd admin privileges.   `retry` simply requires that you have permission to upload the source.

A more advanced example is to fetch all builds that are failed in a series:

>>> karmic = ubuntu.getSeries(name_or_version="karmic")
>>> failed_states = (
...     'Failed to build',
...     'Dependency wait',
...     'Chroot problem',
...     'Failed to upload',
...     )
>>> builds = []
>>> for build_state in failed_states:
...     builds.extend(
...         karmic.getBuildRecords(build_state=build_state))

This will potentially return builds that are superseded so they need to be filtered to see if the build’s source is published.  This is something we’re going to fix soon, so that you can specify that you only want builds with published sources in the getBuildRecords() call.