[09:02] <tsdgeos> Mirv: so Qt 5.4.1 is looking like it can be landed?
[09:06] <Mirv> tsdgeos: the ubuntu-keyboard problem was not scary after all, so that was a good thing. we've now new blockers but they are not related to phone so I think I should be able to put the silo forward for QA signoff maybe tomorrow (the qtmir + uitk silos need to land first anyhow)
[09:07] <Mirv> tsdgeos: so now it looks like 5.4.1 is a "normal" bugfix release after all, so we should be able to go forward. I've been rebuilding a lot now today in the PPA to get final builds done. gles is also todo still.
[09:07] <Saviq> Mirv, would it be a good time to backport a thing or two, or would you rather wait?
[09:07] <Mirv> tsdgeos: the question is how much time there is before vivid-rtm branches and if 5.4.1 makes it on time to vivid
[09:07] <tsdgeos> Mirv: right
[09:08] <Mirv> Saviq: depends. today is a good day to push more builds if you're sure about some patch that is needed. you mean on top of 5.4.1, right?
[09:08] <Saviq> Mirv, yeah
[09:08] <Saviq> Mirv, https://codereview.qt-project.org/#/c/103687/
[09:09] <Mirv> Saviq: yes, mzanetti has given me that already :)
[09:09] <Saviq> ah ok :)
[09:09] <Saviq> Mirv, there is also https://codereview.qt-project.org/#/c/107969/
[09:10] <Saviq> or we could go for https://codereview.qt-project.org/#/c/103738/ directly
[09:10] <Saviq> but neither is yet merged
[09:12] <tsdgeos> Saviq: i'd prefr https://codereview.qt-project.org/#/c/107969/
[09:12] <tsdgeos> Saviq: since https://codereview.qt-project.org/#/c/103738/ is not just https://codereview.qt-project.org/#/c/103738/ but all the 5 or 6 leading to it
[09:12] <Saviq> tsdgeos, ah, right, and it's getting into 5.4 anyway
[09:12] <tsdgeos> yep
[09:12] <tsdgeos> i just staged it
[09:12] <tsdgeos> had forgotten it was approved
[09:22] <Mirv> tsdgeos: Saviq: ok, so 107969
[09:24] <tsdgeos> yeah
[13:40] <mterry> dandrader, did you never rebase on mine?  I can rebase on yours then
[13:41] <dandrader> mterry, what branch are you talking about?
[13:41] <mterry> dandrader, lp:~mterry/unity8/fix-two-qmluitests and lp:~dandrader/unity8/unifyShellTests
[13:42] <dandrader> mterry, ah, so you mean that one has to rebase on top of the other so that both can go in the same silo/landing?
[13:42] <mterry> dandrader, yeah, that's what I was getting at yesterday.  No worries, I'll rebase
[13:42] <dandrader> mterry, ah, I didn't get that yesterday
[14:07] <mterry> Saviq, ok resubmitted my qmluitests branch on top of dandrader's, and set to top-approved again
[14:16] <mterry> dandrader, could you finish up https://code.launchpad.net/~mterry/unity8/unlock-sim-after-wizard/+merge/251612 ?
[14:21] <Saviq> mterry, thanks
[14:21] <Saviq> Cimi, https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1430815
[14:21] <dandrader> mterry, sure. somehow I messed your reply
[14:21] <dandrader> s/messed/missed
[14:22] <mterry> dandrader, the reply was not the most satisfying anyway  :)
[14:22] <dandrader> Saviq, so what's the fate of silo 006?
[14:22] <Saviq> dandrader, waiting for QA sign-off
[14:23] <dandrader> hmm
[14:23] <greyback> dandrader: got a little time to do a MR? https://code.launchpad.net/~gerboland/qtmir/remove-legacy-notification-support/+merge/252551
[14:23] <dandrader> greyback, sure, can do it later today
[14:23] <greyback> thanks1
[14:23] <dandrader> greyback, but it seems mzanetti got it already
[14:24] <greyback> dandrader: the MR superseded a much older one which he reviewed. He's not looked at this one
[14:25] <greyback> even though I told LP not to link the old one, it carried over the reviewer
[14:26] <Saviq> Cimi, it's not clear what the problem is there, can you please find out
[14:30] <Saviq> faenil, meet tsdgeos (if you did not before) - he's our scope master :)
[14:31]  * tsdgeos says hi
[14:33] <tsdgeos> faenil: and welcome
[14:33] <Saviq> tsdgeos, faenil just joined the London team as a prototyper
[14:33] <tsdgeos> yep saw on twitter ^_^
[14:34] <tsdgeos> internet is an easy stalking machine
[14:49] <mterry> dandrader, added comment in unlock-sim-after-wizard
[14:49] <dandrader> mterry, ok
[15:00] <mterry> @unity, is there someone with a spare locked SIM to just give a quick "verified-it-worked" review to https://code.launchpad.net/~mterry/unity8/unlock-sim-after-wizard/+merge/251612 ?
[15:02] <Saviq> mterry, /me
[15:03] <mterry> Saviq, thanks!  dandrader|afk looked at code already, but you're welcome to do the same  :)
[15:08] <tsdgeos> mterry: how hard would it be to make the test of https://code.launchpad.net/~mterry/unity8/cancel-pam-harder/+merge/251174 fail if i remove these lines http://paste.ubuntu.com/10580506/ ?
[15:08] <tsdgeos> i.e. if i remove them it passes
[15:09] <tsdgeos> which i guess it shouldn't, no?
[15:09] <mterry> tsdgeos, I would have to add code to verify that all threads are cleaned up at the end of the test.  A valid thing to do, for sure
[15:10] <tsdgeos> not only the threads but also the "responds()" happen, no?
[15:10] <tsdgeos> not sure if that's done together or not
[15:10] <tsdgeos> mterry: how hard would it be?
[15:11] <mterry> tsdgeos, well the responds cause the threads to go away
[15:11] <mterry> tsdgeos, probably not hard, i can add
[15:11] <tsdgeos> mterry: cool :)
[15:13] <mterry> Saviq, thanks man
[15:17] <tsdgeos> mterry: actually from what i can see, in that test no future is ever executed
[15:18] <tsdgeos> i.e. i added a debug to authenticateWithPam and it doesn't get there
[15:18] <tsdgeos> is it something we may want to add some wait() to get some of the futures getting in it?
[15:19] <mterry> tsdgeos, or maybe a second test for that specific bit -- that first test was just to make sure we could even handle quick cancels without side effects (like crashing)
[15:19] <tsdgeos> ok :)
[15:20] <mterry> tsdgeos, huh, on your machine you don't even get to authenticateWithPam?  I definitely do here, but that may be machine-specific
[15:20] <Saviq> Cimi, oh? so the "scrolls to top-left" is still an issue with your branch?
[15:21] <tsdgeos> mterry: on that test?
[15:21] <mterry> tsdgeos, testing threads is not my favorite sport  :)
[15:21] <Cimi> Saviq, yes
[15:21] <mterry> tsdgeos, yeah
[15:21] <Saviq> meh
[15:21] <Cimi> Saviq, that branch is fixing the animation
[15:21] <Cimi> Saviq, not the zoomable image bug
[15:21] <mterry> tsdgeos, or maybe i only did when I had print statements sprinkled throughout  :)
[15:21] <tsdgeos> mterry: yeah i don't
[15:21] <Cimi> Saviq, I am looking now at the card summary bug, then that
[15:22] <tsdgeos> i did add qDebug() << "MOOOO"; just to the first line of authenticateWithPam
[15:22] <Saviq> Cimi, ah now I get it, ok
[15:23] <mterry> tsdgeos, I think I'll end up having to put some #ifdef debugging code that will have pieces of the code block.  that way I know I'll be testing the right segments
[15:25] <mterry> tsdgeos, but that might be more involved.  Can I make ya a deal?  I'll add the code to check that all threads are cleaned up in this MP now.  But the more intense #ifdef, blocking, synchronizing etc code can be a separate MP?  Which I will put on my todo.  I just don't want to block the crash fix on testing nirvana
[15:25] <tsdgeos> mterry: sure
[15:26] <tsdgeos> i'm still unhappy about the process events though
[15:26] <tsdgeos> but oh well
[15:26] <tsdgeos> my idea was
[15:26] <mterry> tsdgeos, oh hm
[15:26] <tsdgeos> well not idea
[15:26] <tsdgeos> what i implement
[15:26] <tsdgeos> was
[15:26] <tsdgeos> a connect with a lambda
[15:26] <tsdgeos> but then the lambda code was never executed
[15:26] <tsdgeos> and then the test still passed
[15:26] <tsdgeos> and that's where i decided to back off :D
[15:27] <mterry> tsdgeos, :)  when debugging myself, I had qDebug() lines everywhere, in parent and child thread.  And that must have made it more likely that I hid different speeds in the two threads
[15:28] <mterry> tsdgeos, a lambda would help because you have the pam_handle in your closure.  But the "this->futures" data is also thread-specific
[15:28] <mterry> would need to fold that into the closure too
[15:41] <greyback> paulliu: http://bazaar.launchpad.net/~phablet-team/platform-api/trunk/view/head:/src/ubuntu/application/testbackend/ubuntu_application_sensors.cpp
[15:43] <greyback> paulliu: you've seen this code, it injects raw input events which platform-api test backend will receive and send up the stack: https://code.launchpad.net/~canonical/unity8/fake_platform_sensors_module/+merge/247334
[15:45] <paulliu> greyback: yes. But that doesn't works good. So I'll need to dig into.
[15:45] <Cimi> Saviq, ping
[15:45] <Cimi> Saviq, https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1430815
[15:45] <Saviq> Cimi, pong
[15:45] <greyback> paulliu: ok
[15:45] <Cimi> "category-layout": "horizontal-journal",
[15:45] <Saviq> Cimi, I think it's more than that
[15:45] <Cimi> Saviq, in CardCreator, we consider horizontal just template["card-layout"] [15:45] <Saviq> Cimi, per design, if you have art and summary, you have a background
[15:46] <Cimi> Saviq, for vertical, yes
[15:46] <Cimi> Saviq, not for horizontal
[15:46] <Saviq> Cimi, well, yeah, but that's a vertical card
[15:46] <Cimi> Saviq, I am wondering if they expected the horizontal-journal to be horizontal
[15:47] <Cimi> Saviq, but they say "grid horizontal scope card"
[15:47] <Saviq> Cimi, they only have a single item in that category
[15:47] <Saviq> Cimi, I expect they wanted vertical-journal, to not have the blank white at the bottom
[15:48] <Saviq> Cimi, but I can't see anything wrong with that - per design we force a background if you have a summary
[16:00] <Cimi> Saviq, yeah
[16:00] <Cimi> Saviq, if we have both summary and art, always background
[16:00] <Cimi> https://docs.google.com/a/canonical.com/document/d/1n880Fih5KyGPcoP5chidnHDG_8TxXUgSuij7f4rHpuk/edit#
[16:00] <Cimi> "Cards are automatically placed within an ubuntu shape when any of the cards in that category contain a summary and an art. "
[16:01] <Saviq> Cimi, sounds like we don't have that implemented too well (because it didn't say that before)
[16:02] <Saviq> or well, we can only assume there will be a summary if the scope declared it
[16:02] <Saviq> so yeah
[16:02] <Saviq> we do that
[16:06] <mterry> tsdgeos, OK.  I've added a check at the end of the test for the thread count.  But when testing it, I didn't trigger its failure even if I removed that processEvents block.  I had to add some qDebug statements to actually slow down the parent thread enough to trigger the new failure.  So it's still a valid test, but not necessarily being hit.  For that, we need to intentionally slow down the parent thread in specific points.  Which needs the wh
[16:06] <mterry> ole #ifdef bits and some more tooling.  I didn't realize how bad a test I'd made because I was always testing with prints  :-/  How about I promise to not only revisit the test situation, but re-examine the explicit calls to processEvents
[16:07] <tsdgeos> mterry: sure :)
[16:47] <tsdgeos> can anyone reproduce the Dash::test_close_temp_scope_preview_opening_scope failure?
[16:47] <tsdgeos> it's pretty consistent in CI
[16:47] <tsdgeos> but i can't seem to get it here
[16:48] <greyback> Mirv: hey, you aware of QtCreator crashing with a multimonitor setup and you unplug the monitor that QtC instance is on?
[16:50] <Saviq> tsdgeos, I had the 8 failures CI reported, lemme see
[16:50] <tsdgeos> Saviq: 1 is fixed in one branch of mine, 5 in one of mterry
[16:50] <tsdgeos> but there's 2 in the dash i can't repro
[16:50] <tsdgeos> but since one is atyend
[16:51] <tsdgeos> i'll use the same trick i used in the other one
[16:51] <tsdgeos> and see if CI is happy
[16:51] <Saviq> tsdgeos, it felt like a candidate for putting in a function, too
[16:52] <tsdgeos> totally
[16:52] <tsdgeos> but first let me see if i can make it pass in CI
[16:52] <tsdgeos> and then we'll make it prettier
[16:53] <Saviq> etoomanytests
[16:53] <tsdgeos> yeah
[16:53] <tsdgeos> running qmluitests takes ages nowadays
[16:57] <Saviq> tsdgeos, yeah, can't get it to fail after all
[16:57] <tsdgeos> let's see what CI has to say
[17:08] <cheekoli> is there a way to show the unity workspace switcher from within a script? I am working on changing the count on the fly--its all working currently, except when i run it (with a keyboard shortcut) i'd like to pop up the workspace switcher so i can see the current count of workspaces
[17:09] <cheekoli> Saviq, thanks for your help yesterday... got it working :)
[17:11] <cheekoli> the trickiest part was getting the script to connect to the right display session... luckily i'd been down that road and already had a script for it :)
[17:16] <Saviq> cheekoli, I think you just need to inject <Super>+s
[17:17] <Saviq> cheekoli, there's no other entry point to get into the spread I don't think
[17:45] <cheekoli> thanks for the advice again, seems to work
[19:22] <dandrader> mzanetti, you there?
[19:23] <mzanetti> dandrader, what up?
[19:23] <dandrader> mzanetti, is it know/expected that it takes two taps/clicks in order to switch focus between windows?
[19:24] <mzanetti> dandrader, neither
[19:24] <dandrader> mzanetti, first tap unfocus the previous. second tap focus the new
[19:24] <mzanetti> dandrader, this used to work. seems a newish issue
[19:25] <dandrader> mzanetti, that's with shellRotation branch. don't know if other are needed on top ofit
[19:25] <dandrader> mzanetti, also, this is in make tryOrientedShell. so maybe it only happens there, which would be odd
[19:29] <mzanetti> compiling trunk
[19:34] <mzanetti> dandrader, seems broken in trunk too
[19:34] <dandrader> mzanetti, ok
[19:36] <dandrader> man, playing with the qml tests in a touch screen opens a new dimension, as you can interact with them with actual touch events, not having to emulate them out of mouse input
[19:38] <dandrader> mzanetti, it might be a clue that you can also drag windows along on when you the first press
[19:38] <dandrader> mzanetti,  *when you first press them (ie, when they're not focused yet)
[19:39] <mzanetti> dandrader, yeah... could be
[21:40] <spaceindaver> Hi all, I installed the latest nvidia drivers (340) and nvidia-prime (for switching graphics cards on an optimus laptop) and now every time I boot unity fails to start after I log in. I can get it to run again if I delete my .config directory. Any idea what could be causing this?