Archive for the ‘PPA’ Category

Updating the Personal Package Archive docs

Thursday, April 9th, 2009

Recently I spent a day with Julian Edwards, one of the developers working on Launchpad’s Personal Package Archives feature.

We wanted to come up with a plan for improving the help materials we have for PPAs, including:

Right now, our PPA help guide is one long and somewhat unwieldy wiki page. Over the next couple of months, I’m going to break it down into smaller guides each based around one particular task, such as creating the source package and uploading the package, including how to deal with errors.

Up until now, we haven’t included any help on actually creating a Debian-style package ready for uploading to a PPA. One of the reasons for that was that there’s a wealth of packaging material and support already available in the Ubuntu community and more widely. However, one of the new guides I’m going to create will look at basic packaging, tailored specifically to the needs of PPAs.

If you use PPAs, I’d love your input on this work. Either mail me directly, leave a comment here or visit the bug report and blueprints I’ve created:

People and teams get multiple Personal Package Archives

Wednesday, April 1st, 2009

The release of 2.2.3 brings with it a change for PPAs — we are now supporting multiple PPAs per person!

You will have probably already noticed that we made a change in 2.2.1 that altered the URLs you see for a PPA’s index page and its sources.list entry; these now have the extra “ppa” in there. This is actually the default name for the first PPA that anyone creates.
Example old-style URL:

Which is now:

You can create additional PPAs from your own profile page or your team’s profile page. You are able to name them whatever you like with one exception — we are not allowing you to name them “ubuntu”. This is so that we can maintain backwards compatibility with the old upload paths where you don’t need to specify the default PPA’s name.

To upload to the additional PPAs your upload path should look like:

incoming = ~myname/ubuntu/otherppaname

These additional PPAs will behave as any other PPA, the only difference being that they clearly belong to a person or a team, and you won’t need to create dummy teams/people to have more PPAs.

We hope you enjoy this new feature!

Simplifying for multiple PPAs

Monday, February 9th, 2009

If you’ve ever contributed to a Debian-based distribution or used the neat Launchpad PPA services then you’ve probably used dput before. We use dput to upload packages to a Debian repository such as the Debian Archive, Ubuntu Archive, or personal archives such as a Personal Package Archive on Launchpad. Getting the hard work you’ve done to the archive for the whole world to enjoy is an important part of a packager’s work flow and should be easy as possible. This is probably why dput is so popular – it does its job and stays out of the way.

However, recently while adding support to dput for uploading packages via sftp, I realized that one’s dput configuration file can get rather lengthy and messy. Being the Lazy Engineer (TM) that I am, I decided to fix this problem. What I noticed was that you needed to configure an upload target (aka host) for each PPA you might want to upload to but all the configuration stanzas for PPAs were exactly the same except for a part of the path. In fact, it seemed like a number of the stanzas for other archives in my dput configuration file were the same except for the same spot. Wouldn’t it be nice if I could just have a single configuration stanzas for these cases and only need to supply an argument for dput to automagically do the right thing? I thought so which is why I’ve added a new feature to dput that allows you to have an upload target “template” where you can pass a single argument to the target specified that will be used to fill in the missing pieces.

So, instead of having a file in your home directory that looks like the following:

fqdn =
method = ftp
incoming = ~cody-somerville/ppa/ubuntu
login = anonymous

fqdn =
method = ftp
incoming = ~xubuntu-dev/ppa/ubuntu
login = anonymous


I can simply have the following:

fqdn =
method = ftp
incoming = ~%(ppa)s/ubuntu
login = anonymous

To upload to my PPA now, I’d type: dput ppa:cody-somerville/ppa <changesfile>

To upload to the Xubuntu Developers’ ppa, I’d type: dput ppa:xubuntu-dev/ppa <changesfile>

Once Launchpad supports multiple PPAs per user or team, simply replace “ppa” with
the name of the PPA. If you’re lazy, you can modify your to have the
ppa part automatically entered for you until then.

Anyhow, I hope you enjoy. Cheers!

PPA page performance improvements

Monday, February 9th, 2009

Last week was the first of some Launchpad Performance Weeks that we’re embarking upon. The Soyuz team worked hard on improving the performance of the PPA page, which had a tendency to be very slow or even time out on PPAs that have a lot of binaries published.

