Beta test: new package picker
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.
Linking Git merge proposals to bugs
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.
Beta test: Git recipes
Published by Colin Watson January 25, 2016 in Beta, Code, Cool new stuff
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.
Launchpad news, October 2015
Published by Colin Watson November 9, 2015 in General
Here’s what the Launchpad team did in October.
Beta test: webhooks
Published by Colin Watson in Beta, Code, Cool new stuff, General
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.
PPAs for ppc64el
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.
Launchpad news, September 2015
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.
Launchpad news, August 2015
Published by Colin Watson September 2, 2015 in General
Here’s a summary of what the Launchpad team got up to in August.
Launchpad news, July 2015
Published by Colin Watson August 2, 2015 in General
Here’s a summary of what the Launchpad team got up to in July.
Improved filtering options for Gmail users
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.
