[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [fedora-virt] qemu/kvm status



On Fri, Feb 13, 2009 at 09:50:06AM +0000, Mark McLoughlin wrote:
> Hi Glauber,
> 
> I'm glad you left the bottle of wine until last - this work requires a
> strong stomach! :-)
> 
> On Thu, 2009-02-12 at 13:29 -0200, Glauber Costa wrote:
<snip>
> > [1] Most firmware is compiled for one specific architecture, but
> > should run on qemu whichever your host architecture is. We don't
> > have a cross compiler infra in place, so we have to compile it natively.
> > The easiest would be to pick binaries directly from upstream, which
> > usually provides it. But we have policies that say we have to build
> > everything we ship. So we have a crazy bootstrap process in place,
> > in which we first build natively, and then feed a tar.gz for the
> > other architectures. It means every package should be built at least
> > twice in the process of getting something out of the door.
> 
> Okay, let me see if I understand this:
> 
>   1) You need to fix or update something in the package
> 
>   2) You make the change and build it in koji
> 
>   3) The build finishes, you download the binary RPM, unpack with 
>      rpm2cpio and:
> 
>        $> cd usr/share
>        $> tar -cvjf etherboot-binaries-$(nvr).tar.bz etherboot/
> 
>   4) Update the spec file with the new tarball name, upload the tarball 
>      to the sources repo, check in and build in Koji
> 
> Two suggestions:
> 
>   1) The second build shouldn't rebuild the binaries on any arch - that 
>      way each arch has identical binaries

Currently (on etherboot, and I think that's the case on the bios packages
made by Glauber), we use prebuilt binaries only on the arches we can't
build the binaries. This lets us use exactly the same package for step
2 and 4. But maybe we can change this:

- First build: all prebuilt binaries tarballs removed from the spec, only
  native binaries built (using something like %define only_native 1)
- Second build: added the prebuilt binaries from the first build,
  no binaries actually compiled, but uses only the prebuilt binaries


We have a problem with any of the above approaches: we don't want to make
the first build a scratch build (we want to keep the build information
stored somewhere on Koji), but we don't want this build to be available
for the users, as the result is an incomplete package. I am thinking
about asking a Koji tag to be created just to store those "intermediate
build step" RPMs. What do you think?


> 
>   2) We add a "make update-binaries" the makefile - it would do:
> 
>         $> koji download-build $(make verrel)
>         $> rpm2cpio ... | cpio
>         $> tar -cvjf ...
>         $> grep -v etherboot-binaries sources > sources.tmp
>         $> mv sources.tmp sources
>         $> sed -i -e ... etherboot.spec
>         $> make upload FILES=...

+1. This should be automated as much as possible.

-- 
Eduardo


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]