[07:17] <didrocks> hey mmrazik!
[07:17] <didrocks> mmrazik: FYI https://code.launchpad.net/~robru/webbrowser-app/packaging/+merge/153650
[07:17] <didrocks> I think you need to configure CI for it
[07:20] <mmrazik> didrocks: its there.  for some reason the triggering was stuck. I'm using some locking mechanism and there was a stuck process holding the lock (i.e. running but stack)
[07:20] <didrocks> ok :)
[07:20] <mmrazik> this happened 2nd time in the last several months :-/
[07:20] <didrocks> mmrazik: the CI does use some kind of ppa?
[07:20] <mmrazik> didrocks: oh... like a local repo?
[07:21] <didrocks> local repo or ppa
[07:21] <didrocks> I would have except that some are failing.
[07:21] <mmrazik> didrocks:  not really... maybe stuff like qt5-propper
[07:21] <didrocks> ok
[07:23] <nonuby> how do I flip through an apps open windows like alt+tab but app specific (i.e. if i have 5 terminal windows open)
[07:24] <mmrazik> didrocks: btw. the debian/rules is indeed broken in that merge proposal (AFAICS)
[07:24] <didrocks> mmrazik: oh? I missed that
[07:25] <didrocks> ah tab/spaces i guess
[09:43] <mzanetti> Saviq: just readin your mail... what you mean with "But the notion of focus is limited to text entry fields." ?
[09:43] <Saviq> mzanetti, that in a touch-only interface there is no focusing, other than on a text entry field
[09:44] <mzanetti> Saviq: nope...
[09:44] <Saviq> mzanetti, with keyboard navigation you focus on items to navigate between them
[09:44] <mzanetti> Saviq: xbmcremote is fully navigatable with keyboard only. and there is one textfield in the whole app
[09:44] <Saviq> mzanetti, yeah
[09:44] <Saviq> mzanetti, of course
[09:45] <mzanetti> Saviq: there is always some focused element... touching with your finger just doesn't care about it
[09:45] <Saviq> mzanetti, but when you only use a touch interface, you wouldn't know, would you ;)
[09:45] <mzanetti> Saviq: infact, touching a mouse element puts the activeFocus to the next wrapping FocusScope
[09:46] <Saviq> mzanetti, yes, sure, but still, it doesn't affect a touch-only interface at all, does it
[09:46] <mzanetti> Saviq: no... but where do we have a touch-only interface?
[09:47] <mzanetti> ok... right now the shell probably is :D but that needs to change
[09:47] <Saviq> mzanetti, yup ;)
[09:48] <Saviq> mzanetti, anyway, I know - the examples could've been better
[09:48] <mzanetti> Saviq: I just didn't understand that part...
[09:48] <mzanetti> fully support everything else in that thread
[09:48] <Saviq> mzanetti, and if you guys prove me wrong (i.e. there won't be a use-case where we need to differentiate based on available input)
[09:49] <Saviq> I'll be happy as hell ;)
[09:49] <mzanetti> Saviq: well, I think there shouldn't. IMO its bad that notifications are click through on the desktop and not on the phone...
[09:49] <mzanetti> but thats another discussion again
[09:50] <Saviq> mzanetti, I agree
[09:50] <Saviq> mzanetti, but click-through on touch would be broken
[09:50] <mzanetti> Saviq: its also on the desktop :D
[09:50] <Saviq> mzanetti, that's disputable ;)
[09:50] <mzanetti> *hides*
[09:51] <Saviq> mzanetti, but I do agree we need to revisit stuff like that
[09:52] <mzanetti> Saviq: I guess what you meant is not that theres no "focus" on touch ui's but rather there's no "onMouseOver" on touch uis. that makes a difference
[09:53] <Saviq> mzanetti, no, I meant focus
[09:53] <Saviq> mzanetti, as the only things that you do focus are text entries
[09:53] <Saviq> even if behind the scenes focus travels with you
[09:54] <mzanetti> Saviq: not agreeing here... first, yes, it travels with you, which makes a difference implementation wise, and second, there are cases where you actually highlight it too - eg. copy/paste
[09:55] <Saviq> mzanetti, implementation wise, sure it makes a diff, but that's only when you plan to allow keyboard navigation
[09:55] <Saviq> if you don't care about keyboard nav, you don't need focus at all
[09:56] <mzanetti> thats true... but we do care about that I guess... anyways, we're going round in circles... I think we both have the same opinion on how to handle the whole situation... no need to dispute over wordings :)
[09:56] <Saviq> mzanetti, c/p you mean selecting text in a browser? I don't know if I treat that as focus... even with our browser you can select text for c/p without focusing it
[09:56] <Saviq> mzanetti, yeah ;)
[09:57] <Saviq> mzanetti, I did mean, overall, that we should _not_ differentiate if at all possible
[09:57] <Saviq> but if we _do_, then, if at all possible, not based on the abstract / arbitrary form factor variable
[09:57] <mzanetti> full ack
[10:14] <mzanetti> tsdgeos: hey ho!
[10:14] <mzanetti> tsdgeos: friendly reminder: https://code.launchpad.net/~mzanetti/autopilot/faqs/+merge/152864 :)
[10:14] <tsdgeos> ah sorry
[10:15] <mzanetti> np
[10:15] <tsdgeos> i thought that had my implicit ok
[10:15] <tsdgeos> i'll give you the expliciti one :D
[10:15] <mzanetti> tsdgeos: seems noone wants to top-approve as long as you have the Needs Fixing in there
[10:15] <mzanetti> :)
[10:17] <tsdgeos> mzanetti: fixed, are you finding someone else to top approve? or want me to do it too?
[10:18] <mzanetti> tsdgeos: its ok... probably thomi should top approve stuff that goes to python-autopilot
[10:18] <tsdgeos> oki
[10:31] <tsdgeos> Saviq: do you remember why we need the super friends ppa?
[10:31] <tsdgeos> Saviq: i don't have any package installed from it and stuff compiles/links just fine
[10:35] <Cimi> tsdgeos, why qmluitests is kept separate?
[10:35] <tsdgeos> Cimi: separate to what?
[10:35] <Cimi> tsdgeos, unittests
[10:36] <tsdgeos> Cimi: becasue it needs to open a window that needs gl and the builders don't have that thus make test would fail
[10:36] <Cimi> tsdgeos, ah I see
[10:38] <tsdgeos> Cimi: is https://code.launchpad.net/~unity-team/unity/phablet.crossfadeimage-tests/+merge/153221 ready for review? want me to have a look?
[10:39] <Cimi> tsdgeos, ready
[10:39] <Cimi> tsdgeos, I'm about to start testing dashbar botto swipe
[10:39] <tsdgeos> oki
[10:42] <Saviq> tsdgeos, we might only need it for quantal
[10:42] <Saviq> tsdgeos, the people lens uses libfriends
[10:44] <tsdgeos> Saviq: does it? i don't have libfriends here and it compiled fine :-S
[10:45] <tsdgeos> Saviq: ah, all goes thorough dee it seems
[10:45] <Saviq> tsdgeos, ok, it uses Dee directly
[10:45] <tsdgeos> so you don't need it on compile time
[10:46] <Saviq> tsdgeos, yeah
[10:46] <tsdgeos> so we probably need friends on runtime
[10:46] <tsdgeos> shall we add that to some of the apt-get install we do?
[10:46] <Saviq> tsdgeos, it's not a hard req
[10:47] <tsdgeos> oki
[10:47] <tsdgeos> Saviq: so https://code.launchpad.net/~aacid/unity/more_build_work/+merge/153743
[10:47] <Saviq> tsdgeos, we'll just have to describe it in the docs
[10:47] <Saviq> tsdgeos, and in that case drop the super-friends PPA
[10:48] <tsdgeos> right, let me drop it from that MR then
[10:48] <Saviq> yup
[10:48] <tsdgeos> quantal too, right?
[10:56] <Cimi> in the dashbar tests I need to have a model of the lenses, how do I create a fake one or use the existing?
[10:59] <tsdgeos> good question :D
[10:59] <tsdgeos> do you need to have fake ones to inject some values?
[10:59] <tsdgeos> or using the existing ones is ok?
[11:00] <Cimi> tsdgeos, it's ok
[11:00] <tsdgeos> Cimi: https://code.launchpad.net/~unity-team/unity/phablet.crossfadeimage-tests/+merge/153221 looks ok to me, any reason you did not put the "readonly" to running ?
[11:01] <Cimi> tsdgeos, that part was added by mzanetti
[11:01] <Cimi> tsdgeos, I am not sure we need it at all!!
[11:01] <Cimi> mzanetti, why did you add running property?
[11:02] <tsdgeos> for the waitForAnimation part i gather
[11:02] <mzanetti> tsdgeos: Cimi: nope. I forgot... should be readonly
[11:02] <tsdgeos> mzanetti: can you update it and then i'll approve the MR
[11:02] <Cimi> mzanetti, but why do we have it in the first place I meant?
[11:02] <mzanetti> sure
[11:03] <mzanetti> Cimi: to not have to rely on wait() to know when the animation is done
[11:03] <Cimi> mzanetti, but it's not needed in unity
[11:03] <Cimi> mzanetti, just for tests...
[11:03] <mzanetti> Cimi: besides, it could be useful for implementations too when you want to make sure to not set a new image before the previous animation is completed
[11:04] <Cimi> mmm ok
[11:04] <mzanetti> Cimi: and its perfectly valid to add properties that ease up testing
[11:04] <mzanetti> Cimi: as long as they don't kill memory or cpu
[11:04] <Cimi> mzanetti, they make code more complex
[11:05] <mzanetti> Cimi: I don't agree that adding one property exposing some state of a component makes code more complex...
[11:05] <Cimi> mzanetti, one property is nothing
[11:05] <Cimi> mzanetti, but one, two or other changes for each file
[11:05] <Cimi> will increase complexity
[11:05] <mzanetti> Cimi: sure... you shouldn't add 50 lines of javascript
[11:06] <mzanetti> but look at the tests... I think yours - with the wait for the animation - were way more complex then my version
[11:06] <Cimi> mzanetti, anyway, this property might also be useful when using it, so it's good to have it
[11:06] <mzanetti> so this change actually simplifies the code - as tests are code too
[11:08] <Cimi> mzanetti, I used wait to avoid adding properties indeed
[11:09] <tsdgeos> hving a look at the diff it seems the property simplifies the test quite a bit
[11:09] <tsdgeos> mzanetti: just add the readonly and let's approve it
[11:12] <Cimi> tsdgeos, so how do I use the models?
[11:12] <tsdgeos> Cimi: not sure, which file are you testing exactly
[11:12] <tsdgeos> ?
[11:12] <Cimi> tsdgeos, dashbar
[11:13] <tsdgeos> Cimi: i think injecting a fake model here makes more sense tbh
[11:13] <Cimi> y
[11:13] <Cimi> ok
[11:16] <mzanetti> tsdgeos: done
[11:16] <Saviq> mzanetti, https://pastebin.canonical.com/86996/ can you reduce that diff, please?
[11:17] <Saviq> mzanetti, looks like you didn't refresh before changing :/
[11:17] <tsdgeos> mzanetti: reject https://code.launchpad.net/~mzanetti/unity/xvbf-test/+merge/151928 right?
[11:18] <mzanetti> Saviq: oops
[11:19] <Saviq> mzanetti, I tried to sanitize the work items a bit, with correct milestones and such
[11:19] <mzanetti> Saviq: is there a way to just revert my change again or do I manually undo the diff?
[11:21] <mzanetti> tsdgeos: yes... I ca delete it
[11:21] <tsdgeos> mzanetti: ok
[11:23] <tsdgeos> Cimi: mzanetti: what happened to https://code.launchpad.net/~mzanetti/unity/phablet-rename-notepad/+merge/151197 ?
[11:24] <mzanetti> tsdgeos: have to ask Ugo
[11:24] <mzanetti> I'll do
[11:29] <mzanetti> Saviq: I hope it should be ok again... please have a quick check
[11:29] <Saviq> mzanetti, cheers
[11:29] <mzanetti> tsdgeos: Ugo took care about the MP
[11:29] <tsdgeos> mzanetti: meaning?
[11:29] <tsdgeos> we should approve ours?
[11:30] <mzanetti> tsdgeos: what happened here is this:
[11:30] <mzanetti> notes-app got renamed. that requires changes in notes-app, the shell, and the image generation project - mostly at the same time
[11:31] <mzanetti> so when an app gets renamed I usually review all 3 MP's but don't top-approve any of them
[11:31] <mzanetti> and leave that to the developer of the app to make sure its in the correct order/timeframe
[11:31] <mzanetti> seems that approach has failed here
[11:32] <mzanetti> but its approved now
[11:32] <tsdgeos> ok :-)
[11:33] <tsdgeos> mzanetti: if you add the readonly to lp:~mzanetti/unity/preview-play-button-size and lp:~unity-team/unity/phablet.crossfadeimage-tests we'll get down to only 12 branchs in review :D
[11:34] <mzanetti> tsdgeos: I will...
[11:36] <tsdgeos> Cimi: i see you approved https://code.launchpad.net/~unity-team/unity/phablet-people-listview-carousel/+merge/153154 but not top approved, what is missing? you prefer someone else to have a look?
[11:39] <Cimi> tsdgeos, yes
[11:40] <tsdgeos> Cimi: ok, i can do another review, if you want, can you give me some edge cases i should check when running in the tablet, etc? so i can check those before reading the code and make sure it makes sense?
[11:41] <Cimi> tsdgeos, I don't have a tablet
[11:42] <Cimi> tsdgeos, I think the best idea would be playing with it and seeing if you can see regressions
[11:42] <tsdgeos> Cimi: ok
[11:42] <Cimi> tsdgeos, I tested and there aren't for me
[11:53] <luv> ok guys, i tried to work on ubuntu online accounts but when running dpkg-buildpackacge in signon-plugin-oauth2-0.15 in raring i get this: http://pastebin.com/MhjPaf3w
[11:55] <mmrazik> didrocks: we have some packaging changes (adding a subpackage with autopilot tests) for autopilot-qt
[11:55] <mmrazik> I assume that can't go into raring, right?
[11:56] <didrocks> mmrazik: autopilot-qt is still not in raring. I know that cyphermox was working on that some days ago
[11:56] <mmrazik> shall I branch lp:autopilot-qt into lp:autopilot-qt/raring and change the cupstream2distro-config stuff?
[11:56] <mmrazik> didrocks: oh... right
[11:56] <didrocks> mmrazik: so coordinate with him first please
[11:56] <mmrazik> ok
[11:56] <didrocks> mmrazik: maybe we can have everything in one shot :)
[12:02] <tsdgeos> gusch: do you have a tablet?
[12:03] <luv> ok, i will just file a bug against signon-plugion-oauth2 when i get back home
[12:03] <tsdgeos> oh not even tablet is needed
[12:04] <gusch> tsdgeos: yes
[12:05] <tsdgeos> gusch: https://code.launchpad.net/~unity-team/unity/phablet-people-listview-carousel/+merge/153154 needs fixing
[12:05] <tsdgeos> looks like there is some vertical spacing missing
[12:05] <tsdgeos> or something
[12:05] <tsdgeos> i get lots of overlaps where the carousel is used
[12:07] <mzanetti> tsdgeos: added the readonly on both... in the play-button one its a bit useless, but ok
[12:08] <gusch> tsdgeos: ah - I see the implicitHeight is not fixed - I'll push an update
[12:08] <tsdgeos> mzanetti: maybe qml can do some optimization, won't hurt
[12:08] <mzanetti> yeah sure... I've added it already
[12:10] <gusch> tsdgeos: pushed
[12:11] <gusch> tsdgeos: ups - no, there was an error
[12:15] <tsdgeos> gusch: can we get a test for the implicitheight? do you think it's hard?
[12:15] <gusch> tsdgeos: so far I have tests for the JS only - and no plans to extend that
[12:16] <gusch> tsdgeos: reason is, that I don't work on the shell anymore ...
[12:17] <mzanetti> Saviq: while testing PageHeader.qml we noticed this: https://pastebin.canonical.com/87001/
[12:17] <tsdgeos> gusch: :/
[12:17] <tsdgeos> gusch: ok, the MR still needs fixing though, on the tablet it looks very different from the current one (i.e. "too much" spacing)
[12:17] <mzanetti> Saviq: I think the PageHeader shouldn't directly access the greeter, instead that Connection should be outside the component
[12:18] <Saviq> mzanetti, yeah, bad shortcut
[12:18] <tsdgeos> gusch: i'll comment and let's see who fixes it since i guess you are not doing it because you are not a shell guy anymore
[12:18] <gusch> tsdgeos: I pushed the update for the implicit height now
[12:18] <mzanetti> ack... no problem... just wanted to know if you agree
[12:18] <tsdgeos> yep, seen
[12:18] <Saviq> mzanetti, this should probably be exposed on the shell
[12:19] <Saviq> mzanetti, accessing greeter directly _anywhere_ outside of Shell.qml is bad
[12:19] <mzanetti> yeah...
[12:31] <tsdgeos> woot, i can use the hud to add contants in the telephony app, someone has been wiring up stuff :-)
[12:46] <Saviq> tsdgeos, :)
[12:47] <luv> ohh, i see the patch for fast window switching got some praise even on the reg http://www.theregister.co.uk/2013/03/04/ubuntu_13_04_review/page2.html :-) thanks guys!
[13:06] <kgunn> Saviq: mzanetti hey guys, thanks for updating bp's, i am totally for using "13.04-month-5" monikers
[13:06] <mzanetti> np :)
[13:06] <kgunn> only wonder was....will it "screw up" 13.04 reporting metrics
[13:06] <kgunn> i asked warner but never got an answer
[13:06] <Saviq> kgunn, those are defined milestones
[13:07]  * mzanetti doesn't know too much about how those metrics are collected
[13:07] <kgunn> Saviq: right, understand...but that work isn't targeting 13.04 as a whole
[13:07] <kgunn> i'm still ok with it
[13:07] <zvuci> hi is there a Mir for ubuntu desktop which i can try? thnx
[13:07] <Saviq> kgunn, true, I was just adhering after the ML discussion
[13:08] <kgunn> Saviq:
[13:08] <kgunn> Saviq: what they get for not answering :)
[13:08] <kgunn> i'm ok with it
[13:08] <Saviq> kgunn, ;)
[13:08] <Saviq> zvuci, http://unity.ubuntu.com/mir/ should help
[13:08] <Saviq> zvuci, there's also #ubuntu-mir
[13:08] <kgunn> zvuci: hang on digging
[13:08] <zvuci> i was there
[13:09] <zvuci> i mean is it working
[13:09] <kgunn> zvuci: https://wiki.edubuntu.org/Mir/GetInvolved
[13:09] <zvuci> like normal desktop
[13:09] <zvuci> ok
[13:11] <kgunn> zvuci: if you're curious about what we're trying to do and when read this http://voices.canonical.com/user/201/
[13:14] <Cimi> Saviq, I'm creating a fake model for dashBar, the name should be reachable via lens.name, how do I fake this?
[13:14] <Saviq> mzanetti, a MockLens component with name as property?
[13:14] <Saviq> rm
[13:14] <Saviq> Cimi, ^
[13:15] <Saviq> mzanetti, sorry
[13:16] <Cimi> Saviq, where is MockLens?
[13:16] <Saviq> Cimi, there isn't
[13:16] <Cimi> ah ok
[13:16] <Saviq> Cimi, you need to create it
[13:16] <Cimi> ah ok
[13:16] <Cimi> I thought we were reusing something
[13:18] <zvuci> thnx kgunn i get the direction
[13:20] <Cimi> Saviq, I'm lil confused: I have ListElement { MockLens { id: lens; name: "music" } } ?
[13:21] <Cimi> I don't think, where am I failing?
[13:21] <Cimi> qt docs are not explaining this case
[13:21] <Saviq> Cimi, ListElement is flat
[13:21] <Saviq> Cimi, you can't use it like that
[13:21] <Cimi> ah ok
[13:22] <Cimi> Saviq, so what shall I use?
[13:23] <Saviq> Cimi, I don't think it's possible without C++
[13:25] <Saviq> mzanetti, ideas ^?
[13:25] <Saviq> mzanetti, Cimi needs a list model that will expose a role "lens" that will have properties
[13:25] <Cimi> ok
[13:26] <mzanetti> Saviq: Cimi: hmm, I think you have to do it like we did with the filterGrid
[13:26] <Saviq> hmm /me tries with a JS array
[13:26] <Cimi> dashBar has source: "graphics/lensIcons/%1.png".arg(lens.name)
[13:26] <Cimi> it's the only bit used of the model
[13:26] <davidcalle> didrocks, hey
[13:30] <Saviq> Cimi, we'll need the mock lens in other places, too
[13:32] <Cimi> mzanetti, we didn't test the filter grid afaics
[13:32] <mzanetti> Cimi: no... not with testing. when we set them in the lens
[13:33] <mzanetti> Cimi: the ListModel only holds the string names and the are actually loaded with a Loader where you can set other properties from the ListModel
[13:33] <Cimi> ah I see
[13:34] <Cimi> mzanetti, like Data ?
[13:34] <mzanetti> Cimi: Data?
[13:35] <mzanetti> Cimi: Like in DashHome.qml for example
[13:35] <mzanetti> Cimi: you write the MockLens.qml as string in there and add the properties you want
[13:36] <mzanetti> Cimi: later in the Loader you load the Mocklens.qml using the value from the model and in Loader.onCompleted: you set the rest of the properties in there
[13:36] <mzanetti> something like that
[13:38] <didrocks> hey davidcalle
[13:39]  * Cimi lunch
[13:39] <mzanetti> Saviq: what exactly is the InputfilterArea supposed to do?
[13:40] <Saviq> mzanetti, it says to the input system "don't pass those events to the apps"
[13:40] <mzanetti> Saviq: I wrote tests for it... doesn't seem to worl
[13:40] <mzanetti> work
[13:40] <mzanetti> Saviq: however, seeing it imports Ubuntu.Application it might not work on desktop only
[13:40] <Saviq> mzanetti, you'd have to test that in another application
[13:41] <Saviq> mzanetti, and no, it won't work on desktop
[13:41] <mzanetti> Saviq: thats bad
[13:41] <mzanetti> I don't understand why we have the Ubuntu.Application not available on the desktop
[13:41] <mzanetti> it already caused tons of workarounds
[13:41] <Saviq> mzanetti, because no one wrote it
[13:41] <Saviq> mzanetti, we'd have to wrap BAMF and stuff
[13:42] <Saviq> mzanetti, and anyway it needs to be rewritten on top of Mir
[13:42] <mzanetti> Saviq: no... we just do that component loading in there instead of 5 times in each app
[13:42] <mzanetti> Saviq: not saying all the functionality needs to be there
[13:42] <mzanetti> Saviq: but this component loading workaround in every app is just insane
[13:42] <Saviq> mzanetti, of course
[13:42] <davidcalle> didrocks, how do you want to handle scopes depending on non-default music players? Depends on the music player and "enhances" it?
[13:43] <didrocks> davidcalle: I would say "suggests" it
[13:43] <didrocks> davidcalle: as a depends would pull it by default
[13:43] <Saviq> mzanetti, not sure what to tell you, we need that API available on the desktop, yes
[13:43] <Saviq> in that form or another
[13:44] <davidcalle> didrocks, I wasn't thinking of having them by default because of the depends, but indeed, suggests solves it.
[13:44] <didrocks> davidcalle: let's have all scopes installed by default
[13:44] <mzanetti> Saviq: ok... anyways, I wrote some test but they fail of course - as the InputFilterArea does so too
[13:44] <didrocks> davidcalle: then, you have the functionnality if it's installed
[13:44] <Saviq> mzanetti, but it needs to lose functionality like the InputFilterArea, as that's only supposed to be available for the shell
[13:45] <didrocks> davidcalle: you just need to ensure it won't fail if not installed :)
[13:45] <Saviq> mzanetti, there
[13:45] <davidcalle> didrocks, tests should handle this case already. Will check.
[13:46] <Saviq> mzanetti, current Ubuntu.Application was thrown together on an as-needed basis
[13:46] <Saviq> with no real long-term goal behind it
[13:46] <didrocks> davidcalle: thanks
[13:47] <mzanetti> Saviq: yeah... I just remember back in december I wanted to move the loading inside the component because in all the apps we were introducing the workaround... someone said I shouldn't do that
[13:48] <Saviq> mzanetti, we  need to reevaluate what's available in that API and move stuff that's supposed to be available to applications out
[13:48] <Saviq> and preferably implement for X desktop
[13:49] <mzanetti> Saviq: yep. lets do that right after we are sufficient with testing
[13:49] <Saviq> mzanetti, can you add a work item to iteration 0, please?
[13:49] <mzanetti> Saviq: in the meantime, not sure what to do with this one... https://code.launchpad.net/~mzanetti/unity/phablet-test-inputfilterarea/+merge/153803 I think we could merge nevertheless as the qmluitests are not yet executed in jenkins anyways
[13:50] <mzanetti> Saviq: yes, I'll add the work item
[13:50] <Saviq> mzanetti, those tests wouldn't work anyway
[13:50] <mzanetti> no?
[13:50] <Saviq> mzanetti, the InputFilterArea doesn't do anything in the scope of the current app
[13:50] <Saviq> i.e. shell
[13:50] <Saviq> mzanetti, it only informs the input system
[13:50] <Saviq> to _not_ deliver those events to other apps
[13:50] <mzanetti> right...
[13:51] <Saviq> mzanetti, that's why I said you'd need a separate app to verify that it works
[13:51] <mzanetti> got it... ok. I'll make it happen. but in that case probably only once it works
[13:52] <Saviq> mzanetti, and testing that belongs to whatever provides that API anyway..
[13:52]  * Saviq biab
[14:24] <tsdgeos> mzanetti: can you review https://code.launchpad.net/~aacid/unity/phablet_hud_results_test/+merge/153816 or want me to find someone else?
[14:25] <mzanetti> tsdgeos: I can do
[14:25] <tsdgeos> great :-)
[14:29] <mzanetti> tsdgeos: the test would be nicer using the _data() function... (for next time. don't need to change it now)
[14:30] <tsdgeos> mzanetti: oki :-)
[14:31] <cyphermox> didrocks: mmrazik: autopilot-qt is supposed to be ready, just needs the bootstrap commit IIRC
[14:31] <didrocks> cyphermox: FFe is accepted?
[14:31] <mmrazik> cyphermox: ok. Do you think we can get the libautopilot-qt-autopilot subpackage as well?
[14:32] <cyphermox> is that a merge pending?
[14:32] <cyphermox> too many things at once, I haven't finished going through my checklist this morning
[14:39] <cyphermox> didrocks: yeah the ffe is approved provided we can get AA review
[14:40] <didrocks> \o/
[14:40] <didrocks> I'm pretty sure you will a AA review :p
[14:40] <didrocks> I'm pretty sure I'll do it ;)
[14:44] <cyphermox> yeah, not worried about that
[14:44] <tsdgeos> Saviq: did you have time for https://code.launchpad.net/~aacid/unity/more_build_work/+merge/153743 ?
[14:44] <Saviq> tsdgeos, at it now
[14:44] <tsdgeos> cool :-)
[14:45] <cyphermox> didrocks: https://code.launchpad.net/~mathieu-tl/autopilot-qt/bootstrap/+merge/153827
[14:45] <cyphermox> duh, my 3G modem doesn't work with the new ModemManager :'(
[14:45] <didrocks> cyphermox: looks good. However, i would add the bug # for the FFe while you are at it
[14:46] <cyphermox> oh shucks
[14:46] <cyphermox> of course
[14:47] <cyphermox> updated...
[14:47] <Saviq> tsdgeos, only thing that looks weird is: "quantal=true; if (raring) quantal=false" - maybe we should have "raring=false; if (raring) raring=true" instead? ;)
[14:47] <cyphermox> didrocks: I'd add it to the qa stack now as well
[14:48] <Saviq> tsdgeos, also, weren't you removing friends from there?
[14:48] <tsdgeos> Saviq: yeah, thought it was a bit weird too when i read it, now that we have a second opinion i'll change it
[14:48] <cyphermox> didrocks: where did you move the stack config to?
[14:48] <tsdgeos> Saviq: wasn't sure if i shall kill it from quantal too, i kill it too right?
[14:48] <didrocks> cyphermox: great! so in tomorrow daily?
[14:48] <cyphermox> yeah
[14:48] <didrocks> cyphermox: see my email a week ago, lp:cupstream2distro-config
[14:48] <cyphermox> I want it in tomorrow daily
[14:48] <Saviq> tsdgeos, yeah, it's a soft dep, we'll talk about it in some docs
[14:49] <tsdgeos> oki
[14:49] <tsdgeos> gusch: saw my new comment?
[14:49] <didrocks> cyphermox: mmrazik was talking about a new subpackage, maybe everything should land at the same time?
[14:49] <tsdgeos> mzanetti: and another small one https://code.launchpad.net/~aacid/unity/phablet_test_searchbar_set_query/+merge/153828
[14:50] <didrocks> cyphermox: and please, unblock the current stack in manual publication mode while you are at it :)
[14:51] <gusch> tsdgeos: ok - but what spaces?
[14:51] <tsdgeos> between the items of the carousel
[14:52] <tsdgeos> e.g. with your version if i go to videos
[14:52] <tsdgeos> there is spaces between them
[14:52] <tsdgeos> with the current one they overlap
[14:53] <gusch> tsdgeos: is it a one pixel space?
[14:53] <tsdgeos> gusch: no it's like 30
[14:54] <tsdgeos> i'll give you a screenshot
[14:54] <gusch> tsdgeos:yes, thx
[14:55] <tsdgeos> Saviq: pushed the friends removal and raring/quantal logic switching
[14:55] <Saviq> tsdgeos, cheers, can you update the
[14:55] <Saviq> nothing
[14:57] <Saviq> tsdgeos, actually, yeah - update debian/control with a "qt-components-ubuntu | qtdeclarative5-ubuntu-ui-toolkit-plugin" dep
[14:57] <Saviq> and we can redo the commit message to say "prepare for package renames"
[14:57] <tsdgeos> Saviq: is that the syntax?
[14:57] <tsdgeos>          qt-components-ubuntu (>= 0.1.5~) | qtdeclarative5-ubuntu-ui-toolkit-plugin,
[14:58] <Saviq> tsdgeos, yup, looks good
[14:58] <tsdgeos> pushed
[15:02] <gusch> tsdgeos: ah - I can see it - I guess it is a regression by the last change of Cimi - checking
[15:02] <cyphermox> didrocks: moo?
 cyphermox: and please, unblock the current stack in manual publication mode while you are at it :)
