PPA on Launchpad Blog

Self-service riscv64 builds

Colin Watson — Wed, 22 Nov 2023 14:00:43 +0000

Launchpad has supported building for riscv64 for a while, since it was a requirement to get Ubuntu’s riscv64 port going. We don’t actually have riscv64 hardware in our datacentre, since we’d need server-class hardware with the hypervisor extension and that’s still in its infancy; instead, we do full-system emulation of riscv64 on beefy amd64 hardware using qemu. This has worked well enough for a while, although it isn’t exactly fast.

The biggest problem with our setup wasn’t so much performance, though; it was that we were just using a bunch of manually-provisioned virtual machines, and they weren’t being reset to a clean state between builds. As a result, it would have been possible for a malicious build to compromise future builds on the same builder: it would only need a chroot or container escape. This violated our standard security model for builders, in which each build runs in an isolated ephemeral VM, and each VM is destroyed and restarted from a clean image at the end of every build. As a result, we had to limit the set of people who were allowed to have riscv64 builds on Launchpad, and we had to restrict things like snap recipes to only use very tightly-pinned parts from elsewhere on the internet (pinning is often a good idea anyway, but at an infrastructural level it isn’t something we need to require on other architectures).

We’ve wanted to bring this onto the same footing as our other architectures for some time. In Canonical’s most recent product development cycle, we worked with the OpenStack team to get riscv64 emulation support into nova, and installed a backport of this on our newest internal cloud region. This almost took care of the problem. However, Launchpad builder images start out as standard Ubuntu cloud images, which on riscv64 are only available from Ubuntu 22.04 LTS onwards; in testing 22.04-based VMs on other relatively slow architectures we already knew that we were seeing some mysterious hangs in snap recipe builds. Figuring this out blocked us for some time, and involved some pretty intensive debugging of the “strace absolutely everything in sight and see if anything sensible falls out” variety. We eventually narrowed this down to a LXD bug and were at least able to provide a workaround, at which point bringing up new builders was easy.

As a result, you can now enable riscv64 builds for yourself in your PPAs or snap recipes. Visit the PPA and follow the “Change details” link, or visit the snap recipe and follow the “Edit snap package” link; you’ll see a list of checkboxes under “Processors”, and you can enable or disable any that aren’t greyed out, including riscv64. This now means that all Ubuntu architectures are fully virtualized and unrestricted in Launchpad, making it easier for developers to experiment.

New domain names for PPAs

Colin Watson — Wed, 16 Feb 2022 18:08:27 +0000

Since they were introduced in 2007, Launchpad’s Personal Package Archives (PPAs) have always been hosted on ppa.launchpad.net. This has generally worked well, but one significant snag became clear later on: it was difficult to add HTTPS support for PPAs due to the way that cookies work on the web.

Launchpad uses a cookie for your login session, which is of course security-critical, and because we use multiple domain names for the main web application (bugs.launchpad.net, code.launchpad.net, and so on), the session cookie domain has to be set to allow subdomains of launchpad.net. We set the “Secure” flag on session cookies to ensure that browsers only ever send them over HTTPS, as well as the “HttpOnly” flag to prevent direct access to it from JavaScript; but there are still ways in which arbitrary JS on an HTTPS subdomain of launchpad.net might be able to exfiltrate or abuse users’ session cookies. As a result, we can never allow any HTTPS subdomain of launchpad.net to publish completely user-generated HTML that we don’t process first.

We don’t currently know of a way to get ppa.launchpad.net to serve arbitrary HTML as Content-Type: text/html, but this is quite a brittle protection as there are certainly ways (used for things like installer uploads) to upload arbitrary files to ppa.launchpad.net under a user-controlled directory structure, and we don’t want the webapp’s security to depend on nobody figuring out how to convince a browser to interpret any of that as arbitrary HTML. The librarian is already on a separate launchpadlibrarian.net domain name for a similar reason.

To resolve this dilemma, we’ve added a new ppa.launchpadcontent.net domain name which supports both HTTP and HTTPS (and similarly private-ppa.launchpadcontent.net for private PPAs, which as before is HTTPS-only). add-apt-repository in Ubuntu 22.04 will use the new domain name by default.

The old names will carry on working indefinitely - we know they’re embedded in lots of configuration and scripts, and we have no inclination to break all of those - but we recommend moving to the new names where possible. ppa.launchpad.net will remain HTTP-only.

Some systems may need to be updated to support the new domain name, particularly things like HTTP(S) proxy configuration files and no_proxy environment variables.

PPAs for ppc64el

Colin Watson — Tue, 27 Oct 2015 17:33:13 +0000

