=== bryceh is now known as bryce2
[00:55] <bryce2> hmm
[03:20] <Sarvatt> hmm ccab5c82759e2ace74b2e84f82d1e0eedd932571 introduced pretty frequent MCE errors in dmesg at the expense of a 20% performance increase on intel with turbo boost.. how long until someone complains about that
[03:20] <Sarvatt> way back in 2.6.39-rc1
[03:22]  * Sarvatt has 17 errors in dmesg from 4 days uptime because of it on an e6420
[03:39] <bjsnider> Sarvatt, did you read this: http://netsplit.com/2011/09/08/new-ubuntu-release-process/
[03:40] <Sarvatt> yeah, can't say i agree, he very obviously has the perspective the thing he cares about will get updated easier with that development model ignoring the rest of the world that is *buntu that doesnt fit that model at all :)
[03:41] <Sarvatt> i'd much rather see something like debian unstable with opt in to things you care about updates
[03:42] <bjsnider> i think he's taken everything into account
[03:42] <bjsnider> his way would work
[03:42] <bjsnider> it's possible that ubuntu 11.10 and 11.11 would be exactly the same though
[03:42] <Sarvatt> linaro is already doing it
[03:42] <bjsnider> if no new software was ready
[03:43] <Sarvatt> cutting monthly ubuntu releases
[03:44] <Sarvatt> as a user, honestly all i care about is getting X and driver updates and having a stable desktop, and getting select app updates when i want
[03:44] <Sarvatt> worst part about development releases to me is the desktop breaking up weekly up until 2 weeks before final release
[03:44] <bjsnider> his way nothing would be updated unless it was ready
[03:45] <bjsnider> maybe it would also cut down on all of the meetings
[03:45] <bjsnider> it sounds like you guys spend a lot of time talking about things
[03:46] <bjsnider> under the current system
[03:47] <bjsnider> Sarvatt, do you want to keep the current system?
[04:02] <Sarvatt> obviously not, i'm hoping to discuss the idea of backporting drivers from +1/+2/+3 to the LTS via opt in pockets at 12.04 UDS because thats what I care about and feel we're lacking in support for when the LTS isn't viable on newer hardware 6 months later because of SRU policies but I still don't think the chrome model would work in the world where you go through 6 months of fixing up universe to work with a gcc change like we just did and I think we'd
[04:02] <Sarvatt> do
[04:03] <Sarvatt> what do ya see a lot of time spent talking on?
[04:03] <Sarvatt> and who's us btw, you're us too :)
[04:04] <Sarvatt> your nvidia updates in x-updates are now going to distro users if you didn't notice :)
[04:05] <Sarvatt> jockey pulls from the PPA now
[04:05] <bjsnider> what?
[04:05] <bjsnider> jockey pulls from the what now?
[04:05] <Sarvatt> in oneiric it offers nvidia-current-updates and if they pick that it pulls from x-updates ppa
[04:06] <Sarvatt> not sure if that got SRUed to natty or not
[04:06] <bjsnider> oneiric is currently beta though
[04:17] <Sarvatt> 6 months a year where drivers can be updated because of freezes is not enough, thats for sure
[04:23] <Sarvatt> bjsnider: yer prolly talking to the wrong guy, i get paid to make prerelease hardware work in the distro thats out when the hardware comes out (which is usually 3-4 months into the next dev cycle), then work in that release+1 out of the box so it can get certified. the 6 month cycle works decently for that even if i wouldn't personally want to use that and i see lots of complications with every kind of change :) all I care about is the drivers, you pr
[04:23] <Sarvatt> faster but i'd prefer slower
[04:24] <Sarvatt> anything i care about updating faster i just update myself anyway
[04:26] <ScottK> Given how painful Testing transitions in Debian (which are easier than what he's talking about), I think he substantially underestimates the complexity of what he's proposed.
[04:27] <ScottK> I agree with the problem statement, but not his solution.
[04:27] <ScottK> Works for Chromium (one package) doesn't tell you it'll scale to 20,000.
[04:28] <ScottK> Sarvatt: Are you still interested in E6320 bugs or is that now "old"?
[04:29] <Sarvatt> ScottK: definitely, I did look at your bug but I'm a bit stumped at it. the kwin backtrace was because DRI got ripped out from under it when the GPU reset and disabled acceleration which mesa couldn't cope with (that specific kwin segfault is fixed in mesa 7.12 but was a bit too big to backport when i looked)
[04:30] <ScottK> Sarvatt: OK.  Cool.  Thanks for looking at it.
[04:30] <ScottK> I'll mark that in the bug then.
[04:31] <Sarvatt> it definitely was a driver problem and not kwin, you were right there
[04:32] <ScottK> That was mgraesslin.
[04:32] <ScottK> He told me.
[04:32] <tjaalton> Sarvatt: i think we decided on the lts backport strategy already :)
[04:35] <Sarvatt> they fixed the app segfaulting when acceleration gets ripped out from underneath it in mesa, but its still a kernel bug that caused the GPU reset in the first place
[04:36] <Sarvatt> going to need to upstream this bug and they are going to ask you to do some crazy stuff to reproduce it, and it seems like a very transient bug that happens a long time after a suspend/resume cycle under intense memory pressure from chromium so that might be a pain in the butt
[04:37] <Sarvatt> or just mark the dang thing fix released because the segfault is fixed in mesa 7.12 :(
[04:38] <Sarvatt> ScottK: hopefully i can reproduce it locally so dont have to put you through all the headache installing xorg-edgers and stuff it should reproduce on an e6420
[04:39] <ScottK> We don't have 7.12, though, do we?
[04:39] <Sarvatt> nope its not released until january
[04:39] <ScottK> rmadison told me 7.11.
[04:39] <ScottK> I milestoned it for "P".
[04:40] <ScottK> I'm glad to help, but this is my primary laptop, so I can't go breaking it.
[04:40] <Sarvatt> its a kernel problem already fixed in 3.0, i haven't used 2.6.38-11's i915 since UDS-O so thats probably why I haven't hit it
[04:41] <ScottK> K.  Thanks for looking into it.
[04:41] <Sarvatt> but i've got it going now
[04:41] <Sarvatt> tjaalton: the kernel part is the sketchiest part, we need some serious discussion on it
[04:43] <Sarvatt> you potentially regress a lot less upgrading x-x-v-intel on your intel than you do upgrading the kernel
[04:44] <Sarvatt> they already do LTS backport kernels though I guess
[04:44] <Sarvatt> its how it would possibly work with the archives thats way beyond me
[04:51] <Sarvatt> ScottK: thanks for milestoning it to P because realistically it might not be backported to N before O comes out with how tricky it looks to be to reproduce.. I really hope its not as common as the 10.10 issues your daughter had
[04:52] <Sarvatt> (didn't manage to reproduce it today, I suspended/resumed and used chromium all day on stock packages and haven't hit it yet)
[04:52] <tjaalton> Sarvatt: yes, kernel backports are already happening
[04:53] <tjaalton> though with bugs like https://bugs.launchpad.net/ubuntu/+bug/824913
[04:53] <tjaalton> (archive fail)
[04:54] <Sarvatt> we're hitting some annoying stuff using lts-backport-natty in the OEM project we're working on, bluez userspace in lucid doesnt work on the lts backport kernel
[04:54] <tjaalton> so opting in would mean installing the linux-lts-backport-foo for the pocket, and enabling the ppa for that release
[04:55] <tjaalton> sure, that's a concern
[04:55] <Sarvatt> i dont care about bluez userspace, do you? :P
[04:55] <tjaalton> no, but it's not just bluez that might break :)
[04:55] <Sarvatt> yeah exactly
[04:56] <Sarvatt> tjaalton: that was only a problem with linux-lts-backports-maverick
[04:56] <Sarvatt> when we first did the natty backport i poked the kernel guys about the header problem and they fixed up natty but maverick got released without that fix
[04:57] <tjaalton> ah
[04:58] <Sarvatt> yeah its fixed in git http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commit;h=bff6b282d69e7a909d672ef24236b455449558d1
[04:59] <Sarvatt> looks like it was released in 3 updates since that bug too, closing that bug
[05:00] <Sarvatt> oh the meta hasn't been pushed yet
[05:10] <Sarvatt> https://bugs.launchpad.net/bugs/839595 really stinks, dont have a single machine here that didnt get +2 minutes boot time from yesterdays update :(
[05:10]  * Sarvatt must be installing wrong or something
[05:21] <tjaalton> i've not seen that
[05:52] <ScottK> Sarvatt: Me too.  So far I think I've had that particular problem only once.  X on this E6320 has gotten noticeably more reliable since Natty's release, so something is going right.
[05:54] <Sarvatt> yeah it sucks it took so long for 2.6.38-11 to come out, the patches in there to make sandybridge stable were floating around in april but the kernel kernel update got held up until august :(
=== yofel_ is now known as yofel
[21:09] <Sarvatt> tjaalton: are you interested in setting that up?
[21:09] <Sarvatt> i sure as heck can't keep up with 2 xorg-edgers like PPAs
[21:11] <Sarvatt> but it would be really good if we started staging things for release+1 on git.debian.org and would even make xorg-edgers that much easier to do, i'm already doing lots of it just rewriting the packaging in current git and efforts get duplicated when the next release comes around because its not in git
[21:12] <Sarvatt> btw, I dont care if proprietary drivers break, I was just mentioning that nvidia's supposedly xserver 1.11 supporting release doesn't work with xserver 1.11 because of the extension abi snafu
[21:13] <Sarvatt> (well it does as long as you have IgnoreABI in xorg.conf)
=== jussi01_ is now known as jussi
[22:51] <bryce2> Shocking news!  http://www.phoronix.com/scan.php?page=news_item&px=OTg5Mg  3D interfaces use up more power than 2D!  And Michael Larabel has PROOF.
[22:54] <debfx> fascinating