[23:28] wgrant: StevenK: hi, so we should look to do a deployment this morning. if you were to get your qa done, we could almost do to the end of the current revision list [23:29] Indeed, just trying to sort out why I can't actually connect to Europe still [23:29] * wgrant tunnels through US [23:30] wgrant: also, i need to do a FDT of 11862 (or 11864 i guess) but fdt is currently blocked according to the LPS page? [23:30] We need to switch back to wild, choke and hack before we can attempt a FDT. [23:31] ok. timeframe for that? [23:31] druk and whatever the other one are precised. [23:31] Right, if we're lucky we *might* be able to fdt tomorrow night [23:31] ok. np. i have about 3 cards in the landing lane that will stay there until then [23:32] Hm [23:32] I think this is actually *faster* [23:32] because I'm tunneling everything through a v6 connection to my US VPS [23:32] Hah [23:33] StevenK: do you know if those bb failures due to the auditor fixture setup are sorted or whatever? [23:33] Someone should convince someone to check pilinut to see if there's any stuff left around [23:34] wallyworld_: It was just one. [23:34] i'm also not sure about the latest db devel failure in test_getAllPermissions_constant_query_count [23:34] i saw 2 i'm sure [23:34] but maybe not [23:34] wallyworld_: btw, not sure if you saw, but I reverted your reversion of db-devel in devel, then reverted the reversion of the reversion in the stable->db-devel merge [23:34] i think one was in devel and one in db devel [23:34] Since you mislanded it [23:35] oh, sorry. what did i do? [23:35] Your initial person merge testfix (reverting the DB patch entirely) landed on devel [23:35] That's why it didn't fix db-devel [23:35] oh bollocks [23:35] That explains why we were all so confused and buildbot didn't auto-kick :) [23:35] thanks for fixing it then [23:36] yeah, that explains it [23:36] so this test_getAllPermissions_constant_query_count failure, do you recall seeing that before? it seems vaguely familiar [23:36] We'll need to be very careful with the next db-stable merge, though [23:36] wallyworld_: I'm still wondering *how* to QA my death to security contact branch ... [23:36] cjwatson added that a couple of weeks ago [23:37] It spuriously failed for a while [23:37] then cjwatson fixed it [23:37] but it's apparently not quite fixed [23:37] yeah, so do we comment out that test? [23:37] How common is it? [23:37] or just leab db devel bb for a bit [23:37] not sure how common [23:37] just see that it's broken now [23:38] i guess since fdt is stalled, we can leave it for him to fix maybe [23:38] StevenK: that's the branch to delete security contacts? [23:39] wallyworld_: It does not delete them from the DB. It drops the code from the model, UI and tests. [23:39] The DB branch can not land until that branch is deployed. [23:39] sure [23:40] so i guess it's a matter of filing some security bugs on qas and managing subscriptions etc - all the stuff that used to touch security contact - and see what breaks [23:41] And non-security private bugs, on both private_bugs=True and False [23:41] And check transitions as well [23:42] do we seem to be getting a lot of "slave lost b b errors lately? [23:42] That's usually ops restarting things [23:57] wgrant: So I have a new project -- security contact isn't in the UI, so that's a plus. I've set private_bugs=True so now I should file a security bug to see that it stays as PRIVATESECURITY and a normal bug to see it gets overridden to USERDATA?