Cool new stuff on Launchpad Blog

Review merge proposals in VS Code

Adam Steciuk — Tue, 08 Sep 2026 10:32:27 +0000

Launchpad Merge Proposals, a VS Code extension for reviewing Launchpad merge proposals, is now available on the Visual Studio Marketplace as a preview release.

The extension brings the review into the editor. It finds the merge proposals for the branch you have checked out, renders their diffs in VS Code’s diff editor, and lets you comment and vote without opening a browser.

What the extension does

Finds the merge proposals for the branch you are on

It reads the upstream of the checked-out branch and lists merge proposals in both directions: outgoing, where your branch is the source, and incoming, where it is the target. Proposals can be filtered by status.

Renders diffs in the VS Code editor

Open Files Changed and the proposal opens in VS Code’s side-by-side diff editor, with syntax highlighting and the surrounding file for context. Files are decorated to show where comments already exist.

Puts comments next to the code

Published inline comments appear beside the lines they refer to, and new ones are drafted in the same place, with full markdown support. Drafts are stored on Launchpad, so a review started in the editor can be finished in the browser, or the other way around.

Submits the whole review at once

Pick a vote, write the summary comment, and submit. Every inline draft is published alongside it.

Getting started

Install Launchpad Merge Proposals in VS Code 1.105 or newer.
Open a project backed by a Git repository on Launchpad, and check out a branch tracking a remote one.
Open the Launchpad Merge Proposals view from the Activity Bar and sign in when prompted.
Select a merge proposal, then pick a preview diff to see the changes and comments.

Sign-in uses Launchpad’s OAuth flow, and the token is stored in VS Code’s secret storage. Launchpad asks what level of access to grant, and the level you pick determines what the extension can do. Reading diffs and published inline comments needs at least read access. Drafting inline comments and submitting reviews needs change access.

Current status of the project

This is a preview release. The core review flow works and we use it daily, but some capabilities are still experimental while we work out how they should behave. The README covers the current state, including a known issues section that we update with each release.

Feedback

We want to hear what works, what breaks, and what is missing. Please report bugs and file feature requests on the project’s Launchpad page.

The extension is free software under GPL-3.0, and its source is hosted on Launchpad. We welcome contributions via merge proposals. You can even review them using the extension itself!

Merge Launchpad merge proposals with one click

Goulin Khoge — Fri, 04 Sep 2026 09:52:42 +0000

Maintainers can now merge changes (merge proposals) directly from the Launchpad UI.

The new Request merge button is available to anyone with permission to push to the target branch. Launchpad enables it if the merge proposal has:

An active status and an up-to-date diff
No conflicts with the target branch
Approval from the target repository owner, a member of its owner team, or designated review team
Successfully completed any configured CI checks
No unmerged prerequisite branches

When you click on Request merge, Launchpad queues the merge, tracks its progress, and lets you know when the change has been merged.

The feature is available for all Launchpad-hosted Git repositories, with no additional setup or integration required.

Happy merging!

Introducing PPA Dependency Pinning

Riad El Terek — Thu, 03 Sep 2026 07:07:37 +0000

PPA maintainers now have more control over where their build dependencies come from. With PPA dependency pinning, you can assign priorities to the PPAs your builds depend on, helping ensure that your packages build against the software you intend to use.

Whether you are testing a patch, maintaining a customised library, or preparing a new release, this feature makes it easier to manage builds that rely on packages outside the standard Ubuntu archive.

NOTE: This setting applies only to package builds performed by Launchpad and can only be set by the PPA maintainer. It does NOT change package selection on users’ computers, nor affect local builds.

Why dependency priorities matter

Personal Package Archives (PPAs) let developers build and distribute packages through Launchpad. When packages in one PPA require packages from another PPA in order to be built, the maintainer can configure the other PPA as a build dependency.

However, making a package available does not necessarily mean it will be selected. When multiple repositories provide the same package at the same priority, Ubuntu’s package manager generally prefers the newer version. APT’s documentation explains these selection rules.

Imagine that your application needs a library containing a patch you maintain in a separate PPA. Your builds will only use that library successfully until an Ubuntu update introduces a package with a higher version number. Subsequent builds will select the Ubuntu version instead, even though it does not contain your patch.

PPA dependency pinning gives you a way to express which source your builds should always prefer by allowing you to assign a priority to each PPA dependency. Launchpad applies those priorities when preparing the build environment.

For the patched-library example, an appropriate priority lets you keep using the library from your chosen PPA, even when Ubuntu publishes a newer version. This reduces the need to adjust package version numbers to influence which source is selected.

Who is this for?

The feature is useful for teams that:

Test fixes or features that are not yet available in Ubuntu.
Maintain customised dependencies for their applications.
Build related projects across several PPAs.

Configure priorities in Launchpad

When Launchpad prepares a build, APT resolves versioning conflicts by selecting the package repository with the highest priority. Some values already have conventional meanings: 500 is the default for available packages, and 990 is generally used for packages from the configured target release. Values above 1000 are especially strong and may cause APT to select a package even when it is an older version. See APT’s documentation for more information.

