[08:15] <tsdgeos> Mirv: https://codereview.qt-project.org/#/c/110325/ has been updated, but not with any crucial bits i think, may leave the rebuild for final in case we accept it
[08:17]  * Mirv context switches from qtdeclarative to qtbase
[08:17] <Mirv> tsdgeos: ok.
[08:18] <tsdgeos> Mirv: sorry :D qtdeclarative one for regexp was merged upstream and Saviq and me checked yesterday it seems to fix the issue we were having with it
[08:20] <Mirv> tsdgeos: yes, it's in 004 now, I'd be happy to hear results from testing the PPA specifically (the armhf has also finished building with ~test1 version, even though the final build is still ongoing)
[08:24] <tsdgeos> ok
[09:04] <tsdgeos> Mirv: seems to be fine for me
[09:16] <Mirv> thanks!
[11:04] <Saviq> dednick, diff here looks busted https://code.launchpad.net/~nick-dedekind/unity8/desktop-app-focus/+merge/256287
[11:10] <tsdgeos> Cimi: how's the review of https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1442085 going?
[11:11] <tsdgeos> MacSlow: https://code.launchpad.net/~aacid/unity8/pot_file top approve?
[11:11] <Cimi> tsdgeos, I was wondering if we needed to fix qt 5.5/5.4.2 too there
[11:11] <tsdgeos> Cimi: we do
[11:11] <tsdgeos> Cimi: https://codereview.qt-project.org/#/c/110348/
[11:12] <Cimi> tsdgeos, so it was a regression in 5.4.2 ?
[11:12] <tsdgeos> no clue tbh
[11:12] <tsdgeos> may be a 5.4.2 regression
[11:12] <tsdgeos> or that somehow our 5.4 packages have something that make this work
[11:12] <tsdgeos> didn't feel like building 5.4.1 from upstream and checking
[11:12] <Saviq> MacSlow, crash of maliit-server and unity8-dash likely when they try and launch to unity8 that crashed on startup, your "process not found" error, too, I've not seen that hapen though
[11:13] <Cimi> tsdgeos, I don't know if we do 5.4.2 first ot 5.5, but if we do 5.4.2 we should have tests not to fail... a fix in the tests is not possible?
[11:13] <MacSlow> tsdgeos, generally yes... but why does autopilot/DBus crap out again on Jenkins?
[11:13] <Saviq> MacSlow, you should merge ~unity-team shellRotation branch into yours btw, there were quite a bit of conflicts
[11:13] <tsdgeos> MacSlow: good question :/
[11:14] <tsdgeos> Cimi: if we do 5.4.2 the tests will fail which is what they should be doing, no?
[11:14] <MacSlow> Saviq, I thought I did that yesterday... will double-check
[11:14] <Saviq> MacSlow, didn't know you did, that's fine then
[11:15] <Saviq> MacSlow, I'll tweak demo-stuff recipe configs so that it builds your branch instead
[11:15] <MacSlow> tsdgeos, looking at the log it fails with createPlatformOpenGLContext... some issue with Ubuntu-L.ttf ... ?
[11:15] <Saviq> MacSlow, tsdgeos, the jenkins failure seems to be a timeout
[11:15] <MacSlow> Saviq, I still want to check...
[11:15] <Cimi> tsdgeos, ah, so the visual itself is broken in 5.4.2
[11:15] <MacSlow> Saviq, tsdgeos: in that case I'm good to top-approve tsdgeos branch... I can hardly imagine the pot-file fixes to affect that :)
[11:16] <Cimi> tsdgeos, I thought visuals were fine, tests were failing
[11:16] <tsdgeos> Cimi: yes
[11:16] <Cimi> good then
[11:16] <Saviq> MacSlow, indeed
[11:16] <dednick> Saviq: yup. i know. fixing
[11:16] <MacSlow> tsdgeos, done
[11:17] <MacSlow> Saviq, doh... didn't merge with unity-team shellRotation branch... *sigh*
[11:18] <MacSlow> Saviq, so forget my alarm-bells for the moment :)
[11:18] <tsdgeos> Cimi: i.e. if we update to 5.4.2 there can be two things happening, 1 the tests break because the visuals break and then we need to patch 5.4.2 with my upstream patch (if accepted) or we do actually have some other patch in some place that fixes it too and then we're fine :D
[11:18] <Saviq> MacSlow, there were alarm bells? ;)
[11:19] <MacSlow> Saviq, maybe I used teh wrong term :)
[11:20] <Saviq> tsdgeos, I think our last release must've caused the timeouts in Jenkins
[11:20] <tsdgeos> may be :/
[11:20] <Saviq> tsdgeos, this is the first instance that took 2h40 http://s-jenkins.ubuntu-ci:8080/job/unity8-ci/5534/console
[11:20] <tsdgeos> there's more than one thing failing
[11:20] <tsdgeos> thing -> job
[11:20] <Saviq> or actually
[11:21] <Saviq> that's 4d21h ago
[11:21] <Saviq> so before the last release
[11:21] <tsdgeos> where do you check how much it took
[11:21] <tsdgeos> ?
[11:22] <Saviq> http://s-jenkins.ubuntu-ci:8080/job/unity8-ci/5543/
[11:22] <Saviq> top right
[11:22] <Saviq> or https://jenkins.qa.ubuntu.com/job/unity8-ci/5546/ for the public instance
[11:22] <tsdgeos> i have how we haven't been able to convince QA people to install the timestamp extension :/
[11:22] <tsdgeos> s/have/hate
[11:23] <Saviq> tsdgeos, vote https://trello.com/c/f1V9Y5Gj/213-timestamps-on-all-ci-logs up if you can ;)
[11:24] <tsdgeos> so we went from 1:41 to 2:40 ?
[11:24] <tsdgeos> no voting power
[11:24] <Saviq> tsdgeos, well, it times out at 2:40
[11:25] <Saviq> tsdgeos, I mean the AP runner times out after 120 mins
[11:25] <Saviq> http://s-jenkins.ubuntu-ci:8080/job/generic-deb-autopilot-runner-vivid-mako/1929/console
[11:25] <tsdgeos> right
[11:26] <Saviq> tsdgeos, I'm calling that's actually bug #1421009
[11:26] <tsdgeos> may be
[11:26] <Saviq> AP complains about no reply on dbus straight after launching unity8
[11:26] <Saviq> must be that
[11:27] <tsdgeos> that or the other bug i fixed in ap
[11:27] <tsdgeos> think it's unreleased yet
[11:27] <Saviq> tsdgeos, it is https://launchpad.net/ubuntu/+source/autopilot/1.5.0+15.04.20150408-0ubuntu1
[11:27] <tsdgeos> https://code.launchpad.net/~aacid/autopilot/dbus_search_no_seen_connections/+merge/254109
[11:28] <Saviq> yeah that's there since last week
[11:29] <Cimi> tsdgeos, why that change in widgetData assignment after oncompleted?
[11:30] <tsdgeos> Cimi: because is whattriggets the bug
[11:31] <Cimi> tsdgeos, ah so if the data changes after the component was created the layout gets confused
[11:31] <Cimi> I get that
[11:31] <tsdgeos> Saviq: those autopilot releases are confusing
[11:31] <MacSlow> Saviq, last time I merged with unity-team/shellRotation was on Friday... and I'm missing the merge with trunk.
[11:32] <MacSlow> Saviq, so doing that now
[11:33] <Saviq> tsdgeos, I agree, train really helped with obviousness of what's released and what's not
[12:22] <dandrader> mzanetti, is https://code.launchpad.net/~dandrader/unity8/ddaImprovements/+merge/255896 ok for you now?
[12:24] <dandrader> tsdgeos, you need to review  https://code.launchpad.net/~dandrader/unity8/ddaImprovements/+merge/255896  again as I added a bunch of new stuff.
[12:24] <dandrader> tsdgeos, mostly API grooming, moving code around
[12:33] <mzanetti> dandrader, from an API point of view, I think yes
[12:35] <dandrader> mzanetti, can I get a review from you then? Not the full code review, as tsdgeos was doing that. could be review a type like "API and manual test"
[12:36] <tsdgeos> dandrader: i can have a look yes
[12:36] <mzanetti> ah ok. tsdgeos, you already ok with the code etc?
[12:36] <mzanetti> I'll give it a test too then
[12:36] <tsdgeos> mzanetti: i was fine with the "old" code
[12:36] <tsdgeos> not sure how much it has changed
[12:36] <mzanetti> right... I don't think it change a whole lot, but yeah. let's give it a check
[12:39] <mzanetti> dandrader, looks like a lot of jenkins failures
[12:39] <mzanetti> all related to dragging
[12:40] <dandrader> mzanetti, you mean autopilot?
[12:41] <mzanetti> dandrader, qmltests
[12:41] <mzanetti> dandrader, https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-vivid/701/
[12:41] <dandrader> mzanetti, ah, found them now
[12:41] <tsdgeos> ah yeah i think that's why i didn't review last time i went over it
[12:50] <Saviq> Cimi, when you're free, bug #1330959 would be a nice fix now the shape can do it
[12:50] <mzanetti> dandrader, interestingly the right edge is "smooth as silk" indeed, but the launcher seems jumpy now :)
[12:51] <dandrader> oh boy
[12:51] <mzanetti> still good enough I guess
[12:51] <mzanetti> wouldn't block on it I think
[12:52] <mzanetti> it's really only when you intentionally try to get the slowest possible speed that is still recognized as a drag
[12:53] <tsdgeos> elopio: do you think you're getting https://code.launchpad.net/~canonical-platform-qa/ubuntu-ui-toolkit/fix1401517-overwrite_swipe_borders/+merge/248986 in soon?
[12:53] <tsdgeos> asking to know how "urgent" is to review https://code.launchpad.net/~canonical-platform-qa/unity8/click_item_with_swipe/+merge/245051 that seems to depend on it
[12:55] <Cimi> Saviq, I was having a look at the recency in the spread, but I can do this easily probably
[12:56] <Saviq> Cimi, as you wish
[12:56] <mzanetti> dandrader, do we still have something like dragArea.status == Undecided?
[12:56] <mzanetti> dandrader, I think that's the issue. the launcher should be visible during that state too
[12:58] <mzanetti> dandrader, also from an API point of view I guess having a property "pressed" in addition to the "dragging" one would make sense I think
[12:59] <dandrader> mzanetti, no there's no "dragArea.status == Undecided" in the public API
[12:59] <dandrader> mzanetti, but now touchX, touchY etc will only move once the gesture is recognized
[13:00] <dandrader> mzanetti, and touchX,touchY,etc will move in a smooth way, instead of jumping to the actual touch position
[13:00] <mzanetti> right.. wonder why the launcher appears too late then
[13:01] <dandrader> mzanetti, wider drag threshold most likelly
[13:01] <mzanetti> dandrader, also line 2820 in the diff makes me suspicious a bit
[13:02] <mzanetti> dandrader, so the idea from design was to show the launcher's shadow immediately when you touch, but only bring in the launcher when actually dragging
[13:02] <mzanetti> dandrader, so having a "pressed" property that is true when a touch is there, but no gesture recognized would get us that I think.
[13:03] <mzanetti> like: pressed && !dragging == Undecided
[13:07] <dandrader> mzanetti, ok
[13:59] <elopio> tsdgeos: not getting it too soon. I've put it back to work in progress.
[13:59] <tsdgeos> ok
[14:55] <tsdgeos> Mirv: tried the new qt with the patch that was supposed to fix kuniqueapplication, it doesn't
[15:07] <Saviq> dednick, desktop-app-focus diff still looks very much b0rked, is it based on something other than trunk?
[15:07] <Saviq> or is it supposed to be almost 2kloc
[15:07] <Saviq> ?
[15:08] <dednick> Saviq: i've added mocking for Utils plugin
[15:09] <dednick> and it's almost 1.2k ;)
[15:09] <Saviq> dednick, ah, please be more descriptive in commit msg :)
[15:14] <tsdgeos> dednick: you almost got me in https://code.launchpad.net/~nick-dedekind/unity8/1436982.message-freeze/+merge/255702 ;) https://code.launchpad.net/~nick-dedekind/unity8/1436982.message-freeze/+merge/255702/comments/638192
[15:15] <dednick> tsdgeos: : woops :)
[15:16] <dednick> copy paste is my enemy
[15:16] <dednick> but couldn't live without it
[15:18] <dednick> guess i should add tests for those...
[15:28] <tsdgeos> dednick: also i'm kind of confused as to why https://code.launchpad.net/~nick-dedekind/unity8/1436982.message-freeze/+merge/255702 fixes the said bug
[15:28] <tsdgeos> which property is being updated on pressing clera all?
[15:30] <dednick> tsdgeos: i believe it's a property on the org.freedesktop.Accounts.User interface. There is only a "Changed" signal, so any property that is altered causes the maybeChanged slot to be called.
[15:30] <dednick> tsdgeos: i'm guessing it's XHasMessages
[15:31] <dednick> it's a bit of a shite interface.
[15:32] <dednick> well, in the sense that it doesn't tell you what's changed.
[15:32] <tsdgeos> yeah
[15:32] <tsdgeos> i can see
[15:32] <Saviq> dednick, tsdgeos, looks like what mzanetti was fighting on the launcher?
[15:33] <kapiteined> Saviq: did you see i was able to reproduce the screen rotate lock bug?
[15:33] <mzanetti> erm, wat?
[15:33] <Saviq> mzanetti, lag in launcher
[15:33] <mzanetti> ah
[15:33] <dednick> Saviq: could be. i think he put an async call in there
[15:33] <Saviq> mzanetti, due to AS
[15:33] <Saviq> kapiteined, not yet
[15:33] <mzanetti> yeah... changing one of the builtin properties causes *everything* to update
[15:34] <kapiteined> ok, take your time, it was just a heads  up.
[15:34] <dednick> maybe worth looking into fixing underlying issue (ie Changed(propertyName)). assuming it's safe to do that.
[15:35] <mzanetti> dednick, I had a chat with mterry about that... proper fix would probably be to patch accountsservice
[15:35] <mzanetti> and yes, we're not exactly sure what else relies on the general changed() signal. but sure, we could just not use that ourselves
[15:36] <mzanetti> dednick, where do you see the issue?
[15:36] <dednick> mzanetti: clearing or adding a message in indicators
[15:37] <dednick> calls the maybeChanged, which refreshes background as an async call.
[15:37] <dednick> which can take ages for some reason
[15:37] <dednick> *as an sync call.
[15:38] <mzanetti> dednick, yeah, exactly what I had in launcher drag'n'drop. this is what I did: http://bazaar.launchpad.net/~unity-team/unity8/trunk/revision/1678
[15:40] <dednick> mzanetti: right. i've changed the getUserProperty to async for updates.
[16:27] <Mirv> tsdgeos: ok :(