hi, yesterday i try to rebuild fedora packages for rhel/centos/epel-5 and i've got a few comments. i try to build these packages: bochs-bios-2.3.8-0.6.git36989b0d2.fc11.src.rpm etherboot-5.4.4-13.fc11.src.rpm gtk-vnc-0.3.8-8.fc11.src.rpm libvirt-0.6.3-10.fc11.src.rpm openbios-1.0-1.fc11.src.rpm python-virtinst-0.400.3-8.fc11.src.rpm qemu-0.10.4-5.fc11.src.rpm qemu-0.10.50-4.kvm86.fc12.src.rpm vgabios-0.6-0.6.c.fc12.src.rpm virt-manager-0.7.0-4.fc11.src.rpm virt-viewer-0.0.3-5.fc11.src.rpm
- first of all i really don't like to trick used in bochs-bios and etherboot. these can be build on ix86 and has only noarch subpackages. why not just define as noarch for the main packages and and exclude/includearch only for ix86? it'd be cleaner and easier. i saw that you're waiting for a rpm bugfix, but currently (and probably later) it also won't compile on x86_64 in koji since it's exclude all ix86 packages! what's more it _is_ build on x86_64 just do not create any result binary rpm which more annoying!
- on the other hand in this case bochs-bios subpackage called bochs-bios-data (since you can't call it bochs-bios cause of the above:-( and of course qemu-system-x86 wrongly requires bochs-bios in stead of bochs-bios-data. it's a bug!
- bochs-bios install only /usr/share/bochs/BIOS-bochs-latest /usr/share/bochs/BIOS-bochs-legacy but qemu requires BIOS-bochs-kvm which not exist anywhere. a link should have to be create for any of the above file as BIOS-bochs-kvm either in bochs-bios or in qemu. anyway why bochs-bios pulled out of qemu when it's also in qemu?
- libvirt BR qemu. why? which require all qemu package which require openbios-ppc, vgabios, bochs-bios-data, etherboot-*. so this is a dependency hell. imho it'd be useful to clean up!
- openbios build only for the given arch, but qemu requires all qemu-system* so it can't be build eg on i386 for i386 since libvirt BR qemu!
- in more package the in the subpackage "Group field must be present in package", so group name missing:-( and bacuse of this none of openbios, bochs-bios and etherboot can be build on epel:-(
- this /etc/libvirt/qemu/networks/default.xml makes me crazy. since blow up my current guest's configs:-(((
On Fri, May 22, 2009 at 11:23:01AM +0200, Farkas Levente wrote:
hi, yesterday i try to rebuild fedora packages for rhel/centos/epel-5 and i've got a few comments. i try to build these packages:
Are you actually going to import them into EL-5? I discussed with lkundrak already doing that for just qemu.
[...]
- in more package the in the subpackage "Group field must be present in
package", so group name missing:-( and bacuse of this none of openbios, bochs-bios and etherboot can be build on epel:-(
Has RPM changed so it no longer requires the Group field? It was a pretty useless field anyway.
Rich.
Richard W.M. Jones wrote:
On Fri, May 22, 2009 at 11:23:01AM +0200, Farkas Levente wrote:
hi, yesterday i try to rebuild fedora packages for rhel/centos/epel-5 and i've got a few comments. i try to build these packages:
Are you actually going to import them into EL-5? I discussed with lkundrak already doing that for just qemu.
most people use my repo on centos for kvm and i just try to update th repo, but there are far too many problems. may be next week i spend another week with this:-(
[...]
- in more package the in the subpackage "Group field must be present in
package", so group name missing:-( and bacuse of this none of openbios, bochs-bios and etherboot can be build on epel:-(
Has RPM changed so it no longer requires the Group field? It was a pretty useless field anyway.
but make these package not be able to rebuild:-( or would be useful to update rhel's rpm too...
On Fri, May 22, 2009 at 11:23:01AM +0200, Farkas Levente wrote:
- libvirt BR qemu. why? which require all qemu package which require
openbios-ppc, vgabios, bochs-bios-data, etherboot-*. so this is a dependency hell. imho it'd be useful to clean up!
The build process wants QEMU so its a BR. There is no dependancy hell here unless you're using the wrong tools. mock trivially pull in the chain of deps as needed during build, so there's nothing to 'clean up'.
- in more package the in the subpackage "Group field must be present in
package", so group name missing:-( and bacuse of this none of openbios, bochs-bios and etherboot can be build on epel:-(
Just add the 'Group' field to the spec in EPEL branch of CVS.
- this /etc/libvirt/qemu/networks/default.xml makes me crazy. since blow
up my current guest's configs:-(((
That will only be created if it doesn't exist, so it will not impact things unless you have created another network with a clashing IP address range, which is trivially avoidable.
Daniel
Daniel P. Berrange wrote:
On Fri, May 22, 2009 at 11:23:01AM +0200, Farkas Levente wrote:
- libvirt BR qemu. why? which require all qemu package which require
openbios-ppc, vgabios, bochs-bios-data, etherboot-*. so this is a dependency hell. imho it'd be useful to clean up!
The build process wants QEMU so its a BR. There is no dependancy hell here unless you're using the wrong tools. mock trivially pull in the chain of deps as needed during build, so there's nothing to 'clean up'.
i can't build (since i don't have ppc) but i need it for qemu-system-ppc which is needed by qemu which is needed by libvirt:-( are you sure all of these req and br are required?
- this /etc/libvirt/qemu/networks/default.xml makes me crazy. since blow
up my current guest's configs:-(((
That will only be created if it doesn't exist, so it will not impact things unless you have created another network with a clashing IP address range, which is trivially avoidable.
but if it's not exist then it's created and all guest will suddenly have a new interface which may interfere with the existing network which is very hard to find the reason!:-(
On Fri, May 22, 2009 at 01:23:06PM +0200, Farkas Levente wrote:
Daniel P. Berrange wrote:
On Fri, May 22, 2009 at 11:23:01AM +0200, Farkas Levente wrote:
- libvirt BR qemu. why? which require all qemu package which require
openbios-ppc, vgabios, bochs-bios-data, etherboot-*. so this is a dependency hell. imho it'd be useful to clean up!
The build process wants QEMU so its a BR. There is no dependancy hell here unless you're using the wrong tools. mock trivially pull in the chain of deps as needed during build, so there's nothing to 'clean up'.
i can't build (since i don't have ppc) but i need it for qemu-system-ppc which is needed by qemu which is needed by libvirt:-( are you sure all of these req and br are required?
You're not making any sense here. You don't need a ppc host, to build qemu-system-ppc. All host architectures can build all QEMU targets, you're not restricted to matching host & qemu target, with the exception of KVM.
- this /etc/libvirt/qemu/networks/default.xml makes me crazy. since blow
up my current guest's configs:-(((
That will only be created if it doesn't exist, so it will not impact things unless you have created another network with a clashing IP address range, which is trivially avoidable.
but if it's not exist then it's created and all guest will suddenly have a new interface which may interfere with the existing network which is very hard to find the reason!:-(
This only creates a bridge on the host. No guest is connected to this bridge unless you configure it that way. So merely having the config does not affect existing guests
Daniel
Daniel P. Berrange wrote:
On Fri, May 22, 2009 at 01:23:06PM +0200, Farkas Levente wrote:
Daniel P. Berrange wrote:
On Fri, May 22, 2009 at 11:23:01AM +0200, Farkas Levente wrote:
- libvirt BR qemu. why? which require all qemu package which require
openbios-ppc, vgabios, bochs-bios-data, etherboot-*. so this is a dependency hell. imho it'd be useful to clean up!
The build process wants QEMU so its a BR. There is no dependancy hell here unless you're using the wrong tools. mock trivially pull in the chain of deps as needed during build, so there's nothing to 'clean up'.
i can't build (since i don't have ppc) but i need it for qemu-system-ppc which is needed by qemu which is needed by libvirt:-( are you sure all of these req and br are required?
You're not making any sense here. You don't need a ppc host, to build qemu-system-ppc. All host architectures can build all QEMU targets, you're not restricted to matching host & qemu target, with the exception of KVM.
i wrote above i can't build openbios-ppc which required by qemu etc...so i can't build libvirt:-(
- this /etc/libvirt/qemu/networks/default.xml makes me crazy. since blow
up my current guest's configs:-(((
That will only be created if it doesn't exist, so it will not impact things unless you have created another network with a clashing IP address range, which is trivially avoidable.
but if it's not exist then it's created and all guest will suddenly have a new interface which may interfere with the existing network which is very hard to find the reason!:-(
This only creates a bridge on the host. No guest is connected to this bridge unless you configure it that way. So merely having the config does not affect existing guests
ok. i don't know since yesterday i wasn't more time for this, but until now there was no such interface in guest as virbr0 and after testing the new packages i have. may be there are other reason for this but that also comes from one of these new packages.
On Fri, May 22, 2009 at 02:04:28PM +0200, Farkas Levente wrote:
Daniel P. Berrange wrote:
On Fri, May 22, 2009 at 01:23:06PM +0200, Farkas Levente wrote:
Daniel P. Berrange wrote:
On Fri, May 22, 2009 at 11:23:01AM +0200, Farkas Levente wrote:
- libvirt BR qemu. why? which require all qemu package which require
openbios-ppc, vgabios, bochs-bios-data, etherboot-*. so this is a dependency hell. imho it'd be useful to clean up!
The build process wants QEMU so its a BR. There is no dependancy hell here unless you're using the wrong tools. mock trivially pull in the chain of deps as needed during build, so there's nothing to 'clean up'.
i can't build (since i don't have ppc) but i need it for qemu-system-ppc which is needed by qemu which is needed by libvirt:-( are you sure all of these req and br are required?
You're not making any sense here. You don't need a ppc host, to build qemu-system-ppc. All host architectures can build all QEMU targets, you're not restricted to matching host & qemu target, with the exception of KVM.
i wrote above i can't build openbios-ppc which required by qemu etc...so i can't build libvirt:-(
Then just disable the qemu-system-ppc bits in QEMU. It really isn't hard to remove the ppc sub-RPM and change the target-list for the QEMU build to turn off ppc.
Daniel
Daniel P. Berrange wrote:
On Fri, May 22, 2009 at 02:04:28PM +0200, Farkas Levente wrote:
Daniel P. Berrange wrote:
On Fri, May 22, 2009 at 01:23:06PM +0200, Farkas Levente wrote:
Daniel P. Berrange wrote:
On Fri, May 22, 2009 at 11:23:01AM +0200, Farkas Levente wrote:
- libvirt BR qemu. why? which require all qemu package which require
openbios-ppc, vgabios, bochs-bios-data, etherboot-*. so this is a dependency hell. imho it'd be useful to clean up!
The build process wants QEMU so its a BR. There is no dependancy hell here unless you're using the wrong tools. mock trivially pull in the chain of deps as needed during build, so there's nothing to 'clean up'.
i can't build (since i don't have ppc) but i need it for qemu-system-ppc which is needed by qemu which is needed by libvirt:-( are you sure all of these req and br are required?
You're not making any sense here. You don't need a ppc host, to build qemu-system-ppc. All host architectures can build all QEMU targets, you're not restricted to matching host & qemu target, with the exception of KVM.
i wrote above i can't build openbios-ppc which required by qemu etc...so i can't build libvirt:-(
Then just disable the qemu-system-ppc bits in QEMU. It really isn't hard to remove the ppc sub-RPM and change the target-list for the QEMU build to turn off ppc.
this means even on a primary platform ix86 these packages can't be rebuild without modification. wouldn't be easier to put back openbios-ppc, vgabios, bochs-bios-data, etherboot into qemu?
On Fri, May 22, 2009 at 09:41:01PM +0200, Farkas Levente wrote:
Daniel P. Berrange wrote:
On Fri, May 22, 2009 at 02:04:28PM +0200, Farkas Levente wrote:
Daniel P. Berrange wrote:
On Fri, May 22, 2009 at 01:23:06PM +0200, Farkas Levente wrote:
Daniel P. Berrange wrote:
On Fri, May 22, 2009 at 11:23:01AM +0200, Farkas Levente wrote: > - libvirt BR qemu. why? which require all qemu package which require > openbios-ppc, vgabios, bochs-bios-data, etherboot-*. so this is a > dependency hell. imho it'd be useful to clean up! The build process wants QEMU so its a BR. There is no dependancy hell here unless you're using the wrong tools. mock trivially pull in the chain of deps as needed during build, so there's nothing to 'clean up'.
i can't build (since i don't have ppc) but i need it for qemu-system-ppc which is needed by qemu which is needed by libvirt:-( are you sure all of these req and br are required?
You're not making any sense here. You don't need a ppc host, to build qemu-system-ppc. All host architectures can build all QEMU targets, you're not restricted to matching host & qemu target, with the exception of KVM.
i wrote above i can't build openbios-ppc which required by qemu etc...so i can't build libvirt:-(
Then just disable the qemu-system-ppc bits in QEMU. It really isn't hard to remove the ppc sub-RPM and change the target-list for the QEMU build to turn off ppc.
this means even on a primary platform ix86 these packages can't be rebuild without modification. wouldn't be easier to put back openbios-ppc, vgabios, bochs-bios-data, etherboot into qemu?
These packages were split out from QEMU because, they were duplicating functionality in Bochs & QEMU packages. It was also not clear that they were in compliance with the license, because there was no corresponding source to the pre-built binary being shipped. You fundamentally can't build many of these packages on all archs. This last reason is the real key bit. openbios-ppc can only be built from source on a PPC host, so we need to build on PPC, and then include that built binary on a 2nd build on all other archs. The only practical way todo this is if the BIOS is separate from QEMU, otherwise you end up havig to rebuild far too much stuff each time.
Daniel
Daniel P. Berrange wrote:
On Fri, May 22, 2009 at 09:41:01PM +0200, Farkas Levente wrote:
Daniel P. Berrange wrote:
On Fri, May 22, 2009 at 02:04:28PM +0200, Farkas Levente wrote:
Daniel P. Berrange wrote:
On Fri, May 22, 2009 at 01:23:06PM +0200, Farkas Levente wrote:
Daniel P. Berrange wrote: > On Fri, May 22, 2009 at 11:23:01AM +0200, Farkas Levente wrote: >> - libvirt BR qemu. why? which require all qemu package which require >> openbios-ppc, vgabios, bochs-bios-data, etherboot-*. so this is a >> dependency hell. imho it'd be useful to clean up! > The build process wants QEMU so its a BR. There is no dependancy hell > here unless you're using the wrong tools. mock trivially pull in the > chain of deps as needed during build, so there's nothing to 'clean up'. i can't build (since i don't have ppc) but i need it for qemu-system-ppc which is needed by qemu which is needed by libvirt:-( are you sure all of these req and br are required?
You're not making any sense here. You don't need a ppc host, to build qemu-system-ppc. All host architectures can build all QEMU targets, you're not restricted to matching host & qemu target, with the exception of KVM.
i wrote above i can't build openbios-ppc which required by qemu etc...so i can't build libvirt:-(
Then just disable the qemu-system-ppc bits in QEMU. It really isn't hard to remove the ppc sub-RPM and change the target-list for the QEMU build to turn off ppc.
this means even on a primary platform ix86 these packages can't be rebuild without modification. wouldn't be easier to put back openbios-ppc, vgabios, bochs-bios-data, etherboot into qemu?
These packages were split out from QEMU because, they were duplicating functionality in Bochs & QEMU packages. It was also not clear that they were in compliance with the license, because there was no corresponding source to the pre-built binary being shipped. You fundamentally can't build many of these packages on all archs. This last reason is the real key bit. openbios-ppc can only be built from source on a PPC host, so we need to build on PPC, and then include that built binary on a 2nd build on all other archs. The only practical way todo this is if the BIOS is separate from QEMU, otherwise you end up havig to rebuild far too much stuff each time.
and if qemu do not require qemu-system-ppc which do not require openbios-ppc then those part which will run on ix86 can be build on ix86...
-
Daniel P. Berrange -
Farkas Levente -
Richard W.M. Jones