Canonical Voices

Posts tagged with 'upstream'


A few weeks ago I wrote about my new role as an upstream QA engineer. I have now officially been in that role since June. Quite expectedly I had (and still have) some backlog from my previous Desktop engineer role, but I have had plenty of time to work on automatic tests and some test technology now. If you are interested in the daily details, you can look at the ramblings on my G+ page; in a nutshell I worked on integration tests for udisks2 (mostly upstream now), a mock polkit API, and a small enhancement of the scsi_debug kernel module. On the distro QA side I got the integration tests of udisks2, upower, PostgreSQL, Apport, and ubuntu-drivers-common working and added to our Jenkins autopkgtest runner, where they are executed whenever the particular package or any of its dependencies get updated. This already uncovered a surprising number of actual bugs, so I’m happy that this system starts being useful after the initial hump of getting the tests to run properly in that environment.

In that previous blog post I mentioned that Canonical will hire a second person for an upstream QA engineer role. I am pleased that the job posting is now online, so if you are familiar with how the Linux plumbing and desktop stacks work, are frantic about testing, like to work with the Linux, plumbing, GNOME, and other FOSS communities, know your way around jhbuild, Jenkins, and similar technologies, and would like to explore new possibilities like applying static code checking or creating APIs to fake hardware, please have a look at the role description! Please feel free to contact me on IRC (pitti on Freenode) or by email if you have further questions about the role.

Read more
Michael Hall

Last week we introduced a new ‘Download for Ubuntu’ campaign for upstreams to use on their websites, letting their users know that the app is available in Ubuntu already.  We event generated a list of targeted upstreams we wanted to reach out to in order to spur the adoption of these buttons.  What we didn’t go into much detail about why upstreams should use them.  I hope to remedy that here.

It’s easy

Let’s just get that out of the way, this won’t take a significant amount of work on the part of an upstream.  It’s just a one time change to a website.  You don’t even need to change it every cycle, since the buttons point to the App Directory entry for the application itself, not any specific version of it.

It makes installing your app more appealing

The button isn’t just another way of getting your app, it also tells the user that it will install correctly, all of it’s dependencies are available and will be installed, everything is configured to work with their system, and they will get be getting updates and security fixes to it through a mechanism they already use and trust.  In short, it’s a promise of a good user experience (which I’ll admit we don’t always live up to, more on that below).  Telling 20 million users (and growing) that your app is safe and easy to install is surely worth a few pixels on your website.

It’s good social exposure for your app

By sending users to the App Directory, instead of just immediately installing, new users get to see what others are saying about your app through the ratings and reviews (which will be mostly positive, because your app is awesome right?)  of other Ubuntu users.  Not only does this tell your users that other people like your app, but it’s also telling them that they can add their own ratings and reviews, which will in turn boost your app’s standing.  More reviews leads to more users, which leads to more reviews, it’s a great positive feedback loop.

Users will be looking for it

Not right now, obviously, since we just started this campaign.  But as more upstreams adopt the new button, it’s going to be one of the first things Ubuntu users will be looking for on your website (for all the reasons mentioned above).  With a majority of website visitors leaving in less than a minute (according to a lazy Google search), the promise of a quick and easy install might just be the difference between a new user and a lost opportunity.

This campaign benefits everybody: end users, upstream developers and, yes, Ubuntu too.  So let’s improve these ties, together.  If you’re an upstream, you can copy/paste the following HTML snippet directly into your website (replacing {{pkgname}} with the name of your application’s package in Ubuntu).  If you want to reach out to an upstream developer, please add them to our list so we know who’s contacting them, and what the status is.

<a href="{{pkgname}}/">
 <img src=""  title="Download for Ubuntu" alt="Download for Ubuntu button" width="122" height="49" />

Now I know we can’t always give the best user experience possible (see, I told you I’d get to that).  Sometimes our packagin isn’t quite right, or the default configuration of your app is sub-optimal.  Our six month release cadence and package freezes mean that rapidly developing applications will often be out of date in our main repositories.  We’ve taken on a lot of work by distributing apps the way we do, and even though we’re a very large community, it’s still hard to get every package right.  Luckily, you’re not powerless here, if you spot problems with the way we distribute your app, or you need to get a newer version out to Ubuntu users, you can do something about that.

Package fixes

Even though our process locks applications to the version in the archives for that particular release of Ubuntu, we will still allow changes to the packaging itself.  So if we’ve done something wrong on our end that is giving your app a hard time, we’ll fix it and make that available to all of your Ubuntu users as a Stable Release Update.

Backport newer versions

