[00:02] <RAOF> robert_ancell: Not really opposed, but I think it should be low priority (and so not shown by default on install). If someone adds the PPA, they probably want the system compository.
[00:13] <thomi> hmm, so in the last three days something changed in mir, and now I once again get file handle leaks, which prevent the mir-stress tests from running.
[01:57] <thomi> robert_ancell: got a second?
[01:58] <robert_ancell> thomi, sure
[01:58] <thomi> robert_ancell: I think that, even in it's uncompleted state, mir-stress is useful enough to be run on merge proposals. To achieve this, I need to get it merged into trunk. Do you see any issues with me merging it into lp:mir and continuing to work on it from there? (i.e.- after it's run on all MPs?)
[01:59] <robert_ancell> thomi, as long as it works fine it should be good to start merging
[01:59] <thomi> well, As of today, it would fail MPs, but that's because mir leaks FDs again
[01:59] <thomi> which seems to be a recurring problem
[02:00] <thomi> so it might cause you some grief, but in a good way :)
[02:01] <thomi> robert_ancell: the other thing is that from next Monday (the 10th), I'm on holiday for 2 weeks, so perhps it's better to wait until I get back.. or maybe we pick a strategy so even if it causes problems it won't be too disruptive
[02:01]  * thomi shrugs
[02:01] <robert_ancell> thomi, worth proposing now, so it can get reviewed early
[02:01] <thomi> ok
[03:53] <robert_ancell> thomi, is lp:lightdm-trunk-packaging supposed to contain all the lightdm project files? I need to add a new build-dep, not sure what the correct way to update this branch is
[03:53] <robert_ancell> I mean lp:~lightdm-team/lightdm/trunk-packaging
[03:54] <thomi> that sounds like the "old" way distro used to do packaging.
[03:54] <thomi> I'll investigate, one sec
[03:55] <thomi> robert_ancell: yeah, in time we should probably regenerate that, but I believe you should be abel to update the build-dep in that branch fine
[03:56] <thomi> just ignore all the other files :)
[03:56] <robert_ancell> thomi, ok, cheers
[03:56] <robert_ancell> I just push directly right? i.e. no MP
[03:56] <thomi> robert_ancell: yep
[03:57] <robert_ancell> thomi, and I don't need to update debian/changelog?
[03:57] <thomi> robert_ancell: ideally we'd have inline packaging, but I understand why that's not an option here
[03:57] <thomi> robert_ancell: nope, shouldn't need to
[03:57] <robert_ancell> yeah, I've been trying to think of a better method, but ultimately there will be some Ubuntu specific things that would have to diverge
[03:57] <thomi> yeah
[03:58] <thomi> you could perhaps still make upstream release tarballs without the debian/ directory?
[03:58] <robert_ancell> I could (and would)
[04:53] <robert_ancell> RAOF, do you know of any other method to communicate the Mir socket to clients other than via a MIR_SOCKET env variable?
[04:54] <robert_ancell> I guess in theory we could give the socket the shell and it could pass it on via some clever method but it seems it would make things overly difficult
[04:55] <RAOF> I'm still partial to “the shell opens a mir connection before spawning the client, and when it is spawned fd 3 is ready to connect to Mir”
[04:56] <RAOF> Failing that, it's an environment variable, or possibly just $RUN/user/mir/socket
[04:58] <robert_ancell> RAOF, is there a potential case of having more than one Mir server to connect to?
[04:59] <RAOF> I can't think of any reason why a user would want more than one Mir session active at one time.
[04:59] <robert_ancell> RAOF, the problem with option 1, is you can't run an app from a terminal ever (unless we make some clever opt-in API to the shell)
[04:59] <robert_ancell> I'm working on LightDM support for Mir sessions, but given they only exist in theory it's kind of hard to write test cases for :)
[05:00] <RAOF> Eh, we write “mir-run” which is a trivial wrapper around a shell DBus API to get an app spawned.
[05:00] <robert_ancell> Also, I guess even in case 1 you would have to pass an env variable to the app to give it the fd number
[05:01] <RAOF> No?
[05:01] <robert_ancell> I'm assuming at the moment that whatever the solution there will be an env variable set - and I can base tests off that variable (and make the daemon set it)
[05:01] <robert_ancell> hard code 3=mir socket?
[05:01] <robert_ancell> you can't introspect fds in any way can you?
[05:01] <RAOF> fd 3 would always be the mir socket, in the same way that fd 0-2 are always stdout, sterr, stdin.
[05:02] <robert_ancell> unless we screw something up and another fd gets inserver
[05:02] <robert_ancell> inserted
[05:02] <RAOF> Correct.
[05:02] <RAOF> But then that'd be a problem with sending the fd number as an environment variable anyway.
[05:03] <robert_ancell> I couldn't think of a problem..
[05:04] <RAOF> Well, it's the same sort of problem as “what if we leave another fd open as fd 3”, right?
[05:05] <RAOF> “What happens if we screw up and the fd number we set in the environment doesn't match the actual fd?”
[05:06] <RAOF> You know, we could also get this over dbus.
[05:08] <RAOF> But that's probably overthinking it.
[05:09] <robert_ancell> RAOF, ok, a specific case would be if an app was launching another app and had to pass on the fd - the next fd available might not be 3
[05:10] <RAOF> robert_ancell: It could fork(), close(3), then open the mir connection, which should then be fd 3?
[05:10] <robert_ancell> RAOF, 3 might be something else that it does need to pass on, e.g. some pipe for something
[05:11] <robert_ancell> I guess you could dup and close, but it seems nicer to just be explicit
[05:11] <RAOF> Yeah, I guess.
[05:12] <RAOF> I suspect that we'll probably end up with $XDG_RUNTIME_DIR/mir/socket, or whatever $MIR_SOCKET points to if that's set.
[05:12] <robert_ancell> yeah, that
[05:12] <robert_ancell> 's what I'm hoping
[05:13] <robert_ancell> RAOF, is that still what Wayland is doing afayk?
[05:13] <RAOF> I think so, yes.
[05:14] <RAOF> The well-known-fd option is cool, but probably overkill ;)
[05:17] <robert_ancell> RAOF, pff, I don't even trust stderr to be 2, I use STDERR_FILENO
[10:22] <alan_g> alf_: looking at client-rpc-report-lttng - and wondering (without thinking too deeply) that it would be nice to avoid having different client & server shared libs for lttng support. Would that require reworking the TRACEPOINT_* magic?
[10:23] <alf_> alan_g: thinking...
[10:37] <alf_> alan_g: I think this is doable. We would need to create a single SO containing the tracepoint provider sources (*_tp.*) from both client and server. This means that server produces mirserverlttng.a, the client produces mirclientlttng.a, and at some point (in shared?) we create a libmirlttng.so from these two.
[10:38] <alf_> alan_g: However, it does create some complications in terms of packaging, and also it couples the client and the server object-file-wise.
[10:38] <alan_g> alf_: thanks for thinking it through - I don't think that would be worth doing.
[10:39] <alan_g> I was more thinking of removing the direct dependencies on lttng - not the program specific stuff generated
[10:42]  * alan_g will be offline for a few minutes while he moves to the garden "office"
[15:12] <racarr> Morning
[15:15] <alan_g> Afternoon
[15:23] <kgunn> alf_: ping
[15:23] <alf_> kgunn: pong
[16:52] <racarr> "Finished" new platform API mirserver. Coffee break!
[17:18] <racarr> lol...
[17:18] <racarr> tried not drinking caffeine for a while this morning to see what would happen
[17:18] <racarr> now halfway through coffee...*twitch*
[17:23] <racarr> I think
[17:24] <racarr> I don't know when exactly.
[17:24] <racarr> But we should adopt
[17:24] <racarr> ubuntu::Event as MirEvent
[17:25] <racarr> The current codepath on the client is kind of embarasing:
[17:26] <racarr> read droidinput::InputMessage off the wire. Copy to droidinput::InputEvent, copy to MirEvent, send to platorm API, copy to Ubuntu event (99% identical with mir event...but not memcpy identical XD), send to toolkit, copy to QEvent
[17:26] <racarr> Elegance: ^
[17:28] <racarr> kdub_: An interesting point about the C->C++ layer in the client library and the lack of testing
[17:28] <racarr> the same problems
[17:29] <racarr> prevent platorm-api-mirclient from having good unit tests
[17:29] <racarr> because you can't meaningfully mock the machinery of the client library, so you would have to mock the whole server, or just run a server or whatever.
[17:29] <kdub_> right, its like oblique testing
[17:29] <kdub_> and there are some oblique data paths that have popped up
[17:30] <racarr> Ignoring for  second the idea of getting rid of mirclient
[17:30] <racarr> it could be made more testable.
[17:30] <racarr> i.e.
[17:30] <racarr> we introduce a "ClientConfiguration" which lets you mock the machinery (i.e. MirConnection) etc.
[17:30] <racarr> and there is private API like
[17:30] <racarr> mir_connect_with_configuration
[17:31] <racarr> (mir_connect calls this with default_configuration)
[17:32] <racarr> though I don't even know what I want to test here and if that helps me ;)
[17:34] <kdub_> i thought we had one of those
[17:35] <kdub_> src/client/default_connection_configuration.cpp
[17:39] <racarr> kdub_: I don't have that file ;)
[17:40] <racarr> are you sure you didn't write it today
[17:48] <racarr> uint32_t ua_ui_display_query_horizontal_res
[17:49] <racarr> I wonder if someone will hate us for that in a decade
[17:49] <racarr> "Unity crashes when I enable by second 2147483648
[17:49] <racarr> pixel monitor"
[17:50] <racarr> ...feels pretty unlikely
[17:51] <kdub_> racarr, its a newer file... http://bazaar.launchpad.net/~mir-team/mir/trunk/view/head:/src/client/default_connection_configuration.h
[17:51] <kdub_> maybe a merge will bring it in
[17:51] <racarr> lol, it requires over 256 exabytes per second of bandwidth to drive a monitor that overflows 32 bit resolution
[17:51] <racarr> with 32 bit color depth
[17:51] <racarr> that
[17:52] <racarr> cant be true
[17:52] <racarr> anyway enough of that
[17:52] <racarr> kdub_: Ohhh
[17:52] <racarr> beautiul
[17:52] <racarr> it came in alfs stuff
[17:52] <racarr> I guess
[20:17] <kgunn> racarr: kdub_ does the android input stack support pretty much any evdev device ?
[20:17] <kdub_> my understanding is yes, but i'll for racarr to confirm
[20:41] <kgunn> kdub_: mind joining #ubuntu-unity
[20:42] <kdub_> oh sure.. .should add that one to my autojoin channels too!
[21:43] <racarr> kgunn: Merr. Sorry. Comcast strikes again.
[21:43] <racarr> Yes pretty much any evdev device seems to be the case
[21:44] <racarr> there are all sorts of weird defines for like ...the right pedal axis, or the left rudder lol.
[23:28] <racarr> *stretches* platform API server/client 2.0 are "finished" save for a sensors enabled hybris build, that's just one last bit of wiring for tomorrow though
[23:29] <racarr> I think I just wrote roughly 100 3-4 line functions *cringe*