=== mpt_ is now known as mpt [07:24] Europe comes online and Launchpad times out lots :) === sil2100_ is now known as sil2100 [09:58] alf: We don't use the snapshot logic for screencasting, right? [09:58] And "screenshots" use screencasting [10:01] duflu: right and right [10:01] screensnapcastshot [10:02] thing [10:02] (tm) [10:49] does anyone know at what point the SessionAuthorizer is created for qt apps? [10:58] tsdgeos: during Mir startup - when the_session_authorizer() is called setting up the connector. [10:58] alan_g: yeah i found [10:58] alan_g: so i have a small problem not sure if you're able to help [10:59] alan_g: basically the sessionauthorizer is calling things "too early" and my other singleton that is supposed to work together with it is still not ready [10:59] i guess that's more qtmir than mir [11:00] tsdgeos: yeah, Mir doesn't like singletons [11:00] alan_g: well it's not really even a singleton (Well it is, but it's basically loaded by another plugin :D) [11:00] * tsdgeos checks when Gerry is back from holydays [11:01] tsdgeos: so your SessionAuthorizer does stuff when created? [11:02] alan_g: no, thing goes like this [11:02] SessionAuthorized is created [11:02] someone calls connection_is_allowed [11:02] but the other thing we use to "naswer" connection_is_allowed is still not created [11:02] so things go wrong [11:02] unfortunately "the other thing" is in a different plugin [11:03] so synchronizing them seems to be pretty hard [11:03] more for me that have no clue at all about that code :D [11:03] dandrader: maybe you know a bit about SessionAuthorizer/ApplicationManager ? [11:04] tsdgeos, a bit, don't expect much [11:04] Is there a way to block connection_is_allowed until the needed helper is loaded? [11:04] alan_g: i guess that'd be it, but being in different plugins is not that optimal i'd say [11:05] dandrader: do you know if/how unity8 finds out about apps that were running before it started? [11:05] Well, I'm not sure why Mir would be started before unity is ready to handle connections [11:06] because everything is a plugin :/ [11:07] But it doesn't need to be *started* when the plugin loads [11:10] tsdgeos, I recall that it didn't know about them [11:11] tsdgeos, but that might have changed recently [11:11] ok [11:11] tsdgeos, as you already mentioned, Gerry is the one that has been working on that part === alan_g is now known as alan_g|lunch === dandrader_ is now known as dandrader === alan_g|lunch is now known as alan_g [13:37] camako: this bug is about the time taken by this test to run. Not about it failing (which I don't deny). https://bugs.launchpad.net/mir/+bug/1375211/comments/4 [13:37] Ubuntu bug 1375211 in Mir "[regression] unit_tests AndroidInputReceiverSetup.* takes excessive time" [Low,In progress] [13:42] alan_g, Before r1955, it was taking excessive time but passing jenkins... with r1955 (tried to address the issue of time taken) but the test itself failed on jenkins every time. [13:44] camako: about the test - https://code.launchpad.net/~vanvugt/mir/fix-1375211-v2/+merge/236989/comments/580795 [13:47] alan_g, so you're okay with the fix in there but not the test? [13:48] camako: yeah. The test is well motivated, but flaky [13:51] alan_g, if it passes jenkins, then no harm done by the test (or is that not the case?)... if it doesn't, then duflu will then agree to remove it. [13:53] camako: the test, in effect, set a timer to 0ms and then tests that it expires in under 1ms at least one time in a hundred. Which is likely, but *not* guaranteed by anything we can control. (we're not a RTOS) [13:54] think valgrind on slow, loaded build servers... [13:58] I agree it's not a guarantee... but it's a problem if it fails with high probability. It's difficult to say it will. My thought is if it passes jenkins then it's good enough. [14:00] That attitude is how we get annoying intermittent test failures. If a thousand tests each passes 99.9% of the time we have trouble landing. [14:02] If that were true, yes... I'm just saying it'll be more convincing if you can get it to fail locally, for instance, by simulating a loaded server. [14:04] I'll remind you of that when it goes wrong during an urgent release. [14:04] :-) [14:07] I understand what you're saying anfd they are valid points. But without evidence (and assuming it passes jenkins - which *is* a loaded server), it's difficult to support one-side of the argument over the other. Feel free to put these comments on the review and even disapprove. === dandrader is now known as dandrader|afk === chihchun is now known as chihchun_afk === dandrader|afk is now known as dandrader === dandrader is now known as dandrader|afk === alan_g is now known as alan_g|EOW === dandrader|afk is now known as dandrader [18:54] kgunn: are you the person to get unity-scopes-api bugs triaged? I have this new top crasher today https://errors.ubuntu.com/problem/72efb07867c31436ac312b1a5027bfa6ee90b0bd [18:56] kgunn: hmm never mind it looks like it might be apparmor [19:00] robotfuel: for future, that'd be thostr [22:10] kgunn: I ran in to this on both mako and krillin today https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1360593 [22:10] Ubuntu bug 1360593 in unity8 (Ubuntu) "unity8 freezes randomly" [Critical,Confirmed] [22:10] I unmarked the duplicate of the location services bug [22:10] :( [22:11] let me know if you'd rather have a new bug open [22:11] kgunn: ^ [22:14] ah I see in the last comment you want a fresh bug.. so I'll do that [22:14] robotfuel: also can you please attach a profile of the memory being used ? [22:14] e.g. list of all processes and threads [22:15] i'd be curious if this might be the damn OOM killer killing services [22:15] it shouldn't [22:15] kgunn: sure, it's very low on memory [22:37] kgunn: this the new bug https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1377332 I grabbed extra logs so let me know if I can help with more [22:37] Ubuntu bug 1377332 in unity8 (Ubuntu) "UI randomly freezes" [Undecided,New] [22:39] I have dinner plans have to run