The Mer Wiki now uses your Mer user account and password (create account on https://bugs.merproject.org/)


Nemo/Creating Releases

From Mer Wiki
< Nemo(Difference between revisions)
Jump to: navigation, search
(Getting the build script and configs)
m (Getting the build script and configs)
 
(37 intermediate revisions by 5 users not shown)
Line 5: Line 5:
 
* Logged in to Mer SDK
 
* Logged in to Mer SDK
  
== Getting the build script and configs ==
+
== Background ==
  
  # Create new directory for Nemo Releases
+
Nemo has three levels or phases on repositories. First is '''devel''' level that contains the latest and the greatest. To this level commits are done by developers and for packages that have been converted to git format the the updates are coming straight from the git commits see [[Nemo/Development]]. Because of this there can be occasional breakages in the devel.
 +
 
 +
After devel comes '''testing''' to which packages are submitted usually with creq's (See: [[#Promoting_packages_in_OBS]]) by the maintainer/qa person who tests the packages and accepts them.
 +
 
 +
Last phase is '''stable''' that is currently not used, but it will contain more testing and where nothing should break.
 +
 
 +
== Taking new Mer release to Nemo ==
 +
When new mer release is taken in use in nemo it is first added to '''devel'''. This is done by editing ''mer:devel'' project in the Mer OBS, e.g.,
 +
  osc -A https://api.merproject.org meta prj mer:devel -e
 +
 
 +
.. and then with your favourite editor change the '''path''' lines of appropriate release, '''latest_''' and/or '''next_''', to match the new release id:
 +
  <repository name="'''latest_'''i586">                                                                                                                                                                                                           
 +
    <path project="mer:mds2:Core:i586:'''0.20130411.1'''" repository="Core_i586"/>                                                                                                                                                               
 +
    <arch>i586</arch>                                                                                                                                                                                                                       
 +
  </repository>                                                                                                                                                                                                                             
 +
 
 +
'''NOTE''': You can see the latest releases from http://releases.merproject.org/releases/latest-release and http://releases.merproject.org/releases/next-release
 +
 
 +
For '''testing''' the process is similar to '''devel''', i.e., edit ''mer:testing'' project in Mer OBS. Addition thing with ''testing'' level is that one needs also update the repository links at http://releases.nemomobile.org/rnd/repos/ to match the new release. This is done by editing the rnd/repos/mer-latest-testing/.htaccess file on the appropriate server. Should be noted though that on '''devel''' level the links are made to point latest and next and should not need changing.
 +
 
 +
'''NOTE''': latest release should be promoted from '''devel''' to '''testing''' only when the build errors have been fixed.
 +
 
 +
== Promoting packages in OBS ==
 +
 
 +
Packages are promoted '''from devel to testing''' by maintainer. For this there is a script available at https://github.com/nemomobile/release-tools/blob/master/check-project-diff.py that creates a creq line for you with all the modifications that are currently available between the two repos. Example cmdline for promoting ''mw'' content:
 +
 
 +
./check-project-diff.py -S nemo:devel:mw -D nemo:testing:mw -c --show-changelog --add-without-changes
 +
 
 +
While script is executed it shows you the changelog differences and also in the end gives the creq cmdline that can be copy pasted to terminal. Example of creq cmd:
 +
osc -A https://api.merproject.org/ creq -m fixes -a submit nemo:devel:mw connman-qt nemo:testing:mw -a submit nemo:devel:mw connman-qt5
 +
 
 +
'''NOTE:''' this creq cmdline is just a template and should be modified if you want to submit just part of the current changes.
 +
 
 +
After the creq has been submitted it goes to '''BOSS review''', which can be watched at #mer-boss IRC channel at Freenode. BOSS also informs about status of reviews at #nemomobile channel when request is accepted, declined or needs review by maintainer. After the prechecks are done the request comes to '''maintainer review''' where maintainer checks the request,
 +
osc -A https://api.merproject.org/ review show --diff '''<REVIEW_ID>'''
 +
And if it is ok then accepts or declines the review
 +
osc -A https://api.merproject.org/ review accept/decline '''<REVIEW_ID>''' -m "'''<COMMENT>'''"
 +
 
 +
When this maintainer review is done the request goes to build check where it is checked that no builds are failing after this request is accepted to target project.
 +
 
 +
== Snapshots ==
 +
 
 +
=== Creating the snapshot ===
 +
 
 +
Before one can do snapshot of repository one should check that the repository is build properly. For this there is a tool in https://github.com/nemomobile/release-tools/blob/master/check-build-failures.sh
 +
Example usage:
 +
./check-build-failures.sh nemo:testing:mw latest_armv7hl
 +
 
 +
You can also go to the [https://build.merproject.org/project/subprojects?project=nemo OBS WebUI] and check the status from there.
 +
 
 +
After verifying that the repositories are build properly one can do snapshots with the snapshot script. This snapshot tool for creating the snapshot is available at https://github.com/nemomobile/release-tools and is used to create a snapshot and update the links latest links. To create for example testing snapshot call
 +
./nemo-snapshot.sh testing
 +
 
 +
This new snapshot will be then available at http://releases.nemomobile.org/snapshots/repos/
 +
 
 +
'''NOTE:''' This script currently assumes that one is on the repository server and have certain permissions to directories.
 +
 
 +
=== Importing the snapshot ===
 +
 
 +
https://github.com/nemomobile/release-tools/blob/master/import-nemo-snapshot-dod.sh can be used to import a new snapshot.
 +
 
 +
Example usage:
 +
sudo ./import-nemo-snapshot-dod.sh --nemo-id <NEMO_ID>
 +
 
 +
After this you can see the new static snapshot as nemo:<NEMO_ID>:* projects in the OBS.
 +
 
 +
== Release ==
 +
 
 +
=== Creating the release ===
 +
 
 +
To create a release one uses the https://github.com/nemomobile/release-tools/blob/master/nemo-release.sh tool. This tool creates a release based on the latest snapshot that has been done.
 +
Example usage:
 +
./nemo-release.sh
 +
 
 +
After script has been called new release is available at http://releases.nemomobile.org/releases/
 +
 
 +
'''NOTE:''' Script assumes certain structure in the filesystem to be present atm.
 +
 
 +
== Images ==
 +
 
 +
Creating images can be done by anyone from anywhere as there is no need for internal server access.
 +
 
 +
=== Getting the build script and configs ===
 +
 
 +
 
 +
<span style='color:red'>'''For Wayland/Qt5 please use this repository: https://github.com/faenil/NemoWaylandKickstart '''</span>
 +
 
 +
For X11/Qt4 the steps are as follows:
 +
 
 +
Lets do directory for all of this nemo release stuff
 
  mkdir nemo-releases
 
  mkdir nemo-releases
 
  cd nemo-releases
 
  cd nemo-releases
  
# Install mer configs and mer-kickstarter
+
Install mer configs and mer-kickstarter
 
  zypper install mer-kickstarter-configs mer-kickstarter
 
  zypper install mer-kickstarter-configs mer-kickstarter
  
# Install nemo configs
+
Nemo Configurations do not have any package atm. so we get the git tree..
 
  git clone git://github.com/nemomobile/nemo-kickstarter-configs.git
 
  git clone git://github.com/nemomobile/nemo-kickstarter-configs.git
 
  cd nemo-kickstarter-configs
 
  cd nemo-kickstarter-configs
  
# Create kickstart files
+
.. and make .ks files out of it.
  mer-kickstarter -e . -c release-latest/nemo-latest.yaml -o nemo-latest-ks/
+
  mer-kickstarter -c repos.yaml -o nemo-ks/
 +
cd ..
  
# Get the daily image builder script that is used to do releases
+
To make the actual images there is tool called daily-image-builder..
  git clone https://gitorious.org/image-building-tools/daily-image-builder
+
  git clone git://gitorious.org/image-building-tools/daily-image-builder.git
+
 
  cd daily-image-builder
 
  cd daily-image-builder
+
 
Next thing is to configure the script for your needs. The default config should be fine though
+
.. the default config should be fine so lets use that one
 
  cp builder.conf.tmpl builder.conf
 
  cp builder.conf.tmpl builder.conf
  
== Building the release ==
+
=== Creating mic cmdlines to test individual image creation ===
 +
 
 +
Following command lists all the mic cmdlines for the .ks files that can be used to create individual images manually
 +
./builder.py --use-ks-dir=../nemo-kickstarter-configs/nemo-ks/ --release-id=latest
 +
 
 +
=== Building the release images ===
 +
 
 +
==== Release ====
  
After this you can test the release build. The extra -pandaboard filter is used as it is not part of the official Nemo releases.
+
The release images are done with following command:
  ./builder.py --use-ks-dir=../nemo-latest-ks/ --release-id=NEMO,latest-release --extra-filter=handset,-pandaboard
+
  sudo ./builder.py --use-ks-dir=../nemo-kickstarter-configs/nemo-ks/ --release-id=latest --extra-filter=-rnd --run-mic
  
If the cmdlines seem ok then you can do the release with
+
==== RND ====
  sudo ./builder.py --use-ks-dir=../nemo-latest-ks/ --release-id=NEMO,latest-release --extra-filter=handset --run-mic
+
The rnd image creation differs a bit, for that you need to give filter ''rnd'' instead of ''-rnd'' and also you need to give FLAVOUR and SSU_RELEASE_TYPE as values to the tokenmap.<br>
 +
Example below will create all RND images:
 +
  sudo ./builder.py --use-ks-dir=../nemo-kickstarter-configs/nemo-ks/ --release-id=latest --extra-filter=rnd --tokenmap=SSU_RELEASE_TYPE:rnd,FLAVOUR:devel --run-mic

Latest revision as of 21:44, 4 February 2014

This page guides how to build Nemo Mobile releases.

Contents

[edit] Prerequisites

[edit] Background

Nemo has three levels or phases on repositories. First is devel level that contains the latest and the greatest. To this level commits are done by developers and for packages that have been converted to git format the the updates are coming straight from the git commits see Nemo/Development. Because of this there can be occasional breakages in the devel.

After devel comes testing to which packages are submitted usually with creq's (See: #Promoting_packages_in_OBS) by the maintainer/qa person who tests the packages and accepts them.

Last phase is stable that is currently not used, but it will contain more testing and where nothing should break.

[edit] Taking new Mer release to Nemo

When new mer release is taken in use in nemo it is first added to devel. This is done by editing mer:devel project in the Mer OBS, e.g.,

osc -A https://api.merproject.org meta prj mer:devel -e

.. and then with your favourite editor change the path lines of appropriate release, latest_ and/or next_, to match the new release id:

 <repository name="latest_i586">                                                                                                                                                                                                            
   <path project="mer:mds2:Core:i586:0.20130411.1" repository="Core_i586"/>                                                                                                                                                                 
   <arch>i586</arch>                                                                                                                                                                                                                        
 </repository>                                                                                                                                                                                                                              

NOTE: You can see the latest releases from http://releases.merproject.org/releases/latest-release and http://releases.merproject.org/releases/next-release

For testing the process is similar to devel, i.e., edit mer:testing project in Mer OBS. Addition thing with testing level is that one needs also update the repository links at http://releases.nemomobile.org/rnd/repos/ to match the new release. This is done by editing the rnd/repos/mer-latest-testing/.htaccess file on the appropriate server. Should be noted though that on devel level the links are made to point latest and next and should not need changing.

NOTE: latest release should be promoted from devel to testing only when the build errors have been fixed.

[edit] Promoting packages in OBS

Packages are promoted from devel to testing by maintainer. For this there is a script available at https://github.com/nemomobile/release-tools/blob/master/check-project-diff.py that creates a creq line for you with all the modifications that are currently available between the two repos. Example cmdline for promoting mw content:

./check-project-diff.py -S nemo:devel:mw -D nemo:testing:mw -c --show-changelog --add-without-changes

While script is executed it shows you the changelog differences and also in the end gives the creq cmdline that can be copy pasted to terminal. Example of creq cmd:

osc -A https://api.merproject.org/ creq -m fixes -a submit nemo:devel:mw connman-qt nemo:testing:mw -a submit nemo:devel:mw connman-qt5

NOTE: this creq cmdline is just a template and should be modified if you want to submit just part of the current changes.

After the creq has been submitted it goes to BOSS review, which can be watched at #mer-boss IRC channel at Freenode. BOSS also informs about status of reviews at #nemomobile channel when request is accepted, declined or needs review by maintainer. After the prechecks are done the request comes to maintainer review where maintainer checks the request,

osc -A https://api.merproject.org/ review show --diff <REVIEW_ID>

And if it is ok then accepts or declines the review

osc -A https://api.merproject.org/ review accept/decline <REVIEW_ID> -m "<COMMENT>"

When this maintainer review is done the request goes to build check where it is checked that no builds are failing after this request is accepted to target project.

[edit] Snapshots

[edit] Creating the snapshot

Before one can do snapshot of repository one should check that the repository is build properly. For this there is a tool in https://github.com/nemomobile/release-tools/blob/master/check-build-failures.sh Example usage:

./check-build-failures.sh nemo:testing:mw latest_armv7hl

You can also go to the OBS WebUI and check the status from there.

After verifying that the repositories are build properly one can do snapshots with the snapshot script. This snapshot tool for creating the snapshot is available at https://github.com/nemomobile/release-tools and is used to create a snapshot and update the links latest links. To create for example testing snapshot call

./nemo-snapshot.sh testing

This new snapshot will be then available at http://releases.nemomobile.org/snapshots/repos/

NOTE: This script currently assumes that one is on the repository server and have certain permissions to directories.

[edit] Importing the snapshot

https://github.com/nemomobile/release-tools/blob/master/import-nemo-snapshot-dod.sh can be used to import a new snapshot.

Example usage:

sudo ./import-nemo-snapshot-dod.sh --nemo-id <NEMO_ID>

After this you can see the new static snapshot as nemo:<NEMO_ID>:* projects in the OBS.

[edit] Release

[edit] Creating the release

To create a release one uses the https://github.com/nemomobile/release-tools/blob/master/nemo-release.sh tool. This tool creates a release based on the latest snapshot that has been done. Example usage:

./nemo-release.sh

After script has been called new release is available at http://releases.nemomobile.org/releases/

NOTE: Script assumes certain structure in the filesystem to be present atm.

[edit] Images

Creating images can be done by anyone from anywhere as there is no need for internal server access.

[edit] Getting the build script and configs

For Wayland/Qt5 please use this repository: https://github.com/faenil/NemoWaylandKickstart

For X11/Qt4 the steps are as follows:

Lets do directory for all of this nemo release stuff

mkdir nemo-releases
cd nemo-releases

Install mer configs and mer-kickstarter

zypper install mer-kickstarter-configs mer-kickstarter

Nemo Configurations do not have any package atm. so we get the git tree..

git clone git://github.com/nemomobile/nemo-kickstarter-configs.git
cd nemo-kickstarter-configs

.. and make .ks files out of it.

mer-kickstarter -c repos.yaml -o nemo-ks/
cd ..

To make the actual images there is tool called daily-image-builder..

git clone git://gitorious.org/image-building-tools/daily-image-builder.git
cd daily-image-builder

.. the default config should be fine so lets use that one

cp builder.conf.tmpl builder.conf

[edit] Creating mic cmdlines to test individual image creation

Following command lists all the mic cmdlines for the .ks files that can be used to create individual images manually

./builder.py --use-ks-dir=../nemo-kickstarter-configs/nemo-ks/ --release-id=latest

[edit] Building the release images

[edit] Release

The release images are done with following command:

sudo ./builder.py --use-ks-dir=../nemo-kickstarter-configs/nemo-ks/ --release-id=latest --extra-filter=-rnd --run-mic

[edit] RND

The rnd image creation differs a bit, for that you need to give filter rnd instead of -rnd and also you need to give FLAVOUR and SSU_RELEASE_TYPE as values to the tokenmap.
Example below will create all RND images:

sudo ./builder.py --use-ks-dir=../nemo-kickstarter-configs/nemo-ks/ --release-id=latest --extra-filter=rnd --tokenmap=SSU_RELEASE_TYPE:rnd,FLAVOUR:devel --run-mic
Personal tools