[07:33] <Saviq> o/
[07:36] <tsdgeos> Saviq: you better?
[07:41] <Saviq> tsdgeos, yeah, very much so, thanks
[07:41] <tsdgeos> :)
[07:42] <Saviq> I don't remember having been killed like that for a wee
[07:42] <Saviq> k
[08:09] <Saviq> dednick, hey, you been able to reproduce bug #1436982 ?
[08:44] <dednick> Saviq: hey. haven't tried yet. busy with the AP tests for sprint
[08:44] <Saviq> kk
[08:44] <dednick> I can give it a try though...
[08:44] <dednick> shouldnt take long
[08:45] <dednick> alkthough i seem to have lost my simcard :/
[08:48] <seb128> Saviq, hey, wb
[08:49] <Saviq> seb128, thanks
[08:49] <seb128> Saviq, bug #1435988 ... no, no idea, but I hit it a few time and I saw askubuntu and g+ comment from customers who hit it as well
[08:49] <seb128> it's quite confusing if you are used to unlock from that side
[08:49] <Saviq> agreed, not sure how to diagnose, unfortunately
[08:49] <seb128> Saviq, for sure there is a way to work on it out of that having steps to reproduce
[08:50] <seb128> incomplete seems a poor status
[08:50] <seb128> it's going to expire and autoclose
[08:50] <seb128> but it's a valid bu
[08:50] <seb128> bug
[08:50] <Saviq> here ya go, Confirmed
[08:50] <seb128> thanks
[08:57] <dednick> Saviq: can confirm. it's quite bad :(
[08:57] <dednick> seems to be whenever anything is added/removed from notifications.
[08:58] <Saviq> mhm, triaged it, will try in rtm too, feels like a regression
[09:11] <dednick> Saviq: do the autopilot tests always run in the same order?
[09:11] <Saviq> dednick, no
[09:11] <dednick> Saviq: why not?
[09:11] <Saviq> dednick, I think they're randomized on purpose
[09:11] <dednick> Saviq: ah. k
[09:11] <Saviq> dednick, because that could hide issues with the tests :)
[09:12] <dednick> Saviq: yeah. figured.
[09:13] <dednick> should probably run them twice in that case ;)
[09:13] <dednick> in smoke tests anyway
[09:18] <dednick> unity: anyone know if there's a way to gracefully exit phablet-test-run before it's finished?
[09:39] <Saviq> dednick, don't think there is
[09:39] <Saviq> dednick, it's just an autopilot call on the device, and I don't think AP can do anything smart on Ctrl+C or anything
[09:39] <Saviq> dednick, btw, can't seem to reproduce the clear-all lag on rtm, so likely a regression
[10:40] <Mirv> tsdgeos: hey, back to bug #1421009, I've just added a comment explaining various suites that 100% pass on mako without the PPA, and have failures with the PPA even with the AP fix. did you see the failures and do you have any insight where the timing (?) problems could lie? I'd ping brendand next again from QA but I believe it'd help them the more they know about how the system changes with the Qt patches.
[10:46] <tsdgeos> Mirv: it's hard to explain
[10:46] <tsdgeos> honestly of all the failures i've been able to find
[10:46] <tsdgeos> none actually seemed qdbus related
[10:47] <tsdgeos> which to me they seem like they've been there all the time
[10:47] <tsdgeos> just hidden by qdbus serializing lots of things on the main thread
[10:48] <tsdgeos> which is no longer happening with these patches
[10:48] <tsdgeos> so threads run more "freely"
[10:48] <tsdgeos> i'll write that in the bug
[10:50] <tsdgeos> now, i agree there's probably easier ways to fix the bug "for now"
[10:51] <tsdgeos> without that large patchset
[10:51] <Mirv> tsdgeos: indeed I can on a high level understand how threads flowing freely affects many things. but it seems that the failures we get on mako are not "this test is failing", but "tests fail randomly"
[10:51] <tsdgeos> if we know that it comes from the fact that libusermetrics is using dbus now
[10:51] <tsdgeos> Mirv: that's what threads have
[10:51] <tsdgeos> they always run in different order
[10:51] <Mirv> right, it seems it was introduced when the libusermetrics landing happened
[10:51] <tsdgeos> so stuff will fail randomly
[10:53] <tsdgeos> Mirv: you would not know which landing specifically?
[10:58] <Mirv> tsdgeos: https://launchpad.net/ubuntu/+source/libusermetrics/1.1.1+15.04.20150219-0ubuntu1 that landed on image #106 on 20150220: http://people.canonical.com/~ogra/touch-image-stats/106.changes
[10:59] <Mirv> tsdgeos: and it's not really that it started using dbus, maybe it started it using differently, now via click
[10:59] <Mirv> diff at http://launchpadlibrarian.net/198152771/libusermetrics_1.1.1%2B14.10.20141020-0ubuntu1_1.1.1%2B15.04.20150219-0ubuntu1.diff.gz
[10:59] <tsdgeos> sure
[12:52] <Saviq> mzanetti, here's what we talked about last week: bug #1438172
[13:00] <mzanetti> Saviq, ack, thanks
[13:49] <ricotz> Trevinho, hi :), did you see an issue like that on unity7/bamf? https://answers.launchpad.net/plank/+question/263909
[13:49] <tsdgeos> noone knows how to disable apparmor?
[13:50] <tsdgeos> i want it to make it stop unable to do my work
[13:50] <tsdgeos> it's annoying how underdocumented it is
[13:55] <seb128> tsdgeos, how does he stop you to do your work?
[13:55] <tsdgeos> seb128: i can't run autopilot tests
[13:56] <seb128> why not?
[13:56] <tsdgeos> because it complains about autopilot not being able to access dbus
[13:56] <seb128> if that's a specific bug we should fix it for everyone
[13:56] <tsdgeos> the bug is that one needs 154 commands to run autopilot tests it may seem :D
[13:56] <seb128> can you open at least a bug about it (if not done yet)?
[13:56] <seb128> tsdgeos, https://wiki.ubuntu.com/DebuggingApparmor
[13:57] <tsdgeos> seb128: phablet-config autopilot --dbus-probe enable as suggested by Mirv fixed it
[13:58] <seb128> good
[13:58] <Mirv> there are a bit too many things people need to remember when running AP tests
[13:59] <Mirv> I'm using ubuntu-ui-toolkit's test script, but ideally 'phablet-test-run' would unlock and lit the phone, enable dbus probe, checkout and update tests if necessary, install needed dependencies etc
[13:59] <seb128> yeah, the wrapper should default to that maybe, or be smart and detect when it's needed
[13:59] <greyback> +1
[14:17] <om26er> tsdgeos, Hi! some times on first boot my dash (...and all other scopes) looks like this: http://i.imgur.com/crDZ2G8.png
[14:18] <tsdgeos> lol
[14:18] <tsdgeos> the empty images is back
[14:18] <om26er> icons do get automatically loaded after like 2 minutes flat
[14:19] <tsdgeos> om26er: which image?
[14:19] <om26er> tsdgeos, vivid-proposed, latest.
[14:19] <om26er> r168
[14:22] <tsdgeos> om26er: is it possible that you have very bad network at that point?
[14:23] <om26er> tsdgeos, could be, my internet have not been too great.
[14:23] <om26er> tsdgeos, but why does it affect click scope
[14:23] <tsdgeos> because how quick loads async images
[14:24] <tsdgeos> once there's 8 http async images loading
[14:24] <tsdgeos> it won't load any other
[14:24] <tsdgeos> even if it's a local file
[14:24] <tsdgeos> which is stupid and i fixed it for Qt 5.6
[14:24] <tsdgeos> i could try to convince ourselves to run a patch not to do that in Qt 5.4
[14:24] <tsdgeos> i guess
[14:25] <tsdgeos> om26er: can you open a bug and i'll see what i can do to convince people to accept that patch and then we can see if it's really the fix or not?
[14:25] <om26er> tsdgeos, sure.
[14:39] <mhall119> w/w #unity
[14:42] <davmor2> tsdgeos: not meaning to be funny, but these are installed apps where the icon is in the desktop file so why would BB speed matter at all?  It should fetch from local and not touch the net at all surely?
[14:42] <tsdgeos> davmor2: you may want to read the explanation i already gave
[14:43] <davmor2> tsdgeos: ah yeap got it
[17:43] <mzanetti> Saviq, https://code.launchpad.net/~mzanetti/unity8/fix-launcher-losing-apps/+merge/254613
[17:47] <Saviq> mzanetti, tx!