[03:34] robru: looks like it was just the two orphaned binaries in vivid-proposed, the britney output looks sane now [03:35] slangasek: oh good [03:35] Thanks [03:38] 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] slangasek: is this a problem that's likely to happen a lot? Might be worth making britney more resilient against dangling binaries [03:46] robru: The whole point of britney is to make sure deps are satisfiable and packages can be installed... [03:46] robru: Being "resilient" against that means not running it. [03:47] infinity: I'm referring to an unhandled traceback when packages are indirectly deleted from -proposed [03:47] Oh. [03:47] I missed that context. [03:47] And what do you mean by indirectly deleted? [03:47] infinity: probably britney should report that situation meaningfully [03:48] infinity: we discovered two cases where armf had a binary but no associated source [03:48] NBS packages, then. [03:48] Oops phone, should have been incorrectly deleted [03:48] Though, NBS doesn't cause tracebacks in the primary archive. [03:49] Causes issues, but not tracebacks. [03:52] infinity: the main britney considers proposed as the input, on the train, proposed is the destination, so it's likely handled deferently [03:52] Differently [05:11] 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] robru: so, deps missing from the staging overlay. why are you not testing against the real overlay instead? [05:12] I don't see any reason to test against a staging overlay that's empty [05:13] 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] 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] slangasek: Yeah, but we have NBS in the release pocket all the time too, so I dunno. [05:14] robru: ok. given that this is basically a spot test during development, I think it's fine anyway [05:16] slangasek: yeah, we'll find all the issues in the first production iteration since that won't block publications anyway ;-) [05:17] 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] which is probably better than a friday rollout anyway [05:22] most likely ;) [05:27] slangasek: actually, I just realized that charm changes mean this'll be a bigger rollout than simply pulling trunk into the instance [05:27] slangasek: I should file an RT so we can schedule this with IS [05:27] slangasek: if I give you an RT can you set the priority/deadline? [05:28] slangasek: we need to tear down the unit and redeploy with 50GB root disk just like we did for jenkins [05:32] slangasek: https://rt.admin.canonical.com/Ticket/Display.html?id=87235 please deadline for tuesday EOD === fabo_ is now known as fabo === henrix_ is now known as henrix === sgclark_sleeping is now known as sgclark === psivaa_ is now known as psivaa === rsalveti_ is now known as rsalveti === FourDollars_ is now known as FourDollars === tgm4883_ is now known as tgm4883 === fginther` is now known as fginther === Chipaca` is now known as Chipaca === \b is now known as benonsfotware === benonsfotware is now known as benonsoftware