[08:20] tsdgeos: Saviq: soo, DBus qtbase patches + switching-scopes qtdeclarative crash fix in vivid-021 [08:21] Mirv: can we get the qtdeclarative one in an rtm silo so that Pat can try it on his mako? [08:23] tsdgeos: yes already is, bug just updated [08:23] cool [08:48] Mirv, you rock ;) [09:11] Saviq: damn now i can't reproduce the lock even when erasing the qml cache that helped the other day [09:11] so can't really test if that silo helps at all [09:11] tsdgeos, I'm trying here too, let's see [09:24] tsdgeos, got it to lock [09:24] (without silo) [09:24] adb shell rm -R "~phablet/.cache/QML" && adb reboot [09:25] how many tries? [09:25] like 4 or 5 [09:25] i stopped at 8 [09:25] ok [09:28] i guess it's better if i install the silo and try to reproduce the lock [09:28] i'll try that [09:28] Saviq: you using mako or krillin? [09:28] tsdgeos, mako [09:29] i'll try krillin [09:29] since the bug was reported on krillin no? [09:29] or you think happens more often on mako? [09:31] tsdgeos, I've only ever tried on mako, but that's because I use it more for testing and such [09:42] Saviq: we had a script somewhere that swipped the greeter away, right? [09:42] or a dbus call or something [09:42] tsdgeos, ./tools/unlock-device [09:43] tsdgeos, but it reboots an such [09:44] tsdgeos, a bit of hackery on the script should help indeed [09:44] adb doesn't work if the device is locked [09:44] ha [09:45] wait there was a way to fix that [09:45] tsdgeos, yeah on krillin it doesn't [09:45] sudo touch /userdata/.adb_onlock [09:46] \o/ [09:55] Saviq: i settled for while [ true ]; do adb shell rm -R "~phablet/.cache/QML" && adb reboot && sleep 60 && adb shell "gdbus call --session --dest com.canonical.UnityGreeter --object-path / --method com.canonical.UnityGreeter.HideGreeter && echo Greeter unlocked"; done [09:55] will let it run for a while see what happens [10:06] tsdgeos, I've gone for while true; do adb shell rm -R "~phablet/.cache/QML"; ./tools/unlock-device || break; done [10:07] right, that should work better yes [10:07] well not better [10:07] but is less typing :D [10:10] if only nautilus wouldn't open a window per reboot [10:14] yeah :D [10:15] it does? [10:15] * larsu probably didn't get any context [10:22] larsu, MTP [10:22] larsu, we're rebooting the phone in a loop to see if a boot-deadlock is gone [10:22] larsu, so it's opening a window every time the device shows up, and never closes the previous one [10:23] Saviq: ah! Ya, I've been annoyed by that particular design decision as well :/ [10:24] it should probably reuse an existing window that was previously associated with that device [10:24] but it doesn't know that... [10:24] it should get to know ;) [10:25] because like it never moves away from the mtp share [10:25] definitely [10:25] even though the device is rebooting [10:25] oh weird. I thought it moves to ~ or so when a device disappears [10:36] larsu, https://owncloud.sawicz.net/index.php/s/0afe9e8a599ef8fef2f2a105e9db357d# [10:36] larsu, note how breadcrumb and title bar still say "Nexus 4", but no such device [10:36] ya. buggy [10:46] tsdgeos, 30-odd successful runs here, reflashing now to compare [10:47] Saviq: with silo? [10:47] tsdgeos, yeah, successful with silo [10:47] will run with pristine image now to see how it compares [10:47] same here [10:47] same here [11:14] tsdgeos, some 15 runs successful without the silo... not sure our testing method is legit [11:14] * Saviq goes back to manual reboot [11:14] yeah... [11:15] but the bug says that it was failing on dbus too [11:15] so the unlock should fail :& [11:16] oh yeah totally [11:16] just that it doesn't deadlock for some reason [11:25] elopio, bug #1434518 [11:25] bug 1434518 in unity8 (Ubuntu) "test_can_unlock_pin_screen broken under py3" [High,Triaged] https://launchpad.net/bugs/1434518 [11:29] tsdgeos, without silo, deadlock in 6 reboots, with a simple "adb shell rm -R "~phablet/.cache/QML" && adb reboot" [11:29] Saviq: weird [11:29] when/how do you detect the deadlock then? [11:29] you press the screen? [11:30] tsdgeos, I can see it [11:30] tsdgeos, I've only clock and date on screen [11:30] right [11:30] tsdgeos, no indicators or infographics [11:30] the rest is black-ish [11:30] yeah [11:30] and MTP complains [11:30] and gdbus reaches timeout [11:31] * Saviq gets silo [11:31] sorry i misled you trying to use the script :/ [11:31] nw [11:31] it was a good try, something must be causing it to not trigger [11:47] @unity: the current landing I'm looking at: http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=landing-030 any other MP I should put in there? [11:51] Saviq, the swipe-to-act visual-update was already part of an earlier landing-silo, right? [11:51] MacSlow, yeah, that's landed Wednesday [11:51] ok [12:05] Saviq, so autopilot tests in Jenkins are failing because they're using an outdated platform-api: "/usr/lib/arm-linux-gnueabihf/qt5/bin/qmlscene: symbol lookup error: /usr/lib/arm-linux-gnueabihf/qt5/plugins/platforms/libqpa-ubuntumirclient.so: undefined symbol: u_application_instance_get_mir_connection" [12:06] Saviq, what needs to happen for it to use the latest one? [12:08] MacSlow, you can top-approve https://code.launchpad.net/~dandrader/unity8/noRotatingRectInMakeTry/+merge/253513 now. Jenkins results are in. [12:09] dandrader, the phones need to get upgraded [12:09] dandrader, the runs today should be good [12:11] dandrader, done [12:11] MacSlow, thanks [12:11] dandrader, or qtubuntu needs to be rebuilt against the platform-api that just landed [12:13] tsdgeos, I'm calling it fixed, some 30 reboots, a wipe, no deadlock [12:13] Saviq: that seems great [12:13] Mirv, ↑ [12:13] so we land it? or? [12:14] good question, any progress upstream? [12:14] how much more testing we need to call it done :D [12:14] let me se [12:14] e [12:15] still not applied [12:15] thiago said he wanted to wait for alpha [12:15] and apply it after [12:15] alpha is now out, so i can reping him [12:15] would be nice [12:15] I can see a test failure on the first change [12:16] test failure where? [12:17] tsdgeos, https://codereview.qt-project.org/#/c/102762/ [12:17] it's ssl [12:17] kk [12:17] probably one of those days [12:17] were the test servers were down or something [12:18] dandrader, -ci jobs were stuck at image #127, should flash latest now [12:18] in case you need a re-run [12:18] Saviq, ok [12:27] pete-woods, hey, anything we need to tell you to release GPS for bug #1434379? we already tell you when scope becomes inactive (unfocused), right? [12:27] bug 1434379 in Canonical System Image "GPS always active when a scope that uses location is in the background " [High,Confirmed] https://launchpad.net/bugs/1434379 [12:27] oh yay huge selection handles [12:29] viel besser [12:36] tsdgeos: Saviq: I'm currently running AP:s on rtm, so the earliest I can land the vivid silo would be Monday anyway. but it's good if it's ok from your testing, I can add that to the spreadsheet. did you test the qtdeclarative fix too? [12:41] Mirv, sure, Monday's fine, tsdgeos will have to report on the crash fix [12:41] Saviq: hmm, I thought that was already fixed [12:42] pete-woods, sounds like you need some explaining time with rsalveti then :) [12:45] Saviq: the behaviour he described is intentional [12:45] I think [12:45] pete-woods, that it keeps GPS on when unfocused? [12:45] pete-woods, sounds unlikely [12:46] oh [12:46] yeah [12:46] just spotted that part [12:46] we need the UI to deactivate all scopes when the scopes aren't in view, really [12:47] Saviq: ok, tsdgeos to report on that. [13:01] Saviq: Mirv: actually Pat since he's the one that can repro, he said he'll test over weekend and report back [13:02] tsdgeos: he'll probably test only rtm though? although, it's the same patch of course so.. [13:02] tsdgeos, lp:~aacid/unity8/passphrase_kewboard <- what's a kewboard? :-D [13:02] dandrader: it's a cool keyboard! [13:02] i mean kewl! [13:03] :) === alan_g is now known as alan_g|lunch [13:36] pete-woods: what we fixed was when we move to a scope that doesn't use gps [13:37] pete-woods: this one I just found yesterday, when testing the overall power related fixes === facu is now known as Facu [13:52] rsalveti|afk: yes, I see this bug is different now. silly me assuming === alan_g|lunch is now known as alan_g === dandrader is now known as dandrader|afk === MacSlow is now known as MacSlow|lunch [14:20] Mirv: yaeh the patch is very low profile, to be honest i'm not really even sure it fixes the crash, but it's the only way i can think of it happening [14:46] Saviq: on it. === MacSlow|lunch is now known as MacSlow === dandrader|afk is now known as dandrader [16:28] tsdgeos, are getting failures like that? http://paste.ubuntu.com/10635830/ [16:28] tsdgeos, s/are/are you [16:28] dandrader: so i remmeber last time i run the tests if they were not under xvfb they seemed to fail [16:28] which is confusing [16:29] tsdgeos, wow, it does pass under xvfb... [16:29] may be worth investigating [16:30] tsdgeos, but this one fails under xvfb: http://paste.ubuntu.com/10635849/ [16:30] tsdgeos, do you get the same? [16:34] dandrader: was not failing ast time [16:34] let me check [16:35] tsdgeos, "ast time"? [16:35] last [16:41] Totals: 69 passed, 0 failed, 0 skipped, 0 blacklisted [16:41] ********* Finished testing of ListViewWithPageHeaderTest ********* [16:41] Built target xvfbtestListViewWithPageHeader [16:41] dandrader: ↑ [16:41] * tsdgeos has to go now [16:41] tty on monday [16:41] "works for me"(tm) === dandrader is now known as dandrader|afk === alan_g is now known as alan_g|EOW === dandrader|afk is now known as dandrader === dandrader is now known as dandrader|bbl === dandrader|bbl is now known as dandrader