QEMU new Package

[Glauber Costa]

Hi guys.

I've built a qemu image in here:

http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151

It contains the basic work to get qemu package updated. Basically,
we're talking about getting the qemu code from svn and creating multiple
packages, so one could grab just the architecture of interest.
Todo, is the creation of a meta-package to grab'em all at once.

This is also the first step in merging qemu and kvm packages, which
I'd like to do in two steps.

1) This one.
2) replace qemu-svn with kvm-userspace

The later is not as trivial as it seems. Nobody exercices this path
usually, and we're likely to find bugs that prevent the build to finish
(Well, I tested, and there _are_ bugs ;-) ). But I believe we can have
it sorted out.

If no one has any major opposition to the state of things, I intend to
commit it to CVS tomorrow (with some minor changes), and put it into
rawhide so we can start having a more serious testing out of it.

[Daniel P. Berrange]

On Tue, Feb 03, 2009 at 06:11:31PM -0200, Glauber Costa wrote:
> Hi guys.
>
> I've built a qemu image in here:
>
> http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151
>
> It contains the basic work to get qemu package updated. Basically,
> we're talking about getting the qemu code from svn and creating multiple
> packages, so one could grab just the architecture of interest.
> Todo, is the creation of a meta-package to grab'em all at once.
>
> This is also the first step in merging qemu and kvm packages, which
> I'd like to do in two steps.
> This one.
> replace qemu-svn with kvm-userspace
>
> The later is not as trivial as it seems. Nobody exercices this path
> usually, and we're likely to find bugs that prevent the build to finish
> (Well, I tested, and there _are_ bugs ;-) ). But I believe we can have
> it sorted out.
>
> If no one has any major opposition to the state of things, I intend to
> commit it to CVS tomorrow (with some minor changes), and put it into
> rawhide so we can start having a more serious testing out of it.

Has anyone discussed with the upstream QEMU developers about doing a
new release. I've seen no such discussions on the public qemu-devel
list. If QEMU guys are planning a new release soon, then we'd have
no need for a CVS snapshot, or at least confidence that QEMU guys
consider it geting stable enough that a release is viable. If the
QEMU devs don't consider a new release viable I'd like to know why
they think this, *before* we subject Fedora users to a CVS snapshot.

Daniel

[Mark McLoughlin]

On Tue, 2009-02-03 at 21:58 +0000, Daniel P. Berrange wrote:
> On Tue, Feb 03, 2009 at 06:11:31PM -0200, Glauber Costa wrote:
> > Hi guys.
> >
> > I've built a qemu image in here:
> >
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151
> >
> > It contains the basic work to get qemu package updated. Basically,
> > we're talking about getting the qemu code from svn and creating multiple
> > packages, so one could grab just the architecture of interest.
> > Todo, is the creation of a meta-package to grab'em all at once.
> >
> > This is also the first step in merging qemu and kvm packages, which
> > I'd like to do in two steps.
> > This one.
> > replace qemu-svn with kvm-userspace
> >
> > The later is not as trivial as it seems. Nobody exercices this path
> > usually, and we're likely to find bugs that prevent the build to finish
> > (Well, I tested, and there _are_ bugs ;-) ). But I believe we can have
> > it sorted out.
> >
> > If no one has any major opposition to the state of things, I intend to
> > commit it to CVS tomorrow (with some minor changes), and put it into
> > rawhide so we can start having a more serious testing out of it.
>
> Has anyone discussed with the upstream QEMU developers about doing a
> new release. I've seen no such discussions on the public qemu-devel
> list. If QEMU guys are planning a new release soon, then we'd have
> no need for a CVS snapshot, or at least confidence that QEMU guys
> consider it geting stable enough that a release is viable. If the
> QEMU devs don't consider a new release viable I'd like to know why
> they think this, *before* we subject Fedora users to a CVS snapshot.

Yep, see:

http://lists.gnu.org/archive/html/qemu-devel/2009-02/msg00138.html

Given that plan, pulling in svn snapshots is similar to pulling in
release candidates from upstreams that do release candidates.

Cheers,
Mark.

[Daniel P. Berrange]

On Tue, Feb 03, 2009 at 10:08:03PM +0000, Mark McLoughlin wrote:
> On Tue, 2009-02-03 at 21:58 +0000, Daniel P. Berrange wrote:
> > On Tue, Feb 03, 2009 at 06:11:31PM -0200, Glauber Costa wrote:
> > > Hi guys.
> > >
> > > I've built a qemu image in here:
> > >
> > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151
> > >
> > > It contains the basic work to get qemu package updated. Basically,
> > > we're talking about getting the qemu code from svn and creating multiple
> > > packages, so one could grab just the architecture of interest.
> > > Todo, is the creation of a meta-package to grab'em all at once.
> > >
> > > This is also the first step in merging qemu and kvm packages, which
> > > I'd like to do in two steps.
> > > This one.
> > > replace qemu-svn with kvm-userspace
> > >
> > > The later is not as trivial as it seems. Nobody exercices this path
> > > usually, and we're likely to find bugs that prevent the build to finish
> > > (Well, I tested, and there _are_ bugs ;-) ). But I believe we can have
> > > it sorted out.
> > >
> > > If no one has any major opposition to the state of things, I intend to
> > > commit it to CVS tomorrow (with some minor changes), and put it into
> > > rawhide so we can start having a more serious testing out of it.
> >
> > Has anyone discussed with the upstream QEMU developers about doing a
> > new release. I've seen no such discussions on the public qemu-devel
> > list. If QEMU guys are planning a new release soon, then we'd have
> > no need for a CVS snapshot, or at least confidence that QEMU guys
> > consider it geting stable enough that a release is viable. If the
> > QEMU devs don't consider a new release viable I'd like to know why
> > they think this, *before* we subject Fedora users to a CVS snapshot.
>
> Yep, see:
>
> http://lists.gnu.org/archive/html/qemu-devel/2009-02/msg00138.html
>
> Given that plan, pulling in svn snapshots is similar to pulling in
> release candidates from upstreams that do release candidates.

Lucky timing ! Reaction so far from QEMU upstream seems fairly positive,
so testing the SVN snapshot in rawhide leading upto the release would
be reasonable, particularly as he proposed date of end of month would
fit in with F11 freeze reasonably well.

Daniel

[Mark McLoughlin]

(cc-ed a few people who were interested on irc)

On Tue, 2009-02-03 at 18:11 -0200, Glauber Costa wrote:
> Hi guys.
>
> I've built a qemu image in here:
>
> http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151
>
> It contains the basic work to get qemu package updated. Basically,
> we're talking about getting the qemu code from svn and creating multiple
> packages, so one could grab just the architecture of interest.
> Todo, is the creation of a meta-package to grab'em all at once.

Okay, so this adds ~30 sub-packages. In retrospect, maybe ajax and co.
have a point saying that's a bit excessive :-)

One downside to so many sub-packages is that it means the total size of
the RPMs is ~15Mb instead of ~10Mb.

The on-disk size of the current qemu package is ~50Mb. What most people
care about is /usr/bin/qemu (and in future qemu-kvm). Those bits only
have a ~3Mb on-disk size. Each other target adds ~1.5Mb.

How about splitting it this way:

qemu:
    - /usr/bin/qemu
    - /usr/bin/qemu-system-x86_64 (only on x86_64, obviously)
    - qemu-kvm
    - qemu-nbd
    - docs
    - BIOSes
    - keymaps
    - init script

qemu-img
    - /usr/bin/qemu-img

qemu-system:

- qemu-system-arm
    - qemu-system-cris
    - qemu-system-i386
    - qemu-system-m68k
    - qemu-system-mips
    - qemu-system-mips64
    - qemu-system-mips64el
    - qemu-system-mipsel
    - qemu-system-ppc
    - qemu-system-ppc64
    - qemu-system-ppcemb
    - qemu-system-sh4
    - qemu-system-sh4eb
    - qemu-system-sparc

qemu-linux:

- qemu-alpha
    - qemu-arm
    - qemu-armeb
    - qemu-cris
    - qemu-debuginfo
    - qemu-i386
    - qemu-m68k
    - qemu-mips
    - qemu-mipsel
    - qemu-ppc
    - qemu-ppc64
    - qemu-ppc64abi32
    - qemu-sh4
    - qemu-sh4eb
    - qemu-sparc
    - qemu-sparc32plus
    - qemu-sparc64
    - qemu-x86_64

One thing I don't like too much about that is if you do a yum update
from the current package you lose all the stuff in qemu-system and
qemu-linux. I doubt that would cause anyone trouble in practice, though.

Cheers,
Mark.

[Daniel P. Berrange]

On Tue, Feb 03, 2009 at 10:34:12PM +0000, Mark McLoughlin wrote:
> (cc-ed a few people who were interested on irc)
>
> On Tue, 2009-02-03 at 18:11 -0200, Glauber Costa wrote:
> > Hi guys.
> >
> > I've built a qemu image in here:
> >
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151
> >
> > It contains the basic work to get qemu package updated. Basically,
> > we're talking about getting the qemu code from svn and creating multiple
> > packages, so one could grab just the architecture of interest.
> > Todo, is the creation of a meta-package to grab'em all at once.
>
> Okay, so this adds ~30 sub-packages. In retrospect, maybe ajax and co.
> have a point saying that's a bit excessive :-)
>
> One downside to so many sub-packages is that it means the total size of
> the RPMs is ~15Mb instead of ~10Mb.
>
> The on-disk size of the current qemu package is ~50Mb. What most people
> care about is /usr/bin/qemu (and in future qemu-kvm). Those bits only
> have a ~3Mb on-disk size. Each other target adds ~1.5Mb.
>
> How about splitting it this way:
>
> qemu:
>     - /usr/bin/qemu
>     - /usr/bin/qemu-system-x86_64 (only on x86_64, obviously)

