Monthly Archives: April 2013

Team Workflow with bzr and Launchpad

I was trying to explain how our team did workflow to a former colleague last week and I so I started thinking about all the different workflows I’ve dealt with in my career. This one is by far my favorite, although I know it’s not git which everyone loves, I’m curious what workflows other groups use with launchpad. Take a look at this one and let me know, can our team do anything better, can yours?

First a brief note about our team at Canonical. We work on “premium” customer-facing projects, typically on ARM based hardware. We are downstream from Ubuntu for the most part, and although we do send fixes upstream when it makes sense, often we make customizations to packages that cannot go upstream. I’ll use a real-world example for this workflow explanation, we have a platform where we want to remove the user list, help menu entry, and the logout menu enty from the session indicator, so we needed to modify indicator-session to do so.

The tl;dr version of our workflow is Decentralized with shared mainline, with parts of Decentralized with automatic gatekeeper added.

Setup a Shared Master (mainline)

Grab the source for indicator-session for the distroseries we’re based on, precise in this case. We usually grab it from launchpad or apt-get source if launchpad’s precise copy is out of date. This code gets pushed to lp:~project-team/project/indicator-session. This is now the master/mainline version. Everyone on the team has write access to this, provided they follow team rules.

Setting Up My Local Branch

I have a pbuilder already setup for our project usually, so my first step is to setup my local tree. I like to use a two level hierarchy here so that builds don’t “pollute” my main project area where I have dozens of different branches checked out. So I setup a subdirectory and checkout a copy to master.

cd ~/Projects/project-precise-amd64
mkdir indicator-session
cd indicator-session
bzr branch lp:~project-team/project/indicator-session master

Now I branch master, if this wasn’t a fresh checkout, I would bzr pull in master first.

bzr branch master remove-buttons

Make Changes

At this point we make fixes or whatever changes are needed. The package is built, changes are tested, and lintian is run (this one gets forgotten many times).

We have a few goals to meet for changes, we don’t always succeed, but here they are:

  1. No new lintian errors, if it’s a new package that we made, 0 is better.
  2. If the package has unit tests, add a new test case to cover what we just fixed/changed.
  3. Patches should have minimal DEP3 headers.
  4. Coding style should follow upstream.
  5. No new compiler warnings without explanation.
  6. Good changelog entries with bug numbers if applicable. Entries should list what files were modified. Distroseries set to UNRELEASED still (more on why later).

A note on lintian, Jenkins is capable of rejecting packages with lintian errors. We have this disabled because we need to fix the errors that crept in first when we didn’t follow this rule.

Push to a Remote Branch for Review

We code review everything we do, so the next step is to make the branch public for a review.

bzr commit -m "good message, usually we just use the changelog entry" --fixes lp:BUGNUM
bzr push lp:~project-team/project/indicator-session-remove-buttons

Setup a Code Review

Everything is reviewed and all reviews are sent to the team, though the onus is on the submitter to ping appropriate people if they don’t get a timely review. For code reviews, everyone is expected to provide a good explanation of what they’re doing and what testing was done.

We also have one of the “enhancements” here as we have a Jenkins instance (similar to this one) setup for some projects and Jenkins gets to “vote” on the review. Packages that fail to build or fail unit tests are marked as “Rejected” in the review by Jenkins.

Merge Back to Master

After the review is approved, the code submitter merges the code and commits it up to the mainline. I’m paranoid about master changing, although the push will fail if it did, so I always update it first.

We have to also fix the distroseries back. We do this on our team because it reduces the chance that someone will dput a package that is built from a local or non-master branch. If somone were to try and dput the changes file built from the remove-buttons branch, it would fail. We really want the archive to only have packages built from master, it’s more repeatable and easier to track changes.

cd ~/Projects/project-precise-amd64/indicator-session
cd master
bzr pull
bzr merge ../remove-buttons
dch -e (modify distroseries from UNRELEASED to precise)
debcommit -r
bzr push :parent

Jenkins Does dput

Our team is slowly moving into the world of Jenkins and build/test automation, so we have Jenkins watching the master branch for interesting projects and it will manage the dput for us. This also provides a final round of build testing before we dput.

