Re: [gentoo-dev] Separately buildable binary blobs
Doug Goldstein wrote: sys-firmware/ipxe, sys-firmware/seabios, sys-firmware/sgabios, sys-firmware/vgabios .. So basically, how important is it to keep supporting these separately buildable blobs knowing that it might slow the release of QEMU within our own tree. Each of those sys-firmware/ packages have quite significant use cases well outside of QEMU. Note also that in particular SeaBIOS but possibly the others too are really recommended to build with a separate, known-good, toolchain - even if you're building for the same platform that you run on. The buildgcc[1] script from coreboot generates such a toolchain. USE=vanilla gcc+binutils may or may not work. I have certainly experienced USE=-vanilla gcc+binutils output broken machine code for coreboot and SeaBIOS. I have been unable to take time to investigate and report those breakages anywhere so they may still output broken machine code because of whatever patches. //Peter [1] http://review.coreboot.org/gitweb?p=coreboot.git;a=tree;f=util/crossgcc
Re: [gentoo-dev] Separately buildable binary blobs
On Sun, Jan 20, 2013 at 10:45 PM, Peter Stuge pe...@stuge.se wrote: Doug Goldstein wrote: sys-firmware/ipxe, sys-firmware/seabios, sys-firmware/sgabios, sys-firmware/vgabios .. So basically, how important is it to keep supporting these separately buildable blobs knowing that it might slow the release of QEMU within our own tree. Each of those sys-firmware/ packages have quite significant use cases well outside of QEMU. Aware of that, but no one added them to the tree prior to me adding them to the tree for QEMU. Since then I haven't had a single user report a bug or contact me in any way about using it outside of QEMU. The one exception is myself with ipxe as I use that at work to provide something similar to boot.fedoraproject.org but on a much grander scale. Note also that in particular SeaBIOS but possibly the others too are really recommended to build with a separate, known-good, toolchain - even if you're building for the same platform that you run on. Aware of that as well, you'll notice we have always defaulted to using pre-built binaries of the releases by Kevin O'Connor the upstream maintainer and for any bugs reported with QEMU if someone built their own BIOS I always tell them they need to try with the upstream blob. The point of my original post was we go through the effort to ALLOW users to build their own binary blobs but is it really necessary as part of our culture? If this was Debian the answer would obviously be yes. -- Doug Goldstein
Re: [gentoo-dev] Separately buildable binary blobs
Doug Goldstein wrote: we go through the effort to ALLOW users to build their own binary blobs but is it really necessary as part of our culture? I don't think that question can be answered? The way I see it either someone maintains those packages, or not. I'd be sad to see them go, but am not a dev so can not do anything about it. //Peter
[gentoo-dev] Separately buildable binary blobs
How important are separately buildable binary blobs? Rather than speak in terms of app/foo and app/bar, I'll just come out and say its app-emulation/qemu. Due to the nature of the package it relies on firmware blobs to emulate certain aspects of the system (e.g. BIOS). I've been working on making each of the binary blobs buildable and adding them to the tree e.g. sys-firmware/ipxe, sys-firmware/seabios, sys-firmware/sgabios, sys-firmware/vgabios. Unfortunately QEMU upstream keeps their own repos of the various components and for each release builds their own and commits it within their repo. They ship with these pre-built blobs and that is what they install by default. The result is from the true package upstreams there often is not a release that works with QEMU. For example, QEMU 1.3.0 requires a git revision of SeaBIOS. So basically, how important is it to keep supporting these separately buildable blobs knowing that it might slow the release of QEMU within our own tree. -- Doug Goldstein
