Canonical Voices

Posts tagged with 'ppa'

Colin Watson

The Ubuntu Foundations team has sponsored work on various improvements to Launchpad’s archive handling lately, mainly to expose various new facilities on the API where we were previously using privileged scripts.  This has involved cleaning up a substantial amount of old code along the way, and it has become possible to fix some other old bugs as spin-offs.

One of these old bugs is “Archive:+copy-packages nearly unusable due to timeouts”.  The +copy-packages page allows anyone who can upload to a PPA to instead copy packages from another PPA.  This saves effort, and in the “Copy existing binaries” mode it can save a substantial amount of build time as well.  For example, the LibreOffice packaging team uses this to deliver packages to different sets of users after they have passed various levels of testing.

Unfortunately, the very cases where this is most useful, namely large and complex packages, are also the cases where it is most likely to break.  Copying large numbers of binary packages involves large numbers of database queries and can quite easily overrun the timeout for a single request to the Launchpad web application.  Doing this for several series at once, a common case which seems reasonable, is proportionally less likely to work.  Various attempts have been made to optimise the database interactions here, but ultimately doing lots of complex synchronous work in time for a single web request is doomed to failure.

The solution to all this is to copy packages asynchronously.  For some time Launchpad has had the ability to schedule “package copy jobs” which run very shortly after the request (typically within a minute) but not immediately.  For example, the Ubuntu team uses these when copying new versions of packages from Debian unstable in cases where there are no Ubuntu-specific modifications, and when releasing proposed updates to stable releases for general use after verification.  A similar facility has been present in the code for the +copy-packages page for some time, but not exposed due to various bugs.  We believe that these bugs have been fixed now, and so we would like to start copying packages asynchronously when requested via the web UI.

We have exposed this to beta testers first.  The effect is that, if you are a beta tester when you ask for packages to be copied, you will be told something like “Requested sync of 2 packages.  Please allow some time for these to be processed.”  The processing should normally happen within a minute or two, and you will be able to see it in progress on the +packages page for the target archive.  If it succeeds, the in-progress notification will be removed and you will be able to see the changes in the target archive.  Otherwise, you will see a failure notification along these lines:

A notification of a failed copy to a PPA.

If beta-testing goes well, then we will enable this for all users, and remove the old synchronous copying code shortly afterwards; so please do report any problems you see.

