<> ||<>|| 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. == How to find bugs needing verification == 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. == 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) ||[[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'. == 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 1. Verify that you do not have the proposed package installed by checking the package version using 'dpkg -l PKGNAME | cat' 1. Recreate the bug using the steps identified in the "TEST CASE" 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/ xenial-proposed main restricted universe<
>For verifying SRUs on non-x86 architectures, instead use: * deb http://ports.ubuntu.com/ubuntu-ports/ xenial-proposed main restricted universe 1. Execute 'sudo apt-get update' 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' 1. Reboot the system 1. Try to recreate the bug using the steps identified in the "TEST CASE" 1. Use the software installed by the package in common ways 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 == <> == Tagging the report == === SRU specific === <> === Regression specific === <> == 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 [[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]]