| coltim | hi - I'm having an issue with my 14.10 unity and was wondering if this would be an appropriate place to seek assistance | 01:05 |
|---|---|---|
| === duflu_ is now known as duflu | ||
| penghuan | does libbamf can be use in python like libwnck | 08:06 |
| Saviq | penghuan, there's GI bindings for bamf, so you definitely can use it, whether that's "like libwnck" I'm not sure | 08:26 |
| facubatista | Holas | 08:57 |
| MacSlow | facubatista, ola | 08:59 |
| facubatista | MacSlow, hey :) | 08:59 |
| tsdgeos | facubatista: isn't it early for your daily hola? | 09:03 |
| facubatista | tsdgeos, it is... but couldn't sleep, and took the oportunity to do some work with somebody in opposite timezone :) | 09:04 |
| tsdgeos | :) | 09:04 |
| tsdgeos | it's a good thing we're spread and you can use your sleeplessness | 09:04 |
| facubatista | :D | 09:04 |
| penghuan | Saviq, thanks! gi binding is enough for me | 09:25 |
| tsdgeos | Mirv: Saviq: good news \o/ | 10:03 |
| tsdgeos | ppa5 doesn't have the black screen of death | 10:03 |
| tsdgeos | so it's really the reduce-relocations bug that crept up | 10:03 |
| tsdgeos | now we need to find someone with ld expertise i guess | 10:04 |
| Mirv | tsdgeos: \o/ so even without qtdeclarative and unity8 rebuild? I did qtdeclarative rebuild 3h ago but because PPA publishings were broken (until now it's slowly getting back working) it didn't get visible | 10:05 |
| tsdgeos | Mirv: yep | 10:05 |
| Mirv | tsdgeos: so it's that removing of reduce-relocations, what about the removing of the -Bsymbolic option? | 10:05 |
| tsdgeos | unity8 still doesn't work because needs https://code.launchpad.net/~aacid/unity8/unitySortFilterProxyQML | 10:05 |
| tsdgeos | Mirv: reduce relocations does remove the bsymbolic | 10:05 |
| tsdgeos | or the other way around | 10:06 |
| tsdgeos | not sure | 10:06 |
| Mirv | I mean, also that patch enabling bsymbolic on armhf was disabled, in addition to removing reduce-relocations. I'm first to admit I've no idea about your debugging craze in December and how these two things related to each other :) I'm just wondering whether with the patch remaining in use, but reduce-relocations still removed, the result would be the same or if they go hand in hand. | 10:07 |
| tsdgeos | they are the same thing | 10:07 |
| tsdgeos | see http://paste.ubuntu.com/9692057/ | 10:07 |
| tsdgeos | basically reduce_relocations means using bsymbolic | 10:08 |
| tsdgeos | so if we remove the patch to enable bsymbolic we need to remove the reduce_relocations call too | 10:08 |
| Mirv | the patch only affects the test http://is.gd/XFELcp - so my understanding would be that with the patch intact, it allows using reduce-relocations on non-x86 (so that it has an effect). so for armhf, same result for armhf could be achieved by keeping reduce-relocations (enable bsymbolic) but removing the patch so that the bsymbolic test would always return fail on armhf | 10:12 |
| Mirv | anyhow, we most of all care about armhf so debugging that so that the feature could be re-enabled would be nice | 10:12 |
| tsdgeos | you're going to need someone that understands the linker | 10:13 |
| tsdgeos | if you revert http://is.gd/XFELcp but keep the reduce-relocations in configure | 10:14 |
| tsdgeos | the armhf build fail | 10:14 |
| tsdgeos | saying "-reduce-relocations was requested but this compiler does not support it" | 10:14 |
| tsdgeos | so if you want reduce-relocations on non-arm (which i guess we do) you need two different configure calls, one for arm and the other for non-arm | 10:15 |
| Mirv | oh, ok! thanks for explaining. | 10:16 |
| Mirv | that's of course probably how I ended up with that patch in the first place in May for 5.3.0... just forgotten about it | 10:20 |
| === vrruiz_ is now known as rvr | ||
| mzanetti | how can I make the tutorial show up at boot? | 10:53 |
| mzanetti | without wiping | 10:53 |
| mzanetti | Cimi: ^ | 10:53 |
| Saviq | mzanetti, phablet-config | 11:05 |
| mzanetti | Saviq: thanks | 11:06 |
| tsdgeos | i cancel a CI job and it appears as failed :/ | 11:47 |
| Saviq | tsdgeos, yeah, that's unfortunate | 11:48 |
| Saviq | tsdgeos, filed a bug #1408627 | 11:52 |
| ubot5 | bug 1408627 in Ubuntu CI Services "Cancelling a -ci job should not vote "Needs fixing"" [Undecided,New] https://launchpad.net/bugs/1408627 | 11:52 |
| tsdgeos | guys do you think something like http://paste.ubuntu.com/9692360/ makes sense? | 11:54 |
| tsdgeos | Saviq: mzanetti: greyback_: ↑↑ | 11:56 |
| mzanetti | tsdgeos: without this it segfaults, right? | 11:56 |
| tsdgeos | not sure about no item | 11:56 |
| tsdgeos | but without the item.visible | 11:56 |
| tsdgeos | it just "clicks there" | 11:57 |
| tsdgeos | clicking potentially somewhere else | 11:57 |
| mzanetti | right. yeah | 11:57 |
| Saviq | tsdgeos, sounds like a good idea to improve failure info | 11:57 |
| tsdgeos | which if the item is not visible | 11:57 |
| tsdgeos | it's most likely not what you wanted | 11:57 |
| mzanetti | tsdgeos: definitely a +1 on line 9 and 10 | 11:57 |
| greyback_ | is odd tho, as invisible item still has geometry | 11:57 |
| mzanetti | on the invisible one.. not so sure | 11:57 |
| mzanetti | I think I do that intentionally somewhere | 11:57 |
| mzanetti | to make sure the click does not trigger anything | 11:57 |
| tsdgeos | mzanetti: you click on something that's not visible? | 11:57 |
| greyback_ | but yeah, no point interacting with invisible things | 11:58 |
| mzanetti | yeah well, it's usually visible | 11:58 |
| tsdgeos | seems like abusing mouseClick | 11:58 |
| tsdgeos | mzanetti: well then you do a expectFail | 11:58 |
| tsdgeos | and click | 11:58 |
| tsdgeos | maybe? | 11:58 |
| tsdgeos | if you want to check that clicking did nothing? | 11:58 |
| mzanetti | I still need to click, no? | 11:58 |
| mzanetti | dunno | 11:58 |
| tsdgeos | yeah dunno :D | 11:59 |
| tsdgeos | i realizeed i was clicking on an invisible item on one of my tests | 11:59 |
| mzanetti | or maybe you have a stack of mouse areas or something and want to trigger different things on different states of the app | 11:59 |
| tsdgeos | and i would had hoped someone told me | 11:59 |
| mzanetti | so you use the click() still on the topmost mouse area, regardlesss if that one is visible or not | 11:59 |
| tsdgeos | instead of just going "oh sure i'll click there" | 12:00 |
| mzanetti | I could live with both I guess | 12:00 |
| === MacSlow is now known as MacSlow|lunch | ||
| === alan_g is now known as alan_g|lunch | ||
| === MacSlow|lunch is now known as MacSlow | ||
| MacSlow | Saviq: since when does the run.sh script no longer start unity8 itself, but only the dash? | 13:38 |
| Saviq | MacSlow, since we messed up https://code.launchpad.net/~saviq/unity8/no-sigstop-main/+merge/245758 | 13:39 |
| MacSlow | Saviq, ah ok... trying... thanks | 13:41 |
| === alan_g|lunch is now known as alan_g | ||
| * Cimi lunch | 14:14 | |
| tsdgeos | so for those tests i have that mouseClikcs are not being registered | 14:27 |
| tsdgeos | i don't think what daniel did can be the culprit right? that was only for touches, right? | 14:27 |
| mterry | Saviq, there is a (flaky) test failure in my tutorial-new-screens MP that is due to a "libIndicatorsFakeQml.so: undefined symbol: _ZN14UnityMenuModel12setModelDataERK8QVariant" error. Now... I've seen this myself locally for any test that loads the Shell, but it's very flaky. I had mentioned that I see it before, but no one else could verify at the time. Now that jenkins sees it too, I'm thinking it's a real error and not something my lapto | 14:39 |
| mterry | p just does. Any clues on why it would happen (and be so flaky? seems like a race on loading libraries...?) | 14:39 |
| Saviq | tsdgeos, yeah, touches only | 14:40 |
| Saviq | mterry, hmm | 14:40 |
| Saviq | mterry, sounds quite weird | 14:41 |
| * mterry looks into it | 14:43 | |
| mterry | Saviq, ah, I think it's just a missing LD_LIBRARY_PATH pointing at the fake QMenuModel. I don't know why it would be flaky though, I would expect consistent failure | 14:54 |
| Saviq | mterry, indeed | 14:55 |
| mterry | And doesn't explain why I saw that error on normal shell tests either in the past, unless we recently cleaned up that linking situation | 14:56 |
| Saviq | mzanetti, think you could test http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=landing-024 when it builds? I'm testing rtm | 15:29 |
| Cimi | mterry, you added both chevron and tick png, but while for tick you used gridUnit, you used pixels for chevron | 17:51 |
| Cimi | mterry, are those assets supposed to scale or not? | 17:51 |
| === charles_ is now known as charles | ||
| kgunn | mterry: so rickspencer is testing the proposed fix for "power dialog on resume"....it's in silo3 for rtm | 19:47 |
| kgunn | however, he's seeing | 19:47 |
| mterry | uh oh | 19:47 |
| * mterry gets an rtm device | 19:47 | |
| kgunn | it seems like the 3 things in combination that trigger this are: | 19:47 |
| kgunn | 1. you are "roaming" on 2g because you are away from a known AP | 19:47 |
| kgunn | 2. you get an sms when the phone is sleeping | 19:47 |
| kgunn | 3. you try to turn on the phone while still roaming | 19:47 |
| kgunn | though, it could be a fluke that I had the bug with this combination twice in a row | 19:47 |
| kgunn | mterry so he says he was at home on wifi, then left home...so began to roam, dunno i f that matters as a precondition | 19:48 |
| mterry | kgunn, what is the symptom? (just the power dialog showing, or something worse, like a crash?) | 19:48 |
| kgunn | mterry: correct...nothing other than a laggy startup + the unexpected sight of the power dialog | 19:49 |
| kgunn | also... | 19:49 |
| kgunn | <rickspencer3> last night, I could not even get into the phone | 19:49 |
| kgunn | the screen kept turning off when I tried to dismiss the dialog | 19:49 |
| kgunn | <kgunn> oh wow...weird | 19:49 |
| kgunn | <rickspencer3> today I just had to dismiss it a bunch of times | 19:49 |
| rickspencer3 | o/ | 19:50 |
| mterry | rickspencer3, hi! | 19:50 |
| kgunn | mterry: did you have reliable repro steps? | 19:50 |
| rickspencer3 | hi mterry | 19:50 |
| rickspencer3 | nice to see you again! | 19:50 |
| rickspencer3 | it's been a looong time :) | 19:50 |
| mterry | rickspencer3, is the problem that the silo did not improve *anything* or that it got better, but there are still cases where the dialog shows and it shouldn't? | 19:50 |
| mterry | rickspencer3, :) | 19:50 |
| * rickspencer3 assumes he has some MPs for quickly from mterrt to ack | 19:50 | |
| rickspencer3 | mterry, hard to say | 19:50 |
| mterry | rickspencer3, I wouldn't be so sure... ;) | 19:50 |
| rickspencer3 | I would say, it didn't get better | 19:50 |
| rickspencer3 | though, the impact was way worse last night, so maybe it got better | 19:51 |
| kgunn | rickspencer3: do you seem to see it more than most people? | 19:51 |
| rickspencer3 | kgunn, well, I was getting the issue fixed in silo 7 a lot | 19:51 |
| * kgunn wonders if people are just dismissing, but not complaining | 19:51 | |
| mterry | rickspencer3, bummer -- it's a hard bug to reproduce, but my reproduction steps don't look anything like yours | 19:51 |
| rickspencer3 | mterry, what are your repro steps? | 19:51 |
| mterry | rickspencer3, usually involve low-memory or high-load or huge background image for the greeter to load. Basically anything to slow down the shell's ability to load the greeter longer than 2s, which is the threshold for the dialog to appear | 19:52 |
| mterry | rickspencer3, but yours are telephony related | 19:52 |
| rickspencer3 | mterry, so, actually that is commiserate with my experience | 19:52 |
| kgunn | high cpu load due to telephony? | 19:53 |
| rickspencer3 | kgunn, well, first high cpu load due to NM and location-service chatting back and forth | 19:53 |
| rickspencer3 | which was fixed in silo 7 | 19:53 |
| rickspencer3 | not, it seems, based on 2 cases, that receiving an sms causes the phone to get busy | 19:54 |
| rickspencer3 | though not as busy as the NM/location problem | 19:54 |
| rickspencer3 | I came back home and plugged it into my 'puter asap, and top said that message+ was causing dbus daemon to take up 96% of a cpu core | 19:54 |
| rickspencer3 | though it quickly died away | 19:54 |
| kgunn | mm | 19:54 |
| rickspencer3 | so, my suspicion, which experience suggests is totally wrong ... | 19:55 |
| rickspencer3 | is that receiving an sms when the phone is sleeping makes the phone busy when you try to wake it up | 19:55 |
| rickspencer3 | mterry, does that sound like it might be similar to your repro steps? | 19:56 |
| mterry | rickspencer3, ok well good. Sounds like we see high load as a trigger for the bug. But bummer that the patch doesn't work for you. I'll try testing the silo on my rtm device and seeing if I can make a better patch | 19:56 |
| rickspencer3 | mterry, but it seems like we could easily set up a test to cause high laud on resume, right? | 19:56 |
| mterry | rickspencer3, yeah I'll see if I can make a little busy-wait script for easier reproduction | 19:57 |
| kgunn | load giant image | 19:57 |
| kgunn | or some such | 19:57 |
| kgunn | thanks mterry | 19:57 |
| mterry | kgunn, that was previous repro step, but it wasn't super reliable. I'll see about loading cpu | 19:57 |
| rickspencer3 | now, if receiving an sms while asleep causes a cpu spike, we should also fix that ;) | 19:58 |
| mterry | rickspencer3, either that or there's a weird correlation between sms and power dialog. Which should also be fixed :) | 19:58 |
| kgunn | rickspencer3: well...i could see that, you wanna see texts right away...so burn & churn on cpu seems like that'd be a good thing | 19:59 |
| rickspencer3 | in any case, obviously the power dialog needs to be robust in the case of a busy CPU :) | 19:59 |
| kgunn | right | 19:59 |
| rickspencer3 | kgunn, yeah, maybe you are right | 19:59 |
| rickspencer3 | maybe it's not a bug | 19:59 |
| rickspencer3 | hi jfunk, you missed all the action | 19:59 |
| rickspencer3 | jfunk, so, mterry is going to: | 19:59 |
| rickspencer3 | 1. install silo 3 and see if he can repro the issue himself with it installed | 19:59 |
| rickspencer3 | 2. try to create a test condition where the phone has high cpu load on resume so that we can make an automated test for this condition | 20:00 |
| mterry | rickspencer3, (to be pedantic, the issue is high CPU load on suspend, not resume. I think) | 20:01 |
| rickspencer3 | mterry, oh? | 20:02 |
| rickspencer3 | mterry, for me, this is stuff that happens on resume | 20:02 |
| mterry | rickspencer3, well... that's the issue my patch tries to fix. But if the patch isn't fixing it... | 20:02 |
| mterry | rickspencer3, well you wouldn't know, would you? The power dialog just sits there while suspended | 20:02 |
| rickspencer3 | mterry, huh | 20:02 |
| rickspencer3 | mterry, so, I unplug my phone and put in my pocket | 20:03 |
| rickspencer3 | it doesn't know it's roaming until I leave, after it's suspended, right? | 20:03 |
| mterry | rickspencer3, (the greeter is loaded when suspending, but if loading it takes over 2s, the power dialog shows because we never handle the "power button release" event -- that's what I *thought* was the problem. Again, if the silo doesn't fix it, maybe more is happening | 20:03 |
| mterry | rickspencer3, there could be a similar problem happening on resume with the power button event handle taking too long | 20:04 |
| mterry | So maybe two bugs here with same symptom, and I only fixed one | 20:04 |
| rickspencer3 | mterry, yeah, so .. | 20:04 |
| rickspencer3 | this *only* happens to me when I leave my office or my apartment | 20:04 |
| rickspencer3 | so it seems like there is no way it could be on suspend | 20:04 |
| mterry | rickspencer3, fair. Like I said, I'm guessing that it can happen on both, and I've only fixed one side of it | 20:05 |
| rickspencer3 | yeah | 20:05 |
| rickspencer3 | ok, thanks mterry | 20:05 |
| kgunn | mterry: so i think since it's on suspend....its related to this bug no ? bug https://bugs.launchpad.net/qtmir/+bug/1355173 | 20:10 |
| ubot5 | Launchpad bug 1355173 in unity8 (Ubuntu) "Switching windows with a Trusted Prompt Session active loses the trusted prompt session" [Critical,In progress] | 20:10 |
| kgunn | dang it...not that one | 20:10 |
| mterry | phew | 20:10 |
| mterry | :) | 20:10 |
| kgunn | bug 1309915 | 20:10 |
| ubot5 | bug 1309915 in qtmir (Ubuntu RTM) "foreground app should keep wakelock open until actual suspend happens (aka camera takes ~5 seconds to be responsive after waking phone)" [Critical,In progress] https://launchpad.net/bugs/1309915 | 20:10 |
| kgunn | that lag happens b/c apps weren't allowed to suspend but began to | 20:11 |
| mterry | kgunn, I'm not sure if it's related to that or not... | 20:11 |
| * kgunn remains suspicious it's related.... | 20:15 | |
| kgunn | greyback__: what do you think ^ ? could that be the seed for mterry's bug ? | 20:15 |
| kgunn | greyback__: basicallly, cpu spike causing power dialog to show on resume sometimes and the spike being caused | 20:16 |
| kgunn | by the suspend happening on the resume...cause it didn't have time to do it on shutdown | 20:16 |
| kgunn | sleep rather | 20:16 |
| mterry | kgunn, well I know that CPU spike on suspend can cause it. I'm not sure what the cause on resume is yet. It might be triggered by CPU spike or not. I haven't investigated that side of things yet | 20:17 |
| jfunk | hey mterry, lmk if you need any support from the QA team in terms of AP expertise etc when you've got the steps locked down | 20:39 |
| mterry | kgunn, jfunk: ok.... I can confirm that silo3 fixes the bug I was trying to fix... "Slow greeter load causing the power dialog to show on suspend". Of course now it seems there are more ways to trigger that dialog. Let me get reproduction steps / script for ease of QA. I think as long as the silo doesn't make anything worse, we should land it while I separately investigate other ways the dialog appears | 20:41 |
| kgunn | mterry: +1 for me | 20:41 |
| mterry | jfunk, kgunn, rickspencer3: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1383277/comments/18 lists my reproduction steps and a tiny script to load the CPU on a krillin. jfunk, that script is not perfect for automation yet, it leaves detached CPU bombs hanging around that have to manually be killed. Maybe that's "good enough" if automation is going to reboot anyway... But let me know if I should work on something more elegant | 20:55 |
| ubot5 | Launchpad bug 1383277 in Canonical System Image "Power dialog sometimes shown on resume" [Critical,In progress] | 20:55 |
| mterry | jfunk: are you the QA contact for rtm silo 003 as well? | 20:57 |
| Saviq | mzanetti, messages icon is only getting bright now (i.e. in vivid), no color | 20:57 |
| mzanetti | oh | 20:58 |
| jfunk | mterry: no, that would be in #qa just ping 'ops-team' | 21:03 |
| jfunk | mterry: though you need to mark it as ready for QA | 21:03 |
| jfunk | and it would show up automatically on their Qeue | 21:03 |
| jfunk | queue | 21:03 |
| mterry | kgunn, was this problem blocking silo 003? Do we need to provide guidance for approving it with the caveat that it won't solve all power dialog problems? | 21:03 |
| jfunk | ToyKeeper: can you read mterry's comment above re: script and steps to repro | 21:05 |
| jfunk | ToyKeeper: since I suspect you'll be the one running the verification | 21:05 |
| mterry | jfunk, (I don't know where silo 003 was in its landing process yet) | 21:05 |
| jfunk | ToyKeeper: if you could distill the steps to repro and evaluate the script for suitability as part of a regression run that would be swell, please email the results of your investigation to the QA team | 21:06 |
| ToyKeeper | jfunk: Sure, I'm just working on silo 7 at the moment. | 21:06 |
| jfunk | ToyKeeper: I thought that one was under wraps | 21:06 |
| jfunk | ToyKeeper: when I look at the trello it doesn't appear to be in progress | 21:07 |
| ToyKeeper | jfunk: If so, great. Hardware just showed up for testing it, and I'm getting that set up. | 21:07 |
| jfunk | ToyKeeper: I think it's been put to rest, the silo 3 is more "of the essence" | 21:07 |
| jfunk | though that hardware will come in handy for future regression runs | 21:07 |
| ToyKeeper | At least, the plan was to add it to regression testing, so I'll need to get it set up within a few days. | 21:07 |
| jfunk | ToyKeeper: ack | 21:08 |
| jfunk | ToyKeeper: if you could please work with mterry on this silo and help him understand what to do to move it forward | 21:08 |
| ToyKeeper | Yup. | 21:09 |
| ToyKeeper | It'll take a few minutes to get a krillin reflashed. | 21:11 |
| Saviq | mterry, nothing's blocking silo 003 afaict, I just didn't manage to test it yet | 21:13 |
| mterry | Saviq, ok cool -- I was just called in to verify that one of my branches in it did in fact work after a brief scare. So I just wanted to make sure it's back on track. Sounds like it's fine, we didn't stop the line for that issue yet | 21:14 |
| ToyKeeper | mterry: BTW, what does the background image have to do with the bug? | 21:14 |
| mterry | ToyKeeper, the technical cause is that when handling the request to suspend, the shell loads the greeter. Which includes loading the background image. While it loads the greeter, it blocks handling the "power button released" event. So if we take longer than 2s, the shell thinks the user did a long press once it eventually does handle the "release" event. And so it shows the power dialog | 21:16 |
| mterry | ToyKeeper, so if we have a large image and are under load, we can easily take longer than 2s | 21:16 |
| mterry | ToyKeeper, the fix I used was to not block handling the "released" event | 21:16 |
| ToyKeeper | Makes sense. :) | 21:17 |
| ToyKeeper | Still catching up on scrollback. | 21:17 |
| Saviq | mterry, on that note, I think what greyback__'s doing (keeping wakelock while any app's not suspended) will help with that as well | 21:19 |
| Saviq | i.e. bug #1309915 | 21:19 |
| ubot5 | bug 1309915 in qtmir (Ubuntu RTM) "foreground app should keep wakelock open until actual suspend happens (aka camera takes ~5 seconds to be responsive after waking phone)" [Critical,In progress] https://launchpad.net/bugs/1309915 | 21:19 |
| mterry | Saviq, in the sense of not causing load? good | 21:19 |
| Saviq | mterry, well, not not causing load, but rather not letting the hw go to low power mode | 21:21 |
| ToyKeeper | mterry: Have you also run through the unity8 test plan to check if the change affects anything else? | 21:36 |
| mterry | ToyKeeper, no not the whole thing, just played with the greeter | 21:36 |
| ToyKeeper | It doesn't seem like the change should affect anything else, but the diff seems large enough to need the whole test plan. | 21:39 |
| Saviq | ToyKeeper, it's in rtm silo 003 and we will test it tomorrow | 21:42 |
| ToyKeeper | Saviq: Fair enough. :) | 21:43 |
| mterry | rickspencer3, kgunn: if either of you realizes what steps lead to the power dialog on resume, I'd love it. I tried to reproduce using phonesim and a *call* while suspended (since calls are easier to fake with phonesim than sms). But didn't seem to do anything for me | 21:44 |
| rickspencer3 | mterry, for me, I have to be away from my home or office AP | 21:51 |
| mterry | rickspencer3, ah right, the roaming bit. And receive an sms while roaming | 21:53 |
| mterry | or maybe... just not on wifi.. | 21:53 |
| rickspencer3 | mterry, then you decapitate he chicken and sprinkle the blood in a circle around you | 21:53 |
| * mterry expenses a chicken | 21:53 | |
| kgunn | lol | 21:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!