[01:59] <bryce> hum, there's an ickle in our bug tracker
[04:49] <tjaalton> yeah
[05:02] <Sarvatt> bryce: you didn't notice him pinging us about things? maybe because he only pings tjaalton now :) but yeah it's much appreciated
[08:17] <bryce> yeah didn't see any pings much
[08:18] <bryce> works for me; I got sick of forwarding all those bugs to bugzilla
[09:35] <tjaalton> whoa, still four weeks until the feature freeze
[10:42] <mlankhorst> :o
[11:15] <mlankhorst> plenty of time to get unity through then
[11:17] <tjaalton> yup
[11:17] <tjaalton> and mesa :)
[11:17] <tjaalton> slash llvm
[11:17] <mlankhorst> yeah llvm is the blocker atm
[11:18] <tjaalton> doko doesn't seem to be around..
[11:18] <tjaalton> maybe I'll just create the snapshot and we can bikeshed it later
[11:20] <mlankhorst> sure
[11:21] <mlankhorst> could you do a patch to debian/rules for libLLVM-3.2.so too?
[11:21] <tjaalton> for the snapshot, not mesa?
[11:22] <mlankhorst> yeah seems like a packaging error
[11:28] <mlankhorst> looks like we will also need a newer dh-exec in precise to build it
[12:19] <mlankhorst> tjaalton: first stab at fixing things, pending build.. http://paste.ubuntu.com/1616315/
[12:20] <mlankhorst> probably messed up with email address
[12:23] <tjaalton> mlankhorst: thanks. so the r600 tree is based on 3.2, so it should be possible to create a (huge) diff that just pulls the backend..
[12:23] <mlankhorst> yeah needs to be ubuntu-devel-discuss@ubuntu.com
[12:24] <mlankhorst> but agreed, big diff ought to be reasonable for now, maybe package llvm-3.3 snapshot too before freeze, then choose which one we want to keep closer to 9.1 release?
[12:29] <tjaalton> i guess it's easier to go the diff route
[12:30] <mlankhorst> yeah but would be nice if we could reach to an agreement with doko about it
[12:31] <tjaalton> of course
[12:45] <tjaalton> upstream doesn't seem to use tags, or they don't work on the git mirror
[12:45] <mlankhorst> probably using svn
[12:45] <tjaalton> yep
[12:57] <mlankhorst> http://paste.ubuntu.com/1616523/ fixed version that worksforme (TM)
[13:05] <tjaalton> why did you touch the source-building target?
[13:06] <mlankhorst> because it was upset at my quiltrc file
[13:07] <tjaalton> what would be the changelog entry for the symlink?-)
[13:08] <tjaalton> I'll create an "official" debdiff for doko
[13:08] <tjaalton> adding the r600 backend was a breeze
[13:08] <mlankhorst> erm something like "remove extra libLLVM-3.2.so.1 installed by llvm-3.2-dev"
[13:09] <mlankhorst> and "add libLLVM-3.2.so symlink to /usr/lib/llvm-3.2/lib to satisfy programs expecting it to be there (mesa)"
[13:10] <tjaalton> ok, building
[13:11] <tjaalton> bah
[13:13] <tjaalton> forgot to enable the backend
[13:13] <mlankhorst> :-)
[13:13] <tjaalton> --enable-experimental-targets=R600
[13:15] <mlankhorst> but is the diff isolated to just adding the extra target, then?
[13:16] <tjaalton> yes
[13:19] <tjaalton> http://pastebin.com/Ld5stjBa :)
[13:20] <tjaalton> or rather http://pastebin.com/ygUcWEaF
[13:21] <tjaalton> diffing tstellars master to release_32
[13:24] <tjaalton> pinged sylvestre to hear what he thinks about adding the patch..
[13:25] <tjaalton> built fine btw
[13:30] <mlankhorst> hm to sru mesa 9.0.2 I would have to revert a whole bunch of wayland patches
[13:30] <mlankhorst> seems to be easier if I could just disable wayland altogether
[13:41] <mlankhorst> oh it built
[13:41] <mlankhorst> git diff a5776ac0b8c015bf5d6a8513cefec5920895cc8e^ src/egl/wayland/ src/egl/drivers/dri2/*wayland* src/gallium/state_trackers/egl/wayland/   src/egl/drivers/dri2/egl_dri2.h | patch -Rp1
[13:43] <tjaalton> should I upload llvm to x-staging?
[13:44] <mlankhorst> sure, for raring I guess?
[13:45] <tjaalton> yup
[13:55] <mlankhorst> shall I push my WIP for mesa 9.0.2 sru to ubuntu-quantal branch?
[13:55] <tjaalton> yup
[13:56] <mlankhorst> done
[13:58] <mlankhorst> just need to find some bug as justification, or maybe I should file one and find an excuse to play supreme commander for a few hours
[13:58] <mlankhorst> ;P
[13:59] <mlankhorst> bryce: since you were running piglit tests before, what is the setup you use to check for regressions between micro releases?
[14:36] <mlankhorst> argh stupid game won't crash! need another testcase now
[14:55] <tjaalton> wth again https://launchpadlibrarian.net/130535383/upload_4278734_log.txt
[15:32] <mlankhorst> 6 mar?
[15:33] <tjaalton> huh
[15:33] <mlankhorst> from that log
[15:33] <tjaalton> so it is my machine
[15:33] <tjaalton> shit
[15:34] <tjaalton> how did that happen..
[15:34] <mlankhorst> did you suspend a few times? I had it live a year in the future with that sometimes
[15:34] <tjaalton> hibernate
[15:35] <mlankhorst> guessing that's possibly why :-)
[15:36] <tjaalton> great, git histories messed up then
[16:02] <tjaalton> hum, so canonical-x staging ppa has the arm builders set up, so perhaps it's best to use that one instead..
[16:10] <mlankhorst> you can get arm builders on your own ppa if you awnt
[16:10] <tjaalton> well this is one hassle less
[16:15] <tjaalton> pushed llvm there, fixed timestamps first
[16:15] <tjaalton> should upload fine now..
[18:14] <tjaalton> cleaned canonical-x/staging from old packages
[18:24] <bryce> mlankhorst, piglit includes a script that lets you chart several runs together, that's really all I've been using to do comparisons.  I probably should get something a bit more structured set up... some day.
[18:46] <mlankhorst> :/
[18:51] <bryce> mlankhorst, what exactly are you looking for?
[18:51] <mlankhorst> some structured way to run tests for mesa 9.0 against mesa 9.0.2 for sru'ing to quantal
[18:54] <bryce> mlankhorst, this is basically what I use:  http://paste.ubuntu.com/1617512/
[18:55] <bryce> then like I said, I do the comparisons by running that other command manually
[18:59] <bryce> mlankhorst, the original script I was using is http://paste.ubuntu.com/1617523/, but just runs one test
[19:03] <bryce> Sarvatt, to set up an xorg-server 1.14 ppa, what all needs done?  Will we need the protos and so on too?  Can we just use the edgers scripts to do the snapshot?
[19:08] <tjaalton> bryce: we already have the ppa
[19:08] <tjaalton> canonical-x/staging
[19:08] <tjaalton> it has arm builders and all
[19:08] <tjaalton> pushed llvm for mesa there, not sure if that gets in the archive or not
[19:09] <tjaalton> and it only needs to carry the server & drivers
[19:09] <bryce> tjaalton, ah thanks
[19:09] <tjaalton> protos, libs (if any) we can push to raring
[19:09] <Sarvatt> inputproto and libxi should be all that needs updating besides xserver
[19:09] <tjaalton> yeah
[19:09] <bryce> tjaalton, ah I mean I'm looking for xserver in particular
[19:10] <tjaalton> mlankhorst has tested some rc already, not pushed anywhere yet
[19:11] <mlankhorst> build tested
[19:11] <tjaalton> ship it
[19:11] <tjaalton> no commits upstream since jan 23rd
[19:11] <tjaalton> keithp has been travelling
[19:12] <bryce> looks like we're mostly caught up on the proto packages that have been released, so I guess unless they depend on changes only in git, we should be ok?
[19:13] <bryce> we have inputproto 2.2.99.1 already, libxi could be updated
[19:13] <tjaalton> oh we had that
[19:13] <Sarvatt> yeah whoops, just uploaded inputproto to the ppa too :P
[19:14] <bryce> oh that's not supposed to be in raring?
[19:14] <tjaalton> just delete it :)
[19:14] <tjaalton> no harm having it in raring..
[19:14] <bryce> ok
[19:15] <Sarvatt> doing libxi now
[19:16] <bryce> has someone already snapshotted xserver?  We going to use what's in the ubuntu+1 branch currently, or update to a newer snapshot?
[19:18] <tjaalton> need newer
[19:18] <bryce> it's from Jan 9th, so fairly new
[19:18] <bryce> ah ok
[19:20] <tjaalton> bumps xi minor version etc
[19:22] <tjaalton> and major too..
[19:22] <tjaalton> err, input abi I mean
[19:23] <tjaalton> 35 commits since then
[19:30] <Sarvatt> xi's up there, doing xserver now
[19:30] <tjaalton> use git too..
[19:30] <tjaalton> :)
[19:32] <tjaalton> because we'd be able to then binary copy the packages straight to raring
[19:32] <Sarvatt> well hell, i thought we just wanted a testing ppa
[19:32] <tjaalton> so same standards apply :)
[19:33] <tjaalton> we can have both! :)
[19:33] <tjaalton> at the same time
[19:35] <tjaalton> maybe there was some miscommunication then, sorry :/
[19:48] <bryce> hum, I'm trying to understand how raof's pointer barrier velocity changes got taken upstream, but am having trouble seeing it.  It appears no one gave review comments on the patches upstream, and I don't see anything relating to velocity in the current xfixes/cursor.c.  What am I missing?
[19:48] <bryce> is it possible we are going to need to keep the patch and forward port it?
[19:49] <tjaalton> haven't looked
[19:51]  * bryce looks harder
[19:52] <bryce> ah? http://lists.x.org/archives/xorg-devel/2012-June/031647.html
[20:09] <bryce> ok, it's there.  s/velocity/dx,dy/ and so on :-)
[20:09] <tjaalton> maybe just ask jasper/peter :)
[20:09] <tjaalton> ah
[20:19] <bryce> yep, found everything I needed.
[22:02] <tjaalton> Sarvatt: I've cherry-picked your commits to u+1 to d-e ;)
[22:12] <tjaalton> libxi uploaded to raring
[23:01] <bryce> tjaalton, need help with anything?
[23:03] <mlankhorst> sleeping, I would imagine :-)