The more observant of you will have noticed that the PPA page on edge is now using asynchronous requests to fetch both the “Repository disk usage” section, and the package information section that is expanded when you click on the triangle at the left of each source package row. This means that the initial page load time is a lot quicker! There’s still some more speed we can get out of the page by reducing the query load that it places on the database server, and we’ll deliver that change soon.

We also fixed a smaller snafu — as part of the webservice work that we’re doing, we managed to accidentally enable a URL that let you view the main Ubuntu repository as if it were a PPA page. These links nearly always timed out because of the size of the Ubuntu archive, so that URL will now redirect to the /ubuntu page on Launchpad instead.

Also in the pipeline is a major overhaul of the PPA page. Watch out for that soon!

Adding a PPA’s key to Ubuntu

Wednesday, January 28th, 2009

Last month I mentioned that we were generating a unique key for each Personal Package Archive.

Well, that’s complete meaning each PPA now has its own key that’s used to sign its packages. And if you create a new PPA, Launchpad will generate a new key for it within a couple of hours.

This means that you now need to add the PPA’s key to apt before you install any of its packages. It’s really easy: all you need to do is copy the PPA’s public key and import it using System->Administration->Software Sources and then the Authentication tab.

Here’s a screencast that takes you through the steps:

(Higher quality Ogg Theora version)

Of course, you can also do it in the terminal. There’s more on the PPA help page.

Note: the PPA keys help you see that the package hasn’t been altered since Launchpad built it on behalf of the PPA owner. It does not mean that Launchpad, Ubuntu or Canonical endorse the packages. You should ensure you trust the PPA owner before you install their software.

Feelin’ hot hot hot

Thursday, October 16th, 2008

If you’ve ever come to file a bug and found that it’s already been reported, you may have wanted to let the project know that you too have been affected.

Trouble is: many projects find “me too” comments unhelpful because they don’t add much to the discussion.

Launchpad’s new “This bug affects me too” feature lets you record just that but without the guilt! Give it a go in our staging environment.

We’ll use the “me too” data in future to help projects identify “hot” bugs.

Kubuntu distributes KDE 4 using PPA

Monday, January 14th, 2008

Seen some of the bling and functionality in KDE 4 and thought, “I want some of that”?

If you’re running Kubuntu or Ubuntu, no problem! Thanks to Launchpad’s Personal Package Archives, upgrading is as simple as adding a new repository.

Jonathan Riddell – chief Kubuntoid – sent word on why they’re using a PPA:

“It’s the fastest and most flexible way to make our KDE 4.0 packages available. For example: it’s very easy to bring in new contributors since we can just add them to the necessary team. The other great thing is that we can get packages out there very quickly because they get published as soon as they are compiled.”

Take a look at Kubuntu’s KDE 4 page to get KDE 4 on your desktop.

Personal Package Archives for everyone!

Sunday, November 25th, 2007

Over the past few months we’ve been beta-testing a new Launchpad feature that has stirred up interest right across the Ubuntu community and beyond: Personal Package Archives (PPA).

Thanks to the members of the Launchpad Beta Testers team, the beta test has been a great success and we’re now confident that Personal Package Archives are ready for everyone.

So, as of today, every Launchpad user and team can have their own Personal Package Archive!

Building and hosting Ubuntu packages

Using your PPA you can build and publish software packages for Ubuntu. They can be based on existing Ubuntu packages or you can create completely new packages of any free software project.

So, you get your own apt repository – hosted by Launchpad – that Ubuntu users can add to their sources.list. Then, they can install packages from your repository and receive updates whenever you publish them, pretty much as they would with packages in the primary Ubuntu archive.

If you’re already comfortable with creating .deb packages for Ubuntu you can get started straight away. All you need to do is:

Activate PPA

  1. Import your GPG key to your Launchpad profile.
  2. Sign the Ubuntu Code of Coduct.
  3. Click Activate PPA on your Launchpad profile page.
  4. Follow our PPA quick-start guide.

To create a PPA for a team, click “Activate PPA” on your team’s overview page.

Launchpad will build your source for both i386 and AMD64 architectures against whichever currently supported Ubuntu release you choose.

