[12:16] <rvr> 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] <mardy> rvr: do you see the "VK.com account tester" in your applications list?
[12:18] <rvr> mardy: Ah, nope, I didn't install that
[12:18] <rvr> That's why
[12:18] <rvr> Ok
[12:18] <mardy> rvr: yes, accounts are visible only if there's an app which can use them
[12:58] <kdub> rvr, got approvals on the MPs in https://trello.com/c/TgBCQi3L
[12:59] <kdub> 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] <rvr> kdub: Ack
[13:38] <jgdx> robru, neat new building interface. Kinda miss having to press build twice though, maybe add it as opt-in/easter egg?
[13:52] <Saviq> robru, hey, think you could include field diffs in the audit logs?
[15:10] <robru> jgdx: lol
[15:10] <robru> Saviq: yeah there's some issues with errors not being reported, I'm working on that
[17:33] <robru> slangasek: sil2100: we meeting today? sil's email mentioned laptop problems
[17:34] <slangasek> robru: I assume not unless sil2100 says otherwise or you have something that you need to cover today
[17:35] <robru> 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] <oSoMoN> trainguards: why is silo 3 marked failed for automated signoff? I’m not seeing any autopkgtest failure in the reports
[18:37] <robru> oSoMoN: https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-003/excuses.html see the ALERT
[18:38] <robru> oSoMoN: so the version in your silo is lower than the version in xenial overlay.
[18:39] <robru> 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] <oSoMoN> 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] <oSoMoN> 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] <dobey> oSoMoN: because it's newer than your version
[20:32] <robru> oSoMoN: apparently it's in xenial-security https://launchpad.net/ubuntu/+source/oxide-qt/1.15.7-0ubuntu0.16.04.1
[20:33] <oSoMoN> but touch images give a higher priority to the overlay PPA, don’t they?
[20:33] <dobey> not simply
[20:33] <robru> oSoMoN: yeah, in touch images. not when britney is evaluating silos, that's different.
[20:34] <oSoMoN> what’s the point of doing that, if that doesn’t match a real-world scenario?
[20:34] <dobey> 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] <robru> 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] <robru> oSoMoN: in this case the package wouldn't be published to xenial-proposed so this wouldn't come up
[20:36] <dobey> robru: well, it should come up, because the security update should have been copied to the overlay PPA
[20:37] <robru> 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] <robru> oSoMoN: you can ask QA to ignore the failure and test the silo anyway.
[20:38] <dobey> robru: right, but that doesn't change the fact that we're apparently missing a security update in the overlay
[20:38] <oSoMoN> 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] <robru> dobey: the versioning of the silo package gives me the impression that it's the same package?
[20:39] <robru> 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] <oSoMoN> 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] <oSoMoN> overlay
[20:40] <oSoMoN> 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] <dobey> oSoMoN: i guess you shouldn't have added the ~overlay1 here
[20:40] <oSoMoN> robru, I’ll ask jibel to override that error tomorrow to proceed with QA validation anyway, thanks for the tip
[20:41] <robru> 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] <robru> oSoMoN: which it's not too late to do
[20:41] <dobey> oSoMoN: it seems it should have just been a binary copy
[20:42] <dobey> not sure where they were copied from though
[20:42] <robru> oSoMoN: in fact I can do that for you now if you want
[20:42] <oSoMoN> 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] <oSoMoN> robru, wait
[20:42] <robru> oSoMoN: I've seen this before but I can't remember which packages it was
[20:43] <robru> 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] <oSoMoN> 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] <robru> ok
[20:43] <dobey> it's just too bad there still isn't arm64 builds :-/
[20:43] <oSoMoN> it’s coming
[20:44] <dobey> eww