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 _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
