Launchpad documentation office hour #8: Documentation clinic
Published by charles-odada September 2, 2026 in General
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
Introducing PPA Dependency Pinning
Published by mohamadriad-elterek September 3, 2026 in API, Cool new stuff, General
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:
- apt_preferences(5)
- Launchpad manual’s create a PPA page
- Launchpad API Archive Dependency page
- lp-shell documentation
Charm recipe uploads now authorize with Ubuntu SSO
Published by harsh-s August 28, 2026 in General
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
Published by clinton-fung June 19, 2026 in General
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.
Private snap manifests
Published by clinton-fung May 13, 2026 in General
As part of our ongoing commitment to security and transparency, we are pleased to announce an improved approach to snap manifest generation for private projects. This update specifically addresses the long-standing technical block that suppressed the creation of manifest.yaml files during private snap builds, an important component for generating accurate Software Bills of Materials (SBOMs).
The challenge of secret exposure
Previously, manifest generation for private builds was deliberately disabled as a protective measure. The primary security concern was that including a snap manifest in a binary snap could inadvertently expose sensitive source credentials or internal build configurations.
While effective at preventing data leaks, this restriction also created significant hurdles for users wanting to produce SBOMs. Given that access to these private snaps is limited to those with explicit authorization, the risk of data and secret leakage is significantly reduced, allowing us to decommission the previous suppression mechanism.
What this means for developers
For private snaps built on Launchpad, the manifest.yaml will now automatically be included in binary snaps by default during the build process.
Looking ahead
We are continuing to refine our offering, providing more and better features that support enhanced security and efficiency.
We invite you to share your feedback on this change by reaching out to us:
- Matrix: #launchpad:ubuntu.com
- Email: feedback@launchpad.net
- Ask a question: https://answers.launchpad.net/launchpad
Documentation office hours: launchpadlib tutorial
Published by charles-odada March 18, 2026 in General
The Launchpad team will be hosting its fourth public documentation office hour this Friday, March 20th, from 1330 UTC. In this office hour, we will start by discussing a launchpadlib tutorial we are working on. Whether you are an expert or novice on the topic, we welcome your input so we can help others to get started using launchpadlib.
As always, feel free to drop in at any time from 1330 to 1430 UTC with other Launchpad documentation ideas and issues.
Launchpad community documentation office hour (Public)
Friday, 20th March 1330 – 14:30 UTC
Google Meet joining info
Video call link: https://meet.google.com/gcd-hnxo-sce
Launchpad documentation office hours
Published by charles-odada March 3, 2026 in General
Did you know that Launchpad has a bi-weekly documentation office hour that’s open to everyone? Join us this Friday (6th March) for our third session from 1330 – 1430 UTC. These office hours will be a good opportunity to:
- Discuss the documentation practices of the Launchpad team and make recommendations
- Highlight your documentation issues and/or pages that don’t meet your needs
- Point out gaps in available documentation
- Share any other Launchpad-related documentation thoughts
Looking forward to see you there!
Meet joining info Video call link: https://meet.google.com/gcd-hnxo-sce
Technical Author on engineering duty: Launchpad support
Published by charles-odada February 22, 2026 in General, Teams
Being on support for Launchpad has a huge sense of responsibility. For a whole week, you are the first point of contact for users experiencing issues related to Launchpad or the services attached to it. For the person on support, even roadmap work takes a backseat.
All Launchpad engineers, except managers, take turns being on support. Managers provide Level 2 and 3 support, and in some sense, are always on support. There is no explicit expectation for a technical author (TA) to take on this responsibility, but why should engineers have all the fun?
What was the motivation to go on support?
For a TA being embedded in your team’s duties and processes is key to driving documentation efforts and positively influencing what the team does beyond documentation. As Launchpad’s first full-time TA, I had my work cut out.
When I started, my main role was driving existing objectives to completion. In later months, I had to play a key role in choosing the objectives. With so many pending issues, prioritization was the main challenge. Although I was able to figure things out, with lots of help from the Launchpad and documentation teams, I knew there were still some gaps left to cover.
I decided to learn as much as possible about the product, team, and users, to help identify which aspects of documentation were most important to address. Guruprasad and I discussed shadowing engineers on support, but Clinton suggested I try the real thing too.
Shadowing engineers on support
The expectation that I would be going on support raised the stakes, and I had to make the most of my time shadowing engineers. Interacting with users requires a higher level of care, and I was also keen to repay the faith the team had placed in me.
I shadowed İlker, Artem, and Inês in the three weeks before my turn. We used different techniques depending on our calendars and what issues they were addressing. In some cases, we would have a live meeting and I would follow along as they handled different tasks. In other cases, the approach was asynchronous, with the person on support linking me to user requests they were working on, discussions in the Launchpad channel, or documentation they had used to address specific issues.
In the support chair
On the morning of my first day on support, I couldn’t change the header of Launchpad’s public channel on Matrix. This was a simple yet frustrating problem and it took me a while to figure out this was a Matrix issue, not a skill issue. Despite the frustration, this was a good reality check. Support week is unpredictable and nothing can be underestimated.
The rest of the week brought plenty of highs, lows, and unpredictable scenarios. My main takeaways were:
- Documentation – Being on support relies heavily on the availability and quality of documentation. In addition to improving my product and team knowledge, I was able to identify where and how existing documentation succeeded and failed. Whoever is on support is always expected to identify gaps and add to the documentation, but as a TA, I was also able to identify additional issues that hamper information extraction in our docs.
- Many requests are easy to handle – The Launchpad team has done a great job of documenting the processes needed to handle many types of requests and issues.
- The role challenges you to learn and do more – Trying to address user issues required interacting with parts of Launchpad I didn’t have to before.
- It’s a great team-building experience – For Launchpad engineers, being on support is such a core part of the job that it has its own culture and language. A lot of what it means to be part of the Launchpad team became clearer during this experience.
- It’s not a one person job – It was mentioned to me many times before, but it was great to see it in practice – the person on support isn’t always expected to solve the issue. Sometimes I just needed to tag someone else in, redirect the issue to the right team, or let a user know we would look into an issue
Best moment
A user reported a bug where they couldn’t delete a comment. On inspection, the comment seemed to just be an attached text file. I started by going through the logs and confirmed that they had indeed deleted something, but it appeared to have been a different comment.
I suspected this had something to do with the attachment so I decided to recreate the issue, i.e., uploading an attachment as a comment and trying to delete it. I confirmed that trying to delete such comments did not work. Bug confirmed… right?
In Launchpad, we are a bit suspicious when things go exactly as planned the first time round. In this case, this issue appeared far too easy to encounter. I did some digging and found an older bug report where the unusual process for deleting such comments was also mentioned. So, I was able to tell the user how to solve their problem and avoided adding to our long list of bugs by marking this as a duplicate.
Final words
Supporting users is a team’s responsibility, not an individual’s. Technical authors maintain documentation used in support but may not get to test the experience of using it, and this can result in blind spots. This experience not only highlighted some of these blind spots for me, I also got to learn a lot about Launchpad, the community that uses it, and how we can improve the documentation to better serve users.
Launchpad mailing lists have been shut down
Published by Guruprasad L February 4, 2026 in General
As announced in Sunsetting Launchpad mailing lists, we have now shut down the Launchpad mailing lists hosting service.
For backup and archival, we have provided an archive of the public mailing lists at https://archive.lists.launchpad.net. All valid public lists.launchpad.net URLs that existed at the time of the shutdown now redirect to the archive, where the content will remain accessible. If you experience any issues with the archive, please report them by submitting a question or by contacting us on our Matrix channel, #launchpad:ubuntu.com.
Introducing Webhooks for Package Uploads in PPAs
Published by ines-almeida December 1, 2025 in General
We have extended our webhooks capabilities to be able to trigger webhooks on successful and unsuccessful package uploads to Personal Package Archives (PPAs).
When a new source package is uploaded to one of your PPAs, the system can now send an instant webhook notification to an endpoint you control. This will make it easier to build automations around package uploads and binary package builds in your PPAs.
The webhook configuration includes scopes so you can configure to only trigger on successful use cases, or vice versa. Each webhook payload includes essential metadata about the upload – more details in the Webhooks page of our user documentation.
To try it out, you can add a webhook to your archive via the API (API reference), or via the UI by going to “Manage Webhooks” in your archive’s page.
If you have ideas or feedback, reach out to us!
