Revision as of 11:18, 23 June 2013

Getting started with the build system

To get started you will need to activate your Mer account for OBS. Upon initial login you will be guided through a mini-process to set up your home repository.

After this it's a good idea to set up osc in the Mer Platform SDK with the new account. osc is a command line front-end for the build service. When issuing osc help for the first time you will be guided through a mini-process to set up a local default configuration. After the initial set-up completed just fire up your favorite editor and open the file ~/.oscrc. In the file, change

 apiurl = https://api.opensuse.org

to

 apiurl = https://api.merproject.org

Alternatively you can follow the more detailed instructions here: Osc_Setup Further down in the same file you will find a config section named [https://api.opensuse.org]. Change the section name to [https://api.merproject.org], and set the corresponding user = and pass = config options to match your Mer account. You can test your osc set-up by issuing

 osc ll

which should produce a list of all projects on the Mer build server. A more comprehensive "OBS getting started" page is at the MeeGo wiki.

Nemo Mobile OBS project structure

OBS at https://build.merproject.org/

Maintainer: Sage, #nemomobile @ Freenode

In each project there are two sets of repositories. One repository chain that builds against current release of Mer Core and another that builds against the "next" prerelease of Mer Core. These repositories are identified with latest_<arch> and next_<arch>, where <arch> is the architecture the repository is compiling against.

All the nemo related project are under the nemo project, and they follow the following structure:

nemo:<phase>:<project>:<subproject>

<phase> can be one of the following values: stable, testing or devel

• each <phase> has a complete nemo tree below it and is self-contained (ie no building against projects in a different <phase>)
• when a package is QA'ed it moves (how?) to the next phase, in order of devel -> testing -> stable
• the process from developer point of view starts from 'devel' phase where the changes are submitted, after this it is responsibility of maintainer(s) and QA team(s) to forward the new submission forward and report back on any issues.

The subprojects are described below.

nemo:<phase>:mw

Compiled against: mer:mds:core:{latest,next}:{arch}/{latest,next}_{arch}

Architectures (schedulers): i486 (i586), i586, armv6el (armv7el), armv7el, armv7hl (armv8el), armv7tnhl (armv8el?)

Shared components between ux and apps

Contains:

• policyframework
• maliit
• qt-components
• telepathy

nemo:<phase>:ux

Compiled against: nemo:<phase>:mw

Architectures (schedulers): i486 (i586), i586, armv6el (armv7el), armv7el, armv7hl (armv8el), armv7tnhl (armv8el?)

lipstick based UX for Nemo

nemo:<phase>:apps

Compiled against: nemo:<phase>:mw

Architectures (schedulers): i486 (i586), i586, armv6el (armv7el), armv7el, armv7hl (armv8el), armv7tnhl (armv8el?)

Project for applications in Nemo, such as calculator, contacts, messaging etc.

nemo:<phase>:hw:*

nemo:<phase>:hw:n9xx-common

Architectures (schedulers): armv7hl (armv8el)

Common parts for Nokia N900, N950 and N9 hardware adaptations

nemo:<phase>:hw:n900

Compiled against: nemo:<phase>:hw:n9xx-common

Architectures (schedulers): armv7hl (armv8el)

Nokia N900 Hardware adaptation project

nemo:<phase>:hw:n950-n9

Compiled against: nemo:<phase>:hw:n9xx-common

Architectures (schedulers): armv7hl (armv8el)

Nokia N950 and N9 Hardware adaptation project

nemo:<phase>:hw:pandaboard

Compiled against: nemo:<phase>:mw

Architectures (schedulers): armv7hl (armv8el)

PandaBoard OMAP4 hardware adaptation project

nemo:<phase>:hw:x86-generic

Compiled against: nemo:<phase>:mw

Architectures (schedulers): i486 (i586), i586

Generic x86 architecture adaptation project