https://bugs.freedesktop.org/show_bug.cgi?id=109135

--- Comment #13 from rmuncrief@humanavance.com ---
(In reply to Alex Deucher from comment #12)
> (In reply to iive from comment #10)
> > (In reply to Alex Deucher from comment #9)
> > > (In reply to rmuncrief from comment #8)
> > > > (In reply to Alex Deucher from comment #7)
> > > > > Can you bisect to figure out what commit broke things for you?
> > > > 
> > > > Actually I remember doing that many years ago when I was a maintainer for
> > > > Steam under wine. I'll look and see if I can find a current bisect tutorial
> > > > and give it a try. Any links or tips you can give to help give me a quick
> > > > start would be appreciated. I do remember it can take many days, which I'm
> > > > willing to invest as I said. However the fewer days the better! :)
> > > 
> > > It's pretty straight forward.  Just google for "kernel git bisect howto".
> > 
> > Bisecting between two major stable kernel versions is a nightmare.(Aka
> > 4.18.0 - 4.19.0)
> > 
> > Most of the new changes are done before RC1 and it is quite common that
> > there are major breakages there, in systems we do not want to bother with.
> > These breakages are usually fixed (or reverted) in later Release Candidates.
> 
> This is not always the case; in most cases bisects are pretty smooth.  If
> you run into unrelated problems with a particular commit, you can always
> skip it during the bisect (git bisect skip).

Okay. I'm recompiling the first bisect now, there were no problems starting it
this time after using "git stash." However I didn't issue "make clean" because
it's unclear if it's necessary and I'm hoping I don't have to recompile
everything for each iteration. Is it necessary or not? The instructions are
vague and simple say you "might" have to. How would one know if they should?
Does the compile fail if you need to, or can silent problems be introduced if
you don't?

-- 
You are receiving this mail because:
You are the assignee for the bug.