[00:12] Is there any further information that I should (and am able to) disclose for this bug report? https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/604192 [00:12] Launchpad bug 604192 in xserver-xorg-video-intel (Ubuntu) "Screen goes blank and flashes vertical stripes on 1s interval (affects: 1) (heat: 6)" [Undecided,Confirmed] [00:38] Sarvatt: Rock on, dude, thanks! We've been publically targetting xserver 1.9 since UDS, and it looks like it's going to be in a better state than 1.8 anyway. [00:39] Takyoji: An i845 chip? Dear lord, I'm surprised it works at all :/ [00:40] Takyoji: If you're prepared to do a bunch of work, though, that bug looks like it would be amenable to a regression analysis via bisection. [00:44] out of curiosity, how would it not be able to work? :P [00:45] also, is there any specific guide(s) available for regression analysis? [00:50] Hm. [00:51] I'm not sure if we've got a bisection howto page on the wiki. Let me check. [00:51] Takyoji: The basic principle would be to: (a) Check which component is broken (options here are xserver-xorg-video-intel, the kernel, mesa, or libdrm). [00:52] (b) Check out the git source of that component, and run "git bisect" to rebuild it at different points between 9.10 and 10.04 to work out precisely when it broke. [01:04] Takyoji: https://wiki.ubuntu.com/X/Bisecting is a bit of an overview; there's also the bisecting mesa page linked from there. [01:05] ahh, alrighty [01:07] So I don't even have to overlook the source code then; just simply find what exact revision broke it? [01:09] Right. [01:09] You can do that without needing to know anything about the source. [01:10] First off, though, you need to know which component broke, so you'll want to try each of the 9.10 components in 10.04, one at a time. [01:16] So first I have to verify which component it even is, before going through bisecting, correct? [01:35] Takyoji: Yes. Because you need to be able to identify a good point and a bad point in the same source. [01:40] Then you can run a bisection over that git history. If you don't have a good *and* a bad point in the same git source then you can't checkout the commit half way between, work out whether it's good or bad, and then repeat. === bryceh is now known as 40FAA7E1T === 40FAA7E1T is now known as bryyce [09:31] Alright ladies and gentlemen! Let your i8xx gpus feast on the joy that is https://edge.launchpad.net/~raof/+archive/aubergine [09:39] Everyone *else* who feels like a test could ensure that it doesn't break your working Intel GPU. [09:41] what's the difference with xorg-edgers? [09:44] The re-introduction of a legacy, non-GEM UMS codepath. [09:45] ie: work around the various longstanding breakages on i8xx cards which were caused by assuming various bits of the hardware actually worked by not using it. [10:31] \o/ [11:37] do we install the nvidia-settings package by default for all nvidia users? [11:46] vish: the nvidia packages recommend nvidia-settings [11:47] it's treated as a dependency [11:47] tseliot: ah ok , thanks [11:48] vish: BTW did the gtk guys reply to your request to integrate my patch for that papercut now that we know that Orca would work fine? [11:49] tseliot: yeah , i'll have to poke ebassi again today.. [11:49] vish: ah, good [11:49] he was the one who requested review from accessibility folks [11:50] ok, let's see if he decides to include the patch now or if he has further requests === freeflyi1g is now known as freeflying [16:17] what's the most stable 2.6.35 kernel? I've tried the one that comes with mavrick alpha2 and I've tried lucid with linux-image-2.6.35-7-generic-pae. I know this is bit off topic but I'm trying to test xorg-edgers' nouveau driver so I need a 2.6.35 kernel