[04:16] <RAOF> Oh, fun. mesa FTBFS with -j5.
[04:17] <tjaalton> yeah it can have those issues.. though haven't seen it fail in quite a while
[04:17] <tjaalton> RAOF: building the unreleased git version?
[04:18] <RAOF> tjaalton: Both that and the archive version fail in the same way.
[04:18] <tjaalton> ah
[04:18] <RAOF> Trying to generate radeonsi source files.
[04:19] <tjaalton> huh, built it several times yesterday and they were all fine (-j8 though)
[04:45] <RAOF> tjaalton: Hah. And now git fails to build in the final stage because glu.h exists in debian/tmp. What?!
[04:46] <RAOF> Oh, that reminds me. Who wants to review apitrace? It's ready in git, I think we should have it in Ubuntu, and we don't need to wait for Debian. jcristau's obviously too busy to review it there.
[04:49] <tjaalton> RAOF: that's.. weird, don't see it here
[04:49] <tjaalton> I can have a look at apitrace today
[04:52] <tjaalton> hmm, wonder why cloning it drops it in a nonexistant master branch
[04:53] <tjaalton> oh right
[04:53] <tjaalton> since there's no debian-unstable branch :)
[04:53] <tjaalton> which is where HEAD is pointing at
[04:58] <RAOF> Heh.
[05:20] <tjaalton> which one should be fixed, the remote HEAD or the branch name(s)?
[05:20] <tjaalton> s/fixed/changed/
[05:22] <RAOF> tjaalton: Are you talking about apitrace or mesa here?
[05:22] <tjaalton> apitrace?
[05:23] <tjaalton> uh
[05:23] <tjaalton> -?
[05:24] <tjaalton> the convention has been to add -unstable(/-experimental) there, that's why setup-repository made apitrace.git/HEAD look like that
[05:25] <RAOF> Ah, sorry.
[05:26] <tjaalton> no worries, easy to change either way :)
[05:26] <RAOF> Ah.
[05:26] <RAOF> Right. And I didn't notice because I don't clone that!
[05:26] <tjaalton> exactly
[05:26] <tjaalton> been there, done that..
[05:26] <RAOF> I guess it should follow pkg-xorg convention and be named debian-unstable.
[05:28] <tjaalton> ok, so I renamed refs/heads/{debian,upstream}
[05:29] <tjaalton> now when you fetch you have both the old and new branches under as origin/*
[05:29] <tjaalton> -under
[05:29] <RAOF> Cool
[05:29] <tjaalton> just reset the local branch to follow the correct one
[05:31] <tjaalton> dunno what is the best way to remove the old remote branches
[05:32] <tjaalton> ah, git branch -r -d origin/foo
[05:32] <RAOF> Already done that.
[05:32] <tjaalton> cool :)
[05:32] <tjaalton> so we're set
[06:18] <RAOF> tjaalton: Mesa build confusion resolved! I was gentarball-ing with a seriously out of date upstream-experimental.
[06:19] <tjaalton> hah :)
[06:19] <tjaalton> that would explain glu.h, yes
[06:22] <RAOF> Yeah, I was wondering about that, given the damn thing has been deleted from the mesa tree!
[07:13] <dupondje> next Xorg version will support Optimus?
[07:13] <dupondje> Any roadmap available? thats for 13.04 ?
[07:16] <ml|vacation> dupondje: kernel support is missing
[07:16] <dupondje> what do we need exactly for it in kernel?
[07:17] <ml|vacation> sure you can share buffers, but for it to be actually useful you need to synchronize them to
[07:18] <ml|vacation> too*
[07:18] <dupondje> Optimus seems to be a mess to handle :(
[07:18] <dupondje> things on the roadmap for it in kernel?
[07:19] <ml|vacation> so that is what I've been working on, kernel tree is somewhere but i wont restart until next monday :p
[07:19] <tjaalton> dupondje: hm, I thought I asked if it was a hybrid setup.. noticed the bug discussion now
[07:21] <dupondje> ml|vacation: its planned for 13.04 or will it still make in 12.10 ?
[07:22] <tjaalton> 13.04
[07:23] <dupondje> or xorg-edgers ^^
[07:24] <tjaalton> well the userspace bits are nearly there
[07:24] <tjaalton> so you can just use a mainline kernel in addition to 12.10
[07:25] <dupondje> can I follow the status somewhere? So I'm up-to-date ? :)
[07:25] <tjaalton> https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-hybrid-graphics probably
[07:25] <tjaalton> it's missing some detail though
[07:30] <dupondje> subscribed :)
[07:38] <tjaalton> RAOF: apitrace doesn't have a gentarball target, shouldn't it?
[07:38] <ml|vacation> dupondje: I'll try to get the upstream pieces inside quantal, but it's less useful without the kernel parts
[07:40] <dupondje> using a daily kernel isnt an issue :)
[07:42] <RAOF> tjaalton: It's got a pristine-tar branch
[07:44] <RAOF> tjaalton: I guess it could also have a gentarball target, though.
[07:48] <tjaalton> RAOF: oh right, it does
[07:49] <RAOF> git-buildpackage. It's pretty good :)
[07:50] <tjaalton> debian/gbp.conf needs an update :)
[07:51] <tjaalton> oh you fixed it
[07:53] <tjaalton> hmm, why is the lintian warning suppressed? for backports?
[07:55] <RAOF> Hm. Does that no longer apply?
[07:55] <RAOF> It's there because when I first packaged it that warning showed up; is debhelper 9 stable now?
[07:56] <tjaalton> yeah
[07:57] <tjaalton> so you can bump it to >= 9
[07:59] <dupondje> nouveau bug followup is sweet :)
[07:59] <dupondje> in less then 24h issue is closed :)
[07:59] <dupondje> the reason we love open source!
[08:00] <tjaalton> I should probably forward some..
[08:00] <tjaalton> RAOF: policy is at 3.9.3
[08:00] <dupondje> try it out :) Ben does a great job!
[08:01] <tjaalton> I should probably try quantal on my hybrid t420s soon..
[08:02] <tjaalton> precise finally getting stable on it :)
[08:02] <dupondje> then its getting boring ;)
[08:02] <tjaalton> dang, didn't forward the compiz gpu-hungness yet
[08:04] <tjaalton> RAOF: don't know how to run the beast, but it builds and looks clean, so I'm ok with uploading it to quantal
[08:05] <RAOF> tjaalton: Install the frontend package and you can run qapitrace (it'll be in the dash), which allows you to trace stuff, or you can run “apitrace trace $app” to generate a trace.
[08:05] <RAOF> But given that I've built it in a clean chroot here, and it works, you probably don't have to do much testing :)
[08:06] <tjaalton> RAOF: yeah, I'll give it a whirl at some point
[08:07] <tjaalton> oh right, quantal laptop still gpu-hung, hehe..
[08:07] <RAOF> With the multiarch fixes in there you should even be able to trace wine apps reasonably!
[08:08] <tjaalton> hope I never need to go down that path..
[08:09] <tjaalton> but actually, would this help with the gpu hang I have? or is it more for debugging performance issues?
[08:09] <tjaalton> ah, read the description now :)
[08:10] <RAOF> Yeah.
[08:11] <RAOF> If you have some app that triggers the hang you could trace that, then the trace can be replayed on a dev box.
[08:12] <RAOF> ...which should reproduce the hang, making it easy to test :)
[08:15] <tjaalton> oh cool
[08:15] <tjaalton> I'll try it out then
[08:45] <tjaalton> hmm, should have a way to reproduce it more quickly
[19:15] <dupondje> [ 9560.052783] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
[19:15] <dupondje> [ 9560.052788] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state
[19:16] <dupondje> outch
[19:25] <tjaalton> dupondje: so file a bug and attach it there
[19:25] <tjaalton> i915_error_state
[19:32] <dupondje> on what package?
[19:34] <tjaalton> ubuntu-bug xorg
[19:39] <dupondje> https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1046505
[19:39] <ubottu> Launchpad bug 1046505 in xorg (Ubuntu) "i915_hangcheck_hung" [Undecided,New]
[19:39] <dupondje> there :)
[19:50] <tjaalton> thanks
[19:59] <tjaalton> dupondje: can you reproduce it?
[20:44] <dupondje> tjaalton: nope, unable to reproduce it
[20:44] <dupondje> never had it before afaik