[06:56] <mlankhorst> RAOF: yeah but that was after that comment he put in :)
[06:57] <mlankhorst> I just wanted to know if there was a way to say 'hold on until I have more info I don't want to risk it getting upstream'
[06:58] <mlankhorst> s/upstream/in updates/
[06:59] <mlankhorst> oh timing
[06:59] <mlankhorst> RAOF: yeah but that was after that comment he put in. I just wanted to know if there was a way to say 'hold on until I have more info I don't want to risk it getting released'
[07:52] <mlankhorst> RAOF: can synaptics be sru'd?
[08:15] <RAOF> mlankhorst: Yes; failing anything else, I'll get to it on my SRU team day tomorrow.
[09:59] <seb128> RAOF, mlankhorst: what's the deal with those workitems?
[09:59] <seb128> [raof] Switch on SNA for -intel in quantal post-alpha1 once it's had a week to bake in -edgers: TODO
[09:59] <seb128> [bryce] Forward SNA-related -intel bugs to Intel between alpha1 and alpha2: BLOCKED
[09:59] <seb128> [ubuntu-x-swat] Evaluate shippability of SNA for -intel in quantal pre-alpha-2: BLOCKED
[09:59] <seb128> [raof] Drop libgl1-mesa-swx11 and 8bit/16bit osmesa packages from mesa post-alpha1: TODO
[09:59] <seb128>  
[10:00] <seb128> we are past post-alpha1 ;-)
[10:00] <seb128> we are post-alpha2!
[10:00] <seb128> do you know why the BLOCKED as well? what is blocking?
[10:05] <RAOF> I may be missing some context here?
[10:16] <seb128> RAOF, sorry, https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-xorg-general
[10:16] <seb128> RAOF, those are work items from that spec
[10:17] <seb128> RAOF, I just noticed reviewing the list that they seemed to be "post a1" items and we are post a2 ... so I was wondering what's the status on thelm
[10:54] <tjaalton> seb128: sna just got enabled in edgers last week
[10:55] <tjaalton> so slightly behind schedule there
[10:55] <mlankhorst> RAOF: lets drop swx11 and enable vdpau then?
[10:55] <tjaalton> and the other task is blocked because of that
[10:56] <tjaalton> let the debian bug reporter sort out the packaging bits first?
[10:56] <tjaalton> that's why it got reverted from our mesa
[10:56] <tjaalton> handling hw-specific config files is not trivial
[10:56] <mlankhorst> oh k
[10:56] <mlankhorst> fairly sure mesa no longer uses config files though
[10:57] <mlankhorst> or at least had an attempt to use autoconf more
[10:58] <tjaalton> /etc/XvMCConfig or what it was called
[10:58] <tjaalton> not for vdpau
[10:58] <mlankhorst> that's used by the xvmc wrapper
[10:58] <tjaalton> the patch enabled that too
[10:59] <mlankhorst> it could be moved towards loading xvmc lib based on driver like vdpau does
[11:00] <mlankhorst> but dropping xvmc altogether sounds like a better plan
[11:00] <tjaalton> yeah, not much useful these days
[11:14] <RAOF> mlankhorst: Yup. That can me my reward after processing the SRU queue tomorrow :)
[11:19] <mlankhorst> ah k
[11:45] <seb128> tjaalton, mlankhorst, RAOF: can somebody update the workitems to reflect the new target? is a3 realistic?
[11:46] <mlankhorst> should be easy
[14:30] <mlankhorst> RAOF: ugh for copyright notice what is preferred?
[14:42] <mlankhorst>  * Copyright © 2012 Canonical
[14:42] <mlankhorst> good enough?
[14:42] <tjaalton> Ltd.
[14:42] <tjaalton> there's probably some template on wiki.c.c
[14:42] <tjaalton> or just copy from elsewhere
[14:43] <mlankhorst> hm ok :)
[14:43] <mlankhorst> I finished my initial dma-buf-mgr stub, surprisingly little survived of my initial code. Now to hook it up..
[15:34] <ogra_> so i got this new machine ... with two radeon 6670 cards and three monitors ...
[15:34] <ogra_> apparently to use all three across the two cards i need to enable xinerama ... which then disables composite ... 
[15:35] <ogra_> is there any reason that we build our xserver in a way that excludes composite when xinerama is on ? i thought that was fixed in 1.10
[15:36] <jcristau> it's not really
[15:36] <ogra_> and what is http://cgit.freedesktop.org/xorg/xserver/commit/?id=84a14fab8f930ef1855444ae4e9e3e14ee008328 ?
[15:37] <ogra_> i thought that enabled it 
[15:37]  * ogra_ was hoping it was only a build time switch we miss
[16:07] <mlankhorst> and v2 sent to ml :)
[17:33] <bryceh> ogra_, have you tried with the blob?
[17:34] <cnd> bryceh: do you know when the quantal X server is going to be uploaded?
[17:36] <bryceh> cnd, do you mean 1.12?  That went u p last week
[17:36] <cnd> bryceh: oh great!
[17:36] <cnd> I just got back from a small vacation
[17:36] <bryceh> cnd, we expect to continue pulling upstream versions off and on through to the 1.13 release
[17:36] <cnd> so I didn't notice
[17:36] <bryceh> cnd, welcome back!
[17:36] <cnd> oh, quantal will be 1.13?
[17:36] <cnd> that makes fixing upstream bugs easier :)
[17:37] <bryceh> well, that's the target, but we'll keep options open until we can bang on it and make sure it's safe
[17:37] <cnd> yeah
[17:37] <cnd> I'm going to be trying to fix an upstream bug today, so us being on 1.12 now is nice
[17:38]  * bryceh nods
[17:39] <bryceh> mlankhorst, reminds me; you now can start rolling the LTS point release scripts to set up those 12.x PPAs now
[17:42] <mlankhorst> bryceh: ah was still busy with dma-buf synching but got to the point where I like the api :)
[17:42] <mlankhorst> do you mean 12.x straight or renamed?
[17:43] <bryceh> mlankhorst, renamed
[17:43] <mlankhorst> oh sure, will do!
[17:48] <mlankhorst> bryceh: kept myself busy with the synching problem, found a nice solution for deadlocks on free, simply wait until deferred fput patches hit mainline, problem goes away by itself there. The synching api itself will be done by a renamed and slightly modified version of ttm reservation.
[17:48] <bryceh> mlankhorst, cool
[17:49] <bryceh> mlankhorst, do those fput patches make any sense to think about SRUing to precise?
[17:49] <mlankhorst> probably not, but it will be in the backported kernel
[17:49]  * bryceh nods
[17:49] <bryceh> ok sounds good
[17:50] <mlankhorst> there's only 1 opportunity for deadlocking now in dma-buf and that should be solved by not taking the lock there.
[19:14] <ricotz> bryceh, hi :)
[19:15] <ricotz> bryceh, could you push a rebuild of nvidia-blob for abi 12 in quantal?
[19:37] <tjaalton> tseliot's business
[19:38] <tjaalton> actually
[19:38] <tjaalton> mlankhorst: you uploaded nvidia the last time?
[19:40] <tjaalton> ricotz: they should be fine, no?
[19:42] <mlankhorst> tjaalton: nope?
[19:42] <mlankhorst> but yeah should have been rebuilt
[19:43] <tjaalton> i'm not sure if they use the automatic stuff
[19:43] <tjaalton> but hardcoded values
[19:43] <ricotz> tjaalton, currently not
[19:43] <ricotz> it just needs and rebuild
[19:43] <ricotz> and/an
[19:44] <tjaalton> https://lists.ubuntu.com/archives/quantal-changes/2012-June/003202.html
[19:44] <tjaalton> how come that didn't fix it then
[19:44] <ricotz> tjaalton, 302.17
[19:44] <tjaalton> that's not in quantal
[19:45] <ricotz> https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers/302.17-0ubuntu1
[19:45] <tjaalton> ok, well that was uploaded even later, so
[19:46] <Sarvatt> he uploaded straight to ubuntu when x was in proposed?
[19:46] <ricotz> Sarvatt, probably
[19:46] <tjaalton> ok
[19:46] <ricotz> tjaalton, fact is it depends on abi 11 instead of 12 ;)
[19:47] <ricotz> so i hope someone could push a rebuild
[19:51] <jcristau> if a rebuild changes that, something's broken
[19:52] <ricotz> jcristau, it automatically picks up the abi version provided by xserver-xorg-dev, what is broken with that?
[19:53] <tjaalton> the blob doesn't automatically gain new abi
[19:53] <jcristau> it's a blob.  you know the abi versions it supports statically
[19:53] <jcristau> it doesn't depend on what you build against at all
[19:53] <ricotz> the packaging does it that way
[19:53] <jcristau> then the packaging is screwed up.
[19:53] <ricotz> so this would need to be changed then
[19:54] <tjaalton> i've downloaded it
[19:55] <ricotz> i am not here to argue about this, i am just saying nvidia-blob is not installable in this condition and a rebuild against the newer xserver fixes it
[19:55] <ricotz> despite the fact that the packaging might need some rethinking in this case
[19:57] <Sarvatt> jcristau: i very much agree, but its like that so its not installable when it doesn't support the new abi in the gui driver installer
[19:57] <tjaalton> hm?
[19:59] <bryceh> %-)
[19:59] <tjaalton> i can push the rebuild
[19:59] <tjaalton> and worry about the packaging later..
[20:04] <ricotz> tjaalton, thanks
[21:15] <tjaalton> nice, firefox and tbird both taking ~80% cpu
[21:52] <tjaalton> ok both were due to the leapsecond mess