Err, qemu-system-x86_64 exists just fine on 32-bit hosts.
> - qemu-kvm

This should go away altogether I hope. Until it does, just
keeping it whereever the x86 emulators are should be fine.
> - qemu-nbd

This one should be separate, since it is generally useful
even without any of the emulators - eg by Xen, or anyone
else wishing a nbd client for disk images.
> - docs
> - BIOSes
> - keymaps
> - init script
>
> qemu-img
>     - /usr/bin/qemu-img
>
> qemu-system:
> - qemu-system-arm
> - qemu-system-cris
> - qemu-system-i386

What's this for ?  'qemu' is always i386, and that shouldn;t
be changed because far too much assumes 'qemu' is always the
i386 binary.
> - qemu-system-m68k
> - qemu-system-mips
> - qemu-system-mips64
> - qemu-system-mips64el
> - qemu-system-mipsel
> - qemu-system-ppc
> - qemu-system-ppc64
> - qemu-system-ppcemb
> - qemu-system-sh4
> - qemu-system-sh4eb
> - qemu-system-sparc

Why not group them into related sets. eg, all PPC
variants in one package, all the 'sh' variants,
and all the 'mips' variants, and all x86 variants.
That'd compress the # of sub-RPMS to a small handful

qemu-system-x86
   qemu-system-mips
   qemu-system-sh
   qemu-system-ppc
   qemu-system-sparc
   qemu-system-68k
> qemu-linux:
> - qemu-alpha
> - qemu-arm
> - qemu-armeb
> - qemu-cris
> - qemu-debuginfo
> - qemu-i386
> - qemu-m68k
> - qemu-mips
> - qemu-mipsel
> - qemu-ppc
> - qemu-ppc64
> - qemu-ppc64abi32
> - qemu-sh4
> - qemu-sh4eb
> - qemu-sparc
> - qemu-sparc32plus
> - qemu-sparc64
> - qemu-x86_64

This seems reasonable - judging by how broken most of these
are, I find it hard to believe they're used much, so having
them in one sub-RPM ought to be fine.
> One thing I don't like too much about that is if you do a yum update
> from the current package you lose all the stuff in qemu-system and
> qemu-linux. I doubt that would cause anyone trouble in practice, though.

Just keep 'qemu' as a meta-package pulling in all the sub-RPMs.

People who only want the x86 bits will probably going from a starting
point of having the 'kvm' RPM installed. If we make system-system-x86
sub-RPM replace+obsolete 'kvm', then updates from people who just have
KVM will keep a lightweight install, and those who have the full QEMU
stack will not be broken either.

Daniel

[Mark McLoughlin]

On Tue, 2009-02-03 at 22:44 +0000, Daniel P. Berrange wrote:
> On Tue, Feb 03, 2009 at 10:34:12PM +0000, Mark McLoughlin wrote:
> > (cc-ed a few people who were interested on irc)
> >
> > On Tue, 2009-02-03 at 18:11 -0200, Glauber Costa wrote:
> > > Hi guys.
> > >
> > > I've built a qemu image in here:
> > >
> > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151
> > >
> > > It contains the basic work to get qemu package updated. Basically,
> > > we're talking about getting the qemu code from svn and creating multiple
> > > packages, so one could grab just the architecture of interest.
> > > Todo, is the creation of a meta-package to grab'em all at once.
> >
> > Okay, so this adds ~30 sub-packages. In retrospect, maybe ajax and co.
> > have a point saying that's a bit excessive :-)
> >
> > One downside to so many sub-packages is that it means the total size of
> > the RPMs is ~15Mb instead of ~10Mb.
> >
> > The on-disk size of the current qemu package is ~50Mb. What most people
> > care about is /usr/bin/qemu (and in future qemu-kvm). Those bits only
> > have a ~3Mb on-disk size. Each other target adds ~1.5Mb.
> >
> > How about splitting it this way:
> >
> > qemu:
> >     - /usr/bin/qemu
> >     - /usr/bin/qemu-system-x86_64 (only on x86_64, obviously)
>
> Err, qemu-system-x86_64 exists just fine on 32-bit hosts.

Yeah, what I was getting at was that the qemu package would only contain
an emulator for the native architecture. So, qemu wouldn't contain the
x86_64 emulator on 32 bit.

That was when I thought /usr/bin/qemu was just a hardlink to the native
system emulator.

Now that I see that /usr/bin/qemu is always i386 (even on e.g. ppc), I
don't like this idea of the base package containing just the native
emulator so much anymore.
> > - qemu-kvm
>
> This should go away altogether I hope. Until it does, just
> keeping it whereever the x86 emulators are should be fine.

Yep.
> > - qemu-nbd
>
> This one should be separate, since it is generally useful
> even without any of the emulators - eg by Xen, or anyone
> else wishing a nbd client for disk images.

Agree, but I'd be inclined not to bother until someone actually wants
it.
> > - docs
> > - BIOSes
> > - keymaps
> > - init script
> >
> > qemu-img
> >     - /usr/bin/qemu-img
> >
> > qemu-system:
> > - qemu-system-arm
> > - qemu-system-cris
> > - qemu-system-i386
>
> What's this for ?  'qemu' is always i386, and that shouldn;t
> be changed because far too much assumes 'qemu' is always the
> i386 binary.

Right, my mistake - the name was just taken from glommer's proposed
qemu-system-i386 package which would contain /usr/bin/qemu.
> > - qemu-system-m68k
> > - qemu-system-mips
> > - qemu-system-mips64
> > - qemu-system-mips64el
> > - qemu-system-mipsel
> > - qemu-system-ppc
> > - qemu-system-ppc64
> > - qemu-system-ppcemb
> > - qemu-system-sh4
> > - qemu-system-sh4eb
> > - qemu-system-sparc
>
> Why not group them into related sets. eg, all PPC
> variants in one package, all the 'sh' variants,
> and all the 'mips' variants, and all x86 variants.
> That'd compress the # of sub-RPMS to a small handful
>
> qemu-system-x86
>    qemu-system-mips
>    qemu-system-sh
>    qemu-system-ppc
>    qemu-system-sparc
>    qemu-system-68k

Sounds reasonable enough.
> > qemu-linux:
> > - qemu-alpha
> > - qemu-arm
> > - qemu-armeb
> > - qemu-cris
> > - qemu-debuginfo
> > - qemu-i386
> > - qemu-m68k
> > - qemu-mips
> > - qemu-mipsel
> > - qemu-ppc
> > - qemu-ppc64
> > - qemu-ppc64abi32
> > - qemu-sh4
> > - qemu-sh4eb
> > - qemu-sparc
> > - qemu-sparc32plus
> > - qemu-sparc64
> > - qemu-x86_64
>
> This seems reasonable - judging by how broken most of these
> are, I find it hard to believe they're used much, so having
> them in one sub-RPM ought to be fine.
> > One thing I don't like too much about that is if you do a yum update
> > from the current package you lose all the stuff in qemu-system and
> > qemu-linux. I doubt that would cause anyone trouble in practice, though.
>
> Just keep 'qemu' as a meta-package pulling in all the sub-RPMs.
>
> People who only want the x86 bits will probably going from a starting
> point of having the 'kvm' RPM installed. If we make system-system-x86
> sub-RPM replace+obsolete 'kvm', then updates from people who just have
> KVM will keep a lightweight install, and those who have the full QEMU
> stack will not be broken either.

Yeah, sounds good.

So, in summary:

qemu-img
    - /usr/bin/qemu-img

qemu-common:
    - /usr/bin/qemu-nbd
    - docs
    - BIOSes
    - keymaps
    - init script

qemu-system-x86:
    - /usr/bin/qemu
    - qemu-system-x86_64
    - /usr/bin/qemu-kvm

qemu-system-arm:
    - qemu-system-arm

qemu-system-cris:
    - qemu-system-cris

qemu-system-m68k
    - qemu-system-m68k

qemu-system-mips
    - qemu-system-mips
    - qemu-system-mips64
    - qemu-system-mips64el
    - qemu-system-mipsel

qemu-system-ppc 
    - qemu-system-ppc
    - qemu-system-ppc64
    - qemu-system-ppcemb

qemu-system-sh
    - qemu-system-sh4
    - qemu-system-sh4eb

qemu-system-sparc
    - qemu-system-sparc

qemu-linux:
    - qemu-alpha
    - qemu-arm
    - qemu-armeb
    - qemu-cris
    - qemu-debuginfo
    - qemu-i386
    - qemu-m68k
    - qemu-mips
    - qemu-mipsel
    - qemu-ppc
    - qemu-ppc64
    - qemu-ppc64abi32
    - qemu-sh4
    - qemu-sh4eb
    - qemu-sparc
    - qemu-sparc32plus
    - qemu-sparc64
    - qemu-x86_64

