The Mer Wiki now uses your Mer user account and password (create account on https://bugs.merproject.org/)
Automated Packaging from git
Setting up a webhook to github
NOTE: If you don't see the "Settings" tab as shown here, contact your project admin to give you more rights.
After clicking "Test Hook" the webhooks admin interface will show to the admins that you have active git tree. Now contact on the admins Sage or w00t at #nemomobile IRC channel and they will help you to setup the rest of the webhook process. Here the admin asks you what will be the package name and the target obs project where it should go and saves the information to the webhook admin interface. After this you can check the that the information is valid from https://webhook.merproject.org/webhook/
With tar_git service
tar_git is the service that is used to package packages where nemomobile is the upstream, which means packages that are located at https://github.com/nemomobile/
With tar_git service packaging information is carried on the same git branch with the code in rpm/ subdirectory. This directory can contain any files which all are exported to packaging in OBS. Usually the content is just plain spec file:
If more than one .spec, .yaml or .changes is present the one that matches to the "Package" in webhooks will be taken. This allows one to create multiple packages with same source and different .spec file.
Changelogs are automatically generated from git commit messages, when ever git commit contains line that contains the following format
commit 1efda9cf6a950509b26b69c599fbdc89f70104ae Author: Captain Nemo <firstname.lastname@example.org> Date: Fri Apr 26 15:21:34 2013 +0300 This is a sample commit message that contains two entries that are picked to the .changes file. [sample text] Longer sample text [feature] New feature X added Signed-off-by: Captain Nemo <email@example.com>
it is added automatically to the next changelog entry when new version is tagged. NOTE: Also should be noted that there MUST be at least one commit between each tag that contains a line shown above so that the changelog will be generated properly. Here is example how the lines above would correspond in .changes file
* Mon Apr 08 2013 Developer <firstname.lastname@example.org> - 0.1 - [sample text] Longer sample text - [feature] New feature X added
NOTE: If you have existing changelog that isn't already in proper format, i.e., git tags and commit messages, you need to add the old .changes file to the rpm/ directory. This .changes file will be is used as a base of the changelog generation and automated changelogs are appended to that. Should be noted that this changes file MUST NOT be updated after adding it to the git tree.
When ever you do tag on the branch enabled with the webhook, it will automatically launch the tar_git service and the new sources will be downloaded and built on the target project.
Please refer to the tagging format at: https://wiki.merproject.org/wiki/Nemo/Development/Releasing
To follow the behaviour of your webhooks you can join to #mer-boss IRC channel @ Freenode. Here is couple of examples of those messages:
< Merbot`> Tag(s) by Developer X in master branch of https://github.com/nemomobile/nemo-qml-plugins.git, which will trigger build in project nemo:devel:mw package nemo-qml-plugins (https://build.merproject.org//package/show?package=nemo-qml-plugins&project=nemo:devel:mw) < Merbot`> 1 commit(s) pushed by Developer Y to master branch of https://github.com/tswindell/telepathy-ring.git
If you tagged a package you can click the link and check that everything is ok.
Testing rpm package build before committing
To test sources that have tar_git packaging there is tool called mb, this can be installed to Mer Platform SDK and comes in package called sdk-utils. The usage is following:
mb build -t [sb2-target] rpm/my-package.spec
This automatically downloads and installs the dependencies to the sb2 target you specified and then builds and rpm package from the sources within that sb2 target.
After this you can move the rpm to the target device and install it and test that everything is ok. The rpm filename can be seen in the end of mb command if it was successfull. Example below.
... Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/sage/rpmbuild/BUILDROOT/nemo-mobile-session-13-0.arm Wrote: /home/sage/rpmbuild/RPMS/armv7hl/nemo-mobile-session-13-0.armv7hl.rpm Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.YyhUi6 + umask 022 + cd /home/sage/rpmbuild/BUILD + cd nemo-mobile-session + /bin/rm -rf /home/sage/rpmbuild/BUILDROOT/nemo-mobile-session-13-0.arm + exit 0
In case you are building dependency packages and need them for sb2 target you can also install it to your target easily
sb2 -t mer-core -R -m sdk-install rpm -Uvh --force /home/sage/rpmbuild/RPMS/armv7hl/nemo-mobile-session-13-0.armv7hl.rpm
Q: I removed a tag remotely and pushed it again, but this didn't trigger the webhook at github? A: Retag locally and then push again.
With git_pkg service
For packages where Nemo isn't upstream there is plan to use git_pkg instead of tar_git. See https://github.com/lbt/git-pkg for the code. This integration work has not started yet.
Before starting to use git_pkg you need to set following environment variables if using gitpkg <= 0.0.5
export EDITOR=vim export GIT_AUTHOR_NAME="Developer" export GIT_AUTHOR_EMAIL="email@example.com"
With gitpkg there is the master branch which contains the code, but only the code and no packaging information. The packaging information is located in separate pkg-mer branch.
Create new release
Before doing release you need to tag the version in master branch, e.g.,
git tag 0.26
After this you can do the release
After calling this command EDITOR is opened and you are asked to fill in the changelog information.
Q: I screwed up something when doing gp_release --ver=0.1.1 how can I revert?
git tag -d pkg-mer-0.1.1-1 mer-0.1.1-1; git checkout pkg-mer && git reset --hard HEAD~1 && git checkout master;
This section is a bit of a guide about how to perform unified development on the software that we (in Nemo) write and maintain.
- Nemo/Development/Releasing - for releasing software we maintain