A six-month release cycle means that every Ubuntu release has relatively up to date versions of applications, at least compared to distros that have a longer cadence.  But for rapidly developed applications, where new versions come out more frequently than that, this means their packages can become outdated quickly.  And with the five year lifetime of our LTS releases, most packages will get to be stale by the end.  That’s why we have a special repository just for backporting new versions of packages to stable releases of Ubuntu. And starting with 11.10, this repository is enabled by default.

In order to have your application backported to a stable release, it first has to be accepted into the current development release.  If your new version was in Debian’s unstable repository at the beginning of the development cycle, chances are it’s already there.  If it’s not in Debian you’ll need to submit your package to be included in the development release.  Once it’s there, you can request that it be backported to one more more stable Ubuntu releases.  You can use the requestbackport command line tool (from ubuntu-dev-tools package) to automate much of the process, or if you’re not running Ubuntu simply file a bug to start the request.

Read more
Michael Hall

It’s no secret anymore, we want apps in Ubuntu.  Big app, small apps, shiny apps, cute apps,  apps that play a catchy tune while avian avengers explode porcine poachers.  You name it, we want it in Ubuntu.  And we need your help getting them.

It doesn’t matter if you’re not a programmer, there are plenty of programmers in the world, and they’re making all kinds of really cool apps that you want, that I want, that we all want.  But they’re not putting them in Ubuntu, and that’s why I need your help.

You see I’m just one person, and with David Planella we’ve got, well, two people.  Now, two people can find an awful lot of apps on the internet, that’s true.  Especially when that’s part of your job.  But even still that would hardly amount to a drop in the bucket of apps that have been made.  And we’re not happy with just a drop in the bucket, are you?

No, of course you’re not.  So right about now you’re probably thinking of a bunch of cool apps you’ve used or seen or read about recently (and if you weren’t before, you certainly are now, aren’t you).  And you may be wondering how you can help us get them into the Ubuntu Software Center.   Well wonder no more my friend, because we have a Trello board.

Not terribly impressive, I’ll admit, but it is terribly useful.  You see, David and I will be contacting each and every one of these app developers about submitting their apps to the Software Center, and moving the card from column to column as that conversation progresses.  And while we have a nice long “To Contact” list right now, it’s not going to stay that way without your help.

We’re opening up this board to anybody who wants to add new upstream apps for us to contact.  All you need to do is follow David’s instructions on this wiki page to get started.  It’s quick, mostly painless, and best of all you get to start telling us what to do (at least a little bit).

But wait! There’s more!  Didn’t I say we were just two people?  There’s no way we could contact all these upstreams on our own.  And hey, you’ve just signed up to join the Trello board (you did do that, right?), which means you can start contacting them too, and moving their cards, and make Ubuntu even better.  We’ve even created a reusable email template that you can use for that initial contact.

If you contact one of the app developers, make sure you move their card to the “Conversation Started” column, assign it to yourself, and add comments about who you contacted and any other relevant information.  This of course requires that you joined the board, which you definitely should do if you are going to be working on this.  And please note that is says “Started”, not “Finished”.  Once you contact the developer, keep that line of communication open and help them through the process of submitting their app.  If you get to a point where you can’t help them, let David or I know and we’ll be happy to pick it up.

Read more
Michael Hall

Expanding on my previous post calling for pkgme backend contributors, here’s a list of the backends we would like to see added, and who in the community you can contact for help in making them. If you can act as a mentor for one of these backends, please say so in the comments and I will add your name to the list.    For any questions about pkgme itself, and what options are available to backends, your best bet is to ask James Westby (james_w) in the #pkgme channel on freenode.


QMake is a Makefile-generator. It uses information that the application author puts into a project file to build the Makefile for a project. A qmake backend would need to either use qmake to extract the information requested by pkgme, or parse the same project file that qmake uses in order to provide that information.

Information about qmake:

Help Contact: Angelo Compagnucci


Flash applications can be packaged for Ubuntu by wrapping them in a GTK window that contains a Webkit browser widget, and an index.html file for it to load that embeds the given flash file.

The Quickly Flash template currently does much the same thing. To do the same in pkgme, you will need to pass the necessary wrapper files to the extra_files request. extra_files should return a JSON object where the key is the file path relative to the root of the target application, and the value is the contents of that file.

Help Contacts: Michael Terry and Stuart Langridge


A backend for an HTML5 application would also require wrapping the target application in a GTK window with embedded Webkit widget. Only instead of creating an index.html, you would just point the Webkit widget to the target application’s HTML files.

Help Contact: Didier Roche


The Java backend would need to parse ant’s build.xml files to extract information about the target application or an already built jar file’s manifest.

Help Contact: James Page

Read more
Michael Hall

