[00:31] <Sarvatt> this packaging is so hacky and just a workaround to not make them not download git and build it every time, needs a lot of review and cleanup (man pages also) if its ever going in debian https://code.launchpad.net/~xorg-edgers/piglit/debian-packaging
[00:47] <Prf_Jakob> Sarvatt: Which mesa version are you guys going to use?
[00:48] <Sarvatt> 8.1.x
[00:48] <Sarvatt> in 12.10, and 12.04.2
[00:48] <Prf_Jakob> ok
[00:48] <Prf_Jakob> ok
[00:54] <Sarvatt> theres a nasty bug in core mesa breaking unity on every gpu that may actually be a unity issue though, cant update till we figure that out which hopefully will happen before feature freeze so we can get 8.1
[00:55] <Sarvatt> oh feature freeze is 3 weeks away, i guess there will be paperwork involved to upload it anyway
[01:05] <Prf_Jakob> Ok
[01:05] <Prf_Jakob> I should clean up the wayland related patches then.
[05:59] <tjaalton> debfx: hey, do you know if virtualbox will support the video abi of 1.13 anytime soon? looks like 4.2 beta doesn't
[08:37] <mlankhorst> tjaalton: speaking of that, which one are still missing for 1.13?
[08:41] <tjaalton> mlankhorst: -ivtv, the arm ones and vboxdrv
[08:41] <mlankhorst> ah k
[08:42] <mlankhorst> speaking of which, I need a arm staging tree..
[08:43] <mlankhorst> tjaalton: can you upload rc4? :)
[08:44] <tjaalton> I already did?
[08:44] <tjaalton> didn't push git though..
[08:44] <tjaalton> done
[08:45] <tjaalton> how easy it is to miss that phase..
[08:45] <tjaalton> i blame multitasking
[08:46] <debfx> tjaalton: I asked the upstream developer on friday. he said he'll look into it but as I understand supporting RCs isn't a priority for them.
[08:47] <tjaalton> debfx: ok. we might be able to patch it to build in the meantime
[08:49] <tjaalton> sigh, do we really need -glamo
[08:51] <tjaalton> not going to touch it
[08:53] <tjaalton> bug 1034793
[08:53] <ubottu> Launchpad bug 1034793 in xserver-xorg-video-voodoo (Ubuntu) "Please remove obsolete video drivers from the archive" [Undecided,New] https://launchpad.net/bugs/1034793
[09:52] <mlankhorst> tjaalton: indeed :P
[10:12] <mlankhorst> tjaalton: yeah seeing how often that seems to happen I wonder if it should be part of the tagging phase
[10:20] <tjaalton> mlankhorst: what should?
[10:21] <tjaalton> oh generating the changelog?
[10:22] <mlankhorst> well just that you can't upload to ubuntu without uploading the git parts first :)
[10:23] <tjaalton> ah
[10:23] <mlankhorst> in the same way xorg-util-modular/release.sh is supposed to work
[10:26] <tjaalton> well, xorg-server didn't get the changelog mangling commit in it for .902, so the changelog that git had looks weird since the changes were done to .902-1
[10:27] <tjaalton> so, always create a new changelog entry for -0ubuntu1 or such, if debian is unreleased
[10:27] <tjaalton> need to use dch -n for that, i guess
[10:28] <tjaalton> and then edit to make it not be a nmu
[10:30] <tjaalton> but yeah, whatever tools there are to force git push would be fine :)
[10:31] <tjaalton> dunno if it's feasible though
[10:31] <tjaalton> since we don't do tags
[10:31] <tjaalton> and you can forget that too
[10:32] <tjaalton> so should it be pushed after building a source package? that wouldn't work either, if you're just testing stuff
[10:39] <tjaalton> mlankhorst: ah, so nothing was lost, just that instead of bdaab9165aac it's preferred to just create a new changelog entry for ubuntu
[10:39] <tjaalton> in similar cases
[10:39] <tjaalton> and I use dch -n for that, don't know of a better tool
[10:40] <tjaalton> but I've added the git trick to my config. looks like I had .gitattributes already but nothing to call it..
[12:07] <mlankhorst> :)
[15:16] <shadeslayer> is there a know bug about X taking up all your memory after about 3-4 hours ?
[15:18] <mlankhorst> with nouveau?
[15:22] <tjaalton> shadeslayer: it's likely some app, not x
[15:22] <shadeslayer> well ... it mentions lightdm and X in the same line
[15:22] <shadeslayer> ( the process )
[15:27] <tjaalton> 'it'?
[15:44] <shadeslayer> tjaalton: htop
[15:45] <shadeslayer> and yeah, it's definitely leaking memory, X is now using 25% of my RAM
[15:45] <tjaalton> check xrestop
[15:46] <shadeslayer> tjaalton: http://i.imgur.com/XF9pi.png
[15:46] <tjaalton> which driver?
[15:47] <shadeslayer> well .. I have 2 cards, and I think it's using the discrete ati card
[15:47] <tjaalton> fglrx?
[15:47] <shadeslayer> nope
[15:47] <shadeslayer> don't have fglrx
[15:47] <tjaalton> k
[15:47] <shadeslayer> lsmod says radeon
[15:48] <shadeslayer> hmm ... xrestop shows kwin at the top
[15:48] <tjaalton> using how much pixmem
[15:48] <shadeslayer> 1568614K
[15:48] <shadeslayer> so about 1.5G's :|
[15:49] <tjaalton> there you go
[15:49] <tjaalton> it might still be a leaking driver, dunno
[15:52] <shadeslayer> hmm
[16:12] <shadeslayer> tjaalton: so restarting kwin takes down kwin's mem consumption, but X still consumes the same amount of memory
[16:14] <tjaalton> could be the driver then
[16:14]  * shadeslayer ponders filing a bug
[16:14] <shadeslayer> tjaalton: anything that I can do to debug it a bit?
[16:14] <shadeslayer> oh ... I recently modified my xorg.conf a bit
[16:15] <shadeslayer> maybe that's what's causing it
[16:15] <tjaalton> which release is this?
[16:15] <shadeslayer> quantal
[16:15] <tjaalton> hmm
[16:15] <tjaalton> -proposed has a newer xserver, but I think it's either mesa or the kernel that's buggy, not the xserver
[16:18] <shadeslayer> hmm .. lets try and see if that fixes anything
[18:45] <tjaalton> nice, xserver crash when switching sessions
[18:45] <tjaalton> apport didn't catch it
[18:45] <tjaalton> duh
[19:03] <mlankhorst> tjaalton: raof dropped the rethrow signals patch but it requires starting xorg-server with core :)
[21:06] <tjaalton> mlankhorst: yeah, i'll hack it locally to catch the crash