Archive for the ‘PPA’ Category

PPAs now 2 GiB

Tuesday, May 4th, 2010

Since we first launched Personal Package Archives, we’ve set a starting size limit of 1 GiB.

However, we’ve also said “yes” pretty much every time someone’s ask us for more space. So, seeing as how most requests have been for an increase to 2 GiB, we’ve gone ahead and upgraded every PPA to a minimum of 2 GiB. If you already have a larger allowance, it’ll stay in place.

What’s a build score, then?

Friday, May 8th, 2009

If you upload source packages to Launchpad — either to be built and distributed in a PPA or for Ubuntu’s primary archive — you’ve probably spotted the term “build score” and wondered what it represents.

A build score is the priority that Launchpad has assigned to a particular build job. I’ve just added a new page to the Launchpad help wiki that explains how Launchpad decides that priority but here’s the quick version.

When you upload a source package, Launchpad looks at:

  • the target component
  • the target pocket
  • source urgency — defined by the packager
  • time since upload to the queue
  • whether the package is destined for a public or private PPA.

Launchpad then gives the build a score in each of those categories, adds it all up and the total is the build score you see on the build details page. The higher number, the higher the priority.

So, for example, a build destined for the security pocket gets a higher priority than a backport. However, to prevent lower priority packages from never making it to a builder, packages get an extra few points as they get older.

Get the full details in the guide over on the help wiki.

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.