Beso <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], 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
