[07:43] <zzarr> good morning
[08:55] <tsdgeos> Saviq: do you know how far ltinkl was on the mocks for testLogin1Capabilities ?
[08:56] <tsdgeos> should i work on that?
[09:04] <tsdgeos> https://code.launchpad.net/~lukas-kde/unity8/fixLogin1Tests/+merge/272493 seems pretty much almost done
[09:04]  * tsdgeos finds something else to do
[09:11] <Saviq> tsdgeos, quite far, but there were issues with dbus processes staying on after the test completed
[09:12] <Saviq> and I never got around to looking into it
[09:14] <tsdgeos> Saviq: is that reproducible with regular make foo or does it need the pkgtest to happen?
[09:14] <Saviq> tsdgeos, dunno
[09:15] <tsdgeos> ok let me check then
[09:35] <Saviq> tsdgeos, autopkgtest results in silo 30 don't look too good :/ http://paste.ubuntu.com/14476759/
[09:35] <tsdgeos> ouch
[09:35] <Saviq> although most of them are Launcher(214)
[09:36] <Saviq> so one fix should help a lot there
[09:36] <tsdgeos> what's will all those launcher failures
[09:36] <Saviq> but there are a few new ones
[09:36] <Saviq> tsdgeos, I'm worried this might be timing when dragging the launcher out or so
[09:36] <tsdgeos> love this one
[09:36] <tsdgeos> Actual   (): 434.2858326192127
[09:36] <tsdgeos>    Expected (): 434.28571428571433
[09:36] <Saviq> yeah
[09:36] <Saviq> that's xenial btw
[09:37] <tsdgeos> yaeh the launcher ones seem to be failing to drag it into view
[09:38] <Saviq> vivid looks much better http://paste.ubuntu.com/14476772/
[09:39] <tsdgeos> Saviq: mzanetti: we need to focus on getting those to 0, at this point we have so many things failing it gets hard to tell if a failure is a regression, fixed elsehwere or needs fixing
[09:39] <Saviq> tsdgeos, totally, I do, however, run both of them on amd64 before releasing any silo
[09:39] <Saviq> so my runs yesterday for silo 30 were both 100%
[09:40] <mzanetti> agreed
[09:41] <Saviq> tsdgeos, I will try today to get at least a temp job running those in our jenkaas so we can maybe put it through its paces
[09:41] <tsdgeos> Saviq: so this are results not from you but from the builders?
[09:41] <Saviq> unfortunately that might not be enough
[09:41] <Saviq> tsdgeos, https://requests.ci-train.ubuntu.com/#/ticket/776
[09:41] <Saviq> down at the bottom "Autopkgtest results"
[09:41] <Saviq> um wroing
[09:41] <Saviq> https://requests.ci-train.ubuntu.com/#/ticket/854
[09:41] <Saviq> tsdgeos, ↑
[09:43] <tsdgeos> oki
[09:44] <Saviq> so yeah, seems roughly reproducible between vivid and xenial, modulo launcher not getting pulled out
[09:57] <tsdgeos> i can't get extra processes when running ltinkl's branch with regular makeFoo
[09:57] <tsdgeos> i guess it's pbuilder only?
[10:02] <Saviq> tsdgeos, could very well be
[10:12] <Saviq> tsdgeos, oh but, our current CI's autopkgtests run on hardware actually
[10:12] <Saviq> IIRC
[10:12] <Saviq> s/current/old/
[10:13] <tsdgeos> Saviq: what do you mean?
[10:13] <Saviq> tsdgeos, not in pbuilder/autopkgtest or anything
[10:13] <Saviq> tsdgeos, or actually... in a dedicated VM
[10:14] <Saviq> like one with GPU and stuff
[10:14] <tsdgeos> you mean the extra process for the login1 tests?
[10:15] <tsdgeos> it didn't seem to be failing on the CI stage, not sure where fginther saw the extra process/failure
[10:17] <Saviq> tsdgeos, he SSH'd to the machine when it failed
[10:17] <Saviq> tsdgeos, lemme restart it in the mean time
[10:18] <Saviq> ah conflict
[10:19] <Saviq> tsdgeos, re: SM_BUSNAME, I think the plan was to put the mock on the session bas originally... but then we found that there's no problem mocking a system bus...
[10:19] <tsdgeos> i see
[10:20] <Saviq> tsdgeos, FWIW we already have it elsewhere
[10:21] <tsdgeos> it's just that it's the thing actually causing the conflcit D:
[10:21] <Saviq> http://pastebin.ubuntu.com/14476963/
[10:21] <tsdgeos> if it wasn't there it'd merge fine
[10:22] <Saviq> well, sure, I agree - since we can mock system bus, we shouldn't have that define at all
[11:44] <dandrader> mzanetti, is this related to what you're fixing? https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1515977
[11:59] <tsdgeos> mzanetti: found race condition in one of the shell tests https://code.launchpad.net/~aacid/unity8/fix_test_focusAppFromLauncherExitsSpread/+merge/282292
[11:59] <tsdgeos> Saviq: ↑
[12:00] <Saviq> tsdgeos, coolz
[12:00] <dandrader> tsdgeos, what's "bfb"?
[12:01] <tsdgeos> dandrader: it's the "home" button
[12:02] <tsdgeos> i didn't name it, just following the way
[12:02] <mzanetti> I named it...
[12:02] <dandrader> yeah
[12:02] <mzanetti> design calls it like that
[12:02] <dandrader> we should probably mock or disable that dismiss timer in tests....
[12:06] <tsdgeos> dandrader: putting the mouse over the button disables it
[12:08] <dandrader> tsdgeos, right
[12:12]  * tsdgeos goes to hunt more failing tests
[13:55] <mterry> kgunn_, how does deprecation work in a Touch lifecycle context?  Like with LTS releases, we don't support skipping an LTS upgrade, so we know we can drop deprecated stuff after each LTS release.  But do we have a similar story for Touch?  (not in terms of apps, which have frameworks, but in terms of things like u8's internal properties)
[14:08] <Saviq> mterry, wdym "u8's internal properties"?
[14:08] <kgunn_> mterry: interesting question, when you say "deprecation for life cycle" don't  you still mean for apps to understand/accomodate ?
[14:09] <mterry> Saviq, uh like if we changed where a gsettings is stored, but we still need to support upgrades from old devices, so we can't yet drop the old location.  My question is "when can we?"
[14:09] <mterry> kgunn_, no I mean in customer/device support lifecycle
[14:10] <Saviq> so upgrades from how far back do we support, really?
[14:10] <mterry> Saviq, yeah
[14:10] <Saviq> ok, no idea ;)
[14:10] <mterry> Saviq, like 10 OTAs?  Forever?
[14:11] <mterry> Saviq, makes me much more cautious about adding settings like that now  :)
[14:34] <tsdgeos> Saviq: do we worry about
[14:34] <tsdgeos> FAIL!  : qmltestrunner::Card::test_art_size(Tall) property height
[14:34] <tsdgeos>    Actual   (): 434.2858326192127
[14:34] <tsdgeos>    Expected (): 434.28571428571433
[14:34] <tsdgeos>    Loc: [/tmp/adt-run.Q55ONm/build.yU8/unity8-8.11+15.04.20160111.1/tests/qmltests/Dash/tst_Card.qml(341)]
[14:34] <tsdgeos> ?
[14:34] <tsdgeos> want me to change it so that it compares say the first 3 decimals?
[14:35] <Saviq> tsdgeos, well... it failed, didn't it...
[14:35] <tsdgeos> yeah, it's also i386
[14:35] <tsdgeos> which shall be killed with fire
[14:36] <tsdgeos> but ok, will make it check say up to two decimals, should me more than enough
[14:36] <Saviq> tsdgeos, we need to make it pass *somehow*, shouldn't tryCompare or something be smart about it?
[14:36] <tsdgeos> well you told it to compare two doubles, it doesn't know how much exact you want them to be
[14:37] <tsdgeos> it has "some" wiggle room
[14:37] <tsdgeos> but probably for this different it thinks it's too different
[14:37] <ltinkl> isn't there some sort of qFuzzyCompare in QML? :o
[14:39] <ltinkl> tsdgeos, yup, tryCompare uses fuzzy comparisons for numbers
[14:39] <tsdgeos> ltinkl: yes, but fuzzy compare for those 2 numbers probably fails
[14:40] <ltinkl> tsdgeos, see function qtest_compareInternal(act, exp)
[14:40] <ltinkl> tsdgeos, basically it goes like: if (Math.abs(act - exp) <= 0.00001)
[14:41] <ltinkl> tsdgeos, yours differ already at the 4th decimal :p
[14:45] <ltinkl> tsdgeos, using number.toFixed(3) should help it, if you're happy with the precision
[14:47] <tsdgeos> ltinkl: i'd be happy with 1px precision :D
[16:39] <Saviq> dandrader, https://code.launchpad.net/~dandrader/qtmir/appRestart-lp1527737/+merge/281701/comments/716315
[16:41] <dandrader> Saviq, always reproducible?
[16:42] <Saviq> dandrader, not sure yet, but reproducible enough it seems
[16:42] <Saviq> dandrader, might be related to the app failing
[16:44] <Saviq> or crashing
[16:50] <Saviq> dandrader, yeah, it looks app crashing is causing AppMan to go into bad state
[17:15] <Saviq> dandrader, so yeah, camera + content-hub is easiest to reproduce with today, as the camera app crashes and sends AppMan into the broken state
[17:15] <dandrader> Saviq, ok...
[17:16] <Saviq> dandrader, I've removed qtmir from silo 30 to get it landed without that change
[19:17] <dandrader> Saviq, https://code.launchpad.net/~dandrader/qtmir/appRestart-lp1527737/+merge/281701/comments/716386
[19:17] <dandrader> Saviq, it's a iffy use case