Provided by: checkbox-ng_0.23-2_all bug


       checkbox_ng - CheckboxNG Documentation

       CheckboxNG  is a hardware testing tool useful for certifying laptops, desktops and servers
       with Ubuntu. It is a new version of Checkbox that is built directly on top of PlainBox

       CheckboxNG replaces Checkbox, where applicable.

          Documentation is under development. Some  things  are  wrong,  inaccurate  or  describe
          development goals rather than current state.


       CheckboxNG  can be installed from a PPA (recommended) or pypi on Ubuntu Precise (12.04) or

          $ sudo add-apt-repository ppa:checkbox-dev/ppa && sudo apt-get update && sudo apt-get install checkbox-ng


       CheckboxNG has special support for running stable release updates tests  in  an  automated
       manner.  This  runs  all  the  jobs  from  the  sru.whitelist and sends the results to the
       certification website.

       To run SRU tests you will need to know the so-called Secure  ID  of  the  device  you  are
       testing. Once you know that all you need to do is run:

          $ checkbox sru $secure_id submission.xml

       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.


       To report bugs on the Checkbox project you will need a launchpad  account.  You  may  find
       instructions  on  how  to  create  one <>
       useful. Once you have an account you can report bugs <

       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't know Checkbox internals that much or are in doubt  just  file  it  on  the  base
       'Checkbox'       project       (you       can       use       this       direct       link
       <>.) 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.


       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  Launchpad  project  group

   Architecture Diagram
       [image: Architecture Diagram] [image]

       This  diagram  contains  a  high-level approximation of the current Checkbox architecture.
       There are three main "pillars". On the left we have end products. Those are  actual  tools
       that certification and engineers are using.  On the right we have the test market. 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.

       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.

       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

       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 and of providers. As an added complexity the library needs to be  called
       from python3 code and python2 code.

          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.

          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.

   Component Descriptions
     │Project                  │ Responsible for                         │ Type                     │
     │Next Generation Checkbox │                                         │ Application              │
     │(GUI)                    │        • The     C++/QML                │                          │
     │                         │          user interface                 │                          │
     │                         │                                         │                          │
     │                         │        • The   graphical                │                          │
     │                         │          launcher    for                │                          │
     │                         │          providers, e.g.                │                          │
     │                         │          checkbox-certification-client  │                          │
     │Next Generation Checkbox │                                         │ Application              │
     │(CLI)                    │        • The    python    command-line  │                          │
     │                         │          interface                      │                          │
     │                         │                                         │                          │
     │                         │          • the text user interface      │                          │
     │                         │                                         │                          │
     │                         │          • the SRU testing command      │                          │
     │                         │                                         │                          │
     │                         │        • Additional certification APIs  │                          │
     │                         │                                         │                          │
     │                         │          • sending data to Launchpad    │                          │
     │                         │                                         │                          │
     │                         │          • sending data to HEXR         │                          │
     │                         │                                         │                          │
     │                         │        • the  DBus  service  needed by  │                          │
     │                         │          GUI                            │                          │

     │Client     Certification │                                         │ Provider                 │
     │Provider                 │        • canonical-certification-client │                          │
     │                         │          executable                     │                          │
     │                         │                                         │                          │
     │                         │        • client          certification  │                          │
     │                         │          whitelists                     │                          │
     │Server     Certification │                                         │ Provider                 │
     │Provider                 │        • server           certification │                          │
     │                         │          whitelists                     │                          │
     │                         │                                         │                          │
     │                         │        • additional server whitelists   │                          │
     │System-on-Chip    Server │                                         │ Provider                 │
     │Certification Provider   │        • SoC    server    certification │                          │
     │                         │          whitelists                     │                          │
     │Checkbox Provider        │                                         │ Provider                 │
     │                         │        • Almost all job definitions     │                          │
     │                         │                                         │                          │
     │                         │        • Most of custom "scripts"       │                          │
     │                         │                                         │                          │
     │                         │        • Default and SRU whitelist      │                          │
     │Resource Provider        │                                         │ Provider                 │
     │                         │        • Almost all resource jobs       │                          │
     │                         │                                         │                          │
     │                         │        • Almost all resource "scripts"  │                          │
     │Checkbox Support         │                                         │ Library                  │
     │                         │        • Support   code   for   various │                          │
     │                         │          providers                      │                          │
     │                         │                                         │                          │
     │                         │        • Parsers for many text formats  │                          │
     │PlainBox                 │                                         │ Library  and Development │
     │                         │        • Almost all core logic          │ Toolkit                  │
     │                         │                                         │                          │
     │                         │          • RFC822   (job    definition) │                          │
     │                         │            parser                       │                          │
     │                         │                                         │                          │
     │                         │          • Configuration handling       │                          │
     │                         │                                         │                          │
     │                         │          • Testing              session │                          │
     │                         │            (suspend/resume)             │                          │
     │                         │                                         │                          │
     │                         │          • Job runner                   │                          │
     │                         │                                         │                          │
     │                         │          • Trusted launcher             │                          │
     │                         │                                         │                          │
     │                         │          • Dependency resolver          │                          │
     │                         │                                         │                          │
     │                         │          • Command line handling        │                          │
     │                         │                                         │                          │
     │                         │          • The  XML,  HTML   and   XSLX │                          │
     │                         │            exporters                    │                          │
     │                         │                                         │                          │
     │                         │          • and more...                  │                          │
     │                         │                                         │                          │
     │                         │        • Provider development toolkit   │                          │
     │                         │                                         │                          │
     │                         │          • 'plainbox startprovider'     │                          │
     │                         │                                         │                          │
     │                         │          • '' implementation   │                          │

     │Legacy   Checkbox    (no │                                         │ Monolithic   Application │
     │longer maintained)       │        • Applications                   │ Library and Data         │
     │                         │                                         │                          │
     │                         │          • Qt4 GUI                      │                          │
     │                         │                                         │                          │
     │                         │          • Gtk2 GUI                     │                          │
     │                         │                                         │                          │
     │                         │          • Urwid (text) GUI             │                          │
     │                         │                                         │                          │
     │                         │        • Core                           │                          │
     │                         │                                         │                          │
     │                         │          • Plugin  and  Event / Message │                          │
     │                         │            Engine                       │                          │
     │                         │                                         │                          │
     │                         │          • Almost     Every     feature │                          │
     │                         │            implemented a core plugin    │                          │
     │                         │                                         │                          │
     │                         │        • Data                           │                          │
     │                         │                                         │                          │
     │                         │          • Jobs and whitelists          │                          │


          This changelog contains only a summary of changes. For a more  accurate  accounting  of
          development history please inspect the source history directly.

   CheckboxNG 0.23 (unreleased)
       • Bugfixes:

   CheckboxNG 0.22
       • Bugfixes:

   CheckboxNG 0.3
       • Bugfixes:

   CheckboxNG 0.2
       • Bugfixes:

   CheckboxNG 0.1
       • Initial release

       • Support for displaying configuration

       • Support for running SRU tests (automatic regression testing)


       Test 'scripts' are small programs which are used to aid in implementing tests.

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


       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.

       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.

       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 tutorial on how to
       create launchers and their relationship with legacy Checkbox.

       As checkbox-gui is a Qt application, settings must  follow  the  INI-style  rules  of  the
       QSettings <> class.

       Multiple-line  values are supported but must be enclosed in doubles quotes and extra lines
       must start with one space, e.g:

          key = "Hello

       • From QML:


       • From C++:


       Conversely,  checkbox-launcher-specific  launchers   must   follow   Python   ConfigParser
       <> syntax.

       Also,  some settings only make sense for either GUI or CLI, and are thus not understood by
       the other. These are noted below.

   Supported Settings
              QML application title and welcome screen header. Defaults to System Testing.

              Welcome message to display on the first screen  (checkbox-gui  supports  Rich  text
              allowing HTML-style markup). Defaults to <p>Welcome to System Testing.</p> [...]

              Regular  expression  to  match  a subset of whitelist filenames. On checkbox-gui it
              defaults to .*. For checkbox-launcher it has no default and must be defined.

              Pattern that whitelists need to match to be preselected. Python regular expression.
              It has no default and must be defined.  (CLI only)

              If  set  to true, user will not receive a choice of whitelist. Only the preselected
              ones (see whitelist_selection) will be selected.  (CLI only).

              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)

              Header  text  of  the  submission  pop-up  , shown to the user after submission has
              completed. (GUI only)

              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 none value. To validate using a regex,
              must be regex.  (GUI only)

              Regular expression to validate input in submission field (e.g.   email,  secure_id)
              if input_type is regex. (GUI only).  RegExpValidator, default .*

              Temporary  text  to  put  in input field, used to guide the user.  Launchpad E-Mail
              Address (default) or Secure ID (15 or 18 characters). (GUI only)

              Preconfigured secure_id to fill in the text field.

              The label for the "Send" button. Submit Results (default)  or  Save  Results.  (GUI

              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)

              Boolean,  add  an  extra  header  to  also send the results to HEXR (works with the
              certification transport)

              Location to save the XML submission file, if set to an empty  string  will  open  a
              file save dialog. Default: /tmp/submission.xml (GUI only)

              Transport  endpoint.  Defaults  to <none>.  Supports submission to LP (the default,
              value launchpad), certification, or local (save to disk)

              URL to submit results to. This allows to upload to different websites, for  example
              it  can  upload  directly  to  hexr,  or  to  the staging sites. Used only with the
              certification submit_to value.

              Name of a custom config file to load.  Config  files  are  mainly  used  to  define
              environment variables. (CLI only)

              If  set,  resources,  local  jobs  and  attachments  will be output to screen, this
              generates a lot of text and is mainly for debugging.  (CLI only)


       This document provides an explanation of why launchers are necessary, what you can achieve
       with  them,  and  goes  over several examples to better describe their capabilities. For a
       detailed reference on which settings are supported by launchers, and specific  syntax  for
       launcher files, look at /profiles.

   Legacy checkbox behavior control
       In the past, Checkbox's behavior was controlled by three mechanisms.

       First,  the  functions of checkbox could be augmented by adding plugins.  For example, the
       ability to submit to certification website was added by the checkbox-certification package
       using  a plugin. The plugins included by checkbox-certification and which add new behavior
       to base checkbox were:


       These added the way to prompt the user for  submission-specific  data,  generate  the  xml
       report, and other functions.

       Next,  the  behaviors of the plugins could be configured or controlled using configuration
       files, which are "cascaded". A config file can  include  others  and  those  can  in  turn
       include others.

       This  is  an example of a project-specific project-qt.ini main config file. It's the first
       file read when the project-specific client is launched. Some settings are abbreviated:

          includes = %(checkbox_oem_share)s/configs/checkbox-project-base-qt.ini %(checkbox_project_share)s/configs/checkbox-project-base.ini

          repositories = deb http://.*\(archive\|security\) precise-security
          routers = multiple
          server_iperf =
          sources_list = /etc/apt/sources.list
          wpa_n_psk = password
          wpa_n_ssid = access-point

          title = My project System Testing

       Notice  the  includes  line,  this  instructs   it   to   load   the   config   file   for
       checkbox-project-base-qt  and  checkbox-project-base.  Checkbox-project-base-qt  loads the
       configs for checkbox-certification and checkbox-project.  Settings  are  cascaded  so  the
       config options near the top override the ones near the bottom.

       Finally, the "binary" used to invoke checkbox is a shell script that defines where to find
       the things checkbox needs to run: you can  define  a  share  directory,  a  specific  data
       directory,  point  to  a configuration file and define some environment variables that you
       may need during testing. Here's an example for checkbox-project-qt:

          export CHECKBOX_DATA=${CHECKBOX_DATA:-~/.checkbox}
          export CHECKBOX_SHARE=${CHECKBOX_SHARE:-/usr/share/checkbox}
          export CHECKBOX_OPTIONS=${CHECKBOX_OPTIONS:---log-level=debug --log=$CHECKBOX_DATA/checkbox-project.log}
          export CHECKBOX_CERTIFICATION_SHARE=${CHECKBOX_CERTIFICATION_SHARE:-/usr/share/checkbox-certification}
          export CHECKBOX_OEM_SHARE=${CHECKBOX_PROJECT_BASE_SHARE:-/usr/share/checkbox-project-base}
          export CHECKBOX_PROJECT_SHARE=${CHECKBOX_PROJECT_SHARE:-/usr/share/checkbox-project}

          # Convenience for defining the PYTHONPATH directory.
          if [ "$CHECKBOX_SHARE" != "/usr/share/checkbox" ]; then

          python3 $CHECKBOX_SHARE/run "$@" $CHECKBOX_PROJECT_SHARE/configs/$(basename $0).ini

       Here you can see that it defines some locations and an important part is the final python3
       line, where it will locate and use the required .ini config file we saw earlier.

       This  hierarchical  organization  was  very powerful but was also difficult to handle, and
       also had some limitations. Part of the work we did with checkbox was to integrate all  the
       project-specific  plugins into checkbox trunk, this way all the core code is in one place,
       and the project-specific variants only supply jobs, whitelists,  data  and  configuration,
       without adding new behavior.

   New plainbox behavior control
       Unlike  checkbox,  plainbox's  core  is monolythic, and it has no concept of plugins. This
       makes it easier to understand and work with. The plainbox core has implementations for all
       the  functions in the old checkbox packages, so no additions are necessary to use features
       such as submission to certification or report generation.

       What we call plainbox is the library that implements all the functionality, as can be seen

       Plainbox  provides  tools  to  help  test  developers  write and package tests.  These are
       delivered in "providers", which are entities designed to  encapsulate  test  descriptions,
       custom  scripts  for  testing,  whitelists  and assorted data. They were designed to allow
       teams to write and deliver  their  custom  tests  without  worrying  too  much  about  the
       underlying plainbox code.

       To get information on how to write tests and providers, see the Provider Tutorial

       However,  when  actually  using  these tests to verify a real system, we wanted to provide
       something easier and closer to the user experience of checkbox. We  created  two  clients,
       checkbox-gui  and  checkbox-cli,  which  had some hardcoded behaviors, and we also started
       creating other clients which were based on these but were purpose specific. For  instance,
       we had a version of checkbox for SRU testing, another for server certification, and so on.

       But  then  we realized that a lot of the code was duplicated and the behaviors were common
       except for a few changes. So we came  up  with  the  concept  of  "launchers",  which  are
       somewhat similar to checkbox's configuration files and shell script launchers.

       The  idea is that checkbox-gui and checkbox-cli have some very basic behaviors, since they
       are the clients that are shipped by default with ubuntu. They can show all  the  available
       whitelists,  show  a  predefined welcome message, and at the end will let the user see the
       html report and submit it to launchpad using their e-mail address, similar to the  version
       of checkbox that shipped with Ubuntu.

       Instead  of using complicated command line switches, launchers allow you to configure some
       optional behaviors to customize your testing experience. A launcher contains settings, and
       is  similar  to  a  shell  script,  but  the  interpreter  will  be either checkbox-gui or

       Here are a few examples of what can be done with launchers.

       As a surprise, checkbox-cli is itself a launcher:

          #!/usr/bin/env checkbox-launcher
          text = Welcome to System Testing!
              Checkbox provides tests to confirm that your system is working properly.
              Once you are finished running the tests, you can view a summary report for
              your system.
              Warning: Some tests could cause your system to freeze or become
              unresponsive. Please save all your work and close all other running
              applications before beginning the testing process.

          whitelist_filter = ^default$
          whitelist_selection = ^default$
          skip_whitelist_selection = True

          submit_to = launchpad

       You can see here we customize a few options: it shows  a  welcome  message,  automatically
       selects the default whitelist, and will submit to launchpad when it's finished.

       A graphical launcher example is canonical-certification-client.


          title = "System Certification"
          text = "<p>Welcome to System Certification!</p><p></p><p>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.</p><p></p><p> To learn how to create or locate the Secure ID,
          please see here: <a href=\"\"></a></p><p></p>"

          whitelist_filter = "^client-(cert|selftest).*"

          input_type = "regex"
          input_placeholder = "Secure ID (15 or 18 characters)"
          ok_btn_text = "Submit Results"
          submit_to_hexr = "true"

          xml_export_path = "/tmp/submission.xml"

          submit_to = "certification"

       Graphical  launchers  are  a  bit  more complicated, but essentially it's similar, what it
       allows is for you to define some parameters to customize your testing experience.

       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:

          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

          whitelist_filter = ^hwsubmit$
          whitelist_selection = ^hwsubmit$
          skip_whitelist_selection = True
          skip_test_selection = True

          # A bogus secure_id ensures we don't ask it
          # It can always be overridden in the .conf file.
          secure_id = 000

          submit_to = certification
          submit_url =

       FInally,  canonical-driver-test-suite  provides both a graphical and a text mode launcher,
       which are functionally equivalent:


          title = "Canonical Driver Test Suite"
          text = "<p>Welcome to the Canonical Driver Test Suite.</p>
           <p>This program contains automated and manual tests to help you discover
           issues that will arise when running your device drivers on Ubuntu.</p>
           <p>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.</p>
           <p>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.</p>
           <p>To begin, simply click the Continue button below and follow the onscreen

          whitelist_filter = "^ihv-.*"

          ok_btn_text = "Save Results"
          input_type = "none"

          xml_export_path = ""

          submit_to = "local"

       Text mode:

          #!/usr/bin/env checkbox-launcher
          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

          # 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


       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 'Checkbox' 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.

       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:

       • Days 1-4: Time allowed for new changes to be introduced into trunk.

       • Day 5: Changes are merged from the trunk of lp:checkbox and lp:checkbox-certification to
         their respective release branches.  The changelogs for both are bumped at this point and
         revisions are tagged.  At this stage it may also be necessary to copy the package 'fwts'
         from  the  FWTS  Stable  PPA <
         fwts-stable> to  the  Checkbox  Release  Testing  PPA  <

       • 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

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

       • Day 10: The tested version of Checkbox is copied to the stable PPA.

   Launchpad Branches
       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:

       • lp:checkbox/release <- lp:checkboxlp:checkbox-certification/release <- lp:checkbox-certificationlp:~checkbox-dev/checkbox/checkbox-packaging-release                                  <-

   Auditing milestoned bugs
       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  checkbox  milestones
       <> and locate the milestone dated with
       the release date.

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

       • For  bugs  that  are in any other non-closed status (except Fix Commited) - re-milestone
         them to the following milestone.

   Cutting the release
       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 lp:checkbox and lp:checkbox/release):

          bzr branch lp:checkbox/release checkbox-release
          bzr branch lp:checkbox checkbox-trunk
          cd checkbox-release
          current_stable=`head -n1 $(find . -name 'changelog') | grep -oP '(?<=\().*(?=\))'`
          bzr merge lp:checkbox

       at  this point if no changes (other than one to debian/changelog) get merged in then we do
       not perform a release of the package in question. In  practice  this  often  happens  with
       checkbox-certification but never with checkbox:

          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 `find . -name 'debian'`; cd ..
          bzr tag `head -n1 debian/changelog | grep -oP '(?<=\().*(?=\))'`
          dch -r (save modified changelog)
          dch -i -U 'Incremented changelog'
          bzr push lp:checkbox

       The   last   step  in  the  process  is  to  perform  a  build  of  the  packages  in  the
       ppa:checkbox-dev/testing PPA. To do this we need  to  go  to  the  recipe  pages  for  the
       checkbox and/or checkbox-certification release branches.

          • checkbox-testing  recipe  <

          • checkbox-certification-testing     recipe      <

       The Build Now option should be available on the page. Click it to start a build.

   Copying Firmware Test Suite to the Testing PPA
       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't  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  Copy  packages  view  of  the  Firmware  Test  Suite  (Stable)  PPA
       <> and
       select  the  'fwts'  packages  for  all  releases  back  to  Precise.  We  need to set the
       'Destination PPA' as 'Checkbox Release  Testing  [~checkbox-dev/testing]'  and  the  'Copy
       options'  field  to  'Copy  existing binaries', then click 'Copy packages'. This step then
       needs to be repeated but set the 'Destination PPA' field to 'PPA for  Checkbox  Developers

   Next Release of Checkbox e-mail
       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:

       •                 <hardware-certification->

       • <>

       The content is typically something like this:

          Subject: Next Release of Checkbox (18/11/2013)


          The next release of Checkbox is available in the
          Please test it at your convenience. Checkbox is based on revision 2484 of
          lp:checkbox and Checkbox Certification is based on revision 586 of


       If one or the other of Checkbox and Checkbox Certification  have  not  been  updated  then
       there is no need to mention that package

   Testing the release
       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
       checkbox-certification-client  and  checkbox-certification-server 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.

   Release Meeting
       On  the Thursday before the release is made, a meeting is held between a representative of
       the Certification team and a representative of the Commercial  Engineering  QA  team.  The
       meeting    is    held    at    7:30    UTC    as    shown    in   this   calendar   invite
       An agenda for the meeting is included in the invite.

   Publishing the release
       To  publish  the  release  we  simply  need to copy a number of packages from the Checkbox
       Release Testing PPA <> to the Hardware
       Certification  Public PPA <>.
       To do this we  go  to  the  Copy  packages  view  of  the  Checkbox  Release  Testing  PPA
       <>   and   select   all
       versions of the following list of packages: checkbox, checkbox-certification,  fwts.  Make
       sure  that  the  'Destination  PPA' field is set to 'Public PPA for Hardware Certification
       [~hardware-certification/public]' and that the  'Copy  options'  field  is  set  to  'Copy
       existing binaries', then click 'Copy Packages'.

       After     that     is    done    an    announcement    email    should    be    sent    to   <>.
       A template for the announcement in included below:


          A new release of checkbox has been uploaded to the Hardware
          Certification Public PPA
          ( The
          release is based on revision 2294 of lp:checkbox


       Please attach the most recent part of the changelog as release notes

       • genindex

       • modindex

       • search


       Zygmunt Krynicki


       2013-2014, Zygmunt Krynicki