=== Guest42341 is now known as O
=== O is now known as Guest78101
[08:49] <tsdgeos> Mirv: not sure if we told you or you did realize but the support for the audio roles landed in unity8
[08:49] <Mirv> tsdgeos: I did realize it, and I've rebuilt it in 5.5.1 PPA and I would test it if xenial images were not broken (not sure if they would now be fixed already)
[08:50] <Mirv> tsdgeos: anyway, it's excellent! a big landing you had.
[08:50] <tsdgeos> yep :D
[08:50] <tsdgeos> we roll like that
[08:50] <Mirv> s/I did realize it/I did publish it/ ;)
[09:34] <tsdgeos> dednick: did you see daniel's comment in https://code.launchpad.net/~nick-dedekind/qtubuntu/1493530-mimeData/+merge/272630 ?
[09:34] <tsdgeos> mzanetti: what's the fate of https://code.launchpad.net/~mzanetti/ubuntu-clock-app/detect-qtmm-version/+merge/275177 ?
[09:35] <mzanetti> tsdgeos, I don't know...  I'll ping popey to get one of them merged
[09:35] <mzanetti> popey, ^ :)
[09:36]  * popey looks
[09:37] <dednick> tsdgeos: no i havent
[09:37] <dednick> Q_ASSERT? not so sure. it seems to call it with null every startup.
[09:37] <popey> uh
[09:40] <dednick> tsdgeos: or maybe not. i do keep getting a log message about null clipboard data
[09:40] <dednick> cant remember where from though...
[09:40] <dednick> probably server side
[09:41] <tsdgeos> dednick: not saying he's right or nt, just saying "let's move it forward, he needs an answer" :D
[09:43] <mzanetti> dednick, hey, any progress on the freezes Saviq reported?
[09:43] <mzanetti> I had them quite often during the weekend
[09:45] <dednick> mzanetti: no. i managed to get it to freeze a few times, but didnt have debug symbols. After i installed, i spent about an hour trying to reproduce it with no luck. I'll try again today.
[09:46] <dednick> mzanetti: when i did get it to freeze, it seemed to be stuck in a loop. was getting loads of log messages from the card creator re "binding loop for height"
[09:47] <dednick> but there's also another freeze which is happening (in trunk as well i think) where it will freeze for 5-10 seconds and come right again.
[09:47] <dednick> mzanetti: does yours come right or keep locked?
[09:48] <mzanetti> dednick, afaict it keeps locked until I open the right edge
[09:49] <mzanetti> however, if it freezes for multiple seconds, there's the chance that I've just not been patient enough
[09:49] <dednick> mzanetti: next time it happens can you try wait for a bit?
[09:50] <mzanetti> ack
[09:50] <mzanetti> dednick, happens like 5 times a day or so... at least over the weekend
[09:50] <popey> mzanetti, I don't quite understand which of the two merges should land. there's another linked from that one, and loads of abstentions!
[09:50] <mzanetti> popey, you decide :)
[09:51] <Guest78101> mzanetti, same here on arale, constant freezing
[09:51] <Guest78101> rc-proposed
[09:51] <mzanetti> yep, rc-proposed
=== Guest78101 is now known as QUESTION
[09:52] <QUESTION> omg LOL
[09:53] <QUESTION> can i ask something??
[09:56] <popey> !ask
[09:56] <ubot5> Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience
[09:56] <QUESTION> :))
=== QUESTION is now known as Guest78101
[10:02] <davmor2> Guest78101: did you ask the question yet?
[10:14] <dednick> tsdgeos: i've commented and pushed a change. I don't think we should be clearing the clipboard.
[10:14] <tsdgeos> oki :)
[10:14] <tsdgeos> i don't know enough about it tbh
[10:29] <mzanetti> tsdgeos, ok, all branches merged
[10:29] <tsdgeos> :)
[10:30] <tsdgeos> mzanetti: i think you missed https://code.launchpad.net/~mzanetti/unity8/ubuntuanimations/+merge/276511 ?
[10:30] <mzanetti> indeed
=== marcusto_ is now known as marcustomlinson
[12:10] <dandrader> mzanetti, made so that https://code.launchpad.net/~dandrader/unity8/noStretchOnResize/+merge/274752 now does not depend on that qtmir branch anymore
[12:10] <dandrader> mzanetti, so it can get merged independently
[12:10] <mzanetti> dandrader, nic
[12:10] <mzanetti> nice
[12:11] <dandrader> mzanetti, it will take forever for the qtmir branch to get landed because of other outstanding branches that also change the same code.
[12:11] <mzanetti> mhm
[12:12] <dandrader> mzanetti, and I fear leaving that untiy8 branch hanging aroung as that part of the code (desktop window management) is under heavy development, so it can bit rot quite fast
[12:12] <mzanetti> fair enough, yes
=== alan_g is now known as alan_g|lunch
[13:22] <mzanetti> tsdgeos, hey, https://code.launchpad.net/~aacid/unity8/dash_reset_instead_of_fatal/+merge/274363 links to an abandoned silo
[13:22] <mzanetti> what's the status? should unity-scopes=8 be landed by us then?
[13:30] <tsdgeos> mzanetti: pstolowski what happened with that silo?
[13:31] <mzanetti> tsdgeos, the dash seems to freeze for a couple of seconds frequently since the last landing. any thoughts?
[13:32] <tsdgeos> hmmm
[13:32] <tsdgeos> not really let me check the log
=== dandrader is now known as dandrader|afk
[13:50] <mzanetti> tsdgeos, seems to happen quite often when it is focused
[13:50] <mzanetti> tsdgeos, only happening with the dash tho afaict
[13:51] <tsdgeos> mzanetti: i can't find anything obvious
[13:51] <tsdgeos> even though with the move to 1.3 there's lots of ubuntu shape changes
[13:51] <pstolowski> mzanetti, tsdgeos i had to free that silo for now cause we were short on silos. will recreate it once aggregators are ready and i can land the feature
[13:52] <pstolowski> mzanetti, tsdgeos feel free to land your branch with another silo
[13:53] <tsdgeos> pstolowski: can't since you made me increase the dependencies :D
[13:53] <pstolowski> tsdgeos, ah, indeed
[13:54] <tsdgeos> pstolowski: so can i have the names of the branches that it depends on so i can list them in our MR?
[13:55] <tsdgeos> mzanetti: do you do anything in special? or?
[13:56] <mzanetti> tsdgeos, this is reproducible quite easily. just focus some other app, after a few secs go back to the dash and continuosly flick it up and down. after some few seconds it will freeze for like 10 secs or so
[13:56] <mzanetti> tsdgeos, nothing in the logs :/
[13:56] <tsdgeos> 10 seconds?
[13:56] <mzanetti> something like that. not always the same amount
[13:56] <tsdgeos> i thought you meant something like 0.2 seconds :D
[13:56] <mzanetti> someties like 3 secs, but also have seen 20 too
[13:57] <tsdgeos> ok, let me try to reproduce it here and i'll try to figure out what's wrong
[13:57] <mzanetti> cool, thanks
[13:58] <pstolowski> tsdgeos, https://code.launchpad.net/~stolowski/unity-scopes-shell/diff-updates/+merge/273554
[13:58] <pstolowski> tsdgeos, and https://code.launchpad.net/~stolowski/unity-api/scope-activate-action/+merge/273557
[13:59] <tsdgeos> ok, tx, mzanetti i've updated the branches
=== dandrader|afk is now known as dandrader
=== alan_g|lunch is now known as alan_g
=== balloons is now known as Guest42098
[14:41] <Guest42341> tsdgeos, same thing as mzanetti here with arale on rc-proposed, the dash freezes for 2-10 sec
[14:41] <tsdgeos> greyback_: what can cause this? ↓
[14:41] <tsdgeos> qtmir.surfaces: MirSurfaceItem::dropPendingBuffer() surface = qtmir::MirSurface(0x2e1ce10) buffer dropped. 0 left.
[14:41] <tsdgeos> mzanetti: ↑ i get that as unity8 log when i see the freeze, can you confirm?
[14:41] <greyback_> tsdgeos: if a surface is set visible=false, and app keeps drawing. We drop those new frames from the app to avoid blocking it
[14:42] <mzanetti> interesting
[14:42] <tsdgeos> greyback_: how can i know who 0x2e1ce10 belongs to?
[14:42] <mzanetti> I think I saw this message even though the surface was visible
[14:42] <tsdgeos> greyback_: is it possible there's a bug in there? i'm seeing it in conjunction with unity8-dash rendering "freezing" when on the front
[14:42] <greyback_> tsdgeos: should be printed earlier in the log
[14:43] <greyback_> tsdgeos: possible, sure.
[14:43] <mzanetti> dednick, so looks like being occlusion related after all ^
[14:43] <greyback_> dednick: you were trying to repro that last week ^^
[14:43] <tsdgeos> greyback_: http://paste.ubuntu.com/13208991/ :/
[14:43] <greyback_> mzanetti: occlusion is the act of setting surfaces visible=true/false
[14:43] <mzanetti> yes. I know
[14:43] <tsdgeos> greyback_: maybe i need to enable more logging?
[14:44] <greyback_> tsdgeos: from high level, would indicate to me the MirSurfaceItem has visible=false, but app is still drawing somehow.
[14:44] <greyback_> tsdgeos: there is no more to enable, we should improve that
[14:45] <mzanetti> greyback_, yep. but the surface *is* visible. so seems like the occlusion branches tell MirSurface it would be not even though it is
[14:45] <greyback_> mzanetti: a likely theory
[14:46] <greyback_> I'm assuming this just happens randomly?
[14:46] <mzanetti> greyback_, quite reproducible
[14:46] <tsdgeos> it's randomly quite reproducible :D
[14:47] <greyback_> dednick wasn't able to on Friday, playing around for a good hour
[14:47] <tsdgeos> i mean you can't make it happen 100% but you can make it happen quite often
[14:47] <mzanetti> greyback_, open some random app, keep it focused for a few secs, then switch to dash and swipe it up/down frequently. the dash will freeze
[14:47] <mzanetti> definitely a good 90% hit rate here
[14:47] <tsdgeos> i've a much lower hit rate
[14:47] <tsdgeos> maybe 30%
[14:48] <tsdgeos> but still "reproducible enough"
[14:48] <mzanetti> krillin here
[14:48] <tsdgeos> MX4 for me
[14:48] <tsdgeos> maybe the speedness of the hw "helps"
[14:48] <greyback_> mzanetti: please add that to the bug, would help
[14:48] <greyback_> also what device? I suspect a race condition
[14:48] <greyback_> yeah, my thinking
=== Guest42098 is now known as balloons_
[14:48] <mzanetti> greyback_, is there a bug report for it?
[14:48] <greyback_> dednick ^ ?
[14:49] <dednick> reading backlog
[14:50] <dednick> i was getting those messages when the surface was visible in u8
[14:51] <greyback_> dednick: which would make me suspicious. We shouldn't need to drop frames from a visible surface
[14:51] <greyback_> only case that would happen is if client not respecting vsync and swapping faster than 60htz
[14:52] <greyback_> and dash doesn't do that
[14:53] <mzanetti> oh dear... OTA-8 final freeze is tomorrow
[15:01] <tsdgeos> greyback_: mzanetti: dednick: so i leave the investigation in your hands? you probably can find a cause/cure faster than me in that area
[15:01] <mzanetti> tsdgeos, yes, thanks for confirming tho
[15:01] <dednick> i thought occlusion has landde?
[15:01] <greyback_> tsdgeos: yep
[15:01] <dednick> landed
[15:01] <mzanetti> dednick, yes, it has, which is the issue with the OTA-8 freeze
[15:01] <mzanetti> dednick, need to ship a fix by tonight I guess, or we'll have to revert
[15:02] <dednick> mzanetti: ok
=== balloons_ is now known as balloons
=== dandrader is now known as dandrader|bbl
[16:31] <ltinkl> cimi, if you want to review the new deco visuals, be my guest: https://code.launchpad.net/~lukas-kde/unity8/newWindowDecosAndPanel/+merge/276810
[16:41] <tsdgeos> cimi: so https://trello.com/c/dNjca4ie/229-range-input-filter-widget is all good and ready for review?
[17:32] <mterry> ltinkl, on your desktopFileActions branch, is there any concern about letting Touch apps define such extra actions and running code that way?
[17:33] <ltinkl> mterry, right, this is intended more for existing desktop apps (chrome, libreoffice, ...)
[17:33] <mterry> ltinkl, I know, but there's nothing in this branch restricting it to legacy apps
[17:33] <ltinkl> mterry, not aware of any touch app that would use this currently
[17:33] <ltinkl> mterry, it's restricted to the same binary currently (because of the security model)
[17:34] <mterry> ltinkl, oh I don't see that restricting...
[17:35] <ltinkl> mterry, but I think apps like the touch webbrowser might want to add a "New tab..." shortcut to its desktop file and handle that within the same instance/window
[17:35] <mterry> ltinkl, yeah... I'm not worried about legitimate uses.  I'm thinking of malicious apps here
[17:35] <ltinkl> mterry, in the MP, lines 387-394
[17:36] <mterry> ltinkl, ah...  it uses app_id there, not the result of exec()
[17:36] <ltinkl> mterry, I extract the args and pass it to the same binary
[17:36] <ltinkl> mterry, yeah, it should be safe although the args splitting might be a bit naive
[17:36] <mterry> ltinkl, my eyes glossed over that and assumed that first argument was the first exec token
[17:37] <ltinkl> mterry, anyways, the MP could use a review ;)
[17:38] <mterry> ltinkl, yeah I was about to comment on it, but wanted to talk with higher bandwidth first  :)
[17:38] <ltinkl> mterry, worth noting I got rid of QSettings there... it was failing badly
[17:39] <mterry> ltinkl, so now I'm less concerned about malicious apps.  But for a legitimate app, feels odd that I can just put garbage in the first token of the Exec line...
[17:39] <ltinkl> mterry, yea... our sandboxing wouldn't allow launching another app anyway I bet
[17:40] <mterry> ltinkl, well this is unity8 launching it.  I could imagine app "malicious.mterry" might try to launch another app like "good.ltinkl" if it was allowed to
[17:40] <ltinkl> mterry, still I can think of good usecases: file manager, right click on a ZIP file, select "Extract to...", launches some archiver program
[17:41] <mterry> ltinkl, so sandboxing isn't enough, we definitely should restrict it to same appId
[17:41] <mterry> ltinkl, like your MP does
[17:41] <ltinkl> mterry, yea
[17:41] <ltinkl> mterry, but a I said, I could also think of valid use cases when one might want to launch another app
[17:41] <mterry> ltinkl, but it just feels weird that "good.ltinkl" if it wants to use these actions has to put in some ignored token on the exec line (presumably its own executable, so maybe it doesn't matter).  But if they put in something else, they don't get any warnings, they just get a different executable than they expected running
[17:42] <ltinkl> mterry, yeah, perhaps at least a warning would be in place?
[17:42] <mterry> ltinkl, but that sort of cross-app dependency is not something our app ecosystem is ready for  :)  (unless they are core apps maybe?)
[17:43] <ltinkl> mterry, dunno really, such cross deps should probably be handled by the content hub
[17:43] <mterry> ltinkl, yeah.  I was just reiterating that it's good we don't allow launching other appIds right now  :)
[17:44] <mterry> ltinkl, ok will really review your branch now  :)
[17:45] <mterry> mzanetti, regarding QSettings vs gsettings for desktop parsing, I remember you looking into that in the past.  What was the story there? <- ltinkl
[17:46] <ltinkl> mterry, it just failed to parse anything else than the [Desktop Entry] group for me
[17:46] <mzanetti> mterry, so, QSettings can do it for simple things. If you need more complicated things, QSettings won't do
[17:46] <ltinkl> mterry, also omitting some regular translated entries
[17:46] <mterry> ltinkl, silly QSettings
[17:47] <ltinkl> ah right, I remember
[17:47] <mterry> mzanetti, yeah we had converted to gsettings already somewhere in unity8 right?
[17:47] <ltinkl> it fell over when it encountered
[17:47] <ltinkl> right to left text
[17:47] <mterry> er... not gsettings.  But glib
[17:47] <mzanetti> mterry, well, QSettings does not implement the .desktop file spec. It implements the .ini file spec, which happens to be a subset of the .desktop one
[17:47] <ltinkl> indeed
[17:47] <mterry> mzanetti, right
[17:47] <ltinkl> Name[il]=this_is_right_to_left_text
[17:48] <ltinkl> and QSettings is gone :)
[17:48] <ltinkl> and doesn't parse anything past this point
[17:48] <mterry> ltinkl, well looks like it's still used in ./plugins/Unity/Indicators/indicatorsmanager.cpp
[17:49] <mterry> ltinkl, but that's for actual ini files I think
[17:49] <mterry> So probably ok
[17:49] <ltinkl> dunno that code
[17:49] <ltinkl> mterry, qtmir having similar code is something to worry more
[17:49] <mzanetti> mterry, ah, did the question arise when reviewing lukas' branch?
[17:49] <mterry> mzanetti, yeah
[17:50] <mterry> mzanetti, I was surprised that we still had QSettings code in there actually
[17:50] <mzanetti> mterry, it was enough for what the launcher needed so far
[17:50] <mzanetti> but not any more...
[17:50] <mterry> cool
[17:50]  * mterry is caught up  :)
=== dandrader|bbl is now known as dandrader