General on Launchpad Blog

Introducing the new Launchpad blog

Guruprasad L — Sat, 07 Nov 2026 00:51:08 +0530

The Launchpad blog has moved from WordPress to a static site, built from the launchpad-blog project on Launchpad.

All the posts since 2007 have been carried over, and they are at the same URLs as before. Existing links to posts, categories, tags and authors keep working. If you follow the blog with a feed reader, you do not need to change anything. The feed is still at https://blog.launchpad.net/feed/, and old posts will not show up again as new ones.

The old comments were not carried over, but you can still read them through the Wayback Machine.

If you find a broken link, a missing image or a post that does not look right, please report a bug.

Bug Tracking for PPAs Is Now Available in Launchpad

İlker Emre Koç — Wed, 21 Oct 2026 13:21:32 +0000

Launchpad now supports bug tracking for Personal Package Archives (PPAs). You can report and track issues against a PPA, individual source packages within it, and specific Ubuntu releases.

This brings bug reports closer to the packages they concern, giving users a place to report problems and maintainers a clearer picture of what is affected.

Why Track Bugs Against a PPA?

PPAs let maintainers distribute packages outside Ubuntu’s official archives. Those packages might contain a newer upstream release, an experimental feature, a patch that is not available in Ubuntu’s version, or even exist solely in PPAs without being in the primary Ubuntu archive at all.

These differences matter when something goes wrong. A bug affecting a package from a PPA does not necessarily affect the package in Ubuntu’s official archive. Likewise, an issue might affect one PPA’s package without affecting another.

PPA bug tracking lets a report capture that distinction directly.

A Practical Example

Suppose a team publishes a new version of an application called Example Editor in its testing PPA. A user installs it on Ubuntu 24.04 LTS and discovers that opening a large document causes a crash. The version in Ubuntu’s official archive works correctly.

The user can report the issue against the source package in the team’s PPA and identify the affected Ubuntu release. This gives the maintainers a report tied to the package they distribute, without treating it as a confirmed problem in Ubuntu’s version.

If investigation shows that other targets are affected, the same Launchpad bug can track those too, with a separate status for each target.

Tracking Issues at the Right Level

PPA bug tracking supports different levels of detail:

PPA: for issues concerning the archive as a whole.
A source package: for issues affecting a particular package within the PPA.
An Ubuntu release: to distinguish which release is affected, including for a particular source package.

This allows reports to start with the information available and become more specific as maintainers investigate.

Getting Started

Open the PPA’s page in Launchpad and select View bugs to browse its bug reports.

The bugs page lists reports affecting the PPA or its source packages. You can search existing reports or select Report a bug to create a new one.

On a bug report, the Affects table identifies the PPA and its owning person or team. Each target has its own status, importance, and assignee, so you can track progress for the PPA separately from other affected targets.

You can also add a PPA or one of its source packages as an affected target on an existing bug report. Select Also affects PPA/package beneath the Affects table.

In the form that opens, select the affected PPA. If you know which source package is affected, enter its name; otherwise, leave that field blank. Select Continue to proceed.

To change an existing bug target, expand its row in the Affects table. Select PPA, choose the archive, and optionally specify a source package. Select Save Changes to update the target.

For PPA Maintainers

With the new PPA bugs, bug reports now have another target to better reflect where your packages are published. You can use Launchpad’s bug-tracking workflow to triage issues and track their status for the relevant PPA, source package, or Ubuntu release.

When a report also affects Ubuntu’s official package or an upstream project, use the appropriate additional bug targets to record that scope. Keeping those targets accurate helps everyone understand where investigation or a fix is still needed.

Available Now

PPA bug tracking is now enabled in Launchpad. Visit your PPA and select View bugs to explore it.

Protect your Launchpad API tokens with a security key

Jürgen Gmach — Mon, 19 Oct 2026 20:40:02 +0000

Supply-chain attacks that harvest developer credentials are on the rise. The Shai-Hulud campaign, for example, used automated scanners to sweep up any secrets they could find in files and keyrings. If you use Launchpad’s API, one of those secrets is your API token – and until now it has been about as safe as the laptop it sits on.

Launchpad now supports hardware-bound API tokens: you can tie your API access to a USB FIDO2 security key, such as a YubiKey, so that a stolen token is useless to an attacker who does not have your physical key.

The problem

Tools like lp-shell and ubuntu-archive-tools use the launchpadlib library to talk to Launchpad. After you log in, launchpadlib stores your OAuth token – either as a plaintext file on disk or in your desktop keyring. The keyring is unlocked when you log in to your session, so to anything running as you, or to malware that can read your files, that token is effectively plaintext.

For most people that is an acceptable risk. For core developers, stable release update team members, archive administrators, and Launchpad developers who run a lot of unaudited code, it is a tempting target.

The idea

Hardware-bound API tokens change what gets stored. Instead of a usable token, launchpadlib stores a long-lived OAuth refresh grant that is useless on its own. To do anything with it, launchpadlib has to ask your security key to sign a challenge from Launchpad, which mints a short-lived access token for the actual API calls.

The stored grant cannot mint a token without the key. So if an attacker copies your grant, they get nothing – the signing happens on a device they do not have.

How it works

Once you have registered a key and issued a grant, logging in looks like this:

launchpadlib loads your stored refresh grant.
It asks Launchpad for a challenge.
Your security key signs the challenge (you touch the key, and enter its PIN if it has one).
Launchpad verifies the signature against your registered key and returns a short-lived access token.
launchpadlib uses that token for API calls until it is close to expiry, then you need to touch your hardware key to renew.

