From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1L4DlZ-0004T0-Mv for garchives@archives.gentoo.org; Sun, 23 Nov 2008 12:08:41 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id AD841E02A4; Sun, 23 Nov 2008 12:08:40 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by pigeon.gentoo.org (Postfix) with ESMTP id 62DFAE02A4 for ; Sun, 23 Nov 2008 12:08:40 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1L4DlR-0002Jt-7Z for gentoo-amd64@lists.gentoo.org; Sun, 23 Nov 2008 12:08:33 +0000 Received: from ip68-230-99-190.ph.ph.cox.net ([68.230.99.190]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 23 Nov 2008 12:08:33 +0000 Received: from 1i5t5.duncan by ip68-230-99-190.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 23 Nov 2008 12:08:33 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-amd64@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-amd64] Re: kde4, xorg, xf86-video-ati/radeon, and multi-panel display Date: Sun, 23 Nov 2008 12:08:24 +0000 (UTC) Message-ID: References: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@lists.gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-230-99-190.ph.ph.cox.net User-Agent: Pan/0.133 (House of Butterflies) Sender: news Content-Transfer-Encoding: quoted-printable X-Archives-Salt: e5f0c619-0e4c-4b99-8a8e-6054a7aef46c X-Archives-Hash: 207661d55e12c304da64f25faa9206d0 Beso posted d257c3560811230324r6f2d2a31p74a546e8be289cd2@mail.gmail.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=20 versions at the time, but invalid over the longer term. Specifically, I=20 had the scripts copying over the outputdir (which I set so the sources=20 themselves stay clean, everything I've done is in the outputdir), so a=20 new build would only have to rebuild where the code had changed. Well,=20 all that broke early in the 2.6.27 series, between rc1 and rc2, when x86=20 moved its headers around. For several rcs I was unable to compile at=20 all, until I figured out it was still trying to use the old headers=20 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=20 the scripts, it was, but not quite as I expected), then fix the scripts=20 so they cleared the outputdir properly (while still saving and=20 transferring the .config in the same dir), then test my changes thru=20 several rcs... Meanwhile I found a real bug late in the .27 development cycle and was=20 pressed to bisect it, learning a bunch about git and git bisect in the=20 process... and updating my scripts with git versions... all within only a= =20 couple weeks before target release, since I hadn't been able to test=20 earlier since I couldn't compile. Oh, and along in there I typoed a variable name and a script that was=20 supposed to clean the outputdir in my git version, instead tried to=20 "clean" /! Yes, I brown-bag-errored a rm -rf /! Fortunately I caught it= =20 before it got thru with /home, but unfortunately after it killed /bin,=20 /dev, /etc... But fortunately my backups weren't too out of date. =20 Still, I had to recover in the middle of that already time-pressed bisect= =20 cycle. But I did, and I finished the bisect, thereby tracing the problem= =20 to a single commit, and they figured out the problem and patched it=20 before 2.6.27 release. And I found a bug to bisect in the .28 rc series as well. It was keeping= =20 my machine from properly hibernating, which meant after every failed test= =20 during the bisect cycle, there was a good chance the RAID-6 wasn't synced= =20 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= =20 trying to catch-up on all these things! =3D:^) --=20 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