qemu:
    - meta package requiring all sub-packages

Cheers,
Mark.

[Daniel P. Berrange]

On Wed, Feb 04, 2009 at 08:41:56AM +0000, Mark McLoughlin wrote:
> So, in summary:
>
> qemu-img
>     - /usr/bin/qemu-img
>
> qemu-common:
>     - /usr/bin/qemu-nbd
>     - docs
>     - BIOSes
>     - keymaps
>     - init script
>
> qemu-system-x86:
>     - /usr/bin/qemu
>     - qemu-system-x86_64
>     - /usr/bin/qemu-kvm
>
> qemu-system-arm:
>     - qemu-system-arm
>
> qemu-system-cris:
>     - qemu-system-cris
>
> qemu-system-m68k
>     - qemu-system-m68k
>
> qemu-system-mips
>     - qemu-system-mips
>     - qemu-system-mips64
>     - qemu-system-mips64el
>     - qemu-system-mipsel
>
> qemu-system-ppc 
>     - qemu-system-ppc
>     - qemu-system-ppc64
>     - qemu-system-ppcemb
>
> qemu-system-sh
>     - qemu-system-sh4
>     - qemu-system-sh4eb
>
> qemu-system-sparc
>     - qemu-system-sparc
>
> qemu-linux:
>     - qemu-alpha
>     - qemu-arm
>     - qemu-armeb
>     - qemu-cris
>     - qemu-debuginfo
>     - qemu-i386
>     - qemu-m68k
>     - qemu-mips
>     - qemu-mipsel
>     - qemu-ppc
>     - qemu-ppc64
>     - qemu-ppc64abi32
>     - qemu-sh4
>     - qemu-sh4eb
>     - qemu-sparc
>     - qemu-sparc32plus
>     - qemu-sparc64
>     - qemu-x86_64
>
> qemu:
>     - meta package requiring all sub-packages

ACK, this gets my vote.

Daniel

[Glauber Costa]

On Wed, Feb 04, 2009 at 08:41:56AM +0000, Mark McLoughlin wrote:
> On Tue, 2009-02-03 at 22:44 +0000, Daniel P. Berrange wrote:
> > On Tue, Feb 03, 2009 at 10:34:12PM +0000, Mark McLoughlin wrote:
> > > (cc-ed a few people who were interested on irc)
> > >
> > > On Tue, 2009-02-03 at 18:11 -0200, Glauber Costa wrote:
> > > > Hi guys.
> > > >
> > > > I've built a qemu image in here:
> > > >
> > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151
> > > >
> > > > It contains the basic work to get qemu package updated. Basically,
> > > > we're talking about getting the qemu code from svn and creating multiple
> > > > packages, so one could grab just the architecture of interest.
> > > > Todo, is the creation of a meta-package to grab'em all at once.
> > >
> > > Okay, so this adds ~30 sub-packages. In retrospect, maybe ajax and co.
> > > have a point saying that's a bit excessive :-)
> > >
> > > One downside to so many sub-packages is that it means the total size of
> > > the RPMs is ~15Mb instead of ~10Mb.
> > >
> > > The on-disk size of the current qemu package is ~50Mb. What most people
> > > care about is /usr/bin/qemu (and in future qemu-kvm). Those bits only
> > > have a ~3Mb on-disk size. Each other target adds ~1.5Mb.
> > >
> > > How about splitting it this way:
> > >
> > > qemu:
> > >     - /usr/bin/qemu
> > >     - /usr/bin/qemu-system-x86_64 (only on x86_64, obviously)
> >
> > Err, qemu-system-x86_64 exists just fine on 32-bit hosts.
>
> Yeah, what I was getting at was that the qemu package would only contain
> an emulator for the native architecture. So, qemu wouldn't contain the
> x86_64 emulator on 32 bit.
>
> That was when I thought /usr/bin/qemu was just a hardlink to the native
> system emulator.
>
> Now that I see that /usr/bin/qemu is always i386 (even on e.g. ppc), I
> don't like this idea of the base package containing just the native
> emulator so much anymore.
> > > - qemu-kvm
> >
> > This should go away altogether I hope. Until it does, just
> > keeping it whereever the x86 emulators are should be fine.
>
> Yep.
> > > - qemu-nbd
> >
> > This one should be separate, since it is generally useful
> > even without any of the emulators - eg by Xen, or anyone
> > else wishing a nbd client for disk images.
>
> Agree, but I'd be inclined not to bother until someone actually wants
> it.
> > > - docs
> > > - BIOSes
> > > - keymaps
> > > - init script
> > >
> > > qemu-img
> > >     - /usr/bin/qemu-img
> > >
> > > qemu-system:
> > > - qemu-system-arm
> > > - qemu-system-cris
> > > - qemu-system-i386
> >
> > What's this for ?  'qemu' is always i386, and that shouldn;t
> > be changed because far too much assumes 'qemu' is always the
> > i386 binary.
>
> Right, my mistake - the name was just taken from glommer's proposed
> qemu-system-i386 package which would contain /usr/bin/qemu.
> > > - qemu-system-m68k
> > > - qemu-system-mips
> > > - qemu-system-mips64
> > > - qemu-system-mips64el
> > > - qemu-system-mipsel
> > > - qemu-system-ppc
> > > - qemu-system-ppc64
> > > - qemu-system-ppcemb
> > > - qemu-system-sh4
> > > - qemu-system-sh4eb
> > > - qemu-system-sparc
> >
> > Why not group them into related sets. eg, all PPC
> > variants in one package, all the 'sh' variants,
> > and all the 'mips' variants, and all x86 variants.
> > That'd compress the # of sub-RPMS to a small handful
> >
> > qemu-system-x86
> >    qemu-system-mips
> >    qemu-system-sh
> >    qemu-system-ppc
> >    qemu-system-sparc
> >    qemu-system-68k
>
> Sounds reasonable enough.
> > > qemu-linux:
> > > - qemu-alpha
> > > - qemu-arm
> > > - qemu-armeb
> > > - qemu-cris
> > > - qemu-debuginfo
> > > - qemu-i386
> > > - qemu-m68k
> > > - qemu-mips
> > > - qemu-mipsel
> > > - qemu-ppc
> > > - qemu-ppc64
> > > - qemu-ppc64abi32
> > > - qemu-sh4
> > > - qemu-sh4eb
> > > - qemu-sparc
> > > - qemu-sparc32plus
> > > - qemu-sparc64
> > > - qemu-x86_64
> >
> > This seems reasonable - judging by how broken most of these
> > are, I find it hard to believe they're used much, so having
> > them in one sub-RPM ought to be fine.
> > > One thing I don't like too much about that is if you do a yum update
> > > from the current package you lose all the stuff in qemu-system and
> > > qemu-linux. I doubt that would cause anyone trouble in practice, though.
> >
> > Just keep 'qemu' as a meta-package pulling in all the sub-RPMs.
> >
> > People who only want the x86 bits will probably going from a starting
> > point of having the 'kvm' RPM installed. If we make system-system-x86
> > sub-RPM replace+obsolete 'kvm', then updates from people who just have
> > KVM will keep a lightweight install, and those who have the full QEMU
> > stack will not be broken either.
>
> Yeah, sounds good.
>
> So, in summary:
>
> qemu-img
>     - /usr/bin/qemu-img
>
> qemu-common:
>     - /usr/bin/qemu-nbd
>     - docs
>     - BIOSes
>     - keymaps
>     - init script
>
> qemu-system-x86:
>     - /usr/bin/qemu
>     - qemu-system-x86_64
>     - /usr/bin/qemu-kvm
>
> qemu-system-arm:
>     - qemu-system-arm
>
> qemu-system-cris:
>     - qemu-system-cris
>
> qemu-system-m68k
>     - qemu-system-m68k
>
> qemu-system-mips
>     - qemu-system-mips
>     - qemu-system-mips64
>     - qemu-system-mips64el
>     - qemu-system-mipsel
>
> qemu-system-ppc 
>     - qemu-system-ppc
>     - qemu-system-ppc64
>     - qemu-system-ppcemb
>
> qemu-system-sh
>     - qemu-system-sh4
>     - qemu-system-sh4eb
>
> qemu-system-sparc
>     - qemu-system-sparc
>
> qemu-linux:

I believe qemu-user suits better upstream name usage. Other than that,
I think this proposal is sound.

Also, there has been a proposal by ajax in #fedora-devel to have a "qemu-native"
package, that would install native emu/virt for whatever architecture you're running at.

What do you guys think of this?

[Daniel P. Berrange]

On Wed, Feb 04, 2009 at 01:15:00PM -0200, Glauber Costa wrote:
> > So, in summary:
> >
> > qemu-img
> >     - /usr/bin/qemu-img
> >
> > qemu-common:
> >     - /usr/bin/qemu-nbd
> >     - docs
> >     - BIOSes
> >     - keymaps
> >     - init script
> >
> > qemu-system-x86:
> >     - /usr/bin/qemu
> >     - qemu-system-x86_64
> >     - /usr/bin/qemu-kvm
> >
> > qemu-system-arm:
> >     - qemu-system-arm
> >
> > qemu-system-cris:
> >     - qemu-system-cris
> >
> > qemu-system-m68k
> >     - qemu-system-m68k
> >
> > qemu-system-mips
> >     - qemu-system-mips
> >     - qemu-system-mips64
> >     - qemu-system-mips64el
> >     - qemu-system-mipsel
> >
> > qemu-system-ppc 
> >     - qemu-system-ppc
> >     - qemu-system-ppc64
> >     - qemu-system-ppcemb
> >
> > qemu-system-sh
> >     - qemu-system-sh4
> >     - qemu-system-sh4eb
> >
> > qemu-system-sparc
> >     - qemu-system-sparc
> >
> > qemu-linux:
>
> I believe qemu-user suits better upstream name usage. Other than that,
> I think this proposal is sound.
>
> Also, there has been a proposal by ajax in #fedora-devel to have a "qemu-native"
> package, that would install native emu/virt for whatever architecture you're running at.
>
> What do you guys think of this?

