Published by Colin Watson November 16, 2016 in Code
Launchpad has had Git-to-Bazaar code imports since 2009, along with imports from a few other systems. These form part of Launchpad’s original mission to keep track of free software, regardless of where it’s hosted. They’re also very useful for automatically building other artifacts, such as source package recipes or snap packages, from code hosted elsewhere. Unfortunately they’re quite complicated: they need to be able to do a full round-trip conversion of every revision from the other version control system, which has made it difficult to add support for Git features such as signed commits or submodules. Once one of these features is present anywhere in the history of a branch, importing it to Bazaar becomes impossible. This has been a headache for many users.
We can do better nowadays. As of last year, we have direct Git hosting support in Launchpad, and we can already build snaps and recipes straight from Git, so we can fulfil our basic goal more robustly now with a lot less code. So, Launchpad now supports Git-to-Git code imports, also known as Git mirroring. You can use this to replace many uses of Git-to-Bazaar imports (note that there’s no translations integration yet, and of course you won’t be able to branch the resulting import using
See our Git documentation for more details.
Published by Colin Watson September 20, 2016 in Beta
If you are a member of Launchpad’s beta testers team, you’ll now have a slightly different interface for selecting source packages in the Launchpad web interface, and we’d like to know if it goes wrong for you.
One of our longer-standing bugs has been #42298 (“package picker lists unpublished (invalid) packages”). When selecting a package – for example, when filing a bug against Ubuntu, or if you select “Also affects distribution/package” on a bug – and using the “Choose…” link to pop up a picker widget, the resulting package picker has historically offered all possible source package names (or sometimes all possible source and binary package names) that Launchpad knows about, without much regard for whether they make sense in context. For example, packages that were removed in Ubuntu 5.10, or packages that only exists in Debian, would be offered in search results, and to make matters worse search results were often ordered alphabetically by name rather than by relevance. There was some work on this problem back in 2011 or so, but it suffered from performance problems and was never widely enabled.
We’ve now resurrected that work from 2011, fixed the performance problems, and converted all relevant views to use it. You should now see something like this:
Exact matches on either source or binary package names always come first, and we try to order other matches in a reasonable way as well. The disclosure triangles alongside each package allow you to check for more details before you make a selection.
Please report any bugs you find with this new feature. If all goes well, we’ll enable this for all users soon.
Update: as of 2016-09-22, this feature is enabled for all Launchpad users.
Published by Colin Watson September 8, 2016 in Code
We just rolled out a new feature for Launchpad’s Git repository hosting: Git-based merge proposals can now be linked to Launchpad bugs. This can be done manually from the web UI for the merge proposal, but normally you should just mention the Launchpad bug in the commit message of one of the commits you want to merge. The required commit message text to link to bugs #XXX and #YYY looks like this:
LP: #XXX, #YYY
This is the same form used for Launchpad bug references in debian/changelog files in source packages, and the general approach of mentioning bugs in commit messages is similar to that of various other hosting sites.
Bugs are not automatically closed when merge proposals land, because the policy for when that should happen varies from project to project: for example, projects often only close bugs when they make releases, or when their code is deployed to production sites.
Users familiar with Bazaar on Launchpad should note that the model for Git bug linking is slightly different: bugs are linked to merge proposals rather than to individual branches. This difference is mainly because individual branches within a Git repository are often much more ephemeral than Bazaar branches.
Documentation is here, along with other details of Launchpad’s Git hosting.
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.