[02:23:35] legoktm: does MutableRevisionRecordTest::testSetGetPageId pass for you? It fails on master for me. [03:19:46] AaronSchulz: let me see... [03:20:16] I get << Failed asserting that 2 is identical to 0. >. [03:21:15] that's the same error that is failing on travis I think [03:23:18] AaronSchulz: not failing locally for me, but I'm also running PHP 7.3rc3 [03:24:08] 7.2 for me [03:26:47] hm, 7.2 didn't make a difference for me locally [03:26:58] in any case, I'm pretty sure there is a legit failure [03:27:14] but my environment is more like jenkins, which is probably why it's not failing there either [03:36:24] probably leakage [03:39:59] James_F: https://www.mediawiki.org/w/index.php?title=Deprecation_policy&diff=prev&oldid=2931858 does that help? [03:40:21] legoktm: Yup, thanks. [03:40:44] (I thanked you for it earlier.) [03:55:32] legoktm: AaronSchulz that failure is the usual error that fails on installs where sitename/dbname != "Mywiki", which is most local developers and Travis. [03:55:37] But not Jenkins [03:55:50] Might be time to just change that on Jenkins [03:55:55] So it's at least the same [03:56:25] should we change it to something like "jenkinswiki"? [04:55:44] musikanimal: fair enough, I suspected that was the case - thank you. [04:59:21] yup [05:00:45] There is no indicator that it's an autoblock or cookie block from what's been pasted in unblock requests fwiw - but the ip's not matching is a pretty obvious tell now that I've seen a few. [05:01:22] yes I was going to say that. The "you're blocked" message could be improved in this situation [05:01:43] There's a balance to be reached, like you probably saw in the comment I linked [05:01:46] beans and all that [05:01:46] we wouldn't want to mention cookies, of course, but it probably shouldn't say you're in a completely different IP range [16:47:55] AaronSchulz: sorry for still looking at you, but any new ideas on the excessive lock wait timeout issue? https://phabricator.wikimedia.org/T207881 [16:48:37] greg-g: we could try a backport [16:49:25] ohsi, I didn't notice that somehow [17:18:09] greg-g: is that the only blocker left? [17:32:04] greg-g: and should https://phabricator.wikimedia.org/T207876 be untagged? [17:32:30] Reedy: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CentralAuth/+/468789 isn't merged but was backported to wmf.26 but "hasn't helped"; should I merge? Backport to wmf.1? [17:32:51] though Timo said the regressing patch is recent one [17:33:34] * AaronSchulz will just deploy that backport too [17:33:54] Yes, my objection there is disrupting the train pointlessly, not that it shouldn't be backported and fixed. [17:34:12] "Backport-worthy" < "OMG TRAIN BLOCKER" [23:29:57] UBN bug fix https://gerrit.wikimedia.org/r/c/mediawiki/core/+/469798 [23:31:23] anyone available to review it? [23:34:35] * AaronSchulz was beated to it [23:35:11] Sorry, AaronSchulz. [23:35:22] heh [23:37:12] it was a race between James_F and MaxSem in the end [23:37:40] I sat on it for a couple of minutes thinking to wait for CI, but decided against. [23:37:42] they both gave +2 in the same second according to gerrit, 4:33:50 [23:37:52] Ha, indeed. [23:38:15] But Max is listed first, so presumably it has sub-second timing it's not showing. [23:39:23] WMF engineering is very competitive! [23:39:30] now we just wait for jenkins for an hour [23:39:55] TimStarling: wmf.1's tests will run faster. [23:40:05] ok, that's good [23:40:23] Whee [23:40:24] Zuul expects it to land in ~7 minutes' time. [23:41:30] so someone will deploy it for me? you know I am in portland and I am being antisocial right now [23:41:41] TimStarling: I'll get it deployed. [23:41:47] thanks [23:41:50] Or MaxSem will, given he's got the conch. [23:41:59] MaxSem: Sorry for volunteering you.