[05:25] <Mirv> bregma: added https://bugs.launchpad.net/unity-scope-audacious/+bug/1229028 which blocks automatic testing of unity stack
[06:59]  * tsdgeos waves hello
[07:34] <tsdgeos> pstolowski: hi there, did you get that problem we had before I went into holidays fixed?
[07:35] <pstolowski> tsdgeos: hi! nope, it's waiting for you ;)
[07:35] <tsdgeos> damn! should have gotten a longer holiday :D
[07:35] <tsdgeos> j/k
[07:36] <tsdgeos> ok, will get into it after reading the ton of email
[07:39] <tsdgeos> bah, we do something really wrong with power management on the phones
[07:39] <tsdgeos> left the house with the Nexus4 turned off and full of baterry
[07:39] <tsdgeos> just to come back and it even doesn't react to charging
[07:47] <tsdgeos> oh my, and we shelved qt 5.1
[07:47] <tsdgeos> sigh
[07:57] <tsdgeos> larsu: ping
[07:57] <larsu> tsdgeos: good morning
[07:57] <tsdgeos> larsu: morning
[07:58] <tsdgeos> larsu: the mouse wheel on the volume thing still has some issues here, you aware of it?
[07:58] <larsu> no, what are those issues?
[07:58]  * larsu never uses that feature…
[07:59] <tsdgeos> middle mouse scroll once, then left click on the indicator
[07:59] <tsdgeos> takes like 4 seconds to draw
[07:59] <larsu> woah
[07:59] <larsu> not for me
[08:00] <larsu> this is on saucy I presume?
[08:00] <tsdgeos> yep
[08:00] <larsu> is it only after freshly logging in or does it happen all the time?
[08:01] <tsdgeos> all the time
[08:01] <tsdgeos> i guess it may also be the reason that mouse wheeling doesn't seem as it would work
[08:01] <tsdgeos> since it only changes volume like once each 4 seconds
[08:01] <tsdgeos> i can't really mousewhell and notice an immediate change in volume
[08:01] <larsu> ya I definitely don't have this
[08:01] <tsdgeos> :-/
[08:02] <larsu> can you execute `dbus-monitor destination=com.canonical.indicator.sound` while you do this
[08:02] <tsdgeos> oh lol
[08:02] <larsu> do the messages appear after the 4 seconds or immediately when you scroll?
[08:03] <tsdgeos> they appear during 4 seconds
[08:03] <tsdgeos> kind of :D
[08:03] <tsdgeos> something fights between 0.392637 and 0.392624
[08:03] <tsdgeos> http://paste.ubuntu.com/6144572/
[08:05] <larsu> mind = blown
[08:05]  * larsu wonders what's going on there
[08:07] <larsu> tsdgeos: I assume `dbus-monitor sender=com.canonical.indicator.sound` is similar (with the difference that instead of SetState calls you see Changed signals)
[08:08] <tsdgeos> yep
[08:08] <tsdgeos> larsu: some float vs double or something?
[08:08] <larsu> might be
[08:08] <larsu> but it shouldn't even update the state in response to an update of the state
[08:09] <larsu> I'll look into it, thanks for bringing it up
[08:09] <larsu> if you want to make a bug, that would be superb ;)
[08:09] <larsu> (but not strictly necessary)
[08:10] <tsdgeos> larsu: against indicator sound?
[08:10] <larsu> tsdgeos: yes please
[08:22] <tsdgeos> larsu: https://bugs.launchpad.net/indicator-sound/+bug/1229076
[08:24] <larsu> tsdgeos: thanks! I'll try to look at it today or tomorrow
[08:25] <tsdgeos> thanks!
[09:01] <Saviq> paulliu, let me know if you need a hand with the music filter grid
[09:08] <paulliu> Saviq: ok.
[09:18] <Saviq> paulliu, should be as simple as fixing the "clicked" signal signature?
[09:30] <paulliu> Saviq: yeah.. I'm fixing it and testing it right now.
[09:31] <Saviq> paulliu, cool, thanks - Thomas is asking for an ETA in #ferrets
[09:40] <mzanetti> Saviq: can you have a quick look and tell me if you're happy with the direction it goes before I clean it up and add tests? https://code.launchpad.net/~mzanetti/unity8/switching-previews/+merge/186991
[09:45] <Saviq> mzanetti, looking good, but it's limited to a single category - can we make it not?
[09:45] <mzanetti> Saviq: uh... is that really wanted?
[09:45] <mzanetti> Saviq: I guess it should be possible
[09:45] <Saviq> mzanetti, yes, you're supposed to be able to just get through the whole scope
[09:46] <Saviq> mzanetti, what's the solution? same as for the calendar?
[09:46] <mzanetti> Saviq: right now I just put the category's model to the ListView, that's it
[09:47] <mzanetti> for including all... I'd need to try a bit
[09:47] <Saviq> mzanetti, yeah, I think we need to go with the "3-item ListView" that you add/remove items to
[09:47] <Saviq> /from
[09:47] <mzanetti> mhm...
[09:47] <Saviq> mzanetti, there's one more thing...
[09:48] <mzanetti> Saviq: should the contents still only be loaded once you actually switch to a preview or should it be cached for all 3?
[09:48] <Saviq> mzanetti, on demand
[09:48] <Saviq> mzanetti, the list view in the back needs to scroll to show you the currently previewed item
[09:48] <mzanetti> ok. then the solution for cancelling proposed by pstolowski still works... he proposed in auto cancelling a old request when a new one comes in
[09:49] <Saviq> yeah, that's fine
[09:49] <mzanetti> Saviq: scrolling with the current OpenEffect is an issue tho
[09:49] <Saviq> mzanetti, yeah, you need to enable: true it for the time
[09:49] <mzanetti> ah right... that might work
[09:49] <mzanetti> ok. will check it out
[09:49] <Saviq> thanks
[09:50] <Saviq> mzanetti, looking good, though, Oren will be happy :D
[09:50] <mzanetti> Saviq: one more thing: the design shows a little arrow pointing to the current item
[09:50] <mzanetti> any idea how to get that into the openeffect?
[09:50] <Saviq> mzanetti, let's leave that for later, I'd say
[09:50] <mzanetti> ack
[09:51] <Saviq> mzanetti, same with highlighting the previewed item
[09:51] <Saviq> mzanetti, that's sugar, where the actual feature is a big usability improvement
[09:51] <mzanetti> heh... missed that in the design so far
[09:51] <mzanetti> I fully agree
[10:17] <pstolowski> mzanetti: ping
[10:17] <mzanetti> pstolowski: hey man
[10:18] <pstolowski> mzanetti: hi! you don't have the nullptr check branch for Friday's crash, do you?
[10:19] <mzanetti> pstolowski: no, not really... as I said: when I wanted to actually implement it I realized that I'd really need to be able to reproduce in order to find out what else breaks if I take the DeeModel's sourceModel away
[10:20] <mzanetti> we might as well end up with a crash in some other line of code
[10:20] <pstolowski> mzanetti: yeah... so do you mind if I take it?
[10:20] <mzanetti> pstolowski: please do :)
[10:20] <pstolowski> mzanetti: not that I know precisely what to do about it :P
[10:21] <mzanetti> pstolowski: well, I'd say it'd be a good idea investigating into that if that returns the nullptr
[10:22] <mzanetti> seems like it should return an empty model instead of null
[10:30] <tsdgeos> mzanetti: Saviq: what's the phablet-flash command one has to run nowadays?
[10:30] <tsdgeos> phablet-flash  cdimage-touch --pending ?
[10:30] <Saviq> tsdgeos, actually no
[10:31] <popey> tsdgeos: depends if you want the read-only image or not
[10:31] <Saviq> phablet-flash ubuntu-system --channel devel-proposed
[10:31] <tsdgeos> Saviq: ta
[10:31] <popey> devel-proposed is a bit broken today
[10:31] <Saviq> tsdgeos, and then `adb touch /userdata/.writable_image; adb reboot`
[10:31] <popey> so might not be the best one to flash
[10:31] <mzanetti> Saviq: is apt-get able to install unity build deps on the ro image nowadays?
[10:32] <popey> might be better using  phablet-flash ubuntu-system --channel saucy
[10:32] <Saviq> popey, well, for development... it's probably good to get the latest, even if *a bit* broken?
[10:32] <Saviq> popey, how broken, btw?
[10:32] <popey> sure
[10:32] <popey> download-manager broken
[10:32] <popey> so you cant download click packages
[10:32] <Saviq> popey, k, we'll keep in mind, thanks
[10:32] <Saviq> mzanetti, not without rw-ing the image
[10:33] <mzanetti> Saviq: last time I tried I rw-ed the image and it still bailed out
[10:33] <Saviq> mzanetti, /me tries
[10:33] <mzanetti> Saviq: I think the place where dpkg stores its db is not large enough or something like that happened
[10:34] <Saviq> mzanetti, oh
[10:34] <greyback> stupid jetlag
[10:34] <greyback> hi guys!
[10:35] <mzanetti> greyback: hey man
[10:35] <greyback> mzanetti: hey, I need to catch up with you on the devdays stuff
[10:36] <mzanetti> greyback: yep
[10:36] <mzanetti> wanna do that now?
[10:37] <Saviq> popey, btw, "rm: cannot remove '/etc/init/ssh.override': Device or resource busy" any idea?
[10:38] <popey> why you doing that out of interest?
[10:39] <Saviq> popey, well, we probably shouldn't indeed
[10:40] <Saviq> popey, i.e. "initctl start ssh" is enough (we'll fix in our scripts)
[10:40] <Saviq> popey, but it's weird anyway
[10:40] <popey> and that's after making the fs rw?
[10:40] <popey> (and rebooting)
[10:45] <mzanetti> Saviq: hmm... I'd say run_on_device -s should still enable ssh permanently
[10:45] <tsdgeos> pstolowski: i commented in https://code.launchpad.net/~aacid/unity8/lvwph_update_section_header/+merge/183457
[10:45] <tsdgeos> pstolowski: isn't the testcase enough to convince you the fix is good?
[10:46] <Saviq> popey, yes
[10:46] <Saviq> mzanetti, I'd say it shouldn't - as long as it will start it with every run...
[10:47] <mzanetti> Saviq: hmm... ok... I've been abusing run_on_device -s to make the device usable for my general purpose (which includes enabling ssh)
[10:47] <Saviq> mzanetti, exactly ;)
[10:48] <Saviq> mzanetti, btw, you can edit /userdata/system-data/etc... instead of making it rw
[10:48] <Saviq> mzanetti, and that's possibly the correct way
[10:48] <mzanetti> Saviq: for enabling ssh?
[10:48] <Saviq> mzanetti, yeah
[10:48] <mzanetti> Saviq: no... you need to delete that .override file
[10:49] <mzanetti> Saviq: and the bind-mounted stuff doesn't allow that
[10:49] <Saviq> mzanetti, `echo "auto" > /userdata/system-data/etc/init/ssh.override`
[10:49] <Saviq> mzanetti, that should work
[10:49] <mzanetti> Saviq: doesn't do for me
[10:49] <mzanetti> Saviq: as long as that file is here (even if empty) ssh doesn't autostart here
[10:49] <mzanetti> not sure why, tho
[10:49] <pstolowski> tsdgeos: as I said, I'm ok to approve if you think it still makes sense
[10:49] <tsdgeos> pstolowski: i do
[10:50] <Saviq> popey, actually that might be the reason for the error - the file is also in /userdata/... (I assume overlaid?)
[10:50] <pstolowski> tsdgeos: ok
[10:51] <Saviq> mzanetti, anyway, run_on_device seems to work here
[10:51] <Saviq> we *do* need a -c option to at least remove unity8-build-deps from the device...
[10:52] <mzanetti> Saviq: yep. it does. except that it fails to install build-essentials. haven't looked into that yet
[10:52] <Saviq> mzanetti, installed fine here, it's building for me
[10:52] <mzanetti> Saviq: since a week or so I need to manually apt-get build-dep unity8. otherwise cmake wouldn't be installed after a fresh flash...
[10:52] <Saviq> mzanetti, yes - that's it
[10:53] <Saviq> mzanetti, drop the unity8-build-deps .deb
[10:53] <mzanetti> from where?
[10:53] <Saviq> mzanetti, it only installs it when it's older than debian/control
[10:53] <Saviq> mzanetti, from ~phablet/
[10:53] <Saviq> mzanetti, /me wanted to save generating / installing it every time
[10:53] <mzanetti> hmm... I'm pretty sure I had this also after flashing with -b
[10:54] <Saviq> mzanetti, /me doubts it
[10:54] <Saviq> but obviously that doesn't work out well
[10:54] <mzanetti> not 100% positive on it...
[11:15] <Saviq> mzanetti, noticed one more thing you should tackle while "crossing" the category boundary
[11:16] <Saviq> mzanetti, it shouldn't be possible to go "out" of the filtered model
[11:16] <mzanetti> Saviq: yeah... I'm kinda struggling with that currently
[11:16] <mzanetti> Saviq: as in the ScopeView I don't even have access to all those models
[11:17] <Saviq> mzanetti, we might need to expose them
[11:18] <Saviq> tsdgeos, here's a bug "spawned" out of the other one https://bugs.launchpad.net/unity8/+bug/1229144
[11:20] <tsdgeos> Saviq: i see
[11:21] <mzanetti> Saviq: what I find a bit weird is that apparently model.results in the delegate gives a *model. but calling data(index, "results") gives a string
[11:21] <Saviq> mzanetti, is data() invokable?
[11:21] <mzanetti> yeah
[11:22] <mhr3> mzanetti, did you try get() instead?
[11:22] <mzanetti> mhr3: there is no get() in QSortFilterProxyModelQml
[11:23] <mzanetti> and I'm afraid there can't be
[11:23] <mhr3> mzanetti, why are you getting sortfiltermodel?
[11:23] <mhr3> is that the count>0 wrapper thing?
[11:23] <mzanetti> mhr3: scopeview.categories
[11:24] <mhr3> mzanetti, that returns DeeListModel
[11:24] <mhr3> s
[11:24] <mzanetti> print("...........................finding model", categoryView.model)
[11:24] <mzanetti> ...........................finding model QSortFilterProxyModelQML(0x1db4470)
[11:24] <mzanetti> ...........................finding model QSortFilterProxyModelQML(0x1db4470)
[11:24] <mzanetti> damn copy/paste
[11:27] <mhr3> mzanetti, scopeView.categories is SortFilterModel scopeView.scope.categories should give you access to the DeeListModels
[11:30] <mzanetti> mhr3: ah... that gives me a object with "count" 0
[11:32] <mhr3> mzanetti, what exactly are you doing?
[11:32] <mzanetti> mhr3: in onPressAndHold I get the model and the index of the pressed item
[11:33] <mzanetti> mhr3: but the thing is, the Preview must be able to walk over all categories
[11:33] <mzanetti> mhr3: so I need to find out which model this is (if there are any other models before and after this)
[11:33] <mhr3> you mean rows in the model
[11:35] <mzanetti> mhr3: if you look from the ScopeListView POV yes, if you look at it from the FilterGrid POV not, in that case its really other models before/after this model
[11:35] <mzanetti> but in the onPressAndHold handler I've only got data from the FilterGrid POV
[11:37] <mhr3> mzanetti, you have the delegateItem.model, isn't that enough?
[11:38] <mzanetti> mhr3: no... that only points to the model for this category
[11:38] <mzanetti> but I need all categories
[11:39] <mhr3> mzanetti, wasn't the previewing supposed to work only within a category?
[11:39] <mzanetti> mhr3: not any more since Saviq is back :P
[11:39] <mzanetti> mhr3: no... I think design wants it to include the whole scope
[11:39] <Saviq> mhr3, is that the case for unity7?
[11:40] <Saviq> mhr3, mzanetti ok, looks like we need clarification from design
[11:40] <mhr3> Saviq, yes
[11:40]  * Saviq always assumed it's "global"
[11:40] <mhr3> Saviq, moreover it'd be terribly complex, imagine you cross to a completely different renderer
[11:40] <mzanetti> from a code POV I think including all categories seems like a major headache right now.
[11:40] <mhr3> indeed
[11:41] <Saviq> mhr3, different renderer doesn't matter - we're not "replacing" the model for the current renderer
[11:41] <mzanetti> from a usability POV... not sure... I personally think crossing categories might be confusing... but not entirely sure
[11:41] <Saviq> mhr3, even if you mean different *category* renderer, doesn't really pose much more headaches
[11:42]  * Saviq asks Oren
[11:42] <mhr3> Saviq, yes i meant category renderer
[11:42] <mzanetti> ack
[11:42] <mhr3> going from previewing grid to carousel
[11:43] <mhr3> i can see the transition to make it nice really complex
[11:43] <Saviq> mhr3, doesn't feel more complex than enabling preview in the carousel itself
[11:43] <mhr3> hmm, perhaps
[11:44] <Saviq> mhr3, the view behind the preview would just scroll, and then we'd need to scroll the carousel to show the entry in question
[11:44] <mhr3> anyway, crossing categories seems silly :P
[11:44] <Saviq> maybe, /me assumed it'd work :)
[11:44] <mzanetti> immagine you swipe through the list of available apps and suddenly you end up in dash plugins.
[11:44] <Saviq> especially since it's not like you can expect all the previews in a category to be of the  same type
[11:44] <mzanetti> exactly, yeah
[11:45] <mzanetti> bbiab
[12:06] <mzanetti> Saviq: already got an answer from Oren?
[12:09] <Saviq> mzanetti, no
[12:09] <Saviq> mzanetti, he's in a meeting
[12:10] <mzanetti> ok
[12:10] <Saviq> mzanetti, btw, as part of it, you could improve the situation on bug #1224555
[12:11] <Saviq> mzanetti, re: header, at least
[12:11] <mzanetti> Saviq: afaik paulliu is working on that
[12:11] <mzanetti> paulliu: are you?
[12:13] <paulliu> mzanetti: yeah..
[12:13] <mzanetti> Saviq: ^
[12:13] <Saviq> paulliu, can you please update the above bug?
[12:14] <Saviq> assign yourself and such
[12:14] <paulliu> sure.
[12:19] <Saviq> mzanetti, mhr3 Oren confirmed - stop on category boundary
[12:19] <mzanetti> Saviq: nice
[12:19] <mhr3> good, that should actually be doable :)
[12:20] <mzanetti> Saviq: so I'll clean this mess up and propose for merging
[12:20] <mzanetti> mhr3: yeah, its actually done already
[12:37] <Saviq> ok, our autolanding doesn't work
[12:37] <Saviq> fginther, help ;(
[12:37] <Saviq> fginther, http://s-jenkins:8080/job/unity8-autolanding/
[12:38] <Saviq> fginther, the three landings of unity8 today failed in the same exact way - gallery apps tests failed on phones
[12:40] <pstolowski> Saviq: hey, with today's trunk I'm getting qml errors about 'Hud' type; what do I miss?
[12:40] <Saviq> pstolowski, what error exactly?
[12:40] <Saviq> right... so under otto it fails 'cause we're not killing notify-osd
[12:40] <Saviq> mzanetti, remember ↑?
[12:40] <mzanetti> Saviq: yeah...
[12:40] <Saviq> mzanetti, what did we decide re: notify-osd vs. our own notification interface?
[12:41] <mzanetti> Saviq: export `dbus-launch`
[12:41] <Saviq> mzanetti, and why didn't we do that yet?
[12:41] <mzanetti> Saviq: actually I had hoped to do this in the autopilot stuff itself. but that doesn't work
[12:41] <Saviq> mzanetti, thing is, I'm afraid if the whole shell is run under a "new" dbus
[12:41] <mzanetti> Saviq: because the pythong notify libs are being loaded before the ctor is called. so they load the env var before we have a chance to change it
[12:42]  * mzanetti really wonders why he can't type python without a g at the end
[12:42] <Saviq> mzanetti, that might be even worse - whatever is run in the session won't be available
[12:42] <pstolowski> Saviq: ah, nvm, it's actually Nick's filter-selector branch, trunk runs fine
[12:42] <Saviq> pstolowski, for that you probably need a newer UITK
[12:42] <Saviq> pstolowski, or even Nic's branch, for that matter
[12:42] <pstolowski> Saviq: yeah
[12:42] <Saviq> pstolowski, it's linked on Nic's MR
[12:43] <mzanetti> Saviq: what do you mean with that? what would be running what's not available?
[12:43] <Saviq> mzanetti, if stuff isn't dbus-activated, but upstart-managed
[12:43] <Saviq> mzanetti, if we run the whole suite under a new dbus
[12:43] <Saviq> mzanetti, we won't get those
[12:43] <mzanetti> yeah... might cause issues. I agree
[12:44] <Saviq> we really should have an "empty" session
[12:44] <mzanetti> or better: it might hide issues we have
[12:44] <Saviq> without unity7
[12:44] <mzanetti> +1
[12:44] <mzanetti> that's what we did in the vms so far
[12:44] <mzanetti> I had unity7 shut down and only started a plain X
[12:44] <Saviq> fginther, didrocks, can we have otto run unity8 tests without unity7?
[12:45] <Saviq> we can work around issues - like we did until now - but their amount will grow and cause us carrying cruft :/
[12:47] <Saviq> pete-woods, https://code.launchpad.net/~pete-woods/libusermetrics/color-themes-gconf/+merge/186770/comments/426459
[12:47] <Saviq> pete-woods, let's continue the discussion here, if we need to, latency on MRs is too big ;)
[12:48] <pete-woods> Saviq: relocatable schema sounds good to me
[12:48] <pete-woods> Saviq: is this supported by stuff like dconf-editor?
[12:48] <Saviq> pete-woods, sure
[12:49] <Saviq> pete-woods, a relocatable schema is just one that doesn't have a default path associated with it
[12:49] <Saviq> pete-woods, so you need to explicitly point it at some place - and there can be multiple of those
[12:49] <pete-woods> Saviq: okay, then we just have a fixed schema in some place with a string list of the theme "names"?
[12:50] <Saviq> pete-woods, shouldn't even be needed
[12:50] <Saviq> pete-woods, as long as we put all of them under a known path
[12:50] <pete-woods> Saviq: how do I iterate over them?
[12:50] <Saviq> so all of the objects under /somewhere/themes/ would be those
[12:50] <Saviq> pete-woods, you just ls /somewhere/themes/ and assume all of theme are that
[12:51] <pete-woods> Saviq: is there some "children of node X" type method in the Qt QPI?
[12:51] <Saviq> pete-woods, of sorts
[12:51] <Saviq> pete-woods, dunno, larsu, around?
[12:53] <larsu> Saviq: yep
[12:53] <Saviq> larsu, so, we need multiple sets of values for "infographic palettes"
[12:53] <Saviq> larsu, so that would be palette1/foreground palette1/background etc.
[12:54] <Saviq> larsu, would relocatable dconf schemas be a good way to store those in dconf?
[12:54] <Saviq> larsu, question no. 2 - to iterate over those, should they just all be stored under a common path, so, say /com/canonical/infographic/palettes/{palette1,palette2} etc.?
[12:55] <Saviq> and if so, do we need a *list* of those paths stored somewhere, or would iterating over /com/canonical/infographic/palettes/'s children be enough
[12:56] <larsu> Saviq: definitely a question for desrt, not me
[12:56] <larsu> let's move this to #ubuntu-desktop :)
[12:56] <Saviq> larsu, and, would we have APIs for that in the Qt gsettings APIs?
[12:56] <Saviq> larsu, k
[12:56] <larsu> Saviq: we don't have APIs like that in gsettings-qt, but I can certainly add it
[12:57] <Saviq> larsu, k, let's see what desrt says
[12:59] <Saviq> pete-woods, join #ubuntu-desktop please?
[13:02] <tsdgeos> Saviq: do you have some kind of repro steps for https://bugs.launchpad.net/unity8/+bug/1225391 ?
[13:02] <tsdgeos> i can't repro it here
[13:03] <Saviq> tsdgeos, well, yeah, search, clear, search, clear, search, clear...
[13:03]  * Saviq tries
[13:04] <Saviq> tsdgeos, right, can't repro
[13:04] <Saviq> mhr3, can you ↑?
[13:04]  * Saviq flashes maguro
[13:05] <tsdgeos> errrr
[13:05] <tsdgeos> how am i supposed to stop a search?
[13:06] <tsdgeos> i.e. hide the search bar
[13:07] <tsdgeos> hmmm
[13:08] <tsdgeos> we aren't resizing the shell when the OSK shows so i can't see some stuff without hiding the OSK
[13:08] <tsdgeos> :/
[13:08] <Saviq> tsdgeos, it's "persistent"
[13:09] <Saviq> tsdgeos, so if it happens, you can scroll down to see
[13:09] <Saviq> tsdgeos, bug #1213034
[13:09] <Saviq> huh? how is that fix committed?
[13:10] <tsdgeos> exactly my question :D
[13:11] <tsdgeos> not being able to dismiss it is a pain
[13:11] <tsdgeos> since i can't see everything easily
[13:12] <Saviq> tsdgeos, yeah, it's a regression
[13:14] <tsdgeos> and that's where we need an autopilot test :-)
[13:14]  * tsdgeos hides
[13:15] <Saviq> tsdgeos, not ap, qml test is enough
[13:16] <Saviq> tsdgeos, and completely +1
[13:16] <tsdgeos> Saviq: autopilot to test the OSK is not really there, no?
[13:16] <Saviq> tsdgeos, that shouldn't be a test in unity8, though
[13:16] <Saviq> tsdgeos, it should be tested with the SDK - we should just make sure our text field is unfocused
[13:16] <tsdgeos> true
[13:17] <tsdgeos> i'm lost now
[13:18] <Saviq> fginther, didrocks, please help ;(
[13:18] <tsdgeos> did https://code.launchpad.net/~aacid/unity8/lvwph_update_section_header/+merge/183457 failed to merge because some tests in the gallery fail?
[13:18] <Saviq> tsdgeos, right
[13:18] <tsdgeos> why?
[13:18] <didrocks> Saviq: I don't know how we can do it (and in hangouts about Mir TBH)
[13:18] <Saviq> tsdgeos, that's something you missed - we're running *some* tests across the board
[13:18] <Saviq> tsdgeos, so as to test if something doesn't break something else
[13:19] <fginther> Saviq, sorry, I'm trying to catch up now.
[13:19] <Saviq> tsdgeos, so, gallery with unity8, some other apps with UITK etc.
[13:19] <tsdgeos> so we never get anything merged because all our tests are unstable :D
[13:19] <Saviq> fginther, I can give you a summary
[13:19] <Saviq> tsdgeos, or theirs ;)
[13:19] <Saviq> fginther, our tests assume we're running in a clean session (no unity7 running)
[13:20] <Saviq> fginther, and while we could think of working around stuff
[13:20] <tsdgeos> so i just keep approving until magic happens?
[13:20] <Saviq> tsdgeos, nah, right now we have a different issue
[13:20] <tsdgeos> ook
[13:20] <Saviq> tsdgeos, 'cause we've moved from VM'ed tests to real hardware ones
[13:20] <Saviq> tsdgeos, which means we're under unity7, and that causes issues we need to tackle first
[13:20] <tsdgeos> i see
[13:20] <fginther> Saviq, ah, right
[13:21] <Saviq> fginther, we'll grow the number of workarounds unnecessarily, IMO
[13:22] <Saviq> to test in a non-real environment anyway, where unity8 runs in a unity7 session
[13:22] <fginther> Saviq, so we essentially need to kill unity7 first, right?
[13:22] <Saviq> fginther, not even that
[13:22] <Saviq> fginther, ideally we shouldn't start it at all
[13:22] <Saviq> fginther, i.e. start a unity8 session instead
[13:23] <fginther> Saviq, got it, the VM setup is coming back to me now
[13:23] <Saviq> fginther, otherwise we might end up hiding real issues
[13:23] <Saviq> fginther, case at hand - notify-osd is prestarted with unity7
[13:24] <Saviq> fginther, and while we could kill it so that unity8 takes the notifications over - doesn't sound like a correct solution
[13:24] <mhr3> tsdgeos, it's really hard to repro, just keep searching it will happen at some point
[13:24] <Saviq> fginther, we did think of running the tests under a separate dbus session, but again - that might cause some other things to fail, 'cause we *do* expect some other things to be pre-started
[13:25] <Saviq> or at least might
[13:25] <mhr3> tsdgeos, i just had it happen in the video scope
[13:25] <fginther> Saviq, I think I know how to fix this, but it might take most of the day. Do we need to fall back to the VMs to keep the testing moving?
[13:25] <Saviq> fginther, we can't merge anything currently, 'cause our mediumtests are failing
[13:25] <mhr3> tsdgeos, it seems to be more common when you expand a category
[13:25] <Saviq> fginther, if we can go back to VMs for the time being, that could be a solution for us indeed
[13:26] <fginther> Saviq, ack, will set that up first
[13:26] <Saviq> mhr3, ah! I think you hit the jack pot
[13:26] <Saviq> mhr3, tsdgeos: expand "More suggestions", search, reset search → "More suggestions" empty
[13:26] <tedg> greyback, Hey, so we had a conference call where the focused observers came up.
[13:27] <tedg> greyback, It was mentioned that the app guys might want to have separate wakeup and focus events going to the shell.
[13:27] <greyback> tedg: yes sorry I missed it, I was traveling
[13:27] <tedg> greyback, That way it'd be "wake up" -> "send url" -> "focus"
[13:27] <tedg> greyback, Yeah, no problem.
[13:27] <greyback> tedg: I don't follow. Can you give me an example?
[13:28] <tedg> greyback, We had Saviq track your movements... we knew exactly where you were.
[13:28] <Saviq> tsdgeos, uh oh, just managed to break the LVWPH again...
[13:28] <tedg> greyback, So on the case of an app that is in the background and it gets send a new URL to open.
[13:28]  * greyback looks around nervously
[13:28] <tsdgeos> Saviq: wops
[13:28] <Saviq> tsdgeos, expand "Installed", tap "SEARCH"
[13:28] <Saviq> tsdgeos, breakage
[13:28] <tedg> greyback, So then if it was paused, it would have to be unpaused before getitng the URL
[13:29] <tedg> greyback, And it'd be better if it could get the URL before being shown to the user.
[13:29] <Saviq> tsdgeos, but yeah, if an expanded category disappears
[13:29] <Saviq> tsdgeos, it doesn't come back
[13:29] <Saviq> mhr3, can you confirm ↑?
[13:29] <tedg> greyback, More concrete, opening a music file in the dash while the music player is open.
[13:29] <tedg> (but in the background)
[13:29] <tsdgeos> Saviq: can you tell me what are you searching exactly?
[13:29] <Saviq> tsdgeos, abc
[13:30] <tsdgeos> ok
[13:30] <Saviq> tsdgeos, so that "Installed" goes away
[13:30] <mhr3> Saviq, yep, expanding, searching and resetting seems to break it quite reliably
[13:30] <Saviq> \o/
[13:30]  * Saviq adds to the bug
[13:30] <greyback> tedg: sure. So if url is to be dispatched to a background app, the application manager needs to be notified which app should be woken up. Once app is woken, push the url to it, and then give it focus. Sound right?
[13:31] <tedg> greyback, Yup.
[13:31] <tedg> greyback, So do you want just two observers?
[13:31] <tedg> "freshen up" and "focus"
[13:31] <Saviq> Cimi, standup
[13:32] <tedg> "start the coffee" and "drink it"
[13:33] <greyback> tedg: am thinking. For case when app needs to be respawned, we need to know when app is ready to receive the url
[13:34] <tedg> greyback, We're good there already, we pass it on the command line.  And in the secondary activation case I handle that as well.
[13:34] <tedg> greyback, https://code.launchpad.net/~ted/upstart-app-launch/fdo-application-open/+merge/186887
[13:34] <tedg> greyback, That'll send a URL to a running app
[13:35] <greyback> tedg: to confirm: for the respawn case, upstart is respawning the app and passing the url on the cmd line?
[13:36] <tedg> greyback, Initial startup case, yes.  In the running case we're sending it via DBus.
[13:41] <greyback> tedg: okay. This gives me concern, as now 2 separate libs might respawn apps: the url launcher, or the app manager
[13:41] <Saviq> fginther, there's a good question: how did we ever get through daily release
[13:41] <Saviq> fginther, /me suspects gallery-app triggers notify-osd to launch, maybe...
[13:41] <tedg> greyback, No, what I'm saying is that I think we should put in an observer in libupstart-app-launch so that we can ask the app manager to do it.
[13:42] <tedg> greyback, So then the process will be "detect running" - "ask to wake up" - "send url" - "ask to focus"
[13:42] <tedg> greyback, Where the two asks are the app manager.
[13:42] <Saviq> fginther, so yeah, if you reverse the suites
[13:42] <Saviq> fginther, unity8 gallery_app - that might actually work :D
[13:42]  * Saviq tries
[13:44] <greyback> tedg: I need to step through the process, let me write it up somewhere
[13:45] <tedg> K
[13:45] <mzanetti> Saviq: did you progress with the issue that .desktop files are only found in /usr/share/applications?
[13:45] <Saviq> mzanetti, should be fixed now?
[13:45] <Saviq> mzanetti, do you have a way to make it fail still?
[13:45] <mzanetti> ok... today in the QA weekly veebers said he would require a fix for that in his app lifecycle autopilot tests
[13:46] <mzanetti> so I assumed it is still broken
[13:46] <mzanetti> I didn't test myself
[13:46] <Saviq> mzanetti, ok, will ping him later today
[13:57] <Saviq> fginther, fook yeah, instead of moving unity8 tests back onto VMs
[13:57] <Saviq> fginther, can you just reverse "gallery_app unity8" so that unity8 tests run first?
[13:57] <Saviq> fginther, as a quick workaround, that is?
[13:57] <fginther> Saviq, no problem, will give it a try
[13:58] <Saviq> fginther, that should fix mediumtests-saucy - mediumtests-touch are probably still failing - that might be your bigger issue
[14:00] <fginther> Saviq, it's switched now
[14:00] <fginther> Saviq, http://10.97.2.10:8080/job/unity8-autolanding/474/ is using the new order
[14:00] <Saviq> fginther, thanks, yeah I started it manually
[14:01] <Cimi> dednick, finished
[14:02] <dednick> Cimi: i'm back in mumble if you wan to talk?
[14:03] <greyback> tedg: http://sketchpad.cc/KNwZMfaosY
[14:03] <greyback> tedg: how right or wrong am I?
[14:03] <greyback> welcome to edit to fix my errors
[14:05] <greyback> tedg: case 1 & case 5 disagree greatly, that's problematic for me
[14:06] <tedg> greyback, So I guess I don't understand case 5, is there something different happening there outside the app?  I mean, shouldn't the app backend detect it has a saved state and resume it?
[14:07] <greyback> tedg: honestly, I can't answer that. Need to ask maybe Kaleo or ricmm that
[14:08] <tedg> greyback, Are you doing anything different?  :-)  You're not tracking the state of the app in that regard, right?
[14:08] <greyback> tedg: right now I just send a signal to the app to say "save state" and "resume state"
[14:09] <tedg> greyback, Do you mean SIGSTOP/CONT there?
[14:10] <tedg> greyback, Or actually give the serialized data?
[14:13] <greyback> tedg: right now via Mir we send lifecycle state signals "I'm suspending you" and "you've been resumed" to the app.
[14:13] <greyback> tedg: so if app looses focus, it gets "I'm suspending you" signal. 3 seconds later, process stopped with SIGSTOP.
[14:14] <greyback> if app gets focus later, process resumed with SIGCONT, and app sent signal "you've been resumed"
[14:14] <tedg> greyback, What happens if the app is shutdown.  Do you still send resume?
[14:14] <tedg> greyback, Or is resume assumed at init() ?
[14:17] <tedg> greyback, I made an alternative case 5
[14:18] <tedg> greyback_, I made an alternative case 5
[14:18] <greyback_> tedg: sorry I dropped out there
[14:19] <tedg> greyback_, NP
[14:20] <tedg> greyback_, I've edited up your sketchpad a bit
[14:20] <greyback_> tedg: great, that's what it's for :)
[14:21] <greyback_> tedg: we need to clarify if this is correct: "Application notices saved state files, initiates resume"
[14:22] <tedg> greyback_, Correct
[14:23] <greyback_> tedg: another thing that I'm concerned about is the command line argument stuff. When appManager respawns a process, it relaunches the process with the original command line arguments. But upstart won't know those
[14:23] <tedg> greyback_, I'm confused what you mean by "respawn"
[14:24] <tedg> greyback_, Please don't call "exec" anywhere in your code :-)
[14:24] <tedg> greyback_, That means we're not getting the environment and containment, which were the reasons we decided to use Upstart there.
[14:26] <greyback_> tedg: sure. So what if app1 launched with cmdline --one. App then switched away from and killed. Then app1 resumed with cmdline --two.
[14:26] <tedg> greyback_, We don't accept command line arguments, only those on the desktop file.
[14:27] <greyback_> tedg: if app loads its serialization file, will not that "--two" be overwritten?
[14:27] <tedg> greyback_, If they changed their desktop file?
[14:27] <greyback_> tedg: but you say the urldispatcher passes url via command line
[14:28] <greyback_> to apps which need to be launched
[14:29] <tedg> greyback_, yes, so if the desktop Exec line has a %u on it we'll fill that in with the URL.
[14:29] <tedg> greyback_, So I think the app management API has to handle that case.  Resume, and then emulate the "new URL" signal.
[14:32] <Cimi> mzanetti, I can you repeat me the commands for autopilot?
[14:32] <greyback_> tedg: using dbus to send it the new url? Like we'd do to an app that was running
[14:34] <tedg> greyback_, No, I'm saying that the App should do that.  In that there's a signal it sends when it gets a URL over DBus, it should internally generate the same signal.  We can't know whether, for instance, the resume was successful or not.
[14:34] <mzanetti> Cimi: yeah, "autopilot --help"
[14:34] <tedg> greyback_, The app may be treating it as a new start.
[14:34] <mzanetti> :P
[14:35] <Cimi> mzanetti, but there was an import?
[14:35] <mzanetti> import?
[14:36] <Saviq> fginther, success on mediumtests-saucy at least
[14:36] <Cimi> mzanetti, I need a test suite
[14:36] <fginther> Saviq, cool
[14:37] <Cimi> qah ok maybe
[14:37] <Cimi> snide the tests dir
[14:39] <davmor2> hey unity guys,  on initial boot of the phone, there is no wifi an no 3g till you get through the actual start guide, this means that the click apps and online scope prefs don't show.  Is there a way to autoupdate the scopes once there is an internet connection of some sort?
[14:39] <thostr_> greyback_: tedg: let's have a hangout with lool to conclude
[14:43] <Saviq> davmor2, we have a plan for this, but needs to be executed
[14:43] <mzanetti> Cimi: ah... now I get it... yes, inside tests/autopilot/
[14:43] <mzanetti> unless the test suite is installed into the system
[14:43] <Saviq> davmor2, the dash will monitor the network connection, and refresh online sources when connected
[14:44] <davmor2> Saviq: nice :)
[14:44] <davmor2> Saviq: is there a bug for that already that you are tracking on?
[14:44] <greyback_> tedg: that'll work if apps have logic to do that. But it feels wrong to me, as traditionally, command line arguments are fixed during the application runtime. I consider an app which saves its state, is killed, relaunches and restores its state, to be equivalent to an app which has not stopped at all.
[14:44] <Saviq> davmor2, but we need some support thingies for that in a few places
[14:44] <Saviq> davmor2, good question, mhr3, is there a bug for refreshing online scopes?
[14:45] <tedg> greyback_, To the app it should be, but we can't really handle that externally.
[14:45] <tedg> greyback_, So the lower levels of the SDK need to handle that.
[14:46] <Saviq> tedg, greyback_ about that... /me wonders if we should really actually use arguments to pass stuff around... since we still need DBus (or whatever) entry points for passing them to running apps, maybe we can think of a single entry point that will work for both?
[14:46] <Saviq> tedg, greyback_, i.e. when app starts, it would "ask" the app manager to feed it any outstanding actions
[14:47] <Saviq> when ready, that is
[14:47] <greyback_> tedg: let's find out who is doing the serialization work in the SDK and see what he/she thinks
[14:48] <tedg> greyback_, +1, do you know who that is?
[14:48] <tedg> Saviq, I'm not against that, but it seems like more work :-)
[14:49] <Cimi> mzanetti, WireProtocolVersionMismatch: Wire protocol mismatch at <session bus :1.143 /com/canonical/Autopilot/Introspection>: is 1.3, expecting 1.4
[14:49] <Cimi> }}}
[14:51] <Saviq> tedg, does it really? depends if we do still support actions through arguments
[14:51] <tedg> Saviq, I think we have to for non-SDK applications, no?
[14:51] <tedg> :q
[14:52] <Saviq> Cimi, you got autopilot 1.4 installed
[14:52] <Saviq> Cimi, drop ppa:autopilot, uninstall autopilot, reinstall
[14:52] <Saviq> tedg, I mean *in* the apps themselves
[14:52] <Saviq> tedg, not in app manager
[14:53] <tedg> Saviq, I think they do... Music app does.
[14:53] <Saviq> tedg, that's because we didn't tell them otherwise ;)
[14:54] <Saviq> tedg, and well, that's all fine and all, but once we start implementing the common actions API
[14:54] <Saviq> tedg, from launcher, from indicators, through urls...
[14:54] <Saviq> we need to support a DBus way of doing it
[14:55] <Saviq> anyway
[14:55] <Saviq> so supporting process arguments for those feels like more work
[14:56] <Saviq> sure, apps can still support *some* arguments, like passing URLs, for the non-Ubuntu / non-Unity / non-AppManager case
[15:02] <tedg> Saviq, Yes, this is URIs, not actions though in general.
[15:02] <mzanetti> Cimi: you're not up to date...
[15:03] <Saviq> tedg, k
[15:03] <Saviq> fginther, https://jenkins.qa.ubuntu.com/job/generic-mediumtests-touch/1364/?
[15:03] <mhr3> Saviq, davmor2, i don't recall one, feel free to open
[15:03] <mzanetti> Cimi: python-autopilot and libautopilot-qt need to be same version
[15:03] <Saviq> fginther, so that issue is still there :/
[15:03] <tedg> Saviq, The FD.o application interface has space for that, we're not at that point though.
[15:03] <Cimi> mzanetti, upgrading
[15:03] <Saviq> tedg, right, /me forgets about that all the time
[15:05] <fginther> Saviq, would a reboot between test suites help?
[15:05] <Saviq> fginther, no idea
[15:06] <Saviq> fginther, not sure what's happening there
[15:06] <Saviq> fginther, but all gallery app tests fail
[15:06] <davmor2> mhr3, Saviq: will do
[15:06] <mhr3> thx
[15:07] <fginther> Saviq, I'll give that a try, gallery-app tests aren't failing like that when run in isolation
[15:08] <Saviq> fginther, thanks
[15:17] <davmor2> mhr3, Saviq: https://bugs.launchpad.net/unity8/+bug/1229241
[15:18] <Saviq> thanks davmor2
[15:34] <ssweeny> mhr3, ping. another day another question :)
[15:35] <mhr3> ssweeny, same as mfisch's on #ubuntu-touch? :)
[15:36] <mfisch> its a new one I think ;)
[15:36] <ssweeny> mhr3, no actually, this is about having scopes in /custom not loaded
[15:36] <mhr3> ssweeny, oh?
[15:36] <ssweeny> mhr3, i thought it was related to mfisch's issue but i was mistaken
[15:37] <ssweeny> mhr3, yeah even with the latest -proposed i get the no key file error for my scopes
[15:37] <ssweeny> mhr3, they're in /custom/xdg/data/unity/scopes
[15:37] <pstolowski> mzanetti, mhr3 : here is a branch https://code.launchpad.net/~stolowski/unity8/results-nullptr-fix/+merge/187052 that should help with the crash on GetResultsForCategory, though I wasn't able to reproduce that situation.
[15:37] <mhr3> ssweeny, do you have those XDG_DATA_DIRS patches?
[15:37] <ssweeny> mhr3, i thought they'd landed
[15:38] <mzanetti> pstolowski: ok... so its not just me
[15:38] <mzanetti> thanks a bunch for the fix tho... I'll have a look
[15:38] <mhr3> ssweeny, i thought so too, but didn't check
[15:38] <mhr3> ssweeny, there should be upstart job that changes the envvar, do you see it somewhere?
[15:39] <ssweeny> mhr3, it's not in /etc/init
[15:39] <ssweeny> would it be in a session job?
[15:40] <mhr3> yes, it's a session job
[15:41] <ssweeny> mhr3, i have the custom-env.conf job
[15:41] <mhr3> ssweeny, it that the one that changes it?
[15:42] <ssweeny> mhr3, yeah it has this line initctl set-env XDG_DATA_DIRS="/custom/xdg/data:${XDG_DATA_DIRS:-/usr/share}"
[15:43] <mhr3> ssweeny, didn't lool say that it needs the --global --retain params?
[15:43] <ssweeny> mhr3, perhaps. i don't remember :/
[15:43] <kgunn> mterry: ping - hey can you bump the build dep for unity-system-compositor ? didrocks is going to try and land mir today for touch
[15:44] <mhr3> ssweeny, this is what his mail said
[15:44] <mhr3>         initctl set-env --retain --global XDG_DATA_DIRS=/custom/share:/usr/share/ubuntu:/usr/share/gnome:/usr/local/share/:/usr/share/
[15:45] <ssweeny> mhr3, ah, let me try that then
[15:45] <mhr3> although what you posted looks like a fixed version of this
[15:45] <mhr3> still, maybe it's missing those params
[15:46] <mterry> kgunn, does it need a bump or just a rebuild?
[15:46] <kgunn> didrocks: ^ ?
[15:46] <kgunn> mterry: i understand it would be a bump in the build dep control file
[15:46] <didrocks> mterry: bumping so that a rebuild is trigger (but it's just a rebuild in fact)
[15:46] <didrocks> but otherwise "nothing to release"
[15:50] <mterry> didrocks, are we going to 0.0.11 or shall I use 0.0.10+13.10.20130923-0ubuntu1 ?
[15:50] <didrocks> mterry: 0.0.11 sounds better
[15:52] <tsdgeos> Saviq: should category expansion live between searchs?
[15:52] <tsdgeos> or shall it be reset?
[15:52] <mterry> didrocks, https://code.launchpad.net/~mterry/unity-system-compositor/bump/+merge/187057
[15:53] <Saviq> tsdgeos, I *think* we made it to live through explicitly
[15:53] <tsdgeos> we did make it live
[15:53] <tsdgeos> but was for when you scrolled up and down
[15:53] <didrocks> mterry: approving, but I think we'll need latest Mir to be merged in first
[15:53] <tsdgeos> and the item was recreated
[15:53] <ssweeny> mhr3, i *thnk* adding those parameters fixed it
[15:53] <Saviq> tsdgeos, i.e. when you search, expand, and want to limit the search  even more
[15:53] <tsdgeos> Saviq: i did not think about searches
[15:53] <Saviq> tsdgeos, should not reset
[15:53] <ssweeny> mhr3, but i might be running into mfisch's issue now
[15:53] <tsdgeos> because the current code is probably wrong for searches
[15:53] <mterry> didrocks, yar, won't build without that
[15:54] <Saviq> tsdgeos, so yeah, I think it should live through
[15:54] <tsdgeos> ok
[15:54] <Saviq> tsdgeos, isn't there a "expanded" property on the Category object, even?
[15:54] <tsdgeos> i'll make it so that it stores something better than the index then
[15:54] <tsdgeos> like category name or something
[15:54] <Saviq> mhr3, how does unity7 handle that ↑↑?
[15:54] <asac> mzanetti: so thostr said you were able to reproduce and one of you is working on lp:1228097
[15:54] <tsdgeos> Saviq: is there?¿
[15:54] <asac> can you confirm and update the bug please?
[15:54] <mhr3> ssweeny, sorry, no known fix for that one, keep restarting, it's a race should work at some point
[15:55] <ssweeny> mhr3, got it. thanks for the help with my issue though :)
[15:55] <mhr3> Saviq, it doesn't destroy category renderers, just hide them
[15:56] <Saviq> mhr3, ah, interesting
[15:56] <Saviq> let's not do that :D
[15:56] <tsdgeos> so i need to store something better than the expandedIndex
[15:56] <tsdgeos> since it may happen that between searches the index of a given category changes
[15:56] <mhr3> tsdgeos, category id should be quite unique :)
[15:57] <mzanetti> asac: no. still not able to reproduce... but we have a blind fix :/
[15:57] <tsdgeos> mhr3: i'll store that then ;-)
[15:57] <asac> a blind fix?
[15:57] <asac> thostr said you were able to reproduce
[15:57] <asac> not sure now
[15:58] <asac> i will install daily-proposed and just run the unity8 autopilots
[15:58] <asac> if that crashes on maguro you owe me at least 5 whiskies in the hotel lobby
[15:58] <asac> :)
[15:58] <mhr3> uuh, that's an expensive crash
[16:00] <tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity8/bug1225391/+merge/187058 fixes the empty categories stuff
[16:00] <tsdgeos> i'm not ultra happy about *why* it does fix it
[16:00] <tsdgeos> but i guess we can go with it
[16:01] <kgunn> mzanetti: for SIM pin entry are we enabled ? or rather...what's needs to happen there for phone v1 ?
[16:02] <kgunn> mzanetti: remember, we didn't need to allow user to cancel
[16:02] <kgunn> mzanetti: forced pin entry on boot
[16:03] <mzanetti> kgunn: hmm... so we're still working on the proper solution. MacSlow was progressing with it.
[16:03] <mzanetti> Saviq: are you aware of what exactly the state is there?
[16:04] <kgunn> mzanetti: would it be loads of effort to cut to a simple forced entry ? (seems i recall not a lot of time)
[16:05] <pstolowski> mzanetti: do you have a branch that I could use to test preview-cancellation?
[16:05] <mzanetti> kgunn: no. that's still there in a branch and could be merged I guess.
[16:05] <kgunn> mzanetti: totally realize you'd prefer not to...but its got "favorite question" status
[16:05] <mzanetti> pstolowski: yes. give me a second to push
[16:05] <tsdgeos> mhr3: when you say "missing scope views" in https://bugs.launchpad.net/unity8/+bug/1229144 ?
[16:05] <mzanetti> kgunn: ack.
[16:05] <tsdgeos> mhr3: what's exactly missing?
[16:06]  * tsdgeos waves to kgunn, I'm back from holiday
[16:06] <kgunn> tsdgeos: welcome back sir!
[16:06] <kgunn> hope it was a good one
[16:07] <tsdgeos> it was indeed
[16:07] <mzanetti> pstolowski: lp:~mzanetti/unity8/switching-previews/
[16:08] <Saviq> kgunn, mzanetti it was almost ready for review on Friday
[16:08] <mzanetti> yeah... that's what I thought..
[16:08] <Saviq> kgunn, would be ready if MacSlow didn't break his stomach yesterday
[16:08] <mzanetti> ouch
[16:08] <kgunn> eeewww
[16:09] <pstolowski> mzanetti: thanks
[16:09] <kgunn> Saviq: are you opposed to landing a forceful pin entry in the meantime ?
[16:10] <Saviq> kgunn, kind of, yes... it's been waiting for some time already, what good will one more day do...
[16:10] <tsdgeos> Saviq: you seem to also repro https://bugs.launchpad.net/unity8/+bug/1229144  sometimes?
[16:10] <Saviq> tsdgeos, yeah, pretty often on desktop
[16:10] <Saviq> tsdgeos, just run, see if all your scopes are there, rinse, repeate
[16:10] <mzanetti> I see that on the phone too quite often
[16:10] <Saviq> -e
[16:12] <kgunn> Saviq: "what good will one more day do"....?...so are you arguing for or against landing a "forced pin entry"
[16:12] <Saviq> kgunn, against
[16:13] <kgunn> Saviq: ah.."what harm will one more day do"
[16:13] <Saviq> kgunn, that
[16:13] <Saviq> kgunn, no point in merging something half-baked, that will probably cause us other issues
[16:13] <tsdgeos> Saviq: ah, you mean the whole scope is missing?
[16:13] <Saviq> tsdgeos, yes
[16:13] <tsdgeos> i see
[16:13] <tsdgeos> ok, i'll check that tomorrow
[16:13] <tsdgeos> well not tomrrow
[16:14] <tsdgeos> since it's a holiday tomorrow
[16:14] <tsdgeos> i'll check on wednesday :D
[16:14] <Saviq> tsdgeos, slacker
[16:14]  * tsdgeos waves
[16:14] <mzanetti> :D
[16:14] <Saviq> o/
[16:14] <tsdgeos> Saviq: have to maintain the spaniard cliche
[16:14]  * mzanetti whishes germany hadn't wasted all the public holidays in June
[16:15] <Saviq> lol
[16:21] <mhr3> ssweeny, any luck with restarting?
[16:21] <ssweeny> mhr3, yeah, actually this may be coincidence but when i left out the --retain flag (but kept global) it seemed to work
[16:22] <mhr3> ssweeny, hm, yes i'd go with coincidence
[16:24] <kgunn> mterry: mind joining #ubtunu-mir ?
[16:24] <ssweeny> mhr3, you're probably right
[16:32] <Cimi> mzanetti, I added something like
[16:32] <Cimi>     def get_hud_edge_drag_area(self):
[16:32] <Cimi>         return self.app.select_single("EdgeDragArea", objectName="hudDragArea")
[16:32] <Cimi> mzanetti, but I am not able to get the property distanceThreshold
[16:33] <mhr3> ssweeny, actually --retain is:
[16:33] <mhr3>                      If  the  specified variable is already set, do not modify
[16:33] <mhr3>                      it.
[16:33] <mhr3> so definitely should *not* be there
[16:33] <mzanetti> Cimi: try to remove the "EdgeDragArea"
[16:34] <mhr3> ssweeny, also the get-env should have --global
[16:35] <ssweeny> mhr3, ok
[16:37] <Cimi> mzanetti, works… why^
[16:37] <Cimi> ?
[16:39] <mzanetti> Cimi: I think the classname is "DirectionalDragArea"
[16:39] <Cimi> ah ok
[16:39] <mzanetti> Cimi:  you need to give the C++ class type
[16:39] <Cimi> mzanetti, oh right, I see then
[16:39] <mzanetti> err, class name
[16:40] <mzanetti> Cimi: however, since autopilot 1.4 the class name is optional and only objectName is enough
[17:36] <kgunn> mterry: i heard you alreday know about lightdm/GN regress...so lightdm didn't make it into touch image ?
[17:36] <kgunn> just double checkin' you do actually know
[17:36] <mterry> kgunn, no...  apparently last Friday it wasn't tested on maguro after all, and now they are seeing crashes on maguro (vs just slowness reported before)
[17:36] <mterry> kgunn, cwayne has a maguro that he will help me remote-debug
[17:37] <kgunn> mterry: cool (...well...not cool but...you're on it :)
[17:39] <mterry> kgunn, seeing crashes at least makes sense compared to slowness.  They say they don't see it on rw images.  So probably just a directory that needs to be set to rw
[17:51] <om26er> mhr3, is there a .desktop file entry to hide an icon only on Ubuntu touch ?
[17:52] <mhr3> om26er, only desktop files with X-Ubuntu-Touch=true are shown
[17:52] <om26er> mhr3, ok
[21:20] <om26er> larsu, still up ?
[21:20] <larsu> om26er: ish
[21:20] <om26er> larsu, ok, i'll present you something simple :) bug 1229422
[21:21] <larsu> om26er: ah, thanks for filing that. I'll take care of it tomorrow
[21:21] <om26er> larsu, coolio
[21:31] <kgunn> mterry: any joy on lightdm for GN ?
[21:33] <mterry> kgunn, cwayne and I are chewing through it.  Best I have so far is that logind is refusing PAM's request to create a session for the user, which means /run/user/$UID is not created, which leads to unpleasantness
[21:33] <kgunn> mterry: there's a lot of unpleasantness going round :)
[21:33] <mterry> kgunn, why logind is refusing is an ongoing investigation.  I'm going into office tomorrow for access to a maguro for further debugging as needed
[22:55] <shiznix> anyone know what's happening with unity-lens-music ?
[22:56] <shiznix> it hasn't been able to build since libunity updates some months ago
[22:56] <shiznix> or is it in the process of being integrated into smart-scopes ?