[02:07] <bryceh> on the valve invites...  the invites went out to survey respondents first; uds invites are coming in a second wave.  pass it on.
[02:23] <Azelphur> I managed to get in :)
[02:23] <Prf_Jakob> bryceh: k, thanks for the update.
[02:23] <Azelphur> is there a recommended way to grab that new nvidia driver?
[02:23] <Azelphur> probably x updates?
[02:24] <bryceh> Azelphur, no, it should be in your Additional Hardware Drivers right now
[02:24]  * Azelphur has a look
[02:24] <Sarvatt> if it's not thats a bug and would be good to know, i saw some updates saying never recommend -experimental that could go wrong
[02:24] <Azelphur> bryceh: experimental-304?
[02:25] <Sarvatt> should be a -310
[02:25] <Azelphur> there's a 310 too
[02:25] <Azelphur> so I go with the 310? righto :)
[02:25] <Sarvatt> yah thats the good one, bryceh got 2x the fps in l4d2 with that over 304
[02:25] <Azelphur> sweet
[02:27] <Sarvatt> Azelphur: interested if serioussam 3 works for you with a real beta key :P
[02:27] <bryceh> Sarvatt, it does; I was just playing it :-)
[02:27] <Sarvatt> damn!
[02:27]  * Azelphur is happy to test anything for anyone :p
[02:28] <bryceh> rocket launcher all the thingees!
[02:28] <Azelphur> whee \o/
[02:28] <Sarvatt> it doesn't work without a key even though lots of other things do
[02:29] <bryceh> the graphics performance was pretty crappy, and I spotted some (I think) corruption here and there.  Don't know if those are worth reporting.
[02:29] <bryceh> and that's with:
[02:29] <bryceh> xorg:nvidia_experimental_310 - NVIDIA accelerated graphics driver (**experimental** beta) (Proprietary, Enabled, In use)
[02:30] <Sarvatt> http://paste.ubuntu.com/1338840/ and fails to launch because no linux binaries :( I bought that game in advance to try it
[02:30] <Sarvatt> all the humble bundle games work fine but no surprise there
[02:33] <ScottK> Anyone preparing a mesa SRU soon?  https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1065125/comments/10
[02:34] <Sarvatt> i'm just glad to have steam not taking 2-3 minutes to load to chat on it or redeem cd keys :) its surprisingly buggy though, GUI crashes but its still running all the time
[02:34] <Sarvatt> ScottK: saw the responses with the fix right at EOD.. safe to say not yet :P
[02:34] <bryceh> Sarvatt, yeah quite buggy, but a lot better than it has been
[02:34] <Sarvatt> does kwin use gles by default now?
[02:34] <Sarvatt> aka is it that urgent?
[02:34] <ScottK> Sarvatt: OK.  As long as it's on the list.
[02:34] <ScottK> It does on arm*
[02:35] <Sarvatt> where blobs are used instead of mesa?
[02:35] <ScottK> Other than that, no, but people are using gles version as a workaround for some of the problems in Bug #1061073 
[02:35] <ScottK> Yes.
[02:36] <ScottK> The bigger potential impact is with people working around 106073 (only part of which is solve in kwin (the slow part)).
[02:36] <Sarvatt> ScottK: is it urgent enough that it can't wait for mesa 9.0.1 in ~a few weeks? Just curious because SRUing it is no big deal but 9.0.1 is planned for SRU
[02:37] <ScottK> Probably not that urgent.
[02:37] <ScottK> I know RAOF saw the corruption at UDS, but I don't know about progress on in beyond that.
[02:37] <Sarvatt> ah, yeah slowness was fixed in kwin, corruption still hasn't been figured out but the not updating isn't something i've seen a bug on
[02:40] <ScottK> We just uploaded KDE SC 4.9.3 to raring today and it'll come soon as an SRU.
[02:40] <Sarvatt> StFS: ^^ awesome
[02:41] <Sarvatt> i wasn't sure how kde updates happend, if it would be SRUed or in -backports and he asked
[02:42] <ScottK> We have a micro-release exception for KDE.
[02:42] <Sarvatt> kwin point releases are kinda nuts when I looked at 4.9.0 to 4.9.2 changes so wasn't sure
[02:44] <ScottK> There's a pretty good record on not regressing.
[02:46] <ScottK> StFS: KDE 4.9.3 for quantal is available (except for translation updates that are still waiting to build) for testing in https://launchpad.net/~kubuntu-ppa/.
[02:47] <ScottK> Please file bugs against the https://launchpad.net/kubuntu-ppa project if you find regressions.
[02:53] <Sarvatt> ScottK: is there a default team to assign kde bugs to for that bug?
[02:53] <ScottK> There are people that pay attention to the bugs filed against that project.
[02:53] <Sarvatt> i added the kdebase-workspace task, part of it is fixed in 4.9.3 that'll eventually come
[02:54] <ScottK> Oh, in bugs.kde.org it's very hit or miss.
[02:54] <Sarvatt> just wondering how to make sure that part is auto closed when it does update
[02:56] <Azelphur> seems like voice chat doesn't work
[02:58] <ScottK> Reasonably likely not an #ubuntu-x related topic.
[02:59] <Sarvatt> Azelphur: i'm amazed the overlay works and it doesn't take 3 minutes to start like it does in wine at least :P
[02:59] <ScottK> Sarvatt: For 1061073, I think you wanted quantal-updates, not precise-updates.
[02:59] <Azelphur> Sarvatt: indeed
[02:59] <Sarvatt> but holy crap its buggy, gui crashes and it's still running in the background, kill off all the processes, still running
[03:00] <Azelphur> another thing I notice, I have a different keyboard layout, but all my keybindings in game are qwerty
[03:00] <Sarvatt> ScottK: oops, thanks
[03:00] <ScottK> No problem.
[03:05] <Azelphur> is there a way to file bugs?
[03:07] <Sarvatt> nope :(
[03:09] <Azelphur> ah
[03:09] <Azelphur> also what's the deal with real full screen in Linux and dual screen, in order for an app to go full screen do you actually have to turn one monitor off so to speak?
[03:11] <Azelphur> also, 170FPS at 2560x1440 on all max graphics settings, niiiiiiiice
[03:14] <Azelphur> I have so many questions haha, does this work with nouveau yet?
[03:17] <Sarvatt> wish I knew :) pretty safe to say theres problems though. best bet for bug reports is the forums
[03:18] <Azelphur> yea guess so
[03:19] <Azelphur> It seems to ignore xinerama info that's for sure
[03:34] <Azelphur> Anyone with dual screen about to help me test something with the steam beta? You don't actually need to be in the beta to test it
[04:12] <Azelphur> bryceh: I'm having an odd issue occasionally while playing TF2 where my entire system just locks up for 1-5 seconds every now and again
[06:36] <Azelphur> does anyone know how you might solve this issue with dual screen + steam big picture? https://dl.dropbox.com/u/3832397/screenshots/2012/November/2012-11-07-063029_5120x1440_scrot.png
[07:19] <bryceh> Azelphur, yeah dunno on any of that; worked for me.  I would check dmesg for errors, ditto Xorg.0.log.  Make sure you're running latest video drivers, etc.
[07:34] <Azelphur> righto
[07:39] <bryceh> Azelphur, btw whenever reporting issues always summarize your video card, video driver version, ubuntu version, and any other versions that might be pertinent.  Often we just play guessing game when we don't know that stuff.
[07:39] <Azelphur> I see
[07:39] <Azelphur> that dual screen thing, I've seen that issue with other apps too, such as flash player
[07:39] <Azelphur> nvidia gtx 570 proprietary 310 xubuntu 12.04 64bit
[07:40] <Azelphur> quad screen (2 separate X screens running twinview)
[07:40] <bryceh> hmm, I haven't tested twinview too much myself
[07:41] <Azelphur> hehe
[07:41] <bryceh> now that nvidia supports xrandr, I'd probably just disable twinview entirely and set up using randr.  If the issue still exists there, switch on display debugging (xdiagnose, first checkbox), then examine dmesg for how it's laying out the screens.
[07:42] <bryceh> er, s/screens/displays/
[08:17] <mlankhorst> morning
[08:38]  * bryceh waves
[08:46] <mlankhorst> Azelphur: nouveau is unoptimized, I'm aware that are some things that could be done more efficiently there, so likely not getting as much fps
[08:46] <mlankhorst> plus on fermi and kepler you're stuck on boot speeds, which is not very high
[08:46] <Azelphur> interesting, I wonder if it'd actually work / be fast enough to be playable
[08:49] <mlankhorst> well boot speeds limits you to 1/10th of the normal power, or maybe even 1/20th, didn't check..
[08:52] <mlankhorst> however on geforce gtx < 400 it ought to work right
[08:52] <mlankhorst> minus rendering bugs and general inefficiencies :-)
[13:17] <tjaalton> fresh install, log in & out and there are four unity daemons left running plus pulseaudio and gvfsd-trash.. nice
[13:20] <mlankhorst> oh i just spent a few hours finding out why this thing failed without a sign of life, network-manager got reinstalled and probably took down the network interface..
[14:19] <mlankhorst> bryceh: do we want to be able to install mesa9 without the rest of the backports stack for steam?
[15:02] <mlankhorst> oh bug on this system after all, stupid nfs state corruption
[17:54] <bryceh> mlankhorst, yeah I think so
[17:55] <mlankhorst> bryceh: ok in that case should I just make it require on libdrm-lts-quantal and rename mesa-lts-quantal to mesa9?
[17:57] <bryceh> mlankhorst, how would users install it?
[17:58] <mlankhorst> we could make an exception for it, and just install libgl1-mesa9-dri/glx{,:i386}
[17:58] <mlankhorst> though the package itself would still be called mesa-lts-quantal because of how the rename script works
[17:59] <mlankhorst> s/package/source &/
[18:02] <bryceh> mlankhorst, let's just leave things as they are and see how things go.  I'm not clear that this would really be that much simpler for users than just the mesa9 ppa, and am worried it might make the backport stack a touch more complex.
[18:03] <bryceh> mlankhorst, it's a good idea though, but I suspect users that need it should really just opt-in whole hog to the full stack.
[18:03] <mlankhorst> hm might be better
[18:04] <mlankhorst> I really want to see if I can get libdrm in unrenamed, should I apply to the technical board?
[18:09] <bryceh> mlankhorst, no not for a one off backport, that's just an "ordinary" SRU.  You would have to convince RAOF or another SRU admin.
[18:15] <mlankhorst> well suppose I'll have to try harder at convincing raof then, didn't want to do that in the session since the kernel team also hijacked it :)
[20:17] <darkxst> I have a small patch that fixes pointer barriers under gnome-shell, would anyone here be able to review it?
[20:17] <darkxst> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1073724?
[20:19] <bjsnider> gnome-shell apparently has a number of issues with multiple monitors
[20:19] <bjsnider> i use it but with only one monitor so i guess i'm not seeing them
[20:20] <darkxst> bjsnider, this issue was introduced by the patch that does the sticky edges for unity
[20:21] <darkxst> my patch to that patch fixes the issue in gnome-shell and does not affect the velocity barriers for unity stick edges
[20:23] <bjsnider> do you have other issues with gnome-shell using two monitors?
[20:24] <darkxst> bjsnider, no not really, there are a couple of outstanding design issues (like workplace switchers), but overall it works well
[20:26] <bjsnider> darkxst, is was talking to the designer of gnome-mplayer about this
[20:26] <bjsnider> a few weeks ago i think
[20:27] <bjsnider> darkxst, https://groups.google.com/forum/?hl=en&fromgroups=#!topic/gnome-mplayer/1sjcFsQQyoM
[20:28] <bjsnider> that might be a link to hsi exact post, i'm not sure
[20:28] <bjsnider> he obviously expresses some distaste for certain design decisions
[20:29] <bjsnider> and i asked the gnome devs in their irc channel and they acknowledged problems in dual-head situations
[20:30] <bjsnider> a lot of people seem to be using 2 monitors i guess
[20:30] <darkxst> oh right, that is why I wrote this extension https://extensions.gnome.org/extension/323/multiple-monitor-panels/
[20:38] <darkxst> I believe there was a session re multiple monitors at the gnome boston summit, so they are working to improve things
[20:42] <bjsnider> well, they know about the issues so i'm sure there are plans in the works
[20:42] <RAOF> mlankhorst: It's still not clear to me why renaming the libdrm *source* to libdrm-quantal-backport, bumping the SONAMEs to include some informative string, and then having the two libdrm stacks parallel installable wouldn't work.
[21:16] <darkxst> anyway, who would be the best person to talk to about my pointer barrier patch?
[21:31] <mlankhorst> RAOF: soname is going to be annoying, would mean patching everything to make it parallel installable, not really a good idea :/
[21:32] <mlankhorst> though diversions might work for just generic libdrm stuff
[21:33] <bjsnider> how about alternatives
[21:35] <mlankhorst> would probably require changing original libdrm too, would rather have it wipe out original libdrm entirely 
[21:52] <RAOF> mlankhorst: It won't mean patching anything to make it parallel installable.
[21:53] <RAOF> mlankhorst: Oh, sorry - it does mean changing the -dev package name.
[21:53] <RAOF> mlankhorst: But the rest of libdrm is already parallel installable. And I don't think we need to make the dev package parallel installable?
[21:53] <mlankhorst> true
[22:08] <mlankhorst> RAOF: what part is parallel installable you mean?
[22:11] <RAOF> libdrm2, libdrm-{intel,radeon,nouveau}1
[22:16] <mlankhorst> erm renamed conflicts with those
[22:16] <RAOF> Why?
[22:17] <mlankhorst> I suppose I could give it a shot again with the apt bug fixed, things went seriously wrong before there..
[22:18] <RAOF> give me a moment to debaby
[22:19] <RAOF> Ok.
[22:20] <RAOF> So, here's what I would do - if you've already done it, and it didn't work, then say so :)
[22:21] <mlankhorst> think it might work better now, but still leaves you at a point without libdrm at all
[22:23] <RAOF> 1) Rename the quantal libdrm source package to libdrm-quantal-backports or whatever
[22:23] <RAOF> 2) Add a patch to libdrm-quantal-backports to change the SONAME for libdrm2 and libdrm-{intel,nouveau,radeon} to libdrm2ubpq, libdrm-intel1ubpq, etc
[22:23] <RAOF> 3) Rename the libdrm-dev in libdrm-quantal-backports to libdrm-quantal-backports-dev (or whatever)
[22:23] <RAOF> 4) Profit! libdrm2ubpq is now parallel installable with libdrm2, so you don't have to worry about apt removing libdrm2.
[22:24] <mlankhorst> hmz would have to look into step 2, would prefer automation as much as possible
[22:24] <mlankhorst> are long filenames ok?
[22:24] <RAOF> Things which Build-Depend against libdrm-quantal-backports-dev will Depend: against libdrm2ubpq, things which Build-Depend against libdrm-dev will Depend: against libdrm2
[22:25] <RAOF> mlankhorst: Yeah, long filenames are fine. AFAIK we don't run into any path length restrictions on the ISOs.
[22:26] <RAOF> mlankhorst: The patch in step 2 would be once-off; you'd only need to write it once (and make a trivial change for the raring-backports), and then it'd keep applying to the packages.
[22:28] <mlankhorst> guess I'll create a base patch + suffix
[23:06] <bryceh> so, the slow up with UDS attendees getting invites is that valve can't determine their steam id's from their launchpad record.  so they're working on an alternative way to get the keys out.
[23:06] <mlankhorst> ah was wondering, was expecting them to just mail a key
[23:08] <mlankhorst> my steam email isn't even the same as launchpad mail
[23:08] <tjaalton> I don't even have an account there
[23:09] <tjaalton> seems to be down too
[23:15] <tjaalton> and up again
[23:44] <darkxst> I have a small patch that fixes pointer barriers under gnome-shell, would anyone here be able to review it?
[23:44] <darkxst> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1073724