[07:42] <mzanetti> didrocks: hey. is there a way to enable arm builds for my ppa?
[07:42] <didrocks> hey mzanetti, which ppa?
[07:42] <mzanetti> didrocks: https://launchpad.net/~mzanetti/+archive/testing
[07:42] <didrocks> mzanetti: this will ask to use a non virtual ppa, we try to diminish the need as possible
[07:42] <didrocks> mzanetti: personal ppa? I doubt about it
[07:43] <mzanetti> didrocks: so the only way to publish apps is to upload them to the official touch apps ppa?
[07:44] <didrocks> mzanetti: right now, but this week will be to use daily releases
[07:44] <didrocks> mzanetti: we need to transition to HUD 2 today, as discussed with sergio and ricardo
[07:44] <didrocks> hey sil2100! how are you?
[07:44] <didrocks> sil2100: btw, ready to push HUD 2 today? ^
[07:45] <didrocks> sil2100: do you mind coordinating with mzanetti on the medium tests so that we can transition to it? (not sure if we should disable temporarly to get things merged and so on)
[07:45] <mzanetti> didrocks: can't really follow... what has HUD to do with this?
[07:45] <didrocks> mzanetti: because we don't have daily release until apps are migrated to new HUD
[07:45] <didrocks> don't/can't
[07:45] <didrocks> as we have a newer HUD in the ppa
[07:45] <tsdgeos> didrocks: we are
[07:45] <tsdgeos> meaning
[07:45] <tsdgeos> i have branches waiting
[07:46] <tsdgeos> https://code.launchpad.net/~aacid/unity/new_hud_client/+merge/156603
[07:46] <didrocks> tsdgeos: yeah, I was waiting for the finale quantal touch image to be in, which should be done by done?
[07:46] <mzanetti> didrocks: I don't need daily releases... I just want to upload an app somewhere so it gets build for arm and I can install it on my phone again
[07:46] <didrocks> mzanetti: you can use the touch ppa for one manual upload, yeah
[07:46] <tsdgeos> and https://code.launchpad.net/~aacid/unity/new_hud_client_api/+merge/156616
[07:46] <didrocks> mzanetti: this will be reconverted for that purpose
[07:46] <tsdgeos> actually only the first is needed
[07:46] <tsdgeos> the for it to work
[07:47] <didrocks> tsdgeos: there is not only unity-next, but good to know it's ready ;)
[07:47] <tsdgeos> the second is to use the improvements
[07:48] <tsdgeos> didrocks: well i said "we" ;) for a certain definition of we ;)
[07:48] <didrocks> heh ;)
[07:48] <tsdgeos> didrocks: that's going where? raring? or s-something?
[07:48] <didrocks> thanks tsdgeos! will keep you posted once we have the base transition done
[07:48] <didrocks> tsdgeos: raring daily-build-next and next ppas
[07:48] <didrocks> tsdgeos: which will go into s then
[07:48] <tsdgeos> i see
[07:48] <tsdgeos> tx
[07:48] <didrocks> yw!
[07:49] <Saviq> mzanetti, can you please investigate ignoring /tests for coverage?
[07:49] <mzanetti> Saviq: ack
[07:50] <tsdgeos> *** Error in `/usr/bin/perl': corrupted double-linked list: 0x029f0fe8 ***
[07:50] <tsdgeos> :_S
[07:50] <Saviq> tsdgeos, panda?
[07:50] <tsdgeos> yeah
[07:50] <Saviq> tsdgeos, yeah, they sometimes go there and cry in the corner :/
[07:50] <Saviq> hence the black eyes
[07:59] <Saviq> mzanetti, tsdgeos, there seem to be issues with publishing (not just delay) in the end
[08:00] <mzanetti> mmrazik: ^
[08:00] <mzanetti> mmrazik: known issue or new?
[08:00] <Saviq> the last published ones are from yesterday 2pm https://jenkins.qa.ubuntu.com/job/unity-phablet-ci/
[08:00] <mmrazik> mzanetti, Saviq: let me check. We had some issues in the past (several months ago)
[08:06] <dednick> mzanetti: ping
[08:08] <mmrazik> Saviq, mzanetti: its a different thing than in the past :-/ There are no errors. It looks like the publishing just takes ages
[08:08] <mmrazik> I might need Larry to figure out whats going on
[08:08] <mmrazik> it might be high load on jenkins.qa.ubunut.com or something like that and I have no access there
[08:08] <Saviq> mmrazik, thanks
[08:08] <Saviq> dednick, ping https://code.launchpad.net/~nick-dedekind/unity/phablet.run_on_device_gdb/+merge/159378 ?
[08:09] <dednick> Saviq: thanks. seen it. i'll take a look
[08:09] <Saviq> dednick, cheers, just going through the active MPs
[08:12] <dednick> mzanetti: when you were looking at the network indicator layout issue, did you say it WASNT working in the chewie-client, or it WAS?
[08:12] <mzanetti> dednick: it wasn't here on desktop
[08:12] <dednick> mzanetti: hm. odd. working on mine
[08:12] <mzanetti> dednick: however, I use my desktop at GRID_UNIT_PX=18. That might makes a difference
[08:13] <dednick> mzanetti: ah. is that just an env setting i can change to test?
[08:13] <mzanetti> dednick: yes
[08:13] <mzanetti> dednick: also, I think the fix I proposed (use height instead of implicitHeight) got merged.
[08:14] <mzanetti> so if you try with current trunk it might be fixed
[08:14] <dednick> mzanetti: that's the same px as the nexus phone right?
[08:14] <mzanetti> dednick: i think the same as Galaxy Nexus. The n10 uses 20 if I'm not mistaken
[08:16] <Saviq> dednick, also, there seems to be a regression with the indicators in trunk, when you swipe over an indicator quickly, the page is blank until you un-pin the indicator from the bottom
[08:17] <Saviq> dednick, and "MenuContent.qml:102: TypeError: Object ClockPage_QMLTYPE_265(0xc29478) has no method 'reset'"
[08:17] <Saviq> dednick, can you please look into that?
[08:17] <dednick> Saviq: sure
[08:17] <Saviq> dednick, it looks like when the indicators are unloaded, they don't come back as soon as they are loaded again
[08:19] <dednick> Saviq: the indicators are only supposed to be loaded when you press the indicator bar. Previously they were being loaded on startup because of a bug.
[08:19] <dednick> but maybe we want that...
[08:19] <Saviq> dednick, yeah, that's fine
[08:19] <Saviq> dednick, but they don't load at all
[08:19] <Saviq> dednick, well, they do, but are invisible
[08:19] <tsdgeos> didn't sergio said that images where now raring based?
[08:19] <tsdgeos> i just did phablet-flash and got a quantal one
[08:20] <Saviq> tsdgeos, yeah, I still had to use the --alternate-settings approach
[08:20] <dednick> Saviq: ok. i havent seen that. I've only seen that they pop up after a bit of a delay
[08:20] <dednick> Saviq: i'll take another look
[08:20] <tsdgeos> Saviq: doh :/
[08:20] <Saviq> tsdgeos, and it did download quantal-* anyway
[08:32] <Saviq> mzanetti, I'd say that's hanging... :/
[08:33] <Saviq> http://<IP_ADDRESS>:8080/job/generic-mediumtests-runner/1263/console
[08:33] <mzanetti> Saviq: hmm... not sure...
[08:33] <mzanetti> 23 minutes is indeed a bit long for autopilot tests...
[08:33] <Saviq> mzanetti, shouldn't there be more output?
[08:34] <mzanetti> Saviq: no
[08:34] <Saviq> mzanetti, ah k
[08:34] <mzanetti> Saviq: autopilot doesn't print anything if you tell it to log to an xml file
[08:34] <Saviq> mzanetti, sounds like room for improvement ;)
[08:35] <mzanetti> Saviq: actually... I've been asked to ask you to join a session about autopilot in Oakland
[08:35] <mzanetti> Saviq: feedback to developers of autopilot mainly. interested?
[08:35] <Saviq> mzanetti, can you invite me on the calendar?
[08:35] <Saviq> mzanetti, sure
[08:35] <mzanetti> Saviq: there's no schedule yet. but yes, I'll let you know as soon as I know anything
[08:35] <Saviq> mzanetti, cool, yeah, count me in
[08:54] <MCR> Hi :)
[08:54] <tsdgeos> mzanetti: we really need to fix that "QXcbConnection: XCB error: 148 (Unknown), sequence: 148, resource id: 0, major code: 140 (Unknown), minor code: 20" thing
[08:54] <tsdgeos> it's getting silly having to retrigger so many qmluitests jobs
[08:54] <MCR> mmrazik, could you please take a look @ the compiz 0.9.10 automerger as it stopped to work recently... ?
[08:56] <mmrazik> MCR: looking
[08:56] <tsdgeos> mzanetti: also seems ps-panda-5 doesn't have the new stuff that acceps Digia licenses, can you check?
[08:56] <MCR> thanks a lot
[08:56] <mmrazik> MCR: was it actually working before?
[08:56] <mzanetti> tsdgeos: yep
[08:56] <mmrazik> or maybe it was renamed?
[08:56] <MCR> mmrazik, yes
[08:56] <MCR> mmrazik, https://code.launchpad.net/~compiz-team/compiz/0.9.10/+activereviews
[08:57] <MCR> https://code.launchpad.net/~compiz-team/compiz/0.9.10
[08:57] <mmrazik> oh... 0.9.10 == lp:compiz
[08:57] <MCR> it worked until 04-18
[08:57] <MCR> yes
[08:57] <MCR> it is not for raring anymore unfortunately...
[08:58] <MCR> but we still need the merger, also CI and all the rest of the cool features ;)
[08:58] <mmrazik> MCR: was lp:compiz 0.9.9 until ~04-18?
[08:58] <MCR> no
[08:58] <mmrazik> mhm..
[08:58] <mzanetti> tsdgeos: panda-5 updated
[08:59] <mmrazik> MCR: I can fix it but I still don't understand why it worked before :-/
[08:59] <tsdgeos> mzanetti: cheers!
[08:59] <MCR> but compiz/raring was deleted and 0.9.9 became compiz/raring
[08:59] <MCR> I think
[08:59] <MCR> (I did not do this change)
[08:59] <mmrazik> didrocks: head/unity.cfg should have no target_branch for compiz, right (ATM it points to lp:compiz/0.9.9)?
[09:00] <MCR> some shuffling was going on... but we already worked on 0.9.10 for some time
[09:00] <mmrazik> didrocks:  which is the same as raring
[09:00] <didrocks> mmrazik: didn't I change that?
[09:00] <didrocks> mmrazik: let me recheck, I'm almost sure I changed it
[09:00] <MCR> hi didrocks :)
[09:00] <mmrazik> didrocks: its still in trunk
[09:00] <didrocks> hey MCR!
[09:00] <mmrazik> or let me pull..
[09:01] <mmrazik> nope. its in the trunk
[09:01] <didrocks> right, I'm puzzled
[09:01] <didrocks> I'm sure I fixed it though
[09:01]  * didrocks checks jenkins
[09:01] <MCR> thanks, didrocks
[09:01] <mmrazik> didrocks: its not in your r218
[09:02] <mmrazik> which is changing raring to 0.9.9
[09:02] <didrocks> mmrazik: argh, indeed
[09:02] <mmrazik> anyway... I still don't get it why 0.9.10 was landing before
[09:02] <mmrazik> didrocks: shall I just fix it?
[09:03] <didrocks> mmrazik: I'm pushing it
[09:03] <mmrazik> ok
[09:06] <tsdgeos> mzanetti: any chance we can fix the "libGL error: failed to load driver: swrast" on the thing that runs the qmluitests? maybe that way we get past the qxcbconnection stuff
[09:07] <MCR> didrocks, mmrazik: Does your cryptic conversation mean it's fixed ? ;)
[09:07] <mmrazik> MCR: I'm just waiting for the triggering job to finish
[09:07] <didrocks> MCR: lp:compiz is taken into account, yeah ;)
[09:07] <mmrazik> MCR: but it looks like the jobs are queued
[09:07] <mmrazik> just wanted to wait with the "yes, its fixed" message :)
[09:08] <MCR> cool - that was fast, thanks -> I shout out loud if the merger stays on weekend mode
[09:09] <mmrazik> MCR: yes please. Unfortunately these sort of errors are hard to find. I have a watchdog that looks for merge proposals that are approved but not merged for a long time. But that only works for branches we are "aware" of (i.e. they are configured to autoland).
[09:09] <mmrazik> in this particular case the error was that lp:compiz was not even configured to autoland
[09:10] <MCR> mmrazik, no problem @ all, if it gets fixed that fast... thanks a lot
[09:10] <mmrazik> (which was a typo)
[09:10] <dednick> Saviq: I've got to go out before our standup today and I may not be back by then. Shall i just add my work to the standup doc?
[09:10] <Saviq> dednick, please do
[09:10] <MCR> mmrazik, you are always super-responsive +1
[09:10] <mzanetti> tsdgeos: I'll try
[09:16] <dednick> mzanetti, Saviq: found the issue with indicators height. The BasicMenu type changed recently to a Ubuntu.Component.ListItem.Standard which has a height set. needed to heigh: undefined everything using implicitHeight
[09:17] <Saviq> dednick, ah!
[09:17] <mzanetti> nice
[09:17] <Saviq> dednick, good catch
[09:18] <Saviq> mzanetti, pushed lp:~saviq/+junk/interface-tests with a SignalSpy and _data()-driven where applicable
[09:18] <dednick> just making sure i didnt break anything and i'll put a MP throught
[09:18] <mzanetti> Saviq: ack. I'll check it out
[09:27] <MCR> duflu, hi. I would like to bring the ubuntu code-patches (for scale and expo for example) inline, otherwise the code is hard to maintain. Do you know the reason why they have been made Ubuntu-only ?
[09:29] <duflu> MCR: Because they did not meet Compiz standards, and more importantly upstream Compiz didn't like them :)
[09:30] <duflu> MCR: Hang on...  I upstreamed them already... !?
[09:31] <MCR> I like them and they do not need specific Ubuntu-only functions or depend on nux as far as I could tell...
[09:31] <MCR> duflu, I am not sure...
[09:32] <MCR> duflu, scale for example...
[09:32] <duflu> MCR: Looking at lp:compiz, they are not patches any more (?)
[09:32] <duflu> So what do you mean?
[09:33] <MCR> well, I compiled scale from lp:compiz and it does not have the close button and title overlapping...
[09:33] <MCR> I did not apply the patches yet, though...
[09:33] <MCR> so I am not 100% sure
[09:34] <MCR> duflu, do not worry about it -> I'll have to look into it in detail yet
[09:34] <MCR> just wanted to know which was the reason in the first place
[09:34] <duflu> MCR: Oh right, the Unity modifications. No. Those live in lp:unity AFAIK and upstream does not want them. Last time I asked around.
[09:35] <MCR> sure - they should live in lp:compiz ofc
[09:35] <duflu> Besides, you can close windows with scaleaddon. A proper upstream compiz solution would use or extend scaleaddon
[09:35] <didrocks> sil2100: still not around? ;)
[09:35] <duflu> MCR: No we don't want them in lp:compiz. They're ugly and Unity-look-specific :)
[09:35] <MCR> ;)
[09:36] <duflu> Umm, pretend I didn't say the first bit
[09:36] <duflu> MCR: Anything that looks like Unity should be in lp:unity. But feel free to add a generic-looking close/cross button
[09:36] <Saviq> dednick, I just reproduced the empty indicator on current release image, so it might not be a regression after all, or at least not a new one
[09:37] <MCR> duflu, it is not unity-specific in this case ;)
[09:37] <MCR> it will use whatever theme the user uses...
[09:37] <dednick> Saviq: does it happen when you first load the session?
[09:37] <MCR> for the titlebar in scale
[09:37] <Saviq> dednick, not really, it happens whenever
[09:37] <MCR> but scaleaddon would be the place to be, I agree...
[09:37] <Saviq> dednick, I think I see what the issue is
[09:38] <duflu> MCR: Hmm. Well I don't think that's the solution I would approve. But I don't approve things any more so you don't need my view
[09:38] <dednick> Saviq: hm. ok. I've seen it take quite a long time, but never not show at all. Is it a specific indicator, or anything?
[09:38] <Saviq> dednick, it happens when I release the touch before crossing the threshold that makes it show at all
[09:38] <MCR> duflu, I always respected your view ;)
[09:38] <dednick> Saviq: ah. ok
[09:38] <MCR> and still am
[09:38] <dednick> Saviq: possibly a state change issue
[09:39] <Saviq> dednick, yeah, simple way to reproduce: touch panel, drag minimally down until the grey bar comes down, release
[09:39] <dednick> Saviq: yeah. just got it
[09:39] <MCR> but it is hard to fix things in expo for example with this patch mess...
[09:40] <Saviq> dednick, cheers
[09:41] <duflu> MCR: I resolved the "patch mess" last year. What are you talking about?
[09:41] <MCR> duflu, maybe I am confusing 2 issues now -> scale and expo
[09:42] <MCR> I was just working on scale recently
[09:42] <MCR> so I just noticed the scale problem and thought it might be the patch issue, but did not look into it in detail
[09:43] <duflu> MCR: There are no major scale/expo patches any more. See: http://bazaar.launchpad.net/~compiz-team/compiz/0.9.10/files/head:/debian/patches/
[09:43] <MCR> \o/
[09:43] <duflu> I wonder how old your branch is :)
[09:43] <MCR> ;)
[09:44] <MCR> isn't 0.8 the right one ?
[09:51] <tsdgeos> dednick: why the file test_categories ?
[09:53] <dednick> tsdgeos: just a script to run the CategoryScene test.
[09:53] <dednick> although not really a test. just a debug scene
[09:53] <tsdgeos> do we really need that?
[09:53] <dednick> the Scene, or the script?
[09:53] <tsdgeos> ah
[09:53] <tsdgeos> so it's not "really a test"
[09:53] <tsdgeos> ?
[09:54] <dednick> tsdgeos: no. it's just to verify that the category results are working correctly
[09:54] <tsdgeos> can't we do that in a test?
[09:55] <nik90> I built unity-next according to the instructions provided on wiki.ubuntu.com just to try it out. After that I removed however I noticed that there are 2 additional lenses as seen in http://imgur.com/RS0RUm4. How do I remove them?
[09:55] <nik90> does anybody know the package name?
[09:55] <dednick> tsdgeos: i guess its in the dash tests or will be when it gets merged.
[09:55] <dednick> i'll remove it.
[09:56] <dednick> tsdgeos: it was just so i could debug when writing the unity pugin stuff.
[09:56] <tsdgeos> i see
[09:57] <tsdgeos> dednick: any particular reason for the change in Lenses::updateLenses ?
[10:00] <dednick> tsdgeos: not really. just though more sense to have a non-visible Music lens, than Home lens (even though it's just test data).
[10:00] <tsdgeos> oki
[10:07] <tsdgeos> dednick: the fact that there is no globalresults is on purpose?
[10:11] <dednick> tsdgeos: you mean different to the normal results?
[10:14] <tsdgeos> dednick: yep
[10:14] <tsdgeos> i mean the non fake lens.cpp does
[10:14] <tsdgeos>     m_categories->setResultModel(m_results);
[10:14] <tsdgeos>     m_categories->setGlobalResultModel(m_globalResults);
[10:14] <tsdgeos> you do
[10:14] <tsdgeos> + m_categories->setResultModel(m_results);
[10:14] <tsdgeos> + m_categories->setGlobalResultModel(m_results);
[10:16] <tsdgeos> it is true that we're not using globalResults anywhere i think
[10:16] <tsdgeos> so if that's the reason i'm ok
[10:16] <tsdgeos> just asking
[10:16] <dednick> tsdgeos: yeah. we didnt seem to be. so i didnt see a point until we do.
[10:17] <tsdgeos> ok
[10:18] <tsdgeos> dednick: what's the other branch that depends on this?
[10:18] <tsdgeos> launchpad tells me there are 2 but when clicking on the link gives me an empty page :-S
[10:18] <dednick> tsdgeos: i would have thought the home lens would use it. but it seems to use filter models with the normal results
[10:20] <dednick> tsdgeos: https://code.launchpad.net/~nick-dedekind/unity/phablet-tests-dashcontent/+merge/159459, https://code.launchpad.net/~nick-dedekind/unity/phablet-tests-dash/+merge/160032
[10:20] <tsdgeos> tx
[10:21] <dednick> tsdgeos: i think Cimi has got some as well
[10:22] <tsdgeos> ok
[10:22] <tsdgeos> approved, looks good
[10:23] <dednick> tsdgeos: ta
[10:27] <dednick> Saviq: https://code.launchpad.net/~nick-dedekind/unity/phablet.indicators.small-swipe/+merge/160321
[10:27] <dednick> mzanetti: https://code.launchpad.net/~nick-dedekind/indicators-client/menu-implicitHeight/+merge/160310
[10:28] <dednick> just letting you know they're there :)
[10:30] <Saviq> dednick, awesome, approved
[10:30] <mzanetti> dednick: I don't think explicitly setting height to undefined is what we should do
[10:31] <mzanetti> dednick: can't we fix the issue in its root instead of working around it in some upper layers?
[10:31] <mzanetti> I can't see how this would be better than the preivous version
[10:31] <dednick> mzanetti: yeah, i wasnt really sure about that.
[10:31] <dednick> mzanetti: but the issue is in Ubuntu.Components
[10:32] <mzanetti> dednick: then it'll bite us over and over again I guess unless we report a bug to the SDK guys
[10:32] <dednick> mzanetti: could maybe use implcitHeight there...
[10:32] <mzanetti> dednick: yeah. I think that would be way to go
[10:32] <Saviq> dednick, yeah, sounds like if Standard has a height: defined, it's a bug
[10:32] <Saviq> dednick, please pick it up with sdk guys
[10:34] <dednick> mzanetti, Saviq: ok. who's on the sdk team ? :)
[10:34] <mzanetti> dednick: bzoltan, timp, zsombi
[10:34] <sil2100> didrocks: eek
[10:34] <dednick> ta
[10:34] <sil2100> didrocks: took me longer than I thought, uugh
[10:35] <didrocks> the HUD 2.0 work?
[10:35] <sil2100> No, I jumped out to the bank to take out some money for Oakland ;)
[10:35] <didrocks> ah ok
[10:35] <sil2100> Now, doing HUD!
[10:35] <didrocks> great ;)
[10:38] <dednick> mzanetti: do you know why we use implicitHeight anyway? what is the benifit?
[10:39] <mzanetti> dednick: in this particular case?
[10:39] <dednick> mzanetti: ya.
[10:40] <mzanetti> dednick: no... I would be fine with real height in here as its the end user representation... still the SDK using height instead of implicitHeight feels like a bug.
[10:40] <dednick> mzanetti: ok.
[10:41] <mzanetti> Saviq: wanted to keep the implicitHeight here which - regarding chewie's overengineered architecture - could make sense...
[10:41] <mzanetti> dednick: ^
[10:41] <Saviq> dednick, height/width should never be defined on top-level component in a QML file
[10:42] <Saviq> dednick, implicitHeight/implicitWidth is there exactly for that purpose - "if height is not defined otherwise, here's my default height"
[10:42] <dednick> Saviq: ok. thanks.
[10:42] <mzanetti> dednick: basically chewie doesn't paint a full UI itself, but rather has a set of components that are compiled together by the middleware as needed. So everything can be seen as components in there
[10:42] <Saviq> dednick, and if the component is used wrong, it's the component user's fault, not the component's
[10:57] <dednick> Saviq, mzanetti: looks like renato made changes to the ListItem to fix that issue. we're just not using an up-to-date version of ubuntu-ui-toolkit
[10:57] <Saviq> dednick, ah, so the fix wasn't released yet?
[10:58] <dednick> it's in trunk, but not sure about the ppa
[10:58] <dednick> attempting to update now and see
[11:01] <MCR> mmrazik, seems there are still Jenkins issues left... armhf builds seem failing and the links point to 404 errors
[11:01] <mmrazik> MCR: we have some issues with publishing the results to public jenkins
[11:01] <mmrazik> MCR: what is the link which gives you 404?
[11:01] <MCR> https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix1168919-multimonitor-cube-gears-green-gear-always-in-front/+merge/158790
[11:01] <mmrazik> (for some reasons it takes up to 17h to get it published :-/)
[11:01] <MCR> the last comment by Jenkins
[11:02] <MCR> the failure link
[11:02] <mmrazik> MCR: it looks like some jenkins problem :-/ http://pastebin.ubuntu.com/5595249/
[11:03] <MCR> mmrazik, the same here: https://code.launchpad.net/~mc-return/compiz/compiz.merge-showmouse-another-cleanup/+merge/159993
[11:03] <mmrazik> MCR: I need to go to doctor but will be back in ~hour
[11:03] <mmrazik> will check it then
[11:03] <MCR> thanks
[11:03] <MCR> happy healing
[11:03] <tvoss> mmrazik, ping
[11:04] <mmrazik> tvoss: pong
[11:07] <dednick> Saviq: I think we're using standard sdk that comes with raring. We should be be adding the ubuntu-sdk ppa to the build script.
[11:08] <Saviq> dednick, but it was broken on the device, which uses the phablet-team ppa
[11:08] <dednick> Saviq: i c. phablet-team doesnt include ubuntu-ui-toolkit package.
[11:08] <Saviq> hmm
[11:09] <Saviq> so where are we getting it for the device images from....
[11:10] <dednick> i have no idea. trying to track it down now.
[11:11] <dednick> Saviq: qtdeclarative5-ubuntu-ui-toolkit-plugin
[11:11] <Saviq> dednick, yeah that I know, just where does the package come from...
[11:12] <Saviq> right, so ubuntu-ui-toolkit is already daily-landed
[11:15] <mzanetti> Saviq: isn't michi on irc?
[11:15] <Saviq> mzanetti, at the moment he's probably in bed
[11:15] <Saviq> mzanetti, well, maybe not yet, but it's 9pm for him
[11:15] <mzanetti> Saviq: no... he comments to my MPs
[11:15] <mzanetti> Saviq: ah... I thought he would be from sweden
[11:16] <Saviq> mzanetti, nope, Brisbane
[11:16] <mzanetti> oh... brisbane
[11:16] <Saviq> mzanetti, http://s-jenkins:8080/job/unity-phablet-ci/730/ stuck?
[11:17] <Saviq> or just queued..
[11:17] <mzanetti> Saviq: queued :/ we bumped the ticket's priority today morning
[11:17] <mzanetti> Saviq: the one for more VM's
[11:17] <Saviq> .thanks
[11:18] <Saviq> damn MIR! ;P
[11:18] <tsdgeos> Saviq: proably queued, see http://s-jenkins:8080/job/unity-phablet-qmluitests/
[11:18] <Saviq> yeah it just started
[11:27] <Cimi> tsdgeos, this should be ok... https://code.launchpad.net/~unity-team/unity/phablet.test_GenericLensView/+merge/160143
[11:28] <tsdgeos> Cimi: you should make that depend on the other MR that does the CategoryFilter changes and stuff
[11:28] <tsdgeos> otherwise it's going to be a mess when merging
[11:28] <mzanetti> tsdgeos: Saviq: good news. I think I found the issue. well not found the root cause, but found how to reliably work around it (I hope). If you see it happening again, please ping me immediately
[11:29] <Saviq> mzanetti, which one? publishing? or getting stuck?
[11:29] <mzanetti> talking about getting stuck I am
[11:29] <tsdgeos> awesomer
[11:29] <Cimi> tsdgeos, done
[11:30] <mzanetti> Saviq: regarding the publishing: it seems to be on the public jenkins instance which is not maintained by us. martin opened a ticked
[11:30] <Saviq> mzanetti, k thanks
[11:30] <mzanetti> ticket
[11:50] <sil2100> didrocks: hmmm
[11:50] <sil2100> didrocks: the hud switch might be a bit troublesome
[11:51] <nic-doffay> mzanetti, got time for another quick QML Q?
[11:51] <mzanetti> nic-doffay: of course
[11:51] <nic-doffay> Check this out: https://pastebin.canonical.com/89744/
[11:51] <nic-doffay> I'm trying to pass the X & Y values of the itemAtIndex of the first Repeater into the second Repeater. What is the correct way to achieve this?
[11:52] <mzanetti> nic-doffay: I wouldn't use 2 repeaters
[11:53] <nic-doffay> mzanetti, what would you suggest?
[11:54] <mzanetti> nic-doffay: something like this: https://pastebin.canonical.com/89749/
[11:55] <mzanetti> nic-doffay: would that work for your case?
[11:55] <nic-doffay> mzanetti, I need to specifically pass each x and y of the each dots.
[11:56] <nic-doffay> But otherwise the formatting is better.
[11:57] <mzanetti> nic-doffay: like this? https://pastebin.canonical.com/89750/
[11:57] <mzanetti> nic-doffay: anyways, theDot.x and theDot.y will be 0, 0 here
[11:57] <nic-doffay> mzanetti, so that id will be the correct index?
[11:58] <mzanetti> nic-doffay: you don't need the index. the whole Item {} is repeated. inside the Item {} its just like there would be only this one
[11:58] <nic-doffay> mzanetti, hmm ok. So it's probably best to regenerate the x & y from the Circle component?
[11:59] <mzanetti> nic-doffay: why do you need x & y at all?
[12:00] <mzanetti> nic-doffay: the whole Item takes care about positioning. inside the item you shouldn't need to know about it, do you?
[12:00] <nic-doffay> mzanetti, because the dots are positioned according to their index in a ring. The circle object for each index needs to be at the same position the dot is.
[12:00] <mzanetti> nic-doffay: it is like this
[12:02] <mzanetti> nic-doffay: if you move the Item {} around, the Dot and the Circle will also be moved accordingly, because the Item is the parent and its children will always be painted inside the parent (unless you specify something else)
[12:02] <nic-doffay> mzanetti, right, I think I misunderstood something then.
[12:02] <nic-doffay> I'll give it a go and get back to you...
[12:02] <mzanetti> nic-doffay: ok. let me know how it goes.
[12:03] <nic-doffay> mzanetti, one more thing.
[12:03] <mzanetti> yes?
[12:03] <nic-doffay> I need to trigger an animation in the Dot and the Circle.
[12:03] <nic-doffay> Should I put a function in the item which calls both of them?
[12:04] <nic-doffay> then reference it with itemAt(i).callFunction.
[12:04] <nic-doffay> Would that be the cleanest?
[12:04] <mzanetti> nic-doffay: hmm... hard to say... depends a bit what the trigger is and what kind of animation
[12:04] <Saviq> nic-doffay, mzanetti I think there's one more issue here - the circles need to be in a separate layer than the  dots
[12:05] <Saviq> nic-doffay, mzanetti as the circles need to be blended with the big circle
[12:05] <nic-doffay> Saviq, is there no way you can specify the Z order of a Component?
[12:05] <Saviq> and the dots just painted on top of that
[12:05] <Saviq> nic-doffay, z-order yes, but then you need to blend
[12:05] <nic-doffay> Saviq, yeah I'm going to get the blending done after the ordering is correct.
[12:06] <nic-doffay> I just wanted to get the circles appearing first then move on to everything else.
[12:06] <Saviq> nic-doffay, btw, weren't you supposed to draw the circles in GL?
[12:07] <Saviq> nic-doffay, that's what loicm suggested, no?
[12:07] <Saviq> I thought that was the approach, too, as it'd be more performant that way
[12:07] <mzanetti> Saviq: you think it'd really be more performant?
[12:08] <nic-doffay> The circles are being drawn with a ShaderEffect atm Saviq .
[12:08] <nic-doffay> I just haven't done any blending maths yet.
[12:08] <Saviq> nic-doffay, yes, that means an fbo per circle
[12:09] <Saviq> mzanetti, yes I believe so, if they'd be painted in single buffer instead a buffer per-circle as it is now
[12:09] <nic-doffay> Saviq, that would require more work then.
[12:09] <mzanetti> Saviq: more performant in terms of memory usage you mean... not in terms of speed
[12:09] <mzanetti> ok... that could well be the case
[12:09] <Saviq> mzanetti, yeah, resources
[12:09] <nic-doffay> I wanted to get some sort of results for a video Kevin asked me to put together for the end of Thursday.
[12:09] <Saviq> nic-doffay, ok, that's fine for now, just asking
[12:10] <mzanetti> Saviq: otoh working with layer: enabled in the right place might do the trick too
[12:10] <mzanetti> but I don't know for sure
[12:10] <Saviq> mzanetti, that would only mean caching after the fact, IIUC
[12:11] <Saviq> nic-doffay, but then as I mentioned you need a separate layer for the circles and the dots, to be able to blend the center circle in between them, no?
[12:11] <Saviq> unless you get get to the z-order in a ShaderEffect, not sure, really
[12:11] <nic-doffay> Saviq, you're probably right. I'm not familiar enough with this to know atm.
[12:12] <Saviq> but I'm afraid you can't - you just get a blended texture to sample
[12:12] <nic-doffay> What would be the best way to achieve that?
[12:15] <Saviq> nic-doffay, your approach with two repeaters is one possibility (btw, we need a circle Positioner)
[12:16] <paulliu> Hi. I rebase to trunk today. I've add "import Unity.Test 0.1 as UT" but I got "Unity.Test" is not installed. Is there something I need to set?
[12:17] <paulliu> Other similar tests runs good.
[12:18] <nic-doffay> Saviq, what would the Positioner be used for?
[12:19] <Saviq> paulliu, make sure the import path for the test is set correctly
[12:19] <Saviq> nic-doffay, Positioners take a bunch of items and position them
[12:19] <Saviq> nic-doffay, we have Row, Column, Grid, Flow
[12:20] <nic-doffay> Saviq, how would this help with a circle?
[12:20] <Saviq> nic-doffay, if we create a Circle one, it would just take however many items you give it as children
[12:20] <Saviq> nic-doffay, and align them in a circle
[12:21] <Saviq> nic-doffay, but that's just theoretical, I just thought of it right now ;)
[12:21] <nic-doffay> Saviq, ok at the moment I'm generating the positions from within the Dot. It would probably be simpler if I pushed my stuff and you had a review of it to see where I could improve things with QML components I'm unfamiliar with.
[12:22] <Saviq> nic-doffay, yeah, the Dot should just be that - a dot
[12:22] <Saviq> nic-doffay, the delegate of the Repeater should calculate the x/y/rotation
[12:23] <Saviq> nic-doffay, I'd probably abstract those parts that calculate that
[12:24] <nic-doffay> Saviq, here's the branch: https://code.launchpad.net/~nicolas-doffay/unity/infographics_transitions
[12:24] <Saviq> nic-doffay, and then put the Dot and the Circle inside that "x/y/rotation calculator" in a Repeater
[12:24] <nic-doffay> Saviq, I'm not sure what you mean by putting the Circle inside the calculator in the Repeater, mind giving me a quick example?
[12:34] <mmrazik> MCR: the jenkins issues should be fixed and the MPs re-approved
[12:34] <MCR> mmrazik, thanx once again +1
[12:34] <Saviq> nic-doffay, that's very rudimentary and probably wrong, but something like https://pastebin.canonical.com/89755/
[12:35] <nic-doffay> Saviq, that's enough thanks a lot. So you also recommend moving it into it's own .qml?
[12:35] <Saviq> nic-doffay, if you want to abstract it, yes, there's no other way
[12:37] <didrocks> sil2100: can you expand a little bit?
[12:37] <paulliu> OK, Now I got the path set corrected. But now I get "Unity" plugin "FakeUnityQml" not found while I'm doing "import Unity 0.1".
[12:37] <sil2100> didrocks: give me 5 more minutes, need to re-check something first ;)
[12:37] <paulliu> Is that still a IMPORT_PATH issue?
[12:38] <paulliu> We currently don't have any tests for the qml have "import Unity 0.1" right now.
[12:43] <nic-doffay> Saviq, mzanetti thanks for your help as always.
[12:44] <mzanetti> nic-doffay: no worries. did it help you in the end?
[12:44] <nic-doffay> mzanetti, yeah for sure.
[12:44] <mzanetti> ok then
[12:47] <Saviq> paulliu, no tests themselves, but the components under test do
[12:47] <Saviq> paulliu, did you build?
[12:47] <Saviq> the error you got means "the plugin was found, but can't find the plugin .so file"
[12:48] <mzanetti> Saviq: https://code.launchpad.net/~mzanetti/unity/phablet-no-coverage-for-tests/+merge/160292
[12:49] <paulliu> Saviq: Yeah, I'm run ./build and ./run, all good.
[12:49] <paulliu> Saviq: there is libFakeUnityQml.so generated in builddir/
[12:52] <Saviq> paulliu, please push your code and we'll have a look
[12:52] <paulliu> Saviq: ok.
[12:54] <kgunn> nic-doffay: ping
[12:55] <MacSlow> Saviq, regarding your fix-suggestions (https://code.launchpad.net/~macslow/unity/phablet-notification-renderer/+merge/155512/comments/353258) ... if I leave out the "model." from "model.<role>" in the delegate, access to the roles no longer works
[12:56] <nic-doffay> kgunn, what's up
[12:56] <Saviq> MacSlow, checking, it should only be needed when there's a naming conflict
[12:57] <MacSlow> Saviq, all data from the different roles is missing from a notification, when dropping model. and I run the test
[12:57] <Saviq> MacSlow, yeah, only the icons would be left, right
[12:57] <Saviq> MacSlow, sorry, didn't read properly - leave model. be
[12:58] <MacSlow> Saviq, good... other thing... I gladly drop the UbuntuShape for the 2x2 case (icon-summary layout case), if I knew how I could switch to just a simple Image-item there
[12:59] <Saviq> MacSlow, that's why I proposed to just switch the sources of icon and secondaryIcon
[13:00] <Saviq> MacSlow, when there's no body
[13:00] <Saviq> MacSlow, so icon would remain 6x6
[13:01] <Saviq> MacSlow, do we expect transitions between standard and icon-summary?
[13:02] <MacSlow> Saviq, hm... that would then need to be documented in the 3rd-part developer docs... it's a fair approach... no there's no intention to transition like that
[13:02] <Saviq> MacSlow, why would it need to be documented?
[13:03] <Saviq> MacSlow, and anyway, I wonder if summary-body shouldn't simply assume the icon to not be there?
[13:03] <Saviq> in that case it would require docs in 3rd-party docs
[13:03] <MacSlow> Saviq, so the app-developer knows to pass in a secondary-icon, if he/she wants a icon-summary layout.
[13:03] <Saviq> MacSlow, we could just use icon
[13:03] <Saviq> MacSlow, but I do think only supporting secondaryIcon for icon-summary layout is actually better
[13:03] <Saviq> more explicit
[13:04] <Saviq> and people won't start passing avatars to icon-summary
[13:04] <Saviq> that would get shrunk to 2x2
[13:04] <MacSlow> Saviq, yes... summary-body has no icon at all
[13:04] <Saviq> MacSlow, I wonder if this should simply be another type?
[13:04] <Saviq> MacSlow, instead of relying on body being empty?
[13:06] <MacSlow> Saviq, no... I think it's better to have it adapt implicitly instead of introducing a different notification-type just for a layout-variation
[13:06] <Saviq> MacSlow, ok then, let's go for "icon gets ignored if there's no body"
[13:07] <Saviq> sounds good?
[13:07] <MacSlow> +1
[13:17] <tsdgeos> Cimi: maybe that test can include the onmovementstarted thing? what do you think'
[13:17] <tsdgeos> ?
[13:19] <tsdgeos> though there's not really much to test either
[13:22] <Cimi> tsdgeos, mmm
[13:22] <Cimi> indeed
[13:23] <Cimi> because I don't really know how to test that
[13:23] <Cimi> it's a listviewwithheader thing
[13:32] <Saviq> nic-doffay, standup?
[13:32] <nic-doffay> Saviq, yep one sec.
[13:36] <nic-doffay> Saviq, not hearing anyone, mumble doing it's thing again.
[13:36] <Saviq> nic-doffay, we could hear you
[13:36] <nic-doffay> Saviq, sorted
[13:45] <paulliu> Saviq: https://code.launchpad.net/~paulliu/unity/dash_people_test/+merge/160366
[13:48] <MacSlow> Saviq, the use of strings for "Notifications.Type.Interactive" are the stand-ins until we merge in the backend, where those will come in in the final form
[13:48] <Saviq> MacSlow, yeah, but where is "type" defined?
[13:48] <MacSlow> mzanetti, Saviq: ^ is there a better way for this stand-in?
[13:48] <Saviq> MacSlow, Notification.qml doesn't have a "type" property
[13:48] <Saviq> MacSlow, unless I misread again, but was trying to look real hard :D
[13:48] <MacSlow> Saviq, oh... wait :)
[13:50] <Saviq> MacSlow, which suggests the type property isn't really used ;)
[13:50] <Saviq> MacSlow, or at least the conditions never return true, but the thing still works fine
[13:50] <Cimi> mzanetti, I don't remember the file where we hace mouseMove() definition
[13:51] <Cimi> or dandrader or Saviq
[13:51] <Saviq> Cimi, UnityTestCase.qml, no?
[13:51] <mzanetti> yep
[13:51] <Saviq> Cimi, it's in tests/utils/ now
[13:51] <MacSlow> Saviq, bollocks... that's the problem when one works with multiple branches (locally) and assumes too much... fixed now
[13:51] <Cimi> Saviq, not that
[13:51] <Cimi> Saviq, it's not qt?
[13:51] <dandrader> Cimi, mouseMove comes from Qt's TestCase
[13:51] <Saviq> Cimi, then TestCase itself
[13:51] <Saviq> Cimi, just ctrl+click on it
[13:52] <Cimi> ok
[13:52] <Saviq> in QtCreator
[13:53] <Cimi> dandrader, I just noticed that mouseMove has a delay parameter
[13:54] <Cimi> dandrader, maybe this is what we need?
[13:55] <dandrader> Cimi, it's implemented with wait()
[13:55] <Cimi> dandrader, but in which way?
[13:55] <Cimi> dandrader, just a simple wait (delay) ?
[13:55] <dandrader> Cimi, I think so
[13:55] <Cimi> or like the smart way I was thinking with gerry?
[13:56] <Cimi> dandrader, we're using that in the sdk
[13:56] <Cimi> the delay
[13:59] <Cimi> dandrader, here https://code.launchpad.net/~tpeeters/ubuntu-ui-toolkit/panel/+merge/158399
[14:03] <Saviq> paulliu, here's the correct CMake line:
[14:03] <Saviq> add_qml_test(Dash DashPeople IMPORT_PATHS ${CMAKE_BINARY_DIR}/tests/mocks ${CMAKE_BINARY_DIR}/plugins ${qmltest_DEFAULT_IMPORT_PATHS})
[14:03] <Cimi> Saviq, paulliu ordering is important too if you override plugins
[14:03] <Saviq> paulliu, it fails with "PeoplePreviewData is unavailable", but that's correct
[14:04] <Saviq> Cimi, exactly, and it's actually reverse order
[14:04] <Saviq> Cimi, as in the last will be loaded first
[14:04] <paulliu> Saviq: ok.
[14:08] <paulliu> Saviq: why PeoplePreviewData is unavailable is correct? It works yesterday.
[14:09] <Saviq> paulliu, because it needs to be implemented as a fake
[14:09] <Saviq> paulliu, yesterday there was no fake Unity plugin, today there is one
[14:09] <Saviq> paulliu, look in /tests/qmltests/plugins/Unity/
[14:09] <paulliu> Saviq: ok.. let me check.
[14:10] <Saviq> paulliu, something of the sort needs to be implemented to fake the PeoplePreviewData interface
[14:11] <paulliu> Saviq: ok.
[14:15] <paulliu> Saviq: ok, so I just need to copy peoplepreviewdata.cpp to fake_peoplepreviewdata.cpp and add some mock-up data there?
[14:17] <mhr3> didrocks, hey, any idea why friends didn't build in the ppa?
[14:17] <mhr3> http://<IP_ADDRESS>:8080/view/cu2d/view/Experimental/view/100Scopes/job/cu2d-100scopes-experimental-1.1prepare-unity-lens-friends/37/console
[14:17] <didrocks> 2013-04-23 07:09:54,550 INFO A version (0.1.1bzr13.03.26daily13.03.27ubuntu.unity.experimental.certified-0ubuntu1) is available at the destination for that component but is not in trunk which is still at 0.1.2-0ubuntu1. Ignoring that component for source: unity-lens-friends, branch: lp:~unity-team/unity-lens-friends/libunity7-compatible, series: raring.
[14:17] <didrocks> cf the console :)
[14:17] <Saviq> paulliu, not necessarily, you can create a QML component that mimics the same
[14:17] <Saviq> paulliu, the approach is your choice
[14:17] <paulliu> Saviq: ok.
[14:17] <mhr3> didrocks, can you translate that for me?
[14:18] <mhr3> into non debian language? :P
[14:18] <didrocks> mhr3: there is a version in the certified ppa
[14:18] <didrocks> of friends
[14:18] <didrocks> called 0.1.1bzr13.03.26daily13.03.27ubuntu.unity.experimental.certified-0ubuntu1
[14:18] <didrocks> this one was committed automagically to the changelog
[14:18] <didrocks> I guess ;)
[14:18] <didrocks> and it's not anymore in debian/changelog
[14:19] <mhr3> didrocks, so it needs to be fixed where?
[14:19] <didrocks> mhr3: I guess you removed it yesterday while doing you merge, right?
[14:19] <didrocks> mhr3: lp:~unity-team/unity-lens-friends/libunity7-compatible needs to have the changelog entry
[14:19] <mhr3> didrocks, nope, it was never there
[14:20] <didrocks> mhr3: or we can remove friends from the certified ppa
[14:20] <didrocks> until next run
[14:20] <didrocks> it won't look at it anymore
[14:20] <mhr3> but we do want friends in the ppa
[14:20] <mhr3> well.. the scope
[14:20] <didrocks> mhr3: I mean, removing it until next daily
[14:21] <didrocks> or until we relaunch
[14:21] <didrocks> mhr3: it's not like in distro, if we loose that changelog entry, it's not important :)
[14:21] <mhr3> didrocks, oh, why not, if that fixes it...
[14:21] <mhr3> didrocks, although i do wonder where did the changed changelog came from
[14:21] <mhr3> i suppose there's a magical sed somewhere
[14:22] <didrocks> mhr3: it was published in the certified ppa
[14:22] <didrocks> so it proposed a branch against it
[14:22] <didrocks> not sure what happened then :)
[14:22] <mhr3> it went boom? :)
[14:22] <didrocks> possible that a merge ate it :)
[14:23] <mhr3> the bots are that hungry? i thought you feed them regularly
[14:25] <nic-doffay> Saviq, the thing with the Positioner is that the x & y implicitly rely on the item's width and height. Any recommendations?
[14:25] <sil2100> didrocks: we're getting some armhf panda permission problems in merges, but I think fginther is looking into that now ;)
[14:25] <nic-doffay> The positioner doesn't really take that into account.
[14:25] <sil2100> ERROR:pbuilderjenkins:Permission denied
[14:25] <didrocks> mhr3: not enough apparently :)
[14:25] <mhall119> davidcalle: ping
[14:26] <didrocks> sil2100: yeah, I saw the failure, ok, let's wait for Francis!
[14:26] <Saviq> nic-doffay, you're writing the positioner, so you can do whatever you need
[14:27] <Saviq> nic-doffay, so you should take the size of the children into account
[14:27] <nic-doffay> Saviq, I'm thinking of just having a variable to hold the size of a dot and circle.
[14:27] <nic-doffay> Sound reasonable?
[14:27] <Saviq> nic-doffay, no ;)
[14:28] <nic-doffay> What would be preferable then?
[14:28] <Saviq> nic-doffay, a simple solution would be to have the positioner 0x0
[14:28] <Saviq> nic-doffay, and in the delegate then anchors.centerIn
[14:28] <Saviq> nic-doffay, the actual Dot / Circle
[14:28] <Saviq> inside the positioner
[14:29] <nic-doffay> Saviq, I'm not sure I see where the child's dimensions fit into that.
[14:29] <Saviq> nic-doffay, into that they don't
[14:29] <Saviq> nic-doffay, if the positioner is 0x0, you just anchors.centerIn: parent the actual Dot / Circle
[14:30] <Saviq> nic-doffay, it's not great 'cause you're drawing outside of the parent item
[14:30] <nic-doffay> I'm still not sure how that would replace this: x: infoGraphicsHalfWidth - halfWidth + radius * Math.sin(slice)
[14:31] <nic-doffay> Saviq, where halfWidth is the dot's half width.
[14:31] <Saviq> nic-doffay, if the item you're positioning is 0x0
[14:32] <Saviq> nic-doffay, there's no width or height
[14:32] <Saviq> nic-doffay, so you just need to calculate the center point
[14:32] <Saviq> so it would be « x: infoGraphicsHalfWidth + radius * Math.sin(slice) »
[14:33] <davidcalle> mhall119, pong
[14:33] <Saviq> nic-doffay, and then you go Repeater { delegate: CirclePositioner { Dot { anchors.centerIn: parent } } }
[14:33] <nic-doffay> Saviq right, I think I need to look into these anchor points a bit. I'm used to setting offsets and that's about it.
[14:33] <mhall119> davidcalle: hey, you've got a couple of work items on http://summit.ubuntu.com/uds-1305/ that are still TODO
[14:33] <mhall119> can you update them and set them to POSTPONED if need be?
[14:34] <Saviq> nic-doffay, you should use anchor lines (they're not points) almost everywhere
[14:34] <Saviq> nic-doffay, they're faster than absolute positioning
[14:34] <Saviq> nic-doffay, and more explicit about what they are
[14:35] <davidcalle> mhall119, do you have blueprint links or something? I don't find anything on summit.
[14:36] <mhall119> ah, sorry, thought I had the BP link in the clipboard
[14:36] <mhall119> https://blueprints.launchpad.net/ubuntu/+spec/community-r-accomplishments-clients
[14:36] <mzanetti> Saviq: tsdgeos: 6 new raring VM's waiting to be tortured :)
[14:36] <Saviq> mzanetti, !!!
[14:37] <Saviq> mzanetti, http://s-jenkins:8080/label/quantal&&amd64/ is waiting ;)
[14:37] <mzanetti> Saviq: http://s-jenkins:8080/label/quantal&&amd64/load-statistics
[14:37] <mzanetti> that was a busy day today :)
[14:37] <Saviq> youch
[14:38] <davidcalle> mhall119, thanks
[14:38] <Saviq> mzanetti, that graph looks like it's smoothed out too much ;)
[14:38] <Saviq> mzanetti, we had 1.2 executors at times ;)
[14:39] <Saviq> and usually _almost_ 2, wth?
[14:43] <mzanetti> Saviq: yeah... the VMs shut themselves down when unused
[14:43] <mzanetti> Saviq: that makes them disappear from the available executors.
[14:43] <mzanetti> Saviq: quite weird... but bottomline is: if the grey one is higher than the red one we have an issue
[14:44] <Saviq> mzanetti, yeah, and then the graph is smoothed out, which makes it all look really weird ;)
[14:56] <tsdgeos> lol
[14:56] <tsdgeos> running the qtdeclarative unittests
[14:56] <tsdgeos> has left me with around 50 ghost entries in unity
[15:03] <sil2100> didrocks: merged \o/
[15:03] <sil2100> didrocks: https://code.launchpad.net/~sil2100/cupstream2distro-config/rename_libhud-qt/+merge/160380
[15:03] <sil2100> didrocks: https://code.launchpad.net/~sil2100/phone-app/rename_libhud-qt/+merge/160391
[15:03] <sil2100> didrocks: https://code.launchpad.net/~sil2100/gallery-app/rename_libhud-qt/+merge/160398
[15:03] <sil2100> Looking for others
[15:04] <nic-doffay> Saviq, is this looking ok?
[15:04] <nic-doffay> https://pastebin.canonical.com/89775/
[15:05] <matzipan> hey, guys, how can i join unity-design, the mailing list?
[15:05] <matzipan> a
[15:05] <Saviq> nic-doffay, property int totalElements: parent.totalElements
[15:05] <nic-doffay> I'm going to have to replace the sprite.x & y with the child's x & y, but I'm not sure how to get that info since it's a delegate.
[15:05] <Saviq> nic-doffay, how do you know that parent has totalElements? ;)
[15:05] <nic-doffay> Any better way of getting the Repeaters count Saviq ?
[15:05] <Saviq> nic-doffay, you should avoid referencing objects that are out of your scope
[15:06] <Saviq> nic-doffay, yeah, pass it through in the delegate
[15:06] <Saviq> nic-doffay, Repeater { id: repeater; delegate: Item { value: repeater.value } }
[15:06] <Saviq> nic-doffay, use Positioner.index explicitly
[15:06] <Saviq> instead of just index
[15:06] <nic-doffay> Saviq, same goes for the width, height and x & y I'm assuming?
[15:07] <Saviq> nic-doffay, you should use "width" and "height" in your calculations, not implicis
[15:07] <Saviq> implicits
[15:08] <Saviq> nic-doffay, 'cause if someone overrides the dimensions of your positioner, you need to take that into account
[15:08] <Saviq> nic-doffay, and why property int angle? why not rotation: straight away?
[15:09] <Saviq> nic-doffay, also, you need to pass the center of the circle somewhere
[15:09] <nic-doffay> Saviq, would that not be the implicitWidth of all the children / 2?
[15:09] <nic-doffay> At least that's what I assumed.
[15:10] <Saviq> nic-doffay, implicit width / height, is the default
[15:10] <Saviq> nic-doffay, but if the user of the component decides to override it for whatever reason
[15:10] <Saviq> he will provide a width: and height:
[15:11] <Saviq> nic-doffay, otherwise they will be bound to the implicits
[15:11] <nic-doffay> Got it Saviq
[15:11] <nic-doffay> So should I replace implicitWidth and height with other variables?
[15:12] <Saviq> nic-doffay, no, let it be, it's correct as is
[15:12] <Saviq> nic-doffay, by default it will be the dimensions of the children
[15:12] <Saviq> nic-doffay, but in calculating x and y
[15:12] <Saviq> nic-doffay, you need to use actual "width" and "height"
[15:12] <nic-doffay> Saviq, which will be passed in by the Repeater I'm assuming.
[15:13] <Saviq> nic-doffay, it will be bound to implicits
[15:13] <Saviq> nic-doffay, unless you override it somewhere
[15:13] <didrocks> kenvandine: mind reviewing sil2100's branches?
[15:13] <Saviq> nic-doffay, why do you need sprite at all?
[15:13] <didrocks> ah those, easy, can do :)
[15:13] <nic-doffay> Saviq, I don't I said I'll replace that earlier.
[15:13] <kenvandine> didrocks, i would love to!
[15:14] <Saviq> nic-doffay, if the assets are square (which they should be) you don't care about that
[15:14] <didrocks> sil2100: I think all apps are concerned :) starting from -config should help
[15:15] <sil2100> didrocks: indeed it looks like that!
[15:18] <kenvandine> sil2100, just point me at branches as needed
[15:21] <tedg> mpt, Is there a reason we don't show the security of the access point in the panel?
[15:21] <tedg> mpt, i.e. whether it's WPA or not.
[15:21] <mpt> tedg, I hadn't even thought about it.
[15:22] <tedg> mpt, It isn't done on other OSes, but it seems like useful information.
[15:22] <mpt> What would you do differently as a result?
[15:22] <tedg> That's what I was trying to figure out.
[15:22] <mpt> I mean, you'd better not be thinking "This is a secure wi-fi connection, so it's okay for me to send my credit card details over unencrypted HTTP"
[15:23] <tedg> The only thing I could think of is that it could be key in realizing I was on my home network vs. the Starbucks next door.
[15:23] <tedg> Perhaps whether I'd turn on a VPN or not?
[15:24] <Saviq> tsdgeos, Cimi, dandrader, mzanetti MacSlow, nic-doffay, paulliu, I'm close to EOD and back in OAK
[15:24] <tsdgeos> Saviq: enjoy
[15:24] <nic-doffay> Saviq, cheers!
[15:24] <Saviq> will have network until tomorrow ~noon CET, so ping me with anything urgent
[15:24] <dandrader> Saviq, ok. see you in OAK
[15:24] <Cimi> Saviq, ciao!
[15:25] <MacSlow> Saviq, nearly done with the MR-fixes... only the wire-up of the actions is undergoing
[15:25] <Saviq> otherwise, you behave!
[15:25] <dandrader> :)
[15:25] <MacSlow> Saviq, see you in Oakland
[15:25] <Saviq> MacSlow, we'll see how my evening goes, might still get to it ;)
[15:25] <mzanetti> Saviq: ok then. take care
[15:26] <MacSlow> Saviq, apart from the working action wire-up I've pushed all changes already... so you'll have something to review if you find the time :)
[15:27] <paulliu> Saviq: see you there.
[15:29] <sil2100> kenvandine: ok! One coming right up!
[15:29] <sil2100> kenvandine: https://code.launchpad.net/~sil2100/share-app/rename_libhud-qt_and_hud1/+merge/160411
[15:45] <sil2100> kenvandine: another one! https://code.launchpad.net/~sil2100/camera-app/rename_libhud-qt_and_hud1/+merge/160416
[16:02] <nic-doffay> mzanetti, got a moment to look at this? https://pastebin.canonical.com/89782/
[16:02] <nic-doffay> What's the best way to trigger something on each dot outside the scope now that I'm using a delegate?
[16:04] <mzanetti> nic-doffay: eating right now... will come back to you in 10 mins
[16:13] <mzanetti> nic-doffay: what exactly do you want to do?
[16:17] <nic-doffay> Call a function which is a member of the Dot component from outside the repeater's scope.
[16:17] <nic-doffay> mzanetti, ^
[16:18] <mzanetti> nic-doffay: for all the items or just a specific one?
[16:20] <mzanetti> nic-doffay: if you need to change some state in the dots, create a property. like this: https://pastebin.canonical.com/89785/
[16:23] <mzanetti> nic-doffay: if you need to execute imperative code, you can use a signal: https://pastebin.canonical.com/89786/
[16:26] <nic-doffay> Thanks mzanetti looks like I'll be using a signal.
[16:26] <sil2100> kenvandine: and yet another one: https://code.launchpad.net/~sil2100/mediaplayer-app/rename_libhud-qt_and_hud1/+merge/160427
[16:27] <sil2100> (sorry it took so long, had a context switch)
[16:35]  * sil2100 is wondering if he missed anything else
[16:37] <tsdgeos> sil2100: gallery?
[16:37] <tsdgeos> browser?
[16:37] <sil2100> Browser!
[16:37] <tsdgeos> almost every phone-app uses Hud
[16:37] <tsdgeos> it was the only way to quit until yesterday :D
[16:37] <sil2100> tsdgeos: thanks, I missed the browser app it seems ;)
[16:39] <tsdgeos> sil2100: calculator, calendar, clock?
[16:40] <mzanetti> tsdgeos: hey
[16:41] <tsdgeos> yo
[16:41] <mzanetti> tsdgeos: http://s-jenkins:8080/job/generic-mediumtests/1559/
[16:41] <mzanetti> there is a hud test failing now
[16:41] <mzanetti> tsdgeos: I think just the state needs to be updated from "moving" to "spreadMoving"
[16:42] <mzanetti> tsdgeos: could you confirm its just that?
[16:42] <tsdgeos> whas that changed recently?
[16:42] <sil2100> tsdgeos: those are not in daily-building yet;)
[16:43] <tsdgeos> sil2100: oki
[16:43] <mzanetti> tsdgeos: don't know. I just see it failing now - reproduceable
[16:44] <tsdgeos> mzanetti: which state are we speaking of?
[16:45] <tsdgeos> mzanetti: it's already spreadMoving
[16:45] <mzanetti> tsdgeos:
[16:45] <mzanetti> in show_launcher    self.assertThat(launcher.state, Eventually(Equals("spreadMoving")))
[16:45] <mzanetti> MismatchError: After 10.0 seconds test on Launcher.state failed: 'spreadMoving' != dbus.String(u'moving', variant_level=1)
[16:45] <tsdgeos> ok
[16:45] <tsdgeos> so your sentence was backwards
[16:46] <mzanetti> tsdgeos: I wonder how this could happen... shouldn't autolanding already have failed here?
[16:46] <tsdgeos> mzanetti: anyway what's wrong is not that
[16:46] <tsdgeos> look at that launcher
[16:46] <tsdgeos> is like 10 pixels of the border
[16:46] <tsdgeos> mzanetti: it should i guess
[16:47] <tsdgeos> can you locally reproduce the launcher being off?
[16:47]  * tsdgeos can't
[16:47] <mzanetti> me neither
[16:48] <tsdgeos> but you can reproduce the autopilot problem?
[16:48] <mzanetti> let me test locally.... so far I just know that all our builds fail because of this
[16:49]  * tsdgeos doesn't remember anymore how to run autopilot :D
[16:49] <tsdgeos> autopilot run
[16:49] <mzanetti> tsdgeos: autopilot list
[16:49] <mzanetti> tsdgeos: or make autopilot
[16:50] <mzanetti> segfaults here
[16:50] <tsdgeos> boom
[16:50] <tsdgeos> same here
[16:50] <mzanetti> need to LD_LIBRARY_PATH the builddir somehow
[16:51] <tsdgeos> command? then
[16:51] <mzanetti> if the run script wouldn't be broken for additional arguments /
[16:51] <tsdgeos> LD_LIBRARY_PATH=. make autopilot ?
[16:51] <tsdgeos> no luck here
[16:51] <mzanetti> I think this is needed too: export QML2_IMPORT_PATH=$PWD/builddir/plugins:$PWD/builddir/tests/mocks
[16:52] <tsdgeos> nothing
[16:52] <tsdgeos> listen, i need to go, feeling quite a bit sick, need to lie for a while in the bed
[16:52] <mzanetti> export LD_LIBRARY_PATH=$PWD/../unity_build/build/lib
[16:52] <mzanetti> tsdgeos: ^
[16:53] <tsdgeos> i'll have a look toorrow first thing if you haven't got to it
[16:53] <tsdgeos> sorry bout that
[16:56] <sil2100> kenvandine: this more -> https://code.launchpad.net/~sil2100/webbrowser-app/rename_libhud-qt/+merge/160436 ;)
[17:28] <sil2100> tedg: hi!
[17:28] <sil2100> tedg: you around? ;)
[17:28] <tedg> Yup
[17:29] <tedg> Though, thinking about lunch :-)
[17:29] <sil2100> tedg: just a quick question then! Since I didn't use HUD 2.0 recently, I'd like to know if what we have here is correct:
[17:30] <sil2100> http://<IP_ADDRESS>:8080/job/ps-generic-autopilot-release-testing/label=autopilot-ati/140/artifact/results/artifacts/unity.tests.test_search.HudSearchTests.test_hud_search%20%28basic%29.ogv <- the HUD results are something like "Text here bla bla ()" <- what's with that () ?
[17:30] <tedg> sil2100, Is this for Unity Nux ?
[17:31] <tedg> Oh, need VPN.
[17:31] <sil2100> tedg: it's from the daily-build-next PPA, so it's still using unity nux there, just with the new HUD?
[17:31] <tedg> sil2100, Ah, yeah.  So that changed from 1 to 2
[17:32] <tedg> sil2100, It used to be "File > New" and now it's "New (File)"
[17:32] <sil2100> Ah
[17:32] <tedg> So then "File > Doc > New" would be "New (File, Doc)"
[17:32] <sil2100> Ok, makes sense now, thanks - I'll have to fix up the autopilot tests for that then, got a bit confused when I saw that first
[17:32] <sil2100> Grab lunch!
[17:32] <tedg> We should probably hide the () when there are no entries though.
[17:32] <tedg> That's confusing.
[17:42] <mmrazik|afk> fginther, mzanetti, Saviq: according to IS the publishing issues should be resolved
[17:43] <mmrazik|afk> yup. 1 job in the queue
[17:43] <mmrazik|afk> compared to ~530 in the morning
[17:43] <mzanetti> mmrazik|afk: thanks
[21:54] <tedg> Hey alesage, I think this one is not my fault.  Do you know what causes this?  https://jenkins.qa.ubuntu.com/job/hud-raring-amd64-ci/17/console
[21:55] <alesage> tedg, yes I saw that; we've been having publishing troubles, I'll re-run the job
[21:55] <tedg> alesage, Ah, okay.  Thanks!
[23:41] <robru> mterry (or anybody really), I need a bit of help with a packaging issue. I need to know the difference between debian/tmp and debian/binary-package-name and what kind of logic DH uses to pick which of those it uses. I've got a package where I'm trying to build multiple binary packages and dh_install is dumping files from both binary packages into debian/tmp where they clobber each other. Some documentation indicates that
[23:41] <robru> debian/[binary-package-name] is the default, but it's not using that and I'm not sure how to make it use that.