Re: [Qemu-devel] [Qemu-stable] [SeaBIOS] problems with freeBSD

[Michael Tokarev <mjt@tls.msk.ru>]

07.03.2013 15:56, Gerd Hoffmann wrote:

>> Just a note, or an "alternative opinion", so to say.  In Debian, we have
>> a social contract which, among other things, ensures that the binaries
>> you, as a user, get, comes with source which you can modify on the
>> system you installed.  This requires, for example, that all binaries
>> shipped are actually built from the corresponding source, and that
>> no blobs from whatever other sources are used, ever.
> 
> That is perfectly fine.  How to you handle ppc firmware for x86 hosts
> btw?  Build on ppc buildhost and ship as noarch package?  Or do you do
> cross compiler builds, so that users can patch+rebuild it on their x86
> host too?

"Foreign" firmware handling is an unsolved issue.  Yes, basically,
it is built on the corresponding build machine (eg, openbios-ppc is
built on a ppc machine) and shipped as "noarch" package.  The same
is for X86 seabios/vgabios/etc stuff actually.

So technically this is a violation in some way.  However, that same
ppc firmware actually can be rebuilt in a (qemu) virtual machine with
the same debian release installed.

That's why I say it is basically unsolved issue -- the "solution"
isn't actuall a solution but a workaround instead.

For added "fun", currently we ship optionroms from qemu in seabios
source package, exactly because of this reason - seabios is what
gets built on x86 only and is distributed on as "noarch" binary,
while qemu is built on all architectures.

And for another fun, we've several broken qemu architectures in
Debian at the moment -- s390 and ppc64 are missing firmwares
exactly because of the difficulties building them, despite the
fact they're shipping in upstream qemu tarball.

>> We don't even ship any upstream blobs in the debian qemu _source_
>> package: we repack upstream qemu.tar.gz by removing these blobs.
> 
> That's a bit over the top for my taste as the release tarballs include
> both source and blobs.

Yes this is a bit extremistic, so to say.  But this is the same
base principle of Debian: we should ensure and demonstrate it all
is buildable.  Just mere presence of a blob in a tarball is already
suspicious :)

>   Although it might be the debian release is just
> a bit too old for that, not fully sure with which release anthony
> started to include the firmware submodules, might be it was after 1.1

Nope, qemu started including sources before that.  But it doesn't
matter really, it is just the way how debian works, nothing to
do with qemu really.  Especially since most of these submodules
are already packaged in Debian separately (be it because the
qemu needs or due to other means).

Thanks,

/mjt