[06:28] <duflu> RAOF: Shouldn't "nm" show us exporting versioned symbols?
[06:29] <RAOF> duflu: Not in the default output, apparently.
[06:29] <RAOF> See objdump -T
[07:44] <RAOF> duflu: Re bug #1355005 - presumably you tested the --vt parameter on desktop?
[07:44] <duflu> RAOF: Yeah checking android right now
[07:44] <RAOF> duflu: Because that's a mesa-specific option.
[07:45] <RAOF> Passing --vt 1 will fail on android, but we don't pass --vt 1 on android as far as I can tell, so…
[07:47] <duflu> RAOF: Yep. Handballed to lightdm (if at all)
[07:48] <RAOF> I don't know how Cemil was getting his device to fail :)
[07:49]  * duflu checks the lightdm source
[07:51] <RAOF> What?!
[07:52] <RAOF> As soon as I get fed up with parallel valgrind runs reliably hitting what would seem to be a race in InProcessServer setup, it's suddenly all “what do you mean? It works just fine”
[07:55] <duflu> RAOF: Temp files!
[07:56] <RAOF> duflu: Generated by valgrind?
[07:56] <duflu> RAOF: Our tests do
[07:56] <RAOF> Oh, no. All of those are fine.
[07:56] <RAOF> As demonstrated by “make test ARGS=-j200” being reliable.
[07:56] <RAOF> Well, except for very rare failures in InProcessServer, which *doesn't* make a temp file.
[07:57] <duflu> RAOF: Wow, that's the run on a quantum computer option?
[07:57] <duflu> Cos of course it finds a solution then
[07:57] <RAOF> That's the “almost all of the memory is shared, and a major component of the test time is where we (necessarily) sleep for 3 seconds or whatever>
[07:58] <RAOF> There's no real reason not to run *all* the tests at once :)
[07:58] <RAOF> I just don't know the CMakery to make it happen by default
[08:00] <RAOF> Oh!
[08:01] <duflu> RAOF: More curious is how Cemil got it working at all. If you have the latest tip of either Mir branch then USC won't build at all (bug 1355021)
[08:02] <duflu> I guess it just wasn't the latest code
[08:11] <anpok> RAOF: it fails for me too image 183..
[08:11] <anpok> (vt param issue)
[08:11] <RAOF> anpok: What's adding the vt parameter?
[08:15] <anpok> it is not part of usc-wrapper
[08:16] <anpok> oh also the logs say that lightdm does it
[08:18] <RAOF> Yeah, /var/log/lightdm/lightdm.log is your winner.
[08:18] <RAOF> But why is LightDM setting the --vt parameter for you but not for me?
[08:18] <RAOF> What device are you running on?
[08:22]  * RAOF suspects lightdm's vt_can_multiseat() check is faulty.
[08:22] <anpok> n4
[08:24] <anpok> hm vt is only omiited if it stays unconfigured and negative
[08:24] <RAOF> anpok: Does your n4 have a /dev/tty0 and /sys/class/tty/tty0/active?
[08:24] <RAOF> Because that's what LightDM uses to determine whether or not to set the VT.
[08:25] <anpok> yes
[08:25] <anpok> both
[08:25] <RAOF> Ok, so that's why.
[08:26] <RAOF> The N4's kernel would appear to have CONFIG_VT set for some reason.
[08:28] <anpok> seat_unity_start?
[08:28] <RAOF> So: options are - add a VT option to the android backend, as it would clearly work (for some devices), change the LightDM check to not detect VT on android, or revert the change that makes unrecognised options fatal.
[08:29] <RAOF> anpok: Indeed. Calls vt_can_multi_seat()
[08:29] <anpok> but if it gets no vt it fails..
[08:29] <anpok> is there a fallback somwhere else that would then start usc?
[08:30] <RAOF> But it *does* get a VT
[08:30] <anpok> sure
[08:31] <RAOF> Oh, it only fails if it doesn't get a VT *and* vt_can_multi_seat returns true. Otherwise it sets 0.
[08:31] <anpok> given a device without a config_vt kernel...
[08:31] <RAOF> Which is “oh, I don't do VTs”
[08:31] <anpok> ah ok
[08:32] <RAOF> So, if you test on the N10 you'll never hit this, because it's apparently built without CONFIG_VT
[08:32] <anpok> and 0 means ommit
[08:32] <RAOF> Correct
[08:33] <alan_g> RAOF: we can add a handler for --vt to USC
[08:33] <alan_g> It's a few LOC as a workaround
[08:34] <alan_g> If Mir handles it then USC never hears about it, otherwise it can ignore it
[08:35] <RAOF> alan_g: That's a fine workaround, but we should also get lightdm to stop passing it.
[08:35] <alan_g> Yes.
[08:35] <RAOF> Because lightdm might behave incorrectly. If, say, it expects us to be on a particular VT and we totally ignore that :)
[08:35] <anpok> hm .. configuring lightm with minimum-vt=0 is not accepted by lightdm it expects >0
[08:36] <anpok> would be the wrong setting anyhow
[08:38] <alan_g> So, shall I put a workaround into USC/devel-mir-next? (With dirty great FIXME comments about lightdm)
[08:39] <RAOF> alan_g: Sounds like the quickest unblock.
[08:41] <anpok> hm lightdm is supposed to provide the platform parameters
[08:41] <anpok> so it should figure out which platform is going to be used
[08:41] <anpok> and only then consider vt options
[08:42] <anpok> or are we going to have start up time configured platform options?
[08:42] <RAOF> We should probably invest in an actual configuration file at some point.
[08:43] <anpok> i mean select the platform on startup inside mir..
[08:43] <RAOF> Oh, that.
[08:43] <RAOF> See https://code.launchpad.net/~raof/mir/privatise-all-the-things/+merge/228796
[08:43] <RAOF> Where we select the platform on startup inside mir :)
[08:45] <anpok> hm so in theory lightdm then needs to provide relevant options for all possible loadable platforms
[08:45] <RAOF> Not really; the only reason why lightdm provides the VT is that it needs to do VT handling.
[08:46] <RAOF> We *should* have a config file so that nonvolatile options can be specified there, though.
[09:27] <alan_g> RAOF: Done
[09:28] <alan_g> duflu: have you a fix for lp:1355021 or shall I MP mine?
[09:28] <duflu> alan_g: Yes, it's been up for review some time now :)
[09:29]  * alan_g hits refresh
[09:32] <alan_g> duflu: I think "Requires.private: mirclient" is all we need, but if you know better?
[09:33] <duflu> alan_g: Tried that first. Apparently it doesn't work like we thought it does
[09:33] <duflu> And the pkg-config docs are vague
[09:33] <alan_g> Hmm, I built USC that way - but I'll take your word for it
[09:34] <duflu> alan_g: Maybe I made a mistake. But that was my first idea.. private
[09:35] <alan_g> I'll retest
[09:40] <duflu> alan_g: I mean doesn't work in mirserver.pc.in ... and that's where you want the fix obviously. Users of mirserver should never have any knowledge that libmirserver links to libmirclient privately
[09:42] <alan_g> duflu: Yes. That's what I mean
[09:44] <duflu> alan_g: I also noticed we're missing Requires gles and egl too. But propose them separately
[09:52] <alan_g> duflu: that makes sense. "Requires.private: mirclient"  in mirserver.pc.in fixes builds of USC, qtmir, unity-mir and platform-api (the devel-mir-next branches) I think it is the way to go.
[09:53] <duflu> alan_g: I can only assume I made a mistake. It failed for me... didn't add -lmirclient to the link line of usc
[09:54] <alan_g> duflu: care to re-check?
[09:54] <duflu> alan_g: Actually I think rpath-link is nicer
[09:55] <duflu> alan_g: Not really. I'm trying to finish other things today. Land whatever works
[09:58] <alan_g> duflu: it was RAOF that suggested removing rpath
[09:58] <duflu> alan_g: Yeah it's a big hammer I guess. That's one disadvantage
[13:18] <groot_> Hello guys.
[13:19] <groot_> kdub: good news :). At last I booted UT with the latest ubuntu image (8 august). But logcat shows the same errors as it did in previous image.
[13:20] <alan_g> camako: There's a workarond for the --vt problem on USC/devel-mir-next already. And for the FTBFS at https://code.launchpad.net/~alan-griffiths/mir/fix-1355021/+merge/230272
[13:20] <groot_> Screen flickers a lot whenever I touch, probably due to EGL_BAD_MATCH error. I've the logs, can you take a look ?
[13:21] <camako> alan_g, yep incorporating them into the branches right now.
[13:24] <groot_> here's the logcat http://paste.ubuntu.com/8017115/. If you need any other logs, let me know.
[13:26] <kdub> groot_, good progress, flickers how?
[13:30] <groot_> kdub, all icons bounces up and down. Sometimes screen becomes white. When I press any app, it doesn't open until I touch the screen again.
[13:30] <kdub> hmm, might not have a quick fix :/
[13:32] <groot_> there's a error in logcat "call to OpenGL ES API with no current context". Maybe it's because of this or EGL_BAD_MATCH.
[13:32] <groot_> kdub: I'm patient :). Any log you need to identify the problem ?
[14:53] <racarr> Guten morgen!
[15:27] <alan_g> 192325
[15:32] <racarr> qengho: Hi...can't find this chromium-mir-apply-patch
[15:32] <racarr> you mentioned
[15:32] <racarr> did you take it down? Or maybe I am forming the URL wrong...
[15:32] <qengho> Oh. Hrm.
[15:33] <racarr> or is it not in your public_html? I dont seem to be able
[15:33] <qengho> Oh, not a url. I can move it into the web space.
[15:33] <racarr> to ssh to chinstrap anymore
[15:33] <racarr> ah
[15:35] <qengho> racarr: Okay, now in web space.
[15:37] <racarr> qengho: Ok well I will giveit a try and see what happens :)
[15:37] <qengho> racarr: I don't mean to dump a big problem on you. I'm debugging too. I think it's initializing too many times, and I'm testing that guess now.
[15:41] <racarr> Well I will at least get a build going so I have a working tree
[15:53] <racarr> qengho: + grep 'X-rev: untethered, sync dev patch back to release. Wanted 22454{revision:-a revision but none was specified.}' debian/patches/mir-support
[15:54] <racarr> ?
[15:54] <racarr> ./apply-patch-distro.sh: line 52: f: unbound variable
[15:56] <qengho> racarr: Hrm. I'm missing a blackslash.  Download again?
[15:56] <qengho> Just fixed in place.
[16:05] <racarr> qengho: :) s'goin now thanks
[16:05] <qengho> racarr: shell script within a shell script within a shell script.  Fancy, but error-prone.
[16:23] <dandrader> alf_, is the take_snapshot() method guaranteed to call the callback from a thread different from the caller?
[16:24] <dandrader> alf_, in other words: is it guaranteed to be asynchronous or could it be synchronous?
[16:27] <qengho> Hi, what can my client use to determine whether it's in a Mir session?  Env var "MIR_SERVER_NAME"?
[16:35] <alan_g> qengho: I'm not sure I understand the question. A Mir session doesn't exist until a client connects to a Mir server - at which point it ought to know about having connected.
[16:45] <racarr> qengho: I guess you mean like, how could you autodetect mir v. x11
[16:47] <racarr> MIR_SOCKET will not necessarily be set so I don't really know...
[16:47] <racarr> You can see if mir_connect fails :)
[16:47] <racarr> certainly if you can connect to X11 and Mir you probably want to connect to Mir
[16:58] <alan_g> qengho: By default a client connects to $XDG_RUNTIME_DIR/mir_socket - so that file existing would be an indication of a mir server. But the server could have supplied $MIR_SOCKET to override this location. (It is also possible for servers to do something else that the Mir code doesn't support directly but the client should know about that.)
[16:58] <qengho> Thanks.
[16:58] <alan_g> As racarr says, if mir_connect fails then there's probably no Mir server
[17:11] <racarr> Can we rm -rf platform-api-mirserver? did someone already
[17:12] <racarr> looks like its still there
[17:13] <racarr> qengho: It is telling me patches/mir-support already exists and bailing out of the script
[17:15] <qengho> racarr: Ah, right. You can "quilt delete mir-support" or edit debian/patches/series to disable the one I added.
[17:18] <greyback> racarr: +1 on  rm -rf platform-api-mirserver
[17:21] <racarr> qengho: :) thanks. I figured. I just wanted to make sure I was "following the instructions"
[17:21] <racarr> for reproducability
[17:21] <racarr> greyback: Ok I will submit an MP soon...I dont know if now is the time to do it but
[17:21] <racarr> I mean otherwise we will just forget lol
[17:21] <racarr> I would at least :)
[17:22] <greyback> racarr: it's far from important right now
[17:22] <greyback> but nobody will forget it - any time you've to do anything with papi, you can't avoid seeing it :)
[17:23] <racarr> mm
[22:30] <mhall119> is mircast working to record videos from a device yet?
[22:38] <ogra_> that always worked ... but youo wont have enough space on the device for the raw data
[22:43] <ogra_> mhall119, http://paste.ubuntu.com/8021284/ ... still in very early stages (and i havent touched it in  months) ... my plan was to actually get from there to having netcat stream it on a port into avconv on a PC
[23:10] <RAOF> ogra_: Did you look at hooking the stream up to the hardware video encoding bits?
[23:10] <RAOF> ogra_: I think that our screencasting interface should be expressive enough for you to do zero-copy screencast → hardware encoder, which would give you much more space on the device :)
[23:11] <ogra_> oh, thats actually a nice idea, no, the above is just a bit of sunday afternoon scriptery from when mirscreencase was new ... i'll pick up that work after RTM again
[23:12] <ogra_> *cast
[23:26] <camako> Mir 0.6.0 release is ready for testing.... Here are the instructions to use Mir 0.6.0 : http://pastebin.ubuntu.com/7993688/
[23:28] <camako> AlbertA, racarr, kdub ^^ ... You guys might be EoD by now, but in case you're not...
[23:29] <camako> Mir test plan --- > https://wiki.ubuntu.com/Process/Merges/TestPlans/Mir