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.

With the Ubuntu TV port to Unity 3d currently underway, the project team is looking towards future feature development and they want the community’s input on what the product should do.  Specifically they are gathering a list of use cases that consumers might want in a Smart TV in five key areas:

• Local/networked media
• How should Ubuntu TV interface with media on the local device or local network?
• Online media
• How should Ubuntu TV find and play online media?
• Control from another device (smartphone, tablet etc.)
• How can you use your existing phone or table to interface with your TV?
• Broadcast (LiveTV, PVR)
• How should Ubuntu TV list, store and playback live TV?
• Applications
• What types of applications would be useful on a TV?

So here’s your chance to get involved and be heard, go to this wiki page and start adding your use cases to the list.

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.

Qt/qmake

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: http://qt-project.org/doc/qt-4.8/qmake-manual.html

Help Contact: Angelo Compagnucci

Flash

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

HTML5

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

Java

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

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 setup.py 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:

pkgme

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 https://code.launchpad.net/pkgme, 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.

Sweet Chorus

Juju is revolutionizing the way web services are deployed in the cloud, taking what was either a labor-intensive manual task, or a very labor-intensive re-invention of the wheel  (or deployment automation in this case), and distilling it into a collection of reusable components called “Charms” that let anybody deploy multiple inter-connected services in the cloud with ease.

There are currently 84 Juju charms written for everything from game backends to WordPress sites, with databases and cache servers that work with them.  Charms are great when you can deploy the same service the same way, regardless of it’s intended use.  Wordpress is a good use case, since the process of deploying WordPress is going to be the same from one blog to the next.

Django’s Blues

But when you go a little lower in the stack, to web frameworks, it’s not quite so simple.  Take Django, for instance.  While much of the process of deploying a Django service will be the same, there is going to be a lot that is specific to the project.  A Django site can have any number of dependencies, both common additions like South and Celery, as well as many custom modules.  It might use MySQL, or PostgreSQL, or Oracle (even SQLite for development and testing).  Still more things will depend on the development process, while WordPress is available in a DEB package, or a tarball from the upstream site, a Django project may be anywhere, and most frequently in a source control branch specific to that project.  All of this makes writing a single Django charm nearly impossible.

There have been some attempts at making a generic, reusable Django charm.  Michael Nelson made one that uses Puppet and a custom config.yaml for each project.  While this works, it has two drawbacks: 1) It requires Puppet, which isn’t natural for a Python project, and 2) It required so many options in the config.yaml that you still had to do a lot by hand to make it work.  The first of these was done because ISD (where Michael was at the time) was using Puppet to deploy and configure their Django services, and could easily have been done another way.  The second, however, is the necessary consequence of trying to make a reusable Django charm.

Just for Fun

Given the problems detailed above, and not liking the idea of making config options for every possible variation of a Django project, I recently took a different approach.  Instead of making one Django Charm to rule them all, I wrote a small Django App that would generate a customized Charm for any given project.  My goal is to gather enough information from the project and it’s environment to produce a charm that is very nearly complete for that project.  I named this charming code “Naguine” after Django Reinhardt’s second wife, Sophie “Naguine” Ziegler.  It seemed fitting, since this project would be charming Django webapps.

Naguine is very much a JFDI project, so it’s not highly architected or even internally consistent at this point, but with a little bit of hacking I was able to get a significant return. For starters, using Naguine is about as simple as can be, you simply install it on your PYTHONPATH and run:

python manage.py charm --settings naguine

The –settings naguine will inject the naguine django app into your INSTALLED_APPS, which makes the charm command available.

This Kind of Friend

The charm command makes use of your Django settings to learn about your other INSTALLED_APPS as well as your database settings.  It will also look for a requirements.txt and setup.py, inspecting each to learn more about your project’s dependencies.  From there it will try to locate system packages that will provide those dependencies and add them to the install hook in the Juju  charm.

The charm command also looks to see if your project is currently in a bzr branch, and if it is it will use the remote branch to pull down your  project’s code during the install.  In  the future I hope to also support git and hg deployments.

Finally the command will write hooks for linking to a database instance on another server, including running syncdb to create the tables for your models, adding a superuser account with a randomly generated password and, if you are using South, running any migration scripts as well. It also writes some metadata about your charm and a short README explaining how to use it.

All that is left for you to do is review the generated charm, manually add any dependencies Naguine couldn’t find a matching package for, and manually add any install or database initialization that is specific to your project.  The amount of custom work needed to get a charm working is extremely minor, even for moderately complex projects.

Are you in the Mood

