[01:11] <chaz-yorba> anybody have an idea why an application menu would be titled "Unknown Application Name" instead of the name of the application?
[01:12] <chaz-yorba> I'm trying to add application menus to Geary, and it's working, just showing up with the wrong name, and I don't know how to make it see the correct name
[08:23] <Saviq> mornin'
[08:23] <Saviq> tsdgeos, better today?
[08:23] <tsdgeos> almost there
[08:23] <tsdgeos> my throat still not happy
[08:23] <tsdgeos> got some kind of infection i'd say, but head's mostly fine
[08:23] <tsdgeos> so it's a good thing we don't talk that much in here :D
[08:24] <Saviq> tsdgeos, good ;D
[08:24] <Saviq> seen https://code.launchpad.net/~aacid/unity8/more_filter_fixes/+merge/198427/comments/459996 ?
[08:24] <tsdgeos> yep
[08:25] <tsdgeos> i guess the tests are not as separate one from eachoer as they should be
[08:25] <tsdgeos> and i only was testing my new test isolated
[08:25] <tsdgeos> should be an easy matter to make the test be self contained
[08:25] <tsdgeos> on it
[08:51] <tsdgeos> actually it's weird, a mouseClick is not getting where it should :-S
[08:55] <tsdgeos> actually it's weird, a mouseClick is not getting where it should :-S
[08:55] <tsdgeos> err
[08:55] <tsdgeos> i meant
[08:55] <tsdgeos> ok, found out what's wrong
[08:55] <Saviq> \o/
[09:04] <tsdgeos> pushed
[09:04] <tsdgeos> should fix it
[09:04] <tsdgeos> now let's see the tabbar ones
[09:04] <tsdgeos> that have the problem that pass here afair
[09:10] <tsdgeos> we still don't have videos for the qml tests, right?
[09:14] <tsdgeos> interesting adding a waitForRendering i can make it fail here too
[09:14] <tsdgeos> good
[09:52] <tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity8/more_filter_fixes/+merge/198427 passed now
[09:52] <Saviq> tsdgeos, thanks
[10:15] <Saviq> dednick, ping
[10:15] <dednick> Saviq: yo
[10:16] <Saviq> dednick, hey, did you see my comment on the messaging app time issue?
[10:16] <Saviq> bug #1253810
[10:17] <Saviq> dednick, I got kinda lost in the menu vs. model vs. modelIndex and which model is it supposed to call the loadExtendedAttributes on...
[10:17] <Saviq> dednick, it could use some streamlining...
[10:19] <Saviq> dednick, but to start with, in all the Component.onCompleted:, you need to check whether model is there already, and also react to modelChanged - so you basically need BaseMenuItem to introduce a property that will hold that model (and modelIndex, for that matter), and have those bound in onLoaded
[10:20] <dednick> Saviq: can you give me a few minutes. Just going into a meeting with john.
[10:20] <Saviq> dednick, I know it's not entirely your code, but remember the rule of thumb: never reach outside of the current file - if you need something - bind it
[10:20] <Saviq> dednick, sure
[10:28] <Saviq> tsdgeos, still one failure in tabbar dash
[10:28] <tsdgeos> yeah
[10:28] <tsdgeos> bit lost tbh
[10:28] <tsdgeos> pushed a small change to try to find out if it's the tab not changing
[10:29] <tsdgeos> or the tab change not propagating to the dash
[10:29] <tsdgeos> let's see what the next run says
[10:37] <Saviq> tsdgeos, cheers
[10:37]  * Saviq builds qt5 release for i386 to see if it helps with bug #1258057
[10:38] <Saviq> oh no /me isn't ;?
[10:39] <Saviq> ok back in the game
[10:52] <dednick> Saviq: hm. ok, trying to sort out the naming and "outside of source", but I don't think we need to react to modelChanged. if it does, all the items will invalidate anyway.
[10:53] <Saviq> dednick, somehow model is null in onCompleted
[10:53] <Saviq> dednick, I did find it weird indeed
[10:53] <Saviq> dednick, especially since it was reaching out of scope
[10:54] <dednick> I don't want to put the model or anything like that into the items. That adds impl detail. all impl detail properties are added to the Components in the Factory.
[10:54] <Saviq> dednick, s/null/undefined/
[10:54] <dednick> Saviq: hm. weird.
[10:54] <tsdgeos> EphemeralNotificationsTests is also unstable now?
[10:55] <Saviq> tsdgeos, shouldn't be
[10:55] <dednick> Saviq: oh, model, or modelIndex undefined?
[10:55] <Saviq> dednick, model
[10:55] <dednick> Saviq: for messaging items?
[10:55] <tsdgeos> Saviq: it failed twice in my tabbar branch, which has nothing to do with notifications :-/
[10:55] <Saviq> tsdgeos, only jenkins, of course?
[10:55] <tsdgeos> Saviq: of course
[10:56] <Saviq> tsdgeos, ah autopilot?
[10:56] <dednick> Saviq: model is defined in the Factory, so i'm not sure why it's out of scope.
[10:56] <tsdgeos> Saviq: yep
[10:57] <Saviq> dednick, what I *think* might be happening there
[10:57] <Saviq> dednick, is that model is ambiguous
[10:57] <Saviq> dednick, remember "model" is something a ListView provides in delegates' context
[10:57] <Saviq> dednick, so maybe it's enough to just prefix it with menuFactory
[10:57] <dednick> Saviq: ok. well I'm changing the names. let me see if that fixes it.
[10:58] <Saviq> dednick, yeah, I was quite lost what was what
[11:01] <Saviq> tsdgeos, hm? https://code.launchpad.net/~aacid/unity8/tabbar_dash/+merge/192505/comments/460186
[11:02] <tsdgeos> that's the last one
[11:02] <tsdgeos> but see http://s-jenkins:8080/job/unity8-ci/1865/console
[11:03] <tsdgeos> and also i have seen it somewere else
[11:03] <mzanetti> greyback: Saviq: https://code.launchpad.net/~mzanetti/unity-api/new-screenshot-api/+merge/198536
[11:03] <mzanetti> If you're happy with this I'd go ahead updating tests and changing unity-mir to reflect it
[11:03] <Saviq> tsdgeos, it looks like a crash or something
[11:04] <Saviq> mzanetti, looks good
[11:04] <tsdgeos> ok, so ui tests failed again, obviously
[11:05] <tsdgeos> confusing
[11:15] <greyback> mzanetti: +1 from me
[11:17] <mzanetti> nice. thanks
[11:29] <tsdgeos> ok, new iteration in the way
[11:34] <Saviq> tsdgeos, seen http://pastebin.ubuntu.com/6555591/ ?
[11:36] <tsdgeos> hmmm
[11:36] <tsdgeos> nope
[11:36] <tsdgeos> but tbh i don't usually compile webkit
[11:39] <mhr3_> Saviq, question about the json validation - how much validation do you think it should do? just ensuring that keys have proper types, or check values as well?
[11:39] <mhr3_> Saviq, ie should a "card-size": "xx-large" cause an error?
[11:40] <Saviq> mhr3_, if we use the json schema, that would be an error, yes
[11:41] <Saviq> mhr3_, or we can say that this is just a string and not an enum
[11:41] <Saviq> mhr3_, at which point we'd need to warn outside of the schema validation, that this is an incorrect value
[11:41] <mhr3_> Saviq, the way i see it is that the validation is a top-level thing, and if it fails, things are too bad, you can no longer just fallback to a default for one key
[11:42] <mhr3_> the question is really about extensibility
[11:42] <Saviq> mhr3_, yeah, that's why I'm saying it could be a warning at a higher level
[11:42] <mhr3_> when we do add support for xx-large, we want the old devices to still work with that scope, don't we?
[11:43] <Saviq> mhr3_,  but yes, IMO it should check the values and any other rules we might have (say you're required to map at least one of title, price, rating, or that you can only map subtitle if you've mapped title as well)
[11:43] <Saviq> mhr3_, that would be a new version of the schema, though
[11:44] <mhr3_> Saviq, but then it's for sure that the old device wouldn't support it
[11:44] <Saviq> mhr3_, right
[11:44] <Saviq> mhr3_, so... maybe the client needs to send the highest version it supports, then?
[11:45] <Saviq> mhr3_, and we might have conversion rules
[11:45] <Saviq> mhr3_, but anyway, still, we need to discern between a recoverable and non-recoverable errors
[11:45] <Saviq> mhr3_, i.e. we can recover from xx-large
[11:46] <mhr3_> sure, it's just starting to sound like too much work for the scope authors
[11:46] <Saviq> mhr3_, by falling back to the default medium
[11:46] <Saviq> mhr3_, the conversion rules would be our side
[11:46] <Saviq> mhr3_, so you get results v10 from the scope
[11:46] <Saviq> mhr3_, but client only supports v8
[11:46] <mhr3_> then you don't have code that understands v10
[11:47] <Saviq> mhr3_, well, you won't have a v10 scope in that case
[11:47] <Saviq> mhr3_, I'm thinking SSS
[11:47] <mhr3_> i'm thinking scopes in app store
[11:47] <Saviq> mhr3_, yeah, that's framework version, though
[11:48] <Saviq> mhr3_, they would require 14.04 or 14.10 - and won't be available for older devices
[11:48] <mhr3_> hm, ok that solves that part
[11:48] <Saviq> mhr3_, for SSS, we'd need v10-to-v8 conversion code
[11:48] <mhr3_> weeee, "fun"
[11:49] <Saviq> indeed
[11:49] <Saviq> mhr3_, still better than us requiring scope authors to support multiple versions
[11:49] <mhr3_> think sss will just hide those scopes for the older devices :)
[11:49] <Saviq> mhr3_, that can work as well, yeah
[11:49] <Saviq> it's supposed to be s, after all
[11:50] <Saviq> mhr3_, so, done! ;)
[11:50] <Saviq> mhr3_, bu
[11:50] <Saviq> t
[11:50] <Saviq> mhr3_, error vs. warning
[11:50] <mhr3_> aah, no buts
[11:50] <Saviq> mhr3_, xx-large size would be a warning, fallback to default
[11:50] <Saviq> mhr3_, but mapping only subtitle would be error
[11:50] <mhr3_> sounds reasonable
[11:51] <Saviq> mhr3_, so we can't do "real" schema for card-size
[11:51] <mhr3_> the schema will be super complex for such checks though
[11:51] <Saviq> mhr3_, we need a sanitizer layer on top of the schema
[11:52] <Saviq> mhr3_, so yeah, schema could not error out for any recoverable error
[11:52] <Saviq> mhr3_, the sanitizer layer could do both warning and error
[11:52] <mhr3_> Saviq, i'm just doing http://paste.ubuntu.com/6555663/
[11:52] <mhr3_> so wondering how much it'll grow in the future
[11:53] <Saviq> mhr3_, yeah, that will grow a lot, I'm afraid...
[11:53] <Saviq> mhr3_, especially if we say some things are recoverable errors
[11:53] <Saviq> mhr3_, but then... do we really want that?
[11:54] <mhr3_> future me will be pissed when he has to implement it
[11:54] <Saviq> mhr3_, couldn't we say that "dude, you've seen the errors in the dev tool, sod off"?
[11:54] <mhr3_> well, something still has to produce those
[11:54] <Saviq> mhr3_, the schema would, tehn
[11:54] <Saviq> then
[11:55] <Saviq> mhr3_, and on top of that only stuff the schema can't catch
[11:55] <mhr3_> so we'd maintain a super-strict and a regular schema?
[11:55] <Saviq> mhr3_, yeah
[11:55] <Saviq> mhr3_, wait
[11:55] <Saviq> no
[11:55] <Saviq> one schema
[11:55] <Saviq> mhr3_, we just say no-fallbacks, your stuff needs to be correct
[11:56] <mhr3_> hmm
[11:56] <Saviq> mhr3_, and if it's not, we ignore results from your scope completely
[11:56] <Saviq> mhr3_, if we do the dev tool right, that *could* be enough
[11:56] <mhr3_> yea, just wondering whether i'm happy or sad about that :)
[11:57] <Saviq> mhr3_, it's either that or a thick sanitizer layer
[11:57] <mhr3_> but ok, i see your point
[12:00] <davidcalle> mhr3_, Saviq, my two cents as an author: if you are going with the no-fallbacks road, awesome docs please :)
[12:00] <Saviq> davidcalle, I know :)
[12:00] <Saviq> davidcalle, it's just for the JSON definitions, though, and will be validated by a JSON schema that we maintain and agree to
[12:01] <Saviq> davidcalle, so basically, if we failed to do the schema right, and you have something that passes the schema and sanitization checks - it's our responsibility to deal with it
[12:01] <Saviq> davidcalle, but as long as you don't pass the schema, you're on your own ;)
[12:02] <Saviq> davidcalle, that schema will be documented, too, btw
[12:02] <mhr3_> the schema *check* that is
[12:02] <Saviq> mhr3_, yes, validation and sanitization
[12:02] <mhr3_> clarifying cause it sounded like you need to pass some kind of schema
[12:03] <Saviq> ok yeah, sorry
[12:04] <davidcalle> Authors can still pass the layout - according to the specs - they want, right ?
[12:06] <Saviq> davidcalle, yes yes
[12:06] <davidcalle> Saviq, ok
[12:07] <dednick> Saviq: https://code.launchpad.net/~nick-dedekind/qmenumodel/loadExtAttributes-dataChanged/+merge/198549
[12:08] <Saviq> dednick, cool
[12:08] <Saviq> dednick, did you manage to verify it fixes the bug?
[12:08] <Saviq> dednick, or is that just a road to that?
[12:08] <dednick> Saviq: it's only part of it.
[12:08] <Saviq> dednick, ok
[12:08] <dednick> Saviq: is there actually a bug? or is it just log messages?
[12:09] <Saviq> dednick, https://launchpad.net/bugs/1253810
[12:09] <dednick> Saviq: ah, yeah, i ddint see that in original comment
[12:10] <Saviq> biab
[12:14] <dednick> Saviq: is there a way you can reproduce reliably?
[12:16] <dednick> hm. just realised my nexus 10 doesnt have sim, so no messaging... boo
[12:16] <dednick> but of an issue
[12:16] <dednick> s/but/bit
[12:22] <om26er> mzanetti, are music previews supposed to work? i.e. able to play a song in the dash ?
[12:24] <tsdgeos> yes
[12:31] <mzanetti> om26er: yes. it doesn't work?
[12:31] <mzanetti> hmm... it doesn't indeed
[12:35] <mzanetti> greyback: how do you test unity-mir changes on the device? Do you sync code manually and compile on the device or is there some run_on_device thingie for it?
[12:36] <greyback> mzanetti: sync usually.
[12:50] <tsdgeos> mzanetti: ? works here (desktop)
[12:57] <Saviq> dednick, you don't have a phone at all?
[12:57] <Saviq> dednick, I can reproduce semi-reliably
[12:58] <Saviq> dednick, so I can test anything you need
[12:59] <dednick> Saviq: yeah, i have a galaxy nexus, but didnt bring it to the office with me today :(
[12:59] <Saviq> dednick, well, there's bound to be *someone* with a phone in the office ;)
[12:59] <Saviq> dednick, but regardless - let me know, I can test
[13:00] <dednick> Saviq: cool. i can't seem to reproduce with the test app.
[13:01] <Saviq> dednick, it's a race, basically, so makes sense that it only happens on some devices but not others
[13:01] <Saviq> dednick, you can try restarting unity8 while things stay in the indicator to see - happened for me some times, too
[13:27] <dednick_> Saviq: you mind checking if trunk qmenumodel fixes the issue for you? Will most likely still get nasty log messages though.
[13:27] <dednick_> when you have a few minutes free of course
[13:28] <Saviq> dednick_, will do
[13:29] <dednick_> Saviq: thanks
[13:40] <Saviq> tsdgeos, how do I tell Qt to use a certain QPA plugin path? i.e. a locally built one?
[13:47] <dandrader> Saviq, I think you have to install it
[13:48] <Saviq> dandrader, yeah, it's installed in a prefix
[13:48] <Saviq> dandrader, but I now need to tell Qt what that prefix is...
[13:48] <dandrader> Saviq, I mean that I think it must be installed in Qt's regular plugin path
[13:48] <Saviq> dandrader, ugh
[13:49] <Saviq> that can't be :/
[13:49] <dandrader> Saviq, one way to avoid messing up things is giving your QPA a different name
[13:49] <dandrader> Saviq, so that you can choose when to use it with the QT_QPA_PLATFORM env var
[13:53] <Saviq> dandrader, yeah, thing is... if I set the prefix during building Qt, shouldn't the "regular plugin path" be under that prefix anyway?
[13:53] <dandrader> Saviq, I guess so
[13:54] <Saviq> dandrader, yeah, which is why I'm surprised it doesn't *just work*
[13:59] <tsdgeos> Saviq: there's some envvar
[13:59] <tsdgeos> Saviq: have you found it?
[13:59] <Saviq> tsdgeos, no
[13:59] <tsdgeos> let me check
[14:00] <tsdgeos> QT_QPA_PLATFORM_PLUGIN_PATH
[14:00] <tsdgeos> not sure what you have to make it point to
[14:01] <tsdgeos> or oyu can use -platformpluginpath to the binary
[14:01] <Saviq> tsdgeos, thanks, will check it out in a bit
[14:01] <Saviq> tsdgeos, weird that it wouldn't pick them up from the default prefix by default, 'innit?
[14:01] <tsdgeos> it is
[14:08] <tsdgeos> wow now the tabbar test crashed
[14:08] <tsdgeos> do we keep the .crash files for them?
[14:29] <MacSlow> Saviq, mumble doesn't start here... keep trying
[14:29] <Saviq> MacSlow, tsdgeos, mzanetti, we're in a meeting still with greyback and kgunn
[14:30] <tsdgeos> ok
[14:30] <MacSlow> Saviq, ok
[14:32] <MacSlow> hm... -> "Settings schema 'com.canonical.unity-gtk-module' is not installed"
[14:59] <Saviq> tvoss, btw, added benefit for out-of-process content picker → it can be contained read-only, so it can't b0rk the app's data
[15:00] <tvoss> Saviq, I'm just thinking that it really is the right way of doing it for tight integration
[15:01] <Saviq> tvoss, "it" → separate process?
[15:01] <tvoss> Saviq, separate process, with the app providing a "factory" for a content picker that runs under read-only confinement and probably resource limited
[15:01] <tvoss> Saviq, with the content hub providing the "executor"
[15:01] <Saviq> tvoss, yeah, and that can actually be stateful as well
[15:02] <Saviq> tvoss, per-content-picking sessions
[15:02] <Saviq> -s
[15:02] <tvoss> Saviq, sure, that's what I mean
[15:02] <Saviq> tvoss, so actual app and its content picking sessions can be archived separately
[15:02] <Saviq> tvoss, archived, killed, resumed etc.
[15:02] <Saviq> tvoss, without affecting any of the other content pickers or the app itself
[15:03] <tvoss> Saviq, yup, but I still think the vanilla picker integration would be a good first cut, too, as it would work for all apps regardless
[15:03] <Saviq> tvoss, sure
[15:03] <tvoss> Saviq, okay, I will note down those thoughts
[15:03] <Saviq> tvoss, first step → single instance
[15:03] <tvoss> Saviq, ack
[15:03] <tvoss> Saviq, driving use-case for second step: gallery
[15:03] <Saviq> tvoss, yup
[15:04] <tvoss> DONE ... almost ;)
[15:54] <mhr3_> Saviq, mzanetti, https://code.launchpad.net/~mhr3/unity-scopes-shell/json-defaults/+merge/198591
[16:07] <greyback> looks like Qt5.2 is out
[16:10] <dednick_> Saviq: https://code.launchpad.net/~nick-dedekind/unity8/indicator-menuitems-lp1253810/+merge/198597
[16:10] <dednick_> it's probably a bit more than you hoped for though
[16:10] <Saviq> mhr3_, cheers
[16:10] <Saviq> dednick_ conflicts?
[16:10] <dednick_> ...
[16:21] <dednick_> Saviq: ok, fixed conflicts
[16:55] <mhr3_> mzanetti, hm, know about https://code.launchpad.net/~sil2100/unity-scopes-shell/revert_25/+merge/198595 ?
[16:55] <sil2100> mhr3_, mzanetti: testing this revert on my phone to make sure
[16:57] <kgunn> Saviq: ^
[16:57] <mhr3_> i just don't see why it shouldn't work... unless the unity8 part didn't get merged
[16:58] <Saviq> hrmpf
[16:59] <Saviq> mhr3_, http://bazaar.launchpad.net/~unity-team/unity8/trunk/revision/563 did get merged
[17:00] <kgunn> Saviq: mhr3_ so we had all the relevant merges but we didn't test if a click package could launch ?
[17:00] <sil2100> mhr3_, Saviq: but we're not releasing unity8 now
[17:00] <Saviq> kgunn, we did
[17:00] <Saviq> sil2100, it was released already
[17:00] <kgunn> weird
[17:00] <Saviq> kgunn, something else must be in play
[17:00] <Saviq> kgunn, the unity8 change was safe either way
[17:00] <sil2100> Then something's wrong, somewhere else it seems
[17:00] <mhr3_> Saviq, was that the only thing? doesn't seem enough
[17:00] <kgunn> Saviq: right...so are we reverting the correct thing? or are we just reacting to fast ?
[17:01] <kgunn> can we bisect ?
[17:01] <Saviq> mhr3_, 562, too
[17:01] <Saviq> mhr3_, http://bazaar.launchpad.net/~unity-team/unity8/trunk/revision/562
[17:02] <Saviq> mhr3_, sil2100, do we need to release scopes-shell today?
[17:02] <sil2100> Saviq: we released it already
[17:02] <Saviq> ah
[17:02] <sil2100> Saviq: since no AP tests caught this behavior
[17:02] <Saviq> :/
[17:02] <sil2100> :|
[17:03] <sil2100> Saviq, mhr3_, kgunn: the revert works fine and fixes the issue, so we'll be pushing it out as a temporary solution
[17:03] <kgunn> sil2100: Saviq ...does AP test cover this behavior ?
[17:03] <Saviq> sil2100, ok
[17:03] <sil2100> Sadly...
[17:03] <kgunn> sil2100: ok
[17:03] <mhr3_> sil2100, ok
[17:03] <Saviq> kgunn, we're launching apps, apparently not click ones
[17:03] <mhr3_> kgunn, sounds like it doesn't
[17:03] <Saviq> kgunn, although for that there's no excuse - we just have low integration coverage all over
[17:04] <Saviq> https://bugs.launchpad.net/bugs/+bugs?field.tag=needs-ap-test FWIW
[17:05] <kgunn> Saviq: ok, no time like the present...can we elect someone from our team to add an AP test to download a known click and launch it ?
[17:06] <Saviq> kgunn, don't even need to download
[17:06] <Saviq> kgunn, there's some preinstalled
[17:06] <kgunn> sweet...1/2 done
[17:06] <kgunn> surely...even when this was on trunk, someone tried to launch a click app ?
[17:08] <Saviq> kgunn, it was in trunk unity8 (safe), unity-scopes-shell (apparently non-safe) was just tested during the review
[17:09] <kgunn> Saviq: ok...well, let's pick a victim for tomorrow to go add a specific AP test
[17:11] <mhr3_> Saviq, it's weird though, if ap is launching at least non-clicks it should catch the issue
[17:11] <mhr3_> both are launched the same way
[17:12] <Saviq> mhr3_, it's launching them directly
[17:12] <Saviq> mhr3_, not from the shell
[17:12] <mhr3_> then we really want a test to do it via shell
[17:12] <Saviq> mhr3_, oh yeah, definitely
[17:16] <kgunn> Saviq: would zanetti be best for this ?
[17:16] <kgunn> i added a critical bug https://bugs.launchpad.net/unity8/+bug/1260013
[17:16] <Saviq> kgunn, actually we can ask veebers to get this overnight
[17:16] <kgunn> ok...will put his name on it
[17:17] <Saviq> except...
[17:17] <Saviq> I can launch clicks fine from the launcher
[17:17] <sil2100> kgunn, mhr3_, Saviq: thanks guys, the revert is in the build right now
[17:17] <kgunn> right...need to launch from the dash right ?
[17:18] <Saviq> kgunn, right, it doesn't go through the scopes..
[17:18] <mhr3_> Saviq, how can the revert even work? shouldn't it blow up because unity expects just app_id now?
[17:18] <Saviq> launched fine
[17:19] <Saviq> from dash
[17:19] <Saviq> mhr3_, shell doesn't really care
[17:20] <Saviq> sil2100, is there a bug reporting that issue?
[17:20] <sil2100> Saviq: let me file it
[17:23] <sil2100> Saviq, mhr3_: https://bugs.launchpad.net/unity-scopes-shell/+bug/1260020
[17:25]  * Saviq no get it...
[17:25] <Saviq> can confirm with released unity8, trunk works fine, with no related change between the last release and now :?
[17:28] <sil2100> Saviq: what do you mean?
[17:29] <Saviq> sil2100, I mean that it works fine when I run unity8 trunk with the release of unity-scopes-shell
[17:29] <sil2100> Ah
[17:29] <sil2100> hm
[17:29] <Saviq> sil2100, but not when running released unity8, where there's nothing in trunk unity8 related to it at all
[17:30] <Saviq> sil2100, might be my env is unclean
[17:30] <Saviq> sil2100, building from scratch now
[17:32] <Saviq> sil2100, yeah, something must've remained in my environment
[17:32] <Saviq> kgunn, ↑ that could've bit us when testing, FWIW
[17:37] <cwayne_> davidcalle, is there a list of keywords somewhere for the server-side scopes?
[17:37] <cwayne_> i know for local ones you can just rgrep keyword in /usr/share/unity/scopes/
[17:37] <davidcalle> cwayne : https://productsearch.staging.ubuntu.com/smartscopes/v1/remote-scopes here you go :)
[17:38] <davidcalle> cwayne_, wait, remove the staging from the uri
[17:38] <cwayne_> davidcalle, awesome, thanks!
[17:43] <cwayne_> davidcalle, some of them never seem to return anything, (e.g. stackexchange: and grooveshark:)
[17:45] <Saviq> mhr3_, activating "/com.ubuntu.weather_weather_1.0.158.desktop"
[17:45] <Saviq> :/
[17:49] <mhr3_> Saviq, ehm? but the code did .basename()
[17:49] <Saviq> mhr3_, yeah
[17:49] <mhr3_> so... wtf?
[17:49] <Saviq> which seems to not do what it's expected to
[17:50] <davidcalle> cwayne_, yes, they are part of the API limited scopes, so they will work again in a few hours, when they don't hit their queries limits anymore. There is some caching work going on, to make these outages less noticeable.
[17:51] <Saviq> mhr3_, ah wait, that's *before* the basename
[17:52] <mhr3_> Saviq, aah... dots
[17:52] <mhr3_> will try to activate "com"
[17:54] <mhr3_> needs to be .completeBaseName()
[17:57]  * mhr3_ out
[18:01] <Saviq> uh :/
[18:12] <Saviq> alesage, dednick is back this week
[18:12] <alesage> Saviq, ok super, shall we get a review from him?
[18:16] <Saviq> alesage, yeah, we need to get indicator-stubs through, first...
[18:17] <Saviq> alesage, and I've completely no idea what's happening there :/
[18:17] <alesage> Saviq, ok understood--so it is the test failures that are blocking us
[18:17] <Saviq> alesage, yeah
[18:17] <alesage> Saviq, I'll try to take it up with CI
[18:22] <Saviq> alesage, I don't think they can do anything there - I can reproduce it locally - just have no idea what's happening
[18:22] <Saviq> kgunn, FWIW https://code.launchpad.net/~saviq/unity-scopes-shell/fixed-click-launch/+merge/198626
[18:23] <Saviq> .baseName() vs. .completeBaseName()
[18:23] <alesage> Saviq, weird, but is it just our (i.e. my) branch?
[18:23] <Saviq> alesage, yeah, that's the thing
[18:23] <Saviq> alesage, your tests do *something* to the test env that makes them fail
[18:23] <Saviq> alesage, they pass in isolation, of course
[18:23] <alesage> Saviq grr ok
[18:24] <Saviq> alesage, so it's pretty difficult to pin down, I just need to sit down and look at the phone while it's doing the tests at least
[18:25] <alesage> Saviq ok right I haven't run the whole suite, will do so this afternoon and get some help
[19:42] <mhall119> Saviq: did you get a chance to work on a Unity 8 Saucy PPA today?
[19:43] <Saviq> mhall119, I'm afraid not, was a hot day
[19:43] <mhall119> no worries, just let me know when it's there and I'll go back and update the documentation (after trying it, of course)
[19:44] <Saviq> mhall119, do you think daily recipes from trunks would be ok?
[19:45] <mhall119> what's going into trusty's archives currently?
[19:45] <Saviq> mhall119, manual releases
[19:45] <Saviq> mhall119, but that would add burden on that process, if it was to go to saucy, too
[19:46] <mhall119> right, do we want *only* saucy builds in the PPA then, or saucy *and* trusty from trunk?
[19:46] <Saviq> mhall119, I'd say saucy only
[19:46] <Saviq> mhall119, as a "try this, but if it doesn't work, it's not our top priority"
[19:46] <Saviq> mhall119, we basically can't maintain both
[19:50] <mhall119> ok, that's fine with me
[20:02] <Saviq> mhall119, ok, I put unity-api and unity-scopes-shell in recipes for https://code.launchpad.net/~phablet-team/+archive/desktop-deps
[20:02] <Saviq> mhall119, at least temporarily (I'd like to move it under ~unity-team)
[20:03] <mhall119> why didn't you put it under ~unity-team to begin with?
[20:03] <Saviq> mhall119, that PPA I had already, and it has increased points
[20:03] <Saviq> mhall119, those two should be all that's needed to build unity8 on saucy, will verify later today
[20:04] <Saviq> points == build score
[20:04] <mhall119> ok, I'll try from there
[20:42] <Saviq> http://download.qt-project.org/official_releases/qt/ cool beanz
[20:43] <Saviq> greyback, still around?
[21:03] <kgunn> Saviq: hey hey...think that means we'll get 5.2 before christmas ?
[21:03] <kgunn> in touch that is
[21:04] <Saviq> kgunn, looking at https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta2
[21:04] <Saviq> kgunn, not necessarily
[21:04] <Saviq> kgunn, or well https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta2/+packages
[21:05] <Saviq> kgunn, a *lot* of red :/
[21:19] <kgunn> Saviq: you still on?...if i modified an AP test...can i check that out by doing run_on_device...and then doing all the other steps for running AP tests?
[21:20] <kgunn> or more simply...how would i go about doing that
[21:20] <kgunn> ?
[21:20] <Saviq> kgunn, if you only modified the AP test
[21:20] <Saviq> kgunn, it's enough to go on the device (ssh preferred for better terminal)
[21:20] <kgunn> yes...that's all
[21:20] <Saviq> kgunn, issue `initctl stop unity8`
[21:21] <Saviq> go into ~phablet/shell
[21:21] <Saviq> and run `PYTHONPATH=tests/autopilot autopilot run unity8` for the whole suite
[21:21] <Saviq> or `PYTHONPATH=tests/autopilot autopilot run unity8.test.foo` for a single test
[21:22] <Saviq> you can see the available test names with `PYTHONPATH=tests/autopilot autopilot list unity8`
[21:22] <Saviq> kgunn, only difference if you want to run the tests on the local build - `ninja -C builddir install` first
[21:22] <kgunn> Saviq: that's pretty cool...thanks...i'm trying to disable some tests on maguro...want to make sure i didn't break anything for mako
[21:23] <Saviq> kgunn, as in - the autopilot tests will pick up the locally built/prefix-installed unity8
[21:23] <kgunn> ok...nah, i was gonna use todays image
[21:23] <Saviq> kgunn, ugh, disabling tests ;/
[21:24]  * Saviq just runs the suite on mako and maguro to see what's the whole deal
[21:25] <kgunn> so didrocks complaining that some tests are flakey on maguro...so instead of arguing...and avoid turning them off completely, i was going to disable them on maguro
[21:25] <kgunn> so you might not see failures
[21:29] <Saviq> or! we could fix the flakiness of the tests ;)
[21:30] <Saviq> kgunn, did you actually see them fail, btw?
[21:31] <kgunn> Saviq: didn't "see" them...but reported here http://ci.ubuntu.com/smokeng/trusty/touch/maguro/56:20131210:20131203/5363/unity8-autopilot/
[21:31] <kgunn> and http://ci.ubuntu.com/smokeng/trusty/touch/maguro/55:20131209.1:20131203/5355/unity8-autopilot/558729/
[21:31] <Saviq> no crashes at all?
[21:31] <Saviq> that's good :)
[21:31] <kgunn> yes
[21:32] <Saviq> kgunn, so, that really is just one flakiness - that we should just fix
[21:32] <Saviq> kgunn, all the tests failed to unlock unity8
[21:33] <Saviq> (failed ones, that is)
[21:33] <Saviq> so it's the unlock emulator that needs fixing - but first we need to reproduce locally
[21:33]  * kgunn abandons skipif maguro
[21:33] <kgunn> Saviq: that's the strange thing...seems to be happening on maguro
[21:34] <Saviq> kgunn, yeah, it might be some timing - TBH it might  just be that 10s isn't enough for maguro
[21:34] <kgunn> wow
[21:34] <Saviq> to start unity8 and get it in a state that's considered "ready"
[21:34] <Saviq> mind you, that's loading the dash and such
[21:35] <kgunn> yeah...so maybe 15 sec would be ok for maguro...seems it does pass sometimes
[21:35] <Saviq> most times
[21:35] <kgunn> so right on the edge
[21:35] <Saviq> yup
[21:35] <Saviq> kgunn, if you want to try
[21:36] <kgunn> its worth a shot
[21:36] <Saviq> kgunn, tests/autopilot/shell/emulators/greeter.py:40
[21:36] <Saviq> kgunn, add timeout=15
[21:36] <Saviq> as a second argument
[21:36] <Saviq> to wait_for()
[21:37] <kgunn> its like you can see me searching :)
[21:37] <Saviq> kgunn, wanna review something? :)
[21:37] <Saviq> https://code.launchpad.net/~saviq/unity8/add-autopilot-pydev/+merge/195589
[21:37] <Saviq> kgunn, if you install eclipse, and pydev from http://pydev.org/manual_101_install.html
[21:38] <Saviq> kgunn, importing the existing unity8/tests/autopilot project into eclipse
[21:38] <Saviq> kgunn, will get you a nice python IDE
[21:38] <Saviq> unless you're a hardcore VI user, that is
[21:38] <Saviq> ;)
[21:39] <Saviq> kgunn, so yeah, that timeout would really be my guess
[21:40] <kgunn> pydev installed on eclipse...done
[21:42] <kgunn> Saviq: ah...so that mp just allows you to open the project in eclipse easily
[21:43] <Saviq> kgunn, yeah, just saves you 5s... every time you clean your branch - so a substantial amount of time, IMO :)
[21:45] <Saviq> kgunn, and well, QtC is useless for python, so :/
[21:47] <Saviq> kgunn, in case you didn't do it before - Eclipse doesn't "open" projects
[21:47] <Saviq> kgunn, you have to go File → Import → Existing projects into workspace
[21:47] <kgunn> Saviq: was just about to ask...was pretty sure it'd be an import
[21:48] <Saviq> kgunn, 25 passed on maguro here
[21:48] <Saviq> kgunn, will add some timings
[21:48] <kgunn> Saviq: you mean 25 seconds ?...did it fail for you with less ?
[21:49] <kgunn> or the original 10
[21:49] <Saviq> kgunn, no, 25 tests pass
[21:49] <Saviq> kgunn, i.e. 100% pass rate
[21:49] <Saviq> for the original 10s
[21:49] <kgunn> ah yeah
[21:49] <Saviq> so we really must be *just* there
[21:49] <Saviq> like the phone getting hotter in the lab and throttling down or something
[21:49] <Saviq> but I'll add some prints just to be sure
[21:50] <Saviq> if we're reaching like 8s or something, I'm certain that's it
[21:50] <Saviq> on mako - reliably 100% pass rat
[21:50] <Saviq> e
[21:51] <kgunn> yeah...i wondered about temp too...or even age
[21:51] <kgunn> hell even strong vs weak silicon
[21:55] <Saviq> ok so that theory goes down the drain...
[21:55] <kgunn> Saviq: i might be doing something wrong....but the .project & .pydevproject don't show up in the import ?
[21:55] <Saviq> greeter took 1.3s
[21:55] <Saviq> greeter took 1.2s
[21:56] <Saviq> kgunn, Import → Existing projects into workspace → Select root directory (point to unity8 checkout)
[21:57] <Saviq> Should come up with "Unity8 Autopilot" project
[21:58] <kgunn> Saviq: ah yes..magic...
[21:58] <kgunn> thot i had to navigate to the test dir
[21:59] <Saviq> kgunn, well, it should show up if you selected tests/autopilot, too
[21:59] <Saviq> kgunn, it just looks for .project in the subtree
[22:01] <Saviq> kgunn, so, it's actually the unlock gesture that fails
[22:03] <kgunn> Saviq: eeewww
[22:04] <Saviq> kgunn, yeah, it's probably a timing issue in the sense that the gesture is ignored 'cause the movement is not delivered in a timely manner
[22:04] <Saviq> because the device is too slow
[22:05] <kgunn> stupid omap
[22:05] <kgunn> Saviq: so...maybe a retry ?
[22:05] <kgunn> i mean it passes more than not
[22:05] <Saviq> kgunn, it was supposed to be retrying
[22:07] <Saviq> kgunn, I think we lost that as part of a refactor actually
[22:31] <mhall119> Saviq: unity-scopes-api failed to build in the PPA
[22:31] <Saviq> mhall119, yeah, I pung michi in #ferrets
[22:32] <mhall119> ok
[22:32] <mhall119> I'll check again tomorrow
[22:32] <Saviq> mhall119, yeah, I'll monitor it, too
[22:33] <mhall119> thanks
[22:33] <mhall119> Saviq: seriously though, you're allowed to sleep :)
[22:33] <Saviq> mhall119, bollocks
[22:33] <mhall119> we're contractually guaranteed a full 3 hours of sleep every night
[22:37] <kgunn> mhall119: actually...no that's not true
[22:42] <alesage> tedg, thomi having a question about how to install indicator-network minus unity (?)
[22:44] <tedg> alesage, ?
[22:45] <alesage> tedg nm for now thx :)
[22:58] <Saviq> veebers, hey, can you please check out https://code.launchpad.net/~saviq/unity8/helper-retry-unlock/+merge/198648
[22:59] <veebers> Saviq: sure, I'll look now
[23:00] <veebers> Saviq: hmm, I don't think retrying is very good in a test, surely it should work or fail?
[23:00] <veebers> Saviq: oh I'll read scrollback, see if ther is more information
[23:01] <Saviq> veebers, flaky tests on maguro
[23:01] <Saviq> veebers, that's really an issue of timing
[23:02] <Saviq> veebers, the gesture recognizer is quite strict about the velocity of the gesture
[23:02] <veebers> Saviq: is there a way that we can check if the device is ready for input or if the greeter is ready to receive input?
[23:02] <veebers> Saviq: perhaps there is a way to fix the swipe gesture used
[23:02] <Saviq> veebers, there's no real data as to why it fails, really - we suspect that the device is still under heavy load initially
[23:03] <Saviq> veebers, and so the gesture is jerky or so
[23:03] <Saviq> veebers, ideally we'd control the time from outside
[23:03] <Saviq> veebers, but then we start to influence the test too much
[23:04] <veebers> Saviq: I don't understand the comment " ideally we'd control the time from outside"
[23:04] <Saviq> veebers, velocity is calculated based on RTC
[23:04] <veebers> ah ok
[23:04] <Saviq> veebers, and if the movement isn't smooth
[23:05] <Saviq> veebers, that calculation might result in the gesture being rejected
[23:05] <Saviq> veebers, just because the device has not settled yet
[23:06] <Saviq> veebers, if we controlled the time the velocity calculation takes - we'd probably be rid of such issues, but it's a Schroedinger's Cat problem
[23:06] <veebers> Saviq: you're suggesting that the device not being settled yet means that theh python script (autopilot) that is sending the drag events will miss or lag and thus causing the gesture to be rejected?
[23:06] <Saviq> veebers, yeah, more or less
[23:06] <Saviq> veebers, the input isn't delivered in a synchronous manner
[23:06] <veebers> right, make sense
[23:07] <Saviq> veebers, so it seems retrying is actually something least hacky (we could just wait a few seconds) ;)
[23:07] <Saviq> veebers, it won't influence us at all in the 95% of cases where it unlocks at first swipe
[23:08] <Saviq> veebers, but won't fail for that reason in the remaining 5%
[23:08] <veebers> Saviq: right. ok that makes sense. Could you add a comment as to why we're using a retry approach please (i.e. a very edge-case). I would hate for a test author to see it and consider it good practice
[23:08] <Saviq> veebers, sure, doing
[23:08] <Saviq> veebers, if we later come up with a better metric of "it's ready" than looking whether the home scope is focused, we might be fine
[23:09] <Saviq> veebers, especially when we split the greeter out
[23:09] <veebers> Saviq: good point. Could you then also file a bug (stating the AP test is using a retry because of: blah) and reference that in the comment
[23:10] <veebers> Means we can keep track of these hacks/workarounds and fix them when we can
[23:10] <Saviq> veebers, +1
[23:14] <mzanetti> Saviq: If this is still the issue where the greeter gets stuck half way through swiping I suspect there is acutally something else.
[23:15] <Saviq> mzanetti, no, that's not it
[23:15] <Saviq> mzanetti, or at least we don't know what it is
[23:15] <Saviq> mzanetti, we'd have to look at the devices under test
[23:15] <mzanetti> Saviq: I debugged this a while back when we had this on the VMs still
[23:16] <mhall119> kgunn: we only get 2 hours or sleep?
[23:16] <mzanetti> Saviq: and no matter what I tried it (in terms of delaying, retrying etc) did not make any difference
[23:16] <Saviq> mzanetti, let's see, then, if retrying helps
[23:16] <Saviq> mzanetti, if it doesn't, we'll investigate more
[23:17] <Saviq> mzanetti, asking for a camera pointing at the devices
[23:17] <Saviq> mzanetti, https://code.launchpad.net/~sil2100/unity-scopes-shell/revert_25/+merge/198595 btw :(
[23:17] <mzanetti> Saviq: also the fact that the video was showing the greeter just being stuck at the position where autopilot would release the gesture, and not bouncing either left or right made me think there is something really stuck
[23:17] <Saviq> mzanetti, fortunately https://code.launchpad.net/~saviq/unity-scopes-shell/fixed-click-launch/+merge/198626
[23:18] <veebers> Saviq: oh, I had presumed that you had already tested and this solved the issue ;-) perhaps it could be an input being ignored issue? I think there is a bug + workaround for something similar already
[23:18] <Saviq> veebers, guess what - not reproducible locally ;)
[23:18] <veebers> Saviq: oh, the best kind of bugs ^_^
[23:18] <Saviq> veebers, this at least will give us more output
[23:19] <mzanetti> Saviq: so I'm confused, there was this revert and then you submitted it again?
[23:19] <veebers> Saviq: ack, makes sense to me. We can always remove it if it doesn't work or makes things worse
[23:19] <Saviq> mzanetti, baseName vs. completeBaseName
[23:19] <Saviq> mzanetti, clicks have dots in their desktop file names
[23:19] <Saviq> mzanetti, so we ended up sending "com" in the signal
[23:19] <mzanetti> awww meen
[23:19] <mzanetti> sorry :/
[23:20] <Saviq> mzanetti, what's worse, run_on_device didn't show that happening for me initially
[23:21] <Saviq> mzanetti, possible due to left-over Unity plugin being there in shell/builddir
[23:21] <Saviq> mzanetti, so even when testing, that could've masked the issue for you guys
[23:21] <Saviq> mzanetti, so yeah, lack of tests bit us here
[23:22] <Saviq> veebers, pushed
[23:24] <dmo> Hello.  I cannot seem to add or remove items from the launcher.  Right-clicking on an icon and selecting 'Unlock from launcher' does nothing.  Also, when I drag an icon to the launcher, it won't dock.  Any ideas?
[23:24] <veebers> Saviq: awesome, have bottom approved
[23:24] <Saviq> dmo, that's under unity7?
[23:24] <Saviq> dmo, as in desktop Ubuntu?
[23:25] <dmo> Ubuntu desktop 13.10
[23:25] <Saviq> dmo, can you please file a bug using `apport-bug unity`?
[23:27] <Saviq> veebers, will you top-approve once jenkins says "aah whatever, do whatever you want" aka "PASSED"?
[23:28] <Saviq> of course.. bad whitespace..
[23:28] <dmo> I'm not familiar with apport-bug-unity.  Would you give me more information?
[23:28] <dmo> What's strange is this used to work for me.
[23:29] <Saviq> dmo, alt+f2, write "apport-bug unity" and follow the instructions
[23:32] <Saviq> ok, it's time i/
[23:33] <Saviq> \o
[23:33] <Saviq> ttyl
[23:34] <Saviq> ah mzanetti one last thing - even more symbols http://paste.ubuntu.com/6557929/
[23:35] <Saviq> and we're off  \o
[23:36] <dmo> Sending of the report failed, probably due to the company's firewall.  Do I need to do anything special to get around this?