[00:12] <Takyoji> 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] <ubot4> 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] <RAOF> 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] <RAOF> Takyoji: An i845 chip?  Dear lord, I'm surprised it works at all :/
[00:40] <RAOF> 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] <Takyoji> out of curiosity, how would it not be able to work? :P
[00:45] <Takyoji> also, is there any specific guide(s) available for regression analysis?
[00:50] <RAOF> Hm.
[00:51] <RAOF> I'm not sure if we've got a bisection howto page on the wiki.  Let me check.
[00:51] <RAOF> 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] <RAOF> (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] <RAOF> 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] <Takyoji> ahh, alrighty
[01:07] <Takyoji> So I don't even have to overlook the source code then; just simply find what exact revision broke it?
[01:09] <RAOF> Right.
[01:09] <RAOF> You can do that without needing to know anything about the source.
[01:10] <RAOF> 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] <Takyoji> So first I have to verify which component it even is, before going through bisecting, correct?
[01:35] <RAOF> Takyoji: Yes.  Because you need to be able to identify a good point and a bad point in the same source.
[01:40] <RAOF> 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.
[09:31] <RAOF> Alright ladies and gentlemen!  Let your i8xx gpus feast on the joy that is https://edge.launchpad.net/~raof/+archive/aubergine
[09:39] <RAOF> Everyone *else* who feels like a test could ensure that it doesn't break your working Intel GPU.
[09:41] <Duke`> what's the difference with xorg-edgers?
[09:44] <RAOF> The re-introduction of a legacy, non-GEM UMS codepath.
[09:45] <RAOF> 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] <bryyce> \o/
[11:37] <vish> do we install the nvidia-settings package by default for all nvidia users?
[11:46] <tseliot> vish: the nvidia packages recommend nvidia-settings
[11:47] <tseliot> it's treated as a dependency
[11:47] <vish> tseliot: ah ok , thanks
[11:48] <tseliot> 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] <vish> tseliot: yeah , i'll have to poke ebassi again today..
[11:49] <tseliot> vish: ah, good
[11:49] <vish> he was the one who requested review from accessibility folks
[11:50] <tseliot> ok, let's see if he decides to include the patch now or if he has further requests
[16:17] <scar_> 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