[00:02] <Saviq> mterry, 002
[00:02] <mterry> Saviq, awesome, thanks
[00:03] <Saviq> mterry, but looks like the build failed
[00:03] <mterry> Saviq, curious.  Will look
[00:03] <Saviq> or the fooking SSO tricked me :/
[00:03] <mterry> Saviq, 002?  looks fine.  arm64 failed, but I think that's normal
[00:04] <Saviq> mterry, yeah, but just mir
[00:04] <Saviq> mterry, should've been all built by now
[00:04] <mterry> Saviq, I see
[00:05] <Saviq> mterry, I kicked the build for real now
[00:05] <Saviq> stoopid SSO :|
[08:16] <tsdgeos> Saviq: ping
[08:16] <Saviq> tsdgeos, pong
[08:16] <tsdgeos> Saviq: autopilot tests are run with powerd forcing the display to be on, right?
[08:17] <Saviq> tsdgeos, on devices, yeah
[08:17] <tsdgeos> Saviq: that's bad for last mterry's test
[08:17] <tsdgeos> in https://code.launchpad.net/~mterry/unity8/hide-greeter-on-focus-request/+merge/201817
[08:17] <tsdgeos> i just ran it with "powerd-cli display on" and it fails
[08:17] <tsdgeos> but without it, it works fine
[08:17] <tsdgeos> any idea how to overcome that?
[08:19] <Saviq> tsdgeos, right... I think we should just lock regardless of the powerd-cli override...
[08:20] <Saviq> tsdgeos, ah but we're not listening to the power key directly, but through powerd, which doesn't change the state (even though it actually turns the display off)
[08:20] <tsdgeos> right
[08:20] <tsdgeos> us listening directly to powerd
[08:21] <tsdgeos> and then forcing powerd to be on
[08:21] <Saviq> kind of beats the purpose, yeah
[08:21] <tsdgeos> is kind of contradicting with the test :D
[08:21] <Saviq> I'll chat with Michael later
[08:22] <tsdgeos> okidoki
[08:55] <tsdgeos> Saviq: i'm confused as to how https://code.launchpad.net/~paulliu/unity8/zoomImage/+merge/207941 is building in CI if it doesn't build here
[08:55] <tsdgeos> any idea?
[08:55] <tsdgeos> ah
[08:55] <tsdgeos> CI is automerging with trunk
[08:55] <tsdgeos> right?
[08:55] <tsdgeos> makes sesne
[08:56] <Saviq> tsdgeos, yeah, always, when looking at branches, merge on top of trunk
[08:56] <tsdgeos> sure i do that, didn't remember CI did it
[08:57] <Saviq> kies
[09:06] <Cimi> Saviq, I think I'll patch unity-mir in a different way
[09:07] <Cimi> Saviq, how about checking if the upstart job is unity 8 || UNITY_MIR_EXPECTS_SIGSTOP == "1" ?
[09:07] <Saviq> Cimi, why leave the upstart job is unity8, let's just make the unity8 job require ↑
[09:07] <Cimi> Saviq, in case something fucks up in unity8 job
[09:08] <Cimi> and the variable doesn't get properly set
[09:10] <tsdgeos> anyone knows why lokcing while on run_on_device always makes unity8 crash?
[09:10] <Saviq> Cimi, why would something fuck up there?
[09:10] <tsdgeos> and how hard would that be for that to be fixed?
[09:10] <Saviq> tsdgeos, hwc?
[09:10] <tsdgeos> yeah
[09:11] <Cimi> Saviq, I'm not a fan of this upstart so far :D
[09:11] <Saviq> Cimi, you're not a fan of many things :P
[09:11] <Saviq> tsdgeos, I wonder if we're not conflicting with u-s-c...
[09:11] <Cimi> Saviq, Chicago pizza among these
[09:11] <Cimi> :D
[09:11] <Saviq> tsdgeos, we actually should make run_on_device run it through upstart...
[09:12] <Cimi> did you guys got to the hotel safe?
[09:12] <Saviq> Cimi, yeah, we're good, thanks ;)
[09:12] <Cimi> I died of headache straight after :)
[09:12] <Saviq> tsdgeos, otherwise we'll fall into the "we're running under a different env" issue again and again
[09:12] <tsdgeos> Saviq: trueth
[09:13] <Saviq> tsdgeos, and it's enough to go "restart unity8 BINARY=shell/builddir/unity8" to have it run under upstart
[09:13] <Saviq> tsdgeos, then, tail ~/.cache/upstart/unity8.log... and trap ctrl+C to "restart unity8" again
[09:14] <Saviq> should be doable
[09:16] <Saviq> tsdgeos, that should be done in the "run" script actually, so that we do the same on desktop
[09:16] <tsdgeos> ok, i'll have a quick look
[09:17] <Saviq> tsdgeos, check `initctl status unity8` first, and start/stop if it wasn't running, restart if it was
[09:17] <Cimi> Saviq, what happens if we run the binary unity8 and not the upstart job?
[09:18] <Saviq> Cimi, it fails
[09:18] <Saviq> Cimi, 'cause it doesn't know about u-s-c, for example
[09:20] <Saviq> Cimi, and basically it runs under a different environment, and conflicts with the currently running one
[09:20] <Saviq> we don't want that
[09:20] <Cimi> mope
[09:20] <Cimi> nope
[09:21] <Cimi> Saviq, btw I want to learn C++, throw me bugs in the future
[09:29] <tsdgeos> mzanetti: ping
[09:29] <mzanetti> tsdgeos: pong
[09:29] <tsdgeos> mzanetti: any idea why we have testlistviewwithpageheader target but not xvfbtestlistviewwithpageheader ?
[09:30] <mzanetti> tsdgeos: hmm... there should...
[09:30] <tsdgeos> i guess i did something weird in tehre
[09:30] <mzanetti> give me a few minuts and I'll check/fix
[09:33] <tsdgeos> mzanetti: thanks :)
[09:38] <Cimi> Saviq, unity8 job will NEVER start until the post-script of the wizard ended?
[09:38] <Saviq> Cimi, what starts the unity8 job?
[09:39] <Cimi> start on ((xsession SESSION=ubuntu-touch) or (xsession SESSION=ubuntu-touch-surfaceflinger)) and started dbus
[09:39] <Cimi> Saviq, I am worried about races and conflicts with env variables
[09:39] <Saviq> Cimi, when does the session start?
[09:40] <Cimi> question for mterry
[09:40] <Cimi> !
[09:40] <Cimi> but wizard starts on         initctl unset-env UNITY_MIR_EXPECTS_SIGSTOP
[09:40] <Cimi> nope
[09:40] <Cimi> start on starting xsession-init
[09:41] <Cimi> but wizard is started with exec ubuntu-touch-session system-settings-wizard
[09:41] <Cimi> maybe I don't need this ubuntu-touch-session
[09:42] <Cimi> terminator is AWESOME btw when working with multiple projects and adb
[09:47] <Saviq> tsdgeos, sorry for the late notice... we're having the new header catchup in 15 mins
[09:47] <tsdgeos> Saviq: ok, when how where?
[09:47] <tsdgeos> when in 15 mins :D
[09:47] <Saviq> tsdgeos, I'll do a hout
[09:48] <Saviq> will let you know when we find a room
[09:48] <tsdgeos> ok
[09:51] <Cimi> Saviq, whgat does what():  Exiting Mir! Reason: Nested Mir and Host Mir cannot use the same socket file to accept connections! mean?
[09:51] <Cimi> Saviq, the addition of the wizard kills unity8
[09:51] <Saviq> Cimi, isn't it clear English?
[09:51] <Cimi> it has to be something to do with the variables
[09:52] <Saviq> Cimi, we resolved that yesterday
[09:52] <Cimi> Saviq, well I updated the jobs but still doesn't work
[09:52] <Saviq> Cimi, means both MIR_SOCKET and UNITY_MIR_SOCKET point at the same file
[09:52] <Cimi> Saviq, so basically after the wizard starts, unity8 starts
[09:52] <Cimi> Saviq, but then I reboot
[09:53] <Cimi> and next time the pre-start script of the wizard does not run
[09:53] <Cimi> and unity8 has this error
[09:53] <Cimi> this is my unity8.conf http://paste.ubuntu.com/7230074/
[09:53] <Saviq> Cimi, sounds like the pre-start of wizard mangles stuff
[09:54] <Saviq> Cimi, print out initctl list-env --global | grep MIR in unity8 pre-start
[09:54] <Cimi> and this my wizard http://paste.ubuntu.com/7230075/
[09:54] <Cimi> yup
[09:59] <Cimi> mmm
[09:59] <Cimi> [ -e $HOME/$RUN_FILE ] && stop || true
[10:00] <Cimi> Saviq, despite ^, the pre-start script continues
[10:00] <Cimi> the file does exist
[10:03] <Cimi> can it be that stop returns false?
[10:04] <Cimi> unless the pre-start script runs either way
[10:26] <mzanetti> tsdgeos: https://code.launchpad.net/~mzanetti/unity8/fix-lwvph-xvfb/+merge/215139
[10:26] <tsdgeos> mzanetti: while you're at it, can do do the organicgrid and stuff that is below in that file
[10:27] <tsdgeos> seems it doesn't work either
[10:27] <mzanetti> tsdgeos: sure
[10:27] <tsdgeos> tx :)
[10:29] <Saviq> Cimi, http://upstart.ubuntu.com/cookbook/#stop-a-job-that-is-about-to-start-from-within-that-job
[10:30] <Saviq> Cimi, not sure you need the || true
[10:30] <Cimi> Saviq, well
[10:30] <Cimi> Saviq, I now put everything under if else
[10:30] <Cimi> and works
[10:30] <Cimi> Saviq, basically [ -e $HOME/$RUN_FILE ] && stop || true
[10:30] <Saviq> Cimi, but yeah, I think "stop" does not return
[10:30] <Cimi> Saviq, prevent the exec
[10:31] <Saviq> Cimi, you'd need a stop && exit
[10:31] <Cimi> but the pre-start script runs ALL
[10:31] <Saviq> Cimi, and yeah, if/else works, too
[10:31] <Saviq> Cimi, "stop" is just a command, it doesn't actually exit the script
[10:31] <Cimi> Saviq, probably exit is better?
[10:31] <Saviq> Cimi, both are fine
[10:32] <Cimi> because then in stop I have check for file
[10:32] <Cimi> Saviq, exit exits upstart or the scripot?
[10:33] <om26er> running unity8 autopilot on the device takes ages, I wonder why does it keep waiting for unity8 to stop for a long time ?
[10:34] <Saviq> om26er, unity8 stop isn't really optimized...
[10:34] <Saviq> om26er, sometimes it takes a half minute or so for it to exit
[10:35] <Saviq> om26er, we just never had time to look at it
[10:35] <om26er> Saviq, aah, it will help your MRs get CI approve quicker ;)
[10:36] <Saviq> om26er, I know, I know ;)
[10:38] <tsdgeos> MacSlow: ping
[10:38] <om26er> took ~2000 seconds
[10:39] <MacSlow> tsdgeos, yup
[10:40] <tsdgeos> MacSlow: do https://code.launchpad.net/~macslow/unity8/modal-snap-decisions/+merge/210988 and https://code.launchpad.net/~macslow/unity-notifications/modal-snap-decisions need to land at the same time? Or should unity-notifications land first and then unity8? or?
[10:42] <MacSlow> tsdgeos, lp:~macslow/unity-notifications/modal-snap-decisions should go in first
[10:43] <tsdgeos> MacSlow: and who has to review that? us? or some other team?
[10:43] <MacSlow> tsdgeos, since there are no consumers of modal snap-decisions yet it not so critical... but the unity-notifications branch first would be nicer
[10:44] <MacSlow> tsdgeos, we ... nobody from the api-team is really that involved in lp:unity-notifications
[10:45] <MacSlow> tsdgeos, "on paper" it's the api-team... "in practise" it's us :)
[10:45] <tsdgeos> ok :/
[10:45] <tsdgeos> so i'll do it i guess?
[10:45] <MacSlow> tsdgeos, that would be great... ping me if any questions arise
[10:48] <tsdgeos> sure
[10:59] <tsdgeos> MacSlow: What does the  Q_ENUMS(Roles) in NotificationModel ?
[11:01] <MacSlow> tsdgeos, that's got to be an overlooked left over
[11:01] <MacSlow> tsdgeos, since this is coming from unity-api now
[11:01] <tsdgeos> MacSlow: kill it!
[11:04] <MacSlow> tsdgeos, done
[11:06] <Cimi> Saviq, https://code.launchpad.net/~cimi/unity8/unity8.upstart_unity-mir_variables/+merge/215152
[11:07] <mzanetti> tsdgeos: this one reliably fails for me: test_show_scope_on_load
[11:07] <Cimi> greyback, https://code.launchpad.net/~cimi/unity-mir/unity-mir.stop-server_wizard/+merge/214983
[11:09] <tsdgeos> mzanetti: using xvfb or not or don't matter?
[11:10] <mzanetti> tsdgeos: in any case
[11:10] <tsdgeos> let me see
[11:11] <mzanetti> tsdgeos: jfi: http://paste.ubuntu.com/7230296
[11:11] <jfi> mzanetti, Hi, hum, what should I see in this log?
[11:12] <mzanetti> jfi: heh, sorry... that should have been a "just for information" to tsdgeos :)
[11:12] <tsdgeos> lol
[11:13] <jfi> haaa :)
[11:14] <tsdgeos> mzanetti: i'm going to claim "SDK"
[11:14] <tsdgeos> here
[11:14] <tsdgeos> people reverted stuff and then reverted some stuff
[11:15] <tsdgeos> and yeah test doesn't pass
[11:15] <tsdgeos> Saviq: and this is why you don't do archive uploads
[11:15] <tsdgeos> because suddenly our tests stop passing
[11:16] <Saviq> tsdgeos, it's getting into our trunk with the next landing
[11:16] <Saviq> i.e. today
[11:16] <tsdgeos> didrocks: can you please set a commit message and to make CI happy in https://code.launchpad.net/~didrocks/unity8/backport-latest-release/+merge/215100
[11:16] <Saviq> tsdgeos, you can
[11:16] <tsdgeos> mzanetti: basically you need https://code.launchpad.net/~didrocks/unity8/backport-latest-release/+merge/215100
[11:17] <Saviq> tsdgeos, done
[11:17] <mzanetti> tsdgeos: ack, thanks
[11:17] <tsdgeos> Saviq: i know i can, but there's the tale about free fishes vs explaining how to fish
[11:17] <Saviq> tsdgeos, ;)
[11:22] <mzanetti> tsdgeos: do we need to have different qml (try vs test) files for OrganicGrid? that doesn't work with all the macros we have
[11:24] <tsdgeos> mzanetti: they are different now, i guess with some work they could be not different
[11:24] <mzanetti> tsdgeos: I have converted the cmake stuff to use the macros. test and xvfbtest works, but try fails to find the file currently. Would you mind taking care of that?
[11:25] <mzanetti> I'll push to a unity-team branch
[11:25] <tsdgeos> ok
[11:27] <mzanetti> tsdgeos: lp:~unity-team/unity8/fix-lvwph-xvfb
[11:27] <tsdgeos> tx
[11:31] <didrocks> tsdgeos: there is a commit message, right?
[11:31] <didrocks> (or someone did it)
[11:36] <tsdgeos> didrocks: Saviq did add it
[11:39] <Cimi> dednick, jenkins does not merge this? https://code.launchpad.net/~nick-dedekind/ubuntu-settings-components/access-point-init/+merge/212913
[11:39] <dednick> Cimi: no idea
[11:42] <tsdgeos> mzanetti: that's not going to fly, you're not even compiling my try.cpp file either
[11:45] <tsdgeos> i'll do some cmake-ry
[11:45] <tsdgeos> let's see if you like it later ^_^
[12:36] <mzanetti> tsdgeos: right... if you're too busy I can probably make it happen tomorrow or early next week
[12:38] <Saviq> Cimi, no, it's under ci train
[12:44] <Saviq> Cimi,  "* Are there any related MPs required for this MP to build/function as expected? Please list.
[12:44] <Saviq> No"
[12:44] <Saviq> Cimi, what about the unity-mir change?
[12:44] <Saviq> Cimi, you need to fix the upstart integration AP test
[13:25] <mterry> Saviq, I see that silo 002 continues to be a punk
[13:27] <Saviq> mterry, does it, /me looks
[13:27] <Saviq> :|
[13:28] <Saviq> mterry, ah crap, unity8
[13:28] <mterry> Saviq, does it need merging or some such?
[13:28] <Saviq> mterry, /me fixes
[13:28] <Saviq> mterry, https://code.launchpad.net/~didrocks/unity8/backport-latest-release/+merge/215100
[13:29]  * Saviq builds stuff one by one, can't be bothered to loose so much time due to just one project :|
[13:29] <mterry> huh
[13:30] <Saviq> mterry, we had a revert go straight into distro, not yet landed (about to, though)
[13:30] <Saviq> mterry, but also, after a change some two weeks ago, the job only uploads in bulk, if all the projects complete the source package build
[13:31] <Saviq> mterry, before it would upload straight after it completed per-project, but the release team requested it to be changed
[13:31] <mterry> hmm, ok
[13:32] <mzanetti> MacSlow: https://bugs.launchpad.net/unity8/+bug/1305885
[13:34] <MacSlow> mzanetti, hm... not sure yet how to do it... I'll look into it once I've done eMails
[13:50] <mterry> Cimi, so I was playing with launching the wizard from split greeter mode
[13:50] <mterry> Cimi, did I ping you about that yesterday?
[13:50] <tsdgeos> mzanetti: at the end i did it from scratch, hope you don't mind ^_^, that way you can review it even if maybe I ended up with similar solutions to what you did
[13:51] <Cimi> mterry, yes
[13:51] <mzanetti> tsdgeos: sure, no problem
[13:51] <mterry> Cimi, does the wifi branch need a further review?
[13:52] <tsdgeos> pete-woods: hud is at 100% again, is there a log you added to help find out who was the culprit?
[13:53] <Cimi> mterry, yes but still hold on
[13:54] <MacSlow> mterry, boot-anim is done
[13:54] <mterry> MacSlow, saw your email!  Awesome
[13:55] <Cimi> mterry, ok it's fine now
[13:55] <tsdgeos> pete-woods: " Hit DBusMenu safety valve for menu at :1.119 /MenuBar/1 "
[13:55] <tsdgeos> this one?
[13:56] <Cimi> seb128, mterry https://code.launchpad.net/~unity-team/ubuntu-system-settings/wizard.wifi/+merge/212675
[13:59] <pete-woods> tsdgeos: can you look up the process with d-feet?
[13:59] <tsdgeos> pete-woods: it's kontact
[13:59] <tsdgeos> pete-woods: but i run kontact every day
[13:59] <tsdgeos> and after killing hud-service is back to normal
[14:00] <pete-woods> tsdgeos: which version of HUD are you on, btw?
[14:00] <tsdgeos> whatever is on trusty
[14:00] <pete-woods> so definitely latest then?
[14:00] <tsdgeos> 13.10.1+14.04.20140402-0ubuntu1
[14:00] <pete-woods> bah, I can't understand how that could be going crazy even with the safety valve in place
[14:01] <tsdgeos> :/
[14:01] <pete-woods> tsdgeos: were you using kontact at the time?
[14:01] <tsdgeos> well it runs all the time, it's my email client of choice
[14:03] <tsdgeos> mterry: seen my comments on https://code.launchpad.net/~mterry/unity8/greeter-ux-fixes/+merge/210042 ?
[14:03] <mterry> tsdgeos, looking
[14:07] <pete-woods> tsdgeos: fair enough, well at least I have an app I can have a look at for debugging now :)
[14:08] <tsdgeos> MacSlow: ping
[14:15] <tedg> Saviq, paulliu, What priority do you guys see bug 1302213 as having?
[14:15] <Saviq> tedg, in progress
[14:16] <MacSlow> tsdgeos, yup
[14:16] <tsdgeos> MacSlow: how do i test manually https://code.launchpad.net/~macslow/unity8/modal-snap-decisions/+merge/210988 ?
[14:16] <paulliu> tedg: I'm working on that right now.
[14:16] <tsdgeos> MacSlow: i.e. the stuff you have in the video
[14:16] <tedg> Saviq, Okay, so should we start looking to implement it in indicator-session?
[14:16] <tsdgeos> MacSlow: also did a small comment
[14:16] <tedg> Ah, sounds like yes.
[14:16] <paulliu> tedg: I'm currently adding a plugin inside Unity8
[14:17] <tedg> paulliu, Cool, thanks!
[14:17] <charles> paulliu, \o/
[14:17] <MacSlow> tsdgeos, to test you just trigger any of the sd-example-*.py from lp:unity-notifications/examples...
[14:17] <Saviq> paulliu, put it in unity-mir instead
[14:18] <tsdgeos> MacSlow: ok
[14:18] <MacSlow> tsdgeos, when on the greeter no input-blocking tinted background should appear... when on the normal shell/dash it should
[14:18] <Saviq> paulliu, no need to introduce a new plugin
[14:18] <paulliu> Saviq: hmm. ok
[14:18] <MacSlow> tsdgeos, collapsing the two lines you mentioned
[14:18] <Saviq> greyback, can you point paulliu if there's a place already where it'd make sense to put it ↑?
[14:20] <charles> paulliu, so it's going to be the three-argument KDE style logout function at /com/canonical/Unity, yes? What interface name should indicator-session refer to?
[14:21] <paulliu> charles: yes. /com/canonical/Unity/Logout
[14:21] <greyback> paulliu: hey
[14:21] <paulliu> greyback: hi
[14:21] <charles> paulliu, ty :)
[14:22] <paulliu> Saviq: what's unity-mir? I just branched it and reading the source.
[14:22] <MacSlow> tsdgeos, fixed
[14:22] <greyback> paulliu: I think you can add it to the ApplicationManager QML plugin, so lp:unity-mir:src/modules/Unity/Application/application_manager.h
[14:22] <tsdgeos> MacSlow: tx :)
[14:23] <tsdgeos> MacSlow: i had two autopilot failures http://paste.ubuntu.com/7230988/
[14:23] <tsdgeos> let me run again
[14:23] <paulliu> greyback: ok. Let me read the source.
[14:23] <greyback> paulliu: unity-mir enables unity to run as a mir server, launch/monitor&stop apps, and control app surfaces (hide/bring to front)
[14:24] <paulliu> greyback: ok. got it.
[14:24] <MacSlow> tsdgeos, well last time I tried it everything was fine... but that some days ago... I've to pull all pieces in again and see for myself.
[14:24] <Saviq> paulliu, a little bit more info: https://bugs.launchpad.net/unity8/+bug/1302213/comments/4
[14:24] <greyback> paulliu: any questions, please poke me
[14:25] <paulliu> Saviq, greyback, ok. thanks
[14:26]  * MacSlow wonders who'd be a good person to ask for help regarding mumble
[14:27] <tsdgeos> MacSlow: yep, two same errors on a rerun, so please have a look
[14:27] <Saviq> MacSlow, #is I'd say
[14:28] <MacSlow> Saviq, same issue since the start of the week... I'll add my notes to the stand-up doc
[14:29] <tsdgeos> MacSlow: did you change your canonical SSO password? I found once that the syncs to mumble apssword are monthly or something
[14:29] <tsdgeos> so you won't remember you had changed your password
[14:29] <tsdgeos> and then mumble will stop working
[14:29] <mterry> tsdgeos, replied
[14:29] <mterry> (to greeter-ux-fixes comments)
[14:31] <MacSlow> tsdgeos, no... didn't touch that
[14:32] <tsdgeos> mterry: ok, i still think that the hinting animation there all the time is a bit weird, but if it's on purpose, let's get it to more people and see how many comments we get from the world :)
[14:32] <mterry> tsdgeos, yeah I suspect there will be some pushback honestly.  But design said they wanted to try it this way first
[14:32] <Saviq> MacSlow, k
[14:38] <mardy> it must be a change in the unity8, let's talk in freenode/#ubuntu-unity
[14:38] <mardy> ops :-)
[14:40] <mardy> Saviq: hi! :-) In the recent images, when an application window is closed, one is back to the apps lens, rather than to the last used app; I guess this is intentional?
[14:42] <Saviq> mardy, quit as in from the app itself?
[14:42] <Saviq> mardy, sounds related to bug #1305128
[14:43] <Saviq> greyback, ↑ another behaviour change with right-edge :/
[14:43] <tedg> charles, paulliu, it looks like Unity7 added a session interface, could we use that? http://bazaar.launchpad.net/~3v1n0/indicator-session/unity-session/view/head:/src/backend-dbus/com.canonical.Unity.Session.xml
[14:43] <tedg> Trevinho, ^
[14:43] <mardy> Saviq: yes, from the app itself
[14:43] <Trevinho> tedg: yeah, I hope so, I'm fixing the tests right now
[14:44] <Trevinho> tedg: I've to fix the things for restarting (and showing proper dialog), but I will
[14:44] <tedg> Trevinho, To give you some context, we were talking about what to do in Unity8. I was thinking being the same would be good.
[14:44] <paulliu> tedg: ok. I can use this.
[14:45] <Saviq> mardy, please comment on the bug, Gerry is looking into it
[14:45] <tedg> paulliu, Cool, charles, work for you?
[14:47] <Trevinho> tedg: yeah, I imagined that :)
[14:48] <mterry> Cimi, looks like you left a debugging comment in: console.log("quit");
[14:48] <bfiller> mardy: is this the issue when creating a google account the UI switches back to the dash when you press the login button?
[14:48] <Trevinho> tedg: not sure the api is complete, but this is the introspection so far http://pastebin.ubuntu.com/7231097/
[14:48] <Trevinho> tedg: it has some things thare are still somewhat related to gnome-session internal usage, but it can be cleaned up
[14:48] <tedg> Trevinho, Oh, wow, why are you duplicating all the logind stuff?
[14:49] <charles> tedg, paulliu, that's fine, I take it RequestLogout / RequestReboot / RequestShutdown do not prompt for confirmation?
[14:49] <charles> the "LockPrompt" method hints that prompting methods would use that suffix in their name
[14:50] <charles> tedg: nice find, btw
[14:50] <Trevinho> tedg: well, it just provides calls to our SessionManager... And while is not ufficially supported, ad that point I just made available all the features we have :)
[14:50] <Cimi> mterry, I repushed
[14:50] <tedg> Trevinho, Heh, okay. But we should probably be careful to not have too much API to support into the future.
[14:50] <tsdgeos> mterry: the "darkening" when pulling from left including the launcher is very weird
[14:50] <tsdgeos> give it a try
[14:50] <tedg> Trevinho, Would hate to have people start depending on it.
[14:51] <mardy> bfiller: yes
[14:51] <mterry> tsdgeos, it is?
[14:51] <mterry> let me play with it again
[14:51] <Trevinho> tedg: yeah, indeed... but I guess people will expect breakage anyway when switching away from u7
[14:51] <tsdgeos> mterry: so it is clear as you drag it, but then release and goes to a few different stages of dark
[14:51] <bfiller> mardy: why is the app trying to close when you press the login button?
[14:52] <tedg> Trevinho, Heh, you don't want an angry OMG! Ubuntu! story do you? ;-)
[14:52] <mterry> tsdgeos, ah yeah, the "launcher fully out" dark on top of the greeter?
[14:52] <tsdgeos> mterry: no no
[14:52] <Trevinho> tedg: ahah, yeah, I'm pleasing the press :D
[14:53] <mterry> tsdgeos, ah...  if you actually log in
[14:53] <tsdgeos> mterry: so you pull from left, get the launcher out, keep pulling, dash appears and it's mostly "the correct color",
[14:53] <tsdgeos> mterry: but then you finish the move
[14:53] <tsdgeos> and things go dark, darker, clearerr
[14:53] <mardy> bfiller: because it's a different process; this is planned to change soon, though, so this shouldn't be an issue in the longer period
[14:53] <tsdgeos> or some weird combination
[14:53] <mterry> tsdgeos, we probably should not keep launcher out in that case.
[14:54] <tsdgeos> mterry: i don't know what should happen but that definitely feels weird.
[14:54] <mterry> tsdgeos, I see what you mean now.  I'll see if I can't make that more natural (and launcher shouldn't stay up anyway)
[14:55] <tsdgeos> mterry: ok :) want a comment in the MR as a reminder?
[14:55] <mterry> tsdgeos, sure, I could get hit by a bus and we don't want to forget it  :)
[14:55] <tsdgeos> :P
[14:58] <tsdgeos> mterry: also you need to run make pot_file to get the new text into the pot file
[14:58] <mterry> tsdgeos, I thought that was done separately from the MPs?
[15:03] <tsdgeos> mterry: oyu mean automatically?
[15:03] <tsdgeos> i don't think so
[15:03] <tsdgeos> but i may be wrong
[15:03] <mterry> tsdgeos, huh ok
[15:03] <tsdgeos> Saviq: we have to run pot_files manually, right?
[15:03] <tsdgeos> mterry: i'd love it to be run automagically
[15:06] <Saviq> tsdgeos, yeah, but if they'd run automagically, you'd get them change with every commit
[15:06] <Saviq> tsdgeos, 'cause of line numbers...
[15:06] <tsdgeos> i know
[15:06] <Saviq> OTOH maybe we should update the line numbers...
[15:07] <tsdgeos> the script that does that is the commit champion of KDE :D
[15:07] <tsdgeos> Saviq: we should, the lines are there to help translators locate stuff, if they are out of sync they can cause confusion (if someone is actually using them)
[15:12] <Saviq> tsdgeos, then we're just missing ALL in the target
[15:13] <Saviq> tsdgeos, there was a reason, though, why we didn't want it there... :)
[15:13]  * Saviq hopes it was only that we didn't want it changing all the time...
[15:14] <tsdgeos> :D
[15:14] <mterry> Saviq, we could just run it automatically at release time
[15:14] <mterry> doesn't need to be every commit
[15:14] <tsdgeos> mterry: but then your release comes out with outdated translations no?
[15:14] <tsdgeos> your translators are always one version behind
[15:14] <mterry> tsdgeos, OK.  Animation + pot file update
[15:15] <mterry> tsdgeos, well that's true for how Ubuntu does things now.  Package hits archive, then translators get to play with it.  But the 6 month release cycle means that strings settle down near end
[15:16] <Saviq> tsdgeos, sounds like they are always behind with the CI train, 'cause there isn't an intermediate step...
[15:16] <tsdgeos> yeaps
[15:16] <Saviq> tsdgeos, unless, obviously, there was no i18n change
[15:17] <Saviq> tsdgeos, and well, you can do a only-i18n release when wanted
[15:18] <tsdgeos> ok
[15:21] <Saviq> tsdgeos, mterry, but yeah, we could (should) add a make-pot step before landing
[15:22] <Saviq> would have to be manual, though, unless we get a way to do hooks in the train or something
[15:22] <Saviq> doubt it'd happen for train, maybe for airline
[15:24] <tsdgeos> mterry: ok, approved :)
[15:24] <mterry> tsdgeos, thanks!
[15:25] <mterry> Saviq, I was testing the unity8 autopilot tests yesterday.  They seem like they fail.  Is that fixed / known?
[15:27] <mzanetti> tedg: hi, will UAL support starting apps by short appid?
[15:27] <tedg> mzanetti, It's on my todo, right now you can do it by constructing the full appid via the function in the lib.
[15:27] <mzanetti> tedg: ah ok. thanks
[15:28] <tedg> mzanetti, You can call it with NULL for any of the parameters and it'll fill out that for you.
[15:28] <tedg> Well, not package.
[15:28] <tedg> It can't guess that :-)
[15:28] <mzanetti> tedg: what's "package"?
[15:28] <mzanetti> teh "bar" in com.ubuntu.foo_bar_0.1.2 ?
[15:28] <Saviq> mterry, any one in particular?
[15:28] <tedg> mzanetti, The first of the triplet: $(package)_$(app)_$(version)
[15:29] <mzanetti> ah ok... so package is the only required basicall
[15:29] <mzanetti> which is the short appid
[15:29] <tedg> yeah, we'll choose the first app
[15:29] <mterry> Saviq, two lockscreen ones and two application lifecycle ones.  I lost my note with the precise names
[15:29] <tedg> No, short appid is $(package)_$(app)
[15:29] <tedg> It just trims off the version.
[15:29] <Saviq> mterry, what device?
[15:29] <mterry> Saviq, mako
[15:29] <Saviq> mterry, and that's trunk, or?
[15:30] <Saviq> mterry, I just ran a set pre-landing today, and was fine
[15:30] <mterry> Saviq, it was....  I think it was trusty
[15:30] <mterry> Saviq, OK, will try again
[15:30] <tedg> mzanetti, You can get the desktop files of the installed apps by short id by setting up a click hook.
[15:31] <mzanetti> yeah... finding the .desktop file is not that problematic... I'm just trying to figure how to distinguish stuff...
[15:32] <mzanetti> because sometimes we get appid:///com.ubuntu.foo/bar/current-user-version, sometimes, its application://something.desktop (which I guess can also contain _). and sometimes its the full appid
[15:47] <Cimi> mterry, got a chance to see?
[15:47] <mterry> Cimi, yeah, building now on phone
[15:51] <tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity8/run_upstart/+merge/215228
[15:51] <tsdgeos> works pretty well
[15:51] <Cimi> mterry, don't build on phone, so cross building
[15:51] <Saviq> tsdgeos, awesomes
[15:51] <Cimi> mterry, it's awesome
[15:51] <Cimi> *do
[15:52] <Saviq> tsdgeos, why 'tailf -n0'?
[15:52] <Saviq> tsdgeos, ah that won't show the previous lines?
[15:52] <tsdgeos> Saviq: because otherwise you get the log of the previous ru
[15:52] <Saviq> tsdgeos, yup
[15:52] <tsdgeos> it's totally confusing
[15:52] <Saviq> tsdgeos, hoped it was as simple as that, awesome
[15:53] <Saviq> tsdgeos, ah but wait
[15:53] <Saviq> tsdgeos, that will end up with no shell on phone when you ^C
[15:53] <Cimi> mterry, just follow instructions here https://wiki.ubuntu.com/SimpleSbuild
[15:54] <Saviq> tsdgeos, I meant: if(running) { was_running=true; stop unity8 } ... if (was_running) { start unity8 }
[15:54] <Saviq> tsdgeos, so that you replace the running one with the testing one, and go back to the original one when ^C
[15:54] <tsdgeos> Saviq: not really
[15:55] <tsdgeos> run_on_device does that already
[15:55] <tsdgeos> i was tempted to not even contemplate the case where unity8 is running tbh
[15:55] <tsdgeos> since run_on_device stops it
[15:55] <tsdgeos> and we don't usually have it running on the desktop
[15:56] <Saviq> tsdgeos, ah right, run_on_device is stopping it
[15:56] <Saviq> tsdgeos, maybe indeed not even stop it, but bail out if it's started already
[15:57] <tsdgeos> Saviq: that was what i originally had, ok will do
[15:57] <tsdgeos> pushed
[16:15] <mterry> Cimi, the keyboard isn't coming up for me
[16:15] <Cimi> mterry, do you have patched mir?
[16:15] <mterry> Cimi, oh no
[16:15] <mterry> i forgot that bit
[16:15] <Cimi> mterry, are you using sbuild to compile?
[16:15] <Cimi> it will take ages
[16:15] <mterry> Cimi, I have a Mir build lying around I can repurpose
[16:16] <mterry> Cimi, one nice thing about building on device
[16:16] <mterry> Cimi, wait, mir or unity-mir?  I see the referenced lp:~cimi/unity-mir/unity-mir.stop-server_wizard branch...
[16:17] <Cimi> mterry, unity mir
[16:17] <Saviq> mterry, cross-build, don't build everything on devices :P
[16:17] <mterry> Saviq, I should I know
[16:19] <Cimi> mterry, https://wiki.ubuntu.com/SimpleSbuild
[16:19] <mterry> I get it, I get it!  :)
[16:19] <Saviq> https://wiki.ubuntu.com/CrossBuilding ;D
[16:19] <Saviq> mterry, just kicked unity8 in split silo, should finally build fine
[16:31] <mterry> Cimi, hmm, with unity-mir now, I get no notification at all
[16:33] <Cimi> mterry, this might be due to something else
[16:33] <Cimi> mterry, remove previous network connections and reboot
[16:34] <mterry> Cimi, clear /etc/NetworkManager/system-connections/ you mean?
[16:34] <Cimi> mterry, right
[16:35] <mterry> Cimi, ok, now it's back yeah
[16:35] <Cimi> mterry, kbd?
[16:35] <Cimi> osk?
[16:36] <mterry> Cimi, came up...
[16:36] <mterry> seems to work
[16:36] <Cimi> good
[16:39] <mterry> Cimi, OK, I'm going look at actual code changes for comments there, but functionality seems correct
[16:39] <Cimi> good
[16:40] <mterry> Cimi, why the '.qml' enforcement?  Was that separate cleanup or needed for wifi?
[16:41] <Cimi> mterry, because it was going bad with all my backup files
[16:42] <Cimi> .~1~
[16:42] <Cimi> etce
[16:42] <Cimi> I realised we only need .qml files anyway
[16:42] <Cimi> at least check for extension
[16:42] <Cimi> and don't load everything inside the dir, png included
[16:42] <Cimi> as qml pages
[16:44] <mterry> Cimi, doesn't that break .disabled checking?
[16:44] <Cimi> mterry, it shouldn't
[16:44] <Cimi> but check if it does :)
[16:45] <Cimi> tests seem to pass
[16:45] <mterry> Cimi, tests pass, but I don't get how.  Looking at the PageList.cpp code
[16:46] <Cimi> mterry, first it adds pages that end with qml
[16:47] <Cimi> mterry, then checks for disabled files and removes the pages?
[16:47] <mterry> Cimi, but it checks for disabled pages among the list it collected before (those that end in .qml)
[16:47] <Cimi> so it shoudln't work
[16:48] <Cimi> mterry, well, you got the idea maybe requires a simple fix
[16:48] <mterry> Cimi, I guess we could collect .disabled files in the same first pass but in a different list, then go through that list after, removing the qml versions
[16:48] <mterry> Cimi, and this passes the test?
[16:48]  * mterry tries
[16:49] <Cimi> mterry, we can probably strip the extensions
[16:50] <Cimi> mterry, thing is
[16:51] <Cimi> mterry, disabled is added alongside the qml
[16:51] <mterry> Cimi, qDebug() << "before delete";
[16:51] <mzanetti> josharenson: https://bugs.launchpad.net/unity8/+bug/1269282
[16:52] <mterry> Cimi, we can't reuse the Notification.qml from unity8?
[16:52] <mzanetti> josharenson: https://bugs.launchpad.net/unity8/+bug/1302050
[16:53] <Cimi> mterry, you mean importing the file?
[16:53] <mterry> Cimi, yeah
[16:54] <mterry> Cimi, readonly property bool connected: mainMenu.connectedAPs [16:54] <Cimi> mterry, but what if unity chanes and we break?
[16:54] <Cimi> mterry, I don't think so
[16:56] <mterry> Cimi, why do we have a 1s delayed timer on quit?  We don't need to show that final loading screen.  If we're quitting, we can just drop that last page
[16:56] <mterry> (the spinner page)
[16:56] <Cimi> mterry, I liked it :D
[16:56] <mterry> Cimi, but we will have a USC spinner that takes its place
[16:56] <Cimi> mterry, I agree we can drop this with split
[16:57] <mterry> Cimi, but with this branch, it's just a fake spinner
[16:57] <mterry> no reason for it
[16:57] <mterry> Cimi, if unity8 changes its notification code, we want to pick those changes up, eh?
[16:57] <Cimi> feel free to push everything, I'll review later on
[16:57] <Cimi> mterry, but if they break us?
[16:58] <mterry> Cimi, that's what tests are for?  autopilot tests for the system settings
[16:58] <Cimi> mterry, eventually it will all go inside the menu
[16:59] <mterry> Cimi, and we use such a small part of their API -- Just a Notifications {} block with a model, right?
[16:59] <mterry> Cimi, not like that's going to break much
[17:01] <Cimi> mterry, it won't work easily now
[17:01] <Cimi> mterry, in fact we don't have it as a module in unity
[17:01] <Cimi> mterry, I'd just copy the files..
[17:02] <Cimi> mterry, will be back in ~2 hours
[17:02] <mterry> Cimi, yeah, test-page-list test isn't succeeding
[17:03] <mterry> Cimi, why can't we import?
[17:03] <Cimi> branch is ~unity-team if you want to push
[17:03] <mterry> Cimi, ok, see ya
[17:03] <Cimi> mterry, because we have to hook up the path
[17:03] <Cimi> mterry, it's not as a module
[17:03] <Cimi> like Unity.Dash.Notifications 0.1
[17:04] <Cimi> it's not automagically :D
[17:04] <Cimi> it's fine to keep our own copy and don't bother much
[17:04] <mterry> Cimi, but so much code duplication!
[17:04] <Cimi> all of this will go away when we have the password entry inside the listview
[17:04] <mterry> Cimi, figuring out the path seems easier than duplicating
[17:04] <Cimi> what we need to do though is copying the code for the tablet mode as well
[17:05] <Cimi> mterry, go ahead then!
[17:05] <mzanetti> josharenson: https://bugs.launchpad.net/unity8/+bug/1305885
[17:05] <Cimi> :P
[17:06] <mterry> Cimi, "patches welcome"
[17:06] <Cimi> :D :D :D
[17:06]  * Cimi runs away :D
[17:06] <mterry> Cimi, this isn't how reviews are supposed to go!  :)
[18:28] <mterry> Cimi, hmm, also ./wizard/test.sh doesn't work anymore with a mirserver
[18:55] <tedg> Saviq, Why are you stripping tags?
[19:25] <Saviq> tedg, because they're old, from lp:unity
[19:25] <Saviq> tedg, and they don't point at anything in lp:unity8
[19:26] <Saviq> tedg, not all, just the ones that don't make sense
[19:31] <tedg> Do they share a common history?
[19:35] <Cimi> mterry, let's remove it then
[19:35] <mterry> Cimi, shoot, I lost my scrollback, I forget what I said to you
 [19:28] Cimi, hmm, also ./wizard/test.sh doesn't work anymore with a mirserver
