[gentoo-user] Re: how to "git-bisect" in a portage-compatible way ?

[Nicolas Richard <theonewiththeevillook@yahoo.fr>]

Le 10/03/10 17:08, walt a écrit :
> On 03/10/2010 03:03 AM, Nicolas Richard wrote:
>> So the general question is : if I want to use git-bisect (I have never
>> done that before, but today is a good time to try),
> 
> It's a great tool and easy to use once you've learned the basic steps.
> You can ask here if you need help with it.

I have to agree, it's quite a nice tool. Unfortunately the bug is a bit
unpredictable (random crash which requires a reboot) and I found out
that the version I thought was good (2.4.11) was in fact bad, and that I
probably had been lucky not to encounter a crash for some days.
Moreover, releases of libdrm prior to 2.4.11 are incompatible with my
current xf86-xorg-intel (while writing this and looking at gitk, I
notice that there are a few commits which should be compatible. I'll try
these later.)

What is weird is that if I use older versions, I feel it crashes less
often than with new versions. I have in mind two things two try:
* bisecting another package, e.g. xf86-xorg-intel or even the kernel.
* instead of trying to find a commit which does not have "the" bug, find
one which has a related but different bug. I mean, the crash is not
always the same, sometimes I can still access the console, sometimes I
just have to reboot, sometimes the kernel crashes too... maybe I can
find a commit for which the bug behaves differently.

Let me stop being off topic for a few seconds, and ask a real question
about git-bisect : imagine there are two bugs : bug A is a known bug,
present in version 2.4.11 but corrected in 2.4.18, and bug B is another
bug which I'm trying to bisect. Problem : they have the same effect
(let's say : a crash) and I want to fix bug A because it might hide bug
B. Assuming that the patch which fixes bug A can be applied to the files
of versions 2.4.11-2.4.18, is it possible to bisect these modified
versions ?
What I can imagine is : do a normal git-bisect session, but each time
apply the patch before ./configure'ing. That sounds ok, but is it ? And
if yes, what's the correct way to tell git to "put the changes induced
by one commit on the current head" ? (I hope I'm being clear and not
mixing the terms, here).

> When you configure the git test package, use the "--prefix=/usr/local"
> flag so that the test library gets installed in /usr/local/lib, and
> /usr/local/include, etc.

I followed your advice (/usr/local is actually the default location for
libdrm) and it worked quite nice because it is easy to track the files
installed by the package within /usr/local... maybe this is not true for
more complicated packages ?

> Then, to test the new library, just change the /usr/lib/libdrm symlink
> to point at /usr/local/lib/libdrm.so.whatever.

Actually, it seems that the system first looks in /usr/local/lib before
/usr/lib, so it was probably unnecessary to modify the symlinks (noticed
it at the end).

-- 
Nico.