[00:00] bryceh: I've just got a backtrace from the xorg apport hook: http://paste.ubuntu.com/647730/ [00:00] Are you aware of this? [00:07] no hadn't seen it [00:07] thanks [01:15] fixed [01:16] RAOF, push git on xorg [01:17] Bah. Done. [01:17] thanks [01:29] ok, I'm going to work on xdiagnose a bit more but am done fussing with X bugs for today. [01:29] RAOF, the queue's knocked down a bunch, but here's what's left: http://www.bryceharrington.org/Arsenal/Reports/ubuntu-x-swat/workqueue-oneiric.html [01:30] That's looking pretty healthy for the moment! [01:30] keep in mind that list doesn't include bugs we've set as incomplete and are waiting on people to respond on [01:31] that's just ones that you and I need to do something [01:31] but yeah, even the "all bugs reported" status look ok: http://www.bryceharrington.org/Arsenal/Reports/ubuntu-x-swat/totals-oneiric.svg [01:32] of course I worry that the bug you found in the apport hook might have been preventing people from filing bugs.... [01:35] http://www.bryceharrington.org/Arsenal/Reports/ubuntu-x-swat/totals-oneiric-workqueue.svg [01:38] Look at that! We fixed all the bugs just in time last cycle :) [01:39] something like that ;-) [01:39] we're definitely doing better than last cycle [01:40] last time we started at 0 and did pretty well [01:40] this time we started with 20 bugs, that I pulled forward from natty, and we're back down to 20 today [01:47] Man, it'll be good to have the vblank-when-disabling-outputs kernel in natty-updates; I'd guess at least one commenter on slangasek's -intel GPU hang bug is hitting that. [01:51] yeah [01:52] RAOF, you might also look at whether some of the mesa gpu fixes would be worth putting into natty's mesa as sru's [01:54] Yeah. If they apply ;) === Sinnerman is now known as Cobalt [07:08] RAOF, i see that the testing results on bug #753994 are good, but i also see keith asking for updates (to comments) [07:08] Launchpad bug 753994 in linux (Ubuntu Oneiric) (and 2 other projects) "[arrandale] Display is slanted when using 1360x768 resolution (affects: 1) (heat: 8)" [Medium,Confirmed] https://launchpad.net/bugs/753994 [07:09] apw: Yeah. I presume that's why I couldn't find it in any upstream kernel tree. [07:10] RAOF, i see no response from the submitter updating it unless they also updated the title [07:11] apw: I haven't seen any response, either; I don't think that's an artefact of title updating. [07:12] I guess I'll send a Tested-By: reply and see if ajax wants to address the comments. [07:22] bryceh, ping [07:22] RAOF, good idea [07:22] Which is exactly what I've done :) [07:22] diverse_izzue: It's probably a bit late for bryceh. Can I help you? [07:23] RAOF, heh ... as it sounds like its just comment updates that doesn't preclude us from starting the SRU process [07:23] cirtainly if there is no response 'soon' [07:23] apw: You'd need to pull it into the current kernel first! :P [07:24] RAOF, heh yeah, well frankly thats the norm as the devel kernel is always off from mainline too these days [07:24] ROAF, I don't know his time zone. I reported this bug (811640), and he responded by asking me to install a PPA (ppa:bryce/melon). However the xorg-server in that PPA is not new enough to supersede what's in oneiric, so I'm not sure that PPA will do what he intended. [07:26] RAOF, the above is for you, but is misspelled your name :-) [07:28] Yeah. I was just looking at the bug. So, you *could* install those packages manually, and they should work (until you next update, at which point they'll be upgraded to the newer oneiric versions). Or you could wait for tomorrow when bryceh will hopefully have oneiric packages in that PPA :) [07:30] RAOF, they are oneiric packages, but i think there was just an xorg update pushed to oneiric, which is why the ppa ones are already not new enough. [07:30] Ah. That's right, I stopped upgrades from dying. [07:31] RAOF, don't understand [07:31] I updated the xorg package yesterday to fix an upgrade bug. [07:32] is there a way to give a ppa a higher priority than the main repos? [07:33] There is, but you probably don't want that. Just do an ‘aptitude install xserver-xorg-core=$THE_VERSION_IN_THAT_PPA’, and then don't update before rebooting ;) [07:33] oh, ok, and will that automatically pull the right versions of other stuff built from that source package? [07:37] To satisfy dependencies, yeah. [07:40] RAOF, thanks for the help, will now try [08:29] bryceh, latest xdiagnose introduced bug 813367 [08:29] Launchpad bug 813367 in xdiagnose (Ubuntu) "xorg apport hook fails with TypeError: list indices must be integers, not list (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/813367 [12:02] Ah, sna also wants "shm: Replace open-coded version of GetScratchPixmapHeader". Now I understand the sna comments in the desktop meeting :-) [15:00] ricotz, you're now starting to package gnome-shell extensions? [15:20] bjsnider, the package is available for 2 months ;) -- actually cdbs started it [15:45] last i read the gnome recommendation was not to package any of them [15:50] bjsnider, this doesnt sound useful, where do you read this? [15:54] some of them must be installed in /usr because of gsettings schemas which isnt recommended for end-users [16:11] jibel, thanks; investigating [16:31] say, I've noticed that my laptop sees i915 waking up 60 times a second... is there some way to diagnose this so I can get some battery life back/ [16:33] (this is on natty btw) [16:43] kees, look in your logs for error messages, turn on more debugging messages, look at modinfo i915 for any tunables, re-test on oneiric kernel, and if all else fails contact jbarnes [16:44] kernel team might have more structured diagnostics; generally we punt power and suspend type issues over to them. [16:52] kees: and disable the blinking cursor if it's on, also check if the panel clock displays seconds.. [16:56] tjaalton: oooh, blinking cursor! [16:56] let me try that first... [16:57] tjaalton: hm, no change there [17:01] kees: duh, should've helped [17:02] tjaalton: powertop still shows 60 wakeups a second :( [17:04] tjaalton: any idea how to debug this? [17:15] kees: running compiz? [17:20] jcristau: yeah. I don't remember it doing that before, though [17:21] maybe pageflip didn't work before [17:21] hmpf. [17:21] kees: (sorry, got disconnected) it's probably some x client causing it, like compiz as jcristau suggested [17:21] * kees waves goodbye to battery life [17:26] or use unity-2d, that's low power [17:26] yeah [17:35] kees, newer powertop has some trace points for tracking things like this, and might give the pid of what client is being naughty [17:36] kees, 60 wakes/sec sounds like something using vblank events [17:38] bryceh: yeah, so it probably is compiz. I'm going relogin in here in a second... [17:40] kees, if you definitively narrow it to compiz; might check by disabling plugins. [17:40] er, might *also* check [17:43] letting the compositing manager synchronise updates with vblank is what this interrupt is all about, so i'm not surprised it shows up... [17:49] drm_vblank_event_delivered in /sys/kernel/debug/tracing/events/drm sounds like it might give the pid of what's getting the events [17:50] i suppose the interrupt could be disabled when there's nothing to draw though... [17:50] yeah [17:51] dunno if that's supposed to be implemented, i haven't been paying too much attention :) [17:53] or implemented but off due to bugs [17:57] switching off sync to vblank in compiz, opengl plugin seems to work [17:57] albert23, gconf setting? [17:57] ccsm [17:57] kees, ^ [17:59] kees, also I don't know if you already looked but modinfo i915 shows tunables for fiddling rc6 (render c6 deep sleep) and fbc (framebuffer compression). [18:00] those probably won't affect the wakeup problem though. rc6 sleep may give you some suspend power improvements if you have it turned off. [18:01] kees is quiet now; perhaps he ran out of power? ;-) [18:42] bjsnider, i was hoping that tseliot uploaded the new nvidia blob to oneiric, but it didnt :\ [18:42] he* [19:18] ricotz, which, the 275.19 or the 280? [19:19] bjsnider, 275.19 [19:19] i can throw it into x-updates based on his most recent build scripts [19:19] the source package is already there, which is the big deal with the blob. it's very large [19:21] tseliot's probably tied up with oem work or something. I've not talked to him in some time [19:21] i think oneiric users should be ont he 280 at this point because of the recent kernels/x-server support though right? [19:21] there's several oneiric packaging bugs with -nvidia if anyone wants to take a look. look like simple path checking issues and such [19:21] bryceh, he said he'd put it in there not long ago. he might have forgotten [19:21] bjsnider, sounds about right [19:30] as long there is no xserver 1.11 in oneiric using the stable 275.x should be the one [19:31] 280.x doesnt feel that stable for me currently [19:33] what's the xserver version in oneiric right now? [19:33] bjsnider, putting it it x-updates would be nice for now [19:33] oneiric has 1.10 and 275.09.07 [19:33] i think 1.10.2 [19:34] when is 1.11 going in? [19:34] 1.10.2.902 [19:34] 1.11 isn't going in for oneiric [19:34] is this final yet?` [19:34] yep [19:34] ok [19:34] that's kind of conservative [19:34] well, 1.10.3 will be final [19:35] unless there's a 1.10.4 that looks important [19:35] or 1.10.4 ;) [19:35] :P [19:35] bjsnider, precisely [19:36] I don't know if 280 is going to make it into oneiric, but like I said sounds right for x-updates probably [19:36] but up to you guys; if you think it's unstable then perhaps wait. [19:36] no, 275 should go in x-updates [19:36] it's marked beta [19:37] does the 275 build with the oneiric kernel? [19:37] bjsnider, yes, it is already in the repos [19:38] they patched it for 3.0 awhile ago [19:38] like I said there's been some packaging bugs reported, but they seem to be corner cases [19:38] yeah, there are probably multiarch problems [20:44] ricotz, the package is now available for amd64 === yofel_ is now known as yofel [21:22] bjsnider, thanks :)