[00:26] <RAOF> mlankhorst: Hey, what's the expectation of buffer lifecycle vis-a-vis dma-buf? It's entirely up to us, isn't it?
[00:27] <racarr> rsalveti: ricmm: I have roughly zero ideas :(
[00:28] <racarr> afk for a little bit soon
[00:28] <racarr> why can qtubuntu
[00:28] <racarr> link succesfully against papi mirclient?
[00:29] <racarr> if the gstreamer codec cant
[01:16] <slangasek> rsalveti: possibly also worth noting that the cross-compiler in saucy hasn't been updated since July...
[01:35] <ricmm> well but even natively exhibited the issue
[01:35] <ricmm> sorry, building natively by hand didnt show the issue
[01:35] <ricmm> building with dpkg did, and I do see a couple differences
[01:35] <ricmm> racarr: still there? when building the deb pkg it uses -DBoost_COMPILER=-gcc
[01:36] <duflu> robert_ancell: I assume you didn't want a chat yesterday?
[01:36] <robert_ancell> duflu, nope, I'm good if you've got nothing
[01:36] <duflu> The usual...
[01:37] <duflu> Which is nothing not already mentioned on Wed
[01:46] <slangasek> ricmm: so by hand vs. packaging could be gcc-4.7 vs. gcc-4.8; and native vs. cross, the cross-compiler for gcc-4.7 actually hasn't been updated since April, even.  I'm going to try updating it now.
[01:48] <slangasek> for the 4.8 cross-compiler, I was mistaken, it is up-to-date wrt the native compiler
[02:05] <racarr> ricmm: Still around
[02:06] <ricmm> yea
[02:06] <racarr> hmm I remember that flag used to be necessary to build on android
[02:06] <ricmm> asking me? or answering
[02:06] <racarr> but don't know the etymology
[02:06] <racarr> more answering
[02:06] <racarr> than asking :p
[02:06] <ricmm> right
[02:10] <ricmm> racarr: alright so I see the issue, not sure how to fix it
[02:11] <ricmm> src/client/mir_client_library.cpp has a global std::unordered_set<MirConnection*> MirConnection::valid_connections;
[02:11] <ricmm> but thats a static member var of MirConnection
[02:12] <ricmm> when building Debug (unoptimized), the internal unordered_set's Hashtable has a correct address (_M_buckets)
[02:12] <ricmm> when release, the address is set to the next field's value (bucket_count), both to 0x17/23
[02:13] <ricmm> obv when it goes to clear it in the destructor and it memsets at 0x17 it goes boom
[02:13] <ricmm> it feels like a compiler bug
[02:14] <racarr> ricmm: Maybe break during initialization and set
[02:14] <racarr> a watch on the pointer
[02:14] <racarr> to see if it gets overwritten due to memory corruption
[02:14] <racarr> or if it really is a compiler bug
[02:17] <racarr> well you don't even need a watch right? I guess just
[02:17] <racarr> is it set incorrectly at initialization
[02:17] <ricmm> yea trying to get there
[02:17] <ricmm> its just templates and templates
[02:17] <ricmm> sec
[02:21] <slangasek> so you think the miscompile is in libmirclient, not in platform-api?
[02:33] <ricmm> wtf !
[02:33] <ricmm> racarr: ping
[02:33] <ricmm> http://paste.ubuntu.com/6220619/
[02:34] <ricmm> _M_buckets is changing
[02:34] <ricmm> and whatever is doing it is happening in mirclient p-api
[02:34] <ricmm> sigh
[02:34]  * ricmm rebuilds papi with symbols
[02:35] <d-snp> hey, do you guys know if steam os is going to run mir?
[02:37] <racarr> ricmm: What is your test case? I mean
[02:37] <racarr> opening a connection
[02:37] <racarr> oh well I guess it shouldnt change the address
[02:38] <ricmm> theres no test case
[02:38] <ricmm> loading the library is enough, as it creates the static set of MirConnection*
[02:38] <racarr> oh its literally just an empty program?
[02:38] <ricmm> yea
[02:39] <ricmm> racarr: https://launchpad.net/bugs/1238312
[02:40] <ricmm> the empty example is there
[02:40] <racarr> ok well hopefully papi debug symbols should be enlightening
[02:48] <ricmm> poor gdb
[02:48] <ricmm> not easy to watch for expressions ina c++ heavy stack
[02:50] <ricmm> nvm its stuck
[02:50] <ricmm> sigh
[02:50] <ricmm> oh no its not, just taking 100x times to run
[02:52] <ricmm> racarr: http://paste.ubuntu.com/6220667/
[02:53] <ricmm> looks like when error_connections is created, valid_connections goes to hell
[02:56] <racarr> ricmm: Hrm :/
[02:58] <racarr> it smells like compiler bug, but compiler bug smells like...probably not :p
[02:58] <racarr> ricmm: So wait why does qtubuntu work
[02:58] <racarr> I just built everything on device today, and clients seem fine, ran a bunch of autopilot tests, etc
[02:59] <ricmm> it works when we use the library
[02:59] <ricmm> at which point valid_connections will grow
[02:59] <ricmm> and it will most likely fix itself
[03:00] <racarr> lol
[03:00] <racarr> mm
[03:04] <racarr> ricmm: so it only happens when you link to ubuntu-application-api-mirclient
[03:04] <racarr> which also pulls in hybris
[03:05] <racarr> I wonder if its some sort of hybris wizardry gone wrong
[03:05] <racarr> seems as likely as a compiler bug
[03:05] <ricmm> seriously doubti ts hybris
[03:05] <ricmm> we are nowhere near nadroid at that point
[03:06] <racarr> but hybris has some
[03:06] <racarr> pthread
[03:06] <racarr> wizardy right
[03:06] <racarr> and the valid connections set is
[03:06] <racarr> potentially right next to a mutex
[03:06] <ricmm> hmm which one?
[03:06] <racarr> std::mutex MirConnection::connection_guard
[03:07] <ricmm> oh that one of course
[03:07] <ricmm> lol
[03:07] <ricmm> thats not a bad guess
[03:08] <ricmm> I could get a dbg hybris and check if we are hitting something weird
[03:08] <racarr> Seems worth figuring out
[03:08] <racarr> Dinner just showed up and I will be finished soon and start working more focused on this too...
[03:08] <racarr> now I am puzzled XD
[03:12] <racarr> ricmm: Err so
[03:12] <ricmm> I'm gonna move that thing to be initialized *after* error_connections
[03:12] <ricmm> and see what happens
[03:12] <ricmm> heh
[03:12] <racarr> on my phone, which...I flashed this afternoon, latest image I believe, then proceeded to build mir, platform-api (mirclient+mirserver), qtubuntu and unity-mir on
[03:13] <racarr> the test program doesnt segfault?
[03:13] <ricmm> how did you build mir
[03:13] <ricmm> Debug or Release?
[03:13] <racarr> Ah
[03:13] <ricmm> it has to be optimized
[03:13] <ricmm> otherwise it works
[03:14] <racarr> ok rebuilding
[03:17] <ricmm> sigh...
[03:18] <ricmm> racarr: swapping order of init with the mutex fixes it
[03:18] <ricmm> perhaps you are right with hybris and the mutex
[03:23] <robert_ancell> duflu, what does "this is the one" mean?
[03:23] <duflu> robert_ancell: As in the rules don't allow us to roll any more...?
[03:23] <robert_ancell> the one for?
[03:23] <robert_ancell> i.e. the final version for saucy?
[03:23] <duflu> robert_ancell: Yes. Unless we have exceptions?
[03:24] <ricmm> racarr: I dont like it at all :)
[03:25] <ricmm> racarr: im gonna eat and stuff its kinda late here maybe ill sleep
[03:25] <ricmm> I'll work early tomorrow to look at hybris and whats going on there
[03:25] <ricmm> for the time being....
[03:25] <ricmm> racarr: https://code.launchpad.net/~ricmm/mir/lp-1238312/+merge/190524
[03:25] <duflu> robert_ancell: I suspect we had an exception since everything against phone-v1-freeze hasn't hit lp:mir or the archive yet
[03:25] <robert_ancell> duflu, in a perfect world, but we might have things due to 1) or 2) in https://lists.ubuntu.com/archives/ubuntu-devel-announce/2013-October/001064.html
[03:26] <robert_ancell> duflu, I believe the plan is for the phone to switch straight to t-series, so new work will go in there
[03:26] <duflu> robert_ancell: Yeah of course. I'm just curious where saucy maintenance branches from. Looks like lp:mir r1096
[03:27] <robert_ancell> duflu, that seems likely
[03:28] <robert_ancell> duflu, your email lacks a little context there :)
[03:28] <duflu> robert_ancell: The point is Mir got released, or soon will be. One of them
[03:28] <robert_ancell> brb
[03:30] <racarr> ricmm: Ok so the risk is
[03:30] <racarr> if its not a compiler bug and something really is overwriting the mutex
[03:31] <racarr> then moving it
[03:31] <racarr> just defers
[03:31] <racarr> issues
[03:31] <ricmm> I know
[03:31] <ricmm> dont happrove that just leave it there sitting for now
[03:31] <ricmm> and im the morning ill look into hybris and pthread mutexes
[03:31] <racarr> mm
[03:32] <racarr> ill give it some look over night
[03:32] <ricmm> alright
[03:32] <racarr> Thanks for digging :D
[03:42] <rsalveti> racarr: this is not something with hybris
[03:42] <rsalveti> otherwise it'd not even work with the O0 version
[03:43] <rsalveti> hybris just maps function calls, don't change the program stack :-)
[04:00] <robert_ancell> RAOF, there's no way to tell XMir to look for "no Mir socket" right? I think that's the last piece to fix bug 1211141
[04:01] <RAOF> robert_ancell: How do we tell normal clients to do so? XMir does have a -mirSocket <str> option.
[04:01] <robert_ancell> RAOF, yeah, but I don't set that anymore and it defaults to /tmp/mir_socket
[04:01] <robert_ancell> the only way it doesn't use /tmp/mir_socket is if I give it something
[04:02] <robert_ancell> but in this case there is no socket
[04:02] <robert_ancell> I think we can just drop the default and set it to NULL now
[04:02] <RAOF> We didn't use URI specifiers for the bare-fd case?
[04:03] <robert_ancell> RAOF, I guess that might work, but I'd kind of like to just use the environment variable
[04:03] <robert_ancell> I'll try that
[04:04] <RAOF> Yeah, looks like you could send -mirSocket fd://4
[04:04] <RAOF> (For example)
[04:07] <RAOF> robert_ancell: Looks like the XMir in the archive will pass NULL through to mir_connect if you don't explicitly pass mirSocket; that presumably does what you want.
[04:07] <robert_ancell> RAOF, I read that it won't due to:
[04:07] <RAOF> robert_ancell: Or, rather, if libmirclient treats NULL as ‘look in an environment variable’, then that'll do what you want ;)
[04:08] <robert_ancell> yes mirclient does the right thing, but I think it's impossible for XMir to send NULL
[04:08] <robert_ancell> due to:
[04:08] <robert_ancell>    if (mirSocket != NULL)
[04:08] <robert_ancell>         socket = mirSocket;
[04:08] <RAOF> That's not in the current code.
[04:09] <robert_ancell> ah
[04:09] <robert_ancell> RAOF, what is the correct branch?
[04:11] <robert_ancell> brb
[04:11] <rsalveti> bottom approved https://code.launchpad.net/~ricmm/mir/lp-1238312/+merge/190524 as well
[04:13] <robert_ancell> RAOF, hmm, that didn't work either.
[04:14] <robert_ancell> [  1247.459] (EE) Failed to connect to Mir: connect not called
[04:15] <robert_ancell> have to solve that one another time, bye all
[04:16] <duflu> robert_ancell: Please leave the door open for running native Mir clients in USC. It's frequently a critical way to triage bugs...
[04:16] <robert_ancell> duflu, it's just a flag that's passed to u-s-c (--no-file)
[04:17] <duflu> robert_ancell: Yeah OK. Optional is good
[04:17] <robert_ancell> I would make it the default but mir is a pita in allowing changes like that
[04:30] <RAOF> Harumph.
[04:40] <mlankhorst> RAOF: no idea
[04:52] <RAOF> mlankhorst: Ok. I think I was mistaken, and they're per-drm-fd, which makes the point moot.
[05:45] <tvoss> duflu, resubmitted
[05:45] <duflu> tvoss: Already reapproved
[05:45] <tvoss> duflu, thx
[06:35] <mlankhorst> RAOF: ;D
[06:38] <RAOF> mlankhorst: It's a little odd that gem handles are the only thing that *aren't* refcounted, but that's ok :)
[06:45] <tvoss> alf_, ping
[06:46] <alf_> tvoss: pong
[07:32] <mlankhorst> RAOF: the fd isn't either
[08:40] <tvoss_> alan_g, alf_ I would appreciate if the both of you can make yourself familiar with https://code.launchpad.net/~kdub/mir/android-buffer-syncfence
[08:41] <tvoss_> alan_g, alf_ it tackles the performance issues on mako and maguro. It's on hold, but I would like to see it in Monday the latest
[08:41] <alan_g> tvoss_: Rats. Just when I cleared interruptions and got back to "very important"
[08:42] <tvoss_> alan_g, sorry :) that's life :)
[08:43]  * alan_g wonder when he'll be allowed to fix the shutdown/restart cycle
[08:44] <alf_> tvoss_: Does this branch actually fix the issue, or does it prepare the ground for the real fix? According to the description it does the latter, but perhaps I have misunderstood.
[08:44] <tvoss_> alf_, it actually fixes the issue
[08:56] <tvoss_> alf_, alan_g also https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1238287
[08:56] <tvoss_> alf_, alan_g Saviq is working to get us a better stacktrace
[08:57] <alf_> tvoss_: alan_g: ok, I will pick that up when I am done with the first pass of kdub's MP
[08:58] <tvoss_> alf_, thx
[09:13] <hikiko> mlankhorst, hi
[09:13] <hikiko> could you get a look at this: https://code.launchpad.net/~hikiko/mir/mir.fix-in-session-leader/+merge/190353 if you have a moment?
[09:28] <mlankhorst> RAOF: oh btw I patched mir a little too while I was debugging
[09:28] <mlankhorst> http://paste.debian.net/55897/
[09:29] <mlankhorst> in nested mode mir shouldn't claim a vt
[09:30] <mlankhorst> hikiko: actually there was a thing about that..
[09:30] <hikiko> :) what thing?
[09:31] <mlankhorst> oh fine just keep it like that if it fixes it :P
[09:32] <mlankhorst> yeah should be ok
[09:33] <hikiko> it fixes it, my only obsession was that there might be a case where a session leader has a controlling terminal, but since in the next line you do: openvt it should be fine isnt it? vt == new controlling terminal
[09:33] <hikiko> could you approve it?
[09:34] <mlankhorst> sec
[09:36] <mlankhorst> hikiko: meh obscure posix stuff, I need a moment to read up again..
[09:36] <duflu> Do we still not have CI running tests on Android?
[09:37] <hikiko> sure mlankhorst no prob :)
[09:37] <mlankhorst> hikiko: does being a sesion leader imply we own a process group too?
[09:38] <mlankhorst> hm I guess
[09:39] <hikiko> when you become a session leader you also become the leader of a new process group
[09:40]  * duflu used to know what that meant, but forgot
[09:40] <hikiko> and you cant become the session leader if you are a pg leader so that's why you break the group there I guess
[09:41] <hikiko> I think what you do is similar to the double fork trick that leaves one process without controlling terminal
[09:43] <hikiko> because you want to assign the vt as controlling terminal when you call openvt
[09:45] <mlankhorst> well good enough, I don't want to worry about it too much
[09:46] <hikiko> yes, it's a minor change it just fixes the tests
[09:47]  * mlankhorst instantly forgets everything about posix sessions again
[09:47] <hikiko> could you approve it so that we merge it?
[09:47] <hikiko> lol
[09:48] <alf_> mlankhorst: hikiko: The question is: what's the purpose of the code there. To claim a new controlling terminal, or to ensure we have none?
[09:49] <hikiko> alf_, since mir usually starts from a tty without being a session leader
[09:49] <hikiko> it might have a controlling terminal
[09:49] <mlankhorst> to claim the controlling terminal, but in some circumstances I guess we already own it
[09:49] <mlankhorst> meh lets see
[09:49] <hikiko> what we want is that it leaves the terminal and gets the vt
[09:49] <mlankhorst> we should be session leader to intercept SIGHUP and SIGCONT
[09:50] <alf_> mlankhorst: hikiko: if the purpose is to be able to claim a new controlling terminal, the code is fine. If it is to ensure we have none, then it is not.
[09:50] <mlankhorst> then it's fine
[09:50] <hikiko> alf_, the open vt command right after the if(..)
[09:51] <hikiko> assigns a controlling terminal (the vt) to the session leader
[09:51] <hikiko> so we do have a controlling terminal :)
[09:52] <alf_> hikiko: ok then, approved
[09:53] <hikiko> thanx
[09:53]  * alan_g is about to debug stuff that tends to break the graphics stack when it goes wrong
[12:48] <Saviq> hey folks, any idea about bug #1238645 ?
[12:53] <ogra_> Saviq, why would you stop maliit-server ?
[12:53] <ogra_> Saviq, it is tied to the shell through an upstart job
[12:53] <Saviq> ogra_, it's "simulating" a crash
[12:53] <ogra_> Saviq, to guarantee that it is always up
[12:53] <Saviq> ogra_, doesn't seem to be in some of our autopilot test
[12:54] <Saviq> s
[12:54] <ogra_> Saviq, right, the last fix for the upstart job went just in
[12:54] <Saviq> ogra_, but it should work regardless
[12:54] <ogra_> how would it work ?
[12:54] <Saviq> ogra_, it works through uinput
[12:54] <ogra_> if a test tries to use the not running OSK
[12:54] <tvoss_> Saviq, might well be that /dev/uinput is left with weird permission/weird state when maliit crashes
[12:54] <Saviq> ogra_, not through maliit
[12:54] <ogra_> ah
[12:55] <Saviq> tvoss_, maliit uses /dev/uinput?
[12:55] <Saviq> tvoss_, maliit isn't a standard input device is it?
[12:57] <ogra_> definitely not
[12:57] <ogra_> hmm, though we ship it by default
[12:57] <ogra_> root@ubuntu-phablet:/# ls -l  /dev/uinput
[12:57] <ogra_> crw-rw---- 1 root autopilot 10, 223 Oct 11 14:35 /dev/uinput
[12:58] <ogra_> with proper permissions even
[12:58] <ogra_> Saviq, check the permissions during and after the run
[12:58] <ogra_> probably autopilot breaks them
[12:59] <Saviq> ogra_, ah interesting
[12:59] <Saviq> crw-rw---- 1 system bluetooth 10, 223 Oct 11 10:44 /dev/uinput
[12:59] <tvoss_> hah ;)
[12:59] <ogra_> lol
[13:00] <ogra_> so just get a BT keyboatd for your test
[13:00] <ogra_> *keyboard
[13:00] <ogra_> and you will be fine
[13:00] <Saviq> the interesting thing is that it works
[13:00] <ogra_> (well, you might also need a robot to punch the keys ... but thats a minor detail)
[13:01] <tvoss_> ogra_, would like to see the branches linked to the bug report for building the robot
[13:01] <tvoss_> ;)
[13:01] <ogra_> haha
[13:01] <ogra_> Saviq, so find out what mangles the permissions
[13:01] <Saviq> ogra_, tvoss_, chowning :autopilot doesn't matter
[13:01] <ogra_> nothing in AP should touch them
[13:01] <Saviq> ogra_, nothing now ;)
[13:02] <Saviq> ogra_, they're at autopilot now
[13:02] <ogra_> ?
[13:02] <ogra_> who is they
[13:02] <Saviq> ogra_, I've chmod'ed :autopilot
[13:02] <ogra_> the permissions are set by udev rules
[13:02] <ogra_> ah
[13:02] <Saviq> ogra_, and it's still working / not changing
[13:02] <ogra_> :(
[13:02] <Saviq> ogra_, and anyway ap wouldn't be able to chmod it would it
[13:02] <Saviq> ogra_, running as phablet
[13:03] <ogra_> hmm
[13:03] <Saviq> or chown
[13:03] <ogra_> try to chgrp it to android_input
[13:03] <ogra_> phablet is in that group
[13:05] <Saviq> ogra_, but it *does* work when maliit is running
[13:05] <Saviq> ogra_, and perms don't change
[13:05] <Saviq> ogra_, I doubt it's so low level an issue
[13:07] <tvoss_> Saviq, is qt expecting an input method to run to process key events?
[13:08] <tvoss_> Saviq, at least on mobile platforms?
[13:15] <Saviq> tvoss_, no, I can use python + autopilot to type in there
[13:15] <Saviq> tvoss_, when maliit isn't running
[13:15] <Saviq> tvoss_, just it doesn't happen when ran through tests
[13:16] <tvoss_> Saviq, so what is the actual problem then?
[13:16] <tvoss_> Saviq, ah
[13:16] <tvoss_> :)
[13:16] <Saviq> tvoss_, so we need someone to track where the events get lost
[13:16] <Saviq> tvoss_, and/or if they're even delivered at all
[13:16] <tvoss_> asac, ^ we might need someone from your team here
[13:16] <Saviq> tvoss_, reproducible locally as the bug describes
[13:16] <Saviq> tvoss_, so someone just needs to look at the events from autopilot all the way up to unity8
[13:17] <Saviq> tvoss_, to see where they disappear
[13:18] <asac> wait
[13:18] <asac> Saviq: thats the problem? group getting changed on /dev/uinput?
[13:18] <Saviq> no
[13:19] <Saviq> tvoss_, asac, it's nothing infrastructural
[13:19] <tvoss_> Saviq, okay
[13:19] <Saviq> tvoss_, the events just don't get through the whole stack
[13:19] <tvoss_> Saviq, but you can manually send events from autopilot?
[13:19] <Saviq> tvoss_, yes, with autopilot.input.Keyboard - yes
[13:20] <asac> ok let me know if it turns out a premission problem on /dev/uinput in the end
[13:20] <tvoss_> asac, can someone from your team look if autopilot is having issues during the test run?
[13:20] <Saviq> tvoss_, tried under different scenarios of maliit stopping after / before autopilot creates the Keyboard object
[13:21] <Saviq> but everything worked fine no matter what I tried
[13:21] <asac> during which test run?
[13:21] <asac> sorry i lack context
[13:22] <tvoss_> asac, https://launchpad.net/bugs/1238645
[13:25] <asac> tvoss_: and you guys say you cant reproduce it?
[13:25] <asac> e.g. its always working for you? :)
[13:25] <tvoss_> asac, it's reproducible every time. However, when running autopilot manually and injecting key events, everything works
[13:45] <Saviq> guys, seen anything like https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1236251 already?
[13:45] <Saviq> let me upload a better .crash
[13:46] <Saviq> since lp/apport decided to drop everything, 'cause it's a duplicate of a private bug :P
[13:46] <seb128> Saviq, those Mir guys are mean to system settings
[13:46] <Saviq> seb128, yeah, can you access https://bugs.launchpad.net/bugs/1234930 ?
[13:46]  * Saviq hates private crashers
[13:46] <seb128> Saviq, yes, make it public for you
[13:46] <Saviq> seb128, thanks
[13:46] <seb128> not that it's useful...
[13:47] <Saviq> useless
[13:47] <Saviq> ok /me uploads a better crash
[14:29] <tvoss_> alf_, where is alan_g?
[14:30] <alf_> tvoss_: I don't know, last I saw was "* alan_g is about to debug stuff that tends to break the graphics stack when it goes wrong"
[15:39] <alf_> tvoss_: didrocks: please ensure that lp:mir and lp:development-branch stay in sync, i.e. commit to development-branch first and then merge into lp:mir manually, even when in a hurry
[15:39] <didrocks> alf_: we discussed that with duflu, the dev branch should contains it as well
[15:41] <alf_> didrocks: it doesn't and tracking changes can get confusing, as I am sure you know
[15:44] <alf_> didrocks: hmm, sorry it does, but that shows that these back and forth merges are difficult to track...
[15:45] <didrocks> alf_: I don't understand why your team recreated trunk somewhere else
[15:45] <didrocks> but that's another discussion I can't tackle now
[15:49] <mhall119> hey guys, I have the new mir-enabled builds for the phone, how can I take a screenshot now?
[15:49] <mhall119> /system/bin/screencap doesn't work anymore
[15:49] <kdub> mhall119, i don't know that there's a way at the moment
[15:50] <mhall119> :( that will put a serious dent in my Google+ postings
[15:57] <alf_> didrocks: tvoss_: fixed typo and synchronized lp:mir and development-branch
[15:58] <didrocks> alf_: thanks!
[15:59] <tvoss_> alf_, thanks
[16:25] <robotfuel> is there a way to run mir headless? like Xvfb does?
[16:31] <robotfuel> mhall119:  you might want to try this for screencap with mir http://people.canonical.com/~j-lallement/touch/mirfbdump
[16:31] <mhall119> robotfuel: thanks, balloons gave me that and it works perfectly
[17:15] <racarr> Saviq: WSeems like probably there is a switch
[17:15] <racarr> errr
[17:15] <racarr> ...whoops. IRC was stuck about 2 pages up
[18:30] <kgunn> kdub: no pressure - just curious....when do you think you might MP the "Ricky Bobby" patch
[18:31] <kdub> kgunn, working on it right, now, i'm hoping by eod
[18:32] <kgunn> kdub: cool...i was just asking that way if you did...i could queue it up for Monday
[18:52]  * greyback eod
[19:44] <kdub> unit tests are... 103mb
[19:45] <rsalveti> does anyone knows why the autobuilder is not producing armhf binaries?
[19:45] <rsalveti> looking at https://code.launchpad.net/~kdub/mir/android-buffer-syncfence/+merge/189717
[19:45] <rsalveti> seems it's not even building for armhf
[19:46] <kdub> i think we had some trouble with jenkins?
[19:46] <kdub> something i heard from alf_ during the daily mir standup
[19:47] <rsalveti> hm, ok
[20:01] <popey> kgunn: https://bugs.launchpad.net/ubuntu-clock-app/+bug/1238798
[20:01] <popey> clock core app renders black under mir, fine in sf
[20:02] <kgunn> popey: huh...which image
[20:02] <popey> I'm using 93
[20:02] <kgunn> popey: any other apps doing that ?
[20:03] <kgunn> popey: and specifically on 93, you deleted .display-mir and it worked ?
[20:03] <popey> lemme try that to confirm
[20:05] <popey> kgunn: sorry, stand down - black on sf too
[20:05] <kgunn> popey: ;)
[21:56] <jono> popey, I wonder if that is related to https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1229287
[21:59] <popey> jono: its new, sergio was looking at it in -touch
[22:00] <jono> popey, aha!