There's no need for a package for that. Just conditionally add

Provides: qemu-native

to the appropriate qemu-system-XXX  sub-RPM according to the arch you're 
building on.

Daniel

[Adam Jackson]

On Wed, 2009-02-04 at 15:17 +0000, Daniel P. Berrange wrote:
> > Also, there has been a proposal by ajax in #fedora-devel to have a "qemu-native"
> > package, that would install native emu/virt for whatever architecture you're running at.
> >
> > What do you guys think of this?
>
> There's no need for a package for that. Just conditionally add
>
> Provides: qemu-native
>
> to the appropriate qemu-system-XXX  sub-RPM according to the arch you're 
> building on.

Actually my proposal was to have qemu-native and qemu-everything-else.
On the basis that either you just want a vm and the native arch is good
enough, or you want a particular arch and therefore clearly have disk to
burn.

But, I'm no domain expert here.  If the typical qemu user is something
other than I've envisioned, then feel free to ignore me.

- ajax

[Glauber Costa]

On Wed, Feb 04, 2009 at 11:08:01AM -0500, Adam Jackson wrote:
> On Wed, 2009-02-04 at 15:17 +0000, Daniel P. Berrange wrote:
> > > Also, there has been a proposal by ajax in #fedora-devel to have a "qemu-native"
> > > package, that would install native emu/virt for whatever architecture you're running at.
> > >
> > > What do you guys think of this?
> >
> > There's no need for a package for that. Just conditionally add
> >
> > Provides: qemu-native
> >
> > to the appropriate qemu-system-XXX  sub-RPM according to the arch you're 
> > building on.
>
> Actually my proposal was to have qemu-native and qemu-everything-else.
> On the basis that either you just want a vm and the native arch is good
> enough, or you want a particular arch and therefore clearly have disk to
> burn.

Not always having disk to burn is the case.
You can easily fit an embedded system in a couple of mb, so the disk image
for an arm system, for instance, is likely to require this couple of mb too.

Going further, qemu-user-xxx (which is probably a qemu handler to watch porn)
needs no extra disk at all, since you'll be just running normal binaries
with an emulation layer.
> But, I'm no domain expert here.  If the typical qemu user is something
> other than I've envisioned, then feel free to ignore me.

We feel totally free to ignore you, because the internet is a free country, 
and we're free men ;-)

But your comments are always welcome.

[Mark McLoughlin]

On Wed, 2009-02-04 at 13:15 -0200, Glauber Costa wrote:
> On Wed, Feb 04, 2009 at 08:41:56AM +0000, Mark McLoughlin wrote:
> > qemu-linux:
>
> I believe qemu-user suits better upstream name usage. Other than that,
> I think this proposal is sound.

The reason I suggested qemu-linux is because I think QEMU's existing
naming sucks :-)

i.e. system/softmmu == "emulate a full machine" and user == "emulate the
linux kernel ABI"

system vs. linux makes it a little more sense, in my book.
> Also, there has been a proposal by ajax in #fedora-devel to have a "qemu-native"
> package, that would install native emu/virt for whatever architecture you're running at.
>
> What do you guys think of this?

As long it's just a Provides as danpb suggests, I don't mind ...

Cheers,
Mark.

[Glauber Costa]

On Wed, Feb 04, 2009 at 03:51:56PM +0000, Mark McLoughlin wrote:
> On Wed, 2009-02-04 at 13:15 -0200, Glauber Costa wrote:
> > On Wed, Feb 04, 2009 at 08:41:56AM +0000, Mark McLoughlin wrote:
> > > qemu-linux:
> >
> > I believe qemu-user suits better upstream name usage. Other than that,
> > I think this proposal is sound.
>
> The reason I suggested qemu-linux is because I think QEMU's existing
> naming sucks :-)
>
> i.e. system/softmmu == "emulate a full machine" and user == "emulate the
> linux kernel ABI"
>
> system vs. linux makes it a little more sense, in my book.

I agree with you 150e^7 %. Another example of naming suckiness on upstream is
the fact that "qemu" stands for qemu-system-i386 on whichever platform you're on,
even on a rotten potato.

However, this is a reason for us to go upstream and suggest name changes. In the mean
time, adopting a different name ourselves will just make matters more confusing.
> > Also, there has been a proposal by ajax in #fedora-devel to have a "qemu-native"
> > package, that would install native emu/virt for whatever architecture you're running at.
> >
> > What do you guys think of this?
>
> As long it's just a Provides as danpb suggests, I don't mind ...

I believe this is a good suggestion because of kvm. Users using exclusively
kvm will probably want to grab native emulation, whatever it is. And for the
record, kvm ppc is completely merged in qemu.

[Daniel P. Berrange]

On Wed, Feb 04, 2009 at 02:23:12PM -0200, Glauber Costa wrote:
> On Wed, Feb 04, 2009 at 03:51:56PM +0000, Mark McLoughlin wrote:
> > On Wed, 2009-02-04 at 13:15 -0200, Glauber Costa wrote:
> > > On Wed, Feb 04, 2009 at 08:41:56AM +0000, Mark McLoughlin wrote:
> > > > qemu-linux:
> > >
> > > I believe qemu-user suits better upstream name usage. Other than that,
> > > I think this proposal is sound.
> >
> > The reason I suggested qemu-linux is because I think QEMU's existing
> > naming sucks :-)
> >
> > i.e. system/softmmu == "emulate a full machine" and user == "emulate the
> > linux kernel ABI"
> >
> > system vs. linux makes it a little more sense, in my book.
>
> I agree with you 150e^7 %. Another example of naming suckiness on upstream is
> the fact that "qemu" stands for qemu-system-i386 on whichever platform you're on,
> even on a rotten potato.
>
> However, this is a reason for us to go upstream and suggest name changes. In the mean
> time, adopting a different name ourselves will just make matters more confusing.

No, we do *not* want to change the 'qemu' binary. Soo much stuff out
there knows & assumes 'qemu' is the i386 binary, and qemu-system-x86_64
is the x86_64 emulator.  If this were a brand new project, sure it'd
make sense to have 'qemu-system-i386', but at this stage we should not
be renaming binaries in wide use just for sake of naming prettiness.
> > > Also, there has been a proposal by ajax in #fedora-devel to have a "qemu-native"
> > > package, that would install native emu/virt for whatever architecture you're running at.
> > >
> > > What do you guys think of this?
> >
> > As long it's just a Provides as danpb suggests, I don't mind ...
>
> I believe this is a good suggestion because of kvm. Users using exclusively
> kvm will probably want to grab native emulation, whatever it is. And for the
> record, kvm ppc is completely merged in qemu.

Daniel

[Glauber Costa]

On Wed, Feb 04, 2009 at 04:28:27PM +0000, Daniel P. Berrange wrote:
> On Wed, Feb 04, 2009 at 02:23:12PM -0200, Glauber Costa wrote:
> > On Wed, Feb 04, 2009 at 03:51:56PM +0000, Mark McLoughlin wrote:
> > > On Wed, 2009-02-04 at 13:15 -0200, Glauber Costa wrote:
> > > > On Wed, Feb 04, 2009 at 08:41:56AM +0000, Mark McLoughlin wrote:
> > > > > qemu-linux:
> > > >
> > > > I believe qemu-user suits better upstream name usage. Other than that,
> > > > I think this proposal is sound.
> > >
> > > The reason I suggested qemu-linux is because I think QEMU's existing
> > > naming sucks :-)
> > >
> > > i.e. system/softmmu == "emulate a full machine" and user == "emulate the
> > > linux kernel ABI"
> > >
> > > system vs. linux makes it a little more sense, in my book.
> >
> > I agree with you 150e^7 %. Another example of naming suckiness on upstream is
> > the fact that "qemu" stands for qemu-system-i386 on whichever platform you're on,
> > even on a rotten potato.
> >
> > However, this is a reason for us to go upstream and suggest name changes. In the mean
> > time, adopting a different name ourselves will just make matters more confusing.
>
> No, we do *not* want to change the 'qemu' binary. Soo much stuff out
> there knows & assumes 'qemu' is the i386 binary, and qemu-system-x86_64
> is the x86_64 emulator.  If this were a brand new project, sure it'd
> make sense to have 'qemu-system-i386', but at this stage we should not
> be renaming binaries in wide use just for sake of naming prettiness.

I totally agree.

Just saying that renaming things in our packages is even worse.

[Daniel P. Berrange]

