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