[08:42] <tsdgeos> pstolowski: Saviq: should the unity-scope-tool package depend on pkg-config and libunity-scopes-dev ?
[08:42] <tsdgeos> tools/registry-tracker.cpp is invoking pkg-config
[08:42] <Saviq> tsdgeos, then sounds like it should
[08:43] <tsdgeos> k, will prepare a MR
[08:43] <Saviq> tsdgeos, but why on libunity-scopes-dev?
[08:43] <tsdgeos> Saviq: because it's the thing it's pkg-config'ing
[08:43] <tsdgeos>         arguments << "--variable=scopesdir";
[08:43] <tsdgeos>         arguments << "libunity-scopes";
[08:43] <tsdgeos>         pkg_config.start("pkg-config", arguments);
[08:45] <pstolowski> otp
[08:46] <Saviq> tsdgeos, ugh, shouldn't it be doing that build time?
[08:46] <tsdgeos> don't know :D
[08:49] <Mirv> Qt 5.4.1 breaking stuff!!11 ...not really, seems pretty smooth, but qtmir test is broken probably because a dummy qtsensors plugin went away bug #1427529
[08:49] <Saviq> Mirv, thanks
[08:49] <Mirv> tsdgeos: if you want to give a whirl, the PPA is now usable on phone
[08:50] <Mirv> Saviq: I've assumed you're in some sort of deadline limbo lately, but I guess now actually you can be reached possibly again :)
[08:51] <Saviq> Mirv, oh? nah, I was just in CPT the week before last
[08:57] <Mirv> Saviq: ok, good that you're available for my eternal Qt pings too!
[08:57] <Saviq> :)
[08:57] <Saviq> brb
[08:57] <Mirv> 5.4.1 should be smooth, of course, but you never know if we adjusted to some .0 bug already too hard.
[09:08] <Saviq> seb128, hey, have you tried running the unity8 session recently? it started locking up before I can log in here :/
[09:08] <Saviq> @unity ↑
[09:08]  * Saviq grabs dbg symbols
[09:08] <seb128> Saviq, hey
[09:08] <seb128> Saviq, likely https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1422835
[09:08] <Saviq> hmm right
[09:09] <tsdgeos> didn't that land?
[09:09] <seb128> Saviq, there is an uitk fix in staging for 10 days, but uitk landings... no comment...
[09:09] <Saviq> tsdgeos, it got committed to staging, not released
[09:09] <seb128> tsdgeos, no, there has been no uitk landing since mid-feb
[09:09] <tsdgeos> Saviq: show the backtrace, that one is very disctintive
[09:12] <Saviq> tsdgeos, comin' right up
[09:15] <Saviq> tsdgeos, http://pastebin.ubuntu.com/10513059/
[09:16] <tsdgeos> hmmm
[09:17] <tsdgeos> doens't look like it i'd say
[09:17] <Saviq> yeah
[09:17]  * Saviq gets more symbols
[09:18] <tsdgeos> Saviq: are we blocked on pam?
[09:18] <Saviq> tsdgeos, ah, there's a branch from mterry that might be helping there
[09:18] <Saviq> although that was a crash
[09:18] <Saviq> https://code.launchpad.net/~mterry/unity8/cancel-pam-harder/+merge/251174
[09:18]  * Saviq tries anyway
[09:19] <tsdgeos> don't know saw two threads in pam-like waits
[09:19] <Saviq> yeah
[09:43] <pstolowski> tsdgeos, +1 for adding these dependencies to unity-scope-tool; i can't find good explanation for the pkg-config invocation there, could very well be determined at build-time; perhaps mhr3 had a reason to do it that way back then
[10:16] <tsdgeos> Saviq: pstolowski: https://code.launchpad.net/~aacid/unity8/scope-tool-dependencies/+merge/251573
[10:25] <pstolowski> tsdgeos, looks good; is # comment allowed in debian/control?
[10:26] <tsdgeos> pstolowski: yep, there's others and it did build :D
[10:27] <pstolowski> cool :)
[10:47] <tsdgeos> greyback: did we release the fix for the startTimer in another thread thing?
[10:48] <tsdgeos> i think we did
[10:48] <tsdgeos> i'm getting some others when launching apps
[10:48] <greyback> tsdgeos: yep we did
[10:48] <tsdgeos> but on the app process not in unity8
[10:48] <tsdgeos> so may be different issue
[10:48] <greyback> yeah
[10:49] <greyback> I guess it wasn't just qtmir that was making that mistake
[11:05] <Saviq> dandrader, hey, here's the mirevent 2.0 silo http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=landing-006
[11:06] <Saviq> dandrader, I had some doubts about package dependencies there, added comments to the relevant MPs
[11:07] <Saviq> /food
[11:10] <dandrader> Saviq, ok
[11:10] <dandrader> Saviq, I saw your comments yesterday. racarr solved them. Unless you made new ones today
[11:53] <tsdgeos> pete-woods: can you review/top-approve https://code.launchpad.net/~aacid/thumbnailer/fix_dbus_blocking/+merge/251065 ?
[11:54] <pete-woods> tsdgeos: it seems like a bunch of different people are trying to fix the same bug here
[11:54] <tsdgeos> well the bug is assigned to me :D
[11:54] <tsdgeos> pete-woods: who else do you know is trying to fix it?
[11:54] <pete-woods> tsdgeos: could you liaise with michi about this? he's not the owner of thumbnailer
[11:55] <pete-woods> tsdgeos: afaik kaleo is doing something funky with some new image provider codepath
[11:55] <tsdgeos> pete-woods: s/not/now ?
[11:55] <tsdgeos> pete-woods: oh yeah Kaleo patch is crazy :)
[11:55] <pete-woods> tsdgeos: correct :)
[11:55] <pete-woods> tsdgeos: also michi wants to fix this at a lower level inside the thumbnailer service
[11:56] <tsdgeos> and at the "wrong" level too imho, https://codereview.qt-project.org/#/c/107427/ is a better fix
[11:56] <tsdgeos> pete-woods: he can't fix that at the lower level
[11:56] <tsdgeos> at least not this bug
[11:56] <pete-woods> tsdgeos: I guess I'm just saying, I think we should talk to everyone involved
[11:56] <tsdgeos> i mean this bug is the provider is broken
[11:56] <pete-woods> so we get the right solution, which could well be yours
[11:56] <tsdgeos> so it blocks the main ui
[11:56] <tsdgeos> you can make it faster and what not
[11:56] <tsdgeos> but still should not block the main ui
[11:56] <pete-woods> tsdgeos: I'm not saying you're wrong. I just want only one person to fix this thing
[11:57] <pete-woods> instead of 3 competing and probably interfering patches
[11:57] <tsdgeos> sure
[11:57] <pete-woods> your fix is appealing to me, because I actually understand the code :)
[11:57] <tsdgeos> i added michi to https://code.launchpad.net/~aacid/thumbnailer/fix_dbus_blocking/+merge/251065
[11:58] <pete-woods> thanks!
[11:58] <pete-woods> if this is all that is required to fix the overall issue, that will save michi from diving down a large rabbit hole
[11:58] <tsdgeos> this fixes "a lot"
[11:59] <tsdgeos> of course doesn't fix the a slow thiumbnail "blocking" a quick one from appearing
[11:59] <tsdgeos> since there's still only one thread for thumbnails
[11:59] <tsdgeos> that'd be either Kaleo's or my patch
[11:59] <tsdgeos> but it's not "the bug" itself
[11:59] <pete-woods> right, so you don't paralellise, but at least you don't block
[11:59] <tsdgeos> it's just a way to make it better
[12:01] <pete-woods> I think it's really worth you having a conversation with michi to explain what exactly the main issue is, the details of how image providers work, etc. otherwise I worry he may do a load of complicated work with possibly little benefit
[12:01] <tsdgeos> pete-woods: do you think it's best if i mail him? not sure if he'll read the MR mail
[12:01] <pete-woods> tsdgeos: definitely
[12:01] <tsdgeos> and we hardly co-indicide in time, no?
[12:01] <pete-woods> probably the same as me
[12:01] <pete-woods> he's there in the mornings
[12:01] <pete-woods> but sure, it's hard
[12:02] <pete-woods> just you know like a million times more than me about the image provider stuff
[12:02] <pete-woods> I can only speculate, rather then know for certain
[12:02] <pete-woods> I think he's planning a super parallelised vision of the thumbnailer
[12:02] <tsdgeos> sure, i'll mail him
[12:02] <pete-woods> and I want to make sure it will expose an API that is actually usable by the QML image provider engine
[12:03] <pete-woods> and also that he doesn't waste 2 weeks of effort
[12:10] <Mirv> tsdgeos: Saviq: any possibility of looking at Qt 5.4.1? keyboard seems broken, maliit-framework crashing. any problem like this without a good explanation makes it a bit more unlikely to get 5.4.1 in with the schedule tight..
[12:10] <Mirv> crashes at QV4::ExecutionContext::setProperty()
[12:15] <tsdgeos> pete-woods: sent, hope i was clear enough :D
[12:16] <tsdgeos> Mirv: which silo is it on?
[12:20] <Mirv> tsdgeos: 012
[12:21] <Mirv> (https://wiki.ubuntu.com/Touch/QtTesting)
[12:21] <tsdgeos> i'll try to have a quick look after lunc
[12:21] <tsdgeos> h
[12:28] <dandrader> Saviq, installed silo 006 on my N4 and all seems fine to me
[12:40] <Saviq> dandrader, kk
[12:50] <pete-woods> tsdgeos: thanks for that! :)
[14:17] <tsdgeos> Mirv: the internal structures of qtdeclarative have changed in 5.4.1 vs 5.4.0, have we rebuilt everything that needs qtdeclarative5-private-dev to build?
[14:21] <Mirv> tsdgeos: we should have, since everything that uses qtdeclarative5-private-dev, meaning a symbol from there marked so in the .symbols file, should depend on qtdeclarative-abi-5-4-0. so, maliit-framework is one of them and was rebuilt.
[14:22] <Mirv> but with current knowledge that includes, in addition to Qt packages itself, only ciborium gsettings-qt maliit-framework qtmir qtubuntu ubuntu-ui-toolkit unity8
[14:23] <Mirv> I've tested browser, video and music playback, everything so far otherwise seems correct but the keyboard
[14:23] <tsdgeos> the crash is weird
[14:33] <tsdgeos> Mirv: how pressing is this?
[14:34] <Mirv> tsdgeos: not pressing if you don't want 5.4.1 to vivid-rtm. in that case I'd land it only after the branching has happened. I just thought https://qt.gitorious.org/qt/qtbase/source/69196b38c481610ef30bfe8ce8e7ba6826729ab8:dist/changes-5.4.1 sounds pretty good.
[14:35] <Mirv> tsdgeos: but also not pressing in the sense I'm gone Thu - Tue, ie back next Wed to see if 5.4.1 finalization can happen
[14:35] <Mirv> but if wanted to vivid-rtm it'd need to be non-regressions of course and also the fixed regressions should be understood that they are not a cause of any risky changes in 5.4.1
[14:35] <tsdgeos> Mirv: ok
[14:51] <Mirv> tsdgeos: filed bug #1427710 - and noted 5.4.0 -> 5.4.1 recompiles slight less than 5.3.2 -> 5.4.0. however, there are recompiles available in a separate PPA if paranoid, and I just upgraded eg ubuntu-keyboard without help
[16:20] <om26er> tsdgeos, Hi!
[16:20] <om26er> tsdgeos, can you tell how can i verify the fix for bug 1410131 ?
[16:21] <tsdgeos> om26er: i'm going to go with you can't :/
[16:21] <tsdgeos> not without editing the code
[16:21] <tsdgeos> to ouput some debug
[16:22] <om26er> tsdgeos, hm, need moar unit tests :)
[16:23] <om26er> tsdgeos, does it affect the phone or is it desktop specific ?
[16:25] <tsdgeos> om26er: it does totally affect the phone
[16:26] <tsdgeos> om26er: and yes, more unit tests there won't hurt
[16:26] <om26er> tsdgeos, I have to verify the fix before landing, I am willing to edit some files if needed
[16:27] <om26er> as long as its qml only (no compilation ;)
[16:30] <tsdgeos> om26er: is this a task you need to do now? and how much qml do you know? i can give you the point were adding some code needs to be added, if you can carry on from there nice, if i need to give you the whole of qml code to add, i'm a bit blocked somehwere else atm
[16:31] <Saviq> tsdgeos, this is QA validation of landings (as we have for RTM), enabled for vivid starting yesterday
[16:32] <tsdgeos> right, just don't land that one :D
[16:32] <tsdgeos> i honestly think it's still a bit risky and probably don't want to delay other landings because of this
[16:32] <Saviq> tsdgeos, well, I already tested it, would have to rebuild and retest ;P
[16:34] <Saviq> om26er, ultimately the validation is that you can't see the difference...
[16:35] <Saviq> you could compare that mem usage is lower, right tsdgeos?
[16:35] <Saviq> but it's not by a whole lot
[16:35] <tsdgeos> Saviq: yes mem should be a bit smaller
[16:35] <tsdgeos> for very long scopes
[16:37] <om26er> Saviq, tsdgeos ok hope it doesn't introduce regressions.
[16:37] <om26er> (and sorry for late response, the top indicator never blinked)
[16:37] <tsdgeos> for a definition of regression it will introduce regressions, it changes the caching behaviour, so we have much less stuff on memory now
[16:38] <tsdgeos> so it is possible that on fast flicks of long scopes the icons will have to be reloaded
[16:38] <tsdgeos> if that's a regression of not
[16:38] <tsdgeos> it's up to the definiion of a regression
[16:39] <om26er> we can call that a "trade-off"
[16:42] <tsdgeos> yep, and as Saviq now (and me tested back then when i made this)
[16:42] <tsdgeos> you should not even see it
[16:46] <om26er> tsdgeos, so need to confirm, are the qtmir changes in the silo only for desktop ?
[16:46] <tsdgeos> om26er: do not know
[16:46] <tsdgeos> Saviq: ↑↑
[16:46] <Saviq> om26er, qtmir isn't in the silo any more
[16:47] <Saviq> or well... *should* not be
[16:47] <Saviq> om26er, sorry, /me removes, but there is nothing in there affecting your testing
[17:26] <Cimi> do we need to protect from division by zero in qml properties?
[18:03] <dandrader> greyback, https://code.launchpad.net/~dandrader/qtubuntu/shellRotation/+merge/242215 is still on "needs fixing" from your side