On Tue, Feb 03, 2009 at 06:11:31PM -0200, Glauber Costa wrote:
> Hi guys.
>
> I've built a qemu image in here:
>
> http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151
>
> It contains the basic work to get qemu package updated. Basically,
> we're talking about getting the qemu code from svn and creating multiple
> packages, so one could grab just the architecture of interest.
> Todo, is the creation of a meta-package to grab'em all at once.
>
> This is also the first step in merging qemu and kvm packages, which
> I'd like to do in two steps.
> This one.
> replace qemu-svn with kvm-userspace
>
> The later is not as trivial as it seems. Nobody exercices this path
> usually, and we're likely to find bugs that prevent the build to finish
> (Well, I tested, and there _are_ bugs ;-) ). But I believe we can have
> it sorted out.
>
> If no one has any major opposition to the state of things, I intend to
> commit it to CVS tomorrow (with some minor changes), and put it into
> rawhide so we can start having a more serious testing out of it.

The major blocker here is that it breaks upgrades. ie, upgrade to F11
and you end up with an install with no emulators present. 'qemu' should
stay as a package which pulls in everything - by Requires on all the
sub-RPMs. I agree with mark that there are too many sub-RPMs here.
I think we should group related archs, so that all x86 related system
emulators are in one sub-RPM, all mips together, all sh together, etc

Also, the /etc/init.d/qemu script will need updating to take account
of the fact that not all usermode emulators will be present - it should
only register binary format handlers for those which are actually
installed.

Also, you'll need to have the keymap files in a sub-RPM that all the
qemu-system-X packages can depend on, since the keymap data files are
needed for all the binaries which support SDL & VNC.

Daniel

[Glauber Costa]

On Tue, Feb 03, 2009 at 10:53:47PM +0000, Daniel P. Berrange wrote:
> On Tue, Feb 03, 2009 at 06:11:31PM -0200, Glauber Costa wrote:
> > Hi guys.
> >
> > I've built a qemu image in here:
> >
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151
> >
> > It contains the basic work to get qemu package updated. Basically,
> > we're talking about getting the qemu code from svn and creating multiple
> > packages, so one could grab just the architecture of interest.
> > Todo, is the creation of a meta-package to grab'em all at once.
> >
> > This is also the first step in merging qemu and kvm packages, which
> > I'd like to do in two steps.
> > This one.
> > replace qemu-svn with kvm-userspace
> >
> > The later is not as trivial as it seems. Nobody exercices this path
> > usually, and we're likely to find bugs that prevent the build to finish
> > (Well, I tested, and there _are_ bugs ;-) ). But I believe we can have
> > it sorted out.
> >
> > If no one has any major opposition to the state of things, I intend to
> > commit it to CVS tomorrow (with some minor changes), and put it into
> > rawhide so we can start having a more serious testing out of it.
>
> The major blocker here is that it breaks upgrades. ie, upgrade to F11
> and you end up with an install with no emulators present. 'qemu' should
> stay as a package which pulls in everything - by Requires on all the
> sub-RPMs. I agree with mark that there are too many sub-RPMs here.
> I think we should group related archs, so that all x86 related system
> emulators are in one sub-RPM, all mips together, all sh together, etc

Ok, so what you mean is a meta package "qemu" that just depends on all others
for folks that already has qemu installed? It makes sense. Do we plan on
carrying it on forever, or dropping it by F12?
> Also, the /etc/init.d/qemu script will need updating to take account
> of the fact that not all usermode emulators will be present - it should
> only register binary format handlers for those which are actually
> installed.

According to the current proposal, they will. We're splitting qemu-system into
multiple, but qemu-user will have all targets. So all we have to do is install
the init script only when installing the user package.

[Daniel P. Berrange]

On Wed, Feb 04, 2009 at 02:29:13PM -0200, Glauber Costa wrote:
> On Tue, Feb 03, 2009 at 10:53:47PM +0000, Daniel P. Berrange wrote:
> > On Tue, Feb 03, 2009 at 06:11:31PM -0200, Glauber Costa wrote:
> > > Hi guys.
> > >
> > > I've built a qemu image in here:
> > >
> > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151
> > >
> > > It contains the basic work to get qemu package updated. Basically,
> > > we're talking about getting the qemu code from svn and creating multiple
> > > packages, so one could grab just the architecture of interest.
> > > Todo, is the creation of a meta-package to grab'em all at once.
> > >
> > > This is also the first step in merging qemu and kvm packages, which
> > > I'd like to do in two steps.
> > > This one.
> > > replace qemu-svn with kvm-userspace
> > >
> > > The later is not as trivial as it seems. Nobody exercices this path
> > > usually, and we're likely to find bugs that prevent the build to finish
> > > (Well, I tested, and there _are_ bugs ;-) ). But I believe we can have
> > > it sorted out.
> > >
> > > If no one has any major opposition to the state of things, I intend to
> > > commit it to CVS tomorrow (with some minor changes), and put it into
> > > rawhide so we can start having a more serious testing out of it.
> >
> > The major blocker here is that it breaks upgrades. ie, upgrade to F11
> > and you end up with an install with no emulators present. 'qemu' should
> > stay as a package which pulls in everything - by Requires on all the
> > sub-RPMs. I agree with mark that there are too many sub-RPMs here.
> > I think we should group related archs, so that all x86 related system
> > emulators are in one sub-RPM, all mips together, all sh together, etc
>
> Ok, so what you mean is a meta package "qemu" that just depends on all others
> for folks that already has qemu installed? It makes sense. Do we plan on
> carrying it on forever, or dropping it by F12?

Plan to keep it indefinitely.
> > Also, the /etc/init.d/qemu script will need updating to take account
> > of the fact that not all usermode emulators will be present - it should
> > only register binary format handlers for those which are actually
> > installed.
>
> According to the current proposal, they will. We're splitting qemu-system into
> multiple, but qemu-user will have all targets. So all we have to do is install
> the init script only when installing the user package.

That simplifies things nicely

Daniel

[Mark McLoughlin]

On Wed, 2009-02-04 at 14:29 -0200, Glauber Costa wrote:
> On Tue, Feb 03, 2009 at 10:53:47PM +0000, Daniel P. Berrange wrote:
> > On Tue, Feb 03, 2009 at 06:11:31PM -0200, Glauber Costa wrote:
> > > Hi guys.
> > >
> > > I've built a qemu image in here:
> > >
> > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151
> > >
> > > It contains the basic work to get qemu package updated. Basically,
> > > we're talking about getting the qemu code from svn and creating multiple
> > > packages, so one could grab just the architecture of interest.
> > > Todo, is the creation of a meta-package to grab'em all at once.
> > >
> > > This is also the first step in merging qemu and kvm packages, which
> > > I'd like to do in two steps.
> > > This one.
> > > replace qemu-svn with kvm-userspace
> > >
> > > The later is not as trivial as it seems. Nobody exercices this path
> > > usually, and we're likely to find bugs that prevent the build to finish
> > > (Well, I tested, and there _are_ bugs ;-) ). But I believe we can have
> > > it sorted out.
> > >
> > > If no one has any major opposition to the state of things, I intend to
> > > commit it to CVS tomorrow (with some minor changes), and put it into
> > > rawhide so we can start having a more serious testing out of it.
> >
> > The major blocker here is that it breaks upgrades. ie, upgrade to F11
> > and you end up with an install with no emulators present. 'qemu' should
> > stay as a package which pulls in everything - by Requires on all the
> > sub-RPMs. I agree with mark that there are too many sub-RPMs here.
> > I think we should group related archs, so that all x86 related system
> > emulators are in one sub-RPM, all mips together, all sh together, etc
>
> Ok, so what you mean is a meta package "qemu" that just depends on all others
> for folks that already has qemu installed? It makes sense. Do we plan on
> carrying it on forever, or dropping it by F12?

There's no harm carrying it indefinitely.
> > Also, the /etc/init.d/qemu script will need updating to take account
> > of the fact that not all usermode emulators will be present - it should
> > only register binary format handlers for those which are actually
> > installed.
>
> According to the current proposal, they will. We're splitting qemu-system into
> multiple, but qemu-user will have all targets. So all we have to do is install
> the init script only when installing the user package.

Ah, and the initscript only applies to the user targets? That makes
perfect sense then.

Cheers,
Mark.

[Glauber Costa]

