Tag Archives: ubuntu

pbuilder via pbuilder-scripts: A Short Howto

There are a myriad of ways to do cross-compiles and a smaller myriad that can do chrooted debian package builds. One of my favorite tools for this is pbuilder and I’d like to explain how (and why) I use it.

A pbuilder environment is a chrooted environment which can have a different distroseries or architecture than your host system. This is very useful, for example, when your laptop is running raring x64 and you need to build binaries for saucy armhf to run on Ubuntu Touch. Typically pbuilders are used to build debian packages, but they can also provide you a shell in which you can do non-package compilations. When you exit a pbuilder (typically) any packages you’ve installed or changes you’ve made are dropped. This makes it the perfect testing ground when building packages to ensure that you’ve defined all your dependencies correctly. pbuilder is also smart enough to install deps for you for package builds, which makes your life easier and also avoids polluting your development system with lots of random -dev packages. So if you’re curious, I recommend that you follow along below and try a pbuilder out, it’s pretty simple to get started.

Getting Setup

First install pbuilder and pbuilder-scripts. The scripts add-on really simplifies setup and usage and I highly recommend it. This guide makes heavy use of these scripts, although you can use pbuilder without them.

sudo apt-get install pbuilder pbuilder-scripts

Second, you need to setup your ~/.pbuilderrc file. This file defines a few things, mainly a set of extra default packages that your pbuilder will install and what directories are bind-mounted into your pbuilder. By default pbuilder scripts looks in ~/Projects, so make that directory at this point as well and set it in the .pbuilderrc file.

Add the following to .pbuilderrc, substitute your username for user:

BINDMOUNTS="${BINDMOUNTS} /home/user/Projects"
EXTRAPACKAGES="${EXTRAPACKAGES} pbuilder devscripts gnupg patchutils vim-tiny openssh-client"

I like having the openssh-client in my pbuilder so I can copy stuff out easier to target boxes, but it’s not strictly necessary. A full manpage for ~/.pbbuilderrc is also available to read about setting more advanced stuff.

Don’t forget to make the folder:
mkdir ~/Projects

Making your First Pbuilder

Now that you’re setup, it’s time to make your first pbuilder. You need to select a distroseries (saucy, raring, etc) and an architecture. I’m going to make one for the raring i386. To do this we use pcreate. I use a naming scheme here so that when I see the 10 builders I have, I can keep some sanity, I recommend you do the same, but if you want to call your pbuilder “bob” that’s fine too.

cd ~/Projects
pcreate -a i386 -d raring raring-i386

Running this will drop you into an editor. Here you can add extra sources, for example, if you need packages from a PPA. Any sources list you add here will be permanent anytime you use this pbuilder. If you have no idea what I mean by PPA, then just exit your editor here.

At this point pcreate will be downloading packages and setting up the chroot. This may take 10-30 minutes depending on your connection speed.

This is a good time to make coffee or play video games

This is a good time to make coffee or play video games

Using your pbuilder

pbuilders have two main use cases that I will cover here:

Package Builds

pbuilder for package builds is dead simple. If you place the package code inside ~/Projects/raring-x86, pbuilder will automagically guess the right pbuilder to use. Elsewhere and you’ll need to specify.

Aside: To avoid polluting the root folder, I generally lay the folders out like this:


Then I just do this

cd ~/Projects/raring-i386/project/project-0.52

This will unpack the pbuilder, install all the deps for “project” and then attempt to build it. It will exit the pbuilder (and repack it) whether it succeeds or fails. Any debs built will be up one level.

Other – via a Shell

The above method works great for building a package, but if you are building over and over to iterate on changes, it’s inefficient. This is because every time it needs to unpack and install dependencies (it is at least smart enough to cache the deps). In this case, it’s faster to drop into a shell and stay there after the build.

cd ~/Projects/raring-i386

This drops you into a shell inside the chroot, so you’ll need to manually install build-deps.

apt-get build-dep project

ptest also works great when you need to do non-package builds, for example, I build all my armhf test code in a pbuilder shell that I’ll leave open for weeks at a time.

Updating your pbuilder

Over time the packages in your pbuilder may get out of date. You can update it simply by running:

pupdate -p raring-i386

This is the equivalent of running apt-get upgrade on your system.