The signing step is a standard WebAuthn assertion – the same mechanism browsers use for passkeys – so it builds on a well-tested security model.

Keeping it usable

Security that gets in the way does not get used, so the design keeps everyday work smooth:

A minted access token is reused until it is nearly expired, so you are not touching your key on every command.
Long-running scripts keep working; the token is renewed as needed.
The grant is stored in your keyring by default, or in a file you control if you prefer.

What it protects – and what it doesn’t

Being honest about the boundaries matters:

Opportunistic theft of stored credentials – the main thing this defends against. A scanner that grabs your grant gets something it cannot use.
Targeted attacks on your user session – if an attacker can already run code as you, they could still capture a freshly minted access token. Reducing that exposure is future work.
Root-level compromise – out of scope. If an attacker owns the machine, no client-side measure fully protects you.

This is also specifically about programmatic access through launchpadlib, not logging in to the Launchpad website, and it is not intended for automation or bot accounts.

Try it

You will need a USB FIDO2 security key and launchpadlib with the fido2 extra:

pip install 'launchpadlib[fido2]'

Then register your key, issue a grant, and log in with it. The step-by-step instructions are in the Launchpad documentation’s how-to, Use hardware-bound API tokens, with the design and protocol covered in the developer docs.

We would love your feedback as you start using it! feedback@launchpad.net

Launchpad product roadmap updates – Blueprints and Translations

Guruprasad L — Wed, 14 Oct 2026 08:54:21 +0000

We would like to share an update regarding our plans for the Blueprints and Translations features in Launchpad.

Retiring Launchpad Blueprints

Launchpad Blueprints are lightweight feature specifications attached to projects and distributions.

As the usage of Blueprints has declined steadily, we plan to retire the feature at the end of the 27.10 cycle (October 2027) and remove its data. This reduces technical debt and frees development and maintenance time for the features most of our users rely on.

Reimagining Launchpad Translations

Launchpad Translations lets communities translate software through a web interface, with translation templates and message sharing across projects, distributions and series.

The current implementation has not changed substantially in many years, and the translation ecosystem has moved on considerably since it was built. Rather than continue incremental maintenance, we are considering replacing it with a modern, purpose-built translation platform and providing an integrated Launchpad experience on top of that. Weblate is an obvious candidate, though no decision has been made as yet.

Before we choose a direction, we want to hear from the people who use Translations. We are particularly interested in which workflows matter most to you, what you rely on that a general-purpose tool might not provide, how you currently get data in and out, and what a migration would need to preserve for you to consider it successful.

We will be collecting input over the coming months. Our tentative target for completing this change is the end of the 27.10 cycle (October 2027), but that timeline may shift as we learn more.

Get in touch

If you have any questions or concerns about the Blueprints retirement, need help exporting your Blueprints data, or have feedback to share on the Translations revamp, please contact us on Matrix (#launchpad:ubuntu.com), submit a question or send an email to feedback@launchpad.net.

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:

Launchpad documentation office hour #8: Documentation clinic

Charles Odada — Wed, 02 Sep 2026 17:19:19 +0000

The Launchpad team will host its eighth public documentation office hour this Friday, September 4th, from 1330 UTC. In this session, we will be conducting a documentation clinic for projects hosted on Launchpad.

If your project is on Launchpad and you’d like some guidance on creating, improving, or publishing its documentation, drop by at any time from 1330 to 1430 UTC. We’ll see you there!

Launchpad community documentation office hour (Public)
Friday, 4th September · 1330 to 1430 UTC
Google Meet joining info
Video call link: https://meet.google.com/gcd-hnxo-sce

Charm recipe uploads now authorize with Ubuntu SSO

Harsh Singh — Fri, 28 Aug 2026 12:16:27 +0000

Launchpad builds charm recipes and uploads them to Charmhub on your behalf. Up until now, the uploads were authorized via Candid. Charmhub is retiring Candid and moving to Ubuntu One SSO, which is the same sign-on service that Launchpad already uses for snap recipes.

We have updated Launchpad to use the new flow. When you authorize a charm recipe, you will now be taken to Ubuntu SSO instead of Candid to authenticate. The rest of the process, building and uploading, remains unchanged.

What you need to do:

You do not need to make any changes right now.

Please note:

Recipes which were already authorized prior to this change will keep uploading with their existing credentials.
The new flow will apply the next time you authorize a recipe — either when creating a new charm recipe, or when re-authorizing an existing recipe.
Authorizations last up to a year, which is the maximum that Charmhub allows.

If you run into any issues while authorizing a recipe or uploading a charm, please let us know by contacting us via Matrix: #launchpad:ubuntu.com or asking a question.

Launchpad security advisory: Fix applied for unsafe tar file extraction vulnerability

Clinton Fung — Fri, 19 Jun 2026 08:00:10 +0000

We received a private report from a security researcher describing a vulnerability affecting Launchpad. The vulnerability involved the unsafe processing of tar files at build upload and custom upload. We investigated promptly and deployed a fix shortly after the report. The reporting party has confirmed the issue is no longer exploitable.

Following remediation, we completed additional review and monitoring. We found no evidence of malicious exploitation. No user action is required.

We are sharing this update as part of our ongoing commitment to transparency and security.

We thank splitline (@_splitline_) and the DEVCORE Research Team for privately reporting this issue.