=== chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [05:49] robru: ^ we've that kind of errors [05:49] I see there have been changes in the trunk [05:49] (of cupstream2distro) [05:50] but sil2100 can look at it when he's up === chihchun_afk is now known as chihchun [07:01] bzoltan_: Mirv: terribly sorry, I've identified the issue, working on a fix. [07:07] bzoltan_: Mirv: ok I've pushed a fix to trunk, you should see that hit production in 10 minutes, deepest apologies. [07:24] Alright looks good, I'm off [07:53] trainguards: hey, would it be possible to re-kick this build: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-069/+build/9637542 [07:54] it succeeds with all other arches & on all xenial builds, just i386 vivid failed. Suspect flaky test [07:55] greyback: on it [08:08] thanks robru! [08:34] Mirv, I confirm that silo 42 fixes bug #1488364 [08:34] bug 1488364 in Oxide "[Qt 5.5] OxideQSslCertificate::issuer doesn't work in Qml" [Medium,Triaged] https://launchpad.net/bugs/1488364 [09:05] oSoMoN: thanks! [09:05] Mirv, thanks to you for the backport! [09:06] you're welcome [10:17] hey trainguards, got autopkg failure https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-ci-train-ppa-service-landing-071/xenial/armhf/u/unity-scope-click/20160427_085222@/log.gz which seems unrelated to the changes in silo 71 [10:17] a dependency problem [10:22] flaky test [10:22] grumble [10:23] robru: no probs thanks for fixing it [10:24] sil2100, hey, can you help with silo 71 again? see my earlier msg above === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [10:49] pstolowski: hey! [10:49] pstolowski: sorry, was in a meeting, let me take a look === xavigarcia is now known as xavigarcia_lunch === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === _salem is now known as salem_ === xavigarcia_lunch is now known as xavigarcia === Laney is now known as seb128smum === seb128smum is now known as Laney [13:56] jibel, hey, tiagosh told me you were blocking their silo on a unity8 failure [13:57] jibel, if it's "qmltestrunner::Wizard::test_accountPage()" that's a known issue (flakiness) in unity8 and not their fault. We have a fix for it in silo 27 [13:57] mzanetti, I am not blocking anything :) [13:57] hmm... ok, that was the information I got [13:57] mzanetti, I am just not forcing a silo without understanding why it's failing [13:58] mzanetti, yeah that's the test [13:58] right. so it is failing because of britney being muuuch slower than our jenkins. it passes in our jenkins but is flaky (rather constantly) on britney [13:58] so, just to let you know that this particular test failure is not the app's silo's fault [13:59] mzanetti, okay, I just needed a confirmation from the unity8 team [13:59] ack [13:59] thanks [14:21] salem_, silo 55 marked ready for qa. It should land today or tomorrrow [14:21] jibel, awesome, thank you! === timp is now known as t1mp [15:07] sil2100, hey, have you found anything about silo 71? I just rebuild a while ago and got depednency error again (click scope, xenial only) === salem_ is now known as _salem [15:53] pstolowski: yeah, looked at it and again looking, hard to say what might be the cause here - did you poke the unity8 guys if they saw such an error on their silos before? [15:54] (since it's part of unity8's autopkgtest deps) [15:57] sil2100, hmm i think i was looking at older version of excuses after rebuilding it.. apparently click scope tests is still in progress [15:59] I don't see them running on the autopkgtest page though [15:59] pstolowski: could you maybe try poking pitti? He has much more experience in autopkgtests, he might know if those are running or something died horribly [16:00] Hello, I need a MOTU/core-dev to publish this silo for me please: https://requests.ci-train.ubuntu.com/#/ticket/1305 === chihchun is now known as chihchun_afk [16:02] tedg: hey! I checked it briefly in the morning, did you have someone doing a preNEW review (from the archive admins)? [16:02] sil2100: I asked seb128 to review the packaging, but I'm not sure what else is needed. [16:02] (and I fixed the things he asked me to) [16:03] tedg, the packaging looked good out of the few things I pointed out [16:03] Happy to follow other steps as needed, but I'm not sure what they are. [16:04] seb128: if it got your blessing then I guess it's good to go ;) [16:04] * sil2100 can proceed with publishing then [16:04] sil2100, will do, thanks [16:04] sil2100, tedg, I can have another look but not today, at a sprint and wrapping up now [16:04] seb128: ok, will wait for a final ACK from you [16:04] tedg: would it be ok with you to wait till tomorrow ^ ? [16:05] tedg, it was looking good so probably fine, feel free to land [16:05] Since an archive admin needs to +1 it since this lands straight to xenial-overlay right now, so a NEW-like review is in order [16:05] sil2100: Yes, I think that's fine, it does have a couple strings in it. So end of the week would be good. [16:07] sil2100: After that, how do we do seed changes for overlays? https://code.launchpad.net/~ted/ubuntu-seeds/policy-kit/+merge/291966 [16:08] tedg: we have local branched-off versions in the overlay that we manually upload - I can pick up this change from you and push it to the xenial and vivid overlays [16:09] Right now it's a bit complicated as we're still not doing landings for yakkety, but yeah, leave it on my plate and I'll make sure it's in all the right places [16:09] * sil2100 puts it on his list [16:09] sil2100: Ah, I see, cool, thank you! [16:10] sil2100, could you please publish silo 38, when you have a moment? [16:21] oSoMoN: sure, on it now [16:21] Wooo \o/ [17:17] sil2100: When is the feature freeze for OTA11? [17:54] bzoltan_: string freeze is Friday, selected none string changes can land after that [18:44] davmor2: cool, thanks.. so my silo can still make it :) [18:54] bzoltan_, which silo? [19:43] trainguards: automated signoff of silo 10 failed, but looking at the failure (in unity8’s qmluitests), it’s obvious it’s got nothing to do with browser changes, can someone with the appropriate permissions re-run that test please? I don’t seem to be allowed === salem_ is now known as _salem