On Mon, Jul 09, 2007, Aurelien Jarno wrote:
> Most of the patches are actually merged into bochs CVS. The diff against
> the bochs bios is in the QEMU sources and is currently 1600 bytes long.
>
> The problem is that you have to build it with -DQEMU (or something like
> that), which is in favor of
On Mon, 2007-07-09 at 11:34 +0200, Loïc Minier wrote:
> On Mon, Apr 16, 2007, Sam Morris wrote:
> > Given that it is not
> > likely that QEMU's patches (which are more extensive in QEMU's CVS
> > trunk) are not likely to be merged upstream into bochs an
On Mon, Jul 09, 2007 at 11:34:35AM +0200, Loïc Minier wrote:
> On Mon, Apr 16, 2007, Sam Morris wrote:
> > Given that it is not
> > likely that QEMU's patches (which are more extensive in QEMU's CVS
> > trunk) are not likely to be merged upstream into b
On Mon, Apr 16, 2007, Sam Morris wrote:
> Given that it is not
> likely that QEMU's patches (which are more extensive in QEMU's CVS
> trunk) are not likely to be merged upstream into bochs any time soon, I
> think it's best if a separate bochsbios-qemu
Apparently the QEMU folks build their bios.bin from bochs' CVS trunk.
bochs 2.3 is far too old--it does not even include the files patched by
QEMU's bios.diff.
Presumably we don't want to force the bochs maintainers to keep updating
their bochs packages to the latest version in bochs' cvs, and/or
On Wed, Feb 14, 2007 at 04:28:26PM -0500, Michael Gilbert <[EMAIL PROTECTED]>
wrote:
> On 2/14/07, Robert Millan wrote:
> >So, why not just updating bochs to CVS version?
>
> that makes sense. the concern would be potentially introducing RC
> bugs with the new bochs (since the etch release is ni
On 2/14/07, Robert Millan wrote:
So, why not just updating bochs to CVS version?
that makes sense. the concern would be potentially introducing RC
bugs with the new bochs (since the etch release is nigh).
i'd say the only option in the etch-timeframe is to disable the
-kernel-kqemu flag, but
This is caused by qemu using the PC-BIOS from the bochsbios package
instead of the one packages with the qemu tarball. It's from bochs, but
a much more recent CVS version.
if this is the case, then there should be two versions of the
bochsbios package (similar to what is done for python, the ker
what is the status of this?
the problem is still existing and makes qemu debian packages pretty
useless for me.
i'm aware of the fact that you rebuild the upstream tarball without the
pc-bios files, but as they are pretty important, is there any special
reason why you are pulling them out, except
This is caused by qemu using the PC-BIOS from the bochsbios package
instead of the one packages with the qemu tarball. It's from bochs, but
a much more recent CVS version.
Marc.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Package: qemu
Version: 0.8.2-4
Severity: normal
When using the qemu from the Debian repositories, trying to use
-kernel-kqemu results in a kernel panic in the guest OS - this has been
tested with both Debian Etch and Fedora Core 6 as the guest OS. This is
with kqemu either from the Debian repos
11 matches
Mail list logo