[19:36] <mterry> Cimi, ah.  Well.  I think it might work if you are running inside Mir and have MIR_SOCKET set correctly
[19:36] <mterry> Cimi, I made some commits!
[19:37] <mterry> Cimi, used unity8 Notifications, split out the wizard into its own package (since now we depend on unity-mir and unity8 stuff which the normal settings package doesn't want to
[19:37] <mterry> Cimi, dropped spinner (i know you liked it, but we shouldn't artificially delay, and it was a placeholder since it wasn't in original design)
[19:37] <mterry> Cimi, and cleaned up the code a bit (dropped debugs, fixed some FIXMEs)
[19:39] <Cimi> cool
[19:39] <Cimi> I'll have a look after dinner if my gf doesn't kill me
[19:40] <mterry> Cimi, oh and I restored .disabled support
[19:40] <mterry> Cimi, what do we need qtbase5-private-dev for?
[19:41] <Cimi> mterry, mmmmmmmmm
[19:41] <Cimi> something
[19:41] <Cimi> mmm
[19:41] <mterry> Cimi, I'll look.  it's late for you
[19:45] <Cimi> just remove it and see what breaks xD
[21:03] <Cimi> mterry, had a look, good!
[21:03] <mterry> Cimi, nice  :)   I also added the MP checklist junk to the description
[21:03] <Cimi> mterry, it is fine after all that code removed for dlopening mir lib?
[21:04] <mterry> Cimi, should be.  unity8 only did the dlopen stuff because it also supported non-mir use cases
[21:04] <mterry> like surfaceflinger
[21:04] <mterry> But we don't need that junk anymore
[21:04] <Cimi> mterry, we don't need the checklist :P
[21:04] <Cimi> mterry, it's not unity8 :P
[21:05] <mterry> Cimi, everybody has a checklist now man
[21:05] <mterry> Cimi, https://wiki.ubuntu.com/Process/Merges/Checklists/ubuntu-system-settings
[21:05] <Cimi> argh
[21:06] <Cimi> like we never did those