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