Re: [Pan-users] Git pull build failure on Fedora 15 32-bit

[Duncan]

Lacrocivious Acrophosist posted on Mon, 07 Jan 2013 17:16:44 +0000 as
excerpted:

> Recent git pulls do not build for me on a Fedora 15 32-bit box. Previous
> git pull builds have succeeded and I am now using Sexual Chocolate (GIT
> bf56508).
> 
> Console output may be seen at: http://pastebin.com/vS9SVUSs
> 
> Note that for my builds I 'cheat' by changing line 55 of configure.in
> to: GNUTLS_REQUIRED=2.10.5 ...which has not caused any problems before
> (newer versions are not available for Fedora 15). Configure reports
> 'With GnuTLS:
> yes = 3.0.11' but it lies. I do use SSL with my primary NSP.
> 
> I would appreciate suggestions to work around the failure shown in the
> console output pastebin.

Well, the "dumb non-coder" way to at least nail down the problem to a 
specific commit is to do a git bisect.  You can do man git-bisect to get 
the manpage, but basically, you do git bisect start, then git bisect bad 
<commit> (feed it the first commit you know is bad, or let it start from 
current HEAD if you don't know).  Then git bisect good <commit> (feed it 
the last known good commit).  

After you give it both a good and a bad commit, it checks out a point 
near the middle for you to try.  You try it, and then use git bisect good 
or git bisect bad (without the commit), so it knows whether the problem 
is before or after that.  It'll then checkout a commit near half of 
what's left, and you test it.

You can use git bisect skip, if there's a different problem with what it 
has chosen, so you can't find out whether it's bad or good on the problem 
you're testing, and git will try something on one side or the other, but 
of course that way, you might end up with the bad commit in the range it 
can't check as you've skipped them all.

After a few rounds of this it narrows down the problem as far as 
possible, ideally to a single commit, and you can report it (or the 
range) as the culprit.

As I said, this is the "dumb non-coder" way of brute-force-narrowing it 
down to a single commit, but I've used it to narrow down and file a 
number of kernel bugs, since I routinely run git kernels, and have thus 
prevented several bugs from making it to a full kernel release, as a 
result of doing this.  Of course, with the number of kernel commits, I 
often have a dozen or more rounds of bisecting, before I nail it down, 
but with much less activity in pan's git, chances are you can do it in a 
half-dozen or so rounds of testing.

The good thing about it is that it allows non-coders to help a bit with 
tracing down the problem, AND, if you can trace it to a single commit, 
often, at least in the short term (until something else depends on that 
commit), you can revert just that commit (either via git or by making a 
simple patch that reverts it, that you apply manually, I've done both), 
and still run current pan, testing other new code and features, until 
that problem is fixed.  Much nicer than being stuck at some old version, 
unable to run anything newer and try all the nice new features, as you'd 
be without the ability to narrow down and revert a single commit. =:^)

Of course, if Heinrich gets to it first, knowing the code and what he's 
changed recently that has to do with the problem, he may well be able to 
find and fix the problem right away.  But the bisect thing does give you 
a way to do something to help, instead of just reporting the problem and 
then having to just wait for someone that can help, if they don't have 
time at that time to get to it. It's nice to be able to do something 
about it yourself even as a non-coder, even if it's also a bit of drudge 
work.  At least, I've found it so. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman