=== davidcalle_ is now known as davidcalle [09:02] Mirv: so Qt 5.4.1 is looking like it can be landed? [09:06] 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] 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] Mirv, would it be a good time to backport a thing or two, or would you rather wait? [09:07] 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] Mirv: right [09:08] 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] Mirv, yeah [09:08] Mirv, https://codereview.qt-project.org/#/c/103687/ [09:09] Saviq: yes, mzanetti has given me that already :) [09:09] ah ok :) [09:09] Mirv, there is also https://codereview.qt-project.org/#/c/107969/ [09:10] or we could go for https://codereview.qt-project.org/#/c/103738/ directly [09:10] but neither is yet merged [09:12] Saviq: i'd prefr https://codereview.qt-project.org/#/c/107969/ [09:12] 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] tsdgeos, ah, right, and it's getting into 5.4 anyway [09:12] yep [09:12] i just staged it [09:12] had forgotten it was approved [09:22] tsdgeos: Saviq: ok, so 107969 [09:24] yeah === Malsasa_ is now known as Malsasa === MacSlow is now known as MacSlow|lunch === alan_g is now known as alan_g|lunch === MacSlow|lunch is now known as MacSlow [13:40] dandrader, did you never rebase on mine? I can rebase on yours then [13:41] mterry, what branch are you talking about? [13:41] dandrader, lp:~mterry/unity8/fix-two-qmluitests and lp:~dandrader/unity8/unifyShellTests [13:42] 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] dandrader, yeah, that's what I was getting at yesterday. No worries, I'll rebase [13:42] mterry, ah, I didn't get that yesterday === alan_g|lunch is now known as alan_g [14:07] Saviq, ok resubmitted my qmluitests branch on top of dandrader's, and set to top-approved again [14:16] dandrader, could you finish up https://code.launchpad.net/~mterry/unity8/unlock-sim-after-wizard/+merge/251612 ? [14:21] mterry, thanks [14:21] Cimi, https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1430815 [14:21] mterry, sure. somehow I messed your reply [14:21] Ubuntu bug 1430815 in Canonical System Image "grid horizontal scope card has white background" [High,New] [14:21] s/messed/missed [14:22] dandrader, the reply was not the most satisfying anyway :) [14:22] Saviq, so what's the fate of silo 006? [14:22] dandrader, waiting for QA sign-off [14:23] hmm [14:23] dandrader: got a little time to do a MR? https://code.launchpad.net/~gerboland/qtmir/remove-legacy-notification-support/+merge/252551 [14:23] greyback, sure, can do it later today [14:23] thanks1 [14:23] greyback, but it seems mzanetti got it already [14:24] dandrader: the MR superseded a much older one which he reviewed. He's not looked at this one [14:25] even though I told LP not to link the old one, it carried over the reviewer [14:26] Cimi, it's not clear what the problem is there, can you please find out [14:30] faenil, meet tsdgeos (if you did not before) - he's our scope master :) [14:31] * tsdgeos says hi [14:33] faenil: and welcome [14:33] tsdgeos, faenil just joined the London team as a prototyper [14:33] yep saw on twitter ^_^ [14:34] internet is an easy stalking machine [14:49] dandrader, added comment in unlock-sim-after-wizard [14:49] mterry, ok === dandrader is now known as dandrader|afk [15:00] @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] mterry, /me [15:03] Saviq, thanks! dandrader|afk looked at code already, but you're welcome to do the same :) [15:08] 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] i.e. if i remove them it passes [15:09] which i guess it shouldn't, no? [15:09] 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] not only the threads but also the "responds()" happen, no? [15:10] not sure if that's done together or not [15:10] mterry: how hard would it be? [15:11] tsdgeos, well the responds cause the threads to go away [15:11] tsdgeos, probably not hard, i can add [15:11] mterry: cool :) [15:13] Saviq, thanks man [15:17] mterry: actually from what i can see, in that test no future is ever executed [15:18] i.e. i added a debug to authenticateWithPam and it doesn't get there [15:18] is it something we may want to add some wait() to get some of the futures getting in it? [15:19] 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] ok :) [15:20] tsdgeos, huh, on your machine you don't even get to authenticateWithPam? I definitely do here, but that may be machine-specific [15:20] Cimi, oh? so the "scrolls to top-left" is still an issue with your branch? [15:21] mterry: on that test? [15:21] tsdgeos, testing threads is not my favorite sport :) [15:21] Saviq, yes [15:21] tsdgeos, yeah [15:21] meh [15:21] Saviq, that branch is fixing the animation [15:21] Saviq, not the zoomable image bug [15:21] tsdgeos, or maybe i only did when I had print statements sprinkled throughout :) [15:21] mterry: yeah i don't [15:21] Saviq, I am looking now at the card summary bug, then that [15:22] i did add qDebug() << "MOOOO"; just to the first line of authenticateWithPam [15:22] Cimi, ah now I get it, ok [15:23] 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] 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] mterry: sure [15:26] i'm still unhappy about the process events though [15:26] but oh well [15:26] my idea was [15:26] tsdgeos, oh hm [15:26] well not idea [15:26] what i implement [15:26] was [15:26] a connect with a lambda [15:26] but then the lambda code was never executed [15:26] and then the test still passed [15:26] and that's where i decided to back off :D [15:27] 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] 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] would need to fold that into the closure too === dandrader|afk is now known as dandrader [15:41] paulliu: http://bazaar.launchpad.net/~phablet-team/platform-api/trunk/view/head:/src/ubuntu/application/testbackend/ubuntu_application_sensors.cpp [15:43] 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] greyback: yes. But that doesn't works good. So I'll need to dig into. [15:45] Saviq, ping [15:45] Saviq, https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1430815 [15:45] Cimi, pong [15:45] paulliu: ok [15:45] Ubuntu bug 1430815 in Canonical System Image "grid horizontal scope card has white background" [High,Confirmed] [15:45] "category-layout": "horizontal-journal", [15:45] Cimi, I think it's more than that [15:45] Saviq, in CardCreator, we consider horizontal just template["card-layout"] === "horizontal"; [15:45] Cimi, per design, if you have art and summary, you have a background [15:46] Saviq, for vertical, yes [15:46] Saviq, not for horizontal [15:46] Cimi, well, yeah, but that's a vertical card [15:46] Saviq, I am wondering if they expected the horizontal-journal to be horizontal [15:47] Saviq, but they say "grid horizontal scope card" [15:47] Cimi, they only have a single item in that category [15:47] Cimi, I expect they wanted vertical-journal, to not have the blank white at the bottom [15:48] Cimi, but I can't see anything wrong with that - per design we force a background if you have a summary [16:00] Saviq, yeah [16:00] Saviq, if we have both summary and art, always background [16:00] https://docs.google.com/a/canonical.com/document/d/1n880Fih5KyGPcoP5chidnHDG_8TxXUgSuij7f4rHpuk/edit# [16:00] "Cards are automatically placed within an ubuntu shape when any of the cards in that category contain a summary and an art. " [16:01] Cimi, sounds like we don't have that implemented too well (because it didn't say that before) [16:02] or well, we can only assume there will be a summary if the scope declared it [16:02] so yeah [16:02] we do that [16:06] 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] 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] mterry: sure :) === seb128_ is now known as seb128 [16:47] can anyone reproduce the Dash::test_close_temp_scope_preview_opening_scope failure? [16:47] it's pretty consistent in CI [16:47] but i can't seem to get it here [16:48] Mirv: hey, you aware of QtCreator crashing with a multimonitor setup and you unplug the monitor that QtC instance is on? [16:50] tsdgeos, I had the 8 failures CI reported, lemme see [16:50] Saviq: 1 is fixed in one branch of mine, 5 in one of mterry [16:50] but there's 2 in the dash i can't repro [16:50] but since one is atyend [16:51] i'll use the same trick i used in the other one [16:51] and see if CI is happy [16:51] tsdgeos, it felt like a candidate for putting in a function, too [16:52] totally [16:52] but first let me see if i can make it pass in CI [16:52] and then we'll make it prettier [16:53] etoomanytests [16:53] yeah [16:53] running qmluitests takes ages nowadays [16:57] tsdgeos, yeah, can't get it to fail after all [16:57] let's see what CI has to say [17:08] 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] Saviq, thanks for your help yesterday... got it working :) [17:11] 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] cheekoli, I think you just need to inject +s [17:17] cheekoli, there's no other entry point to get into the spread I don't think === dandrader is now known as dandrader|lunch [17:45] thanks for the advice again, seems to work === alan_g is now known as alan_g|EOD [19:22] mzanetti, you there? [19:23] dandrader, what up? [19:23] mzanetti, is it know/expected that it takes two taps/clicks in order to switch focus between windows? [19:24] dandrader, neither [19:24] mzanetti, first tap unfocus the previous. second tap focus the new [19:24] dandrader, this used to work. seems a newish issue [19:25] mzanetti, that's with shellRotation branch. don't know if other are needed on top ofit [19:25] mzanetti, also, this is in make tryOrientedShell. so maybe it only happens there, which would be odd [19:29] compiling trunk [19:34] dandrader, seems broken in trunk too [19:34] mzanetti, ok [19:36] 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] mzanetti, it might be a clue that you can also drag windows along on when you the first press [19:38] mzanetti, *when you first press them (ie, when they're not focused yet) [19:39] dandrader, yeah... could be === dandrader is now known as dandrader|bbl [21:40] 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? === dandrader|bbl is now known as dandrader