[15:02] <cyphermox> you mean QA?
[15:02] <tsdgeos> gusch: ok, i was uploading the screenshots now :D
[15:02] <didrocks> cyphermox: what we discussed in MP, yeah, QA ;)
[15:02] <didrocks> so done :)
[15:02] <cyphermox> alright, yeah
[15:03] <didrocks> thanks!
[15:03] <Saviq> tsdgeos, FYI grep -q
[15:04] <tsdgeos> Saviq: ?
[15:04] <Saviq> tsdgeos, "grep > /dev/null" == "grep -q"
[15:04] <tsdgeos> ah
[15:05] <kaleo> tvoss: can't make one on one today
[15:05] <tsdgeos> the man page confuses me
[15:05] <kaleo> tvoss: conflicting meetin
[15:05] <tsdgeos> "Exit immediately with zero status if any match is found, even if an error was detected."
[15:05] <tsdgeos> if there is an error do i want a  0?
[15:06] <tvoss> kaleo, ack, same here
[15:06] <Saviq> tsdgeos, if a match was found, yes
[15:06] <tsdgeos> probably
[15:06] <tsdgeos> ok, i'll change it
[15:06] <Cimi> mzanetti, can you help me with the mocklens :D
[15:06] <Saviq> tsdgeos, you can go one line, even
[15:06] <Saviq> tsdgeos, if grep -q raring /etc/lsb-release; then
[15:06] <mzanetti> Cimi: whats the issue?
[15:07] <tsdgeos> sure, you can do all sort of stuff on bash :D
[15:07] <Cimi> mzanetti, I don't understand at all
[15:07] <tsdgeos> i feel much more confortable with the other tbh
[15:07] <Saviq> tsdgeos, +1
[15:09] <tsdgeos> Saviq: new grep pushed
[15:09] <Saviq> tsdgeos, cheers, that will be all, I think
[15:09] <mzanetti> Cimi: more detailed please
[15:10] <Cimi> mzanetti, you game me directions, a
[15:10] <Cimi>  but I don't understand what I am supposed to do
[15:10] <Cimi> you said I should write mocklens.qml as strings and add properties
[15:10] <Cimi> what you meant write as string, and which properties?
[15:10] <mzanetti> camerin: oh ok
[15:11] <mzanetti> camerin: sorry... should have been Cimi
[15:11] <Cimi> why I need a loader, what I need to load
[15:11] <mzanetti> Cimi: ok.. give me a few minutes and I'll pastebin something together
[15:11] <Cimi> mzanetti, thanks
[15:14] <gusch> tsdgeos: now the spacing should be fixed again as well
[15:14] <mzanetti> Cimi: hmm... actually that seems to be even easier... what exactly do you want to do?
[15:16] <Cimi> mzanetti, dashBar needs
[15:16] <Cimi> s/needs/uses/
[15:16] <Cimi> "source: "graphics/lensIcons/%1.png".arg(lens.name)"
[15:17] <Cimi> so I guess I need a model with 5 items, music, people, home, apps, videos
[15:18] <mzanetti> Cimi: hmm... first I'd recommend to make "lens" a property of the component... we should never access variables from outside the component
[15:23] <mzanetti> Cimi: still around?
[15:23] <Cimi> mzanetti, yes
[15:24] <mzanetti> Cimi: do you agree with my previous statement?
[15:24] <Cimi> mzanetti, I didn't understand :)
[15:24] <mzanetti> hehe
[15:25] <mzanetti> Cimi: so... the Component DashBar.qml calls lens.something
[15:25] <mzanetti> Cimi: however, "lens" is not defined in the while DashBar.qml
[15:25] <Cimi> mzanetti, lens is in the model
[15:25] <Cimi> mzanetti, there is a listview, each item has index, lens
[15:26] <Saviq> mzanetti, lens is a role
[15:26] <mzanetti> I see... sorry then
[15:28] <mzanetti> Cimi: and whats the issue with just doing this:
[15:28] <mzanetti> model: Lenses {}
[15:29] <tsdgeos> gusch: ahh much bettar
[15:29] <gusch> tsdgeos: should 1:1 visual identical now again
[15:32] <Saviq> mzanetti, lenses are filtered
[15:33] <tsdgeos> https://code.launchpad.net/~mterry/unity/poeple-typo/+merge/153840 wops :S
[15:33] <mzanetti> Saviq: are they even if you don't wrap it in a SortFilterProxyModel?
[15:33] <Saviq> mzanetti, well, no, then they're not
[15:34] <Saviq> mzanetti, but TBH Lenses should be non-creatable
[15:34] <tsdgeos> if we have that typo ↑↑↑ how does it work?¿
[15:34] <mterry> tsdgeos, ::shrug::
[15:34] <mzanetti> Saviq: you mean setting it by a contextProperty?
[15:34] <Saviq> mzanetti, yes, and register as non-creatable
[15:35] <Cimi> gusch, thanks for the fix
[15:35] <Saviq> tsdgeos, mterry, there's two places that populate that
[15:35] <mzanetti> Saviq: yeah ok... but then that's just the same for the tests...
[15:35] <Cimi> gusch, fun enough, I fixed locally on friday, forgot to do bzr push :)
[15:35] <Saviq> tsdgeos, mterry, depending on whether the lens is loaded onCompleted or not
[15:35] <tsdgeos> Saviq: i see, gonna approve the change then
[15:35] <Saviq> tsdgeos, yeah, thanks
[15:35] <mzanetti> Cimi: try with using model: Lenses {} for now. and if we change them to be non-creatable we need to do the same as tsdgeos does with the HUD (mocking it all with C++)
[15:35] <gusch> Cimi: ah - hehe - it was too easy, so I got the fix too fast ;)
[15:40] <tsdgeos> gusch: Cimi: did we find any way to evaualte if the listview is really better?
[15:41] <tsdgeos> or we just assume it's better because it'll have less elements
[15:41] <Cimi> tsdgeos, people say it will consume less memory
[15:41] <Cimi> tsdgeos, although I don't like the workaround
[15:42] <Cimi> and I prefer repeater coding-wise
[15:42] <Cimi> but we don't have other choices if we want to use listview
[15:42] <gusch> tsdgeos: in my early test it saved a few MB (not a lot, and measurement were not very relieable)
[15:42] <Cimi> gusch, those tests are not valid because you were using cacheBuffer I believe
[15:42] <gusch> tsdgeos: but anyway - Repeater does scale well (think of having 100, or even more items)
[15:43] <Cimi> does not you meant
[15:43] <tsdgeos> yeap
[15:43] <Cimi> listview should scale better
[15:43] <tsdgeos> Cimi: which "workaround" you mean?
[15:43] <Cimi> tsdgeos, enlarging the area adding left and right negative margin
[15:44] <tsdgeos> ah, ok
[15:44] <tsdgeos> it's a bit weird yeah, but with qml sometimes you have to do that stuff, it's not that horrible i think
[15:44] <Saviq> +1
[15:45] <dandrader> mzanetti, I've replied to your comments and updated https://code.launchpad.net/~dandrader/unity/phablet_tst_FilterGrid/+merge/153599
[15:47] <mzanetti> dandrader: the wait(100) is a bit... lets say - not that good
[15:47] <mzanetti> :D
[15:47] <dandrader> let me check if it works without that magic line :)
[15:48] <dandrader> mzanetti, it does. will remove them now
[15:48] <dandrader> mzanetti, btw, you can do "make testFilterGrid"
[15:49] <mzanetti> dandrader: if you need to wait, use "tryCompare(filtergrid.height, filtergrid.totalContentHeight)" or something like this
[15:49] <mzanetti> dandrader: albert did that in the autopilot tests and it seems to work fine
[15:49] <mzanetti> dandrader: yeah, the cmake stuff you did is very nice
[15:49] <dandrader> mzanetti, yes, I did this tryCompare thing in my update as well
[15:50] <dandrader> mzanetti, pushed the wait(100) removal
[15:51] <mzanetti> dandrader: it doesn't compile any more... I think you need to merge trunk and upgrade your libdee-qt-3
[15:52] <Saviq> yeah
[15:52] <Saviq> s/libdee-qt5-3/libdee-qt5/
[15:52] <dandrader> mzanetti,  ok, will check that
[15:57] <dandrader> mzanetti, it should just work if you take lp:unity/phablet and do a "bzr merge lp:~dandrader/unity/phablet_tst_FilterGrid". As opposed to using lp:~dandrader/unity/phablet_tst_FilterGrid directly
[15:58] <mzanetti> dandrader: ok. I'll try
[16:00] <mterry> cyphermox, what's the story with indicator-head's red status?  Is it anything for unity-head to worry about?
[16:04] <Saviq> tsdgeos, hmm, why do I have to confirm apt-get like 6 times on initial ./build -s?
[16:05] <cyphermox> mterry: I think it's probably safe, there's a commit that can't land and that I'll need to revert, but otherwise the tests seem to be failing .. are the same as are often failing
[16:05] <tsdgeos> Saviq: because we don't have any -y in the apt-get install
[16:05] <cyphermox> mterry: perhaps sil can comment
[16:05] <tsdgeos> Saviq: can add
[16:05] <cyphermox> doh
[16:06] <Saviq> tsdgeos, maybe we could have a -y option for the script...
[16:06] <cyphermox> mterry: there hasn't been meaningful changes to indicators lately anyway
[16:06] <Saviq> tsdgeos, but adding -y everywhere sounds good enough
[16:06]  * tsdgeos adds
[16:08] <tsdgeos> Saviq: pushed
[16:08] <mzanetti> dandrader: I agree on the ResponsiveGridView comment. And with the last comment I'm just trying to push the mindset a bit... Often its not much more efforts to just add one testrow that checks if stuff triggers a crash when setting insane values for example
[16:08] <mzanetti> dandrader: approving
[16:10] <dandrader> mzanetti, ok, thanks
[16:14] <Cimi> mzanetti, Lenses is in unity plugin?
[16:14] <mzanetti> Saviq: do we want something like this? https://code.launchpad.net/~juhapekka-piiroinen/ubuntu-ui-toolkit/bazaar-plugin-precommit-hook-for-makecheck/+merge/153842
[16:14] <mzanetti> Cimi: yes
[16:15] <Saviq> mzanetti, looks good
[16:15] <Cimi> mzanetti, I think I need to load it somehow from the makefile
[16:15] <Saviq> mzanetti, we should also check whitespaces :)
[16:15] <mzanetti> Cimi: I fear you have to spend the effort to mock it out in C++. There is a Hud example already
[16:15] <Cimi> mmm ok
[16:15] <mzanetti> Saviq: where? at the end of lines?
[16:16] <Saviq> mzanetti, and that no \t is used
[16:16] <mzanetti> Saviq: hm... could run astyle on stuff yeah
[16:17] <Saviq> tsdgeos, did you see https://code.launchpad.net/~aacid/unity/more_build_work at the top?
[16:17] <Cimi> mzanetti, I'll go and study a bit this HudClient then
[16:17] <tsdgeos> Saviq: yeah, ignore that, it'll just work fine
[16:18] <tsdgeos> Saviq: happens because i push with "bzr push --stacked-on bzr+ssh://bazaar.launchpad.net/+branch/unity/phablet/" so that it does not take hours for each new branch
[16:18] <Saviq> tsdgeos, it doesn't work _just_ fine - bzr+http doesn't work, but yeah it works with bzr+ssh
[16:18] <Saviq> tsdgeos, good tip
[16:18] <Saviq> tsdgeos, wouldn't --stacked-on lp:unity/phablet work?
[16:19] <tsdgeos> Saviq: i remember it gave some error
[16:19] <tsdgeos> it was obviously the first thing i tried
[16:19] <Saviq> tsdgeos, mhm
[16:19] <tsdgeos> let me try again
[16:19] <mzanetti> I think I tried it too after albert gave me the above line
[16:19] <tsdgeos> bzr: ERROR: Server sent an unexpected error: ('error', 'UnsupportedProtocol', 'Unsupported protocol for url "lp:unity/phablet"')
[16:21] <tsdgeos> Saviq: yeah bzr+http doesn't work, i suffered that once when trying to checkout from a non logged in VM
[16:21] <tsdgeos> but tbh i can live with that if it means i push in 10 seconds instead of 10 minutes
[16:21] <Saviq> tsdgeos, guess how I found out ;)
[16:32] <didrocks> mmrazik: rev 82, adding unity-lens-photos please :)
[16:34] <mmrazik> didrocks: done
[16:34] <mmrazik> didrocks: btw. I'm still bootstrapping the local repo and using the PPA. At one point of time I'll need to remove the ppa and use the local repo only
[16:34] <mmrazik> unfortunately daily > bzr
[16:35] <didrocks> mmrazik: it was designed for that
[16:35] <didrocks> so that d > b
[16:35] <didrocks> is it a problem? things shouldn't build-dep on d*
[16:35] <mmrazik> didrocks: sure.... I mean unfortunately for the bootstrapping purposes. I can't keep the PPA _and_ the local repo and hope the PPA will be irreleveant sooner or later
[16:36] <didrocks> mmrazik: ah, yeah, as we don't succeed a full stack build
[16:36] <didrocks> mmrazik: you don't have the merge back
[16:36] <didrocks> so dont' get the bumped revision
[16:38] <Cimi> Saviq, I'm trying importing Unity from plugins dir
[16:38] <Cimi> but I get symbols errors
[16:38] <Saviq> Cimi, ./run
[16:38] <Cimi> QWARN  : qmltestrunner::UnknownTestFunc() file:///home/cimi/Development/phablet/phablet.dashBar_bottomswipe/tests/unittests/tst_DashBar.qml:19:1: plugin cannot be loaded for module ".home.cimi.Development.phablet.phablet.dashBar_bottomswipe.plugins.Unity": Cannot load library /home/cimi/Development/phablet/phablet.dashBar_bottomswipe/plugins/Unity/libUnity-qml.so: (/home/cimi/Development/phablet/phablet.dashBar_bottomswipe/plugins/Unity/libUnity-qml
[16:38] <Cimi> .so: undefined symbol: _ZTIN5unity4dash13PeoplePreviewE)
[16:38] <Cimi>      import "../../plugins/Unity"
[16:38] <Cimi> Saviq, ^
[16:38] <Saviq> Cimi, see what's set there
[16:38] <Cimi> ok
[16:39] <Saviq> Cimi, you need to use the libs from ../unity_build/build
[16:39] <Cimi> mzanetti, maybe we need to patch the unittests to import from that dir too?
[16:40] <mzanetti> Cimi: that's already happened... should be merged soon
[16:41] <mzanetti> Cimi: it'll come with this one https://code.launchpad.net/~dandrader/unity/phablet_tst_FilterGrid/+merge/153599
[16:41] <Cimi> mzanetti, studying, thx
[16:42] <Cimi> mzanetti, this is qmluitests though
[16:42] <Cimi> mzanetti, not unittests dir
[16:42] <mzanetti> Cimi: ah ok... yeah... can you create the same for those?
[16:43] <Cimi> sure
[16:43] <mzanetti> Cimi: it also has the advantage that "make check" gets more verbose
[16:44] <Cimi> ok
[16:47] <tsdgeos> mzanetti: since you did the greeter are you checking mterry's https://code.launchpad.net/~mterry/unity/phablet-greeter-lightdm/+merge/152288 ?
[16:50] <seb128> mterry, hum, autopilot/jenkins are not happy :-(
[16:50] <seb128> mterry, they loop on "2013-03-18 15:40:26,617 dx-autopilot-ati INFO: Caught [Errno 111] Connection refused, retrying sshcheck(180)"
[16:51] <seb128> mterry, same for intel and nvidia it seems
[16:54] <mibofra> hi :))
[16:54] <mterry> tsdgeos, mzanetti: While I would love a review of that, I'm currently fixing that branch's autopilot tests and adding more.  But the functionality itself won't change
[16:54] <mterry> fginther, ^ to seb128 's comments
[16:55] <mzanetti> tsdgeos: mterry: yes, can do
[16:56] <mzanetti> tsdgeos: https://code.launchpad.net/~mzanetti/unity/phablet-make-check-hook/+merge/153868
[16:57] <Cimi> mzanetti, what line 77 and 82 do?
[16:57] <Cimi> https://code.launchpad.net/~dandrader/unity/phablet_tst_FilterGrid/+merge/153599
[16:57] <Cimi> the if equals the elf?
[16:57] <Cimi> *else
[16:58] <mzanetti> Cimi: 77: if (argc == 1)
[16:58] <mzanetti> Cimi: 82 } else {
[16:58] <Cimi> ah ok
[16:58] <Cimi> mzanetti, it's a different syntax
[16:58] <mzanetti> Cimi: 88: }
[16:59] <mzanetti> Cimi: yes. cmake syntak is a bit weird sometimes... I also think adding the condition to else() and endif() is optional, but common practice
[16:59] <Cimi> mzanetti, never used cmake before, just automake
[16:59] <Cimi> was curious
[16:59] <tsdgeos> mzanetti: oh stealth stuff :D
[17:00] <mzanetti> Cimi:  if you understood automake I guess you are the one that will answer all build system questions now :D
[17:00]  * mzanetti bails out at latest in the 5th line of any autotools script
[17:00] <Cimi> mzanetti, understood is a hard word :D
[17:00] <MacSlow> mzanetti, Saviq: "hud-client-1", which the build-script for unity-phablet needs... is meant to come from where?
[17:00] <Cimi> mzanetti, I used it in my libraries and cried when needed
[17:00] <Saviq> MacSlow, it's build locally
[17:01] <tsdgeos> mzanetti: how does that work? do i need to do it in each of the dirs? or once i do make install once it'll work everywhere?
[17:01] <Saviq> MacSlow, installed in ../unity_build/build/
[17:01] <Saviq> MacSlow, remember to use ./build
[17:01] <tsdgeos> MacSlow: did you do ./build -s ?
[17:01] <Saviq> it sets up PKG_CONFIG_DIR
[17:01] <mzanetti> tsdgeos: see the desription
[17:01] <mzanetti> tsdgeos: you have to install manually...
[17:01] <tsdgeos> mzanetti: doesn't answer my question :D
[17:01] <tsdgeos> mzanetti: for each of the repos or just once?
[17:02] <tsdgeos> i guess for each of the repos
[17:02] <mzanetti> tsdgeos: hmm... I think just once for all
[17:02]  * mzanetti tests to push something else
[17:02] <MacSlow> Saviq, this is what I get... pastebin.ubuntu.com/5625708
[17:03] <mzanetti> tsdgeos: install once, use in all... which is probably not what we want...
[17:03] <tsdgeos> mzanetti: i don't want to run make qmluitests in qt-components repo
[17:03] <tsdgeos> MacSlow: did you do ./build -s ?
[17:03] <Saviq> MacSlow, go ./build_unity and see if hud is built/installed properly
[17:04] <mzanetti> tsdgeos: yes. I agree. I'll fix it
[17:04] <MacSlow> tsdgeos, bummer... thx
[17:04] <MacSlow> Saviq, ./build_unity is a script here
[17:04] <tsdgeos> MacSlow: are you in raring or quantal?
[17:04] <Saviq> MacSlow, yeah, run it
[17:05] <MacSlow> tsdgeos, this is on a fresh 12.10 to raring update
[17:05] <tsdgeos> MacSlow: then you may want to wait for https://code.launchpad.net/~aacid/unity/more_build_work/+merge/153743 to be merged or merge it manually
[17:05]  * tsdgeos eods
[17:06] <tsdgeos> afternoon/evening guys
[17:06] <MacSlow> tsdgeos, Saviq: doing the -s with ./build now
[17:06] <MacSlow> tsdgeos, good night
[17:06] <Saviq> MacSlow, what it does is run ./build_unity -s; ./build_unity
[17:06] <seb128> mterry, is there anyone else than fginther that knows about utah/jenkins/autopilot there?
[17:06] <MacSlow> Saviq, I'm waiting for ./build -s to finish first
[17:07] <seb128> mmrazik, ^?
[17:07] <MacSlow> Saviq, I guess after that issues should be gone
[17:07] <Saviq> MacSlow, yeah, that's what will happen
[17:07] <mterry> seb128, mmrazik should yeah
[17:07] <Saviq> MacSlow, and that, in turn, builds libunity, UnityCore, hud, people lens
[17:07] <mmrazik> seb128: whats up?
[17:07] <Saviq> and installs in ../unity_build/build/
[17:07] <MacSlow> Saviq, I'm still used to do everything manually :)
[17:07] <seb128> mmrazik, hey
[17:07] <Saviq> MacSlow, yeah we wasted too much time on doing things manually ;)
[17:07] <seb128> mmrazik, hum, autopilot/jenkins are not happy :-(
[17:07] <seb128> they loop on "2013-03-18 15:40:26,617 dx-autopilot-ati INFO: Caught [Errno 111] Connection refused, retrying sshcheck(180)"
[17:07] <MacSlow> Saviq, :)
[17:08] <seb128> mmrazik, e.g http://10.97.0.1:8080/job/ps-unity-autopilot-release-testing/label=autopilot-intel/118/console
[17:08] <MacSlow> Saviq, we had to suffer so our users (3rd-party devs) will have a sweet time hacking on the phone
[17:09] <mmrazik> seb128: that looks like an utah issue. Not sure If I'll be able to do something with that. Let me check on KVM if there is something obvious
[17:09] <seb128> mmrazik, who would?
[17:09] <mmrazik> seb128: nuclearbob, jcollado ...
[17:09] <mmrazik> gema for escalating (if you need to)
[17:09] <seb128> mmrazik, can you ping them?
[17:11] <MacSlow> Saviq, hm... "./build -s" tries to fetch libnux-3.0-dev ?
[17:11] <Saviq> MacSlow, yeah, merge the branch tsdgeos mentioned
[17:11] <Saviq> MacSlow, or run with -n
[17:11] <MacSlow> Saviq, ah ... that's that issue... I see... thx
[17:11] <Saviq> that will _not_ do local nux
[17:14] <MacSlow> got to run... bbl
[17:14] <Saviq> cheers
[18:36] <dandrader> how do I declare a QML property that can hold any js object?
[18:40] <dandrader> hmm, seems specifying the property type is optional
[18:53] <Saviq> dandrader, "property var name: value"
[18:54] <Saviq> dandrader, var can hold anything
[18:54] <dandrader> Saviq, thanks
[18:54] <Saviq> dandrader, http://qt-project.org/doc/qt-5.0/qtqml/qtqml-typesystem-basictypes.html
[18:59] <luv> is launchpad broken for you guys too? (cant log in ... Your page was stale.)
[19:01] <luv> umm
[19:01] <luv> maybe it just requires 3rd party cookies, grrr
[19:24] <om26er> Cimi, Hi!
[19:25] <om26er> Cimi, the volume slider handler looks distorted and have looked like that since 12.10 Could you look into that please :)
[19:26] <kgunn> om26er: Cimi is awfully busy on getting our UnityNext testing up to snuff
[19:27] <om26er> kgunn, ouch, alright I will get someone else look into that.
[19:27] <kgunn> om26er: :) no problem
[19:27] <kgunn> just that we really need to keep our focus
[19:27] <kgunn> or all these folks worrying about enuff time/people to do mir/unitynext
[19:28] <kgunn> will be proven true
[19:28] <kgunn> om26er: and no worries...we all got needs, i understand :)
[19:28] <om26er> kgunn, Indeed that's a more important issue for the time being
[19:35] <mterry> seb128, any progress with utah/
[19:35] <mterry> ?
[19:47] <seb128> mterry, we brough it to #qa, they think it's an installer issue, so we moved to #ubuntu-devel but they need to get debug logs for cjwatson
[19:47] <seb128> mterry, mmrazik was eod and I'm not sure anyone else was going to follow up on that, I will make sure to keep nagging tomorrow morning ;-)
[19:48] <mterry> seb128, thanks  :)
[19:48] <seb128> mterry, installer issue: apparently the username used for preseeding is not respected
[19:48] <seb128> mterry, yw
[21:12] <mzanetti> mterry: looks great!
[21:12] <mzanetti> mterry: https://code.launchpad.net/~mzanetti/unity/phablet-elide-user/+merge/153934 :D
[21:20] <mterry> mzanetti, I'm working on a followup branch so that we don't need to rebuild to use the mock liblightdm-qt5-2 library
[21:29] <cyphermox> mterry: hey
[21:29] <cyphermox> could you quickly review another small merge? https://code.launchpad.net/~mathieu-tl/libindicator/revert-indicator-ng/+merge/153938
[21:33] <mterry> cyphermox, done