pkgme is a small utility created by James Westby, its purpose is to create a Debian package for any unpackaged applications.  It’s currently used when applications are submitted through the Ubuntu Developer Portal as tarballs, inspecting the contents of the application to determine how to build a package from it.  In order to support many different types and configurations of application, James built pkgme to support any number of different backends.

Currently there is support for apps using Python and Distutils, apps compiled by cmake, and apps written in Vala.  But there are still many, many applications out there that aren’t covered by these backends, including Qt apps, HTML5 apps, Flash apps and more.  That’s where you, dear contributor, come in.

UPDATE: Here is a list of desired backends and mentors to help you with them.

But I don’t know how to create packages!

That’s okay, you don’t need to know how to make packages to create a pkgme backend.  It already knows how to make packages, what it doesn’t know is where to find the information it needs to do that.  This is what backends are, just one or more small scripts that extract enough information about a project to let pkgme do its thing.

Ok, I’m interested, how do I start?

First of all, get a copy of the latest pkgme code from its bazaar branch in Launchpad:

bzr branch lp:pkgme ./pkgme

Then, create a VirtualEnv environment to install it into:

virtualenv ./env

Then, install it into the Virtualenv:

source ./env/bin/activate
cd ./pkgme
python develop

Now you’ve got a working pkgme installed and running in your virtualenv. You can leave your virtualenv by running ‘deactivate’.  Time to get started on your backend!

Where do I put my new backend code?

Since we’re going to submit your new backend to the pkgme branch, we can just create it there:

cd ..
mkdir ./pkgme/pkgme/backends/<your backend name>

Great, now I have an empty Backend, what do I put here?

The first thing your backend needs is a ‘want’ file.  You see, in order for pkgme to know which backend it should use on any particular application, it needs to ask every backend how much they want it.  It does this by executing a script named ‘want’ in each backend.

Your want file is executed from the target application’s directory, so in your script ./ will be the root of the target application’s directory.  This lets you script easily browse through the files in the application to determine how well it can provide packaging information for it.

In order to tell pkgme how much your backend wants to handle the target application, your ‘want’ file simply needs to print a number to STDOUT.  The backend with the highest number is the one pkgme will use.  These are the suggested ranges for your ‘want’ value:

  • 0 – no information can be provided about the project (e.g. a Ruby backend with a Python project).
  • 10 – some information can be provided, but the backend is generic (e.g. Ruby backend).
  • 20 – some information can be provided, and the backend is more generic than just language (e.g. Ruby on Rails backend).
  • 30 – some information can be provided, and the backend is highly specialized.

Now I have what I want, what do I do with it?

Once pkgme has chosen your backend to use against an application, it will call one or more scripts from your backend to get information about the application.  As the backend author, you can choose to provide separate scripts for each piece of information, or you can provide just a single script called ‘all_info’ that will provide everything.

Lots of scripts

For separate scripts, you will need to provide an executable in your backend directory for each of the pieces of information that pkgme might request.  Each script should print that information to STDOUT, or exit with an error if it can not provide it.

Just one script

However, if looking up bits of information one at a time is a time-consuming task for your backend, you can do it all in one shot.  If you want to do that, then the only script you need is one called ‘all_info’.  When this script is called, it is also given a JSON list on STDIN.  This list contains the keys for all the pieces of information that pkgme needs from your backend.  As output, this scripts needs to print a JSON dictionary to STDOUT.  This dictionary should contain a key for each of the fields sent as input, along with its corresponding value.  If your backend can’t provide a value for one of those fields, it should be left out of the dictionary.

You can test your new backend by switching to the directory of a project your backend is made to support, and running:


Make sure your virtualenv is still activated, or pkgme won’t be found. If everything works, you should have a ./debian/ directory in the application’s root folder.

Hurray, my backend works.  Do you want it?

Of course we want it!  What a silly question.  And it’s already in your local branch of pkgme too!  Well, it’s in the directory anyway, you still need to add it to the workingset:

cd ./pkgme/pkgme/backends/
bzr add <your backend name>

Then commit your changes and push them back to Launchpad:

bzr commit -m "Added backend for <your backend name>"
bzr push lp:~<your lp username>/pkgme/add-backend-<your backend name>

Then head on over to, click on your new branch name, and then click the “propose for merging” link.  Fill out the description of what your backend adds, and submit it.  From there it will get reviewed by one of pkgme’s maintainers, and either get merged into the main branch, or sent back to you for fixes.

Read more
Michael Hall

My big focus during the week of UDS will be on improving our Application Developer story, tools and services.  Ubuntu 12.04 is already an excellent platform for app developers, now we need to work on spreading awareness of what we offer and polishing any rough edges we find.  Below are the list of sessions I’ll be leading or participating in that focus on these tasks.

