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.
