[07:33] <mzanetti> Saviq: good morning
[07:33] <Saviq> mzanetti, o/
[07:33] <mzanetti> Saviq: hey... take the phone and turn on the screen
[07:34] <mzanetti> then start dragging the greeter, but don't release
[07:34] <mzanetti> drag left and right continuosly
[07:35] <Saviq> mzanetti, gets stuck
[07:35] <Saviq> mzanetti, probably when you reach the DirectionalDragArea
[07:35] <Saviq> :/
[07:39] <Saviq> hmm no
[07:39] <Saviq> unrelated to the DDA
[07:40] <mzanetti> Saviq: sorry... had my weekly QA sync meeting
[07:40] <Saviq> mzanetti, don't be
[07:40] <mzanetti> Saviq: soo... yes.
[07:40] <mzanetti> it freezes
[07:40] <mzanetti> and actually it happens to me (as I started dogfooding) like every 20th unlock of the phone or so
[07:40] <mzanetti> and I have to plug it and restart the shell
[07:41] <mzanetti> I have taken out all the greeter content... still happens
[07:41] <mzanetti> I have also removed the animation from the background (fade in from behind), still happens
[07:42] <mzanetti> it kinda seems as when causing too fast dragging at some point the input gets lost
[07:42] <mzanetti> as the indicator icons still change state (e.g. wifi signal strength)
[07:42] <mzanetti> Saviq: ^
[07:42] <Saviq> mzanetti, yeah, seems the Revealer gets confused
[07:42] <Saviq> or the whole input stack, even
[07:43] <mzanetti> that'd be bas
[07:43] <mzanetti> bad
[07:43] <greyback> hi guys
[07:43] <Saviq> morning greyback
[07:43] <mzanetti> hey ho greyback
[07:43] <mzanetti> greyback: one for you too:
[07:44] <mzanetti> greyback: start an app
[07:44] <mzanetti> greyback: restart the shell
[07:44] <greyback> Saviq: mzanetti: greetings on this fine morning
[07:44] <mzanetti> greyback: try to open a new app
[07:44] <greyback> mzanetti: with trunk?
[07:44] <mzanetti> greyback: or image 147 (aka. the dogfooding one)
[07:45]  * greyback gets downloading image 147
[07:52] <Saviq> mzanetti, it doesn't even feel like speed is a factor
[07:52] <mzanetti> Saviq: hmm... in my experience slow is worse than fast
[07:52] <Saviq> mzanetti, yeah I meant it happens in both cases
[07:53] <Saviq> mzanetti, it feels like some buffer overflows or something
[07:53] <mzanetti> Saviq: I have debugged it for a little while on the weekend but didn't really come to anything useful tbh
[07:57] <Saviq> mzanetti, the Revealer itself seems fine, tst_Revealer.qml doesn't show the issue
[07:59] <Saviq> mzanetti, and dropping the DirectionalDragArea doesn't help, either
[08:00] <mzanetti> Saviq: the DDA is not used when unlocking yet, is it? I think only the launcher uses it yet
[08:00] <Saviq> mzanetti, yeah, I was just afraid the interaction between them was the issue
[08:00] <mzanetti> Saviq: btw, side note: pmcgowan complained quite a bit about the DDA in the Launhcer on friday
[08:00] <Saviq> mzanetti, i.e. the fact that we've added the DDA at all
[08:01] <Saviq> mzanetti, what about?
[08:02] <mzanetti> Saviq: I guess he holds the device in the right hand, starts with the thum at the left lower corner and moves it in a sort of circular gesture towards the upper right (hope you understand what I mean)
[08:02] <mzanetti> Saviq: his finger always leaves the allowed angle and the launcher gets stuck
[08:02] <Saviq> mzanetti, possible, we simply need to tweak the values
[08:02] <mzanetti> Saviq: sergiusens on the other side really loves the current angle config
[08:05] <Saviq> mzanetti, I'm almost sure something overflows, it feels like you need to generate almost exactly the same amount of events to trigger this
[08:05] <Saviq> not that that feeling helps much
[08:05] <mzanetti> haha
[08:06] <Saviq> mzanetti, i.e. on manta I need to go back and forth 7-8 times to the center of the screen and back to the right edge
[08:07] <mzanetti> hmm... could be, yes... what I don't really understand is that it happens only with the greeter. revealing an app from the right edge doesn't have this problem
[08:07] <mzanetti> but still when removing all the greeter content and replacing it with a black rectangle, it still happens
[08:08] <Saviq> mzanetti, I feel like it's the Revealer at fault
[08:08] <Saviq> mzanetti, at least the way the Greeter uses it must be exposing some issue in it
[08:09] <Saviq> mzanetti, it's quite a complicated beast
[08:09] <mzanetti> the revealer?
[08:09] <Saviq> mzanetti, Revealer.qml
[08:10]  * mzanetti hammers prints into every line of revealer.qml
[08:10] <Saviq> mzanetti, oh, but it also gets stuck after 10 or so times being unlocked :/
[08:10] <Saviq> that's bad
[08:11] <Saviq> that's what you meant that it happens for you during normal usage
[08:11] <mzanetti> yeah
[08:11] <Saviq> I wonder why noone else dogfooding encountered that
[08:11] <mzanetti> Saviq: and then I restart the shell and get hit by the bug I reported to greyback... then I have to reboot :D
[08:11] <mzanetti> Saviq: so far everyone I told could reproduce
[08:12] <Saviq> mzanetti, yeah
[08:12] <mzanetti> Saviq: and M. Frey said he suffered from that too since a while already
[08:12] <Saviq> mzanetti, /me wonders if the buffer "drains" after time
[08:12] <Saviq> so if you only do it every minute or so
[08:12] <Saviq> it wouldn't happen
[08:12] <Saviq> but it doesn't feel so from your experience
[08:14] <greyback> yep, 13 unlocks and now I cannot unlock
[08:14] <greyback> fresh flash
[08:14] <Saviq> is bad
[08:14] <greyback> can't bring out the launcher either
[08:15]  * Saviq wonders if the IFA is animated too often
[08:15] <Saviq> that's a new thing
[08:17] <Saviq> greyback, mzanetti got it
[08:18] <mzanetti> really?
[08:18] <mzanetti>  \o/
[08:18] <greyback> :)
[08:18] <Saviq> mzanetti, drop the InputFilterArea from Greeter
[08:18]  * mzanetti pimps his dogfood
[08:21] <Saviq> wth just happened...
[08:21] <Saviq> is it just me or has compiz just become freakishly unstable?
[08:22] <mzanetti> become?
[08:22] <mzanetti> yeah... removing IFA gets around it indeed.
[08:30] <greyback> mzanetti: when you say "restart the shell" - how are you doing that?
[08:31] <mzanetti> greyback: usually I do a "sudo service ubuntu-session restart"
[08:31] <Saviq> mzanetti, greyback https://code.launchpad.net/~saviq/unity/phablet.fix-greeter-stuck/+merge/167002
[08:31] <greyback> mzanetti: I see. Usually when I do that it kills the applications too, but sometimes qmlscene doesn't respect that
[08:32] <mzanetti> Saviq: btw... afaik starting today autolanding etc will be moved over to saucy. we are supposed to backport ciritical fixes to the dogfood image manually
[08:32] <Saviq> greyback, it won't kill the apps if they're not focused (i.e. stopped)
[08:32] <greyback> Saviq: ah really
[08:32] <Saviq> greyback, yeah, as SIGINT doesn't do anything to them
[08:33] <Saviq> they need SIGKILL
[08:33] <Saviq> SIGTERM, rather
[08:33] <Saviq> (doesn't do anything)
[08:33] <greyback> makes sense
[08:34] <mzanetti> Saviq: can you explain why this actually fixes it?
[08:34] <Saviq> mzanetti, the InputFilterArea doesn't update its size all the time to match with the Greeter's
[08:34] <Saviq> mzanetti, so there's no updates sent to the input stack
[08:35] <Saviq> mzanetti, and that's what was getting stuck, I believe
[08:35] <mzanetti> Saviq: oh... I see.... didn't know the greeter is resized
[08:35] <Saviq> mzanetti, it's not
[08:35] <Saviq> mzanetti, but it's moved around
[08:35] <Saviq> mzanetti, i.e. geometry changes
[08:35] <mzanetti> Saviq: ah ok...
[08:35] <mzanetti> yeah... might wel be..
[08:35] <Saviq> mzanetti, still needs fixing at the other side
[08:35] <mzanetti> Saviq: so in that case the actual bug must be inside the IFA
[08:35] <Saviq> mzanetti, yes
[08:36] <Saviq> mzanetti, but anyway we need to review our use of IFAs to not animate them, it usually is the case of "should we filter this area or not"
[08:36] <greyback> +1
[08:36] <Saviq> mzanetti, regardless of how far the related gesture is
[08:36] <greyback> should almost be an on/off thing really IMO
[08:37] <mzanetti> yeah, I agree... thats what I do in the launcher...
[08:37] <Saviq> greyback, well, there's probably a few cases: the left / top / right edge
[08:37] <mzanetti> is >0 pixels shown, enable it fullscreen
[08:37] <Saviq> greyback, and then the whole screen
[08:37] <greyback> Saviq: hence the "almost" :)
[08:37] <Saviq> yup
[08:37] <Saviq> and yeah, the launcher
[08:37] <Saviq> and the hud
[08:38] <Saviq> so yeah, there's a few, but they should have static geometry
[08:42] <greyback> mzanetti: so restarting shell, the bug I see is that the apps lens has a black preview of an app that didn't die. I can still launch apps however, and window switching is ok. What am I missing?
[08:42] <mzanetti> greyback: my scenario:
[08:42] <mzanetti> I launcher the phone app
[08:42] <mzanetti> I launch another app
[08:43] <mzanetti> bring the phone app to top (app screenshot gets taken)
[08:43] <mzanetti> restart the shell
[08:43] <mzanetti> start the gallery, once its loaded, it shows the app screenshot of the phone (you can see the gallery starting up an initializing, but then overridden by the phone app screenshot)
[08:44] <mzanetti> Saviq: approved your fix... once this and and the app screenshot fix (^) is in, I vote for a new release as those are the only 2 issues I found while dogfooding through the weekend
[08:45] <Saviq> mzanetti, yeah, will do
[08:46] <greyback> Hmm, another bug: open phone app at the dialer screen, left-edge swipe to show launcher - rest of screen is darkened a bit, tap a number on the dialer. Dialer gets that input event, but it shouldn't
[08:46] <Saviq> mzanetti, we might also think about increasing the angle on the Launcher
[08:46] <Saviq> mzanetti, will ping pmcgowan about this later
[08:46] <mzanetti> Saviq: yeah.. I increased it to 30 in my branch.. seems perfect for me... I wanted to ask Pat how he feels with 30°
[08:47] <mzanetti> its 10° right now
[08:47] <Saviq> yeah, probably too low
[08:48] <mzanetti> Saviq: btw... I think my launcher branch improves the overall behavior quite a bit.. might make sense if you guys start testing it
[08:48] <Saviq> mzanetti, yeah, will do
[08:49] <mzanetti> I'll push the 30 degrees there
[08:51] <mzanetti> Saviq: btw... xbmcremote should be in a usable state (in case you wanna start dogfooding too ;)
[08:51] <Saviq> :)
[09:01] <greyback> mzanetti: I'm really struggling to reproduce your bug. Worst I see is a flicker of the last-focused-app when launching a new app (not good tho, will look into it)
[09:02] <Saviq> fook... with every letter I type into the dash, a Chromium tab is opened <facepalm>
[09:05] <greyback> oO
[09:05] <greyback> that's insane
[09:05] <greyback> ghost in the machine?
[09:06] <Saviq> greyback, probably some scope gets confused
[09:07] <greyback> confused or not, no scope should be able to do anything like that
[09:09] <Saviq> greyback, actually it's the online accounts
[09:10] <Saviq> greyback, it had (has?) problems with accessing my google account, so signon-ui did something weird
[09:11] <greyback> Saviq: very very weird
[09:11] <mzanetti> greyback: ok... I only can reproduce it in combination of the greeter bug
[09:11] <mzanetti> greyback: so open an app, say the phone-app
[09:12] <mzanetti> greyback: lock the screen, and then reproduce the hang by swiping the greeter left/right continuously
[09:12] <mzanetti> greyback: it'll get stuck, then reboot the shell and try starting another app
[09:12] <mzanetti> don't ask me how that is related...
[09:13] <greyback> Ok, will try. But code-wise, before /every/ animation we request a new screenshot. They are cached however, so maybe there's a cache bug. Will see
[09:13] <greyback> thanks for digging for me
[09:14] <mzanetti> greyback: are you doing something when the animation is finished too?
[09:14] <mzanetti> greyback: so maybe its only when restarting the shell in the middle of an animation
[09:14] <Saviq> mardy, ping
[09:14] <greyback> mzanetti: nope, nothing fancy on animation finish. Just hide the screenshot
[09:15] <greyback> but we always refresh screenshot before starting a new animation
[09:15] <mzanetti> greyback: weird thing is, while an animation is running I can see the screenshot of the correct up. only when it then sits there and should run (e.g. no screenshot at all) I see the screenshot of the app from before the restart
[09:16] <mzanetti> s/up/app/
[09:22] <Saviq> mzanetti, I think it might be not a screenshot, but the actual app
[09:23] <Saviq> mzanetti, while the new app is painting its first frame
[09:44] <mzanetti> Saviq: should I create a new directory test/qttest/ in unity-api?
[09:49] <greyback> mzanetti: hmm, while I've still not found your exact bug, I've found something quite likely related. At least it's somewhere to start
[09:49] <nic-doffay> Saviq, I think the infographics are ready to land now. Mind giving me and updated opinion?
[09:51] <nic-doffay> Saviq, just noticed one more bug I'll chat to pete-woods about it, will get back to you when it's sorted.
[09:52] <pstolowski> sil2100: ping
[10:00] <nic-doffay> Saviq, apparently it's cool. As above if you wouldn't mind having another look at it.
[10:00] <Saviq> mzanetti, yes please
[10:01] <Saviq> nic-doffay, mzanetti was doing your review there, so I'll let him take care of it :)
[10:01] <mzanetti> ack
[10:01] <nic-doffay> mzanetti, hold off on that... Merging trunk overwrote something.
[10:09] <mardy> Saviq: pong
[10:09] <Saviq> mardy, hey, it seems signon-ui has some issues with the Ubuntu-SSO enabled Google accounts
[10:09] <Saviq> mardy, at some point every letter entered into the dash opened a tab in Chromium for me...
[10:10] <mardy> Saviq: what did the tabs contain?
[10:10] <Saviq> mardy, about:blank...
[10:11] <mardy> weeeird
[10:11] <Saviq> mardy, resolved now after a few runs of "give access" in signon-ui, but just letting you know that there are some issues like that
[10:11] <mardy> Saviq: I'll check, thanks
[10:11] <Saviq> mardy, weird indeed, imagine how I felt ;)
[10:13] <nic-doffay> mzanetti, lol
[10:14] <nic-doffay> Doing one last commit for new gradients.
[10:25] <nic-doffay> mzanetti, it's ready whenever you are. Shouldn't be a lot left to look at.
[10:30] <mzanetti> nic-doffay: hehe... go into your builddir and do a "make testGreeter". Seems the infographics has troubles keeping the pace :)
[10:30] <nic-doffay> mzanetti, argh forgot about the tests.
[10:31] <mzanetti> nic-doffay: you're lucky... till all passing. however, I miss a test that actually waits for the animation to be completed and checks if everything is fine
[10:31] <mzanetti> nic-doffay: do you think that would be worth having?
[10:33] <nic-doffay> mzanetti, elaborate on everything fine :P
[10:34] <mzanetti> nic-doffay: the animation actually stops and all the final values have been reached
[10:34] <mzanetti> nic-doffay: and it seems you messed up with the last merge. you reverted the change from mterry that changes the PathView to be a ListView
[10:35] <nic-doffay> mzanetti, I'll revert back to his revision.
[10:37] <mzanetti> nic-doffay: the rest seems ok to me... fix that merge and we can merge it I'd say
[10:38] <nic-doffay> mzanetti, any idea what's going on with the tests?
[10:38] <mzanetti> nic-doffay: ?
[10:38] <mzanetti> whats wrong with them?
[10:39] <nic-doffay> getting errors trying to make them.
[10:39] <nic-doffay> mzanetti, ^
[10:39] <mzanetti> nic-doffay: works fine for me
[10:40] <mzanetti> nic-doffay: if the error is "cannot load libunity-core-0.6.so.5" or something like that, wipe your unity_build directory and do a fresh ./build -s
[10:40] <mzanetti> I had that end of last week
[10:40] <nic-doffay> cool
[11:09] <Cimi> in qml, how do I write a timer to update a variable at midnight?
[11:11] <Cimi> not sure I can change the interval while running...
[11:11] <Saviq> Cimi, ATM you'd need a timer to check every minute if midnight passed
[11:12] <Cimi> Saviq, updating the interval?
[11:12] <Cimi> Saviq, when you start the calender, it's as long as the remaining time till midnight
[11:13] <Cimi> Saviq, then you trigger it and set interval of one day
[11:14] <Saviq> Cimi, that's complicating too much, we'll later have an object that you will ask for signals with given resolution
[11:14] <Cimi> ok
[11:14] <Cimi> Saviq, I'm sick btw :)
[11:14] <Saviq> Cimi, and why're you happy about that? ;)
[11:15] <Cimi> Saviq, not happy :)
[11:15] <Cimi> Saviq, but better to mile than being sad, always
[11:22] <nic-doffay> mzanetti, is it literally only the PathView that needs to be changed back to a ListView?
[11:23] <mzanetti> nic-doffay: no... I think mterry's commit did a few other small graphical changes too
[11:24] <mzanetti> Saviq: question: unity-apis will generate a library we can link at some point, right?
[11:24] <nic-doffay> mzanetti, is that revision 656?
[11:26] <mzanetti> nic-doffay: don't think so
[11:27] <mzanetti> nic-doffay: oh shit... it reverts more
[11:27] <mzanetti> nic-doffay: also the fix that we have only 50 people in the lens
[11:28] <nic-doffay> mzanetti, which revision screwed everything?
[11:29] <mzanetti> nic-doffay: I guess your last merge
[11:29] <mzanetti> nic-doffay: the changes you reverted came in friday afternoon... so you messed up either friday night or today morning
[11:30] <Saviq> mzanetti, not sure about that, at least for the abstract headers I really just planned to include them as sources in the implementation
[11:31] <mzanetti> Saviq: so the actual question is, if I create a mock implementation with some launcher entries now, how will I be able to use that in the shell until the real one is done?
[11:32] <Saviq> mzanetti, a plugin on the same path should be enough?
[11:32] <mzanetti> Saviq: plugin?
[11:33] <Saviq> mzanetti, your case might be slightly different
[11:33] <mzanetti> Saviq: so it is a lib in the end...
[11:34] <Saviq> mzanetti, for Notifications what we have is a mock implementation (a Unity.Notifications plugin) inside lp:unity-api
[11:34] <Saviq> mzanetti, but that's just minimal, one that's used to pass the tests inside lp:unity-api
[11:35] <mzanetti> Saviq: right... but in that case you don't need the header and as long as there is a plugin with that name somewhere it'll work
[11:35] <Saviq> mzanetti, yeah, the header is just convenience
[11:35] <mzanetti> Saviq: in my case I need to include a header and then still someone needs to load the actual backend and give me a pointer to it somehow
[11:37] <Saviq> mzanetti, easiest solution would be to have a separate "Launcher backend" plugin, one that will expose the list of favourites, and that we can pass to our internal launcher model
[11:39] <mzanetti> Saviq: the plugin interface is then in the unity-api repo or in ours?
[11:39] <Saviq> mzanetti, I'm starting to think the separation between "our part of the backend" and "their part of the backend" becomes difficult
[11:42] <Saviq> mzanetti, there should be just one "Unity.Launcher" plugin that does everything what we need - and the shell-facing interface would just be model, with a way to pass the list of running apps to it
[11:43] <mzanetti> Saviq: hehe... thats what we asked you in the meeting last week
[11:43] <Saviq> mzanetti, I misunderstood the question, then :/
[11:43] <Saviq> mzanetti, I don't see a reason to split it up unnecessarily
[11:44] <mzanetti> Saviq: nah... I think its fine right now... the question is just how to load the backend implementation from with in c++
[11:44] <Saviq> mzanetti, I don't think we need to, we just need to pass the list of favorites to the "launcher model"
[11:45] <Saviq> mzanetti, this way we'll be able to qml-test it easily, too
[11:46] <Saviq> mzanetti, i.e. Launcher.Model { favourites: Launcher.favorites; running: Mir.runningApps }
[11:46] <mzanetti> Saviq: so you mean the launchermodel I have in my launcher branch should be moved over to unity-apis?
[11:46] <Saviq> mzanetti, not the implementation of it, just the interface definition, with the abstract headers
[11:47] <mzanetti> Saviq: huh? I don't see what that would change
[11:47] <Saviq> mzanetti, mumble?
[11:47] <mzanetti> yeah
[11:57] <sil2100> pstolowski: pong!
[11:58] <pstolowski> sil2100: heyah! how does the landing story look today?
[11:59] <sil2100> pstolowski: I just finished all the irritating tax errands so I can start soon
[11:59] <didrocks> pstolowski: we'll need to disable 2 scopes though, the 2 python2 ones (launchpad and sshsearch)
[12:00] <didrocks> sil2100: you will have a libunity update to do for that I guess ^
[12:00] <didrocks> (and rebuilding libunity and then unity)
[12:00] <didrocks> pstolowski: we can still land them in universe though
[12:00] <pstolowski> didrocks: what's wrong with them?
[12:00] <didrocks> pstolowski: we are moving away from python2 installed by default
[12:00] <didrocks> so we don't want to introduce back python2 deps
[12:01] <pstolowski> didrocks: ah, fair enough
[12:01] <pstolowski> didrocks: will let davidcalle know..
[12:01] <didrocks> pstolowski: thanks, I was hunting for him, but not around :p
[12:02] <sil2100> Ah, so the decision is 'no' to those scopes in the end
[12:02] <didrocks> yep :)
[12:02] <didrocks> sil2100: pstolowski: I'll let you handle the 2 rebuilds?
[12:05] <pstolowski> didrocks: I'm unclear on what that means and what needs updating in libunity?
[12:05] <sil2100> didrocks: same here - do you mean getting rid of python2 deps?
[12:06] <sil2100> In libunity?
[12:06] <mhr3> pstolowski, client-scope.json
[12:06] <mhr3> scopes*
[12:06] <pstolowski> mhr3: right..
[12:06] <sil2100> oh
[12:06] <didrocks> mhr3: someone following, thanks! :)
[12:06] <didrocks> so updating this one
[12:07] <sil2100> mhr3: thanks, forgot about that one
[12:07] <didrocks> and have unity rebuilt to pick the recommends frmo the new .json file
[12:07] <sil2100> pstolowski: can you scratch out a MR?
[12:07] <pstolowski> sil2100: y
[12:07] <sil2100> Thanks! I'll approve it when needed
[12:15] <pstolowski> davidcalle: hi!
[12:19] <davidcalle> pstolowski, hey :)
[12:19] <greyback> back, had power outage
[12:20] <pstolowski> davidcalle: (13:59:53) didrocks: pstolowski: we'll need to disable 2 scopes though, the 2 python2 ones (launchpad and sshsearch)
[12:20] <pstolowski> davidcalle: (14:00:23) didrocks: pstolowski: we can still land them in universe though
[12:20] <pstolowski> davidcalle: (14:00:48) didrocks: pstolowski: we are moving away from python2 installed by default
[12:21] <davidcalle> pstolowski, thanks for the heads up. Universe is ok until their deps move to python3 (or maybe Launchpad could end up server side).
[12:23] <pstolowski> davidcalle: https://code.launchpad.net/~stolowski/libunity/disable-some-scopes/+merge/167027
[12:23] <pstolowski> sil2100: ^
[12:24] <didrocks> pstolowski: you should bump debian/changelog version so that unity can build-dep on it
[12:24] <didrocks> sil2100: ^
[12:25] <pstolowski> didrocks: k
[12:34] <sil2100> didrocks: just making sure, a bump to 7.0.0daily13.05.31ubuntu.unity.next-0ubuntu2 is ok, right? It certainly doesn't look beautiful when dep'ing such a version, but should be ok?
[12:35] <didrocks> sil2100: should rather be 7.0.1 IMHO but that's fine as well
[12:36] <didrocks> sil2100: hum, look at what's in the ppa
[12:36] <didrocks> sil2100: but I guess the version is higher than 7.0.0daily13.05.31ubuntu.unity.next-0ubuntu2
[12:36] <greyback> mzanetti: I've replied to a couple of your comments, can I get your input please https://code.launchpad.net/~gerboland/unity/refactor-wm-and-test/+merge/166524
[12:37] <sil2100> didrocks: I was wondering about bumping the micro version, but we're not really breaking the API here...
[12:39] <didrocks> sil2100: micro version is not for breaking the API, it's more for adding a new capability that you depend on, which is the case here, you want to pick the latest :)
[12:40] <sil2100> didrocks: that's not what the example in the FAQ shows! ;)
[12:40] <didrocks> sil2100: it's a wiki, feel free to edit it to amend it :)
[12:42] <sil2100> pstolowski: so, as I discussed with didrocks, change the version number to 7.0.1-0ubuntu1 if you can (and in configure.ac bump the version as well)
[12:43] <sil2100> pstolowski: this way it'll be indeed cleaner in the unity dependencies
[12:43] <mzanetti> greyback: answered
[12:43] <greyback> mzanetti: thanks
[12:44] <greyback> mzanetti: ok I see the value, I'll add it. Shouldn't take too long
[12:51] <mzanetti> Saviq: ok. now I don't see any more why I would need anything in unity-apis at all for the launcher... I would just move that header file into lp:unity/phablet and we implement all stuff in there
[12:51] <Saviq> mzanetti, thing is, ultimately we don't want the Unity.Launcher plugin to live with lp:unity/phablet
[12:52] <mzanetti> oh... I see
[12:52] <Saviq> mzanetti, because we want to allow different implementations of it
[12:52] <Saviq> mzanetti, hence the need for lp:unity-api at all - a way to maintain a contract between the shell and $implementation
[12:53] <Saviq> mzanetti, i.e. the shell is supposed to be a dumb View on top of the data coming from Unity.Launcher
[12:53] <Saviq> mzanetti, and whoever implements Unity.Launcher needs to adhere to that contract
[12:53] <Saviq> mzanetti, hence the split
[12:53] <sil2100> didrocks: to get the unity libunity version bump in, I will have to first run the re-build for libunity alone, right? Since otherwise the merger won't find 7.0.1 and will bail out - the other way would be merging it in manually and re-running both libunity and unity at once
[12:53] <Saviq> mzanetti, you can live without it of course
[12:54] <Saviq> mzanetti, but you'll just have more work ahead of you
[12:54] <didrocks> sil2100: exactly
[12:54] <Saviq> and by you I mean $someone who implements the Unity.Launcher plugin
[12:54] <Saviq> mzanetti, ^
[12:55] <didrocks> sil2100: as you wish, check with upstream but personnally, I'm fine with a manual push to speed this up (on the unity side)
[12:55] <mzanetti> Saviq: ok... but that header that I have in there right now doesn't make any sense in there
[12:55] <Saviq> mzanetti, /me looks
[12:56] <mzanetti> Saviq: thats basically the interface between me an Wellark
[12:56] <mzanetti> and
[12:56] <Saviq> mzanetti, yeah
[12:56] <Saviq> mzanetti, that's not supposed to be there
[12:57] <mzanetti> ok... so for now I just put that into lp:unity/phablet and create the other interface in the unity-apis. we can start with the implementation in unity/phablet until we know where it should go for real
[12:57] <mzanetti> Saviq: ^
[12:57] <Saviq> mzanetti, yeah, we can just extract the API parts later
[12:58] <Saviq> mzanetti, but yeah, just go with a simple implementation now
[12:58] <Saviq> mzanetti, simply because it will probably change substantially as we go
[12:58] <Saviq> mzanetti, and at the end when we decide it's ready to ship, we extract it
[12:59] <Saviq> mzanetti, and start enforcing the contract
[13:02] <Saviq> mzanetti, sorry if I got you confused
[13:03] <mzanetti> you kinda did :D no worries tho.
[13:05] <kgunn> Saviq just 2 cents....we should probably enforce few weeks before Oct
[13:05] <kgunn> just as a test to see if we're settled
[13:06] <Saviq> kgunn, way before that :)
[13:06] <kgunn> if api's still changing...that'd be troubling
[13:06] <mzanetti> lol
[13:06] <kgunn> Saviq cool....wasn't sure what you meant by "ready to ship"
[13:06] <sil2100> bregma: ping!
[13:06] <Saviq> kgunn, "when we decide it's ready to be enforced" more or less :)
[13:06] <mzanetti> kgunn: if it compiles, ship it
[13:07] <Saviq> kgunn, so "when it works" more or less
[13:07] <kgunn> Saviq mzanetti cool
[13:08] <kgunn> Saviq mzanetti as long as "when it works" is prior to Oct minus 3 weeks ; )
[13:08] <Saviq> right ;)
[13:09] <nic-doffay> kgunn, any more info on the next task for me or should I just shout at Loic?
[13:10] <bregma> sil2100, pong
[13:11] <kgunn> nic-doffay ping loic he was ready when you are
[13:11] <kgunn> Saviq ^ nic-doffay gonna tackle openeffect
[13:11] <Saviq> kgunn, yup, great, thanks
[13:12] <sil2100> bregma: we're modifying he list of scopes in libunity and bumping the version of libunity, we'll also need to bump the dep in unity
[13:13] <sil2100> bregma: would you mind if I would merge in manually https://code.launchpad.net/~sil2100/unity/bump_libunity_for_scopes/+merge/167031 once the libunity version bump is in?
[13:13] <sil2100> bregma: since otherwise the merger won't let the merge in, because we would have to release the libunity new version first
[13:13] <sil2100> But with a manual merge, we can do both at once
[13:14] <bregma> sil2100, unity 7.0.1 would be a raring SRU release
[13:14] <bregma> I think you would want to prepare a 7.1.0 release
[13:15] <sil2100> bregma: I mean libunity 7.0.1
[13:16] <sil2100> bregma: since from what I see saucy has 7.0.0 with the 100scopes right now... is that incorrect?
[13:16] <bregma> ah, OK, I misread the merge
[13:16]  * bregma rubs his eyes again
[13:20] <sil2100> bregma: once this merge (for libunity) gets in [1], I would like to merge manually the branch I pasted earlier
[13:20] <sil2100> [1] https://code.launchpad.net/~stolowski/libunity/disable-some-scopes/+merge/167027
[13:25] <didrocks> tedg: so, we have maybe found the source of the hang in dbus and the whole machine
[13:25] <didrocks> mhr3: ^
[13:25] <tedg> ?
[13:25] <sergiusens> mzanetti: Saviq I do, less randomness going on! I'd really like some histerisys for bringing up the launcher too :-)
[13:25] <didrocks> hud-service is using 2.2g
[13:25] <didrocks> so the machine is swapping
[13:25] <didrocks> and dying
[13:25] <didrocks> sil2100: ^
[13:25] <mhr3> didrocks, wooooo
[13:25] <tedg> didrocks, Ah, on Unity 7?
[13:25] <mzanetti> sergiusens: what are you talking about?
[13:25] <didrocks> tedg: right
[13:26] <tedg> didrocks, Yeah.  I've got a fix on the TODO list for that.
[13:26] <tedg> didrocks, Queries aren't getting free'd in HUD.
[13:26] <mzanetti> sergiusens: ah... the revealing angle
[13:26] <didrocks> tedg: can it get higher on the stack? It's blocking us for more than a month ;)
[13:26] <sergiusens> mzanetti: yeah, that :-)
[13:27] <tedg> didrocks, Oh, I didn't realize.  I figured it wasn't a big deal because for most people HUD dies in 10 min anyway.
[13:27] <mhr3> didrocks, can't we just kill hud before each AP invocation for now?
[13:27] <sil2100> !
[13:27] <didrocks> tedg: or add a segfault please :p
[13:27] <mzanetti> sergiusens: could you try with 30 degrees angle if you still like it?
[13:27] <didrocks> mhr3: is it possible in AP?
[13:27] <didrocks> sil2100: maybe would know ^
[13:27] <mhr3> didrocks, i mean in the thing that invokes AP
[13:27] <tedg> didrocks, I'll work on that today.  I don't think it's a big deal actually.  Sorry it was blocking you.
[13:28] <didrocks> mhr3: no, it's a black box for us
[13:28] <didrocks> mhr3: AP runs all the tests
[13:28] <didrocks> and returns
[13:28] <didrocks> so it should be the tests in a teardown doing that
[13:28] <Saviq> sergiusens, what hysteresis do you have in mind?
[13:28] <sil2100> mhr3: what do you have in mind exactly?
[13:28] <didrocks> tedg: no worry, we didn't know the source of the issue, we were thinking of a dbus issue first
[13:28] <mhr3> didrocks, yea, but i meant that the machine is going to survive one AP check (the 500 tests), just kill it before that
[13:28] <mzanetti> sergiusens: /usr/share/qml-phone-shell/Launcher/Launcher.qml, search for DirectionalDragArea and change "angle: 10" to "angle: 30"
[13:29] <didrocks> tedg: just know, as we are on the machine when the freeze happened, we realized the issue
[13:29] <sergiusens> Saviq: some sort of acceleration and drag from the edges... to get what I mean, try and tick a checkbox in the gmail webapp
[13:29] <mhr3> didrocks, but anyway, if ted says it should be easy to fix... why bother
[13:29] <sergiusens> mzanetti: I like it how it is
[13:29] <sergiusens> :-)
[13:29] <didrocks> mhr3: the issue is that even the machine is dying and so the tests are going to take 3 hours. I think it's better to be able to kill it if needed between the tests
[13:29] <mzanetti> sergiusens: I'm having some troubles too with 10°
[13:30] <mzanetti> sergiusens: seems a little too restrictive to me
[13:31] <sil2100> didrocks, mhr3: between tests we can do easily, but not sure if that won't cause some AP test failures, as I noticed that sometimes HUD is a bit flacky before first usage of a newly spawned hud-service
[13:32] <sergiusens> mzanetti: I like angle 10 :-) But I may be just strange
[13:32] <mzanetti> sergiusens: did you try with 30?
[13:33] <sergiusens> mzanetti: not really..one sec
[13:34] <mzanetti> sergiusens: I know that 10 is great for people like you. but as we also know that 10 is too low for people like Pat, we try to find out if 30 would still be ok for people like you :P
[13:34] <Saviq> greyback, dude, you're in a park!? :)
[13:35] <greyback> Saviq: have plumber in the house drilling, so out in bard garden
[13:35] <greyback> back
[13:35] <Saviq> mterry, can you hear us?
[13:35] <sergiusens> mzanetti: it's ok... but I think Pat is only in the _reveal the launcher_ as an independent thing.. I don'k like the launcher revealing when I'm swiping in the gallery for example, and that reduced it's chance of doing _the wrong thing_ (the wrong thing being not what I expected :-D)
[13:35] <mterry> Saviq, no
[13:35] <mterry> hmm
[13:37] <nic-doffay> Saviq, I have nothing to report, going to skip on the standup, waiting to hear back from Loic...
[13:37] <Saviq> nic-doffay, k
[13:41] <mzanetti> lol... I like greyback's birds
[13:41] <mzanetti> :D
[13:44] <mzanetti> katie: should it be the always the ubuntu wallpaper or the current wallpaper?
[13:45] <sil2100> didrocks, cyphermox, tedg: what's the status with the indicator stack right now? Can we switch daily-release again, or not yet?
[13:46] <sil2100> Since we'll need some indicators for saucy at least, so at least a manual re-build once the configs are switched
[13:46]  * didrocks is interested as well about it :)
[13:46] <katie> mzanetti: I think the current wallpaper
[13:46] <cyphermox> it would be nice to re-enable that , yes
[13:46] <mzanetti> katie: ok, thanks
[13:46] <tedg> charles, larsu, what are your thoughts on sil2100's question?
[13:46] <katie> mzanetti, but hopefully we can get the blur and it won't need to be anything other than the ubuntu wallpaper
[13:46] <sil2100> cyphermox: I can do that in my merge I'm preparing right now
[13:46] <cyphermox> it should already be set up for saucy
[13:47] <sil2100> cyphermox: indeed it is :) Thanks!
[13:47] <tedg> It seems now that we have the base ido stuff we can transition softly, no?
[13:47] <mzanetti> katie: hehe, yes
[13:47] <sil2100> charles, larsu: ^
[13:47] <cyphermox> sil2100: we really just need the ok from ted / larsu that we'd be good to re-enable the indicators after whatever it is transition that was being done..
[13:48] <larsu> sil2100, tedg: I think we can switch at this point
[13:49] <sil2100> larsu: awesome, so I'll switch the stack 'on' today along with all the other transitioning stuff
[13:49] <didrocks> larsu: no change in the package list?
[13:50] <seb128> does that mean that we will have gmenumodel version of indicators landing in saucy?
[13:50] <didrocks> or tests to run?
[13:50] <seb128> is unity7 handling those fine? (we didn't get any unity landing yet in saucy)
[13:50] <didrocks> sil2100: btw, meanwhile you can maybe start publish the other stack, just don't touch the HUD one for now please :)
[13:50] <mzanetti> katie, mterry: I've updated the branch and replaced the Blur with a background image: lp:~unity-team/unity/phablet-pinlock
[13:51] <tedg> seb128, They're starting to, but we now have the infrastructure to transition smoothly.
[13:51] <mterry> mzanetti, ok
[13:51] <mzanetti> katie: let me know if you need help running/testing it on the device
[13:51] <sil2100> didrocks: will do slowly, I'll merge in the unity dependency switch now that libunity's version bump is in
[13:51] <katie> mzanetti, thanks
[13:51] <larsu> didrocks: nope
[13:51] <tedg> seb128, IDO and libindicator have stable base classes.
[13:51] <katie> mzanetti, don't have a device right at this moment, but will probably ask for help a bit later
[13:51] <mzanetti> sure
[13:52] <larsu> sil2100: which indicator would even get switched over? I don't think we landed any gmenu-port in trunk..
[13:55] <sil2100> larsu: this would basically mean that current trunks of all indicator packages would start being published to ubuntu saucy daily, so whatever you have in trunks right now
[13:56] <sil2100> larsu: we have been asked during the sprint to disable that for some transitioning period or something, not really up-to-date with if everything got done now
[13:56] <mterry> mzanetti, I'd like your opinions on https://code.launchpad.net/~mterry/unity/phablet-greeter-single-user/+merge/166296 when you have time to review
[13:56] <larsu> sil2100: yeah I know, but I think we didn't land anything in the trunks - so not much would change
[13:57] <larsu> sil2100: I think we will very soon though, and it'd be nice if those changes got autolanded
[14:08] <nic-doffay> Saviq, I need some pointers about what I need to do for this opening effect.
[14:13] <Saviq> nic-doffay, do you have a Nexus 10 around?
[14:14] <nic-doffay> Saviq, nope
[14:14] <nic-doffay> Not of my own at least.
[14:14] <nic-doffay> Saviq, I'll have to see if I can borrow someone else's.
[14:14] <Saviq> nic-doffay, try with jounih and / or vesar
[14:15] <Saviq> nic-doffay, thing is: if you open the preview on the phone, it's more or less fluid
[14:16] <Saviq> nic-doffay, but if you open it on the Nexus10, depending on where you open it, it's not fast enough
[14:16] <Saviq> nic-doffay, and we had an idea how to reduce it to a single ShaderEffect... Kaleo_, can you shed some light on the OpenEffect? how did we want to simplify it?
[14:18] <Saviq> nic-doffay, one thing for sure: clip: true shouldn't be needed in there
[14:18] <Saviq> nic-doffay, a combination of fragment and vertex shaders should make sure we only paint the top and bottom parts, respectively
[14:19] <Saviq> nic-doffay, that's part of where the slowness might come from - we effectively draw the surface twice, clipping both
[14:26] <Kaleo_> nic-doffay: to summarize the issue is that it's not fast enough
[14:27] <nic-doffay> Kaleo_, I'm not even aware of what the OpenEffect is atm.
[14:27] <mzanetti> nic-doffay: Components/OpenEffect.qml
[14:28] <Kaleo_> nic-doffay: Saviq needs to have a hangout with you then
[14:28] <Saviq> nic-doffay, ok yeah, let's start from the beginning
[14:29] <Saviq> nic-doffay, can we do a quick hangout?
[14:29] <sil2100> In the meantime...
[14:29] <sil2100> cyphermox: could you do a deep review of the switch branch without top-approving for now?
[14:29] <mzanetti> mterry: is it ok that you remove the call to showPrompt() ?
[14:29] <sil2100> cyphermox: https://code.launchpad.net/~sil2100/cupstream2distro-config/switch_unity_and_deps_to_saucy/+merge/167043
[14:30] <cyphermox> sure
[14:30] <nic-doffay> Saviq, yeah sure
[14:30] <mzanetti> ah I see... you removed all the users... ok
[14:30] <mterry> mzanetti, the only users I leave in the demo mock is the guest one, which doesn't use a prompt
[14:30] <cyphermox> sil2100: does the QA team already have the -ci stuff setup for saucy? I'm not sure
[14:31] <mterry> mzanetti, note that this branch has implications for your pinlock branch (in the sense that it will make it more likely you'll want to add a new lightdm mock for your pin case)
[14:32] <mzanetti> mterry: I can still use the full mock to testsing, no?
[14:32] <mterry> mzanetti, yes and no...
[14:33] <mterry> mzanetti, full mock will still be there, but your code currently has a hard-coded 'LightDM.Greeter.authenticate("has-pin")' bit
[14:33] <mterry> mzanetti, ideally...
[14:34] <mterry> mzanetti, on startup in single-user mode, the greeter would start authenticating that single user
[14:34] <mterry> mzanetti, which would be the pin user in your test.  We can't leave that hardcoded has-pin name in the code
[14:34] <mterry> mzanetti, and we aren't showing the PIN screen in multi-user mode, which is the mode you get with the full mock
[14:36] <mzanetti> mterry: I'm not sure where to call authenticate() anyways
[14:37] <mzanetti> but for testing I should be ok with calling authenticate("has-pin")
[14:37] <mterry> mzanetti, but you have that call directly in the qml code, as I recall.  Not in the test mock
[14:38] <mterry> mzanetti, you see in LoginList, where we connect to onCountChanged?  That's the startup authentication for the LoginList
[14:38] <mzanetti> mterry: yes... Its in the code for testing purposes... as designers want to be able to see the lockscreen on the phone
[14:38] <mterry> mzanetti, the single user mode needs a similar logic
[14:40] <mterry> mzanetti, the designers want the demo code to use the pin, or they want to be able to look at the pin screen by manually running in a test mode?
[14:41] <mzanetti> mterry: well, they want to use it somehow without knowing what a LD_LIBRARY_PATH is
[14:42] <mterry> mzanetti, maybe it makes sense to switch the default ./run -f plugin to be your (unwritten) new pin lightdm mock
[14:42] <mterry> mzanetti, instead of the full one, since our focus is really the phone anyway
[14:43] <mterry> mzanetti, I am just uncomfortable with hardcoding testing user names in the non-test code  :)
[14:43] <mterry> mzanetti, but to add your new pin lightdm mock, you'll probably want to have my branch landed
[14:43] <mzanetti> mterry: sure... that has to go
[14:44] <mzanetti> mterry: but I still don't know how this will work...
[14:44] <mzanetti> mterry: what should I call then? authenticate() without any username?
[14:45] <mterry> mzanetti, you'll do the same thing LoginList does, but instead of authenticating with the selected user in the list, you'll authenticate with the first (really only) user in the LightDM.Users model
[14:46] <mterry> mzanetti, the LoginList has onCountChanged logic for startup purposes.   You'll just need to do a similar thing on startup in your new qml code
[14:48] <mzanetti> mterry: ok
[14:48] <mzanetti> mterry: your branch looks good
[14:51] <Saviq> nic-doffay, here's a very simple example of how it's used: lp:~saviq/+junk/open-transition
[14:51] <nic-doffay> Saviq, cool ta
[14:51] <sil2100> fginther: ping
[14:52] <fginther> sil2100, morning!
[14:52] <sil2100> fginther: morning!
[14:52] <mzanetti> infographic has landed \o/
[14:52] <mzanetti> pete-woods: nic-doffay: ^
[14:52] <nic-doffay> mzanetti, ^5
[14:53] <sil2100> fginther: could you take a look and give us a sign if CI is ready for a switch to saucy? https://code.launchpad.net/~sil2100/cupstream2distro-config/switch_unity_and_deps_to_saucy/+merge/167043
[14:53] <pete-woods> mzanettii: woot!
[14:53] <pete-woods> mzanetti even!
[14:54] <mzanetti> :)
[14:55] <fginther> sil2100, cool! I'll take a look
[14:58] <didrocks> sil2100: publishing the apps stack meanwhile?
[15:02] <sil2100> didrocks: by publishing, you mean for raring? ;) I can force it if the HUD thing is under your control!
[15:03] <didrocks> sil2100: from what I know, there is no big change in the HUD, but you should better check :)
[15:03] <didrocks> (like no ABI change)
[15:04] <Saviq> mzanetti, hum, so we want to release to include the greeter fix, but now infographics landed - are we sure we want them in the (probably last) release for raring?
[15:04] <mzanetti> Saviq: uh... right
[15:05] <mzanetti> Saviq: I don't see how it would break anything else... (but I guess that counts to famous last words too)
[15:07] <Saviq> mzanetti, as 147 is supposed to be the last raring thing, I'd rather branch from release 180 and cherry pick into it
[15:07] <Saviq> s/thing/image/
[15:07] <Saviq> and we all need to move to saucy soon
[15:07] <sil2100> didrocks: all looks ok, forcing publishing of the apps stack for raring
[15:08] <mzanetti> Saviq: yeah... that makes sense... we should only cherry-pick stuff to that dogfooding image anyways
[15:08] <Saviq> mzanetti, yup
[15:08] <didrocks> sil2100: thanks!
[15:10] <sil2100> didrocks: btw. are you doing some experimenting on the QA stack right now? Since I see it was published 29 minutes ago, but it looks as if it was re-run like around 10 minutes ago again
[15:10] <sil2100> Just not published because check failed
[15:11] <didrocks> sil2100: yeah, it's the one we are experimenting on until ted is fixing the HUD (as the swapping is killing the machine)
[15:11] <sil2100> didrocks: I'll also force publishing of the unity stack in a moment
[15:11] <didrocks> sil2100: ok, good :)
[15:11] <didrocks> sil2100: we didn't have a package list on the QA stack, so creating it :(
[15:11] <didrocks> sil2100: do you mind creating the package list for unity please?
[15:12] <didrocks> sil2100: listing all the binaries we need to install from this stack?
[15:12] <didrocks> sil2100: there is ./daily-release/jenkins-tools/default-binaries which should help getting the biggest of it
[15:13] <didrocks> sil2100: but it's ignoring all the stuff that are not installed by default, so no scope
[15:13] <didrocks> they need to be added manually :)
[15:14] <mterry> mzanetti, when I run trunk with ./run -f, I don't see the infographic anymore.  Is there some package I need to update or something?
[15:15] <mzanetti> mterry: right... that's probably a bug... didn't think of the -f when reviewing the infographics stuff
[15:16] <mzanetti> mterry: basically they patched the mock plugin... seems only the non-f one
[15:16] <mzanetti> pete-woods: ^
[15:16] <pete-woods> mzanetti: we patched both I thoguht
[15:17] <sil2100> didrocks: ok!
[15:17] <mzanetti> pete-woods: doesn't seem to work with the full one. I didn't investigate why
[15:17] <sil2100> didrocks: will try adding that - can I attach that to the branch/merge that's doing the saucy switch?
[15:17] <mzanetti> mterry: pete-woods: oh... it works
[15:17] <pete-woods> mzanetti: I understand why
[15:18] <mzanetti> mterry: pete-woods: its only the first few users don't have any
[15:18] <pete-woods> it's becuase the default user has no infographic data
[15:18] <sil2100> didrocks: or should I merge it in before doing the switch ;) ?
[15:18] <Cimi> how do I bind two properties?
[15:18] <Cimi> in qml
[15:18] <mterry> pete-woods, mzanetti : only empty-name and has-password have them?
[15:18] <didrocks> sil2100: one merge for those is fine :)
[15:18] <Cimi> I want to change a property when I change another one, and viceversa
[15:19] <didrocks> thanks!
[15:19] <mterry> ah and no-password
[15:19] <Cimi> so I could use onPropertyChanged but I feel it might loop
[15:19] <pete-woods> mterry: I think that at the time I made the fake data, you only had like 3 users
[15:19] <sil2100> didrocks: ok, thanks!
[15:19] <pete-woods> clearly some more got added since
[15:20] <mterry> pete-woods, is there no design for "if we have no infographic data"?  Surely we are supposed to show something in that case
[15:20] <mzanetti> Cimi: don't really understand the question
[15:20] <mzanetti> Cimi: like this? http://paste.ubuntu.com/5729613/
[15:20] <mzanetti> Cimi: if you change "foo", "bar" and "baz" will update
[15:20] <didrocks> mzanetti: I think he wants 2 way data-bindings
[15:21] <mzanetti> ahhh
[15:21] <sil2100> didrocks: in the meantime, I'm publishing the unity stack as it seems all looks fine there
[15:21] <Cimi> mzanetti, I want to change currentIndex of a listview when I update a property
[15:21] <Cimi> mzanetti, but I want to change
[15:21] <didrocks> sil2100: sure!
[15:21] <Cimi> the property when the user changes currentIndex
[15:21] <mzanetti> Cimi: right... one sec
[15:21] <cyphermox> sil2100: good to start approving?
[15:22] <pete-woods> mterry: that would be a question for the design team, I guess
[15:22] <pete-woods> I'll pass it along
[15:23] <sil2100> cyphermox: you mean the cupstream2distro-config saucy-switch branch? If it looks fine to you you can approve it locally, I would wait a moment with the global one still as there are some discussions still going on
[15:23] <sil2100> cyphermox: also, I'd like fginther to take a look first if the CI is ready and well 'defined'
[15:23] <cyphermox> yeah
[15:24] <mzanetti> Cimi: you should be able to use a regular binding one way (e.g.  "currentIndex: foobar")
[15:25] <mzanetti> Cimi: and do the other way round with a Binding { property: foobar; value: listView.currentIndex }
[15:25] <mzanetti> Cimi: it _should_ work. Altough it might cause binding loop detection warnings
[15:26] <sil2100> fginther: ^ in case you missed it ;)
[15:26] <mzanetti> Cimi: instead of the Binding {} you can also use onCurrentIndexChanged. that should still work
[15:26] <fginther> sil2100, sorry, still looking, I was interrupted...
[15:26] <sil2100> fginther: no problem, there's no haste! As we're still blocked on the decision from the touch team
[15:28] <nic-doffay> Having issues flashing the tablet. Unable to push the files. Anyone run into similar issues?
[15:28] <nic-doffay> adb root is fine.
[15:29] <fginther> sil2100, looks good. Should I top approve?
[15:30] <nic-doffay> Saviq, ? ^
[15:30] <sil2100> fginther: for now a local approve is enough, thanks! Since I dont' want to change the config before sergiusens and rsalveti give a green light
[15:30] <sil2100> fginther: but that means all the CI saucy elements are correct and ready? :)
[15:30] <Saviq> nic-doffay, what kind of issues? does it say there's not enough space maybe?
[15:31] <Saviq> nic-doffay, did you (can you) try with phablet-flash -b to wipe all the data from it?
[15:31] <nic-doffay> Saviq, not yet.
[15:31] <fginther> sil2100, yes. ci parts are good
[15:31] <Saviq> nic-doffay, it might be that there's not enough space on the device
[15:31] <Saviq> nic-doffay, and make sure you use the ppa:phablet-team/tools
[15:31] <sergiusens> sil2100: can I see the MR?
[15:32] <sergiusens> sil2100: I can approve too as soon as it's good
[15:34] <sil2100> sergiusens: https://code.launchpad.net/~sil2100/cupstream2distro-config/switch_unity_and_deps_to_saucy/+merge/167043
[15:34] <sil2100> sergiusens: here it is basically
[15:38] <sergiusens> sil2100: can you add all the apps in there?
[15:38] <sergiusens> sil2100: ui-toolkit?
[15:39] <sergiusens> sil2100: we might need to just move everything
[15:39] <sil2100> sergiusens: ok, I can also migrate the rest as well
[15:39] <sil2100> Would make sense
[15:42] <tedg> sil2100, didrocks, fix in the pipeline for review.  Plus a couple others that should make autopilot happier as well.
[15:42] <didrocks> tedg: thanks!
[15:42] <sil2100> tedg: awesome!
[15:43] <sergiusens> sil2100: fginther https://blueprints.launchpad.net/touch-preview-images/+spec/foundations-1305-saucy-migration
[15:43] <sil2100> didrocks: ^ as mentioned, I'll also transition the touch apps to saucy
[15:43] <sergiusens> didrocks: ^^ that's the saucy bp
[15:43] <sil2100> sergiusens: thanks! Will change the task statusess
[15:44] <didrocks> sergiusens: sil2100: ah, thanks! :-)
[15:44] <didrocks> sil2100: hum, wait for moving stack using otto to saucy, we didn't plug it yet to saucy
[15:45] <nic-doffay> Saviq, getting this on ./run_on_device -s now... https://pastebin.canonical.com/91998/
[15:45] <nic-doffay> I've run network setup etc.
[15:45] <nic-doffay> with -i
[15:45] <sil2100> didrocks: for instance, hud?
[15:45] <rsalveti> olli_: sergiusens: sil2100: didrocks: so, we'll be doing saucy related work from today on, no more raring
[15:46] <rsalveti> feel free to push whatever you can to the archive, we'll also be working on getting our customizations during this week
[15:46] <rsalveti> so we can have a fully archive-based image asap
[15:46] <sil2100> rsalveti: that would be my understanding
[15:46] <didrocks> sil2100: yep, hud for now, but we can revert back just for tomorrow on utah
[15:46] <sil2100> rsalveti: thanks1
[15:47] <Saviq> nic-doffay, seems you have network issues, try restarting the device maybe and make sure it's connected
[15:47] <olli_> sil2100, does this mean we are good?
[15:47] <nic-doffay> Saviq, it's def connected!
[15:47] <Saviq> nic-doffay, try again, then, it sometimes happens
[15:47] <didrocks> rsalveti: we are blocked on the WI for pushing that to the archive, so we'll wait for this first
[15:47] <sergiusens> didrocks: sil2100: do we have a tag for the last raring build in the branches?
[15:48] <rsalveti> didrocks: sure, just saying we're good :-)
[15:48] <didrocks> sergiusens: not a tag, you have the changelog with the rev number
[15:48] <rsalveti> raring no more
[15:48] <didrocks> rsalveti: that's an excellent news!
[15:48] <olli_> didrocks, sil2100 what does this mean for scopes?
[15:48] <olli_> jono is asking for a reliable eta
[15:49] <didrocks> olli_: that's not related, we can push the scopes in saucy if the hud doesn't depend on anything we don't have in distro
[15:49] <didrocks> sil2100: mind checking that? ^
[15:49] <didrocks> sil2100: that the deps for unity (only the hud-service) has no build-dep on anything we don't have in saucy
[15:49] <didrocks> (like libhybris)
[15:50]  * sil2100 was busy regexing the config
[15:50] <sil2100> Let me scroll up
[15:51] <sil2100> didrocks, jono: give me a moment and I'll browse through the dependencies of unity and get back to you guys
[15:51] <jono> thanks sil2100
[15:52] <sil2100> Since indeed, if we have all that's needed in distro (besides hud and indicators-related things), we could push the current 100scopes to saucy
[15:52] <tedg> didrocks, We're good
[15:53] <didrocks> tedg: sweet! \o/ We'll let you know soon (tomorrow at most ;))
[15:53] <Cimi> mzanetti, but if I do onCurrentIndexChanged: property = ...
[15:53] <Cimi> and onPropertyChanged: currentIndex = ..
[15:53] <Cimi> it is a binding loop
[15:53] <mzanetti> Cimi: not if you do this:
[15:53] <thostr_> sil2100: didrocks: "could push" does it mean we'll push today?
[15:54] <mzanetti> onCurrentIndexChanged: if (property != targetVal) property = targetVal
[15:54] <mzanetti> Cimi: ^
[15:54] <didrocks> thostr_: tomorrow daily release rather
[15:54] <Cimi> mmm
[15:54] <thostr_> didrocks: for sure or is this our best guess?
[15:55] <nic-doffay> Saviq, sorted, I see it's just stubborn sometimes.
[15:55] <Saviq> nic-doffay, good
[15:55] <mzanetti> nic-doffay: found a bug in infographics
[15:56] <nic-doffay> mzanetti, shoot
[15:56] <mzanetti> nic-doffay: unlock the phone (swipe away the lockscreen) and then lock it again => the circles are gone
[15:56] <didrocks> thostr_: well, depends if the tests pass as usual
[15:56] <nic-doffay> mzanetti, must be a new one. pete-woods any ideas?
[15:56] <didrocks> thostr_: but it's been reviewed for NEW, we'll need help for other archive admins
[15:57] <didrocks> thostr_: and there is the question of the hud being publishable to saucy
[15:57] <didrocks> that all deps are available in saucy
[15:57] <Cimi> mzanetti,
[15:57] <Cimi>     onCurrentIndexChanged: if (currentDate != currentItem.monthStart) currentDate = currentItem.monthStart
[15:57] <Cimi>     onCurrentDateChanged: if (currentIndex != __diffMonths(minimumDate, currentDate)) currentIndex =  __diffMonths(minimumDate, currentDate)
[15:57] <Cimi> ?
[15:57] <didrocks> so checking for libhybris, ofono and so on
[15:57] <pete-woods> nic-doffay: I'd say that has never been tested before
[15:57] <didrocks> if this is good, we're good
[15:57] <mzanetti> nic-doffay: seems rendering.. the data is still there. if I double-click the center the circles appear again, but with an opacity animation
[15:57] <didrocks> that's why I asked sil2100 to check this
[15:57] <thostr_> didrocks: ok
[15:58] <pete-woods> nic-doffay: which is probably why it doesn't work
[15:58] <nic-doffay> mzanetti, ok. I'll get to the bottom of it as soon as this tablet is sorted.
[15:58] <mzanetti> Cimi: that should work I guess
[15:59] <didrocks> thostr_: sil2100: I see that hud is build-dep on armhf on libubuntu-platform-api1-dev
[15:59] <didrocks> so I guess that it depends on libhybris
[15:59] <didrocks> and so we need that one in distro first, which is pending from the phone fundation team (with good progress AFAIK)
[15:59] <didrocks> sil2100: thostr_: olli_: jono: ^
[16:01] <sil2100> didrocks: any ETA for that to be accepted? ;/
[16:01] <jono> man, what an interconnected set of teams and deps :-)
[16:01] <didrocks> sil2100: it's a question for rsalveti
[16:02] <didrocks> jono: the issue is that everything is bound together, meaning: autopilot transition, hud transition and a new set of deps
[16:02] <didrocks> jono: nothing with backward compatibility :)
[16:02] <didrocks> that's why I told at vUDS that we need to switch everything at the same time
[16:02] <rsalveti> didrocks: sil2100: I'm pushing libhybris later today
[16:02] <rsalveti> so it should be available tomorrow
[16:02] <didrocks> I hoped we can relax this constrain :)
[16:02] <sil2100> \o/
[16:02] <didrocks> rsalveti: ah excellent! so in NEW I guess?
[16:02] <didrocks> rsalveti: or did you bribe an archive admin already?
[16:03] <sil2100> It's a really big switch, so there's a lot of dependencies ;)
[16:03] <sil2100> ;p
[16:03] <rsalveti> didrocks: I'll ping the admins :-)
[16:04] <didrocks> rsalveti: ok, I'm afraid it's not in in time for dailies
[16:04] <didrocks> sil2100: what about switching tomorrow morning, after the current daily
[16:04] <rsalveti> yeah, that would be better I guess
[16:04] <didrocks> we'll be sure that libhybris is in
[16:04] <didrocks> rebuild everything
[16:04] <didrocks> and push whatever we can
[16:04] <sil2100> didrocks: if that's fine with jono and thostr_, it's fine with me - I'll prepare all branches for the switch
[16:04] <didrocks> (all the stuff that are not build-dep on ofono)
[16:04] <didrocks> rsalveti: do you remember exactly what's dep on ofono? ^
[16:04] <sil2100> Since we also need to get the unity build-dep-change in before that
[16:05] <didrocks> yep
[16:05] <sil2100> I can't merge it in now because it would break all merges ;p
[16:05] <rsalveti> didrocks: there's no extra dep for ofono, it talks with android via socket
[16:05] <jono> sil2100, I am not suggesting this needs to urgently go in, my issue today was around setting accurate expectations in the community
[16:05] <rsalveti> and we'll be cleaning that up during the following weeks, so no need to worry much now
[16:06] <jono> so if this takes a week to go in, so be it, I just need an accurate ETA on when it will land
[16:06] <didrocks> rsalveti: I mean, what component are dependings on the ofono package I listed on the spec?
[16:06] <rsalveti> the critical path is libhybris and libplatform-api
[16:06] <didrocks> rsalveti: just to ensure they are not part of those stacks :)
[16:06] <rsalveti> right, they can use the one available in the archive
[16:06] <rsalveti> there's no specifics for our ofono
[16:06] <didrocks> hum, let me check the package list
[16:06] <tedg> didrocks, as far as I'm concerned we can drop that for now.
[16:07] <didrocks> tedg: it's part of the hud stack?
[16:07] <didrocks> just interested in the dep :)
[16:07] <rsalveti> didrocks: we have packages depending on ofono, but they can pull the one from the archive
[16:07] <katie> mzanetti, hello
[16:07] <tedg> The platform API doesn't actually *do* platform abstraction yet.  So it's not that useful.
[16:07] <rsalveti> but it might need indeed the telepathy ofono stuff
[16:07] <mzanetti> hi katie
[16:07] <rsalveti> let me check
[16:07] <tedg> didrocks, We have a conditional build for it.
[16:07] <didrocks> rsalveti: yeah, there were some ofono package, telepathy-* and some other…
[16:07] <didrocks> tedg: ah, so if not there, ignored?
[16:08] <katie> mzanetti, I can't seem to get your unlocking branch to work
[16:08] <tedg> didrocks, When cyphermox was getting phone builds up, he added it.
[16:08] <rsalveti> right, I'll check the telepathy ones later today to see what are the issues there
[16:08] <tedg> didrocks, I think we have an explicit flag, but it's all in the /debian/* directory.
[16:08] <didrocks> rsalveti: ok, mind dropping an email?
[16:08] <mzanetti> katie: ok... lets go to a less flooded channel
[16:08] <didrocks> sil2100: maybe that to check and an additional flag to add ^
[16:08] <rsalveti> didrocks: sure
[16:09] <didrocks> thanks :)
[16:09] <cyphermox> didrocks: tedg: which?
[16:09] <tedg> cyphermox, platform-api
[16:09] <cyphermox> ok
[16:09] <cyphermox> right
[16:09] <cyphermox> for hud
[16:15] <sil2100> jono: ok, thanks, I did not have any accurate ETA as well, but I was expecting to do most of the work today (and hoping for a final resolve around today/tomorrow)
[16:15] <didrocks> sil2100: rather tomorrow, as we need libhybris in the distro and maybe telepathy-ofono and some others
[16:15] <didrocks> sil2100: read what's above ^ :)
[16:16] <didrocks> jono:  ^
[16:16] <sil2100> didrocks: yes yes, reading that up, that's a lot of people to follow ;)
[16:18] <sil2100> didrocks: ah, and I was talking about my expectations in the morning if anything right now ;)
[16:18] <sil2100> Things that I have been 'expecting' when starting my day
[16:18] <sil2100> ;p
[16:22]  * olli is lost... sil2100, didrocks.. iow: we will start seeing scopes (and it's dependencies/prereqs) being pushed tomorrow morning
[16:23] <didrocks> olli: *IF* libhybris and ofono deps are in distro/resolved by tomorrow, (and tests continue to pass), 100scopes will be in saucy
[16:28] <cyphermox> ofono is already in distro...
[16:29] <didrocks> cyphermox: telepath-ofono is?
[16:29] <cyphermox> yes, that too
[16:29] <cyphermox> afaik anyway
[16:29] <sil2100> cyphermox: I checked for telepath-ofono like 0.5h ago ang I didn't see it
[16:30] <cyphermox> it may be out of date
[16:30] <cyphermox> telepathy-ofono?
[16:30] <didrocks> cyphermox: not out of date, it was never in distro
[16:30] <didrocks> cyphermox: see the specs we discussed during UDS
[16:30] <cyphermox> hmm
[16:31] <cyphermox> I must be confusing with another package that did this
[16:31] <cyphermox> because I swear there was a telepathy-ofono before :)
[16:31] <didrocks> I made the list in a spec of some ofono package not in distro
[16:31] <cyphermox> anyway
[16:31] <didrocks> didn't seem to have been removed: https://launchpad.net/ubuntu/+source/telepathy-ofono
[16:31] <cyphermox> should involve awe so that we know it's ready..
[16:31] <cyphermox> yeah
[16:32] <cyphermox> it must be a different name
[16:32] <cyphermox> because there definitely used to be a telepathy plugin for ofono
[16:33] <rsalveti> cyphermox: it's not the old telepathy-ofono
[16:33] <rsalveti> it's a new one
[16:33] <rsalveti> that depends on telepathy-qt5
[16:33] <cyphermox> no I realize that
[16:33] <cyphermox> anyway, that should get landed asap...
[16:34] <rsalveti> yup
[16:36] <rsalveti> I'll go over the ofono dependencies as soon I'm done with hybris
[16:36] <didrocks> thanks a bunch rsalveti :)
[16:38] <mzanetti> Saviq: that ninja stuff seems to cause issues :/
[16:41] <Saviq> mzanetti, you mean that you need to build -c?
[16:41] <mzanetti> Saviq: huh?
[16:41] <Saviq> mzanetti, I'm not sure that's ninja's fault, but if you convince me that's the case we'll get rid of it
[16:42] <Saviq> mzanetti, something else, then?
[16:42] <mzanetti> Saviq: I mean that: a) on a fresh device without existing builddir it takes like ages to build
[16:42] <Saviq> mzanetti, same with make, I'd say
[16:42] <tedg> mhr3, Thoughts here?  https://code.launchpad.net/~ted/hud/dee-sync/+merge/166819/comments/369844
[16:43] <tedg> mhr3, Trying to clean up HUD loose ends :-)
[16:43] <mzanetti> Saviq: nope... make was way faster (seems like we were using all cores with make but are using only one with ninja)
[16:43] <mzanetti> Saviq: second is that it does not always reliably detect what needs to be rebuilt
[16:43] <mhr3> tedg, i clicked refresh on that tab like 30seconds before you pinged :)
[16:44]  * tedg is happy the telepathy is working
[16:44] <Saviq> mzanetti, indeed, build:50 should have -j$NUM_JOBS
[16:47] <mhr3> tedg, commented
[16:48] <tedg> mhr3, Sure, but the other patch protects from uninitialized models.
[16:48] <tedg> mhr3, So this one just means that we don't init with no data, and then get a refresh.  Instead, we wake up once to a fully functional model.
[16:49] <mhr3> tedg, it can't give you complete protection, it's in a different process
[16:49] <tedg> mhr3, Not arguing here for protection.  I understand it doesn't do that.  I'm just saying it's a better interaction for the client process.
[16:50] <tedg> mhr3, The protection stuff is in another branch that already landed.
[16:50] <tedg> mhr3, https://code.launchpad.net/~ted/hud/dee-service-sync/+merge/166869
[16:51] <mhr3> tedg, one problem is that the client will get a non-empty model then, without it it can just connect to row signals
[16:51] <mhr3> no need to iterate over the model in the begginging
[16:51] <mhr3> beginning*
[16:51] <Saviq> mzanetti, if you can confirm ninja is giving us issues, I'm good with dropping it by default
[16:52]  * tedg recommends pirate
[16:52] <mzanetti> Saviq: well... right now I have the second time that I manually need to wipe the builddir on the device to make it build stuff again
[16:52] <tedg> mhr3, Won't it have to wait until it gets the schema, or just set up handlers and dee takes care of that?
[16:52] <Saviq> mzanetti, yeah, that I've had, too (build -c, effectively)
[16:53] <mhr3> tedg, so my point is just that the current behavior is perfectly valid from dee pov
[16:53] <Saviq> mzanetti, but we'd need to see that make wouldn't have the same issue
[16:53] <mzanetti> true
[16:53] <mhr3> tedg, that you shouldn't do operations on the model while it isn't synced
[16:53] <Saviq> mzanetti, I'll try and reproduce tomorrow (it seems building trunk and then your launcher branch showed that)
[16:54] <mhr3> tedg, to make it super safe, you'd set the schema on the client side too
[16:54] <mhr3> right after you instantiate the model
[16:54] <tedg> mhr3, Hmm, didn't realize I could do that...
[16:54] <mhr3> and before it's synced
[16:54] <tedg> mhr3, Should I?
[16:54] <mhr3> you can
[16:54] <mhr3> it you know it
[16:54] <tedg> I didn't ask that.  ;-)
[16:54] <mhr3> if*
[16:54] <mhr3> if it never changes, do it
[16:55] <tedg> K, it doesn't.  Will do.
[16:55] <tedg> It only changes with package versions, which dpkg will take care of for us.
[16:57] <tedg> cyphermox, This is mostly packaging, can you look at it?  https://code.launchpad.net/~ted/hud/disable-unused-tests/+merge/167077
[16:58] <cyphermox> sure
[16:58] <mzanetti> mterry: can you help me for a minute?
[16:59] <cyphermox> tedg: awesome.
[16:59] <cyphermox> tedg: is it normal you remove some libappindicator / indicator-* dependencies?
[17:00] <tedg> cyphermox, Normal?  We were only using them in that test.
[17:00] <cyphermox> great
[17:00] <tedg> cyphermox, Otherwise it's all dbus
[17:00] <cyphermox> approved.
[17:00] <tedg> This distangles the two much better.
[17:00]  * cyphermox runs out to get lunch
[17:00] <cyphermox> yup
[17:00] <mterry> mzanetti, sure
[17:00] <cyphermox> it's a really good change
[17:00] <cyphermox> I'll be back in an hour or so
[17:00] <tedg> Have fun!
[17:01] <nic-doffay> mzanetti, I should have a patch ready shortly
[17:01] <tedg> untangles... bother.  Couldn't figure out what was wrong there :-)
[17:03] <didrocks> thomi: veebers: once you are back, first, good morning :) second! there is a mysterious None test that is run in autopilot test suite. (maybe autopilot-gtk?) it seems to run some tests and save them in None.ogv. But recordmydesktop is not exited
[17:03] <didrocks> thomi: veebers: http://10.97.0.1:8080/job/autopilot-raring-daily_release/label=autopilot-nvidia/71/consoleFull search for "None.ogv"
[17:25] <didrocks> thomi: veebers: please look at this run as well: http://10.97.0.1:8080/job/autopilot-raring-daily_release/label=autopilot-nvidia/73/artifact/results/autopilot/autopilot.log. Only 3 failures are listed despite the bunch of exceptions we are getting and a lot of ogv. Seems the xml generation doesn't match
[17:25] <didrocks> thomi: veebers: if you can give a look at tell me what you have found, that would be awesome :)
[19:36] <mzanetti> dandrader: thanks for the review. can you tell me why the tests fail to link against libunity-core?
[19:38] <dandrader> mzanetti, http://paste.ubuntu.com/5730429/
[19:39] <dandrader> mzanetti, maybe there's something wrong/outdated with my setup, but I don't get this with lp:unity/phablet
[19:39] <mzanetti> dandrader: oh.. thats a different one than I get
[19:39] <mzanetti> dandrader: but I don't understand why :/
[19:40] <mzanetti> dandrader: here it looks like this: http://paste.ubuntu.com/5730436/
[19:40] <mzanetti> dandrader: on jenkins it passes
[19:43] <dandrader> mzanetti, did you rebuilt from scratch your ../unity_build?
[19:43] <dandrader> might be worth trying it
[19:43] <dandrader> and then ./build --clean
[19:44]  * dandrader tries it out
[19:45] <mzanetti> dandrader: I just don't get why the other tests importing Unity would pass then
[19:45] <dandrader> mzanetti, did you update CMakeLists.txt?
[19:45] <dandrader> mzanetti,  I mean, does Launcher test need a new import path there?
[19:46] <mzanetti> dandrader: yes, but its there
[19:51] <dandrader> mzanetti, hmm, still the same error
[19:51] <mzanetti> dandrader: yeah... same here
[19:53] <mzanetti> dandrader: I don't get it... its the same libunity that all the others import too...
[19:54] <dandrader> mzanetti, me neither
[19:55] <mzanetti> dandrader: replied to the review
[20:18] <kgunn> mterry: ping
[20:19] <mterry> kgunn, hi