[00:01] <RAOF> kees: Looks like that might be fixed in the most recent drm-fixes pull request? (So, not yet in any kernel that you'll have access to, but still… ☺)
[00:13] <bryceh_> kees, I can repro it but haven't had time to poke around with it yet
[00:13] <bryceh_> RAOF, is the drm-fixes branch built by the kernel team?
[00:14] <bryceh_> http://kernel.ubuntu.com/~kernel-ppa/mainline/
[00:14] <bryceh_> looks like not, but they have builds of drm-next and drm-intel-next, - think the fix is in one of those?
[00:17] <RAOF> I don't think so, but let's play chase-the-git-commit!
[00:26] <RAOF> bryceh_: No, not in drm-next, but is in drm-intel-next.
[00:30] <bryceh_> RAOF, what's the commit id(s)?
[00:31] <RAOF> bryceh_: 467cffba8 (ooh!  gen2 *and early gen3*), a1656b, and 0ee537abbd
[00:31] <bryceh_> thanks
[00:32] <bryceh_> heh, I just finished saying my 945 never freezes, and then guess what
[00:32] <RAOF> :)
[00:32] <RAOF> Ding!
[00:33] <bryceh_> so maybe for the betterment of our testing, we just need to get a lot more brash and braggy about how bugfree our hw is?
[00:33] <RAOF> My GM45 *never* hangs!
[00:37] <trinikrono> vesa never hangs!
[00:37] <RAOF> (Because it's never used ☺)
[00:43] <bryceh_> feh, of course now I can't seem to reproduce it
[00:44] <bryceh_> kees, assuming you've still been seeing the bug with the current kernel, please load the drm-intel-next kernel and run that for a day or two and see if you can verify the issue is missing there
[00:54] <kees> bryceh_: I'll try, I'm in the middle of debugging some other ubuntu-specific kernel changes :P
[00:56] <bryceh_> yeah I'm in the middle of patch pilot work but can bang on it tomorrow or wednesday probably
[00:56] <bryceh_> (if I can ever reproduce it reliably again)
[02:26] <RAOF> You know one of the biggest things I miss in git? from bzr  Being able to reference tools by their unique prefixes (bzr st, etc)
[02:40] <bryceh_> RAOF, yeah
[02:40] <bryceh_> been rockin' the bzr today with patch piloting
[02:41] <RAOF> I think mesa 7.10.1 is ready for upload, by the way.
[02:41] <RAOF> I also think that there are some cherry-picks that will fix bug #721881 (or at least turn it into a non-segfault)
[02:41] <ubot4`> Launchpad bug 721881 in xserver-xorg-video-intel (Ubuntu) "compiz crashed with SIGSEGV in intel_region_data() (affects: 1) (heat: 246)" [Medium,New] https://launchpad.net/bugs/721881
[02:42] <bryceh_> RAOF, how much testing has it gotten so far?
[02:43] <bryceh_> i.e. is it ready to go now, or should I test it on my own hw first (which will have to wait 'til tomorrow)
[02:45] <RAOF> It's had a couple of day's testing on my hardware.  It wouldn't hurt to test on yours, too.
[02:45] <bryceh_> alright; better safe than sorry, I'll todo it for tomorrow
[02:47] <RAOF> I'll ensure it's in cooperteam.net/Packages along with binaries.
[02:47] <bryceh_> ok coo
[02:48] <bryceh_> wow, we're getting wayland bug reports - bug #729614
[02:48] <ubot4`> Launchpad bug 729614 in wayland (Ubuntu) "wayland-compositor crashed with SIGSEGV in wl_event_loop_dispatch() (affects: 2) (dups: 1) (heat: 18)" [Medium,New] https://launchpad.net/bugs/729614
[02:48] <bryceh_> someone has actually used it :-D
[02:49]  * bryceh_ wanders off
[02:50] <bjsnider> bryceh_, now...you have to fix the bug
[02:51] <bryceh_> heh
[02:51] <bryceh_> maybe if I get bored between now and release day
[02:51] <bryceh_> actually it's probably already fixed upstream, there's probably a patch that can be backported
[02:52] <bryceh_> hrm, Mr. Spikey McSpike has returned to the graph...  http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/totals-natty-workqueue.svg
[02:53] <bryceh_> meh, just dupes of known gpu lockups.  sure wish we could get those solved
[02:56]  * bryceh_ really wanders off
[04:56] <LLStarks> hmmm. does sandy bridge optimus mean that the framebuffer for the discrete gpu would be on the cpu?
[05:10] <RAOF> No, because the CPU doesn't have that kind of memory on it.
[05:10] <RAOF> Unless you feel like taking up many megabytes worth of L3 cache with your framebuffer that you'll need to copy out to system memory anyway :)
[06:21] <tjaalton> bryceh_: evtouch doesn't even build, and should be removed from the archive imo :)
[06:21] <tjaalton> (re: the recently added patch)
[06:23] <tjaalton> oh goodness, new unity that should fix the crashing decorator every time I send an email from tb
[07:09] <bryceh_> tjaalton, ah, I knew it was obsolete.  Yeah we should get rid if it if it'll never build again
[07:10] <tjaalton> well it's patchable, but it's gone from debian too, and no upstream..
[07:24] <LLStarks> isn't deprecation wonderful?
[07:24] <tjaalton> yep
[07:26] <tjaalton> bryceh_, RAOF: thoughts about merging xorg? I haven't looked at it too closely, but at least dexconf would get removed, finally
[07:43] <bryceh_> tjaalton, would be a good idea, not sure how we've missed it
[07:46] <tjaalton> bryceh_: I'll prepare it today
[07:46] <tjaalton> been a while..
[07:47] <bryceh_> tjaalton, last week I happened to clean up most of the bugs filed against xorg - https://bugs.edge.launchpad.net/ubuntu/+source/xorg
[07:48] <bryceh_> pretty much all the ones with an importance set seem to be things relevant to the xorg package now
[07:49] <tjaalton> yeah I noticed, good stuf
[07:49] <tjaalton> f
[07:50] <tjaalton> bryceh_: the next UDS we might discuss about splitting failsafe/apport from xorg, so they could be maintained separately, to minimize the churn (and keep them on lp if appropriate)?
[07:51] <tjaalton> iirc that has been planned at some point
[07:51] <lag> Can any of you tell me what a CMAP (colour map) is please?
[07:53] <bryceh_> tjaalton, in fact we already have a blueprint on it.  I'd planned to work on it this cycle but just didn't get to it (work on wayland took a bit more time than expected).  I can make it a focus next cycle.
[07:54] <tjaalton> bryceh_: ah good
[07:54] <bryceh_> in fact there already is a package with these files in universe - 'xdiagnose'
[07:55] <bryceh_> so mostly is just a matter of setting up the appropriate rules and so on to transition us, and do plenty of testing
[07:56] <tjaalton> yeah
[08:40] <RAOF> bryceh_: I don't have strong opinions on merging xorg.  If tjaalton wants to do it, great :)
[08:50] <RAOF> bryceh_, tjaalton: If you're interested in testing mesa 7.10.1 it's in http://cooperteam.net/Packages (i386 and amd64)
[08:51] <tjaalton> RAOF: ok, I hear there are lot of intel changes, so I'll load it on my laptop..
[08:51] <RAOF> Yup.
[08:51] <RAOF> It's almost all intel fixes (mainly for sandybridge)
[08:52] <RAOF> But also a bunch of glsl, etc.
[08:53] <RAOF> Oh, and I pulled in a patch to make nvaf not kill X. 
[09:50] <lag> Morning all
[09:50] <lag> I just conducted a dist-upgrade to Natty
[09:50] <lag> Which removed my Nvidia driver
[09:51] <lag> When I try to install it again, apt attempts to uninstall 23 packages - what's the latest?
[09:52] <tjaalton> nvidia-current is at 270.29
[09:53] <lag> It was nvidia-current I tried to install
[09:53] <lag> But it wants to remove btrfd-tools, libclutter, python things, and a load of libs
[09:54] <tjaalton> not because of nvidia
[09:55] <lag> The following packages have unmet dependencies: 
[09:56] <tjaalton> please use pastebin
[09:56] <lag> xserver-xorg-core: Breaks: xserver-xorg-video-8 which is a virtual package
[09:56] <lag> I can't, I'm not typing any more out :)
[09:56] <lag> it's on a console, no copy-paste
[09:56] <tjaalton> install pastebinit :)
[09:57] <tjaalton> anyway
[09:57] <tjaalton> sure about not having some ppa's around?
[09:57] <tjaalton> could be a stale mirror too
[10:01] <lag> Oddly, my sources file still says Maverick?
[10:01] <tjaalton> didn't use do-release-upgrade?
[10:01] <lag> I didn't initiate it
[10:02] <tjaalton> oh, who did?-)
[10:02] <lag> The Update Manager
[10:02] <tjaalton> you said "dist-upgraded"
[10:02] <tjaalton> so I thought you ran apt-get by hand
[10:02] <lag> Yes, it did a dist upgrate
[10:02] <lag> upgrade*
[10:03] <tjaalton> well the upgrader probably failed and it fell back on maverick?
[10:03] <lag> It said it has competed successfully 
[10:03] <tjaalton> run do-release-upgrade -ed
[10:03] <tjaalton> uh, -d
[10:04] <lag> I've just initiated another full upgrade
[10:04] <tjaalton> so sources.list is full of maverick, or both m and n?
[10:04] <lag> There were no m
[10:04] <lag> s/m/n
[10:05] <tjaalton> probably ask mvo how that could've happened
[10:18] <mvo> lag: could you mail me the logs in /var/log/dist-upgrade/* (or file a bug) please?
[10:20] <lag> mvo: I'll take a look when my (second) upgrade has finished
[10:20] <mvo> ok
[10:30] <lag> tjaalton: mvo: Same deal
[10:43] <tjaalton> RAOF: can't connect to your server
[10:43] <tjaalton> lag: file a bug against update-manager then (ubuntu-bug update-manager)
[10:44] <lag> Woooooooooooo
[10:44] <lag> I'm in 
[10:44] <mvo> to diagnose this, we need the logs
[10:44] <lag> What a nuisance 
[10:45] <RAOF> tjaalton: Try again?
[10:45] <lag> mvo: One step at a time
[10:45] <tjaalton> RAOF: yeah, works now
[10:59] <lag> mvo: Okay, I still have issues
[10:59] <lag> mvo: What logs are going to be of most help to you?
[10:59] <lag> dmsg, gdm
[11:02] <mvo> lag: if you used update-manager or do-release-upgrade for the upgrade /var/log/dist-upgrade/* will contain what is needed
[11:02]  * mvo will be away for lunch for a couple of minutes now
[11:22] <asac> RAOF: hey ... do you know if "00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)" gallium is now working in natty or xorg-edgers?
[11:22]  * asac would like to have that ;)
[11:23] <RAOF> You want gallium on that?  I don't believe 965g has seen more than a handful of commits since last I tested it, and then it immediately hung the GPU pretty much regardless of what I threw at it.
[11:23] <RAOF> Now, if you had a slightly older GPU, i915g is getting to the point where we might want to ship it in dri-experimental :)
[11:24] <lag> mvo: You are now in possession of my logs
[11:25] <RAOF> asac: Why do you particularly want gallium support for that?  egl_dri2 should give (complete?) GL|ES1 and GL|ES2 support with the classic driver.
[11:25] <RAOF> But not OpenVG, and I guess there may be differing levels of extension support.
[11:25] <asac> RAOF: hmm. are there packages for maverick? guess not right?
[11:25] <RAOF> UUuuuum… dunno :)
[11:25] <asac> RAOF: i want GLES2 accell ... not more
[11:25] <RAOF> Works in Natty, then :)
[11:26] <asac> RAOF: if there are other ways to achieve that i ma happy
[11:26] <RAOF> (And should in xorg-edgers)
[11:26] <asac> RAOF: maverick in xorg-edgers
[11:26] <asac> '
[11:26] <asac> ?
[11:26] <RAOF> Just checking.
[11:27] <RAOF> Yup, I think so.  xorg-edgers has a shiny trunk snapshot of mesa, and should build egl_dri2.
[11:27] <asac> ok what was the script that helps downgrading to archive version for that stuff again?
[11:27]  * asac wants to be save
[11:27] <RAOF> ppa-purge.
[11:28] <RAOF> Available in xorg-egders and also in Natty universe :)
[11:28] <asac> thanks ... i will try ;)
[11:33] <brobostigon> i was talking to someone last about trying to confirm 730099, and trying a non-ubuntu kernel, howeer it reminded me, that only a couple of weeks ago, i had debian sid on my eeepc, and no gpu lockup problems, so it confirms what wnted to test, because of my memory failiure.
[12:42] <lag> mvo: Are you back from lunch yet?
[12:42] <lag> mvo: I'm guessing this may have something to do with my issue: Xorg:1258 conflicting memory types c0000000-c0960000 write-combining<->uncached-minus
[12:45] <tjaalton> umm, a failure to dist-upgrade from 10.10 has little to do with X
[12:49] <mvo> lag: hello, the logs have some uncommon pattern, I wonder what was triggering the conffile prompt for /etc/lsb-release ? did you modify this file manually? it seems the actual problem is a postinst failure from seamonkey-browser, but the error message is very odd (/var/lib/dpkg/info/seamonkey-browser.postrm): No such file or directory)
[12:50] <lag> I haven't modified lsb-release, only read it (to make sure the update was successful 
[12:50] <lag> )
[12:50] <mvo> lag: I can not say much about why gdm does not start anymore, but the error look not good :/
[12:50] <lag> I did manual edit /etc/apt/sources.list
[12:51] <lag> I s/maverick/natty
[12:51] <tjaalton> mvo: a case of the "top of the list" dpkg bug? (the one with gazillion dupes)
[12:51] <mvo> lag: is ther a /etc/lsb-release.dpkg-old  or something like this still left? if so, could you pastebin it please?
[12:51] <lag> But that was to 'fix' the already occurred problem
[12:51] <mvo> tjaalton: well, the seamonkey one is the origin of the failure cascade, but it is a odd failure
[12:52] <lag> Should I try to uninstall it and do another upgrade?
[12:52] <lag> Where did you see the failure?
[12:53] <mvo> lag: I was looking at apt-term.log
[12:53] <lag> tjaalton: It must have something to do with it
[12:53] <lag> tjaalton: I upgrade, x stops working
[12:53] <mvo> hm, actually this looks like a old log 
[12:53] <lag> Okay
[12:55] <tjaalton> lag: but because of the incomplete upgrade, not due to some drive bug
[12:55] <lag> tjaalton: Well I've never seen it before
[12:55] <lag> tjaalton: The kernel has been upgraded too
[12:56] <tjaalton> of course
[12:57] <lag> More timestamps and less DOS EOLs needed in the logs me thinks
[12:58] <lag> Oh I see, they're not EOLs they're backspaces
[13:49] <cnd> lag, the device.event file you sent me is empty
[13:49] <cnd> at least, that's what thunderbird tells me
[13:49] <cnd> I don't know whether to believe it or not :)
[13:51] <lag> cnd: It is on my desktop too
[13:51] <cnd> lag, that's odd
[13:51] <lag> cnd: I can't create another one just yet, as I'm having major dramas with my Desktop
[13:52] <cnd> lag, when you go to create it, chvt to a console
[13:52] <lag> cnd: I don't know why it would be empty though, I followed the instructions very carefully 
[13:52] <cnd> some X drivers, synaptics in particular, grab the event device node
[13:52] <cnd> oh wait, that's in the instructions
[13:52] <cnd> hmm
[13:52] <cnd> lag, you did touch the screen to generate events, right :)
[13:52] <lag> No?
[13:52] <cnd> oh, I guess I need to make that clear :)
[13:52] <lag> That'll be it then :)
[13:53] <lag> I guess you did :)
[13:53] <cnd> you need to generate events for the recording
[13:53] <lag> I'll do it again, when I can log back in to my Desktop
[13:53] <lag> mvo: Any advice on that?
[13:53] <cnd> lag, ok, thansk!
[14:51] <tseliot> Sarvatt: when are we going to have xserver 1.10 RC3 in Natty? (just to know when I should upload nvidia)
[14:56] <Sarvatt> tseliot: could do it today if you want to sponsor ~50 packages :P xorg-edgers is up to date
[14:57] <tseliot> Sarvatt: 50 might be a bit excessive, given my todo list ;) Good to know that it's in xorg-edgers
[14:59] <Sarvatt> i'm not sure though, need to ask RAOF and bryce and see if they have any plans yet, I've had my head in the sand doing other stuff
[15:01] <Sarvatt> it's a pretty painless transition though, 2 xserver patches upstream already and one that needed an easy refresh, everything else just needs rebuilds
[15:06] <tseliot> ah, that's good
[15:54] <Sarvatt> haven't been able to reproduce any kind of text corruption on gen3 intel darnit
[16:33] <tjaalton> RAOF: the mesa seems to work fine, no gpu hangs on 965GM unlike with 7.10
[16:36] <tjaalton> the _new_ mesa, that is
[16:41] <tjaalton> bryceh_: btw, you haven't pushed the latest xorg changes to git
[17:24] <tjaalton> whee, waltop tablets work just fine on natty, need to switch 50-wacom.conf to match it
[18:23] <bryceh_> tjaalton, pushed
[18:59] <Sarvatt> any objections to doing something like this for ati to fix jcastro's bug? http://sarvatt.com/downloads/patches/palm_disable_pageflip.patch
[19:00] <Sarvatt> https://bugs.launchpad.net/xserver-xorg-driver-ati/+bug/715330
[19:04] <jcastro> Sarvatt: it has some issues resuming from suspend, but I haven't investigated
[19:37] <cnd> bryceh_, do you know when the next xorg-server upload will be?
[19:42] <Sarvatt> do we need a FFe for it?
[19:52] <bryceh_> Sarvatt, yeah probably 
[19:52] <bryceh_> cnd, within the next week or so probably
[19:53] <cnd> bryceh_, ok, I've pushed some bug fixes and am working on one last issue right now
[19:53] <cnd> they don't have to go in asap, so it can wait
[19:53] <bryceh_> cnd, oh thought you meant when were we going to do the xserver abi bump
[19:54] <cnd> I mean package upload for xorg-server
[19:54] <cnd> whether or not it includes any abi bumps
=== ajmitch_ is now known as ajmitch
[19:55] <bryceh_> cnd, ok thanks for letting me know. 
[19:56] <Sarvatt> cnd: looks like we're on the same flight to/from budapest along with the rest of the world
[19:56] <cnd> Sarvatt, cool :)
[19:56] <cnd> let me see what seat I am
[19:58] <Sarvatt> I dont have a seat yet, just booking it now
[19:59] <cnd> Sarvatt, I'm at 25G both ways
[19:59] <cnd> Sarvatt, though I doubt you're on the same flight as me going to budapest
[19:59] <cnd> I'm going for the design sprint the week before too :(
[19:59] <Sarvatt> oh whoops, didn't look at the date
[20:00] <cnd> yeah, tricky tricky :)
[20:01] <Sarvatt> well shoot, I accepted it because I thought you and vanhoof would be on it but you're both going early, whoops :P
[20:01] <Sarvatt> seat in front of you has power but you don't, boo
[20:03] <cnd> really?
[20:03] <Sarvatt> cnd: at least it isn't 1 week each in shanghai then portland then 2 weeks in budapest like vanhoof has to do :D
[20:04] <Sarvatt> http://www.seatguru.com/airlines/American_Airlines/American_Airlines_Boeing_767-300_B.php
[20:04] <cnd> Sarvatt, oh well... I don't usually try to do work on these flights
[20:04] <cnd> too hard
[20:05] <cnd> and I should be sleeping on the flight over
[21:37] <bryceh_> cnd, xserver uploaded
[21:38] <cnd> bryceh_, oh, thanks!
[21:47] <LLStarks> is -nv gone from the default archive now?
[21:51] <tjaalton> LLStarks: not yet
[21:51] <tjaalton> bryceh_: thanks!
[21:56] <RAOF> Sarvatt: Yeah, that disable-pagefilp patch looks like a good idea.
[22:34] <bryceh_> so, I've lost track a bit, but is the latest -nvidia support the latest xserver abi bump?
[22:34] <bryceh_> if that's the case, then should we think about updating to the xserver with this abi now?
[22:34] <RAOF> If it does, then yeah.  We should move to 1.10 final.
[22:35] <bryceh_> RAOF, do you want to go ahead and prep the package upload?
[22:35] <RAOF> Yup.
[22:35] <bryceh_> I'll find out what the -nvidia situation is
[22:36] <bryceh_> I think we're good, but just to doublecheck
[22:36] <tjaalton> that should then wait for tseliot to prep nvidia?
[22:36] <tjaalton> he was asking for the schedule this afternoon
[22:36] <bryceh_> tjaalton, ahh, ok
[22:36] <bryceh_> tjaalton, yeah maybe we should set up a staging ppa for this
[22:37] <bryceh_> then we can put all the bits and pieces together in there and do test upgrades
[22:37] <tjaalton> or prepare the packages and we'll upload them tomorrow when we're around
[22:38] <bryceh_> right.  my earlier statement was ambiguous, I was meaning the thinking should be done now, not the upload ;-)
[22:38] <tjaalton> yeah, sure
[22:39] <RAOF> We should certainly coordinate with tseliot.  After all, that's why we haven't updated already :)
[22:56] <bryceh_> ok, looks to me like everything is good to go on the proprietary driver front, but I'll shoot off another coordination email with tseliot and everyone
[22:57] <RAOF> And I'll stop trying to debug this unity deadlock and get on the packaging.\
[23:20] <bjsnider> RAOF, the 270.30 driver works with 1.10 final, and tseliot is waiting for that to be uploaded before he send the blob in. 
[23:20] <bryceh_> alright, I've emailed tseliot and cc'd raof and others
[23:21] <bryceh_> RAOF, I think we can just reuse https://edge.launchpad.net/~ubuntu-x-swat/+archive/ppa for staging purposes
[23:21] <bryceh_> this is pretty much what was in mind when that was set up originally anyway
[23:22] <tjaalton> can the packages get pulled from the ppa to the archive, or would it need another round of uploads?
=== yofel_ is now known as yofel
[23:23] <bryceh_> tjaalton, I think we'll have to do another set of uploads
[23:23] <tjaalton> since if it's the latter, I'd just shove them in the archive. the diff to the current stack is small
[23:23] <bryceh_> it's more the abi change I'm concerned with than actual bugs
[23:24] <tjaalton> rebuilds take care of that, and versioned depends
[23:24] <tjaalton> versioned build-depends
[23:24] <bryceh_> yeah, but in theory that should have worked last time too
[23:24] <tjaalton> well there are packages we are not in charge of
[23:25] <tjaalton> but -video-all doesn't depend on them (like vbox)
[23:25] <tjaalton> or maybe I'm missing something :)
[23:27] <bryceh_> tjaalton, RAOF and I found that when we bumped the ABI going from 1.9 to 1.10 that even though we both tested the individual packages and .debs thoroughly, there were bugs we missed because we installed the .debs individually, resolving dependencies by hand.
[23:28] <bryceh_> so we felt it would be a better practice and not that much additional effort, to stage the packages in a ppa first, so we can easily do test upgrades
[23:28] <bryceh_> tjaalton, it seems that as ubuntu has evolved, the tolerance for cowboying in xserver changes has decreased a lot since a couple years ago ;-)
[23:29] <tjaalton> meh :)
[23:32] <bjsnider> gee, i wonder why?
[23:33] <tjaalton> those bastards breaking blobs again?-)