Hi all,
QEMU release tarballs contain a handful of prebuilt roms that enable various features and emulation targets. We currently don't package any of these roms.
For things like seabios, sgabios, vgabios, and ipxe, we can chuck out the prebuilt data and depend on natively built Fedora packages. However a handful of the roms require building on non-x86 (ppc, sparc32/64, s390). Being able to package the prebuilt roms would enable us to distribute working qemu-system-{ppc*,sparc*,s390*}
Does this sound reasonable, and if so, what's the process for getting this approved? I'm looking at:
http://fedoraproject.org/wiki/Packaging:Guidelines#No_inclusion_of_pre-built... http://fedoraproject.org/wiki/Licensing:Main#Binary_Firmware
And it sounds like this is a reasonable case for exception, but just want to confirm. Here's all the details I can gather about the roms:
/usr/share/qemu/openbios-ppc /usr/share/qemu/openbios-sparc32 /usr/share/qemu/openbios-sparc64 Usage : Needed for emulation of certain machines for those architectures. Source : http://git.qemu.org/openbios.git License : GPLv2 http://git.qemu.org/?p=openbios.git;a=blob;f=COPYING
/usr/share/qemu/slof.bin Usage : Needed for PPC pSeries emulation Source : http://git.qemu.org/SLOF.git License : BSD http://git.qemu.org/?p=SLOF.git;a=blob;f=LICENSE
/usr/share/qemu/palcode-clipper Usage : Needed for s390 emulation Source : http://repo.or.cz/w/qemu-palcode.git License : GPLv2 http://repo.or.cz/w/qemu-palcode.git/blob/HEAD:/COPYING
/usr/share/qemu/s390-zipl.rom Usage : Needed for s390 emulation Source : http://repo.or.cz/w/s390-tools.git License : GPl http://repo.or.cz/w/s390-tools.git/blob/HEAD:/LICENSE
/usr/share/qemu/ppc_rom.bin Usage : Needed for PPC PREP emulation Source : https://github.com/tycho/openhackware License : GPLv2 https://github.com/tycho/openhackware/blob/master/COPYING
And some compiled device trees. Maybe these just count as program data though?
/usr/share/qemu/bamboo.dtb Usage : Needed for PPC bamboo machine. Source : http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=ar... License : GPLv2
/usr/share/qemu/petalogix-ml605.dtb /usr/share/qemu/petalogix-s3adsp1800.dtb Usage : Needed for microblaze emulation Source : Hmm, actually I can't seem to find any canonical source :(
Thanks, Cole
On 07/24/2012 03:10 PM, Cole Robinson wrote:
Hi all,
QEMU release tarballs contain a handful of prebuilt roms that enable various features and emulation targets. We currently don't package any of these roms.
For things like seabios, sgabios, vgabios, and ipxe, we can chuck out the prebuilt data and depend on natively built Fedora packages. However a handful of the roms require building on non-x86 (ppc, sparc32/64, s390). Being able to package the prebuilt roms would enable us to distribute working qemu-system-{ppc*,sparc*,s390*}
Does this sound reasonable, and if so, what's the process for getting this approved? I'm looking at:
I really do wish we could come up with a clever way to build these on the native platforms, but I also understand how difficult that is, and I really don't want to stonewall on that.
Perhaps this merits a specific exception. How about something like this:
=== QEMU ROMS === Whenever possible, ROMS implementing BIOS or Firmware for QEMU system targets must be built from source on the intended architecture. However, in many situations, this is not practical or possible. As a special exception, prebuilt binary ROMS implementing BIOS or Firmware for QEMU system targets may be included in Fedora Packages, as long as the corresponding source code is also included in the Source RPM package.
Thoughts?
/usr/share/qemu/petalogix-ml605.dtb /usr/share/qemu/petalogix-s3adsp1800.dtb Usage : Needed for microblaze emulation Source : Hmm, actually I can't seem to find any canonical source :(
This one seems more troublesome than the others, but since .dtb files seem to be just device trees without any real "code", we can safely treat them as content.
~tom
== Fedora Project
On Tue, Jul 24, 2012 at 03:26:24PM -0400, Tom Callaway wrote:
I really do wish we could come up with a clever way to build these on the native platforms, but I also understand how difficult that is, and I really don't want to stonewall on that.
On the BZ we discussed cross-compiling them. It would require approx. 2 extra packages per architecture, ie. a cross gcc and a cross binutils (since it's firmware, no libc is required of course).
Rich.
Richard W.M. Jones píše v Út 24. 07. 2012 v 20:48 +0100:
On Tue, Jul 24, 2012 at 03:26:24PM -0400, Tom Callaway wrote:
I really do wish we could come up with a clever way to build these on the native platforms, but I also understand how difficult that is, and I really don't want to stonewall on that.
On the BZ we discussed cross-compiling them. It would require approx. 2 extra packages per architecture, ie. a cross gcc and a cross binutils (since it's firmware, no libc is required of course).
the cross-gcc and cross-binutils all(?) Linux kernel arches are already there, no libgcc yet, but it shouldn't be an issue for firmwares
Dan
On Tue, Jul 24, 2012 at 10:24:38PM +0200, Dan Horák wrote:
Richard W.M. Jones píše v Út 24. 07. 2012 v 20:48 +0100:
On Tue, Jul 24, 2012 at 03:26:24PM -0400, Tom Callaway wrote:
I really do wish we could come up with a clever way to build these on the native platforms, but I also understand how difficult that is, and I really don't want to stonewall on that.
On the BZ we discussed cross-compiling them. It would require approx. 2 extra packages per architecture, ie. a cross gcc and a cross binutils (since it's firmware, no libc is required of course).
the cross-gcc and cross-binutils all(?) Linux kernel arches are already there, no libgcc yet, but it shouldn't be an issue for firmwares
Cole, I think we ought to look into this before trying to get an exception. Let's discuss tomorrow.
Rich.
On Tue, Jul 24, 2012 at 10:11:12PM +0100, Richard W.M. Jones wrote:
Cole, I think we ought to look into this before trying to get an exception. Let's discuss tomorrow.
FWIW I was able to build SLOF easily using the cross compiler and upstream sources:
sudo yum install gcc-powerpc64-linux-gnu git clone https://github.com/dgibson/SLOF.git cd SLOF export CROSS="powerpc64-linux-gnu-" make js2x
I didn't try any other ROMs yet, but it does look like this problem isn't insurmountable.
Rich.
On 07/24/2012 03:26 PM, Tom Callaway wrote:
On 07/24/2012 03:10 PM, Cole Robinson wrote:
Hi all,
QEMU release tarballs contain a handful of prebuilt roms that enable various features and emulation targets. We currently don't package any of these roms.
For things like seabios, sgabios, vgabios, and ipxe, we can chuck out the prebuilt data and depend on natively built Fedora packages. However a handful of the roms require building on non-x86 (ppc, sparc32/64, s390). Being able to package the prebuilt roms would enable us to distribute working qemu-system-{ppc*,sparc*,s390*}
Does this sound reasonable, and if so, what's the process for getting this approved? I'm looking at:
I really do wish we could come up with a clever way to build these on the native platforms, but I also understand how difficult that is, and I really don't want to stonewall on that.
Perhaps this merits a specific exception. How about something like this:
=== QEMU ROMS === Whenever possible, ROMS implementing BIOS or Firmware for QEMU system targets must be built from source on the intended architecture. However, in many situations, this is not practical or possible. As a special exception, prebuilt binary ROMS implementing BIOS or Firmware for QEMU system targets may be included in Fedora Packages, as long as the corresponding source code is also included in the Source RPM package.
Thoughts?
Sounds good to me. I'll wait for that block (or similar) to end up on the wiki before making any package changes. Thanks Tom!
- Cole
On 07/24/2012 03:53 PM, Cole Robinson wrote:
On 07/24/2012 03:26 PM, Tom Callaway wrote:
On 07/24/2012 03:10 PM, Cole Robinson wrote:
Hi all,
QEMU release tarballs contain a handful of prebuilt roms that enable various features and emulation targets. We currently don't package any of these roms.
For things like seabios, sgabios, vgabios, and ipxe, we can chuck out the prebuilt data and depend on natively built Fedora packages. However a handful of the roms require building on non-x86 (ppc, sparc32/64, s390). Being able to package the prebuilt roms would enable us to distribute working qemu-system-{ppc*,sparc*,s390*}
Does this sound reasonable, and if so, what's the process for getting this approved? I'm looking at:
I really do wish we could come up with a clever way to build these on the native platforms, but I also understand how difficult that is, and I really don't want to stonewall on that.
Perhaps this merits a specific exception. How about something like this:
=== QEMU ROMS === Whenever possible, ROMS implementing BIOS or Firmware for QEMU system targets must be built from source on the intended architecture. However, in many situations, this is not practical or possible. As a special exception, prebuilt binary ROMS implementing BIOS or Firmware for QEMU system targets may be included in Fedora Packages, as long as the corresponding source code is also included in the Source RPM package.
Thoughts?
Sounds good to me. I'll wait for that block (or similar) to end up on the wiki before making any package changes. Thanks Tom!
I suppose we could still do this exception, because I know cross-compilers don't always work properly/sanely. That said, I'd still encourage efforts to build these files from source in all "practical" cases.
~tom
== Fedora Project
On 07/24/2012 02:26 PM, Tom Callaway wrote:
On 07/24/2012 03:10 PM, Cole Robinson wrote:
Hi all,
QEMU release tarballs contain a handful of prebuilt roms that enable various features and emulation targets. We currently don't package any of these roms.
For things like seabios, sgabios, vgabios, and ipxe, we can chuck out the prebuilt data and depend on natively built Fedora packages. However a handful of the roms require building on non-x86 (ppc, sparc32/64, s390). Being able to package the prebuilt roms would enable us to distribute working qemu-system-{ppc*,sparc*,s390*}
Does this sound reasonable, and if so, what's the process for getting this approved? I'm looking at:
I really do wish we could come up with a clever way to build these on the native platforms, but I also understand how difficult that is, and I really don't want to stonewall on that.
Perhaps this merits a specific exception. How about something like this:
=== QEMU ROMS === Whenever possible, ROMS implementing BIOS or Firmware for QEMU system targets must be built from source on the intended architecture. However, in many situations, this is not practical or possible. As a special exception, prebuilt binary ROMS implementing BIOS or Firmware for QEMU system targets may be included in Fedora Packages, as long as the corresponding source code is also included in the Source RPM package.
Thoughts?
Sounds reasonable enough to me, I could support that.
-- rex
SLOF: https://bugzilla.redhat.com/show_bug.cgi?id=844737
openbios: https://bugzilla.redhat.com/show_bug.cgi?id=844748
This is as far as we can go for now, because cross-gcc doesn't support 32 bit ppc or sparc.
I need to look at modifying cross-gcc to support those, although it'd be interesting to hear from the maintainers why exactly those variants are missing in the first place.
Rich.
On Tue, Jul 31, 2012 at 04:51:30PM +0100, Richard W.M. Jones wrote:
SLOF: https://bugzilla.redhat.com/show_bug.cgi?id=844737
openbios: https://bugzilla.redhat.com/show_bug.cgi?id=844748
This is as far as we can go for now, because cross-gcc doesn't support 32 bit ppc or sparc.
Apparently it does, using <prefix>-gcc -m32. I'll modify the openbios package to build 32 bit versions.
Rich.
packaging@lists.fedoraproject.org
-
Cole Robinson -
Dan Horák -
Rex Dieter -
Richard W.M. Jones -
Tom Callaway