[fedora-virt] qemu/kvm status

[Glauber Costa]

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
qemu currently does not have any kind of issue with arm.
for ia64, there's no qemu, just kvm. So if we need, we'll just build locally.

The only real issue is sparc, and in this case, yeah, bummer, but we can
still use the binaries approach.

Still leaves us with etherboot, bochs-bios and vga-bios. There are three
packages in which we can do a much better job. Can't see why hold them
because of the sparc package.

> 
> 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 :|