The Mer Wiki now uses your Mer user account and password (create account on https://bugs.merproject.org/)
Nemo/Creating Releases
(→Promoting packages in OBS) |
(→Creating the snapshot) |
||
Line 50: | Line 50: | ||
You can also go to the [https://build.merproject.org/project/subprojects?project=nemo OBS WebUI] and check the status from there. | 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 | + | 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 | ./nemo-snapshot.sh testing | ||
− | '''NOTE:''' This script currently assumes that | + | '''NOTE:''' This script currently assumes that one is on the repository server and have certain permissions to directories. |
== Images == | == Images == |
Revision as of 10:02, 7 May 2013
This page guides how to build Nemo Mobile releases.
Contents |
Prerequisites
- Mer Platform SDK installed
- Logged in to Mer SDK
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 not 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.
Repository 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 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
NOTE: This script currently assumes that one is on the repository server and have certain permissions to directories.
Images
Getting the build script and configs
# Create new directory for Nemo Releases mkdir nemo-releases cd nemo-releases
# Install mer configs and mer-kickstarter zypper install mer-kickstarter-configs mer-kickstarter
# Install nemo configs git clone git://github.com/nemomobile/nemo-kickstarter-configs.git cd nemo-kickstarter-configs
# Create kickstart files mer-kickstarter -c repos.yaml -o nemo-ks/ cd ..
# Get the daily image builder script that is used to do releases git clone git://gitorious.org/image-building-tools/daily-image-builder.git cd daily-image-builder
Next thing is to configure the script for your needs. The default config should be fine though
cp builder.conf.tmpl builder.conf
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
The release images are done with following command:
sudo ./builder.py --use-ks-dir=../nemo-kickstarter-configs/nemo-ks/ --release-id=latest --extra-filter=-pandaboard,-rnd --run-mic
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 except for the PandaBoard:
sudo ./builder.py --use-ks-dir=../nemo-kickstarter-configs/nemo-ks/ --release-id=latest --extra-filter=-pandaboard,rnd --tokenmap=SSU_RELEASE_TYPE:rnd,FLAVOUR:devel --run-mic