=== chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [12:16] mardy: Hey. I checked that owncloud plugin works fine, but I can't see VK listed in System Settings > Accounts. I installed the package. [12:17] rvr: do you see the "VK.com account tester" in your applications list? [12:18] mardy: Ah, nope, I didn't install that [12:18] That's why [12:18] Ok [12:18] rvr: yes, accounts are visible only if there's an app which can use them === _salem is now known as salem_ [12:58] rvr, got approvals on the MPs in https://trello.com/c/TgBCQi3L [12:59] also noted the bug that the silo failed on last time in the trello card (if you remember 2 mondays ago, the silo failed) [13:13] kdub: Ack [13:38] robru, neat new building interface. Kinda miss having to press build twice though, maybe add it as opt-in/easter egg? [13:52] robru, hey, think you could include field diffs in the audit logs? === chihchun_afk is now known as chihchun [15:10] jgdx: lol [15:10] Saviq: yeah there's some issues with errors not being reported, I'm working on that [17:33] slangasek: sil2100: we meeting today? sil's email mentioned laptop problems [17:34] robru: I assume not unless sil2100 says otherwise or you have something that you need to cover today [17:35] slangasek: nah I think I'm good. I'm just doing a couple days of bugfixing before I start the next big chunk of parallelization [18:37] trainguards: why is silo 3 marked failed for automated signoff? I’m not seeing any autopkgtest failure in the reports [18:37] oSoMoN: https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-003/excuses.html see the ALERT [18:38] oSoMoN: so the version in your silo is lower than the version in xenial overlay. [18:39] oSoMoN: I guess you need to bump the version & reupload, or if those are the same package, just copy the xenial-overlay one into the silo, that'll satisfy britney [20:31] robru, re silo 3, that’s not right, the version in xenial-overlay (1.14.7-0ubuntu2~xenial1) is lower than the version in the silo [20:31] robru, from what I understand britney is complaining because of the version in xenial-updates (1.15.7-0ubuntu0.16.04.1), but I don’t understand why it would do that [20:32] oSoMoN: because it's newer than your version [20:32] oSoMoN: apparently it's in xenial-security https://launchpad.net/ubuntu/+source/oxide-qt/1.15.7-0ubuntu0.16.04.1 [20:33] but touch images give a higher priority to the overlay PPA, don’t they? [20:33] not simply [20:33] oSoMoN: yeah, in touch images. not when britney is evaluating silos, that's different. [20:34] what’s the point of doing that, if that doesn’t match a real-world scenario? [20:34] needs to change, or we need to be better about ensuring security updates that go to released ubuntus end up in the overlay [20:35] oSoMoN: the point of running britney on silos is that it matches how britney is run on -proposed, so it would catch issues that would happen when the silo is published [20:36] oSoMoN: in this case the package wouldn't be published to xenial-proposed so this wouldn't come up [20:36] robru: well, it should come up, because the security update should have been copied to the overlay PPA [20:37] dobey: but I mean when this silo is published, the overlay package will be copied to overlay without going through xenial-proposed, so the main xenial britney would never look at this scenario [20:38] oSoMoN: you can ask QA to ignore the failure and test the silo anyway. [20:38] robru: right, but that doesn't change the fact that we're apparently missing a security update in the overlay [20:38] robru, I understand that, but as dobey points out, packages in silos go to -proposed only for yakkety, so complaining about xenial doesn’t seem correct [20:38] dobey: the versioning of the silo package gives me the impression that it's the same package? [20:39] oSoMoN: running britney for non-yakkety was a design goal, since it was viewed as a bug that publishing to overlay sneaks around britney. [20:39] robru, dobey: yes, they’re the same packages, we’re putting them in the silo precisely because security updates are not copied to the overaly [20:39] overlay [20:40] robru, I don’t mean that we shouldn’t be running britney, but somehow this kind of error shouldn’t be considered a blocker [20:40] oSoMoN: i guess you shouldn't have added the ~overlay1 here [20:40] robru, I’ll ask jibel to override that error tomorrow to proceed with QA validation anyway, thanks for the tip [20:41] oSoMoN: yeah if you'd just copied the identical package without changing the version then britney would have said it was fine since it's no-change same package. [20:41] oSoMoN: which it's not too late to do [20:41] oSoMoN: it seems it should have just been a binary copy [20:42] not sure where they were copied from though [20:42] oSoMoN: in fact I can do that for you now if you want [20:42] but we had been doing that (with the ~overlay1 suffix) when xenial was the devel series, and it never was a problem, in fact it’s the first time I’m seeing this kind of error [20:42] robru, wait [20:42] oSoMoN: I've seen this before but I can't remember which packages it was [20:43] oSoMoN: munging the version number to ~overlay1 only makes sense if you specifically need to rebuild against overlay PPA contents which might differ from stock xenial. not sure if that's the case here [20:43] no, please don’t do that, it’s not a binary copy because the version in the silo is built against the overlay PPA, which might have e.g. updated media-hub packages [20:43] ok [20:43] it's just too bad there still isn't arm64 builds :-/ [20:43] it’s coming [20:44] eww === salem_ is now known as _salem