[04:43] <RAOF> Oh, balls.
[04:45] <RAOF> I'd like to sync a newer nouveau snapshot from Debian (bugfixes, ability to run without kernel component), but that requires libdrm-nouveau1 to be built from libdrm sources.
[04:52] <tjaalton> bryce: thanks!
[04:52] <tjaalton> RAOF: if you'd wrap up a patch for it.. ;)
[04:54] <RAOF> tjaalton: libdrm?  I might.
[04:59] <tjaalton> yep
[15:18] <bryce> heya tormod 
[15:18] <tormod> hi bryce
[15:18] <bryce> how goes?
[15:19] <tormod> well, thanks. and quite busy :)
[15:20] <bryce> yep, seems to be going around ;-)
[15:20] <tormod> did you look at my logging patch ?
[15:21] <bryce> I did, but only briefly (just flew home from sprint in berlin and still a bit jet lagged)
[15:21] <bryce> offhand it looked good, I think it can be done
[15:21] <tormod> u-dev sprint?
[15:21] <bryce> yep
[15:21] <tormod> did you also go to fosdem?
[15:22] <bryce> nope
[15:22] <tormod> I wanted to go this year, but - too busy
[15:22] <bryce> ETOOMUCHTRAVEL ;-)
[15:23] <tormod> well I hope you can consider my logging patch, because your log patch... how can I say it?
[15:24] <bryce> ??
[15:25] <tormod> the log becomes a bit too scrambled
[15:25] <bryce> scrambled?
[15:25] <tormod> mixed up with timestamps everywhere in the middle of lines
[15:25] <bryce> hrm
[15:26] <tormod> maybe it's a bit ddx dependent, surely looks bad on radeon
[15:27] <tormod> see for example this log with my patch: http://launchpadlibrarian.net/22291743/13.%20Xorg.0.log.patched.WORKING
[15:28] <bryce> do you have an example of a bad log?
[15:29] <tormod> was just looking for one, not here. must be some on launchpad?
[15:29] <bryce> fwiw, I can't actually take credit for the patch - it was written by canonical's oem team.  but definitely something I've wanted in there
[15:32] <jcristau> i guess the problem is LogVWrite can be called with something that's not a full line
[15:32] <tormod> or worse, there was something written before LogVWrite was called
[15:33] <jcristau> same thing :)
[15:34] <tormod> jcristau, sort of :) I proposed to move the time stamp to logWriteVerb 
[15:34] <bryce> jcristau: is x log timestamping something debian would take a patch for?
[15:35] <mnemo> bryce: any idea when the drm kernel patch for the "temporary intel freezes" will be commited to jaunty? --> https://bugs.launchpad.net/xserver-xorg-video-intel/+bug/320813/
[15:35] <tormod> jcristau: see bug #285787
[15:36] <bryce> mnemo: yes in fact I talked with Tim about that last week; he's planning on waiting until upstream has reached a final decision on what they're going to take
[15:36] <tjaalton> mnemo: when linus pulls it in his tree
[15:36] <tjaalton> (hi)
[15:36] <bryce> heya tjaalton
[15:36] <mnemo> bryce: airlie has sent that patch to linus already
[15:36] <jcristau> bryce: i'd rather see it go upstream, i think. debian specific patches -> fail.
[15:36] <tjaalton> mnemo: yes, but linus hasn't pulled that yet
[15:36] <mnemo> aah okay
[15:37] <bryce> jcristau: fair enough
[15:37] <tormod> I also think ubuntu-specific X log format = fail
[15:37] <tjaalton> bryce: howdy
[15:37] <tjaalton> I can reproduce the "maxclient patch breaks compiz on nvidia" -bug
[15:37] <bryce> tormod: then maybe we should drop the patch at beta
[15:38] <bryce> tjaalton, I see coincidentally ajax has started talk of some XID fixup for 11.1
[15:41] <tjaalton> bryce: where's that?
[15:41] <bryce> tjaalton: xorg-devel@
[15:42] <tjaalton> aww, need to subscribe to that
[15:42] <bryce> Subject: XC-MISC / X-Resource / core protocol extension proposal
[15:42] <jcristau> tormod: seen my reply to your acer quirk patch?
[15:43] <tormod> jcristau: yes, saw it, will respond a bit later
[15:43] <jcristau> ok :)
[15:45] <tormod> bryce: apropos X startup performance, I just finished a 55 comment long debugging in bug 319363 - turned out gdm switched to failsafe because the computer took more than 10 seconds to start the mga driver...
[15:45] <tjaalton> haha
[15:45] <tormod> 333 P2 that was :)
[15:47] <tormod> guess what I feel about failsafeX
[15:47] <bryce> patches welcomed
[15:50] <bryce> actually that's probably not failsafe-x but rather gdm
[15:50] <bryce> if not for failsafe-x, you'd end up on the old ncurses error screen
[15:58] <bryce> tormod: ok, your log patch fix uploaded
[15:59] <tormod> bryce: maybe the timeout in gdm (ok that is gdm's fault I guess) should be scaled with cpufreq :)
[16:01] <jcristau> tormod: maybe whatever is taking 10 seconds to start X should be fixed...
[16:01] <tormod> it's just that failsafeX makes debugging a bit more difficult. Maybe LP could scan the logs and mark them if they are VESA logs.
[16:01] <tormod> jcristau: the PC is just that old
[16:02] <bryce> tormod: in what way does it make it more difficult?  the failsafe-x scripts are quite simple and if there are ways they can be improved, I'd love to hear
[16:05] <tormod> it creates misunderstandings in the bug reports - well it could be just me. So many times I have to explain that I don't want that VESA log but I need the other log and the user can't find it or create one and so on.
[16:05] <tjaalton> it's true..
[16:05] <tormod> But I have learned as well: now I ask them to boot with "text" and run xinit
[16:07] <tormod> BTW a trick for getting info in the event of a "black screen" for instance: xinit -e 'sh -c "xrandr --verbose > log" '
[16:07] <bryce> tormod: hrm, but I force that log to Xorg.failsafe.log.  They still include that one?
[16:09] <bryce> tormod: cool, added to https://wiki.ubuntu.com/X/Troubleshooting/BlankScreen
[16:30] <maco> the stuff wgrant was doing with moving features into syndaemon in october, that gets rid of the need for SHMConfig and synclient, right?
[16:34] <maco> (at least for the features that have been migrated, i mean)
[17:11] <tormod> bryce, did you notice xorg-server build broke?
[17:11] <tormod> libgl1-mesa-dev: Depends: libgl1-mesa-glx (>= 7.3) but it is not going to be installed
[17:12] <tormod> oh I guess it only broke on anything !386
[17:13] <bryce> tormod: no didn't notice that
[17:13] <bryce> tormod: link?
[17:15] <tjaalton> it has been broken for ports some time now
[17:15] <bryce> ah ok.  amd64 too?
[17:15] <tjaalton> nothing to see, move along..
[17:15] <tjaalton> no, amd64 is fine
[17:15] <bryce> seemed to build ok on amd64
[17:15] <tjaalton> so is armel and lpia
[17:15] <bryce> ok, yeah I know about those breakages
[17:16] <tormod> sorry for the noise, I haven't got xorg-server build reports for a long while :)
[17:17] <bryce> ok no prob
[17:17] <bryce> better to have a few false alarms than be delayed in solving a build breakage issue
[17:19] <tormod> bryce, keeping the log patch until Beta sounds like a good idea
[17:22] <bryce> tormod: btw I booted with the original log patch and see the issues you described
[17:24] <tormod> bryce: you didn't test it before you uploaded it :)
[17:24] <bryce> tormod: you caught me :-)
[17:25] <tormod> ok I am not so angry at failsafeX any longer, since the original log should be in that failsafe tarball
[17:25] <bryce> at the sprint, with sucky wireless, was hard to do testing
[17:26] <maco> but easy to upload big files? ;)
[17:26] <tormod> you have a dev sprint without good internet connection? that's funny
[17:27] <bryce> maco: a) .dsc's are small files to upload, and b) I do build and upload on my home machine
[17:27] <tormod> probably to keep you working and not watching youtube
[17:27] <bryce> tormod: oh it was horrible, I was lucky to be connected most of the time
[17:27] <maco> i forgot only the .dsc had to go
[17:27] <maco> at uds, you mean?
[17:27] <maco> too many geeks, not enough bandwidth for all of 'em
[17:27] <bryce> maco, no dev sprint
[17:28] <bryce> yeah partly it was overloaded, partly there weren't enough AP's for all the rooms
[17:30] <bryce> can I complain about the chairs too?  sitting in them all week + bad airplane seats on way home = threw out my back yesterday when I got home.  Owwww :-(
[17:30]  * maco hands bryce a cookie
[17:30] <maco> and a bag of ice
[17:30] <bryce> thanks maco :-)
[17:31] <bryce> oh on positive note, I got lucky and got to sit in 1st class on trip home.  sat 2 seats away from Clive Owen.  that was cool
[17:44] <maco> my version of the equivalent sort of luck is running into Dan Kaminsky on Saturday then having him join my friends and i for drinks in the hotel bar
[17:48] <bryce> :-)
[18:06] <maco> so uh, any answer to the question i asked before?
[18:09] <bryce> maco: I could guess but probably would be wrong
[18:09] <bryce> maco: best ask wgrant or tjaalton
[18:09] <maco> wgrant is /away right now
[18:10] <maco> oh. both are.
[18:10] <maco> ok, well i *think* based on a conversation i had with wgrant back in oct that thats how it works, i just wanted to double-check
[18:13] <bryce> maco: you could email them (or mail ubuntu-x@)
[18:14] <maco> well i was asking to double-check something i was going to say on u-d-d, but i just put in a disclaimer that i think that's how it works but wgrant was doing it so he can correct me
[18:16] <maco> holy screen artifacts, batman
[18:17] <maco> are screen artifacts in kde4 a you-guys thing or kde4-guys thing?
[18:30] <bryce> depends
[18:39] <tseliot> maco: it's something they have to deal with in Qt4
[19:59] <maxb> Could someone consider reverting the "Increase MAX_CLIENTS" xorg-server patch until the problems it causes are worked out? It's the most popular problem in #ubuntu+1 right now. (bug 326344)
[20:02] <andersk> Packages with that patch reverted are available in my PPA: https://launchpad.net/~anders-kaseorg/+archive/ppa I have confirmed that the problem is gone with the patch removed. 
[20:03] <maxb> Whoops :-) Guess I should have searched all PPAs before uploading to my own
[22:03] <bryce> maxb: done
[22:53] <zmiq_> hi, I have some trouble with xorg-intel driver, and found a patch that solves it; can anybody apply the patch and recompile for me? I'm using jaunty. Thanks
[23:33] <maxb> zmiq_: Would it not make more sense for you to do it locally?
[23:59] <zmiq_> any hints about how to do it? Just download everything -devel, apply the patch and make will work?