providers:certification-client: removed fwts_test and log attachment from 14.04 client whitelists
providers:checkbox: Added fwts_desktop_diagnosis job.

A log attachment job was also added.

Jobs added to relevant whitelists in providers:certification-client
providers:checkbox: Added cpu cstates job.

A log attachment job was also added.

Jobs added to relevant whitelists in providers:certification-client
providers:certification-client: removed s3/s4 log checking jobs.

The logs themselves are still attached.
providers:checkbox: Added fwts oops test.

Added the test to certification desktop whitelists.
providers:certification-client: added wakealarm and uefirtvariable tests to whitelist

Tests are generated by a local fwts and fwts_logs jobs, these were also
added to the whitelist.
"Added some firmware-related test definitions and whitelist items to certification lists.

8f54fbe providers:certification-client: added wakealarm and uefirtvariable tests to whitelist
0951d74 providers:checkbox: Added fwts oops test.
307ef99 providers:certification-client: removed s3/s4 log checking jobs.
f021cc7 providers:checkbox: Added cpu cstates job.
6a0fe4c providers:checkbox: Added fwts_desktop_diagnosis job.
ed5cbb2 providers:certification-client: removed fwts_test and log attachment from 14.04 client  [r=brendan-donegan][bug=1306468][author=roadmr]"
checkbox-ng:dbus: SelectJobs sees all session jobs

This patch changes how ServiceWrapper.SelectJobs() operates. Previously
it would look at all providers and select among any of the jobs defined
there. The problem is that that would never consider generated jobs
(children of local jobs that are not acting as a pure category
assignment).

This patch fixes that problem in a slightly hacky way. Since
SelectJobs() is defined on the service object (ideally it would have
been defined on the session object) and the whole DBus API cannot
support more than one session without breaking the API we can cheat and
peek at the full list of jobs as seen through the first (only) existing
session that the service object knows about. If the session does not
exist yet we just do what we did before, match among all the provider
jobs.

Fixes: https://bugs.launchpad.net/checkbox-ng/+bug/1309128

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
plainbox:highlevel: track sessions created by Service.create_session()

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
"automatic merge by tarmac [r=brendan-donegan][bug=1309128][author=zkrynicki]"
providers:checkbox: renamed resolution-change generator job to comply with new convention
mk-venv: add support for Utopic Unicorn

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
"automatic merge by tarmac [r=roadmr][bug=][author=zkrynicki]"
checkbox-support:parsers:test_udevadm: Added expectations and data for Vostro 270.

Interesting because it has an Intel 0152 graphics adapter which the
parser doesn't recognize as VIDEO.

This is apparently because of how it uses the PCI class attribute with a
previously-uninteresting value of 0x80.
checkbox-support:lib:pci: Added a constant with Intel vendor PCI ID
checkbox-support:parsers:udevadm: Updated heuristic for some VIDEO devices.

Usually a video device has a PCI subclass_id of Pci.CLASS_DISPLAY_VGA or
Pci.CLASS_DISPLAY_3d. However, some manufacturers which hadn't
previously used a subclass_id of Pci.CLASS_DISPLAY_OTHER (0x80 or
decimal 128) have begun to do so (as of 2013-2014); and others which
previously used this class for uninteresting devices are now using it
for actual video devices.

Previously we identified AMD as doing this, and added a simple heuristic
to accomodate that; on a few newer systems, Intel has also started using
the OTHER display class, but erratically. This code implements a more
versatile heuristic we can expand if/when we find other vendors/devices
that break our old expectations.

A previous commit added a test and data file to confirm that things
behave as expected, and also that none of the other tests break,
indicating that this change doesn't cause old systems to "sprout" new
VIDEO devices on account of faulty heuristics.
"05797dd checkbox-support:parsers:udevadm: Updated heuristic for some VIDEO devices.
5a2fb13 checkbox-support:lib:pci: Added a constant with Intel vendor PCI ID
6ef10c0 checkbox-support:parsers:test_udevadm: Added expectations and data for Vostro 270.

    Usually a video device has a PCI subclass_id of Pci.CLASS_DISPLAY_VGA or
    Pci.CLASS_DISPLAY_3d. However, some manufacturers which hadn't
    previously used a subclass_id of Pci.CLASS_DISPLAY_OTHER (0x80 or
    decimal 128) have begun to do so (as of 2013-2014); and others which
    previously used this class for uninteresting devices are now using it
    for actual video devices.
    
    Previously we identified AMD as doing this, and added a simple heuristic
    to accomodate that; on a few newer systems, Intel has also started using
    the OTHER display class, but erratically. This code implements a more
    versatile heuristic we can expand if/when we find other vendors/devices
    that break our old expectations.
    
    A previous commit added a test and data file to confirm that things
    behave as expected, and also that none of the other tests break,
    indicating that this change doesn't cause old systems to "sprout" new
    VIDEO devices on account of faulty heuristics.
 [r=zkrynicki][bug=1312736][author=roadmr]"
providers:checkbox: converted resolution job (default resolution)
providers:checkbox: converted screen-resolution
providers:checkbox: converted minimum_resolution