[07:24] <duflu> Europe comes online and Launchpad times out lots :)
[09:58] <duflu> alf: We don't use the snapshot logic for screencasting, right?
[09:58] <duflu> And "screenshots" use screencasting
[10:01] <alf__> duflu: right and right
[10:01] <duflu> screensnapcastshot
[10:02] <duflu> thing
[10:02] <duflu> (tm)
[10:49] <tsdgeos> does anyone know at what point the SessionAuthorizer is created for qt apps?
[10:58] <alan_g> tsdgeos: during Mir startup - when the_session_authorizer() is called setting up the connector.
[10:58] <tsdgeos> alan_g: yeah i found
[10:58] <tsdgeos> alan_g: so i have a small problem not sure if you're able to help
[10:59] <tsdgeos> 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] <tsdgeos> i guess that's more qtmir than mir
[11:00] <alan_g> tsdgeos: yeah, Mir doesn't like singletons
[11:00] <tsdgeos> 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] <alan_g> tsdgeos: so your SessionAuthorizer does stuff when created?
[11:02] <tsdgeos> alan_g: no, thing goes like this
[11:02] <tsdgeos> SessionAuthorized is created
[11:02] <tsdgeos> someone calls connection_is_allowed
[11:02] <tsdgeos> but the other thing we use to "naswer" connection_is_allowed is still not created
[11:02] <tsdgeos> so things go wrong
[11:02] <tsdgeos> unfortunately "the other thing" is in a different plugin
[11:03] <tsdgeos> so synchronizing them seems to be pretty hard
[11:03] <tsdgeos> more for me that have no clue at all about that code :D
[11:03] <tsdgeos> dandrader: maybe you know a bit about SessionAuthorizer/ApplicationManager ?
[11:04] <dandrader> tsdgeos, a bit, don't expect much
[11:04] <alan_g> Is there a way to block connection_is_allowed until the needed helper is loaded?
[11:04] <tsdgeos> alan_g: i guess that'd be it, but being in different plugins is not that optimal i'd say
[11:05] <tsdgeos> dandrader: do you know if/how unity8 finds out about apps that were running before it started?
[11:05] <alan_g> Well, I'm not sure why Mir would be started before unity is ready to handle connections
[11:06] <tsdgeos> because everything is a plugin :/
[11:07] <alan_g> But it doesn't need to be *started* when the plugin loads
[11:10] <dandrader_> tsdgeos, I recall that it didn't know about them
[11:11] <dandrader_> tsdgeos, but that might have changed recently
[11:11] <tsdgeos> ok
[11:11] <dandrader_> tsdgeos, as you already mentioned, Gerry is the one that has been working on that part
[13:37] <alan_g> 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:42] <camako> 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] <alan_g> camako: about the test - https://code.launchpad.net/~vanvugt/mir/fix-1375211-v2/+merge/236989/comments/580795
[13:47] <camako> alan_g, so you're okay with the fix in there but not the test?
[13:48] <alan_g> camako: yeah. The test is well motivated, but flaky
[13:51] <camako> 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] <alan_g> 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] <alan_g> think valgrind on slow, loaded build servers...
[13:58] <camako> 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] <alan_g> 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] <camako> 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] <alan_g> I'll remind you of that when it goes wrong during an urgent release.
[14:04] <camako> :-)
[14:07] <camako> 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.
[18:54] <robotfuel> 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] <robotfuel> kgunn: hmm never mind it looks like it might be apparmor
[19:00] <kgunn> robotfuel: for future, that'd be thostr
[22:10] <robotfuel> kgunn: I ran in to this on both mako and krillin today https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1360593
[22:10] <robotfuel> I unmarked the duplicate of the location services bug
[22:10] <robotfuel> :(
[22:11] <robotfuel> let me know if you'd rather have a new bug open
[22:11] <robotfuel> kgunn: ^
[22:14] <robotfuel> ah I see in the last comment you want a fresh bug.. so I'll do that
[22:14] <kgunn> robotfuel: also can you please attach a profile of the memory being used ?
[22:14] <kgunn> e.g. list of all processes and threads
[22:15] <kgunn> i'd be curious if this might be the damn OOM killer killing services
[22:15] <kgunn> it shouldn't
[22:15] <robotfuel> kgunn: sure, it's very low on memory
[22:37] <robotfuel> 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:39] <robotfuel> I have dinner plans have to run