[06:53] mlankhorst: what was the motivation for 716e08fb054e in mesa? :) [06:55] nothing in changelog [06:59] merging from debian and it causes issues [07:00] tjaalton: files didn't exist any more [07:00] hmm ok I see [07:02] might come back if we give in to building libosmesa separately again [07:14] not sure if we should, beh i need to figure out what is wrong [07:15] hmm osmesa is built the same way on debian too [07:15] but it's the swx11 targets that put files there [07:16] anyway, fixing the osmesa build not to link to shared glapi should be configurable [07:16] or just disable it altogether, as it doesn't make much sense [07:16] meh I want to figure out why osmesa doesn't work right first [07:16] isn't that obvious? [07:18] libglapi exists, so it looks more like a linking fail in osmesa if it doesn't work [07:19] of osmesa, that is [07:23] simple linking works just fine on saucy, hm lets see with nvidia-319 [07:31] tjaalton: still works for me with nvidia-319 installed too on saucy [07:34] 32-bits and 64-bits [07:34] extern int OSMesaGetCurrentContext; [07:34] int main() { return OSMesaGetCurrentContext; } [07:35] ok then [07:57] works on quantal too, maybe their configuration was just broken [10:18] 9.1.4 uploaded [12:27] and again, powerpc ftbfs.. [12:28] link? [12:28] 9.1.1-0ubuntu2 [12:28] enabled llvm to work around it :P [12:29] heheehheheh [12:29] didn't bother to check at this point how it's built on debian [12:29] it's fallout from the shared mesa stuff, I think [12:30] ah, right [12:30] http://launchpadlibrarian.net/143988643/mesa_9.1.3-0ubuntu4_9.1.4-0ubuntu1.diff.gz if you care [12:31] only thing I care about is finishing sru first [12:32] oh looks like my xbmc fixed to vdpau got in [12:33] nouveau E[ PFIFO][0000:01:00.0] read fault at 0x0000f00000 [PAGE_NOT_PRESENT] from PCOPY1/PCOPY1 on channel 0x005fce0000 [DRM] [12:33] weee [12:34] I really need to figure out what is going on there === smartboyhw_ is now known as smartboyhw