PerformingSRUVerification
|
Size: 2898
Comment:
|
Size: 8236
Comment: added step 11 at How_to_perform_the_test
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| SRU Verification is the process of testing packages, updated to fix a bug, that exist in the -proposed repository. These packages need testing to ensure that the package continues to function as designed and that the bug is fixed. | <<Include(QATeam/Header)>> ||<tablestyle="float:right; font-size: 0.9em; width:40%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;"><<TableOfContents>>|| Stable Release Update (SRU) Verification is the process of testing packages from the -proposed repository, that have been updated to fix bugs in a [[https://wiki.ubuntu.com/Releases|stable release]]. 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 [[https://wiki.ubuntu.com/StableReleaseUpdates|Stable Release Update]] page. To find out how to enable -proposed look at the [[https://wiki.ubuntu.com/Testing/EnableProposed|Enable Proposed]] page. |
| Line 5: | Line 11: |
| Bugs needing SRU verification can be found by viewing the [http://people.ubuntu.com/~ubuntu-archive/pending-sru.html Pending Ubuntu SRUs] or by querying Launchpad for the bug tag [https://launchpad.net/ubuntu/+bugs?field.tag=verification-needed verification-needed] or by search for bugs subscribed to by the SRU verification team. 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. | There are many ways to find bugs needing SRU verification: * by viewing the [[http://people.ubuntu.com/~ubuntu-archive/pending-sru.html|Pending Ubuntu SRUs]], * by asking aptitude from the command-line: "aptitude search ~i~Aproposed" * by querying Launchpad for a specific release (here lucid) and the bug tag [[https://launchpad.net/ubuntu/lucid/+bugs?field.status%3Alist=FIXCOMMITTED&field.tag=verification-needed|verification-needed]], * or by looking at bugs which the SRU verification team is [[https://bugs.launchpad.net/~sru-verification/+subscribedbugs|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). If no changelog bug is displayed, clicking on the version of the package in the '-proposed' column will take you to the changelog entry for that version of the package in launchpad (the bug number may be displayed in the changelog but not in the report if the bug number doesn't respect a standard format) 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. |
| Line 9: | Line 24: |
| The first step in identifying how to test is determing 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. attachment:multiple-release-targets.png |
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. |
| Line 12: | Line 26: |
| Alternatively, at the [http://people.ubuntu.com/~ubuntu-archive/pending-sru.html Pending Ubuntu SRUs] page there are sections for each release of Ubunut that is currently supported. | More than one release may be affected by the bug. In that case, the bug needs to be reproduced and the fix needs to be tested for each affected release. |
| Line 14: | Line 28: |
| In addition to knowing the release or releases of Ubuntu affected you also need to have a detailed steps to recreate the bug. These can be found in the "TEST CASE" section at the end of the bug's description. | In the example below the Landspace bug affects the Jaunty, Karmic, Lucid and Maverick releases of Ubuntu and should be verified in each stable release (Jaunty, Karmic and Lucid) ||<tablestyle="float:center; font-size: 0.75em; background:#C2B8A1;margin: 0 0 1em 1em;" style="padding:0.5em;">[[https://wiki.ubuntu.com/QATeam/PerformingSRUVerification?action=AttachFile&do=get&target=bug_example_large.png|{{https://wiki.ubuntu.com/QATeam/PerformingSRUVerification?action=AttachFile&do=get&target=bug_example_small.png}}]]|| || Click to zoom || Alternatively, at the [[http://people.ubuntu.com/~ubuntu-archive/pending-sru.html|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. [[https://bugs.edge.launchpad.net/ubuntu/karmic/+source/flashplugin-nonfree/+bug/429841|Flashplugin-nonfree bug 429841]] has an example of what the test case will look like. Test cases should be added to the description of the report in a standardised format: {{{ TEST CASE: 1. description of step 1 2. description of the step 2 3. ... VERIFICATION DONE What is the expected result at the end of the test. }}} Note that the verification-failed is either the subject of the bug report or a regression. Writing the test case is a mandatory step of the [[StableReleaseUpdates|SRU procedure]]. But sometimes, there is no such test case. If the test case is missing and the reproduction steps are not obvious, you can provide one if you can reproduce the issue described in the bug report or set the status to 'In progress', describe why you cannot reproduce and set the verification tag to 'verification-failed'. |
| Line 20: | Line 55: |
| 1. Install all available updates | 1. Ensure that your system is up to date by installing all available updated packages from the -updates and -security repositories 1. Verify that you do not have the proposed package installed by checking the package version using 'dpkg -l PKGNAME | cat' |
| Line 22: | Line 58: |
| 1. Modify your '/etc/apt/sources.list' file to include the -proposed repository * what the line looks like for Gutsy |
1. Modify your '/etc/apt/sources.list' file to include the -proposed repository as described in [[Testing/EnableProposed|how to enable -proposed]]. * deb http://archive.ubuntu.com/ubuntu/ oneiric-proposed main restricted universe |
| Line 25: | Line 61: |
| 1. Install the updated package via 'sudo apt-get install package' or 'sudo apt-get install package=version-number' | 1. Install the proposed package via 'sudo apt-get install PKGNAME' or 'sudo apt-get install PKGNAME=VERSION-NUM' 1. Verify that you installed the correct package version using 'dpkg -l PKGNAME | cat' |
| Line 29: | Line 66: |
| 1. Once you have finished testing the package from the -proposed repository you can disable -proposed. Failing to do so will lead to you updating any package available from the -proposed repository at the next apt update. Having a look at the patch may help to know exactly which part of the package is affected by the fix and what needs to be more specifically tested. One of the most important aspects of the testing procedure is to verify that the update does not introduce a regression. == Updating the bug report == <<Include(StableReleaseUpdates,,from="== Verification ==", to="If you want to help us")>> == Tagging the report == === SRU specific === <<Include(Bugs/Tags,,from='=== SRU Specific ===',to='=== X ')>> === Regression specific === <<Include(Bugs/Tags,,from='=== Regression specific ===',to='=== SRU Specific ===')>> |
|
| Line 32: | Line 88: |
| In the event that your current release of Ubuntu is not the same as the release of Ubuntu affected by the bug there are many ways for you to still 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 VMWare, virtual box, kvm or qemu. Depending on the nature of the bug report it may also be possible to use a chroot to perform the verification. | 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 a [[https://help.ubuntu.com/community/VirtualMachines|Virtual Machine]] such as [[https://wiki.ubuntu.com/Testing/VirtualBox|Virtual Box]], [[https://wiki.ubuntu.com/KvmVirtManagerEtc|kvm]], [[https://help.ubuntu.com/community/Installation/QemuEmulator|qemu]] or VMware. Virtual Machines can not be used to reproduce hardware specific issues. Depending on the nature of the bug report it may also be possible to use a [[https://wiki.ubuntu.com/DebootstrapChroot|chroot]] to perform the verification. == Tips and tricks == * An useful tool to quickly check the versions of a package available in the active releases is `rmadison` from the package `devscripts`. * You can fetch the changelog of a package directly from the command line with `apt-get changelog PACKAGE_NAME` * The full publishing history of a package: https://launchpad.net/ubuntu/+source/PACKAGE_NAME/+publishinghistory * If you're wondering where is the uploaded package you should check [[ https://launchpad.net/ubuntu/oneiric/+queue|the state of the upload queue]] == Links == * [[StableReleaseUpdates|Stable Release Update]] procedure * [[http://people.ubuntu.com/~ubuntu-archive/pending-sru.html|Pending Ubuntu SRUs]] * List of bugs which the SRU verification team is [[https://bugs.launchpad.net/~sru-verification/+subscribedbugs|subscribed]] * How to [[Testing/EnableProposed|Enable Proposed]] * How to triage [[Bugs/HowToTriage|guide]] |
Stable Release Update (SRU) Verification is the process of testing packages from the -proposed repository, that have been updated to fix bugs in a stable release. 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 Pending Ubuntu SRUs,
- by asking aptitude from the command-line: "aptitude search ~i~Aproposed"
by querying Launchpad for a specific release (here lucid) and 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). If no changelog bug is displayed, clicking on the version of the package in the '-proposed' column will take you to the changelog entry for that version of the package in launchpad (the bug number may be displayed in the changelog but not in the report if the bug number doesn't respect a standard format)
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.
More than one release may be affected by the bug. In that case, the bug needs to be reproduced and the fix needs to be tested for each affected release.
In the example below the Landspace bug affects the Jaunty, Karmic, Lucid and Maverick releases of Ubuntu and should be verified in each stable release (Jaunty, Karmic and Lucid)
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. Flashplugin-nonfree bug 429841 has an example of what the test case will look like.
Test cases should be added to the description of the report in a standardised format:
TEST CASE: 1. description of step 1 2. description of the step 2 3. ... VERIFICATION DONE What is the expected result at the end of the test.
Note that the verification-failed is either the subject of the bug report or a regression.
Writing the test case is a mandatory step of the SRU procedure. But sometimes, there is no such test case. If the test case is missing and the reproduction steps are not obvious, you can provide one if you can reproduce the issue described in the bug report or set the status to 'In progress', describe why you cannot reproduce and set the verification tag to 'verification-failed'.
How to perform the test
After booting into the affected release of Ubuntu the following steps should be taken:
- Ensure that your system is up to date by installing all available updated packages from the -updates and -security repositories
- Verify that you do not have the proposed package installed by checking the package version using 'dpkg -l PKGNAME | cat'
- Recreate the bug using the steps identified in the "TEST CASE"
Modify your '/etc/apt/sources.list' file to include the -proposed repository as described in how to enable -proposed.
deb http://archive.ubuntu.com/ubuntu/ oneiric-proposed main restricted universe
- Execute 'sudo apt-get update'
- Install the proposed package via 'sudo apt-get install PKGNAME' or 'sudo apt-get install PKGNAME=VERSION-NUM'
- Verify that you installed the correct package version using 'dpkg -l PKGNAME | cat'
- Reboot the system
- Try to recreate the bug using the steps identified in the "TEST CASE"
- Use the software installed by the package in common ways
- Once you have finished testing the package from the -proposed repository you can disable -proposed. Failing to do so will lead to you updating any package available from the -proposed repository at the next apt update.
Having a look at the patch may help to know exactly which part of the package is affected by the fix and what needs to be more specifically tested.
One of the most important aspects of the testing procedure is to verify that the update does not introduce a regression.
Updating the bug report
Include: Nothing found for "If you want to help us"!
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/
Removal of updates
This section has moved to https://canonical-sru-docs.readthedocs-hosted.com/en/latest/explanation/non-standard-processes/#removal-of-languishing-updates
Regressions
This section has moved to https://canonical-sru-docs.readthedocs-hosted.com/en/latest/howto/regression/#howto-report-regression
Testing for Regressions
(defunct section removed)
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:
- Draft a wiki page, like the ones below, outlining what you believe should be the exception.
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
GRUB
GRUB related packages require a special SRU process due our EFI signing pipeline, documented at StableReleaseUpdates/Grub.
OpenVPN
Updates including upstream OpenVPN microreleases should follow the special case documentation at OpenVPNUpdates. This is not a standing approval or policy exception, but a general pattern to update OpenVPN upstream microreleases consistently under existing SRU policy.
Language Packs (language-pack-*)
There is some documentation at: https://git.launchpad.net/langpack-o-matic/tree/doc/operator-guide.txt
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.
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.
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
This section has moved to https://canonical-sru-docs.readthedocs-hosted.com/en/latest/explanation/non-standard-processes/#explanation-removals
Links
This section has moved to https://canonical-sru-docs.readthedocs-hosted.com/en/latest/reference/status/
Reviewing procedure and tools
This section has moved to https://canonical-sru-docs.readthedocs-hosted.com/en/latest/internal/#reviewing-procedure-and-tools
Contacting the SRU team
This section has moved to https://canonical-sru-docs.readthedocs-hosted.com/en/latest/howto/contact/
Tagging the report
SRU specific
See StableReleaseUpdates for more information.
Tag |
Use case |
A Stable Release Update bug with a package in -proposed that has been confirmed to fix the bug. |
|
A Stable Release Update bug with a package in -proposed that has been verified to not fix the bug. |
|
A Stable Release Update bug with a package in -proposed needing testing. |
|
block-proposed-<series> |
A bug that should be held back being released into the updates pocket for the corresponding stable series. See StableReleaseUpdates#Staging_an_upload. |
Regression specific
See the regression tracker for a list of these bugs and QATeam/RegressionTracking for more information.
Tag |
Use case |
A bug in a release that was not present in a previous release. Should be used together with a separate tag for the release the regression was found in. This also applies to a development release where an update introduces a regression prior to its official release. |
|
A bug in a stable release that was introduced by a package from -updates. This would not apply to a development release where a regression was introduced prior to its official release. |
|
A bug in a stable release of Ubuntu that was found when testing a package from -proposed. |
|
An apport crash bug report that was identified by the retracer as having the same characteristics as a fixed crash report. |
|
This is for when a bisect is requested or required to fix the bug. |
|
The reporter, developer, or triager is in the process of performing a bisection. |
|
Add when a bisect has been completed and the offending commit(s) identified. |
Release Specific
Tag |
Use case |
A bug tracking a cause of a package not being migrated to the release pocket. This tag causes the bug to appear on the update excuses report. |
|
A bug that should be held back from migrating into the release pocket |
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 a Virtual Machine such as Virtual Box, kvm, qemu or VMware.
Virtual Machines can not be used to reproduce hardware specific issues.
Depending on the nature of the bug report it may also be possible to use a chroot to perform the verification.
Tips and tricks
An useful tool to quickly check the versions of a package available in the active releases is rmadison from the package devscripts.
You can fetch the changelog of a package directly from the command line with apt-get changelog PACKAGE_NAME
The full publishing history of a package: https://launchpad.net/ubuntu/+source/PACKAGE_NAME/+publishinghistory
If you're wondering where is the uploaded package you should check the state of the upload queue
Links
Stable Release Update procedure
List of bugs which the SRU verification team is subscribed
How to Enable Proposed
How to triage guide
QATeam/PerformingSRUVerification (last edited 2017-09-27 12:43:57 by vorlon)