[07:36] <Cimi> is this channel quiet or am I disconnected?
[07:37] <MacSlow> Cimi, just quiet
[07:37] <Cimi> MacSlow, ciao Mirco!
[07:37] <MacSlow> morning Cimi
[08:02] <Saviq> dednick, hey, need an opinion... Plugin.cmake, I want to use those macros for mocks, too
[08:03] <Saviq> dednick, so I need to be able to override destination, and for qmlfiles a NO_INSTALL option
[08:03] <dednick> Saviq: hm. they may need some mods to put files into correct folders.
[08:04] <Saviq> dednick, but then I'd need to pass absolute destination anyway, so plugin_subpath loses sense
[08:04] <Saviq> and what's worse we have different destinations for shadow and installation, so suddenly I need two separate paths
[08:06] <Saviq> dednick, another option would be global qmlplugin_DEFAULT_PREFIX that, if set, would be used (unless overridden in the call itself)
[08:06] <dednick> Saviq: hm. might be best if you make export_mock_qmlplugin ?
[08:06] <Saviq> dednick, don't want completely separate macros, rather wrappers around a generic one
[08:07] <Saviq> dednick, but then you can't override... but maybe that's fine, if you want to override, you just use the "top level" one
[08:08] <Saviq> ok yeah, I think I'll go for that
[08:08] <Saviq> dednick, thanks for being a sounding board :)
[08:09] <Saviq> FYI guys, I was working until 3am last night, so will be taking some of that time back today, might be available intermittently
[08:09] <dednick> Saviq: hm. as far as I can tell. You should only need to adjust the path from ${CMAKE_BINARY_DIR}/plugins > ${CMAKE_BINARY_DIR}/test/mocks . and the NO_INSTALL
[08:09] <dednick> Saviq: although, aren't some mocks installed?
[08:09] <Saviq> dednick, some are, yes
[08:10] <Saviq> dednick, but the other path I need to adjust is ${SHELL_INSTALL_QML}
[08:10] <Saviq> dednick, for those that are installed
[08:18] <Saviq> biab
[08:34] <tsdgeos> dednick_: yes we can
[08:34] <tsdgeos> dednick_: it's a 5.2 feature
[08:34] <tsdgeos> so we couldn't until then
[08:34] <tsdgeos> s/then/recently when we started requiring 5.2
[08:34] <tsdgeos> well we don't do that *yet*
[08:35] <tsdgeos> so base your branch on https://code.launchpad.net/~aacid/unity8/killqt51/+merge/217391
[08:42] <didrocks> Saviq: hey! I was wondering if you got any info on the crash on stop and working on it?
[08:56] <Cimi> tsdgeos, didn't we have out layouts?
[08:56] <tsdgeos> Cimi: ?
[08:56] <tsdgeos> out -> own?
[08:56] <Cimi> own
[08:56] <Cimi> yes
[08:57] <Cimi> our
[08:57] <tsdgeos> Cimi: we have some own layouts for the Dash yes
[08:57] <Cimi> r is close to t
[08:57] <Cimi> I thought from sdk
[08:57] <Cimi> I remember tim working on something
[08:57] <tsdgeos> ah no idea :D
[08:57] <Cimi> better use qt imho though
[08:57] <Cimi> they probably have more guys than us :)
[08:58] <tsdgeos> Cimi: do you remember at some point the PreviewZoomableImage was center aligned and then we brought it back to left aligned?
[08:58] <tsdgeos> you remember why?
[08:58] <tsdgeos> it's a change that https://code.launchpad.net/~paulliu/unity8/zoomImage/+merge/207941 also introduces back
[08:58] <mhr3> tsdgeos, the fitting was buggy then
[08:58] <tsdgeos> mhr3: do you remember when?
[08:59] <tsdgeos> seems to work fine-ish here with https://code.launchpad.net/~paulliu/unity8/zoomImage/+merge/207941
[08:59] <mhr3> tsdgeos, is was with some specific images
[08:59] <mhr3> stuff from amazon iirc
[08:59] <Cimi> nope
[09:00] <tsdgeos> ok, let's wait for Saviq to come back from the death and see if he remembers
[09:00] <tsdgeos> mhr3: not ignoring your opinion, eh!
[09:00] <mhr3> yeah, right
[09:01] <tsdgeos> just i can't make it fail with amazon right now
[09:01] <Cimi> tsdgeos, activeFocus is a qt property?
[09:02] <tsdgeos> maybe he remmbers something mrore
[09:02] <tsdgeos> Cimi: it is
[09:11] <Cimi> Saviq, mhr3 I think I found issue and fix for the review
[09:12] <Cimi> nope
[09:13] <mhr3> oh?
[09:13] <mhr3> ooohhhh.. :(
[09:18] <Cimi> tsdgeos, when you want a new challenge, I have sth for you
[09:18] <tsdgeos> Cimi: i'm still busy writing my code that writes qml code :D
[09:42] <dednick> _sbin_init.1000.crash    - err, not ideal
[09:47] <Cimi> tsdgeos, how do I know which component is stealing my event?
[09:47] <tsdgeos> dednick: :D
[09:47] <tsdgeos> Cimi: press?
[09:47] <Cimi> tsdgeos, yep
[09:48] <Cimi> tsdgeos, basically with ratinginput enabled in our previews
[09:48] <Cimi> tsdgeos, if you scroll the preview
[09:48] <Cimi> tsdgeos, and tap on the TextArea
[09:48] <tsdgeos> is it enabled?
[09:48] <Cimi> tsdgeos, the mouseArea of the textArea does not get events
[09:49] <Cimi> guess so
[09:49] <Cimi> I am forcing it to true now
[09:49] <Cimi> tsdgeos, enabled and no events
[09:50] <Cimi> tsdgeos, like something else is stealing
[09:50] <tsdgeos> ok
[09:51] <Cimi> tsdgeos, so would like to know who is stealing
[09:51] <tsdgeos> don't know, start adding mouseareas all over
[09:51] <tsdgeos> see which get it and which not
[09:56] <Cimi> tsdgeos, if I add mousearea on top of the textarea it gets events
[09:57] <Cimi> well, still trying
[09:57] <Cimi> let's see
[10:04] <Cimi> mhr3, ok got it
[10:04] <Cimi> how to fix, dunno yet
[10:05] <Cimi> tsdgeos, textArea has a flickable
[10:05] <tsdgeos> it's the flickable war!
[10:05] <Cimi> tsdgeos, inside the flickable there's a textedit
[10:06] <Cimi> tsdgeos, inside this mousearea
[10:06] <tsdgeos> Cimi: try disable the outer flickable
[10:07] <tsdgeos> or something
[10:07] <tsdgeos> we've had that before
[10:07] <tsdgeos> look for some todo or fixme in other preview stuff
[10:07] <tsdgeos> there's comments about it
[10:12] <Cimi> tsdgeos, ok
[10:12] <Cimi> tsdgeos, kinda works
[10:12] <Cimi> mhr3, found reason
[10:12] <mhr3> Cimi, yey!
[10:12] <Cimi> mhr3, SDK bug
[10:26] <mhr3> xnox, awful bug in dbus' upstart script - it writes the dbus-address into $HOME, and if there's no space on the home partition it makes the boot fail
[10:34] <xnox> mhr3: good point. imho i never wanted it to write anything into $HOME, yet somebody insisted on that, whilst we were debugging environment issues.
[10:34] <xnox> mhr3: i can upload to drop that.
[10:34] <xnox> or well at least not fail.
[10:35] <Cimi> mhr3, fixed https://launchpad.net/~ci-train-ppa-service/+archive/landing-009/
[10:35] <seb128> xnox, mhr3: wasn't that for adb shell to parse or something? the write shouldn't be an issue, not handling it failing is the bug
[10:37] <mhr3> i do not know what was the reasoning, but it can basically brick your phone, so needs to be fixed
[10:38] <mhr3> think full home partition should be something QA should be looking into testing
[10:38] <mhr3> davmor2, ^?
[10:39] <xnox> mhr3: i'm not sure that even with gnome2 desktop or unity (any) i could login with a full home partition.
[10:40] <mhr3> xnox, well but at least you don't need to be doing emergency calls on gnome2 desktop
[10:42] <Cimi> seb128, we really need a way to detect if there is active connection on the phone
[10:42] <xnox> mhr3: very very true!!
[10:42] <seb128> Cimi, wasn't thostr's team working on a connectivity api for that?
[10:42] <Cimi> seb128, on my nexus, I get wifi signal connected but is a lie
[10:42] <Cimi> I have no idea
[10:43] <Cimi> seb128, also, unity8 dash without connectivity is a laugh
[10:43] <davmor2> mhr3: hahahahahahaha yeah I'm gonna brick my only phone for fun ;)  This is not something on our schedule but I'm assuming this is something that would have to be run manually if it bricks the phone as there is no physically way to retrieve it from the datacenter  but it's not something we are ever going to run daily
[10:43] <Cimi> seb128, we need at least to show something and tell you're disconnected, that's why all is blank
[10:43] <Cimi> seb128, pinging you because I know you care about those issues :)
[10:44] <davmor2> Cimi: known issue routing is screwed, disconnect and reconnect
[10:44] <mhr3> davmor2, well, it's not real brick, you can still connect to the phone, it should be just checking that it actually starts up
[10:44] <Cimi> dednick, this would be nice https://code.launchpad.net/~nick-dedekind/ubuntu-settings-components/access-point-init/+merge/212913
[10:44] <mhr3> davmor2, people will be escalating this
[10:45] <Cimi> seb128, you know what happened to this branch https://code.launchpad.net/~nick-dedekind/ubuntu-settings-components/access-point-init/+merge/212913
[10:45] <Cimi> approved since ages
[10:45] <Cimi> not getting jenkins
[10:45] <seb128> no, maybe ubuntu-settings-component is not set up for ci
[10:45] <Cimi> seb128, so I merge manually?
[10:45] <seb128> something to ask the #ubuntu-ci-eng channel or maybe fginther
[10:45] <seb128> no
[10:46] <seb128> we should ask CI to enable it
[10:46] <dednick> seb128: hm. it was. but doesnt seem to be anymore
[10:46] <dednick> I'll chase it up
[10:46] <davmor2> mhr3: what people?  Or are you asking if we'll be escalating it?
[10:46] <seb128> dednick, Cimi: in fact jenkins ran?
[10:46] <seb128> the first comment
[10:46] <seb128> dednick, Cimi: there is not automerging anymore, things need to go through CI train with a lander
[10:47] <Cimi> seb128, I know nothing about this ci train
[10:47] <dednick> seb128: it ran ages ago, but the job doesnt seem to exist anymore
[10:47] <Cimi> seb128, where can I read about it?
[10:47] <seb128> Cimi, no idea, I don't think it's well documented
[10:47] <seb128> but that's how all our landing are happening for some months
[10:48] <Cimi> I know
[10:48] <Cimi> but always had a big question mark :)
[10:48] <seb128> Cimi, https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdC05a2ZQSmgwU2NFYnJQOE9qMDRYa3c&usp=drive_web#gid=1
[10:48] <seb128> that lists Saviq as the ubuntu-settings-components owner/lander
[10:48] <xnox> mhr3: davmor2: well for this particular issue, one doesn't need to do anything drastic -> e.g. add /etc/init/foo.conf job that does chmod -w =)))
[10:50] <mhr3> xnox, davmor2, yea i don't think it's hard to test, but definitely something that should be tested regularly
[10:50] <Cimi> seb128, so what is ci train:?
[10:51] <Cimi> and why
[10:51] <dednick> Cimi: i think the "train" is a metaphorical one :)
[10:51] <Cimi> at first seems not efficient
[10:52] <seb128> Cimi, it's the workflow we use for landings
[10:52] <Cimi> seb128, what was wrong with the automatic merge by jenkins?
[10:52] <dednick> seb128: do we need to tick something somewhere to mark MPs to land?
[10:52] <xnox> Cimi: it's like auto-landing, without the "auto" =)
[10:53] <dednick> seb128: "we" as in the landing king (Saviq in this case)
[10:55] <davmor2> mhr3: it won't be run regularly unless it can be automated.  We only have so many hours in a day.  xnox making home -w isn't the same as having it mostly or completely full so might not give the results you expect
[10:56] <seb128> Cimi, try asking asac about the why
[10:57] <seb128> Cimi, basically to make sure things are tested on the image before being merged
[10:57] <mhr3> davmor2, everything can be automated :)
[10:58] <Cimi> seb128, but jenkins was doing this
[10:58] <Cimi> seb128, as well as the reviewer
[10:58] <Cimi> seb128, so when you were approving things, they were tested
[10:58] <seb128> Cimi, well, you are months late and I'm the wrong person to ask anyway
[10:58] <Cimi> I have been doing this for years
[10:58] <seb128> Cimi, well, the new workflow gives you a ppa to test
[10:59] <seb128> so you don't have to do manual builds
[10:59] <Cimi> so I can stop testing, the landing king will do this for me?
[10:59] <seb128> and you can easily install e.g on your phone
[10:59] <seb128> no
[10:59] <seb128> the opposite
[10:59] <seb128> you better make sure you test
[10:59] <seb128> the lander just line up merges and get you a ppa
[10:59] <seb128> that you can use to confirm things that are about to land are good
[11:00] <Cimi> seb128, but then it happens you approve, like this dednick branch, and sits for more than a month doing anything
[11:01] <seb128> Cimi, right, the owner of the component is supposed to watch things approved and organize regular landings
[11:01] <seb128> it's like before you could have pending reviews not getting reviewed as well
[11:01] <seb128> well, talk to Saviq, I'm sure he can organize a landing for you
[11:02] <Cimi> seb128, but I don't need one, I tested already :)
[11:02] <Cimi> I just want this merged
[11:02] <seb128> well, a landing is what makes the change go to Ubuntu and merged back to trunk
[11:02] <seb128> right
[11:02] <dednick> Saviq: ^^ !! :) https://code.launchpad.net/~nick-dedekind/ubuntu-settings-components/access-point-init/+merge/212913
[11:02] <seb128> then ask Saviq of a landing
[11:03] <Cimi> seb128, we should be able to skip those "landings", they seem inefficient to me
[11:03] <Cimi> they are good for few cases, not for others
[11:04] <Cimi> imagine I do one line modification to a debian/control file, changing a version number
[11:04] <Cimi> do I really need a landing for that?
[11:04] <Cimi> or for adding a #FIXME comment
[11:04] <seb128> Cimi, that has been discussed for weeks since the CI train was added
[11:04] <seb128> I'm not interested to spend my day discussing that again
[11:04] <Cimi> seb128, so how to we skip them?
[11:04] <seb128> especially that I'm only an user of that system
[11:05] <seb128> you don't
[11:05] <Cimi> ah cool, brilliant idea
[11:05] <seb128> talk to asac if you are unhappy
[11:05] <Cimi> I will! :)
[11:05] <seb128> cool
[11:05] <seb128> on that note, lunch time here
[11:05] <seb128> bbl
[11:13] <xnox> Cimi: core-devs can still dput things into the archive. That's what i do, on a quiet weekend and watch results on ci.ubuntu.cm
[11:14] <Cimi> xnox, spend your weekend in a swimming pool instead, tomorrow will be sunny here :)
[11:15] <xnox> Cimi: oh really?! i will indeed. speaking of which my gym is trying to extort 500 again for me to renew.
[11:15]  * xnox misses the sun
[11:35] <mhr3> tsdgeos, QT_QPA_PLATFORM doesn't matter for QCoreApplication, right?
[11:35] <tsdgeos> mhr3: no
[11:36] <mhr3> tsdgeos, no, it doesn't?
[11:36] <mhr3> or "no, it does"? :)
[11:36] <tsdgeos> mhr3: correct
[11:36] <tsdgeos> no, it does not
[11:36] <mhr3> lol
[12:22] <Saviq> dednick, right away
[12:23] <Saviq> dednick, care to review https://code.launchpad.net/~daker/ubuntu-settings-components/fix.slider/+merge/199356 ?
[12:23] <Saviq> dednick, we could land together
[12:25] <dednick> Saviq: sure
[12:26] <Saviq> didrocks, greyback is on it for unity-mir
[12:30] <dednick> Saviq: hm. why no jenkins for that branch?
[12:31] <dednick> Saviq: doesn't merge cleanly anymore
[12:34] <Saviq> dednick, ok, please comment on it
[12:46] <Saviq> tsdgeos, mhr3, on centered LazyImage, weird stuff happened when image was smaller than displayed IIRC
[12:46] <Saviq> or maybe it was about aspect ratio...
[12:50] <Saviq> dednick, kicked ci for it, since Adnane updated it already
[12:50] <Saviq> dednick, but also kicked the wrong CI for it first, hence the CI
[12:51] <dednick> Saviq: ok. ta.
[12:51] <didrocks> Saviq: great!
[12:55] <Cimi> Saviq, issue with the TextArea was indeed a bug with the SDK that is fixed by silo009
[12:55] <Saviq> Cimi, oh, I knew about that silo... didn't know it had text area changes :/
[12:55] <Cimi> Saviq, mainly due to Flickable inside the TextArea fighting
[12:56] <Cimi> Saviq, I did not too... I told zsombi there was a bug in the flickable and he said he is aware and there is a fix there :)
[12:57] <Cimi> Saviq, dednick on https://code.launchpad.net/~daker/ubuntu-settings-components/fix.slider/+merge/199356
[12:57] <Cimi> we usually have not shortened versions
[12:57] <Cimi> like minIcon
[12:57] <Cimi> instead minimumIcon or so
[12:57] <Cimi> at least ion the sdk
[12:58] <Saviq> Cimi, and why are you writing this here instead of as a comment for the MP, if that's something you'd like fixed? ;)
[12:58] <Cimi> Saviq, because I am a chatty guy :D
[12:58] <Cimi> I will
[12:58] <dednick> Cimi: it's not related to the MP
[12:58] <Saviq> Cimi, GET TO WORK :P
[12:58] <Cimi> dednick, I know
[12:58] <dednick> Cimi: so raise a bug
[12:59] <Cimi> dednick, but I noticed now
[13:01] <Cimi> here we go https://bugs.launchpad.net/ubuntu-settings-components/+bug/1315380
[13:01]  * Cimi -> lunch
[13:16] <mhr3> dednick, did you write the run_tests macro that was in unity8?
[13:16] <mhr3> cmake macro that is
[13:16] <dednick> mhr3: nope
[13:16] <dednick> mzanetti: ^ ?
[13:17] <mhr3> dednick, still, you're good with cmake... how do i make that thing not run tests in parallel
[13:17] <mhr3> ?
[13:18] <dednick> mhr3: eh? i'm shit with cmake... i didn't think tests were run in parallel
[13:19] <mhr3> dednick, neither did i until today
[13:21] <dednick> mhr3: uh, i see that you can use RUN_SERIAL for a cmake test.
[13:22] <dednick> mhr3: but it's just a custom target, so maybe not
[13:23] <mhr3> hm, but clearly something changed in U, i can't get the tests to actually run in parallel on T
[13:23] <mhr3> ah.. there we go
[13:23] <mhr3> /usr/bin/ctest --force-new-ctest-process -j8
[13:25] <dednick> mhr3: oohh. i thought you were talking about the qml test macros
[13:25] <mhr3> yea... no
[13:27] <dednick> mhr3: well i think you can use the RUN_SERIAL property for where run_test uses add_test in that case
[13:27] <dednick> add_test(NAME ${_test} COMMAND ${testCommand} RUN_SERIAL)
[13:28] <mhr3> nope, doesn't work there
[13:29] <dednick> er. no. sorry, set_tests_properties
[13:30] <mhr3> yea, did that on first try, didn't work
[13:30] <mhr3> apparently you need to do (.. PROPERTIES RUN_SERIAL TRUE)
[13:30] <dednick>  set_tests_properties(${_test} PROPERTIES ENVIRONMENT "LC_ALL=C" RUN_SERIAL TRUE)
[13:30] <dednick> mhr3: no work?
[13:31] <mhr3> yea, that does
[13:31] <mhr3> i was missing the TRUE
[13:31] <dednick> right.. good stuff... i'm hungry
[13:34] <Saviq> dednick, CI +1 on the branch, so when you're back please have a look and let's land the two
[13:40] <dednick> not gone yet :)
[13:44] <dednick> Saviq: done and approved.
[13:44] <Saviq> dednick, thought "I'm hungry" suggested you'll be gone for lunch ;)
[13:44] <Saviq> dednick, landing, then
[13:44]  * mhr3 bets dednick has crisps on his table
[13:44] <dednick> preparing myself for feasting
[13:45] <dednick> i just had a quick random meat stick from fridge. not quite sure waht is was....
[13:46] <Saviq> ...
[13:46] <MacSlow> dednick, I hope you tossed in the frypan first :)
[13:46] <dednick> tasted good. er. no
[13:46]  * dednick is away for some food now
[14:01] <tsdgeos> Saviq: so what do we do with paulliu1's branch that centers images again? approve and fix it when something break + test?
[14:01] <tsdgeos> because if we don't really remember what went wrong...
[14:01] <Saviq> tsdgeos, well, I do remember what went wrong
[14:01] <tsdgeos> yes
[14:01] <tsdgeos> but not in which case
[14:02] <tsdgeos> doesn't mean his code is going to have the same problem
[14:02] <tsdgeos> and if we don't know the case, why reject?
[14:02] <Saviq> tsdgeos, should be easy to reproduce still
[14:02] <tsdgeos> i gave it a try, failed
[14:02] <Saviq> tsdgeos, maybe he fixed it then
[14:02]  * Saviq looks for the commit
[14:02] <tsdgeos> that's what i'm saying
[14:02] <tsdgeos> his code is a complete different beast
[14:02] <tsdgeos> that also centers it
[14:03] <tsdgeos> but has more stuff
[14:17] <paulliu1> tsdgeos: I remember the centering stuff. Actually it is just a bug I've done in the code. So I fix the test cases to do the zoom-in/out twice to test that.
[14:18] <tsdgeos> paulliu1: no sure i understand what you mean
[14:19] <paulliu> tsdgeos: sorry, which branch are you actually talking about now?
[14:19] <tsdgeos> paulliu: none
[14:20] <tsdgeos> paulliu: i am saying that months ago, when we made the images center like you have done in lp:~paulliu/unity8/zoomImage  we found a problem
[14:20] <tsdgeos> but noone can't exactly remember when the problem happened
[14:20] <tsdgeos> i was asking if people remembered so i could test it against your branch and see if it also happened or not
[14:20] <tsdgeos> but i can't
[14:39] <tsdgeos> Saviq: about tests for this dynamic card stuff branch
[14:39] <tsdgeos> i'm unusure what to do honestly
[14:40] <tsdgeos> i want to still have tryCard
[14:40] <tsdgeos> so you can write your own stuff and whatnot
[14:40] <tsdgeos> but testCard doesn't make much sense
[14:40] <Saviq> tsdgeos, doesn't it?
[14:40] <tsdgeos> and a testCardCreator would be basically "check that the string you return is the string we expect you to return", which is a bit lame
[14:40] <Saviq> tsdgeos, I think we should keep testCard
[14:41] <Saviq> tsdgeos, one that's using the card creator
[14:41] <tsdgeos> Saviq: what would testCard do?
[14:41] <Saviq> tsdgeos, verify that in a given template/component configuration stuff is as expected
[14:41] <tsdgeos> hmmmm, ok
[14:42] <tsdgeos> can do i guess
[14:42] <Saviq> tsdgeos, instead of checking for whether stuff is visible
[14:42] <Saviq> tsdgeos, you'd check that you can't find it maybe
[14:42] <Saviq> *not visible
[14:42] <Saviq> but for visible things, I think the tests shouldn't even change that much
[14:42] <Saviq> well, they probably will since you got rid of CardHeader
[14:43] <tsdgeos> yep
[14:43] <tsdgeos> another thing
[14:43] <tsdgeos> we use the CardHeader in the preview stuff
[14:43] <tsdgeos> so rename it and use it in PreviewHeader ?
[16:04]  * greyback eow
[16:04] <greyback> talk Tue!