launchpadblog

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.

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:

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.

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 feedback@launchpad.net.

Look forward to seeing you there!

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

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 http://ppa.launchpad.net/autoppa/ubuntu gutsy universe
deb-src http://ppa.launchpad.net/autoppa/ubuntu 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:

[supertool]
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 ~/.dput.cf. 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,
lsb-release
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:

VERSION = "AUTOPPA_VERSION(devel)"[len("AUTOPPA_VERSION("):-1]

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:

DEBUILD_PRESERVE_ENVVARS="DISPLAY"

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!

The Personal Package Archives beta has received an enthusiastic response!

If you’re interested in learning to package for Ubuntu and want to use your PPA, read on.

At 15.00 UTC on Thursday 13th September, the Launchpad and Ubuntu MOTU teams are jointly hosting PPA and Packaging 101. This IRC session in #launchpad will introduce you to:

• the basics of packaging for Ubuntu
• solving your dependencies from the relevant Ubuntu section – i.e. the ogre model
• version consistency between PPA and Ubuntu’s primary archive.

It’s also your opportunity to ask questions about PPA and get answers from the Launchpad and MOTU teams. If you want to see a particular topic covered, add it to the class’s agenda on the Launchpad help wiki.

See you there!