A few caveats for starting with pbuilder.

  • Ownership – files built by pbuilder will end up owned as root, if you want to manipulate them later, you’ll need to chown them back or deal with using sudo
  • Signing – unless you bind mount your key into your pbuilder you cannot sign packages in the pbuilder. I think the wiki page may cover other solutions.
  • Segfaults – I use pbuilders on top of qemu a lot so that I can build for ARM devices, however, it seems that the more complex the compile (perhaps the more memory intensive?) the more likely it is to segfault qemu, thereby killing the pbuilder. This happened to a colleague this week when trying to pbuild Unity8 for armhf. It’s happened to me in the past. The only solution I know for this issue is to build on real hardware.
  • Speed – For emulated builds, like armhf on top of x86_64 hardware (which I do all the time), pbuilds can be slow. Even for non-emulated builds, the pbuilder needs to uncompress itself and install deps every time. For this reason if you plan on doing multiple builds, I’d start with ptest.
  • Cleanup – When you tire of your pbuilder, you need to remove it from /var/cache/pbuilder. It also caches debs in here and some other goodies. You may need to clean those up manually depending on disk space constraints.


I’ve really only scratched the surface here on what you can do with pbuilder. Hopefully you can use it for package builds or non-native builds. The Ubuntu wiki page for pbuilder has lots more details, tips, and info. If you have any favorite tips, please leave them as a comment.

Tagged ,

Hacking the initrd in Ubuntu Touch

This week I’ve been hacking some of the initrd scripts in Ubuntu Touch and I thought that I’d share some of the things I learned. All of this work is based on using Image Update images, which are flashable by doing phablet-flash ubuntu-system. First, why would you want to do this? Well, the initrd includes a script called “touch” which sets up all of the partitions and does some first boot migration. I wanted to modify how this process works for some experiments on customizing the images.

Before getting started, you need the following packages installed on your dev box: abootimg, android-tools-adb, android-tools-fastboot

Note: I was told after posting this that it won’t work on some devices, including Samsung devices, because they use a non-standard boot.img format.

Getting the initrd

The initrd is inside the boot.img file. I pulled mine from here, but you can also get it by dding it off of the phone. You can find the boot partition on your device with the following scriptlet, taken from flash-touch-initrd:

for i in $BOOT; do                                                              
    path=$(find /dev -name "*$i*"|grep disk| head -1)                           
    [ -n "$path" ] && break                                                     
echo $path

Once you have the boot.img file by whatever means you used, you need to unpack it. abootimg is the tool to use here, so simply run abootimg -x [boot.img]. This will unpack the initrd, kernel and boot config file.

Unpacking and Hacking the initrd

Now that you have the initrd, you need to unpack it so you can make changes. You can do this with some cpio magic, but unless you have a UNIX-sized beard, just run abootimg-unpack-initrd . This will dump everything into a folder named ramdisk. (UNIX beard guys: mkdir ramdisk; cp initrd ramdisk; cd ramdisk; cat initrd | gzip -d | cpio -i)

To make changes, simply cd into ramdisk and hack away. For this example, I’m going to add a simple line to ramdisk/scriprts/touch. My line is

echo "mfisch: it worked!" > /dev/kmsg || true

This will log a message to /var/log/kern.log which can assist us to make sure it worked. Your change will probably be less trivial.


Repacking the initrd is simple. To repack, just run abootimg-pack-initrd [initrd.img.NEW] Once you do this you’ll notice that the initrd size is quite different, even if you didn’t make any changes. After discussing this with some people, the best I can figure is that the newly packed cpio file has owners and non-zero datestamps, which make it slightly larger. One clue, when compared to mkinitramfs, abootimg-pack does not use the -R 0:0 argument and there are other differences. If you want to do this the hard way, you can also repack by doing: cd ramdisk; find . | cpio -o -H newc | gzip -9 > ../initrd.img.NEW

Rebuilding the boot image

The size change we discussed above can be an issue that you need to fix. In the file bootimg.cfg, which you extracted with abootimg -x, there is a line called bootsize. This line needs to be >= the size of the boot.img (not initrd). If the initrd file jumped by 4k or so, like mine did, be sure to bump this as well. I bumped mine from 0x837000 to 0x839000 and it worked. If you don’t do this step, you will wind up with a non-booting image. Once you correct this, rebuild the image with abootimg:

abootimg --create saucy-new.img -f bootimg.cfg -k zImage -r initrd.img.NEW

I’ve found that if your size is off, it will sometimes complain during this step, but not always. It’s best to check the size of saucy-new.img with the line you changed in bootimg.cfg at this point.

