Local Mer

A local Mer setup is the term given to the local OBS setup you need if you want to do a clean build of Mer.

Why?

• Independence
• Project configuration changes (build flags, etc)
• Paranoia
• Experiments
• …

Requirements

Before you start, you must setup:

• A working instance of Mer Delivery System 2, containing the release of Mer that you want to build.
• A project on your OBS that links to that instance. We called it MDS. If you choose another name, remember to change it while performing the commands.
• OSC installed on your machine and configured to reach your OBS instance. Your user must be able to create projects and packages.

Build process

The process has the following steps. Repeat for whatever architectures are needed. i586 is mandatory and must be done for first.

Limitations in the current OBS mean we can’t use normal linked builds because it doesn’t disable all i586 builds except the ones we want.

To match Mer architecture with the correct OBS scheduler, check out OBS architecture naming.

MDS2 allows you to choose the release of Mer by appending the version number to the project name.

Let's take for example:

i586 architecture

BS_ARCH=i586
BS_SCHED=i586
MER_RELEASE=0.20130528.1

Other architectures

BS_ARCH=armv7l
BS_SCHED=armv7el
MER_RELEASE=0.20130528.1

Create XML configuration file for OBS project

Using your preferred text editor, create a temporary XML file (we called it CorePrj.xml), containing:

i586 architecture

<project name="Core:i586">
  <title></title>
  <description>
Tied to remote.
  </description>
  <person role="maintainer" userid="Admin"/>
  <person role="bugowner" userid="Admin"/>
  <debuginfo>
    <disable/>
  </debuginfo>
  <build>
    <enable/>
  </build>
  <publish>
    <enable/>
  </publish>
  <repository name="Core_i586">
    <arch>i586</arch>
  </repository>
</project>

Other architectures

<project name="Core:${BS_ARCH}">
  <title></title>
  <description>
Tied to remote.
  </description>
  <person role="maintainer" userid="Admin"/>
  <person role="bugowner" userid="Admin"/>
  <debuginfo>
    <disable/>
  </debuginfo>
  <build>
    <enable/>
  </build>
  <publish>
    <enable/>
  </publish>
  <repository name="Core_${BS_ARCH}">
    <arch>i586</arch>
    <arch>${BS_SCHED}</arch>
  </repository>
</project>

Create project

osc meta prj Core:${BS_ARCH} -F CorePrj.xml

Copy/link packages

The next command links the packages from MDS2 to your local project. You can copy them instead of linking by changing osc linkpac -C copy to osc copypac.

WARNING: this can take some time due to the large number of packages.

osc ls MDS:Core:${BS_ARCH}:${MER_RELEASE} | xargs -L1 -Ixxx osc linkpac -C copy MDS:Core:${BS_ARCH}:${MER_RELEASE} xxx Core:${BS_ARCH} xxx

Crude check there were no errors after it finishes

osc ls MDS:Core:${BS_ARCH}:${MER_RELEASE} | sort > /tmp/fake-list
osc ls Core:${BS_ARCH} | sort > /tmp/bs-list
diff /tmp/fake-list /tmp/bs-list

If some packages are missing, link or copy them again:

echo -e "elfutils-libelf-x86\nmeego-cross-armv7hl-sysroot" | xargs -L1 -Ixxx osc linkpac -C copy MDS:Core:${BS_ARCH}:${MER_RELEASE} xxx Core:${BS_ARCH} xxx

Copy the prjconf file

osc meta prjconf MDS:Core:${BS_ARCH}:${MER_RELEASE} | osc -A merci meta prjconf Core:${BS_ARCH} -F -

Set the target schedulers

Open the editor for the local project XML file with this command:

osc meta prj Core:${BS_ARCH} -e

And add these lines inside the repository tag:

i586 architecture

<path repository="Core_i586" project="MDS:Core:i586:${MER_RELEASE}"/>

Other architectures

<path repository="Core_i586" project="Core:i586"/>
<path repository="Core_${BS_ARCH}" project="MDS:Core:${BS_ARCH}:${MER_RELEASE}"/>

Allow the local build to take place

Now wait for the project to rebuild. The following command is interesting:

watch osc jobhistory Core:${BS_ARCH} Core_${BS_ARCH} ${BS_SCHED}

Remove the remote link

Once the build is done, edit the project and remove the MDS:Core lines (also remove the Tied to remote reminder in the description):

osc meta prj Core:${BS_ARCH} | grep -v "MDS" | grep -v "Tied to remote" | osc meta prj Core:${BS_ARCH} -F -

Notes about using Mer Delivery System 1

If possible, Mer Delivery System 2 should always be used instead of Mer Delivery System 1.

If you want to use MDS1, you can follow the same process. You just have to remove the ${MER_RELEASE} part from the remote project names, because MDS1 always points to the latest release.