[00:42:51] https://ci.debian.net/data/autopkgtest/unstable/amd64/m/mediawiki/1146898/log.gz lots of notices/warnings from PHP 7.3 so far :o [02:07:36] > PHP Notice: compact(): Undefined variable: messages in [02:08:03] Ah, > [02:08:07] > Before PHP 7.3, any strings that are not set will silently be skipped. [02:08:14] http://php.net/manual/en/function.compact.php [02:08:50] So you can't try to capture whatever and see if it's there or not. [02:09:06] That's fair, but means we should probably refactor these to be array-returning instead of variable-exposing [08:03:09] legoktm: less.php looks abandoned :| [08:08:24] :sad_trombone: And its tests emit warning even on 7.2 :P [14:42:02] MaxSem: sigh...my trivial PR from over 2 years ago is still open [14:45:19] I just got a newline addition from 9 months ago merged :) [14:45:43] (to MW core) [16:24:53] anomie: duesen_ : Has any MCR config or rollout change happened recently? [16:25:11] Notice a sudden flux of fatal exceptions "Uninitialized field: content_address" starting earlier today [16:28:13] Krinkle: Yes, we enabled read-new mode on Commons. [16:29:54] anomie: https://phabricator.wikimedia.org/T207054 [16:35:45] anomie: Lookslike something might be wrong with a specific set of servers. [16:35:58] It's causing other fall out as well. Something is broken somehow. [16:36:06] * Krinkle updates task [16:45:21] Ugh. Callbacks. Let's see if I can dig up an actual reproduction, since T207054 is just "this happens". [16:45:21] T207054: Some Commons pages fatal with IncompleteRevisionException: "Uninitialized field: content_address" - https://phabricator.wikimedia.org/T207054 [17:29:01] anomie: I recommend we depool the server as first measure. [17:29:02] Thoughts? [17:29:11] Updated hte task with another highly frequent error from the same code path. [17:29:19] Krinkle: Which server? [17:29:28] mw1331 [17:29:30] see task [17:29:46] I've been messing with that one to try to get a better backtrace. Done with that for the moment though. [17:32:19] Ah, k. a !log may've helped there, but fine I suppose. Thanks for checking. [17:32:47] Sorry about that. [17:35:17] anomie: the original spike did involve the same server, do you have reason to believe there might be somethign off on that server? [17:35:59] It's only on mw1331 and mw1312. Not sure why. [18:09:49] Krinkle: It looks like the scap sync-file this morning for InitialiseSettings.php somehow or other wasn't picked up on mw1331. Details in T207054#4667886. [18:09:50] T207054: Some Commons pages fatal with IncompleteRevisionException: "Uninitialized field: content_address" - https://phabricator.wikimedia.org/T207054 [18:30:38] legoktm: forking [18:33:58] speaking of which, who has permissions to fork it into the Wikimedia org? [18:34:52] MaxSem: It's pretty trivial, but ideally we'd want to transfer rather than fork if at all possible. [18:35:40] For the reference, the maintainer hasn't been responding in year and a half [18:36:18] https://github.com/oyejorge/less.php ? [18:36:34] Yes [18:36:42] MaxSem: https://github.com/wikimedia/less.php done. [18:36:47] <3 [18:52:24] and it works wonderfully on HHVM, too: https://travis-ci.com/wikimedia/less.php/jobs/151904536 [19:01:07] MaxSem: "rotate(-0deg);" is special. [19:50:56] I guess we could use manifest_version 2 in here https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/Lockdown/+/REL1_31/extension.json now that it requires MW 1.31+ ? [19:51:25] No point backporting that sort of thing [19:51:40] Doesn't look to be any obvious beenfit from upgrading that extension either [19:53:16] I just picked REL1_31 but it's the same at master [19:54:05] so I wonder that if that extension now requires MW 1.31+ to work, and manifest version 2 requires MW 1.29+... [19:54:20] just asking [19:54:38] Like I say, yes you can [19:54:43] But there's no benefit from doing so [19:54:49] So it might be work for the sake of it :) [19:55:16] well, the minimal benefit is stricter validation [19:55:59] I'll take this as "don't bother" :) [20:00:04] With regards to that extension, I am also wondering https://phabricator.wikimedia.org/T206806#4661080 [20:00:24] it seems that no Lockdown.php file was left, so it might be broken for some sites? [20:00:50] It's helpful [20:00:54] I was thinking on adding the standard PHP entry point [20:00:55] But people ignore deprecated warnings [20:01:00] So they might not notice anyway [20:01:05] Shit been broken means it'll get fixed [20:01:21] The readme being out of date is hte bigger issue [20:01:28] watch your mouth :P xD [20:01:55] I made some tweaks to the README [20:01:59] minor stuff [20:02:11] I currently lack time to look deeper at the issue [20:02:14] (s) [20:52:31] greg-g: I'd imagine smaller trains would have helped with regards to https://phabricator.wikimedia.org/T205369 (I suspect it is mostly https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/451025/) [20:54:07] AaronSchulz: +1, we (releng) really want to start pushing the train more often. Getting there is going to be hard but I think the payoff is worth it. [20:54:32] aye :) [20:55:18] greg-g: is there a ticket/writeup? [20:56:02] Is it too late to get https://gerrit.wikimedia.org/r/c/mediawiki/core/+/465675 (bunch of API deprecation removals) into 1.32? If not, anyone want to merge it? [20:58:55] oh, I didn't grep [20:59:09] anomie: not too late, if it misses tomorrow's (I think) branch cut, we can backport it [21:05:26] anomie: Sorry for finding usages. Gods know what to do about the ZeroPortal one. [21:05:36] legoktm: https://codesearch.wmflabs.org/deployed/?q=is_callable&i=nope&files=&repos= is a fun hit-list. :-( [21:05:46] rm -rf ZeroPortal [21:05:47] James_F: Since Zero is gone, can we just undeploy it? [21:05:54] it's not dead yet :( [21:05:56] anomie: It's not gone until January. [21:06:02] anomie: So… no. [21:06:07] I thought it went away this past January... [21:06:14] Nope. January 2019. [21:06:27] no new contracts, but there are existing ones that have yet o expire [21:06:31] *to [21:06:31] Indeed. [21:12:28] MaxSem: not explicitly, no [21:14:25] afterwards, ZeroPortal might have to stay up for a few more months to allow the (former) partners to retrieve their data, but I've heard it's broken already [21:17:29] what data? [21:17:45] usage stats, etc [21:17:58] I wonder if they really care [21:18:11] It's not like we're gonna turn around and be like, "hey, this is really popular. let's do it again" [21:18:38] never say never Reedy ;) [21:19:04] Maybe we'll need WP Zero in the UK after brexit [21:19:40] Nah, the Tories, will just make you request every web page in writing [22:16:42] anomie: https://gerrit.wikimedia.org/r/q/topic:%2522kill-bc%2522+status:open drops the rest of the back-compat. [22:17:43] legoktm: PHPUnit 6 seems to run fine on PHP 7.3 right? [22:17:51] I think I mistook PHP 7.3 for PHPUnit 7.3 [22:18:11] I'll have an answer for you in 15 minutes [22:18:14] k [22:18:54] Because keeping HHVM, PHPUnit 4, 6, 7 and PHP 7.0 - 7.3 is gonna be impossible or a big time leecher. [22:19:27] We'll kill two of those pretty soon. [22:19:35] Yeah, but not in 1.31 [22:19:51] Yes, LTS "support" strikes again. [22:20:24] possibly before 1.32 finalizes, but maybe not before the first 1.32.0 release, but we can still remove "hhvm support" officially from 1.32 and just keep it internal until WMF switch is complete [22:20:33] Given 1.33-wmf.1 is coming soon already [22:21:08] well before HHVM is gone, but between REL1_32 branching and releasing, we might finalise it just. Unsure. [22:21:48] The current release notes for 1.32 claim we support HHVM, which… isn't true. [22:22:48] btw, regarding less.php, there's good news and bad news. [22:23:26] The good news is, there's already a PR for it upstream - https://github.com/oyejorge/less.php/pull/367, and the maintainer still works for the company that needed less.php in the first place. [22:24:03] The bad news is, it seems the maintainer and Typesetter CMS now use the Leafo version of less.php and scssphp. [22:24:11] Which is the version we moved away from to use oyejorge's instead. [22:24:28] back to leafo? [22:24:37] e..g https://github.com/Typesetter/Typesetter/commit/14b0911e4c056d [22:24:38] Yeah [22:25:05] should we move back too? :p [22:26:17] Hm.. no, they've adopted Leafo for scssphp only. And that one Leafo actively maintains. [22:26:28] But leafo's less.php is still dead (since 2014) as before. [22:26:37] Krinkle: PHPUnit 6.x seems fine on PHP 7.3 [22:26:43] https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-php73-docker/1/console [22:26:46] I'll try to ping oye/typesetter to see if they can fast-track this patch [22:26:57] legoktm: cool, let's hope that will stay for now. [22:33:11] legoktm: I might just rm -rf Leafo/less.php and replace with oyejorge's and then merge these kinds of outstanding PRs (with back-compat bridge, which already exists mostly). [22:33:22] If I recall correctly, they gave Ori and myself write access. [22:33:29] :ooo [22:33:35] before we abandoned Leafo [22:33:53] But I'll give them a chance to priorise the PR first :) [22:44:31] https://phabricator.wikimedia.org/T207100 looks pretty fun [22:44:46] to my eye both "i"s look identical but apparently they're not [22:45:05] that looks like they are different i [22:45:08] when i zoom in [22:57:44] Krinkle https://github.com/leafo/lessphp/pull/626 can be closed [22:59:06] oh that may fix php 7.1 [23:15:23] paladox: Yeah, but our tests are fine on PHP 7.1 [23:15:32] It's not currently an issue for us. [23:15:39] (also we don't use that library currently) [23:24:38] Ok