[09:19] * tsdgeos looks at dbus and asks it why so much locking [09:19] http://paste.ubuntu.com/10425178/ [09:39] tsdgeos, multiple locks get you a discount on home insurance, maybe that? [09:40] CE 0x7f506c00fa10 0 [09:40] QDBusConnection: warning: blocking call took a long time (803 ms, max for this thread is 500 ms) to service "com.canonical.Thumbnailer" path "/com/canonical/Thumbnailer" interface "com.canonical.Thumbnailer" member "GetArtistArt" [09:40] CE2 0x7f506c00fa10 0 801 [09:40] Saviq: there's a hidden joke in there i didn't get i'd say :D [09:41] tsdgeos, nvm ;) [10:03] preliminary analisis, it's hard to fix :D [10:03] qt likes doing it's dbus on the main thread it seems [10:03] so if you do a sync call from a thread it still blocks the main thread [10:03] need to verify [10:04] s/it's/its [10:41] tsdgeos, yay :/ [10:49] mzanetti, tsdgeos, about the one failing autopilot test, if you have enough items in the launcher for it to start collapsing, one of the tests will fail, could that have been your issue? [10:50] wasn't launcher related as far as i remember [10:50] well, it's not a launcher-related test that fails [10:50] it was test_click_app_icon_on_dash_must_focus_it IIRC [10:58] then this is the one that mzanetti had failing afair [10:58] re (was in a meeting) [10:59] that was my failing one: test_get_applications_should_return_correct_applications [10:59] ok, different one, then [11:00] ah [11:00] bad memory :D [11:27] greyback, shall I land the two top-approved branches for qtmir? [11:28] Saviq: lp:~gerboland/qtmir/fix-lifecycle-exempt-keeps-wakelock is safe to land. The other one I think requires some unity8 changes on desktop (mouse != touch any more) [11:29] greyback, ack === MacSlow is now known as MacSlow|lunch === alan_g is now known as alan_g|lunch === MacSlow|lunch is now known as MacSlow [13:41] mterry, hey, not sure if you saw - I can confirm jibel's wizard-interrupts bug [13:42] Saviq, I did see! Bummer. I couldn't reproduce when I tried yesterday, but will try again, after some MIR stuff [13:42] Saviq, I don't *think* it's the dash stealing focus, because I think we ignore the dash when killing the wizard on a focus [13:43] Saviq, but will double check [13:43] kk [13:58] mzanetti, yo. whats the best place to download unity8 with the inprogress window management features ? [13:58] om26er, vivid silo 0 has a bit more than vivid itself [13:59] Saviq, so vivid is a must ? I can't try on 14.10 ? [13:59] Saviq, also just apt-get install unity8 ? [13:59] om26er, we can't afford to backport everything to stable [14:00] om26er, `citrain host-upgrade 0` more like [14:00] om26er, but yeah, vivid is the only thing we've tested with === alan_g|lunch is now known as alan_g [14:17] hmm hmm [14:18] dandrader, "/usr/bin/ld: cannot find -llightdm-qt5-2", rings a bell? [14:18] Saviq, no, why you ask? [14:18] dandrader, that's me trying to build http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=landing-019 locally [14:19] dandrader, and I remember something similar initially after your lightdm mock refactor [14:25] * Saviq tries trunk [14:25] ok yeah, trunk doesn't build either [14:26] it's probably ninja or ccache :/ [14:33] ok, so a missing depends between targets it must be === dandrader is now known as dandrader|afk [14:40] Saviq, and in that wizard-disappears bug, you don't see the greeter either? It goes right to the dash? [14:40] mterry, correct [14:40] Saviq, that's super werid [14:41] mterry, reproduced on both mako and arale, too [14:41] Saviq, is the factory reset important, or can it happen after a normal flash? [14:41] mterry, it happened after wipe for me [14:41] oh you say bootstrapping/wiping works [14:42] Saviq, is picking "French" part of the repro steps? [14:42] mterry, "Polish" in my case, but might be the thing [14:42] mterry, like that might be the thing that triggers a restart of services [14:42] Saviq, yeah [14:43] Saviq, and out of curiousity, what is your SIM setup at the time? [14:43] (like slots, locked, etc) [14:45] mterry, none [14:45] Saviq, OK (SIM page is next, thought maybe that was involved === dandrader|afk is now known as dandrader [14:55] Saviq, just got it! Yeah, it does feel a lot like the dash is getting focused, killing the wizard [14:55] mterry, looks like it from the console log as well [14:57] Saviq, you mean you see the dash being launched a second time? [14:57] Yeah, I see that too [15:45] greyback, how do I verify your qtmir wakelock fix? [15:47] Saviq: start music app, play a song, blank the screen, run "sudo powerd-cli list" and verify the only wakelock held is pulseaudio's [15:49] greyback, btw, we could use a better name than "active" there ;) [15:51] the concept will migrate out of qtmir eventually [15:51] greyback, in any case, doesn't seem to work [15:52] what doesn't? [15:52] greyback, permanent "active" lock held when music is running [15:52] by pulseaudio? [15:52] without my patch, there would be 2 locks, one by shell, one by PA [15:52] greyback, not playing yet [15:53] greyback, just launched music, locked screen [15:53] that should not be the case [15:53] greyback, goes away when I put music in background [15:54] greyback, that's the silo http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=landing-019 [15:57] brb, testing desktop fixes [16:01] Saviq: hmm you're right, wtf [16:03] my patch releases it ok, but something re-acquires another one [16:15] greyback, FWIW it seems to be qtmir still, as the name is the same [16:15] Saviq: it is, was my fail, I'm just testing my fix now [16:15] kk [16:15] gonna test first thing tomorrow then [16:27] greyback, do you know what's holding it from getting merged? https://code.launchpad.net/~mir-team/qtubuntu/port-to-mirclient/+merge/245164 [16:27] dandrader: on desktop, indicators are not reponding to mouse input events any more [16:28] we may need to add MouseAreas where DirectionalDragAreas are, to do something sensible. [16:36] greyback, ermm... what does it have to do with this branch? [16:37] dandrader: it breaks indicators [16:37] try it and see [16:37] greyback, you know why? it's not supposed to cause any behavioral changes... [16:38] dandrader: I didn't look closely into it, but my guess was that DDA only listens for touch events, not mouse events [16:40] greyback, but this qtubuntu branch is meant to make qtubuntu bypass papi and use mirclient directly.... [16:40] no change how input events are handled... or maybe I'm missing something [16:40] dandrader: oh sorry, I mis-read the name. I thought it was the qtmir branch you were mentioning [16:41] no there's nothing stopping the qtubuntu branch from landing, other than me liking to land it with the qtmir one [16:41] greyback, it can't be landed by itself? [16:41] greyback, along with the papi one, that is [16:42] it could, but testing it in the silo will not be that useful, as the new code-paths won't be exercised until the qtmir bits are in there too, no? [16:42] Trevinho, for bug 1425362, is there an easy way to get the same env as you? Make a VM, install unity8-desktop-session-mir, set lightdm.conf.d to use unity sessions and then log into unity8? [16:42] bug 1425362 in unity8 (Ubuntu) "unity8 crashed with SIGSEGV in QLightDM::GreeterImpl::authenticateWithPam() when logging in" [Medium,New] https://launchpad.net/bugs/1425362 [16:43] greyback, ah, you mean the mouse input handling part will be left unused until the qtmir branch lands [16:44] dandrader: yeah [16:44] make sense [16:44] makes [16:45] greyback, I think mzanetti made a branch that sprinkles some MouseAreas around to make controls usable with mouse input [16:45] dandrader: indeed, think we'll grab that [16:47] greyback, so we could get that branch + qtmir port-to-event-2.0 + qtubuntu's use-mirclient + the papi one and land them now? [16:47] dandrader: I think so. Want to look after that? [16:47] greyback, I would. but I don't have landing super powers. What can I do? [16:47] I'm still stuck in usc/mir [16:48] dandrader: get the branches ready, then ping me and I can request a silo [16:48] greyback, ok [16:49] greyback, dandrader: yes. (was in a meeting) [16:49] mzanetti, so is https://code.launchpad.net/~mzanetti/unity8/indicators-mouse/+merge/250429 still WIP? [16:49] dandrader, yeah, that's really just a hack for silo0 [16:50] dandrader, I think this requires design input [16:50] mzanetti, well, it serves to avoid regressing when landing qtmir's port-to-event-2.0 [16:51] dandrader, ah, I see... [16:51] will also need to see if we need a FFe or not [16:51] ok well, I guess we can put it in then... it's quite simple anyways, just adds a MouseArea [16:52] but the whole topic requires design input and more work === dandrader is now known as dandrader|lunch === alan_g is now known as alan_g|EOD === dandrader|lunch is now known as dandrader === dandrader is now known as dandrader|afk [20:13] kgunn, et. al regarding this bug: https://bugs.launchpad.net/autopilot/+bug/1422797, I have a better idea what's happening with it, I'm just not sure what else autopilot can do in this situation [20:13] Launchpad bug 1422797 in Autopilot "Mir refuses the app to connect" [High,Incomplete] [20:14] The camera app is crashing and when autopilot attempts to stop the app it times out as ual-stop doesn't stop it within 10sec (due to the crashing/apport). [20:15] then the next couple of tests fail to launch the app again as ual fails to launch it (again, due to it still in the process of crashing( [20:15] As far as I can see autopilot is stopping/launching things as expected, unless I'm missing something? [20:16] veebers: but sounds like there is no time accounted for a crashing app.... [20:16] veebers: question... [20:16] if the camera app does not crash...is there a problem ? [20:16] kgunn: not that I'm aware of, I've been unable to reproduce, so relying on the logs from ci. [20:16] kgunn: I should have time later this morning to check that [20:17] veebers: i guess i'm asking, if the AP test is meant to catch problems, and the camera app crashes....that is a problem [20:17] kgunn: the suggestion is that ual should be doing the right thing too [20:17] but...if apport is running the whole system freezes (i've witenessed this as well) [20:18] kgunn: that's a good point, and perhaps a possible feature. [20:18] veebers: i guess i'm saying, while it'd be nice to run the remaining tests....technically, the AP caught the crash [20:18] and you can always find out what the remaining test results are, after you stop and fix the crash you found [20:19] you=proverbial you [20:20] kgunn: sure, so what makes sense in the event of a crash, should ap wait for apport to finish (if it's running), how long should it wait before continuing or doing something more heavy handed [20:20] veebers: yeah, i would argue wait...b/c engineers are gonna ask "did you get a crash file" :) [20:21] to try and debug th eproblem [20:21] kgunn: isn't a crash file generated anyway? [20:21] as for a time to wait...i've seen it run for what felt like a solid 10 seconds before.... [20:22] veebers: true...i guess it doesn't have to process it [20:22] kgunn: well, at the end of the test autopilot fires of an attempt to ual-stop the application and times out after 10 sec [20:22] also, when attempting to launch the app it gives it 10 to start successfully [20:23] so in the test log I reviewed, it appears there are 30+ seconds from failure to stop and the next test being able to start it again [20:23] veebers: i suppose there's always polling? is apport running ?....or diable apport processing like you say [20:23] ? [20:24] I don't think it's autopilots place to disable apport [20:24] veebers: yeah, then you gotta go with either longer waits or polling to see what's running [20:24] as to polling, how long makes sense to wait for apport, what if that goes bung too and then we have infinite wait [20:24] man...30+seconds...wow [20:24] veebers: does apport go bung ? [20:25] kgunn: Not sure, I haven't seen it personally , just thinking of things to consider :0) [20:25] imho, solve the first problem, worry about finding an infinite wait some other day :) [20:26] veebers: hopefully....we shou;dn't be having too many crashes...and when we do if apport hangs as well, i would hope that would be a very very very small amount of instances :) [20:26] yes, true [20:27] kgunn: so at this point, I don't think the linked bug is related to autopilot (ap just triggers it perhaps) and there should be a new bug assigned to autopilot related to doing when it detects the app under test has crashed [20:27] That way we can backlog it and get something done on it [20:27] i concur [20:28] veebers: if my concurrence helps in any way :) [20:28] kgunn: can I ask you to file that bug with your thoughts and expectations for it please? [20:28] it sure does [20:29] veebers: isn't this bill's bug ? [20:29] i don't own ual either [20:29] kgunn: oh perhaps, sorry we were talking about this the other day hence me bothering you, sorry ;-P [20:29] np [21:27] Is this a good place for questions about Unity8 or is that elsewhere? [21:46] Hi all, I am having getting unity to run after logging in. I just get my desktop background without any launcher or status bar [21:46] After checking the compiz logs I see that it failed to load opengl [21:47] any idea how I could fix this? === dandrader|afk is now known as dandrader [22:01] redlama42, yes, this is the place [22:03] dandrader: Whenever I try and log into a unity8-mir session lightdm just makes logging in anywhere impossible and I have to restart it. [22:03] dandrader: You know what's up? [22:05] redlama42, hmm, no. I very seldomly try out unity8 in a desktop/laptop machine. I'm almost always working with it in phones and tablets only [22:08] dandrader: Damn, thanks anyways.