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

Re: [fedora-virt] qemu/kvm status



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:
> Hello guys
> 
> I hope you're all doing fine, with joy in your hearts.
> 
> After a adventurous while, I have updated and QAed a new
> qemu srpm. I worked mostly on x86 and sparc QA, since they
> are the ones in which we have to build additional firmware.
> 
> Speaking of firware, for the very same reason as etherboot[1],
> I'm proposing some new packages. They are:
> 
> Bochs bios:
> http://glommer.fedorapeople.org/bochs-bios-2.3.8-0.1.git36989b0d2.fc11.src.rpm
> http://koji.fedoraproject.org/koji/taskinfo?taskID=1121809
> 
> OpenBIOS:
> http://glommer.fedorapeople.org/openbios-1.0-0.1.svn450.fc11.src.rpm
> http://koji.fedoraproject.org/koji/taskinfo?taskID=1119906
> 
> VGABIOS:
> http://glommer.fedorapeople.org/vgabios-0.6-0.1beta.fc11.src.rpm
> http://koji.fedoraproject.org/koji/taskinfo?taskID=1120633
> 
...
> [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

  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=...

Cheers,
Mark.


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