FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo User

 
 
LinkBack Thread Tools
 
Old 03-10-2010, 10:03 AM
Nicolas Richard
 
Default how to "git-bisect" in a portage-compatible way ?

Hello,

Background info : I'm experiencing a bug and found out that the bug
doesn't appear with libdrm-2.4.11 (I kept an ebuild for this one in
/usr/local/portage/...), but it does occur with libdrm-2.4.13 (not sure
about the version numbers anymore, and I have yet to try 2.4.12, too,
but that's not the question)

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), 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 ?

Some more precise questions :
- before I begin, should I first unmerge libdrm ?
- once I finished with bisecting, should I reemerge libdrm ? Will
portage overwrite files it may need to overwrite ? what about orphanned
files (if any) ?

I looked at the documentation list on gentoo.org, I did find a section
entitled "Non-portage maintained software", but this is not what I'm
looking for. Where else should I look at ?

thanks for your comments

Nicolas.
 
Old 03-10-2010, 03:08 PM
walt
 
Default 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.
 
Old 03-11-2010, 02:54 PM
Nicolas Richard
 
Default 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.
 
Old 03-12-2010, 12:13 AM
walt
 
Default 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 ) 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.
 
Old 03-16-2010, 07:24 AM
Nicolas Richard
 
Default 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.
 

Thread Tools




All times are GMT. The time now is 02:27 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org