Some teams have autolanding setup, that is when the review is approved, the Jenkins instance will do the merge. For now, we’ve kept a human in the loop.

Update the Bug

It is annoying to look at a bug 3 months after you fixed it and wonder what version it’s fixed in. Although the debian/changelog tracks this, we generally always add a bug comment saying when a bug was fixed. For the most part people usually just paste the relevant changelog entry into the bug and make sure it’s marked as Fix Committed.

Tagged , , ,

dconf Settings: defaults and locks

Last year I worked on a project where I was playing around with system-wide default settings and locks and I thought I’d share a post based on some of my notes. Most all of what I will mention here is covered in depth by the dconf SysAdmin guide, so if you plan on using this, please read that guide as well. UPDATE: Gnome has moved all the dconf stuff into the Gnome SysAdmin guide, it’s a bit more scattered now, but there.

For most everyone, you have just one dconf database per user. It is a binary blob and it’s stored in ~/.config/dconf/user. Anytime you change a setting, this file gets updated. For system administrators who may want to set a company-wide default value, a new dconf database must be created.

Create a Profile

The first step in setting up other databases is to create a dconf profile file. By default you don’t need one since the system uses the default database, user.db, but to setup other databases you will. So create a file called /etc/dconf/profile/user and add the list of databases that you want. Note that this list is a hierarchy and that the user database should always be on top.

For this example, I will create a company database and a division database. The hierarchy implies that we will have company-wide settings, perhaps a wallpaper, settings on top that are specific to the division, perhaps the IP of a proxy server that’s geographically specific, and each user will have customized settings on top of that.

To create a profile, we’ll do the following:

mkdir -p /etc/dconf/profile

and edit /etc/dconf/profile/user, then add:

user-db:user
system-db:division
system-db:company

Keyfiles

(Note: I am doing this on a relatively clean precise install using a user that has not changed their wallpaper setting, that is important later)

Once you have created the profile hierarchy, you need to create keyfiles that set the values for each database. For this example, we will just set specific wallpaper files for each hierarchy. This is done with key files:

mkdir -p /etc/dconf/db/division.d/

and edit /etc/dconf/db/division.d/division.key, add the following:

[org/gnome/desktop/background]
picture-uri='file:///usr/share/backgrounds/Flocking_by_noombox.jpg'

Next we’ll create the company key file:

sudo mkdir -p /etc/dconf/db/company.d/

and edit /etc/dconf/db/company.d/company.key, add the following:

[org/gnome/desktop/background]
picture-uri='file:///usr/share/backgrounds/Murales_by_Jan_Bencini.jpg'

Finally, you need to run sudo dconf update so that dconf sees these changes.

After running dconf update, you will see two changes. The first and most obvious change is that the background is now a bunch of Flocking birds, not the Precise default. The second change is that you will see two new binary dconf database files in /etc/dconf/db, one called company and one called division. If you don’t see these changes then you did something wrong, go back and check the steps.

flocking

Since I have no default set the division’s default takes precedence

The current user and any new users will inherit the Division default wallpaper, Flocking. However, the user still may change the wallpaper to anything they want, and if they change it, that change will be set in the user database, which takes precedence. So this method gives us a soft-default, a default until otherwise modified. If you are trying this test on a user who has already modified the wallpaper, you will notice that it didn’t change due to this precedence.

If we want to force all users, new and existing, to get a specific wallpaper, we need to use a lock.

Locks

For this example, let’s assume that the IS department for our division really really likes the Flocking picture and doesn’t want anyone to change it. In order to force this, we need to set a lock. A lock is simple to make, it just specifies the name of the key that is locked. A locked key takes precedence over all other set keys.

Before doing this, I will use the wallpaper picker and select a new wallpaper, this will take precedence, until the lock is created. I picked Bloom for my test.

I like flowers more than birds.

I like flowers more than birds.

Now it’s time to make the lock, because the IS department really doesn’t like flowers, so we create the lock as follows.

sudo mkdir -p /etc/dconf/db/division.d/locks/

and then edit /etc/dconf/db/division.d/locks/division.lock (note file name doesn’t really matter) and add the following line:

