[05:56] <tjaalton> bryceh: oh you took the task to send the patches upstream, nice :)
[05:56] <tjaalton> i just had a brief look at the remaining patches yesterday and spotted these two
[05:56] <tjaalton> bryceh: btw, you bumped the package revision of xorg-server ;)
[07:32] <ricotz> Sarvatt, thanks for pushing the driver updates that fast
[07:33] <bryceh> tjaalton, dch's fault :-)
[07:41] <tjaalton> don't use -i ;)
[07:42] <bryceh> tut tut, use -i all the time
[07:44] <tjaalton> it already increments the version when the previous entry is finalized, so -i is rarely needed
[07:46] <bryceh> huh
[07:49] <mlankhorst> morning btw
[07:50] <tjaalton> bryceh: ahh, you need DEBCHANGE_RELEASE_HEURISTIC="changelog" in .devscripts
[07:50] <tjaalton> then it works properly
[07:51] <bryceh> tjaalton, aha thanks
[07:52] <tjaalton> normally i just edit the changelog directly, but dch adds the multimaint-tags
[07:53] <bryceh> yeah same
[07:54] <RAOF> Moshi moshi.
[07:58] <tjaalton> so the big api change got merged in xserver master, and for 1.13 we might see some of the hotplug/offload functionality too
[08:00] <tjaalton> anyway, 12,5h until the meeting ;)
[08:01] <jcristau> tjaalton: i think that's the default in recent devscripts fwiw
[08:02] <tjaalton> oh
[08:02] <tjaalton> not on precise anyway
[08:02] <tjaalton> I tested it now and noticed the difference
[08:03] <tjaalton>  2.11.6ubuntu1
[08:03] <tjaalton> but makes sense
[08:03] <tjaalton> yeah changed in 2.11.7
[08:04] <jcristau> i've had to put it in .devscripts for years so i'm happy it's finally changed :)
[08:57] <mvo> could someone check https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1008864 please? it appears that for some users the python equivalent of glxinfo in software-center causes a full X crash on intel: python /usr/share/pyshared/debtagshw/opengl.py is what they run
[09:03] <tjaalton> mvo: doesn't crash here with sandybridge on 3.4 kernel, will try with the precise one
[09:04] <mvo> tjaalton: thanks, maybe some odd cnfiguration on the users system?
[09:04] <tjaalton> mvo: not necessarily, intel drm is in rather bad shape on 3.2 :/
[09:05] <tjaalton> some fixes in -proposed
[09:05] <mvo> good to hear
[09:05] <mvo> (about the fixes, not the bad shape ;)
[09:05] <tjaalton> :)
[09:05] <tjaalton> and more being validated
[09:11] <tjaalton> mvo: still doesn't crash :/
[10:19] <RAOF> tjaalton: When's the meeting, again?
[10:20] <tjaalton> RAOF: 21:30 UTC
[10:20] <tjaalton> so, 10h from now
[10:20] <tjaalton> bit early for you, late for me ;)
[10:20] <mlankhorst> slightly late
[10:22] <tjaalton> no too bad, the other night I was up until 3am+ playing infamous2..
[10:33] <tjaalton> sweet, intuos5 backport works
[10:33] <tjaalton> lunch->
[18:11] <bcurtiswx> in 12.04 i have a Dell U3011 monitor with 2560x1600 resolution, but after fresh install i only see 1600x1024 as max resolution
[18:12] <bcurtiswx> how do I go about forcing 2560x1600 ?
[18:13] <tjaalton> which driver?
[18:13] <bcurtiswx> nvidia
[18:13] <bcurtiswx> nouveau i think
[18:13] <bcurtiswx> NVIDIA Quadro NVS 295
[18:13] <tjaalton> check that it's actually being used and not vesa
[18:13] <bcurtiswx> tjaalton, how do I do this?
[18:13] <tjaalton> Xorg.0.log
[18:14] <bcurtiswx> where at? /etc/X11 ?
[18:14] <tjaalton> /var/log
[18:14] <bcurtiswx> /var/log ?
[18:14] <bcurtiswx> ok
[18:14] <bcurtiswx> brb
[18:14] <tjaalton> or 'dmesg|grep nouveau'
[18:15] <tjaalton> hmm if it's a fresh install then it should be used
[18:15] <tjaalton> thought there would be remnants of the nvidia blob
[18:17] <bryceh_> tjaalton, wonder how many reasons we could dream up for why a system would max out at a lower resolution.
[18:18] <tjaalton> bryceh_: :)
[18:18] <bryceh_> bet there's at least a couple dozen
[18:18] <tjaalton> there are many, but let's rule out the obvious ones first..
[18:18] <tjaalton> like, kms disabled for one reason or another
[18:18] <bryceh_> tjaalton, most obvious being stray xorg.conf?
[18:19] <tjaalton> bcurtiswx: are you sure that your card has enough power, in other words it has the extra power cable attached?
[18:19] <tjaalton> I used to have such issues many times, damn hw builders
[18:20] <tjaalton> bryceh_: well, not if it's a fresh install, but yeah
[18:20] <bcurtiswx> tjaalton, not sure about extra power cord, it's a brand new build delivered yesterday from DELL
[18:20] <bcurtiswx> i don't think it would be underpowered
[18:20] <bryceh_> ahhhhhh
[18:21] <bryceh_> bcurtiswx, so it has proper resolution initially, but you wiped the Dell image and reinstalled, and now you don't have it?
[18:21] <bcurtiswx> tjaalton, i grep dmesg for vesa dn nouveau and VESA comes up with results while nouveau does not
[18:21] <bcurtiswx> s/dn/in
[18:21] <bryceh_> tjaalton, should we ask him for the Xorg.0.log, or would that be cheating like looking at the lid on the puzzle box?
[18:22] <bcurtiswx> i can get that for ya
[18:22] <tjaalton> heh
[18:22] <bcurtiswx> is there a way to send a text file to pastebin ?
[18:22] <bryceh_> pastebinit!
[18:22] <tjaalton> bcurtiswx: install pastebinit, then run 'pastebinit /var/log/Xorg.0.log'
[18:22] <bcurtiswx> ok brb
[18:22] <tjaalton> echo!
[18:23] <bcurtiswx> +
[18:24] <bcurtiswx> bryceh_, tjaalton http://paste.ubuntu.com/1027284/
[18:24] <bryceh_> ah, -nvidia
[18:25] <bryceh_> use the nvidia graphics config utility thingee
[18:26] <bcurtiswx> ?
[18:26] <Sarvatt> bcurtiswx: you have it hooked up via a single link cable it looks like
[18:26] <Sarvatt> is that dvi or dp?
[18:27] <bcurtiswx> its a DVI cord plugged into one that looks like HDMI but it's not quite
[18:27] <Sarvatt> if its dvi you need a dual link cable to use the full resolution
[18:27] <bryceh_> [    33.660] (--) NVIDIA(0): DELL U3011 (DFP-0): Internal Single Link TMDS
[18:27] <Sarvatt> ah yeah could be that too
[18:28] <Sarvatt> you need an actual dual link dvi cable the whole way or to use displayport, cant do it over HDMI either
[18:28] <bryceh_> huh, that would not have been on my two dozen reasons list
[18:32] <tjaalton> would've been on mine :)
[18:32] <tjaalton> and it's using the blob
[18:32] <tjaalton> so not exactly fresh install
[18:32] <tjaalton> to the letter :)
[18:33] <tjaalton> i had a similar monitor for several years, and they're quite picky
[18:33] <Sarvatt> those 2560x1600 monitors are pains in the butt
[18:33] <tjaalton> this 27" 25x14 is pretty nice
[18:33] <tjaalton> :)
[18:34] <Sarvatt> oh ya got one?
[18:34] <tjaalton> if only it wouldn't turn off by itself several times a day
[18:34] <tjaalton> yeah
[18:34] <tjaalton> for two months now
[18:34] <tjaalton> samsung sa850t
[18:39] <Sarvatt> bcurtiswx: err so
[18:39] <Sarvatt> http://www.nvidia.com/object/product_quadro_nvs_295_us.html
[18:39] <Sarvatt> says you need to use displayport
[18:40] <Sarvatt> guess ya can get a displayport to dual link dvi adapter
[18:41] <tjaalton> or just use a dp cable
[18:41] <tjaalton> since the monitor has a dp port
[18:41] <Sarvatt> bcurtiswx: if you're near woodbridge I can give ya a dp cable :P
[18:41] <bcurtiswx> OK, i hooked up a second cable
[18:41] <bcurtiswx> its one screen that Ubuntu sees as two
[18:42] <bcurtiswx> how do I make it work?
[18:42] <tjaalton> huh?
[18:42] <bcurtiswx> OK my monitor has TWO DVI hookups
[18:42] <bcurtiswx> and i have two DVI-DP connections
[18:43] <tjaalton> don't do that
[18:43] <bcurtiswx> tjaalton, then what shal I do ?
[18:44] <Sarvatt> its the dvi-dp adapters that are limiting you to single link bandwidth
[18:44] <Sarvatt> ya need a displayport cable
[18:44] <tjaalton> use either a displayport cable, or a dual-link dvi-cable with a dp->dl-dvi adapter
[18:44] <Sarvatt> the cables like $5 vs a $50 dual link dvi to displayport adapter
[18:44] <tjaalton> yes, the cheap passive adapters only do single-link
[18:44] <tjaalton> i know, I have two :)
[18:45] <bcurtiswx> i have one cord that takes on DVI and splits it into two
[18:45] <bcurtiswx> one*
[18:46] <bcurtiswx> that what you mean?
[18:46] <tjaalton> no
[18:46] <tjaalton> dl-dvi is a cable that has all the pins connected
[18:46] <tjaalton> but that won't work either unless you have a proper dp->dl-dvi adapter
[18:46] <tjaalton> which is an active box with a power source
[18:47] <tjaalton> and costs money
[18:47] <tjaalton> well, more than the 15EUR a passive one is
[18:47] <tjaalton> maybe 50
[18:47] <Sarvatt> what ya need is something like this http://www.amazon.com/PTC-Premium-Series-DisplayPort-Displayport/dp/B001MIB0SU/ref=sr_1_1?ie=UTF8&qid=1339008125&sr=8-1
[18:47] <Sarvatt> i'm not sure if you have full sized displayport or mini on the gpu though
[18:47] <Sarvatt> but ya said it looked like hdmi so probably full sized
[18:52] <Sarvatt> bcurtiswx: aren't you in fairfax? http://www.microcenter.com/single_product_results.phtml?product_id=0308064 is the only one i can find for sale in a local shop
[18:52] <bcurtiswx> Sarvatt, yes i'm at GMU in fairfax
[18:53] <bcurtiswx> what's with that displayport to displayport hookup?
[18:53] <tjaalton> it's the best you can get
[18:53] <tjaalton> and cheapest
[18:53] <bcurtiswx> we have a cord with displayport on both ends
[18:53] <tjaalton> so use that
[18:54] <bcurtiswx> how? the card is displayport and monitor is DVI
[18:54] <Sarvatt> the monitor has displayport
[18:54] <Sarvatt> dell says it does at least
[18:54] <bcurtiswx> hmm, maybe i'm blind (wouldn't surprise me)
[18:54] <bcurtiswx> brb
[18:54] <tjaalton> it has a dp, two dl-dvi, two hdmi-1.3, vga..
[18:55] <tjaalton> or it's not U3011 :)
[18:55] <Sarvatt> bcurtiswx: right next to the orange audio plug
[18:55] <tjaalton> :)
[18:58] <bcurtiswx> it's right next to the DVI plug which we couldn't see the DP port without not being lazy
[18:58] <Sarvatt> http://sarvatt.com/dp.png
[18:58] <bcurtiswx> thanks, gonna go switch that up
[18:59] <Sarvatt> cool beans
[18:59] <Sarvatt> that should "just work"
[19:06] <mlankhorst> hybrid graphics is fun
[19:06] <mlankhorst> I keep hitting the hard problems early :D
[19:10] <bcurtiswx> Sarvatt, bryceh_, Thanks :) I feel dumb, but It works and thats the important part
[19:10] <bcurtiswx> Sarvatt, I'm in Falls Church now
[20:31] <tjaalton> meeting time?
[20:31] <tjaalton> bryceh_, mlankhorst, RAOF, Sarvatt
[20:32] <tjaalton> uh
[20:32] <tjaalton> 1h from now
[20:32] <tjaalton> sorry :)
[20:32] <tjaalton> didn't realize the uk time isn't utc during summer time
[21:12] <bryceh_> :-)
[21:22] <mlankhorst> morning
[21:22] <mlankhorst> di
[21:24] <RAOF> Heh.
[21:33] <RAOF> bryce, mlankhorst, Sarvatt, tjaalton: *Now* it's meeting time :)
[21:33] <tjaalton> finally
[21:35] <mlankhorst> wb
[21:35] <bryceh> so
[21:35] <mlankhorst> but yeah lets see *checks email*
[21:36] <bryceh> lts first?
[21:36] <mlankhorst> sure
[21:36] <bryceh> mlankhorst, alrighty take it, where we at?
[21:36] <mlankhorst> well the repository is up so I think at this point we just need to land the stack in Q first :)
[21:37] <mlankhorst> I have been spending some time on upstream atm, helping airlied with his hybrid graphics work
[21:37] <bryceh> ok, any outstanding issues aside from the uninstallation problem?
[21:37] <mlankhorst> it's not going to be supported afaict
[21:37] <bryceh> ok
[21:38] <mlankhorst> so it's not that big a deal
[21:38] <bryceh> we'll need to document it where appropriate, but guess we can consider that good enough
[21:38] <bryceh> ok, next item was copying nouveau ddx
[21:38] <bryceh> I think that's fine.  anyone got concerns there?
[21:39] <mlankhorst> well the support for that is in debian now, will still require 3.4 kernel
[21:39] <tjaalton> but fine for quantal?
[21:39] <RAOF> And fine for the LTS backports, too; that's exactly why we depend on the lts kernel backport :)
[21:39] <bryceh> mlankhorst, does current nouveau ddx *require* 3.4, or just that you don't get the latest functionality unless running 3.4?
[21:40] <mlankhorst> bryceh: some fermi changes landed that will disable accel for fermi unless you have 3.4
[21:40] <bryceh> ok so yeah, quantal and ppas which depend on the lts kernel backport.  guess that means not in x-updates ppa though
[21:41] <mlankhorst> about that, what should be my focus atm? I've been helping airlied with his hybrid work on the nouveau side
[21:42] <tjaalton> that's fine
[21:42] <RAOF> That seems valuable to me
[21:43] <mlankhorst> mostly on the nvidiaside because i know it better :)
[21:43] <bryceh> yeah, also bug reports filed against precise
[21:43] <tjaalton> about the backports; maybe drop -backport from the name to follow the kernel name
[21:43] <bryceh> tjaalton, might wait and see what vanhoof finds out for name suggestions, but  yeah
[21:43] <RAOF> Has the nomenclature for those packages stabilised?
[21:44] <tjaalton> mlankhorst: there were some nouveau bugs filed against libdrm that I moved to -nouveau, so if you have some time to take a look that would be great
[21:44] <tjaalton> bryceh: right
[21:44] <bryceh> RAOF, I think the kernel team JFDI'd
[21:44] <tjaalton> -lts-quantal
[21:44] <tjaalton> is what it has now
[21:44] <mlankhorst> but hybrid graphics will require at least 3.5
[21:44] <mlankhorst> maybe 3.6 depending on synch support
[21:44] <tjaalton> we'll have it
[21:44] <tjaalton> 3.5-rc1 is already being prepared
[21:44] <bryceh> ok, so next topic is hybrid gfx
[21:45] <tjaalton> and hybrid is still ways off :)
[21:45] <RAOF> We might not have 3.6 :)
[21:45] <tjaalton> oops
[21:45] <tjaalton> xserver master now has the api groundwork for the new functionality
[21:45] <bryceh> mlankhorst, I gather this is the main topic you wanted to see discussion on?
[21:46] <tjaalton> and airlied sent an email commenting on the 1.13 release schedule and what he might want to see happening this cycle
[21:46] <mlankhorst> indeed :)
[21:47] <tjaalton> so, probably not all of it but output slaves (hotplug usb etc) and dri2 offload
[21:47] <mlankhorst> tjaalton: Yeah I was helping airlied a bit by writing some tests for behavior, showing how nvidia hardware worked and help understand problem a bit later
[21:47] <mlankhorst> and even fix a firmware bug
[21:47] <RAOF> My email is being slow; was there a tentative date for 1.13?
[21:47] <mlankhorst> september-ish
[21:47] <tjaalton> yeah
[21:47] <tjaalton> early sep
[21:48] <tjaalton> 4th
[21:49] <mlankhorst> but maybe the patches for synching could be cherry picked
[21:49] <mlankhorst> if it happens not to land in 3.5, it might not be that big depending on what intel hw supports
[21:49] <tjaalton> yeah cherry-picking is possible, at least if we know what to cherry-pick early on
[21:50] <RAOF> Or we could feed that request to the kernel team; is 3.6 still looking possible, given appropriate motivation?
[21:50] <mlankhorst> the specific changes will be small though
[21:50] <tjaalton> that decision is made mid-august or so?
[21:51] <mlankhorst> so maybe I should rest a bit on coding on the hybrid stuff for now and only influence the decisions about it still being made
[21:51] <mlankhorst> the synching will probably be done inside the kernel only
[21:51] <tjaalton> whatever is the latest is what's best for intel anyway.. has been the case for a long time
[21:52] <RAOF> I'm sure haswell will work *swimmingly* with 3.5! :)
[21:52] <mlankhorst> in any case I think apart from input to the linaro guys about this dmabuf stuff
[21:52] <mlankhorst> that there's not much more I can do here atm
[21:52] <tjaalton> RAOF: ! :)
[21:52] <bryceh> mlankhorst, could be, yeah
[21:53] <bryceh> mlankhorst, do you have hybrid hw?
[21:53] <mlankhorst> bryceh: just one laptop atm :)
[21:53] <bryceh> mlankhorst, if not then yeah probably backburner it for time being and just follow discussion
[21:54] <mlankhorst> but speaking of which I had to ask you about hardware so if you have some that looks interesting and maybe some radeon as well :)
[21:54] <bryceh> I don't think hybrid is **so** important that it'd warrant doing a franken-drm for it
[21:55] <mlankhorst> well we should be able to turn it off the proper way at least with the 1.13 changes
[21:55] <tjaalton> there's not much left in the drm left aiui
[21:55] <tjaalton> uh
[21:55] <mlankhorst> i mean, turn off graphics card like raof's
[21:55] <RAOF> Not much *more* to do in the drm :)
[21:56] <tjaalton> that
[21:56] <bryceh> mlankhorst, what I tend to do is have a few PC boxes and random assortment of cards to mix and match.  Especially for nvidia/radeon testing that's what I'd suggest
[21:56] <mlankhorst> RAOF: Yeah the patches will probably be small though
[21:57] <mlankhorst> especially since nouveau already has synch code in place
[21:57] <bryceh> you can get a variety of low end video cards pretty cheaply; for most testing purposes those will be adequate, then once and a while pick up a high end card just for fun
[21:57] <mlankhorst> bryceh: true, but what about radeon+intel hybrid?
[21:57] <RAOF> Right. So, likely to be either cherrypickable, or another motivation to use 3.6.
[21:58] <bryceh> mlankhorst, for that you'll need a laptop, and requisitioning one from pete is probably the least hassly way to do it
[21:58] <tjaalton> mlankhorst: tseliot should have those, and RAOF has one too I believe
[21:58] <RAOF> mlankhorst: I'm not sure if the BIOSes support it, but you should be able to do radeon+intel hybrid on a desktop, too?
[21:58] <mlankhorst> if we can get the synch changes in, it would be nice to have
[21:58] <mlankhorst> RAOF: All the ones I have seemed to always disable intel. :/
[21:59] <bryceh> mlankhorst, magic words seem to be "I'm interested in broken hybrid graphics laptops that I can work on fixing"  ;-)
[21:59] <mlankhorst> hehehhe
[22:00] <bryceh> mlankhorst, at uds we talked about the feasibility of replicating a hybrid box via a PC with onboard video + pci-e card, and sounded like it might be another thing to try out at least for some testing purposes
[22:00] <mlankhorst> bryceh: yeah but it seems the card just disappears atm, if i had a less buggy bios.
[22:01] <bryceh> mlankhorst, so, write up a request to send to pete.  I can proof-read it for you ahead of time if you'd like.
[22:01] <mlankhorst> sure
[22:02] <bryceh> mlankhorst, ok anything else on hybrid?
[22:02] <mlankhorst> nope, next topic?
[22:02] <bryceh> SNA!
[22:02] <bryceh> snaaaah snaaaah
[22:02] <bryceh> RAOF, feel like switching it on now?
[22:02] <mlankhorst> oh that's needed for hybrid btw
[22:02] <tjaalton> is upstream enabling it soon?
[22:02] <bryceh> of course
[22:03] <mlankhorst> because of Y-major tiling
[22:03] <RAOF> sna's needed for hybrid?
[22:03] <bryceh> tjaalton, I think it is already switched on by debian and we're forcing it off
[22:03]  * bryceh doublechecks
[22:03] <RAOF> Only in experimental.
[22:03]  * RAOF merged 2.19 in last week. Or Monday. Or something.
[22:03] <tjaalton> right
[22:03] <mlankhorst> RAOF: Probably going to be because of the blitter being braindead and sna actually using the 3d hardware for it
[22:03] <bryceh>   * No SNA for unstable, it's too fast of a moving target for now.
[22:03] <tjaalton> yeah I remember airlied mentioning that
[22:04] <RAOF> The last thing I heard about sna from !ickle was airlied talking about corruption that a fellow RHer was seeing when they tried it.
[22:04] <tjaalton> he's not going to fix uxa :)
[22:04] <RAOF> And ickle saying ?yeah, you need at least the very latest everything or I don't care?
[22:04] <tjaalton> hehe
[22:04] <tjaalton> "typical"
[22:05] <bryceh> *sigh*
[22:05] <bryceh> anyway, I would like to propose we switch it on now and kick the tires on it and make a decision prior to alpha-2
[22:05] <RAOF> So we could turn it on, and if we need it for hybrid and we *want* hybrid (which I think we do), then we should do so now and ensure we hit as many problems as early as possible.
[22:06] <mlankhorst> oh btw for nouveau ddx i want to ask darktama first, after that it could probably be copied from experimental
[22:06] <bryceh> if nothing else we can do the bug-forwarding-to-intel dance for a bit
[22:06] <tjaalton> not until quantal has 3.5-rc1 though? :)
[22:06] <bryceh> and by we I mean me :-/
[22:06] <tjaalton> or any 3.5-rc
[22:06] <mlankhorst> rc1? optimistic
[22:06] <tjaalton> no i mean turning sna on
[22:07] <bryceh> tjaalton, why?
[22:07] <mlankhorst> oh sure
[22:07] <tjaalton> bryceh: it's closer to upstream than 3.4
[22:07] <bryceh> tjaalton, ah you mean for bug forwarding?
[22:07] <mlankhorst> by the way no guarantee hybrid will be complete this cycle, if not definitely for next though :)
[22:07] <tjaalton> bryceh: yeah
[22:08] <mlankhorst> Fortunately the synch changes are kernel only
[22:08] <tjaalton> mlankhorst: right, but we might get some of the features
[22:08] <bryceh> tjaalton, *shrug* they always want us to have the user test against -drm-intel-next-experimental-not-yet-maybe anyway
[22:08] <bryceh> so don't think waiting for 3.5-rc to hit is going to matter much
[22:09] <tjaalton> well, turn it on only after _some_ initial testing on quantal? :)
[22:09] <bryceh> tjaalton, so maybe switch it on in edgers for a week and see if anyone cries uncle first?
[22:10] <tjaalton> sounds good. Sarvatt?
[22:10] <mlankhorst> lgmt
[22:10] <mlankhorst> lgtm*
[22:10] <tjaalton> lgtm?
[22:10] <tjaalton> ah
[22:10] <mlankhorst> looks good to me
[22:11] <tjaalton> <- n00b
[22:11] <RAOF> I'll give it a bash on my systems, too.
[22:11] <bryceh> same
[22:12] <bryceh> RAOF, you want the task of turning it on or shall I?
[22:12] <tjaalton> i'm still running precise, because of all the bugs
[22:12] <tjaalton> in precise :)
[22:12] <RAOF> bryceh: I'll turn it on.
[22:12] <bryceh> ok sounds good
[22:13] <bryceh> next topic... speaking of bugs in precise...  8.0.3?
[22:13] <tjaalton> yeah, Sarvatt pushed the merge to git
[22:13] <bryceh> last time we talked about it, thinking was we could maybe get the whole thing through SRU?  do we want to try that?
[22:14] <tjaalton> sure, but it needs to get in quantal first, after alpha1
[22:14] <bryceh> was thinking if we did piglit runs on precise with and without it, and showed no regressions, it would help
[22:14] <RAOF> That would indeed help.
[22:15] <bryceh> I've got systems set up for doing piglit runs on the various drivers, so can take that part of the task
[22:15] <tjaalton> then maybe a meta-bug with the commit diff explained in detail, in order to dispel fears that it might look too scary
[22:15] <tjaalton> (damn wifi resetting all the time)
[22:15] <mlankhorst> i thought the release team hated meta bugs?
[22:15] <tjaalton> sure they do
[22:16] <bryceh> they do hate unexplained diff bits more though :-)
[22:16] <tjaalton> but since there are no other bugs to use..
[22:16] <RAOF> There are *no* existing launchpad bugs fixed by 8.0.3?
[22:16] <mlankhorst> speaking of which can we SRU synaptics soon?
[22:16] <bryceh> although based on past experience I tend to have low grokkage of mesa changelogs.  would someone else be able to write that part up?
[22:16] <tjaalton> RAOF: probably yes, but don't think there are _verified_ bugs
[22:17] <bryceh> tjaalton, is what sarvatt put in git good to go?  Could I slap it in a ppa and expect it to build?
[22:17] <RAOF> I would probably be able to do the metabug part, but I'm not sure if I'm the best person to do that.
[22:17] <bryceh> if so, I could spam likely looking bugs to test it.
[22:18] <RAOF> That sounds like a winner.
[22:18] <tjaalton> bryceh: it builds
[22:18] <mlankhorst> It didn't crash when I logged in to desktop
[22:18] <mlankhorst> (I didn't say anything about misrenders)
[22:18] <tjaalton> RAOF: heh, being on the sru team
[22:18] <bryceh> RAOF, in the sense that you'd be the reviewer?
[22:18] <RAOF> mlankhorst: That's not *quite* the level of testing we're hoping for on SRUs :)
[22:19] <mlankhorst> RAOF: if you do it right you can do that with synaptics currently
[22:19] <mlankhorst> :D
[22:19] <bryceh> RAOF, in which case maybe it'd be better to have you write the meta bug and another SRU reviewer do the review?
[22:19] <RAOF> bryceh: That would work.
[22:19] <bryceh> RAOF, effectively giving the whole a double SRU review :-)
[22:19] <RAOF> For added freshness!
[22:19] <bryceh> okie doke, sounds like a plan
[22:20] <bryceh> last topic, a few patches I noticed that need some actions
[22:20] <bryceh> https://bugs.launchpad.net/~ubuntu-x-swat/+patches
[22:20] <bryceh> #993427 - fglrx breakage with the kernel
[22:21] <mlankhorst> oh do we care about vdpau? It's just going to excarbate the flash problem..
[22:21] <bryceh> basically needs tseliot to look at that one.  I would do it myself but I'm not sure how we're doing git packaging stuff for fglrx now.  anyone clue me in?
[22:22] <tjaalton> no idea
[22:22] <tjaalton> it's on github maybe
[22:22] <bryceh> mlankhorst, bug #1002224 suggests we do care
[22:22] <RAOF> nvidia & fglrx was on github last time I touched it.
[22:22] <mlankhorst> bryceh: I mean, I understand vdpau and xvmc, and it's not that big of a win without hardware acceleration
[22:22] <bryceh> mlankhorst, I +1'd it, and it looks good to me for sponsoring it, but wanted to run it by everyone else for sanity checking?
[22:22] <tjaalton> should we drop patch 610206 as silly?
[22:22] <tjaalton> i mean close bug 610206
[22:23] <bryceh> tjaalton, yeah go for it
[22:24] <bryceh> RAOF, is tseliot cool with just having stuff pushed there, or does he actually want to review everything first?
[22:24] <RAOF> I think we should, yes.
[22:24] <mlankhorst> bryceh: I mean, it's not going to benefit anything yet. :/
[22:24] <RAOF> bryceh: I proposed a merge when I touched it, that seemed to work well.
[22:24] <bryceh> mlankhorst, ah.  is there risks for having it turned on?
[22:25] <RAOF> mlankhorst: Doesn't r300/r600 have shader-based acceleration for at least some of vdpau?
[22:25] <bryceh> RAOF, ok thanks, I'll give that a try
[22:25] <mlankhorst> RAOF: for mpeg2.. in which case your cpu is fast enough to do everything
[22:25] <RAOF> Heh. Of course!
[22:25] <mlankhorst> and the bitstream processing is still done on software
[22:26] <RAOF> I don't object to vdpau being turned on, though. If it breaks something it's simple to turn off.
[22:27] <mlankhorst> i guess it could be turned on on the simple fact nvidia is even buggier because it's using overlays
[22:27] <RAOF> Although obviously it should be wrapped by VAAPI 
[22:27] <RAOF> ?
[22:27] <mlankhorst> RAOF: va-api is insane :P
[22:27] <bryceh> maybe this would be another one to switch on post alpha-1 and evaluate pre alpha-2?
[22:28] <RAOF> Yup.
[22:28] <bryceh> alrighty
[22:28] <RAOF> Also should see if Debian's interested.
[22:29] <bryceh> RAOF, do you mean aside from the discussion on the linked bug?
[22:30] <bryceh> ok, last patch question, bug #996250 - it's a security issue but marked low priority.  Should we be taking action on that, or will the security team handle it?
[22:30] <bryceh> kees, ^^
[22:30] <mlankhorst> oh hey could anyone look at that other security bug btw
[22:30] <tjaalton> oh, speaking of mesa. I'd like it to only build the 32bit libosmesa. would speed up the build quite a bit, and besides debian and us no other distro is building 8 & 16bit libs as well..
[22:31] <tjaalton> maybe this was discussed already at some point
[22:31] <RAOF> Ah, missed that.
[22:32] <RAOF> In other mesa cleaning - is there any reason at all to build libgl1-mesa-swx11?
[22:32] <tjaalton> no
[22:32] <mlankhorst> to prevent apt-get install .*quantal with renamed stack from building
[22:32] <mlankhorst> :-)
[22:32] <mlankhorst> working*
[22:33] <bryceh> mlankhorst, haha
[22:33] <RAOF> Ok. I'm happy to drop < 32bit osmesa, and swx11; tjaalton, have you discussed with debian-x at all?
[22:34] <bryceh> so yeah, maybe another thing to drop post alpha1 and evaluate before alpha2?
[22:34] <tjaalton> RAOF: yes, a bit. I'll propose these two but they could be post-wheezy material anyway
[22:35] <RAOF> To experimental!
[22:35] <tjaalton> yeah
[22:35] <RAOF> Yeah, what with the incoming freeze and all.
[22:35] <RAOF> We can drop them sooner; post-A1 seems fine.
[22:35] <tjaalton> right
[22:35] <tjaalton> i have a branch that reworks the osmesa builds
[22:36] <mlankhorst> will the swx11 be a transitional package that depends on proper gl please?
[22:36] <tjaalton> from last fall, did some build benchmarking
[22:36] <tjaalton> mlankhorst: why would that be needed? proper gl gets installed anyway
[22:37] <RAOF> Does dropping the package entirely make -lts-quantal harder?
[22:37] <tjaalton> s/gets/is/
[22:37] <mlankhorst> maybe
[22:38] <mlankhorst> i never tried with swx11 so i cant say with 100% certainty, but wouldn't surprise me.
[22:38] <bryceh> shall we give it a go anyway, and make that part of the pre-alpha2 eval?
[22:38] <mlankhorst> sure
[22:38] <bryceh> guessing it'll become pretty evident if it makes -lts-quantal harder
[22:38] <tjaalton> libgl1-mesa-swx11 has one non-mesa rdepends
[22:38] <mlankhorst> i could always add the rules to the proper gl in that case
[22:39] <bryceh> alright.  I'll draft up the tasks from all the above into the blueprint for us.
[22:39] <mlankhorst> pyglet..
[22:39] <tjaalton> and python-pyglet has 'libgl | libgl1-mesa-swx11'
[22:39] <bryceh> ok, any other topics?
[22:39] <tjaalton> *libgl1
[22:39] <tjaalton> uh, so python-pyglet needs fixing
[22:39] <tjaalton> hum no
[22:40] <mlankhorst> tjaalton: not necessarily for backport quantal at least
[22:40] <RAOF> Everything that we care about Provides: libgl1, though.
[22:40] <mlankhorst> since it's not using versioned provides
[22:40] <tjaalton> libgl1-mesa-glx provides libgl1
[22:41] <mlankhorst> tjaalton: right so for backports ill just let it provide libgl1-mesa-swx11 and replaces too
[22:41] <tjaalton> bryceh: well, I've been going through the intel hang bugs, since I moved on to using the ivybridge machine a few weeks ago, and current precise is not working too well with it
[22:41] <tjaalton> mlankhorst: replaces is needed only if it replaces files
[22:42] <tjaalton> and there are no other reverse deps so meh :)
[22:42] <mlankhorst> like libGL1
[22:42] <bryceh> tjaalton, ok
[22:42] <mlankhorst> that's the whole reason we need them
[22:43] <tjaalton> anyway.. the merge window for the next precise kernel update closes late next week
[22:43] <tjaalton> so there are still some days to find and verify backportable fixes to drm
[22:43] <bryceh> tjaalton, what are your thoughts on the ivy bridge freezes?
[22:43] <tjaalton> but I'm only looking at i915
[22:44] <tjaalton> bryceh: works with 3.4, buggy with 3.3.6, haven't tried 3.3.7 which someone said would fix the rest. but mesa 8.0.3 might help as well
[22:44] <mlankhorst> is there anything else on the agenda?
[22:45] <tjaalton> impossible to tell since it's a hard freeze and I get no data out of it
[22:45] <mlankhorst> else I'd really like to get some sleep now :)
[22:46] <bryceh> mlankhorst, no other items after gpu freezes, unless anyone else has anything?
[22:46] <bryceh> tjaalton, can you ssh in while its frozen?
[22:47] <bryceh> tjaalton, https://wiki.ubuntu.com/X/Debugging/WirelessWithoutX, or ethernet
[22:47] <tjaalton> bryceh: no, it's completely dead
[22:47] <RAOF> I think I was seeing that hard-freeze, too.
[22:47] <bryceh> tjaalton, so maybe more than just drm falling over?
[22:47] <bryceh> netconsole?
[22:48] <tjaalton> it had other freezes where you could chvt and restart X, which really didn't work out that well. but those are now fixed by the -proposed kernel and mesa update
[22:48] <tjaalton> I'll test some combinations first before going too deep :)
[22:48] <bryceh> sounds good
[22:49] <tjaalton> I could reproduce some of the bugs on my snb laptop too
[22:49] <tjaalton> so should be able to verify the proposed fixes too
[22:50] <bryceh> sounds good.  I stopped looking at gpu lockups after the release, although I know there were still some that never got figured out.
[22:50] <bryceh> I've had a few freezes on my own intel boxes since the release, but nothing I could reproduce
[22:51] <bryceh> ok, let's wrap the meeting up.  mlankhorst go get some sleep :-)
[22:51] <tjaalton> there's one verified fix, one that I can repro, and one that still needs the reporter to check
[22:52] <tjaalton> hmm i should probably get afk as well
[22:56] <mlankhorst> night :)
[22:56] <tjaalton> zzz ->
[22:57] <RAOF> To the showers!
[23:16] <bryceh> new WI's → https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-xorg-general
[23:47] <RAOF> Ok. SNA is not *totally* crackful.
[23:48] <RAOF> Just a little bit.
[23:49] <RAOF> Oh, ARSE. Did I really run ?git clean? without having committed those files to git?
[23:51] <RAOF> Dej? D?p to the rescue!