=== duflu_ is now known as duflu [09:33] Mirv: i see you landed https://bugs.launchpad.net/ubuntu/+source/qtdeclarative-opensource-src/+bug/1431798 [09:33] Ubuntu bug 1431798 in qtdeclarative-opensource-src (Ubuntu) "unity8-dash crashed with signal 7 in QMutex::lock() when switching scopes" [Medium,In progress] [09:33] Mirv: did Pat confirm his crashes seem gone? [09:36] tsdgeos: yes he did, 3 days no crashes [09:37] Mirv: awesome, you landing it for vivid too? [09:37] tsdgeos: vivid testing still ongoing, and it's currently entangled with the qtbase dbus updates which I try to confirm if they regress or not. if the dbus patches regress I'll try landing qtdeclarative alone. [09:39] tsdgeos: I should know a bit more in 1-3h with my mako busy running the tests (like yesterday, and during the night..) [09:39] Mirv: ok :) [09:39] it's annoying that there are many kinds of things that halt the AP runs and need manual intervention === JMulholland_ is now known as JMulholland [10:25] mzanetti: how's the landing going? [10:25] tsdgeos, which landing? [10:26] mzanetti: silo 30 [10:26] is there something we have to do? [10:26] tsdgeos, "Packages built. Testing pass. QA needs to sign off. " [10:26] k [10:59] aaaaaaaaaand we're magically just down to either 0 or 1 autopilot test failing [10:59] https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/1708/ [11:00] https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/1704/ [11:18] tsdgeos: Saviq: the qtbase dbus patches seem to reliably regress autopilot testing, it's enough to run UITK AP and with/without is different. http://people.canonical.com/~tjyrinki/qt5/fail/ [11:18] I'm splitting out the qtbase to be able to land the qtdeclarative fix alone which doesn't regress [11:18] -> qtdeclarative now in 012 still, but qtbase (current build) moved to 018 [11:19] with qtbase update I'm getting min. 8 failures, with qtdeclarative update only (or archive version) I'm getting 0-2 [11:21] s/012/021/ for qtdeclarative [11:23] Mirv: interesting, so you're saying UITK autopilot fail more with the dbus patches? [11:23] in a relatively reliable way? [11:23] tsdgeos: yep, unfortunately, and at least some of the failing tests cite DBus [11:23] Mirv: which one? [11:24] tsdgeos: that one mako fail was a close one: 'assword' != 'password' [11:24] tsdgeos: I've those runs in those url:s and also two I did yesterday but thought something was wrong in my environment. I've two successful runs with archive versions and now one with qtdeclarative only, so it seems clear [11:24] tsdgeos: http://people.canonical.com/~tjyrinki/qt5/fail/ap-2015_03_24-08_44_32-ubuntuuitoolkit-1-021.tests [11:24] greyback_: yep, i could actually get that one to fail locally last time i tried [11:25] tsdgeos: the password entry box either not getting input focus quick enough, or AP typing just a little too quickly after the edge swipe [11:25] greyback_: probably [11:26] Mirv: actually the other day i realized we were missing 2 patches from the series, could you add them? [11:26] https://codereview.qt-project.org/#/c/103739/ [11:26] https://codereview.qt-project.org/#/c/103740/ [11:26] just in case [11:26] tsdgeos: some grepping http://pastebin.ubuntu.com/10668300/ [11:27] Mirv: both runs are with the patches, right? [11:27] tsdgeos: yes, since without patches no errors (or 1-2 at most) [11:27] k [11:28] tsdgeos: ok please copy-paste them to the bug report too. I can push a new build and hopefully have testing results with the new patches during tomorrow. [11:30] if I get the qtdeclarative tested during today [11:36] Mirv: thanks :) [11:52] tsdgeos: aware of any recent patch in qt5.4 that would improve dash performance? [11:54] greyback_: not really why? [11:55] greyback_: i fixed a bug in the thumbnailer that may help with snapiness [11:55] tsdgeos: alf has been testing a mir change, and he noticed dash suddenly performing better than before [11:55] we were pondering if some recent qt change might be the reason [11:56] not that i know [11:56] I couldn't see anything the the changelog either [11:56] * greyback_ scratches head [11:56] greyback_: as said could be the thumbnailer [11:56] it blocked the main thread a lot [11:56] tsdgeos: true [11:56] or could just be placebo :D [11:57] tsdgeos: oh while you're here, I see a few dbus-related patches going in, do they help in having dbus not on the main thread? [11:58] greyback_: they make dbus stuff be handler more in the thread dbus stuff is happening [11:58] and not in the main thread [11:59] they won't offload stuff from the main thread if you're doing it in the main thread [11:59] not sure i'm making sense [11:59] sure, if you have the dbus stuff in the main thread, it'll stay in the main thread [11:59] but if you have it in a different thread, I recall that a sync method call would block the main thread sometimes [12:00] or something like that [12:01] right [12:01] that's supposed to be improved/fixed [12:01] sweet [12:15] greyback_: but then Mirv shows we have regressions in the uitk autopilot because of those [12:16] tsdgeos: ah boo [12:16] so either they are not totally good or those AP tests need some work [12:16] it may have been AP relied on the old blocking behaviour [12:27] greyback_: right [12:27] needs investigation === alan_g is now known as alan_g|lunch [13:23] mzanetti, still waiting for the review of https://code.launchpad.net/~dandrader/unity8/mouseClickSwitchesSurfaceFocus/+merge/252745 === alan_g|lunch is now known as alan_g [14:11] kgunn, Hi! can you tell when can I have my shell rotating ? [14:12] om26er: well...we've got 2 hurdles right now [14:13] 1 vivid is on uber lockdown for our migration from rtm-14.09 to vivid (e.g. no new features for phone) [14:13] ...so until i have a place to land it, it's kinda moot [14:13] 2 is we're still struggling with the AP test for it, but we're on the sprint for QA this week [14:13] since we pleaded to them for some help [14:14] so..hopefully the "calvary has arrived" and by the time we finish the AP test...we'll have a landing zone for ti [14:14] oops/ti/it [14:14] kgunn, hmm that's number 2 on must-have list, number 1 being faster app launch time. Which is very slow right now. [14:15] * kgunn slightly confused on mixing 1&2's [14:15] om26er: what must-have-list are you talking about ? [14:15] yours? or someone else's ? [14:16] kgunn, thats mine :) [14:16] :) [14:16] om26er: is the slow app launch native? or webapp ? [14:16] curious [14:17] kgunn, yes native apps [14:18] om26er: is that pre-existing or new (a-la latest Qt or something?) [14:18] kgunn, its old issue [14:18] mmmkk === dandrader is now known as dandrader|afk === om26er_ is now known as om26er [14:34] Saviq, I am seeing a unity8 crash, quite frequent on vivid. [14:34] logs unfortunately are seems useless here: https://errors.ubuntu.com/oops/456d67fa-d232-11e4-8df8-fa163e4aaad4 [14:34] Saviq: he's out sick [14:34] om26er: can't access that url :S [14:35] the url has nothing useful [14:35] ah now [14:35] seems like apport didn't collect a dump, so no bt [14:35] nothing indeed [14:35] tsdgeos, I have the .crash file, can you make a use out of that ? [14:36] om26er: if it's complete yes [14:36] om26er: post it somewhere [14:37] om26er, does it contain the dump? [14:37] or did apport fail to collect it? === dandrader|afk is now known as dandrader [14:39] seb128, seems not, it looks useless [14:39] right [14:39] if you can easily trigger it, maybe try to attach gdb from an adb session and trigger the segfault [14:39] tsdgeos, I sent the email, but its useless [14:39] k [14:40] seb128, thats the big problem, its random, need to look closer [14:40] om26er, well, keep gdb on it for some hours while working, maybe you get it [16:07] landed stuff \o/ === dandrader is now known as dandrader|afk === balloons is now known as iwishiwasascoola === iwishiwasascoola is now known as balloons === dandrader|afk is now known as dandrader [17:40] hey, is there a known issue that sometime right swipe to unlock stops working? [17:46] opened https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1435988 [17:46] Ubuntu bug 1435988 in unity8 (Ubuntu) "sometime right edge swip stop working on the lockscreen" [Undecided,New] [17:46] mterry, ^ not sure if that's one for you? [17:47] seb128, probably? [17:48] mterry, let me know if any log of debug info would be useful [17:48] seb128, I doubt we log anything useful in that case :-/ [17:49] hum, k === alan_g is now known as alan_g|EOD === dandrader is now known as dandrader|afk === greyback__ is now known as greyback === dandrader|afk is now known as dandrader