PerformingSRUVerification

Revision 29 as of 2008-08-06 16:18:10

Clear message

Contents

SRU Verification is the process of testing packages from the -proposed repository, that have been updated to fix bugs. These packages need testing to ensure that the package continues to function as designed and that the bug is fixed. It is also important to ensure no regression has been introduced by the fix. More information about the process can be found at Stable Release Update page. To find out how to enable -proposed look at the Enable Proposed page.

How to find bugs needing verification

There are many ways to find bugs needing SRU verification: by viewing the SRU To Do or Pending Ubuntu SRUs or by querying Launchpad for the bug tag verification-needed or by looking at bugs which the SRU verification team is subscribed.

The Pending Ubuntu SRUs are generated by parsing the changelogs of the packages in -proposed repository. By clicking on changelog bugs entry you will be taken to the Launchpad bug report (if it exists). Some bugs resolved by -proposed packages require specific hardware and these can be identified by the hw-specific tag in Launchpad or by the (hw) next to the bug number at the Pending Ubuntu SRUs page.

Identifying how to test

The first step in identifying how to test, is determining the release or releases of Ubuntu affected by the particular bug. This can be done by looking at the bug report and determining the release affected by the bug.

In the example below the Postgresql8.1 bug affects the Dapper, Feisty, Gutsy and Hardy releases of Ubuntu and should be verified in each one.

  • https://wiki.ubuntu.com/QATeam/PerformingSRUVerification?action=AttachFile&do=get&target=bug.png

    Click to zoom

Alternatively, at the Pending Ubuntu SRUs page there are sections for each release of Ubuntu that is currently supported.

In addition to knowing the release or releases of Ubuntu affected you also need to have detailed steps to recreate the bug. These can be found in the "TEST CASE" section at the end of the bug's description. Bug 172264 has an example of what the test case will look like.

How to perform the test

After booting into the affected release of Ubuntu the following steps should be taken:

  1. Ensure that your system is up to date by installing all available updated packages from the -updates and -security repositories
  2. Verify that you do not have the proposed package installed by checking the package version using 'dpkg -l PKGNAME | cat'
  3. Recreate the bug using the steps identified in the "TEST CASE"
  4. Modify your '/etc/apt/sources.list' file to include the -proposed repository
  5. Execute 'sudo apt-get update'
  6. Install the proposed package via 'sudo apt-get install PKGNAME' or 'sudo apt-get install PKGNAME=VERSION-NUM'
  7. Verify that you installed the correct package version using 'dpkg -l PKGNAME | cat'
  8. Reboot the system
  9. Try to recreate the bug using the steps identified in the "TEST CASE"
  10. Use the software installed by the package in common ways

Updating the bug report

Include: Nothing found for "[[Anchor"!

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.

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

  2. Describe why the fix was insufficient or broken in a comment to the bug report.
  3. Modify the verification-needed-$RELEASE tag to a verification-failed-$RELEASE tag on the bug report where $RELEASE is the release name which you tested.

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

  1. Modify the 'verification-needed-$RELEASE' tag to a 'verification-done-$RELEASE' tag on the bug report where $RELEASE is the release name of the upload you have tested e.g. verification-done-precise. The tag global verification-needed should be left on the bug until all release tasks have been verified.

  2. Describe the general steps taken to verify the package (and any special difficulties) in a comment on the bug.

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.
  2. Mark this bug with the tag regression-proposed

  3. Ask a bug supervisor to target the bug to the appropriate Ubuntu releases.

  4. Follow up on 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.
  5. Set the verification-failed-$RELEASE tag on the corresponding SRU bug report where $RELEASE is the release name of the upload you tested.

If you want to help us to verify Stable Release Updates then read 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.

  2. Ensure all critical and high importance bugs are verified in a timely manner. If not, the SRU QA Engineer will perform the testing.
  3. 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.

  4. If necessary, the QA team will set up separate SRU verification program, for big packages like eglibc, python, X.

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.

In the case where an SRU upload triggers an autopkgtest regression, the target package will not be released into -updates until the failure is resolved. There are a few ways that can happen:

  • If the reported autopkgtest regression is a real regression caused by the upload, the update should be considered verification-failed and the package should be re-uploaded with the regression fixed. Otherwise the update will be removed from -proposed as per the usual procedures.

  • If the reported autopkgtest regression is not a real regression or not a regression caused by the proposed update (but instead broken by some other dependency), the analysis of this has to be documented for the SRU team. The generally recommended way is commenting on one of the SRU bugs for the upload. Once the rationale is submitted and approved/validated by an SRU member, the SRU team will add a badtest or reset-test hint for the broken package and release the update as per usual procedures (once validation and aging is complete). Alternatively, the uploader/verifier can modify the hints and provide an MP in the bug along with the rationale. Useful input here can be re-running the failing test against only the release/updates pocket, as documented in the ProposedMigration wiki page.

  • If the reported autopkgtest regression is the result of a flaky test, the uploader can try re-running the test to see if it is indeed just a transient issue. If the issue still persists but the analysis clearly shows that it is not a real regression, a rationale for that should be provided in one of the SRU bugs.

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

