On Wednesday 21 December 2011, Dirk Müller wrote:

I think short term the solution would be to push a webpage that shows the status of the buidls to the outside, as there is no problem with publishing the build results, only access to the machines / worker network should be restricted.

Hi, was way easier than I thought: copy of the monitor page with failed or unresolvables: http://www.suse.de/~dmueller/arm-buildservice/monitor/ list of status of "interesting" failures (interesting because they only happen on qemu or only on arm, and not on opensuse factory). http://www.suse.de/~dmueller/arm-buildservice/ both are refreshed roughly every 2 hours. Greetings, Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On 30.12.2011, at 18:44, Mikhail Zabaluev wrote:

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?)

Eventually they're running the build script again, so if anything that's the place to put it. I don't fully see why you'd need LD_PRELOAD though? Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org