* [gentoo-dev] Separately buildable binary blobs
@ 2013-01-19 1:34 Doug Goldstein
2013-01-21 4:45 ` Peter Stuge
0 siblings, 1 reply; 4+ messages in thread
From: Doug Goldstein @ 2013-01-19 1:34 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [gentoo-dev] Separately buildable binary blobs
2013-01-19 1:34 [gentoo-dev] Separately buildable binary blobs Doug Goldstein
@ 2013-01-21 4:45 ` Peter Stuge
2013-01-21 5:17 ` Doug Goldstein
0 siblings, 1 reply; 4+ messages in thread
From: Peter Stuge @ 2013-01-21 4:45 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [gentoo-dev] Separately buildable binary blobs
2013-01-21 4:45 ` Peter Stuge
@ 2013-01-21 5:17 ` Doug Goldstein
2013-01-21 5:22 ` Peter Stuge
0 siblings, 1 reply; 4+ messages in thread
From: Doug Goldstein @ 2013-01-21 5:17 UTC (permalink / raw
To: gentoo-dev
On Sun, Jan 20, 2013 at 10:45 PM, Peter Stuge <peter@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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [gentoo-dev] Separately buildable binary blobs
2013-01-21 5:17 ` Doug Goldstein
@ 2013-01-21 5:22 ` Peter Stuge
0 siblings, 0 replies; 4+ messages in thread
From: Peter Stuge @ 2013-01-21 5:22 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-01-21 5:22 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-01-19 1:34 [gentoo-dev] Separately buildable binary blobs Doug Goldstein
2013-01-21 4:45 ` Peter Stuge
2013-01-21 5:17 ` Doug Goldstein
2013-01-21 5:22 ` Peter Stuge
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox