[10:35] <wgrant> Who do I go to for a FinalFreeze exception for main? I've got a couple of -synaptics fixes to push through.
[10:35] <tjaalton> wgrant: pitti for instance
[10:35] <wgrant> WTG
[10:35] <wgrant> Er.
[10:35] <wgrant> WTF
[10:36] <wgrant> One of my patches got pulled upstream
[10:36] <wgrant> Blah.
[10:36] <wgrant> It wasn't even finished.
[10:36] <tjaalton> triggerhappy people :)
[10:37] <wgrant> Well, it was in Ubuntu, but I just rewrote much of it.
[10:38] <wgrant> tjaalton: Does Christoph Brill exist on IRC?
[10:39] <tjaalton> wgrant: dunno
[12:29] <Kano> hi! xforcevesa still does not work with todays daily, no fix commited?
[12:35] <tjaalton> no
[12:36] <wgrant> I wonder if a quirk should be added to -intel to stop it from adding brightness properties on this laptop... they don't work very well.
[12:37] <Kano> why not? thats a really needed fix because running with wrong xserver -> no pic at all. especially when the xserver IS running. like for my nv 8800 gts 512
[12:39] <tjaalton> no time
[12:39] <tjaalton> personally at least
[12:41] <Kano> what i really hate that the last nv oss git change is 7 w ago and it is definitely not working...
[12:41] <Kano> interestingly rv410 works better with xserver 1.5
[12:42] <Kano> something seems fixed the ddc issue, but sadly lenny does not use 1.5 but 1.4.2 so it flickers.... i would like to know which patch fixed it
[12:42] <Kano> it is not the ati driver
[14:11] <jcristau> wgrant: his nick is either egore or cbrill iirc
[15:00] <tseliot> jcristau: I am trying to call GetCrtcInfo() through the python bindings of XCB (xcb-randr is installed) by passing it the equivalent of Display *dpy, XRRScreenResources *resources, RRCrtc crt
[15:00] <tseliot> but it doesn't work
[15:01] <tseliot> as it expects numbers and not objects
[15:01] <tseliot> jcristau: any ideas on this?
[15:10] <tseliot> furthermore it seems to accept only 2 arguments instead of 3
[15:10] <tseliot> or maybe xcb works in a different way?
[15:18] <jcristau> i have no clue about python
[15:19] <tseliot> jcristau: ok but if it were C, could I use the arguments I mentioned above?
[15:20] <tseliot> this is the function prototype:
[15:20] <tseliot> XRRCrtcInfo *
[15:20] <tseliot> XRRGetCrtcInfo (Display *dpy, XRRScreenResources *resources, RRCrtc crtc);
[15:21] <jcristau> tseliot: something like 'dpy = XOpenDisplay(NULL); resources = XRRGetScreenResources(dpy, ...); crtcinfo = XRRGetCrtcInfo(dpy, resources, resources->crtc[i]);' should work
[15:22] <tseliot> jcristau: ok, it might be depend on the python bindings then as I have tried exactly what you have suggestee
[15:23] <tseliot> s/suggestee/suggested/
[15:23] <tseliot> thanks
[15:23] <jcristau> i've only ever used the Xlib C stuff, not xcb nor python, so..
[15:24] <tseliot> ok, no problem
[17:17] <superm1> wgrant, no i can't say i've seen that
[17:19] <bryce> heya
[17:29] <bryce> wgrant: do you have a fix for 270002 ready to go in?  I could upload it and help getting it through feature freeze
[17:30] <bryce> or alternatively if the fix needs more time to bake, we should drop the release-critical task
[18:11] <tjaalton> bryce: he was asking for a release manager earlier today, so that's probably one of the fixes
[18:16] <bryce> 282735 may be the other
[20:11] <mvo_> tseliot: thanks for your work on the fglrx hang during upgrade - what can we do abou tit in update-manger? changing the unpack/install order is hard, what do you think causes it?
[20:13] <tseliot> mvo_: well, I suggested a workaround (instead of the solution) because we don't know what's modprobing the driver at random
[20:14] <tseliot> mvo_: wouldn't it be possible for you to add a script that is executed before a dist-upgrade?
[20:14] <mvo_> tseliot: yes, what do you suggest?
[20:16] <tseliot> mvo_: maybe check the existence of "linux-restricted-modules-*" installed packages
[20:16] <tseliot> mvo_: then do something like sudo apt-get install these_packages
[20:16] <tseliot> so as to upgrade them
[20:17] <tseliot> and finally run the dist-upgrade
[20:17] <tseliot> mvo_: what do you think? Is it doable? (I know it's not elegant but it should work)
[20:18] <mvo_> tseliot: hm, that is really not ideal, and difficult to do
[20:18]  * mvo_ scratches his head
[20:19] <tseliot> mvo_: shall we remove the nvidia.ko and fglrx.ko manually then=
[20:19] <tseliot> ?
[20:20] <mvo_> that is better (but evil too)
[20:20] <mvo_> oh well
[20:20] <tseliot> the main reason why I would like to upgrade the lrm first is the fact that this would remove the 2 binary drivers before the dist-upgrade
[20:21] <mvo_> right
[20:26] <tseliot> mvo_: would it be better if we tested the existence of linux-restricted-modules-$(uname -r) and upgraded that with a script?
[20:31] <mvo_> tseliot: its probably best to test the existance of the module(s) itself. does it happen with nvidia too?
[20:32] <tseliot> mvo_: we have no evidence that it could happen with nvidia but we'd better do it for the 3 flavours of the nvidia driver too
[20:35] <tseliot> that is to say "nvidia_legacy", "nvidia", "nvidia_new"
[20:35] <mvo_> hm, ok
[20:35] <mvo_> and the most plausible explaination is that something tries to modprobe it during the upgrade?
[20:36] <tseliot> yes, maybe it gets the pci id from the modalias file and modprobes the most appropriate driver
[20:37] <tseliot> ati -> fglrx in the bug report
[20:38] <tseliot> I'm not sure though
[21:43] <wgrant> bryce: I have fixes for both, but I'm waiting on upstream's response for one fix.
[21:43] <wgrant> I'm pretty sure they're both fine, but upstream merged one of my previous unfinished changes before I asked for it, so I want to sort that out.
[21:58] <bryce> wgrant: since one is targeted to intrepid, that makes it a high profile issue, and a high priority to get in ASAP
[21:59] <wgrant> bryce: Right, I'll attach a new debdiff now.
[22:00] <wgrant> This one simplifies my syndaemon changes a lot, so it's not small... but syndaemon isn't used by lots of people, and it seems pretty bulletproof now. Damn signal handlers...
[22:01] <wgrant> The tapping fix is definitely fine, however.
[22:57] <mvo_> if one of the X guys could have a look at https://bugs.edge.launchpad.net/ubuntu/+source/gnome-screensaver/+bug/278112 (and especially  https://bugs.edge.launchpad.net/ubuntu/+source/gnome-screensaver/+bug/278112/comments/45 ) that would be most appreciated
[22:57] <ubottu> Launchpad bug 278112 in compiz "Screensaver doesn't start" [Medium,In progress] 
[23:01] <bryce> mvo, sorry I'm completely swamped today, can it wait?
[23:19] <mvo_> bryce: it has to then I guess. would be nice though. while I think its good, its a bit scary to patch in this area
[23:22]  * mvo_ needs to go to bed now