[08:09] mzanetti: can you do when you have some free time? https://code.launchpad.net/~aacid/unity8/fix-xvfbtest-dashview-plugin [08:09] https://code.launchpad.net/~aacid/unity8/fix-xvfbtest-dashview-plugin/+merge/215181 [08:12] Saviq, what do I do though with the cmake file since my patch didn't work? [08:13] Mirv, if you're preparing a qt pkg for the carousel issue, feel free to add it to silo 015 [08:15] Cimi, let me check something [08:19] mhr3: I'm not (yet), since it's in a non-touch seed so I was thinking of having it for the beginning of u-series with a bunch of other patches [08:19] Cimi, http://paste.ubuntu.com/7260172/ [08:19] Cimi, that works [08:20] Cimi, set_tests_properties only affects things when you run `make test`, not when you use `make testfoo`, 'cause testfoo is not a test, it's just a custom target [08:21] Cimi, might want to wrap the second LC_ALL= in quotes [08:21] Saviq, makes sense [08:21] Cimi, so http://paste.ubuntu.com/7260175/ [08:21] Saviq, so we don't need make test here, or we do? [08:21] sorry, set test properties [08:21] Cimi, we do [08:21] Cimi, 'cause if you run `make test` [08:21] Mirv: understand this is not specifically against you but more against "stable distros concept". So we have a bug, we have a fix for the bug, but since it's "stable" the bug is not applied <- never understood this rationale [08:22] Cimi, it would fail [08:22] Saviq, but can't we set it for all tests? [08:22] set it once for all? [08:22] Cimi, no, it has to be per-test [08:22] ok [08:22] or per-custom-command [08:23] Saviq, have you tried turning on the perf overlay for the shell? [08:23] it's quite interesting [08:23] mhr3, no I haven't [08:23] Saviq, http://paste.ubuntu.com/7260184/ [08:24] mhr3, great, MP! [08:24] :P [08:25] tsdgeos: well it's more like it cannot enter right now since it's final freeze and it's seeded. it could go in as SRU, but so far we've always just moved to the next development version instead for touch. [08:25] Saviq, observation #1, rendering in both the apps scope and scopes scope are much slower compared to the rest [08:25] tsdgeos: but I do get your point, the burden of how to do stable updates more often that not leads to not having updates [08:27] tsdgeos: the history behind it is that usages of distro and libs are large and abound, and there have been numerous examples of minor, 100% rock solid 1-liner patches that ended up causing grievance. so that's why it's more like "no changes, unless provenly regression-free for all reverse depedencies" for stable update [08:28] but it's cultural, too [08:29] Mirv: which is understandable from some pov, but is still against "progress", since if you delay the patch you'll face that grievance anyway in "the next release", so it's better if you face it now since it also means it'll be fixed sooner (if you delay the patch 6 months the guy that did it may not even be around anymore and you have to decide which of the two bugs is worse) [08:29] but as said, it's not against you and i'm not trying to change ubuntu's stance on it [08:30] i'm just explaining the reason of open handed bug fixing i apply to the projects i'm maitainer/release manager [08:38] dednick, hey, can you please have a look at bug #1306499 - I've a feeling it's a feedback loop of some sort :| [08:38] bug 1306499 in unity8 (Ubuntu) "Sound indicator is laggy #287 on mako" [Undecided,Confirmed] https://launchpad.net/bugs/1306499 [08:40] Saviq: I've already commented on it. It's not unity8. the issue exists on desktop as well. although not sure why unity8 stops responding... [08:41] Saviq: i can look into the problem on a deeper level if you wish [08:41] dednick, well, if it updates the slider repeatedly.. [08:41] dednick, but you're right, it's there on desktop, too [08:43] Saviq: but there are other issues.: i guess if the user is currently interacting with the slider, the server probably shouldn't update it (jerky) . Also, should maybe put an update throttle in there (i think the desktop has one). We're posting a massive number of updates with the live slider. [08:44] dednick, yeah, I know [08:45] but it's really a regression on the desktop too [08:45] it used to work afair [08:45] indeed [08:45] dednick, that's something the bidirectional binding component could deal with, when we get to write it... [08:45] tsdgeos: yeah. i think it's something to do with the account services [08:46] tsdgeos, re: launcher-dbus, I think the problem is QtDBus doesn't handle subscribing to a path and all its children [08:46] tsdgeos, we need /unity/launcher/$app_id [08:47] tsdgeos, so that we can confine it [08:47] tsdgeos, but apparently QtDBus can't do it... [08:47] so you get into low level dbus message handling [08:47] Saviq. tsdgeos: i think it is this: http://bazaar.launchpad.net/~indicator-applet-developers/indicator-sound/trunk.14.04/revision/431 [08:48] dednick, yeah, another feedback loop... [08:48] i'll revert and see if it fixes the prob [08:55] Saviq: mhhhhok [08:56] just wanted to make sure it was not ted just going the way it resembles more what glib does [08:57] tsdgeos, yeah, he asked around, but didn't get anywhere [08:57] tsdgeos, would be nice to get it on QtDBus indeed (especially since I think we might need it more often in the future) [08:58] well, contribution upstream is welcome i'm pretty sure [09:05] dpm, what did you do to my name? :P [09:05] dpm, i don't have that weird l thing in Michal :P [09:08] Saviq, shall I do for all the other tests or just for this? [09:10] :PPPPPP [09:11] mhr3, lol, other Michal's have it, so I thought you deserve to have a special letter too! [09:12] Saviq, so is the ł only used in Polish? [09:13] dpm, yes ;) [09:13] dpm, ąęółśżźćń [09:14] of those I've only seen ó used anywhere else, TBH [09:14] wow, you like your accents in consonants :) [09:14] we use ó quite often in Catalan too [09:15] we have ó too [09:16] but still no weird l :) [09:16] Saviq, shall I add only this cmakefile modification for now? [09:16] or all tests? [09:20] Cimi, to qmltests/CMakeLists.txt as well [09:21] Saviq, but there are other tests apart that [09:21] Saviq, I don't think all with require though [09:21] generally is text and dimes [09:22] }times [09:23] interesting so ń and ñ are the same sound [09:41] Saviq, this should be enough http://paste.ubuntu.com/7260511/ ? [09:41] Cimi, you can't have two ENVIRONMENT properties [09:42] Saviq, so how do I set two? [09:42] Cimi, space separated [09:42] I tried and complained [09:42] Cimi, space separated in the same quotes [09:42] oh maybe in the same " " [09:42] Cimi, not separate string [09:42] yep [09:43] Saviq, well cmake was passing with that anyway :) [09:43] committing [09:43] Cimi, sure, but probably not the tests :P [09:44] Saviq, do we have a function that is called after the autopilot test ends? [09:45] Cimi, addCleanup is used for that [09:45] Saviq, all test suite? [09:46] Cimi, http://unity.ubuntu.com/autopilot/tutorial/advanced_autopilot.html [09:48] Saviq: um, can't really think of a solid solution for volume issue [09:48] It's feedback from asynchronous account service property changes . we change the valume 10 times internally (and send off update to account services), then get a slow trickle volume property changes from account services... ever needed to deal with that before? [09:48] dednick, right, that's what I was afraid of... [09:49] there doesnt seem to be a way which we can tell if it was a locally updated value or someone else that updated the service. [09:50] dednick: can you tell the service thing "you this is the new value but don't tell me, i already know about it"? [09:50] tsdgeos: um. dont think so. it's just a dbus property update [09:50] tsdgeos, yeah, it's just like QML props... [09:50] right [09:51] dednick, other than making it sync, or adding some timeout logic... [09:52] Saviq: hm. dont think sync will work, since the prop update is still async. [09:53] or a "i'm about to receive these notifications, ignore them" [09:54] mhr3, yeah, but would you just maintain a list of those you didn't receive yet? [09:54] indeed [09:55] i'd call the class implementing it "NotificationPremonition" :) [09:55] thought about that. but operations the operations can fail. dont think it's guaranteed to get the prop update for the one you sent. [09:55] tsdgeos, I wonder... if we increased the cache buffer (i.e. moved delegatecreationbegin/end), we wouldn't be blocking as much would we [09:56] hmm or wait, not [09:56] it doesn't know about cacheBuffer vs. on screen [09:56] Saviq: it doesn't guarantee it, but yes if you have enough buffer zone for async creation of stuff it'd be doing less blocking [09:56] but otoh everything is inside an async card now [09:56] so i don't know why is still blocking at all [09:57] in the optim branch i mean [09:57] it should just give us blank spots [09:57] tsdgeos, well, Loaders are not async by default are they? [09:58] but this one is [09:58] delegate: Loader { [09:58] asynchronous: true [09:58] CardFilterGrid.qml [09:58] mhm [09:59] dednick, hm, then the only safe way is to add a timestamp? [09:59] yikes :| [10:00] mhr3: uh? [10:02] dednick, when changing the volume, the requester passes current timestamp, and then the service exposes it [10:03] mhr3: would require changes to service. dont think that's possible. [10:03] oh well... heuristics then [10:04] yeah. i think we're just going to have to have a timeout [10:07] fwiw yesterday on android the volume overlay wasn't updating for me properly either :) [10:10] :) [10:16] Saviq, http://paste.ubuntu.com/7260650/ [10:17] Saviq, this works... [10:17] Cimi, can't see how it would [10:18] Cimi, indicators are already started before [10:18] Cimi, you can probably see it working because LC_ALL got exported as C already [10:18] Saviq, maybe they can change locale on the fly? [10:18] like the settings? [10:18] Cimi, or maybe you should think about how environment variables work :P [10:18] ahah [10:19] Saviq, so upstart kills the indicators somehow [10:19] Cimi, unity8 does (not for long) [10:19] Saviq, thing is, with this code, indicators and shell are english while testing, then spanish when tests end [10:20] Cimi, unity8 on exit stops them, but that won't be the case after upcoming unity8 release [10:20] Saviq, so you can see how it would work now [10:20] Cimi, well, not without --global I don't, TBH [10:21] I can add global, but works [10:21] proof http://paste.ubuntu.com/7260669/ [10:23] Saviq, -g is implied [10:23] -g, --global [10:23] Operate on the global job environment table and all [10:23] existing running job environment tables. This option is [10:23] implied when not run from within a job. [10:24] Cimi, ah right [10:24] Cimi, so yeah, that actually leaves your environment broken, 'cause LC_ALL is unset, instead of being reset to the original value [10:26] Saviq: when do you get teh file:///home/phablet/shell/qml/Dash/Card.qml:140: TypeError: Cannot read property 'height' of null [10:26] file:///home/phablet/shell/qml/Dash/Card.qml:141: TypeError: Cannot read property 'opacity' of null [10:26] warnings on the optim branch? [10:27] tsdgeos, scrolling carousel in music, I think [10:28] Saviq, so I can save a variable with initctl storing LC_ALL and then using it inside the cleanup? [10:28] Cimi, sure, but that still won't make it work with the release that will be merged in an hour or so [10:29] Cimi, since indicators won't be stopped on unity8 stop [10:29] Saviq, crashes from whoopsie still aren't sent automatically? [10:29] mhr3, they should be [10:29] Saviq, https://errors.ubuntu.com/?package=unity8&period=month [10:30] ~40 crashes... doesn't seem right :P [10:30] of course it does! [10:30] period=month! [10:30] :P [10:30] Cimi, so let's wait until then, I can't wrap my head around this atm, it really feels like we'll end up having to restart the whole session for this... [10:31] Saviq, do you know who would know more about it? [10:31] pitti? [10:31] mhr3, ev, to start with [10:31] Cimi, otherwise we'll just be hunting services that need to be restarted... [10:32] Cimi, so it feels like we shouldn't be doing this for ap tests [10:33] tsdgeos, yeah, scrolling in carousel - can be reproduced in tryGenericScopeView [10:33] Saviq, ok [10:33] Saviq: ok, tx [10:34] Saviq, I'll attach the patch to the bugreport but not push it to the branch [10:34] so we don't lose the trick [10:34] Cimi, it's not really a trick ;) [10:36] Saviq, well, you know always where to put hands, but not everyone is handy in python or upstart... so unless you'll be the one fixing this but, a quick note helps [10:37] Saviq: i don't get it with tryGenericScopeView :S [10:37] Saviq: which branches do you have merged in? [10:38] if any [10:38] tsdgeos, trunk + your branch (+ && windowShown) [10:38] weird [10:38] i've the same [10:38] lemme try again [10:38] Saviq: so you do the tryGSV and just flick the carousel horizontally? [10:39] tsdgeos, yes, and then Alt+F4 to actually see output [10:39] h wait [10:39] I'm only getting binding loops there [10:39] tsdgeos, so no, I can only see that through run_on_device in the music scope [10:40] ok [10:40] i need to add music there again [10:40] soomehow it disappeared [10:40] i guess i bootstrapped [10:40] tsdgeos, prolly [10:41] Saviq, ideally, indicator services might restart when locale changes [10:41] Cimi, and scopes... and foo... and bar... and baz... [10:42] yes [10:42] Cimi, truth is the whole session needs to restart [10:42] tsdgeos, looking through Card.qml, there's plenty of things that could be offloaded to CardTool, anything that only queries template and components... [10:42] well, if doesn't affect UX [10:42] tsdgeos, but when I did a quick try, it didn't really help :P [10:42] Cimi, if it doesn't, it shouldn't run in the session ;) [10:42] on my phone when I change locale I don't have to reboot it :) === Malsasa_ is now known as Malsasa [10:43] Saviq, if from the settings we change locale [10:43] Saviq, indicators can easily restart because we don't have them opened [10:43] Saviq, ssame for the dash and scopes (we're in the system settings app) [10:44] Cimi, that's a band-aid, not a solution [10:44] Saviq: yeah there's lots of things one thinks can be "optimized" but then the benchmark says "not really" [10:44] Cimi, anyway, people know about it, you can stop thinking on it ;) [10:44] tsdgeos, yeah, exactly... [10:44] Saviq: i think i even put the art in a loader at some stage and didn't help [10:44] but i'll try again [10:45] tsdgeos, yeah, ignore me if it doesn't [10:45] tsdgeos, it looked like it's more expensive to bind than to do the calculation in each card... which feels insane [10:57] tsdgeos, please let me know when you're done with that branch, there's pressure to get it in... [10:57] Saviq: sure [10:58] Saviq: i mean we can probably get it in already, is not magic, but helps a bit already [10:58] there's stuff i want to check [10:58] but we don't need to land everything together [10:58] tsdgeos, no, I mean like adding : '{}' to reduce warnings [10:58] but sure, i need to reduce the warnings [10:58] tx [10:58] /food === MacSlow is now known as MacSlow|lunch === pete-woods is now known as pete-woods-lunch [11:30] mzanetti, how do I see errors from make test? [11:30] Cimi: where? [11:30] ah [11:30] make test [11:30] Cimi: use ctest -V [12:01] Saviq, any idea what this is? https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1297197/+attachment/4085366/+files/unlock_screen.mp4 [12:01] Ubuntu bug 1297197 in unity8 (Ubuntu) "New scopes performance needs to be improved" [High,Triaged] [12:01] mhr3, I *think* it might be the screenshot [12:01] mhr3, in the apps list [12:02] i've never seen it *that* slow [12:02] mhr3, I've encountered that on and off [12:02] mhr3, after an autopilot run, for example [12:02] Saviq, actually, just happened :) [12:03] Saviq, but it unlocked to an empty scopes scope, so unless the screenshots are refresh even when not visible, it's not them [12:03] (it was empty cause i killed it half an hour ago) [12:04] mhr3, the screenshots get updated more often than the scope results, yes [12:04] mhr3, can you kill the app and try again? [12:05] Saviq, oh, i don't have any running :P [12:05] mhr3, was that after the phone was off for a while? [12:06] Saviq, yes, but i'm aware of the render thread blocking, waited a bit [12:06] mhr3, mhm [12:07] Saviq, cpu on 100% when swiping the greeter away [12:07] Saviq: mhr3: I didn't have any app running and it was a fresh boot [12:08] didrocks, the first video is expected [12:08] didrocks, that's scopes loading its results for the first time [12:08] didrocks, the latter I haven't seen ever :| [12:08] Saviq: I get it really frequently [12:08] I guess popey told it as well [12:08] Saviq: we really just have the default (I wiped it yesterday) [12:08] the only thing, as told, my network is quite effective… [12:09] (and it's worse sometimes, really noticeable) [12:09] mhr3, you're not blocking the UI any more are you? [12:10] Saviq, when sending a query i might [12:10] Saviq, but there are no queries sent in this case [12:11] grr [12:14] mhr3, in didrocks's example there might have been a query - he's going to the apps scope, and there can be a screenshot made, 'cause there's an app in the scope === MacSlow|lunch is now known as MacSlow [12:16] let me record what i see [12:21] Saviq, https://drive.google.com/file/d/0BxxLngWtDRLjbmZMNHZpUDNYdG8/edit?usp=sharing [12:22] smaller jerk, but still a jerk [12:22] mhr3: got something similar sometimes [12:23] Saviq, regarding the needed version-bump for unity-api (unity-notifications and unity8 for modal-snap-decision)... going from 0.1.2 to 0.1.3 should be sufficient... no need to touch the minor part?! [12:25] MacSlow, it's not about that [12:25] MacSlow, it's about the Provides: unity-notification-impl-$foo [12:25] MacSlow, and Version: in unity-notifications.pc [12:26] MacSlow, and Depends: unity-notifications-impl-$foo in unity8 [12:26] Saviq, sure... but it needs to start there [12:26] that's unity-api, unity-notifications, unity8, respectively [12:27] Saviq, it should be based on the unity-api-version number and not on the package-version [12:29] MacSlow, yes, the two are somewhat unrelated [12:29] mhr3, I'm not getting this here at all, can you see any output in unity8.log? are you sure there's no query fired (a failed query or something)? [12:29] mhr3, I killed my scopes scope, and it just goes fluently to the dash... [12:30] Saviq, the only thing i see is [12:30] file:///usr/share/unity8/Dash/CardFilterGrid.qml:36:5: QML FilterGrid: Binding loop detected for property "height" [12:30] lots of it though [12:30] but probably not during the unlock [12:30] mhr3, yeah, only interesting part is during the unlock [12:30] hmmm [12:30] QIODevice::write: device not open [12:31] nah [12:32] Saviq, just an unlock - http://paste.ubuntu.com/7261216/ [12:32] mhr3, ok that's interesting... [12:32] Saviq, and plus displaying empty scopes scope [12:32] so... ehm? [12:33] well, still shouldn't cause that [12:33] but shouldn't be there in the first place [12:33] (not to mention the binding loop doesn't make sense) [12:33] Saviq, aren't you running tsdgeos's opti branch? [12:33] mhr3, no [12:33] hm, ok no idea then [12:35] ah, well, the binding loop is "kind of" there [12:36] mhr3, ok, nothing else I can get from you without profiling it... do you know if it persists across unity8 restarts? [12:36] I have the same binding loop detection [12:36] (across reboots) [12:37] didrocks, and the jerky unlock, too? [12:37] Saviq: yeah, I get that really regularly [12:37] across reboots/versions [12:38] (and not always on the first unlock) [12:38] * Saviq must try with broken 3G or something [12:38] mhr3, does scopes scope use network for surfacing? [12:39] (other than icons) [12:39] Saviq, does that matter? [12:39] mhr3, it might, that's what I'm trying to find out [12:39] even if it does it's outside of unity process [12:40] mhr3, yeah but if you're blocking on query, it might still affect unity8, no? [12:40] or is the place you're blocking at only pinging scope-registry [12:41] no, the blocking happens only between the time a client requests a query creation and the query object being created [12:41] anything else is fully async [12:41] and the network query == anything else [12:41] mhm [12:42] mhr3, can you consistently reproduce across unity8 restarts? [12:42] * mhr3 tries [12:43] Cimi, you broke something https://jenkins.qa.ubuntu.com/job/generic-mediumtests-builder-trusty-armhf/4456/console [12:44] Cimi, QT_QPA_PLATFORM is no longer in the environment [12:44] Cimi, for three of the tests [12:45] Saviq, not really, first unlock was jerky but now it's ok [12:45] fwiw the binding loops are still there [12:45] mhr3, yeah [12:46] those are spurious warnings [12:46] well, still need to get rid of them [12:46] Saviq, unity-notifications will bump its "Provides" from unity-notifications-impl-2 to unity-notifications-impl-3, but how can I make sure it'll build-depend on unity-api 0.1.3 ... I only know how to make it depend on package-versions [12:47] MacSlow, well, that's standard [12:47] MacSlow, you need to bump unity-api indeed, and bump the B-D in unity-notifications [12:47] Saviq, even the greeter itself refreshes much faster, i no longer need to wait 3 seconds for it to settle [12:49] mhr3, right, so, you wanna add "-qmljsdebugger=port:3768" to unity8.conf's exec args... [12:49] MacSlow, so, all in all, build-depends are handled as usual, only runtime deps are special [12:49] mhr3, and the next time you encounter that - connect to it and do some profiling [12:49] didrocks, ↑ [12:51] * didrocks notes [12:51] Saviq: can't really do testing atm, firedrills on firedrills… [12:51] didrocks, I understand, just letting you know, I'll be trying to repro it, too [12:52] yep ;) [13:03] Saviq, still not sure how to proceed... should I check for the unity-api version only in unity-notification headers (checking defined UNITY_API_VERSION_STRING from ) or predict the upcoming package-version number of libunity-api-dev (7.80.7) in unity-notifications build-deps? [13:03] Saviq, with that do i connect to it and what do i do once i am connected? [13:03] s/that/what/ [13:03] Saviq, I haven't done that type of thing in ages [13:03] MacSlow, don't "predict", bump it in unity-api [13:04] Saviq, so just the check in the header... ok [13:04] MacSlow, you just need an UNRELEASED changelog entry in unity-api's debian/changelog [13:05] MacSlow, the train machinery only deals with the part after + [13:06] MacSlow, so just add an UNRELEASED at 7.80.7-0ubuntu1 or whatever the scheme is there [13:06] kgunn, Saviq: I don't have urgent work, if you folks have bugs or reviews you'd like to me to look at [13:06] Saviq, ok [13:06] mterry, hey [13:06] mterry, https://code.launchpad.net/~mterry/unity8/greeter-ux-fixes/+merge/210042 [13:06] mterry, three issues found during testing [13:07] Saviq, ask and I shall receive. looking into it [13:07] Saviq, I did strip tags from all my remote and local branches! How'd they sneak in [13:08] mterry, that's an old comment [13:08] mterry, you're clean [13:08] mterry, last two comments are relevant [13:08] ah I see [13:08] MacSlow: curious if you're working one similar to this ? [13:08] https://bugs.launchpad.net/unity-mir/+bug/1308368 [13:08] Ubuntu bug 1308368 in unity-mir "snap decisions can pop up under the onscreen keyboard" [Undecided,New] [13:09] sounds maybe more like unity-mir in general... [13:09] kgunn: no [13:09] kgunn, we'll have to split notifications out of dash to fix that - post - QtComp work [13:09] kgunn: after the unity-api version thing I wanted to jump on bug https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1308011 [13:09] Ubuntu bug 1308011 in Unity 8 "SIM unlock UI shifts a half-gridunit when starting and breaks easily" [High,New] [13:10] kgunn, or well composite OSK on the correct layer - so yah, QtComp work [13:11] yeah, might be better to "leave it" until Qt comp [13:12] kgunn: but I can tackle (or at least look closer at it) that after 1308011 [13:15] kgunn: on the topic of that bug 1308368, I've yet to see any design how notifications are meant to be presented on the phone in landscape orientation [13:15] bug 1308368 in Unity 8 "snap decisions can pop up under the onscreen keyboard" [Medium,Triaged] https://launchpad.net/bugs/1308368 [13:16] Saviq: i think we could try to review and land what is in https://code.launchpad.net/~aacid/unity8/card_optimizations/+merge/213660 right now [13:16] not saying there's more things to be investigated/improved [13:16] tsdgeos, sure [13:17] but what we have is defenitely an improvement i'd say [13:17] so worth going in to make people a bit happier [13:17] MacSlow: sure, but landscape is a bit irrelevant to the stacking order... [13:18] tsdgeos, slightly unrelated: FilterGrid.qml:69 - we're getting binding loop warnings off that all the time [13:18] tsdgeos, and I can't say I disagree... [13:18] yep === _salem is now known as salem_ [13:18] that's the next one i want to tackle [13:18] tsdgeos, ok [13:18] tsdgeos, I think we talked about this [13:18] it even happens at times hickups happen [13:19] kgunn: well... there's the case of the password-entry snap-decisions... if hte osk would be overlapped by the notification (and swallowing input) that would make entering password "hard" [13:19] so it may or may not be related [13:19] but killing them is a good thing for sure [13:19] MacSlow: ah... true, would need a autoscroll to have text entry in view, for sure... [13:20] kgunn: I just wish this whole "stuff a dialog into a notification" would be solved in a better way... but we don't have that yet. [13:21] tsdgeos, yeah, what's interesting, too, is that they show up when unlocking... when nothing should change at all re:dash, unless results are being refreshsed [13:21] -s [13:21] greyback, so, is it time to create a proper home (lp project) for qpamirserver? [13:21] kgunn: then such problems could be avoided [13:21] dandrader: ah yes, that reminds me [13:22]