[07:16] <Saviq> Cimi, coolz
[07:28] <djbello1> can anybody help? I had Mythbuntu installed and had a specific background image set. I have now moved to regular Ubuntu-desktop, and I have plenty of problems with the desktop. I finally got the lightdm unity-greeter working, but the background image is always the one I had previously. And when I go into the settings panel and try to set a different image, nothing changes at all. It's driving me nuts. I've already gotten rid of all hid
[07:29] <djbello1> And by moved I mean I installed the "ubuntu-desktop" package.
[07:31] <djbello1> I should also note that I had been running Mythbuntu 12.04 LTS for the longest time and just upgraded to 14.04 LTS today.
[07:35] <Saviq> djbello1, it's probably best if you post this on askubuntu.com or as a bug
[07:35] <Saviq> or maybe a mailing list
[07:36] <djbello1> aw man.
[07:37] <djbello1> I'll give it a shot then.
[07:49] <Mirv> Saviq: tsdgeos: are you ready for Qt 5.3? I still find it hard to understand which packages would need recompilation and which problems are clear bugs, but Unity8 starts now. scopes are clearly broken though despite the rebuilds. https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta2
[07:49] <Saviq> Mirv, we probably are not
[07:50] <Mirv> bugs at https://bugs.launchpad.net/bugs/+bugs?field.tag=qt5.3 against qtubuntu*, unity-api, unity-scopes-shell. I've disabled tests in unity-scopes-shell, qtubuntu, qtubuntu-sensors because some test failed, so that might be telling.
[07:50] <tsdgeos> i can't make unity-api nor unity-scopes-shell tests pass here
[07:50] <tsdgeos> not sure it is 5.3 related
[07:50] <tsdgeos> or that you need a special environment/knowledge
[07:50] <Saviq> tsdgeos, I just ran unity-api tests and they passed :?
[07:51] <tsdgeos> Saviq: really?
[07:51] <Saviq> tsdgeos, in your branch, no less
[07:51] <Mirv> tsdgeos: yep, same here in the PPA, which is why I filed the bugs and disabled tests to get builds going
[07:51] <tsdgeos> ok, then maybe it was scopes-shell only
[07:52] <tsdgeos> Saviq: i didn't do 2013 -> 2014 nor drop authors because it's a verbatim c&p
[07:52] <tsdgeos> Saviq: but i will :)
[07:53] <Saviq> tsdgeos, yeah, let's clean it up in the process? if you're unsure about the docs, maybe we should get mhr3 to doc them?
[07:53] <tsdgeos> Saviq: i don't think i can really add the docs
[07:53] <Saviq> tsdgeos, yeah, that
[07:53] <Saviq> tsdgeos, resubmit as ~unity-team then?
[07:53] <Mirv> Saviq: tsdgeos: darn, you're both not "there" next week yet. so, it'd be good to get opinions from you whether we would enjoy/need Qt 5.3 probably for this cycle, or if we need to stay at 5.2 (which would create problems in coordination with Kubuntu, that is, we might need to fork everything and block Debian autosyncs)
[07:53] <tsdgeos> ok, will fix your comments and resubmit
[07:53] <tsdgeos> Mirv: i'd prefer we switch at some point
[07:54] <tsdgeos> but that's me
[07:54] <tsdgeos> with my only-engineering pov
[07:54] <Saviq> Mirv, I don't think we'd block the switch, no
[07:54] <Saviq> Mirv, and I would like to switch, too, we'll look into what's happening this week
[07:55] <Saviq> tsdgeos, indeed -scopes-shell fails for me, too
[07:55] <Mirv> tsdgeos: Saviq: I added you rights to a doc that lists pros/cons. I was assuming we go for 5.3, but I'm now hearing more conservative thoughts and uncertainty.
[07:55] <Saviq> tsdgeos, ah wait, it complains about timeouts, maybe it requires the scope registry to work
[07:56] <Saviq> tsdgeos, heh, no that made it worse ;D
[07:57] <tsdgeos> Saviq: yeah
[07:57] <tsdgeos> now it's 21 vs 1
[07:57] <tsdgeos> or something :D
[07:58] <Saviq> tsdgeos, yeah, and failed in sbuild, too, we'll need mhr3 to get those going
[07:58] <tsdgeos> Saviq: yeah i had to comment the tests so i could dpkg-package
[07:58] <tsdgeos> and try my patch correctly
[07:58] <tsdgeos> which doesn't work btw
[07:58] <Mirv> Saviq: feel free to edit your quote ;)
[07:58] <tsdgeos> that's why is still in wip  ;)
[07:59] <Saviq> tsdgeos, you can always NOCHECK=1 when dpkg-buildpackage
[07:59] <tsdgeos> Saviq: ah
[07:59] <Saviq> or NO_CHECK=1? Mirv, which one is it?
[07:59] <tsdgeos> i thought that was package dependant
[07:59] <tsdgeos> and not build wise
[08:02] <Mirv> tsdgeos: Saviq: I tend to add an empty override_dh_auto_test: in debian/rules
[08:02] <Saviq> Mirv, "extra work" is not an argument IMO, we'd need work to backport fixes from stable, and that's not necessarily less work than adapting to 5.3, which is a much less disruptive change
[08:03] <Mirv> Saviq: correct, removing
[08:03] <Mirv> it's quite unrealistic to think 5.2 would be now bug free
[08:03] <Saviq> Mirv, "Risks in quality" sounds like we deem 5.3 be of worse quality...
[08:04] <tsdgeos> Mirv: it is totally not :D
[08:05] <Mirv> Saviq: tsdgeos: well, it's risky in the sense that for example now we have tests failing and scopes not working :)
[08:05] <tsdgeos> and the more we find issues with it (specially in qml) will be harder to get proper fixes once they have moved to 5.3 stable
[08:05] <tsdgeos> seems we've been lucky and not having much of those lately thoguh
[08:05] <Saviq> Mirv, sure, but that's not a "quality risk", that's just us not being ready for 5.3, 'cause we're using private headers here and there ;)
[08:05] <Mirv> but as always, if the biggest hurdles can be won in relatively little time, most apps work etc then we can start validating it
[08:05] <Saviq> tsdgeos, indeed, you fixed them all!
[08:06] <Saviq> Mirv, it all *builds*, that's like a huge improvement already ;D
[08:06] <Mirv> Saviq: right, leaving that bug mention the only, it covers the problems as soon as problems are identified
[08:06] <Mirv> Saviq: :D
[08:06]  * Saviq tries it out
[08:12] <dednick> Saviq: hey. got a problem with the AccountsService dbus object in unity8. The volume indicator updates the accounts service with the user volume directly, and unity8 responds to property changes on the accounts service (background, demo-edges, etc). problem is, that calls into dbus properties seem to be blocking dbus "Get" calls.
[08:13] <dednick> Saviq: causing a lag when dragging around the indicator slider. whole UI blocks (which is pretty bad!)
[08:13] <dednick> Saviq: should be on a thread?
[08:13] <Saviq> dednick, and mterry's change in the indicator didn't help?
[08:13] <dednick> Saviq: yeah. that was one issue. this is a nother
[08:14] <dednick> Saviq: the stuttering is gone. but every second you are dragging the slider, there is a short UI block
[08:14] <Saviq> dednick, are any of the set operations synchronous?
[08:14] <dednick> Saviq: because of this: QDBusMessage answer = iface->call("Get", interface, property);
[08:15] <dednick> Saviq: the Get ops are sync
[08:15] <Saviq> dednick, any idea why that Get takes so long?
[08:16] <dednick> Saviq: no idea. theres a tiny block on desktop as well, but it's not as long as phone
[08:17] <Saviq> dednick, so... in any case yeah this should be wrapped in a lib (we shouldn't be calling dbus directly)
[08:17] <Saviq> dednick, and there the operations should be threaded indeed
[08:20] <Saviq> dednick, well, you could say our QML plugin is the lib, so we could just put it in a thread there as a band-aid
[08:20] <dednick> Saviq: yeah. ok
[08:26] <Saviq> mhr3, are unity-scopes-shell tests working for you?
[08:26] <Saviq> mhr3, this seems to be happening for me on 5.2 as well: bug #1318921
[08:27] <Saviq> and to tsdgeos, too
[08:28] <Saviq> Mirv, :| unity-api passes locally
[08:28] <Saviq> Mirv, and it's a segfault on the builders
[08:28] <Saviq> not good
[08:34] <dpm> morning mhr3, I'm testing scopes translations and I've come across this untranslated string: "Preview" in here. Do you know where it comes from? I think it'd need to be marked for translation in the code, but I'm not sure where to file the bug against
[08:34] <dpm> mhr3, as in this screenshot: http://i.imgur.com/xTiwh2F.png
[08:35] <Mirv> Saviq: those are the most annoying kind :(
[08:35] <Cimi> tsdgeos, Saviq shadows rocking this way https://code.launchpad.net/~cimi/unity8/carousel-shadow/+merge/219233
[08:51] <wtrb> new unity user here. Could anyone point me to how to enable horizontal mouse wheel scrolling?
[08:54] <Saviq> wtrb, there are some settings in the "Mouse and touch pad" section in the settings (top right "cog" icon → settings)
[08:54] <Saviq> wtrb, it doesn't have anything about scrilling horizontally with a mouse wheel, though...
[08:57] <wtrb> Saviq, thanks for the reply. Yes there's nothing there as you say. I was guessing I'd have to use some command line option, but not sure which one.
[08:58] <Saviq> wtrb, best to ask on askubuntu.com
[08:59] <wtrb> will do, thanks
[09:01] <mhr3> dpm, it's in shell itself
[09:02] <mhr3> dpm, but that whole thing will go away
[09:02] <dpm> mhr3, what does exactly "will go away" mean and when?
[09:03] <mhr3> dpm, latest designs replaced it with the title itself
[09:06] <greyback> dammit why did my keyboard shortcuts get reset??
[09:09] <mhr3> greyback, cause you should be using hud!
[09:09] <dpm> mhr3, ok thanks. So I guess I should ask Saviq for the shell. Saviq, so I'm testing translations for a MAE demo next week, and I came across this "Preview" string that's untranslated. mhr3 tells me that it comes from the shell and it will go away. Depending on when, I'd like to find out whether it's worth fixing it for the demo or just wait for the new designs to land. What do you think? http://i.imgur.com/xTiwh2F.png
[09:10]  * greyback shakes his fist at mhr3
[09:12] <Saviq> dpm, mhr3, I think we should fix this in unity8 still, I believe this will involve a bit more to put the title in there (like we need to tweak the preview APIs to accommodate this)
[09:12] <mhr3> Saviq, result.title || "Preview"
[09:13] <Saviq> mhr3, think that's it? we don't want the scope to have more control over this?
[09:13] <mhr3> not unless says so
[09:13] <mhr3> design says so
[09:14] <Saviq> mhr3, well, yeah, OTOH I didn't see a signed-off design yet which does have the title in the header ;)
[09:14] <mhr3> Saviq, and you won't until after malta :)
[09:15] <Saviq> mhr3, yes, that's exactly why I think we should fix i18n for it
[09:15] <Saviq> Mirv, did you carry the "delegate creation" patch to 5.3? that's why unity8 doesn't work well
[09:15] <Saviq> Mirv, that == not finding the added property
[09:15] <Saviq> Mirv, maybe we need to adapt the patch
[09:17] <Mirv> Saviq: oh, no I didn't. it would need adaptation (adaptation welcome), on these quick packages I just commented out most of the patches since most of them where backports anyhow.
[09:18] <Saviq> Mirv, you have a branch somewhere or should I just apt-get source and ping you with the adapted patch?
[09:19] <Mirv> Saviq: just pushed, before you asked, to https://code.launchpad.net/~timo-jyrinki/kubuntu-packaging/qtdeclarative-opensource-src_qt530RC
[09:19] <dpm> mhr3, Saviq, so where do I best file the bug to request internationalization of that string in the meantime while the new designs have not landed?
[09:19] <Saviq> dpm, with unity8, let me just put up a branch, gimme 3 mins
[09:20] <dpm> awesome
[09:20] <Saviq> Mirv, tsdgeos_, btw looks like scopes-shell failing tests are handled here https://code.launchpad.net/~unity-api-team/unity-scopes-shell/fix-tests-after-config-branch/+merge/219177
[09:20] <tsdgeos_> :)
[09:20] <Mirv> Saviq: you'd need the orig tarball anyway from the PPA to the parent dir, and you may want to do bzr rm debian/*.symbols for builds. yes, ping welcome!
[09:20] <Mirv> Saviq: the old patch is still there, just commented out in debian/patches/series
[09:20] <Saviq> Mirv, got it
[09:20] <karni> mhr3: hey. what does "my-preview-one" stand for on the Scopes JSON structure definition doc? Can there be more than one preview?
[09:21] <karni> for a single element
[09:22] <mhr3> karni, that's for not-yet-implemented early-preview support
[09:22] <mhr3> ignore when dealing with regular preview request
[09:22] <mhr3> s
[09:22] <karni> mhr3: okay, thanks
[09:22] <karni> mhr3: but I still need to send that id, right?
[09:22] <karni> (some id)
[09:22] <mhr3> no
[09:23] <karni> so I just push everything 1 lvl up?
[09:23] <mhr3> there also isn't any "previews" key
[09:23] <mhr3> so 2 lvls
[09:23] <karni> ok, what should be the root key, "preview" ?
[09:23] <Saviq> dpm, hum, it's actually already there:
[09:23] <Saviq> https://translations.launchpad.net/unity8/trunk/+pots/unity8/en_GB/+translate?batch=10&show=all&search=preview
[09:24] <Saviq> dpm, which translation were you using, maybe it just misses this string?
[09:24] <dpm> Saviq, oh you're right, nice!, so it's probably not translated in my locale
[09:24] <dpm> let me check
[09:24] <mhr3> karni, hm, dunno tbh, do a request on the rest-server and look at it :)
[09:25] <mhr3> karni, also, remote/rest scopes are kindof no-no, are you sure you should be implementing them?
[09:25] <karni> mhr3: what do you mean by no-no?
[09:25] <dpm> Saviq, indeed, that was the case, thanks for the correction, and sorry for the noise
[09:25] <karni> mhr3: there are things local scopes are not suitable for
[09:26] <Saviq> dpm, no worries
[09:26] <karni> like attempting a search over RSS feed
[09:26] <mhr3> karni, i heard somewhere that most rtm scopes should be local ones
[09:26] <karni> what's rtm?
[09:26] <mhr3> karni, the final image
[09:26] <mhr3> the first one
[09:27] <karni> Well, I'll forward that feedback to Chris, thanks.
[09:30] <Saviq> tsdgeos_, , hum hum hum
[09:30] <Saviq> tsdgeos_, do you know "displayMarginBeginning" and "displayMarginEnd"?
[09:31] <tsdgeos_> Saviq: doesn't ring a bell, where?
[09:31] <Saviq> tsdgeos_, delegateCreation* conflicts with them https://github.com/special/qtdeclarative/commit/40ce9bb0d3a640e16f44ab5aaeb2d050386ffb07
[09:31] <Saviq> tsdgeos_, in 5.3
[09:32] <tsdgeos_> because it does te same thing
[09:32] <tsdgeos_> ^_ ^
[09:32] <tsdgeos_> obviosuly w00t has more pull than i do
[09:33] <tsdgeos_> or he just bypassed aalpert
[09:33] <Saviq> tsdgeos_, exactly... assuming they can be set to negative values
[09:34] <Saviq> tsdgeos_, but I see nothing to prevent that
[09:34] <mhr3> Saviq, could you take a look at https://code.launchpad.net/~mhr3/unity8/update-scope-tool/+merge/219024 pls?
[09:34] <Cimi> @unity + seb128 and whoever knows
[09:34] <Cimi> I am back with my wifi issue that my phone says connected but it's not
[09:34] <Cimi> how do I fix this?
[09:34] <Cimi> I keep rebooting but no luck so far
[09:35] <tsdgeos_> Saviq: we should investigate dropping it and if our patches have some other thing this one doesn't have
[09:35] <seb128> no idea, talk to cyphermox when it's not middle of the night anymore for him I guess?
[09:35] <Cimi> seb128, I am sure I am not alone in this, did anyone reported this issue?
[09:35] <Cimi> seb128, I think it got worse over the past weeks
[09:36] <seb128> Cimi, you better ask on #ubuntu-touch, ogra had routing issues iirc
[09:36] <Cimi> ok
[09:36] <Saviq> tsdgeos_, indeed, could you please do that when you have a moment?
[09:36] <Saviq> tsdgeos_, this seems to be the actual commit into qtdeclarative https://qt.gitorious.org/qt/qtdeclarative/commit/a46312b3b5f97802b8a74e53a86ce4a57df320ef
[09:36] <tsdgeos_> Saviq: i'll write me a note somewhere
[09:37] <tsdgeos_> Saviq: bah aalpert did review it
[09:37] <Saviq> tsdgeos_, nasty
[09:37]  * tsdgeos_ shuts up 
[09:37] <tsdgeos_> and works
[09:40] <Saviq> Mirv, so... it looks like the patch we had to carry was ~implemented upstream... after having been rejected first...
[09:41] <Saviq> Mirv, so we'll have to investigate whether it works for us as it is upstream and potentially drop that patch
[09:43] <Saviq> mhr3, any reason why you're interrogating pkg-config runtime instead of build-time? and why doesn't scope-tool depend on the -dev where that .pc file comes from?
[09:44] <mhr3> Saviq, cause unless you run it against non-installed scope it doesn't need it
[09:44] <Saviq> mhr3, mhm
[09:44] <mhr3> Saviq, and you won't run with non-installed scope unless you have -dev
[09:44] <Saviq> mhr3, unless someone sent you the .so and .ini files (click)
[09:44] <Saviq> mhr3, in which case we'd crash won't we
[09:45] <mhr3> Saviq, in which case you'll just install the click :P
[09:45] <Saviq> mhr3, touché, but still scary :P
[09:46] <Saviq> Mirv, but other than that it seems to work fine
[09:47] <Saviq> Mirv, so the only unknown issue would be the test failure+segfault in unity-api
[09:47] <Saviq> /food
[10:04] <karni> Is there a way to point unity-scope-tool at locally deployed server scopes?
[10:04] <karni> on trusty (I know, old school)
[10:07] <Cimi> mhr3, I need your script for the disk space! :)
[10:08] <davidcalle> karni, ./usr/lib/x86_64-linux-gnu/smartscopesproxy/smartscopesproxy http://localhost:8000
[10:08] <davidcalle> well, you need to stop smart-scopes-proxy first :)
[10:08] <karni> davidcalle: lovely, thanks!
[10:09] <davidcalle> karni, np
[10:12] <tsdgeos_> Saviq: i see in unity-api some Interfaces also define rolenames and some other seems not, shall i add htem?
[10:12] <tsdgeos_> i think it makes sense, but then it's not "Interface" anymore
[10:13] <mhr3> Cimi, also, it's ogra's, not mine ;)
[10:16] <tsdgeos_> mhr3: your opinion on ↑↑↑ ?
[10:17] <tsdgeos_> and by define rolenames i mean
[10:17] <tsdgeos_> doing
[10:17] <tsdgeos_>     m_roles[MockScopes::RoleScope] = "scope";
[10:17] <tsdgeos_>     m_roles[MockScopes::RoleId] = "id";
[10:17] <tsdgeos_>     m_roles[MockScopes::RoleVisible] = "visible";
[10:17] <tsdgeos_>     m_roles[MockScopes::RoleTitle] = "title";
[10:17] <tsdgeos_> not defineing the Enums
[10:17] <tsdgeos_> should probably be part of the Interface
[10:17] <tsdgeos_> since without that it's "worthless"
[10:19] <mhr3> tsdgeos_, not sure i follow, so you mean the strings themselves should be defined in the interface?
[10:20] <tsdgeos_> mhr3: see http://bazaar.launchpad.net/~unity-team/unity-api/trunk/view/head:/include/unity/shell/launcher/LauncherModelInterface.h
[10:20] <tsdgeos_> mhr3: it has a constrcutor and implements  roleNames()
[10:21] <tsdgeos_> mhr3: that makes sure all the implementations expect the same names, so is good, but then it's not a pure interface anymore, so it's not that good
[10:22] <tsdgeos_> mhr3: i think i'd prefer having them though, what's your opinion?
[10:22] <mhr3> tsdgeos_, right, ultimately you don't even need the constructor, so it could be slightly cleaner
[10:23] <mhr3> tsdgeos_, but then the ids could clash in various implementations, could be an issue
[10:23] <mhr3> but maybe not
[10:23] <tsdgeos_> got lost :D
[10:23] <mhr3> i mean the interger ids
[10:24] <tsdgeos_> those are defined as part of the interface
[10:24] <tsdgeos_> that is fine
[10:24] <mhr3> Scope::Roles starts with 0, but maybe an actual implementation would use 0 for its own thing
[10:24] <tsdgeos_> hmmm, don't see it happening tbh
[10:25] <tsdgeos_> i'm more worried about the "strings" being the same in all the implementations
[10:25] <tsdgeos_> and users knowing which strings they can expect
[10:25] <tsdgeos_> since right now it's "guessing"
[10:25] <tsdgeos_> which string in qml gives me RoleScope ?
[10:25] <tsdgeos_> from looking at the interface i can't know
[10:25] <tsdgeos_> but if i add the rolenames mapping
[10:25] <tsdgeos_> i do
[10:27] <mhr3> tsdgeos_, ok, if the int id is not an issue, i don't see a problem with it... and as i said you don't need to keep it as private member, so can be simpler/cleaner
[10:28] <tsdgeos_> mhr3: how should i do it then if not using a private member?
[10:28] <tsdgeos_> want me to use a function static map?
[10:28] <tsdgeos_> s/map/hash
[10:29] <mhr3> tsdgeos_, just return a new map in roleNames()
[10:29] <mhr3> qml caches it anyway afaik
[10:29] <tsdgeos_> ok, hope that's not too slow :D
[10:30] <mhr3> tsdgeos_, Saviq told me as some point that that is actually the desired way
[10:31] <tsdgeos_> ok
[10:43] <mhr3> Mirv, where there some changes to qt in past 2 days?
[10:44] <mhr3> Mirv, we've seen some weird armhf failures and suddenly they're gone again
[10:45] <Saviq> tsdgeos_, in general it's only read once, there's no point in keeping a copy around when QML has to keep it anyway
[10:45] <tsdgeos_> ok
[10:46] <Saviq> tsdgeos_, and yeah, add rolenames, it still is an interface, only not in the programming-language sense (i.e. not a pure-virtual class)
[10:46] <tsdgeos_> added
[10:46] <tsdgeos_> doing the tests
[10:50] <karni> Saviq: any chance for icon actually surfacing in category header? have there been designs delivered? I'm asking, as I would love to be able to show an icon in the category header.
[10:51] <karni> or, the scope header, for that matter :)
[10:51] <Mirv> mhr3: past two.. no, I don't think so, aside from ricardo's x86 emulator related builds
[10:51] <Saviq> karni, https://docs.google.com/a/canonical.com/document/d/1jeGVALlFH7KFEuu7DNPW1KhEhBFh1GhcT4ZsSxIRRqY/edit
[10:51] <karni> Saviq: thanks, reading
[10:51] <Saviq> karni, there's also a weekly engineering/design meeting (in 9 mins actually)
[10:52] <Saviq> karni, most of scope customization is missing from the spec
[10:52] <karni> aha
[10:52] <mhr3> Mirv, ok, something else then, ty
[10:54] <Mirv> mhr3: I don't always get to know myself if someone uploads a Qt module, so that's why I simply checked https://lists.canonical.com/archives/utopic-changes/2014-May/thread.html
[10:55] <mhr3> ah, useful :)
[11:00] <Saviq> tsdgeos_, fyi, I invited you (optional) to a weekly design sync on dash
[11:00] <tsdgeos_> ok
[11:00] <Saviq> tsdgeos_, it starts now if you'd want to join, but it's not necessary if you'd rather work
[11:01] <tsdgeos_> Saviq: yeah i'd just rather do all these billions mocks & Verifier {} for unity-api
[11:01] <Saviq> tsdgeos_, yeah... we need to look into what UITK does for this (like diff the plugindump or something...)
[11:02] <tsdgeos_> or that
[11:02] <tsdgeos_> but still let's finish this :D
[11:02] <Saviq> tsdgeos_, yeah, not now
[11:02] <Saviq> tsdgeos_, /nick tsdgeos?
[11:22] <Cimi> Saviq, where is QLightDM::UsersModel defined from the shell LightDM plugin?
[11:22] <Saviq> Cimi, otp
[11:22] <Cimi> ok
[11:31] <karni> mhr3: thoughts? http://paste.ubuntu.com/7457016/ - this may be python specific, but I don't see how without line 7 the scope would know how to layout widgets in 3 columns, even if 5 and 7 are syntactically equivalent
[11:38] <Wellark> dednick: this is ready for testing: https://code.launchpad.net/~kaijanmaki/unity8/indicator-root-state-icons-fix/+merge/213727
[11:38] <Wellark> see the silo in the description.
[11:40] <Wellark> Saviq: I've removed the spurious tags. please check and mark as approved from your side --^
[11:49] <Wellark> what is this unity-phablet-qmluitests-trusty jenkins job and why is it always failing in ci ?
[11:50] <Cimi> Saviq, still otp?
[11:50] <mhr3> karni, hm... looks good to me
[11:50] <mhr3> davidcalle, ideas ^?
[11:50] <karni> https://bugs.launchpad.net/unity-scopes-api/+bug/1319019
[11:50] <karni> sorry for bug title ;P
[11:51] <Saviq> Cimi, back now
[11:52] <mhr3> marcustomlinson, do you remember how those are parsed ^?
[11:52] <Saviq> dednick, can you follow up on https://code.launchpad.net/~kaijanmaki/unity8/indicator-root-state-icons-fix/+merge/213727 please?
[11:52] <Cimi> Saviq, I think I have the right stuff installed
[11:53] <marcustomlinson> mhr3: looking
[11:53] <Cimi> Saviq, http://paste.ubuntu.com/7457085/
[11:53] <Saviq> Cimi, plugins/LightDM/UsersModel.{cpp,h}
[11:53] <davidcalle> karni, no idea, the onlinemusic scope from u-r-s works fine with two cols too, haven't tried three.
[11:53] <Cimi> Saviq, I have UidRole
[11:53] <Saviq> Cimi, but there's also a bunch of mocks
[11:53] <Cimi> Saviq, but if in code I do
[11:54] <Cimi> Saviq, QVariant data2 = QSortFilterProxyModel::data(index, QLightDM::UsersModel::UidRole);
[11:54] <karni> davidcalle: two cols are no problem
[11:54] <Saviq> Cimi, in plugins/mocks/LightDM/{full,single,demo...}
[11:54] <Cimi> Saviq, make does error: ‘UidRole’ is not a member of ‘QLightDM::UsersModel’
[11:55] <Saviq> Cimi, it's probably loading one of the mocks and not the one you've changed
[11:55] <mhr3> dpm, do you see any of these translatable? http://bazaar.launchpad.net/~ubuntuone-hackers/ubuntu-rest-scopes/trunk/view/head:/configs/scopes-info.yaml ?
[11:55] <Saviq> Cimi, but anyway
[11:55] <Saviq> Cimi, you just added it to the enum, did you also add it to roleNames()? and handled it in data()?
[11:55] <Cimi> Saviq, I had everything
[11:56] <Cimi> Saviq, https://code.launchpad.net/~cimi/lightdm/uid-bindings/+merge/218958
[11:56] <Saviq> Cimi, just put a breakpoint in data() of the model, and see if that's actually what's called
[11:56] <Saviq> Cimi, we're not actually using lightdm
[11:56] <dpm> mhr3, it seems that the descriptions are translatable, but none of the names are: https://translations.launchpad.net/ubuntu-rest-scopes/trunk
[11:56] <Saviq> Cimi, we mock the same API
[11:56] <Saviq> Cimi, until we're in split greeter
[11:56] <Cimi> Saviq, I see
[11:56] <Cimi> Saviq, path to our mocks?
[11:57] <mhr3> dpm, then that's the other part of the problem
[11:57] <Saviq> Cimi, I wrote like 5 above
[11:57] <Cimi> I don't have those
[11:57] <Saviq> Cimi, in lp:unity8
[11:57] <Cimi> in tests?
[11:57] <Saviq> Cimi, there's plugins/LightDM/UsersModel.{cpp,h}
[11:57] <dpm> mhr3, ok thanks for investigating that, will file a bug
[11:57] <Cimi> Saviq, I have those
[11:57] <Saviq> Cimi, then there's the test mocks in tests/mocks/LightDM/*/UsersModel.{cpp,h}
[11:58] <Cimi> ah tests
[11:58] <Saviq> actually UsersModelPrivate
[11:58] <Saviq> 7 in total
[11:58] <Saviq> you need to update all those
[11:59] <Cimi> I am trying now
[11:59] <Cimi> compiling...
[12:00] <mhr3> dpm, pls reply to the thread with the bug# then
[12:00] <Saviq> mhr3, how do I try out the tool update?
[12:01] <dpm> mhr3, done, thanks
[12:02] <mhr3> Saviq, branch for example lp:unity-scope-scopes, build it, and do `...-tool ./builddir/path-to.ini`
[12:05] <Cimi> Saviq, ok works
[12:05] <Saviq> mhr3, it fails trying to aggregate, worked with the click scope
[12:05] <Cimi> Saviq, thank you, didn't realise was using mocks and not qlightdm directly
[12:05] <Saviq> mhr3, but for future reference, what do I do to enable aggregation?
[12:06] <Saviq> Cimi, nw, we can't use the real impl until split greeter
[12:06] <mhr3> Saviq, yea, there's an issue in -api where it can't combine regular server proxy with custom registry (which the tool is using)
[12:07] <mhr3> Saviq, i'll catch that up
[12:09] <Cimi> Saviq, so I need to fake the uid then
[12:09] <Saviq> Cimi, yup
[12:09] <Cimi> ok
[12:09] <Cimi> Saviq, in demo full
[12:09] <Cimi> Saviq, can I fake them all to the same uid?
[12:10] <Saviq> Cimi, do they have the same name?
[12:10] <Cimi> Saviq, well infographics only work on 32011
[12:10] <Cimi> uid
[12:10] <Cimi> of phablet
[12:10] <Cimi> the user who is running the service
[12:12] <Saviq> Cimi, except you shouldn't be using the real infographics but mock it
[12:12] <Saviq> Cimi, as it was mocked before (but now it's rather simpler to mock)
[12:16] <Cimi> Saviq, we were using real infographics
[12:16] <Cimi> Saviq, when I took pics I saw new pic on my screen
[12:28]  * Cimi lunch break
[12:34] <dednick> Saviq: i thought it had been approved...
[12:35] <dednick> maybe CI unapproved.
[12:35] <Saviq> dednick, I think it was, but your vote is still Needs Fixing ;)
[12:35] <Saviq> dednick, Wellark unapproved it
[12:36] <dednick> Saviq: ah. ok, well i've approved. can top approve Wellark ?
[12:47] <marcustomlinson> karni: hey, I left a comment on that bug. make sense?
[12:48] <karni> marcustomlinson: oh, totally! thank you. feel free to mark this invalid.
[12:49] <marcustomlinson> karni: cool, np :)
[12:57] <Wellark> dednick_: we still need a ci train TestPlan checklist
[12:57] <Wellark> sorry, Reviewer Checklist
[12:57] <Wellark> so we can land
[12:58] <Wellark> (not going to land this minute, still fighting the indicator side)
[12:58] <Wellark> but the unity8 branch can be tested already
[12:58] <Wellark> no changes to the icon handling will happen anymore.
[12:59] <pete-woods> Saviq: quick question, if I want to get the "latest" unity builds, do I need to upgrade to utopic, or is there a nice PPA or something for trusty?
[12:59] <Saviq> pete-woods, utopic
[13:00] <pete-woods> Saviq: okay, thanks :)
[13:07] <dednick_> Wellark: ok. well, I've done the checklist
[13:09] <Wellark> dednick_: thanks!
[13:10] <Wellark> dednick_: now it's ready to land as soon as the other MP's in the silo are OK.
[13:38] <Saviq> greyback, I say we're in violent agreement on shell rotation, but you were high when you've written the last email ;)
[13:39] <Saviq> greyback, my only worry is simply that things won't reflow fast enough, that's why I was looking at ways to fake it a bit, but we might just as well take that on later...
[13:47] <greyback> Saviq: that's what I get for stopping the pills
[13:47] <Saviq> greyback, :)
[13:58] <darklight_> Saviq, any news on Uhttps://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1305438 ? I also wrote to the ML as you suggested but nobody cared (or cared enough to answer at leasta)
[13:59] <Saviq> darklight_, sorry, I'm not working on compiz at all, you'll have to be more patient
[13:59] <darklight_> Saviq, but it's not a compiz issue it's a unity issue
[13:59] <Saviq> darklight_, I'm not working on unity (7) either ;)
[14:00] <darklight_> ok , do you know anyone I could bother ? :)
[14:00] <Saviq> darklight_, the folks maintaining unity7 are mostly late US
[14:00] <darklight_> pacific time ?
[14:00] <Saviq> darklight_, filing a bug is best, they'll get to it in due time
[14:01] <darklight_> Saviq, that is the bug it has already been filed
[14:01] <Saviq> darklight_, yes, subscribe to it and arm yourself in some patience I'm afraid is the only thing I can recommend
[14:03] <darklight_> Saviq, well the thing is it has been broken for ~2-3 releases so I have a feeling they just don't care enough to fix it
[14:03] <Saviq> darklight_, can't comment on that
[14:10] <tsdgeos> Saviq: https://code.launchpad.net/~unity-team/unity-api/unity-shell-scopes-api/+merge/219379 is ready for mhr3's docu i'd say
[14:10] <tsdgeos> Saviq: can you give it another review before he adds the docu?
[14:11] <Saviq> tsdgeos, yup, saw that, will do
[14:11] <tsdgeos> it's one of those reviews where it looks big because the test code is huge
[14:11] <tsdgeos> compared to the code itself
[14:11] <Saviq> tsdgeos, yup
[14:19] <Saviq> mhr3, https://code.launchpad.net/~unity-team/unity-api/unity-shell-scopes-api/+merge/219379 is ready for your doc-love :)
[14:19] <cimi_> cannot connect to my ZNC, use Cimi_ for queries instead :)
[14:20] <cimi_> still receiving pings though
[14:21] <mhr3> Saviq, ouch, felt like slap in the face right after joining :P
[14:21] <Saviq> mhr3, should not have left! ;)
[14:22] <mhr3> heh
[14:40] <tsdgeos> mterry: i fixed the Dash test, can you quick review?
[14:40] <cimi_> paulliu, MacSlow my connection degradated at the last minutes, can you ping me your minutes and I add them
[14:40] <mterry> tsdgeos, yes!  let me look
[14:40] <mterry> thanks
[14:40] <paulliu> cimi_: ok. I'll fill it on googledoc.s
[14:40] <tsdgeos> mterry: thankyou for noticing :
[14:40] <tsdgeos> )
[14:40] <MacSlow> cimi_, I'll update the notes myself... no worries
[14:43] <MacSlow> cimi_, done
[14:44] <cimi_> MacSlow, thanks
[14:45] <cimi_> Saviq, I don't understand if I have to fake the infographics on the shell or just for the tests
[14:45] <Saviq> cimi_, just for the tests
[14:45] <cimi_> Saviq, cool
[14:46] <cimi_> Saviq, it will be like a list of svg then, easy
[14:46] <Saviq> cimi_ yup
[14:46] <cimi_> ok
[14:50] <tsdgeos> dandrader|afk: what's missing for top approval of https://code.launchpad.net/~paulliu/unity8/logout/+merge/216373 ?
[14:51] <paulliu> cimi_: done.
[14:51] <cimi_> paulliu, thanks
[14:52] <tsdgeos> mterry: should the tests  of https://code.launchpad.net/~mterry/unity8/split/+merge/213149 work?
[14:53] <mterry>  tsdgeos, tests?  like autopilot and qmluitests?  Yes, except for the existing broken qmluitests
[14:53] <tsdgeos> mterry: ok, i remember some breakage on the autopilot unlock, is that gone?
[14:54] <mterry> tsdgeos, should be
[14:54] <tsdgeos> good, let's see :=)
[14:54] <cyphermox> cimi_: re your issues with connectivity; try the dnsmasq package from this PPA and let me know if it helps: https://launchpad.net/~mathieu-tl/+archive/build-tests/+packages
[14:54] <cyphermox> oh wait, it was for the phone, this ppa doesn't build armhf
[14:54] <cimi_> cyphermox, indeed
[14:54] <cimi_> but thx
[14:55] <cyphermox> I'll copy it to another
[14:55] <mzanetti> Saviq: ping
[14:55] <Saviq> mzanetti, pong
[14:55] <mzanetti> Saviq: I've entered details in the choo-choo spreadsheet
[14:55] <mzanetti> Saviq: however, it changed a bit since I last used it. what's the requestId?
[14:56] <mzanetti> Saviq: row 32
[14:56] <Saviq> mzanetti, you don't look past I
[14:56] <mzanetti> ack
[14:56] <Saviq> mzanetti, it's an issue with the spreadsheet - they should be hidden
[14:56] <mzanetti> so everything should be fine then
[14:57] <mzanetti> Saviq: do I need to do anything to get a silo to test this?
[14:57] <Saviq> mzanetti, yup, but you need to wait for silo 008 to land
[14:57] <mzanetti> Saviq: right. not in a hurry with this
[14:57] <mzanetti> Saviq: once I got the silo, I'll test and move it on from there asap.
[14:58] <Saviq> mzanetti, and then I'll find out whether silo 009 wants to land or whether we should still ignore it for now
[14:58] <mzanetti> Saviq: I'm bugging designers on a daily basis to tell me how to proceed with the ui
[14:58] <Saviq> mzanetti, right edge you mean?
[14:59] <mzanetti> Saviq: no.. dual sim pin entry
[14:59] <Saviq> mzanetti, ah that, yeah
[14:59] <mzanetti> Saviq: I've got functionality mostly implemented, just no idea where to put the labels
[14:59] <mzanetti> Saviq: re right edge, vesa is back :)
[15:12] <dandrader> tsdgeos, I checked the code but I didn't test it or even compiled it
[15:13] <dandrader> s/checked/reviewer
[15:13] <dandrader> reviewed
[15:14] <MacSlow> mzanetti, will the dual sim-pin entry affect the fullscreen notification using the pinpad item?
[15:16] <tsdgeos> dandrader: can you say so on the review, it was unclear to me (or maybe you did and i read too fast :D)
[15:16] <dandrader> tsdgeos, I said in my comment (there's a checklist there)
[15:16] <tsdgeos> dandrader: ok, my bad then, sorry
[15:20] <Saviq> greyback, https://code.launchpad.net/~gerboland/unity-mir/fix-upstart-closed-apps2/+merge/218721/comments/523324
[15:20] <cimi_> tsdgeos, this was branch you wanted review? https://code.launchpad.net/~aacid/unity8/fix_tstDash/+merge/219296
[15:21] <Saviq> ETOOMANYCIMIs
[15:21] <tsdgeos> cimi_: mterry was having a look at that one
[15:21] <cimi_> ok
[15:21] <tsdgeos> cimi_: https://code.launchpad.net/~aacid/unity8/remove_empty_dirs/+merge/219168 ?
[15:21] <tsdgeos> it should take you around 5 seconds to do that one
[15:21] <cimi_> Saviq, I am away from home and cannot access my home server :) I think the port mapping is fucked up
[15:22] <cimi_> pls use cimi_ for the rest of the week
[15:22] <mzanetti> MacSlow: yes, it will. I'll let you know if I need something from you
[15:22] <MacSlow> mzanetti, ok
[15:22] <cimi_> unless I hack on my own home network :)
[15:22] <cimi_> no idea how though
[15:23] <greyback> Saviq: you recall, had the webapp actually died after the first pkill?
[15:23] <Saviq> greyback, yes it did
[15:23] <Saviq> greyback, it's 100% reproducible - like when it resumes, it doesn't get "canberesumed = true"
[15:24] <greyback> Saviq: ok
[15:29] <tsdgeos> Saviq: upstart crashed again :S
[15:29] <tsdgeos> Saviq: should that bug you mentioned be already fixed?
[15:30] <mhr3> alecu_, what app uris is click using?
[15:30] <mhr3> alecu_, do they include version as app id or not?
[15:31] <dandrader> tsdgeos, Saviq: the fault of my missing dash was in a silent javascript NaN situtation... deja vu
[15:31] <Saviq> tsdgeos, just did for me on the phone, too...
[15:31] <Saviq> tsdgeos, filed https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1319083
[15:32] <tsdgeos> Saviq: wrong bugno?
[15:32] <Saviq> tsdgeos, try again, is private still
[15:32] <tsdgeos> ah
[15:32] <tsdgeos> ok
[15:33] <alecu_> mhr3: ? what uri are those? the uris for the actual .click package files, or the uris for package details from the webservice?
[15:34] <Saviq> greyback, it obviously misses "go to webapp" after 3
[15:34] <Saviq> greyback, to resume it (the steps I mean)
[15:35] <greyback> Saviq: ahh, not so obvious :)
[15:35] <Saviq> greyback, sorry, just read through the steps ;)
[15:36] <mhr3> alecu_, the ones that launch actual applications
[15:36] <greyback> Saviq: so you resumed the web app, then switched right back to the dash? Did you wait for hte webapp to appear?
[15:36] <Saviq> greyback, it did
[15:36] <Saviq> greyback, even waited for it to suspend
[15:36] <greyback> Saviq: ok, that helps, will dig
[15:37] <Saviq> greyback, and now it just goes away every time :/
[15:37] <Saviq> after upstart crashed and restarted my session... /me reboot
[15:37] <Saviq> s
[15:37]  * greyback hates webaps
[15:39] <greyback> upstart kinda brittle these days
[15:46] <cimi_> Saviq, I think we need to add liblightdm-qt5-3-dev to build deps, no?
[15:47] <cimi_> and the non dev to depends
[15:48] <alecu_> mhr3: I see that the application:/// url includes the version
[15:48] <tsdgeos> mterry: so from your pov the split branch is "done"? or there's stuff to do?
[15:49] <mhr3> alecu_, mzanetti is asking to ideally drop it
[15:49] <alecu_> mhr3: it's actually: manifest.name + "_" + manifest.first_app_name + "_" + manifest.version + ".desktop";
[15:49] <alecu_> mhr3: we would need to change the click desktop hooks too
[15:49] <mterry> tsdgeos, two things: indicator team needs to fix syncing between sessions with indicator-messages.  And I'm investigating a new breakage with init scripts due to some ubuntu-touch-session changes.  But those are not the unity8 branch.  That I think is done (hopefully!  ;))
[15:50] <Saviq> cimi_, why? we're still not actually building against it or linking to it
[15:50] <alecu_> mzanetti: ^
[15:50] <tsdgeos> mterry: ok
[15:50] <cimi_> Saviq, well fresh system
[15:50] <mzanetti> alecu_: yes, we're stripping them to the short app id (dropping _version)
[15:50] <cimi_> Saviq, apt-get build-dep unity8
[15:50] <cimi_> Saviq, ./build.sh
[15:50] <cimi_> Linking CXX shared module libMockLightDM-qml.so
[15:50] <cimi_> /usr/bin/ld: cannot find -llightdm-qt5-2
[15:51] <mzanetti> alecu_: or rather, asking you to do so, so that we only have short appids in the shell
[15:51] <cimi_> first of all we have qt5-3 now iirc
[15:51] <alecu_> mzanetti: I'll ping the people doing the click hooks, and I can do the work on the click scope
[15:51] <mzanetti> alecu_: awesome, thanks!
[15:52] <Saviq> cimi_, especially since that's a _mock_ you should not even think of solving that with the real library
[15:52] <alecu_> mzanetti: would you mind opening a bug for that?
[15:52] <Saviq> cimi_, which you can't access still until you're running split greeter
[15:52] <mzanetti> alecu_: ack
[15:52] <cimi_> Saviq, anyway found the cmakefile that needs update
[15:52] <alecu_> mzanetti: https://bugs.launchpad.net/ubuntu/+source/unity-scope-click/+filebug
[15:52] <cimi_> Saviq, there is qt5-3 now
[15:53] <mzanetti> alecu_: this is the one that triggered all this: https://bugs.launchpad.net/unity8/+bug/1239750
[15:53] <mzanetti> alecu_: I might just add unity-scope-click as affects too
[15:53] <Saviq> cimi_, you should adapt all the mocks to do -3 now  then
[15:53] <mzanetti> alecu_: the title is a bit misleading by now tho :/
[15:54] <Saviq> cimi_, and there's a debian/rules comment that should get updated
[15:55] <cimi_> Saviq, all done
[15:56] <cimi_> Saviq, sed ftw
[15:56] <alecu_> mzanetti: I think the title of that is perfect, and yes, I see how launcher items would get broken by this
[15:57] <mzanetti> alecu_: ok, I can't add unity-scope-click to it for some reason. It says it doesn't use LP to track bugs
[15:58] <alecu_> mzanetti: right: we are tracking bugs in ubuntu's source package. Let me do it.
[15:58] <mzanetti> ok, thanks
[16:05] <Saviq> o/ folks
[16:05] <cimi_> Saviq, https://code.launchpad.net/~cimi/unity8/lightdm-bump/+merge/219397
[16:06] <Saviq> mterry, can you look at ↑ please
[16:06] <mterry> Saviq, cimi: shouldn't be needed -- we build our own qt5-2 version
[16:07] <mterry> Saviq, cimi: liblightdm bumped to 3 months ago, hasn't been a problem yet
[16:07] <cimi_> mterry, but doesn't work on my system
[16:07] <mterry> cimi, sounds like something isn't being pointed at our mock qt5-2 version
[16:07] <cimi_> was complaining about missing that
[16:07] <cimi_> mterry,  /usr/bin/ld: cannot find -llightdm-qt5-2
[16:08] <mterry> cimi, right, I get that.  But sounds like maybe mock qt5-2 isn't built yet or isn't being pointed at right
[16:08] <mterry> cimi, if you need to make the changes you did, that means something is pointing at system liblightdm which shouldn't be the case.  you should always be pointing at our mock version
[16:09] <cimi_> ok
[16:14] <cimi_> mterry, don't know then, works for you?
[16:15] <mterry> cimi_, yeah.  How are you building?  Did you make any related changes?
[16:15] <cimi_> mterry, trying trunk
[16:15] <cimi_> mterry, new machine
[16:15] <mterry> cimi_, and building via ./build.sh?
[16:15] <cimi_> mterry, yes
[16:15] <mterry> cimi_, ok will give a fresh checkout a try
[16:16] <cimi_> mterry, also make you you don't have that library system wise
[16:18] <cimi_> mterry, spot any mistake here? http://bazaar.launchpad.net/~unity-team/unity8/new-infographics/revision/822#plugins/LightDM/plugin.cpp
[16:19] <cimi_> mterry, the change in tests/mocks/LightDM/CMakeLists.txt I bet
[16:19] <alecu> ted: hi! are you the one maintaining the desktop-hook in https://launchpad.net/upstart-app-launch ?
[16:19] <ted> alecu, Yup
[16:19] <cimi_> Saviq, when you have time, looks like you removed the dependency there http://bazaar.launchpad.net/~unity-team/unity8/new-infographics/revision/822#plugins/LightDM/plugin.cpp
[16:19] <ted> alecu, Though I'm trying to get it to go away :-)
[16:20] <ted> (by default, not entirely)
[16:20] <cimi_> http://bazaar.launchpad.net/~unity-team/unity8/new-infographics/revision/822#tests/mocks/LightDM/CMakeLists.txt
[16:20] <cimi_> Saviq, is there a reason?
[16:20] <alecu> ted: ah! so, I've been asked by mzanetti to fix the click scope for this: https://bugs.launchpad.net/ubuntu/+source/unity-scope-click/+bug/1239750
[16:20] <mterry> cimi_, trunk just built for me
[16:21] <alecu> ted: I was thinking of either 1) changing the click scope and the desktop-hook to rename .desktop files to the short app name
[16:21] <alecu> ted: or 2) making the click scope use short uris (appid://short instead of application:///long.desktop)
[16:22] <ted> alecu, I think that you should use appid://pkg/app/current-user-version, but also you should install your own desktop hook to manage your cache.
[16:23] <alecu> ted: I don't currently have a cache
[16:23] <ted> alecu, That way you can do thinks like break apart the names into your search format on install instead of startup.
[16:23] <alecu> ted: hmmm.... right.
[16:24] <alecu> ted: is "current-user-version" just that const string?
[16:24] <ted> alecu, Yes
[16:24] <alecu> great
[16:24] <ted> alecu, There's a UAL function to break apart an appid into its pieces, please use that :-)
[16:25] <ted> Long term, I think those desktop files should be the short ids because it'll be easier for legacy desktops. But since we don't have any yet, I haven't prioritized changing it much.
[16:26] <alecu> ted: are hooks re-run on system updates? I'm trying to understand what would happen for people that already have apps installed in their phones.
[16:26] <ted> alecu, They're run when the user logs in after the system update. For encrypted homes.
[16:27] <alecu> great
[16:27] <ted> alecu, At the start of each session there's a check to see if any hooks need to be run.
[16:28] <cimi_> #ubuntu-unity
[16:28] <cimi_> hah
[16:28] <cimi_> mterry, sorry I am back
[16:29] <karni> phablet-screenshot no worky? remote object '/tmp/mir_screencast_768x1280.rgba' does not exist
[16:34] <mterry> cimi_, I was just saying that trunk built for me
[16:34] <cimi_> mterry, yes
[16:34] <mterry> cimi_, are you using ninja?
[16:34] <cimi_> mterry, it looks like saviq in the attempt of removing usermetrics mock might had removed something important
[16:34] <cimi_> mterry, http://bazaar.launchpad.net/~unity-team/unity8/new-infographics/revision/822
[16:34] <mterry> cimi_, , but trunk still works (for me)
[16:34] <cimi_> mterry, indeed
[16:35] <cimi_> mterry, is that branch that doesn't
[16:35] <mterry> cimi_, oh!  trunk works for you?
[16:35] <cimi_> yes
[16:35] <cimi_> tried now
[16:36] <cimi_> will try later on
[16:56] <dednick_> mterry: ping
[16:56] <mterry> dednick_, heyo
[16:57] <dednick_> mterry: hey. so that other problem with the laggy slider; it's a blocking call in unity8 originating from the accountsservice plugin.
[16:58] <dednick_> mterry: the unity8 plugin is getting property updates for the volume change, and the the get/set dbus operations for other properties synchronous
[16:59] <mterry> dednick_, ooh, good tracking down.  That sounds like my fault again  :-/
[16:59] <dednick_> mterry: yeah :) I had a go at it this morning, but wasn't really sure about the best way to get it sorted. Possibly needs to go on a thread, or use async calls.
[17:00] <mterry> dednick_, if I recall correctly, that code is trying to be a qml plugin, and those property bindings don't do well with async code -- I assume that's why I wrote it like that
[17:01] <dednick_> mterry: there's a separate dbus & qml part to it.
[17:01] <mterry> dednick_, yeah but the qml part uses the dbus part
[17:01] <dednick_> mterry: yup
[17:01] <mterry> dednick_, I dunno, I'm just guessing why it may have been left as sync
[17:05] <dednick_> mterry: you want to take a look at it? or should i look more into it?
[17:05] <mterry> dednick_, it's my fault, I can look
[17:10] <dednick_> mterry: aiight.
[17:45] <ted> greyback, What does unity-mir use the desktop file for?
[17:46] <greyback> ted: read the application name, comment, icon, stage hint
[17:46] <greyback> as it supplies the shell with a model of running applications plus their metadata
[17:46] <ted> greyback, Perhaps I'm a bit confused on the arch, but I'm surprised that unity-mir handles the user visible strings.
[17:49] <greyback> ted: Unity-mir just handing shell a list of PIDs isn't very friendly to it, especially as unity-mir needs to open the desktop file to get startup data like destination-stage and splash-image
[17:49] <greyback> ted: what's your concern?
[17:50] <ted> greyback, More surprise, I was reading through the shortid branch.
[17:50] <ted> greyback, I'm a little worried that running apps aren't tracked by full appid.
[17:50] <ted> greyback, For instance, if you stop an app, you should be passing the full app id. Not the version that was just installed.
[17:51] <greyback> ted: why? Are not these short appIds unique per user session?
[17:52] <ted> greyback, No, you could upgrade a click while the session is running.
[17:52] <greyback> ted: right, so the appId the launcher saved is now incorrect, as the version string changed
[17:53] <greyback> which is the core bug we're trying to work around
[17:53] <ted> greyback, Correct, or you couldn't stop it.
[17:54] <ted> greyback, So I think it's fine to start an app with the short id, but then you need to refer to that instance with the long from there on out.
[17:54] <greyback> ted: Way the code works: shell asks unity mir stop app with short-appId. unity-mir asks upstart, what is the long appId for this short-appId, please close that
[17:54] <greyback> ted: all conversation with upstart is using long-appId
[17:55] <ted> greyback, Yes, so in that case we ask click for what is the current version for this user.
[17:55] <greyback> ted ah I see what you mean
[17:57] <greyback> ted: so you know the reason we've been trying short appId. Launcher saves the appId of pinned apps. If app updated, the appId stale
[17:57] <ted> greyback, Yes, and I think it makes sense for the launcher to save the short id. I think you just need to translate, when running, once.
[17:59] <greyback> ted:but how does launcher know that the appId changed, and so the desktop file it reads for its icon & name, has moved somewhere new, so it should load the new one?
[18:00] <ted> greyback, You should install a desktop hook for that. Then when it gets changed you'll get a signal.
[18:00]  * larsu wonders why the app id would ever change...
[18:00] <ted> larsu, appid has the version number in it
[18:01] <larsu> oh, that doesn't seem like a good idea to me
[18:01] <larsu> but then, I only barged into this dicussion and know nothing of the subject
[18:01] <larsu> so I'll trust you guys to do the right thing and continue with my evening :)
[18:01] <ted> Heh, it's good for some things bad for others.
[18:02] <ted> Keeping user preferences it's bad for. Managing security profiles it's good for.
[18:03] <greyback> ted: I need mzanetti here to discuss this, I don't know the launchers difficulty with long appIds
[18:04] <greyback> ted: but I will ask, what would be so wrong with having UAL support short appIds? UAL knows the installed & running apps, it can always figure out the right thing
[18:04] <ted> greyback, Kinda yes, kinda no. It doesn't really know anything, it queries Upstart for information. And it's not very good at searching, it would be kinda expensive.
[18:06] <ted> greyback, I'd imagine (and I haven't looked in detail) that at some point you're giving an object back to the launcher, no? Wouldn't it only need the id to create that object?
[18:06] <greyback> ted: and I don't understand why the desktop file can't have a name without the version string, and placed in the user's local app directory. System apps similar, in /u/s/apps.
[18:08] <greyback> ted: unity-mir not passing a fully read desktop file object to launcher, no. Launcher reads the desktop files it needs on it's own. Yeah, there's a bit of duplication re desktop files
[18:08] <ted> greyback, I think it could. And really probably should. But I really only consider those desktop files for compatibility, not a long term solution. We need to move to caching the info on install of the app instead of reading the files at startup.
[18:09] <greyback> ted: desktop files in freedesktop spec, what's wrong with them? They do the job nice & simply. If we want to build a cache of them, fine, but keep the plain text file around
[18:09] <ted> greyback, Ah, okay. I wasn't thinking read desktop file as much as a UnityMirApplicationObject or some such.
[18:10] <ted> greyback, Sure, keep it in the package. But no need to generate another one.
[18:10] <cyphermox> Cimi: the issue you had was with connecting to websites from the phone right? not necessarily with indicator icons and whatnot?
[18:11] <greyback> ted: unity-mir does create an Application object, that the shell can use to read app specific info from (desktop file data part of that model alright). So in that way, you're right. But for apps that Unity-mir hasn't lauched, the Launcher itself has to read the desktop files
[18:11] <ted> greyback, So as long as that object contains the long app id, could you call stop with the data in it?
[18:12] <greyback> ted: keeping it in package doesn't follow freedesktop spec, and package update deletes it and re-creates it in a different directory.. That's problematic. Other shell will simply not use that
[18:12] <greyback> ted:  that could be done
[18:12] <greyback> ted: but frankly, this is a mess
[18:12] <greyback> ted: short & long appIds??!
[18:13] <greyback> I don't like this solution at all
[18:13] <ted> greyback, short to create, long stored and used.
[18:14] <greyback> ted: I fail to see any reason that a shell cares about the version string in the app Id. As far as I'm concerned, it's an implementation detail of click packaging, that its utilities should mask from the shell
[18:14] <greyback> ted: that's what I'm trying to do in unity-mir, hide version string entirely. I honestly don't think I should be doing that either
[18:14] <ted> greyback, The shell cares because it's a critical part of our application lifecycle story, which is restrictive for really good reasons. To be restrictive you to be precise.
[18:15] <ted> have to be
[18:15] <greyback> ted: please give me an example of when shell needs to know this version string. that would satisfy me
[18:17] <ted> greyback, To use the correct information about starting an app. One version could be sidestage and the next version not. You have the info on the wrong version it behaves inconsistently.
[18:18] <greyback> ted: a user can have multiple versions of the same app installed??
[18:18] <ted> greyback, They could start one, upgrade.
[18:19] <ted> Hopefully only for a short time.
[18:19] <greyback> ted: that's not having multiple versions installed simultaneously though
[18:21] <ted> greyback, I think at some level you have to go from long id to short. Not everything needs to know long for sure. I think that unity-mir is a good place to do that.
[18:21] <greyback> ted: so sudoku_1 is running. You update. sudoku_2 is new installed, but sudoku_1 is still running. shell asks UAL to stop "sudoku" <- tell me UAL/upstart could not figure out what needs to stop
[18:22] <ted> greyback, It's more than a UAL thing. Let's say sudoku_1 doesn't have permission to send notifications but sudoku_2 does.
[18:23] <ted> greyback, And really, most of UAL is a library. So the process that'd be figuring all that out would be unity-mir anyway :-)
[18:26] <greyback> ted: I agree that there's a boundary where translation between long & short appIds has to happen. But I don't think unity-mir is the place. If you want someone else to implement a shell that uses UAL, they'll have to care about long & short appIds too, for no other reason than UAL not hiding those detail from them
[18:26] <ted> greyback, So if I changed UAL to create an application object from the short id that you could then call stop/start on, would that be better?
[18:28] <greyback> ted: upstart_app_launch_start_application() <- could it support both long & short appId?
[18:28] <greyback> preferably just short appId - but we might need a transition period
[18:29] <ted> greyback, Sure, but stop is the issue.
[18:30] <greyback> ted: for the update reason?
[18:30] <ted> greyback, Correct.
[18:30] <ted> greyback, So if we could have a _create_application that returned an object with start and stop functions that would work.
[18:31] <greyback> ted: let me work through the steps: shell asks sudoku to start, so unity-mir asks UAL to start sudoku. Internally UAL determines that sudoku is actually sudoku_1 and launches it
[18:32] <greyback> Case 1 - no update: shell asks to stop sudoku, so unity-mir asks UAL to stop sudoku. Internally UAL determines that sudoku is actually sudoku_1 and stops it. All good
[18:33] <greyback> Case 2 - an update happened, sudoku_1 -> sudoku_2. shell asks to stop sudoku, so unity-mir asks UAL to stop sudoku. Internally UAL does what to stop sudoku_1?
[18:33] <ted> greyback, If we had an object we could track the Upstart instance.
[18:35] <greyback> ted: you're proposing instead of just using strings to identify applications, when I start an app, UAL returns an object that unity-mir can operate on?
[18:35] <greyback> ted: that's a nice idea
[18:36] <greyback> would require a rather large refactoring of UAL, but it solves the problem
[18:36] <greyback> I would still very much like that UAL only refers to short appIds
[18:37] <ted> greyback, Not too much, let me look at it. Guessing you want to EOD here soonish :-)
[18:37] <greyback> ted: yeah it's late enough here
[18:38] <greyback> ted: ok, let me know how much work you think it would be. mzanetti & I will consider if our shortAppId stuff will suffice in the short term or not (if yes, I'll try fixing that bug you observed)
[18:39] <ted> greyback, Cool, I'll try to mock something up.
[18:39] <greyback> ted: great, thanking you
[18:42] <greyback> ted:  one last thing, what would be an objection to symlinking the desktop file in the click package to ~/.local/share/applications on install?
[18:43] <ted> greyback, That doesn't really work as the Path isn't right. But I think we could do that to ~/.cache/unity/click-cache/
[18:43] <ted> greyback, Then you don't need to search for them.
[18:44] <ted> greyback, Unity-mir doesn't need all the aa-clickexec stuff to be right like other desktops not using UAL would.
[18:44] <ted> greyback, Those could also have the shortid pretty easily as click already supports that.
[18:45] <greyback> ted: the lack of searching would be great. But then, what is difference between ~/.cache/unity/click-cache/ and  ~/.local/share/applications ?
[18:45] <greyback> it's just an arbitrary directory. But one is part of a freedesktop spec and would help compatibility with other shells
[18:46] <ted> greyback, The ~/.local/s/a would have the Path set to the click directory and the exec line changed, etc. Things that other folks need as well.
[18:46] <ted> greyback, But I'd like to deprecate that on Unity8 only installs so we don't have to create the files in the user's home directory.
[18:48] <greyback> ted: okay. it'll get confusing for people if they try to use utils they know like xdg-open on a unity8 desktop though and they don't work like expected...
[18:48] <ted> greyback, It won't work anyway as we'll reject them starting without using UAL.
[18:49] <greyback> ted: true. Though I don't look forward to using a desktop like that.
[18:50] <ted> greyback, I'm thinking that we should have the terminal app create a trusted session on itself, and then pass that to apps. They'll end up overlayed on the terminal app, which will work for most things.
[18:51] <Saviq> karni, yeah, I saw that, too (screenshot no worky), care to file a bug against Mir and phablet-tools?
[18:52] <greyback> ted: let's see. Once we all start using it, we'll see quickly how practical that actually is
[18:52] <Saviq> Cimi, you  mean I removed the "Infographic" type from the LightDM plugin? yeah, because UserMetrics has its own module now
[18:54] <greyback> Saviq: can I get your clarification on https://code.launchpad.net/~gerboland/unity-mir/fix-upstart-closed-apps2/+merge/218721/comments/523413 ?
[18:54] <Saviq> Cimi, http://bazaar.launchpad.net/~unity-team/libusermetrics/file-based-infographics/files/head:/src/modules/Infographics/
[18:54] <Saviq> greyback, I did "pkill -9 webapp"
[18:54] <Saviq> greyback, so afaict it did kill just the webapp-container
[18:54] <greyback> Saviq: which didn't do anything for me :)
[18:54] <Saviq> greyback, and shouldn't matter in any case
[18:55] <Saviq> greyback, let me check gmail then
[18:55] <Saviq> greyback, it might be specific to "old-style" webapps
[18:55] <greyback> Saviq: I'll try pkill again
[18:55] <Saviq> greyback, try on jakdojade.pl - which is what I tried
[18:55] <greyback> Saviq: either way, I'll try
[18:57] <Saviq> greyback, yeah, gmail behaves fine, jakdojade.pl does not, I wonder if it's the "--webapp" arg
[18:57] <greyback> Saviq: ok, well if I can repro, I can fix
[18:59] <Saviq> greyback, so indeed I'm killing a child
[18:59] <Saviq> greyback, jakdojade.pl uses webbrowser-app --webapp
[18:59] <Saviq> greyback, while gmail uses webapp-container directly
[18:59] <Saviq> in .desktop Exec= lines
[18:59] <greyback> Saviq: grand, that helps
[19:01] <Saviq> greyback, it might be wrong to use webbrowser-app, but that's what the SDK suggested AFAIR, so probably need to cater for that, too
[19:02] <greyback> Saviq: indeed. As it worked before (it did, right?) it must work now too. Just didn't realize gmail was different to other webapps, gmail was my go-to app for testing webapps
[19:02] <kgunn> Saviq: so, can you imagine we'd need to do any work to support push notifications? ...i woulda thot that would be backend (unity api team)work?
[19:02] <kgunn> am  i missing something
[19:02] <Saviq> well, we never resumed anything, so it didn't work in that sense, it behaves fine except for the "can be resumed" use case
[19:03] <Saviq> kgunn, coop between us and API sometimes, but mostly API, yes
[19:03] <Saviq> kgunn, like we already added support for setting the launcher counters
[19:03] <Saviq> kgunn, https://code.launchpad.net/~ted/unity8/launcher-dbus/+merge/215917
[19:04] <kgunn> Saviq: right, like if there some data field we have missing...
[19:04] <Saviq> but that was actually only API team by now since mzanetti exposed everything in the launcher backend before
[19:04] <Saviq> kgunn, we did discuss a "post office" concept today https://docs.google.com/a/canonical.com/drawings/d/1XpLCqGFo0_o6Sg_tDINigcxNq5VzAmbkktdobjwUvlQ/edit
[19:05] <Saviq> kgunn, to consolidate all feedback in a single API, for push and apps to use
[19:05] <Saviq> kgunn, JLenton's team will be incubating that in the push notifications backend for now
[19:05] <Saviq> ted, don't peek!
[19:06] <ted> seb128, Heh
[19:06] <ted> Saviq, Heh
[19:06] <ted> seb128, Sorry
[19:06] <Saviq> ;)
[19:07] <Saviq> kgunn, so as long as we expose all the entry points to the "endpoints" as indicated in that diagram, we're good
[19:08] <kgunn> Saviq: agreed, can't help but wonder/ask...whats the arch advantage of making that "post office" separate from notification backend?
[19:08] <Saviq> kgunn, you mean from push notification backend?
[19:08] <kgunn> yeah
[19:08] <kgunn> realize there is a naming thing there...but
[19:09] <kgunn> like app would use it too (so no longer just push)
[19:09] <Saviq> kgunn, well, we want to make local services/apps interface with the post office, too
[19:09] <Saviq> kgunn, and it's a feeling that push notifications backend should deal with just that - push notifications
[19:09] <Saviq> kgunn, for OEM replacement purposes if not anything else
[19:09] <kgunn> Saviq: got it...makes sense, push notif is more about server req/resp
[19:10] <kgunn> post office more about getting ui elements updates
[19:10] <Saviq> kgunn, yeah, applying policy (like "don't bug me" mode) and such
[19:10]  * kgunn remembers june is coming
[19:10] <kgunn> worries
[19:11] <Saviq> kgunn, oh yeah, post-that
[19:11] <Saviq> kgunn, that's why I say "incubate in push backend"
[19:11] <kgunn> ok
[19:11]  * kgunn worries less, until someone comes along and mandates it for june ;)
[19:12] <Saviq> ;)
[19:12] <kgunn> josharenson josharenson1 hey...which one are you :)...anyway, could you add the raw data to that sheet as well ? sorry if i didn't ask for that y'day
[19:13] <josharenson> kgunn, yeah I'm still gathering it... itll be there by eod
[19:13] <josharenson> kgunn, the internet where I'm at is terrible and I'm downloading android/ubuntu images
[19:14] <kgunn> josharenson: no worries
[19:14] <Saviq> kgunn, I'm thinking we should drop project bugs for unity8 (and other projects under our purview that basically only get released into Ubuntu)
[19:14] <Saviq> kgunn, it would require at least some of us to get into https://wiki.ubuntu.com/UbuntuBugControl
[19:14] <Saviq> kgunn, otherwise we lose triage rights
[19:15] <Saviq> kgunn, advantage being we wouldn't have to bug lists (unity8 and unity8 (Ubuntu))
[19:16] <Saviq> and LP managing the bugreports for us (closing on merge)
[19:16] <Saviq> s/to bug lists/two bug lists/
[19:16] <kgunn> Saviq: +1
[19:16] <kgunn> its what people want i think
[19:16] <kgunn> people==other leaders in canonical
[19:18] <kgunn> Saviq: should we just send team mails out and then lock down the project bugs (disallowing any new entries)?
[19:18] <Saviq> kgunn, well, we need to get into BugControl first :)
[19:18] <Saviq> kgunn, I'm not there, for example
[19:18]  * kgunn remembers there was some reason this wasn't totally clean....
[19:19] <Saviq> kgunn, yeah, you get triage rights for the whole of Ubuntu
[19:19] <Saviq> kgunn, so the barrier to entry is a bit steep
[19:19] <kgunn> Saviq: but also, if you do project milestones...like mir does, then you can't use those
[19:19] <kgunn> your stuck with "ubuntu" as your project
[19:19] <Saviq> kgunn, oh yeah, this would only be about projects that only target Ubuntu
[19:19] <kgunn> i think that's what it was
[19:20] <Saviq> kgunn, sure, once a project starts releasing into something other than Ubuntu, it makes perfect sense to maintain both
[19:20] <Saviq> kgunn, but most of our projects don't (and won't for at least some time)
[19:23] <kgunn> Saviq: should we just push for  whole team ?
[19:23] <Saviq> kgunn, over time, sure
[19:23] <Saviq> kgunn, not necessarily all at once
[19:25] <kgunn> Saviq: i seem to have rights already...have you tested yours ?
[19:28] <Saviq> kgunn, you sure? can you set the status to "triaged" for example?
[19:28] <Saviq> kgunn, or set me as assignee? or set importance?
[19:29] <Saviq> there's a limited set of things you can do with distro bugs
[19:29] <Saviq> when you're not bug control
[19:30] <kgunn> Saviq: yeah...i just tested a bug that is _only_ filed against unity8(ubuntu) and i could do all those things
[19:30] <kgunn> wonder if i have it via inheritance
[19:30] <Saviq> might be, I don't
[19:31] <kgunn> +1 to getting rights before changing anything
[19:32] <kgunn> prob should get gerry, terry, and zanetti rights as well...
[19:32] <ted> greyback, http://bazaar.launchpad.net/~ted/upstart-app-launch/app-object/view/head:/libupstart-app-launch/ubuntu-app-object.h
[19:36] <Saviq> kgunn, I imagine mterry already is bugcontrol
[19:37] <Saviq> kgunn, what does https://launchpad.net/~ubuntu-bugcontrol say about yourself?
[19:37] <mterry> yeah I'm in that team
[19:39] <kgunn> Saviq: they even have greyback as having control...wow...they'll let anyone in
[19:40] <Saviq> kgunn, ;D
[23:21] <kristenbb> hi, anyone here ?