2011/1/11 Carsten Munk <[email protected]>:
> Hi,
>
> So, as some of you have noticed, I've submitted a bunch of -x86
> packages to devel:toolchain, so I'd like to take a minute of your time
> to explain what this does as it'll be a larger submission towards
> Trunk:Testing. And I wanted to get everyone on the same page so
> there's no problems when we do submit this.
>
> As you know, ARM builds on OBS are horribly slow. Of course, some of
> you remember old days where we didn't even have cross compilers, where
> things were even worse :)
>
> So, speedrpm is basically an extension to our current cross
> compilation approach - where we using some tricks dump in X86 binaries
> (including cross gcc and binutls) into an ARM chroot, where it
> transparently replaces the ARM versions, so the compilation process
> basically works like it's a native compile.

And for good measure, since I believe in credit where credit is due:

This submission (speedrpm) was mostly implemented by Jan-Simon Möller
from Linux Foundation, where I've functioned as integrator and adding
a tool or two, testing it with hardfp build and driving to get the
load of new packages submitted to the right place :)

We've also noticed an odd problem with rpm-x86 being used in KVM's,
which we are still investigating.

BR
Carsten Munk

>
> So, to justify these new packages, I'll quickly group them:
>
> * rpm-x86 - this helps in general with build chroot setup, which is
> now done (uncompression and all) by a X86 binary, making chroot setup
> as fast as on X86. This was by far the biggest slowdown in ARM builds
>
> * rpm-build-x86 - this accelerates when rpms are built ('Wrote:') phase.
>
> * bzip2-x86, tar-x86, gzip-x86 - in a build process you are very often
> running untar, un-bzip, un-gzip on big files, which is slow when the
> de-compressor is running as an emulated ARM binary. This speeds up the
> build root setup and very often also post-compilation process.
>
> * coreutils-x86, sed-x86 - these tools usually involve a lot of string
> processing which is also not useful to use X86 binaries in this,
> speeds up general compilation and 'configure'
>
> * file-x86 - many of you have spotted the brp-strip-static-archive
> slowdown, where on big packages this seems to take ages. This speeds
> up this phase by making 'file' a X86 binary.
>
> * elfutils-x86 - this helps in the phase where debuginfo is extracted
> and binaries stripped (eu-strip)
>
> * diffutils-x86 - this helps in 'compare' phase, where the new built
> RPM is compared to the old RPM, as 'diff' and 'cmp' is fast now.
>
> rest are library dependancies for the binaries.
>
> This has been tested on a copy of Trunk:Testing without any problems.
> rpm-x86 has a minor problem with signature checking we're still
> looking into ('warning: .init_b_cache/kernel-headers.rpm: Header V3
> DSA/SHA1 Signature, key ID 79fc1f8a: NOKEY')
>
> Best regards,
> Carsten Munk
>
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev

Reply via email to