[08:09] <tsdgeos> mzanetti: can you do when you have some free time? https://code.launchpad.net/~aacid/unity8/fix-xvfbtest-dashview-plugin
[08:09] <tsdgeos> https://code.launchpad.net/~aacid/unity8/fix-xvfbtest-dashview-plugin/+merge/215181
[08:12] <Cimi> Saviq, what do I do though with the cmake file since my patch didn't work?
[08:13] <mhr3> Mirv, if you're preparing a qt pkg for the carousel issue, feel free to add it to silo 015
[08:15] <Saviq> Cimi, let me check something
[08:19] <Mirv> 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] <Saviq> Cimi, http://paste.ubuntu.com/7260172/
[08:19] <Saviq> Cimi, that works
[08:20] <Saviq> 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] <Saviq> Cimi, might want to wrap the second LC_ALL= in quotes
[08:21] <Cimi> Saviq, makes sense
[08:21] <Saviq> Cimi, so http://paste.ubuntu.com/7260175/
[08:21] <Cimi> Saviq, so we don't need make test here, or we do?
[08:21] <Cimi> sorry, set test properties
[08:21] <Saviq> Cimi, we do
[08:21] <Saviq> Cimi, 'cause if you run `make test`
[08:21] <tsdgeos> 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] <Saviq> Cimi, it would fail
[08:22] <Cimi> Saviq, but can't we set it for all tests?
[08:22] <Cimi> set it once for all?
[08:22] <Saviq> Cimi, no, it has to be per-test
[08:22] <Cimi> ok
[08:22] <Saviq> or per-custom-command
[08:23] <mhr3> Saviq, have you tried turning on the perf overlay for the shell?
[08:23] <mhr3> it's quite interesting
[08:23] <Saviq> mhr3, no I haven't
[08:23] <mhr3> Saviq, http://paste.ubuntu.com/7260184/
[08:24] <Saviq> mhr3, great, MP!
[08:24] <Saviq> :P
[08:25] <Mirv> 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] <mhr3> Saviq, observation #1, rendering in both the apps scope and scopes scope are much slower compared to the rest
[08:25] <Mirv> 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] <Mirv> 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] <Mirv> but it's cultural, too
[08:29] <tsdgeos> 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] <tsdgeos> but as said, it's not against you and i'm not trying to change ubuntu's stance on it
[08:30] <tsdgeos> i'm just explaining the reason of open handed bug fixing i apply to the projects i'm maitainer/release manager
[08:38] <Saviq> dednick, hey, can you please have a look at bug #1306499 - I've a feeling it's a feedback loop of some sort :|
[08:40] <dednick> 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] <dednick> Saviq: i can look into the problem on a deeper level if you wish
[08:41] <Saviq> dednick, well, if it updates the slider repeatedly..
[08:41] <Saviq> dednick, but you're right, it's there on desktop, too
[08:43] <dednick> 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] <Saviq> dednick, yeah, I know
[08:45] <tsdgeos> but it's really a regression on the desktop too
[08:45] <tsdgeos> it used to work afair
[08:45] <Saviq> indeed
[08:45] <Saviq> dednick, that's something the bidirectional binding component could deal with, when we get to write it...
[08:45] <dednick> tsdgeos: yeah. i think it's something to do with the account services
[08:46] <Saviq> tsdgeos, re: launcher-dbus, I think the problem is QtDBus doesn't handle subscribing to a path and all its children
[08:46] <Saviq> tsdgeos, we need /unity/launcher/$app_id
[08:47] <Saviq> tsdgeos, so that we can confine it
[08:47] <Saviq> tsdgeos, but apparently QtDBus can't do it...
[08:47] <Saviq> so you get into low level dbus message handling
[08:47] <dednick> Saviq. tsdgeos: i think it is this: http://bazaar.launchpad.net/~indicator-applet-developers/indicator-sound/trunk.14.04/revision/431
[08:48] <Saviq> dednick, yeah, another feedback loop...
[08:48] <dednick> i'll revert and see if it fixes the prob
[08:55] <tsdgeos> Saviq: mhhhhok
[08:56] <tsdgeos> just wanted to make sure it was not ted just going the way it resembles more what glib does
[08:57] <Saviq> tsdgeos, yeah, he asked around, but didn't get anywhere
[08:57] <Saviq> 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] <tsdgeos> well, contribution upstream is welcome i'm pretty sure
[09:05] <mhr3> dpm, what did you do to my name? :P
[09:05] <mhr3> dpm, i don't have that weird l thing in Michal :P
[09:08] <Cimi> Saviq, shall I do for all the other tests or just for this?
[09:10] <Saviq> :PPPPPP
[09:11] <dpm> mhr3, lol, other Michal's have it, so I thought you deserve to have a special letter too!
[09:12] <dpm> Saviq, so is the ł only used in Polish?
[09:13] <Saviq> dpm, yes ;)
[09:13] <Saviq> dpm, ąęółśżźćń
[09:14] <Saviq> of those I've only seen ó used anywhere else, TBH
[09:14] <dpm> wow, you like your accents in consonants :)
[09:14] <dpm> we use ó quite often in Catalan too
[09:15] <mhr3> we have ó too
[09:16] <mhr3> but still no weird l :)
[09:16] <Cimi> Saviq, shall I add only this cmakefile modification for now?
[09:16] <Cimi> or all tests?
[09:20] <Saviq> Cimi, to qmltests/CMakeLists.txt as well
[09:21] <Cimi> Saviq, but there are other tests apart that
[09:21] <Cimi> Saviq, I don't think all with require though
[09:21] <Cimi> generally is text and dimes
[09:22] <Cimi> }times
[09:23] <tsdgeos> interesting so ń and ñ are the same sound
[09:41] <Cimi> Saviq, this should be enough http://paste.ubuntu.com/7260511/ ?
[09:41] <Saviq> Cimi, you can't have two ENVIRONMENT properties
[09:42] <Cimi> Saviq, so how do I set two?
[09:42] <Saviq> Cimi, space separated
[09:42] <Cimi> I tried and complained
[09:42] <Saviq> Cimi, space separated in the same quotes
[09:42] <Cimi> oh maybe in the same " "
[09:42] <Saviq> Cimi, not separate string
[09:42] <Cimi> yep
[09:43] <Cimi> Saviq, well cmake was passing with that anyway :)
[09:43] <Cimi> committing
[09:43] <Saviq> Cimi, sure, but probably not the tests :P
[09:44] <Cimi> Saviq, do we have a function that is called after the autopilot test ends?
[09:45] <Saviq> Cimi, addCleanup is used for that
[09:45] <Cimi> Saviq, all test suite?
[09:46] <Saviq> Cimi, http://unity.ubuntu.com/autopilot/tutorial/advanced_autopilot.html
[09:48] <dednick> Saviq: um, can't really think of a solid solution for volume issue
[09:48] <dednick> 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] <Saviq> dednick, right, that's what I was afraid of...
[09:49] <dednick> 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] <tsdgeos> 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] <dednick> tsdgeos: um. dont think so. it's just a dbus property update
[09:50] <Saviq> tsdgeos, yeah, it's just like QML props...
[09:50] <tsdgeos> right
[09:51] <Saviq> dednick, other than making it sync, or adding some timeout logic...
[09:52] <dednick> Saviq: hm. dont think sync will work, since the prop update is still async.
[09:53] <mhr3> or a "i'm about to receive these notifications, ignore them"
[09:54] <Saviq> mhr3, yeah, but would you just maintain a list of those you didn't receive yet?
[09:54] <mhr3> indeed
[09:55] <mhr3> i'd call the class implementing it "NotificationPremonition" :)
[09:55] <dednick> 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] <Saviq> 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] <Saviq> hmm or wait, not
[09:56] <Saviq> it doesn't know about cacheBuffer vs. on screen
[09:56] <tsdgeos> 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] <tsdgeos> but otoh everything is inside an async card now
[09:56] <tsdgeos> so i don't know why is still blocking at all
[09:57] <tsdgeos> in the optim branch i mean
[09:57] <tsdgeos> it should just give us blank spots
[09:57] <Saviq> tsdgeos, well, Loaders are not async by default are they?
[09:58] <tsdgeos> but this one is
[09:58] <tsdgeos>         delegate: Loader {
[09:58] <tsdgeos>             asynchronous: true
[09:58] <tsdgeos> CardFilterGrid.qml
[09:58] <Saviq> mhm
[09:59] <mhr3> dednick, hm, then the only safe way is to add a timestamp?
[09:59] <Saviq> yikes :|
[10:00] <dednick> mhr3: uh?
[10:02] <mhr3> dednick, when changing the volume, the requester passes current timestamp, and then the service exposes it
[10:03] <dednick> mhr3: would require changes to service. dont think that's possible.
[10:03] <mhr3> oh well... heuristics then
[10:04] <dednick> yeah. i think we're just going to have to have a timeout
[10:07] <mhr3> fwiw yesterday on android the volume overlay wasn't updating for me properly either :)
[10:10] <dednick> :)
[10:16] <Cimi> Saviq, http://paste.ubuntu.com/7260650/
[10:17] <Cimi> Saviq, this works...
[10:17] <Saviq> Cimi, can't see how it would
[10:18] <Saviq> Cimi, indicators are already started before
[10:18] <Saviq> Cimi, you can probably see it working because LC_ALL got exported as C already
[10:18] <Cimi> Saviq, maybe they can change locale on the fly?
[10:18] <Cimi> like the settings?
[10:18] <Saviq> Cimi, or maybe you should think about how environment variables work :P
[10:18] <Cimi> ahah
[10:19] <Cimi> Saviq, so upstart kills the indicators somehow
[10:19] <Saviq> Cimi, unity8 does (not for long)
[10:19] <Cimi> Saviq, thing is, with this code, indicators and shell are english while testing, then spanish when tests end
[10:20] <Saviq> Cimi, unity8 on exit stops them, but that won't be the case after upcoming unity8 release
[10:20] <Cimi> Saviq, so you can see how it would work now
[10:20] <Saviq> Cimi, well, not without --global I don't, TBH
[10:21] <Cimi> I can add global, but works
[10:21] <Cimi> proof http://paste.ubuntu.com/7260669/
[10:23] <Cimi> Saviq, -g is implied
[10:23] <Cimi>               -g, --global
[10:23] <Cimi>                      Operate  on  the  global  job  environment  table and all
[10:23] <Cimi>                      existing running job environment tables. This  option  is
[10:23] <Cimi>                      implied when not run from within a job.
[10:24] <Saviq> Cimi, ah right
[10:24] <Saviq> Cimi, so yeah, that actually leaves your environment broken, 'cause LC_ALL is unset, instead of being reset to the original value
[10:26] <tsdgeos> Saviq: when do you get teh file:///home/phablet/shell/qml/Dash/Card.qml:140: TypeError: Cannot read property 'height' of null
[10:26] <tsdgeos> file:///home/phablet/shell/qml/Dash/Card.qml:141: TypeError: Cannot read property 'opacity' of null
[10:26] <tsdgeos> warnings on the optim branch?
[10:27] <Saviq> tsdgeos, scrolling carousel in music, I think
[10:28] <Cimi> Saviq, so I can save a variable with initctl storing LC_ALL and then using it inside the cleanup?
[10:28] <Saviq> Cimi, sure, but that still won't make it work with the release that will be merged in an hour or so
[10:29] <Saviq> Cimi, since indicators won't be stopped on unity8 stop
[10:29] <mhr3> Saviq, crashes from whoopsie still aren't sent automatically?
[10:29] <Saviq> mhr3, they should be
[10:29] <mhr3> Saviq, https://errors.ubuntu.com/?package=unity8&period=month
[10:30] <mhr3> ~40 crashes... doesn't seem right :P
[10:30] <Saviq> of course it does!
[10:30] <mhr3> period=month!
[10:30] <Saviq> :P
[10:30] <Saviq> 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] <mhr3> Saviq, do you know who would know more about it?
[10:31] <mhr3> pitti?
[10:31] <Saviq> mhr3, ev, to start with
[10:31] <Saviq> Cimi, otherwise we'll just be hunting services that need to be restarted...
[10:32] <Saviq> Cimi, so it feels like we shouldn't be doing this for ap tests
[10:33] <Saviq> tsdgeos, yeah, scrolling in carousel - can be reproduced in tryGenericScopeView
[10:33] <Cimi> Saviq, ok
[10:33] <tsdgeos> Saviq: ok, tx
[10:34] <Cimi> Saviq, I'll attach the patch to the bugreport but not push it to the branch
[10:34] <Cimi> so we don't lose the trick
[10:34] <Saviq> Cimi, it's not really a trick ;)
[10:36] <Cimi> 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] <tsdgeos> Saviq: i don't get it with tryGenericScopeView :S
[10:37] <tsdgeos> Saviq: which branches do you have merged in?
[10:38] <tsdgeos> if any
[10:38] <Saviq> tsdgeos, trunk + your branch (+ && windowShown)
[10:38] <tsdgeos> weird
[10:38] <tsdgeos> i've the same
[10:38] <Saviq> lemme try again
[10:38] <tsdgeos> Saviq: so you do the tryGSV and just flick the carousel horizontally?
[10:39] <Saviq> tsdgeos, yes, and then Alt+F4 to actually see output
[10:39] <Saviq> h wait
[10:39] <Saviq> I'm only getting binding loops there
[10:39] <Saviq> tsdgeos, so no, I can only see that through run_on_device in the music scope
[10:40] <tsdgeos> ok
[10:40] <tsdgeos> i need to add music there again
[10:40] <tsdgeos> soomehow it disappeared
[10:40] <tsdgeos> i guess i bootstrapped
[10:40] <Saviq> tsdgeos, prolly
[10:41] <Cimi> Saviq, ideally, indicator services might restart when locale changes
[10:41] <Saviq> Cimi, and scopes... and foo... and bar... and baz...
[10:42] <Cimi> yes
[10:42] <Saviq> Cimi, truth is the whole session needs to restart
[10:42] <Saviq> 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] <Cimi> well, if doesn't affect UX
[10:42] <Saviq> tsdgeos, but when I did a quick try, it didn't really help :P
[10:42] <Saviq> Cimi, if it doesn't, it shouldn't run in the session ;)
[10:42] <Cimi> on my phone when I change locale I don't have to reboot it :)
[10:43] <Cimi> Saviq, if from the settings we change locale
[10:43] <Cimi> Saviq, indicators can easily restart because we don't have them opened
[10:43] <Cimi> Saviq, ssame for the dash and scopes (we're in the system settings app)
[10:44] <Saviq> Cimi, that's a band-aid, not a solution
[10:44] <tsdgeos> Saviq: yeah there's lots of things one thinks can be "optimized" but then the benchmark says "not really"
[10:44] <Saviq> Cimi, anyway, people know about it, you can stop thinking on it ;)
[10:44] <Saviq> tsdgeos, yeah, exactly...
[10:44] <tsdgeos> Saviq: i think i even put the art in a loader at some stage and didn't help
[10:44] <tsdgeos> but i'll try again
[10:45] <Saviq> tsdgeos, yeah, ignore me if it doesn't
[10:45] <Saviq> tsdgeos, it looked like it's more expensive to bind than to do the calculation in each card... which feels insane
[10:57] <Saviq> tsdgeos, please let me know when you're done with that branch, there's pressure to get it in...
[10:57] <tsdgeos> Saviq: sure
[10:58] <tsdgeos> Saviq: i mean we can probably get it in already, is not magic, but helps a bit already
[10:58] <tsdgeos> there's stuff i want to check
[10:58] <tsdgeos> but we don't need to land everything together
[10:58] <Saviq> tsdgeos, no, I mean like adding : '{}' to reduce warnings
[10:58] <tsdgeos> but sure, i need to reduce the warnings
[10:58] <Saviq> tx
[10:58] <Saviq> /food
[11:30] <Cimi> mzanetti, how do I see errors from make test?
[11:30] <mzanetti> Cimi: where?
[11:30] <mzanetti> ah
[11:30] <Cimi> make test
[11:30] <mzanetti> Cimi: use ctest -V
[12:01] <mhr3> Saviq, any idea what this is? https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1297197/+attachment/4085366/+files/unlock_screen.mp4
[12:01] <Saviq> mhr3, I *think* it might be the screenshot
[12:01] <Saviq> mhr3, in the apps list
[12:02] <mhr3> i've never seen it *that* slow
[12:02] <Saviq> mhr3, I've encountered that on and off
[12:02] <Saviq> mhr3, after an autopilot run, for example
[12:02] <mhr3> Saviq, actually, just happened :)
[12:03] <mhr3> 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] <mhr3> (it was empty cause i killed it half an hour ago)
[12:04] <Saviq> mhr3, the screenshots get updated more often than the scope results, yes
[12:04] <Saviq> mhr3, can you kill the app and try again?
[12:05] <mhr3> Saviq, oh, i don't have any running :P
[12:05] <Saviq> mhr3, was that after the phone was off for a while?
[12:06] <mhr3> Saviq, yes, but i'm aware of the render thread blocking, waited a bit
[12:06] <Saviq> mhr3, mhm
[12:07] <mhr3> Saviq, cpu on 100% when swiping the greeter away
[12:07] <didrocks> Saviq: mhr3: I didn't have any app running and it was a fresh boot
[12:08] <Saviq> didrocks, the first video is expected
[12:08] <Saviq> didrocks, that's scopes loading its results for the first time
[12:08] <Saviq> didrocks, the latter I haven't seen ever :|
[12:08] <didrocks> Saviq: I get it really frequently
[12:08] <didrocks> I guess popey told it as well
[12:08] <didrocks> Saviq: we really just have the default (I wiped it yesterday)
[12:08] <didrocks> the only thing, as told, my network is quite effective…
[12:09] <didrocks> (and it's worse sometimes, really noticeable)
[12:09] <Saviq> mhr3, you're not blocking the UI any more are you?
[12:10] <mhr3> Saviq, when sending a query i might
[12:10] <mhr3> Saviq, but there are no queries sent in this case
[12:11] <Saviq> grr
[12:14] <Saviq> 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
[12:16] <mhr3> let me record what i see
[12:21] <mhr3> Saviq, https://drive.google.com/file/d/0BxxLngWtDRLjbmZMNHZpUDNYdG8/edit?usp=sharing
[12:22] <mhr3> smaller jerk, but still a jerk
[12:22] <didrocks> mhr3: got something similar sometimes
[12:23] <MacSlow> 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] <Saviq> MacSlow, it's not about that
[12:25] <Saviq> MacSlow, it's about the Provides: unity-notification-impl-$foo
[12:25] <Saviq> MacSlow, and Version: in unity-notifications.pc
[12:26] <Saviq> MacSlow, and Depends: unity-notifications-impl-$foo in unity8
[12:26] <MacSlow> Saviq, sure... but it needs to start there
[12:26] <Saviq> that's unity-api, unity-notifications, unity8, respectively
[12:27] <MacSlow> Saviq, it should be based on the unity-api-version number and not on the package-version
[12:29] <Saviq> MacSlow, yes, the two are somewhat unrelated
[12:29] <Saviq> 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] <Saviq> mhr3, I killed my scopes scope, and it just goes fluently to the dash...
[12:30] <mhr3> Saviq, the only thing i see is
[12:30] <mhr3> file:///usr/share/unity8/Dash/CardFilterGrid.qml:36:5: QML FilterGrid: Binding loop detected for property "height"
[12:30] <mhr3> lots of it though
[12:30] <mhr3> but probably not during the unlock
[12:30] <Saviq> mhr3, yeah, only interesting part is during the unlock
[12:30] <mhr3> hmmm
[12:30] <mhr3> QIODevice::write: device not open
[12:31] <Saviq> nah
[12:32] <mhr3> Saviq, just an unlock - http://paste.ubuntu.com/7261216/
[12:32] <Saviq> mhr3, ok that's interesting...
[12:32] <mhr3> Saviq, and plus displaying empty scopes scope
[12:32] <mhr3> so... ehm?
[12:33] <Saviq> well, still shouldn't cause that
[12:33] <Saviq> but shouldn't be there in the first place
[12:33] <Saviq> (not to mention the binding loop doesn't make sense)
[12:33] <mhr3> Saviq, aren't you running tsdgeos's opti branch?
[12:33] <Saviq> mhr3, no
[12:33] <mhr3> hm, ok no idea then
[12:35] <Saviq> ah, well, the binding loop is "kind of" there
[12:36] <Saviq> mhr3, ok, nothing else I can get from you without profiling it... do you know if it persists across unity8 restarts?
[12:36] <didrocks> I have the same binding loop detection
[12:36] <didrocks> (across reboots)
[12:37] <Saviq> didrocks, and the jerky unlock, too?
[12:37] <didrocks> Saviq: yeah, I get that really regularly
[12:37] <didrocks> across reboots/versions
[12:38] <didrocks> (and not always on the first unlock)
[12:38]  * Saviq must try with broken 3G or something
[12:38] <Saviq> mhr3, does scopes scope use network for surfacing?
[12:39] <Saviq> (other than icons)
[12:39] <mhr3> Saviq, does that matter?
[12:39] <Saviq> mhr3, it might, that's what I'm trying to find out
[12:39] <mhr3> even if it does it's outside of unity process
[12:40] <Saviq> mhr3, yeah but if you're blocking on query, it might still affect unity8, no?
[12:40] <Saviq> or is the place you're blocking at only pinging scope-registry
[12:41] <mhr3> no, the blocking happens only between the time a client requests a query creation and the query object being created
[12:41] <mhr3> anything else is fully async
[12:41] <mhr3> and the network query == anything else
[12:41] <Saviq> mhm
[12:42] <Saviq> mhr3, can you consistently reproduce across unity8 restarts?
[12:42]  * mhr3 tries
[12:43] <Saviq> Cimi, you broke something https://jenkins.qa.ubuntu.com/job/generic-mediumtests-builder-trusty-armhf/4456/console
[12:44] <Saviq> Cimi, QT_QPA_PLATFORM is no longer in the environment
[12:44] <Saviq> Cimi, for three of the tests
[12:45] <mhr3> Saviq, not really, first unlock was jerky but now it's ok
[12:45] <mhr3> fwiw the binding loops are still there
[12:45] <Saviq> mhr3, yeah
[12:46] <Saviq> those are spurious warnings
[12:46] <Saviq> well, still need to get rid of them
[12:46] <MacSlow> 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] <Saviq> MacSlow, well, that's standard
[12:47] <Saviq> MacSlow, you need to bump unity-api indeed, and bump the B-D in unity-notifications
[12:47] <mhr3> Saviq, even the greeter itself refreshes much faster, i no longer need to wait 3 seconds for it to settle
[12:49] <Saviq> mhr3, right, so, you wanna add "-qmljsdebugger=port:3768" to unity8.conf's exec args...
[12:49] <Saviq> MacSlow, so, all in all, build-depends are handled as usual, only runtime deps are special
[12:49] <Saviq> mhr3, and the next time you encounter that - connect to it and do some profiling
[12:49] <Saviq> didrocks, ↑
[12:51]  * didrocks notes
[12:51] <didrocks> Saviq: can't really do testing atm, firedrills on firedrills…
[12:51] <Saviq> didrocks, I understand, just letting you know, I'll be trying to repro it, too
[12:52] <didrocks> yep ;)
[13:03] <MacSlow> 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 <unity/api/Version.h>) or predict the upcoming package-version number of libunity-api-dev (7.80.7) in unity-notifications build-deps?
[13:03] <mhr3> Saviq, with that do i connect to it and what do i do once i am connected?
[13:03] <mhr3> s/that/what/
[13:03] <MacSlow> Saviq, I haven't done that type of thing in ages
[13:03] <Saviq> MacSlow, don't "predict", bump it in unity-api
[13:04] <MacSlow> Saviq, so just the check in the header... ok
[13:04] <Saviq> MacSlow, you just need an UNRELEASED changelog entry in unity-api's debian/changelog
[13:05] <Saviq> MacSlow, the train machinery only deals with the part after +
[13:06] <Saviq> MacSlow, so just add an UNRELEASED at 7.80.7-0ubuntu1 or whatever the scheme is there
[13:06] <mterry> 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] <MacSlow> Saviq, ok
[13:06] <Saviq> mterry, hey
[13:06] <Saviq> mterry, https://code.launchpad.net/~mterry/unity8/greeter-ux-fixes/+merge/210042
[13:06] <Saviq> mterry, three issues found during testing
[13:07] <mterry> Saviq, ask and I shall receive.  looking into it
[13:07] <mterry> Saviq, I did strip tags from all my remote and local branches!  How'd they sneak in
[13:08] <Saviq> mterry, that's an old comment
[13:08] <Saviq> mterry, you're clean
[13:08] <Saviq> mterry, last two comments are relevant
[13:08] <mterry> ah I see
[13:08] <kgunn> MacSlow: curious if you're working one similar to this ?
[13:08] <kgunn> https://bugs.launchpad.net/unity-mir/+bug/1308368
[13:09] <kgunn> sounds maybe more like unity-mir in general...
[13:09] <MacSlow> kgunn: no
[13:09] <Saviq> kgunn, we'll have to split notifications out of dash to fix that - post - QtComp work
[13:09] <MacSlow> kgunn: after the unity-api version thing I wanted to jump on bug https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1308011
[13:10] <Saviq> kgunn, or well composite OSK on the correct layer - so yah, QtComp work
[13:11] <kgunn> yeah, might be better to "leave it" until Qt comp
[13:12] <MacSlow> kgunn: but I can tackle (or at least look closer at it) that after 1308011
[13:15] <MacSlow> 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:16] <tsdgeos> 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] <tsdgeos> not saying there's more things to be investigated/improved
[13:16] <Saviq> tsdgeos, sure
[13:17] <tsdgeos> but what we have is defenitely an improvement i'd say
[13:17] <tsdgeos> so worth going in to make people a bit happier
[13:17] <kgunn> MacSlow: sure, but landscape is a bit irrelevant to the stacking order...
[13:18] <Saviq> tsdgeos, slightly unrelated: FilterGrid.qml:69 - we're getting binding loop warnings off that all the time
[13:18] <Saviq> tsdgeos, and I can't say I disagree...
[13:18] <tsdgeos> yep
[13:18] <tsdgeos> that's the next one i want to tackle
[13:18] <Saviq> tsdgeos, ok
[13:18] <Saviq> tsdgeos, I think we talked about this
[13:18] <tsdgeos> it even happens at times hickups happen
[13:19] <MacSlow> 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] <tsdgeos> so it may or may not be related
[13:19] <tsdgeos> but killing them is a good thing for sure
[13:19] <kgunn> MacSlow: ah... true, would need a autoscroll to have text entry in view, for sure...
[13:20] <MacSlow> 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] <Saviq> 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] <Saviq> -s
[13:21] <dandrader> greyback, so, is it time to create a proper home (lp project) for qpamirserver?
[13:21] <MacSlow> kgunn: then such problems could be avoided
[13:21] <greyback> dandrader: ah yes, that reminds me
[13:22] <greyback> Saviq: have you had chance to think over https://docs.google.com/a/canonical.com/document/d/163nyfh_G90nzQnRdI7IYgrMH_0VdmesBju5jpb4wse0/edit
[13:23] <Saviq> greyback, not yet, probably not today, either
[13:23] <greyback> Saviq: no rush
[13:23] <greyback> dandrader: your answer: not yet :D
[13:24] <greyback> dandrader: if you're idling, I've plenty of ideas still :)
[13:24] <dandrader> greyback, shoot
[13:24] <kgunn> guys...might want to tackle that trusty-touch releast day+1
[13:25] <kgunn> knowing Saviq might be close to melting
[13:25] <greyback> true
[13:27] <kgunn> hey speaking of trusty touch, i thot media hub was gonna land, and that would decouple music from this qt/egl block bug ?
[13:27] <Cimi> Saviq, I did set(qmltest_DEFAULT_PROPERTIES ENVIRONMENT "'QT_QPA_PLATFORM=minimal' 'LC_ALL=C'")
[13:27] <kgunn> ah waiting for QA signoff...
[13:28] <Saviq> Cimi, why did you put them in quotes?
[13:28] <Saviq> Cimi, in single quotes I mean
[13:28] <Cimi> Saviq, because otherwise QT_QPA_PLATFORM is "minimal lc_all=c"
[13:28] <Saviq> Cimi, but apparently I was wrong
[13:28] <Saviq> Cimi, they need to be semicolon-separated :|
[13:29] <Cimi> so "QT_QPA_PLATFORM=minimal;LC_ALL=C"
[13:29] <Cimi> i'll try
[13:29] <asac> kgunn: in the last two landing meetings rsalveti said that media is not ready; might be that we are now readyu and could take a shot
[13:30] <kgunn> asac: yep...was more curious than anything
[13:32] <Cimi> Saviq, I'm ready for a new bug
[13:32] <Cimi> had lunch... feeling fine
[13:34] <rsalveti> kgunn: asac: the qt thing would still be an issue afaik
[13:34] <rsalveti> it is at least when testing the silo
[13:34] <kgunn> rsalveti: absolutely...
[13:34] <rsalveti> I still need to unblank the screen to go to the next song
[13:35] <kgunn> rsalveti: oh...really...ok
[13:35] <kgunn> rsalveti: i meant i know it'd still be a global issue (e.g. alarms and such)...but thot the song advance would be fixed
[13:35] <asac> rsalveti: feels like a bug thogh, no?
[13:35] <asac> i mean the idea is that it continues playing through playlist
[13:35] <asac> even if the app is dead
[13:35] <kgunn> asac: apps not dead
[13:36] <kgunn> just screen off
[13:36] <asac> kgunn: no just sayuing that the lifecycle thing would in tehorry kill the app alltogether
[13:36] <asac> and media hub continues working
[13:36] <kgunn> thot is was whitelisted
[13:36] <asac> sure sure
[13:36] <asac> just saying that its a bug if mediahub requires application to do anything to continue playing next song
[13:37] <kgunn> oh i see
[13:37] <asac> so if the event loop bug that causes the app to stop causes mediahub to not forward to next song, there is something fishy in mediahub still
[13:37] <asac> but maybe i am missing something
[13:37] <rsalveti> oh, right, because ricmm still needs to finish the backgroundplaylist implementation
[13:37] <asac> right. so no playlist support yet
[13:37] <rsalveti> and then change music-app to use that
[13:37] <asac> makes sense then
[13:38] <rsalveti> not sure where we stand with that, will try to ping him
[14:01] <paulliu> Have anyone tried to run unity-mir on Desktop already? I got black screen. After one minute, it goes back to lightdm and system halts.
[14:08] <dandrader> should I see anything on the dash when I ./run unity8 on my desktop?
[14:10] <dandrader> damn. closed the unity8 window instead of ctrl+c. so, should I see anything on the dash when I ./run unity8 on my desktop?
[14:12] <mterry> Saviq, so launcher in tablet-greeter -- I don't recall offhand why the current code disallows it.  But it is rather explicit in code.  Do you remember?
[14:13] <Saviq> mterry, I think the binding there is broken then, it was only meant to be disallowed when account had pin/pwd
[14:13] <Saviq> mterry, if open, launcher should just work, as on phone
[14:14] <Saviq> mterry, now you mention it I remember I saw that some time before indeed
[14:14] <mterry> Saviq, why would we disable when locked?  I thought the interaction then would be show login prompt?
[14:14] <Saviq> mterry, yeah, that wasn't the plan before I think
[14:14] <Saviq> mterry, so yeah, rather legacy
[14:15] <mterry> Saviq, although now that I think about it...  The interaction was that we launch app in background while we show the prompt.  But that seems odd from a security perspective -- maybe we should wait to launch until authenticated.  But anyway
[14:16] <mterry> Saviq, OK, well I'll re-enable launcher in my branch then
[14:17] <mterry> Saviq, I think  it's ready for landing again, unless we want to hold off of Jouni's comments regarding the tease
[14:17] <Saviq> mterry, I kicked another landing already, so not before yesterday
[14:18] <mterry> yesterday?
[14:19] <Saviq> mterry, tomorrow ;)
[14:19] <Saviq> mterry, sorry, OnAir now, brain not working well ;)
[14:20] <mterry> Saviq, oh hah.  I'll let you alone then so you can devote all your grey cells  ;)
[14:26] <MacSlow> Saviq, ok... all needed changes (MRs) for the required version-bump are in place now. I hope I didn't overlook anything. Packages do build, if added depedencies are satisfied
[14:26] <Saviq> MacSlow, cool, thanks, will look at those tomorrow
[14:26] <MacSlow> Saviq, ok
[14:37] <Saviq> mhr3, good call on the qt event loop, I didn't notice the time there :)
[14:44] <greyback> dednick: that was an issue with mir around 0.1.7
[14:44] <greyback> dednick: or maybe 0.1.8. A fix landed definitely in mir/devel for it.
[14:45] <greyback> dednick: a workaround was to use LD_PRELOAD=/path/to/libmirserver.so
[14:57] <Saviq> paulliu, please let me know when you have the log out branches up for review, I think we can do without the prompt in unity8 for now, so make shortcuts if possible
[14:59] <paulliu> Saviq: ok.
[15:03] <tsdgeos> Saviq: any clue about this one? https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-trusty/1696/testReport/junit/%28root%29/qmltestrunner/tst_listviewwithpageheaderqml__compile/
[15:03] <dednick> mterry: is this it? lp:~mterry/mir/missing-links
[15:03] <Saviq> tsdgeos, huh
[15:03] <mterry> dednick, yes, sorry.  Got distracted in an IRC convo
[15:04] <dednick> mterry: no worries. it just missed 0.1.8 . which is why mine is not working :)
[15:04] <tsdgeos> Saviq: yeah that :D
[15:05] <mterry> dednick, I thought we backported it
[15:05] <paulliu> Saviq: I think I got problems testing my unity-mir code.
[15:05] <paulliu> Saviq: In what case that part of code will be executed?
[15:05] <mterry> dednick, I think it was backported in lp:mir, but maybe not lp:mir/devel
[15:05] <dednick> mterry: backported to lp:mir most likely
[15:05] <paulliu> Saviq: Running unity on mir?
[15:06] <Saviq> paulliu, yes, only on mir
[15:06] <mhr3> Saviq, i see de... things :)
[15:06] <Saviq> mhr3, devel?
[15:07] <Saviq> mhr3, that's mir :P
[15:07] <paulliu> Saviq: Strange things happened on my desktop. If I login by unity-mir from lightdm, I got black screen. It doesn't work. And strange things also happened if I switch to console and found that com.canonical.Unity.WindowStack is provided by window-stack-bridge in hud. Not the lib itself?
[15:07] <mhr3> Saviq, too late for 6th sense references? :)
[15:07] <Saviq> mhr3, yes, probably
[15:07] <Saviq> mhr3, dead where?
[15:07] <kiko> mhr3, ping?
[15:07] <mhr3> damn, i'm old :)
[15:08] <mhr3> kiko, pong
[15:08] <kiko> mhr3, an install from a freshly downloaded trusty iso has applications not showing up in the dash search
[15:08] <paulliu> And window-stack-bridge is bringed up by upstart sessions.
[15:08] <kiko> mhr3, so for instance, looking for "terminal" returns nothing in the applications category
[15:08] <Saviq> paulliu, on desktop window-stack-bridge talks to X11
[15:08] <kiko> though I do helpfully get offered the terminator movie
[15:08] <Saviq> paulliu, on phone unity-mir exposes them
[15:08] <kiko> mhr3, also, looking for gimp gives me a BSDM result in the top row
[15:08] <Saviq> tsdgeos, I get the same locally
[15:08] <kiko> which I found pretty avant-garde
[15:09] <mhr3> kiko, bsdm?
[15:09] <mhr3> kiko, also nothing changed there for the past 6months
[15:09] <Saviq> tsdgeos, "make -C builddir testlistviewwithpageheaderqml"
[15:09] <tsdgeos> Saviq: that is weird, i didn't change anything there, did I?
[15:09] <Saviq> tsdgeos, maybe the iterations thing?
[15:09] <kiko> mhr3, yeah, I take you are not into that sort of thing?
[15:09] <kiko> anyway
[15:09] <tsdgeos> Saviq: ok, i'll check
[15:09] <kiko> my point is that there is something weird
[15:09] <kiko> mhr3, what should I do to try and understand where the problem might come from?
[15:10] <paulliu> Saviq: for logout. Isn't that for X11 things?
[15:10] <Saviq> tsdgeos, actually no, the QmlTest.cmake changes
[15:10] <paulliu> Saviq: I think we want to fix Desktop versions?
[15:10] <mhr3> kiko, take a look if the scope processes are running
[15:10] <Saviq> paulliu, no, that's for a Unity8 on Mir session, desktop, not X11
[15:10] <tsdgeos> Saviq: they looked pretty safe to me :/
[15:10] <paulliu> Saviq: ok.
[15:10] <mhr3> kiko, then bustle log might show something
[15:10] <paulliu> Saviq: got it.
[15:10] <paulliu> Saviq: So my problem is shrinked. unity-mir doesn't run on my computer and I have to figure that out.
[15:11] <paulliu> Saviq: And window-stack-bridge shouldn't be there.
[15:12] <Saviq> paulliu, the latter probably doesn't matter
[15:12] <kiko> mhr3, there are 6 processes running with unity-scopes in their names, but I don't know if there is a special scope that needs to run for the application scope to function
[15:12] <Saviq> paulliu, but yeah, you need to have a unity8 on mir running somewhere
[15:12] <kiko> mhr3, what is the bustle log?
[15:12] <Saviq> paulliu, phone/tablet would be good enough, you'd just have to either call the dbus methods manually
[15:13] <paulliu> Saviq: ok
[15:13] <Saviq> paulliu, or change the indicator profiles to desktop, but yeah, ideally you'd test on desktop unity8+mir session
[15:13] <mhr3> kiko, app that records dbus traffic
[15:13] <kiko> mhr3, where do I look
[15:14] <mhr3> apt-get install bustle
[15:14] <kiko> mhr3, aha
[15:14] <mhr3> logout, login, ctrl+alt+t to run terminal, run `bustle`, start logging, press the super key
[15:16] <Saviq> tsdgeos, you need to pass "leftover" arguments down
[15:17] <Saviq> tsdgeos, ${ARGN} should work
[15:17] <tsdgeos> Saviq: yep, works, was doing just that
[15:17] <Saviq> tsdgeos, we'll land that fix separately, don't want to rebuild again
[15:18] <tsdgeos> Saviq: so you want a different branch?
[15:18] <Saviq> tsdgeos, same branch is fine
[15:18] <Saviq> tsdgeos, just that last revision will get in in the next landing
[15:18] <tsdgeos> if nothing breaks
[15:18] <tsdgeos> sure :)
[15:18] <tsdgeos> pushed
[15:18] <Saviq> yeah exactly
[15:25] <mterry> dednick, thanks for the indicator-sound fix for my stupid feedback loop.  Will test
[15:27] <dednick> mterry: :) no worries
[15:27] <dednick> bit of a tricky one that. the solution is a bit crap
[15:28] <mterry> dednick, could we send less updates?
[15:29] <dednick> mterry: yeah. i'm not sure why the desktop does so many. the slider only updates every second or so, but we still get a flood of changes in one batch. As for unity8, we need to put a throttle in for the slider. It throws them out in excess.
[15:30] <dednick> for the desktop, it seems to be queuing the events up, and then emitting events every second or so
[15:30] <mterry> dednick, I guess you do want live updates...  since the icon in the bar should match where the slider is
[15:30] <mterry> low-volume or high-volume icon at least
[15:30] <dednick> mterry: yeah, but maybe only every few hundred ms or so. we get dozens every time you change.
[15:31] <mterry> dednick, hmm so your branch listens less, but how hard is it to send less?
[15:31] <mterry> could still use the same timer thinking
[15:31] <dednick> mterry: it sends less as well.
[15:32] <mterry> oh ok
[15:32] <dednick> mterry: it sends to account services less, but keeps the local volume correct
[15:33] <mterry> dednick, I see.  So we only listen to AS after a second of changing our own
[15:34] <dednick> mterry: ya. all the receives are processed, but only in one update 1 second after the last receive
[15:34] <dednick> well, not all of them i mean. they're merged into a single update 1 second after the last receive
[15:35] <mterry> OK, well I have to eat lunch, but will test with it
[15:35] <dednick> mterry: ta
[15:41] <mhr3> kiko, will you attach the bustle log to the bug?
[15:45] <kiko> mhr3, one log out and back in and it's working unfortunately
[15:46] <mhr3> sucks
[15:56] <kiko> you said it
[15:59] <Cimi> Saviq, what's the right syntax for  set(qmltest_DEFAULT_PROPERTIES ENVIRONMENT "QT_QPA_PLATFORM=minimal" "LC_ALL=C") ?
[16:04] <tsdgeos> Saviq: so no, the binding loop was not causing the performance slow down, but at least it's gone now :D
[16:04] <tsdgeos> Cimi: what's wrong with that?
[16:04] <Cimi> tsdgeos, doesn't work here
[16:06] <mhr3> Cimi, "FOO=bar;QOO=baz"
[16:07] <Cimi> didn't work too
[16:07] <mhr3> we're using it
[16:07] <mhr3> so i'm pretty sure it does
[16:07] <tsdgeos> mhr3: that and the first is the same
[16:07] <tsdgeos> so "doesn't work" is probably "doesn't work somewhere else or doesn't do what i'd like it to do"
[16:08] <Cimi> cmake complains
[16:08] <Cimi> CMake Error at cmake/modules/QmlTest.cmake:154 (set_target_properties):
[16:08] <Cimi>   set_target_properties called with incorrect number of arguments.
[16:08] <Cimi> Call Stack (most recent call first):
[16:08] <Cimi>   cmake/modules/QmlTest.cmake:115 (add_qmltest_target)
[16:08] <Cimi>   tests/qmltests/CMakeLists.txt:16 (add_qml_test)
[16:08] <tsdgeos> right,so it's not the "set" that fails is just that set_target_properties doesn't like being called with a stringlist instead of a string it seems
[16:09]  * tsdgeos needs to go
[16:09] <tsdgeos> tty tomorrow
[16:09] <mhr3> Cimi, we're using
[16:09] <mhr3>         set_tests_properties(test${CLASSNAME}${_test}
[16:09] <mhr3>                 PROPERTIES ENVIRONMENT "QT_QPA_PLATFORM=minimal;LD_LIBRARY_PATH=${CMAKE_BINARY_DIR}/plugins/Unity:${LIBUNITYPROTO_LIBRARY_DIRS};UNITY_SCOPES_RUNTIME_PATH=${SCOPES_TEST_RUNTIME};UNITY_SCOPES_LIST_DELAY=5")
[16:09] <Cimi> mhr3, that's a different command
[16:10] <Cimi> set(qmltest_DEFAULT_PROPERTIES ENVIRONMENT ..
[16:10] <Cimi> not set_tests_properties
[16:10] <mhr3> ah, didn't notice that
[16:10] <mhr3> so perhaps use that :)
[16:12] <tsdgeos> whatthe
[16:12] <tsdgeos> search people stopped working in launchpad?
[16:12] <tsdgeos> mzanetti: that's yours
[16:12] <tsdgeos> https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1308631
[16:12] <tsdgeos> mzanetti: search fails so can't assign it to you
[16:12] <tsdgeos> mzanetti: can you assign it to yourself?
[16:12] <mzanetti> tsdgeos: yes
[16:13] <dednick> hm. i used it a couple of hours ago
[16:13] <tsdgeos> same here
[16:13] <tsdgeos> but for some reason
[16:13] <tsdgeos> now it says "search team"
[16:13] <tsdgeos> instead of search people
[16:14] <tsdgeos> "Select a team of which you are a member"
[16:14] <tsdgeos> anyway
[16:14] <tsdgeos> tomorrow more
[16:49] <asac> kgunn: what is the unity8 thing fixing that we are landing?
[16:50] <asac> kgunn: is this worth risking not being able to get our browser fixed?
[16:50] <asac> we will not have time to do anything if anything is broken with this
[16:50] <kgunn> asac: which line ?
[16:50] <kgunn> silo ?
[16:51] <asac> kgunn: "Unity8 updates
[16:51] <asac> - test fixes
[16:51] <asac> - carousel last item fix
[16:51] <asac> - fix preview widgets
[16:51] <asac> - improve indicator startup
[16:51] <asac> - improve dev scripts
[16:51] <asac> - new default backgrounds
[16:51] <asac> - cleanup
[16:51] <asac> - first go at scope optimizations"
[16:51] <asac> kgunn: so just heard we can back it out in theory
[16:51] <asac> so lets do it
[16:51] <asac> will be super stressful, but can still be kicked out if we get someone testing the image coming out tonight
[16:51] <asac> so lets do it. worry
[16:51] <asac> soryy
[17:01]  * greyback_ gone out
[17:57] <mterry> dednick, commented on sound MP
[18:05] <dandrader> mterry, on the phone, what's the Lockscreen and what's the Greeter?
[18:05] <mterry> dandrader, greeter is what you're used to
[18:06] <dandrader> mterry, so Greeter is the thing showing that circular graph?
[18:06] <mterry> dandrader, Lockscreen is the bit that shows the pin/password entry (after swiping away greeter)  -- those bits aren't enabled on the image yet -- they need the split greeter
[18:06] <mterry> dandrader, yeah
[18:06] <mterry> dandrader, (the infographic)
[18:06] <dandrader> ok, thanks
[18:23] <dednick> mterry: thanks. i'll take a look tomorrow morning