brycehum, there's an ickle in our bug tracker01:59
Sarvattbryce: you didn't notice him pinging us about things? maybe because he only pings tjaalton now :) but yeah it's much appreciated05:02
bryceyeah didn't see any pings much08:17
bryceworks for me; I got sick of forwarding all those bugs to bugzilla08:18
tjaaltonwhoa, still four weeks until the feature freeze09:35
mlankhorstplenty of time to get unity through then11:15
tjaaltonand mesa :)11:17
tjaaltonslash llvm11:17
mlankhorstyeah llvm is the blocker atm11:17
tjaaltondoko doesn't seem to be around..11:18
tjaaltonmaybe I'll just create the snapshot and we can bikeshed it later11:18
mlankhorstcould you do a patch to debian/rules for libLLVM-3.2.so too?11:21
tjaaltonfor the snapshot, not mesa?11:21
mlankhorstyeah seems like a packaging error11:22
mlankhorstlooks like we will also need a newer dh-exec in precise to build it11:28
=== Quintasan_ is now known as Quintasan
mlankhorsttjaalton: first stab at fixing things, pending build.. http://paste.ubuntu.com/1616315/12:19
mlankhorstprobably messed up with email address12:20
tjaaltonmlankhorst: 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
mlankhorstyeah needs to be ubuntu-devel-discuss@ubuntu.com12:23
mlankhorstbut 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:24
tjaaltoni guess it's easier to go the diff route12:29
mlankhorstyeah but would be nice if we could reach to an agreement with doko about it12:30
tjaaltonof course12:31
tjaaltonupstream doesn't seem to use tags, or they don't work on the git mirror12:45
mlankhorstprobably using svn12:45
mlankhorsthttp://paste.ubuntu.com/1616523/ fixed version that worksforme (TM)12:57
tjaaltonwhy did you touch the source-building target?13:05
mlankhorstbecause it was upset at my quiltrc file13:06
tjaaltonwhat would be the changelog entry for the symlink?-)13:07
tjaaltonI'll create an "official" debdiff for doko13:08
tjaaltonadding the r600 backend was a breeze13:08
mlankhorsterm something like "remove extra libLLVM-3.2.so.1 installed by llvm-3.2-dev"13:08
mlankhorstand "add libLLVM-3.2.so symlink to /usr/lib/llvm-3.2/lib to satisfy programs expecting it to be there (mesa)"13:09
tjaaltonok, building13:10
tjaaltonforgot to enable the backend13:13
mlankhorstbut is the diff isolated to just adding the extra target, then?13:15
tjaaltonhttp://pastebin.com/Ld5stjBa :)13:19
tjaaltonor rather http://pastebin.com/ygUcWEaF13:20
tjaaltondiffing tstellars master to release_3213:21
tjaaltonpinged sylvestre to hear what he thinks about adding the patch..13:24
tjaaltonbuilt fine btw13:25
mlankhorsthm to sru mesa 9.0.2 I would have to revert a whole bunch of wayland patches13:30
mlankhorstseems to be easier if I could just disable wayland altogether13:30
mlankhorstoh it built13:41
mlankhorstgit diff a5776ac0b8c015bf5d6a8513cefec5920895cc8e^ src/egl/wayland/ src/egl/drivers/dri2/*wayland* src/gallium/state_trackers/egl/wayland/   src/egl/drivers/dri2/egl_dri2.h | patch -Rp113:41
tjaaltonshould I upload llvm to x-staging?13:43
mlankhorstsure, for raring I guess?13:44
mlankhorstshall I push my WIP for mesa 9.0.2 sru to ubuntu-quantal branch?13:55
mlankhorstjust need to find some bug as justification, or maybe I should file one and find an excuse to play supreme commander for a few hours13:58
mlankhorstbryce: since you were running piglit tests before, what is the setup you use to check for regressions between micro releases?13:59
mlankhorstargh stupid game won't crash! need another testcase now14:36
tjaaltonwth again https://launchpadlibrarian.net/130535383/upload_4278734_log.txt14:55
mlankhorst6 mar?15:32
mlankhorstfrom that log15:33
tjaaltonso it is my machine15:33
tjaaltonhow did that happen..15:34
mlankhorstdid you suspend a few times? I had it live a year in the future with that sometimes15:34
mlankhorstguessing that's possibly why :-)15:35
tjaaltongreat, git histories messed up then15:36
tjaaltonhum, so canonical-x staging ppa has the arm builders set up, so perhaps it's best to use that one instead..16:02
mlankhorstyou can get arm builders on your own ppa if you awnt16:10
tjaaltonwell this is one hassle less16:10
tjaaltonpushed llvm there, fixed timestamps first16:15
tjaaltonshould upload fine now..16:15
tjaaltoncleaned canonical-x/staging from old packages18:14
brycemlankhorst, 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:24
brycemlankhorst, what exactly are you looking for?18:51
mlankhorstsome structured way to run tests for mesa 9.0 against mesa 9.0.2 for sru'ing to quantal18:51
brycemlankhorst, this is basically what I use:  http://paste.ubuntu.com/1617512/18:54
brycethen like I said, I do the comparisons by running that other command manually18:55
brycemlankhorst, the original script I was using is http://paste.ubuntu.com/1617523/, but just runs one test18:59
bryceSarvatt, 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:03
tjaaltonbryce: we already have the ppa19:08
tjaaltonit has arm builders and all19:08
tjaaltonpushed llvm for mesa there, not sure if that gets in the archive or not19:08
tjaaltonand it only needs to carry the server & drivers19:09
brycetjaalton, ah thanks19:09
tjaaltonprotos, libs (if any) we can push to raring19:09
Sarvattinputproto and libxi should be all that needs updating besides xserver19:09
brycetjaalton, ah I mean I'm looking for xserver in particular19:09
tjaaltonmlankhorst has tested some rc already, not pushed anywhere yet19:10
mlankhorstbuild tested19:11
tjaaltonship it19:11
tjaaltonno commits upstream since jan 23rd19:11
tjaaltonkeithp has been travelling19:11
brycelooks 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:12
brycewe have inputproto already, libxi could be updated19:13
tjaaltonoh we had that19:13
Sarvattyeah whoops, just uploaded inputproto to the ppa too :P19:13
bryceoh that's not supposed to be in raring?19:14
tjaaltonjust delete it :)19:14
tjaaltonno harm having it in raring..19:14
Sarvattdoing libxi now19:15
brycehas someone already snapshotted xserver?  We going to use what's in the ubuntu+1 branch currently, or update to a newer snapshot?19:16
tjaaltonneed newer19:18
bryceit's from Jan 9th, so fairly new19:18
bryceah ok19:18
tjaaltonbumps xi minor version etc19:20
tjaaltonand major too..19:22
tjaaltonerr, input abi I mean19:22
tjaalton35 commits since then19:23
Sarvattxi's up there, doing xserver now19:30
tjaaltonuse git too..19:30
tjaaltonbecause we'd be able to then binary copy the packages straight to raring19:32
Sarvattwell hell, i thought we just wanted a testing ppa19:32
tjaaltonso same standards apply :)19:32
tjaaltonwe can have both! :)19:33
tjaaltonat the same time19:33
tjaaltonmaybe there was some miscommunication then, sorry :/19:35
brycehum, 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
bryceis it possible we are going to need to keep the patch and forward port it?19:48
tjaaltonhaven't looked19:49
* bryce looks harder19:51
bryceah? http://lists.x.org/archives/xorg-devel/2012-June/031647.html19:52
bryceok, it's there.  s/velocity/dx,dy/ and so on :-)20:09
tjaaltonmaybe just ask jasper/peter :)20:09
bryceyep, found everything I needed.20:19
tjaaltonSarvatt: I've cherry-picked your commits to u+1 to d-e ;)22:02
tjaaltonlibxi uploaded to raring22:12
brycetjaalton, need help with anything?23:01
mlankhorstsleeping, I would imagine :-)23:03

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!