[fedora-virt] qemu/kvm status

[Daniel P. Berrange]

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

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