Description of problem: KVM now builds and runs on ia64. I am supplying patches needed patches here. Changes involve: 1. spec file changes 2. code changes 3. EFI firmware image (a.k.a "bios") which is open source but difficult to build so is being provided as a binary.
Created attachment 310688 [details] specfile changes to build kvm onia64
Created attachment 310689 [details] patch for kvm code to build on ia64
Created attachment 310690 [details] binary firmware bits for kvm on ia64 This is available from: hg clone http://xenbits.xensource.com/ext/efi-vfirmware.hg
Under *no* circumstances can this pre-built binary blob be distributed in Fedora. It is built from GPL code, and thus all redistribution must have corresponding source. Distributing this binary blob in its current form is a GPL violation. If a ia64 firmware is required for KVM, then it is neccessary to provide a formal release tar.gz (or a tar.gz from a known SCM snapshot) containing *only* source files. The binary firmware must then be built from this source tar.gz using only tools present in Fedora, as part of the normal KVM RPM build process in Koji, so we can guarentee that the resulting binary matches the sources we are distributing.
Doug, Besides the firmware issue Dan already talked about, please let me understand the need for this. The first patch is clearly to our spec file only, but regarding the second one, why is this deviation from upstream needed? Aren't all the bits necessary to make it run in kvm-70, or 71?
(In reply to comment #4) > Under *no* circumstances can this pre-built binary blob be distributed in > Fedora. It is built from GPL code, and thus all redistribution must have > corresponding source. Distributing this binary blob in its current form is a GPL > violation. > > > If a ia64 firmware is required for KVM, then it is neccessary to provide a > formal release tar.gz (or a tar.gz from a known SCM snapshot) containing *only* > source files. The binary firmware must then be built from this source tar.gz > using only tools present in Fedora, as part of the normal KVM RPM build process > in Koji, so we can guarentee that the resulting binary matches the sources we > are distributing. > > How are we dealing with the binary images in the srpm at: kvm-70/qemu/pc-bios? Those are binary images with only a reference to where to get the source in the README. I understand the concern over binary images and would not have submitted this binary file if I had not seen those.
(In reply to comment #5) > Doug, > > Besides the firmware issue Dan already talked about, please let me understand > the need for this. The first patch is clearly to our spec file only, but > regarding the second one, why is this deviation from upstream needed? > > Aren't all the bits necessary to make it run in kvm-70, or 71? The ia64 specific kvm-70 bits do not yet build with gcc-4.3 so part of the patch is to put back the code that used to be there to use gcc34 for the qemu bits. There are also a few other minor build issues with kvm-70 which are in the ia64 kvm git tree which are included here. Once the gcc-4.3 build issues on the ia64 code are resolved much of this special patch will go away.
WRT to comment #6, I'd have to check up on the terms of the existing PC BIOS files, but if they are GPL and don't have any explicit exception to allow distribution of the binaries, then we will need to fix the package so that we also distribute the source of those. So unless the EFI BIOS has an explicit exception for the GPL covered bits to allow binary re-distribution we need to build from source.
I wasn't sure, so I went checking. It may be a big problem for qemu package, but not for kvm. We do distribute the sources of the bios. In the toplevel directory, there are directories bios/ vgabios/, etc. They build a new bios at every kvm build, and deploy them at the right places. The Makefile says: bios: $(MAKE) -C $@ cp bios/BIOS-bochs-latest qemu/pc-bios/bios.bin vgabios: $(MAKE) -C $@ cp vgabios/VGABIOS-lgpl-latest.bin qemu/pc-bios/vgabios.bin cp vgabios/VGABIOS-lgpl-latest.cirrus.bin qemu/pc-bios/vgabios-cirrus.bin extboot: $(MAKE) -C $@ if ! [ -f qemu/pc-bios/extboot.bin ] \ || ! cmp -s qemu/pc-bios/extboot.bin extboot/extboot.bin; then \ cp extboot/extboot.bin qemu/pc-bios/extboot.bin; \ fi
KVM-71 (and the current rawhide package, KVM-72 too), should have the IA64 bits by default. I tried adding ia64 to the arches directive, but it seems koji does not have ia64 build hosts. But the source should be there. Are you willing to build it? Can you confirm that it solves the problem for you? thanks.
(In reply to comment #10) > KVM-71 (and the current rawhide package, KVM-72 too), should have the IA64 bits > by default. > > I tried adding ia64 to the arches directive, but it seems koji does not have > ia64 build hosts. But the source should be there. Are you willing to build it? > Can you confirm that it solves the problem for you? > > thanks. Sorry for the slow response. Was out on vacation for the last 2 weeks. I will give the latest source a try. One issue we had with the upstream code however is the ia64 specific bits did not compile with the latest version of gcc so we may still need to have an ia64 specific patch for fedora to use gcc-compat. Also, the other issue regarding the binary firmware bits. I looked at the license on that and it appears that license allows binary redistribution. We can distribute the source but we will not be able to build it in koji at this point as the build process is very tricky to set up and includes some non free tools. If we are in compliance with the license the firmware bits are distributed on do we still have Fedora rules that would prevent this? If so I don't think it would be a huge deal to not include the firmware and just have a readme that points the user to how to obtain it. putting this in needinfo from me so I don't forget to look at this.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This info is pretty much out of date by now. Since we are not currently building Fedora on ia64 I am closing it and will open a fresh one in the future when builds begin again.