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


SB2

From Mer Wiki
Revision as of 12:36, 21 December 2011 by Stskeeps (Talk | contribs)

Jump to: navigation, search

Contents

SB2

In Mer, we're currently experimenting with integrating SB2 into OBS to provide a better and more flexible cross compilation method. This is instructions to help you get started testing/developing this project.

WARNING: this is in-development code and may cause damage

What does SB2-OBS do differently than current approach

When a SB2flags: configuration item is encountered, 'build' switches behaviour. When it is preinstalling packages, it will install packages listed in SB2install: to BUILD_ROOT and rest to BUILD_TARGET (typically /target). The packages in SB2install are typically a X86 tools/bootstrap, which includes SB2, QEMU and cross compilers.

Upon booting the VM, it will set up an abuild user and chown -R abuild /target. It will then set up a SB2 target in /target and begin to install RPM packages utilizing RPM.

State

The setup can currently build 308 out of 320 packages in Mer Core

Steps

It is assumed you already have a functioning osc+build install on your computer.

Trying it out

In a KVM

  • You need to set up so you can do KVM builds
  • osc build --clean --no-verify --vm-type=kvm Core_armv7l armv7el

OBS project configuration settings

In the fork of 'build' and Carsten Munk's https://github.com/stskeeps/open-build-service OBS fork, it is now possible to do the following configuration settings

 %ifarch armv7el
 SB2install: packages-to-be-installed-in-root
 SB2flags: --toolchain /opt/cross/bin/armv7l-meego-linux-gnueabi-gcc --qemu /usr/bin/qemu-arm --debug
 %endif

The sb2flags available:

 --toolchain /path/to/your/crosscompiler-gcc/in/tools
 --qemu /path/to/your/dynamic/qemu
 --installmode name-of-sb2-mode-used-for-buildsystem-setup
 --defaultmode name-of-sb2-mode-used-for-rpmbuild
 --debug, will enable SB2 debugging/logs

As an example, current home:Admin:sb2:noaccel project configuration is:

 %ifarch armv7el
 sb2install: sb2-tools-arm
 sb2flags: --toolchain /opt/cross/bin/armv7l-meego-linux-gnueabi-gcc --qemu /usr/bin/qemu-arm --debug
 %endif

SB2 enablement details of Mer Core

OBS server and clients

First off, deploy the SB2-OBS patches for obs-build, opensuse-build-service patches to OBS and osc and obs-build for developer's clients from http://github.com/stskeeps/

It is important to deploy obs-build -and- opensuse-build-service to your OBS backend as these are interconnected and the OBS is what publishes 'build' code to the OBS workers.

For opensuse-build-service, it might be easier simply to grab the patch from https://github.com/stskeeps/open-build-service/commit/d54b286f821954f0938fb19a1e7f710e66ebf5ae and patch it directly to your installed setup, in /usr/lib/obs/server.

Foundation

You must have a repository that contains the built RPMs from a project you intend to enable with SB2 cross compilation, both X86 and ARM packages.

In http://webui-ci.tspre.org , we have those in Core:i586 and Core:armv7l. But the ARM port currently is utilizing our old cross compilation approach. So we need to somehow remove that. For non-Mer projects this is probably not needed.

To do this, we have created Core:armv7l:noaccel project, with this meta configuration:

 <project name="Core:armv7l:noaccel">
   <title></title>
   <description></description>
   <person role="maintainer" userid="Admin"/>
   <person role="bugowner" userid="Admin"/>
   <repository name="Core_armv7l">
     <arch>armv7el</arch>
     <arch>i586</arch>
   </repository>
  </project>

The reader may notice that we don't have any <path> directories in this repository. This is because we will be utilizing aggregatepac ( http://en.opensuse.org/openSUSE:Build_Service_Tips_and_Tricks#link_and_aggregate ) to transfer the binaries as-is from our Core:armv7l without having to drag in the project configurations from there.

For aggregatepac to work, you need to have similar <repository> as the origin project in the target project.

What I then did was:

  osc -A http://api-ci.tspre.org ls Core:armv7l | xargs -L1 -Ixxx osc -A http://api-ci.tspre.org aggregatepac Core:armv7l xxx Core:armv7l:noaccel

Which will cause all the built RPMs from Core:armv7l to be represented in Core:armv7l:noaccel.

Then I created our Core:armv7l:sb2 repository with the following meta prj:

 <project name="Core:armv7l:sb2">
   <title></title>
   <description></description>
   <person role="maintainer" userid="Admin"/>
   <person role="bugowner" userid="Admin"/>
   <build>
      <enable/>
   </build>
   <repository name="Core_armv7l">
     <path repository="Core_i586" project="Core:i586"/>
     <path repository="Core_armv7l" project="Core:armv7l:noaccel"/>
     <arch>armv7el</arch>
     <arch>i586</arch>
   </repository>
  </project>

This means, that when searching for RPMs for building, it will first look in Core_i586 repository of Core:i586 and then in Core_armv7l repository of Core:armv7l:noaccel.

Personal tools