"Jim C. Brown"
>> I'm willing to do some testing. But you'll have to tell me how to do the
>> gtk2 interface under windows.....
> Well, you will need to apply the patches and compile from source yourself.
> Not to mention, you'll have to download the windows versions of the GTK2
> libraries (you can probably get binaries).
I'll have to hunt around. I'm not familiar with gtk2.
>> But it gets significantly frustrating when you see the same problems
>> after month after month, etc.
> Only report it the first time you see it.
And then sit back and wait for it to be forgotten....[grimace]
> Some one of those bugs have actually been fixed. A patch was sent a while
> ago that got rid of bug #9441 IDE multimode failure. (Long before the bug
> was submitted.) So was the gcc 3.4 bug (which includes a link to the
Yes, I'm sure some of them are fixed... Nobody is even looking there.
Except for the occasional user trying to be helpful, it's been ignored.
Meanwhile, all those possibly helpful bug reports by users have gone to
> I have to take that back. Savannah bug tracker is not a good way to go, as
> even if the bugs are fixed none of the developers can say so or close the
> Only Fabrice has access. Also, only he has commit access so good patches,
> as the graphics patch, don't always make it in right away.
I can't comment about how to close bugs... I've never done that.
As for submitting patches, Savanah has a facility to do that, too. They can
be submitted seperately. I would expect the most that would be needed would
be registration. (The qemu page doesn't have it enabled, but Savanah has
that ability. I've seen it on other projects.)
> Yes, more communication is needed. We shouldnt be bothered by bugs which
> patches to fix them or bugs that are a non issue or bugs that are easily
Seperate patches aren't necessarily the right thing to do....
Most are *users*. They aren't going to build their own. They will download
one of the pre-made binaries, which is likely to be just CVS. Maybe with
one or two critical patches, but maybe not.
A good way to help this area would be a compile farm doing nightly builds!
This has been suggested before.
That way, everybody can get up to date cvs builds. With the important
> As a side note, I have a hackish patch that will allow you to change the
> in the monitor to a filename that includes spaces. It was not a difficult
> to implement. I don't see why you couldn't have fixed that yourself (if it
> already been fixed in main CVS).
I don't think it's been fixed in cvs. Although I admit I haven't checked
with the last couple cvs builds.
As for fixing it myself...
I'm not really a developer.
I used to write some C code. Nothing really fancy.
But that's been a while. I haven't even had a compiler installed for about
I only recently did one when somebody in the qemu-user's forum explained how
to compile the cvs version under windows. Until then, I didn't even know
how to compile qemu. Qemu does it in the linux style, and I wasn't familiar
Getting back up to speed in C would take me a little while. Getting up to
speed with qemu, and familiar with the style that Fabrice uses, etc. would
take more time.
And although I might be able to fix one or two trivial bugs, I seriously
doubt I'd be able to do the others. They require significant knowledge of
qemu, and of how the hardware is supposed to work and how it's being
emulated. Not everybody can just 'jump in' and do that kind of work.
It's not time that I want to waste.
Qemu-devel mailing list