[07:20] <tsdgeos> Saviq: i was busy with code reviews on thu/fri and have a bunch of stuff on the approved pipeline, do you think we can get a silo today? Otherwise stuff is going to end up conflicting etc
[07:29] <mhr3> Saviq, btw why did you decide against a devel branch?
[07:42] <Saviq> tsdgeos, sure, will try and get it in today
[07:42] <tsdgeos> :)
[07:43] <tsdgeos> Saviq: btw any clue what's wrong with otto?
[07:43] <Saviq> tsdgeos, nope, will talk to ci eng
[07:43] <Saviq> mhr3, because didrocks told us they don't want us to have them, I don't like what it does to the history, I didn't see all that much advantage
[07:44] <mhr3> fewer conflicts?
[07:44] <Saviq> mhr3, also, suddenly it's difficult to cherry-pick into trunk, because all the branches have some of devel in them already
[07:44] <mhr3> and noone likes those :)
[07:45] <Saviq> mhr3, we've been doing fine with those - you just need to release often, and we've been doing fine
[07:45] <mhr3> but yea, perhaps it wouldn't work that great for you
[07:45] <tsdgeos> yeah i think we're doing mostly fine
[07:45] <tsdgeos> and most of the conflicts we end up with are "easy" to solve anyway
[08:16] <tsdgeos> Saviq: it does affect all the tests, but there's no other benchmarks so it doesn't :D
[08:16] <tsdgeos> but yeah need to pass that as variable since we'lk possibly have slower/faster benchmarks in the future
[08:16] <tsdgeos> and a hardcoded value is not going to fly there
[08:21] <Saviq> tsdgeos, k
[08:22] <tsdgeos> Saviq: so when thinking about that list of "things that are upstreamable to SDK", well there's stuff like the whole Card/Previews stuff that personally I don't think they make sense there but they may be upstreamable if designers want to replicate the Dash layouting on some app
[08:23] <Saviq> tsdgeos, yeah, agreed, low prio for upstreaming, though
[08:23] <tsdgeos> so makes it even sense to write it there or?
[08:24] <Saviq> tsdgeos, yeah, add them as "if you want them" or something
[08:24] <tsdgeos> ok
[08:24]  * tsdgeos restarts again then :D
[08:26] <tsdgeos> Saviq: i think https://code.launchpad.net/~macslow/unity8/fix-notification-ap-test-assertions/+merge/212169 is included in https://code.launchpad.net/~macslow/unity8/modal-snap-decisions/+merge/210988 so it should either be discarded or them redone with dependencies or somethimg, no?
[08:27] <tsdgeos> MacSlow: ↑↑↑
[08:27] <Saviq> tsdgeos, doesn't look included, there's more changes in the first branch
[08:28] <Saviq> tsdgeos, but yeah, need to be reconciled
[08:28] <tsdgeos> ah right, they're similar changes but not exactly the same
[08:28] <tsdgeos> sorries
[08:28] <Saviq> don't be, better safe'n'sorry
[08:32] <tsdgeos> karni: no, predictive text is now disabled :D
[08:33] <karni> tsdgeos: hahaah thanks
[08:33] <karni> I thought this was a bad joke
[08:49] <Saviq> tsdgeos, so one thing changed with run-upstart, Alt+F4 or clicking on the window X just results in unity8 respawning...
[08:50] <tsdgeos> trueth
[08:50] <Saviq> tsdgeos, not *sure* that's a problem, though, or how to change that behaviour
[08:50] <Saviq> or that we want to
[08:51] <Saviq> nah, ok, we'll just have to let people know
[08:51] <tsdgeos> not an upstart expert enough to know how to fix that
[08:51] <tsdgeos> but honestly give run is "for us" and that it improves quite a bit the behaviour when run on the phone
[08:51] <tsdgeos> i'll take that over the lock button crashing it on the phone
[08:51] <Saviq> tsdgeos, well, it does improve on desktop, too, e.g. the scope list
[08:51] <Saviq> tsdgeos, +1
[08:55] <Saviq> /food
[09:14] <tsdgeos> guys, an easy one https://code.launchpad.net/~aacid/unity8/remove_acws/+merge/215624
[09:25] <tsdgeos> Cimi: https://code.launchpad.net/~aacid/unity8/carousel_test_base_delegate/+merge/215626
[09:25] <Cimi> tsdgeos, I did not write that test :D
[09:26] <tsdgeos> Cimi: i know you didn't, i'm asking you to review the change
[09:26] <Cimi> ah ok
[09:27] <MacSlow> tsdgeos, I'm fixing the issues between lp:~macslow/unity8/modal-snap-decisions and lp:~macslow/unity8/fix-notification-ap-test-assertions
[09:28] <Cimi> seb128, a review would be nice https://code.launchpad.net/~unity-team/ubuntu-system-settings/wizard.wifi/+merge/212675
[09:28] <Cimi> seb128, when you or your guys have time
[09:29] <seb128> Cimi, sure, not likely to be this week with the lts release
[09:29] <seb128> but it's on my backlog
[09:31] <Cimi> Saviq, greyback I used InputFilterArea in the wizard, I dinamically put blockInput true/false when the notification shows or not, but when it turns false (so should not block input anymore), my interface does not receive any events in any case. What could it be?
[09:32] <MacSlow> tsdgeos, there's one line from lp:~macslow/unity8/fix-notification-ap-test-assertions which slipped into lp:~macslow/unity8/modal-snap-decisions
[09:33] <greyback> Cimi: when you run the wizard (unity-mir compiled with debug mode too), do you see  "Shell depth" message printed?
[09:33] <greyback> Cimi: or a "Default depth" message
[09:33] <tsdgeos> MacSlow: i see, so leave it like that or?
[09:34] <Cimi> greyback, I did see it when I compiled with debug
[09:34] <MacSlow> tsdgeos, no no... I remove the rogue line so they'll cleanly merge
[09:34] <tsdgeos> ok
[09:35] <greyback> Cimi: certain? As if that message ("Shell depth") is not printed, then InputAreas won't work.
[09:36] <greyback> Cimi: as internally in unity-mir, it tried to guess which surface is the shell's surface, so it can place input filter areas on it. If the guess fails, no input to shell/wizard
[09:36] <MacSlow> tsdgeos, fix pushed
[09:37] <Cimi> greyback, it does work
[09:38] <Cimi> greyback, but when I switch blockInput to false
[09:38] <Cimi> greyback, it feels like it's still true
[09:40] <greyback> Cimi: ah I see what's happening. With unity-mir, the shell/wizard surface will *always* get input. What inputFilterAreas do is decide if the input should *also* go to the app surface underneath or not.
[09:40] <MacSlow> tsdgeos, so now the rogue line is gone form https://code.launchpad.net/~macslow/unity8/modal-snap-decisions/+merge/210988
[09:40] <tsdgeos> oki
[09:40] <greyback> Cimi: reason is that shell always wants to listen for edge swipes, even if app on screen. So in that case, an input event goes to *both* shell and the application.
[09:41] <greyback> Cimi: but naturally there are times that shell wants to exclusively take all events, and not let them be copied to the application. That is what Inputareas let shell do
[09:46] <Cimi> greyback, I don't understand why setting it back to false
[09:46] <Cimi> greyback, still my shell doesn't get events
[09:47] <greyback> Cimi: Your shell should always get events. Can you share your code please?
[09:47] <Cimi> greyback, https://code.launchpad.net/~unity-team/ubuntu-system-settings/wizard.wifi/+merge/212675
[09:49] <Cimi> greyback, http://bazaar.launchpad.net/~unity-team/ubuntu-system-settings/wizard.wifi/view/head:/wizard/qml/main.qml
[09:51] <greyback> Cimi: can you please pastebin me the output of your wizard when you run it?
[09:51] <greyback> Cimi: also, without any input areas in the code, does your wizard get input?
[09:51] <Cimi> greyback, yopu want me unity mir with debug?
[09:51] <Cimi> greyback, of course
[09:51] <greyback> Cimi: yes
[09:51] <Cimi> greyback, works with blockInput: false
[09:51] <Cimi> too
[09:52] <Cimi> greyback, but not with blockInput: height > 0 or other combo
[10:03] <Saviq> MacSlow, what issues?
[10:04] <tsdgeos> Saviq: the fact that they conflict
[10:04] <Saviq> tsdgeos, they don't?
[10:04] <tsdgeos> Saviq: there was one change from one in the other, he's removed one line from a that was in b by mistake
[10:05] <Saviq> hmm there was no conflict, though...
[10:05] <Saviq> anyway, let me rebuild the landing, then...
[10:05] <tsdgeos> interesting
[10:06] <tsdgeos> maybe they had been merged originally and bzr just said "sure this is the same change, carry on"
[10:06] <Saviq> probably
[10:08] <MacSlow> Saviq, there was a line from lp:~macslow/unity8/fix-notification-ap-test-assertions somehow in lp:~macslow/unity8/modal-snap-decisions
[10:09] <Saviq> MacSlow, ok got it
[10:09] <MacSlow> Saviq, no idea how it slipped in there
[10:09] <MacSlow> Saviq, sorted it out now
[10:15] <Saviq> MacSlow, please strip the tags of your branches, as per my email from last week
[10:21] <MacSlow> Saviq, didn't we once wipe all those already?
[10:21] <mhr3> Saviq, anything in unity actually linking to libunity-api?
[10:21] <Saviq> MacSlow, apparently not everyone
[10:21] <Saviq> mhr3, no
[10:22] <Saviq> MacSlow, so we're all contaminated again
[10:22] <mhr3> thx
[10:22] <tsdgeos> Saviq: kill ScopeDelegateMapper, can I?
[10:23] <Saviq> tsdgeos, no, we still have DashApps?
[10:23] <Saviq> tsdgeos, or well, if you move the func up, then yeah
[10:24] <tsdgeos> Saviq: yeah but what it does i can make it in place, not in an item people will get tempted to add stuff to
[10:24] <Saviq> tsdgeos, sure
[10:40] <MacSlow> Saviq, since it's very slow to wipe the tags of remote branches, I'm doing it on lp:~macslow/unity8/fix-notification-ap-test-assertions and lp:~macslow/unity8/modal-snap-decisions only... as these are ready to land... I'll check other unity8-branches later
[10:40] <Saviq> MacSlow, yeah, it's rather slow remotely, thanks
[10:41] <MacSlow> Saviq, thought I could do it locally and then push, but forgot that any tag-change doesn't count as a commit so it would not push anything afterwards.
[10:42] <Saviq> MacSlow, indeed
[10:42] <MacSlow> Saviq, I wonder if that's worth a feature-request :)
[10:42] <MacSlow> but then... one does not do such things frequently enough to justify something like this
[10:42] <Saviq> MacSlow, bzr is in maint-only mode, and I really doubt it's easy to do... tags are just completely disconnected from commits in bzr...
[10:54] <Cimi> greyback, http://paste.ubuntu.com/7249077/
[10:56] <greyback> Cimi: okay, nothing looks wrong.
[10:56] <greyback> Cimi: let me try compiling your code and give it a go
[10:57] <Cimi> greyback, want packages?
[10:57] <Cimi> I have them built
[10:57] <greyback> Cimi: nah, will do myself, thanks tho
[10:57] <Cimi> greyback, you need unity mir
[10:57] <Cimi> greyback, wizard wifi
[10:58] <Cimi> (uncomment the inputfilterarea and copy the upstart job)
[10:58] <Cimi> greyback, and you need unity8 branch too (or just update the upstart file from my branch)
[10:59] <Saviq> Cimi, tsdgeos, elopio, please have a look at your approved MPs and clear the tags as mentioned in the comment
[10:59] <Saviq> (and then all of them, local or remote, as per my email last week)
[10:59] <greyback> Cimi: ok. Gimme a while to get set up
[10:59] <Cimi> Saviq, why we have tags again?
[10:59] <Saviq> Cimi, because someone didn't clear them before
[11:00] <Saviq> Cimi, and they're rather viral
[11:00] <Cimi> Saviq, when did you send this mail?
[11:00] <Cimi> and where?
[11:00] <Cimi> I cannot find it
[11:00] <Saviq> Cimi, last week, on unitynextuiteam ML
[11:01] <Cimi> weird I don't have it
[11:02] <Cimi> Saviq, last mail I have is from daniel "a bit away from computer today"
[11:02] <MacSlow> Saviq, tags cleaned
[11:02] <Saviq> MacSlow, thanks
[11:03] <Saviq> Cimi, "Pruning unity8 branches and tags" is the subject
[11:03] <Saviq> Cimi, ah wait
[11:03] <MacSlow> Saviq, I know check other unity8-branches I have... just to be sure nothing slips in again
[11:03] <Saviq> Cimi, it's probably still in moderation...
[11:03] <Cimi> Saviq, AH OK..
[11:03] <Cimi> ok
[11:09]  * tsdgeos looks at the positionedAtBeginning signal in DashContent
[11:09] <tsdgeos> and realizes we're using it as a function
[11:09] <tsdgeos> :S
[11:55] <Malsasa> Hello. My HUD on Ubuntu 12.04 doesn't work anymore. When I tap ALT, Unity opens menu of focused app, not the HUD. My complete question was in http://askubuntu.com/questions/447587/alt-key-for-hud-doesnt-work. I am sorry for my bad English. Thank you.
[12:24] <Cimi> Saviq, after deleting, shall I push or commit?
[12:24] <Saviq> Cimi, no, tags don't go with revisions, if you ran through them, they're deleted
[12:34] <Cimi> greyback, any luck?
[12:35] <greyback> Cimi: not ready yet, sorry
[12:41] <Malsasa> greyback: Hello. My HUD on Ubuntu 12.04 doesn't work anymore. When I tap ALT, Unity opens menu of focused app, not the HUD. Any idea for me? Thank you.
[12:42] <greyback> Malsasa: open System Settings, open "Keyboard", and in the new window, click the "Shortcuts" tab
[12:43] <Malsasa> greyback: I have did it many times. My complete quesion was here http://askubuntu.com/questions/447587/alt-key-for-hud-doesnt-work
[12:44] <Saviq> MacSlow, hey, can you look into bug #1307489 please?
[12:44] <MacSlow> Saviq, ok
[12:44] <greyback> Malsasa: huh, that's strange. Have you playe around in "ccsm" at all? Keys are also set in there, for hte Unity plugin
[12:45] <Saviq> MacSlow, ideally, would be good to get a reproducer without having to send an sms every time, can we make it somehow with the script as used in ap tests?
[12:45] <greyback> Malsasa: I see "Jos" replied with the same idea as mine. Give it a go
[12:45] <Malsasa> greyback: yes, I believe only I have this problem. It is very strange. I have play around CCSM too. I have set ALT there too.
[12:45] <MacSlow> Saviq, yup
[12:45] <MacSlow> Saviq, I see what I can do there
[12:45] <greyback> Malsasa: otherwise I'll have to point you to #ubuntu-desktop where there's more of the unity7 devs available
[12:46] <Saviq> MacSlow, I suspect this is actually happening on the "starting / focusing an app" front, but would like to have a confirmation
[12:46] <Malsasa> wow, so the developers are there? Thank you for pointing me, Mr greyback.
[12:46] <greyback> Malsasa: good luck!
[12:47] <MacSlow> Saviq, I'll make sure to see if the action attached t othe interactive notification is correctly called to rule out any issues with notifications
[12:47] <Malsasa> greyback: thank you from Indonesia!
[12:52] <tsdgeos> Saviq: all tags killed
[12:52] <Saviq> tsdgeos, cheers
[13:39] <greyback> Cimi: ok, so this /might/ be a mir bug. I've managed to launch the wizard and it gets no input events - didn't matter if I had an InputFilterArea or not.
[13:39] <greyback> Cimi: this is mainly after a fresh boot.
[13:40] <greyback> Cimi: one way to check is to set "MIR_SERVER_INPUT_REPORT=log" <- this turns on Mir's input debug printing
[14:00] <Cimi> greyback, so why I reproduce it with the inputfilterarea?
[14:04] <greyback> Cimi: I can't say. I don't see how your use of unity-mir would cause any different behaviour to unity8 tbh.
[14:05] <Cimi> tedg, hi, who is responsible for location indicator?
[14:06] <tedg> Cimi, me or charles
[14:06] <greyback> Cimi: if you could log a bug against unity-mir (to start), with exact instructions on how to reproduce it (clear enough for the mir folks to reproduce), we can have them look into it
[14:06] <tedg> Cimi, It has a pretty big MR pending though.
[14:07] <tsdgeos> Saviq: the ScopeDelegateMapper removal got a bit out of hand https://code.launchpad.net/~aacid/unity8/DashContentScopeDelegateMapperAndMiscFixes/+merge/215664 :D
[14:07] <tsdgeos> but it's now better!
[14:09] <Cimi> Saviq, ok wizard is pretty much ready but pending reviews... any big thing I can work next?
[14:11] <tsdgeos> Cimi: the review i gave you this morning :P
[14:11] <Cimi> tsdgeos, ok
[14:12] <MacSlow> Has anybody seen this happen to their N4 after updating to r294 -> https://www.youtube.com/watch?v=jE1aYjEC7EU somehow it does no longer mount (even adb fails to find the device)
[14:13] <tsdgeos> MacSlow: do you dual boot or something?
[14:13] <tsdgeos> there was a thread about it in the list
[14:13] <tsdgeos> if you do
[14:13] <MacSlow> tsdgeos, no... just plain Ubuntu nothing else
[14:14] <MacSlow> tsdgeos, remember the subject or part of it?
[14:14] <Saviq> MacSlow, I'm getting a test failure with the modal branch... I think mterry's greeter-ux-fixes might be playing with yours http://pastebin.ubuntu.com/7249940/
[14:14] <tsdgeos> #292 Mako
[14:14] <tsdgeos> but it was only dual boot
[14:14] <Saviq> MacSlow, ugh... I only had that with android...
[14:15] <MacSlow> Saviq, first I need to get my N4 working again...
[14:15] <Saviq> MacSlow, I'm afraid the only way I found is to flash factory android https://developers.google.com/android/nexus/images#occam
[14:15] <MacSlow> tsdgeos, thx... I'll read through it
[14:15] <Saviq> MacSlow, and flash ubuntu again
[14:15] <mterry> Saviq, MacSlow: I can look at the interactions between our branches
[14:16] <MacSlow> mterry, thx... that would be cool
[14:16] <MacSlow> Saviq, hm.. ok
[14:16] <Saviq> mterry, you can branch from http://people.canonical.com/~didrocks/citrain/silos/landing-001/unity8/
[14:17] <Cimi> tedg, I have this page for the wizard, but the location doesn't seem to do anything... can you spot the error? http://bazaar.launchpad.net/~cimi/ubuntu-system-settings/wizard.privacy/view/head:/wizard/qml/Pages/30-phone-settings.qml
[14:17] <MacSlow> Saviq, tsdgeos: well it does boot alright... I just can't seem to get any connection via USB/adb
[14:18] <tedg> Cimi, Yeah, the branches really need for it to land before anything works. There's a bunch of platform API stuff that needs to get in.
[14:18] <Cimi> tedg, eta?
[14:18] <Saviq> MacSlow, I suspect it's reconnecting every 5s or so, I had that (on dual-booted android, though)
[14:19] <MacSlow> Saviq, never setup my N4 to dual boot
[14:19] <tedg> Cimi, It's now our oldest pending MR, at just under 3 months. Hopefully soon :-)
[14:19] <MacSlow> Saviq, I'll flash android and reflash ubuntu... just anything to get it working agin
[14:19] <Saviq> MacSlow, yeah, quickest route I'd say
[14:21] <MacSlow> Saviq, no more factory images for "mako"?!
[14:21] <Saviq> MacSlow, it was never "mako"
[14:21] <Saviq> MacSlow, occam
[14:22] <Saviq> MacSlow, mako is device codename, occam is image codename or so
[14:23] <MacSlow> Saviq, so which of those factory images was the one with the broken networking/phone-driver
[14:23] <Saviq> MacSlow, that's old news
[14:23] <MacSlow> Saviq, no longer an issue?!
[14:24] <Saviq> MacSlow, nope, not since we switched to android 4.4.2
[14:24] <MacSlow> I ran into it so :)
[14:24] <MacSlow> ok
[14:26] <tsdgeos> Saviq: what's your opinion on removing the ifdefs for building with old qt 5.0?
[14:27] <Saviq> tsdgeos, let's wait a bit to have a golden image with 5.2
[14:27] <tsdgeos> ok
[14:41] <dednick> Saviq: what are "spurious tags"
[14:41] <Saviq> dednick, we inherited tags from lp:unity back when
[14:41] <dednick> Saviq: um, where would these show up?
[14:42] <Saviq> dednick, 'bzr tags'
[14:42] <Saviq> dednick, you'll see a lot of tags with ? as their revision number
[14:42] <dednick> Saviq: i do indeed...
[14:43] <Saviq> dednick, so yeah, http://people.canonical.com/~msawicz/unity8/strip-u8-tags.sh clears them up
[14:58] <mzanetti> Saviq: I'll drop this, ok? https://code.launchpad.net/~unity-team/unity8/split-surfaces
[14:58] <Saviq> mzanetti, yeah, let's see
[14:58] <mzanetti> we're not doing it this way any more anyways I think
[15:00] <Saviq> mterry, there's one more thing that's not good with the ux fixes - when left-swiping to dash, there's a vertical shadow that's dragging behind the app (and behind finger if there's no app at all)
[15:01] <mterry> Saviq, oh really...  Will investigate
[15:01] <Saviq> mterry, check out the packages from silo 001
[15:01] <Saviq> they exhibit that
[15:03] <Saviq> MacSlow, assign yourself to bug #1307489 please
[15:10] <MacSlow> Saviq, done...
[15:11] <MacSlow> Saviq, btw... even with only Android 4.4.2 on the N4 I get this forest of nautilus windows popping up
[15:11] <Saviq> MacSlow, aah fook wait
[15:11] <Saviq> MacSlow, reboot your host...
[15:11] <Saviq> MacSlow, I think that's what fixed it for me...
[15:12] <MacSlow> hm...
[15:12] <MacSlow> ok...
[15:12] <Saviq> MacSlow, sorry for sending you on a wild goose chase..
[15:12] <MacSlow> back in a moment...
[15:18]  * MacSlow got scared by that reboot...
[15:18] <MacSlow> my screen was all messed up... had to do a second reboot to sort that out....
[15:19] <MacSlow> I hope there are no nasty surprises gfx-driver-wise
[15:20] <mterry> Saviq, OK, trailing shadow fixed in greeter-ux-fixes branch
[15:21] <MacSlow> Saviq, those nautilus-windows are still popping up
[15:21] <Saviq> MacSlow, ouch
[15:21] <Saviq> MacSlow, tried a different cable?
[15:21] <MacSlow> Saviq, it's not as bad... but still some
[15:21] <MacSlow> Saviq, can try
[15:23] <Saviq> MacSlow, I've narrowed the bug down to u8's/unity-mir focusing code, so you're off the hook
[15:23] <MacSlow> Saviq, although I'm not expecting that cable (or usb-port) to be an issue as I also used with with a Nexus5 without any problems
[15:24] <Saviq> mzanetti, I'll throw this one at you, then: bug #1307489
[15:24] <MacSlow> Saviq, regarding the tap or the modal-snap-decision/greeter issue?
[15:24] <Saviq> MacSlow, ↑
[15:24] <mzanetti> Saviq: sure you can. I might dodge tho :P
[15:24] <MacSlow> Saviq, ah ok... thanks for the update
[15:24] <Saviq> mzanetti, you can try!
[15:24] <mzanetti> :D
[15:24] <MacSlow> Saviq, mterry: so I guess I can help out with the ap-failure then?
[15:25] <Saviq> MacSlow, the "conflict" between mterry's and your branch (modal snaps) is still to be looked at, yeah
[15:25] <MacSlow> Saviq, that's what I mean
[15:25] <MacSlow> t
[15:25] <mterry> MacSlow, looking at it, yeah
[15:26] <mterry> MacSlow, so I can reproduce for sure
[15:26] <MacSlow> mterry, I've not had your branches available when writing tests... so I might have overlooked something
[15:27] <mterry> MacSlow, OK, I see the problem
[15:27] <mterry> MacSlow, in my branch, swiping the launcher from left unlocks device and hides launcher
[15:27] <mterry> MacSlow, but your branch is expecting launcher to remain open
[15:28] <mterry> (as it does in trunk)
[15:29] <mterry> MacSlow, but you seem to use the shown status of the launcher as a key part of that test
[15:29] <MacSlow> mterry, yes
[15:29] <olli> alecu, Saviq, greyback in U8, do we cache the reading of *.desktop files
[15:29] <mterry> MacSlow, maybe you could test shown status of the greeter instead?
[15:29] <olli> i.e. if I change a file in a running session, will the change be in effect
[15:29] <olli> or do I need to restart u8
[15:30] <olli> sorry, this is for U8/preview 14.04
[15:30] <Saviq> olli, the change will show up in the dash the next time you search, will be stuck in launcher until you restart, though
[15:30] <MacSlow> mterry, well I need to verify (when the greeter is open) that interaction with it/launcher is possible ... nothing is blocking user-input.
[15:31] <MacSlow> mterry, an test interacting with the infographics would do too
[15:31] <mterry> MacSlow, right.  Do the same thing, but instead of testing that the launcher is visible, just test that the greeter becomes hidden
[15:31] <olli> Saviq, more specifically, if I edit a single .desktop file (add exec/-qt5) will u8 pick that up?
[15:31] <Saviq> MacSlow, please rebase on mterry's branch and verify the modal behaviour is correct?
[15:31] <Saviq> olli, when launching you mean? that should work every time, the file is read on-exec, not earlier than that
[15:31] <Saviq> olli, since it's not actually us but upstart-app-launch reading it, btw
[15:32] <MacSlow> mterry, what's your branch again
[15:32] <Saviq> MacSlow, https://code.launchpad.net/~mterry/unity8/greeter-ux-fixes/+merge/210042
[15:32] <mterry> MacSlow, instead of self.main_window.get_launcher() do self.main_window.get_greeter() -- will test myself too
[15:34] <olli> Saviq, thx
[15:34] <MacSlow> mterry, Saviq: first I need to figure out what's up with all the usb/adb issues I have all of a sudden...
[15:37] <mterry> MacSlow, well replacing those two lines with the following works for me
[15:37] <mterry>         greeter = self.main_window.get_greeter()
[15:37] <mterry>         self.assertThat(greeter.shown, Eventually(Equals(False)))
[15:39] <mhr3> tsdgeos, something's broken with carousel, if there's more than two categories in a scope scrolling all the way down and then up results in the carousel to be completely empty
[15:39] <mhr3> known?
[15:40] <mhr3> tsdgeos, well.. might be lvwph + carousel
[15:40] <mterry> MacSlow, or maybe what you want is to just not pull the launcher so far
[15:40] <mterry> MacSlow, just pull it out but not enough to trigger an unlock
[15:41] <tsdgeos> mhr3: not known
[15:41] <mhr3> tsdgeos, do you have bunch on your device?
[15:41] <Saviq> mhr3, tsdgeos, assuming your lvwph thing landed?
[15:41] <tsdgeos> mhr3: how do i get more than one carousel?
[15:41] <mhr3> tsdgeos, eh.. bunch of music...
[15:42] <MacSlow> mterry, again... I just need some check to verify that the input-blocking modal-background (behind the snap-decisioins) isn't used when the greeter is shown
[15:42] <mterry> MacSlow, ok, so unlocking is fine
[15:42] <mhr3> tsdgeos, grab the deb from 015
[15:42] <tsdgeos> Saviq: it did land, i sincerely hope that is not causing it
[15:43] <tsdgeos> mhr3: let me check a test i have here
[15:43] <tsdgeos> first
[15:43] <mhr3> Saviq, tsdgeos, my image isn't completely fresh
[15:43] <mhr3> from this morning
[15:43] <Saviq> mhr3, good enough
[15:43] <mhr3> Saviq, as in official 294
[15:44] <tsdgeos> damn
[15:44] <tsdgeos> ASSERT: "QTest::TestLoggers::loggerCount() != 0" in file qtestlog.cpp, line 242
[15:44] <tsdgeos> mzanetti: when doing tryXYZ
[15:44] <tsdgeos> any idea?
[15:44] <mzanetti> tsdgeos: yes
[15:45] <mzanetti> tsdgeos: you can workaround it by addint "when: windowShown" to all TestCases
[15:45] <mzanetti> tsdgeos: or reorder them to make sure the first one in the file has that
[15:45] <Saviq> mhr3, tsdgeos, confirmed, carousel does not get recreated properly when it's culled
[15:45] <mzanetti> tsdgeos: fixing that would require subclassing QAbstractTestLogger from qttest-private which I haven't done yet
[15:46] <Saviq> mhr3, tsdgeos, well - it seems to work the second time...
[15:46] <mhr3> Saviq, yea, it's pretty random
[15:46] <Saviq> indeed
[15:46] <Saviq> mhr3, file a bug please
[15:46] <tsdgeos> wooo
[15:46] <tsdgeos> something broke there yes
[15:46] <mhr3> Saviq, k
[15:47] <tsdgeos> and it's probably the originY thing :/
[15:47] <Saviq> :|
[15:47] <Saviq> :\
[15:47] <Saviq> :/
[15:48] <tsdgeos> i mean, what else can it be?
[15:49] <Saviq> well, yeah, sounds relevant
[15:49] <Saviq> OTOH we never destroyed carousels before, did we
[15:50] <mhr3> tsdgeos, Saviq, https://bugs.launchpad.net/unity8/+bug/1307578
[15:50] <tsdgeos> we shouldn't
[15:50] <tsdgeos> i'll have a look tomorrow first thing
[15:51] <MacSlow> mterry, so I'll go with this http://pastebin.ubuntu.com/7250338 in test_modal_sd_with_greeter()... no more checks for the launcher
[15:51] <mterry> MacSlow, that worked for me, yeah
[15:52] <MacSlow> mterry, the test_modal_sd_without_greeter() I don't need to change I assume
[15:52] <mterry> MacSlow, correct
[15:53] <tsdgeos> mzanetti: https://code.launchpad.net/~aacid/unity8/whenGSVtest/+merge/215695
[15:54] <mzanetti> tsdgeos: I was still discussing with Saviq if we should go for this or do the efforts of registering the testlogger. tryLauncher suffers from the same, and probably more
[15:54] <mzanetti> Saviq: did you come to any conclusion? ^
[15:54] <MacSlow> mterry, pushed r774 to lp:~macslow/unity8/modal-snap-decisions so we should be all good now
[15:54] <Saviq> mzanetti, I think if we can avoid it for now - let's
[15:54] <mzanetti> ack.
[15:55] <mterry> Saviq, so MacSlow updated his branch for the test and I updated mine for the shadow.  Should be good to go on both
[15:55] <Saviq> mterry, k, rebuilding now and will test again later
[15:58] <Saviq> o/ ttyt
[15:59] <Cimi> tsdgeos, shall I review this? https://code.launchpad.net/~aacid/unity8/DashContentScopeDelegateMapperAndMiscFixes/+merge/215664
[16:00] <tsdgeos> Cimi: if you have time, please
[16:00] <Cimi> ok
[16:03] <tsdgeos> tomorrow more
[16:03]  * tsdgeos waves
[16:07] <kgunn> Saviq: just to make sure ...so lp:~macslow/unity8/modal-snap-decisions & lp:~mterry/unity8/greeter-ux-fixes corrects... bug 1307489
[16:08] <mterry> ?  let me see
[16:09] <kgunn> mterry: is that "?" for me ?...i was piecing together scrollback, i could be totally wrong
[16:10] <mterry> kgunn, was for you.  Looks like a dup of bug 1267624 which has had a branch extent for a long time, but has been stalled
[16:11] <mterry> kgunn, seems test framework won't let us easily test locking the screen by simulating power button presses -- because the test framework holds a powerd lock
[16:11] <kgunn> mterry: ah...thank you, yeah that does look the same
[16:12] <MacSlow> kgunn, mterry's and my branch are not related to 1307489
[16:12] <kgunn> thanks guys
[16:13] <kgunn> MacSlow: do agree that 1267624 is a dup of 1307489  <- Saviq
[16:15] <mterry> kgunn, so point is I'm looking at it, but it's not there yet.  I'll see if I can do a test workaround today
[16:16] <MacSlow> kgunn, not sure
[16:20] <kgunn> mterry: ok, its the "new blocker"...its==1307489
[16:21] <mterry> kgunn, promotion blocker?  oh my
[16:21] <kgunn> yes, don't go to vegas :)
[16:58] <josharenson> mzanetti: regarding https://bugs.launchpad.net/unity8/+bug/1305885 is the networking setup actually a component/plugin for unity8, or is it a separate application? I looked over the code a lot on my flight home, but can't seem to find where it would live.
[17:00] <mzanetti> josharenson: yeah, the actual networking is in the indicators. However, the issue is in the ui I'd say, which should be in qml/Notifications/
[17:43]  * greyback eod
[18:39] <asac> https://launchpad.net/bugs/1307634
[18:40] <asac> rickspencer reported that (wasnt related to shutdown he thinks)
[18:40] <asac> anyone mind checking if that .crash file is any good?
[18:50] <asac> Saviq: kgunn: i know you are runnin on hot fumes already, but could we motivate someoene from your team to take a look at https://launchpad.net/bugs/1307634 ?
[19:58] <Saviq> kgunn, yeah, seem the same
[20:03] <Saviq> mterry, https://code.launchpad.net/~mterry/unity8/hide-greeter-on-focus-request/+merge/215749/comments/512044
[20:03] <Saviq> wth does apport not collect package versions and such when it's processing a crash....
[20:04] <mterry> Saviq, working on it as we speak
[20:04] <Saviq> mterry, kk
[20:04] <mterry> Saviq, just wanted to get elopio's merge in first
[20:04] <Saviq> asac, I'll look briefly into it, but will probably have to wait until tomorrow for proper investigation
[20:04] <mterry> Saviq, I'm planning to expose a tiny dbus interface for pretending we got a powerd event that we only expose if testability is on.  sound good?
[20:05] <Saviq> mterry, on one hand - yeah maybe - on the other... I think it's a bug in powerd that it doesn't change the power state
[20:05] <Saviq> mterry, especially when it does turn the display off...
[20:06] <mterry> Saviq, true...  I forgot it turned display off.  Does seem like inconsistent internal state
[20:07]  * mterry looks at why powerd does that
[20:15] <Saviq> mterry, inconsistent, and wrong, IMO, too - even if an app requests display to be on, it should be overridden by power key press
[20:23] <asac> Saviq: ack. thanks
[21:21] <mterry> kgunn, poke about bug 1307489.  https://code.launchpad.net/~mterry/unity8/hide-greeter-on-focus-request/+merge/215749 should fix, but note that it needs two other component branches to work totally.  Maybe start a silo for it?  <- Saviq
[21:21] <mterry> I have to go afk for a bit, but will leave IRC on
[21:22] <Saviq> mterry, I'll be pushing it through tomorrow, thanks!
[21:22] <kgunn> mterry: thanks...
[21:22] <kgunn> Saviq: o/ thanks!
[21:24] <kgunn> mterry: quick one...what other 2 component branches are needed ?
[21:25] <mterry> kgunn, it's in the description
[21:25] <mterry> kgunn,
[21:25] <mterry>   https://code.launchpad.net/~mterry/autopilot/allow-focus/+merge/215735
[21:25] <mterry>   https://code.launchpad.net/~mterry/powerd/consistent-state/+merge/215761
[21:25] <kgunn> mterry: i should've read...thanks man
[21:26] <thomi_> mterry: I commented on that MP. I plan on running the full test suite later today
[21:26] <mterry> kgunn, those two are only needed to make autopilot work right.  If you do manual testing, just the one branch is fine
[21:26] <thomi_> mterry: but right now I'm not sure we can land anything anyway
[21:26] <kgunn> thomi_: its a blocker
[21:26] <kgunn> so its special
[21:27] <thomi_> hmm, so will the unity 8 team handle the autopilot MP landing?
[21:28] <thomi_> kgunn: because if so, then as long as you guys run the AP test plan, I'm happy for that to land
[21:28] <kgunn> thomi_: well, i would believe yes, it would all need to go into the same silo
[21:29] <kgunn> thomi_: link to AP test plan ?
[21:30] <thomi_> one sec
[21:30] <kgunn> thomi_: kinda curious if it matches this...https://wiki.ubuntu.com/Touch/Testing#Testing_your_Ubuntu_Touch_Code_before_submission
[21:30] <thomi_> kgunn: https://wiki.ubuntu.com/Process/Merges/TestPlan/autopilot
[21:31] <kgunn> thomi_: ok...that doesn't seem too bad...
[21:31] <thomi_> kgunn: hahaaaaaa
[21:31] <thomi_> kgunn: it takes about 4 hours to run, and then about the same to debug the various failures
[21:31] <thomi_> kgunn: what I'm saying is "have fun with that" :)
[21:31]  * kgunn wonders if we've created an anti-release tool
[21:32] <thomi_> kgunn: you're still wondering? :P
[21:32] <thomi_> kgunn: we have a jenkins job that automates 90% of it though
[21:33] <thomi_> kgunn: http://q-jenkins:8080/job/autopilot-release-gatekeeper/
[21:33] <kgunn> thomi_: should that be on the wiki ?
[21:33] <thomi_> kgunn: run that ^ with the silo PPA in the PPA parameter
[21:33] <thomi_> kgunn: probable, let me edit it
[21:33] <kgunn> i was just about to ask.... where instructions are for desktop
[21:33] <kgunn> "Run the autopilot functional and unit tests"
[21:34] <kgunn> thomi_: desktop is the bitch i take it?
[21:34] <kgunn> in terms of time
[21:34] <thomi_> kgunn: nope, device is the PITA
[21:34] <thomi_> kgunn: desktop takes ~ 15 minutes
[21:34] <thomi_> device takes ~ 4 hours
[21:35] <kgunn> thomi_: no way..i run unity8 & browser all the time...it does eat close to an hour...but 4 ?
[21:35] <thomi_> kgunn: you need to run *all* the AP tests
[21:35] <thomi_> not just unity8
[21:35] <kgunn> ah
[21:35] <kgunn> not how i was reading :)
[21:35] <thomi_> because you're chaning AP code that's used by all the functional test suites
[21:36] <thomi_> luckily, the jenkins job does most of that for you
[21:36] <thomi_> you just need to wait for it to run
[21:36] <thomi_> but then you need to debug the various failures
[21:36] <thomi_> and figure out if they're due to an issue introduced in your code, or bad tests in other projects
[21:36] <thomi_> usually you need to re-run a few suites
[21:37] <kgunn> thomi_: since this is going to take soooo much time...should we just go to silo and test it there ?
[21:37] <kgunn> rather than individually for MP...
[21:37] <kgunn> only to approve and then turn around and do it again ?
[21:37] <kgunn> Saviq: fyi on this ^
[21:37] <thomi_> kgunn: yes, that's wht I'd suggest
[21:37] <thomi_> kgunn: wiki is updated BTW
[21:38] <kgunn> Saviq: mterry ...mind if i queue it up and try ?
[22:30] <mhall119> am I missing something, or has the ability to add scopes as a Favorite to the dash not been implemented yet?
[23:13] <mterry> kgunn, go right ahead!