[00:09] <Wellark> Saviq: actually I could not sleep so I did some digging: https://bugs.launchpad.net/indicator-network/+bug/1380736/comments/8
[01:00] <jhodapp> Saviq, yeah I remember that
[07:34] <Saviq> tsdgeos, can you please look at bug #1381255 please, it looks as if the implicit height fix maybe broke this
[07:36] <tsdgeos> Saviq: sure
[07:36] <tsdgeos> i was going to after deleting the rest of email
[07:36] <Saviq> we seem to have an abstain party on dednick's branch....
[07:37] <dednick> Saviq: sigh...
[07:37] <dednick> Saviq: still about 13 reviewers left ;)
[07:38] <dednick> Saviq: working on a couple of bugs with dissapearing indicators (bluetooth on  flightmode)
[07:39] <Saviq> dednick, kt
[07:39] <Saviq> x
[07:45] <MacSlow> Saviq, I didn't manage yet to sort out the volume-notification over sound-indicator yesterday...
[07:45] <Saviq> MacSlow, yeah, today is the day!
[07:45] <MacSlow> Saviq, can any indicator actually determine, if it's UI is visible (outside of QML)?
[07:46] <Saviq> dednick, ↑?
[07:46] <MacSlow> Saviq, btw... I've seen that Ted updates his branches with my suggestion/fixes already
[07:46] <dednick> MacSlow: the indicator service? now.
[07:46] <dednick> now
[07:46] <dednick> meh. no!
[07:47] <MacSlow> dednick, Saviq: I'll try to figure out something else then.
[07:47] <Saviq> MacSlow, right, I thought that could be a problem... dednick, think we should have a separate volume actionthingy for volume buttons, separate for the slider? is it possible?
[07:48] <Saviq> or maybe hidden actions for vol+ / vol- instead of us changing the volume
[07:48] <dednick> Saviq: not sure what you're talking about?
[07:49] <Saviq> dednick, we have a problem that the indicator doesn't know if volume is changed via slider in the menu or hw buttons
[07:49] <Saviq> dednick, so when changing volume in menu it will pop up the button still
[07:49] <MacSlow> Saviq, dednick: a seperate set of volume-up/down callbacks was my first thought too
[07:49] <Saviq> s/button/bubble/
[07:49] <dednick> Saviq: ah
[07:50] <Saviq> because we're directly manipulating the volume action
[07:51] <dednick> Saviq: hm. i wonder if it should even be the indicator setting off the notification? maybe should be listening to account services for that.
[07:52] <Saviq> dednick, well, too late for now
[07:52] <dednick> Saviq, MacSlow: sounds plausible to have 2 action groups.
[07:53] <dednick> Saviq: ya
[07:53] <MacSlow> Saviq, dednick: ok, I'll try that then
[07:53]  * Saviq thinks it might even be too late to do the additional action
[07:53] <Saviq> MacSlow, make that the last on your prio list please
[07:53] <MacSlow> Saviq, ok
[07:53] <dednick> what did we used to do before using indicator for sound? go direct on android?
[07:53] <MacSlow> Saviq, first one being then?
[07:54] <dednick> for hw buttons i mean
[07:56] <Saviq> dednick, I don't think we ever did anything else
[08:01] <larsu> Saviq: the bubble is shown when using the hw buttons? I fixed that quite some time ago iirc
[08:01] <Saviq> larsu, well, it's *supposed* to be shown now
[08:02] <larsu> Saviq: right, sorry. It's not supposed to be shown when using the slider
[08:02] <Saviq> bug #1232633
[08:02] <Saviq> larsu, well, if you could help MacSlow with that (stuff's in rtm silo 006), that would be awesome
[08:03] <Saviq> larsu, http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu-rtm&q=landing-006
[08:03] <larsu> Saviq: ah, past me tells me we reverted it because sync notifications weren't enabled
[08:03] <larsu> MacSlow: do they^^ work now?
[08:04] <Saviq> larsu, in silo 6, yes
[08:04] <Saviq> larsu, that's what we're enabling now
[08:04] <larsu> Saviq: so it'S just a matter of digging out my old branch?
[08:04] <Saviq> larsu, you tell me...
[08:05] <Saviq> larsu, FWIW there's a new branch from tedg
[08:05] <larsu> Saviq: past me tells both of us. Let me find out ;)
[08:05] <Saviq> larsu, https://code.launchpad.net/~ted/indicator-sound/extreme-volume-warning/+merge/238168
[08:05] <larsu> Saviq: why? I even linked it from the bug report...
[08:05] <Saviq> larsu, well, it does a bit more, since the *actual* feature we're after is the high volume warning
[08:06] <Saviq> larsu, tedg's branch for just enabling the sync notification is https://code.launchpad.net/~ted/indicator-sound/synchronous-notification/+merge/237666
[08:06] <Saviq> MacSlow, I was thinking... for the "only one sound"
[08:06] <MacSlow> larsu, and it mostly alreaday works correctly with tedg's new branches... only an edge-case is bothering us still
[08:06] <Saviq> MacSlow, maybe we should just add a signal to the backend "updated" or so
[08:07] <Saviq> MacSlow, and play the sound onUpdated, too (maybe only for a sync notification)
[08:07] <larsu> Saviq: okay, looks like ted did some extra work but is on top of it (it's not that much work anyway...)
[08:07] <Saviq> MacSlow, think this would be less of a hack than triggering separate notifications
[08:07] <MacSlow> Saviq, yeah
[08:08] <MacSlow> Saviq, new branches or that or rather work that into the already approved ones?
[08:08] <Saviq> MacSlow, it's all sync notifications still, so there
[08:08] <tsdgeos> Saviq: i can't seem to reproduce a bad implicitHeight with the card code Kyle gives, do you have any more pointers about what scope that may be?
[08:08] <Saviq> MacSlow, no need for new branches
[08:09] <MacSlow> Saviq, ok just wanted to be sure
[08:09] <Saviq> tsdgeos, the same as yesterday
[08:22] <paulliu> tsdgeos: hi. So should I revert it back to use the old method for non-interactive stuff?
[08:22] <paulliu> tsdgeos: It doesn't seems to work by using enabled.
[08:22] <tsdgeos> paulliu: so a mousearea still receives presses when disabled?
[08:22] <tsdgeos> that's confusing
[08:22] <paulliu> tsdgeos: yes.
[08:22] <paulliu> tsdgeos: enabled is for "trigger"
[08:22] <paulliu> tsdgeos: not for click/pressandhold
[08:24] <Saviq> paulliu, that's not true http://qt-project.org/doc/qt-5/qml-qtquick-item.html#enabled-prop
[08:25] <Saviq> paulliu, it's a built-in QML property
[08:25] <tsdgeos> paulliu: http://paste.ubuntu.com/8563573/ says no
[08:26] <paulliu> Saviq: but how if the ActionItem has its own property enabled? Will it override the built-in one?
[08:27] <Saviq> paulliu, shouldn't be possible to override it...
[08:28] <paulliu> Saviq: strange. Let me dig into it more.
[08:29] <paulliu> I'll figure that out later. Currently at Narita Airport.
[08:30] <Saviq> paulliu, you're flying to DC already?
[08:30] <paulliu> Saviq: not yet. Going to a conference in Japan right before DC.
[08:31] <Saviq> paulliu, ah, cool, have fun and see you there :)
[08:32] <Saviq> MacSlow, where's the bug this is a dupe of? bug #1381387
[08:33] <MacSlow> Saviq, hold on...
[08:34] <MacSlow> Saviq, https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1378417
[08:35] <Saviq> MacSlow, thanks
[08:35] <MacSlow> Saviq, marked it
[08:36] <Saviq> Wellark, saw mterry's review yesterday? you need to tweak the tests
[08:37] <Saviq> Wellark, also, please add a Breaks: indicator-network (<< foo)
[08:37] <Saviq> Wellark, this way it'll be obvious the indicator needs upgrading
[08:39] <mzanetti> Saviq: does this now pass for you? https://code.launchpad.net/~mzanetti/unity8/fix_snap_decision_test-rtm/+merge/238282
[08:40] <mzanetti> Saviq: still couldn't repro the failure but I checked out what tst_Notifications is doing... hopefully works now
[08:40] <Saviq> mzanetti, you need a laptop refresh, it's too slow :D
[08:41] <Wellark> Saviq: ok. will do
[08:41] <mzanetti> one more year to do
[08:41] <mzanetti> to go
[08:41] <Saviq> mzanetti, ;)
[08:46] <Saviq> mzanetti, hmm I tried the non-rtm version and it failed still :|
[08:46] <Saviq> mzanetti, let me rebuild rtm
[08:46] <Saviq> I saw it passing in CI
[08:46] <mzanetti> aw man
[08:46] <mzanetti> Saviq: rtm and utopic branches do the same
[08:46] <mzanetti> Saviq: do tst_notifications pass for you?
[08:47] <Saviq> mzanetti, same under xvfb
[08:47] <mzanetti> ffs
[08:47] <Saviq> trying
[08:47] <mzanetti> ah right... there isn't a snap decision test
[08:48] <mzanetti> no chance... 100% pass rate here
[08:50] <tsdgeos> karni: ping
[08:52] <Saviq> mzanetti, anyway, CI is happy, not sure I want to block on this
[08:53] <Wellark> Saviq: I'm hesitant on adding the Breaks
[08:53] <Wellark> as it might now break the tools qa are using
[08:53] <Wellark> as they need to manually update i-network from the archive
[08:54] <Wellark> Mirv: could you shed some light on this -- ^
[08:54] <Wellark> AFAIK QA has some script that does most of the settings up
[08:54] <Saviq> Wellark, well, that just needs a comment "upgrade indicator-network from the archive before installing this silo"
[08:54] <Saviq> Wellark, it's the citrain tool
[08:54] <Wellark> so they can do a manual upgrade before running the setup?
[08:55] <Saviq> Wellark, sure
[08:55] <Saviq> Wellark, the ~broken tool *can not* impact how we encode dependencies, that'd be backwards
[08:55] <karni> tsdgeos: pong
[08:55] <tsdgeos> karni: do you know anything about https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1381255 ?
[08:55] <Wellark> Saviq: you forgot the "</sarcasm>"
[08:56] <tsdgeos> karni: i mean the scope that creates the problem, not the VJ code itself
[08:56]  * karni looks
[08:56] <Wellark> Saviq: please, don't talk about backwards now ;)
[08:56] <Wellark> I might get exited..
[08:56] <Wellark> Saviq: ok, will add it
[08:57] <karni> tsdgeos: let me know if you don't have access https://code.launchpad.net/~hanloon-team/hanloon/texts
[08:58] <tsdgeos> seems i do
[08:58] <Saviq> mzanetti, it should be possible to wait on the behavior...
[08:59] <Mirv> Saviq: Wellark: if Breaks is needed, then just add it. I already added a similar comment to rtm-006 silo.
[08:59] <Saviq> Mirv, yup, thanks
[09:01] <Saviq> MacSlow, additional advantage of the indicator changing volume would be that there's currently too many steps of ringtone volume
[09:01] <Saviq> MacSlow, there should be like 4 maybe
[09:02] <Wellark> Mirv, Saviq: does this now look correct?
[09:02] <Saviq> bug #1291458
[09:02] <Wellark> +Breaks: indicator-network (<< 0.5.1+14.10.20141014),
[09:02] <Saviq> Wellark, looks good, yes
[09:02] <MacSlow> Saviq, wasn't aware of that
[09:02] <Wellark> :D
[09:02] <Saviq> MacSlow, well, it's just IMO, but ;)
[09:03] <Wellark> that looks like fun
[09:04] <Mirv> Wellark: looks correct
[09:05] <tsdgeos> karni: do you know if i can run that on the desktop? or is mostly phone?
[09:05] <Mirv> I found volume button working funky when playing a youtube video
[09:05] <Mirv> when testing the scope for fun, and kate perry starts to play, it's an emergency if one can't turn the volume down
[09:06] <karni> tsdgeos: I would not know, sorry. Mostly the phone, probably. (FTR been a couple months I've bee off the scopes team, but feel free to ping me in case you have scopes related questions, I can forward if I don't have answers)
[09:06] <tsdgeos> karni: ok, tx
[09:07] <Mirv> today it seems to work better, yesterday it seemed like there were two volume sliders being tried to be set and it kind of hung for a while, with only increasing volume
[09:08] <Wellark> Saviq: if you need a wing man on that design change just ping me
[09:08] <Saviq> Wellark, I might actually request a session for DC
[09:09] <Wellark> Saviq: I agree the N9 had very intuitive and functional sound controls
[09:11] <Wellark> Saviq: updated the MP's
[09:11] <Wellark> let's see what jenkins says
[09:11] <Wellark> Saviq: will mterry be up soon?
[09:11] <Saviq> Wellark, thanks, just kicking a build in silo
[09:11] <Saviq> Wellark, dunno, not his mom
[09:11] <Saviq> Wellark, ;)
[09:12] <Saviq> Wellark, no earlier than 4pm UTC I'd say
[09:12] <Wellark> blah..
[09:19] <Saviq> tsdgeos, since Daniel abstained on dednick's branch, could you please do as much as possible of a proper review today
[09:19] <Saviq> tsdgeos, I'll try and take away any distractions
[09:20] <tsdgeos> Saviq: ok, give me a few mins more to see if i can reproduce the VJ problem
[09:20] <Saviq> tsdgeos, sure
[09:31] <tsdgeos> Saviq: ok, can reproduce
[09:31] <tsdgeos> and it seems the bug is not in the card itself but somewhere else
[09:31] <tsdgeos> because on reboot
[09:31] <tsdgeos> it shows up fine
[09:31] <tsdgeos> then i pull to refresh
[09:31] <tsdgeos> and boom
[09:31] <tsdgeos> it's bad again
[09:32] <tsdgeos> and then again
[09:32] <tsdgeos> and depending on how lucky you are
[09:32] <tsdgeos> it's good or bad :D
[09:38] <Saviq> tsdgeos, ohkay
[09:38] <Saviq> tsdgeos, ok, try and dig into that then
[09:39] <Saviq> since it's gonna bite us
[09:39] <tsdgeos> ok
[09:54] <MacSlow> Saviq, I've a working solution for sound-playback upon sync. notification-updates (triggered by any hint change)... while it works as expected on the desktop it does not on the phone.
[09:54] <MacSlow> Saviq, where is the console-output of unity8 written to on the phone?
[09:54] <Saviq> MacSlow, ~/.cache/upstart/unity8.log
[09:55] <MacSlow> Saviq, thx
[10:00] <MacSlow> Saviq, so the sound-playback is really exectued on the phone... it not being played back has to be something lower in the audio-stack... not sure what that is yet or how to debug it... I'll update my unity8 branch with the change nevertheless
[10:04] <Saviq> MacSlow, huh, interesting
[10:04] <Saviq> MacSlow, so no need for changes anywhere else? just unity8?
[10:06] <MacSlow> Saviq, there are tons of <property>Changed and the only real sound-relevant is the hint anyway... so I went the least invasive path and let the playback be retriggered upon onHintsChanged (just for sync. notifications)
[10:07] <Saviq> MacSlow, right, sounds fine indeed
[10:07] <MacSlow> Saviq, who's our sound/audio-stack prodigy ?
[10:08] <MacSlow> Saviq, btw http://bazaar.launchpad.net/~macslow/unity8/synchronous-notification/revision/1106
[10:09] <Saviq> MacSlow, one that's alive at this hour, we could try ricmm
[10:09] <MacSlow> Saviq, ok
[10:09] <Saviq> MacSlow, trying it out
[10:13] <MacSlow> Saviq, you'll have to apply http://pastebin.ubuntu.com/8563975/ to lp:~macslow/untiy-notifications/synchronous-notification/examples/icon-value.py
[10:13] <MacSlow> Saviq, as I've not added that
[10:14] <Saviq> MacSlow, I just patched it on the phone
[10:14] <mzanetti> MacSlow: hey, just testing the volume bubble on rtm. looks nice, but the calculation for the icon is different than in the panel. looks a bit odd
[10:15] <mzanetti> would it be much work to align that?
[10:15] <MacSlow> mzanetti, that it seems out of sync is an issue of indicator-sound, which I don't know what introducing it
[10:16] <mzanetti> MacSlow: doesn't look like being out of sync
[10:16] <MacSlow> mzanetti, if unity8 is run on the desktop both icons (notification and panel) are perfectly in sync
[10:16] <mzanetti> just a bit different
[10:16] <MacSlow> mzanetti, ah you mean icon-theme-wise?!
[10:16] <mzanetti> well, the progress bars move the same in the indicator and the bubble
[10:17] <mzanetti> but the icon switches from 2 to 3 bars at a different level
[10:17] <Saviq> mzanetti, it's the indicator that needs to align that
[10:17] <Saviq> mzanetti, https://code.launchpad.net/~ted/indicator-sound/synchronous-notification/+merge/238252
[10:17] <mzanetti> ah ok
[10:17] <MacSlow> mzanetti, that's a icon-name -> volume-level mapping issues
[10:18] <MacSlow> mzanetti, I think I know where the fix for that needs to happen (in indicator-sound)
[10:18] <mzanetti> MacSlow: ok then. I just thought its the notification...
[10:20] <MacSlow> mzanetti, no... just writing another MP-comment with a fix suggestion on tedg's related branch
[10:23] <Saviq> MacSlow, maybe incorporate https://code.launchpad.net/~cimi/unity8/fix-1378920/+merge/238012 into your branch
[10:25] <MacSlow> Saviq, ah yeah... had that on my plate from yesterday still... looking into it now
[10:27] <Saviq> MacSlow, as for the sound... indeed it seems to be a problem with the audio subsystem... I tried using SoundEffect http://qt-project.org/doc/qt-5/qml-qtmultimedia-soundeffect.html, but this only works with uncompressed audio
[10:27] <Saviq> MacSlow, I wonder how we could use pulseaudio's sample caching support
[10:29] <MacSlow> Saviq, hm... I basically know next to nothing about Pulse audio... I would have to poke ricmm for that
[10:30] <Saviq> MacSlow, hmm hmm
[10:30] <Saviq> MacSlow, I added a console.debug in the onHintsChanged {} block
[10:30] <Saviq> MacSlow, and when it doesn't play, I don't get it
[10:30] <Saviq> MacSlow, wrong
[10:31] <Saviq> MacSlow, trying again
[10:31] <MacSlow> Saviq, I saw my debug-output for every hardware-key-press
[10:31] <Saviq> MacSlow, yeah, I put the debug in the wrong block
[10:35] <Saviq> MacSlow, right, yeah, creating the session with the media hub every time seems to cause a lot of the overhead
[10:39] <MacSlow> Saviq, ricmm doesn't seem to feel like being the audio-person we're looking for
[10:48] <Saviq> MacSlow, I'm already there, talking to him and tvoss
[10:59] <karni> Do we have this bug on the radar? -- Need to refresh (pull to refresh or force search) the dash to make sure latest version of the app is launched. that's the case when installing app thorugh adb, not sure if updating from ubuntu store suffers from same problem.
[11:03] <Saviq> karni, it does not
[11:03] <Saviq> karni, I think
[11:03] <Saviq> karni, but it's filed somewhere...
[11:03] <karni> Saviq: if ubuntu store installs/updates are not affected, that's great :)
[11:04] <Saviq> karni, installs are not, for sure, there was a bug for updates
[11:04] <karni> gotcha. good that its filed then.
[11:11] <Saviq> Wellark, hum hum, I took the second SIM out, the SIM dialog shows on boot, but doesn't unlock
[11:11] <Saviq> Wellark, pressing "Unlock SIM" again doesn't do anything
[11:14] <Wellark> Saviq: check the i-network version
[11:14] <Wellark> Saviq: and unity8 has not crashed in between or anything?
[11:14] <Saviq> Wellark, no
[11:14] <Saviq> Wellark, i-n is good
[11:14] <Wellark> Saviq: apt-cache policy indicator-network
[11:15] <Saviq> 0.5.1+14.10.20141014-0ubuntu1
[11:15] <Wellark> ffs...
[11:15] <Saviq> Wellark, unlocks fine when I have both SIMs in
[11:15] <Wellark> Saviq: so krillin? which image number?
[11:15] <Wellark> what channel?
[11:15] <Saviq> Wellark, krillin, rtm proposed of course, 105
[11:15] <Saviq> Wellark, + silo 6
[11:16] <Wellark> christ..
[11:16] <Wellark> Saviq: it's user error. if you don't have two sims, don't buy a dual sim phone!
[11:16] <Wellark> WONTFIX
[11:16] <Saviq> Wellark, it's fine after a flight mode toggle
[11:16] <Saviq> Wellark, but not after a reboot
[11:17] <Wellark> Saviq: yeah.. different code paths
[11:17] <Wellark> Saviq: so, which slot has sim?
[11:17] <Saviq> Wellark, 1
[11:17] <Wellark> and 2 is empty
[11:17] <Wellark> ok.
[11:17] <Saviq> Wellark, on that note, don't you know the sim names from settings yet?
[11:18] <Wellark> Saviq: not yet
[11:18] <Saviq> Wellark, k
[11:18] <Saviq> Wellark, I'm flashing from scratch to verify, but it's 100% reproducible on boot
[11:18] <Wellark> Saviq: yes. I bet it is
[11:19]  * Wellark wants a mainloop!!
[11:20] <Wellark> AARRGGHH
[11:20] <facundobatista> Holas
[11:20] <Wellark> Saviq: ok. got it
[11:20] <Saviq> Wellark, rtm silo 6 is open for you, let me know when you have something to put in there
[11:21] <Wellark> Saviq: give me 10
[11:21] <Wellark> Saviq: or make it 15
[11:21] <Wellark> I need a smoke
[11:21] <Saviq> Wellark, I'll give you more, I need to go out in a bit
[11:34] <Wellark> Saviq: fix is on it's way
[11:34] <Wellark> https://code.launchpad.net/~unity-api-team/indicator-network/fix_unlock_v2/+merge/238415
[11:34] <Wellark> how do we handle that?
[11:34] <Wellark> can we sync i-network from the rtm to utopic?
[11:34] <Wellark> Mirv: ^
[11:35] <Saviq> Wellark, we can, yeah, assuming both sources are meant to be the same
[11:35] <Saviq> Wellark, i.e. there's no diff between utopic and rtm yet
[11:37] <Wellark> Saviq: i-network has no diff
[11:37] <Wellark> Saviq: just one trunk
[11:37] <Saviq> Wellark, yup, then yeah, we can sync from rtm silo to utopic
[11:37] <Wellark> Saviq: ok, so you could add that to the unity8 silo?
[11:37] <Saviq> Wellark, doing
[11:37] <Wellark> Saviq: thanks!
[11:38] <Mirv> Wellark: yes, via silo
[11:45] <Wellark> Saviq: did you add the qtubuntu-media MP is as well?
[11:45] <Wellark> it looks valid, so should be safe to add
[11:45] <Wellark> I just run some additional checks on the code
[11:47] <Saviq> Wellark, not yet, waiting for ACK from sil2100
[11:51] <sil2100> Saviq: what ACK we talking about now? :)
[11:51] <Saviq> sil2100, for the bugs to go into rtm
[11:51] <Wellark> sil2100: the one you should give! ;)
[11:51] <Saviq> sil2100, the three I mentioned before
[11:52] <sil2100> Saviq: yes, ok, didn't get back to you indeed - my mistake ;)
[11:52] <sil2100> Saviq: we got a +1 from Victor
[11:52] <sil2100> So go for it!
[11:53] <Saviq> sil2100, I'll need another reconf on silo 6 then :)
[11:53] <Saviq> tsdgeos, once you get them, please file separate MPs for merging into lp:unity8/rtm-14.09, we want them to go into todays image
[11:53] <Saviq> (the fixes)
[11:57]  * Saviq lunch and a bit of taxes
[11:58] <Saviq> Wellark, i-n building in silo 6
[12:07] <mzanetti> dandrader: hey, addressed your comments in: https://code.launchpad.net/~mzanetti/unity8/launcher-update-on-dconf-change/+merge/236561
[12:08] <dandrader> mzanetti, just approved it
[12:08] <mzanetti> dandrader: thanks. preparing the rtm branch atm
[12:14] <mzanetti> dandrader: https://code.launchpad.net/~mzanetti/unity8/launcher-update-on-dconf-change-rtm/+merge/238423
[12:16] <dandrader> mzanetti, I don't suppose I should test it as well, right?
[12:16] <mzanetti> dandrader: hmm... diff is the same, tests are passing... I'd say we're good...
[12:19] <mzanetti> seb128: hey, do I need to file this branch against rtm too, or will you guys cherry-pick it over when landing? https://code.launchpad.net/~mzanetti/ubuntu-system-settings/update-reset-launcher/+merge/234309
[12:19] <seb128> mzanetti, we don't have branches, we are just going to request that to be copied over
[12:20] <mzanetti> ack
[12:20] <asac> who maintains the timeout it takies to popup the shutdown dialog?
[12:20] <asac> on phone?
[12:20] <asac> (time to push button without release)
[12:29] <seb128> unity8 I guess
[12:30] <seb128> do you find it too long?
[12:39] <Saviq> mzanetti, we don't need rtm branches for everything
[12:39] <Saviq> mzanetti, just the things that are going into 10/16, we'll sync everything else again after the image is done
[12:41] <mzanetti> Saviq: ah ok...
[13:01] <tsdgeos> Saviq: do we want  lp:~aacid/unity8/grid_rows_cols as rtm branch too?
[13:01] <Saviq> tsdgeos, yes, that one, please
[13:01] <Saviq> tsdgeos, and the VJ fix once you have it
[13:01] <tsdgeos> ok
[13:22] <tedg> MacSlow, Reading your e-mail, what do you mean by "volume notifications triggered by changing value in indicator" ?
[13:23] <tedg> I think the "sync issue" is fixed. What you're seeing now is changing modes with the sound notification.
[13:23] <MacSlow> tedg, when you pull down the sound-indicator and change the volume via the slider there... that should not trigger any sync. volume notification... currently it does and actually gets "in the way" visually with the slider
[13:25] <tedg> MacSlow, I thought that's why we had the "background color change" bug?
[13:26] <tedg> MacSlow, And that was the fix.
[13:26] <MacSlow> tedg, no... that's different...
[13:27] <tedg> MacSlow, I don't think we're getting notification of the indicator being open on unity8
[13:27] <tedg> MacSlow, So it'll be hard to detect that case.
[13:27] <MacSlow> tedg, although the background-color contrast issue is fixed (in the sync. notification branch for unity8) the fact that the volume-change via the sound-indictors slider still triggers a sync. notification remains
[13:28] <MacSlow> tedg, I think Saviq asked larsu for some help on that front
[13:29] <tedg> We have an action that can be defined to show it, but I think it's only implemented on u7.
[13:29] <MacSlow> tedg, btw... determining if an indicator is open on QML/unity8-side is easy... doing it from within an indicator seems hard
[13:29] <tedg> It's not *hard* more just that part of the framework was never implemented.
[13:30] <MacSlow> tedg, I stick with "hard" :)
[13:30] <MacSlow> tedg, especially hard ;)
[13:30] <tedg> Heh, I'll go with "unity8 team is lazy" ;-)
[13:31] <tedg> Frankly though, I think that we can land this silo without that fix.
[13:31] <tedg> It's an annoyance.
[13:32] <MacSlow> tedg, sure... although that's me to make the final decision on this
[13:34] <MacSlow> tedg, indeed... two days ago, when I accidentally thought unity-settings-daemon was the place to fix it, I found the related pieces to make it work... for unity7 *sigh*
[13:40] <tedg> MacSlow, Cimi, do you guys know the status of bug 1378920 ?
[13:41] <MacSlow> tedg, yeah... I did some testing for that branch already...
[13:41] <seb128> tedg, hey
[13:41] <seb128> tedg, I think I read somebody pinging you yesterday about that, but I didn't see your reply (if there was one), is indicator-display supposed to show on the rtm image?
[13:42] <tedg> seb128, It won't, the bug isn't super critical. It should work in utopic.
[13:42] <seb128> tedg, ok, I was mostly curious, thanks
[13:42] <tedg> MacSlow, Is it in the notification silo?
[13:43] <MacSlow> tedg, it seems to fix the stated issue... although it behaves a bit odd... while the volume is changed if a video is played back, the video's volume isn't altered sync with the volume-change done via the hw-keys
[13:43] <MacSlow> tedg, not yet
[13:44] <tedg> MacSlow, Any objection to me adding it? I think it'd make it easier to test.
[13:44] <MacSlow> tedg, nope... go ahead
[13:45] <tedg> Saviq, Adding the media role MR to silo rtm/6 and rebuilding
[13:47] <tedg> … reconfiguring …
[13:47] <tedg> .
[13:47] <tedg> .
[13:47] <tedg> .
[13:53] <Saviq> tedg, MacSlow was about to just add that change to his branches
[13:53] <MacSlow> Saviq, haven't done it yet... the silo 6 testing on the mako is keeping me busy still
[13:54] <MacSlow> tedg, Saviq: can pull it in in a heartbeat...
[13:54] <tedg> Uhg, MR targetting Utopic.
[13:54] <Saviq> tedg, yes, MacSlow just please add it to your branches
[13:54] <tedg> ?
[13:55] <tedg> That's weird to me.
[13:55] <MacSlow> tedg, I'll add it to mine...
[13:55] <tedg> But sure. I'll remove it from the spreadsheet.
[13:55] <Saviq> tedg, already done
[13:55] <tedg> Alrighty then.
[13:56] <tedg> Saviq, So I see you've been convinced by the "devel branch" approach ;-)
[13:56] <MacSlow> :)
[13:56] <Saviq> tedg, no
[13:56] <MacSlow> only for sync. volume-notifications ;)
[13:56] <Saviq> tedg, rtm-14.09 is cherry-pick from trunk basically
[13:57] <Saviq> tedg, short lived, only while we've slowed down the rtm images
[13:57] <Saviq> tedg, I have, however, come up with a hybrid staging approach that sil2100 was quite happy to support, just there was no time yet
[13:58]  * tedg is curious, but scared
[13:59] <Saviq> tedg, basically having pull (as opposed to merge) requests supported by the train
[14:00] <Saviq> tedg, FYI, we're looking at playback issues with the sync notification, we might need to turn off the plöpp sounds for now
[14:00] <Saviq> MacSlow, please let me know when you push the role change
[14:01] <tedg> Saviq, I have no idea what the difference between "pull" and "merge" are.
[14:02] <Wellark> Saviq: do we have silo rebuilt?
[14:02] <Saviq> tedg, history
[14:02] <Wellark> could you quickly verify that your setup works?
[14:02] <Saviq> tedg, basically you'd prepare a staging branch that would be pulled onto trunk before any additional MPs get merged into it
[14:03] <tedg> Saviq, Sure, I'm +1 on removing the sounds if that cleans things up. It's not a huge feature, just a nice-to-have.
[14:03] <Saviq> tedg, indeed
[14:03] <Saviq> Wellark, not sure what happened with q-m in the rtm silo, checking
[14:04] <tedg> Saviq, To basically a "per silo devel branch"
[14:05] <tedg> Saviq, But you want to make it yourself instead of having CI Train build it for you.
[14:05] <Saviq> tedg, not even per silo, there's no reason why it shouldn't be lp:foo/staging
[14:05] <Saviq> tedg, you'd pull trunk into it after each landing
[14:06] <tedg> Saviq, So MRs land on staging or trunk?
[14:06] <Saviq> tedg, so before you stage anything, trunk == staging
[14:06] <Saviq> tedg, MR are against trunk
[14:06] <Saviq> tedg, so they remain Approved until the silo lands
[14:06] <Saviq> tedg, but either you manually, or CI, lands them in staging
[14:07] <Saviq> tedg, most MPs would have staging as prerequisite, too
[14:07] <Saviq> tedg, but to not block others, you could still have traditional MPs on top of the staging
[14:08] <tedg> Saviq, So what happens if an MR lands on staging but is decided that it doesn't want to go to trunk right now.
[14:08] <tedg> i.e. I would have though the greeter stuff would have landed before high volume notifications.
[14:08] <tedg> (and in any rational world, it would have)
[14:08] <Saviq> tedg, that's a corner case, and we'd have to deal with it by means of rewriting the staging or so
[14:08] <Saviq> tedg, or reverting it from there
[14:09] <Saviq> tedg, as you'd rather do in bzr
[14:10] <tedg> Saviq, So it seems like a devel branch, except that the history is slightly different. Not sure why changing the history helps.
[14:11] <Saviq> tedg, because you don't end up with a single commit per landing, that's just something I can't agree with ;)
[14:11] <Saviq> tedg, but also the fact that MPs are still targeted against trunk, but can be staged
[14:12] <tedg> Saviq, can you just alias "bzr log" to "bzr log -n2" ? ;-)
[14:12] <Saviq> tedg, tell LP that
[14:12] <tedg> Saviq, If we had a commit message that listed all the MRs that landed in that commit would that solve your issue?
[14:13] <Saviq> tedg, no
[14:13] <Saviq> tedg, I just can't live with that kind of history ;)
[14:13] <tedg> Saviq, So if you could specify that trunk pulled the devel branch and pushed over the trunk, that's all you really want.
[14:13] <Saviq> tedg, yes exactly
[14:13] <Saviq> tedg, with some CI twists
[14:13] <Saviq> tedg, but as far as train is concerned, that's all indeed
[14:16] <tedg> Saviq, I updated indicator-sound for MacSlow's comments on the MR.
[14:17] <tedg> Saviq, Are you rebuilding the whole thing, or should I kick an i-sound build?
[14:17] <Saviq> tedg, I will rebuild unity8 as well, but not just now, sil2100 is fighting with qtubuntu-media in that silo atm
[14:18] <MacSlow> tedg, ah great...
[14:18] <tedg> Okay
[14:19] <sil2100> Saviq: it *should* be building, but I'm in meetings so I didn't check that yet
[14:19] <Saviq> sil2100, it is building, thanks
[14:20] <MacSlow> tedg, approved your branch too now
[14:20] <MacSlow> tedg, I think we've done all we can now there
[14:27] <tedg> dednick, Did you see my comment here? https://code.launchpad.net/~unity-team/unity8/rtm-expanded-panel-design/+merge/238244/comments/585113
[14:27] <tedg> dednick, I'm worried about the hidden indicators
[14:27] <tedg> dednick, We made more hide faster, so people can loose them now :-)
[14:28] <dednick> tedg: "Putting your finger on the bottom bar allows you to slide between the indicators. So if you grab the bar and close, you probably change indicators along the way (which is odd)"
[14:28] <dednick> by design. speak with designers if you disagree.
[14:29] <dednick> tedg: busy fixing the partially selected item
[14:29] <tedg> dednick, Ah, okay. It still is weird :-)
[14:29] <dednick> tedg: hidden items: if they're marked as non-visible, shouldn't they be non-visible?
[14:29] <tedg> dednick, Non-visible on the panel, shown in the expanded set.
[14:30] <dednick> tedg: ok. i'll need to work on that one.
[14:30] <dednick> tedg: although i don't think it's in current design anyway
[14:30] <tedg> dednick, I believe it is…
[14:31] <dednick> tedg: no. bluetooth not in there in flight mode.
[14:31] <tedg> dednick, "Status Bar Functional Overview"
[14:31] <dednick> tedg: i mean in the current impl.
[14:31] <tedg> dednick, We've adjusted bluetooth and location already. They change visibility.
[14:32] <tedg> dednick, messages is next.
[14:32] <dednick> tedg: ok
[14:32] <tedg> dednick, As a fun adventure, turn off GPS and get the location indicator to hide. Now figure out how to turn it back on.
[14:32] <tedg> :-)
[14:34] <Saviq> tedg, unity8 and indicator-sound building
[14:35] <tedg> Saviq, Great, thanks!
[14:36] <Saviq> MacSlow, tedg, I'm inclined to just drop the sound, it's too late I think to be hunting for a solution
[14:36] <MacSlow> Saviq, true
[14:40] <tedg> Saviq, I can just not set it on the notification.
[14:40] <tedg> I'll do that now.
[14:41] <Saviq> tedg, yeah, exactly what I wanted
[14:51] <Wellark> Saviq: did you have time to test the i-network fix?
[14:51] <Wellark> is it still breaking for you?
[14:51] <Saviq> Wellark, just flashing rtm now
[14:51] <Wellark> Saviq: ack
[15:04] <MacSlow> What happened to gst-launch-1.0? None of the usual pipelines work
[15:05] <Saviq> dednick, let me know if you need any help, testing or anything
[15:06] <mterry> dandrader, windowkeysfilter -- that was for a focus issue?
[15:06] <Saviq> Wellark, works1
[15:07] <Saviq> with two
[15:07] <Saviq> now taking one out
[15:07] <seb128> shrug, another unity8 segfault on rtm :/
[15:07] <Saviq> seb128, notification related by any chance?
[15:07] <Saviq> seb128, SIM unlocking?
[15:08] <dandrader> mterry, it's been a while, don't remember. let me check that code again
[15:08] <mterry> dandrader, I want to add power-key handling to the wizard code, but noticed that u8 has it wrapped in this filter class
[15:09] <mterry> dandrader, was curious if wizard needs filtering too (i.e. filtering is needed when handling power events) or if it was just about focus issues as the bzr commit seems to indicate
[15:09] <dandrader> mterry, wizard is a separate process or is it in unity8?
[15:09] <mterry> dandrader, separate process
[15:09] <Saviq> Wellark, hmm hmm it looks like it didn't even ask on boot now
[15:09] <Saviq> rebooting again
[15:10] <seb128> Saviq, no, opened gallery, closed gallery, scroll app scope to start it again, froze
[15:11] <Saviq> Wellark, yeah, it does not ask on boot if there's only one SIM
[15:11] <Wellark> Saviq: you sure you didn't hit the unity8 crash at the same time?
[15:11] <dandrader> mterry, one of the use cases was that volumeControl always had to receive volume un & down keys, even if some mir surface had active focus and was therefore getting all key events
[15:12] <seb128> Saviq, the apport file has no dump or stacktrace though :/
[15:12] <dandrader> mterry, it's a way of getting all key events regardless of what item has the active focus
[15:12] <Saviq> Wellark, yeah, confirmed multiple times
[15:12] <Saviq> Wellark, it seems to "not know" the status of the SIMs yet
[15:12] <Saviq> Wellark, so doesn't ask
[15:12] <mterry> dandrader, hmm..  That probably isn't an issue in the wizard
[15:13] <mterry> dandrader, ok will test without it anyway  :)
[15:13] <Wellark> Saviq: but it works with two..
[15:13] <dandrader> mterry, bear in mind that activeFocus != focus
[15:13] <dandrader> mterry, so even if you set "focus: true" on some item it doesn't mean that it will get active focus (and thus receive the key presses)
[15:14] <dandrader> mterry, it all depends on your item tree
[15:14] <mterry> yeah
[15:14] <mterry> dandrader, I was thinking you were talking about app focus, not item focus.. hm
[15:15] <mterry> dandrader, so might still be an issue in wizard.  What items would steal volume/power events?
[15:15] <dandrader> mterry, btw, is the wizard a surface under unity8 or a independent guy?
[15:15] <Wellark> Saviq: will join the testing in 10 minutes
[15:15] <mterry> dandrader, wouldn't they percolate up if not handled?
[15:15] <mterry> dandrader, independent
[15:15] <dednick> Saviq: thanks. just trying to fix that silly highlight problem when removing items
[15:16] <Saviq> Wellark, yeah, it's fine with two, if you have one, it doesn't ask at all
[15:16] <Wellark> Saviq: what does you apt-cache policy indicator-network say?
[15:16] <dandrader> mterry, because Shell.qml, in its WindowKeysFilter code, is filtering power key events out so they are not send to surfaces managed by unity8
[15:17] <Saviq> DOUBLE RAINBOW FTW!
[15:17] <Saviq> oh man and it's a complete one
[15:18] <Saviq> if only Ola didn't take our camera!
[15:19] <mterry> Saviq, :)
[15:19] <Saviq> Wellark, 0.5.1+14.10.20141015-0ubuntu1
[15:20] <dandrader> mterry, "What items would steal volume/power events?" <- I don't know wizard code. but you could debug it by printing out the QQuickWindow::activeFocusItem() every time it changes
[15:20] <Wellark> Saviq: oh, crap.. sorry. I'm just too tired..
[15:20] <Wellark> oneliner coming in
[15:20] <Wellark> I thought it was a for loop
[15:20] <Wellark> but it was an if
[15:20] <dandrader> mterry, to track down who the heck is getting/stealing the active focus. Helped me a lot when I was debugging such things in unity8
[15:20] <Saviq> ...
[15:21] <mterry> dandrader, thanks
[15:22] <Saviq> http://people.canonical.com/~msawicz/rainbow/
[15:22] <Saviq> and it's *not* getting any less intense
[15:23] <Wellark> Saviq: did you swith the only SIM to slot 2 ?
[15:23] <Saviq> Wellark, no, either empty → no ask
[15:23] <Saviq> can try again
[15:23] <Wellark> wtf...
[15:23] <Wellark> makes no sense...
[15:24] <Saviq> tedg, stuff's built in silo 6
[15:25] <Wellark> it would make sense if the first one is empty and second is not
[15:25] <tedg> Saviq, Cool, I think you might need a rebuild of i-sound to pick up the drop of the sound.
[15:25] <Saviq> tedg, yeah, will just test it out again to see if it's all good now
[15:26] <Wellark> Saviq: what does the indicator show?
[15:26] <Wellark> inside the menu?
[15:27] <Wellark> slot 1 locked, slot to No Sim ?
[15:27] <Saviq> Wellark, opposite, right now, but yeah
[15:27] <Saviq> Wellark, and it takes like 3-4s for it to show up after booting
[15:27] <Wellark> Saviq: so you switched the sim to slot 2 ?
[15:27] <Saviq> Wellark, I have two sims, just taking one of them out
[15:28] <Saviq> Wellark, but yeah, the menu is correct
[15:28] <Wellark> Saviq: for the indicators to show, or the modems to change to "locked" ?
[15:28] <Saviq> Wellark, for the modems to show afaict, looking closely again
[15:28] <Wellark> Saviq: do you get a pin unlock dialog for a correct sim when you run manually:
[15:29] <Saviq> Wellark, they were both offline for a few seconds
[15:29] <Saviq> Wellark, then they changed to locked/nosim
[15:29] <Saviq> Wellark, after 10s or so this time
[15:29] <Wellark> Saviq: dbus-send --print-reply --dest=com.ubuntu.connectivity1 /com/ubuntu/connectivity1/Private com.ubuntu.connectivity1.Private.UnlockAllModems
[15:29] <Wellark> Saviq: after a reboot?
[15:29] <Wellark> shiit..
[15:30] <Saviq> Wellark, yes, that worked
[15:30] <Saviq> Wellark, so it basically looks as if we're calling the Unlock method too early
[15:31] <Wellark> Saviq: ok, checked the code
[15:31] <Wellark> _if_ the modems are reporting their locked status properly when unity8 comes up
[15:31] <Wellark> the code works
[15:31] <Wellark> regardless which modem has sim
[15:31] <Wellark> now..
[15:31] <Wellark> yeah..
[15:31] <Wellark> I need to check what happens
[15:31] <Saviq> Wellark, so basically what you're saying is that having only one SIM makes ofono take longer to get the right status?
[15:31] <Wellark> Saviq: I will investigate that real quick
[15:34] <Saviq> Wellark, I slid in both cards, toggled flight mode on, off, now got no sim / offline :|
[15:34] <Saviq> yeah, flight mode didn't turn off...
[15:34] <Wellark> Saviq: please get me the output of /usr/share/ofono/scripts/list-modems
[15:35] <Wellark> Saviq: that's the toggle switch bug
[15:35] <Wellark> Saviq: try disabling from system-settings
[15:35] <Wellark> and "restart indicator-network"
[15:35] <Saviq> Wellark, yeah, just did, now I have the cards confused I believe
[15:36] <Saviq> Wellark, when should I catch the output?
[15:36] <Wellark> Saviq: just run it now and send me the output, thanks
[15:36] <Wellark> I will then ask you what you see based on the contents
[15:38] <Saviq> Wellark, huh huh, hangs after listing the first modem
[15:38] <Saviq> Wellark, both my SIMs are now unlocked and working according to the indicator
[15:38] <Saviq> ah now it went through, so it's not after, but in the middle
[15:40] <Saviq> Wellark, https://pastebin.canonical.com/118811/
[15:41] <Wellark> Saviq: hangs?
[15:42] <Wellark> oh, you mean the script
[15:42] <Wellark> yes it does that
[15:42] <Saviq> Wellark, k
[15:42] <Wellark> Saviq: so, the indicator should now show both of the modems as conneted to a network and not being locked
[15:43] <Saviq> Wellark, yeah, that was the case
[15:44] <Saviq> Wellark, the log when booting https://pastebin.canonical.com/118813/
[15:45] <Saviq> Wellark, that's with two SIMs, both got unlocked fine on boot
[15:46] <tsdgeos> Saviq: so what needs reviewing now?
[15:46] <Saviq> Wellark, a broken log coming up
[15:46] <Saviq> tsdgeos, nothing, really
[15:46] <tsdgeos> ok
[15:46] <tsdgeos> good :)
[15:46] <Saviq> tsdgeos, well, dednick's branch, but you know, late for that
[15:46] <tsdgeos> :D
[15:47] <Saviq> Wellark, ok, you'll be interested in that
[15:47] <Wellark> Saviq: ack.
[15:47] <Wellark> the first on looked fine
[15:47] <Saviq> Wellark, https://pastebin.canonical.com/118816/
[15:48] <Saviq> Wellark, both modems are basically dead for... 38s on boot
[15:49] <Wellark> Saviq: that explains.
[15:49] <Saviq> dandrader, do you have a fix for the launcher edge?
[15:49] <Wellark> Not my Bug \o/
[15:49] <Saviq> Wellark, so yeah, when we call Unlock..., the modems are just dead
[15:49] <dandrader> Saviq, not yet.
[15:49] <Wellark> Saviq: let's take this elsewhere
[15:50] <dandrader> Saviq, but I can push a quick fix if you need it
[15:50] <dandrader> today
[15:50] <Saviq> dandrader, no, let's not push our luck ;)
[15:53] <dednick> Saviq: i can't get that highlight shit fixed properly. can fix post?
[15:53] <Saviq> dednick, for sure
[15:59] <dednick> Saviq: pushed some more fixes. think it's ready for silo now
[16:00] <Saviq> dednick, ok
[16:00] <cwayne> i seem to have a frozen dash..
[16:02] <Saviq> cwayne, take it out of the fridge
[16:02] <Saviq> cwayne, but for real, frozen or in progress of crashing?
[16:02] <cwayne> Saviq: http://instantrimshot.com/
[16:03] <cwayne> Saviq: not sure
[16:03] <cwayne> ah nm seems it was a crash
[16:03] <cwayne> have a unity8-dash.crash, and my dash is working again
[16:21] <Saviq> tedg, will we get the i-n branches under review today?
[16:21] <Saviq> tedg, also, what's with the settings MP, do we need it in the 10/16 image?
[16:54] <Wellark> Saviq: so, wht's the story with the unlocking? are we good to land?
[16:54] <Wellark> as long as there are two sims it's fine
[16:54] <Saviq> Wellark, seems so, yes
[16:54] <Wellark> and if there is only one then you can get to it inside the indicator
[16:54] <Saviq> Wellark, well, as long as the rild starts, it's fine ;)
[16:54] <Wellark> and demonstrating a dual sim device without two sims would be a bit lame, to begin with :)
[16:54] <Wellark> so, let's count on that
[16:55] <Wellark> Saviq: so anything you need from me ?
[16:55] <Saviq> Wellark, nope, it's good
[16:55] <Wellark> for tonight..
[16:55] <Wellark> it's good
[16:55] <Wellark> Saviq: thanks man!
[16:55] <Saviq> Wellark, o/
[17:18] <mterry> mzanetti, back from lunch, sorry I had missed your messages.  I'll add some testing logic in the branch in a bit
[17:26] <Saviq> dednick, if you're really around, can you please skim the expanded panel diffs in bug #1368856 (rtm vs. trunk)
[17:26] <dednick> Saviq: sure
[17:26] <Saviq> dednick, if I know anything, the trunk one did not get prerequisite into account, hence the difference in diff lineno
[17:26] <dednick> ah. forgot to update rtm
[17:26] <Saviq> dednick, nw, did that
[17:27] <dednick> Saviq: hm. 5k vs 7k?
[17:27] <Saviq> dednick, yeah exactly, but looks like sharedunitymenumodel is taken into account in the trunk one
[17:27] <dednick> not sure what happened to the trunk one. seems to have jumped up byu 2k lines
[17:28] <dednick> ah
[17:35] <dednick> Saviq: looks ok to me.
[17:36] <dednick> bit of a brief skim though...
[17:36] <dednick> i gots to run. later.
[17:40] <greyback_> tedg: hey, would this backtrace suggest anything to you: http://pastebin.ubuntu.com/8566086/
[17:40] <greyback_> unity8 is blocked here
[17:56] <mterry> mzanetti, updated branch and added MP comment
[18:11] <Saviq> greyback_, mzanetti, if you're not gonna be around tomorrow at all, have a good trip and see you there! drop me an email or text if you crystallize a plan for Fri
[18:12] <greyback_> Saviq: certainly, safe trip
[18:18] <mzanetti> Saviq: yep. thanks. See you there
[18:18] <mzanetti> mterry: looking
[18:19] <tedg> greyback_, Hmm, that could be getting the cgmanager connection.
[18:19] <tedg> greyback_, We do that when getting the pid list.
[18:20] <tedg> greyback_, Not sure why that connection wouldn't connect though.
[18:20] <tedg> greyback_, Is cgmanager hung?
[18:20] <greyback_> tedg: yep, I can confirm that unity8/qtmir is checking the PID for an app at that time
[18:21] <mzanetti> mterry: thanks. approved
[18:21] <greyback_> tedg: is first I've heard of cgmanager. It's a separate process then I guess
[18:21] <mterry> mzanetti, awesome
[18:21] <tedg> greyback_, Yeah, system process
[18:21] <tedg> greyback_, Basically provides a way to get info on the cgroup.
[18:21] <greyback_> gotcha
[18:23] <greyback_> tedg: looks ok to me: http://pastebin.ubuntu.com/8566391/
[18:38] <tedg> greyback_, So not sure of any reason that'd be, we're kinda simple there just opening up a dbus connection to a well known path.
[18:38] <tedg> greyback_, We could make it an async callback, but not sure that'd make things less crazy.
[18:39] <greyback_> tedg: yeah, it's why I'm pretty confused why it's blocking there
[19:02] <mterry> jgdx, I can't reproduce the problem
[19:02] <mterry> jgdx, how often does it not work for you?
[19:02] <mterry> oh whoops we were talking in #ubuntu-touch, moving there
[19:12] <Saviq> tedg, you there?
[19:13] <tedg> Saviq, I am here.
[19:13] <Saviq> tedg, will we get the i-n branches under review today?
[19:13] <Saviq> tedg, also, what's with the settings MP, do we need it in the 10/16 image?
[19:14] <tedg> Saviq, I'm not sure about the indicator-network ones, that's Wellark's
[19:14] <tedg> Saviq, Which settings MP? The extreme volume one?
[19:14] <Saviq> tedg, obviously meant i-sound
[19:14] <Saviq> tedg, yes
[19:14] <tedg> Saviq, If that's it... need is strong... it puts the warning in the settings. Incase you didn't notice the notification and the menu.
[19:15] <tedg> Uhg, LP timeout
[19:16] <Saviq> tedg, so the only beef I still have is that the bubbles come up when using the slider
[19:17] <Saviq> tedg, what we were thinking is that we should introduce explicit actions for vol+/vol- hw buttons instead of what we're doing now
[19:17] <tedg> Saviq, Eh, we could. But I'd rather get the open action implemented, we could use it in i-network as well.
[19:18] <Saviq> tedg, hmm but in theory that's not enough even, as the idea would be to never show the bubble if the slider was on screen, and that, I believe, you don't know for indicators, let alone in settings
[19:18] <Saviq> tedg, I think I don't know what's that, in any case, that's a relatively minor beef, you tell me if it's possible to at least not show the bubbles when sound indicator is open
[19:19] <tedg> Saviq, If we had the open action we'd know for indicators for sure. We could query the focused app as well.
[19:19] <tedg> Saviq, My thought is that it's fine to have both for the 10/16 image. We should fix it, but not critical.
[19:19] <Saviq> ah open action meaning whether the indicator is open, understood
[19:19] <Saviq> and settings could very well set it as well
[19:20] <tedg> Yup
[19:20] <Saviq> tedg, I do think we should have explicit vol+/vol- actions in any case
[19:20] <tedg> Saviq, Makes sense, so we can handle stepping differently as well.
[19:20] <Saviq> tedg, as I imagine it's not always going to be just currentVol +/- 0.1
[19:20] <Saviq> tedg, exactly, especially for alert
[19:20] <Saviq> there should only be maybe 4 steps
[19:21] <tedg> We could do logarithmic buttons! /me logs a critical bug
[19:21] <Saviq> ;)
[19:24] <Saviq> tedg, so you're saying I should test the indicator in utopic as well...
[19:26] <tedg> Saviq, We should, I haven't verified that yet. Focused on the rtm landing.
[19:27] <Saviq> tedg, right, I'll kick a build, and since we're landing into rtm separately, we'll do the testing for utopic separately
[19:27] <Saviq> tedg, while the rtm landing can go in
[19:33] <Saviq> mzanetti, you still lurkin'?
[19:37] <Saviq> Wellark, should the autopilot test for i-n work?
[19:37] <mzanetti> Saviq: yeah... packed my stuff for tomorrow
[19:37] <Wellark> Saviq: no, forget about it
[19:38] <Wellark> if it doesn't then bohoo
[19:38] <mzanetti> Saviq: what up?
[19:38] <Wellark> will fix it next week
[19:38] <Saviq> mzanetti, guess what, could you please rebase the test branch for utopic on shared model?
[19:38] <Saviq> as you did with rtm already
[19:43] <mzanetti> Saviq: this one? https://code.launchpad.net/~mzanetti/unity8/fix_snap_decision_test/+merge/238238
[19:44] <Saviq> mzanetti, yes
[19:44] <Saviq> mzanetti, there's a small conflict in tst_Shell.qml
[19:49] <mzanetti> Saviq: https://code.launchpad.net/~mzanetti/unity8/fix_snap_decision_test/+merge/238494
[19:50] <mzanetti> Saviq: wait. mistake
[19:51] <Saviq> mzanetti, looks good, no?
[19:52] <mzanetti> Saviq: yes, now it is
[19:52] <Saviq> mzanetti, kk
[19:52] <Saviq> mzanetti, thanks a bunch
[19:53] <mzanetti> Saviq: nw. how's the image going? keeping you still busy?
[19:53] <Saviq> mzanetti, just testing now
[19:53] <Saviq> mzanetti, and is looking good, no issue found yet
[19:54] <mzanetti> great. is this rtm still?
[19:54] <Saviq> yeah, rtm; well, davmor2 found one http://people.canonical.com/~davmor2/oops.png that I submissively took blame for
[19:56] <mzanetti> the string?
[19:59] <davmor2> Saviq: and the non translated strings in the indicators don'tforget them
[19:59] <Saviq> mzanetti, yeah
[20:16] <Saviq> tedg, I dropped settings from silo 6 as it's going in now, we'd need a separate silo for it if we need it in
[20:28] <tedg> Saviq, K
[20:28] <Saviq> tedg, but IMO it could be left out for now, as you get the bubble in your face in any case
[20:28] <tedg> Saviq, Yeah, I'll look to land via utopic, etc. Normal stuff.
[20:29] <Saviq> tedg, yup, cool beanz
[20:56] <Saviq> tedg, there's conflicts in indicator-sound in utopic silo 26 https://ci-train.ubuntu.com/job/ubuntu-landing-026-1-build/9/console
[20:59] <tedg> That's confusing.
[20:59] <tedg> They're both up-to-date on trunk.
[21:02] <Saviq> tedg, criss-cross
[21:03] <tedg> Sure, but that shouldn't break this case.
[21:03] <Saviq> tedg, but yeah, confusing
[21:03] <Saviq> what's more confusing is that the train can't seem to keep its logs straight, they're interleaved
[21:05] <tedg> Yeah, but I can recreate this one.
[21:05] <tedg> Saviq, So it seems if you drop the sync branch and just do the warning one it's fine.
[21:05] <tedg> Saviq, Let's just do that, it'll pull all the same diffs.
[21:06] <Saviq> tedg, ok, will do, just kicked a build of the rest and will do i-s after that
[21:43] <tedg> Saviq, Why are we putting the dash under suspend/resume?
[21:43] <tedg> Can it not just handle not sucking resources itself?
[21:43] <tedg> greyback_, ^
[21:44] <greyback_> tedg: apparently not
[21:45] <tedg> We trust it to no spawn processes and a billion other things. Seems like it's a "trusted helper" more than a "managed app".
[21:47] <tedg> greyback_, Wait, are we suspend/resuming it or just adjusting it's OOM value?
[21:47] <greyback_> tedg: we suspend/resume it & adjust OOM
[21:48] <tedg> greyback_, So for cases like it getting OOM'd do we re-sigstop the new process?
[21:48] <greyback_> tedg: well it should really not be OOM'd at all
[21:49] <greyback_> but if it is, and is respawned, then yeah it should be re-sigstoppped
[21:49] <tedg> greyback_, If we're adjusting the OOM value to more than the focused app, the focused app can kill it at will.
[21:51] <greyback_> tedg: We just want it so that dash is less likely than the app to be killed. I don't follow your last statement
[21:52] <tedg> greyback_, So we're not dynamically setting it?
[21:55] <greyback_> tedg: we do. Dash is still set at a lower OOM value than the app though, when app focused. (lower=less likely to be killed).
[21:56] <tedg> greyback_, So, for example, the focused app is 100, the unfocused app is 1000, unity 8 is 0. We're toggling the dash between 10 and 90 ?
[21:57] <greyback_> tedg: if dash focused, it is 100. If dash not focused, it is 200
[21:57] <tedg> greyback_, So we're adjusting it so the dash is more likely to be killed than the app.
[21:57] <tedg> If the app is focused.
[21:57] <greyback_> tedg: yep, but still less likely than unfocused apps
[21:58] <tedg> greyback_, Why can't we just set the dash at 200. Then if no apps are focused, they'll all be 1000.
[21:59] <tedg> There'll be no 100.
[21:59] <greyback_> tedg: and if there is a focused app?
[21:59] <greyback_> what OOM does it get?
[21:59] <tedg> 100
[22:01] <greyback_> tedg: would probably work for phone
[22:01] <greyback_> and I can't see an issue with tablet either
[22:04] <tedg> Less moving parts.
[22:04]  * tedg hates on cars for a moment