[08:31] <bryce> tjaalton: -intel merge: http://people.ubuntu.com/~bryce/Uploads/
[08:32] <bryce> tjaalton: also included a couple other patches.  builds ok.  would appreciate a review.  I'll upload tomorrow.
[08:34] <tjaalton> bryce: why not merge 2.3.0 from experimental?-)
[08:34] <tjaalton> and could we finally drop i810
[08:35] <bryce> tjaalton: in part because I want to get 2 patches validated that I'm looking to backport to hardy
[08:35] <tjaalton> no-one uses intrepid..
[08:35] <bryce> heh, I do!
[08:35] <tjaalton> so using hardy-proposed is a better way imho
[08:35] <bryce> (well, for my test box)
[08:35] <tjaalton> ah ok :)
[08:36] <bryce> the one patch is already in hardy-proposed
[08:36] <tjaalton> the packages don't have to be in sync between intrepid and hardy-updates
[08:36] <bryce> also, I think for 2.3.0 we'll be dropping a lot of patches
[08:36] <tjaalton> sure
[08:39] <bryce> tjaalton: also I got word that 2.3.1 is coming out very soon; perhaps that's the one we should merge.
[08:39] <tjaalton> ok
[08:40] <tjaalton> anyway, doing a merge to get one patch in hardy is maybe overkill :)
[08:41] <tjaalton> and probably will get turned down
[08:42] <bryce> actually the reason I'm doing a merge is because I tried doing a regular upload of the patch, and got a reject due to md5sum issues, and I'm guessing the merge needs to go through first
[08:44] <tjaalton> I think it's because -2ubuntu13 is not yet in -updates
[08:44] <tjaalton> hm no
[08:44] <tjaalton> you should be able to upload ubuntu14
[08:44] <tjaalton> to -proposed
[08:45] <tjaalton> er, I meant -1ubuntu13 and 14
[08:45] <bryce> no, I mean I wasn't able to upload to intrepid.  I was able to upload it to hardy-proposed
[08:45] <tjaalton> ah ok
[08:46] <tjaalton> do you have the error message
[08:46] <tjaalton> ?
[08:46] <bryce> yeah
[08:46] <bryce> Rejected:
[08:46] <bryce> MD5 sum of uploaded file does not match existing file in archive
[08:46] <bryce> Files specified in DSC are broken or missing, skipping package unpack verification.
[08:46] <bryce> it's rather obscure what the problem is.  I tried redoing it from scratch 2-3 times, exact same error.
[08:47] <bryce> eh, perhaps it's all not worth the bother.
[08:47] <tjaalton> you tried to upload -1u13 to intrepid? that would fail yes
[08:47] <bryce> oh?  why would it fail?
[08:48] <tjaalton> because it's there already :)
[08:48] <bryce> hmm, I could swear I'd checked
[08:48] <tjaalton> only that the pocket is hardy-proposed
[08:48] <tjaalton> you uploaded it :)
[08:48] <bryce> oh
[08:48] <bryce> feh!
[08:48] <tjaalton> you should use different versioning
[08:49] <tjaalton> like if intrepid had -1ubuntu1, then to get that in hardy you'd upload it as -1u1~hardy1
[08:49] <bryce> like -1u12.1 ?
[08:49] <tjaalton> that's another way yes
[08:49] <tjaalton> but merge 2.3.0 and be done with it for good :)
[08:49] <bryce> yeah
[08:49] <bryce> although not for the reasons I'd assumed ;-)
[08:49] <tjaalton> then when 2.3.1 is released it's easy to re-merge
[08:50] <bryce> yup
[08:50] <tjaalton> so, apart from some patches, there shouldn't be any other changes that we need
[08:50] <tjaalton> libpciaccess should be pushed to main though
[08:51] <bryce> well, I'll do -2ubuntu1 first, just to get all the patches together and since I have it ready, then work on 2.3.x next 
[08:51] <bryce> yeah we definitely need to put a priority on that
[08:51] <tjaalton> ok, the merge looks good
[08:51] <tjaalton> is 19_check_exa_pitch_to_fix_rotate_crash.patch from upstream or your head?-)
[08:52] <tjaalton> (didn't look in the diff, just .changes)
[08:52] <bryce> upstream
[08:52] <tjaalton> ok cool
[08:52] <bryce> but it's not one I'm super confident about.  Probably ok for intrepid but I wanted more testing/verification before putting in for hardy
[08:54] <tjaalton> yep
[09:09] <bryce> uploaded
[10:18] <jcristau> i'm guessing intrepid will likely have xserver 1.5?
[10:18] <bryce> yeah
[10:19] <jcristau> i'll upload a new xorg-server rev today, rebased against the latest server-1.4-branch, fwiw
[10:24] <jcristau> (but first i need the new xtrans)
[10:25] <tjaalton> jcristau: it builds against mesa 7.0.3?
[10:25] <jcristau> tjaalton: "it"?
[10:25] <tjaalton> the server
[10:25] <jcristau> 1.5 doesn't
[10:26] <tjaalton> ah so you don't have packages yet, only the tree?
[10:26] <tjaalton> I'm just confused :)
[10:26] <jcristau> i have packages in experimental, built with --disable-glx --disable-dri --disable-dri2
[10:26] <jcristau> :)
[10:27] <tjaalton> right, remember seeing those
[10:28] <jcristau> but there's a good chance lenny will release with 1.4 anyway :/
[10:28] <tjaalton> is it still planned for sep/oct?
[10:29] <jcristau> something like that
[10:29] <tjaalton> in that case 1.4 is definately a safer bet ;)
[10:29] <jcristau> yeah
[10:30] <tjaalton> although so does intrepid, but we've decided to push the envelope with it :)
[10:31] <tjaalton> 1.4 is getting boring
[11:32] <jcristau> hmm. still shipping the old i810 driver?
[11:39] <tjaalton> yes.
[11:39] <tjaalton> for testing..
[13:07] <tjaalton> yay, pixman synced.. that was fast
[13:21] <kahrytan> How does Screen Resolutions applet get it's mode list ?
[13:22] <tjaalton> it uses xrandr
[13:22] <kahrytan> How does Screen Resolutions applet or X server get it's mode list ?
[13:22] <jcristau> the X server gets it from the monitor
[13:22] <kahrytan> okay. xrandr is wrong in detecting modes for my monitor
[13:22] <tjaalton> kahrytan: log?
[13:22] <jcristau> and xrandr gets it from the X server
[13:22] <kahrytan> What log? it's a GUI app
[13:23] <jcristau> the X log
[13:23] <tjaalton> kahrytan: the xserver log, /var/log/Xorg.0.log
[13:23] <kahrytan> So
[13:24] <james_w> kahrytan has reported this issues as bug 220952
[13:24] <kahrytan> X in Hardy is bugged. 
[13:25] <kahrytan> It doesnt know how to detect my monitor. 
[13:25] <tjaalton> nvidia blob
[13:25] <kahrytan> It has nothing to do with nvidia
[13:25] <tjaalton> how so?
[13:26] <kahrytan> I have tried with NV, Nvidia and without either.
[13:26] <tjaalton> no logfile on the bug
[13:26] <tjaalton> please attach one
[13:26] <jcristau> tjaalton: http://launchpadlibrarian.net/14028337/NV_Output_Xorg.log
[13:26] <kahrytan> You want one w/o the nvidia/nv use
[13:26] <tjaalton> oops
[13:27] <jcristau> no xorg.conf though
[13:27] <jcristau> and, that's not the full log
[13:27] <jcristau> please attach both
[13:27] <kahrytan> xorg.conf is messy
[13:27] <jcristau> then remove it and try again
[13:28] <jcristau> and attach the log from that
[13:28] <kahrytan> How
[13:28] <kahrytan> safely
[13:28] <tjaalton> move the xorg.conf aside and restart the server
[13:28] <kahrytan> it will generate new one from default?
[13:28] <jcristau> mv /etc/X11/xorg.conf /etc/X11/xorg.conf.bak; /etc/init.d/gdm restart
[13:28] <jcristau> or something
[13:29] <kahrytan> It wont use NV/Nvidia will it?
[13:29] <tjaalton> it will use nv
[13:29] <jcristau> it should use nv
[13:29] <tjaalton> should, yes
[13:29] <kahrytan> NV doesnt do OpenGl 
[13:30] <jcristau> you don't need 3d to test this
[13:30] <kahrytan> i know
[13:30] <kahrytan> brb
[13:42] <kahrytan> Xorg.conf didnt regenerate on it's own
[13:42] <tjaalton> no need to
[13:42] <tjaalton> the server autoconfigures itself
[13:42] <kahrytan> but it doesnt create the file
[13:43] <jcristau> no, it doesn't
[13:43] <kahrytan> So no need to attach
[13:43] <tjaalton> the log...
[13:43] <jcristau> need to attach the full log
[13:43] <jcristau> (if there is still a problem)
[13:43] <kahrytan> X uses NV driver?
[13:43] <tjaalton> just attach the log and we'll see
[13:44] <tjaalton> it detects your card and uses the best match
[13:44] <tjaalton> falls back to vesa
[13:44] <tjaalton> if no better alternative
[13:45] <kahrytan> It must rely on NV for modes
[13:46] <tjaalton> please. attach. the. log :)
[13:47] <kahrytan> i know NV detects cuz log says it
[13:48] <kahrytan> https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/220952
[13:48] <tjaalton> reading
[13:50] <tjaalton> what does 'xrandr' on the terminal say?
[13:50] <jcristau> kahrytan: so the problem is that when you start some games they change the resolution and end up with something the monitor doesn't like?
[13:50] <kahrytan> DDC did a crappy job at detecting
[13:50] <kahrytan> jcristau,  Yes.
[13:52] <kahrytan> tjaalton,  attach that too?
[13:52] <jcristau> yes please
[13:52] <kahrytan> i did turn nvidia back on though
[13:52] <jcristau> sigh
[13:53] <kahrytan> cuz gnome was slow w/o it
[13:53] <kahrytan> Nvidia does the same in detecting when in verbose mode. 
[13:54] <jcristau> does xrandr -s 800x600 work?
[13:57] <kahrytan_> jcristau, thank you for that great suggestion. I had to reboot
[13:58] <tjaalton> then try with nv
[13:58] <tjaalton> so we can blame nvidia :)
[13:59] <kahrytan> lol
[13:59] <kahrytan> Please, no nvidia bashing
[14:00] <tjaalton> why not? take a look at the bugs against linux-restricted-modules*
[14:00] <kahrytan> How do I reset xrandr to good rate ?
[14:01] <kahrytan> Because it is not very uh.. ubuntu thing to do. 
[14:02] <tjaalton> which?
[14:02] <tjaalton> damn
[14:07] <kahrytan> Im back
[14:07] <kahrytan> Ive tested xrandr -s 800x600 w/o nv and with it. 
[14:08] <kahrytan> tjaalton, jcristau; guess the verdict
[14:08] <tjaalton> everythin works like a charm?
[14:08] <kahrytan> x likes to use the lowest rate for resolution.
[14:08] <tjaalton> g
[14:09] <tjaalton> 56Hz?
[14:09] <kahrytan> Lowest for NV is 56
[14:10] <kahrytan> It worked with NV/non-NV
[14:11] <kahrytan> And Nvidia does list 56hz
[14:12] <kahrytan> X forked nvidia reports.
[14:14] <kahrytan> Hello?
[14:14] <kahrytan> No talkers?
[14:14] <tjaalton> work
[14:15] <tjaalton> what do you mean "It worked with NV/non-NV"?
[14:15] <kahrytan> yeah
[14:15] <kahrytan> NV does say 56, Nvidia does say 56. 
[14:15] <kahrytan> X just does 56 for NV and not for Nvidia.
[14:15] <tjaalton> so with nv 56Hz works?
[14:15] <kahrytan> yeah
[14:16] <tjaalton> so nvidia bug
[14:16] <kahrytan> no
[14:16] <kahrytan> X bug
[14:16] <tjaalton> explain why
[14:16] <kahrytan> cuz it's obviously not using 56hz for Nivida
[14:16] <tjaalton> uh
[14:17] <tjaalton> f*ck
[14:18] <kahrytan> How do i tell xrandr to use a specifix rate?
[14:18] <tjaalton> man xrandr
[14:19] <tjaalton> but nvidia doesn't support randr-1.2
[14:19] <tjaalton> so I don't think you can specify the rate
[14:19] <kahrytan> or maybe it is that kind of bug
[14:19] <kahrytan> nvidia not supporting new version of xrandr?
[14:19] <tjaalton> if you change the driver and it then fails to work -> driver  bug
[14:20] <tjaalton> yes, that's how it goes in the proprietary world
[14:20] <tjaalton> they lag behind
[14:20] <kahrytan> Not lag
[14:20] <tjaalton> nv doesn't support it either, except for G8x chips
[14:21] <kahrytan> Nvidia will eventually open up
[14:21] <kahrytan> when others do the same
[14:21] <jcristau> others already did
[14:21] <kahrytan> I hear ATI hasnt really
[14:22] <tjaalton> kahrytan: look, I adminster 300+ desktops which use nvidia, so I know the driver is not perfect
[14:22] <tjaalton> +i
[14:22] <jcristau> you hear weird stuff
[14:22] <kahrytan> Does the driver for ati suck ?
[14:22] <jcristau> fglrx certainly does
[14:22] <tjaalton> every driver sucks for some hardware, sure
[14:22] <kahrytan> Who makes that driver?
[14:24] <tjaalton> fglrx? ATI/AMD
[14:24] <kahrytan> And wheres the oss one?
[14:25] <kahrytan> I blame xrandr for breaking nvidia
[14:27] <tjaalton> no, if nvidia can't do 56Hz then it's nvidia bug
[14:27] <tjaalton> bug reassigned already
[14:27] <tjaalton> back to work->
[14:27] <kahrytan> does X uses xrandr for changing resolutions/rates?
[14:28] <kahrytan> tjaalton,  answer?
[14:30] <kahrytan> does X uses xrandr for changing resolutions/rates?
[19:52]  * bryce reads backlog - tjaalton erf that looked painful
[19:53] <bryce> tjaalton: anyway I agree when 2.3.1 is merged that would be a good time to finally turn off i810.  We should probably also put a priority on upstreaming all the remaining 8xx bugs in our tracker