Re: [Qemu-devel] Norton Ghost crashes with page fault for me too.

[jeebs]

"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 
>> month
>> 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 
> itself
> was submitted.) So was the gcc 3.4 bug (which includes a link to the 
> patch).
> Etc.

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 
waste.

> I have to take that back. Savannah bug tracker is not a good way to go, as 
> e.g.
> even if the bugs are fixed none of the developers can say so or close the 
> bug.
> Only Fabrice has access. Also, only he has commit access so good patches, 
> such
> 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 
> have
> 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 
patches applied.


> As a side note, I have a hackish patch that will allow you to change the 
> cdrom
> in the monitor to a filename that includes spaces. It was not a difficult 
> change
> to implement. I don't see why you couldn't have fixed that yourself (if it 
> hasn't
> 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 
two years.

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 
with that.

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.