If you are a member of Launchpad’s beta testers team, you can now try out Git-based recipes. These work very similarly to the Bazaar-based recipes that Launchpad has supported for a long time, with a few minor changes to handle differences in the underlying version control system: the main thing you’ll probably notice is that you almost always need to explicitly specify a branch name. The recipes documentation explains what to do; if you’re already familiar with how recipes work for Bazaar, then you should probably skip straight to the recipes guide to look over the differences for Git.
Please try this out and report any bugs you find. If all goes well, we’ll open this up to all users in a couple of weeks.
Update: as of 2016-03-15, this feature is enabled for all Launchpad users.
Published by Colin Watson November 9, 2015 in General
Here’s what the Launchpad team did in October.
If you are a member of Launchpad’s beta testers team, you can now try out webhooks for Bazaar branches and Git repositories. These can be used to set up integration with external sites for various purposes, such as running CI jobs or publishing documentation. We expect to open this up to all Launchpad users soon, but in the meantime please do file a bug against Launchpad itself if you encounter any problems.
See our webhooks documentation for more details.
Update: as of 2015-11-20, this feature is enabled for all Launchpad users.
Published by Colin Watson October 27, 2015 in PPA
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.
Published by Colin Watson October 4, 2015 in General
October already! As the leaves start to turn red here in the northern hemisphere, here’s a brief summary of what we did in September.
Published by Colin Watson September 2, 2015 in General
Here’s a summary of what the Launchpad team got up to in August.
Published by Colin Watson August 2, 2015 in General
Here’s a summary of what the Launchpad team got up to in July.
Published by Colin Watson July 29, 2015 in Notifications
Users of some email clients, particularly Gmail, have long had a problem filtering mail from Launchpad effectively. We put lots of useful information into our message headers so that heavy users of Launchpad can automatically filter email into different folders. Unfortunately, Gmail and some other clients do not support filtering mail on arbitrary headers, only on message bodies and on certain pre-defined headers such as Subject. Figuring out what to do about this has been tricky. Space in the Subject line is at a premium – many clients will only show a certain number of characters at the start, and so inserting filtering tags at the start would crowd out other useful information, so we don’t want to do that; and in general we want to avoid burdening one group of users with workarounds for the benefit of another group because that doesn’t scale very well, so we had to approach this with some care.
As of our most recent code update, you’ll find a new setting on your “Change your personal details” page:
If you check “Include filtering information in email footers”, Launchpad will duplicate some information from message headers into the signature part (below the dash-dash-space line) of message bodies: any “X-Launchpad-Something: value” header will turn into a “Launchpad-Something: value” line in the footer. Since it’s below the signature marker, it should be relatively unobtrusive, but is still searchable. You can search or filter for these in Gmail by putting the key/value pair in double quotes, like this:
At the moment this only works for emails related to Bazaar branches, Git repositories, merge proposals, and build failures. We intend to extend this to a few other categories soon, particularly bug mail and package upload notifications. If you particularly need this feature to work for some other category of email sent by Launchpad, please file a bug to let us know.
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.
Today we’re announcing early support for hosting Git repositories directly on Launchpad, as well as or instead of Bazaar branches. This has been by far the single most commonly requested feature from Launchpad code hosting for a long time; we’ve been working hard on it for several months now, and we’re very happy to be able to release it for general use.
This is distinct from the facility to import code from Git (and some other systems) into Bazaar that Launchpad has included for many years. Code imports are useful to aggregate information from all over the free software ecosystem in a unified way, which has always been one of the primary goals of Launchpad, and in the future we may add the facility to import code into Git as well. However, what we’re releasing today is native support: you can use git push to upload code to Launchpad, and your users and collaborators can use git clone to download it, in the same kind of way that you can with any Git server.
Our support is still in its early stages, and we still have several features to add to bring it up to parity with Bazaar hosting in Launchpad, as well as generally making it easier and more pleasant to use. We’ve released it before it’s completely polished because many people are clamouring to be able to use it and we’re ready to let you all do so. From here on in, we’ll be adding features, applying polish, and fixing bugs using Launchpad’s normal iterative deployment process: changes will be rolled out to production once they’re ready, so you’ll see the UI gradually improving over time.
- push Git repositories to Launchpad over SSH
- clone repositories over git://, SSH, or HTTPS
- see summary information on repositories and the branches they contain in the Launchpad web UI
- follow links from the Launchpad web UI to a full-featured code browser (cgit)
- push and clone private repositories, if you have a commercial subscription to Launchpad
- propose merges from one branch to another, including in a different repository, provided that they are against the same project or package
What will be supported later?
Launchpad’s Bazaar support has grown many features over the years, and it will take some time to bring our Git support up to full parity with it and beyond. Git repositories use a somewhat different model from Bazaar branches, which we’ve had to account for in many places, and some facilities will require complete reimplementation before we can support them with Git.
Here’s an incomplete list of some of the features we hope to add:
- useful subscriptions (currently only attribute change notifications work, which are not usually very interesting in themselves)
- RSS feeds
- an integrated code browser
See our help page for more known issues and instructions on using Launchpad with Git.
This is a new service, and we welcome your feedback: you can ask questions in #launchpad on freenode IRC, on our launchpad-users mailing list, or on Launchpad Answers, and if you find a bug then please tell us about that too.
Launchpad is free software, licensed under the GNU AGPLv3. We’d be very happy to mentor people who want to help out with parts of this service, or to build things on top of it using our published API. Some preliminary documentation on this is on our developer wiki, and you can always contact us for help.