[03:34] <slangasek> robru: looks like it was just the two orphaned binaries in vivid-proposed, the britney output looks sane now
[03:35] <robru> slangasek: oh good
[03:35] <robru> Thanks
[03:38] <robru> slangasek: https://requests.ci-train.staging.ubuntu.com/static/britney/vivid/landing-005/excuses.html ah i think this is what i meant by deps missing from staging overlay
[03:41] <robru> slangasek: is this a problem that's likely to happen a lot? Might be worth making britney more resilient against dangling binaries
[03:46] <infinity> robru: The whole point of britney is to make sure deps are satisfiable and packages can be installed...
[03:46] <infinity> robru: Being "resilient" against that means not running it.
[03:47] <robru> infinity: I'm referring to an unhandled traceback when packages are indirectly deleted from -proposed
[03:47] <infinity> Oh.
[03:47] <infinity> I missed that context.
[03:47] <infinity> And what do you mean by indirectly deleted?
[03:47] <robru> infinity: probably britney should report that situation meaningfully
[03:48] <robru> infinity: we discovered two cases where armf had a binary but no associated source
[03:48] <infinity> NBS packages, then.
[03:48] <robru> Oops phone, should have been incorrectly deleted
[03:48] <infinity> Though, NBS doesn't cause tracebacks in the primary archive.
[03:49] <infinity> Causes issues, but not tracebacks.
[03:52] <robru> infinity: the main britney considers proposed as the input, on the train, proposed is the destination, so it's likely handled deferently
[03:52] <robru> Differently
[05:11] <slangasek> infinity: these were dangling binary packages in vivid-proposed after the source had been removed (dangling because the package was FTBFS on the arch in question, so the binary version didn't match the source).  Apparently there were a total of two such binary packages in vivid-proposed that date back to before the release
[05:11] <slangasek> robru: so, deps missing from the staging overlay.  why are you not testing against the real overlay instead?
[05:12] <slangasek> I don't see any reason to test against a staging overlay that's empty
[05:13] <slangasek> infinity: and I don't know why they're causing britney tracebacks in the train, but one relevant difference between the archive's p-m and what robru is setting up for silos is that for silos, -proposed is part of testing, not unstable
[05:13] <robru> slangasek: because the decision of what ppa owner team to use happens once, globally. The overlay PPA uses the configured team rather than hard-coding the blessed overlay. that was so that I could test publications and it'd actually work
[05:13] <infinity> slangasek: Yeah, but we have NBS in the release pocket all the time too, so I dunno.
[05:14] <slangasek> robru: ok.  given that this is basically a spot test during development, I think it's fine anyway
[05:16] <robru> slangasek: yeah, we'll find all the issues in the first production iteration since that won't block publications anyway ;-)
[05:17] <robru> slangasek: so I have the db schema done, all I need to do is poke the link to the excuses page(s) into the ticket, I'm thinking we can go live monday
[05:18] <robru> which is probably better than a friday rollout anyway
[05:22] <slangasek> most likely ;)
[05:27] <robru> slangasek: actually, I just realized that charm changes mean this'll be a bigger rollout than simply pulling trunk into the instance
[05:27] <robru> slangasek: I should file an RT so we can schedule this with IS
[05:27] <robru> slangasek: if I give you an RT can you set the priority/deadline?
[05:28] <robru> slangasek: we need to tear down the unit and redeploy with 50GB root disk just like we did for jenkins
[05:32] <robru> slangasek: https://rt.admin.canonical.com/Ticket/Display.html?id=87235 please deadline for tuesday EOD