[00:47] <RAOF> Ok. I'm confused.
[00:47] <RAOF> racarr: Around?
[01:03] <racarr> RAOF: Yeah
[01:08] <RAOF> racarr: Do you have any goddamned idea why https://bugs.launchpad.net/mir/+bug/1204939 might be happening?
[01:08] <RAOF> Check out the patch in the description, plus the server & client output.
[01:16] <racarr> System hang
[01:17] <RAOF> Except you can ssh into the machine in this state, and attach gdb to whatever you want to, and prod it.
[01:17] <racarr> oh no I meant I had a system hang
[01:17] <RAOF> Hah.
[01:17] <RAOF> :)
[01:17] <RAOF> So you did not get my question?
[01:18] <racarr> I do not have an immediate guess..
[01:18] <racarr> I ust cancelled all my evening plans though because I am having weirdcramps (kind of overexerting lately)
[01:18] <racarr> so I can look at it some tonight lol
[01:18] <racarr> Um, if I had any god damned idea?
[01:18] <RAOF> Boo cramps!
[01:20] <racarr> sok. I think it's from building a massive metal dome hich was pretty satisfying
[01:20] <racarr> ok. I will think about it and be back after dinner ~40 minutes?
[01:20] <robotfuel> thomi: I have this new bug that prevents nexuiz from running on xmir for benchmarks https://bugs.launchpad.net/xmir/+bug/1212062
[01:21] <robotfuel> thomi: logs aren't that good at pin pointing the crash :/
[01:21] <RAOF> Heh. Pulseaudio appears to think that my HDMI audio sink is at 48KHz whereas it's really 44.1KHz. Dummy sounds really weird sped up by 10% :)
[01:22] <RAOF> robotfuel: Wait, apport didn't catch the actual segfault?
[01:22] <robotfuel> RAOF: no the logs are pretty much not useful
[01:25] <robotfuel> RAOF: the u-s-c log shows it's restarting, but that's it.
[01:27] <RAOF> Bah.
[01:28] <RAOF> Apport *should* catch that segfault and give us a lovely symbolic backtrace.
[01:31] <RAOF> Whee. Nexuiz is pretty big.
[01:36] <robotfuel> RAOF: I had it turned off, I've turned it back on and will upload the crash it collects
[01:37] <RAOF> a
[01:37] <RAOF> Ah, cool.
[01:38] <robotfuel> I didn't want stray windows about a web apps crashes messing with my benchmark numbers.
[01:39] <RAOF> Fair call.
[01:45] <robotfuel> RAOF: thomi the new bug via apport  https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1212065
[01:45] <robotfuel> I'll make the other one a dupe
[01:46] <RAOF> Ta muchly.
[01:46] <thomi> seems like it's still private
[01:46] <thomi> at least until the LP retracer thingie does it's work
[01:46] <RAOF> I should be able to see it even while it's private, but I can't.
[01:47] <robotfuel> I made it public
[01:47] <robotfuel> strange that it was private
[01:47] <thomi> bugs with stack traces that might contain private info are marked private by default
[01:48] <thomi> lp then redacts that information and makes the bug public again
[01:48] <robotfuel> I've moved the bug to xmir because it only happens when the u-s-c is installedhttps://bugs.launchpad.net/xmir/+bug/1212065
[01:49] <robotfuel> ugh No symbol table info available. maybe I need dbg packages?
[01:49] <RAOF> robotfuel: Nah, the apport retracer should go back in and fill in everything.
[01:50] <RAOF> *should* ☺
[01:52] <robotfuel> I have to run thanks for your help RAOF and thomi
[03:27] <thomi> RAOF: any luck with that bug?
[03:27] <RAOF> thomi: The nexuiz bug? The retracer hasn't touched it yet.
[03:28] <thomi> boooo
[03:28] <RAOF> Ah, there we go.
[03:28] <thomi> oh?
[03:29] <RAOF> The retracer has now touched it :)
[03:31] <RAOF> Huh, yes. That's not going to work.
[03:31] <RAOF> :)
[03:35] <racarr> RAOF: I may have gotten distracted when I found the dongle to plug my guitar in to my computer
[03:35] <RAOF> racarr: Woot!
[03:35] <racarr> I am back to thinking though um
[03:35] <racarr> so how does the failsafe X session
[03:35] <thomi> RAOF: why not?
[03:35] <racarr> come in to play?
[03:36] <RAOF> racarr: The failsafe X session doesn't come into play. Or, rather, it comes into play after the test times out and decides that it's all gone pear-shaped.
[03:36] <racarr> oh ok
[03:36] <RAOF> thomi: Because it calls sna_crtc_set_mode_major; we need to disable that codepath under nested :)
[03:36] <RAOF> racarr: I need to set up my keyboard somewhere that I can actually play it. Also, find all my music. ☺
[03:37] <thomi> RAOF: ok, so "That's not going to work" means "I know what the problem is, and how to fix it", not (as I thought) "the new stack trace does not help me fix the issue" :)
[03:37] <RAOF> thomi: Right.
[03:37] <thomi> RAOF: racarr: in Boston, we should get instruments and have a mir-team plus guests jam session :)
[03:38] <racarr> Oh...yes we should!
[03:38] <racarr> I'll bring my guitar
[03:38] <RAOF> thomi: I'd be pretty rubbish at a jam session, I suspect :)
[03:38] <thomi> no way I'm taking my guitar on an American airline flight though :)
[03:38] <thomi> RAOF: me too, that's half the fun :)
[03:38] <racarr> RAOF: Chords!
[03:38] <racarr> then you add notes, and add fewer if they sound really bad
[03:38] <racarr> it's easy
[03:38] <RAOF> :)
[03:39] <racarr> Ok so wait this lastlog
[03:39] <racarr> seems to imply that
[03:39] <RAOF> http://www.homestarrunner.com/sbemail36.html
[03:39] <racarr> drmAuthMagic
[03:39] <racarr> oh wait
[03:40] <racarr> ok so is that actually failing? andit's a permissions sorta thing with the session stuff
[03:40] <racarr> or could it still be
[03:40] <racarr> some sort of mir failing to send the reply
[03:40] <RAOF> Yeah, that's what I thought.
[03:41] <RAOF> Because you can see the second request successfully written to the socket, but nothing server-side about it.
[03:42] <thomi> RAOF: any idea when we can land the X fix? I need to give an estimate to olli
[03:42] <RAOF> thomi: For nexuiz?
[03:42] <RAOF> thomi: I'll fix it up now if it's urgent.
[03:42] <RAOF> Clearly it is urgent, so…
[03:43] <racarr> RAOF: ButI mean around
[03:43] <racarr> http://paste.ubuntu.com/5983202/
[03:43] <racarr> l155, do we know if ret < 0?Or is it still unclear
[03:43] <thomi> RAOF: yeah, I'd say it's pretty urgent, it's blocking xmir certainly
[03:43] <RAOF> thomi: Along with this ati banana, yeah.
[03:44] <thomi> :)
[03:44] <RAOF> racarr: We don't know if ret < 0, but we do know that we never get there the second time. Also, we know that the first call succeeds.
[03:44] <RAOF> (Because otherwise X would be all bailing)
[03:45] <racarr> ohhh
[03:45] <RAOF> Also, the exception would propagate out, kill unity-system-compositor, and get logged.
[03:45] <racarr> ok thanks I misinterpreted
[03:46] <racarr> Wait what do you mean we dont get there the second time,Doneauth appearstwice
[03:46] <racarr> Oh I see
[03:46] <racarr> its printed twice
[03:48] <RAOF> Right.
[03:48] <RAOF> I shouldn't have used the same string for both bits :)
[03:48] <RAOF> But you get two entry prints, and the "Done auth" is done for each entry print.
[03:49] <RAOF> Man, that's an unclear sentence :)
[03:49] <racarr> Mm
[03:50] <racarr> it would be useful to have
[03:50] <RAOF> But for a successful auth you'll see ‘In drm_auth_magic to auth magic:… In DRMHelper::auth_magic… Done auth… Done auth”
[03:50] <racarr> MIR_SERVER_SESSION_MEDIATOR_REPORT and MIR_SERVER_MSG_PROCESSOR_REPORT=log
[03:50] <racarr> I can't figure out, how far the second auth is getting beyond sent
[03:51] <RAOF> Ah, right. I've not instrumented the server end of the RPC channel.
[05:33] <RAOF> didrocks: Good morning!
[05:33] <didrocks> hey RAOF! thanks for the bug report update
[05:33] <RAOF> Thanks for running the tests.
[05:33] <didrocks> just a little bit scared about the "I have no idea why" :)
[05:33] <didrocks> yw! I got lucky, first time and strike! :)
[05:33] <RAOF> :)
[05:34] <didrocks> It's even annoying, I was preparing myself to a lot of try & retry pain :)
[05:34] <didrocks> RAOF: the machines are free for the next 25 minutes, not sure if this can help though
[05:36] <RAOF> Hm. We could try again with MIR_SERVER_SESSION_MEDIATOR_REPORT and MIR_SERVER_MSG_PROCESSOR_REPORT set to log.
[05:36] <RAOF> That's what racarr suggested.
[05:37] <didrocks> so, environment variable?
[05:37] <didrocks> shold we just set them to something like 1?
[05:37] <RAOF> Yeah. Or we could pass those options in.
[05:37] <RAOF> Nah, both should be set to "log"
[05:37] <didrocks> ah ok :)
[05:38] <didrocks> let's try that
[05:38] <RAOF> Want me to log in, or will you do the honours?
[05:38] <didrocks> RAOF: please log in
[05:38] <didrocks> I need to refind the run first
[05:39] <didrocks> now the question is… what archive was it :p
[05:40] <RAOF> :)
[05:41] <RAOF> You have the unity launcher always visible? :P
[05:41] <didrocks> RAOF: since the update, I can't reveal it anymore
[05:41] <didrocks> so forced to have it always visible :/
[05:41] <RAOF> Oh, which update?
[05:41] <didrocks> like a month ago
[05:41] <RAOF> Huh. Works here. Of course.
[05:41] <didrocks> when changing with the latest X the barrier logic
[05:42] <didrocks> RAOF: ah, better, it's fixed now \o/
[05:42] <didrocks> a little bit hard, but good enough :)
[05:42] <RAOF> Now we have a full 1920px worth of terminal!
[05:44] <didrocks> heh, indeed :)
[05:44] <didrocks> ok, let me find again the command I wrote to restore an archive :p
[05:44] <didrocks> interesting
[05:44] <didrocks> who wrote that buggy code? :p
[05:46] <RAOF> :)
[05:46] <didrocks> RAOF: looks good to you?
[05:47] <RAOF> Yup
[05:47] <didrocks> RAOF: let's poweroff to have new fresh logs
[05:47] <RAOF> Yeah.
[05:48] <RAOF> Also, I'm not sure if lightdm does the right thing wrt unity-system-compositor on restart.
[05:48] <didrocks> RAOF: do you think we should reboot the machine?
[05:48] <didrocks> can do quickly
[05:48] <RAOF> I don't think so.
[05:48] <didrocks> RAOF: just doing it, as the state was screwed the second time we start it
[05:48] <RAOF> Fair 'nuff.
[05:48] <didrocks> don't want to pollute the result :)
[05:50] <duflu> ping mlankhorst
[05:50] <didrocks> RAOF: please re-ssh and re-byobu :)
[05:51] <didrocks> RAOF: it's all yours now
[05:52] <RAOF> didrocks: Bah, that worked.
[05:52] <didrocks> argh indeed
[05:52] <didrocks> let's try to shut it down
[05:52] <RAOF> Although I don't see the logs I'd expect.
[05:52] <didrocks> and reboot again
[05:52] <didrocks> ah?
[05:52] <RAOF> So maybe the environment isn't set in the right place?
[05:52] <didrocks> hum
[05:52] <didrocks> didn't I write in that file? :/
[05:53] <RAOF> We could also edit /etc/lightdm/lightdm.conf.d/10-unity-system-compositor
[05:53] <didrocks> let's retry first
[05:53] <RAOF> Yeah
[05:54] <didrocks> RAOF: quick way to see it worked or not?
[05:54] <didrocks> RAOF: if not, you can poweroff/restart
[05:54] <RAOF> Didn't get the logs we wanted.
[05:54] <RAOF> Also, worked.
[05:55] <didrocks> ok, I let you edit :)
[05:55] <didrocks> (annoying those apps changing term cap)
[05:57] <RAOF> didrocks: Going to shut down and try again?
[05:57] <didrocks> RAOF: please do :)
[05:58] <RAOF> I've not paid attention as to how you actually start it ;)
[05:58] <RAOF> Although I guess the <up> key could work :)
[05:58] <didrocks> ah ok :)
[05:58] <didrocks> yeah
[05:58] <didrocks> RAOF: waow, how did you guess the default user password? :p
[05:58]  * didrocks runs…
[05:58] <RAOF> :)
[05:59] <didrocks> ok, restarted then
[06:01] <didrocks> RAOF: no luck?
[06:02] <RAOF> Wah, box keeps being restarted.
[06:02] <didrocks> oh right
[06:02] <didrocks> let me fix that
[06:02] <didrocks> sorry
[06:04] <didrocks> urgh
[06:04] <didrocks> that's weird
[06:04] <didrocks> it should have copied the "fixed versoin"
[06:04] <didrocks> let me recheck
[06:04] <didrocks> RAOF: in fact all the tests ran
[06:04] <didrocks> that's why it's shutting down
[06:05] <didrocks> grrr, this starts to be annoying, last time it was the way to go
[06:07] <didrocks> oh
[06:07] <didrocks> I'm sooooo stupid
[06:07] <didrocks> saucy-i386-20130813-0917
[06:07] <didrocks> saucy-i386-20130809-0917
[06:07] <didrocks> in the path
[06:08] <didrocks> I could have tried for a long time…
[06:08] <RAOF> :)
[06:08] <didrocks> ok, this time, my first attempt should be the right one
[06:08] <didrocks> that explains as well why the /etc/environment wasn't exposed
[06:08] <RAOF> Heh
[06:09] <didrocks> ok good :)
[06:09] <didrocks> shoudln't restart now
[06:09] <didrocks> the stage is yours
[06:10] <RAOF> Great. So, we've got the logs we're after.
[06:10] <didrocks> \o/
[06:10] <RAOF> Now we just need to actually trigger the bug.
[06:10] <didrocks> right
[06:11]  * RAOF is on Mir weekly call for a while
[06:11] <didrocks> ok ;)
[06:12] <RAOF> Feel free to keep restarting until you hit the bug :)
[06:13] <didrocks> RAOF: doing :p
[06:17] <didrocks> bah… 15 restarts without any issue, I wonder if the debugging log helped maybe to slow it down enough
[06:18] <RAOF> Yay heisenbug?
[06:20] <didrocks> exactly :/
[06:21] <didrocks> RAOF: yeah, I have no idea :/
[06:25] <didrocks> RAOF: I've archived it just in case
[06:26] <RAOF> TA.
[06:27] <didrocks> should I give back the machine to production?
[06:28] <didrocks> (I guess still ~5 minutes for it being free)
[06:29] <didrocks> yeah, the machine is needed, freeing it
[06:37] <RAOF> Sorry, yeah.
[07:10] <dholbach> good morning
[07:10] <Mirv> racarr / ricmm: re: http://bazaar.launchpad.net/~phablet-team/qtubuntu/trunk/revision/165 (mir backends) - there's double dh_auto_configure, the latter one under override_dh_install. that's probably harmless, but also unintentional?
[07:27] <racarr> Mirv: I think that was me, and it was unintentional
[07:40] <Mirv> racarr: ok, filed bug #1212131
[07:41] <Mirv> I'm just finishing testing with the new packages, just to be sure
[07:43] <Mirv> works fine on nexus 4
[07:43] <Mirv> (which was to be expected, but I just wanted to see it in action..)
[07:45] <mlankhorst> duflu: pong
[07:45] <duflu> mlankhorst: Sorry in hangout now
[07:51] <sil2100> duflu: hi! Once you're over with the hangout, I know you're busy but you might have some quick insights on https://bugs.launchpad.net/mir/+bug/1204939 with the new debugging data, as per Didiers comment:
[07:51] <sil2100> https://bugs.launchpad.net/mir/+bug/1204939/comments/11
[07:52] <sil2100> Since we had to block releases of the mir stacks because of that
[07:56] <racarr> Mirv: I'm glad you expected it ;)
[08:17] <duflu> sil2100: We were just discussing that in the hangout. People generally agree that we have not yet ruled out some socket needs better flushing, or similar. RAOF was working on it but just went to dinner I think
[08:18] <duflu> It's just a theory. We're at least getting closer to where the cause might be
[08:19] <duflu> mlankhorst: I'm getting: bo ffff880082c01000 pinned elsewhere: 0x00000002 vs 0x00000004
[08:19] <duflu> ... which sounds like my bo is pinned to "TT" when I'm trying to pin it to VRAM. But I don't understand what it really means by "TT"
[08:20] <mlankhorst> TT is translation table, eg gart :P
[08:20] <mlankhorst> are you on a 3.11 kernel?
[08:20] <duflu> mlankhorst: Oh. No this is 3.8 (raring)
[08:21] <duflu> mlankhorst: RAOF said it sounded like something you fixed recently... ?
[08:21] <duflu> Though I am definitely open to blaming my own code still
[08:22]  * duflu grabs a newer kernel
[08:24] <duflu> tvoss: I didn't actually mean it when I said I was going to sleep. That's many hours away :)
[08:25] <mlankhorst> a framebuffer will be in VRAM, exporting a handle as dma-buf will pin it to GART
[08:25] <duflu> tvoss_^
[08:25] <mlankhorst> on older kernels, 3.11 fixed this
[08:25] <duflu> mlankhorst: Cool thanks. I will give 3.11 a spin
[08:26] <sil2100> duflu: thanks guys :)
[08:28] <duflu> brb
[08:32] <duflu> alan_g: How confident are you that none of our sockets will ever need more flushing than we do already? It sounds like sil2100's issues could be caused by a socket buffering a request or response, but never accumulating enough to flush...
[08:33] <alan_g> duflu: it isn't something I've thought about.
[08:33] <duflu> Fair enough. So it's not impossible I guess
[08:41] <alf__> duflu: alan_g: It's unlikely that socket buffering would actually cause data not to be sent at all. In the worst case it would introduce a small delay while waiting for other data to come along.
[08:42] <duflu> alf__: Worth thinking about for performance at least I guess
[08:50] <duflu> ping greyback
[08:51] <greyback> duflu: pong
[08:51] <duflu> greyback: Can you confirm the fix for bug 1199450?
[08:52] <greyback> duflu: can do. Let me reboot
[08:52] <duflu> Ta
[08:53]  * duflu has managed to simulate the bug with demo_client_fingerpaint but never see it in the wild
[10:01] <duflu> greyback: Any good news before I depart?
[10:02] <greyback> duflu: so far, inputs are immediate, so I think bug is fixed. As it used to take several hours for bug to be noticeable, I'll work the day before marking bug as fixed
[10:02] <duflu> greyback: OK, thanks for testing that
[10:03] <greyback> duflu: thanks for fixing :)
[10:03] <duflu> greyback: No problem. It was consequential to other work I was already doing. BTW using Intel GPUs?
[10:04] <greyback> duflu: yep, sandybridge
[10:04] <duflu> Cool
[10:12] <duflu> mlankhorst: nouveau seems to be (successfully) doing multiple page flips per vblank...
[10:12] <duflu> Or am I imagining things?
[10:13] <mlankhorst> unfortunately not..
[10:14] <mlankhorst> I have 2 patches that help with the vblanking some
[10:15] <mlankhorst> sec
[10:15] <mlankhorst> http://cgit.freedesktop.org/~mlankhorst/linux/commit/?id=4d2b97bdaebd7686075bce5ad1a498918d2ab17f^
[10:15] <mlankhorst> http://cgit.freedesktop.org/~mlankhorst/linux/commit/?id=4d2b97bdaebd7686075bce5ad1a498918d2ab17f
[10:17] <duflu> mlankhorst, OK awesome to see you're already onto it
[10:17] <duflu> I may have to enter kernel land and test those tomorrow...
[10:17] <mlankhorst> duflu: well the fix is really from the second commit in nouveau_display.c -- you should try that separately :P
[10:18] <mlankhorst> but I'm still getting > 60 fps with compositing somehow, dno why
[10:30] <mlankhorst> ah now I understand
[10:41] <mlankhorst> nouveau ddx is messy :/
[13:04] <alan_g> Hmm with the new fangled mir_connection_create_display_config() interface, how do we determine the size of the display? Is MirDisplayMode::vertical_resolution the height?
[15:55] <olli_> didrocks, I checked with RAOF yday on the ATI bug
[15:56] <olli_> discussing whether the stop is warranted or not
[15:56] <didrocks> olli_: ah nice! we discussed a little bit/tried to debug together this morning
[15:57] <didrocks> (no success though)
[15:57] <olli_> he said we should block mostly to "help" you
[15:58] <olli_> i.e. it is probably not an ATI spec. problem but a sporadic IPC one but if we don't get it fixed you will just reboot your system over and over again
[15:58] <olli_> didrocks, just wanted to share that with you
[15:58] <olli_> to show some sympathy ;)
[15:59] <didrocks> olli_: yeah, or have to skip this tests on that machine and add an hack for this one…
[15:59] <didrocks> olli_: thanks ;) let's see how it goes on a longer term
[15:59] <tsdgeos> racarr: ping when you're online
[16:26] <tvoss_> didrocks, what is wrong with this line in debian/control?
[16:26] <tvoss_>  -- Thomas Voss (thomas.voss@canonical.com) Mon, 12 Aug 2013 15:51:35
[16:27] <didrocks> tvoss_: you shouldn't have this line in debian/control
[16:27] <didrocks> or you meant debian/changelog?
[16:27] <tvoss_> didrocks, changelog, sorry :)
[16:27] <tvoss_> ah, spotted it :)
[16:27] <didrocks> tvoss_: you need a double space and <   > between your email address
[16:27] <didrocks> so:
[16:28] <didrocks>  -- Thomas Voss <thomas.voss@canonical.com>  Mon, 12 Aug 2013 15:51:35
[16:28] <didrocks> not sure what you try to do to have () and only one space ;)
[16:29] <tvoss_> didrocks, still no luck
[16:29] <tvoss_>  -- Thomas Voss <thomas.voss@canonical.com>  Mon, 12 Aug 2013 15:51:35
[16:30] <didrocks> tvoss_: you don't have the timezone
[16:30] <didrocks>  -- Thomas Voss <thomas.voss@canonical.com>  Mon, 12 Aug 2013 15:51:35 +0200
[16:30] <didrocks> not sure why you try by hand instead of dch -i, really ;)
[18:22] <bschaefer> small branch, memory leak in multi win demo: https://code.launchpad.net/~brandontschaefer/mir/fix-memory-leak-mutli-win-example/+merge/180210
[18:23] <bschaefer> and small memory leak, just 3 surfaces ~4k bytes
[19:41] <racarr> These lateoclock meetings just do not ork ell for me
[19:41] <racarr> I got so woken up I couldnt get to sleep until 4
[19:55] <tsdgeos> racarr: there?
[19:56] <racarr> tsdgeos: Yes :) sorry
[19:56] <tsdgeos> racarr: did you get the nexus4 mir thing to work?
[19:56] <racarr> I went to our lateoclock meeting last night...and wasn't able to get to sleep afterwards
[19:56] <racarr> Yes! but then I realized I was testing unity8 with old packages still because path wasn't thought I was
[19:57] <racarr> and the PPA isn't installable at the moment
[19:57] <racarr> so now I am building qtubuntu, etc
[19:57] <racarr> just mir trunk, all the demos, etc
[19:57] <racarr> so I guess, I will hopefully see the problem soon at least
[19:58] <tsdgeos> racarr: well, my problem is, i can't even get anything on screen with mir_demo_client_accelerated
[19:58] <tsdgeos> racarr: is all the stuff you use from packages? or you use some code yet to be commited?
[19:58] <racarr> tsdgeos: Ah see, I just did a clean build
[19:58] <racarr> of mir trunk and the demo clients work fine
[19:59] <racarr> I think I didn't try demo_client_accelerated in particular, but did try demo_render_surfaces, demo_render_to_fb, demo_fingerpaint, and demo_inprocess_egl
[19:59] <tsdgeos> well i'm using the image
[19:59] <racarr> hmm
[20:00] <tsdgeos> any idea why i may not be getting anything?
[20:04] <racarr> tsdgeos: We are sure surface flinger is dead?
[20:04] <tsdgeos> racarr: well, it's not showing in ps, is that enough?
[20:06] <racarr> I think actually it might not show up in normal PS anyway because it's on the other side of the LXC container
[20:06] <racarr> but I'm not 100% sure
[20:06] <racarr> with no surface flinger
[20:06] <racarr> nexus 4 should get stuck on the
[20:06] <racarr> "Google" screen
[20:06] <racarr> probably
[20:06] <racarr> tsdgeos: There may be something useful if you run the server with
[20:06] <racarr> MIR_SERVER_DISPLAY_REPORT=log
[20:07] <tsdgeos> yes, it gets stuck on the google screen
[20:07] <racarr> did you try the standalone mir demos?
[20:07] <racarr> render_surfaces, render_to_fb and inprocess_egl?
[20:07] <tsdgeos> racarr: which binary is that?
[20:07] <tsdgeos> is that in any deb pkg?
[20:07] <tsdgeos> or do i have to compile mir?
[20:08] <racarr> tsdgeos: sorry I keep on thinking you have a build directory XD
[20:08] <racarr> um
[20:08] <racarr> I think they were in the demos packagge at least
[20:08] <racarr> mir_demo_standalone_*
[20:08] <tsdgeos> racarr: shall i run as root, as phablet or don't care?
[20:08] <racarr> inprocess_egl, render_surfaces, render_to_fb
[20:09] <racarr> um, you know I had success running them as phablet but I didn't think that was supposed to work
[20:09] <racarr> so lets go with root XD
[20:09] <racarr> and MIR_SERVER_DISPLAY_REPORT=log if they don't work
[20:09] <ricmm> racarr: you get the shell on your n4 ?
[20:10] <tsdgeos> racarr: so this is the server output http://paste.ubuntu.com/5986351/
[20:11] <tsdgeos> and this is the client
[20:11] <tsdgeos> http://paste.ubuntu.com/5986353/
[20:11] <tsdgeos> still nothing on screen
[20:13] <racarr> tsdgeos: When you run the standalone ones
[20:13] <racarr> run without a server
[20:13] <racarr> ricmm: I was running old packages XD
[20:13] <tsdgeos> racarr: the only standalone i can find is mir_demo_standalone_input_filter
[20:14] <racarr> Really ok I guess we don't build them anymore
[20:14] <tsdgeos> and well, that does output stuff to the shell
[20:14] <tsdgeos> but i don't see anything
[20:14] <tsdgeos> not sure if i should be seeing anything or not
[20:14] <ricmm> racarr: so now it doesnt work?
[20:14] <racarr> not with input_filter
[20:14] <tsdgeos> racarr: i guess i can try building stuff if that helps
[20:14] <racarr> ricmm: Well I am still building to verify, it seems not too though
[20:14] <racarr> tsdgeos: Yes, I think that ould be the next step if you can
[20:14] <racarr> just start with building mir
[20:14] <racarr> and we can run the integration-tests binary
[20:15] <racarr> which will verify a lot of
[20:15] <racarr> driver stuff
[20:15] <tsdgeos> but i'm confused as of why you see stuff when using the image and you don't
[20:15] <racarr> and narrow things down
[20:15] <racarr> tsdgeos: No I am using the normal image and built mir atm
[20:15] <tsdgeos> oh
[20:15] <racarr> I switched back to the normal image because I thought maybe I would dogfood it sometimes on days when I dont need google maps
[20:16] <racarr> but it turns out I use google maps pretty much every day lol
[20:16] <racarr> I guess probably I should try the image..
[20:16] <racarr> ill download the image while you build mir XD
[20:18] <racarr> tsdgeos: ricmm: Is this still the link http://s-jenkins:8080/job/ubuntu-touch-phablet-image-saucy-mir/lastSuccessfulBuild/artifact/saucy-preinstalled-phablet-armhf.zip
[20:18] <tsdgeos> racarr: im just using the regular image
[20:18] <tsdgeos> + the mir ppa
[20:18] <racarr> its not working
[20:18] <racarr> tsdgeos: oh ok
[20:19] <racarr> so we should be in roughly the same spot
[20:19] <racarr> so lets see what happens withhhh the integration-tests binary
[20:19] <tsdgeos> racarr: which cmake switch do i need to compile mir?
[20:20] <ricmm> racarr: yea thats the link
[20:20] <ricmm> havent checked today's image, but it should be fine
[20:20] <ricmm> lately if it builds it works
[20:20] <ricmm> so yea
[20:25] <racarr> tsdgeos: -DMIR_PLATFORM=android
[21:15] <tsdgeos> racarr: ok, build, what now?
[21:35] <racarr> tsdgeos: Try running the binaries in build/bin lets start with
[21:35] <racarr> unit-tests, integration-tests and acceptance-tests
[21:36] <tsdgeos> ./bin/mir_demo_standalone_render_sur
[21:36] <tsdgeos> nothing on screen
[21:36] <tsdgeos> running unit-tests now
[21:37] <tsdgeos> everything passes
[21:37] <tsdgeos> +
[21:37] <tsdgeos>   YOU HAVE 2 DISABLED TESTS
[21:37] <tsdgeos> everything passes
[21:43] <tsdgeos> racarr: what now?
[21:55] <bschaefer> racarr, hey, you were looking at a crash in: usr/lib/xorg/modules/extensions/libxmir.so (xmir_auth_drm_magic+0x3f) [0xb752560f]
[21:55]  * bschaefer seems to be getting a black screen on start up, and attempting to load unity7 causes opengl to crash when attempting to load
[21:55] <bschaefer> usr/lib/xorg/modules/extensions/libxmir.so (xmir_auth_drm_magic+0x3f) [0xb752560f]
[21:55] <bschaefer> opps
[21:55] <bschaefer> paste.ubuntu.com/5986691/
[22:00] <racarr> tsdgeos: Mer. I guess try
[22:01] <racarr> the standalone programs that I mentioned
[22:01] <racarr> well also try running mir_demo_server_shell and a client with mir built this way
[22:01] <racarr> bschaefer: I was, but I didn't get so far
[22:01] <racarr> the last theory as of liek 2 am last night as that maybe the second auth magic request
[22:01] <racarr> isnt being sent to the server in time because of socket buffering
[22:01] <bschaefer> racarr, o well nevermind then :), I think i've an incorrect package somewhere...as everyone else seems to have a working intel machine on main
[22:02] <bschaefer> racarr, as I thought it was an ATI problem
[22:02] <racarr> we think that may ust be
[22:02] <racarr> coincidence
[22:02] <racarr>  / most likeley to aggrivate the race
[22:02] <bschaefer> that could be as well, hmm yeah as right now I just get a black screen right after logging into lightdm, but Ill mess around some more
[22:02] <racarr> but
[22:02] <racarr> yeah see if it could be wrong packages
[22:03] <racarr> and if not, I think I can help figure out if it's
[22:03] <racarr> the same bug
[22:03] <racarr> which would be useful
[22:03] <bschaefer> and I can do a "startx" to get into an xsession, but when I attempt to start unity it hangs on loading the opengl driver
[22:03] <bschaefer> alright will do!
[22:05] <bschaefer> racarr, o also one more interesting thing, is as soon as I switch to a tty I get this message and my xsession dies (but no errors):
[22:05] <bschaefer>  (II) AIGLX: Suspending AIGLX clients for VT switch
[22:06] <tsdgeos> racarr: none of the standalone stuff does much, they just turn the screen "less black" and that's it :-/
[22:19] <racarr> tsdgeos: Hmm, and anything novel with MIR_SERVER_DISPLAY_REPORT=log on the standalone stuff?
[22:19] <racarr> They should be rendering things
[22:19] <racarr> tsdgeos: Can we double check that surface flinger is disabled like it documents at the bottom of the page here: https://wiki.ubuntu.com/Touch/Testing/Mir
[22:21] <tsdgeos> racarr: nothing :-/ http://paste.ubuntu.com/5986754/
[22:21]  * tsdgeos checks the surface flinger
[22:21] <tsdgeos> racarr: so basically
[22:21] <tsdgeos> cp /var/lib/lxc/android/rootfs/init.rc /var/lib/lxc/android/overrides/
[22:21] <tsdgeos> vi /var/lib/lxc/android/overrides/init.rc
[22:22] <tsdgeos> # Comment out any line that deals with surfaceflinger (near the bottom there is a chunk of them)
[22:22] <tsdgeos> ?
[22:26] <tsdgeos> yeah
[22:26] <tsdgeos> nothing
[22:31] <racarr> bler
[22:31] <racarr> ok maybe I should riemage my phone
[22:31] <racarr> tsdgeos: I am kind of at a loss to try and determine what oculd be different
[22:31] <tsdgeos> :(
[22:31] <tsdgeos> racarr: i'd appreciate if you tried a reimage, but i agree that's a lot of time
[22:31] <tsdgeos> anyway
[22:31] <tsdgeos> it's almost 1am here
[22:31] <tsdgeos> and tomorrow is a national holiday
[22:31] <tsdgeos> i'm going to log off
[22:32] <bschaefer> racarr, after purging libelg* and reinstalling xserver-xorg-video-intel and libmirserver1...things seem to be working again
[22:32] <tsdgeos> maybe on friday things will be automagically better
[22:32]  * tsdgeos hopes
[22:32]  * tsdgeos waves
[22:33] <bschaefer> libegl*
[22:43] <racarr> bschaefer: Yay
[22:43] <racarr> so probably
[22:43] <racarr> unrelated
[22:43] <bschaefer> yup, still strange though...if it comes back ill let someone know :)
[22:51] <racarr> thanks.
[23:03] <RAOF> racarr: :( Sorry for keeping you up.
[23:03] <RAOF> bschaefer: Your OpenGL app hangs? On hardware that isn't in the QA lab? SCORE!
[23:04] <bschaefer> RAOF, no anymore :(
[23:05] <bschaefer> RAOF, just purged libegl* and reinstalled what was needed and things seem to be working again
[23:05] <bschaefer> not anymore*
[23:05] <RAOF> Eh, it's a race.
[23:05] <RAOF> Of some kind.
[23:05] <RAOF> You'll be back!
[23:05] <bschaefer> RAOF, haha, well thats good news!
[23:06] <bschaefer> my logs were clean until I tried to force start unity, and when compiz was loading the opengl plugin everything hung and I got that stack trace, but it didn't say
[23:07] <bschaefer> the xserver went down with an error, or at all, the log just ends...
[23:29] <thomi> RAOF: any news on the Xorg fix?
[23:29] <RAOF> thomi: Which one?
[23:29] <RAOF> The nexuiz one?
[23:29] <thomi> the nexiuz one
[23:29] <thomi> yeah
[23:29] <thomi> I saw some activity on the bug
[23:29] <thomi> but I'mnot sure how far away we are from having a new package in distro
[23:30] <RAOF> Should be fixed in distro at the moment, I think, but I should also wrap up Chris' newer patch.
[23:30] <thomi> oh sweet, thanks