/org/gnome/desktop/background/picture-uri

After saving the file, run sudo dconf update. Once doing so, I’m again looking at birds, even though I modified it in my user database to point to Bloom.

Lock file forces me to use the Division settings

Lock file forces me to use the Division settings

One interesting thing to note, any changes the user is making are still being set in their dconf user db, but the lock is overriding what is being seen from outside dconf. So if I change the wallpaper to London Eye in the wallpaper picker and then remove the lock by simply doing sudo rm division.lock && sudo dconf update, I immediately get the London Eye. So it’s important to keep this in mind, the user db is being written into, but the lock is in effect masking the user db value when the setting is read back.

London Eye wallpaper is shown after I remove the lock

London Eye wallpaper is shown after I remove the lock

Lock Hierarchy

Lock hierarchy is interesting, in that the lowermost lock takes precedence. What this means is that if we lock both the company and division wallpapers, we will see the company one. In the example below I set locks on the wallpaper key for both databases, and I end up seeing Murales, the company default.

Company setting takes precedence

Company setting takes precedence with both locked

 

Locks Without Keys

It is also possible to set a lock on a hierarchy without a corresponding default key. In this instance the system default is used and the user is unable to change the setting. For this example, I set a company lock but removed the company key. The resulting wallpaper is the system default.

System default wallpaper for Precise is seen

System default wallpaper for Precise is seen

What Value is Seen – A Quiz

If you’d like to test your knowledge of what key will take precedence when read from dconf, follow the quiz below, answers are at the bottom. For each scenario, see if you can figure out what wallpaper the user will see, assume the same database hierarchy as used in the example.

  1. User Wallpaper: unset, Division Wallpaper: Flock, Company Wallpaper: Murales
  2. User Wallpaper: London Eye, Division Wallpaper: Flock, Company Wallpaper: Murales
  3. User Wallpaper: London Eye, Division Wallpaper: Flock, Company Wallpaper: Murales, Lock file for Company Wallpaper setting
  4. User Wallpaper: London Eye, Division Wallpaper: Flock, Company Wallpaper: Murales, Lock file for Division and Company Wallpaper setting
  5. User Wallpaper: London Eye, Division Wallpaper: Flock, Company Wallpaper: unset, Lock file for Division and Company Wallpaper setting

Answers: Flock, London Eye, Murales, Murales, Default for Precise

Testing

Some notes about testing this if you are trying it:

    • Creating new users and logging in as them is a good way to see what settings are shown, the wallpaper is a great visual test as it’s easy to verify.
    • Do not do this on your development box. I screwed up my settings right before I was going to give a demo. I’d recommend a VM. If you do screw something up, check .xsession-errors, that’s where my problem was apparent.

Summary

If you’re a system administrator or you really like pictures of birds, dconf keyfiles and locks are the correct mechanism to make settings that are defaults, soft or hard. Hopefully this has been illustrative on how they work. I’d recommend playing with them in a VM and once you understand the hierarchies and locking, they should be pretty easy to use.

Tagged , ,

Announcing a Gopher Client for Ubuntu Touch

I’ve been wanting to work on an app for Ubuntu Touch for awhile now and so I finally started on it this weekend. I’ve really been swayed by all the arguments about not re-inventing things that have gone on around Ubuntu Touch, so that got me thinking that we really need a gopher client. After all gopher is “faster and more efficient and more organized” than the web, and we could all use more organization.

So with that in mind, here are the first screenshots from my Gopher client:

gopher

Right now this is a very early release. I am still fighting with getting rcs setup locally so I’m not quite ready to share it, but when it’s up, I’ll host a uuencoded tarball on my compuserve page.

I hope that 0.2 will add more features, including:

  1. Veronica search built into the dash
  2. Support for more modern themes, including Green on Black and Yellow on Blue.
  3. EBCDIC support (IBM phones only)
  4. Automated image to ASCII graphics conversion

Once this app is finished, I plan on dealing with the lack of the twitter app. I really don’t understand the issue here, we’ve had the finger protocol since 1977 and it works fine, other than the awkward discussions it can lead to.

 

Tagged