[07:01] <mzanetti> heads up everyone. unity8 doesn't start any more because of a bad merge in ubuntu-ui-toolkit. Don't upgrade your system if it still works for you
[07:06] <jalcine> save yourself!
[07:08] <mzanetti> asac: ping
[07:10] <mzanetti> morning tsdgeos
[07:10] <tsdgeos> mzanetti: morning
[07:15] <tvoss> mzanetti, can you get out that word on the mailing list, too, please?
[07:16] <mzanetti> tvoss: sure
[07:17] <tvoss> mzanetti, great, thx
[07:22] <asac> mzanetti: hi
[07:23] <mzanetti> asac: hi. do we run any integration tests for ubuntu-ui-toolkit?
[07:23] <mzanetti> asac: if yes, how do they work/look like?
[07:24] <asac> mzanetti: what test framework are you using? autopilot?
[07:24] <asac> mzanetti: oh ... so no, not yet
[07:24] <asac> mzanetti: we just have application integration tests that implicitely test the SDK where we use it
[07:25] <mzanetti> asac: yeah... weird thing is:
[07:25] <asac> we are waiting for more advanced tests
[07:25] <mzanetti> asac: unity8 doesn't start any more with the latest ubuntu-ui-toolkit
[07:25] <mzanetti> asac: so I'm wondering how that has passed the release chain
[07:25] <asac> mzanetti: so one way you can do that is basically just write a tests that reproduced this phenomenon and then you will be protected in future
[07:26] <asac> mzanetti: yeah, so reason is lack of testing on real phones and images at merge and daily-release gates
[07:26] <asac> mzanetti: which sdk broke you?
[07:26] <asac> when did that land?
[07:26] <mzanetti> timestamp: Tue 2013-08-27 20:04:05 +0000
[07:26] <mzanetti> this is when the bot committed the changelog
[07:27] <mzanetti> so I guess released a few hours later
[07:27] <asac> mzanetti: can you point me at the commit?
[07:27] <mzanetti> asac: rev 714 in ubuntu-ui-toolkit
[07:27] <asac> mzanetti: you think you could write a test that reproduces this issue for future protection?
[07:28] <mzanetti> asac: yeah sure
[07:28] <mzanetti> asac: but just for my understanding
[07:28] <mzanetti> asac: I assume that ubuntu-ui-toolkit package got released because there were no tests failing in there, right?
[07:29] <mzanetti> asac: and if later unity8 comes along and all the tests fail, it's considered being an issue in unity8 and that one doesn't get released any more, right?
[07:30] <asac> mzanetti: well, the idea is that we figure out the right blamee
[07:30] <asac> the approach ofr that is to: a) blame the owner of the apps whose tests fails as first stop
[07:31] <asac> so if you handn't talked to me i would have come to unity8 first, yes
[07:31] <mzanetti> asac: ok
[07:31] <asac> in order to steer me directly to sdk you could easily add tests for the sdk
[07:31] <asac> basically just put your own safety nets in place
[07:31] <asac> so OTHERS dont shoot you in the foot
[07:31] <asac> if you have a test that clearly diverts initial attention to sdk, then you are fine :)
[07:31] <mzanetti> asac: yeah, but those tests need to be in the ubuntu-ui-toolkit, no?
[07:31] <asac> NOW THAT I KNOW, i WILL know who to blame :)
[07:32] <mzanetti> that's not really the point... I'm trying to catch such failures earlier
[07:32] <asac> mzanetti: no... absolutelyt not... any autopilot test should work, but as i said problem is that daily release doesnt run on real phones yet
[07:32] <asac> so might just not catch everything
[07:32] <asac> mzanetti: so here the stacks we treat as ONE entity: http://reports.qa.ubuntu.com/daily/
[07:32] <mzanetti> asac: no... this completely breaks QML compilation... nothing to with phone or not
[07:33] <asac> hmm
[07:33] <asac> mzanetti: so if you see those stacks, everything has to pass all autopilot tests for now
[07:33] <asac> so if sdk busts everything it should be catched there
[07:33] <asac> if it wasn't I have to check why
[07:33] <asac> so let me see
[07:33] <asac> mzanetti: did you see the ui-toolkit already in the archive?
[07:34] <mzanetti> asac: yeah. apt-get upgrade breaks all unity8 installations right now
[07:34] <tsdgeos> mzanetti: i'm starting to think that  lp:~stolowski/unity8/fix-filter-activation  and  lp:~saviq/unity8/ap-raise-on-typing are actaully problematic by themselves :D
[07:34] <asac> omg
[07:34] <asac> sil2100: Mirv: hey
[07:35] <sil2100> jamesh: hi! Any luck on getting rid of those gstreamer deps?
[07:35] <sil2100> asac: morning!
[07:35] <asac> sil2100: Mirv: can you tell me why the fact that ui-toolkit breaks everything in unity8 wasn't seen in our daily-release systems?
[07:35] <mzanetti> tsdgeos: hehe, yeah. might be. but our latest flakyness in jenkins makes it hard to tell
[07:35] <asac> http://reports.qa.ubuntu.com/daily/
[07:35] <tsdgeos> tvoss: didn't get your emaiil about benhcmarks yesterday
[07:35] <jamesh> sil2100: still working on it.  I should have it cleared up a bit later today.
[07:35] <asac> sil2100: i thought we at least try to run all autopilots there, so unity8 autopilot should have revealed if its really that bad
[07:35] <tsdgeos> tvoss: i already recorded a video of the nexus4+mir if you want to see it
[07:35] <tvoss> tsdgeos, right, still in my draft folder
[07:35] <asac> mzanetti: how is it broken afterards?
[07:35] <mzanetti> asac: doesn't start any more
[07:35] <tvoss> tsdgeos, have seen it, thanks
[07:35] <asac> mzanetti: doesnt boot? did you try run unity8 autopilots?
[07:35] <tsdgeos> s/already/also
[07:36] <asac> mzanetti: ok. then its odd. if that also happens on the x86 side, we should have seen it in daily-release gatest
[07:36] <mzanetti> asac: everything fails... it's like unity8 would crash directly at startup
[07:36] <sil2100> asac: let me see what we're actually running for unity8
[07:36] <jamesh> sil2100: almost everything still worked with those build-deps removed, except for some tests
[07:36] <sil2100> jamesh: \o/
[07:36] <mzanetti> asac: yep, that's why I pinged you. I couldn't find any failure
[07:36] <asac> sil2100: right. seems there was a superbogus commit that busted us and we try to find out how that slipped through :)
[07:36] <asac> sil2100: can you confirm that we run all autopilots (*just not on phone) here: http://reports.qa.ubuntu.com/daily/ ?
[07:37] <mzanetti> tsdgeos: btw: https://code.launchpad.net/~mzanetti/unity8/launcher-initial-extensionSize/+merge/182504 this one seems to reliably work around the initial ListView positioning
[07:37] <asac> sil2100: also, can we backout ui-toolkit?
[07:37] <asac> i would really like to do that until they fixed it :)
[07:37] <mzanetti> tsdgeos: and also might have an impact on our analysis of the bug :/
[07:37] <asac> but lets talk later what to do
[07:37] <asac> lets first figure what happened :)
[07:37] <Mirv> asac: unity8 stack runs only unity8-autopilot tests
[07:37] <tsdgeos> mzanetti: hmmm
[07:37] <Mirv> (from first glance)
[07:37] <tsdgeos> well, why?
[07:38] <sil2100> Mirv: but I see it's upgrading the SDK, so it should see if things are broken
[07:38] <tsdgeos> mzanetti: i mean the simple example we ahve behaves wrong
[07:38] <tsdgeos> mzanetti: no?
[07:38] <Mirv> sil2100: assuming there are tests that break with the SDK update, not sure if ui-toolkit is used much in unity8 itself (probably not)
[07:38] <mzanetti> tsdgeos: yeah... but I think setting the currentIndex doesn't work because of the listview margings (i.e. it thinks the item would already be in the visible part)
[07:39] <sil2100> Mirv: but they say it's *badly* broken, so we should detect the case where nothing works, right?
[07:39] <asac> Mirv: those would have catched this issue though
[07:39] <asac> Mirv: we should at least include one stable app or two i think in that stack as well fwiw, but that unity8 should have failed in this case
[07:39] <Mirv> sil2100: sure, although I thought I was running the latest one on my device but maybe not
[07:39] <mzanetti> this is an example of "badly broken" :) http://s-jenkins:8080/job/generic-mediumtests-runner-saucy/2300/console
[07:40] <jamesh> sil2100: any progress on getting unity-scope-mediascanner in the archive?
[07:40] <mzanetti> tsdgeos: and this one should improve the autopilot test reliability I hope. http://10.97.2.10:8080/job/generic-mediumtests-runner-saucy/2300/console
[07:40] <asac> Mirv: sil2100: ok, please let me know once you figured how this slipped through. also if we can back this out without trying to investigate/fix/debugg (just revert to previoyus state) that would be fantastic
[07:40] <mzanetti> tsdgeos: mind reviewing those two?
[07:40] <asac> we really try to get a good image out today
[07:40] <tsdgeos> bad paste :D
[07:40] <asac> and this is the least i can need for that goal:)
[07:40] <tsdgeos> but i saw the "stable tests" one or whatever is called
[07:41] <mzanetti> tsdgeos: https://code.launchpad.net/~mzanetti/unity8/more-stable-tests/+merge/182448
[07:41] <tsdgeos> mzanetti: ironically it's not passing in CI :D
[07:41] <mzanetti> tsdgeos: haha, yeah
[07:41] <Mirv> probably also UI Toolkit tests shouldn't have passed, if this was the offending commit? https://code.launchpad.net/~nicolas-doffay/ubuntu-ui-toolkit/ubuntu-shape-option-selector/+merge/175242
[07:41] <mzanetti> tsdgeos: well, the first run passed. then all hell broke loose in our ci
[07:41] <asac> Mirv: we dont run any toolkit tests that i know during integration
[07:41] <tsdgeos> ah right
[07:41] <tsdgeos> sorry
[07:41] <mzanetti> tsdgeos: first the VM's being borked and then unity not starting any more at all
[07:41] <asac> if there are tests i want to know
[07:42] <tsdgeos> no need to restage the failed autolandings obviouly
[07:42] <sil2100> jamesh: it's waiting for actual publishing - which didn't happen just yet, so it should be in real quick
[07:42] <jamesh> okay
[07:42]  * mzanetti goes for writing a test in ubuntu-ui-toolkit
[07:42] <asac> mzanetti: can you give us also tests that we can run in the image?
[07:43] <asac> like autopilots etc.
[07:43] <mzanetti> asac: how do you mean?
[07:43] <Mirv> asac: well all of the unit tests are run and were successful https://jenkins.qa.ubuntu.com/job/ubuntu-ui-toolkit-saucy-amd64-ci/425/? , I'd guess there should be a test that would catch something like this
[07:43] <asac> e.g. not only unit/make check tests
[07:43] <asac> mzanetti: there are build time tests
[07:43] <asac> and runtime/integration tests
[07:43] <asac> i also would want more int3egration tests
[07:43] <asac> that test the whole thing
[07:43] <asac> Mirv: i dont care about unit tests ... thats something that is fine and good :) ... but ultimately i want our autopilots/integration tests
[07:44] <asac> to detect if something busts unity8 completely
[07:44]  * mzanetti doesn't agree
[07:44] <asac> mzanetti: how can you disagree on something expressing what i care about :)?
[07:44] <asac> hehe
[07:44] <mzanetti> :D
[07:44] <asac> i said: unit tests are fine and good
[07:44] <mzanetti> right...
[07:45] <mzanetti> I missed the "i" in the beginning
[07:45] <Mirv> hmm, first of all, is there a bug against ui-toolkit for the breakage?
[07:45] <asac> Mirv: i guess not.
[07:45] <tsdgeos> mzanetti: hmmmm
[07:45] <Mirv> https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1217650 maybe this
[07:45] <asac> i am still stuck at an earlier stage :)
[07:45] <asac> yeah that sounds right from title :)
[07:46] <tsdgeos> mzanetti: so i read https://code.launchpad.net/~mzanetti/unity8/more-stable-tests/+merge/182448 as "wait for infographic anim to fnish before moving the greeter away", is that right?
[07:46] <mzanetti> tsdgeos: yes
[07:46] <tsdgeos> mzanetti: shouldn't we fix that to work? :D
[07:47] <mzanetti> tsdgeos: I think it does work (if the machine running it actually fulfills our minimum hardware requirements)
[07:47] <mzanetti> but we're testing with less :D
[07:47] <mzanetti> tsdgeos: but I do agree... If there is really an issue in our code, that should be fixed.
[07:48] <tsdgeos> mzanetti: maybe adding a todo in the Greeter code?
[07:48] <tsdgeos> something like "TODO investigate bla bla"
[07:48] <mzanetti> asac: question: wouldn't it make sense to start (just start) all the applications and unity8 as some sort of integration test for the SDK?
[07:48] <asac> mzanetti: we have all that
[07:48] <asac> it seems its just not run :)
[07:48] <mzanetti> right...
[07:49] <asac> our autopilots have that as well
[07:49] <asac> and more :)
[07:49] <tsdgeos> mzanetti: noone's going to fix it, but we'll cover our asses :D
[07:49] <mzanetti> asac: so in the end it's just an issue that parts of the test suite were currently disabled?
[07:49] <asac> Mirv: sil2100: so, you think we have the means/tools to just throw this out temporarily so sdk team can fix this for real?
[07:50] <asac> mzanetti: yeah... its surely about our daily-release gates not doing what we wanted in this case
[07:50] <asac> the sdk stack should have gone red here: http://reports.qa.ubuntu.com/daily/
[07:50] <asac> and waited for action before pushing to archive
[07:51] <Mirv> asac: I'm just asking SDK team to revert it in trunk until it's resolved
[07:51] <asac> mzanetti: however, without direct integration tests for ui-toolkit the blame would first fall to the busted app/unity maintainers
[07:51] <asac> Mirv: do we have means to do that without team involvement?
[07:51] <mzanetti> asac: that's not a problem for me... I can redirect you after analyzing the issue
[07:51] <asac> we should be able to solve problems like that without having to wait for anything :)
[07:52] <mzanetti> asac: the bigger issue is that it got released
[07:52] <asac> mzanetti: yeah ... thats good.
[07:52] <asac> mzanetti: just sayingL if you want blame protection you can also write tests for your biggest offenders :)
[07:52] <asac> but i agree as long as we catch such things we should be happy
[07:52] <mzanetti> asac: yeah. understood. I wouldn't call the SDK our biggest offender tho... usually it works out quite well. this case is really a stupid mistake
[07:53] <asac> :)
[07:53] <Mirv> asac: not nicely, of course one can forcefully push stuff to trunk
[07:53] <asac> right. thats what safety belts are meant to do
[07:53] <Mirv> asac: but the team is there, online
[07:53] <asac> Mirv: ok, are there other commits?
[07:53] <asac> or just this one?
[07:54] <Mirv> asac: just one commit, and apparently the problem is about PopoverForegroundStyle being made internal
[07:54] <asac> Mirv: ok, can you get them to revert without debugging/testing/fixing?
[07:54] <asac> they can do the real fix in a second step
[07:54] <asac> without firedrill
[07:54] <asac> (so we dont risk picking up another stupid mistake()
[07:54] <asac> see what they say
[07:55] <asac> we really would like to push the button for a new package/image in a couple minutes at best
[08:16] <Mirv> asac: sil2100: ok, revert is merged (merged it manually to hasten) and launched a rebuild
[08:16] <asac> nice!
[08:16] <asac> thanks!
[08:17] <asac> Mirv: keep me posted (e.g. when package hits daily-release pcoket etc.)
[08:17] <Mirv> ok
[08:34] <Mirv> there are so many points that could be a bit faster. amd64 always finishes before i386, so running tests on amd64 might be worthwhile. then, publishing packages after they've been uploaded to PPA takes another 5-10mins, added by the polling interval of 5mins
[08:34] <Mirv> but, it's building now https://launchpad.net/~ubuntu-unity/+archive/daily-build/+sourcepub/3450226/+listing-archive-extra and after i386 has both built and published the tests will be run
[09:01] <hyperair> Zhenech: where was the debian status page for ubuntu indicators again?
[09:02] <Mirv> asac: now in LP https://launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/0.1.46+13.10.20130828-0ubuntu1
[09:03] <asac> Mirv: awesome
[09:03] <Zhenech> hyperair, pkg-ayatana-devel@alioth on qa?
[09:04] <hyperair> Zhenech: more like the stuff that hasn't been packaged
[09:04] <hyperair> nevermind, found it.
[09:04]  * hyperair forgot it was called pkg-ayatana
[09:04] <Zhenech> hyperair, there is like a ton not merged since wheezy
[09:04] <hyperair> yeah i figured
[09:04] <Zhenech> as someone at your end thought it was a good idea to create all new packages and libs
[09:05] <Zhenech> and I did not have time
[09:05] <hyperair> new packages?
[09:05] <hyperair> what new packages?
[09:05] <Zhenech> like there is no more dbusmenu etc
[09:05] <hyperair> ah hell
[09:05] <Zhenech> would have to search myself
[09:53] <mhr3> sil2100, is unity stack completely disabled, or is it going to be run soonish?
[09:53] <mhr3> Mirv, ^?
[09:57] <sil2100> mhr3: let's wait for the next tick, since this tick was badly broken because of all the *things*
[09:58] <Mirv> mhr3: indicators is blocking it, still
[09:58] <Mirv> even next tick at the moment it'd seem, since there is some powerpc related problem
[09:59] <seb128> Mirv, why did you stop the indicator runs?
[09:59] <seb128> Mirv, http://10.97.0.1:8080/view/cu2d/view/Head/view/Indicators/job/cu2d-indicators-head-2.1build/434/
[09:59] <seb128> says you stopped it
[09:59] <seb128> the ppa builds seemed fine
[09:59] <seb128> oh, or is that the "keep waiting on indicator-network"?
[10:02] <sil2100> seb128: I guess he might have aborted so that the next tick kicks in?
[10:02] <seb128> sil2100, no, read #ubuntu-desktop, I think it's an issue with indicator-network
[10:02] <Mirv> seb128: yes, it's that
[10:03] <Mirv> seb128: it happened already yesterday but apparently cyphermox & co didn't notice it, and I didn't notice it until two hours into my day either
[10:03] <Mirv> I filed bug #1217811 now
[10:03] <Mirv> not sure if indicator-network should be tri-arched now, for that
[10:03] <tsdgeos> pstolowski: yay
[10:03] <tsdgeos> :D
[10:03] <tsdgeos> at least
[10:04] <pstolowski> tsdgeos: well... look at #phablet
[10:04] <seb128> Mirv, cf #ubuntu-desktop
[10:04] <tsdgeos> really?
[10:04] <tsdgeos> that happened with some other MR too
[10:04] <pstolowski> tsdgeos: yeah, I just discovered by looking at the history
[10:04] <tsdgeos> something bad happened that day
[10:05] <tsdgeos> ok, good enough we found out :D
[10:06] <tsdgeos> maybe saviq's one that keeps failing is the same?
[10:06] <pstolowski> tsdgeos: it should show empty diff on LP if this is the case
[10:06] <tsdgeos> pstolowski: only if you repush the branch, no?
[10:06] <tsdgeos> or yours did show empty?
[10:07] <pstolowski> tsdgeos: yes, my did show empty, at least when I checked today
[10:07] <tsdgeos> ah
[10:07] <tsdgeos> ok
[10:07] <tsdgeos> let's see saviq's
[10:08] <Mirv> asac: ui-toolkit in release pocket
[10:09] <asac> nice
[10:09] <asac> Mirv: how long did it take? 2.5 hours?
[10:09] <asac> so proposed took 1h
[10:09] <asac> it seems
[10:09] <asac> roughly
[10:09] <asac> maybe 50
[10:10] <seb128> asac, rather ~2hours between commit and landing in saucy
[10:11] <seb128> asac, https://launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+publishinghistory
[10:11] <seb128>  Published 57 minutes ago
[10:11] <seb128> Deleted 39 minutes ago by Ubuntu Archive Robot
[10:11] <seb128> moved to release
[10:11] <asac> seb128: commit == merge proposal time?
[10:11] <seb128> asac, so ~1.5 hour commit to saucy release
[10:11] <asac> or local commit? or landing in trunk?
[10:12] <seb128> asac, they directly pushed the revert to trunk without mp it
[10:12] <asac> seb128: yeah... then it took another 10 minutes before i got it  on archive.ubuntu.com
[10:12] <asac> ok
[10:12] <asac> guess not yet perfect, but definitely a success :)
[10:12] <asac> my phone works
[10:16] <Mirv> asac: something like that
[10:17] <Mirv> asac: and I bypassed the merge proposal phase by direct merge
[10:17] <Mirv> asac: one good point is that when it's build in the PPA, it's copied from there to archives
[10:18] <Mirv> and the amd64 point I made doesn't apply, since armhf often takes more time than i386 + tests
[10:19] <Mirv> the polling in cu2d could be more often, and the PPA publishing is annoyingly slow
[10:34] <tsdgeos> is taking screenshots broken for anybody else?
[10:38] <mhr3> screenshots, screencasts, screen*
[10:41] <tsdgeos> dednick: you there?
[10:41] <dednick> tsdgeos: i am
[10:42] <tsdgeos> dednick: if i run https://code.launchpad.net/~nick-dedekind/unity8/indicator.multi-icon/+merge/181862 on the desktop should i see something different?
[10:42] <Cimi> tsdgeos, ah I see what you mean with clicking when the hud is on
[10:42] <Cimi> tsdgeos, you meant t dismiss the hud?
[10:42] <tsdgeos> yes
[10:42] <Cimi> *to
[10:42] <Cimi> ok
[10:42] <Cimi> tsdgeos, you think it should block inputs?
[10:43] <Cimi> I am not sure
[10:43] <dednick> tsdgeos: i am
[10:43] <dednick> sorry
[10:43] <tsdgeos> :D
[10:43] <dednick> tsdgeos: only if you're running on a device at the moment
[10:43] <tsdgeos> Cimi: well it does for the launcher, right?
[10:43] <dednick> tsdgeos: you "may" get the cellular icon next to the wifi icon.
[10:43] <tsdgeos> Cimi: so either we undo the launcher or do this
[10:43] <Cimi> tsdgeos, I'll ask oren
[10:44] <dednick> tsdgeos: or if you dont have a sim, it should show "No SIM"
[10:44] <tsdgeos> but having different dismiss goes thorught the thing
[10:44] <tsdgeos> seems very weird to me
[10:44] <Cimi> mmm maybe
[10:47] <tsdgeos> dednick: ok, let me see if i can get that to work
[10:48] <tsdgeos> my phone is in a bit of unity-mir flux :D
[10:48] <jamesh> sil2100: the mediascanner change to get rid of those extra gstreamer build deps should land shortly.
[10:49] <Cimi> tsdgeos, ok it's fullscreen now
[10:49] <tsdgeos> oki
[10:52] <tsdgeos> dednick: not sure if you know anything about this
[10:53] <tsdgeos> but i have a bluetooth indicator
[10:53] <tsdgeos> without icon :D
[10:55] <dednick> tsdgeos: yep, we are aware. there is no icon in the theme.
[10:55] <tsdgeos> ok
[10:56] <sil2100> jamesh: that's excellent news
[11:05] <tsdgeos> dednick: ok, i see nothing new
[11:06] <tsdgeos> dednick: tbh the code "looks good"
[11:06] <tsdgeos> but without a way to try it
[11:06] <tsdgeos> don't know what to do :-/
[11:06] <dednick> tsdgeos: you have a sim in?
[11:06] <tsdgeos> nope
[11:06] <tsdgeos> shall i?
[11:06] <dednick> tsdgeos: when last did you do upgrade?
[11:06] <tsdgeos> dednick: minutes ago
[11:07] <dednick> tsdgeos: let me just check if that code is in archive yet.
[11:08] <dednick> tsdgeos: in your wifi indicator, is "mobile" enabled?
[11:08] <tsdgeos> let me see
[11:10] <tsdgeos> dednick: my network indicator is "Empty!"
[11:10]  * tsdgeos reboots the phone
[11:12] <tsdgeos> dednick: not even that
[11:12] <tsdgeos> no network indicator at all
[11:12] <tsdgeos> dednick: can you check there?
[11:13] <dednick> tsdgeos: yeah, it's been a few days since i updated
[11:15] <dednick> tsdgeos: actually, can you make sure that you have indicator-network installed. there was a problem with doing upgrades awhile ago.
[11:16] <dednick> tsdgeos: it was holding back ubuntu-touch upgrade
[11:16] <tsdgeos> dednick: he he
[11:16] <tsdgeos> seems i don't
[11:17] <dednick> tsdgeos: just do manual install of ubuntu-touch and it should resolve
[11:17] <tsdgeos> dednick: oh wait i do
[11:17] <tsdgeos> i was doing the dpkg query on my desktop :D
[11:17] <tsdgeos> ii  indicator-network                                     0.5.0+13.10.20130827.3-0ubuntu1                     armhf        Systems settings menu service - Network indicator
[11:17] <tsdgeos> is that my phone has
[11:18] <dednick> hm. ok
[11:18] <dednick> can you check if the process is running?
[11:20] <tsdgeos> 5.1.1 relesed at last
[11:20] <greyback> yay
[11:20] <tsdgeos> root@ubuntu-phablet:/# ps -A | grep netw
[11:20] <tsdgeos>  1673 ?        00:00:00 indicator-netwo
[11:20] <tsdgeos> dednick: ↑↑↑
[11:20] <dednick> tsdgeos: yeah
[11:20] <dednick> hm
[11:21] <tsdgeos> what more can i do to debug it a bit more?
[11:21] <dednick> tsdgeos: so you're not even getting the icon?
[11:21] <tsdgeos> i do get the icon
[11:21] <dednick> but empty?
[11:21] <tsdgeos> but if i expand it
[11:21] <tsdgeos> it says
[11:21] <tsdgeos> Emtpy!
[11:21] <dednick> er
[11:21] <tsdgeos> without the typo
[11:21] <tsdgeos> :D
[11:22]  * greyback back in 40
[11:22] <larsu> dednick: hey :) Can you reproduce bug #1215644 on the device?
[11:23] <dednick> larsu: i have indeed noticed mine not changing. but i havent looked into it
[11:27] <larsu> dednick: ah, I can reproduce it now too with my test script. Seems to be a bug in the service after all. Sorry to bother :)
[11:28] <dednick> larsu: no worries :)
[11:36] <nic-doffay> Anyone got time for quick sdk review? https://code.launchpad.net/~nicolas-doffay/ubuntu-ui-toolkit/crossfadeimage-size-output-fix/+merge/181836
[11:55] <mzanetti> dandrader: hey. welcome back!
[11:56] <dandrader> mzanetti, thanks :)
[11:56] <dandrader> mzanetti, how are things going?
[11:56] <mzanetti> dandrader: not too bad actually.
[11:57] <mzanetti> dandrader: did you already flash a phone?
[11:57] <mzanetti> probably not...
[11:57] <dandrader> mzanetti, no. still downloading e-mail and :apt-get dist-upgrading"
[11:57] <mzanetti> dandrader: lots of new stuff in the image :)
[11:58] <dandrader> mzanetti, great. now I'm curious :)
[11:58] <mzanetti> dandrader: I was playing around with location stuff lately. couldn't get geoclue working and then I found a hangout session from you where you suggested to rewrite geoclue
[11:59] <mzanetti> dandrader: are you still involved in that stuff?
[12:00] <dandrader> mzanetti, no, I'm not. I worked on that rewrite for a week then gave up and joined this team
[12:01] <dandrader> mzanetti, but tvoss was working on it just before I left on vacations
[12:01] <mzanetti> dandrader: ah ok. but do you still know what's going on there?
[12:01] <mzanetti> ah, I'll ask him
[12:02] <dandrader> mzanetti, but I think we are not going to use geoclue or a rewrite of it
[12:02] <mzanetti> tvoss__: is location stuff supposed to work already? I tried to enable that in one of my app but failed.
[12:03] <dandrader> mzanetti, I made a pure-gps backend for Qt location framework but it was removed a couple of days before my holidays as well
[12:03] <mzanetti> QtLocation was printing a debug message that it couldn't connect to geoclue. I tried to configure geoclue but haven't managed to do so.
[12:04] <dandrader> mzanetti, but I'm sure we won't use geoclue
[12:05] <mzanetti> dandrader: yeah... I'm fine with that... just saying, 3 days ago any access to QtLocation was still printing a message that it is trying to connect to geoclue. That's why I assumed we would use it.
[12:05] <tvoss__> mzanetti, it's meant to work, let me check if all packages landed
[12:05] <mzanetti> tvoss__: note: my status if from the weekend
[12:05] <mzanetti> if something landed last 3 days, I'm outdated already
[12:07] <tvoss__> mzanetti, ack, might be outdated then, the respective packages could possibly land only yesterday after
[12:07] <tvoss__> having unblocked proposed
[12:08] <mzanetti> tvoss__: cool, thanks. I'll try again in the next days and let you know.
[12:09] <tvoss__> mzanetti, thx
[12:53] <kgunn> dandrader: welcome back :)
[12:53] <dandrader> kgunn, thanks!
[12:59] <dandrader> mzanetti,  ok... so should I phablet-flash ubuntu-system or cdimage-touch?
[13:03] <mzanetti> dandrader: cdimage-touch --pending
[13:04] <dandrader> hmm... ok
[13:18] <dandrader> mzanetti, I only have a videos dash, is that expected?
[13:18] <mzanetti> dandrader: no
[13:19] <mzanetti> dandrader: you might want to add -p then... to reset everything
[13:20] <dandrader> mzanetti, -p or --wipe?
[13:20] <mzanetti> dandrader: hmm... didn't know about --wipe
[13:20] <mzanetti> dandrader: always used -p when shit broke loose
[13:22] <dandrader> mzanetti, -p is "Installs from base path, you must have the same directory structure as if you downloaded for real. This option is completely offline."
[13:22] <dandrader> doesn't sound like a reset switch
[13:22] <mzanetti> dandrader: no clue what I did then :D
[13:22] <dandrader> hahah
[13:22] <mzanetti> dandrader: I thought -p would be like --provision or something like that
[13:22] <dandrader> ah, yeah, now I recall
[13:22] <dandrader> before holidays
[13:22] <dandrader> I changed the xml or something
[13:23] <dandrader> to have only the videos dash
[13:23] <dandrader> for debugging purposes :)
[13:26] <mzanetti> mterry: good morning
[13:27] <mzanetti> mterry: I reviewed your branches. found some issues in both
[13:31] <mzanetti> Cimi: dednick: standup
[13:31] <greyback> kgunn: nic-doffay  you too
[13:42] <greyback> mterry: tsdgeos: I missed the crux of that app launching story. You need the greeter to be able to launch apps, yes?
[13:42] <dandrader> greyback, so unity-mir is still not in the official images (from phablet-flash), right?
[13:43] <mterry> greyback, yeah
[13:43] <kgunn> dandrader: cause you left :)
[13:43] <greyback> dandrader: correct, but we're getting close. And I think I'll need your help to get it in!
[13:43] <dandrader> kgunn, :D
[13:43] <dandrader> greyback, ok. what do you want me to do. shoot!
[13:44] <greyback> dandrader: so the main delta is in unity8 now. What would be great is to land all the changes I've made, in such a way that unity8 works on the exisitng SurfaceFlinger image, and also with Mir
[13:44] <mzanetti> tsdgeos: the Qt session starts in 15 mins, right?
[13:45] <tsdgeos> mterry: greyback: so yeah if you pass         "^application:///([a-zA-Z0-9_-]*)\\.desktop$" do url-dispatcher it'll launch an app which from a Qt app will be as easy as just calling QDesktopServices::openUrl once i can get the damn thing to link :D
[13:45] <tsdgeos> mzanetti: yeaps
[13:45] <greyback> dandrader: having the main.cpp do that is the easy part. There are some QML changes which will make it a bit harder. And then tests...
[13:45] <tsdgeos> dandrader: ah, we are having vUDS btw
[13:45] <tsdgeos> dandrader: http://uds.ubuntu.com/
[13:45] <tsdgeos> dandrader: in case you're interested in any specific talk
[13:45] <tsdgeos> s/talk/session
[13:46] <dandrader> tsdgeos, yeah, I skimmed through its pages
[13:46] <greyback> dandrader: so first I'll point you to getting unity8 with Mir on your phone. Instructions: flash your phone. Ssh in, "add-apt-repository ppa:phablet-team/mir" and install the new packages, reboot phone
[13:46] <dandrader> and was listening to the opening sessinon/keynote
[13:46] <mterry> tedg, ^ see tsdgeos about launching application:// urls.  Is there something special that the session-broadcaster does beyond that?
[13:47] <tedg> mterry, It's actually not building the URL, it's launching the job.  But it's basically the same.
[13:47] <greyback> mterry: when greeter launches an app, what manages it's window?
[13:47] <greyback> s/it's/its/
[13:48] <mterry> greyback, it launches inside its user's session, not in the greeter session
[13:48] <tedg> greyback, So you'll get a start event from upstart the same as any other.
[13:48] <mterry> tedg, I don't follow "actually not building the URL, it's launching the job"
[13:49] <tedg> mterry, app -> url -> url-dispatcher -> upstart vs. app -> upstart
[13:49] <mterry> tedg, app -> broadcaster -> upstart, eh?
[13:50] <tedg> mterry, Yes  greeter -> broadcaster -> session upstart -> upstart app launch
[13:50] <mterry> tedg, do we need the broadcaster?  Is there a reason we don't just use url-dispatcher?
[13:50] <tedg> mterry, url-dispatcher is on the session bus, broadcaster is on system
[13:51] <mterry> tedg, oh!  url-dispatcher is just for in-session stuff.  I see.  Yup
[13:52] <tedg> mterry, Long term it should get the URL formats from Click packages, etc.
[13:52] <greyback> mterry: tedg: where does greeter get its launcher from? When the greeter launcher launches something, greeter goes away, revealing shell, which will be animating to show the application?
[13:53] <mterry> greyback, right
[13:53] <mterry> greyback, or you might be brought to the passcode entry screen if session is locked
[13:53] <tedg> greyback, There's two Mir sessions on the system compositor, and two launchers.
[13:54] <tedg> We hear you like launchers... ;-)
[13:54] <mterry> greyback, if you're asking where it gets its data from (list of launchers), the plan is accountsservice.  I have a branch pending for it
[13:55] <mterry> list of launcher items, rather
[13:56] <greyback> mterry: I was more curious of the security aspect.
[13:57] <mterry> greyback, it only lets the lightdm user request launches
[13:58] <mterry> greyback, and the target username is passed along with request, so session knows if a launch is for it or not
[13:58] <greyback> mterry: ok, sounds reasonable
[13:58] <mterry> greyback, and for launcher items, accountsservice won't let non-root/lightdm/original-user see user items
[13:59] <mterry> tedg, btw, I'm working on a branch for broadcaster to make it actually do something
[14:04] <tedg> mterry, Sweet!
[14:04] <tedg> mterry, I realized it's not in daily release.
[14:04] <tedg> mterry, We need to fix that so it "really exists"
[14:16] <dandrader> greyback, after adding ppa:phablet-team/mir, just "apt-get update;apt-get dist-upgrade"  will do the job of installing all the needed packages?
[14:16] <greyback> dandrader: yep
[14:17] <Cimi> tedg, hey dude :P
[14:19] <tedg> Howdy Cimi
[14:34] <greyback> dandrader: get Mir unity8 going?
[14:35] <Cimi> tedg, was just wondering if you knew about the wifi plugin for system settings
[14:35] <dandrader> greyback, yes
[14:35] <tedg> Cimi, I've started it, but if you want to work on it, that's fine with me :-)
[14:35] <dandrader> greyback, what's the sure way of telling you're running mir?
[14:35]  * tedg reassigns ;-)
[14:35] <Cimi> tedg, I can't :P holidays soo
[14:36] <Cimi> soon
[14:36] <tedg> Cimi, That means you have time where other tasks aren't assigned!
[14:36] <greyback> dandrader: ok, so here is the branch with lp:~unity-team/unity8/unity8-integrate-mir/ - want to integrate it with lp:unity8
[14:36] <dandrader> (I get the somewhat different response times and a weird crash here and there, to telltales I'm with unity8-mir)
[14:36] <greyback> dandrader: easiest way to see: run Gallery, and see if the panel overlaps the gallery title
[14:37] <Cimi> tedg, do you have ETA for it?
[14:37] <dandrader> greyback, right. I get that
[14:37] <greyback> dandrader: then you're running Mir with unity8  \o/
[14:37] <dandrader> omg!
[14:38] <dandrader> :)
[14:38] <dandrader> so lp:~unity-team/unity8/unity8-integrate-mir/ is what is running on my device now, right?
[14:38] <dandrader> greyback, ^
[14:40] <tedg> Cimi, Hoping to get basics working today-ish.  But I have to figure out how to steal dednick's code out of Unity8.
[14:40] <Cimi> tedg, I can have a look, although holiday from friday..
[14:41] <greyback> dandrader: correct
[14:41] <tedg> Cimi, https://code.launchpad.net/~ted/ubuntu-system-settings/wifi-panel
[14:48] <greyback> dandrader: so I'm slowly coming up with a plan here: http://studio.sketchpad.cc/GwI2yglrAj
[14:49]  * dandrader reads on
[15:03] <dandrader> greyback, is anyone (besides me) working on this integration at the moment?
[15:04] <greyback> dandrader: I'll be working with you
[15:04] <greyback> dandrader: I'm wanting your input on how we can do this
[15:05] <greyback> dandrader: the plan is that the standard phablet image will ship with SF still the default. And we'll offer an internal switch somewhere to turn on Mir
[15:05] <greyback> dandrader: that internal switch being something like create a particular file, or something.
[15:06] <dandrader> hmm, ok
[15:06] <greyback> dandrader: so how to make unity8 flexible enough to work in both scenarios is the problem
[15:07] <dandrader> greyback, so in unity8-mir there's no way yet for events going solely to the shell?
[15:08] <dandrader> that's what I understood from reading your summary/plan
[15:08] <greyback> dandrader: no there is. Let me re-prhase it
[15:18] <dandrader> greyback, ok, then in unity8-mir we don't have the situation where both unity8 and app get input events, right?
[15:18] <greyback> dandrader: correct
[15:20] <dandrader> greyback, and, if I'm not mistaken, we also don't make use of it (although it happens) on unity8-SF, right? unity8 just ignores those events in such situations. effectively working as an "events to app only " situation
[15:21] <greyback> dandrader: correct
[15:22] <greyback> On SF, shell gets *all* input events. But it has ability to filter them, so apps don't get them
[15:31] <dandrader> greyback, obvious or stupid question: why can't we make the default behavior ("events to app only" or "events app and unity8") the same on both SF and mir configurations? then we would have only a InputFilterArea (or ShellInputArea) whose implementation would come from a different lib depending on the scenario (unity8-SF or unity8-mir). and that switch could be handled easily by providing different paths to search for modules
[15:32] <greyback> dandrader: because this is the way Mir is doing it.
[15:33] <greyback> dandrader: the SF way isn't great mind. Things like edge swipes could also confuse applications, since both shell & app got them.
[15:33] <dandrader> greyback, so can't we make the thing that drives events in the surfaceflinger scenario  (ApplicationManager process ifrc !?) work like mir (app only by default)
[15:33] <greyback> dandrader: the plan is to have way for shell to receive a bunch of events, and if it doesn't accept them, have Mir send those events to the application
[15:35] <greyback> dandrader: I don't understand your question
[15:38] <mzanetti> greyback: are the showWindow() and hideWindow() in the applicationinfo class still needed?
[15:39] <mzanetti> (they don't appear in the doc)
[15:50] <tedg> dednick, Okay, I think I may have confused myself :-)
[15:51] <dednick> tedg: ?
[15:51] <tedg> dednick, Should I be looking at Panel/Indicators/client/IndicatorsTree.qml or IndicatorPage.qml as an example at how to get UnityMenuModel into QML?
[15:52] <dednick> tedg: IndicatorsPage.qml & MenuItemFactory.qml
[15:52] <dednick> IndicatorPage
[15:52] <tedg> dednick, Okay, and then IndicatorsTree is more like the panel?
[15:53] <dednick> tedg: the tree is just a for textual representation of the menus.
[15:53] <dednick> tedg: it's a debug ui
[15:54] <tedg> dednick, Ah, okay.  That explains a lot actually :-)
[15:54] <greyback> mzanetti: I've not heard of them, so no, they're not needed :)
[15:54] <dednick> tedg: the Panel/Indicators/client code is just for the indicator-client app.
[15:55] <dednick> tedg: the code to get the menu items is in plugins/Unity/Indicators
[16:00] <mzanetti> greyback: so I strictly stick to what's in the docs, ok?
[16:00] <greyback> mzanetti: ok
[16:01] <tedg> dednick, Okay, stealing some code.  Let's see if I can get this working :-)
[16:17] <mzanetti> greyback: hey, I'd like your feedback on https://code.launchpad.net/~mzanetti/unity-api/application-api/+merge/182692 when you have some time
[16:18] <greyback> mzanetti: ack
[16:18] <mzanetti> greyback: esp the ApplicationManager which is not really well defined in the doc and the stuff with TODO or FIXME
[16:43] <larsu> Wellark: why the dep on humanity-icon-theme in your patch?
[16:44] <larsu> Wellark: that's a bit overkill only for tests, no?
[17:03] <seb128> larsu, Wellark: if it's for tests it should be a build-depends? seems fine as a build-depênds
[17:07] <larsu> seb128: yes, it is a build depend
[17:07] <seb128> larsu, build-depends are cheap enough...
[17:08] <larsu> seb128: fair enough I guess :)
[17:08]  * larsu is a bit pedantic today
[17:10] <seb128> mterry, hey
[17:11] <mterry> seb128, hello!
[17:11] <seb128> mterry, I hope you are fine ;-) I've some questions for you!
[17:11] <mterry> k
[17:11] <seb128> mterry, so back to the greeter/lock topic, in fact I don't need an option there
[17:12] <seb128> mterry, the behaviour is going to depends on whether unlock is set to swipe/pin/password
[17:12] <mterry> k
[17:12] <seb128> mterry, is the greeter already supporting auth modes and is there a configuration interface for it?
[17:12] <mterry> seb128, yes/no and yes
[17:12] <mterry> seb128, once split, it will support proper PAM auth modes
[17:13] <mterry> seb128, right now, you can fake it by editing an ini file in /home/phablet
[17:13] <mterry> seb128, for the second question...
[17:13] <mterry> let me dig
[17:13] <seb128> thanks
[17:13] <seb128> same as usual, we are going to need system-settings to be able to write that config
[17:14] <mterry> You have to call /usr/lib/accountsservice/accounts-daemon-pam-password-helper with certain arguments, but I've forgotten the syntax
[17:14] <seb128> mterry, I guess the greeter is going to keep running as a separate user (I think some people were discussing making it an user session thing at some point)
[17:14] <mterry> seb128, yeah we need to keep it separate for security
[17:14] <seb128> ok, calling helpers it is then
[17:14] <mterry> I'm looking up how to call that helper
[17:15] <seb128> mterry, thanks
[17:15] <mterry> seb128, OK.  You call it like /usr/lib/accountsservice/accounts-daemon-pam-password-helper USERNAME
[17:15] <mterry> seb128, and pass in "PASSWORD\nPIN" via stdin
[17:16] <mterry> you can skip PIN to unset a pin
[17:16] <mterry> But PINs still need a password underneath
[17:16] <seb128> mterry, the design is https://wiki.ubuntu.com/SecurityAndPrivacySettings#phone-locking
[17:16] <seb128> it has
[17:16] <seb128> - swipe
[17:16] <seb128> - 4digit
[17:17] <seb128> - passphrase
[17:17] <mterry> righ
[17:17] <mterry> right
[17:17] <mterry> seb128, so swipe is simply normal "user doesn't need a password" stuff.  Like put them in nopasswdlogin group etc
[17:17] <mterry> seb128, passphrase is you do above, pass in a passphrase
[17:18] <mterry> seb128, 4digit can just be passing in 4digit\n4digit I suppose.  If you didn't want to have a backing password
[17:18] <nic-doffay> seb128, how long til your eod?
[17:18] <mterry> brb
[17:19] <seb128> nic-doffay, going to be around for another 2-3 hours with dinner in the middle
[17:19] <nic-doffay> seb128, k
[17:20] <om26er> mzanetti, btw with the change in icon size, the launcher icon glow is no longer visible when the icon is tapped
[17:20] <seb128> nic-doffay, why?
[17:21] <nic-doffay> seb128, functional review of that list item option selector
[17:21] <nic-doffay> but we can tackle that tomorrow, no biggie
[17:21] <seb128> nic-doffay, I'm happy to try it when you have it
[17:23] <nic-doffay> seb128, cool
[17:25] <mterry> seb128, did I answer your questions?
[17:25] <Wellark> larsu: yeah, getting rid of it
[17:25] <Wellark> larsu: didn't work anyway
[17:25] <seb128> mterry, I guess, I'm a bit unsure about the "normal "user doesn't need a password" stuff.  Like put them in nopasswdlogin group etc"
[17:26] <seb128> mterry, but that's enough info for me to RTFM/source
[17:26] <seb128> mterry, thanks ;-)
[17:26] <mterry> seb128, I don't recall exactly, but do whatever gnome-control-center does.
[17:26] <mterry> seb128, I know they get put in nopasswdlogin
[17:26] <mterry> seb128, but I don't know what happens to the password entry in /etc/passwd.  Maybe it gets blanked?
[17:26] <dandrader> greyback, ping
[17:27] <greyback> dandrader: pong
[17:27] <dandrader> where does ShellInputArea comes from?
[17:27] <seb128> mterry, I need to check
[17:27] <seb128> mterry, I guess I should just check how are things configured on the default touch install
[17:27] <mzanetti> om26er: removal of the glow is intentional too
[17:27] <seb128> mterry, because "swipe/no password" is the default today
[17:27] <mterry> seb128, but that's not via PAM
[17:28] <mterry> seb128, that's just hardcoded into the greeter
[17:28] <seb128> I saw
[17:28] <om26er> mzanetti, is there going to be an indicator to know if an app is running or not ?
[17:28] <seb128> so I guess that's something you guys are going to resolve on your side at some point anyway
[17:28] <seb128> I saw -> I see
[17:28] <mterry> yeah
[17:28] <mzanetti> om26er: not sure yet. current docs say no
[17:29] <mterry> om26er, yeah I recall katie saying no
[17:30] <om26er> mterry, mzanetti hmm, ok. thats different from the desktop
[17:30] <mterry> om26er, for now!  muhahaha
[17:30] <mzanetti> mterry: there are "running" apps in the dash.
[17:31] <mzanetti> so I asked back if we really don't want it in the launcher
[17:31] <mterry> mzanetti, true
[17:32] <om26er> with this "running in the dash" i always unintentionally close those apps but I think design actually wanted users to not worry about running apps
[17:32] <mterry> Yar, ideally the user never thinks about it
[17:32]  * mzanetti still doesn't agrees
[17:32] <mzanetti> but anyways... right now its somewhat inconsistent
[17:42] <nic-doffay> seb128, available for a test drive?
[17:42] <nic-doffay> It's done.
[17:45] <nic-doffay> seb128, if you're keen to do a functional review: https://code.launchpad.net/~nicolas-doffay/ubuntu-ui-toolkit/list-item-option-selector/+merge/182718
[17:46] <nic-doffay> If you run the gallery click on ListItems, scroll down and you'll see all of em there.
[17:46] <seb128> nic-doffay, sure, doing that in a bit
[17:46] <nic-doffay> seb128, I'll try get it landed asap
[17:47] <nic-doffay> Will prob have to be tomorrow though, I think most key individuals are EOD
[17:47] <seb128> nic-doffay, tomorrow is fine, but thanks ;-)
[20:17] <mzanetti> om26er: ping
[20:18] <om26er> mzanetti, pong
[20:18] <mzanetti> om26er: hi. I just found one bug in our jenkins setup :D
[20:18] <mzanetti> om26er: https://code.launchpad.net/~mzanetti/unity8/more-stable-tests/+merge/182448
[20:18] <om26er> mzanetti, specifically touch setup ?
[20:19] <mzanetti> om26er: not really... the whole thing
[20:19] <mzanetti> om26er: so in this branch I'm trying to find out why tests fail in jenkins...
[20:19] <mzanetti> om26er: its a combination of different things
[20:19] <mzanetti> om26er: look at the last comment
[20:19] <mzanetti> om26er: but I just found the reason for the internal server errors :)
[20:20] <om26er> mzanetti, and that is ?
[20:20] <mzanetti> om26er: the xpath query in the job searches for jobs with the name "generic-mediumtests-aucy"
[20:20] <mzanetti> om26er: and now that also matches generic-mediumtests-saucy-armhf :D
[20:21] <om26er> oh ?
[20:21] <mzanetti> that's when it fives 2 results and the rest of the query bails out :D
[20:21] <om26er> mzanetti, maybe a bug in that version of jenkins
[20:21] <om26er> I know we are using quite an old one
[20:21] <mzanetti> om26er: no... this is a feature not supported by jenkins
[20:21] <om26er> mzanetti, suggest a name and i'll rename
[20:21] <mzanetti> om26er: I just hacked it in to have a way to collect downstream artifacts
[20:22] <mzanetti> om26er: I'd suggest renaming generic-mediumtests-bullder-saucy to generic-mediumtests-builder-saucy-armhf
[20:22] <mzanetti> err...
[20:22] <mzanetti> generic-mediumtests-builder-saucy-i386
[20:22] <mzanetti> or amd64, whatever it is
[20:22] <mzanetti> om26er: ^
[20:23] <om26er> mzanetti, ehm, yes we can do that.
[20:23] <mzanetti> cool.
[20:23] <om26er> i thinks amd64
[20:23] <mzanetti> om26er: iirc amd64 runs the qmltests
[20:23] <mzanetti> and i386 autopilot
[21:15] <tedg> thomi, Can we talk about autopilot?
[21:17] <thomi> tedg: sure, what's up?
[21:17] <tedg> thomi, Trying to understand what you're doing with dbus
[21:17] <tedg> thomi, WRT, confinement
[21:17] <thomi> sure
[21:18] <thomi> it's actually pretty simple: the application under test connects to the session bus (that's what's failing currently). Autopilot then uses dbus to query application state
[21:18] <tedg> So it's "the" session bus, not creating a new one?
[21:19] <thomi> correct, unless qtdbus is doing something funky
[21:19] <tedg> The error in the kernel log is about starting a new dbus instance.
[21:19] <thomi> the code is in lp:autopilot-qt, if you're interested
[21:19] <thomi> yeah
[21:19] <thomi> I wonder if Qt is doing that?
[21:19] <tedg> Perhaps, not sure why it would...
[21:20] <thomi> tedg: if the DBUS_SESSION_ADDRESS env var (or whatever it's called) is missing, how would it know where to connect?
[21:20] <thomi> I can imagine qtdbus may, in that case, just start a new one
[21:20] <tedg> thomi, I'm sure that's not missing, or everything would break :-)
[21:20] <thomi> ok
[21:21] <tedg> thomi, Do you have a system that does this right now?  You can check by doing "initctl list-env"
[21:21] <thomi> tedg: sure, one sec
[21:21] <tedg> If it's easy, there's no reason to not be extra sure :-)
[21:22] <thomi> tedg: it's not there
[21:22] <thomi> pastebin coming...
[21:22] <thomi> tedg: http://pastebin.ubuntu.com/6038080/
[21:24] <tedg> Hmm, my phone is not the same...
[21:25] <thomi> huh. I'm running yeterdays pending image, I can flash again, but it takes a while...
[21:26] <tedg> I haven't flashed for a while... hate doing that.
[21:26] <tedg> Then I have to reinstall a bunch of junk.
[21:29] <tedg> thomi, Do you guys register a name on dbus?
[21:30] <tedg> thomi, How do you find the app under test?
[21:39] <thomi> tedg: umm, that but is a bit hacky :-/
[21:39] <thomi> tedg: we use the dbus introspection stuff to find the thing we're after
[21:40] <thomi> we know the pid of the app under test, so we start by looking for connections with that pid
[21:40] <thomi> then we look for exported objects with the correct interface
[21:41] <tedg> thomi, How do you get the PID of the app?
[21:42] <tedg> thomi, I don't think we're stopping apps from exporting objects, and unconfined programs should be able to talk to confined ones.  But I don't think it could, for example, call a method on your test server.
[21:42] <tedg> thomi, It can only speak if spoken to.
[21:43] <thomi> tedg: we get the pid because either we launched it directly (normal app), or we use 'upstart list' and look for the app_id we launched
[21:44] <tedg> thomi, K, you can use libupstart-app-launch to get the PID for an AppID.
[21:44] <thomi> tedg: just to be clear: an unconfined app (autopilot) can still call whatever it wants on a confined app (dropping-letters, or app under test)
[21:44] <thomi> tedg: has python bindings?
[21:44] <tedg> thomi, Yes, but the app can't call you.
[21:44] <thomi> tedg: ok, that's fine, we don't do that anyway
[21:44] <tedg> thomi, No, but it's plain C.
[21:45] <tedg> thomi, I can introspect it.
[21:45] <thomi> tedg: if there were python bindings to do that, autopilot might use them. Our current hacky solution kind of works though
[21:46] <tedg> thomi, Understand, but it would be nice to use one solution for doing it for everyone.
[21:46] <tedg> thomi, i.e. if that breaks, we need to know, so it's a good test :-)
[21:47] <thomi> sure... well, let me know when there's python2 bindings available, and I'll make the switch :)
[21:47] <thomi> or, if you want an unspecified amount of time, we'll need python3 bindings :)
[21:47] <tedg> Python2?  Isn't that for the old version for the Atari?
[21:48] <tedg> thomi, If you get upstart-app-launch-tools you can use 'upstart-app-pid'
[21:49] <thomi> heh
[21:49] <thomi> anyway, I feel like we're drifting off topic
[21:49] <thomi> about that dbus session bus thingie...
[21:50] <tedg> jdstrand said on the bug he was going to investigate that.
[21:51] <thomi> coolio
[22:46] <mzanetti> mterry: ping
[22:47] <mterry> mzanetti, hi
[22:48] <mzanetti> mterry: was thinking. how can I distinguish if the launcher should use gsettings or accountsservice?
[22:49] <mterry> mzanetti, explain?
[22:49] <mzanetti> mterry: so when running in unity it should use gsettings and sync stuff to accountsservice
[22:49] <mzanetti> mterry: and when running in the greeter only accountsservice?
[22:50] <mterry> mzanetti, Sounds right, if we are assuming we need to keep any data in gsettings after all
[22:50] <mzanetti> mterry: saviq said he wanted that, yes. forgot the reason tbh
[22:51] <mzanetti> mterry: but how do I know if its running in unity or in the greeter? do we need to add some mechanism to "configure" the launcher through it's API?
[22:51] <mzanetti> or is there something else already which gives me that information?
[22:51] <mterry> mzanetti, if $USER=lightdm maybe
[22:52] <mterry> mzanetti, or until the split, if greeter.shown
[22:52] <mzanetti> don't really have that information in the c++ side of things
[22:53] <mzanetti> I could add a temporary property though. and switch to the $USER thing once the split happened
[22:54] <mzanetti> mterry: do you think we should allow modifying the items in the greeter session?
[22:54] <mzanetti> probably not
[22:55] <mterry> mzanetti, we could...  I bet designers would like it.  maybe we should ping them
[22:55] <mzanetti> mterry: but security wise that doesn't sound like a good idea
[22:55] <mterry> mzanetti, fair
[22:55] <mterry> mzanetti, I gotta go
[22:55] <mzanetti> ok
[23:18] <om26er> mzanetti, still around ?
[23:19] <robert_ancell> mzanetti, the indicators use the $INDICATOR_GREETER_MODE to determine if they're running in the greeter - you could re-use that or we could add a new one in unity-greeter