[00:02] 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] 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] robert_ancell: got a second? [01:58] thomi, sure [01:58] 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] thomi, as long as it works fine it should be good to start merging [01:59] well, As of today, it would fail MPs, but that's because mir leaks FDs again [01:59] which seems to be a recurring problem [02:00] so it might cause you some grief, but in a good way :) [02:01] 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] thomi, worth proposing now, so it can get reviewed early [02:01] ok [03:53] 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] I mean lp:~lightdm-team/lightdm/trunk-packaging [03:54] that sounds like the "old" way distro used to do packaging. [03:54] I'll investigate, one sec [03:55] 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] just ignore all the other files :) [03:56] thomi, ok, cheers [03:56] I just push directly right? i.e. no MP [03:56] robert_ancell: yep [03:57] thomi, and I don't need to update debian/changelog? [03:57] robert_ancell: ideally we'd have inline packaging, but I understand why that's not an option here [03:57] robert_ancell: nope, shouldn't need to [03:57] 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] yeah [03:58] you could perhaps still make upstream release tarballs without the debian/ directory? [03:58] I could (and would) [04:53] 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] 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] 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] Failing that, it's an environment variable, or possibly just $RUN/user/mir/socket [04:58] RAOF, is there a potential case of having more than one Mir server to connect to? [04:59] I can't think of any reason why a user would want more than one Mir session active at one time. [04:59] 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] 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] Eh, we write “mir-run” which is a trivial wrapper around a shell DBus API to get an app spawned. [05:00] 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] No? [05:01] 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] hard code 3=mir socket? [05:01] you can't introspect fds in any way can you? [05:01] fd 3 would always be the mir socket, in the same way that fd 0-2 are always stdout, sterr, stdin. [05:02] unless we screw something up and another fd gets inserver [05:02] inserted [05:02] Correct. [05:02] But then that'd be a problem with sending the fd number as an environment variable anyway. [05:03] I couldn't think of a problem.. [05:04] Well, it's the same sort of problem as “what if we leave another fd open as fd 3”, right? [05:05] “What happens if we screw up and the fd number we set in the environment doesn't match the actual fd?” [05:06] You know, we could also get this over dbus. [05:08] But that's probably overthinking it. [05:09] 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] robert_ancell: It could fork(), close(3), then open the mir connection, which should then be fd 3? [05:10] RAOF, 3 might be something else that it does need to pass on, e.g. some pipe for something [05:11] I guess you could dup and close, but it seems nicer to just be explicit [05:11] Yeah, I guess. [05:12] 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] yeah, that [05:12] 's what I'm hoping [05:13] RAOF, is that still what Wayland is doing afayk? [05:13] I think so, yes. [05:14] The well-known-fd option is cool, but probably overkill ;) [05:17] RAOF, pff, I don't even trust stderr to be 2, I use STDERR_FILENO === dpm-afk is now known as dpm === greyback|away is now known as greyback [10:22] 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] alan_g: thinking... [10:37] 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] 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] alf_: thanks for thinking it through - I don't think that would be worth doing. [10:39] 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" === mmrazik is now known as mmrazik|lunch === mmrazik|lunch is now known as mmrazik === alan_g is now known as alan_g|lunch === alan_g|lunch is now known as alan_g === mmrazik is now known as mmrazik|otp === mmrazik|otp is now known as mmrazik [15:12] Morning [15:15] Afternoon [15:23] alf_: ping [15:23] kgunn: pong === mmrazik is now known as mmrazik|afk [16:52] "Finished" new platform API mirserver. Coffee break! === alan_g is now known as alan_g|life [17:18] lol... [17:18] tried not drinking caffeine for a while this morning to see what would happen [17:18] now halfway through coffee...*twitch* [17:23] I think [17:24] I don't know when exactly. [17:24] But we should adopt [17:24] ubuntu::Event as MirEvent [17:25] The current codepath on the client is kind of embarasing: [17:26] 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] Elegance: ^ [17:28] kdub_: An interesting point about the C->C++ layer in the client library and the lack of testing [17:28] the same problems [17:29] prevent platorm-api-mirclient from having good unit tests [17:29] 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] right, its like oblique testing [17:29] and there are some oblique data paths that have popped up [17:30] Ignoring for second the idea of getting rid of mirclient [17:30] it could be made more testable. [17:30] i.e. [17:30] we introduce a "ClientConfiguration" which lets you mock the machinery (i.e. MirConnection) etc. [17:30] and there is private API like [17:30] mir_connect_with_configuration [17:31] (mir_connect calls this with default_configuration) [17:32] though I don't even know what I want to test here and if that helps me ;) [17:34] i thought we had one of those [17:35] src/client/default_connection_configuration.cpp [17:39] kdub_: I don't have that file ;) [17:40] are you sure you didn't write it today [17:48] uint32_t ua_ui_display_query_horizontal_res [17:49] I wonder if someone will hate us for that in a decade [17:49] "Unity crashes when I enable by second 2147483648 [17:49] pixel monitor" [17:50] ...feels pretty unlikely [17:51] racarr, its a newer file... http://bazaar.launchpad.net/~mir-team/mir/trunk/view/head:/src/client/default_connection_configuration.h [17:51] maybe a merge will bring it in [17:51] lol, it requires over 256 exabytes per second of bandwidth to drive a monitor that overflows 32 bit resolution [17:51] with 32 bit color depth [17:51] that [17:52] cant be true [17:52] anyway enough of that [17:52] kdub_: Ohhh [17:52] beautiul [17:52] it came in alfs stuff [17:52] I guess === Cimi_ is now known as Cimi === Cheery_ is now known as Cheery === olli__ is now known as olli === mmrazik|afk is now known as mmraazik === mmraazik is now known as mmrazik === Stskeepz is now known as Stskeeps [20:17] racarr: kdub_ does the android input stack support pretty much any evdev device ? [20:17] my understanding is yes, but i'll for racarr to confirm [20:41] kdub_: mind joining #ubuntu-unity [20:42] oh sure.. .should add that one to my autojoin channels too! [21:43] kgunn: Merr. Sorry. Comcast strikes again. [21:43] Yes pretty much any evdev device seems to be the case [21:44] there are all sorts of weird defines for like ...the right pedal axis, or the left rudder lol. [23:28] *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] I think I just wrote roughly 100 3-4 line functions *cringe* === csslayer_ is now known as csslayer