| === davidcalle_ is now known as davidcalle | ||
| tsdgeos | Mirv: so Qt 5.4.1 is looking like it can be landed? | 09:02 |
|---|---|---|
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| Saviq | or we could go for https://codereview.qt-project.org/#/c/103738/ directly | 09:10 |
| Saviq | but neither is yet merged | 09:10 |
| 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:12 |
| Mirv | tsdgeos: Saviq: ok, so 107969 | 09:22 |
| tsdgeos | yeah | 09:24 |
| === 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 | ||
| mterry | dandrader, did you never rebase on mine? I can rebase on yours then | 13:40 |
| dandrader | mterry, what branch are you talking about? | 13:41 |
| mterry | dandrader, lp:~mterry/unity8/fix-two-qmluitests and lp:~dandrader/unity8/unifyShellTests | 13:41 |
| 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 | 13:42 |
| === alan_g|lunch is now known as alan_g | ||
| mterry | Saviq, ok resubmitted my qmluitests branch on top of dandrader's, and set to top-approved again | 14:07 |
| mterry | dandrader, could you finish up https://code.launchpad.net/~mterry/unity8/unlock-sim-after-wizard/+merge/251612 ? | 14:16 |
| 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 |
| ubot5 | Ubuntu bug 1430815 in Canonical System Image "grid horizontal scope card has white background" [High,New] | 14:21 |
| dandrader | s/messed/missed | 14:21 |
| 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:22 |
| 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:23 |
| greyback | dandrader: the MR superseded a much older one which he reviewed. He's not looked at this one | 14:24 |
| greyback | even though I told LP not to link the old one, it carried over the reviewer | 14:25 |
| Saviq | Cimi, it's not clear what the problem is there, can you please find out | 14:26 |
| Saviq | faenil, meet tsdgeos (if you did not before) - he's our scope master :) | 14:30 |
| * tsdgeos says hi | 14:31 | |
| 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:33 |
| tsdgeos | internet is an easy stalking machine | 14:34 |
| mterry | dandrader, added comment in unlock-sim-after-wizard | 14:49 |
| dandrader | mterry, ok | 14:49 |
| === dandrader is now known as dandrader|afk | ||
| 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:00 |
| Saviq | mterry, /me | 15:02 |
| mterry | Saviq, thanks! dandrader|afk looked at code already, but you're welcome to do the same :) | 15:03 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| mterry | Saviq, thanks man | 15:13 |
| tsdgeos | mterry: actually from what i can see, in that test no future is ever executed | 15:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| tsdgeos | i did add qDebug() << "MOOOO"; just to the first line of authenticateWithPam | 15:22 |
| Saviq | Cimi, ah now I get it, ok | 15:22 |
| 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:23 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| === dandrader|afk is now known as dandrader | ||
| greyback | paulliu: http://bazaar.launchpad.net/~phablet-team/platform-api/trunk/view/head:/src/ubuntu/application/testbackend/ubuntu_application_sensors.cpp | 15:41 |
| 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:43 |
| 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 |
| ubot5 | Ubuntu bug 1430815 in Canonical System Image "grid horizontal scope card has white background" [High,Confirmed] | 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"] === "horizontal"; | 15:45 |
| Saviq | Cimi, per design, if you have art and summary, you have a background | 15:45 |
| 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:46 |
| 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:47 |
| Saviq | Cimi, but I can't see anything wrong with that - per design we force a background if you have a summary | 15:48 |
| 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:00 |
| Saviq | Cimi, sounds like we don't have that implemented too well (because it didn't say that before) | 16:01 |
| 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:02 |
| 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:06 |
| tsdgeos | mterry: sure :) | 16:07 |
| === seb128_ is now known as seb128 | ||
| 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:47 |
| greyback | Mirv: hey, you aware of QtCreator crashing with a multimonitor setup and you unplug the monitor that QtC instance is on? | 16:48 |
| 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:50 |
| 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:51 |
| 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:52 |
| Saviq | etoomanytests | 16:53 |
| tsdgeos | yeah | 16:53 |
| tsdgeos | running qmluitests takes ages nowadays | 16:53 |
| Saviq | tsdgeos, yeah, can't get it to fail after all | 16:57 |
| tsdgeos | let's see what CI has to say | 16:57 |
| 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:08 |
| cheekoli | Saviq, thanks for your help yesterday... got it working :) | 17:09 |
| 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:11 |
| Saviq | cheekoli, I think you just need to inject <Super>+s | 17:16 |
| Saviq | cheekoli, there's no other entry point to get into the spread I don't think | 17:17 |
| === dandrader is now known as dandrader|lunch | ||
| cheekoli | thanks for the advice again, seems to work | 17:45 |
| === alan_g is now known as alan_g|EOD | ||
| dandrader | mzanetti, you there? | 19:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| mzanetti | compiling trunk | 19:29 |
| mzanetti | dandrader, seems broken in trunk too | 19:34 |
| dandrader | mzanetti, ok | 19:34 |
| 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:36 |
| 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:38 |
| mzanetti | dandrader, yeah... could be | 19:39 |
| === dandrader is now known as dandrader|bbl | ||
| 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? | 21:40 |
| === dandrader|bbl is now known as dandrader | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!