[01:22] <bryce> mesa 7.10.3 mmm
[02:11]  * hyperair pokes Sarvatt for a new sna xxvi. =D
[02:51] <Sarvatt> oops forgot to hit retry on it, it failed because natty dri2proto hadn't built yet
[03:03] <Sarvatt> hyperair: sorry, forgot to hit retry after dri2proto updated in edgers, it'll build eventually
[03:03] <hyperair> oh yay =p
[03:04] <hyperair> by the way, i haven't seen any artifacts using sna
[03:04] <hyperair> Sarvatt: and my X uptime is 6 days.
[03:04] <Sarvatt> oh amd64 already built
[03:05] <Sarvatt> it works with chrome/chromium? i haven't tried it in a few days
[03:05] <Sarvatt> well since it was merged really
[03:05] <hyperair> that i haven't tried.
[03:05] <hyperair> let's see..
[03:05] <hyperair> yeah it does
[03:05] <hyperair> any specific website to load?
[03:05] <hyperair> google loads fine
[03:05] <hyperair> the speed dial thing loads fine too
[03:05] <Sarvatt> everything was broken here
[03:05] <hyperair> everything loads fine here.
[03:06] <Sarvatt> guess it'll turn into a "hunt down bugs on specific chipsets" problem then
[03:06] <hyperair> heh
[03:06] <hyperair> i'm glad i'm not hit this time. =p
[03:06] <Sarvatt> http://sarvatt.com/downloads/sna1.png
[03:06] <hyperair> oh yeha i saw that one
[03:06] <Sarvatt> still looked like that last i tried on sandybridge
[03:06] <RAOF> I think it's quite nice that the sna code appears highly generation-specific.
[03:09] <Sarvatt> trying it out now, lessee
[03:19] <Sarvatt> nothing refreshed at all anymore without alt-tabbing under gnome-shell and unity
[03:19]  * Sarvatt pins udev back to 167 before he makes the mistake of upgrading it again
[03:21] <Sarvatt> yeah looks like the checkout in intel-sna was right before the fix for that landed, will fix it up in the morning
[03:29] <Sarvatt> actually i'll just patch it in so its at least working, seems to be broken every morning when I update things and fixed in the afternoon.. can only upload one source package a day to launchpad which is a PITA
[03:30] <ScottK> Why is that?
[03:32] <RAOF> Upstream git SHAs aren't strictly monotone increasing, so can't be usefully used to disambiguate between different tarballs generated on the same day.
[03:32] <RAOF> Ie: it's a limitation of the xorg-edgers utility tools.
[03:33] <Sarvatt> according to launchpad 2.15.0+git20110613.aaaaaaaa-0ubuntu0sarvatt is > 2.15.0+git20110613.ffffffff-0ubuntu0sarvatt
[03:33] <Sarvatt> it started mid karmic cycle
[03:33] <Sarvatt> err 0000000 for the first
[03:36] <ScottK> So just use a per upload of the day serial number in the revision and put the commit hash in debian/changelog.
[03:37] <ScottK> Using the hash in the revision doesn't actually help.
[03:43] <RAOF> Yeah, it just requries tooling.
[03:43] <Sarvatt> not sure I agree, for mesa that'd be like 30-40 commits a day it could be trying to narrow down where the problem is and the changelog isn't saved
[03:47] <Sarvatt> anyway the once a day limitation isnt that big a deal, just need to add new commits at patches if its urgent
[03:49] <ScottK> The changelog isn't saved in the package you upload?
[03:49] <RAOF> You'd include the short SHAsum of the source in the package version.
[03:50] <RAOF> 7.11+git20110614.1+deadbeef-0ubuntu0~sarvatt1 :)
[03:51] <ScottK> That'd do it.
[08:26] <jussi> Morning all. Got a machine here at work that has an "unclickable area". Its a laptop, with ati, and an external screen attached. It makes it fun. :=) 
[08:26] <jussi> He is just reporting a bug now. 
[08:29] <RAOF> What sort of ‘unclickable area’?  In the past this has been a compiz stacking bug, where input-only windows get accidentally stacked on top of everything.
[08:29] <RAOF> Because, hey!  There's nothing so frustrating about X that it can't be made *more* frustrating by clients doing braindead things!
[08:31] <jussi> RAOF: basically there is a area which doesnt let him click there. If he has a webpage, he can scroll past the area and click the link, but it wont work if the link is in the area.
[08:31] <jussi> bug 797062
[08:31] <ubot4> Launchpad bug 797062 in xserver-xorg-input-mouse (Ubuntu) "Can't click with the mouse in a certain area on the screen (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/797062
[08:31] <RAOF> Sounds quite like the compiz stacking issue.
[08:32] <jussi> right, so how do we give you more informaton to make sure its that, and make your life easier? 
[08:32] <RAOF> If he runs ‘xprop’ and clicks in the unclickable area, does he get a bunch of information about a window?
[08:35] <jussi> it just gives 1 line.
[08:35] <RAOF> Pastebin?
[08:36] <jussi> he has put it on the bug
[08:38] <RAOF> Oooh, could you do the same with xwininfo?
[08:38] <RAOF> Sorry.
[08:40] <jussi> RAOF: on the bug
[08:41] <RAOF> Override redirect?  That's a pretty antisocial InputOnly window!
[08:42] <jussi> hehe
[08:43] <RAOF> So, he can look up what process has stuck that window there with “xwininfo -all”, which will include a line like “Process id: 2723 on host Ed”.  Looking up that pid will uncover the process that's being annoying.
[08:44] <RAOF> I think at this point it's a bug in that program.  It doesn't appear to be a bug in Compiz - the window manager should never touch OverrideRedirect windows - and it doesn't appear to be an X bug.
[08:44] <jussi> RAOF: on the bug.
[08:45] <jussi> RAOF: in which program?  the deadspot is there on any program
[08:45] <jussi> hehe, he added some artwork for illustration purposes... :D
[08:45] <RAOF> jussi: Right.  What's happening is that there's an invisible window there.  Which gets all the mouse clicks, and doesn't forward them on.
[08:47] <jcristau> xkill ftw.
[08:48] <RAOF> jcristau: Is it possible to grab the PID of the process from a window which doesn't set NET_WM_PID?  I've forgotten :)
[08:49] <jcristau> probably not easily
[08:49] <RAOF> I guess it'd be easier with that XRes 1.2 protocol patch set.
[08:50] <jussi> Ok, he is going to try go back to work now, but if you need something more than whats on the bug, please ask :)
[08:50] <jcristau> yup, probably
[08:50] <jcristau> but xkill just requires you to click on the window, not the pid.
[08:50] <jussi> jcristau: as noted on the bug, that didnt help
[08:50] <jcristau> ah.
[08:50] <tjaalton> OOM killer ftw
[08:51] <jussi> tjaalton: ? 
[08:51] <tjaalton> my wifes session was somehow messed up, desktopcouch-service was respawning like crazy, and ate all the memory.. of course it killed _my_ session
[08:52] <jussi> dont you just love his artwork? :D
[08:52] <RAOF> You might have better luck passing -frame to xkill, but it might also kill the window manager :)
[08:53] <jussi> https://launchpadlibrarian.net/73495608/Screenshot-1.png - its funny though, that you can drag through the area and it works, but clicking on the area doesnt.
[08:53] <RAOF> Right.  Because drags take a pointer grab, IIRC.
[08:54] <tjaalton> hmm wait, it didn't kill my session after all, it was just the "change user" dialog showing up after 20min of swapping
[08:54] <tjaalton> desktopcouch still taking 100% cpu
[09:31] <tseliot> RAOF, tjaalton: is multiarch mesa already in Oneiric?
[09:31] <tjaalton> tseliot: not yet aiui
[09:31] <RAOF> tseliot: No, not yet.
[09:31] <tjaalton> btw, should we start uploading this stuff in?
[09:31] <tjaalton> xserver, xorg etc
[09:32] <tseliot> tjaalton, RAOF: ok, as I was wondering where I could get it for testing (mainly to test proprietary drivers) and also to know when to upload fglrx and nvidia
[09:32] <RAOF> Mesa's basically just blocking on https://bugs.launchpad.net/ubuntu/+source/llvm-2.9/+bug/790204 at this point.
[09:32] <ubot4> Launchpad bug 790204 in llvm-2.9 (Ubuntu) "[MIR] libllvm-2.9 (affects: 1) (heat: 8)" [Undecided,New]
[09:32] <tjaalton> ah
[09:32] <tjaalton> forgot about that
[09:33] <tjaalton> and it also blocks xserver?
[09:33] <tjaalton> well, mesa that is
[09:33] <tjaalton> uh, mesa blocks xserver
[09:33] <tseliot> oh
[09:33] <RAOF> Well, xserver will need a rebuild after multiarch'd mesa, yes.
[09:33] <RAOF> tseliot: I'll throw the multiarch'd mesa in my aubergine PPA if you like.
[09:34] <tseliot> RAOF: yes, please, I was about to ask that
[09:35] <RAOF> Man, things look quite a lot better with proper font settings and the Ubuntu font now that gnome-tweak-tool works.
[09:36] <tjaalton> but when do we get a proper theme :)
[09:37] <RAOF> Yeah.  Does anyone else think that Awdibitititia results in ridiculously huge chrome? :)
[09:37] <tjaalton> awdiwhat?
[09:38] <RAOF> Whatever the default theme is.
[09:38] <tjaalton> ah
[09:39] <tjaalton> i don't even know where to change the theme
[09:39] <RAOF> gnome-tweak-tool.
[09:39] <RAOF> (Although it's got an undeclared dependency on gnome-shell)
[09:40] <tjaalton> ok, i have the shell already installed, at least it looks nice :)
[09:41] <tseliot> RAOF: so now that you're working on the new gnome-display app, are you going to change libgnome-desktop too?
[09:41] <RAOF> Yes.  It needs a bit of work to extend the GnomeRRConfig stuff.
[09:42] <RAOF> Anything you particularly want done? :)
[09:43] <tseliot> RAOF: yes, I've found a bug where g-s-d tries to assign the same crtc to more than one output when not in clone mode
[09:43] <RAOF> That sounds unlikely to work.
[09:43] <RAOF> ☺
[09:43] <tseliot> I think it's missing a check
[09:43] <tseliot> yes, as a matter of fact, it doesn't
[09:44] <tseliot> currently we don't have a way to check that when assigning crtcs
[09:44] <tseliot> so we should check if 1) we're doing clone mode 2) if so, make sure crtc is not already taken
[09:45] <tjaalton> grr, the text-scaling slider is utterly useless
[09:45] <RAOF> tjaalton: *Yes*
[09:46] <RAOF> Because it's *too hard* to have a frikking *DPI* number, oh no!
[09:46] <tjaalton> and it changes the scaling in realtime, and the lag is just awful
[09:46] <RAOF> Even better, if you hold it down then when the widget reflows it changes the setting for you again :)
[09:47] <RAOF> tseliot: That sounds reasonable.  Do you have a bug in mind?
[09:47] <tseliot> RAOF: so I guess this would be part of 2) http://pastebin.ubuntu.com/626429/
[09:47] <tseliot> sure, I have a public bug but it's better explained in a private bug report
[09:49] <tjaalton> RAOF: exactly..
[09:49] <tseliot> RAOF: here's the public report: bug #791752
[09:49] <ubot4> Launchpad bug 791752 in linux (Ubuntu) "Can not toggle Display to External only mode (affects: 2) (heat: 20)" [High,Confirmed] https://launchpad.net/bugs/791752
[09:49] <RAOF> Gah.  Damnit firefox, get your filthy tendrils out of my ram!
[09:49] <tseliot> :)
[09:50] <RAOF> I don't like it enough to give it 1.7 GiB of memory :)
[09:51] <tseliot> hehe
[09:51] <bryce> no n in dammit.  gotta luv englisch
[09:51] <RAOF> There is when I spell it, damnit :P
[09:51] <RAOF> And between that and evolution sucking an approximately equal slice of ram there's quite a lot of ram pressure on my poor little 4GiB system.
[09:54]  * jcristau hugs mutt
[09:54] <bryce> RAOF, we can call it tasmanian english
[09:55] <RAOF> bryce: Well, there's a subtle difference in pronunciation, too :)
[09:55] <tjaalton> thunderbird aint that bad either, only 100+ megs RES here
[09:55] <RAOF> But all my filters are in evolution :(
[09:56] <tjaalton> bryce: so xdiagnose 0.3 already has the failsafe/apport-stuff on it, so xorg git can enter oneiric?
[09:56] <RAOF> Oh, whoops.  Probably a good idea to get the buildsystem to actually *build* libgallium if I'm going to link against it.
[09:56] <tjaalton> ..and there goes desktopcouch berserk, again
[09:56] <tjaalton> on an idle session
[09:57] <RAOF> What's still pulling desktopcouch in for you, anyway?  I thought U1 stuff had transitioned away from it.  Because it keeps going beserk :)
[09:58] <tjaalton> this is natty
[09:58] <tjaalton> dunno why it's started
[09:59] <bryce> tjaalton, yep, I have a few things to fix up to get it working properly repackaged with dh_python2 but expect to have that done tomorrow
[09:59] <bryce> tjaalton, I don't think there's any reason to hold off xorg.
[09:59] <tjaalton> bryce: ok, I'll upload it today
[09:59] <tjaalton> also a couple of merges ready
[10:01] <tjaalton> hmm, uscan doesn't seem to work on libx11
[10:02] <tjaalton> no, it claims the package is up to date, but I can't find the tarball :)
[10:03] <RAOF> uscan --download-current-version ?
[10:04] <tjaalton> yeah, seems to work better with that
[10:06] <tjaalton> so it checks the git version too..
[16:54] <sithlord48> what package do i install for hw texture compression on my intel card?
[16:56] <jcristau> i guess you want http://dri.freedesktop.org/wiki/S3TC
[16:58] <sithlord48> thats prolly it thx