Okay, but why?

So, it’s a pretty cool feature but why would you want to use it? I’ll leave it to Kiko – Launchpad Release Manager – to explain:

“Many developers want to modify existing packages, or create new packages of their software. The PPA service allows anyone to publish a package without having to ask permission or join the Ubuntu project as a developer.

“This is a tremendous innovation in the free software community. We hope that PPA will make it easier for developers and development teams who have excellent ideas to get their work into the hands of users for testing and feedback. They also get to mix with experienced packagers to improve their skills. PPA is a build system, a publishing system and a community experience. We are also really excited to add the ability to create packages aimed at the mobile environment from launch.”

Matt Zimmerman, who most in the Ubuntu community will know as Canonical’s CTO, explained how PPA will be useful for testing experimental builds:

“Adding a new feature to a package or building it against a new version of a system library requires extensive testing. A PPA allows a developer to form a community of testers who are interested in their changes. The testing community can install the packages, run them for the test period and then remove them cleanly from their system. If the developer releases an updated version, the Ubuntu Update Manager will automatically notify those testers and enable them to update to the newer versions with a single click. This creates a very efficient environment for developers and testers to improve their favorite software.

Dive in

Join us on the launchpad-users mailing list if you have questions or want to talk with other people about how they are using PPA. We’ve also got an introductory class for PPAs at 15.00 UTC on Wednesday 28th November in Freenode’s #ubuntu-classroom.

Personal Package Archives class – 28th November

Friday, November 23rd, 2007

Interested in creating your own Ubuntu packages using Launchpad’s Personal Package Archives?

Next week we’re holding the second of our Personal Package Archives 101 sessions. Launchpad developer Celso Providelo (cprov) and MOTU member Jordan Mantha (Laserjock) will take you through the basics of Personal Package Archives and, if there’s time, take questions.

When? 15.00 – 16.00 UTC 28th November 2007.
Where? #ubuntu-classroom on Freenode.

If there’s anything in particular you would like to see covered in the session send us a mail to

Look forward to seeing you there!

Update: Take a look at our PPA quick-start guide to get up to speed before the session.

Introducing AutoPPA!

Wednesday, November 7th, 2007

Launchpad’s Personal Package Archives (PPA) service takes a great deal of pain out of the packaging process. The days of maintaining system images for package builds are thankfully behind us, but preparing sources to upload to PPA can still be a tedious task. I’m primarily responsible for building packages for the Landscape client. There are several factors which make handling source uploads manually problematic:

  • Subtle differences between the various releases of Ubuntu we support require slightly different debian/control files to build packages for different releases.
  • The pool-based APT repository that PPA publishes requires release-specific package version numbers in debian/changelog. Also, the changelog needs to include the name of the Ubuntu release the build is targeted at.
  • I need to build packages often, weekly or bi-weekly and need to be able to roll out bug fix packages as quickly as possible.
  • The process needs to be sufficiently simple that someone else can easily step in and take care of it if I’m not around.
  • I need to produce packages for all officially supported Ubuntu releases. At present this includes Dapper through Gutsy. In a few weeks we’ll start building packages for hardy. As time goes on we’ll have even more releases to support.

Automation to the rescue! AutoPPA is an application that automates the process of preparing and uploading signed sources to PPA. A project using AutoPPA for automated source uploads needs to meet some criteria:

  • It must be stored in a local Bazaar branch.
  • It must include a debian directory with valid packaging files.

Setting up AutoPPA

The first thing we need to do is install and configure AutoPPA. Add the following deb lines to your /etc/apt/sources.list (replace the Ubuntu release name with whatever is appropriate for your system):

deb gutsy universe
deb-src gutsy universe

Then, update and install autoppa.

sudo apt-get update
sudo apt-get install autoppa

Now, let’s assume we are building packages for the fictitious supertool Python application. For the sake of this example, we’ll assume that the branch to build from is stored at ~/src/supertool/trunk and has Debian package files already in place.

Let’s start by setting up ~/.autoppa.conf. This configuration file contains per-project configuration settings that are unlikely to change often. Here’s a sample:

email = Jamshed Kakar
branch = /home/jkakar/src/supertool/trunk
repository = /home/jkakar/src/supertool
ppa = supertool-ppa
releases = dapper edgy feisty gutsy

The ’email’ field specifies the e-mail address to use in the changelog. The ‘branch’ field specifies the location of the Bazaar branch that code will be built from. The ‘repository’ field specifies the location where temporary branches will be created. The ‘ppa’ field specifies the name of the PPA to upload to, as defined in ~/ Finally, the ‘releases’ field is a space-separated list of Ubuntu releases to prepare packages for. The configuration file can contain as many stanzas as you have projects to build with AutoPPA. Note that the name of the stanza must be the same as the name of the source package, as specified in debian/control.

We’re not quite ready to generate and upload signed sources. There are two more things we need to deal with first. The first is dealing with subtle differences in debian/control because of differences between Ubuntu releases. For a Python application, one of these is the reliance on python-support on dapper and python-central for edgy and newer. AutoPPA provides a simple file-template replacement mechanism to deal with this. Any files that end in .autoppa will be specially processed with output written to a file without the .autoppa extension. There is currently a single special directive, AUTOPPA_INCLUDE(...):, that is handled specially when encountered. If the following lines are defined in debian/control.autoppa:

AUTOPPA_INCLUDE(dapper):Build-Depends: debhelper, python-support,
AUTOPPA_INCLUDE(edgy,feisty,gutsy):Build-Depends: debhelper,
python-central, lsb-release

Then the following will be included in debian/control for Dapper:

Build-Depends: debhelper, python-support, lsb-release

and for Edgy, Feisty and Gutsy:

Build-Depends: debhelper, python-central, lsb-release

This allows us to have a single set of sources despite requiring minor differences for different Ubuntu releases. The obvious question is, why not just use an OR in the Build-Depends list? The answer is that sbuild, used by PPA to perform package builds, doesn’t handle ORs. There are also other cases where this kind of simple processing is handy.

The second thing we may want is version replacement. Any file, not just those that end in .autoppa, that include the special AUTOPPA_VERSION() string will be replaced with the version generated for the build. In Python code the following idiom can be used to assign the version to a local, for example:


When AutoPPA is run it will replace the ‘devel’ portion of that magic symbol with whatever version has been generated for the build.

Finally, Seahorse and devscripts needs to be configured to handle automatic GPG signing. You’ll need to import your GPG key into Seahorse and enable password caching. In order for Debian’s devscripts to work with Seahorse you’ll also need to do the following:

cp /usr/share/devscripts/conf.default ~/.devscripts.

Edit ~/.devscripts, find the ‘# DEBUILD_PRESERVE_ENVVARS=""‘ line and
replace it with:


Phew. Thankfully all that is initial setup that you’ll hopefully never have to think about it again.

Using AutoPPA

Now that everything is set up for our fictitious project, we can use AutoPPA to generate signed sources and upload them for building by PPA. It’s accomplished with a single command:

autoppa supertool-1.0.0-supertool1

The first thing that will happen is that $EDITOR will be opened to collect changelog details. Once you’ve provided details for the changelog everything else should Just Work(tm). AutoPPA will do the following:

  • Create a build branch based on the source branch you specified in ~/.autoppa.conf
  • For each Ubuntu release you’ve specified to build for:
    • Files will be processed such that any .autoppa files are processed and AUTOPPA_VERSION() symbols are updated. The version generated, using the sample above will be, supertool-1.0.0-1-supertool1. This ensure a unique per-release version string.
    • The modifications made for the release will be committed as a revision in the temporary build branch and signed sources will be generated.
  • When signed sources have been generated for all the specified Ubuntu releases:
    • They will all be uploaded to the specified PPA.
    • The build branch will be merged back to the source branch, with the changelog as the commit message.
    • The merged revision will be tagged with the version, 1.0.0-supertool1 in this case.
    • Signed sources and the build branch will be deleted.

Now all we need to do is wait for PPA to build our packages! If you have more than one project setup in ~/.autoppa.conf you can specify multiple builds using a single command, such as:

autoppa supertool-1.0.0-supertool1 awesometool-1.0.0-awesometool1

That’s it! I hope AutoPPA turns out to be useful to others!