| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| Saviq | mzanetti, did Germany explode yesterday? | 07:21 |
|---|---|---|
| mzanetti | Saviq: http://www.youtube.com/watch?v=IynteMtSBxo&app=desktop | 07:32 |
| mzanetti | Saviq: it was raining quite heavily. so it wasn't too bad | 07:34 |
| Saviq | mzanetti, yup, that one's gone viral ;) | 07:36 |
| Saviq | mzanetti, pushed a commit or two to https://code.launchpad.net/~saviq/unity8/refactor-scopeitem/+merge/225745 | 07:45 |
| Mirv | mzanetti: hehe :) | 07:48 |
| mzanetti | Mirv: oh hi! welcome back | 07:49 |
| Mirv | mzanetti: o hai! thanks! | 07:49 |
| Saviq | mzanetti, in lieu of Cimi, could you have a look at the last commits in https://code.launchpad.net/~saviq/unity8/refactor-carousel-activation/+merge/225743, too? 1029+ | 07:50 |
| mzanetti | ok | 07:50 |
| Saviq | thanks | 07:50 |
| mzanetti | Saviq: but I thought Cimi would be around for today still? | 08:01 |
| Saviq | mzanetti, yeah I'm not actually clear on when he's away... | 08:01 |
| mzanetti | there's still 4 unreviewed launcher branches :/ | 08:03 |
| * Saviq needs to reboot the modem... | 08:04 | |
| Saviq | mzanetti, thanks, btw, I talked to John yesterday, filed a design bug: https://bugs.launchpad.net/ubuntu-ux/+bug/1339413 | 08:13 |
| ubot5 | Ubuntu bug 1339413 in unity8 (Ubuntu) "Emblems for apps that are not pinned to launcher don't show up" [Undecided,New] | 08:13 |
| Saviq | mzanetti, wdyt? | 08:14 |
| mzanetti | need to test | 08:14 |
| mhr3 | Saviq, confirming that my yesterday's issues in 018 are fixed | 08:14 |
| mzanetti | oh... right | 08:14 |
| mzanetti | Saviq: well... yeah... if there is no such icon in the launcher, yes | 08:14 |
| Saviq | mzanetti, that's why I said it's a design bug | 08:14 |
| mzanetti | Saviq: and what is the question? | 08:15 |
| Saviq | mzanetti, what do you think, is all :) | 08:15 |
| mzanetti | I think it makes sense... do I need to do that this week still (before freeze etc) | 08:15 |
| mzanetti | ? | 08:15 |
| Saviq | mzanetti, not at all | 08:15 |
| mzanetti | ok... | 08:15 |
| Saviq | mzanetti, it's a design question first | 08:15 |
| mzanetti | so yeah... imo it makes sense to add such things to the launcher | 08:16 |
| Saviq | mzanetti, I wasn't even asking what do you think about impl it ;) | 08:16 |
| Saviq | mhr3, great | 08:16 |
| Saviq | mhr3, running through the test plan now | 08:16 |
| mzanetti | Saviq: btw... yesterday I noticed that we have 250 open bugs in unity8 where at least 50 them are either fixed or not valid any more... | 08:17 |
| Saviq | mzanetti, yeah, if only we had time to triage | 08:17 |
| mzanetti | tried to collect the ones that will be fixed by QtComp at least | 08:17 |
| Saviq | mzanetti, it'll probably be a (pre-)London exercise to clear it up | 08:18 |
| mzanetti | yeah, that seems sensible... well, I'll put some clean up of that on my low prio todo list too | 08:18 |
| mzanetti | maybe I can help a bit with it | 08:18 |
| Saviq | mzanetti, sure, I didn't say necessarily *I* was gonna do it ;) | 08:18 |
| mzanetti | :D | 08:18 |
| mzanetti | me neither | 08:19 |
| Saviq | mzanetti, we just need someone who pisses me off :D | 08:19 |
| Saviq | any takers? | 08:19 |
| * mzanetti hides | 08:19 | |
| tsdgeos | Saviq: sorry man, i'm busy with the dash overview ;) | 08:19 |
| Saviq | ;) | 08:20 |
| tsdgeos | we don't have the paper folded background anymore or never had it? | 08:31 |
| * tsdgeos is fuzzy | 08:31 | |
| Saviq | tsdgeos, we still do :) | 08:31 |
| tsdgeos | just not on the desktop? | 08:31 |
| tsdgeos | don't see it there | 08:31 |
| Saviq | tsdgeos, yes, there too | 08:31 |
| tsdgeos | lol | 08:32 |
| tsdgeos | i was running tryDash *_* | 08:32 |
| Saviq | tsdgeos, yeah thought so ;) | 08:32 |
| Saviq | mzanetti, oh noes, there's autopilot tests relying on the search indicator | 08:50 |
| mzanetti | Saviq: hmm... ok. let me fix that | 08:51 |
| mzanetti | Saviq: btw. I'd say temp scopes are missing a busy indicator for the time where data isn't fetched yet | 08:51 |
| mzanetti | Saviq: same when changing a department | 08:52 |
| Saviq | mzanetti, they always did | 08:52 |
| Saviq | mzanetti, except on landscape | 08:52 |
| mzanetti | yeah, I know... but it wasn't that much of a problem until now | 08:52 |
| Saviq | mzanetti, but agreed, we should find a better place for it than the search entry | 08:52 |
| mzanetti | should I file a bug about it? | 08:52 |
| Saviq | mzanetti, yeah, do, unity8 + ubuntu-ux | 08:53 |
| mzanetti | ack | 08:53 |
| Saviq | mzanetti, other ap tests fail because they expect a single PageHeader | 08:53 |
| Saviq | mzanetti, 5 failures in total | 08:53 |
| mzanetti | ok... 5 is ok. will fix | 08:54 |
| Saviq | mzanetti, I'll kick ci on new-header to get a baseline | 08:54 |
| mzanetti | ok | 08:54 |
| mzanetti | https://bugs.launchpad.net/ubuntu-ux/+bug/1339595 | 08:56 |
| ubot5 | Ubuntu bug 1339595 in Unity 8 "scopes are missing an ActivityIndicator while they fetch data from the network" [Undecided,New] | 08:56 |
| tsdgeos | Saviq: are we supporting search in dash overview? | 10:20 |
| tsdgeos | for RTM i mean | 10:20 |
| Saviq | tsdgeos, we said yes | 10:20 |
| tsdgeos | ok | 10:20 |
| tsdgeos | and suddenly there's a back button in search | 10:21 |
| tsdgeos | we don't have that in dash do we? | 10:22 |
| tsdgeos | maybe in new dash? | 10:22 |
| tsdgeos | i mean new header | 10:23 |
| Saviq | tsdgeos, yeah we do now | 10:23 |
| tsdgeos | ah nice | 10:23 |
| Saviq | tsdgeos, it'll land soonish | 10:24 |
| Saviq | tsdgeos, but you should have it already if you based off of scope-customs | 10:24 |
| tsdgeos | yep | 10:24 |
| tsdgeos | cool | 10:24 |
| tsdgeos | Saviq: hmmmm | 10:28 |
| tsdgeos | Saviq: we have something called scopeStyle in qml/Components | 10:28 |
| tsdgeos | doesn't really seem "abstracted" | 10:28 |
| Saviq | tsdgeos, where? | 10:32 |
| tsdgeos | PageHeader.qml | 10:32 |
| tsdgeos | property var scopeStyle: null | 10:32 |
| Saviq | tsdgeos, well, yeah, I just added it | 10:33 |
| tsdgeos | sure | 10:33 |
| tsdgeos | i mean i realized | 10:33 |
| Saviq | tsdgeos, PageHeader is scope-specific in any case, probably should just move to Dash// | 10:33 |
| tsdgeos | having something with scope in the name in there is a bit weird | 10:33 |
| tsdgeos | or that :D | 10:33 |
| Saviq | tsdgeos, or we might abstract it again and then wrap it in ScopePageHeader or something | 10:33 |
| Saviq | tsdgeos, but agreed, needs resolving | 10:34 |
| Saviq | tsdgeos, since we use it in HUD as well... | 10:34 |
| tsdgeos | just call it style | 10:35 |
| tsdgeos | and be done with it :D | 10:35 |
| davmor2 | Hey guys. I have a device that is currently locked up on the welcome screen. I've got 3 crashes in var/crash one of which is Qt5 the other 2 are indicators. Is there anything of use I can get for you that might lower down the issue some? | 10:37 |
| tsdgeos | mzanetti: ping | 10:43 |
| mzanetti | tsdgeos: pong | 10:48 |
| tsdgeos | mzanetti: the newheader seems to have a gray line on the top | 10:49 |
| tsdgeos | is that on purpose or by mistake? | 10:49 |
| * mzanetti looks | 10:49 | |
| tsdgeos | mzanetti: http://i.imgur.com/WrMJOfz.png this is a header with y: 10 | 10:50 |
| mzanetti | tsdgeos: hmm, no, its not on purpose | 10:51 |
| tsdgeos | it's harder to notice on the dash | 10:51 |
| tsdgeos | since it's there all the time | 10:51 |
| tsdgeos | and similar in color to the background | 10:51 |
| mzanetti | yeah | 10:51 |
| Saviq | tsdgeos, your "Done" button is outside the window, kudos! | 10:51 |
| Saviq | ;) | 10:51 |
| tsdgeos | but in the overview it shows | 10:51 |
| tsdgeos | Saviq: lol | 10:52 |
| mzanetti | tsdgeos: can you press the search button in here? | 10:53 |
| tsdgeos | mzanetti: yes, why? | 10:53 |
| mzanetti | tsdgeos: to see if the search header has the grey line on top too, or if the one we see in here is attached at the bottom of the search header | 10:53 |
| tsdgeos | ah | 10:53 |
| tsdgeos | it "travels" down | 10:53 |
| mzanetti | is there a new one coming in at the top? | 10:54 |
| tsdgeos | nope | 10:57 |
| mzanetti | tsdgeos: hmm... ok... I did tell the PageHeadStyle to no paint a separator | 11:00 |
| mzanetti | tsdgeos: currently investigating in AP tests. I can investigate in this after that | 11:00 |
| tsdgeos | mzanetti: sure, no hurry, it's just a minor visual thing | 11:00 |
| mzanetti | ack | 11:01 |
| === MacSlow is now known as MacSlow|lunch | ||
| === pete-woods is now known as pete-woods-lunch | ||
| === alan_g is now known as alan_g|lunch | ||
| === MacSlow|lunch is now known as MacSlow | ||
| Saviq | mzanetti, t'is me again, how's autopilot? | 12:38 |
| greyback | damn, ran out of disk space, now my user account corrupted | 12:46 |
| mhr3 | Saviq, something missing in 018? | 12:46 |
| Saviq | mhr3, mzanetti's fixing ap tests | 12:46 |
| Saviq | mhr3, should land real soon | 12:46 |
| mzanetti | doing the final run | 12:46 |
| Saviq | greyback, uh oh | 12:46 |
| mzanetti | individually all the failing ones are passing now | 12:46 |
| === alan_g|lunch is now known as alan_g | ||
| mhr3 | k, thx | 12:50 |
| Saviq | mhr3, do we support opening scopes through departments? | 12:53 |
| mhr3 | Saviq, no | 12:53 |
| Saviq | mhr3, and it was never discussed was it? | 12:53 |
| mhr3 | someone did have the idea, we didn't like it | 12:54 |
| mhr3 | one's certain, UX for it would suck | 12:54 |
| Saviq | indeed | 12:54 |
| Saviq | I'd get so confused when this would happen | 12:54 |
| karni | Saviq: Would there be a chance to get this in the work pipeline sooner than later :)? https://bugs.launchpad.net/unity8/+bug/1326470 (notably, I'm interested in the "default uncollapsed state when there is only one category" really) | 12:55 |
| ubot5 | Ubuntu bug 1326470 in unity8 (Ubuntu) "Scope author should be able to set the number of collapsed results to show" [Undecided,Confirmed] | 12:55 |
| cwayne | Saviq: we got that from here btw: https://docs.google.com/a/canonical.com/document/d/1engc5TPtQC9iI8zziMxx9DLVY74b4bvsnPvGBVb95YI/edit | 12:55 |
| Saviq | dudes, one at a time | 12:55 |
| mhr3 | Saviq, oh and can we get also [another random item] ;P | 12:56 |
| cwayne | i wasn't asking for something this time though :) | 12:56 |
| Saviq | ;) | 12:57 |
| * karni stands in the queue | 12:57 | |
| karni | ha! | 12:57 |
| Saviq | mhr3, are you sanitizing collapsed-rows? | 12:59 |
| mhr3 | Saviq, you mean clamping to 1-2? | 13:02 |
| mhr3 | no | 13:02 |
| mhr3 | Saviq, i was actually looking at that piece of code when doing the see more, there's an issue - if the scope sets it to 0, shell will consider it unset and use 2 | 13:03 |
| Saviq | mhr3, that's fine, I'll fix shell | 13:09 |
| mhr3 | Saviq, you probably want to fix that in the grid-see-more branch | 13:10 |
| Saviq | mhr3, nice bump ;) | 13:10 |
| mhr3 | Saviq, and maybe fix the other issues with it? :) | 13:10 |
| === pete-woods-lunch is now known as pete-woods | ||
| mzanetti | Saviq: I've fixed the 5 ap tests that were failing | 13:22 |
| mzanetti | however, now I had others fail (unrelated to the pageheader change) | 13:22 |
| Saviq | mzanetti, which ones? | 13:30 |
| mzanetti | Saviq: lifecycle | 13:30 |
| Saviq | mzanetti, one it's flaky | 13:31 |
| mzanetti | Saviq: Assert(Greeter.created, True) | 13:31 |
| Saviq | mzanetti, btw, testing speed-up: | 13:31 |
| Saviq | while true; do sleep 1; status unity8 | grep -q killed && pkill unity8; done | 13:31 |
| Saviq | on the device | 13:31 |
| mzanetti | huh? | 13:31 |
| Saviq | mzanetti, it will convince unity8 to exit when upstart's asked it | 13:32 |
| Saviq | mzanetti, so it doesn't take a full minute to go away... | 13:32 |
| === _salem is now known as salem_ | ||
| Saviq | mzanetti, just push your fixes to the branch please | 13:35 |
| mzanetti | which ones? | 13:37 |
| Saviq | mzanetti, you did already | 13:42 |
| Saviq | mzanetti, I meant the ap ones | 13:42 |
| mzanetti | yeah, for the PageHeader | 13:43 |
| mzanetti | didn't really investigate in the lifecycle ones | 13:43 |
| === larsu_ is now known as larsu | ||
| === Zhenech_ is now known as Zhenech | ||
| Saviq | mzanetti, you really need to prefix my name if you want a response from me, won't notice otherwise ;) | 14:00 |
| mzanetti | I know :P | 14:05 |
| Saviq | mzanetti, so... clip corners... did you consider putting the icon in the clipper, rotate the clipper and unrotate the icon? | 14:19 |
| Saviq | mzanetti, also, wonder if the clipping should happen when dragging a clipped icon, too? | 14:21 |
| mzanetti | Saviq: not sure I understand the first question | 14:22 |
| mzanetti | vesar: your opinion on Saviq's second question? ^^ | 14:22 |
| Saviq | mzanetti, instead of the mask, you could put the icon in an Item { clip: true; rotate: 45 } or so | 14:23 |
| mzanetti | ah.... yeah, that'd probably work too | 14:23 |
| Saviq | mzanetti, should be faster than another texture lookup | 14:23 |
| mzanetti | thik so? | 14:23 |
| mzanetti | Saviq: think so? | 14:24 |
| mzanetti | I don't know tbh | 14:24 |
| Saviq | mzanetti, yeah, texture lookup you need one per pixel, whereas with clipping you just clip away with geometry | 14:24 |
| Saviq | mzanetti, obviously depends on how it's really implemented, but if you think about it... | 14:25 |
| mzanetti | hmm, well, can change it if you think its better... | 14:25 |
| Saviq | mzanetti, I was told texture lookups are quite expensive (hence blur is difficult) | 14:25 |
| Saviq | mzanetti, would be a bit easier to understand IMO, too | 14:25 |
| mzanetti | Saviq: not sure why blur would do a texture lookup | 14:25 |
| Saviq | mzanetti, huh? | 14:26 |
| mzanetti | oh right.. | 14:26 |
| Saviq | mzanetti, it needs to consider $however_many pixels around the current one | 14:26 |
| mzanetti | yeah, but... that's like evaluating 1024 pixels per pixel | 14:26 |
| mzanetti | Saviq: this one is just 1:! | 14:26 |
| mzanetti | 1:1 | 14:26 |
| Saviq | mzanetti, still | 14:27 |
| mzanetti | but sure, I don't mind changing it... Not sure why I didn't have the simple idea myself :D | 14:27 |
| mzanetti | probably because I wanted to learn how to do it with a shader | 14:27 |
| Saviq | mzanetti, it's not actually that bad, when blurring you're only doing horizontal and vertical, not around | 14:27 |
| Saviq | mzanetti, so it's like a dozen lookups or so | 14:28 |
| mzanetti | mhm... makes sense | 14:28 |
| Saviq | depending on the blur size | 14:28 |
| mzanetti | and the blur mode too | 14:28 |
| Saviq | mzanetti, sure | 14:28 |
| Saviq | mzanetti, http://sunsetlakesoftware.com/2013/10/21/optimizing-gaussian-blurs-mobile-gpu is a good read | 14:29 |
| mzanetti | cool. thats interesting | 14:29 |
| mzanetti | ok... will change it to just do a regular clip then | 14:29 |
| mzanetti | Saviq: I'll track down vesar on the other question | 14:30 |
| vesar | mzanetti,about the second question. yeah I noticed that when testing the branch and asked Esti (who created the visual) because I felt is should clip also when moved around. But her opinion was that it's ok like that. So not clipping when dragging. This because the the metaphor with the clipping corner is launcher background material covering the icon. Those two to be united. So when it's dragged away it's ok not to clip. | 14:30 |
| vesar | mzanetti, sorry for the messy lengthy answer. But basically it's been noted and run through with visual guys and can be left as it is. cool with that? | 14:31 |
| Saviq | vesar, yeah, when dragged away... problem is it happens as you long-press, too :| | 14:31 |
| mzanetti | vesar: it wasn't messy. | 14:31 |
| Saviq | vesar, so when just getting to the quicklist, the corner goes "blink" | 14:32 |
| mzanetti | but that's kinda ok looking at it from Esti's view | 14:32 |
| mzanetti | as you basically start the drag, that would indicate you got it out of the launcher | 14:32 |
| mzanetti | if you then release it, it'll go back in | 14:33 |
| vesar | Saviq, mzanetti. Oh ok I see. No we don't want any blinking when longpressed. | 14:33 |
| Saviq | mzanetti, well, you should have to drag it "out" from under the material then ;) | 14:33 |
| vesar | but when icon detaches from the background then it's ok not to clip anymore | 14:33 |
| Saviq | mzanetti, so we'd need a dragging threshold probably | 14:33 |
| mzanetti | vesar: we'll lose any indication of "you can drag now" | 14:34 |
| Saviq | mzanetti, so you only move the icon away when you pass a 1GU or something | 14:34 |
| mzanetti | that's what's happening already | 14:34 |
| Saviq | hmm, that | 14:34 |
| Saviq | mzanetti, not with the corner it's not? | 14:34 |
| vesar | detaching from it's original position is the key. So when ever the drag to organize threshold is exceeded and the quicklist hides and item starts to move with your finger. | 14:34 |
| vesar | mzanetti, Savic, just checked the current implementation and it's actually not as I remembered it. | 14:36 |
| mzanetti | vesar: what I mean is: if you longpress, the quicklist pops up. That indicates: "You triggered the longpress action. Now use the quicklist or not" | 14:36 |
| mzanetti | vesar: but it doesn't indicate in any way that "Oh, and btw, you can also drag it now" | 14:36 |
| vesar | mzanetti, well we don't really have any indication that you can drag it now. But I see where you're coming from. That by unclipping the corner we would indicate that you can drag it now too. right? | 14:38 |
| mzanetti | vesar: it had one with the old highlight | 14:38 |
| mzanetti | vesar: but we removed that. so the clipping corner would somewhat do that | 14:38 |
| mzanetti | vesar: removing that we don't have anything left in that regard | 14:38 |
| vesar | mzanetti, to be honest now that I'm testing it with the latest build I cannot see any highlight indication. | 14:40 |
| mzanetti | vesar: no. we dropped that with the new border glow/shadow | 14:41 |
| vesar | mzanetti, ok I do see it. But anyone not knowing its existence doesnät | 14:41 |
| vesar | doesn't | 14:41 |
| mzanetti | yeah well.. | 14:41 |
| vesar | mzanetti, but I don't have the new highlight in this build do I | 14:42 |
| mzanetti | that should be landed already, yes | 14:42 |
| Saviq | mzanetti, should it? | 14:43 |
| vesar | mzanetti, I'm having the old version then. dark highlight at the top of the icon and bright at the bottom | 14:43 |
| Saviq | mzanetti, the first launcher things are only in silo now | 14:43 |
| Saviq | mzanetti, and I was reviewing the rest today | 14:43 |
| mzanetti | Oh, I thought 2 or sow where already through | 14:43 |
| vesar | Saviq, mzanetti: at least the icon spacing change has landed | 14:44 |
| Saviq | mzanetti, hmm maybe, there were so many! | 14:44 |
| mzanetti | right, the new item glow didn't land yet | 14:44 |
| Saviq | nope, I just reviewed it today | 14:45 |
| Saviq | spacing's the only thing that landed | 14:45 |
| mzanetti | well anyways. vesar when should the clipping of the corner happen? | 14:45 |
| mzanetti | on longpress or on drag start (when the space where it was shrinks) | 14:46 |
| mzanetti | err. go away | 14:46 |
| vesar | mzanetti, Saviq: the shrinking seems to happen only later. Just a sec I formulate it properly | 14:47 |
| mzanetti | yes, the shrinking happens when you dragged more than 1 grid unit | 14:48 |
| vesar | mzanetti, no. try it. | 14:48 |
| mzanetti | vesar: oh right... that's when the quicklist hides again | 14:49 |
| mzanetti | I meant that | 14:49 |
| vesar | mzanetti, yes and that's the time when the icon becomes whole again. | 14:49 |
| mzanetti | ok | 14:50 |
| vesar | mzanetti, other icons desaturate, quicklist disappears, icon unclips (user enters organizing mode) | 14:50 |
| vesar | mzanetti, And don't worry about the highlight we used to have. I don't think we need that anyway. | 14:50 |
| mzanetti | ok | 14:51 |
| kgunn | Saviq: asking here as it might help others, so i need to use "send" on apport-cli when i experience crashing to process the crash files & it'll give me a url to folow to complete the lp bug | 14:54 |
| Saviq | kgunn, yup | 14:54 |
| kgunn | but does apport "know" if the files are related ? | 14:54 |
| kgunn | or do you have to clean out the old ones ? | 14:55 |
| Saviq | kgunn, no, separate bug per .crash | 14:55 |
| kgunn | and does it just pick the most recent... | 14:55 |
| kgunn | ah | 14:55 |
| Saviq | kgunn, you can only have a single .crash file per process | 14:55 |
| Saviq | kgunn, and it will only get replaced after you uploaded them (apport puts a .uploaded file next to it) | 14:55 |
| kgunn | Saviq: yeah, but sometimes they're related | 14:55 |
| Saviq | kgunn, or remove it, of course | 14:56 |
| Saviq | kgunn, yeah, just cross-mention the other bugs, nothing better than that at the moment | 14:56 |
| kgunn | got it | 14:56 |
| Saviq | in the description or comments | 14:56 |
| mzanetti | Saviq: meh... no, the clipping with an item doesn't work | 14:57 |
| mzanetti | Saviq: because it clips after the rotation tranformation | 14:57 |
| Saviq | mzanetti, well, not if you add the rotation transformation on the clipper? | 14:58 |
| Saviq | instead of on the icon? | 14:58 |
| Saviq | mzanetti, I'm not saying, just asking, really | 14:58 |
| mzanetti | Saviq: yeah. but then I need to counter-correct the values everywhere | 14:59 |
| mzanetti | unless I wrap it once again I guess | 14:59 |
| Saviq | right | 14:59 |
| Saviq | that might be best still... | 14:59 |
| mzanetti | Saviq: this freaks me out... if I move and rotate, I can't just invert that again, it'll be somewhere else | 15:18 |
| mzanetti | I could probably make it work stil, but then there's the 180 degree rotation of the whole launcher coming | 15:19 |
| Saviq | mzanetti, lol, ok, leave it be | 15:19 |
| elopio | ping mzanetti: do you have some time to talk about your comments on https://code.launchpad.net/~om26er/unity8/launcher_integration_test/+merge/226087 ? | 15:19 |
| mzanetti | elopio: sure | 15:19 |
| cwayne | Saviq: heya, is favoriting scopes planned soon? I imagine it was likely waiting on the new-header stuff? | 15:20 |
| === gatox is now known as gatox_lunch | ||
| tsdgeos | mhr3: Saviq: where do i get the backgrounds for the scopes in the scopes overview from? | 15:21 |
| elopio | mzanetti: all your comments are on the prerequisite of that branch, that's mine: https://code.launchpad.net/~elopio/unity8/test_open_app_from_launcher/+merge/225112 | 15:22 |
| tsdgeos | mhr3: Saviq: it has to be part of the scope, but a new role? | 15:22 |
| tsdgeos | or what? | 15:22 |
| mzanetti | elopio: ah ok... I just came by this omer's branch today and missed the prerequisite | 15:23 |
| mhr3 | tsdgeos, in customizations? | 15:23 |
| mzanetti | elopio: so still, I don't think we should add all those launcher tests this way | 15:23 |
| elopio | mzanetti: yes, the diff is weird showing all the things he didn't add them. So don't worry about that. | 15:23 |
| mzanetti | elopio: I do understand we want a test that checks if the emulator can find the launcher | 15:23 |
| mzanetti | elopio: but I don't agree with having 6 tests just dragging the launcher in and out | 15:23 |
| mzanetti | elopio: after all we have about 20 qmltests that verify that | 15:23 |
| elopio | mzanetti: so, the tests are there not to check the functionality. The check the functionality too, but we need them because otherwise you can break the helpers that we will be using on the UX tests. | 15:24 |
| mzanetti | elopio: and one AP test adds > 30 seconds to unity's test suite | 15:24 |
| tsdgeos | mhr3: ok, suggested name for the thing? | 15:24 |
| Saviq | tsdgeos, wait | 15:24 |
| Saviq | tsdgeos, you need to hardcode the background in the overview | 15:25 |
| elopio | mzanetti: I know, and I understand. You have those features already covered. But I see no other way to keep the autopilot helperes always working. | 15:25 |
| tsdgeos | mhr3: Saviq: and we probably also need a way for people to override the font color in dash overview? | 15:25 |
| tsdgeos | Saviq: ?¿ | 15:25 |
| mzanetti | elopio: well, if you really think you need to test all the functions, then please add 1 test that tests the launcher functions, not 2 tests for each function | 15:25 |
| Saviq | tsdgeos, we won't support images as backgrounds, just plain color | 15:25 |
| Saviq | tsdgeos, no, why font color override in dash overview? | 15:25 |
| mzanetti | elopio: its enough if one test fails saying "Launcher emulators broken" | 15:25 |
| elopio | mzanetti: I do the helpers test driven, so I have a teset for every code path. | 15:25 |
| tsdgeos | Saviq: so color + logo + font color override | 15:25 |
| tsdgeos | Saviq: we use exactly the same ones we use for the regular scope? | 15:26 |
| tsdgeos | logo is going to be weird | 15:26 |
| tsdgeos | since in scope is horizontal and in here is vertical | 15:26 |
| mzanetti | elopio: well, I guess that's one of the places where theory and practice differ | 15:26 |
| Saviq | tsdgeos, waaait | 15:26 |
| * tsdgeos is waiting :D | 15:26 | |
| mzanetti | elopio: in terms of usefulness I mean | 15:26 |
| Saviq | tsdgeos, where do you want to put that logo? | 15:26 |
| tsdgeos | Saviq: in the middle of the card like stuff shows | 15:26 |
| Saviq | tsdgeos, that's just art from the scope | 15:26 |
| Saviq | tsdgeos, nothing special | 15:27 |
| Saviq | tsdgeos, it's the scopes scope that will submit you that | 15:27 |
| tsdgeos | hmmmmm | 15:27 |
| elopio | mzanetti: well, it's useful for you when you don't have to wait one extra minute while running your autopilot suite. | 15:27 |
| Saviq | daamit :| | 15:27 |
| tsdgeos | oh right | 15:27 |
| elopio | mzanetti: but it's more useful for us when we can pinpoint directly what's the cause of a failed autopilot test | 15:27 |
| tsdgeos | Saviq: what? | 15:27 |
| mzanetti | elopio: can you? | 15:28 |
| mzanetti | I don't think so | 15:28 |
| elopio | we can just reach that point making small tests, each one for a single code path. | 15:28 |
| mzanetti | elopio: well... let me put it that way. It took me 6 hours today to debug 5 AP tests | 15:28 |
| mzanetti | elopio: And while I understand we need some of them, I don't agree with having 6 that just drag the launcher in and out | 15:29 |
| elopio | mzanetti: that's bad. Tell me which autopilot tests are so hard to debug, and I can try to improve them. | 15:29 |
| mzanetti | elopio: all of them. it takes 32 minutes to find out which ones don't work | 15:29 |
| mzanetti | before you can even start working | 15:29 |
| elopio | mzanetti: that's a necessary evil. We can improve that with paralellization and improving the CI lab, but a high level suite will not take less than 10 minutes, ever. | 15:30 |
| elopio | That's a long time to get feedback. But if you were to run those same tests manually, it would take you 1 hour and you will miss many details. | 15:31 |
| elopio | mzanetti: so, don't get me wrong. I understand you here, you invested a lot on a suite with a fast feedback | 15:31 |
| Saviq | tsdgeos, nothing related, ap still not passing here | 15:32 |
| elopio | mzanetti: that's really cool. But unity also needs to get testability helperes to let us check the quality of the image without doing it manually. | 15:32 |
| Saviq | my fault | 15:32 |
| Saviq | :| | 15:32 |
| elopio | with this three branches I'm proposing, we will be able to check that all the apps pined on the launcher work. | 15:33 |
| mzanetti | elopio: yeah, but still not adding 5 minutes to our test suite just to test the helpers (note: this is not even the high level test you're talking about yet). there must be another way | 15:33 |
| elopio | and that all the apps preinstalled on the phone can be launched through the click scope. That will save us a lot of time of manual testing. | 15:33 |
| alesage | hi I'm able to swipe to open and open launcher but tapping on anything (launcher, apps icons) doesn't launch, wonder how I can help to debug | 15:34 |
| elopio | mzanetti: I'm open to try a different way. | 15:34 |
| alesage | top not showing anything unusual | 15:34 |
| mzanetti | elopio: I still think there should be just one test for the launcher helpers... | 15:34 |
| elopio | mzanetti: but with the scope changes, the only thing that let us keep running the click scopes tests was that I added tests for the helpers. | 15:34 |
| mzanetti | elopio: sure... its ok to have some helpers... but the very best example is the last test: | 15:35 |
| elopio | tsdgeos probably hates me because of this :) but without the tests you would have changed all the code without noticing that you broke the testability helpers. | 15:35 |
| mzanetti | elopio: you don't need to check if cklicking outside the screen does not work | 15:35 |
| mzanetti | that's 34 seconds wasted every time one of us runs the suite | 15:36 |
| elopio | mzanetti: what test are you talking about | 15:36 |
| elopio | ? | 15:36 |
| mzanetti | elopio: test_click_dash_icon_with_launcher_closed_must_raise_exception(self): | 15:36 |
| elopio | mzanetti: well, that's precisely the king of things we have learned to do not to spend 5 hours debugging a test. | 15:37 |
| elopio | many many times we try to click something that is not there, just to find a weird autopilot low level exception saying: not found. | 15:37 |
| elopio | that's an important feature of the helpers. When you try to do something and your preconditions are not met, it must tell you that. | 15:38 |
| elopio | adding a test for that is the only way to make sure that the exception will always be raised for that case. | 15:38 |
| elopio | I could use mocks for that one, making it a test that doesn't start unity if you prefer a less cleaner but faster test. | 15:39 |
| elopio | it will live on your code base, so it's your decision what kind of test do you prefer to maintain. | 15:40 |
| mzanetti | elopio: why are you even exporting low level stuff like drag_launcher, etc? shouldn't a higher level test suite just call open_app_from_launcher(index) and that's it? | 15:40 |
| elopio | but completely removing a test for one code path of the helpers is bad for us. We will not be able to rely on that helper. | 15:40 |
| mzanetti | so basically you just export that one function, have 2 test for that and that's it... if the launcher fails to drag in, our qmltests will catch that before | 15:41 |
| elopio | mzanetti: for that suite of tests launches all the apps from the launcher, yes, only click dash icon is necessary. | 15:42 |
| elopio | but rick asked for an additional test to make sure that the launcher will be usable always, and for that we need to do things like open the dash, open the keyboar, open the indicators page | 15:43 |
| elopio | mzanetti: you qml test will not catch errors on the autopilot helpers, like not swiping long enough, or swiping more than what you needed | 15:44 |
| mzanetti | elopio: I think what rick asked for in that particular case should be done as a qmltest in tst_Shell.qml | 15:44 |
| elopio | mzanetti: it won't catch when the assumptions of the autopilot helpers are not met | 15:44 |
| mzanetti | elopio: but your one test that does launch_app_from_launcher() would catch that | 15:44 |
| mzanetti | and that's enough, we don't need 3 that catch that | 15:44 |
| elopio | and it won't catch when you change all the underlying code and update the qml tests, as happened with the scopes changes. | 15:44 |
| elopio | mzanetti: if you put a test for the integration of the launcher with the osk, you would be pulling an additional dependecy to u8. | 15:46 |
| mzanetti | elopio: yes, it would catch that | 15:46 |
| elopio | mzanetti: lets put an example. There's an open_launcher autopilot helper, that swipes from x1 to x2. | 15:46 |
| mzanetti | elopio: not really | 15:46 |
| elopio | lets say that launcher doesn't have a test | 15:46 |
| elopio | and designers tell you you have to do the launcher twice as fat. | 15:47 |
| elopio | you update the qml code, you get qml test failures, you update the qml tests, and you are back to green. | 15:47 |
| mzanetti | elopio: I never said you shouldn't have any tests for you r helpers | 15:47 |
| elopio | how are you going to notice that there's an autopilot test that needs to be updated? | 15:47 |
| mzanetti | elopio: but I think your helpers are too low level, and hence you require too many tests | 15:47 |
| Saviq | alesage, it's something going haywire with Qt's event propagation, suddenly only touch events work (and not touch-converted-to-mouse) | 15:48 |
| Saviq | alesage, not really easy to get info, other than steps to reproduce... | 15:48 |
| Saviq | alesage, I don't think there's a bug for that yet, either | 15:48 |
| elopio | mzanetti: ok, the one that is urgent for me now is the one that clicks a launcher icon. | 15:48 |
| elopio | I can keep the open and close private | 15:49 |
| Saviq | alesage, so please file one | 15:49 |
| mzanetti | elopio: yeah. so IMO we should have a helper: launcher_app_from_launcher and a teste (ONE) that verifies if this works | 15:49 |
| alesage | Saviq, hmm ok--so long as you're aware, ok I'll file a bug although I'm not sure how to reproduce it | 15:49 |
| elopio | mzanetti: but in one week or two I will be automating the experiences when you turn on the phone for the first time. | 15:49 |
| elopio | for that I need to follow the wizard, and I need to open the dash. | 15:49 |
| mzanetti | ok. well, open_dash makes a second valid use case | 15:50 |
| elopio | now, I can't agree with having one single test that checks that you can open the launcher and click the icon. | 15:51 |
| kgunn | Saviq: wow...so apport-cli and lp integration so good...it figures if you're crash has already been reported ? | 15:52 |
| elopio | mzanetti: that's too big. That's what I've learned through months of checking poorly written tests and trying to understand their errors. | 15:52 |
| Saviq | kgunn, well, if the crash sig is good enough | 15:52 |
| kgunn | that's pretty damn cool | 15:52 |
| elopio | mzanetti: I need one test that makes sure that the launcher can be opened. | 15:52 |
| Saviq | elopio, we're testing that in QML | 15:52 |
| elopio | once I'm sure that test is passing, I can use the tested helper, and go one more step. | 15:52 |
| mzanetti | Saviq: yeah, that's the beginning of the discussion :) | 15:53 |
| Saviq | mzanetti, I know, just wanted to restate | 15:53 |
| elopio | Saviq: yes, I know. What I'm trying to explain is that these are not tests for the features. | 15:53 |
| elopio | these are tests for the helpers. | 15:53 |
| Saviq | elopio, yes, but why is it a problem when we are maintaining the helpers? | 15:53 |
| elopio | if the feature is not working, the test helper will fail, of course. | 15:53 |
| mzanetti | elopio: I agree. but you write them like tests for the features | 15:53 |
| elopio | mzanetti: I wrote the code test-driven. It just excercises all the code paths of the helpers. | 15:54 |
| mzanetti | elopio: that's the ideal world, but for that we'd need an ideal test tool | 15:54 |
| mzanetti | and AP really isn't | 15:54 |
| elopio | mzanetti: the ideal tool simulates a real user. Autopilot does that pretty well. | 15:55 |
| elopio | it's slow, of course, users are slow. | 15:55 |
| elopio | it would be faster if we could boot unity faster | 15:55 |
| elopio | it would be faster if we could reflash the phone faster | 15:56 |
| elopio | but if you do autopilot too fast, that's not simulating a real user. | 15:56 |
| mzanetti | elopio: but really, what do you want to test in your high level test? You want to know if launching an app from the launcher actually starts the app, right? | 15:57 |
| mzanetti | ah.. I'm repeating myself | 15:57 |
| elopio | mzanetti: that's step 1, yes. | 15:58 |
| elopio | once that works, step 2 is to check that the launched app can interact with other apps. | 15:58 |
| mzanetti | yeah ok... but that doesn't affect the launcher any more... | 15:58 |
| elopio | mzanetti: if the call to open_launcher breaks at some point, all the UX suite will be read. | 15:58 |
| elopio | well, half, because some other applications will be opened from the scope. | 15:59 |
| mzanetti | elopio: no it won't. you still have the one test that makes sure launch_app_from_launcher() still works | 15:59 |
| mzanetti | and if we mess up in unity, your high level test suite should say: Error opening app from launcher. | 16:00 |
| mzanetti | it doesn't need to say launcher counldn't be dragged from here to there | 16:00 |
| elopio | mzanetti: ok, it's your code base. I can just warn you that it's a bad idea to have a test called launch_app_from_launcher, without a smaller test called open_launcher. | 16:00 |
| elopio | that's what has caused all the headaches that we are daily reducing on the apps test suites. | 16:01 |
| mzanetti | elopio: I'll take that risk... given that I have a whole other test suite that makes sure the launcher can be dragged... | 16:01 |
| mzanetti | and if its really abug in the helper, I'd rather have one to fix, not 6 of them | 16:01 |
| Saviq | elopio, I agree with mzanetti, our "unit" tests are in QML | 16:03 |
| Saviq | elopio, what you need from the acceptance tests are helpers, which we will maintain | 16:04 |
| Saviq | elopio, there's no need for replicating all the individual tests we have in QML with AP ones | 16:04 |
| elopio | mzanetti: that's the real reason for long debug sessions, holes in the code path test coverage. But I can't seem to convince you. | 16:04 |
| elopio | it's your choice. I'll make the changes. | 16:04 |
| Saviq | elopio, that's fine, we need to plug those holes in QML tests, not in AP ones | 16:04 |
| Saviq | mzanetti, hmm, unity8.shell.tests.test_emulators.MainWindowTestCase.test_search fails on my desktop in new-header | 16:06 |
| mzanetti | humm.... still... ok, will check again | 16:06 |
| Saviq | mzanetti, Object not found with name '*' and properties {'objectName': 'searchTextField'}. | 16:07 |
| mzanetti | elopio: so if you really think you want to have each helper's code path, which I'd agree would make sense, then please still do it in one test. | 16:07 |
| mzanetti | elopio: it doesn't make a difference for me if I debug 6*3 lines or 1*24 lines (given they only test one thing after another anyways) | 16:07 |
| mzanetti | elopio: but it makes a huge difference to me if the AP test suite grows by 5 minutes a month | 16:08 |
| mzanetti | elopio: and if we wouldn't have the issue that unity8 + AP would take 30 secs to just start a test, I would also agree it would make more sense to keep them split | 16:08 |
| mzanetti | but that's unfortunately not what it is | 16:09 |
| elopio | mzanetti: for me, it's the other way around. I have to review, refactor and fix like one autopilot test per day, coming from a different project. | 16:09 |
| mzanetti | yeah.. but that's different. you're testing features there, not helpers | 16:09 |
| elopio | mzanetti: no, I'm testing both. Each project is the same as this one. It has tests for their high level features, and helpers for testing them in combination with other projects. | 16:10 |
| elopio | the toolkit is the biggest example. It takes 40 minutes to run everything, but it's a pleasure to find an error on the autopilot code. | 16:11 |
| elopio | I will do it as you want, but I won't spend hours debuging the problems that might arise on the autopilot code, or adjusting them when a big design change is needed. | 16:12 |
| elopio | you will have to take care of that part. | 16:12 |
| elopio | oh, I have an idea. | 16:14 |
| elopio | mzanetti: what if I start unity just once. You said you agree that we should cover all the code path. Starting unity just once, there will be no time difference between putting all the small tests in a big one, or having them split | 16:15 |
| mzanetti | elopio: I guess I'd be fine with that, not knowing yet about other ramifications it might bring. but sounds reasonable atm | 16:18 |
| Saviq | LOL | 16:20 |
| Saviq | autopilot can't cross the screen boundary | 16:20 |
| Saviq | STOOPID, you need to press against the screen edge! | 16:21 |
| === gatox_lunch is now known as gatox | ||
| mzanetti | elopio: hm... thinking about it... I'd probably prefer if you still don't add tests for all the code paths... | 16:22 |
| mzanetti | elopio: for example today I updated the tests for the emulators that trigger search on dash... I already have tested everything that can go wrong in the qml test suites. so I only need to make sure the high level function search_in_dash() works again | 16:23 |
| mzanetti | and not that autopilot can figure everything that can go wrong once again | 16:24 |
| elopio | mzanetti: you are thinking only for your code base. You are not thinking how autopilot raising a proper exception will help tests in the click scope. | 16:25 |
| elopio | funny example you choose, because thanks to that we found that the search textfield was not getting the focus, and that caused the errors. A look at the screenshot showed that the focus was on the keyring dialog. | 16:25 |
| elopio | so 30 seconds to diagnose the error. No need to rerun anything, just take a look at jenkins. | 16:26 |
| elopio | but I will comply. | 16:26 |
| mzanetti | elopio: I'm not exactly sure what the click scope tests are. But I assume they are testing something that isn't related to the search, but just need the search to get to the actual test. is that correct? | 16:29 |
| Saviq | elopio, also, your example is flawed as it doesn't need any coverage to notice this once you see the video | 16:30 |
| Saviq | elopio, you could blindly tap on known x/y coordinates and still in the video you'd see that there's a password prompt | 16:30 |
| mzanetti | so why would they care what inside unity has gone wrong? they just need the info: Searching failed. But for that we have the test for the emulator that makes sure the search actually works by the time it gets to the click scope | 16:30 |
| elopio | mzanetti: correct. We have a fake server that puts a specific app on the dash, and we need to search for it. | 16:30 |
| mzanetti | and if it doesn't work, I'd rather debug it in unity with the qmltests and mke the emulator work again | 16:31 |
| elopio | Saviq: the hard part is how know what's the right video to look at. | 16:31 |
| Saviq | elopio, you get one per failed test, no? | 16:31 |
| elopio | in this case, there was one failure that provided no information, the one that opened the dialog. | 16:32 |
| elopio | and one that provided a clear clue of where to look, with a clear message of what was going wrong. | 16:32 |
| Saviq | elopio, btw, any idea why suddenly my autopilot tests would require double taps to trigger clicks in the UI? | 16:32 |
| elopio | Saviq: no, if we split the launch test in two, and the open fails, we will have two failures. But if we have written the open helper properly, the failure will be easy to understand in the two, and will be a one line fix. | 16:34 |
| elopio | Saviq: what are you testing? We have seen that on the header when the popup was stealing the focus | 16:34 |
| Saviq | elopio, lockscreen here, and only on desktop | 16:34 |
| elopio | and on the address book forms, when swiping over a focused textfield didn't work. | 16:34 |
| Saviq | elopio, but really, we have those low-level tests in QML, and that's where we want to keep our coverage | 16:35 |
| elopio | Saviq: hard to tell. If you can reproduce it manually, is probably the focus. If you can't, there must be something wrong on autopilot, but it hasn't changed for a while. | 16:35 |
| Saviq | elopio, I can actually reproduce with my mouse, so it's rather weird indeed | 16:37 |
| elopio | Saviq: if you push it, I can give it a try. | 16:37 |
| Saviq | elopio, nah, it must be something local anyway, is fine on device (and in jenkins) | 16:38 |
| elopio | ok. | 16:38 |
| Saviq | mterry, hey, I noticed one thing in u-s-c, if I stop unity8, it will only get off screen when I launch it back, rings a bell? | 17:08 |
| greyback | confirmed | 17:09 |
| mterry | Saviq, you mean the last frame of unity8 stays on screen? | 17:09 |
| Saviq | mterry, yes | 17:09 |
| mterry | Saviq, interesting. If unity8 crashes on my phone, I see the spinner. Do you see that, and are saying this only happens on 'stop' or does this happen for you when it crashes too? | 17:10 |
| === alan_g is now known as alan_g|EOD | ||
| Saviq | mterry, well, if it crashes, it gets restarted straight away | 17:10 |
| Saviq | mterry, and yeah, the spinner shows up for 2 seconds or so | 17:11 |
| Saviq | on unity8 startup | 17:11 |
| mterry | Saviq, sure... But starting unity8 doesn't cause the spinner. Having no registered Mir session causes the spinner to appear. So it's odd that there is a difference between stop and restart | 17:12 |
| Saviq | mterry, I'll try and see again in a mo, running ap now | 17:12 |
| elopio | mzanetti: on the unity code base, you will never get an error because the search was not focused because you don't interact with external things. | 17:13 |
| elopio | but on the helper we have code for that case, and we make sure that it shows the right error every time by having a test that will break if your assumptions change. | 17:13 |
| elopio | sorry, I went to a meeting and forgot to press enter :) | 17:13 |
| elopio | I'll work on the branches. I'll be back when they are ready. | 17:14 |
| Saviq | elopio, sure, verify the field is focused, and interrupt the test if it's not | 17:14 |
| Saviq | elopio, but don't interrupt it if it is | 17:14 |
| Saviq | elopio, I think that was what mzanetti wanted - not a step-by-step "incremental" test, but one that runs the whole needed set of steps in one test | 17:15 |
| mzanetti | Saviq: elopio: yes. (was having dinner) | 17:25 |
| elopio | Saviq, mzanetti: please review the branch: https://code.launchpad.net/~elopio/unity8/test_open_dash/+merge/224553 | 17:36 |
| elopio | if you like the style and the types of tests I'm adding, I'll do the same for the rest. | 17:36 |
| elopio | if not, let me know and I'll make the changes. | 17:36 |
| Saviq | mterry, well, yeah, confirmed, I didn't even have the unity8 process any more, while still looking at the greeter | 17:45 |
| Saviq | mterry, only as I went "start unity8" did the spinner come up | 17:45 |
| mterry | Saviq, fascinating... either Mir is holding on to the session somehow or the USC spinner logic isn't 100%. File a bug against USC | 17:47 |
| Saviq | mzanetti, if around... http://paste.ubuntu.com/7771402/ fixes ap for me on new-header | 18:16 |
| mzanetti | Saviq: oh cool, thanks | 18:17 |
| mzanetti | I wonder how that got lost... | 18:19 |
| karni_ | mhr3: candy :D https://bugs.launchpad.net/savilerow/+bug/1339839 | 18:26 |
| ubot5 | Ubuntu bug 1339839 in unity-scopes-api "Search in scope resets the selected department" [Undecided,New] | 18:26 |
| karni_ | mhr3: got it confirmed by Kyle (he'll mark it confirmed momentarily) | 18:26 |
| === karni_ is now known as karni | ||
| === karni is now known as Guest85816 | ||
| === Guest85816 is now known as karni | ||
| Saviq | mterry, bug #1339843 | 18:39 |
| ubot5 | bug 1339843 in unity-system-compositor (Ubuntu) "Last user session frame visible until restarted" [Undecided,New] https://launchpad.net/bugs/1339843 | 18:39 |
| mterry | cool | 18:40 |
| Saviq | mzanetti, :| there's a conflict between two of your branches, unless you're around and can fix, I'll land without | 19:26 |
| Saviq | https://ci-train.ubuntu.com/job/landing-018-1-build/110/console | 19:26 |
| mzanetti | Saviq: fixing | 19:26 |
| Saviq | mzanetti, thanks | 19:26 |
| mzanetti | Saviq: does it make things more complicate if I resubmit the MP? | 19:29 |
| mzanetti | with the prereq branch | 19:29 |
| Saviq | mzanetti, no, just found out it's required, really | 19:30 |
| mzanetti | Saviq: well, you could drop one of them | 19:30 |
| Saviq | mzanetti, train reorders branches based on prereq | 19:30 |
| mzanetti | whatever is easiest for you | 19:30 |
| Saviq | mzanetti, resubmit's fine | 19:30 |
| mzanetti | ok | 19:30 |
| mzanetti | Saviq: https://code.launchpad.net/~mzanetti/unity8/launcher-update-home-button-design/+merge/226200 | 19:31 |
| mzanetti | Saviq: strangely it didn't conflict here though | 19:31 |
| Saviq | mzanetti, ok let's see what train says, to reproduce conflicts I sometimes had to do exactly the merges the train did | 19:33 |
| Saviq | mzanetti, in the same order (well, those that touch the conflicting file) | 19:33 |
| mzanetti | yeah... but now the prereq branch should change that hopefully | 19:34 |
| Saviq | mzanetti, yeah, merged fine here | 19:35 |
| mzanetti | ok, great | 19:36 |
| Saviq | oof, it merged... | 19:46 |
| mzanetti | Saviq: thanks | 19:48 |
| Saviq | mzanetti, U2 | 19:52 |
| mzanetti | Saviq: oh, btw... I have my dogfooding phone in the locked up state atm. anything useful I could get out of it? | 19:55 |
| Saviq | mzanetti, ideally connect to it with gdb | 19:55 |
| Saviq | gdb -p `pidof unity8` | 19:55 |
| mzanetti | yeah | 19:55 |
| Saviq | mzanetti, and start installing symbols to get as much out of it as possible | 19:55 |
| mzanetti | attached, but obviously no symbols around yet | 19:56 |
| Saviq | yup | 19:56 |
| Saviq | mzanetti, do you have your df phone rw? | 19:56 |
| mzanetti | Saviq: yep, but otherwise still pristine | 19:56 |
| mzanetti | well, upgraded since half a year with OTA | 19:56 |
| Saviq | mzanetti, well, now's the time when it will stop ;) | 19:57 |
| mzanetti | I figured, yeah :D | 19:57 |
| Saviq | mzanetti, but it's easy to just get a pristine image | 19:57 |
| Saviq | mzanetti, system-image-cli -b0 | 19:57 |
| Saviq | it will dl a full image and replace the one you have | 19:58 |
| mzanetti | yeah. I'm not so worried about it... the address book is messed up anyways still | 19:58 |
| mzanetti | so I might even take the chance to start from scratch after half a year | 19:58 |
| mzanetti | Saviq: I still have a bit more space for dbgsyms before I'll trash it. If you see anything suspicious here's what I have so far http://paste.ubuntu.com/7771851/ | 20:11 |
| === salem_ is now known as _salem | ||
| Saviq | mzanetti, as dednick mentioned, QWaitCondition in thread 32 looks interesting | 20:16 |
| Saviq | and 31, for that matter | 20:16 |
| Saviq | oh huh | 20:16 |
| Saviq | requestAuth is not something I'd expect | 20:17 |
| mzanetti | oh yeah... that's interesting indeed | 20:17 |
| Saviq | mir::frontend::Surface::swap_buffers_blocking | 20:17 |
| Saviq | wonder if it didn't resume rendering after resuming from suspend... | 20:18 |
| mzanetti | here's one with moar symbols in that areas: http://paste.ubuntu.com/7771898 | 20:20 |
| mzanetti | Saviq: clock is still at 13:31 | 20:20 |
| Saviq | mzanetti, well, yeah, that just means it hung ~that time | 20:20 |
| Saviq | and snapshotting... | 20:21 |
| mzanetti | Saviq: snapshotting? | 20:22 |
| mzanetti | Saviq: ah... so, think I should install any other dbgsyms? | 20:22 |
| Saviq | __invoke<mir::scene::SnapshottingFunctor> | 20:22 |
| Saviq | mzanetti, you got qtdeclarative5-dbg yet? | 20:23 |
| Saviq | kgunn, we might need to escalate bug #1339700 | 20:28 |
| ubot5 | bug 1339700 in unity8 (Ubuntu) "Device locks randomly on welcome screen" [Critical,Confirmed] https://launchpad.net/bugs/1339700 | 20:28 |
| kgunn | yeah...i was just wondering | 20:28 |
| kgunn | Saviq: is mterry on it already ? | 20:29 |
| Saviq | kgunn, it reached blocker status today, not easy to reproduce | 20:29 |
| kgunn | or are you saying we need some outside help ? | 20:29 |
| Saviq | kgunn, I'd like Mir folk to have a look at the symbols at least | 20:29 |
| kgunn | no problem... | 20:29 |
| mzanetti | still downloading qtdeclarative-dbg here | 20:29 |
| mzanetti | will post the updated ones to the bug | 20:29 |
| Saviq | mzanetti, thanks | 20:30 |
| Saviq | kgunn, I posted a few things looked suspicious to me | 20:30 |
| kgunn | Saviq: ok, i'll get someone....i gotta reboot my machine is being hateful | 20:30 |
| mzanetti | that didn't help much | 20:38 |
| kgunn | Saviq: so i actually have a N4 stuck in the state of locked screen freeze..is there anything you need or i can do ? | 20:40 |
| Saviq | kgunn, nothing special, no | 20:42 |
| Saviq | kgunn, I think we have enough data that now someone just has to sit down and get into a gdb session with a locked-up phone | 20:44 |
| mzanetti | still installing qtbase, as one of the QWaitcondition threads starts in there... | 20:45 |
| mzanetti | maybe I can get a little more out. but for sure not much | 20:46 |
| mzanetti | Saviq: unless you see something else I would reboot the phone then to have it usable again | 20:46 |
| kgunn | Saviq: so AlbertA is gonna take a look... | 20:51 |
| Saviq | mzanetti, yeah, nothing else | 20:53 |
| Saviq | kgunn, thanks | 20:53 |
| === _salem is now known as salem_ | ||
| Saviq | mzanetti, we'll need a little more work on the draggable launcher icon, I get a frame or so of the old icon when dragging different icons | 21:10 |
| === ajmitch_ is now known as ajmitch | ||
| === salem_ is now known as _salem | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
