Hi,
2011/12/21 Joop Boonen
Currently we have the following problem. Due to security issues we only have native ARM workers for the internal openSUSE buildservice. For the external build service we only use qemu.
Because qemu is much slower them native ARM builds the external build is way behind. So for people outside of suse.com it's not really possible to fix packages as you don't know if the current status is still valid.
I would like to know how the people in charge of OBS think about this? Can the current situation be changed or is this due to a security policy? Can we help to solve this issue? If so what are the problems we are facing and which security should be met?
Did I leave something out or is something now correct?
FYI, I have a scratch project trying to bootstrap a self-hosting set of native tools that can be imported to speed up ARM (and possibly other platform) builds: https://build.opensuse.org/project/show?project=home%3Amzabaluev%3ALynch%3AS... The idea is similar to what Mer folks do: natively built essential tools and the cross toolchain, installed into ARM builds using displaced "shadow" locations for libraries and other things, via magic in RPM and OBS that is yet to be done. One of the goals is to see if a runtime emulation layer like hijacking library calls (as in Scratchbox) can be avoided. Now I'm at a point where I can build binutils with a "shadow" glibc in osc chroot, but there is a problem with KVM builds in OBS, where bash fails unable to find dynamic libraries. I would like to debug this with setting LD_DEBUG, but I did not figure out yet how to do it for KVM builders, if it's even possible at all (what do KVM workers run for init, to begin with?) Hope this helps, Mikhail -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org