To get started, open your PPA’s Edit PPA dependencies page and adjust the Priority field beside the relevant dependency. Save your changes to apply the setting to subsequent builds.

For teams that manage their PPA configuration through scripts or automation, priorities can also be configured through the Launchpad API. This can be done through lp-shell as follows:

# Run: lp-shell production devel

In [1]: target_ppa = lp.people["your-launchpad-id"].getPPAByName(
    name="your-ppa-name"
)
In [2]: dependency_ppa = lp.people["dependency-owner"].getPPAByName(
    name="dependency-ppa-name"
)

In [3]: target_ppa.addArchiveDependency(
    dependency=dependency_ppa,
    pocket="Release",
    component="main",
    pin_priority=1001,
)

Existing dependencies retain the default priority of 500, so there is no configuration change required if the current behaviour meets your needs.

Priorities apply to packages supplied by the dependency PPA, so choose them with the contents of that PPA in mind. They express a source preference; they do not freeze a particular package version or guarantee identical builds over time.

Additionally, PPA dependency pinning only affects the build environment on Launchpad. It does not change package preferences on the computers of people who install software from your PPA.

References

For more information, see:

Make fetch service opt-in

Vaishnavi Asawale — Tue, 28 Oct 2025 11:31:12 +0000

Launchpad Builders do not have direct access to the Internet. To reach external resources, they must acquire an authentication token that allows access to a restricted set of URLs via a proxy. This can either be a custom authenticated builder proxy or the fetch service.

The fetch service is a custom sophisticated context-aware forward proxy. Whereas the builder proxy allows requests to allowlisted URLs, the fetch service also keeps track of requests and dependencies for a build.

Users can now opt-in to use the fetch service while building snaps, charms, rocks and sourcecraft packages. You can read more about the fetch service here.

Why is the fetch service important?

To achieve traceability and reproducibility, artifact dependencies retrieved during a build must be identified. The fetch service mediates network access between the build host and the outside world, examining the request protocol, creating a manifest of the downloaded artifacts, and keeping a copy of the artifacts for archival and metadata extraction for each package build.

How to use the fetch service?

To be able to use the fetch service, users must opt-in. For snaps, charms, rocks and sourcecraft packages, the use_fetch_service flag should be set to true in the API. For snaps and charms, this setting is also available in the Edit Recipe UI page.

The fetch service can be run in two modes, “strict” and “permissive”, where it defaults to the former. Both modes only allow certain resources and formats, as defined by inspectors which are responsible for inspecting the requests and the various downloads that are made during the build, ensuring that the requests are permitted.

The “strict” mode errors out if any restrictions are violated. The “permissive” mode works similarly, but only logs a warning when encountering any violations. The mode can be configured using the fetch_service_policy option via the API. For snaps and charms, the mode can also be selected from a dropdown on the Edit Recipe UI page.

When to use the fetch service?

Use the fetch service when you need to keep track of requests and dependencies for a build, e.g., when you need to verify that the artifacts belong to secure, trusted sources.

Beta test: Git recipes

Colin Watson — Mon, 25 Jan 2016 11:33:41 +0000

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.

Beta test: webhooks

Colin Watson — Mon, 09 Nov 2015 15:41:34 +0000

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.

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!

Git code hosting beta

William Grant — Fri, 01 May 2015 20:50:11 +0000

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.

What’s supported?

You can:

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
mirroring
webhooks
an integrated code browser

See our help page for more known issues and instructions on using Launchpad with Git.

Helping out

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.

Launchpad JavaScript now combo loaded and faster than ever.

Richard Harding — Tue, 25 Sep 2012 15:38:51 +0000

Updated network graph

Back in January a side project was started to update the JavaScript used in Launchpad. Launchpad has been using YUI 3.3.0 for a long time, very successfully, however recent advances in YUI 3.5 and higher have added some great tools for development that Launchpad can take advantage of. In order to facilitate easier upgrades our YUI library version Launchpad has been moved to using a combo loader for serving out JavaScript.

This means, that instead of a single launchpad.js file that can be upwards of 3MB in size, each request builds a list of JavaScript modules needed for the current page to work, and the combo loader only sends down those modules. This drastically cuts down on the download size of the JavaScript for users. These combo loaded JavaScript files are also cached for speedy serving to other users of Launchpad.

The combo loader also allows us to specify which YUI version to load via a tweak to the url. In this way we can easily test new version of YUI side by side with the current stable version as they come out. This allows Launchpad to keep with future YUI released much faster.

We’re excited that today Launchpad has moved from YUI 3.3.0 to 3.5.1 and is now served by the combo loader. This change provides a faster experience for users along with easier maintenance and new JavaScript library features for developers.

We’ve still got more to do though. YUI just released version 3.7 and we aim to push that into production faster than ever before. Please let us know how these changes work for you.

Launchpad also wants to thank the folks over at YUI for continuing the great work on a tool that Launchpad heavily depends on.

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)