On Wed, Feb 04, 2009 at 04:30:49PM +0000, Mark McLoughlin wrote:
> On Wed, 2009-02-04 at 14:29 -0200, Glauber Costa wrote:
> > On Tue, Feb 03, 2009 at 10:53:47PM +0000, Daniel P. Berrange wrote:
> > > On Tue, Feb 03, 2009 at 06:11:31PM -0200, Glauber Costa wrote:
> > > > Hi guys.
> > > >
> > > > I've built a qemu image in here:
> > > >
> > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151
> > > >
> > > > It contains the basic work to get qemu package updated. Basically,
> > > > we're talking about getting the qemu code from svn and creating multiple
> > > > packages, so one could grab just the architecture of interest.
> > > > Todo, is the creation of a meta-package to grab'em all at once.
> > > >
> > > > This is also the first step in merging qemu and kvm packages, which
> > > > I'd like to do in two steps.
> > > > This one.
> > > > replace qemu-svn with kvm-userspace
> > > >
> > > > The later is not as trivial as it seems. Nobody exercices this path
> > > > usually, and we're likely to find bugs that prevent the build to finish
> > > > (Well, I tested, and there _are_ bugs ;-) ). But I believe we can have
> > > > it sorted out.
> > > >
> > > > If no one has any major opposition to the state of things, I intend to
> > > > commit it to CVS tomorrow (with some minor changes), and put it into
> > > > rawhide so we can start having a more serious testing out of it.
> > >
> > > The major blocker here is that it breaks upgrades. ie, upgrade to F11
> > > and you end up with an install with no emulators present. 'qemu' should
> > > stay as a package which pulls in everything - by Requires on all the
> > > sub-RPMs. I agree with mark that there are too many sub-RPMs here.
> > > I think we should group related archs, so that all x86 related system
> > > emulators are in one sub-RPM, all mips together, all sh together, etc
> >
> > Ok, so what you mean is a meta package "qemu" that just depends on all others
> > for folks that already has qemu installed? It makes sense. Do we plan on
> > carrying it on forever, or dropping it by F12?
>
> There's no harm carrying it indefinitely.
> > > Also, the /etc/init.d/qemu script will need updating to take account
> > > of the fact that not all usermode emulators will be present - it should
> > > only register binary format handlers for those which are actually
> > > installed.
> >
> > According to the current proposal, they will. We're splitting qemu-system into
> > multiple, but qemu-user will have all targets. So all we have to do is install
> > the init script only when installing the user package.
>
> Ah, and the initscript only applies to the user targets? That makes
> perfect sense then.

yeah. This script has only two purposes in life:
1) Allowing people to do ./my-binary-arm, and call the emulator under the hood
2) pursuit of happiness.

The later is not negatively affected by our new scheme.

[Glauber Costa]

On Tue, Feb 03, 2009 at 10:53:47PM +0000, Daniel P. Berrange wrote:
> On Tue, Feb 03, 2009 at 06:11:31PM -0200, Glauber Costa wrote:
> > Hi guys.
> >
> > I've built a qemu image in here:
> >
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151
> >
> > It contains the basic work to get qemu package updated. Basically,
> > we're talking about getting the qemu code from svn and creating multiple
> > packages, so one could grab just the architecture of interest.
> > Todo, is the creation of a meta-package to grab'em all at once.
> >
> > This is also the first step in merging qemu and kvm packages, which
> > I'd like to do in two steps.
> > This one.
> > replace qemu-svn with kvm-userspace
> >
> > The later is not as trivial as it seems. Nobody exercices this path
> > usually, and we're likely to find bugs that prevent the build to finish
> > (Well, I tested, and there _are_ bugs ;-) ). But I believe we can have
> > it sorted out.
> >
> > If no one has any major opposition to the state of things, I intend to
> > commit it to CVS tomorrow (with some minor changes), and put it into
> > rawhide so we can start having a more serious testing out of it.
>
> The major blocker here is that it breaks upgrades. ie, upgrade to F11
> and you end up with an install with no emulators present. 'qemu' should
> stay as a package which pulls in everything - by Requires on all the
> sub-RPMs. I agree with mark that there are too many sub-RPMs here.
> I think we should group related archs, so that all x86 related system
> emulators are in one sub-RPM, all mips together, all sh together, etc
>
> Also, the /etc/init.d/qemu script will need updating to take account
> of the fact that not all usermode emulators will be present - it should
> only register binary format handlers for those which are actually
> installed.
>
> Also, you'll need to have the keymap files in a sub-RPM that all the
> qemu-system-X packages can depend on, since the keymap data files are
> needed for all the binaries which support SDL & VNC.

Open question:

Do we want the requirements to match %{version}-%{release} ? 
(I believe so)

[Daniel P. Berrange]

On Wed, Feb 04, 2009 at 05:23:52PM -0200, Glauber Costa wrote:
> On Tue, Feb 03, 2009 at 10:53:47PM +0000, Daniel P. Berrange wrote:
> > On Tue, Feb 03, 2009 at 06:11:31PM -0200, Glauber Costa wrote:
> > > Hi guys.
> > >
> > > I've built a qemu image in here:
> > >
> > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151
> > >
> > > It contains the basic work to get qemu package updated. Basically,
> > > we're talking about getting the qemu code from svn and creating multiple
> > > packages, so one could grab just the architecture of interest.
> > > Todo, is the creation of a meta-package to grab'em all at once.
> > >
> > > This is also the first step in merging qemu and kvm packages, which
> > > I'd like to do in two steps.
> > > This one.
> > > replace qemu-svn with kvm-userspace
> > >
> > > The later is not as trivial as it seems. Nobody exercices this path
> > > usually, and we're likely to find bugs that prevent the build to finish
> > > (Well, I tested, and there _are_ bugs ;-) ). But I believe we can have
> > > it sorted out.
> > >
> > > If no one has any major opposition to the state of things, I intend to
> > > commit it to CVS tomorrow (with some minor changes), and put it into
> > > rawhide so we can start having a more serious testing out of it.
> >
> > The major blocker here is that it breaks upgrades. ie, upgrade to F11
> > and you end up with an install with no emulators present. 'qemu' should
> > stay as a package which pulls in everything - by Requires on all the
> > sub-RPMs. I agree with mark that there are too many sub-RPMs here.
> > I think we should group related archs, so that all x86 related system
> > emulators are in one sub-RPM, all mips together, all sh together, etc
> >
> > Also, the /etc/init.d/qemu script will need updating to take account
> > of the fact that not all usermode emulators will be present - it should
> > only register binary format handlers for those which are actually
> > installed.
> >
> > Also, you'll need to have the keymap files in a sub-RPM that all the
> > qemu-system-X packages can depend on, since the keymap data files are
> > needed for all the binaries which support SDL & VNC.
>
> Open question:
>
> Do we want the requirements to match %{version}-%{release} ?

Yes. Full V-R  Requires lines

Daniel

[Mark McLoughlin]

On Tue, 2009-02-03 at 18:11 -0200, Glauber Costa wrote:
> Hi guys.
>
> I've built a qemu image in here:
>
> http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151
>
> It contains the basic work to get qemu package updated. Basically,
> we're talking about getting the qemu code from svn

...

Another thing to watch out for is the guidelines for numbering
pre-release snapshots:

http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Pre-Release_package...

According to those, I think this should be 0.9.2-0.1.svn6392 rather than
0.9.1-svn6392.

Cheers,
Mark.

[Glauber Costa]

On Wed, Feb 04, 2009 at 05:43:55PM +0000, Mark McLoughlin wrote:
> On Tue, 2009-02-03 at 18:11 -0200, Glauber Costa wrote:
> > Hi guys.
> >
> > I've built a qemu image in here:
> >
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151
> >
> > It contains the basic work to get qemu package updated. Basically,
> > we're talking about getting the qemu code from svn
>
> ...
>
> Another thing to watch out for is the guidelines for numbering
> pre-release snapshots:
>
> http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Pre-Release_package...
>
> According to those, I think this should be 0.9.2-0.1.svn6392 rather than
> 0.9.1-svn6392.

Let's let it this way for now. I believe it's not yet certain that the new version
will be called 0.9.2, right?

[Mark McLoughlin]

On Wed, 2009-02-04 at 17:09 -0200, Glauber Costa wrote:
> On Wed, Feb 04, 2009 at 05:43:55PM +0000, Mark McLoughlin wrote:
> > On Tue, 2009-02-03 at 18:11 -0200, Glauber Costa wrote:
> > > Hi guys.
> > >
> > > I've built a qemu image in here:
> > >
> > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151
> > >
> > > It contains the basic work to get qemu package updated. Basically,
> > > we're talking about getting the qemu code from svn
> >
> > ...
> >
> > Another thing to watch out for is the guidelines for numbering
> > pre-release snapshots:
> >
> > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Pre-Release_package...
> >
> > According to those, I think this should be 0.9.2-0.1.svn6392 rather than
> > 0.9.1-svn6392.
>
> Let's let it this way for now.

Let's follow the guidelines carefully written by people with more
packaging experience than us :-)
> I believe it's not yet certain that the new version will be called
> 0.9.2, right?

I think the point is 0.9.2 > 0.9.1, not so much that 0.9.2 will be what
the next version will be called.

Cheers,
Mark.

[Dan Horák]

Mark McLoughlin píše v St 04. 02. 2009 v 17:43 +0000:
> On Tue, 2009-02-03 at 18:11 -0200, Glauber Costa wrote:
> > Hi guys.
> >
> > I've built a qemu image in here:
> >
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151
> >
> > It contains the basic work to get qemu package updated. Basically,
> > we're talking about getting the qemu code from svn
>
> ...
>
> Another thing to watch out for is the guidelines for numbering
> pre-release snapshots:
>
> http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Pre-Release_package...
>
> According to those, I think this should be 0.9.2-0.1.svn6392 rather than
> 0.9.1-svn6392.

And to be fully compliant it is should be 0.9.2-0.1.YYYYMMDDsvn6392,
where YYYYMMDD is the date of the revision 6392. See the "Snapshot
packages" paragraph a bit lower on the mentioned page.

Dan

[Glauber Costa]

