Hi, what I should also note is that we plan to push the SB2 solution upstream, code wise. What is missing for an upstream push is to review the code wrt. to any security violations in the pre- virtual machine phase. Side effects are unlikeley, an own code path with own "prjconf commands" are used (so no side effects to "preinstall:" or "CBinstall:" / "CBpreinstall:") Also, the inclusion of packages from one namespace into another as they are (e.g. x86 packages to arm) needs some consideration, so meta data namespaces are not poisoned. Other than that, the current solution shows exactly what we expected from it. Anyway, QEMU is still involved in those cases as a fallback where no speedup is present. This is needed to fool spec files in cases when they call things like uname or similiar (can name here a list of other exceptions we found). Kind regards, Martin On 01/19/12 08:39, Carsten Munk wrote:

...

Hi, Hi, we currently plan to enable OBS with an additional cross-compilation feature. Which is referred in the "Build Service Concept CrossDevelopment" [1] as Type 3: "[...] the build system is modified so original source and binary packages can be build and used in a repository ".

So instead of using QEMU to emulate a different architecture completely, we want to make use of cross-compilation using the host toolchain.

Later: for executing tests or other "target"-binaries during the %build/%install/%check there will be still the need to use QEMU - which would be then a mix of Type 3 and Type 4.

We have not started yet any coding, just have done some rough concepts and wanted to make our planned effort public to involve the community in the design, to make sure everyone is happy with that effort and useful not only for us. I should probably have noted this before on this mailing list, but I've been working on a cross compilation solution surrounding Scratchbox2 (SB2) and OBS for some months now, with an actual working solution. I haven't yet upstreamed it as we've spent time validating

19. jan. 2012 08.24 skrev Daniel Gollub : the solution and cleaning it up, optimizing - it currently builds my 322 package Mer Core without a hitch or source changes to all packages.

The patches are available on https://github.com/stskeeps and an out-dated description page at http://wiki.merproject.org/wiki/SB2

Scratchbox2 (not really related to Scratchbox 1, as some might know) is a flexible mapping engine. that you can use it to alter the perception of file systems and ability to be choosing to execute other binaries (such as X86 binaries instead of ARM), enabling quite flexible and interesting new ways of cross compiling. It works without binfmt_misc as well, tested both in kvm and chroot. And can accelerate things like autoreconf, etc. And can even export the running of target binaries to a native host through 'sbrsh'

What we do in our build patches, when SB2 is enabled (flagged by a prjconf setting), is to seperate into a build target and a build root. When SB2 isn't enabled, BUILD_TARGET == BUILD_ROOT.

The 'build' script then extracts dependencies noted as SB2install: into the BUILD_ROOT and the rest into BUILD_TARGET. Currently the solution is SB2 + QEMU + toolchain + x86 tools exported using baselibs.conf, but it's sure that a more elegant solution could be done.

It then proceeds to installing the target packages utilizing SB2 and then executing the build, enabling flexible control of what we want to accelerate.

I just briefly wanted to introduce this work, so let me know if you'd like to know more. I'm personally planning on putting it into production with actual images and devices running it over the next weeks - I think your idea could even be done using our SB2-OBS solution.

Reviews on my patches to build/obs/osc / constructive flames etc, most welcome.

BR Carsten Munk

-- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org