If you are relying on package copies in the web UI happening immediately rather than within a few minutes, firstly, please contact us (e.g. #launchpad-dev on freenode IRC, or launchpad-users@lists.launchpad.net) as we would like to understand your requirements in more detail; secondly, you may be able to use the Archive.syncSource API method instead, which also has timeout constraints but is at least guaranteed to remain synchronous.  However, we hope that most people will not have such a requirement.

Read more
Curtis Hovey

Setting up a commercial project in Launchpad has gotten easier. You can now quickly register a proprietary project and enable private bugs. You can create private teams and private personal package archives, AKA private PPA or P3A without the assistance of a Launchpad admin.

When you select the Other/Proprietary license while registering a project, or changing the project’s details,

it is given a complimentary 30-day commercial subscription.

The delay between the moment when a commercial project was registered and when the commercial subscription was purchased and then applied to the project caused a lot of confusion. During this delay, proprietary data could be disclosed. We chose to award the project with a short term commercial subscription which enabled the project to be properly configured while the 12-month commercial subscription was being purchased and applied to the project.

Any project with a commercial subscription can enable

Default private bugs
Once enabled by configuring the project’s bug tracker, all new reported bugs are private. You can choose to make the report public.
Default private bugs
Default private branches
You can request a Launchpad admin to configure private branches for your teams. (You will be able to do this yourself in the near future when projects gain proprietary branches.)

As the maintainer of a project with a commercial subscription, you can register

Private teams
When you register a team, you can choose to set the team visibility to private. The team’s members and data is hidden from non-members.
Private mailing lists
When you create a mailing list for a private team, the archive is also private. Only team members may see the messages in the archive.
Private PPAs
When you create a PPA for your public team, you may choose to make it private; private teams can only have private PPAs. You can subscribe users to your archive so that they may install packages without revealing all your team’s members and data to the subscriber.

A secondary benefit of this change is that you can now try Launchpad’s commercial features before purchasing a 12-month commercial subscription. The features will be disabled at the end of 30-days. Your test data will remain private to ensure your data is not disclosed.

Any open source project may also have a commercial subscription to enable commercial features. You can purchase a commercial subscription at the Canonical store. Commercial subscriptions cost US$250/year/project + applicable V.A.T.

 

(Photo by Fred Dawson on flickr, creative commons license)

Read more
Matthew Revell

How to add a PPA to Ubuntu

I noticed over the weekend that the search term bringing most visitors to this blog was “how to add a PPA to Ubuntu” and variants.

So, here’s a screencast showing you how.

For more, see our help guide.

Update: here’s a video showing how to do it with the Ubuntu Software Centre.

Read more
Matthew Revell

Source package recipes

A pint of ale

Here’s a quick pub quiz:

Question: How do you make packages for Ubuntu?

You can choose from the following answers:

  1. learn Debian packaging through hours of study and practice
  2. borrow existing packaging from elsewhere, throw a couple of Bazaar branches together and let Launchpad handle the rest
  3. Uruguay in both 1930 and 1950.

If you selected either of the first answers you’d be right.

Okay, so, if you want to do it for real — i.e. become an Ubuntu MOTU or otherwise create Debian-style packages from scratch — then you still need to go through the hard work.

However, for everyone else who really just needs to get something out there and working for, say, a group of beta testers, we now have Launchpad’s source package recipes.

How it works, in three steps

It’s almost ridiculously easy to set up a source package build:

  1. Choose a branch in Launchpad, whether hosted directly or imported.
  2. Write a short recipe that tells Launchpad which other branches to pull in, for example to provide packaging or make the code buildable.
  3. Paste your recipe into Launchpad.

And that’s it. Within a few minutes you can set up a daily build direct from your trunk or any other buildable branch in Launchpad.

Watch how it works in our screencast:

An example

Alvin Hall

Let’s say you’re the developer of a home finance application called Alvin. You track your project’s code using Git and host it on your own server. For the past couple of years Alvin has been packaged in the Ubuntu universe and your trunk has also been imported from Git to a Bazaar branch in Launchpad at lp:alvin.

Just as you’re approaching Alvin’s next release, you want to get some wider testing. In the past, you’ve published a nightly tarball and provided instructions on manual installation. That’s given you a handful of dedicated beta testers but you’re worried that you’re asking too much of people.

With Launchpad’s source package recipes, you write a short recipe that pulls in your trunk branch, adds the packaging from Alvin’s existing Ubuntu package and then builds an installable Ubuntu package in the PPA of your choice:


# bzr-builder format 0.3 deb-version 2.0beta+{revno}
lp:alvin
nest-part packaging lp:ubuntu/alvin debian debian

Paste the recipe into Launchpad and with a couple of clicks you have a daily build of your trunk, that’s published as an Ubuntu package in your PPA.

Now you can ask people to test the latest Alvin code by doing no more than adding your PPA to their system. Launchpad will build a new version of the package on each day it spots a change in your trunk (or the Ubuntu packaging). For your beta testers, any changes will show up just like any other Ubuntu update.

Simple as that!

Here’s a quick recap of how it works: you can take any buildable branch — whether hosted in directly Launchpad or imported from Git, Subversion, CVS or Bazaar hosted elsewhere — merge or nest other branches, add packaging and then leave it to Launchpad to create a daily build that it publishes in your chosen PPA.

Seeing it in action

List of daily builds in Launchpad

During the beta, people added a whole range of source package recipes, with a list of more than 350 daily builds as I write this.

Daily builds on Launchpad right now include Project Neon, who have around sixty recipes providing daily builds of KDE and Amarok. There are also daily builds of the Scribus DTP app, Audacity and the scriptable screen reader Gnome Orca.

Try it out

It’s easy to get your own source package recipes and daily builds up and running.

Start at our Getting Started guide and screencast.

I’ll leave the last word to Luke Benstead, who has been using source package recipes while developing a set of game libraries:

I’ve been using LP to develop some small open source game libraries. Because there are quite a few of them, packaging them all is a pain, so the package builds have worked out pretty well for them.

Now I get nightly builds delivered to a PPA, so I know that if I fix a bug it’s reflected to all my machines. And my recipes are only a single line so they’ve been really easy to use. I’m not really sure how they could be easier.

Images:
Beer photo by dearbarbie. CC-BY-SA.
Alvin Hall photo by Phil Guest. CC-BY-SA.

Read more
Martin Pool

Short story: http://pad.lv/12345 takes you to bug 12345, and pad.lv describes more abbreviations.

padlv

Sometimes you’d like to point people to an interesting bug in a project that uses Launchpad, like bug 685380 (that ‘1′ and ‘l’ may need to be more distinct in the new Ubuntu Font).

Typing out https://launchpad.net/bugs/685380 is a bit tedious, and it uses up a fair bit of space in a microblog entry. You can use any of innumerable URL-shortening services, but then the URL’s opaque; which is a shame since it really just wants to represent a 6-digit number.

Therefore: pad.lv (pad love), transparent short URLs for bugs, and other things including projects, people, bug-filing forms, packages, and more.

Maybe someone would like to make bookmarklets that generate these links, or add them into the Launchpad UI?

Thanks to Latvia for letting us use a fraction of their domain name space!

Read more
Martin Pool

You may start getting “Failed to fetch” error messages when updating your software sources (e.g. through “apt-get update” or “Reload package information” in Synaptic), which may be due to a bug we’ve just cleaned up in Launchpad’s PPAs.

The error looks like this:

  W: Failed to fetch http://ppa.launchpad.net/chromium-daily/ppa/ubuntu/dists/maverick/Release
  Unable to find expected entry  restricted/binary-i386/Packages in Meta-index file (malformed Release file?)

  E: Some index files failed to download, they have been ignored, or old ones used instead.

Fixing the cause of the error

Here’s how to fix it. In your terminal, type:

 sudo gedit /etc/apt/sources.list

In the editor, look for PPA sources — these are URLs that feature the ppa.launchpad.net domain. In this example, someone has set up the ~ubuntu-x-swat/x-updates PPA incorrectly:

 deb http://ppa.launchpad.net/ubuntu-x-swat/x-updates/ubuntu maverick main
 deb http://ppa.launchpad.net/ubuntu-x-swat/x-updates/ubuntu maverick restricted
 deb http://ppa.launchpad.net/ubuntu-x-swat/x-updates/ubuntu maverick universe
 deb http://ppa.launchpad.net/ubuntu-x-swat/x-updates/ubuntu maverick multiverse

All of these refer to different components within the same PPA. PPAs only have the first component, so you should delete lines for PPAs that don’t end in “main”. Watch out for lines that wrap, as with the “restricted”, “universe” and “multiverse” examples above.

You may also need to check source lists under the /etc/apt/sources.list.d directory.

Note: you should leave your standard Ubuntu sources, and any non-PPA sources, just as they are.

If you’re not sure how to do this, pop into #launchpad on freenode and one of the Launchpad community will help.

Why this has happened

The Debian-style archives used by Ubuntu are often divided into different components. With Ubuntu, you’ve probably heard of at least “main” and “universe”.

PPAs don’t use these components. However, a bug in Launchpad meant that, until December, PPAs were published with a number of different components. All of these components were empty and there was no way to publish anything to them.

Today, we started to remove these empty components from PPAs. The only impact we anticipate is that anyone whose sources.list referenced these components in a PPA will now see an error when performing an apt-get update or similar.

No packages are being deleted and anyone with a correctly defined sources.list will be able to carry on just as before.

(Originally from Julian.)

Read more
Julian Edwards

An long-requested feature in Launchpad is to let people see who’s using a PPA. Finally, we’ve implemented this!

Initially, the stats are only available on Launchpad’s webservice API. but we aim to show something useful in the web UI at some point.

If you are already familiar with the webservice API, then you can use the following binary_package_publishing_history object methods to retrieve the information:

  • getDailyDownloadTotals
  • getDownloadCount
  • getDownloadCounts

Fabien Tassin is already using the stats to see how many people are using his daily build PPAs, and wrote an interesting blog post about it.

Read more
Julian Edwards

Continuing with the recent improvements to the build farm – Jelmer has made another massive one.

The last major scalability problem that we had was one where the whole farm was blocked when a single builder was ready to upload a build. In the case of large packages, like the kernel, the manager process could block for over a minute while it waited for the upload processor to unpack the package and verify its contents.

Jelmer’s work has decoupled the upload processing from the build farm manager process. What happens now is that the files collected from the builder are thrown into a staging queue area and then the manager process immediately continues with polling the rest of the builders, unblocked. A cron job will then process the builder upload queue at 1 minute intervals.

You can see the dramatic effect this has had on the overall queue for the PPA builders here:
Build Farm Queue Size

This is quite an incredible improvement as you can see! But we’re not stopping there, we’re currently doing a massive refactoring of the builder dispatching code so it’s all fully asynchronous. When this is all done we’re going to be in superb shape to support an increase in load that’s anticipated from the increasing number of people using the package recipes.

Read more
Matthew Revell

SFTP uploads holding post

You can now use SFTP to upload source packages to your Personal Package Archive!

If you’re already familiar with uploading to a PPA, all you need to do is ensure your dput.cf includes the following:


method = sftp
login = <your Launchpad account name>

If you’re new to PPAs, but already know how to create packages for Ubuntu, take a look at our guide.

Read more
Matthew Revell

PPAs now 2 GiB

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.

Read more