[03:27] wonderful, mesa failed to build on md64 [03:38] Odd? Why? [03:39] https://launchpad.net/ubuntu/+source/mesa/9.0~git20120903.e1673d20-0ubuntu1/+build/3768452 [03:40] thats bad, screwed updates for amd64 people [03:40] built just fine on my sbuilder, dammit [03:41] and my ppa it seems [03:44] new git checkout probably fixes it, only like 30 radeon/llvm commits since then [03:45] ok most of those are radeonsi we dont enable :) [03:45] sure we do [03:45] on mesa at least [03:46] oh i was thinking USE_R600_LLVM_COMPILER [03:46] so it should be relatively safe at the moment to install from the q-lts-backport ppa, I assume? [03:46] * ajmitch can pick up pieces if things go wrong [03:47] ajmitch: not sure, the guy updating that ppa has been on vacation for 2 weeks, it might not be ok [03:47] ah, he's still touring .au? [03:47] lots of changes in quantal since then [03:48] i've been on vacation too and havent kept up [03:48] * ajmitch mostly wanted the kernel, but new X on ivy bridge was tempting to try out [03:48] I'll wait for a bit before I update that part then [03:48] that is kept uptodate [03:49] by the kernel team, so go ahead and use the kernel [03:49] tjaalton: it still has mesa 8.0.4, way out of date [03:49] just fine for ivy [03:50] 3.6 kernel is the biggest boost for ivy at the moment [03:50] is that still likely to land for quantal? [03:50] who wants boost, stability is what I'm after :) [03:51] nope 3.5 [03:51] 3.4-> is what provides that [03:51] * ajmitch wants stability, this zareason laptop came with an odd 3.3.6 kernel from a PPA which is far from ideal [03:52] zareason shipped a ppa with a 3.3 kernel? [03:52] yeah 3.5 is way better off [03:53] 3.2 had problems that is taking quite a long time to backport fixes to [03:53] yeah I suspect that's why they used what they did, but it has some serious issues, I prefer to recommend they use something tested [03:56] oh i'm not on ubuntu-announce, that's why didn't notice beta was released [03:56] you're missing out :) [03:58] before these were sent to u-d-a [03:58] zareason is strange, they ship what works, theres lots of people paid to make 3.2 work for oems which we're doing for lenovo hp asus and dell but -proposed updates only come once every 3 weeks so it takes awhile, by now 3.2 in -proposed should be ok (aka 3.2.0-31) but 3.5.x aka quantal really is optimal for performance reasons [03:58] ah, didn't know we have mesa 9.0 in quantal.. [03:58] tjaalton: you uploaded it........ [03:58] a snapshot, yes [03:59] oh well :) [03:59] Sarvatt: it is a bit strange, they're a small team & have set up a NZ shop recently, so I met them last weekend [04:00] just sent one more patch to backport to 3.2.x, no reply yet though [04:02] ben is probably on holiday, no activity since aug 19th [04:02] on the stable tree at least [05:00] triggered a mesa rebuild on amd64, went fine this time .. [05:00] bf -> [05:01] --parallel issues? [05:15] most likely [05:16] cool [06:16] tjaalton: What was that -intel bug where compiz was hung with a black screen after resume, waiting for a swap that'll never complete? [06:17] tjaalton: Nevermind; backscroll wins! [06:17] :) [06:17] 966744 [06:18] so I've hit other bugs trying to reproduce that :/ [06:18] +while [06:23] tjaalton: Were you still reproducing that on Quantal? Jason Warner & Didier seem to be seeing it. [06:24] RAOF: yeah, but not that frequently [06:24] was it you or ickle who suggested to run compiz with xtrace [06:25] ickle, I think. [06:36] uploaded intel-gpu-tools 1.3, forgot to close the bug on the changelog [06:39] :) [06:39] "oops, no ffe" [07:14] RAOF: hey, could you accept gvfs for precise-proposed, fixes bug 819304 [07:15] Launchpad bug 819304 in gvfs (Ubuntu Precise) "gvfsd-cdda crashed with signal 5 in _g_dbus_oom()" [Low,In progress] https://launchpad.net/bugs/819304 [09:14] hi. are you planning mesa-9.0 backports in q-lts-backport ppa? [09:20] later [09:20] the whole stack will be copied [09:20] what gets in quantal [09:22] what means exactly later, one of the next betas or very later? [09:22] I can do packaging myself, thats not the problem. [09:23] it doesn't need packaging but running scripts [09:23] maybe next week once maarten is back from vacation [09:23] scripts sounds good [09:23] where are those "scripts"? [09:24] bzr somewhere, i was supposed to review them but.. :P [09:24] seem to be working fine [09:25] I was thinking of bumping to xserver-1.13 (final) and take sources for libdrm/intelgfx from quantal [09:25] hmm, v2.20.6 released of intelgfx ddx [09:26] can't wait until next week? [09:27] looks like I only need to rebuild quantal package [09:28] no. want to do some drm-intel-next testing. [09:30] then run quantal [09:30] maybe [09:30] just read today an article about q beta is released [09:32] anyway, got to go [09:32] thanks for the informations [09:33] yw [10:36] apw: did you have issues with the mesa in quantal? mind giving the newer snapshot a try if yes? [10:36] tjaalton, is it in -proposed? [10:36] tjaalton, or has it been in there a few days? [10:36] since after the beta, but hang on [10:38] the machine which was very unwell has -proposed enabled and now seems ok [10:38] it went straight to quantal [10:38] but there are people saying that a compiz/unity update fixed it, probably papering over the actual bug [10:38] since compiz is using gles now [10:38] tjaalton, yes then i think i see the same [10:39] as the issue went away around monday [10:39] hmm [10:40] ok, well good to know that it's better, now to figure out how to find out if the old bug is still there [10:40] downgrading compiz isn't easy, I'm told === yofel_ is now known as yofel