Diff for "StableReleaseUpdates"

-  ⇤ ← Revision 205 as of 2013-01-24 20:07:29 → 
  Size: 25896
  Editor: brian-murray
  Comment:
+   ← Revision 404 as of 2025-06-25 19:59:52 → ⇥
  Size: 14476
  Editor: ahasenack
  Comment:
-Deletions are marked like this.
+Additions are marked like this.
 Line 3:
-Once an Ubuntu release has been completed and published, updates for it are only released under certain circumstances, and must follow a special procedure called a "stable release update" or SRU.

There is an automatically generated list of [[http://people.canonical.com/~ubuntu-archive/pending-sru.html|packages which are currently undergoing this process]].

/!\ '''Did you notice a regression in a package which went to -updates?''' Please report this using [[#regressions|these steps]].
+{{{#!wiki warning
SRU documentation has moved to https://canonical-sru-docs.readthedocs-hosted.com/en/latest/

See the announcement: https://lists.ubuntu.com/archives/ubuntu-devel/2024-August/043090.html
}}}
 Line 11:
-In contrast to pre-release versions, official releases of Ubuntu are subject to much wider use, and by a different demographic of users.  During development, changes to the distribution primarily affect developers, early adopters and other advanced users, all of whom have elected to use pre-release software at their own risk.

Users of the official release, in contrast, expect a high degree of stability.  They use their Ubuntu system for their day-to-day work, and problems they experience with it can be extremely disruptive.  Many of them are less experienced with Ubuntu and with Linux, and expect a reliable system which does not require their intervention.

Stable release updates are automatically recommended to a very large number of users, and so it is critically important to treat them with great caution.  Therefore, when updates are proposed, they must be accompanied by a strong rationale and present a low risk of regressions.

  ''"It's just a one-line change!"''

Even the simplest of changes can cause unexpected regressions due to lurking problems:

 * In bug Bug:81125, the upgrade regression had nothing to do with the content of the change that triggered it: any user who had installed the libpthread20 package would encounter a problem the next time libc6 was upgraded.

 * In bug Bug:309674, the failure was a misbuild due to timestamp skew in the build process. The underlying problem existed in the source package in the original release, but would only manifest in a small percentage of builds.

 * In bug Bug:559822, a C++ library (wxwidgets2.8) was uploaded with no code changes. Due to an underlying toolchain change/bug, this caused an ABI change, causing a lot of unrelated packages to break (see bug Bug:610975)

We never assume that any change, no matter how obvious, is completely free of regression risk.
+{{{#!wiki warning
This section has moved to https://canonical-sru-docs.readthedocs-hosted.com/en/latest/explanation/principles/ and https://canonical-sru-docs.readthedocs-hosted.com/en/latest/explanation/requirements/
}}}
-Line 31:
+Line 17:
-Stable release updates will, in general, only be issued in order to fix '''high-impact bugs'''.  Examples of such bugs include:

 * Bugs which may, under realistic circumstances, directly cause a '''security vulnerability'''. These are done by the security team and are documented at SecurityTeam/UpdateProcedures.
 * Bugs which represent '''severe regressions''' from the previous release of Ubuntu. This includes packages which are totally unusable, like being uninstallable or crashing on startup.
 * Bugs which may, under realistic circumstances, directly cause a '''loss of user data'''
 * Bugs which do not fit under above categories, but (1) have an obviously safe patch and (2) affect an application rather than critical infrastructure packages (like X.org or the kernel).
 * For Long Term Support releases we regularly want to enable new hardware. Such changes are appropriate provided that we can ensure not to affect upgrades on existing hardware. For example, modaliases of newly introduced drivers must not overlap with previously shipped drivers.
 * New versions of commercial software in the Canonical partner archive.
 * '''FTBFS'''(Fails To Build From Source) can also be considered. Please note that in '''main''' the release process ensures that there are no binaries which are not built from a current source. Usually those bugs should only be SRUed in conjunction with another bug fix.

For new upstream versions of packages which provide new features, but don't fix critical bugs, a [[https://help.ubuntu.com/community/UbuntuBackports|backport]] should be requested instead.
+{{{#!wiki warning
This section has moved to https://canonical-sru-docs.readthedocs-hosted.com/en/latest/reference/requirements/#what-is-acceptable-to-sru
}}}

=== High-impact bugs ===

See: https://canonical-sru-docs.readthedocs-hosted.com/en/latest/reference/requirements/#what-is-acceptable-to-sru

=== Other safe cases ===

See: https://canonical-sru-docs.readthedocs-hosted.com/en/latest/reference/requirements/#other-safe-cases

=== New upstream microreleases ===

See: https://canonical-sru-docs.readthedocs-hosted.com/en/latest/reference/requirements/#new-upstream-microreleases

=== Staging low priority uploads ===

See: https://canonical-sru-docs.readthedocs-hosted.com/en/latest/explanation/non-standard-processes/#explanation-staged-uploads

=== ESM Uploads ===

See: https://canonical-sru-docs.readthedocs-hosted.com/en/latest/reference/special/

<<Anchor(GeneralRequirements)>>
== General Requirements ==

{{{#!wiki warning
This section has moved to https://canonical-sru-docs.readthedocs-hosted.com/en/latest/reference/requirements/#general-requirements-for-all-srus
}}}

=== Development Release Fixed First ===

See: https://canonical-sru-docs.readthedocs-hosted.com/en/latest/reference/requirements/#general-requirements-for-all-srus

=== Newer Releases ===

See: https://canonical-sru-docs.readthedocs-hosted.com/en/latest/reference/requirements/#general-requirements-for-all-srus
-Line 45:
+Line 58:
-. Check that the bug is fixed in the current development release, and that its bug task is "Fix Released".  It is, in general, not appropriate to release bug fixes for stable systems without first testing them in the current development branch.

 1. Ensure that the bug report for this issue is public.  If the bug has been reported privately and cannot be published, you must first create a separate public bug report in launchpad and copy over as much information as can be published.

 1. Update the bug report '''description''' and make sure it contains the following information:
  1. An explanation of the bug on users and justification for backporting the fix to the stable release.  This may be preceded with an '''[Impact]''' header, but this is not required.  In addition, it is helpful, but not required, to include an explanation of how the upload fixes this bug.
  1. A '''[Test Case]''' section with detailed '''instructions''' how to reproduce the bug. These should allow someone who is not familiar with the affected package to reproduce the bug and verify that the updated package fixes the problem.
  1. A '''[Regression Potential]''' section with a discussion of how regressions are most likely to manifest as a result of this change.  It is assumed that any SRU candidate patch is well-tested before upload and has a low overall risk of regression, but it's important to make the effort to think about what ''could'' happen in the event of a regression.  This both shows the SRU team that the risks have been considered, and provides guidance to testers in regression-testing the SRU.

 1. [[https://answers.launchpad.net/launchpad/+question/140509|Ask a bug supervisor]] to target the bug to the appropriate Ubuntu releases (e. g. the current LTS and latest stable release), then subscribe the team [[https://launchpad.net/~ubuntu-sru|ubuntu-sru]] to your bug report.

 1. Upload the fixed package to ''release''`-proposed` with the patch in the bug report, a detailed and user-readable changelog, and no other unrelated changes. After upload, the bug status should be changed to '''In Progress''', once accepted into ''release''-proposed, the status will be automatically changed to '''Fix Committed'''. Also, make sure that:
  1. The version number does not conflict with any later and future version in other Ubuntu releases (the [[https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging|security policy document]] has a well-working scheme which can be used for SRUs.)
  1. There is a reference to the SRU bug number in the changelog, using the 'LP: #NNNNNN' convention.  Only public bugs should be referenced in the changelog.  If you can't upload to the archive yourself, [[SponsorshipProcess|get a sponsor]], attach a debdiff to the bug and subscribe `ubuntu-sponsors`, as usual.  There is no need to wait before [[https://lists.ubuntu.com/archives/ubuntu-devel/2010-July/030999.html | uploading]].

 1. The ~ubuntu-sru team will [[https://wiki.ubuntu.com/StableReleaseUpdates#Reviewing_procedure_and_tools|review and approve]] then the [[https://wiki.ubuntu.com/ArchiveAdministration#Stable_release_updates|archive admins will accept your upload]].  You can then test the actual binaries in the Ubuntu archive yourself and follow up in the bug report regarding your verification of the bug. The SRU team will evaluate the testing feedback and they will move the package into -updates after it has passed a minimum aging period of '''7 days'''.

 1. Subscribe yourself to bugmail for the package in Launchpad, if you haven't done so already, and '''monitor Launchpad''' for bug reports relating to the update for at least one week.

 Any regression must '''always''' be documented in a bug report, which must be ''Importance: critical'' once the regression has been confirmed.
+{{{#!wiki warning
This section has moved to https://canonical-sru-docs.readthedocs-hosted.com/en/latest/howto/standard/
}}}
-Line 67:
+Line 63:
-{{{
[Impact] 

 * An explanation of the of the bug on users and

 * justification for backporting the fix to the stable release.

 * In addition, it is helpful, but not required, to include an
   explanation of how the upload fixes this bug.

[Test Case]

 * detailed instructions how to reproduce the bug

 * these should allow someone who is not familiar with the affected
   package to reproduce the bug and verify that the updated package fixes
   the problem.

[Regression Potential] 

 * discussion of how regressions are most likely to manifest as a result of this change. 

 * It is assumed that any SRU candidate patch is well-tested before
   upload and has a low overall risk of regression, but it's important
   to make the effort to think about what ''could'' happen in the
   event of a regression.

 * This both shows the SRU team that the risks have been considered,
   and provides guidance to testers in regression-testing the SRU.

[Other Info]
 
 * Anything else you think is useful to include
 * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
 * and address these questions in advance
}}}
+See: https://canonical-sru-docs.readthedocs-hosted.com/en/latest/reference/bug-template/

=== Bug references in changelogs ===

See: https://canonical-sru-docs.readthedocs-hosted.com/en/latest/reference/requirements/#bug-references-in-changelogs

=== Staging an upload ===

See: https://canonical-sru-docs.readthedocs-hosted.com/en/latest/howto/special/#stage-an-upload

==== Landing an upload blocked by staging ====

See: https://canonical-sru-docs.readthedocs-hosted.com/en/latest/howto/special/#land-an-upload-blocked-by-staging

==== Responsibility for SRU verification and cancellation of incomplete verification ====

See: https://canonical-sru-docs.readthedocs-hosted.com/en/latest/explanation/non-standard-processes/#explanation-staged-uploads
-Line 107:
+Line 84:
-Once a fix has been validated, please work with the [[ https://launchpad.net/~ubuntu-sru |Stable Release Update (SRU) Team]] to ensure its published to -updates.  Vanguards from the SRU team can be found in #ubuntu-release on the following schedule:


||'''Day''' || SRU Team Member (IRC nick) ||
|| Monday || Adam Conrad (infinity) ||
|| Tuesday || Chris Halse Rogers (RAOF) ||
|| Wednesday || Clint Byrum (SpamapS) ||
|| Thursday || Brian Murray (bdmurray) ||
|| Friday ||  Steve Langasek (slangasek) ||
|| Ad hoc || Scott Kitterman (ScottK),  Kate Stewart (skaet) ||

== Fixing several bugs in one upload ==

Please avoid creating meta-bugs like "Please SRU this". They just create redundancy and are opaque to original bug reporters, whose feedback is valuable for verification, so these bugs will generally be invalidated by the SRU team. Just prepare all fixed bugs as described above, and either

 * attach the complete patch/debdiff to one bug and point to it in the other bugs ("debdiff which fixes this is attached to bug #xxxxxx")

or

 * attach individual patches to the corresponding bug reports. If you have the fixes in bzr, it is even easier and more convenient to give a pointer to the fix ("fixed in http://bazaar.launchpad.net/.../revision/12") when fixing the bug in trunk.

== New upstream microreleases ==

In some cases, when upstream fixes bugs, they do a new microrelease instead of just sending patches. If all of the changes are appropriate for an SRU by the criteria above, then it is acceptable (and usually easier) to just upload the complete new upstream microrelease instead of backporting the individual patches. Note that some noise introduced by autoreconf is okay, but making structural changes to the build system (such as introducing new library dependencies) is generally not.

If a new upstream release has more intrusive changes, you need to request an exception from the Technical Board, especially if you are going to upload the package with non-SRU changes multiple times in the future. Please see [[#Special|special cases]] below.
+{{{#!wiki warning
This section has moved to https://canonical-sru-docs.readthedocs-hosted.com/en/latest/howto/release/
}}}

== Phasing ==

{{{#!wiki warning
This section has moved to https://canonical-sru-docs.readthedocs-hosted.com/en/latest/explanation/standard-processes/#phasing
}}}

=== Investigation of Halted Phased Updates ===

See: https://canonical-sru-docs.readthedocs-hosted.com/en/latest/howto/phasing/

=== SRU team documentation ===

See: https://canonical-sru-docs.readthedocs-hosted.com/en/latest/internal/#override-phasing
-Line 136:
+Line 104:
-The [[https://launchpad.net/~sru-verification|SRU verification team]] will regularly check open bugs with the `verification-needed` tag and test proposed updates on different hardware to check for inadvertent side effects. Verification must be done in a software environment as close as is feasible to that which will exist after the package is copied to *-updates. Generally this will be with a system that is up to date from *-release, *-security, and *-updates, but not with other packages from *-proposed (except other packages built from the affected source package - they must be updated if generally installed) or *-backports. 

If they discover that your fix is insufficient, or the test case is not sufficient to reproduce the bug, they will:

 1. Set the bug task to '''Status: In Progress'''
 1. Describe why the fix was rejected in a comment to the bug report.
 1. Modify the `verification-needed` tag to a `verification-failed` tag on the bug report.

The SRU verification team may also discover that your fix is good.  They will:

 1. Modify the `verification-needed` tag to a `verification-done` tag on the bug report.
 1. Describe the general steps taken to verify the package, any special difficulties, and the recommended upload date.

While not ideal it is also possible for the uploader of the fix to perform the verification of the package in *-proposed, however it must still be done in a software environment as close as is feasible to that which will exist after the package is copied to *-updates.

Verification feedback from bug reporters and subscribers is greatly appreciated, too, especially if the update is hardware specific. In this case we consider an update as verified if it has at least two positive, no negative testimonials in the bug report, and the verification team just checks whether the new version still works for the main use cases (to check for major regressions).

If you encounter a regression in a package that has been uploaded to *-proposed, please:

 1. File a bug report against the package, describing the nature of the regression you have encountered, including any special steps needed to reproduce the regression.
 1. Mark this bug with the tag `regression-proposed`
 1. [[https://answers.launchpad.net/launchpad/+question/140509|Ask a bug supervisor]] to target the bug to the appropriate Ubuntu releases.
 1. Follow up to the SRU bug report referenced from the package changelog, pointing to the new bug.  If there is more than one bug in the SRU changelog, follow up to the bug that is most closely related to the regression.
 1. Set the `verification-failed` tag on the corresponding SRU bug report.

If you want to help us to verify Stable Release Updates then read [[https://wiki.ubuntu.com/QATeam/PerformingSRUVerification|how to perform a Stable Release Update verification]]

Verification Notes

 1. There is a standing agenda item for the SRU & LTS meeting to make sure all stakeholders are able to raise issues as early as possible.
 1. Ensure all critical and high importance bugs are verified in a timely manner. If not, the SRU QA Engineer will perform the testing.
 1. The SRU QA Engineer will specifically ask at the SRU & LTS meeting if there are specific bugs that need verification that aren't being done by the bug reporter. If necessary, a QA team member will do the verification. If not able (e.g. lack of specific HW), will do more calls for testing and nag the bug reporter again.
 1. If necessary, the QA team will set up separate SRU verification program, for big packages like eglibc, python, X.
+{{{#!wiki warning
This section has moved to https://canonical-sru-docs.readthedocs-hosted.com/en/latest/howto/standard/ and https://canonical-sru-docs.readthedocs-hosted.com/en/latest/howto/regression/#howto-report-regression
}}}

=== Autopkgtest Regressions ===

See: https://canonical-sru-docs.readthedocs-hosted.com/en/latest/howto/autopkgtest-failure/

==== Expected resolution for reported autopkgtest failures ====

See: https://canonical-sru-docs.readthedocs-hosted.com/en/latest/howto/autopkgtest-failure/
-Line 172:
+Line 118:
-If a bug fixed by an update '''does not get any testing/verification feedback''' for '''90 days''' an automated call for testing comment will be made on the bug report.  In the event that there is still no testing after an additional '''15 days''', that's a total of 105 days without any testing, the Stable Release Managers will '''remove the package from -proposed''' and usually close the bug task as "Won't Fix", due to lack of interest. Removal will happen immediately if a package update in -proposed is found to introduce a nontrivial regression.
+{{{#!wiki warning
This section has moved to https://canonical-sru-docs.readthedocs-hosted.com/en/latest/explanation/non-standard-processes/#removal-of-languishing-updates
}}}
-Line 177:
+Line 125:
-If a package update introduces a regression which already made it through the verification process to `-updates`, please '''immediately''' join `#ubuntu-devel` on Freenode, send the message "!regression-alert" on its own, and then describe the problem. Eg:{{{
16:33 < you> !regression-alert
16:33 < ubottu> ... <automated response> ...
16:33 < you> bug #... <your explanation>
}}}

Please include the package name and a relevant bug number if possible. If you cannot join IRC, please follow up on one of the relevant bugs (see changelog).

If the regression ''only'' applies to the package in `-proposed`, please follow up to the bug with a detailed explanation, and tag the bug with ``regression-proposed``.
+{{{#!wiki warning
This section has moved to https://canonical-sru-docs.readthedocs-hosted.com/en/latest/howto/regression/#howto-report-regression
}}}
-Line 188:
+Line 130:
-To minimise the risk of regressions being introduced via a SRU, testing will be perform by Canonical on each proposed kernel.

Depth Regression testing will be performed by the Ubuntu Platform QA team on minimal set of HW that represents the different flavours of Ubuntu Editions and Architectures. This activity will focus on verifying that hw-independent regressions have not been introduced.

Breadth hardware testing will be performed by the HW Certification team on release-certified HW. The test will verify that the proposed kernel can be successfully installed on the latest (point) release, network access is functional, and no other functionality is missing that will enable Update Manager to work correctly.
+(defunct section removed)
-Line 195:
+Line 134:
-== Special Cases ==

The [[https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-March/000550.html|Technical Board resolution on Landscape]] provides a general rationale for the types of special cases that may be approved here in future.

=== New micro releases ===

For some packages it is acceptable to upload new upstream microreleases to stable Ubuntu releases. See /MicroReleaseExceptions for details.
+== Documentation for Special Cases ==

{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/

See the announcement: https://lists.ubuntu.com/archives/ubuntu-devel/2025-June/043391.html
}}}
-Line 204:
+Line 143:
-Because of the way updates to the kernel work, it will follow a slightly
different process which is described on KernelTeam/KernelUpdates.

=== app-install-data-commercial ===

The app-install-data-commercial source package may be uploaded to add .desktop files for new packages in the commercial repository on archive.canonical.com. This does not require prior approval, and the aging requirement is waived; but it must still go through -proposed, a bug report must still be filed with testing instructions (its enough to add the new apps so that the tester can try to install them and verify that this works), and testing must still be recorded in the bug report.

(This section is based on discussions between MichaelVogt and ColinWatson)
+{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#kernel
}}}
-Line 215:
+Line 148:
-The landscape-client source package may be uploaded according to the procedure documented in LandscapeUpdates. See the [[https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-March/000550.html|Technical Board resolution]] for details and rationale.
+{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#landscape
}}}

=== Snapd ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#snapd
}}}

=== Snapcraft ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#snapcraft
}}}

=== Ubuntu-image ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#ubuntu-image
}}}

=== Docker.io group ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#docker-io-group
}}}

=== gce-compute-image-packages ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#gce-compute-image-packages
}}}

=== google-compute-engine ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#google-compute-engine
}}}

=== google-compute-engine-oslogin ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#google-compute-engine-oslogin
}}}


=== google-guest-agent ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#google-guest-agent
}}}

=== google-osconfig-agent ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#google-osconfig-agent
}}}

=== curtin ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#curtin
}}}


=== walinuxagent ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#walinuxagent
}}}

=== GNOME ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#gnome
}}}


=== OpenStack ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#openstack
}}}

=== Certbot ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#certbot
}}}

=== cloud-init ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#cloud-init
}}}


=== DPDK ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#dpdk
}}}

=== ubuntu-release-upgrader and python-apt ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#ubuntu-release-upgrader-and-python-apt
}}}

=== apt and python-apt ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#apt-and-python-apt
}}}

=== rax-nova-agent ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#rax-nova-agent
}}}

=== livecd-rootfs ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#livecd-rootfs
}}}

=== fwupd and fwupdate ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#fwupd-and-fwupdate
}}}

=== snapd-glib ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#snapd-glib
}}}

=== netplan.io ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#netplan-io
}}}

=== ec2-hibinit-agent ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#ec2-hibinit-agent
}}}

=== NVIDIA driver ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#nvidia-driver
}}} 

=== wslu ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#wslu
}}} 

=== openjdk-N ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#openjdk-n
}}} 

=== Postfix ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#postfix
}}} 

=== sosreport/sos ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#sosreport-sos
}}}

=== oem-*-meta ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#oem-meta
}}}

=== ubuntu-dev-tools ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#ubuntu-dev-tools
}}}

=== OpenLDAP ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#openldap
}}}

=== HAProxy ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#haproxy
}}}

=== autopkgtest ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#autopkgtest
}}}

=== squid ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#squid
}}}

=== bind9 ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#bind9
}}}

=== virtualbox ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#virtualbox
}}}

=== ubuntu-advantage-tools ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#ubuntu-advantage-tools
}}}

=== open-vm-tools ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#open-vm-tools
}}}

=== postgresql ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#postgresql
}}}

=== GRUB ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#grub
}}}

=== OpenVPN ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#openvpn
}}}

=== Language Packs (language-pack-*) ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#language-packs-language-pack
}}}

=== cd-boot-images-<arch> ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#cd-boot-images-arch
}}}

<<Anchor(Security)>>
== Data Packages Kept in Sync with Security ==
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#data-packages-kept-in-sync-with-security
}}}
-Line 219:
+Line 383:
-The tzdata package is updated to reflect changes in timezones or daylight saving policies. The verification is done with the "zdump" utility. The first timezone that gets changed in the updated package is dumped with "zdump -v $region/$timezone_that_changed" (this needed to be greped for in /usr/share/zoneinfo/). This is compared to the same output after the updated package got installed. If those are different the verification is considered done.

Because tzdata's packaging has changed subtly from release to release, rather than just backporting the most recent release's source package, we update the upstream tarball instead, following this procedure:

For the releases other than hardy, the process is simple:

{{{
cd $(old source dir)
uupdate -v 2012e ../tzdata_2012e.orig.tar.gz
cd ../tzdata-2012e
}}}

For hardy, you need to repack the sources for the old source format version that was in use:

{{{
mkdir tzdata-2012e~repack
cp tzdata_2012e.orig.tar.gz tzdata-2012e~repack/tzdata2012e.tar.gz
tar -czvf tzdata_2012e~repack.orig.tar.gz tzdata-2012e~repack/ && rm -r tzdata-2012e~repack/
cd $(old source dir)
uupdate -v 2012e~repack ../tzdata_2012e~repack.orig.tar.gz
cd ../tzdata-2012e~repack
}}}

In both cases, you then need to edit debian/changelog to add bug closures, and make sure to use a version number consistent to the previous numbering scheme (2012e~repack-0ubuntu0.8.04 or 2012e-0ubuntu0.12.04 in the above examples).

=== udev keymaps ===

udev ships a set of rules and keyboard maps which provide correct
hotkey assignments for individual laptop and USB hardware, and fixes
"stuck" keys on buggy BIOSes. Those maps can be backported to the
current LTS release(s). After one week of maturing in -proposed and no
regression bug reports it can be moved to -updates.

=== media-player-info ===

The media-player-info package ships udev rules to identify USB music
players as such, to provide tight desktop integration. It is an
architecture: all textual data-only package which has a very low
regression potential. Newer versions can be backported to the current
LTS release(s). After one week of maturing in -proposed and no
regression bug reports it can be moved to -updates.

=== mobile-broadband-provider-info ===

Whenever there are significant changes, a new version is uploaded into the
current development release and all stable releases from 8.10 on.  After one
week of maturing in -proposed and no regression bug reports it can be moved to
-updates.

=== clamav and rdepends ===

Due to the special evolving nature of anti-virus requirements and the complexity of maintaining security fixes for multiple releases, we will work to keep clamav current on all supported releases.  See ClamavUpdates for details.

=== sun-java* ===

Ubuntu 9.04 and later include an officially tested and certified JDK called OpenJDK. Prior to Ubuntu 9.04, the only officially tested and certified JDKs were `sun-java5` and `sun-java6`. These are binary-only packages shipped in multiverse.

To support users of 8.04 LTS who do not have access to the free OpenJDK, new upstream microreleases of `sun-java5` and `sun-java6` can be provided in -updates without checking individual changes for above SRU criteria for as long as Sun/Oracle provides updates. Verification just needs to prove that the packages still upgrade/install for users, and that Java applications and browser applets still run, using the packages from hardy-proposed.

Other users are recommended to upgrade to at least 9.04 and use the supported OpenJDK.

When upstream discontinues maintenance for a version of a sun-java* package (e.g. sun-java5), no more updates will be provided for that package. An announcement should be made to the ubuntu-devel-announce mailing list regarding the discontinued support of the affected package.
+{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#tzdata
}}}

=== distro-info-data ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#distro-info-data
}}}

=== linux-firmware ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#linux-firmware
}}}

=== wireless-regdb ===
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#wireless-regdb
}}}

== Toolchain Updates ==
{{{#!wiki warning
This section has moved to https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#toolchain-updates
}}}
-Line 287:
+Line 411:
+== Package Removals ==

{{{#!wiki warning
This section has moved to https://canonical-sru-docs.readthedocs-hosted.com/en/latest/explanation/non-standard-processes/#explanation-removals
}}}
-Line 289:
+Line 419:
-~+Bugs in different stages of the stable release process: http://people.canonical.com/~ubuntu-archive/pending-sru +~

This page has an "Upload queue status" section which links to all stable review
queues.
+{{{#!wiki warning
This section has moved to https://canonical-sru-docs.readthedocs-hosted.com/en/latest/reference/status/
}}}
-Line 296:
+Line 425:
-If you are a member of the [[https://launchpad.net/~ubuntu-sru|SRU reviewing team]], you should check out the [[https://code.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/|ubuntu-archive-tools]] scripts with

 {{{
 bzr branch lp:ubuntu-archive-tools
 }}}

which greatly simplify the reviewing procedure. You should symlink `queuediff` and `sru-accept.py` somewhere to your `~/bin/` directory for easy access, or put the checkout into your `$PATH`.

The following review procedure is recommended:

 * Open the unapproved queue for a particular release, e. g. https://launchpad.net/ubuntu/precise/+queue?queue_state=1 for precise. This shows the list of SRU uploads which have to be reviewed, commented on, and approved/accepted/rejected.

 * For each package, generate the debdiff to the current version in the archive and open the corresponding bugs:

 {{{
 queuediff -b -s precise ubiquity | view -
 queuediff -b -s precise-updates linux-firmware | view -
 }}}

 `-s` specifies the pocket to compare against, and `-b` opens all the bugs which are mentioned in the .changes file in the browser. This will generate a debdiff between the current archive and the unapproved upload (unless the orig.tar.gz changes this will only download the two diff.gz, so it is
 reasonably fast).

 * Review the bugs for complete description, justification, check that they have a stable task, are conformant to SRU rules, etc, and comment accordingly.

 * Scrutinize the debdiff for matching the changes in the bugs, not having unrelated changes, etc. If you have doubts, comment on the bug.

 * ''If you are an archive administrator:'' 
  * If the bugs and debdiff are okay, accept the package from the `+queue` page, and run 

  {{{
 sru-accept -s precise -p ubiquity 12345 23456
  }}}

  This will tag the bug with `verification-needed`, subscribe `ubuntu-sru`, and add a general "please test and give feedback"-like comment. If you used `queuediff`, that will already have generated a suitable `sru-accept` command, which you just need to copy and run.

  * If the upload is broken or unsuitable for an SRU, reject it from the `+queue` page, and comment on the bug.

 * ''If you are not an archive administrator:'' Send a follow up comment to the bugs:
  * If all is okay: send an "ubuntu-sru approved and reviewed" comment and set the task to "In Progress"
  * If something is wrong: send the feedback to the bug and set the task to "Incomplete"

The [[http://people.canonical.com/~ubuntu-archive/pending-sru|pending SRUs]] should also be reviewed see whether or not there are any to be released or removed from the archive.  The process for deailing with these follows:

<<Include(ArchiveAdministration, ,from="== Moving Packages to Updates ==", to="^*")>>

<<Include(ArchiveAdministration, ,from="== Failed SRUs ==", to="^=")>>
+{{{#!wiki warning
This section has moved to https://canonical-sru-docs.readthedocs-hosted.com/en/latest/internal/#reviewing-procedure-and-tools
}}}

== Contacting the SRU team ==

{{{#!wiki warning
This section has moved to https://canonical-sru-docs.readthedocs-hosted.com/en/latest/howto/contact/
}}}

Ubuntu Wiki

StableReleaseUpdates

Why

When

High-impact bugs

Other safe cases

New upstream microreleases

Staging low priority uploads

ESM Uploads

General Requirements

Development Release Fixed First

Newer Releases

Procedure

SRU Bug Template

Bug references in changelogs

Staging an upload

Landing an upload blocked by staging

Responsibility for SRU verification and cancellation of incomplete verification

Publishing

Phasing

Investigation of Halted Phased Updates

SRU team documentation

Verification

Autopkgtest Regressions

Expected resolution for reported autopkgtest failures

Removal of updates

Regressions

Testing for Regressions

Documentation for Special Cases

Kernel

Landscape

Snapd

Snapcraft

Ubuntu-image

Docker.io group

gce-compute-image-packages

google-compute-engine

google-compute-engine-oslogin

google-guest-agent

google-osconfig-agent

curtin

walinuxagent

GNOME

OpenStack

Certbot

cloud-init

DPDK

ubuntu-release-upgrader and python-apt

apt and python-apt

rax-nova-agent

livecd-rootfs

fwupd and fwupdate

snapd-glib

netplan.io

ec2-hibinit-agent

NVIDIA driver

wslu

openjdk-N

Postfix

sosreport/sos

oem-*-meta

ubuntu-dev-tools

OpenLDAP

HAProxy

autopkgtest

squid

bind9

virtualbox

ubuntu-advantage-tools

open-vm-tools

postgresql

GRUB

OpenVPN

Language Packs (language-pack-*)

cd-boot-images-<arch>

Data Packages Kept in Sync with Security

tzdata

distro-info-data

linux-firmware

wireless-regdb