[07:34] <om26er> Trevinho: Hello!
[13:56] <Trevinho> hey om26er
[13:57] <om26er> Trevinho: Hi! it was about a bug in zesty, which has since been fixed. https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1637758
[13:57] <ubot5`> Ubuntu bug 1637758 in lightdm (Ubuntu) "lightdm greeter session not properly shut down at login" [High,Fix released]
[15:02] <pete-woods> hey folks. I'm having trouble with a QML test in this MR (https://code.launchpad.net/~pete-woods/ubuntu-settings-components/add-ethernet-item/+merge/311503)
[15:02] <pete-woods> for some reason line 246: compare(getChild("labelName").text, data.name)
[15:02] <pete-woods> is failing to find the "labelName" child widget
[15:02] <pete-woods> strangely, if I comment it out, the following lines find their widgets
[15:03] <pete-woods> i.e. "labelStatus" and "statusIcon"
[15:03] <pete-woods> I was hoping someone with more QML-fu than me might spot what's wrong
[15:41]  * pete-woods plays small violin
[15:42] <pete-woods> ltinkl_, mzanetti: maybe obvious to one of you guys? ^
[15:42] <pete-woods> (it's a pretty small MR)
[15:42] <ltinkl_> pete-woods, looking at it
[15:42] <pete-woods> thanks!
[15:43] <josharenson> pstolowski: I've added a feature to unity8 that fixes lp:1575319 However, it introduces a UI hang when dealing with a large number of scopes. For example, on the ScopesList page, if you drag the scope in position #20 to position #0, there is a several second hang as moveFavoriteTo is called. I assume something expensive is happening with the model, but do you have any insight as to why it hanging for so long?
[15:43] <ltinkl_> pete-woods, visible: text !== "" (so if that label isn't visible, it won't find it; I think it's as simple as that :)
[15:43] <mzanetti> ltinkl_, no... you can find invisible things
[15:44] <pete-woods> ltinkl_: good suggestion. I thought that there *was* text, though
[15:44] <pete-woods> even so, I'm going to try it
[15:44] <ltinkl_> mzanetti, pete-woods: sure, I meant _if_ it doesn't have text
[15:45]  * mzanetti suspects it's just not ready yet... perhaps waitForRendering(root) 
[15:47] <ltinkl_> pete-woods, yup, that too maybe; so in getChild(), instead of verify() try to use tryCompare()
[15:49] <pstolowski> josharenson, hi. yeah, i was looking at it a few months ago and i thought i eliminated the most important bottlenecks there. apparently not :(
[15:50] <pete-woods> ltinkl_: right, will see what happens there!
[15:50] <pstolowski> josharenson, would be good to know if it's actually moveFavoriteTo(), or if its storeFavorites() called by moveFavoriteTo
[15:56] <josharenson> pstolowski: I'll instrument it and see
[16:03] <pete-woods> ltinkl_, mzanetti: adding the waitForRendering, (and also removing the visible property), didn't seem to help
[16:04] <pete-woods> I couldn't think of a way to use tryCompare in that method
[16:04] <pete-woods> I don't know how to do a tryCompare(getChild(...), NOT NIL)?
[16:04] <pete-woods> type construct
[16:05] <mzanetti> pete-woods, check out "tryCompareFunction" in unity8
[16:05] <mzanetti> but not sure if that's really your issue
[16:05] <pete-woods> nor am I
[16:05] <mzanetti> at this point I'd need to run your code and debug it
[16:05] <pete-woods> fair enough
[16:06] <pete-woods> I can't see any difference between this widget and the other text widget now
[16:06] <pete-woods> (after I removed the visible condition)
[16:11] <pete-woods> mzanetti: looks like that helped you mentioned has been integrated into the UbuntuTestCase class already
[16:11] <mzanetti> could very well be, yes
[16:13] <pete-woods> mzanetti: you were correct that this isn't the problem, though
[16:13] <pete-woods> it just waits until the timeout now
[16:13] <pete-woods> (but still succeeds for the other widgets)
[16:13] <mzanetti> pete-woods, well, worst case, you can print the object tree
[16:14] <mzanetti> and check if it's there or not
[16:14] <pete-woods> mzanetti: print(ethernetItem) ?
[16:14] <pete-woods> or more difficult than that?
[16:14] <mzanetti> more difficult
[16:14] <mzanetti> but not much :D
[16:15] <pete-woods> JSON.stringify(anything) ?
[16:15] <mzanetti> ethernetItem.children.foreach(print("have item", item); callTheSameRecursiveForAll(item))
[16:15] <mzanetti> pseudo-code-ish :D
[16:17] <mzanetti> pete-woods, or, you getChild() the parent of it and print direct children only
[16:17] <mzanetti> something like that
[16:18] <pete-woods>         function banana(item) {item.children.foreach(print("have item", item); banana(item)) }
[16:18] <pete-woods> ?
[16:20] <pete-woods> did you invent the foreach function?
[16:20] <pete-woods> it seems like I need to do a more traditional index based iteration
[16:24] <pete-woods> hmm, can't see the print output
[16:24] <pete-woods> oh no, I can
[16:24] <pete-woods> just not getting any children
[16:26] <pete-woods> haha
[16:26] <pete-woods> .length, not .size
[16:27] <pete-woods> the DOM is interesting
[16:27] <pete-woods> looks like the object name is being overwritten
[16:28] <pete-woods> and set to "label"
[16:28] <pete-woods> mzanetti: any idea how that could happen?
[16:29] <pete-woods> the test passes if I look for "label", rather than "labelStatus"
[16:29] <pete-woods> sorry, "labelName"
[16:30] <pete-woods> tell me I've not spelled the property wrongly
[16:34] <pete-woods> there's something seriously weird going on
[16:35] <mzanetti> pete-woods, qml should not overwrite the objectName on its own. but perhaps it happens where the component is used?
[16:35] <pete-woods> mzanetti: I don't think it does?
[16:35] <mzanetti> pete-woods, I did not invent the foreach function, there is such a thing in JS, but I never remember the syntax
[16:35] <mzanetti> as I said, pseudo-code
[16:35] <pete-woods> mzanetti: I'm now in the situation where the DOM isn't changing when I tweak the component under test
[16:36] <pete-woods> which makes me think the test env is a bit wacky
[16:36] <pete-woods> dammit
[16:36] <pete-woods> you need to run make each time
[16:36] <mzanetti> are you perhaps loading the wrong thing? e.g. something installed in the system instead of the one in the build tree?
[16:36] <pete-woods> that's very un-QML
[16:36] <mzanetti> depends on the build-system really
[16:36] <pete-woods> fair enough
[16:36] <pete-woods> but still, at least I know why my changes are having no effect
[16:37] <mzanetti> that's something
[16:37] <pete-woods> and now the tests pass
[16:38] <pete-woods> woo!
[16:38] <mzanetti> great!
[16:38] <pete-woods> well, I learned an important lesson
[16:38] <pete-woods> know what the build scripts are doing!
[16:38] <mzanetti> haha
[16:50] <mzanetti> Saviq, resubmitted https://code.launchpad.net/~mzanetti/unity8/disable-spread-while-locked/+merge/311515
[16:50] <mzanetti> Saviq, also kicked the silo build
[16:50] <mzanetti> needs reapproval, ltinkl_ perhaps? ^
[16:55] <ltinkl> mzanetti, yup
[16:58] <ltinkl> mzanetti, in http://bazaar.launchpad.net/~mzanetti/unity8/disable-spread-while-locked/revision/2700, the change test_spreadDisabled(data) looks like a bad merge? or was this intentional?
[16:59] <mzanetti> ltinkl, bad merge indeed
[17:02] <mzanetti> ltinkl, fixed
[17:04] <Saviq> mzanetti, tx
[17:04] <Saviq> we seem to have some other trouble in the silo though
[17:05] <Saviq> greyback_, any idea what could've caused FTBFS on zesty (across the board) https://launchpadlibrarian.net/294546675/buildlog_ubuntu-zesty-amd64.qtmir_0.5.0+17.04.20161122.1-0ubuntu1_BUILDING.txt.gz
[17:07] <greyback_> Saviq: duplicate gmocks?
[17:08] <greyback_> I'll look into it
[17:08] <Saviq> tx
[17:08] <Saviq> it's in silo 2202 https://bileto.ubuntu.com/#/ticket/2202
[17:09] <Saviq> there's only 3 qtmir MPs
[17:09] <Saviq> @unity: please sanity-check the list of MPs in https://bileto.ubuntu.com/#/ticket/2202 - if there's anything missing, or something that maybe shouldn't land yet - please let me know