[opensuse-arm] OBS ARM build discussion I would like to start
Hi all, 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? Regards, Joop. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am Mittwoch, 21. Dezember 2011, 11:34:24 schrieb Joop Boonen:
Hi all,
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.
Well, it is not that the native build is in a so much better shape ...
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?
No. It can be changed when we have arm hardware which support a safe virtualization. Or someone brings the XEN para virtualiziation for arm in a state which can be merged with our mainline kernel (I doubt it is easy).
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?
Actually there is another reason why we need qemu base builds. Our goal should be to make arm builds part of openSUSE:12.2 project so we get an official release. But that means the average openSUSE developer needs to be able to make arm builds and to debug it. I only see qemu as a solution here. bye adrian
Regards,
Joop. -- Adrian Schroeter SUSE Linux Products GmbH email: adrian@suse.de
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Wednesday 21 December 2011, Joop Boonen wrote:
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.
Hi Joop, I know thats a problem. Mid-Term we would like to merge lguest which means that we can run the native hardware virtualized and then not have the problem. 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. Thanks, Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
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
Hi, 2011/12/21 Joop Boonen <joop.boonen@boonen.org>:
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-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 <joop.boonen@boonen.org>:
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
participants (5)
-
Adrian Schröter -
Alexander Graf -
Dirk Müller -
Joop Boonen -
Mikhail Zabaluev