If an SRU did not cause a regression, the update is intended to land but autopkgtest regressions are still found, then the possible resolutions for this situation are as follows:

  • An SRU must not be released if outstanding autopkgtest regressions are reported on the Pending SRU Report.

  • Ideally regressions can be fixed with new uploads to the proposed pockets as required. Fixes for autopkgtests are generally always acceptable. However uploads providing only test fixes will generally be staged using block-proposed-<series> (in which case they need a bug reference).

  • A regression not caused by the SRU may be badtest or reset-tested away (doesn't matter which for SRUs).

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.

To obtain a new ongoing exception such as those documented below:

  1. Draft a wiki page, like the ones below, outlining what you believe should be the exception.
  2. Submit it to the SRU team for approval. This can be done to any individual member of the SRU team directly, or you can send it to ubuntu-release@lists.ubuntu.com for review.

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.

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.

DPDK

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.

apt and python-apt

Not a policy exception, but see AptUpdates for details of unusual SRU versioning.

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.

wslu

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

*** THIS IS OUTDATED !!! *** 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.

ubuntu-advantage-tools

The ubuntu-advantage-tools source package may be uploaded according to the SRU procedures documented in UbuntuAdvantageToolsUpdates. This stable release exception has been approved by RobieBasak for the SRU team part as of 2023-10-04.

open-vm-tools

The open-vm-tools source package may be uploaded according to the proceedure documented in OpenVMToolsUpdates. This stable release exception has been approved by ChrisHalseRogers for the SRU team as of 2024-01-25.

postgresql

The currently supported postgresql source package (as determined by the dependency of the postgresql metapackage) for each stable release may be uploaded according to the proceedure documented in PostgreSQLUpdates. This stable release exception has been approved by ChrisHalseRogers for the SRU team as of 2024-01-31

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.

Feature

16.04 LTS

18.04 LTS

20.04 LTS

21.04

21.10

icu-data

No

No

Yes

Yes

Yes

SystemV tzs

Yes

Yes

Yes

No

No

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.

python3 -c "from datetime import datetime; from icu import ICUtzinfo, TimeZone; tz = ICUtzinfo(TimeZone.createTimeZone('Pacific/Fiji')); print(str(tz.utcoffset(datetime(2020, 11, 10))))"

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.

diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 | cut -d' ' -f2-)

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:

[ Test Plan ]
  
Verify that the following subcommands of `distro-info` print information about the new devel and current stable releases:
  
 * `--devel`
 * `--supported`
 * `--stable`

and try the same commands with these modifiers:

 * `--date=<1 day after release>` along with the above
 * `--fullname`
 * `--release`

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.

Previous Removals:

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.

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.

Phasing of Stable Release Updates: http://people.canonical.com/~ubuntu-archive/phased-updates.html

  • 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

  •  git clone https://git.launchpad.net/ubuntu-archive-tools

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.

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:
     sru-review -s saucy gnash
    This opens all the bugs which are mentioned in the .changes file in the browser, and 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).
    • In case the SRU is a package sync instead of a standard upload, the sru-review tool will not be able to fetch the debdiff for you and will exit with an error. You will have to review the changes manually and then re-run the tool with an additional argument of --no-diff.

    • For Bileto published SRU's you can easily fetch the relevant debdiffs by following the link to the sync's source PPA and opening the ticket URL that's provided in the PPA description. Each upload present there has two diffs generated for review convenience: full and packaging-only.

  • Review the bugs for complete description, justification, check that they have a stable release 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 in the ubuntu-sru team:

    • 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.

      This will tag the bug(s) with verification-needed, verification-needed-$RELEASE, subscribe ubuntu-sru, and add a general "please test and give feedback"-like comment.

    • If the upload is broken or unsuitable for an SRU, reject it by pressing N at the ""Accept the package into -proposed?" prompt and pressing y at the "REJECT the package from -proposed?" prompt.

  • If you are not in the ubuntu-sru team: 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 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:

  • $ ./sru-release xenial kdebase

Please see --help, you can also use this tool to copy packages to -security and to the current development release. N.B. before copying a package to -security ping a member of the ubuntu-security team.

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:

  • $ ./remove-package -m "SRU abandoned (verification-failed)" -s xenial-proposed libreoffice

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:

Day

SRU Team Member (IRC nick)

Monday

Łukasz Zemczak (sil2100), Mauricio Oliveira (mfo)

Tuesday

Chris Halse Rogers (RAOF), Brian Murray (bdmurray)

Wednesday

Robie Basak (rbasak)

Thursday

Andreas Hasenack (ahasenack), Łukasz Zemczak (sil2100 - backup)

Friday

Timo Aaltonen (tjaalton), Steve Langasek (vorlon - backup)


CategoryProcess

Ways to test using virtual machines

In the event that your current release of Ubuntu is not the same as the release of Ubuntu affected by the bug there are still many ways for you to perform the verification of the Stable Release Update without installing the affected release on your hardware. This can be done by using an emulator such as Virtual Box, kvm, qemu or VMware. Virtual machines images for VMware are available at http://isv-image.ubuntu.com/vmware/. Depending on the nature of the bug report it may also be possible to use a chroot to perform the verification.