Flashing and testing

To flash the new boot image, reboot the device and use fastboot.

adb reboot bootloader
fastboot flash boot saucy-new.img

Use the power button to boot the device now.

Once booted you can go check out the kern.log and see if your change worked.

Aug 13 16:11:04 ubuntu-phablet kernel: [    3.798412] mfisch: it worked!

Looks good to me!

Thanks to Stephane Graber and Oliver Grawart for helping me discover this process.

Tagged , , ,

Getting the PID and Process Name From a dbus Caller in C

Over the past few months, I’ve been working on a dbus service (powerd) for Ubuntu Touch. Something that came up recently was the need to get the PID of the processes that call us. We were using this for statistics purposes of tracking who was holding requests, until today, when we decided to go a different direction. So this code is not landed in powerd, but perhaps it is still useful to someone. So I present, how to get the PID and process name from someone that calls you on dbus, in C.

This code assumes a few things. You need to have a working server that handles a call of some sort. We will plug into that call to get the PID of the caller. With that in mind, let’s get started. If you want the version of powerd that does this full async, it’s here: lp:~mfisch/+junk/powerd-pids. Note that this code also incorporates some statistics creation for powerd that is not going to be put into trunk in the form that it is in this branch. Anyway, onto the code:

Create a dbus proxy to make the PID look-up request to

We need a dbus proxy object to talk to. This is the service where we can lookup the PID given then dbus name of the connection. I will connect to this proxy asynchronously. In my “main”, I start the connection:

    /* proxy for getting PID info */

And then finish it later, the main result here is that dbus_proxy is set so I can use it.:

