Comme=
nt # 13
on bug 10913=
5
from rmun=
crief@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 thi=
ngs for you?
> > > >=20
> > > > Actually I remember doing that many years ago when I wa=
s a maintainer for
> > > > Steam under wine. I'll look and see if I can find a cur=
rent bisect tutorial
> > > > and give it a try. Any links or tips you can give to he=
lp give me a quick
> > > > start would be appreciated. I do remember it can take m=
any days, which I'm
> > > > willing to invest as I said. However the fewer days the=
better! :)
> > >=20
> > > It's pretty straight forward. Just google for "kernel =
git bisect howto".
> >=20
> > Bisecting between two major stable kernel versions is a nightmare=
.(Aka
> > 4.18.0 - 4.19.0)
> >=20
> > Most of the new changes are done before RC1 and it is quite commo=
n that
> > there are major breakages there, in systems we do not want to bot=
her with.
> > These breakages are usually fixed (or reverted) in later Release =
Candidates.
>=20
> 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 alwa=
ys
> 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 "m=
ake 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 t=
hey should?
Does the compile fail if you need to, or can silent problems be introduced =
if
you don't?