Personal package archives on Launchpad only build for the amd64 and i386 architectures by default, which meets most people’s needs. Anyone with an e-mail address can have a PPA, so they have to be securely virtualised, but that’s been feasible on x86 for a long time. Dealing with the other architectures that Ubuntu supports (currently arm64, armhf, powerpc, and ppc64el) in a robust and scalable way has been harder. Until recently, all of those architectures were handled either by running one builder per machine on bare metal, or in some cases by running builders on a small number of manually-maintained persistent virtual machines per physical machine. Neither of those approaches scales to the level required to support PPAs, and we need to make sure that any malicious code run by a given build is strictly confined to that build. (We support virtualised armhf PPAs, but only by using qemu-user-static in an amd64 virtual machine, which is very fragile and there are many builds that it simply can’t handle at all.)

We’ve been working with our sysadmins for several months to extend ScalingStack to non-x86 architectures, and at the start of Ubuntu’s 16.04 development cycle we were finally able to switch all ppc64el builds over to this system. Rather than four builders, we now have 30, each of which is reset to a clean virtual machine instance between each build. Since that’s more than enough to support Ubuntu’s needs, we’ve now “unrestricted” the architecture so that it can be used for PPAs as well, and PPA owners can enable it at will. To do this, visit the main web page for your PPA (which will look something like “https://launchpad.net/~<person-name>/+archive/ubuntu/<ppa-name>”) and follow the “Change details” link; you’ll see a list of checkboxes under “Processors”, and you can enable or disable any that aren’t greyed out. This also means that you can disable amd64 or i386 builds for your PPA if you want to.

We’re working to extend this to all the existing Ubuntu architectures at the moment. arm64 is up and running but we’re still making sure it’s sufficiently robust; armhf will run on arm64 guests, and just needs a kernel patch to set its uname correctly; and powerpc builds will run in different guests on the same POWER8 compute nodes as ppc64el once we have suitable cloud images available. We’ll post further announcements when further architectures are unrestricted.

Launchpad news, April-June 2015

Colin Watson — Thu, 09 Jul 2015 01:07:23 +0000

It’s been a while since we posted much regularly on this team blog, not least because for a while Launchpad was running more or less in maintenance mode. That’s no longer the case and we’re back to the point where we can do feature development work again, as exemplified by our recent addition of Git code hosting support.

Lots of other things have been happening in the Launchpad world lately, though, and the half-way point in the year seems like a good time to start talking about them. I’m going to try to do this a bit more regularly, aiming for about once a month when we also update our internal stakeholders. This post covers roughly the last three months.

Git

Of course, you don’t get to release a major new feature and then have everything be perfect. In fact, we’d released it pretty much as soon as we had a minimum viable product, so we knew there was plenty more to do.

Now that the basics work reasonably well, we’ve been focusing on tying off loose ends, and on getting to the point where Launchpad itself can be self-hosted in Git: this is partly because most of the things we need to do for that are relevant to many other projects considering a migration, partly because that ensures that any problems with it will affect Launchpad developers directly, and partly because this will allow us to trim a very large amount of database cruft associated with the representation of Launchpad’s own branches.

Here’s a brief changelog since our initial public announcement:

Leaving the “Target reference path” field empty when proposing a Git-based merge proposal no longer crashes (#1451068)
Git-based merge proposals can be deleted
Pushing to private repositories no longer hangs (#1451107)
The backend now stores reflogs so that we can help users recover from mistakes
Pushing a new default repository for a project now sets the repository owner to the project owner rather than to the person performing the push
The project +sharing view now handles Git repositories
Branches of a project default repository are now shown on the project’s code page, although we expect to be making significant further improvements in this area soon
Individual Git commits under “Recent Commits” now link directly to a full view of the corresponding commit
Merge proposal listings now cover Git (#1453020)
Branches in private repositories now show a privacy banner (#1457553)
Repositories can now be deleted (#1456583)
Private repositories are now browseable and show a privacy banner in the browsing interface
The URLs for Git-based merge proposals have moved to be directly under the source repository rather than under the source branch, so that historical MPs can still be accessed after deleting the branch (#1456589)
Launchpad now sends mail for Git-based merge proposals
There are various new Git repository listing views, chiefly for projects, packages, and people
Repositories now have a complete edit form allowing you to rename them, move them between targets, and set their default branch (“HEAD”) (#1456625)
We’ve exported a few more bits and pieces on the webservice API to support Git merge robots
We’ve brought various bits of automation for Git-based merge proposals up to par with their Bazaar equivalents: when a Git branch is updated, Launchpad now automatically updates the preview diffs for any MPs where that is the source branch, and detects whether any MPs where that is the target branch can now be marked as Merged
The Code settings view for projects now allows you to set the project’s default Git repository and to choose whether the default revision system for the project is Bazaar or Git

We’ve started on support for webhooks, and hope to be able to tell you more about this soon. Git-to-Git repository mirroring and native Git recipes are also frequent requests that we know are important to people, and we hope to get to those soon.

Other code review changes

Many of the changes needed for Git touched on our code review infrastructure, but we’ve been making some other improvements there too. Launchpad has supported “inline comments” on merge proposals for a year or so now, allowing you to comment on parts of a diff without having to manually quote it; but the feature hadn’t been quite finished and lots of people had nits to pick with it. We’ve made a couple of improvements here lately:

Preview diffs in merge proposals now have keyboard navigation to move between files, diff hunks, and inline comments
Links to diffs now include a per-file diffstat under an expander triangle
The mails sent when a reviewer adds inline comments now only include relevant parts of the diff context rather than the entire diff, making them much easier to read and making it harder to miss comments (#1334577)

We threw in a couple of bonus features here as well. You can now see side-by-side diffs for merge proposals as well as unified diffs (#917502): there’s a link at the top of each preview diff allowing you to switch it to side-by-side mode (we may add a user preference for this later). And resubmitting a merge proposal now automatically preserves the commit message (#676769).

Package build infrastructure

When we first added support for building debug symbol packages (ddebs) in Ubuntu, we handled the build and publication side of things with a temporary hack involving a custom hack to our sbuild fork that stashed the ddebs on the builder for a while, and a job that periodically fetched them to ddebs.ubuntu.com. As is the way of temporary hacks, it proceeded to stay that way for eight and a half years. It mostly worked, but was rather fragile, contributed to tying us to an old sbuild, wasn’t very extensible to PPAs, and couldn’t work with virtualised builders where all the builder’s state is reset before every build.

A couple of years ago we put together the Launchpad changes required to store ddebs straightforwardly in Launchpad instead, but weren’t able to deploy this at the time due to needing better librarian infrastructure. We finally got all this cleared out in April and deployed the new ddeb publishing mechanism. The main user-visible effect of this is that ddebs.ubuntu.com isn’t liable to lose packages any more, and ddebs are also available from Launchpad build pages.

Having done this, we were able to upgrade from our 2004-era fork of sbuild to a modern version, which fixed a number of long-standing bugs.

All architectures are now optional for PPAs (#1244868), so, for example, a PPA that only needs to support armhf can save builder cycles by disabling amd64 and i386. At the moment this can only be done by Launchpad administrators, so ask a question on Launchpad if you think this would be worth doing for any of your PPAs.

We rewrote the way that we install build-dependencies for source package recipes. This allows recipes to handle the “:native” qualifier in build-dependencies which is used in some places as part of supporting cross-building.

The next step in this modernisation programme will be to move all builds into ScalingStack and decommission the corresponding bare-metal builders, which we’ll be starting soon and working on an architecture-by-architecture basis as that cloud gains support for them. In the short term, this will give us better build capacity on the migrated architectures; in the longer term, it will let us support PPA builds on more architectures, and erase the cumbersome distinction between “non-virtualised” and “virtualised” builders. More news on this as it happens.

Performance

We upgraded to significantly more modern database servers earlier this year, which meant that a lot of hitherto difficult timeout problems suddenly either disappeared or became tractable. There are still some bad queries and a few mysterious problems, but as a general trend our timeout rates are very significantly down from where they were six months ago. We have some more general plans in this area, and will continue to spot-fix bad pages as they show up and as time permits.

Epilogue

We have lots more to do across the whole application, but still have a rather limited number of developers. If any of this kind of thing sounds interesting and you’d like to help, you can!

Setting up commercial projects quickly

Curtis Hovey — Wed, 18 Apr 2012 12:38:45 +0000

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 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)

Adding a PPA to Ubuntu — the GUI way

Matthew Revell — Thu, 21 Apr 2011 15:11:29 +0000

On Monday I posted a video showing how to add a PPA to Ubuntu using a terminal.

And here’s a video showing how to do it using Ubuntu’s Software Centre.

How to add a PPA to Ubuntu

Matthew Revell — Mon, 18 Apr 2011 22:34:16 +0000

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.

Source package recipes

Matthew Revell — Wed, 06 Apr 2011 16:28:55 +0000

Here’s a quick pub quiz:

Question: How do you make packages for Ubuntu?

You can choose from the following answers:

learn Debian packaging through hours of study and practice
borrow existing packaging from elsewhere, throw a couple of Bazaar branches together and let Launchpad handle the rest
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:

Choose a branch in Launchpad, whether hosted directly or imported.
Write a short recipe that tells Launchpad which other branches to pull in, for example to provide packaging or make the code buildable.
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

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

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.

"Failed to fetch" errors for PPAs ...

Martin Pool — Fri, 18 Feb 2011 04:55:19 +0000

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.)

Tracking PPA download statistics

Julian Edwards — Tue, 11 Jan 2011 13:11:55 +0000

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.