On Wed, Feb 04, 2009 at 05:43:55PM +0000, Mark McLoughlin wrote:
> On Tue, 2009-02-03 at 18:11 -0200, Glauber Costa wrote:
> > Hi guys.
> >
> > I've built a qemu image in here:
> >
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151
> >
> > It contains the basic work to get qemu package updated. Basically,
> > we're talking about getting the qemu code from svn
>
> ...
>
> Another thing to watch out for is the guidelines for numbering
> pre-release snapshots:
>
> http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Pre-Release_package...
>
> According to those, I think this should be 0.9.2-0.1.svn6392 rather than
> 0.9.1-svn6392.
>
> Cheers,
> Mark.

I have a new test package in here:

http://koji.fedoraproject.org/koji/taskinfo?taskID=1105051

I haven't updated the name yet, but this is easy.
Apart from that, the .rpm are useless, as they don't include the firmware
images. (we don't want to ship the binary anyway, which was what current qemu
were doing).

I'll work on it tomorrow. I plan to grab the various pieces needed to compile
the firmwares and other binaries, and colocate them in the same srpm as qemu.

We can use separate packages if we must, but I don't see a big push for it.
We already separate the one which is most likely to be useful for someone else
(pxes).

But I'm open to suggestions.

[Daniel P. Berrange]

On Wed, Feb 04, 2009 at 08:12:10PM -0200, Glauber Costa wrote:
> On Wed, Feb 04, 2009 at 05:43:55PM +0000, Mark McLoughlin wrote:
> > On Tue, 2009-02-03 at 18:11 -0200, Glauber Costa wrote:
> > > Hi guys.
> > >
> > > I've built a qemu image in here:
> > >
> > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151
> > >
> > > It contains the basic work to get qemu package updated. Basically,
> > > we're talking about getting the qemu code from svn
> >
> > ...
> >
> > Another thing to watch out for is the guidelines for numbering
> > pre-release snapshots:
> >
> > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Pre-Release_package...
> >
> > According to those, I think this should be 0.9.2-0.1.svn6392 rather than
> > 0.9.1-svn6392.
> >
> > Cheers,
> > Mark.
>
> I have a new test package in here:
>
> http://koji.fedoraproject.org/koji/taskinfo?taskID=1105051
>
> I haven't updated the name yet, but this is easy.
> Apart from that, the .rpm are useless, as they don't include the firmware
> images. (we don't want to ship the binary anyway, which was what current qemu
> were doing).

This is going to be harder to address for QEMU than it was with KVM.
With KVM we only needed to build a native firmeware. For QEMU you
need to build a PPC firmware to go along with the x86 build of the
PPC emulator, etc. Not clear how we'd manage this very easily since
we don't have cross compilers for every QEMU arch.
> I'll work on it tomorrow. I plan to grab the various pieces needed to compile
> the firmwares and other binaries, and colocate them in the same srpm as qemu.
>
> We can use separate packages if we must, but I don't see a big push for it.
> We already separate the one which is most likely to be useful for someone else
> (pxes).
>
> But I'm open to suggestions.

Can you upload the src.rpm somewhere - when you do a scratch build
from the local src.rpm, koji annoyingly does not make it available
on the task page.

Daniel

[Dan Horák]

Daniel P. Berrange píše v Čt 05. 02. 2009 v 10:46 +0000:
> On Wed, Feb 04, 2009 at 08:12:10PM -0200, Glauber Costa wrote:
> > On Wed, Feb 04, 2009 at 05:43:55PM +0000, Mark McLoughlin wrote:
> > > On Tue, 2009-02-03 at 18:11 -0200, Glauber Costa wrote:
> > > > Hi guys.
> > > >
> > > > I've built a qemu image in here:
> > > >
> > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151
> > > >
> > > > It contains the basic work to get qemu package updated. Basically,
> > > > we're talking about getting the qemu code from svn
> > >
> > > ...
> > >
> > > Another thing to watch out for is the guidelines for numbering
> > > pre-release snapshots:
> > >
> > > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Pre-Release_package...
> > >
> > > According to those, I think this should be 0.9.2-0.1.svn6392 rather than
> > > 0.9.1-svn6392.
> > >
> > > Cheers,
> > > Mark.
> >
> > I have a new test package in here:
> >
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=1105051
> >
> > I haven't updated the name yet, but this is easy.
> > Apart from that, the .rpm are useless, as they don't include the firmware
> > images. (we don't want to ship the binary anyway, which was what current qemu
> > were doing).
>
> This is going to be harder to address for QEMU than it was with KVM.
> With KVM we only needed to build a native firmeware. For QEMU you
> need to build a PPC firmware to go along with the x86 build of the
> PPC emulator, etc. Not clear how we'd manage this very easily since
> we don't have cross compilers for every QEMU arch.
> > I'll work on it tomorrow. I plan to grab the various pieces needed to compile
> > the firmwares and other binaries, and colocate them in the same srpm as qemu.
> >
> > We can use separate packages if we must, but I don't see a big push for it.
> > We already separate the one which is most likely to be useful for someone else
> > (pxes).
> >
> > But I'm open to suggestions.
>
> Can you upload the src.rpm somewhere - when you do a scratch build
> from the local src.rpm, koji annoyingly does not make it available
> on the task page.

It is available - see the "Descendent Tasks"
http://koji.fedoraproject.org/koji/taskinfo?taskID=1105052

http://koji.fedoraproject.org/koji/getfile?taskID=1105052&name=qemu-0.9....

Dan

[Daniel P. Berrange]

On Thu, Feb 05, 2009 at 11:58:20AM +0100, Dan Hor?k wrote:
> Daniel P. Berrange pí??e v ??t 05. 02. 2009 v 10:46 +0000:
> > > I'll work on it tomorrow. I plan to grab the various pieces needed to compile
> > > the firmwares and other binaries, and colocate them in the same srpm as qemu.
> > >
> > > We can use separate packages if we must, but I don't see a big push for it.
> > > We already separate the one which is most likely to be useful for someone else
> > > (pxes).
> > >
> > > But I'm open to suggestions.
> >
> > Can you upload the src.rpm somewhere - when you do a scratch build
> > from the local src.rpm, koji annoyingly does not make it available
> > on the task page.
>
> It is available - see the "Descendent Tasks"
> http://koji.fedoraproject.org/koji/taskinfo?taskID=1105052

Hmm, that's very annoying - its only appearing under the 'ppc' task (which
I never look at because PPC is irrelevant) and not appearing under the
i386 / x86_64 arch tasks.

Daniel

[Dan Horák]

Daniel P. Berrange píše v Čt 05. 02. 2009 v 11:07 +0000:
> On Thu, Feb 05, 2009 at 11:58:20AM +0100, Dan Hor?k wrote:
> > Daniel P. Berrange pí??e v ??t 05. 02. 2009 v 10:46 +0000:
> > > > I'll work on it tomorrow. I plan to grab the various pieces needed to compile
> > > > the firmwares and other binaries, and colocate them in the same srpm as qemu.
> > > >
> > > > We can use separate packages if we must, but I don't see a big push for it.
> > > > We already separate the one which is most likely to be useful for someone else
> > > > (pxes).
> > > >
> > > > But I'm open to suggestions.
> > >
> > > Can you upload the src.rpm somewhere - when you do a scratch build
> > > from the local src.rpm, koji annoyingly does not make it available
> > > on the task page.
> >
> > It is available - see the "Descendent Tasks"
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=1105052
>
> Hmm, that's very annoying - its only appearing under the 'ppc' task (which
> I never look at because PPC is irrelevant) and not appearing under the
> i386 / x86_64 arch tasks.

It is true that didn't check the i386 or x86_64 tasks, I tried just the
first one. Do you want to open a bug against koji or should I?

Dan

[Daniel P. Berrange]

On Thu, Feb 05, 2009 at 12:11:50PM +0100, Dan Hor?k wrote:
> Daniel P. Berrange pí??e v ??t 05. 02. 2009 v 11:07 +0000:
> > On Thu, Feb 05, 2009 at 11:58:20AM +0100, Dan Hor?k wrote:
> > > Daniel P. Berrange pí??e v ??t 05. 02. 2009 v 10:46 +0000:
> > > > > I'll work on it tomorrow. I plan to grab the various pieces needed to compile
> > > > > the firmwares and other binaries, and colocate them in the same srpm as qemu.
> > > > >
> > > > > We can use separate packages if we must, but I don't see a big push for it.
> > > > > We already separate the one which is most likely to be useful for someone else
> > > > > (pxes).
> > > > >
> > > > > But I'm open to suggestions.
> > > >
> > > > Can you upload the src.rpm somewhere - when you do a scratch build
> > > > from the local src.rpm, koji annoyingly does not make it available
> > > > on the task page.
> > >
> > > It is available - see the "Descendent Tasks"
> > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1105052
> >
> > Hmm, that's very annoying - its only appearing under the 'ppc' task (which
> > I never look at because PPC is irrelevant) and not appearing under the
> > i386 / x86_64 arch tasks.
>
> It is true that didn't check the i386 or x86_64 tasks, I tried just the
> first one. Do you want to open a bug against koji or should I?

I'll let you.

I would rather have expected the front page

"Source: cli-build/1233783416.520371.CKwnmXVw/qemu-0.9.1-svn6392.fc11.src.rpm"

to be a hyperlink to the src.rpm

Daniel

[Dan Horák]

