[gentoo-amd64] Re: kde4, xorg, xf86-video-ati/radeon, and multi-panel display

[Duncan]

Beso <givemesugarr@×××××.com> posted
d257c3560811230324r6f2d2a31p74a546e8be289cd2@××××××××××.com, excerpted
below, on  Sun, 23 Nov 2008 11:24:23 +0000:

> by the way i'm still waiting for the kernel upgrade script post... :-)

Well, I had made an assumption that proved true for changing kernel 
versions at the time, but invalid over the longer term.  Specifically, I 
had the scripts copying over the outputdir (which I set so the sources 
themselves stay clean, everything I've done is in the outputdir), so a 
new build would only have to rebuild where the code had changed.  Well, 
all that broke early in the 2.6.27 series, between rc1 and rc2, when x86 
moved its headers around.  For several rcs I was unable to compile at 
all, until I figured out it was still trying to use the old headers 
from .26, mixed up with the ones from .27!  That was NOT working!

So, I had to figure out the problem (which early on I thought might be 
the scripts, it was, but not quite as I expected), then fix the scripts 
so they cleared the outputdir properly (while still saving and 
transferring the .config in the same dir), then test my changes thru 
several rcs...

Meanwhile I found a real bug late in the .27 development cycle and was 
pressed to bisect it, learning a bunch about git and git bisect in the 
process... and updating my scripts with git versions... all within only a 
couple weeks before target release, since I hadn't been able to test 
earlier since I couldn't compile.

Oh, and along in there I typoed a variable name and a script that was 
supposed to clean the outputdir in my git version, instead tried to 
"clean" /!  Yes, I brown-bag-errored a rm -rf /!  Fortunately I caught it 
before it got thru with /home, but unfortunately after it killed /bin, 
/dev, /etc...  But fortunately my backups weren't too out of date.  
Still, I had to recover in the middle of that already time-pressed bisect 
cycle.  But I did, and I finished the bisect, thereby tracing the problem 
to a single commit, and they figured out the problem and patched it 
before 2.6.27 release.

And I found a bug to bisect in the .28 rc series as well.  It was keeping 
my machine from properly hibernating, which meant after every failed test 
during the bisect cycle, there was a good chance the RAID-6 wasn't synced 
at the crash, and I had it doing the resync when I rebooted.

But it's all working relatively good again now... and I'm getting back to 
trying to catch-up on all these things! =:^)

-- 
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