And if you’re curious about what else I’ll be up to, my full schedule for the week can be found here:

Read more
Michael Hall

Ubuntu 12.04, the Precise Pangolin, is scheduled to be released in a little over a week.  This is a very exciting release for us, not only is it an LTS release with 5 years of support, but it also brings some major improvements to Unity and other areas of the desktop.  It’s also going to see a very big focus on independent application developers.

Developers, Developers, Developers!

During the last six months we’ve spent a lot of time building tools and documentation for app developers.  In September of 2011 we launched the Ubuntu Developer Portal, a site dedicated to helping application developers target the Ubuntu platform, and for getting their applications distributed through Ubuntu.

The developer portal provides all the information an app developer needs to write apps for Ubuntu.  It will get you started with tools like Quickly, tell you what languages, toolkits and IDEs are available, and introduce you to the tools and workflows that make developing for Ubuntu a joy.

Once your app is ready, the Developer Portal will walk you through packaging it and submitting it to be published in the Ubuntu Software Center.  The MyApps section lets you upload and manage all your applications, provide branding and screenshots, and set your purchase price.

Going Native

In the past couple of months we’ve added extensive documentation on Unity integration, which allows your application to become part of the desktop experience.  The Unity APIs give your application a presence in multiple areas of the desktop, letting you to add extra information to the Launcher, indicators in the panel, search results in the Dash and more.

All about the Apps

Everybody knows that “Apps” are the big thing now.  No longer relegated to tablets and smartphones, “App Stores” are coming to both major proprietary desktop operating systems as well.  The Ubuntu Software Center already supports independent free and paid app downloads, and with 12.04 we want to grow that segment exponentially.

Not only do we provide a rich platform for app developers to target, we also have the means of delivering those apps directly to over 12 million users worldwide.  With Unity, your app isn’t just visible in the Ubuntu Software Center, but we put it right in the Dash!  Your app will show up whenever the user searches their system for something similar, giving it a level of visibility that no other platform offers.

Join the conversation

Developing applications for Ubuntu doesn’t have to be something you do in isolation.  Having a strong community is an important aspect in today’s software market, and Ubuntu provides you with the tools for collaborating with the existing Ubuntu user community and for growing a strong user community around your own application.    These users can help grow your app by add translations, identify bugs, and even submitting patches.

We’re also building a vibrant community of app developers, and we want you to be a part of that.  Learn tips and tricks from other app developers, share your own expertise and build professional connections.  Here you will also find a number of Ubuntu and Canonical developers who will take your suggestions and feedback for making app development on Ubuntu even better.

Read more
Michael Hall

Hello Unity is now open for translations!

Please help me make this technology showcase is available to application developers in your native language.  Translations are done through Launchpad, and will be built into the Hello Unity package.

Read more
Michael Hall

When the topic of contributions to FOSS come up, it usually happens that people focus entirely on the aspect of creation, specifically code creation, to the exclusion of all others.  In the context of software, this makes a certain amount of sense, since the primary product is the code itself, either in source or binary form.  Even the more broadly-focused, who make a point to expand their definition to include things like documentation and artwork, will still focus exclusively on the creation of those works.  And yet perhaps the single biggest factor towards increased creation of code is in the distribution of what is being created.

There are a number of reasons for people to write new code.  We often talk about a developer “scratching their own itch”, but other times it can be a matter of personal improvement, monetary gain, or even just plain fun.  While there are many reasons to write code, there are not so many reasons for releasing it under a Free or Open Source license.  By choosing such a license, the author explicitly wants his or her creation to be used by others, as many others as possible in fact.  The use of their creation is what motivates them, and it stands to reason that the more it is used, the more motivating it becomes to create.  The underlying reason why this is motivating can vary, but the fact is that creators of FOSS are motivated by the use of FOSS, and the more users there are, the more motivation there will be for creating it.

The number and variety of potential consumers of FOSS is larger than any single developer can hope to reach.  Even a group of developers, even a large group of them, will find it impossible to make their creations available to the widest possible audiences.  And the more effort they put into making their creation available, the less time and resources they have to put back into creating new things.  Likewise the smaller the pool of potential consumers, the less reason developers have to improve on or create something in the first place.  But by choosing an open source license, developers separate the work of distribution from that of creation.  The desire for their creation, then, will naturally lead to a much larger number of individuals and groups bringing these creations to the people who want them.  More importantly, by focusing exclusively on the task of distributing, these new groups are able to afford not just one project, but a multitude of projects, with an increase in the consumption of their creation.  And with an increase in consumption, it is reasonable to expect an increase in contributions.

The default application selection for each Ubuntu release is often the subject of much discussion and advocacy.  People called for the inclusion of Banshee long before Ubuntu made the switch.  It’s unimaginable that people who like a project and appreciate it’s developers would actively seek to have it used by an organization that contributed nothing back.  Likewise when it was announced that Ubuntu would switch back to Rhythmbox, those same advocates genuinely believed that they had lost something, again something unimaginable if they weren’t gaining something valuable from the distribution.  When PiTiVi was selected as a default application, advocates for Openshot made a very strong case for why their preferred application should be included, again because they knew that the project would gain something of value from the increased distribution.  The same happened with F-Spot and Shotwell, with the removal of the Gimp, the various boot splash systems, and more.  I can only assume that the same happens in other distributions.  The only reason why this would happen is if, whether consciously or not, people see a real value, as real as the value of code contributions, in being distributed as widely as possible.

By relieving the developers of the need to put resources into distribution, distributors allow them to create more using the same commitment of time and resources.  Likewise, by increasing the number of people who will be using it, the distributors multiply the motivating value, whatever it may be, that the developer gets in return.  And as the motivation for creating increases, the number of people who participate in creating also increases.  In this way, every distributor of Free and Open Source software contributes towards increasing the total number of creators and creations (including lines of code written), and they do so in direct proportion to the expansiveness of their distribution.

Read more
Michael Hall

I spent some more time over the weekend working on Hello Unity.  If you haven’t already, be sure to read my first post about it.  In short, Hello Unity is a showcase application that demonstrates all the different ways an application developer can integrate their app with the Unity desktop.

The current version of Hello Unity sports a new syntax-highlighted code display, which makes it much easier to read and understand what the code is doing.  I also spent a significant amount of time going through and heavily commenting the code to explain what everything was doing.

In the Launcher section I added support for setting the “urgent” status of the application.  In Unity, this will cause the application’s icon in the Launcher to shake and, if the Launcher is set to auto-hide, will also cause the icon to slide out into view while it shakes.  This is a very useful way of telling a user that your application needs their attention.

A new section was added for integrating with the Message Menu.  It automatically adds a Hello Unity section to the menu, and allows you to add count indicators to it.  Clicking on an item in the menu will execute the code for removing it.  All of this is explicitly commented on in the source code.

Another new section is for Notifications.  While it uses the generic libnotify API, it does highlight how to use it with Ubuntu’s Notify-OSD display system, including how to updated and append text to the currently displayed notification.

Once again, if you are interested in contributing to this project, you can get the code from the Launchpad project page.  Also available there are source tarballs and installable .DEB files.

Read more
Michael Hall

Everybody knows that programmers can contribute to Unity, and I’ve shown in my previous posts that non-developers can still contribute features and fixes that make applications integrate better.  But what if your skills lay more on the creative side of the spectrum?

Well it just so happens that you have something to contribute to Unity too.  In fact, we’re currently in need of some graphic design talent to put some extra polish on some areas of application integration.  Specifically, we need people to help create vector art for application icons that only have raster images, PNG, XPM, etc.

This wiki page contains a list of applications that have been identified as needing an SVG icon.

Now graphic creation isn’t my specialty, so I’m not going to write a step by step guide to creating these images, that’s up to you artists.  What I am going to do, however, is walk you through the process of coordinating with the upstream application developers and submitting your finished image to Ubuntu.

1) Contact the upstream

This is an important step, because even if an application doesn’t have an SVG icon in Ubuntu, there’s still a chance that one already exists.  Read over the first half of my post on upstreaming Quicklists for ways to get in contact with with them. Ask them if they have an SVG  source for their application’s icon.  If they do, that’s great! You can take that and skip down to step #3.  If they don’t, then you will need to work with the upstream project to create one that is right for them.

2) Work with the current image

It’s important that we don’t try and re-brand an application unless the authors want it re-branded.  What we want is a more flexible/scalable version of the image icon we already have.  If you are creating a new SVG file, try to keep as close to the raster image as possible, and be sure to talk to the upstream developers about any deviations or changes you need to make.  And finally, keep with the spirit of open source and make your new image available to both Ubuntu and the upstream project under a copy-left license like the CC-BY-SA or another permissive license of the upstream’s preference.

3) Preparing your image

Since we are getting close to the release of 12.04, the requirements for any further changes are getting stricter.  In order to get your image into the Precise packages, you will need to meet the following two criteria:

It must be approved by the upstream project.  Since your image will be representing their application in Ubuntu, we absolutely need their acceptance of it before it can be used.  This is why step #1 is so vitally important, make sure you are working and communicating closely with upstream from the very beginning.

