[04:43] Oh, balls. [04:45] 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] bryce: thanks! [04:52] RAOF: if you'd wrap up a patch for it.. ;) [04:54] tjaalton: libdrm? I might. [04:59] yep [15:18] heya tormod [15:18] hi bryce [15:18] how goes? [15:19] well, thanks. and quite busy :) [15:20] yep, seems to be going around ;-) [15:20] did you look at my logging patch ? [15:21] I did, but only briefly (just flew home from sprint in berlin and still a bit jet lagged) [15:21] offhand it looked good, I think it can be done [15:21] u-dev sprint? [15:21] yep [15:21] did you also go to fosdem? [15:22] nope [15:22] I wanted to go this year, but - too busy [15:22] ETOOMUCHTRAVEL ;-) [15:23] well I hope you can consider my logging patch, because your log patch... how can I say it? [15:24] ?? [15:25] the log becomes a bit too scrambled [15:25] scrambled? [15:25] mixed up with timestamps everywhere in the middle of lines [15:25] hrm [15:26] maybe it's a bit ddx dependent, surely looks bad on radeon [15:27] see for example this log with my patch: http://launchpadlibrarian.net/22291743/13.%20Xorg.0.log.patched.WORKING [15:28] do you have an example of a bad log? [15:29] was just looking for one, not here. must be some on launchpad? [15:29] 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] i guess the problem is LogVWrite can be called with something that's not a full line [15:32] or worse, there was something written before LogVWrite was called [15:33] same thing :) [15:34] jcristau, sort of :) I proposed to move the time stamp to logWriteVerb [15:34] jcristau: is x log timestamping something debian would take a patch for? [15:35] 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] Error: Could not parse data returned by Ubuntu: timed out (https://launchpad.net/bugs/320813/+text) [15:35] jcristau: see bug #285787 [15:36] Error: Could not parse data returned by Launchpad: timed out (https://launchpad.net/bugs/285787/+text) [15:36] 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] mnemo: when linus pulls it in his tree [15:36] (hi) [15:36] heya tjaalton [15:36] bryce: airlie has sent that patch to linus already [15:36] bryce: i'd rather see it go upstream, i think. debian specific patches -> fail. [15:36] mnemo: yes, but linus hasn't pulled that yet [15:36] aah okay [15:37] jcristau: fair enough [15:37] I also think ubuntu-specific X log format = fail [15:37] bryce: howdy [15:37] I can reproduce the "maxclient patch breaks compiz on nvidia" -bug [15:37] tormod: then maybe we should drop the patch at beta [15:38] tjaalton, I see coincidentally ajax has started talk of some XID fixup for 11.1 [15:41] bryce: where's that? [15:41] tjaalton: xorg-devel@ [15:42] aww, need to subscribe to that [15:42] Subject: XC-MISC / X-Resource / core protocol extension proposal [15:42] tormod: seen my reply to your acer quirk patch? [15:43] jcristau: yes, saw it, will respond a bit later [15:43] ok :) [15:45] 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] Launchpad bug 319363 in xorg "Can not get 1024x768 video mode by undetected monitor and Matrox G100 8MB graphics adapter" [Undecided,Confirmed] https://launchpad.net/bugs/319363 [15:45] haha [15:45] 333 P2 that was :) [15:47] guess what I feel about failsafeX [15:47] patches welcomed [15:50] actually that's probably not failsafe-x but rather gdm [15:50] if not for failsafe-x, you'd end up on the old ncurses error screen [15:58] tormod: ok, your log patch fix uploaded [15:59] bryce: maybe the timeout in gdm (ok that is gdm's fault I guess) should be scaled with cpufreq :) [16:01] tormod: maybe whatever is taking 10 seconds to start X should be fixed... [16:01] 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] jcristau: the PC is just that old [16:02] 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] 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] it's true.. [16:05] But I have learned as well: now I ask them to boot with "text" and run xinit [16:07] BTW a trick for getting info in the event of a "black screen" for instance: xinit -e 'sh -c "xrandr --verbose > log" ' [16:07] tormod: hrm, but I force that log to Xorg.failsafe.log. They still include that one? [16:09] tormod: cool, added to https://wiki.ubuntu.com/X/Troubleshooting/BlankScreen [16:30] 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] (at least for the features that have been migrated, i mean) [17:11] bryce, did you notice xorg-server build broke? [17:11] libgl1-mesa-dev: Depends: libgl1-mesa-glx (>= 7.3) but it is not going to be installed [17:12] oh I guess it only broke on anything !386 [17:13] tormod: no didn't notice that [17:13] tormod: link? [17:15] it has been broken for ports some time now [17:15] ah ok. amd64 too? [17:15] nothing to see, move along.. [17:15] no, amd64 is fine [17:15] seemed to build ok on amd64 [17:15] so is armel and lpia [17:15] ok, yeah I know about those breakages [17:16] sorry for the noise, I haven't got xorg-server build reports for a long while :) [17:17] ok no prob [17:17] better to have a few false alarms than be delayed in solving a build breakage issue [17:19] bryce, keeping the log patch until Beta sounds like a good idea [17:22] tormod: btw I booted with the original log patch and see the issues you described [17:24] bryce: you didn't test it before you uploaded it :) [17:24] tormod: you caught me :-) [17:25] ok I am not so angry at failsafeX any longer, since the original log should be in that failsafe tarball [17:25] at the sprint, with sucky wireless, was hard to do testing [17:26] but easy to upload big files? ;) [17:26] you have a dev sprint without good internet connection? that's funny [17:27] maco: a) .dsc's are small files to upload, and b) I do build and upload on my home machine [17:27] probably to keep you working and not watching youtube [17:27] tormod: oh it was horrible, I was lucky to be connected most of the time [17:27] i forgot only the .dsc had to go [17:27] at uds, you mean? [17:27] too many geeks, not enough bandwidth for all of 'em [17:27] maco, no dev sprint [17:28] yeah partly it was overloaded, partly there weren't enough AP's for all the rooms [17:30] 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] and a bag of ice [17:30] thanks maco :-) [17:31] 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] 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] :-) [18:06] so uh, any answer to the question i asked before? [18:09] maco: I could guess but probably would be wrong [18:09] maco: best ask wgrant or tjaalton [18:09] wgrant is /away right now [18:10] oh. both are. [18:10] 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] maco: you could email them (or mail ubuntu-x@) [18:14] 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] holy screen artifacts, batman [18:17] are screen artifacts in kde4 a you-guys thing or kde4-guys thing? [18:30] depends [18:39] maco: it's something they have to deal with in Qt4 [19:59] 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:00] Launchpad bug 326344 in xorg-server "compiz/kwin freezes on login as of xorg-server 1.5.99.902-0ubuntu2" [Critical,Confirmed] https://launchpad.net/bugs/326344 [20:02] 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] Whoops :-) Guess I should have searched all PPAs before uploading to my own [22:03] maxb: done [22:53] 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] zmiq_: Would it not make more sense for you to do it locally? [23:59] any hints about how to do it? Just download everything -devel, apply the patch and make will work?