Daniel P. Berrange píše v Čt 05. 02. 2009 v 11:20 +0000:
> On Thu, Feb 05, 2009 at 12:11:50PM +0100, Dan Hor?k wrote:
> > Daniel P. Berrange pí??e v ??t 05. 02. 2009 v 11:07 +0000:
> > > On Thu, Feb 05, 2009 at 11:58:20AM +0100, Dan Hor?k wrote:
> > > > Daniel P. Berrange pí??e v ??t 05. 02. 2009 v 10:46 +0000:
> > > > > > I'll work on it tomorrow. I plan to grab the various pieces needed to compile
> > > > > > the firmwares and other binaries, and colocate them in the same srpm as qemu.
> > > > > >
> > > > > > We can use separate packages if we must, but I don't see a big push for it.
> > > > > > We already separate the one which is most likely to be useful for someone else
> > > > > > (pxes).
> > > > > >
> > > > > > But I'm open to suggestions.
> > > > >
> > > > > Can you upload the src.rpm somewhere - when you do a scratch build
> > > > > from the local src.rpm, koji annoyingly does not make it available
> > > > > on the task page.
> > > >
> > > > It is available - see the "Descendent Tasks"
> > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1105052
> > >
> > > Hmm, that's very annoying - its only appearing under the 'ppc' task (which
> > > I never look at because PPC is irrelevant) and not appearing under the
> > > i386 / x86_64 arch tasks.
> >
> > It is true that didn't check the i386 or x86_64 tasks, I tried just the
> > first one. Do you want to open a bug against koji or should I?
>
> I'll let you.
>
> I would rather have expected the front page
>
> "Source: cli-build/1233783416.520371.CKwnmXVw/qemu-0.9.1-svn6392.fc11.src.rpm"
>
> to be a hyperlink to the src.rpm

Done as https://fedorahosted.org/koji/ticket/129

Dan

[Glauber Costa]

On Thu, Feb 05, 2009 at 10:46:09AM +0000, Daniel P. Berrange wrote:
> On Wed, Feb 04, 2009 at 08:12:10PM -0200, Glauber Costa wrote:
> > On Wed, Feb 04, 2009 at 05:43:55PM +0000, Mark McLoughlin wrote:
> > > On Tue, 2009-02-03 at 18:11 -0200, Glauber Costa wrote:
> > > > Hi guys.
> > > >
> > > > I've built a qemu image in here:
> > > >
> > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151
> > > >
> > > > It contains the basic work to get qemu package updated. Basically,
> > > > we're talking about getting the qemu code from svn
> > >
> > > ...
> > >
> > > Another thing to watch out for is the guidelines for numbering
> > > pre-release snapshots:
> > >
> > > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Pre-Release_package...
> > >
> > > According to those, I think this should be 0.9.2-0.1.svn6392 rather than
> > > 0.9.1-svn6392.
> > >
> > > Cheers,
> > > Mark.
> >
> > I have a new test package in here:
> >
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=1105051
> >
> > I haven't updated the name yet, but this is easy.
> > Apart from that, the .rpm are useless, as they don't include the firmware
> > images. (we don't want to ship the binary anyway, which was what current qemu
> > were doing).
>
> This is going to be harder to address for QEMU than it was with KVM.
> With KVM we only needed to build a native firmeware. For QEMU you
> need to build a PPC firmware to go along with the x86 build of the
> PPC emulator, etc. Not clear how we'd manage this very easily since
> we don't have cross compilers for every QEMU arch.

Ok, no cross compile, but we do have a pcc build sys, don't we?

Because this is the way we do for the pxe roms. If we build on i386, we just build
from sources. If we are in another arch, we pick a binary. The difference is
that is's not the binary provided by qemu, but the very own we built for
i386.

[Daniel P. Berrange]

On Thu, Feb 05, 2009 at 09:08:07AM -0200, Glauber Costa wrote:
> On Thu, Feb 05, 2009 at 10:46:09AM +0000, Daniel P. Berrange wrote:
> > On Wed, Feb 04, 2009 at 08:12:10PM -0200, Glauber Costa wrote:
> > > I haven't updated the name yet, but this is easy.
> > > Apart from that, the .rpm are useless, as they don't include the firmware
> > > images. (we don't want to ship the binary anyway, which was what current qemu
> > > were doing).
> >
> > This is going to be harder to address for QEMU than it was with KVM.
> > With KVM we only needed to build a native firmeware. For QEMU you
> > need to build a PPC firmware to go along with the x86 build of the
> > PPC emulator, etc. Not clear how we'd manage this very easily since
> > we don't have cross compilers for every QEMU arch.
>
> Ok, no cross compile, but we do have a pcc build sys, don't we?
>
> Because this is the way we do for the pxe roms. If we build on i386, we just build
> from sources. If we are in another arch, we pick a binary. The difference is
> that is's not the binary provided by qemu, but the very own we built for
> i386.

Ewww. I just looked at the etherboot.spec file - that's gross :-)

So every time you update the RPM build, you have to build twice. Once
to get the correct new i386/x86_64 build. And then change the tar.gz
with the prebuilt binaries, and build the RPM again, so that PPC gets
done correctly ?

So we can do x86 and ppc in Fedora with this trick. The sparc BIOS would
need us to build in the Sparc secondary arch, and then import it back in
to the main arch build system.

Daniel

[Glauber Costa]

On Thu, Feb 05, 2009 at 11:15:48AM +0000, Daniel P. Berrange wrote:
> On Thu, Feb 05, 2009 at 09:08:07AM -0200, Glauber Costa wrote:
> > On Thu, Feb 05, 2009 at 10:46:09AM +0000, Daniel P. Berrange wrote:
> > > On Wed, Feb 04, 2009 at 08:12:10PM -0200, Glauber Costa wrote:
> > > > I haven't updated the name yet, but this is easy.
> > > > Apart from that, the .rpm are useless, as they don't include the firmware
> > > > images. (we don't want to ship the binary anyway, which was what current qemu
> > > > were doing).
> > >
> > > This is going to be harder to address for QEMU than it was with KVM.
> > > With KVM we only needed to build a native firmeware. For QEMU you
> > > need to build a PPC firmware to go along with the x86 build of the
> > > PPC emulator, etc. Not clear how we'd manage this very easily since
> > > we don't have cross compilers for every QEMU arch.
> >
> > Ok, no cross compile, but we do have a pcc build sys, don't we?
> >
> > Because this is the way we do for the pxe roms. If we build on i386, we just build
> > from sources. If we are in another arch, we pick a binary. The difference is
> > that is's not the binary provided by qemu, but the very own we built for
> > i386.
>
> Ewww. I just looked at the etherboot.spec file - that's gross :-)
>
> So every time you update the RPM build, you have to build twice. Once
> to get the correct new i386/x86_64 build. And then change the tar.gz
> with the prebuilt binaries, and build the RPM again, so that PPC gets
> done correctly ?
>
> So we can do x86 and ppc in Fedora with this trick. The sparc BIOS would
> need us to build in the Sparc secondary arch, and then import it back in
> to the main arch build system.

yeah, it's totally gross, but I believe it's the best alternative we have
so far. We lack rpm support for a more decent arrangement.

However, if this is the case, I'd strongly suggest we do alternate packages.
Doing it all inside qemu would severely complicate it. Most of bioses are
projects on their own anyway.

[Mark McLoughlin]

On Thu, 2009-02-05 at 10:46 +0000, Daniel P. Berrange wrote:
> On Wed, Feb 04, 2009 at 08:12:10PM -0200, Glauber Costa wrote:
> > On Wed, Feb 04, 2009 at 05:43:55PM +0000, Mark McLoughlin wrote:
> > > On Tue, 2009-02-03 at 18:11 -0200, Glauber Costa wrote:
> > > > Hi guys.
> > > >
> > > > I've built a qemu image in here:
> > > >
> > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151
> > > >
> > > > It contains the basic work to get qemu package updated. Basically,
> > > > we're talking about getting the qemu code from svn
> > >
> > > ...
> > >
> > > Another thing to watch out for is the guidelines for numbering
> > > pre-release snapshots:
> > >
> > > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Pre-Release_package...
> > >
> > > According to those, I think this should be 0.9.2-0.1.svn6392 rather than
> > > 0.9.1-svn6392.
> > >
> > > Cheers,
> > > Mark.
> >
> > I have a new test package in here:
> >
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=1105051
> >
> > I haven't updated the name yet, but this is easy.
> > Apart from that, the .rpm are useless, as they don't include the firmware
> > images. (we don't want to ship the binary anyway, which was what current qemu
> > were doing).
>
> This is going to be harder to address for QEMU than it was with KVM.
> With KVM we only needed to build a native firmeware. For QEMU you
> need to build a PPC firmware to go along with the x86 build of the
> PPC emulator, etc. Not clear how we'd manage this very easily since
> we don't have cross compilers for every QEMU arch.
> > I'll work on it tomorrow. I plan to grab the various pieces needed to compile
> > the firmwares and other binaries, and colocate them in the same srpm as qemu.
> >
> > We can use separate packages if we must, but I don't see a big push for it.
> > We already separate the one which is most likely to be useful for someone else
> > (pxes).
> >
> > But I'm open to suggestions.
>
> Can you upload the src.rpm somewhere - when you do a scratch build
> from the local src.rpm, koji annoyingly does not make it available
> on the task page.

It does, but it's kinda hard to spot it:

http://koji.fedoraproject.org/koji/getfile?taskID=1105052&name=qemu-0.9....

Cheers,
Mark.