[gentoo-user] Re: how to git-bisect in a portage-compatible way ?
Hm. I'm not sure what you are asking. It was unclear, but you answered the question indirectly. Thanks, Nico.
[gentoo-user] Re: how to git-bisect in a portage-compatible way ?
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.
[gentoo-user] Re: how to git-bisect in a portage-compatible way ?
On 03/11/2010 07:54 AM, Nicolas Richard wrote: 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. 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 ? I seem to recall doing something like that once, but I can't remember how it turned out :o) Not every file in your git working directory is over- written with each 'good' or 'bad' bisect step, so your patch may possibly be rejected as 'reversed' on some iterations of bisect. That is to be expected. 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). Hm. I'm not sure what you are asking. I'm not a developer but I do often apply patches from developers and I try to avoid making commits by accident because then I've made a permanent and unwanted change to my local copy of the remote git repo. For example, if I want to apply a bugfix from 2.4.18 to a working copy of 2.4.11, I would first check out a copy of 2.4.18 and then generate a patch file by using 'git diff -p hexadecimal commit number test.patch' (assuming that you know the commit number of the bugfix, of course). Then check out a working copy of 2.4.11 and apply test.patch to it. The patch may or may not succeed, of course. If the two versions are far enough apart in time, such patches will fail quite often. That's when you start contacting the upstream devs to get their advice/flames. When you are done fiddling with patches you can do 'git reset --hard' to restore a pristine working copy of the git repo. An alternate method is to create a new branch for all your fiddling, e.g. 'git branch junk' and then git checkout 2.4.11, or whatever, and then delete 'junk' when you're finished with your fiddling. I seem to recall that real devs use that method, but I could be mistaken. 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). Good observation. I see that /usr/local is the top line in /etc/ld.so.conf, which I'd forgotten, assuming I ever knew it.
[gentoo-user] Re: how to git-bisect in a portage-compatible way ?
On 03/10/2010 03:03 AM, Nicolas Richard wrote: Hello, ... 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 guess it means I'll have to build libdrm outside portage : if so, once I'm finished with hunting the bug, how to go back to the situation where portage does everything for me ? I can think of several possible ways, but here is one that should work. 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. Then, to test the new library, just change the /usr/lib/libdrm symlink to point at /usr/local/lib/libdrm.so.whatever. That avoids overwriting existing files, and you can just delete the files in /usr/local when you finish. Also, some packages have a make uninstall option you could use instead. Warning: don't try this method with critical system libs like glibc. Changing that symlink would break your whole system at warp speed.
