The Mer Wiki now uses your Mer user account and password (create account on https://bugs.merproject.org/)
SB2
(→Foundation) |
|||
Line 81: | Line 81: | ||
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. | 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. | + | 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: | To do this, we have created Core:armv7l:noaccel project, with this meta configuration: | ||
Line 105: | Line 105: | ||
Which will cause all the built RPMs from Core:armv7l to be represented in 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. |
Revision as of 12:36, 21 December 2011
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.
- Install modified osc client
- git clone git://github.com/stskeeps/osc.git
- cd osc
- (as root) python setup.py install --prefix=/usr
- If you are on ubuntu, you might need to install into dist-packages instead of site-packages
- Install modified 'build'
- git clone git://github.com/stskeeps/obs-build.git
- cd obs-build
- (as root) make install
Trying it out
- Register an account on http://webui-ci.tspre.org
- osc -A http://api-ci.tspre.org ls
- (type in your username/password)
- osc -A http://api-ci.tspre.org checkout Core:armv7l:sb2 acl
- cd Core:armv7l:sb2/acl
- osc build --clean --no-verify Core_armv7l armv7el
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.