[fedora-virt] qemu/kvm status

[Daniel P. Berrange]

On Fri, Feb 13, 2009 at 11:23:01AM -0200, Eduardo Habkost wrote:
> On Fri, Feb 13, 2009 at 01:09:53PM +0000, Daniel P. Berrange wrote:
> > On Fri, Feb 13, 2009 at 10:59:04AM -0200, Glauber Costa wrote:
> > > > 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.
> > > I've talked to some people in #fedora-devel yesterday, for _hours_.
> > > 
> > > It turns out that they're planning on deploying some features in koji
> > > by Feb 28th, that _might_ help us a lot. Really, a lot.
> > > 
> > > The idea is that you can have your package built on an architecture
> > > exclusively with BuildArch directive. But your package can then have
> > > a subpackage with BuildArch: noarch. That way, your package will span
> > > all repositories. This seems like the perfect solution to us. I've
> > > helped them to proceed with some tests, and it seem to work. So what
> > > I'm plannin on doing, is post the rpms for review today, since it is
> > > unlikely that they will receive more updates in this mean time.
> > 
> > The main limitation with that approach is the architecture coverage,
> > and the way it relates to secondary architectures. This will only
> > let us easily do x86 & ppc. If we want sparc, arm or ia64 BIOS, the
> > builds would happen in the 2nd arch build ssytem, and the result
> > would not be available in our main Fedora YUM repos for primary 
> > archs. If we go with your current approach, we can do the build in
> > the 2nd-ary arch, and then pull the result back into the packages
> > on the primary arches
> 
> I don't know if I understood correctly. This means that the new feature
> could solve our problems, but it won't solve all of them because some
> arches where we need some binaries to be built are second-class citzens
> on the build system?

Yes, that is essentially it. The 2nd-ary architectures have completely
separate build system, and separate YUM repository composes. They're
basically a downstream distro, that just gets triggered whenever the
primary arch builds. Similarly the sparc 2ndary arch wouldn't have
access to the '-noarch' x86 firmware we'd build. So for a complete
solutuon I think the manual double build + tar.gz of just build blobs
is probably the only way we'll get full coverage for all the QEMU arches.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|