MeeGo wiki - User contributions [en]

Quality/Compliance tools

2011-06-06T22:46:40Z

Mwichmann: /* Result Format */

= Introduction =

The compliance tools are used to check distributions using the MeeGo software stack, and applications targeting such distributions, for compliance with the MeeGo requirements. Checking is done against reference information which tells the tools what is mandatory.

For MeeGo distribution compliance checking, the candidate distribution needs to supply an image of the distribution in suitable format, which will include source rpm packages. The other input to the tool is an official MeeGo reference image (which also includes source packages), and a list of the mandatory packages.

For application compliance checking, the candidate rpm package is supplied as input. Other inputs are an official MeeGo reference image (this one does not include sources), which will be used to test that installation actually works, as well as a list of packages and a list of packages that make up the MeeGo API. The latter two are used to determine valid dependencies and to perform a check of whether the application is a MeeGo API application or one that uses different/additional libaries.

The tools will generate report files (in HTML currently) to show the result.

= Installation =
The compliance tools can be installed using released rpm and deb packages (available for a variety of distrubutions), or installed from source code if using an unsupported distribution.

== Packages and Repos ==

The code lives in the MeeGo git repository, and will be built by the OBS for all the supported distributions automatically. The home for this is
[http://build.meego.com/package/show?package=meego-compliance-tools&project=devel:tools:building devel:tools:building/meego-compliance-tools].

The following Linux distributions are supported at the moment by OBS (this is a changing list, check the repositories which may be more up to date than this page):

* Debian 5.0
* xUbuntu 9.10, 10.04, 10.10
* Fedora 11, 12, 13, 14
* openSUSE 11.1, 11.2, 11.3, 11.4
* MeeGo 1.0, 1.1, Trunk (1.2)

The packages appear in the tools repository at [http://repo.meego.com/MeeGo/tools/repos/ tools/repos]. rpm-based distributions have usable .repo files in each distribution directory which can be used by zypper or yum, but the deb-based distributions do not; the sources.list.d entry needs to be constructed from the path. For example, for Ubuntu 10.10 the following in /etc/apt/sources.list.d/meego-tools.list:
deb http://repo/meego.com/MeeGo/tools/repos/ubuntu/10.10/ ./

For distros which use rpms natively, there are three packages available:
* meego-compliance-tools (common data, will be installed automatically as the dependency of the two packages below)
* meego-dist-compliance-tools (for MeeGo distro compliance checking)
* meego-app-compliance-tools. (for MeeGo application compliance checking)

For distros which use debs natively, only the meego-compliance-tools package is needed.

== Source Code ==
The tools can also be installed from source (which is all Python). After fetching the code, under the code directory, run:
$ [sudo] make install

The source code is hosted at:
[http://meego.gitorious.org/meego-developer-tools/meego-compliance-tools meego-compliance-tools@gitorious.org]

A typical fetch would be:
git clone git://gitorious.org/meego-developer-tools/meego-compliance-tools.git

== Compliance Image Preparation ==

To prepare the images used in compliance tools, you need [[Image_Creation|MIC2]] with new features (version 0.22.0 or later). The mic2 package from the same tools repository described above will provide a current version.

= Features =
== dist-compliance-tool ==
Executes compliance checking for distributions build from the MeeGo code base. The following features are supported:
* Binary package comparison:
** Exist in target image?
** Version matches the requirement?
*** flexible version checking: support rules with comparison operators like ">=" in core package list (kernel >= 2.6.35)
* Content in source rpm comparison:
** This step will be skipped if binary rpm checking fails
** Spec filename
** Spec content
** Sources and md5sum
** Patches and the content

* File checking:
** Exist in target image
*** For example check /usr/lib/libGLES2.so.1 if exists in target image or not.

== app-compliance-tool ==
For compliance checking for MeeGo applications, the following features are supported:
* check if all dependent packages exist in core package list
* check if the target package can be installed in the minimal image
* verify the installation location of the application
* verify the minimal requirement of the desktop file and icon for the application

= Usage =
== Image Preparation ==
Before using the tools, the reference image needs to be created by using MIC2 (version 0.22.0 or later):
$ [sudo] mic-image-creator --run-mode=0 --cache=mycachedir --format=fs --config=<ks file> --package=tar.bz2 --include-source
The sample ks file is at /usr/share/compliance-tools/share dir after installation or can be downloaded at:
Meego-1.1:[[media:Meego-minimal-compliance-1.0.99.1.ks|MeeGo-minimal-compliance-1.0.99.1.ks]]
Meego-1.2:[[media:MeeGo-minimal-compliance-1.1.99.7.ks|MeeGo-minimal-compliance-1.1.99.7.ks]]
The sample core list file is at /usr/share/compliance-tools/share dir after installation or can be downloaded at:
Meego-1.1:[[media:Core-list-1.0.99.1‎|Core-list-1.0.99.1]]
Meego-1.2:[[media:Meego-full-compliance-pkg-1.2.txt|Core-list-1.1.99.7]]
And the ks file and core list should be synced with and conform to the latest [[Quality/Compliance|MeeGo compliance spec]].

For application compliance checking, the source packages are not needed, so the --include-source option can be omitted.

In future, official pre-made images will be available, when this occurs the appropriate image should be downloaded instead of constructed.

To use the dist compliance check tool (dist_compliance), the needed target image can also be generated by mic2 using the above options. But the target images
will not be limited to this specific format (fs in tar.bz2). If the exist target image is in other formats, please unpack it to a directory manually using format
specific instructions and use this directory as the command line input.

== Devices Compliance Check ==
The command "dist_compliance" is for checking compliance of MeeGo devices, or distributions.

Usage: [sudo] dist_compliance [options]
Options:
--version show program's version number and exit
-h, --help show this help message and exit
-c CORELIST, --corelist=CORELIST
File containing MeeGo Core package list
-r REF, --reference=REF
Path to reference image or unpacked directory
-t TGT, --target=TGT Path to target image or unpacked directory
-o OUTDIR, --outdir=OUTDIR
Output directory of report
-d, --debug Save intermediate log data for debugging

== Apps Compliance Check ==
The command "app_compliance" is for applications compliance checking.

Usage: [sudo] app_compliance [options] <app-rpm>
Options:
--version show program's version number and exit
-h, --help show this help message and exit
-r REFIMAGE, --refimage=REFIMAGE
Path to reference image
-c CORELIST, --corelist=CORELIST
File containing MeeGo Core package list
-m MEEGO_API_PKGLIST, --meego_api_pkglist=MEEGO_API_PKGLIST
File containing MeeGo API package list
-o OUTDIR, --outdir=OUTDIR
Output directory of report
-d, --debug Save intermediate log data for debugging

The sample MeeGo API package list file can be downloaded at:
[[media:MeeGo-API-pkglist.txt|MeeGo-API-pkglist.txt]]

= Result Format =
Currently, the output of checking tools will be stored in HTML files.

A distribution check report will look like this:
[[File:DistSummaryReport.png|none|600px|Sample Report]]

An application check report will look like this:

[[File:Appcheck2.png|none|600px|Sample Report]]

= Bug Report =

If problems were found in the compliance tools, please file bugs at bugs.meego.com. There is a top-level category for compliance - use "MeeGo Spec and Compliance", product "Compliance Tools".

= TODO =

* add checking for contents of binary packages
* use new image format with separated src.rpm pack
* Web UI for commenting the result
* Web service for app checking?
* Eliminate need for a reference compliance image for dist checking

2011-05-11T15:43:35Z

Mwichmann: moved Quality/Compliance/TableProfile to Quality/Compliance/TabletProfile: typo

This is an evolving draft, please propose changes in [[Talk:Quality/Compliance/TabletProfile]] and have larger discussions on meego-dev@meego.com mailing list.

= MeeGo Tablet Profile Specification =
== Hardware Requirements ==

TBD

== Package Management ==
None listed at this time

== ABI and API ==
The MeeGo Tablet Profile extends the Platform API with the following components:

TBD

== Other Requirements ==
None listed at this time

== Tablet Profile Packages ==

TBD

Talk:Quality/Compliance/TabletProfile

2011-05-11T15:31:27Z

Mwichmann: Created page with "Please use a section (+ button) per change proposal. Add <pre>-~~~~</pre> to sign with your username for each comment. Remember to 'watch' this page. Example: == Change request..."

Please use a section (+ button) per change proposal. Add <pre>-~~~~</pre> to sign with your username for each comment. Remember to 'watch' this page.

Example:

== Change request ==

Modify from:

blahblah

To:

halbhalb

-[[User:Stskeeps|Stskeeps]] 19:07, 11 November 2010 (UTC)

* How about 'foobar'? -[[User:Stskeeps|Stskeeps]] 19:07, 11 November 2010 (UTC)
** OK! -[[User:Stskeeps|Stskeeps]] 19:07, 11 November 2010 (UTC)
* Approved, please change page -[[User:Stskeeps|Stskeeps]] 19:07, 11 November 2010 (UTC)

Quality/Compliance/TabletProfile

Mwichmann: /* Implementation of Compliance */

= Compliance Implementation =

== Definition ==
The objective of '''Compliance''' is to provide a base set of functionality that application writers can depend on being there - effectively, an ABI plus other supporting details.

There are two aspects to compliance:
* For application writers, the key aspect is the set of services (libraries, services such as dbus, etc.) that are always present, so that apps know they can use them safely. It also includes a picture of which of those will be consistently provided in future releases so developers can detemine whether their apps will be "future-proof" or not.
* For device implementors, what is needed is a complete picture of what must be delivered, not just the external ABI view, so dependencies are also part of the picture.

In effect, the MeeGo Architecture makes up the starting point for compliance, while the the dependencies of the architecture packages can be seen as providing functionality "on behalf of" the architecture packages so to be practical, they end up in compliance as well. Dependencies could change over time - a dependency in 1.2 might not be a dependency in 1.3 any longer, so this part should not be counted on by applications; but for a given MeeGo release, dependencies are mandatory for devices.

== MeeGo Core vs. Compliance ==

The Compliance set does not need to describe a bootable system, indeed does not need to be a "real OS", it's just the minimum set an OSV needs to provide so that ISVs get a "compatible" OS.

Meego-core on the other hand actually needs to boot, so there's a bunch of things in there that are needed to boot, but that an application couldn't care less about. Bootloaders are a quick example of things that must be in core, but are not important for compliance.

So for all intents and purposes, compliance ends up being a subset of core.

As an example, compliance could include a requirement to handle sysv initscripts, but not describe how that requirement is to be met, so an OSV could replace the exsiting init processing with upstart. As long as the sysv initscripts are handled correctly, that's compliant.

== Implementation of Compliance ==

Since package groups are used to drive image creation anyway, proper grouping can make keeping track of compliance straightforward.

Conceptually, these patterns could be used:

* Base: bootable system, not compliant
* Compliance: Application Compliance packages
* Core = Base + Compliance
* Derived Compliance (need a better name for that) : Compliance and its dependencies
* Hardware Adaption Groups
* UX Groups

The MeeGo package-groups git tree (git://gitorious.org/meego-os-base/package-groups.git) now has these patterns to describe the compliance picture (additional patterns for adaptation, UX, etc):

* meego-base.xml - Basic system
* meego-compliance.xml - Packages needed for Compliance
* meego-full-compliance.xml - MeeGo full compliance including core compliance and its dependencies
* meego-core.xml - MeeGo Core OS

As a note, there is some compliance stuff that doesn't express as a specific pattern (?), and has to be handled separately:

* Kernel 2.6.35 or later -We have separate kernel for separate platforms
* /usr/lib/libEGL.so.1 - we have separate gfx package to provide this
* /usr/lib/libGLES2.so.1 - we have separate gfx package to provide this

Quality

2010-09-03T22:37:28Z

Mwichmann: /* Compliance Program */