It must be a plain SVG file.  This is because it will be added as a patch file against the package, and patch files don’t work well with binary data.  Since a plain SVG file is text, not binary, it makes it much easier to convert into a patch.

4) Submit your new image

The wiki page containing the list of applications has a link to the corresponding bug report filed in Launchpad.  When your image is ready, attach it to the bug report.

You will also need to add the upstream project to the bug report.  Click the “Also affects project” link on the bug page, and choose the Launchpad Project that matches your upstream.

That’s it!  Well, almost.  Once we have your image, the application’s package in Ubuntu will need to be updated to use it, but that will require some changes to packaging scripts and patch files, which will be the subject of a more technical post.  But getting the necessary image is itself a big step.

Read more
Michael Hall

Bazaar is a great tool for distributed development, but distros are built on packages, and so packages are what distro developer care about.  That’s why many of you who have followed my previous blogs have probably been asked for patches to the package itself, not to the bzr branch.

Why the difference?  Well for package maintainers, it’s easier and faster to import  upstream changes if they keep their source code clean.  To do that, any changes made by the distro are applied on top of the unmodified upstream code in the form of patches.  There are many tools designed specifically to make this easy for the package maintainers.

Below I’m going to show you how to turn your code change into a package patch that is easy for Ubuntu developers to add to the distro’s packages.  Only do this if your submitted branch is to a package in main and it hasn’t already been merged.

0) Check your source package format

The following instructions will only work on source packages using quilt 3.0 for managing patches.  Before you do anything else, check that the file debian/source/format contains the following:

3.0 (quilt)


1) Find your revisions

Starting from your existing code branch, we first need to identify which revisions in your branch we need to turn into a patch.  To do that, we simply check for revisions in your branch that don’t exist in the main one.  Here is what I used for geany:

bzr missing --mine-only ubuntu:geany

You just need to replace ‘geany’ with your application’s branch name (the same you bzr branched in my earlier articles).  The –mine-only will limit the result to only revisions in your branch just to keep things simple.  You’ll want to make note of the first and last revisions in this output.  If, like me, you only had one revision missing, that makes it even easier.


2) Generate the patch

Fortunately the package “bzr-builddeb” provides a command that makes this step easy.

mkdir -p debian/patches
bzr dep3-patch -d ubuntu:geany . > debian/patches/add_keywords.patch

Again, just replace ‘geany’ with your application’s branch name, and dep3-patch will find the differences in your branch and convert them into a patch file.

Now that you have a patch file, we need to add it to the list of patches for this package.  To do that, all you need is to add it’s name to the end of the debian/patches/series file like this:

echo add_keywords.patch >> debian/patches/series


3) Convert your source changes

Now that your changes are in a patch file, we need remove those changes from the source code itself.  This is where those revision numbers from step 1 come in, you will need the highest revision number and one less than the lowest.  Since I only had one revision, rev 32, my numbers are 32 and 31.

bzr diff -r 32..31 | bzr patch

This causes bzr to generate a reverse-diff of your changes (by going from the higher to the lower revision), and then apply that reverse-diff to your current code, effectively undoing your changes.

Now you need to apply your new patch file using quilt, so that quilt knows about it:

quilt push -a

Which should give you the following output if everything applies cleanly (if not, then your package is going to need some extra work, and you should ask for help from someone in #ubuntu-devel on freenode IRC).

Applying patch add_keywords.patch
patching file

Now at patch add_keywords.patch


4) Log your changes

Since you are making changes to the package itself now, you need to add that information to the debian/changelog:

export DEBFULLNAME="Michael Hall"
export DEBEMAIL=""
dch -i

You will, of course, want to replace my name and email with your own (Hint: you can put those 2 export lines into ~/.bashrc for future packaging work). This will create a new entry in the chanelog for you, with one higher version number.  All you need to do it add in the comments:

* Add search keywords to .desktop file (LP: #942154)

Be sure to use the proper bug number for your changes.  Also, if you are not running on Precise, you  will need to change the release target at the top of the file to ‘precise’.  Here’s what my new record looks like:

geany (0.21.dfsg-1ubuntu4) precise; urgency=low

* Add search keywords to .desktop file (LP: #942154)

-- Michael Hall <> Wed, 07 Mar 2012 14:40:32 -0500


5) Commit and push

Now it’s time to put everything back into your bzr branch.  First you need to add your patch file:

bzr add debian/patches/add_keywords.patch
bzr add debian/patches/series
bzr add .pc/

If your package branch didn’t already have a ‘series’ file, my instructions in step 2 will have created one, so I’m adding it here just in case.  If it already existed, bzr add won’t do anything.

Next, commit and push your changes back to your submitted branch:

bzr commit -m "Convert source changes into a package patch file"
bzr push lp:~mhall119/ubuntu/precise/geany/add_keywords


Read more
Michael Hall

There has been a fantastic amount of feedback and contributions being made by folks who have been following my recent posts, and we’ve already had some of those contributions landing in Ubuntu 12.04.  But we’re not done yet!

Ubuntu means “I am who I am, because of who we all are”.  In a very literal sense, Ubuntu is what it is, because of what other distros are.  We all bring together the best open source software from upstream developers, and we should all be giving our improvements back to those developers.  Unity may be the default desktop on Ubuntu, but it’s also been ported to ArchLinux and SuSe, and is making it way to Fedora too.  That means that your Quicklist contribution can help more than just Ubuntu, all you need to do is submit it upstream.

Step 1: Find your Upstream

While all of Ubuntu’s package sources use Launchpad, and are therefore all in the same place, your upstream developers will all of their own separate spaces.  Some are rather easy to find, for example Firefox is developed over on  Others may use GitHub, SourceForge, or their own sites.  So you first task if to find out where the code is developed.

Step 2: Talk to your Upstream

Once you’ve found their development home, look for ways of contacting the developers.  Usually there will me an email/mailing list available, an IRC channel or a forum.  Whatever method they prefer, us it to ask the developers how they want you to submit your patch.  Most developers love being contacted by somebody who already has a patch written.

Step 3: Submit your changes

Depending on your upstream’s development process, they may want a patch file with your changes, or they might ask you to use their version control system of choice (svn, git, etc) to submit your change in a way that is easy for them to merge.  Some, especially Debian, may request a patch for the package itself.  This is why Step 2 is so important, you need to know how to submit it in order for it to be accepted.  Don’t worry if you don’t know how do what they want, ask them to help you learn it.  Again, developers like people who come to them with patches.

For Geany, I first found their website,, and from there a link to their Feature Tracker on SourceForge.  I also found their IRC channel, #geany on freenode, and was in contact with their developers there.  In the end, I was asked to create a fork of their code on GitHub, and submit my change as a Pull Request.

Step 4: Updated your Merge Proposal

Once you’ve submitted you changes upstream, leave a comment to that effect in your merge proposal.  Ubuntu developers don’t like to keep custom changes in Ubuntu, and your merge proposal is much more likely to be accepted if they know the change will eventually be made in the upstream project as well.

Step 5: Stay involved with your Upstream

If you were working on a program you like, don’t let this be the end of your contribution!  You now have experience making and submitting changes (to both Ubuntu and Upstream), and you are forming a relationship with the upstream developers.  Keep up with both of those, as they will be invaluable assets to you.


Read more

The Inkscape folks are looking for someone to help finish off some editing for their website introduction video.

Hop on over if you want to lend a hand!

(via Ted Gould) 

Read more

The Yorba folks have released a new version of Shotwell. You can snag it here.

New features include:

  • Video support for Ogg, AVI, MP4, Quicktime, and WMV files
  • Upload videos to major Web services, including YouTube, Facebook, Flickr, and PicasaWeb
  • Runtime monitoring of library directory
  • Background writing of metadata to master files
  • Flagging of photos for batch operations
  • Set multiple photos to desktop background slideshow

Congrats to the Yorba team!

Read more

In case you’ve missed out, smspillaz has started working fulltime at Canonical on working on Compiz. 

Sam’s been shuffling getting things fixed in the code and needs a bit of help, so I asked him to put together a list of things Compiz could use help with.

  • Finish writing the compiz code doxygen
  • Provide a support for sound events using libcanberra in gnomecompat
  • Package compiz-plugins-extra and compiz-plugins-unsupported
  • Figure out why evince is placing it’s window wrongly
  • Figure out what is up with gtk-window-decorator on virtualbox
  • Figure out what is up with resizing xterm in one direction

Here’s the full list with details, if more issues come up we’ll add them there.

Also a special thanks to the moderators of the Ubuntu Forums who volunteered to help the Compiz forums clean out some spam and tidy things up a bit. High five!

Read more

Thanks to PiTiVi I was able to take the webm files from GUADEC and put together a video of Gabriel’s Banshee talk.

Those of you wondering how to make Banshee extensions (Stuart!) will want to pay attention around the 5 minute mark, where he goes into an example on how easy it is to make an extension. 

So, go forth and make great extensions!

Read more

Did you know that offers free advertising to open source projects?

Every project can always use some more new blood. And if you don’t think that’s a good enough reason, as of this writing here is a list of 344,881 other reasons.

Ok I promise not to blog about StackExchange anymore, until tomorrow anyway.

Read more

Allison Randall has blogged about her new role in Ubuntu; working at Canonical as the Technical Architect for Ubuntu. One thing which I think is awesome is how she mentions people who encouraged her:

To give credit where credit is due, there have been 4 great influences on my career over the years, mentors, friends, people who believed in me, encouraged me to dream big dreams and try big things, who taught me that I’m better, smarter, wiser, more dynamic, and resilient than I ever imagined. In alphabetical order: Damian Conway, Greg Kroah-Hartman, Mark Shuttleworth, and Nathan Torkington. Thanks guys, I wouldn’t be here without you!

Everyone has mentors in Free Software, so Allison’s post inspired me to talk about mine. People who made you who you are. I hope this encourages you to talk about the people who inspired you.

While Allison’s post motivated me, this next month I get to celebrate 3 years at Canonical and I would like to thank people who have motivated me to do what I do. Think of them as the root of me:

  • Dave Camp - Dave is one of the older Ximian folk, a former co-maintainer of Nautilus, and later he worked on Mozilla. He taught me to ignore the haters, and rock on by your bad self. He’s a hacker’s hacker, a dude who puts his head down and skates. He doesn’t care about fame, fortune, or any of that jazz, he’s just a dude. He is also an amazing guitar player.
  • Luis Villa - Not much to say here, he’s brought so many of us here that I have no words that could ever be kind enough to explain what Luis has done for so many of us.
  • Jeff Waugh and Benjamin “Mako” Hill - I am going to mush them together, since at the time they were the collective first “Ubuntu Community managers”. Jeff for being the spark plug of motivation and getting me to a UDS, and Mako for being the Free Software advocate who leads by example, not by shoving the GPL down people’s throat. I would love to hear much more from both of you. Both of you believed in me from the beginning, and I will always be grateful.
  • Asa Dotzler - many years ago when I first started wondering what Mozilla was he took the time to explain open source to me. I also love that he flames Linux for what it is, maybe someday we’ll get our act together. :) I’m not even sure if he’s looking at Linux these days but I’ll always appreciate his first interaction with me.