To try Naguine with your Django project, use the following steps:

1. cd to your django project root (where your manage.py is)
2. bzr branch lp:naguine
3. python manage.py charm –settings naguine

That’s all you need.  If your django project lives in a bzr branch, and if it normally uses settings.py, you should have a directory called ./charms/precise/ that contains an almost working Juju charm for your project.

I’ve only tested this on a few Django project, all of which followed the same general conventions when it came to development, so don’t be surprised if you run into problems.  This is still a very early-stage project after all.  But you already have the code (if you followed step #2 above), so you can poke around and try to get it working or working better for your project.  Then submit your changes back to me on Launchpad, and I’ll merge them in.  You can also find me on IRC (mhall119 on freenode) if you get stuck and I will help you get it working.

(For those who are interested, each of the headers in this post is the name of a Django Reinhardt song)

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.

• Upstream App Developer Documentation
  Identify tutorials and documentation needed by upstream developers to port and integrate their applications with Ubuntu and Unity
• App Developer events
  Promote and run a successful series of online app developer events, including at least:
  - The Ubuntu App Developer Week
  - The Ubuntu App Developer Contest
• Ubuntu platform API documentation
  Identify which APIs need to be documented for application developers and ways in which we can provide these APIs in a developer friendly way
• Upstream App Developer Support
  Provide support and mentoring resources for upstream app developers who want to port or integrate their application with Ubuntu and Unity
• Promote and encourage upstream delivery in Ubuntu
  Get more app developers talking about Ubuntu and targeting Ubuntu. Promote Ubuntu as a platform in the places independent app developers socialize.
• Upstream App Developer Outreach
  Identify and engage targetted upstreams to submit their apps to the Ubuntu Software Centre
• Ubuntu App Developer Site incremental improvements
  Building upon the foundations of the initial Ubuntu App Developer site, we’d like to expand it on a second design phase.
• App Developer external outreach
  We want to increase the visibility and awareness of Ubuntu app development outside of the regular Ubuntu channels.
• MyApps submission experience and expectations for upstreams
  Review the current process and identify which parts of the documentation need to be improved. Also figure out what specifically we expect from upstreams and which help the ARB can provide.
• Advertise new apps in the Software Center
  Promote the availability of new apps in the Software Center, both in USC itself and through other channels, to raise awareness of apps targeting Ubuntu

And if you’re curious about what else I’ll be up to, my full schedule for the week can be found here: http://summit.ubuntu.com/uds-q/participant/mhall119/

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.

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.

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.

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.

David Planella and I have spent the past couple of weeks gathering, cleaning and verifying Unity integration documentation that has existed on the Ubuntu wiki, individual blogs and inside the source code itself.   After publishing those docs, a couple of people asked for some kind of simple “hello world” type of application to show off how all that integration works.

So, I made one.

You can get the code from Launchpad:

bzr branch lp:hello-unity

It’s not complete yet, but it’s a start.  Let me know if you’re interesting in contributing to it.

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.

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 geany.desktop.in

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="mhall119@ubuntu.com"
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 <mhall119@ubuntu.com> 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

It’s sometimes easy to talk about “Ubuntu developers” as if they are some faceless “others” who are separate from “Ubuntu users”.  But the reality is that the line between user and developer isn’t quite as clear as many people imagine.

In the response to my recent posts, this mixing of user and developer has become even more clear to me, and I wanted to share it with everybody.  These are the faces of some of the many non-developer users who make Ubuntu better for you.

Nekhelesh Ramananthan

Nekhelesh was one of the first contributors to respond to my postings, and he never slowed down.  He has contributed multiple additions of Quicklists and Keywords, improving the Unity integration for many popular applications.

Trenton Fox

Trenton was another early contributor, creating Quicklists for several of the applications I had targeted for better Unity integration.

David Baucum

David is a long-time member of of my own LoCo Team, so I was thrilled to see him submitting patches to Ubuntu apps.  He was also one of the first to have his contributions land in Ubuntu 12.04.

If you should happen to run into any of these guys online or in real life, be sure to thank them for making Ubuntu better for you.

After all the terrific feedback and contributions we received from community contributors as a result of my Quicklists article, I’ve been asked to talk about how to contribute to improving another feature of Unity, the Applications Lens.

Search is the heart of the Unity Dash, and making search better is great way to contribute to the overall quality and usability of Ubuntu.  And just like Quicklists, there are ways you can do this without being a developer.  In this article, I will show you how to add Keywords to an application that will be used by the Dash’s search function.

Just like in my previous tutorial on Quicklists, I will once again be using Geany as my example application since it is one of my most-used programs.  Geany will be found in a search for “IDE” or “Development”, thanks to those words being in the Comment and GenericName fields of it’s .desktop file.  However, I think it should also be found in a search for “Code” and “Programming”, which it currently does not.

Step 0: File bug reports

This wasn’t part of the Quicklist tutorial, because I had already  filed bugs for the apps we were targetting.  But this time there is no list, so it’s up to you to make sure there is a bug report.  For ubuntu, you can file it against:

https://bugs.launchpad.net/ubuntu/+source/<source_name>/

It’s equally important to file a bug in the upstream’s Bug Tracker.  Refer to the stems up my post about upstreaming your quicklists for how to find your upstream.

Once you  have your bugs filed, post a link to them in the comments so that others know you are working on them.

bzr branch ubuntu:geany

If you followed the Quicklist tutorial, you’ll have already done this.  However, if your merge proposal hasn’t been accepted yet, it’ll be easier to do these changes on a clean branch.  You can give the name of a new directory for this checkout by running:

bzr branch ubuntu:geany ./geany-keywords

Step 2: Adding keywords

Again, just like with Quicklists, you first need to locate the .desktop file for your application.  For me, it was located in the root of the branch in a file called “geany.desktop.in”.  If you don’t see it in the root of your project’s branch, try running this command:

find ./ -name "*.desktop*"

This may not look exactly like the file in your /usr/share/applications/, since some processing is done to add translated strings for the application name and comments.  But as long as you are just adding the Keywords item to the bottom of the file you shouldn’t have to worry about that.

Next you  should look for deprecated keyword fields.  ”Keywords” is a new part of the XDG specification, but your application may have already been using the desktop-specific field “X-GNOME-Keywords”.  If it does, go ahead and rename it to “Keywords”.  Also check for the existence of fields starting with an underscore, like “_Name”.  If your .desktop file has those, that means it’s probably setup for translations already, and you should use “_Keywords” instead, so that they can be translated as well.

For geany, there was no existing Keywords field of any kind, but it was setup for translations, so I used the following:

mhall@mhall-laptop:~/projects/Ubuntu/unity/quicklists/geany$ bzr diff
=== modified file 'geany.desktop.in'
--- geany.desktop.in	2012-02-24 19:30:41 +0000
+++ geany.desktop.in	2012-02-27 18:31:39 +0000
@@ -10,3 +10,4 @@
 Categories=GTK;Development;IDE;
 MimeType=text/plain;text/x-chdr;text/x-csrc;text/x-c++hdr;text/x-c++src;text/x-java;text/x-dsrc;text/x-pascal;text/x-perl;text/x-python;application/x-php;application/x-httpd-php3;application/x-httpd-php4;application/x-httpd-php5;application/xml;text/html;text/css;text/x-sql;text/x-diff;
 StartupNotify=true
+_Keywords=Code;Editor;Programming;

Step 3: Submitting to Ubuntu

Now you need to send your changes to Ubuntu.  This is very similar to what we did for Quicklists, but I’ve added one extra piece to the commit command.

bzr commit -m "Add Keywords to .desktop file" --fixes lp:942154
bzr push lp:~mhall119/ubuntu/precise/geany/add_keywords

By passing the –fixes flag, along with your Launchpad bug #, to the bzr commit command, you will automatically link your new branch with the bug report you created in step 0.

The next step is to once again propose that your changes be merged into the Ubuntu package. To do that, run the following command to open the Launchpad page for your new branch:

bzr lp-open

On that page you’ll see a link labeled “Propose for merging”, click that and fill out the form on the next page to create your merge proposal.

Step 4: Submitting to Upstream

The final step is to send your changes upstream as well.  This is good practice whenever you are making changes, plus it makes it easier for Ubuntu’s package maintainers.  Since every upstream is different in how they want to get submissions, I recommend following my previous upstreaming tutorial for this step.

The Ubuntu Florida LoCo Team is my home team, and this cycle I will once again be meeting up with Chris Johnston to participate in the Ubuntu Global Jam.  Since Chris is the one organizing this event again, I asked him a few questions about it.

Tell me about yourself and how you are involved in Ubuntu

My name is Chris Johnston. I got involved in Ubuntu about 3 years ago. I started by attending a Florida LoCo Team event at Michael Hall’s house. I got involved with the Ubuntu Beginners Team, the Classroom Team, and the BugSquad. I was one of the original planners of Ubuntu User Days and I got involved in developing for what is now the LoCo Team Portal. After attending my first UDS I saw a need and started coding on the Summit Scheduler. Now days I spend most of my time developing on Summit or the LoCo Team Portal.

Have you organized a Global Jam event before, and if so what was your experience? How did you choose a venue and select activities?

I organized a Global Jam event last cycle. We ended up with only 3 people participating, but we had a productive day hacking on summit.ubuntu.com and even got a new developer involved.

What kinds of activities do you plan of doing as part of your upcoming jam?

During this Global Jam, we will again be working on some of the community supported websites, including Summit and the LoCo Team Portal.

How do you spread the word about your event to get more people to participate?

Through the LoCo Team Portal and talking to people about it.

Now it’s time for you all to share your stories about past and future Global Jam events!

As part of an ongoing series of blogs about LoCo Team Jams, I spoke with Benjamin Kerensa (bkerensa), the team contact for Ubuntu Oregon about their Global Jam activities.

Tell me about yourself and how you are involved in Ubuntu

My name is Benjamin Kerensa and I’m Team Lead for Ubuntu Oregon and also actively contribute to  the Ubuntu Weekly News, Ubuntu Developer News, Ubuntu Documentation, Ubuntu BugSquad and I write for OMG! Ubuntu!. I have been involved mostly behind the scenes for a number of years providing community support.

Have you organized a Global Jam event before, and if so what was your experience? How did you choose a venue and select activities?

I have organized a Global Jam before in fact I organized our event last year and I feel it turned out really nice however I did not fully take into account the amount of time needed to get people contributing at an event so our Jam last year was mostly social in nature but this year we are planning for a whole day from morning till late night. Last year I chose PuppetLabs to be our venue because I knew that the folks there shared a very common love for Free Open Source Software and also had facilities that were very accommodating for a crowd of our size. I selected documentation and bugs last cycle however due to the limited time we really didnt get to work on any tasks but we did however get to do a general overview of how to contribute in those areas.

What kinds of activities do you plan of doing as part of your upcoming jam?

This cycle we hope to focus on Bug Triaging and Bitesize Fixes with the help of Ubuntu BugMaster Brian Murray and potentially have a talk on packaging by
Steve Langasek. It is my hope that these focuses will not only benefit the LTS but also gear our community towards accelerated contributions in the area of    development and continue to lay a foundation for future contributors in Oregon to be involved in more technical focused contributions.

Our LoCo is lucky to have the opportunity to work with Western Oregon University this year in a Mentorship Project for their students in which they have chosen to learn how to contribute to Ubuntu as such we anticipate a number of those students to be in attendance.

How do you spread the word about your event to get more people to participate?

I announce via our mailing list and the loco directory and then cross post those announcements to other LUG and Tech focused mailing lists in our region and then I use a mix of social media and IRC to encourage our existing Ubuntu LoCo folks and others to come and check out what we have going on.

Thanks Ben and the entire Ubuntu Oregon team!

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 mozilla.org.  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, geany.org, 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.

Since almost all of recommended packages in my original post have been tackled already thanks to Nekhelesh Ramananthan and David Baucum, here’s a new list for those of you who are still itching to knock a few out.

This list contains some of the most popular downloads from the Ubuntu Software Center that don’t have a Quicklist in Precise.  Not all of them will have useful command line options to make shortcuts for, so if you run across one of those just mention it in the comments and I’ll take it off the list.

Available

• audacity
• filezilla
• compizconfig-settings-manager
• cheese
• adobe-flashplugin
• libreoffice-writer
• emesene
• smplayer
• audacious
• wesnoth-1.8
• blender
• stellarium
• supertuxkart
• calibre
• virtualbox-ose

Done

• k3b done!
• rhythmbox done!
• pidgin done!
• remmina done!

Not Available

• firefox doesn’t properly handle command line options
• vlc doesn’t support command line options
• skype does not support command line options
• gparted only supports 1 commandline option which is useless
• gtk-recordmydesktop does not support command line options
• openshot only supports 1 commandline option which is useless
• eclipse does not support command line options
• ubuntuone-control-panel needs dynamic quicklist (required coding)

Jorge Castro has also linked to an AskUbuntu page that lists many pre-made Quicklists for various apps that just need to be made in a bzr branch and turned into a merge proposal, which is another great and simple way to contribute to Ubuntu.

Last night I posted about how non-developers can directly contribute to the Unity desktop experience, and this morning I was greated by not one, but two contributions already made by Nekhelesh Ramananthan.

First he added player controls to Totem, then he added shortcuts for Update Manager and PPA management to the Software Center launcher. That is some awesome work.

Thanks Nekhelesh!