.\" Man page generated from reStructuredText. . .TH "CHECKBOX_NG" "1" "January 11, 2016" "0.23" "CheckboxNG" .SH NAME checkbox_ng \- CheckboxNG Documentation . .nr rst2man-indent-level 0 . .de1 rstReportMargin \\$1 \\n[an-margin] level \\n[rst2man-indent-level] level margin: \\n[rst2man-indent\\n[rst2man-indent-level]] - \\n[rst2man-indent0] \\n[rst2man-indent1] \\n[rst2man-indent2] .. .de1 INDENT .\" .rstReportMargin pre: . RS \\$1 . nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin] . nr rst2man-indent-level +1 .\" .rstReportMargin post: .. .de UNINDENT . RE .\" indent \\n[an-margin] .\" old: \\n[rst2man-indent\\n[rst2man-indent-level]] .nr rst2man-indent-level -1 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]] .in \\n[rst2man-indent\\n[rst2man-indent-level]]u .. .sp CheckboxNG is a hardware testing tool useful for certifying laptops, desktops and servers with Ubuntu. It is a new version of \fI\%Checkbox\fP <\fBhttp://plainbox.readthedocs.org/en/latest/glossary.html#term-checkbox\fP> that is built directly on top of \fI\%PlainBox\fP <\fBhttp://plainbox.readthedocs.org/en/latest/glossary.html#term-plainbox\fP> .sp CheckboxNG \fIreplaces\fP Checkbox, where applicable. .sp \fBWARNING:\fP .INDENT 0.0 .INDENT 3.5 Documentation is under development. Some things are wrong, inaccurate or describe development goals rather than current state. .UNINDENT .UNINDENT .SH INSTALLATION .sp CheckboxNG can be installed from a PPA (recommended) or pypi on Ubuntu Precise (12.04) or newer. .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C $ sudo add\-apt\-repository ppa:checkbox\-dev/ppa && sudo apt\-get update && sudo apt\-get install checkbox\-ng .ft P .fi .UNINDENT .UNINDENT .SH RUNNING STABLE RELEASE UPDATE TESTS .sp CheckboxNG has special support for running stable release updates tests in an automated manner. This runs all the jobs from the \fIsru.whitelist\fP and sends the results to the certification website. .sp To run SRU tests you will need to know the so\-called \fI\%Secure ID\fP <\fBhttp://plainbox.readthedocs.org/en/latest/glossary.html#term-secure-id\fP> of the device you are testing. Once you know that all you need to do is run: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C $ checkbox sru $secure_id submission.xml .ft P .fi .UNINDENT .UNINDENT .sp The second argument, submission.xml, is a name of the fallback file that is only created when sending the data to the certification website fails to work for any reason. .SH REPORTING BUGS .sp To report bugs on the Checkbox project you will need a launchpad account. You may find \fI\%instructions on how to create one\fP <\fBhttps://help.launchpad.net/YourAccount/NewAccount\fP> useful. Once you have an account you can \fI\%report bugs\fP <\fBhttps://bugs.launchpad.net/checkbox-project/+filebug\fP>\&. .sp On that page you can select the project you wish to file the bug on (we use a number of projects to coordinate releases and we prefer to have bugs associated with appropriate part of Checkbox). If you know the right project to use, just use it and file the bug. If you don\(aqt know Checkbox internals that much or are in doubt just file it on the base \(aqCheckbox\(aq project (you can use \fI\%this direct link\fP <\fBhttps://bugs.launchpad.net/checkbox/+filebug\fP>\&.) A member of the development team will review your bug and re\-assign it to the appropriate location. The bug number will not change when that happens. .SH THE "CHECKBOX STACK" .sp The Checkbox Stack is a collection of projects that together constitute a complete testing and certification solution. It is composed of the following parts (see table below for extra details). All of the projects are linked to from the \fI\%Launchpad project group\fP <\fBhttps://launchpad.net/checkbox-project\fP>\&. .SS Architecture Diagram [image: Architecture Diagram] [image] .sp This diagram contains a high\-level approximation of the current Checkbox architecture. There are three main "pillars". On the left we have \fIend products\fP\&. Those are actual tools that certification and engineers are using. On the right we have the \fItest market\fP\&. This is a open market of tests vendors and suppliers. The tests are wrapped in containers known as providers. In the center we have three shared components. Those implement the bulk of the framework and user interfaces for test execution. Finally in the bottom\-left corner there is a part of checkbox (a library) that is shared with HEXR for certain tasks. HEXR is a out\-of\-scope web application used by part of the certification process. Arrows imply communication with the shape of the arrow shows who calls who. .sp As mentioned before, in the center column there are three main components of shared code (shared by everyone using the end products that are discussed below). The shared code is composed of plainbox, checkbox\-ng and checkbox\-gui. Component responsibilities are discussed in more detail in the table below. Here we can see that checkbox\-gui used DBus API exposed by checkbox\-ng, which in turn uses checkbox\-support (a helper library separated out so share some code with HEXR) and plainbox. .sp In the right hand side column there are various test providers. The checkbox project is producing and maintaining a number of providers (see the table below) but it is expected that our downstream users will also produce their own providers (specific to a customer or project). Eventually some providers may come from third parties that will adopt the format. .sp Lastly in the bottom\-left corner, the shared library, this library contains many parsers of various file formats and output formats. Technically this library is a dependency of HEXR, checkbox\-ng \fIand\fP of providers. As an added complexity the library needs to be called from python3 code and python2 code. .sp \fBNOTE:\fP .INDENT 0.0 .INDENT 3.5 The communication between checkbox\-ng and plainbox is bi\-directional. Plainbox offers some base interfaces and extension points. Those are all exposed through plainbox (using common APIs) but some of those are actually implemented in checkbox\-ng. .UNINDENT .UNINDENT .sp \fBWARNING:\fP .INDENT 0.0 .INDENT 3.5 All internal APIs are semi\-unstable. The DBus API is more stable in practice but should not be relied upon. Projects are encouraged to be merged into lp:checkbox where API transitions can be handled gracefully. The only stable API is are file format specification (job definitions and whitelits). Launcher specification will be stabilized in the next release. .UNINDENT .UNINDENT .SS Component Descriptions .TS center; |l|l|l|. _ T{ Project T} T{ Responsible for T} T{ Type T} _ T{ Next Generation Checkbox (GUI) T} T{ .INDENT 0.0 .IP \(bu 2 The C++/QML user interface .IP \(bu 2 The graphical launcher for providers, e.g. checkbox\-certification\-client .UNINDENT T} T{ Application T} _ T{ Next Generation Checkbox (CLI) T} T{ .INDENT 0.0 .IP \(bu 2 The python command\-line interface .INDENT 2.0 .IP \(bu 2 the text user interface .IP \(bu 2 the SRU testing command .UNINDENT .IP \(bu 2 Additional certification APIs .INDENT 2.0 .IP \(bu 2 sending data to Launchpad .IP \(bu 2 sending data to HEXR .UNINDENT .IP \(bu 2 the DBus service needed by GUI .UNINDENT T} T{ Application T} _ T{ Client Certification Provider T} T{ .INDENT 0.0 .IP \(bu 2 canonical\-certification\-client executable .IP \(bu 2 client certification whitelists .UNINDENT T} T{ Provider T} _ T{ Server Certification Provider T} T{ .INDENT 0.0 .IP \(bu 2 server certification whitelists .IP \(bu 2 additional server whitelists .UNINDENT T} T{ Provider T} _ T{ System\-on\-Chip Server Certification Provider T} T{ .INDENT 0.0 .IP \(bu 2 SoC server certification whitelists .UNINDENT T} T{ Provider T} _ T{ Checkbox Provider T} T{ .INDENT 0.0 .IP \(bu 2 Almost all job definitions .IP \(bu 2 Most of custom "scripts" .IP \(bu 2 Default and SRU whitelist .UNINDENT T} T{ Provider T} _ T{ Resource Provider T} T{ .INDENT 0.0 .IP \(bu 2 Almost all resource jobs .IP \(bu 2 Almost all resource "scripts" .UNINDENT T} T{ Provider T} _ T{ Checkbox Support T} T{ .INDENT 0.0 .IP \(bu 2 Support code for various providers .IP \(bu 2 Parsers for many text formats .UNINDENT T} T{ Library T} _ T{ PlainBox T} T{ .INDENT 0.0 .IP \(bu 2 Almost all core logic .INDENT 2.0 .IP \(bu 2 RFC822 (job definition) parser .IP \(bu 2 Configuration handling .IP \(bu 2 Testing session (suspend/resume) .IP \(bu 2 Job runner .IP \(bu 2 Trusted launcher .IP \(bu 2 Dependency resolver .IP \(bu 2 Command line handling .IP \(bu 2 The XML, HTML and XSLX exporters .IP \(bu 2 and more... .UNINDENT .IP \(bu 2 Provider development toolkit .INDENT 2.0 .IP \(bu 2 \(aqplainbox startprovider\(aq .IP \(bu 2 \(aqmanage.py\(aq implementation .UNINDENT .UNINDENT T} T{ Library and Development Toolkit T} _ T{ Legacy Checkbox (no longer maintained) T} T{ .INDENT 0.0 .IP \(bu 2 Applications .INDENT 2.0 .IP \(bu 2 Qt4 GUI .IP \(bu 2 Gtk2 GUI .IP \(bu 2 Urwid (text) GUI .UNINDENT .IP \(bu 2 Core .INDENT 2.0 .IP \(bu 2 Plugin and Event / Message Engine .IP \(bu 2 Almost Every feature implemented a core plugin .UNINDENT .IP \(bu 2 Data .INDENT 2.0 .IP \(bu 2 Jobs and whitelists .UNINDENT .UNINDENT T} T{ Monolithic Application Library and Data T} _ .TE .SH CHANGELOG .sp \fBNOTE:\fP .INDENT 0.0 .INDENT 3.5 This changelog contains only a summary of changes. For a more accurate accounting of development history please inspect the source history directly. .UNINDENT .UNINDENT .SS CheckboxNG 0.23 (unreleased) .INDENT 0.0 .IP \(bu 2 Bugfixes: \fI\%https://launchpad.net/checkbox\-ng/+milestone/0.23\fP .UNINDENT .SS CheckboxNG 0.22 .INDENT 0.0 .IP \(bu 2 Bugfixes: \fI\%https://launchpad.net/checkbox\-ng/+milestone/0.22\fP .UNINDENT .SS CheckboxNG 0.3 .INDENT 0.0 .IP \(bu 2 Bugfixes: \fI\%https://launchpad.net/checkbox\-ng/+milestone/0.3\fP .UNINDENT .SS CheckboxNG 0.2 .INDENT 0.0 .IP \(bu 2 Bugfixes: \fI\%https://launchpad.net/checkbox\-ng/+milestone/0.2\fP .UNINDENT .SS CheckboxNG 0.1 .INDENT 0.0 .IP \(bu 2 Initial release .IP \(bu 2 Support for displaying configuration .IP \(bu 2 Support for running SRU tests (automatic regression testing) .UNINDENT .SH TEST SCRIPTS .sp Test \(aqscripts\(aq are small programs which are used to aid in implementing tests. .SS brightness_test .sp This script tests the brightness of the systems backlight can be changed by using the kernel interfaces in /sys/class/backlight. There may be more than one interface to choose from, so the correct interface to use is selected by using the heuristic prescribed in \fI\%https://www.kernel.org/doc/Documentation/ABI/stable/sysfs\-class\-backlight\fP\&. The brightness is manipulated by updating the brightness file of the interface and the actual_brightness file is checked to see if the value was modified to the brightness selected. .SH PROFILES CONFIGURATION .sp Execution profiles, or launchers, allow specifying a predefined set of configuration options that allow customization of the welcome screen, displayed whitelists as well as saving results locally or sending the submission file to Launchpad or to the Certification database/HEXR, as well as some other parameters. .sp The profile settings are part of a launcher script and use either checkbox\-gui or checkbox\-launcher (in text\-mode/CLI) as a shebang to interpret the key/values. .sp This document provides a reference on launcher functionality and syntax. To understand the design and concepts and see several examples, you may want to read the \fBtutorial\fP on how to create launchers and their relationship with legacy \fI\%Checkbox\fP <\fBhttp://plainbox.readthedocs.org/en/latest/glossary.html#term-checkbox\fP>\&. .SS Syntax .sp As checkbox\-gui is a Qt application, settings must follow the INI\-style rules of the \fI\%QSettings\fP <\fBhttp://qt-project.org/doc/qt-5/QSettings.html\fP> class. .sp Multiple\-line values are supported but must be enclosed in doubles quotes and extra lines must start with one space, e.g: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C [category] key = "Hello World" .ft P .fi .UNINDENT .UNINDENT .INDENT 0.0 .IP \(bu 2 From QML: .UNINDENT .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C settings.value("category/key", i18n.tr("default_value")) .ft P .fi .UNINDENT .UNINDENT .INDENT 0.0 .IP \(bu 2 From C++: .UNINDENT .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C settings\->value("category/key", app.tr("default_value")) .ft P .fi .UNINDENT .UNINDENT .sp Conversely, checkbox\-launcher\-specific launchers must follow \fI\%Python ConfigParser\fP <\fBhttps://docs.python.org/3/library/configparser.html#supported-ini-file-structure\fP> syntax. .sp Also, some settings only make sense for either GUI or CLI, and are thus not understood by the other. These are noted below. .SS Supported Settings .INDENT 0.0 .TP .B welcome/title QML application title and welcome screen header. Defaults to \fBSystem Testing\fP\&. .TP .B welcome/text Welcome message to display on the first screen (checkbox\-gui supports Rich text allowing HTML\-style markup). Defaults to \fB
Welcome to System Testing.
[...]\fP .TP .B suite/whitelist_filter Regular expression to match a subset of whitelist filenames. On checkbox\-gui it defaults to \fB\&.*\fP\&. For checkbox\-launcher it has no default and \fImust\fP be defined. .TP .B suite/whitelist_selection Pattern that whitelists need to match to be preselected. Python regular expression. It has no default and \fImust\fP be defined. (CLI only) .TP .B suite/skip_whitelist_selection If set to true, user will not receive a choice of whitelist. Only the preselected ones (see whitelist_selection) will be selected. (CLI only). .TP .B suite/skip_test_selection If set to true, user will not be allowed to deselect tests prior to run: all tests in the selected whitelist will be run. (CLI only) .TP .B submission/message Header text of the submission pop\-up , shown to the user after submission has completed. (GUI only) .TP .B submission/input_type Show a Text input field to enter the secure ID or the LP address (default). To just save the results to disk, must use the \fBnone\fP value. To validate using a regex, must be \fBregex\fP\&. (GUI only) .TP .B submission/regex Regular expression to validate input in submission field (e.g. email, secure_id) if input_type is regex. (GUI only). RegExpValidator, default \fB\&.*\fP .TP .B submission/input_placeholder Temporary text to put in input field, used to guide the user. \fBLaunchpad E\-Mail Address\fP (default) or \fBSecure ID (15 or 18 characters)\fP\&. (GUI only) .TP .B submission/secure_id Preconfigured secure_id to fill in the text field. .TP .B submission/ok_btn_text The label for the "Send" button. \fBSubmit Results\fP (default) or \fBSave Results\fP\&. (GUI only) .TP .B submission/cancel_warning Show to the user if he wants to exit without having saved the report. You are about to exit this test run without saving your results report. Do you want to save the report? (GUI only) .TP .B submission/submit_to_hexr Boolean, add an extra header to also send the results to HEXR (works with the certification transport) .TP .B exporter/xml_export_path Location to save the XML submission file, if set to an empty string will open a file save dialog. Default: \fB/tmp/submission.xml\fP (GUI only) .TP .B transport/submit_to Transport endpoint. Defaults to \fBWelcome to System Certification!
This application will gather information from your system. Then you will be asked manual tests to confirm that the system is working properly. Finally, you will be asked for the Secure ID of the computer to submit the information to the certification database.
To learn how to create or locate the Secure ID, please see here: certification.canonical.com
" [suite] whitelist_filter = "^client\-(cert|selftest).*" [submission] input_type = "regex" input_placeholder = "Secure ID (15 or 18 characters)" ok_btn_text = "Submit Results" submit_to_hexr = "true" [exporter] xml_export_path = "/tmp/submission.xml" [transport] submit_to = "certification" .ft P .fi .UNINDENT .UNINDENT .sp Graphical launchers are a bit more complicated, but essentially it\(aqs similar, what it allows is for you to define some parameters to customize your testing experience. .sp A very simple text\-mode launcher is canonical\-hw\-collection which just runs the basic hardware information tests and uploads them to a hardware database: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C [welcome] title = Gathering hardware information text = Gathering hardware information. You may be prompted for your password. This process will take approximately 30 seconds and you will be provided with a URL through which you can confirm and register your hardware submission. [suite] whitelist_filter = ^hwsubmit$ whitelist_selection = ^hwsubmit$ skip_whitelist_selection = True skip_test_selection = True [submission] # A bogus secure_id ensures we don\(aqt ask it # It can always be overridden in the .conf file. secure_id = 000 [transport] submit_to = certification submit_url = https://hardware\-server.example.com/ .ft P .fi .UNINDENT .UNINDENT .sp FInally, canonical\-driver\-test\-suite provides both a graphical and a text mode launcher, which are functionally equivalent: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C #!/usr/bin/checkbox\-gui [welcome] title = "Canonical Driver Test Suite" text = "Welcome to the Canonical Driver Test Suite.
This program contains automated and manual tests to help you discover issues that will arise when running your device drivers on Ubuntu.
This application will step the user through these tests in a predetermined order and automatically collect both system information as well as test results. It will also prompt the user for input when manual testing is required.
The run time for the tests is determined by which tests you decide to execute. The user will have the opportunity to customize the test run to accommodate the driver and the amount of time available for testing.
To begin, simply click the Continue button below and follow the onscreen instructions.
" [suite] whitelist_filter = "^ihv\-.*" [submission] ok_btn_text = "Save Results" input_type = "none" [exporter] xml_export_path = "" [transport] submit_to = "local" .ft P .fi .UNINDENT .UNINDENT .sp Text mode: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C #!/usr/bin/env checkbox\-launcher [welcome] text = Welcome to the Canonical Driver Test Suite This program contains automated and manual tests to help you discover issues that will arise when running your device drivers on Ubuntu. This application will step the user through these tests in a predetermined order and automatically collect both system information as well as test results. It will also prompt the user for input when manual testing is required. The run time for the tests is determined by which tests you decide to execute. The user will have the opportunity to customize the test run to accommodate the driver and the amount of time available for testing. To begin, simply click the Continue button below and follow the onscreen instructions. [suite] # Whitelist(s) displayed in the suite selection screen whitelist_filter = ^ihv\-.* # Whitelist_selection is mandatory so we set it to a bogus value so # no whitelists are preselected. whitelist_selection = bogus .ft P .fi .UNINDENT .UNINDENT .SH CHECKBOX RELEASE PROCESS .sp This page describes the necessary steps for releasing versions of Checkbox and Checkbox Certification to the stable PPA belonging to the Hardware Certification team, on a regular basis. Throughout this document the term \(aqCheckbox\(aq is used as a catch\-all term to cover all versions of Checkbox owned by the Hardware Certification team, currently Checkbox itself and the Checkbox Certification extensions. .SS Overview .sp Currently the process runs on a bi\-weekly cadence, with a new release of Checkbox every two weeks. This covers ten working days, and the tasks carried out on each day or group of days is described below: .INDENT 0.0 .IP \(bu 2 Days 1\-4: Time allowed for new changes to be introduced into trunk. .IP \(bu 2 Day 5: Changes are merged from the trunk of \fBlp:checkbox\fP and \fBlp:checkbox\-certification\fP to their respective release branches. The changelogs for both are \fIbumped\fP at this point and revisions are tagged. At this stage it may also be necessary to copy the package \(aqfwts\(aq from the \fI\%FWTS Stable PPA\fP <\fBhttps://launchpad.net/~firmware-testing-team/+archive/ppa-fwts-stable\fP> to the \fI\%Checkbox Release Testing PPA\fP <\fBhttps://launchpad.net/~checkbox-dev/+archive/testing\fP>\&. .IP \(bu 2 Days 6\-9: Testing is performed by the release manager for the Hardware Certification team, and a representative of the CE QA team (the main customer for Checkbox within Canonical) .IP \(bu 2 Day 9: A release meeting is held between the release manager for the Hardware Certification team and the representative of the CE QA team. Potential issues with the release are identified and plans made to address them. .IP \(bu 2 Day 10: The tested version of Checkbox is copied to the stable PPA. .UNINDENT .SS Launchpad Branches .sp The release process requires separate branches in Launchpad containing a semi\-frozen version of the code that was in trunk on day 5 of the process. This is so that development can continue on trunk without jeopardising the stability of the to\-be released version of Checkbox. The relationship between all branches involved in the process is as shown below: .INDENT 0.0 .IP \(bu 2 \fIlp:checkbox/release\fP <\- \fIlp:checkbox\fP .IP \(bu 2 \fIlp:checkbox\-certification/release\fP <\- \fIlp:checkbox\-certification\fP .IP \(bu 2 \fIlp:~checkbox\-dev/checkbox/checkbox\-packaging\-release\fP <\- \fIlp:~checkbox\-dev/checkbox/checkbox\-packaging\fP .UNINDENT .SS Auditing milestoned bugs .sp Prior to creating the release candidate the release manager should review the list of bugs milestoned for the next release of Checkbox. They should visit \fI\%checkbox milestones\fP <\fBhttps://launchpad.net/checkbox/+milestonesmilestones\fP> and locate the milestone dated with the release date. .INDENT 0.0 .IP \(bu 2 For bugs that are set to In Progress with a branch associated \- liase with the branch owner to see if the merge can be completed before the deadline. .IP \(bu 2 For bugs that are in any other non\-closed status (except \fIFix Commited\fP) \- re\-milestone them to the following milestone. .UNINDENT .SS Cutting the release .sp In order to cut the release, we have to merge the changes from trunk into the release branch, commit them with a suitable message and update the changelog in trunk so that future changes go under the correct version. For each combination of branches shown above, do the following (the example uses \fBlp:checkbox\fP and \fBlp:checkbox/release\fP): .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C bzr branch lp:checkbox/release checkbox\-release bzr branch lp:checkbox checkbox\-trunk cd checkbox\-release current_stable=\(gahead \-n1 $(find . \-name \(aqchangelog\(aq) | grep \-oP \(aq(?<=\e().*(?=\e))\(aq\(ga bzr merge lp:checkbox .ft P .fi .UNINDENT .UNINDENT .sp at this point if no changes (other than one to \fBdebian/changelog\fP) get merged in then we do not perform a release of the package in question. In practice this often happens with \fBcheckbox\-certification\fP but never with \fBcheckbox\fP: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C bzr commit \-m "Merged in changes from rev$(bzr revno \-r tag:$current_stable lp:checkbox) to rev$(bzr revno lp:checkbox) from lp:checkbox" bzr push lp:checkbox/release cd \(gafind . \-name \(aqdebian\(aq\(ga; cd .. bzr tag \(gahead \-n1 debian/changelog | grep \-oP \(aq(?<=\e().*(?=\e))\(aq\(ga dch \-r (save modified changelog) dch \-i \-U \(aqIncremented changelog\(aq debcommit bzr push lp:checkbox .ft P .fi .UNINDENT .UNINDENT .sp The last step in the process is to perform a build of the packages in the \fBppa:checkbox\-dev/testing PPA\fP\&. To do this we need to go to the recipe pages for the \fBcheckbox\fP and/or \fBcheckbox\-certification\fP release branches. .INDENT 0.0 .INDENT 3.5 .INDENT 0.0 .IP \(bu 2 \fI\%checkbox\-testing recipe\fP <\fBhttps://code.launchpad.net/~checkbox-dev/+recipe/checkbox-testing\fP> .IP \(bu 2 \fI\%checkbox\-certification\-testing recipe\fP <\fBhttps://code.launchpad.net/~checkbox-dev/+recipe/checkbox-certification-testing\fP> .UNINDENT .UNINDENT .UNINDENT .sp The \fBBuild Now\fP option should be available on the page. Click it to start a build. .SS Copying Firmware Test Suite to the Testing PPA .sp The Firmware Test Suite tool is a test tool for system firmware that is naturally heavily utilised by Checkbox. To make sure the latest version which contains fixes and new tests/features needed by Checkbox is available and also doesn\(aqt break anything in Checkbox, we need to release it alongside Checkbox. After cutting the release if the Firmware Testing team have notified that a new version is available and that this version should be used for certification, we need to copy it to the Testing PPA. To do this we need to go to the \fI\%Copy packages view of the Firmware Test Suite (Stable) PPA\fP <\fBhttps://launchpad.net/~firmware-testing-team/+archive/ppa-fwts-stable/+copy-packages\fP> and select the \(aqfwts\(aq packages for all releases back to Precise. We need to set the \(aqDestination PPA\(aq as \(aqCheckbox Release Testing [~checkbox\-dev/testing]\(aq and the \(aqCopy options\(aq field to \(aqCopy existing binaries\(aq, then click \(aqCopy packages\(aq. This step then needs to be repeated but set the \(aqDestination PPA\(aq field to \(aqPPA for Checkbox Developers [~checkbox\-dev/ppa]\(aq. .SS Next Release of Checkbox e\-mail .sp So that everyone has the opportunity to perform whatever testing is required in a timely manner, after the PPA builds have been completed an email should be sent to the following mailing lists: .INDENT 0.0 .IP \(bu 2 \fI\%hardware\-certification\-team@lists.canonical.com\fP <\fBhardware-certification-team@lists.canonical.com\fP> .IP \(bu 2 \fI\%commercial\-engineering@lists.canonical.com\fP <\fBcommercial-engineering@lists.canonical.com\fP> .UNINDENT .sp The content is typically something like this: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C Subject: Next Release of Checkbox (18/11/2013) Hi, The next release of Checkbox is available in the https://code.launchpad.net/~checkbox\-dev/+archive/testing PPA. Please test it at your convenience. Checkbox is based on revision 2484 of lp:checkbox and Checkbox Certification is based on revision 586 of lp:checkbox\-certification. Thanks, .ft P .fi .UNINDENT .UNINDENT .sp If one or the other of Checkbox and Checkbox Certification have not been updated then there is no need to mention that package .SS Testing the release .sp Now that the release has been cut, testing should take place prior to the release meeting. From the point of view of the certification team, what needs to be tested is \fBcheckbox\-certification\-client\fP and \fBcheckbox\-certification\-server\fP which form the basis for CE QAs OEM specific versions of Checkbox. Checkbox certification server is tested in the CI loop Checkbox certification client needs to be tested manually. .SS Release Meeting .sp On the Thursday before the release is made, a meeting is held between a representative of the Certification team and a representative of the \fBCommercial Engineering QA\fP team. The meeting is held at 7:30 UTC as shown in this \fI\%calendar invite\fP <\fBhttps://www.google.com/calendar/hosted/canonical.com/event?action=TEMPLATE&tmeid=Y3QxcWVla3ViMTRvMXByOHZlOTFvc283Y2NfMjAxMzA4MjlUMDczMDAwWiBicmVuZGFuLmRvbmVnYW5AY2Fub25pY2FsLmNvbQ&tmsrc=brendan.donegan%40canonical.com\fP>\&. An agenda for the meeting is included in the invite. .SS Publishing the release .sp To publish the release we simply need to copy a number of packages from the \fI\%Checkbox Release Testing PPA\fP <\fBhttps://launchpad.net/~checkbox-dev/+archive/testing\fP> to the \fI\%Hardware Certification Public PPA\fP <\fBhttps://launchpad.net/~hardware-certification/+archive/public\fP>\&. To do this we go to the \fI\%Copy packages view of the Checkbox Release Testing PPA\fP <\fBhttps://launchpad.net/~checkbox-dev/+archive/testing/+copy-packages\fP> and select all versions of the following list of packages: \fBcheckbox, checkbox\-certification, fwts\fP\&. Make sure that the \(aqDestination PPA\(aq field is set to \(aqPublic PPA for Hardware Certification [~hardware\-certification/public]\(aq and that the \(aqCopy options\(aq field is set to \(aqCopy existing binaries\(aq, then click \(aqCopy Packages\(aq. .sp After that is done an announcement email should be sent to \fI\%commercial\-engineering@lists.canonical.com\fP <\fBcommercial-engineering@lists.canonical.com\fP>\&. A template for the announcement in included below: .INDENT 0.0 .INDENT 3.5 .sp .nf .ft C Hi, A new release of checkbox has been uploaded to the Hardware Certification Public PPA (https://launchpad.net/~hardware\-certification/+archive/public). The release is based on revision 2294 of lp:checkbox Thanks, .ft P .fi .UNINDENT .UNINDENT .sp Please attach the most recent part of the changelog as release notes .INDENT 0.0 .IP \(bu 2 genindex .IP \(bu 2 modindex .IP \(bu 2 search .UNINDENT .SH AUTHOR Zygmunt Krynicki .SH COPYRIGHT 2013-2014, Zygmunt Krynicki .\" Generated by docutils manpage writer. .