Что такое stable updates
1.6. Жизненный цикл выпуска
СЛОВАРЬ Релиз
1.6.1. Экспериментальный Статус
1.6.2. Нестабильный Статус
Рисунок 1.2. Компиляция пакета с помощью узлов автоматической сборки
БЕГЛЫЙ ВЗГЛЯД buildd , рекомпилятор пакетов Debian
1.6.3. Миграция в Testing
ЗАМЕТКА Ограничения Testing
СООБЩЕСТВО Менеджер релиза
1.6.4. Переход из тестируемого выпуска в стабильный выпуск
Рисунок 1.3. Путь пакета через различные версии Debian
СЛОВАРЬ Заморозка: финишная прямая
CULTURE GNOME and KDE Plasma, graphical desktop environments
Рисунок 1.4. Хронологический путь программы упакованной Debian
1.6.5. Oldstable и статус Oldoldstable
СООБЩЕСТВО Компании спонсирующие долгосрочную поддержку (LTS)
Что такое stable updates
1.6. Жизненный цикл выпуска
СЛОВАРЬ Релиз
1.6.1. Экспериментальный Статус
1.6.2. Нестабильный Статус
Рисунок 1.2. Компиляция пакета с помощью узлов автоматической сборки
БЕГЛЫЙ ВЗГЛЯД buildd , рекомпилятор пакетов Debian
1.6.3. Миграция в Testing
ЗАМЕТКА Ограничения Testing
СООБЩЕСТВО Менеджер релиза
1.6.4. Переход из тестируемого выпуска в стабильный выпуск
Рисунок 1.3. Путь пакета через различные версии Debian
СЛОВАРЬ Заморозка: финишная прямая
CULTURE GNOME and KDE Plasma, graphical desktop environments
Рисунок 1.4. Хронологический путь программы упакованной Debian
1.6.5. Oldstable и статус Oldoldstable
СООБЩЕСТВО Компании спонсирующие долгосрочную поддержку (LTS)
Ubuntu Wiki
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.
Did you notice a regression in a package which went to -updates? Please report this using these steps.
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.
We never assume that any change, no matter how obvious, is completely free of regression risk.
In line with this, the requirements for stable updates are not necessarily the same as those in the development release. When preparing future releases, one of our goals is to construct the most elegant and maintainable system possible, and this often involves fundamental improvements to the system’s architecture, rearranging packages to avoid bundled copies of other software so that we only have to maintain it in one place, and so on. However, once we have completed a release, the priority is normally to minimise risk caused by changes not explicitly required to fix qualifying bugs, and this tends to be well-correlated with minimising the size of those changes. As such, the same bug may need to be fixed in different ways in stable and development releases.
High-impact bugs
-
app-install-data-commercial is a package index which regularly needs to be adjusted to changes in the commercial package archive.
Other safe cases
- 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. This also includes updating hardware description data such as udev’s keymaps, media-player-info, mobile broadband vendors, or PCI vendor/product list updates. To avoid regressions on upgrade, any such hardware enablement must first also be added to any newer supported Ubuntu release.
- For Long Term Support releases we sometimes want to introduce new features. They must not change the behaviour on existing installations (e. g. entirely new packages are usually fine). If existing software needs to be modified to make use of the new feature, it must be demonstrated that these changes are unintrusive, have a minimal regression potential, and have been tested properly. To avoid regressions on upgrade, any such feature must then also be added to any newer supported Ubuntu release. Once a new feature/package has been introduced, subsequent changes to it are subject to the usual requirements of SRUs to avoid regressions.
- New versions of commercial software in the Canonical partner archive.
For new upstream versions of packages which provide new features, but don’t fix critical bugs, a backport should be requested instead.
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.
- a reliable and credible test suite for assuring the quality of every commit or release,
- the tests are covering both functionality and API/ABI stability,
- the tests run during package build to cover all architectures,
it is also acceptable to upload new microreleases with many bug fixes without individual Launchpad bugs for each of them (
ubuntu-sru will make the final decision). The upstream QA process must be documented/demonstrated and linked from the SRU tracking bug. In other cases where such upstream automatic testing is not available, exceptions must still be approved by at least one member of the Ubuntu Technical Board.
Staging low priority uploads
SRUs for bugs which do not affect users at runtime are inappropriate to force users to apply. There is a cost to our users (and our mirror network) for downloading updates of packages, which should be balanced against the utility of the update to the user downloading it.
However, if such an update otherwise complies with SRU policy, it can be staged to be bundled with a future SRU or security update.
ESM Uploads
There are special procedures for uploads to stable releases in their Extended Security Maintenance (ESM) period. Please prepare the SRU Bug then contact the ESM team.
General Requirements
Development Release Fixed First
If a stable release is fixed but the development release is not, then after the development release becomes a stable release, users upgrading would face an unexpected regression. Therefore, it is a general requirement that the development release is fixed before fixes are backported to the stable releases. Equivalently for new upstream releases, this (or a newer) release must be in the development release.
It is also, in general, not appropriate to release updates for stable systems without first testing them in the current development branch.
One exception to this general rule is the case where the development release is not yet open. There can sometimes be a delay between the release of the most recent version of Ubuntu and the opening for development of the next version. Provided they are important enough, stable release updates should not and do not need to wait for the development release to open.
Newer Releases
If a bug is being fixed in a particular stable release, we would like for all subsequent releases that are still supported to also be fixed at the same time. This is to prevent a user from facing a regression when they upgrade to a newer release.
- When there are two subsequent interim releases
- If there are two subsequent interim releases that are both current, then, as a compromise, additionally fixing only the most recent one is acceptable. Rationale: a user facing this class of regression will at least have an upgrade path available to them that fixes it.
- When you don’t want to fix a subsequent interim release at all
- We recognise that making it a hard requirement to fix all subsequent interim releases would mandate more work, and that a team may not have the resources available to fix and verify (say) an LTS as well as a subsequent interim release that has fewer users. We wouldn’t want to block a fix from landing at all, so we are not making it a hard requirement that subsequent interim releases be fixed.
- However, we strongly recommend that subsequent interim releases be fixed, and it is our expectation that normally uploaders will ensure this. If you are unable to do this, then please: 1) create and mark bug tasks against the subsequent affected releases "Won’t Fix"; and 2) explicitly state in the bug that you are deliberately seeking to fix a release without fixing the subsquent releases. An SRU team member may then accept your upload at their discretion and on a case-by-case basis. If this is not done, then uploaders should expect an SRU review round trip while your intentions are clarified.
Procedure
- Also keep in mind that certain packages can change source package names between releases. In that case, if the given bug applies to a different source package that replaced the old one in a later releases, this source package has to be added as ‘Also affecting’. Make sure that the devel releases package has the bug fixed before proceeding.
- Do not create a meta-bug with a title like "Please SRU this" rather than using existing bug reports. It is redundant and is opaque to original bug reporters, whose feedback is valuable for verification, so these bugs will be invalidated by the SRU team and corresponding uploads will be rejected from the queue.
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.
SRU Bug Template
Staging an upload
See staging low priority uploads for details of SRU policy regarding staged uploads.
To stage an upload, follow the usual process but additionally add a block-proposed-<series> tag to at least one of the SRU bugs together with a comment explaining the reason for the staging.
Staging can also be added retrospectively simply by adding the tag; this can be done at any time before an SRU is released. If you do so, please make sure that you add a bug comment that explains the reason.
Landing an upload blocked by staging
In principle the block-proposed-<series> tag should be removed by an SRU team member when accepting a newer upload not planned for further staging. But if they overlook this, it’s appropriate for whoever notices it (SRU team, or uploader) to remove the block-proposed-<series> tag with a suitable comment when it no longer applies.
Responsibility for SRU verification and cancellation of incomplete verification
It is essential to carry out SRU verification on all related bugs as usual as soon as the upload enters the proposed pocket. We do not want to burden a future SRUer with verification of your low priority bug. If timely verification is not performed, then as usual the staged upload is a candidate for deletion, and a future SRUer is quite entitled to base their upload on the version prior to your staged upload instead. If this happens, the future SRU will not include your changes, effectively cancelling the staging.
Since we try to avoid regressing users on upgrade to a new release, it is essential to carry out this SRU verification for every affected bug series task. If you skip verification of one series then staged uploads in all series are candidates for deletion or overriding as above at the discretion of the SRU team.
Publishing
The Stable Release Updates team regularly checks for SRUs that have succesfully completed verification (all bugs are marked verification-done-$RELEASE for the given release) and releases those to the -updates pocket. Having said that, if there is a priority SRU waiting in the unapproved queue for release to -proposed, or needing release to -updates from -proposed, feel free to contact an SRU vanguard.
Please note that SRUs will not be published to the -updates pocket on Friday (or Saturday or Sunday). Any exception will need justification.
Phasing
Once an package is released to -updates, the update is then phased so that the update is gradually made available to expanding subsets of Ubuntu users. This process allows us to automatically monitor for regressions and halt the update process if any are found. Complete details about the process can be found in a blog post by Brian Murray.
The Phased-Update-Percentage is initially set to 10%, then a job is run (every 6 hours) that checks for regressions and if none are found the phased update percentage will be incremented by 10%. So an update will become fully phased after 54 hours or about 2 days. In the event that a regression is detected the Phased-Update-Precentage will be set to 0% thereby causing supported package managers (update-manager) not to install the update.
The progress of phased updates is visible in a report which is updated by the same job that does the phasing.
Investigation of Halted Phased Updates
Here are some tips on how to utilize the phased updates report to investigate why the phasing has stopped.
When looking at an increased rate of crashes you’ll want to look at the crash(es) with the greatest number of occurrences. Then check to see if the crash is occurring more frequently (by examining the Occurrences table) with the updated version of the package. If it is then’ll you want to sort out why and address the crash in a follow on SRU. If it isn’t then contact the SRU team regarding overriding the crash.
When looking at a new error you’ll want to confirm that the error is in fact a new one by using the versions table. The phased-updater currently checks if the error has been reported about the version immediately before the current version, so if the previous version wasn’t around very long its possiblpossible a specific error wasn’t reported about it. Additionally, you can check to see if the error is really about the identified package or if it it occurs in an underlying library by looking at the Traceback or Stacktrace e.g.possible a specific error wasn’t reported about it. Additionally, you can check to see if the error is really about the identified package or if it it occurs in an underlying library by looking at the Traceback or Stacktrace e.g.e a specific error wasn’t reported about it. Additionally, you can check to see if the error is really about the identified package or if it it occurs in an underlying library by looking at the Traceback or Stacktrace e.g. python crashes being reported about a package using python. If you do not believe the error is a new one or was not caused by your stable release update then contact the SRU team regarding overriding the crash.
SRU team documentation
Overriding halted phasing is done in a similar way to overriding autopkgtest failures. The phased update machinery looks at phased-update-overrides.txt, which is a simple CSV file containing lines of the form source package, version, $THING_TO_IGNORE where $THING_TO_IGNORE can either be an errors.ubuntu.com problem URL to ignore or increased-rate.
Verification
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. 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).
-
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.
If you want to help us to verify Stable Release Updates then read how to perform a Stable Release Update verification
Autopkgtest Regressions
Packages accepted into -proposed as per the SRU process automatically trigger related autopkgtests, similarly to how it happens for the development series. Once those tests are finished, the pending SRU page provides links to any failures that have been noticed for the selected upload. The responsibility of the uploader (and/or the person performing update verification) is to make sure the upload does not cause any regressions — both in manual and automated testing.
It is important to remember that firstly it is the uploader’s responsibility to make sure the package is in a releasable state and that all the autopkgtests triggered by the upload are either passing or badtested. Of course, it is not the uploader’s responsibility to provide the hints for badtests themselves, but it is it’s responsibility to perform the analysis and verification of each listed regression.
Expected resolution for reported autopkgtest failures
Removal of updates
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.
Regressions
If a package update introduces a regression which already made it through the verification process to -updates, please immediately file a bug report about the issue, and add the tag regression-update to the bug.
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 .
Testing for Regressions
To minimise the risk of regressions being introduced via a SRU, testing will be performed 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.
Documentation for Special Cases
The Technical Board resolution on Landscape provides a general rationale for the types of special cases that may be approved here in future. Most exception approvals are now handled directly by the SRU team.
-
Draft a wiki page, like the ones below, outlining what you believe should be the exception.
Note that the SRU team’s delegation from the Technical Board is limited to accepting SRU uploads that meet the policy criteria above. The SRU team maintains documentation for standing exceptions here to keep individual interpretations of the policy criteria consistent. Departing from the policy criteria above still requires approval from the Technical Board.
Kernel
Because of the way updates to the kernel work, it will follow a slightly different process which is described on KernelTeam/KernelUpdates.
Landscape
The landscape-client source package may be uploaded according to the procedure documented in LandscapeUpdates. See the Technical Board resolution for details and rationale.
The juju-core source package may be uploaded according to the procedure documented in JujuUpdates. See the Technical Board discussion for historical context and rationale.
Snapd
The snapd source package may be uploaded according to the procedure documented in SnapdUpdates. Per Technical Board discussion regarding delegation of these decisions to the SRU team, this stable release exception has been approved by SteveLangasek for the SRU team as of 2016-05-12.
Snapcraft
Related to the preceding snapd exception, the snapcraft source package may be uploaded according to the procedure documented in SnapcraftUpdates. This stable release exception has been approved by SteveLangasek for the SRU team as of 2016-05-16.
Ubuntu-image
Also related to snapd, the ubuntu-image package may be uploaded according to the procedure documented in UbuntuImageUpdates. This stable release exception has been approved by SteveLangasek for the SRU team as of 2016-10-19.
Docker.io group
The source packages docker.io, containerd, and runc may be uploaded according to the procedure documented in DockerUpdates. Per Technical Board discussion regarding delegation of these decisions to the SRU team, this stable release exception has been approved by BrianMurray for the SRU team as of 2016-09-20.
gce-compute-image-packages
The source package gce-compute-image-packages may be uploaded according to the procedure documented in gce-compute-image-packages-Updates. Per Technical Board discussion regarding delegation of these decisions to the SRU team, this stable release exception has been approved by BrianMurray for the SRU team as of 2017-03-10. Further amendment to this exception for vendored dependencies approved by LukaszZemczak for the SRU team as of 2023-04-11.
google-compute-engine
The source package gce-compute-image-packages may be uploaded according to the procedure documented in google-compute-engine-Updates. Per Technical Board discussion regarding delegation of these decisions to the SRU team, this stable release exception has been approved by SteveLangasek for the SRU team as of 2022-09-01. Further amendment to this exception for vendored dependencies approved by LukaszZemczak for the SRU team as of 2023-04-11.
google-compute-engine-oslogin
The source package google-compute-engine-oslogin may be uploaded according to the procedure documented in google-compute-engine-oslogin-Updates. Per Technical Board discussion regarding delegation of these decisions to the SRU team, this stable release exception has been approved by SteveLangasek for the SRU team as of 2022-09-01. Further amendment to this exception for vendored dependencies approved by LukaszZemczak for the SRU team as of 2023-04-11.
google-guest-agent
The source package gce-compute-image-packages may be uploaded according to the procedure documented in google-guest-agent-Updates. Per Technical Board discussion regarding delegation of these decisions to the SRU team, this stable release exception has been approved by SteveLangasek for the SRU team as of 2022-09-01. Further amendment to this exception for vendored dependencies approved by LukaszZemczak for the SRU team as of 2023-04-11.
google-osconfig-agent
The source package google-osconfig-agent may be uploaded according to the procedure documented in google-osconfig-agent-Updates. Per Technical Board discussion regarding delegation of these decisions to the SRU team, this stable release exception has been approved by SteveLangasek for the SRU team as of 2022-09-01. Further amendment to this exception for vendored dependencies approved by LukaszZemczak for the SRU team as of 2023-04-11.
curtin
The source package curtin may be uploaded according to the procedure documented in CurtinUpdates. This stable release exception has been approved by SteveLangasek for the SRU team as of 2017-04-05.
walinuxagent
The source package walinuxagent may be uploaded according to the procedure documented in walinuxagentUpdates. This stable release exception has been approved by SteveLangasek for the SRU team as of 2017-04-05.
GNOME
GNOME has a microrelease exception excepting it from the normal QA requirements of the microrelease policy, documented here. This was granted by the technical board on 2012-06-22.
OpenStack
OpenStack packages can be updated according to the procedures documented in OpenStack/StableReleaseUpdates, which includes a list of source packages covered by the MRE. This stable release exception has been approved by LukaszZemczak for the SRU team as of 2017-08-07.
Certbot
The Certbot family of packages can be updated according to the procedures documented in /Certbot. This stable release exception was discussed and subsequently revision 10 of that document was approved by RobieBasak for the SRU team on 2017-08-08.
cloud-init
The source package cloud-init may be uploaded according to the procedure documented in CloudinitUpdates. Per Technical Board discussion regarding delegation of these decisions to the SRU team, this stable release exception has been approved by BrianMurray for the SRU team as of 2017-10-06 with subsequent updates approved by RobieBasak on 2020-07-15.
The dpdk source package can be uploaded according to the procedures documented in DPDK for supported LTS releases of Ubuntu. This stable release exception has been approved by LukaszZemczak for the SRU team as of 2017-08-07.
ubuntu-release-upgrader and python-apt
The packages ubuntu-release-upgrader and python-apt both contain files with listings of Ubuntu mirrors. To facilitate upgrades to new releases ubuntu-release-upgrader should be updated (particularly for LTS releases) so that the list of mirrors is accurate. With that in mind and given that it is just a text file with urls for mirrors it is okay to SRU only mirror changes for these packages without an SRU bug.
rax-nova-agent
The source package rax-nova-agent may be uploaded according to the procedure documented in rax-nova-agent-Updates. This stable release exception has been approved by SteveLangasek for the SRU team as of 2018-08-15.
livecd-rootfs
The livecd-rootfs package is a frequent target of SRUs as part of development of changes to image builds for the target series, and is not intended for general installation on end-user systems. The risk of user-affecting regression is lower as a result, because the impact of changes to this package to end users is mediated by way of image builds. Therefore, the requirement for per-change bug reports and test cases is relaxed, as long as there is at least one linked bug with a test case.
fwupd and fwupdate
The source packages fwupd and fwupdate may be uploaded according to the procedure documented in firmware-updates. This stable release exception has been approved by BrianMurray for the SRU team as of 2019-01-15.
snapd-glib
The source package snapd-glib may be uploaded according to the procedure documented in snapd-glib updates. This stable release exception has been approved by BrianMurray for the SRU team as of 2019-02-19.
netplan.io
The source package netplan.io may be uploaded according to the procedure documented in netplan updates. This stable release exception has been approved by BrianMurray for the SRU team as of 2019-04-01 (no really!).
ec2-hibinit-agent
The source package ec2-hibinit-agent may be uploaded according to the procedure documented in ec2-hibinit-agent updates. This stable release exception has been approved by SteveLangasek for the SRU team as of 2019-09-06.
NVIDIA driver
NVIDIA driver (source packages nvidia-graphics-drivers-*, nvidia-settings, fabric-manager-*, libnvidia-nscq-*) may be uploaded according to the procedure documented in NVIDIA updates. This stable release exception has been approved by ChrisHalseRogers for the SRU team as of 2019-09-17.
The wslu package may be uploaded according to the procedure documented in wslu Updates. This stable release exception has been approved by LukaszZemczak for the SRU team as of 2019-10-24.
openjdk-N
We allow providing OpenJDK short term support releases in the updates pocket, instead of the release pocket to be able to remove those after their support ends as documented in OpenJDK Updates. This very specific stable release exception has been approved by LukaszZemczak for the SRU team as of 2020-04-30.
Postfix
The postfix source package may be uploaded according to the procedure documented in PostfixUpdates. See the Technical Board meeting minutes and its approval for details and rationale.
sosreport
The source package sosreport may be uploaded according to the procedure documented in sosreport updates. This stable release exception has been approved by LukaszZemczak for the SRU team as of 2020-06-25.
oem-*-meta
Source packages of the form oem-*-meta may be uploaded according to the procedure documented in OEMMeta. This stable release exception has been approved by AndyWhitcroft for the SRU team as of 2021-07-15. New packages are acceptable under the same exception.
ubuntu-dev-tools
The source package ubuntu-dev-tools may be uploaded according to the procedure documented in UbuntuDevToolsUpdates. This stable release exception has been approved by Robie Basak.
OpenLDAP
The OpenLDAP source package may be uploaded according to the procedure documented in OpenLDAPUpdates. This stable release exception has been approved by SteveLangasek for the SRU team as of 2022-06-02.
HAProxy
The haproxy source package may be uploaded according to the procedure documented in HAProxyUpdates. This stable release exception has been approved by LukaszZemczak for the SRU team as of 2022-06-27.
autopkgtest
The autopkgtest source package may be uploaded according to the procedure documented in autopkgtest-Updates. This stable release exception has been approved by SteveLangasek for the SRU team as of 2023-01-30.
squid
The squid source package may be uploaded according to the procedure documented in SquidUpdates. This stable release exception has been approved by SteveLangasek for the SRU team on 2023-04-03.
bind9
The bind9 source package may be uploaded according to the procedure documented in Bind9Updates. This stable release exception has been approved by SteveLangasek for the SRU team as of 2023-06-06.
virtualbox
The virtualbox source packages may be uploaded according to the procedure documented in VirtualboxUpdates. This stable release exception has been approved by Martin Pitt for the SRU team as of 2015-11-04.
Data Packages Kept in Sync with Security
Some data packages must always be kept in sync between -updates and -security to avoid behaviour or functionality regressions when using only the security pocket. Because they are pure data, and contain no compiled code, these packages are safe to build in -proposed and then copy to both -updates and -security.
tzdata
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" (you can find the region and timezone name by grep’ing for it in /usr/share/zoneinfo/). This is compared to the same output after the updated package was installed. If those are different the verification is considered done.
The version of tzdata in Ubuntu 20.04 LTS and later includes icu-data (see the update-icu rule in debian/rules) and the verification of it can be done after installing the python3-icu package. There can be a slight lag between the tzdata release and the matching icu-data release, we usually wait for the latter to be released before uploading the update.
In the above we are checking a timezone with a change, "Pacific/Fiji", and a date that falls with in the changing period. We expect the output to be different before (13:00:00) and after (12:00:00) the SRU is installed.
The version of tzdata in Ubuntu 20.10 removed supported for SystemV timezones, however SRUs of tzdata to Ubuntu 20.04 LTS and earlier releases should still include the SystemV timezones. To test that they are still available confirm the following command returns nothing.
Because tzdata’s packaging has changed subtly from release to release, rather than just backporting the most recent release’s source package, we just update the upstream tarball instead. 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 (e. g. 2012e-0ubuntu0.12.04). Uploads should also be made to any releases supported via ESM.
Due to the potentially disastrous consequences of having localtime differ between systems running -updates and systems running only -security, this package is always kept in sync between the two pockets. However, the package can be built with -updates and then copied from -proposed to -updates and -security after the security team has signed off on the SRU bug e.g. 1878108.
distro-info-data
Many tools behave drastically differently based on the contents of ubuntu.csv in distro-info-data. As such, information for new releases is always backported to -updates, and should always be copied to -security to avoid behaviour skew between the two pockets.
This package should be updated as soon as possible after the new release’s name is known. If only the adjective is known, it should be updated even with this partial information (use XANIMAL for the animal where X is the first letter of the adjective). The aging requirement is not applied for releasing to -updates / -security. A tracking bug is still required for SRUs. Verification is still required. The testing section should contain:
linux-firmware
linux-firmware in stable releases is kept in sync with new driver features and lts-hwe kernel updates. linux-firmware follows the normal SRU process (with bugs filed and regression tests performed), however it must also be copied to the -security pocket once verified, due to the vast majority of kernel SRUs also being in the -security pocket, and the necessity of linux and linux-firmware not being mismatched.
wireless-regdb
Much like linux-firmware, wireless-regdb follows the usual SRU process, including a bug and regression testing, however it is another package that needs to be kept in sync between -updates and -security pockets to avoid potential local legal issues for -security users who would otherwise not get the local regdb updates.
Examples
As a reference, see bug #173082 for an idea of how the SRU process works for a main package, or bug #208666 for an SRU in universe.
Package Removals
While it is always preferable to fix a package, rather than drop it, there are rare cases when a universe package becomes actively detrimental in stable releases: If it is unmaintained in Ubuntu and has unfixed security issues or has been broken because of changing network protocols/APIs, it is better to stop offering it in Ubuntu altogether rather than continuing to encourage users to install it.
It is not technically possible to remove a package from a stable release, but this can be approximated by SRUing an essentially empty package with an appropriate explanation in NEWS and a corresponding critical debconf note.
When a package is removed in this way from a stable release, it may need similar removal from the devel release as well, depending on the justification for removal.
Such a package removal should have an SRU tracking bug with an appropriate explanation, and needs to get confirmed by the Technical Board. Once removed, the SRU bug should be added to the "Previous Removals" list below.
Toolchain Updates
Due to the nature of the various Ubuntu toolchain packages (gcc-*, binutils, glibc), any stable release updates of these packages should be released to both the -updates and -security pockets. For that to be possible, any updates of those should be first built in a reliable security-enabled PPA (without -updates or -proposed enabled) and only then binary-copied into -proposed for testing (that is a hard-requirement for anything copied into -security). After the usual successful SRU verification and aging, the updated packages should be released into both pockets.
Links
Bugs in different stages of the stable release process: http://people.canonical.com/
- This page has an "Upload queue status" section which links to all stable review queues.
Phasing of Stable Release Updates: http://people.canonical.com/
- This page displays the Phased-Update-Percentage of packages in the -proposed repository for releases and any regressions detected in that package.
Reviewing procedure and tools
If you are a member of the SRU reviewing team, you should check out the ubuntu-archive-tools scripts with
which greatly simplify the reviewing procedure. You should symlink sru-review and sru-accept somewhere to your
/bin/ directory for easy access, or put the checkout into your $PATH.
-
Exit the tool you are using to review the debdiff
If the bugs and debdiff are okay, accept the package by pressing y at the ""Accept the package into -proposed?" prompt.
- 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 pending SRUs should also be reviewed to see whether or not there are any to be released or removed from the archive. The process for dealing with these follows:
Packages in -proposed can be moved to -updates once they are approved by someone from sru-verification, and have passed the minimum aging period of 7 days. Use the sru-release script from ubuntu-archive-tools for this:
If a package should be removed from -proposed, use the remove-package tool (from ubuntu-archive-tools). e.g., to remove source and binaries for the libreoffice package currently in xenial-proposed:
Contacting the SRU team
If you do not have upload access to the archive, you should ask your sponsor for help in the first instance. If you don’t have a sponsor, you can try asking generally on #ubuntu-devel on Libera.Chat, or the ubuntu-devel-discuss mailing list. See SponsorshipProcess for details.
If you do have upload access, you can contact the SRU team by asking generally in #ubuntu-release on Libera.Chat, or on the ubuntu-release mailing list.
Vanguards from the SRU team can also usually be found in #ubuntu-release on the following schedule:
stable-updates
Some packages from proposed-updates may also be made available via the stable-updates mechanism. This path will be used for updates which many users may wish to install on their systems before the next point release is made, such as updates to virus scanners and timezone data. All packages from stable-updates will be included in point releases.
For Debian 12.2 Bookworm, in order to use packages from bookworm-updates (aka stable-updates), you can add an entry to your sources.list. For example:
For Debian 11.8 Bullseye, in order to use packages from bullseye-updates (aka oldstable-updates), you can add an entry to your sources.list. For example:
For older Debian release *-updates no longer exists as those suites no longer receive updates.
The next time you run apt update, the system will become aware of the packages in the (old)stable-updates section and will consider them when looking for packages to upgrade.
Note that if APT::Default-Release is set in your apt configuration, then, in order for automatic upgrades to work, some apt pinning needs to be added (see apt_preferences(5) for more information):
When a new package is made available via (old)stable-updates, this will be announced on the debian-stable-announce mailing list.
stable-updates were introduced in DebianSqueeze, to replace DebianLenny’s Volatile (see announcement).