These people pointed me in the right direction, and these are the ones who focused me into a fine instrument of Ubuntu laser-destruction. If you hate me, then it’s probably these people’s fault:

  • Luke Kanies from Puppet Labs (at the time from Reductive Labs), who convinced me to think about applying for my current job at Canonical.
  • Oliver Grawert, who made me actually do that or he promised to punch me in the face.
  • Daniel Holbach. The name mentioned by Jono Bacon when he said “I am starting a new team” that made me apply for the job on the spot and totally not care what the consequences are. He has that effect on people.
  • … and of course the rest of you on the community team (and I just don’t mean Canonical folk) who have been supportive of me over the years, even when I quit the team and had a temper tantrum a few years ago.)

And on top of that I’ve got the old folks, the mentors who are just awesome by being there, they’re all good friends and good mentors. I am pretty sure that everyone who has worked with these people are not surprised:

  • Chris Blizzard - old school GNOME, now at Mozilla. He builds airplanes ffs.
  • Vincent Untz - old school GNOME, now at Novell. He builds ice cream ffs.
  • Miguel de Icaza - old school GNOME, now at Novell. He builds stack exchanges ffs.
  • Ryan Lortie - old school GNOME, now at Codethink. He builds dconf ffs.

I’d also like to take a moment to thank the new people — those of you who are new here and want to rock. Spend some time researching my generation’s heroes, and learn from what they have to say.

Hah, I just thought “Some day this entire mess will all be yours”, but I don’t know if that’s a nice thing to say or not, so heh to you.

Read more
Ara Pulido

A couple of weeks ago we launched the Desktop Testing Program. You can read more about it in the original announcement but, basically, we have some infrastructure to track test results for desktop applications, a wiki that stores the testcases description and a large community willing to test every Ubuntu milestone.

The Alpha 3 testing cycle went very well, but we still need more testcases to make the Beta testing cycle event better.

Mathieu Trudel-Lapierre, one of the Network Manager upstream developers, stepped ahead and wrote some testcases for Network Manager. He, as an upstream, wanted Network Manager to be part of the testing program, to have the opportunity to get test results every Ubuntu milestone. His tests will be part of the Desktop Testing Program starting on Maverick Beta.

If you are an upstream (or would like to collaborate somehow with your favourite upstream project), you can review the available tests in our testcases wiki, and, if the application is already there, make sure that the tests still apply and write more to cover new features. If your application is not there, just create a new page and start adding new testcases. In both cases you can follow our syntax guidelines.

I think this is a great opportunity for upstreams to have their project tested on a regular basis by a great community, with results they can browse, in a repeatable way. I just hope more upstreams could know about it. If only this blog was syndicated in Planet Gnome

Read more