dbus_proxy_connect_cb(GObject *source_object,
               GAsyncResult *res,
               gpointer user_data)
    GError *error = NULL;

    dbus_proxy = g_dbus_proxy_new_finish (res, &error);
    if (error) {
        g_warning("dbus_proxy_connect_cb failed: %s", error->message);
        dbus_proxy = NULL;
    else {
        g_debug("dbus_proxy_connect_cb succeeded");

In the call that your service handles, do the lookup synchronously

I have a synchronous lookup listed first, then an async one. You should use the async one because you’re a good coder… unless you need to block until you find out who is calling you for some reason. I’ve left some powerd-isms for the function call, the source is from the requestSysState method that powerd supports. We will use the dbus_proxy object we created above to request the PID.

handle_request_sys_state (PowerdSource *obj, GDBusMethodInvocation *invocation, int state)
    // get the name of the dbus object that called us
    owner = g_dbus_method_invocation_get_sender(invocation);
    if (dbus_proxy) {
        result = g_dbus_proxy_call_sync(dbus_proxy,
                g_variant_new("(s)", owner),
        if (error) {
            g_error("Unable to get PID for %s: %s", owner, error->message);
            error = NULL;
        else {
            g_variant_get(result, "(u)", &owner_pid);
            g_info("request is from pid %d\n", owner_pid);

Once we have the PID, we can lookup the command line by reading /proc/PID/cmdline, my powerd code does this in the async example below.

async dbus for fun and profit

As I stated, synchronous is bad because it makes everyone wait, so here’s the async version.

handle_request_sys_state (PowerdSource *obj, GDBusMethodInvocation *invocation, int state)
    // get the name of the dbus object that called us
    owner = g_dbus_method_invocation_get_sender(invocation);
        g_variant_new("(s)", dbus_name),

Here’s our callback where we handle the results, I left the code in that reads the process name from /proc. We have a utility function called sysfs_read that I used.

get_pid_from_dbus_name_cb(GObject *source_object,
               GAsyncResult *res,
               gpointer user_data)
    GError *error = NULL;
    GVariant *result = NULL;
    guint pid;
    gchar process_name[PROCESS_NAME_LENGTH] = "";
    gchar proc_path[64] = "";
    int ret;

    result = g_dbus_proxy_call_finish (dbus_proxy, res, &error);
    if (error) {
        powerd_warn("get_pid_from_dbus_name_cb failed: %s", error->message);
    else if (result) {
        g_variant_get(result, "(u)", &pid);
        /* safety check */
        if (pid != 0) {
            sprintf(proc_path, "/proc/%u/cmdline", pid);
            ret = sysfs_read(proc_path, process_name, PROCESS_NAME_LENGTH);
            if (ret < 0)
                powerd_debug("error reading process name from %s: %d",
                    proc_path, ret);
                strcpy(process_name, "UNKNOWN");
            g_debug("PID: %u, Process Name: %s", pid, process_name);
        else {
            /* not sure this can happen */
            powerd_debug("unable to get pid info");

With that magic, I can get output like this:

PID: 4434, Process Name: ./powerd-cli
PID: 4436, Process Name: ./powerd-cli

But what about Python?

C is too hard you say. If you got carpal tunnel just from reading that code, I have a simple python call to do this for you, synchronously.


import dbus
import sys

bus=dbus.SystemBus().get_object('org.freedesktop.DBus', '/org/freedesktop/DBus');
print dbus.Interface(bus, 'org.freedesktop.DBus').GetConnectionUnixProcessID(sys.argv[1]);

I use dbus-monitor to find someone interesting on dbus with this call. :1.17 looks like upower, so lets see if it worked:

mfisch@caprica:~$ ./foo.py :1.17
mfisch@caprica:~$ cat /proc/1988/cmdline

Looks right to me!

With the python, you can plug in the caller’s dbus name for “sys.argv[1]” and be on your way, or use the C code if you don’t want python’s overhead and think that managing pointers is entertaining.

Special thanks to Ted Gould who pointed me to this method.

Tagged ,

Being a MOTU

Back in October, I wrote a post about my process of becoming a MOTU. I’ve been pretty busy since October. First of all, I had this 9 month build finally finish:

Successfully signed dsc and changes files

Successfully signed dsc and changes files

Once things sort of settled down from that, I jumped back in to updating and syncing packages. This time I was mainly focusing on desktop packages, because that’s the group my mentor worked on. However, I wanted to get some different experiences, so I also worked on some new debian packages (one of which landed).

So after all this, I talked to a few people and it was suggested that I apply for MOTU. So I cleaned up my wikipage and applied for it. The DMB had a lot of questions in the meeting, but I guess I was persuasive enough because I was approved on June 6!

So what’s next? Personally, I want to keep doing updates, complete a SRU, land my other debian package, sponsor some packages, and help other people achieve their goal of being a MOTU also.

I feel that mentoring is probably one of the most important parts of being a MOTU, so even though I’m new, I’d love to help where I can. I can help by answering questions or helping with ideas of things to work on. Finding the work can sometimes be the hardest part, and the only path forward to becoming a MOTU is doing updates and syncs, so it’s critical to keep up the momentum. So if you’re working on this goal, find me on #ubuntu-motu as mfisch and we can chat.

Tagged , ,

powerd in Ubuntu Touch

The past few weeks I’ve been on loan to work on Ubuntu Touch, specifically the power daemon, powerd. Seth Forshee and I have been working to enhance the power daemon so that system services can interact with it to request that the device stay active, that is, that the device not suspend. The initial round of this work is complete and is landing today. (Note: There is a lot of low-level kernel interaction stuff landing in the code today too, that is not covered here)

What’s Landing

What’s landing today allows a system service, talking on the system bus, to request the Active system power state. We currently only have two states, Active and Suspend. When there are no Active state requests, powerd will drop the state to Suspend and suspend the device. This is best illustrated by showing how we use the states internally: For example, the user activity timer holds an Active state request until it expires at which point the request is dropped. The system then scans the list of outstanding state requests and if none are left, it drops the system to Suspend and suspends the system. Pressing the power button works in the same way, except as a toggle. When the screen is on, pressing the power button drops an active request, when off, it makes an active request.

For now, this ties screen state to system power state, although we plan to change that later. There is no way currently to request a display state independently of a system state, however that is planned for the future as well. For example, a request may be made to keep the screen at a specified brightness.

The API is subject to change and has a few trouble spots, but is all available to look at in the code here. Taking a look at the testclient C code or tester.sh will best illustrate the usage, but remember this is not for apps, it is for other system services. The usage for an app will be to request from a system service via an API something like “playVideoWithScreenOn()”, and then the system service will translate that into a system state request.

Trying it Out

If you want to play with it on your phone, use gdbus to take an active state request and you can block system suspend. You will need to install libglib2.0-bin on your phone if not already installed.

# request active state from PID 99 (a made-up PID). This returns a cookie, which you need to later drop the request. The cookie here is “1”

phablet@localhost:~$ sudo gdbus call --system --dest com.canonical.powerd --object-path\
   /com/canonical/powerd --method com.canonical.powerd.requestSysState 1 99
[sudo] password for phablet: 
(uint32 1,)

show the outstanding requests.

phablet@localhost:~$ sudo gdbus call --system --dest com.canonical.powerd --object-path /com/canonical/powerd --method com.canonical.powerd.listSysRequests
([(':1.29', 99), ('internal', 36)],)

now we pass in the cookie we received earlier and clear our request

phablet@localhost:~$ sudo gdbus call --system --dest com.canonical.powerd --object-path /com/canonical/powerd --method com.canonical.powerd.clearSysState 1

recheck the list

phablet@localhost:~$ sudo gdbus call --system --dest com.canonical.powerd --object-path /com/canonical/powerd --method com.canonical.powerd.listSysRequests
([('internal', 36)],)


If you want to see everything that is going on, check the powerd log file. sudo tail -f /var/log/upstart/powerd.log. For now we have it logging in debug mode, so it will tell you everything.

But My Device Isn’t Suspending

Even though we request suspend, we may not get to suspend, because it appears that at least on some devices (Nexus4 and maybe others) Android’s sensor service is holding a wakelock. We are also working on this issue.

<6>[ 1249.183061] lm3530_backlight_off, on: 0
<6>[ 1249.185105] request_suspend_state: sleep (0->3) at 1249179158043 (2013-05-21 16:38:57.769127486 UTC)
<4>[ 1249.185441] [Touch D]touch disable
<4>[ 1250.217488] stop_drawing_early_suspend: timeout waiting for userspace to stop drawing
<3>[ 1250.244132] dtv_pipe is not configured yet
--> <6>[ 1250.248679] active wake lock sns_periodic_wakelock
<6>[ 1250.248710] PM: Syncing filesystems...
<6>[ 1250.329741] sync done.

Next Steps

We have a bunch of stuff left to do here, the first obvious one is that using a monotonically increasing int for the cookie is not a great plan, so we will switch that to something like a UUID. We also need to send out dbus signals when the system goes into suspend so that services can react. We need to clean-up some of the dbus code while we’re doing that. Finally we plan on implementing display state requests using a similar model to the power state requests. Throughout all of this we need to start integration with the rest of the system.

Tagged , ,

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:



(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:


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:


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.


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.


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:


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


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.


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:


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.



Limiting LXC Memory Usage

I’ve been playing around with LXC over the past few weeks and one of the things I tried out was limiting the memory that the container is allowed to use. I didn’t plan on explaining all the ins-and-outs of LXC here, but a short description is that LXC provides a virtualizedish environment that is more than a chroot gives you, but less than a full-blown virtual machine. If you want more details, please check out stgraber’s blog post about LXC in 12.04.

Kernel Configuration

The first thing you need to do in order to limit memory usage for LXC is make sure your kernel is properly configured, you need the following flag enabled:


If you plan on also limiting swap space usage, you’ll also need:


These flags are enabled for me in my 12.10 kernel (3.5.0-22) and so presumably you’ll have them in 12.04.

Setting the Cap

First, I’m going to create my container. Following the instructions from stgraber’s blog post, and calling the container “memlimit”:

sudo lxc-create -t ubuntu -n memlimit

Once the container is built, we need to modify the config files. Look at /var/lib/lxc/memlimit/config. We need to add a few lines to that file. I’m going to limit memory to 512M and total usage or memory + swap to 1G. Note the second setting is for overall memory + swap, not just swap usage.

lxc.cgroup.memory.limit_in_bytes = 512M
lxc.cgroup.memory.memsw.limit_in_bytes = 1G

Now let’s start the container and get some debug info out of it to make sure these were set:

sudo lxc-start -n memlimit -l debug -o debug.out

The debug.out file will show up wherever you ran lxc-start from, so let’s see if it picked up our limits:

lxc-start 1359136997.617 DEBUG lxc_conf - cgroup 'memory.limit_in_bytes' set to '512M'
lxc-start 1359136997.617 DEBUG lxc_conf - cgroup 'memory.memsw.limit_in_bytes' set to '1G'

Looks good to me!

Note, I tried setting this once to 1.5G and it seems that the fields are only happy with whole numbers, it complained about 1.5G. That error message appeared in the same debug log I used above.

A list of more of the values you can set in here is available here.

Measuring Memory Usage

The view of /proc/meminfo inside the container and outside the container are the same. This means that you cannot rely on tools like top to show how much memory the container is using. In other words, when run inside the container top will correctly only show processes inside the container, it will also show overall memory usage for the entire system. To get valid information, instead we need to examine some files in /sys:

Current memory usage:

Current memory + swap usage:

Maximum memory usage:

Maximum memory + swap usage:

You can use expr to show it as kb or mb which is easier to read for me:

expr `cat memory.max_usage_in_bytes` / 1024

What Happens When the Limit is Reached?

When the cap is reached, the container simply behaves as if the system ran out of memory. Calls to malloc will start failing (returning -1), leading to strange and bad things happening. Dialog boxes may not open, you may not be able to save files, and more than likely where people didn’t bother to check the returned value from malloc (aka, everyone), you’ll get segfaults. You can alleviate the pressure like normal systems do, by enabling swap inside the container, but once that limit is reached, you’ll have the same problem. In this case the host system’s kernel should start firing up the OOM killer and killing stuff inside the container.

Here is my extremely simple test program to drive up memory usage, install gcc in your container and you can try it too:


int main(void) {
    int i;
    for (i=0; i&lt;65536; i++) {
        char *q = malloc(65536);
        printf ("Malloced: %ld\n", 65536*i);

You can simply compiled with: gcc -o foo foo.c

I used the following simple shell construct to watch the memory usage. This needs to be run outside the container and I ran it from the /sys directory mentioned above:

while true; do echo -n "Mem Usage (mb): " \&amp;\&amp; expr `cat memory.usage_in_bytes` / 1024 / 1024; echo -n "Mem+swap Usage (mb): " \&amp;\&amp; expr `cat memory.memsw.usage_in_bytes` / 1024 / 1024; sleep 1; done

With the above shell script runnint, I fired up a bunch of copies of foo one bye one. Here’s the memory usage from that script:

Running a few copies:

Mem+swap Usage (mb): 825
Mem Usage (mb): 511
Mem+swap Usage (mb): 859
Mem Usage (mb): 511

A new copy of foo is starting:

Mem+swap Usage (mb): 899
Mem Usage (mb): 511
Mem+swap Usage (mb): 932
Mem Usage (mb): 511
Mem+swap Usage (mb): 1010
Mem Usage (mb): 511

The OOM killer just said “Nope!”

Mem+swap Usage (mb): 814
Mem Usage (mb): 511
Mem+swap Usage (mb): 825
Mem Usage (mb): 511

At the point where the OOM killer fired up, I see this in my container:
[1] Killed ./foo

So the limits are set, and they’re working.


If you are using LXC or considering using LXC, you can use a memory limit to protect the host from a container run amok. You could also use it to test your code in an artificially restricted environment. In either case, try the tools above and let me know how it works for you.

Tagged , ,

Cairo Perf Testing on the Nexus 7

Last week I was running some cairo perf traces on the Nexus7. Cairo-perf traces are a great way to measure 2d graphics performance and to use those numbers to measure the effects of code, hardware, or driver changes. One other cool thing is that with this tool you can do a benchmark on something like Chromium or Firefox without even needing the application installed.

The purpose of this post is to briefly explain how to build the traces, how to run the tools on Ubuntu, and finally a quick look at some results on the Nexus7.

Before running the tools you need to get setup and build the traces. A full clone and build will use several gigs of disk space. Since the current N7 image only builds a 6G or so filesystem, you may want to build the traces in a pbuilder. The disk I/O on the N7 is also pretty slow, so I found that building in the pbuilder, even though it runs inside a qemu, is much faster on my Core i5 + SSD.

In the steps below I’ve tried to call out the things you can do to reduce the disk space.

Building the traces

1. Setup the build environment

sudo apt­-get install libcairo2-­dev lzma git

2. Grab the traces from git

git clone git://anongit.freedesktop.org/cairo­-traces

3. (Optional) Remove unused files to save on disk space. Don’t do this if you plan on submitting changes back upstream.

cd cairo-­traces
rm -­rf .git

4. Build the benchmarks, I used -j4 on my laptop and -j2 on the Nexus7. I didn’t really investigate the optimal value.

make -j4 benchmarks

5. The benchmark directory is now ready to use for traces. If you built it on a different system, you only need to copy over this directory. You can delete the lzma files if you want.

The traces you are pixman version specific, so if you have a Raring based system like the Nexus7, you can’t re-use them on a Precise based box.

Running cairo-perf-trace

1, Before you start, delete the ocitysmap trace from the benchmarks folder. It uses too much RAM and ended up locking up my N7.

2. If you are at the command line, connected via ssh for example, you need to set the display or it will segfault, simply run export DISPLAY=:0

3. Run the tool, I’d start first with a simple trace to make sure that everything is working.

CAIRO_TEST_TARGET=image cairo-­perf-­trace ­-i3 -­r ./benchmark/gvim.trace > ~/result_image.txt

In that command above we did a few things, first we set the cairo backend. Image is a software renderer, you probably want to use xlib or xcb to test hardware. If you don’t set the CAIRO_TEST_TARGET it will try all the back-ends, this will take a long long time and I don’t recommend doing it. A simple way to get the tool to list them all is to set it to a bad value, for example

mfisch@caprica:~$ CAIRO_TEST_TARGET=mfisch cairo-perf-trace
Cannot find target 'mfisch'.
Known targets: script, xcb, xcb-window, xcb-window&, xcb-render-0.0, xcb-fallback, xlib, xlib-window, xlib-render-0_0, xlib-fallback, image, image16, recording

The next argument, -i3 tells it to run 3 iterations, this gives us a good set of data to work with. -r asks for raw output, which is literally just the amount of time the trace took to run. Finally ./benchmark/gvim.trace shows which trace to run. You can pass in a directory here and it will run them all, but I’d recommend trying that just one until you know that it’s working. When you’re running a long set of traces doing a tail -f on the result file can help assure you that it’s working without placing too heavy of a load on the system. The hardware backend runs took almost all day to finish, so you should always be plugged into a power source when doing this.

The output should look something like this:
[ # ] backend.content test-size ticks-per-ms time(ticks) ...
[*] xlib.rgba chromium-tabs.0 1e+06 1962036000 1948712000 1938894000

Making Pretty Graphs

Once you have some traces you can make charts with cairo-perf-chart. This undocumented tool has several options which I determined by reading the code. I did send a patch to add a usage() statement to this tool, but nobody has accepted it yet. First, the basic usage, then the options:

cairo-perf-chart nexus7_fbdev_xlib.txt nexus7_tegra3_xlib.txt

cairo-perf-chart will build two charts with that command, one will be an absolute chart, on that chart, larger bars indicate worse performance. The second chart, the relative chart takes the first argument as the baseline and compares the rest of the results files against it. On the relative chart, a number below the zero line indicates that the results are slower than the baseline (which is the first argument to cairo-perf-chart.

Now a quick note about the useful arguments. cairo-perf-chart can take as many results files as you want to supply it when building graphs, if you’d like to compare more than two files. If you want to resize the chart, just pass –width= and –height=, defaults are 640×480. Another useful option is –html which generates an HTML comparison chart from the data. The only issue with this option is that you manually need to make a table header and stick it in to a basic HTML document.

Some Interesting Results

Now some results from the Nexus7 and they are actually pretty interesting. I compared the system with and without the tegra3 drivers enabled. Actually I just plain uninstalled the tegra3 drivers to get some numbers with fbdev. My first run used the image backend, pure software rendering. As expected the numbers are almost identical, since the software rendering is just using the same CPU+NEON.

Absolute Results - Tegra3 vs fbdev drivers, image (software) backend

Absolute Results – Tegra3 vs fbdev drivers, image (software) backend

Relative Results - Tegra3 vs fbdev drivers, image (software) backend

Relative Results – Tegra3 vs fbdev drivers, image (software) backend

The second set of results are more interesting. I switched to the xlib backend so we would get hardware rendering. With the tegra3 driver enabled we should expect a massive performance gain, right?

Absolute Results - Tegra3 vs fbdev drivers, xlib backend

Absolute Results – Tegra3 vs fbdev drivers, xlib backend

Relative Results - Tegra3 vs fbdev drivers, xlib backend

Relative Results – Tegra3 vs fbdev drivers, xlib backend

So as it turns out the tegra3 is actually way slower than fbdev and I don’t know why. I think that this could be for a variety of reasons, such as unoptimized 2d driver code or hardware (CPU+NEON vs Tegra3 GPU).

Now that we have a method for gathering data, perhaps we can solve that mystery?

If you want to know more about the benchmarks or see some more analysis, you should read this great post which is where I found out most of the info on running the tools. If you want to know more background about the cairo-perf trace tools you might want to read this excellent blog post.

Tagged , ,