[00:32:02] AaronSchulz: why are you running CentralAuth on sqlite? It's a bit outside of what it was intended for) [00:33:20] I'm not [00:54:59] tgr: Do you know if Logstash's key index is sticky, or would it get better in after 30 days when fixing things related to https://phabricator.wikimedia.org/T189333 ? [00:55:19] like, does it need some kind of command to be run or would it just happen by itself [00:57:55] Krinkle: I'm not sure about searching but IIRC when two different log sources sent different data types with the same name (which causes some subtle breakage) bd808 always had to do some manual cleanup, it wouldn't get fixed auomatically just by not sending one of them anymore [00:58:40] tgr: interesting, so there's something persisting outside the elasticsearch indexes (24h windows afaik?) [00:59:23] that's my recollection (which is unreliable, I never fully understood that issue) [04:54:01] <_joe_> Krinkle: uhm, I'm not sure of some of your results tbh [04:54:09] <_joe_> but well I have the whole day to check [04:57:02] <_joe_> what I mean is that ini_get_all in HHVM seems not to report all the hhvm.* settings which are the relevant ones in most cases [04:58:02] <_joe_> oh no, it does [10:43:53] TimStarling: hey. sorry - went for lunch and forgot the time [10:43:58] are you still around? [12:54:07] I apparently cannot log into my dev wiki atm [12:54:16] It reckons my user account doesn't exist [12:58:27] Reedy: SQLite? [12:58:34] nope, mysql [12:59:15] $ php maintenance/changePassword.php --user=Reedy --password=testpassword [12:59:15] No such user: Reedy [13:00:01] <_joe_> have you checked the db? [13:00:26] For what? :P [13:00:32] <_joe_> Krinkle: I sent you some answers, thanks for that job [13:00:40] <_joe_> Reedy: for the existence of your user [13:00:47] Yes [13:00:56] The wiki has been around for 8 years [13:00:59] Special:ListUsers shows the accounts [13:01:05] <_joe_> ok [13:01:09] :P [13:01:16] Reedy: Did you pull recently without running update.php? Ic483d0fd landed recently. [13:01:22] Ahh [13:01:27] I haven't run update.php recently [13:01:28] * Reedy tries [13:01:46] <_joe_> you know, tables in mysql can get corrupted, moreso if you use myisam or similars [13:02:08] | 1 | Reedy | Sam | :pbkdf2:sha512:30000:64:AFIrTJMz8ZlbtSCkyTYQ4Q==:P0+Kn8KuMrDI0VChe2QoEVBrtIQ7J4Y2wA4PzwlvMTNcluyp6ENeHV4ffyK9ZiZOb/ZKWnjLUolxgWBLYMvBWA== [13:02:48] update.php did quite a bit of stuff [13:03:34] Still similarly broken [13:04:21] * Reedy tests reverting Ic483d0fd [13:04:46] <_joe_> I love your scientific approach at debugging [13:04:48] <_joe_> :P [13:05:06] "Auto-creation of a local account failed: You have not specified a valid username." [13:05:15] <_joe_> I'm sure you took a dump of the db before running update.php [13:05:25] Where's the fun in that? [13:05:33] <_joe_> Reedy: you need to dump the sql query being performed, I guess [13:05:52] <_joe_> mediawiki can do that automatically, I hope [13:06:05] <_joe_> as in, you have some logging channel you can turn on [13:06:18] Yeah, it can [13:06:24] Can even dump them to the web request if you want [13:06:41] I have it turned on ;P [13:07:44] <_joe_> Krinkle: https://gerrit.wikimedia.org/r/c/operations/puppet/+/502986 if you care to take a look [13:09:12] Hmm. Something is definitely more widely broken [13:09:17] anomie: The main page is blank [13:09:53] Reedy: Sanity check that your `actor` table has rows that look sane? [13:10:21] +----------+------------+----------------------------+ [13:10:21] | actor_id | actor_user | actor_name | [13:10:21] +----------+------------+----------------------------+ [13:10:21] | 1 | 1 | Reedy | [13:12:54] That looks sane combined with your user table excerpt from eariler. [13:13:11] Mmm [13:13:36] I wonder if session storage is just borked locally [13:16:48] reboot the host.. Things are fixed [13:16:50] Helpful... [13:17:11] Bad data in memcache maybe? [13:17:44] Seems likely.... I guess if I cached it before the actor update.php was run... [13:18:26] Cheers anyway :) [15:17:47] <_joe_> anomie: when you have time, https://gerrit.wikimedia.org/r/c/mediawiki/core/+/502546 it could help unblock the php7 transition [15:18:10] <_joe_> I tried my best to assess the blast radius of such an override, and it seems pretty limited [16:29:12] are we encouraged to start using return type declarations? (other than nullable types or void that are disallowed in codesniffer) [16:29:12] There is a discussion in the "coding conventions" talk page about spacing but nothing in the Coding Conventions page [16:29:20] except for function parameters [16:29:20] https://www.mediawiki.org/wiki/Manual:Coding_conventions/PHP#Type_declarations_in_function_parameters [16:31:29] dmaza: I don't know if it's encouraged yet or not. We can't type-declare scalars yet, though, only classes. [16:32:53] HHVM as we have it configured will still try to interpret something like "int" as a class by that name instead of the scalar, and since we're dropping HHVM anyway we don't really want to risk breaking other things by trying to change the configuration now. [16:34:33] <_joe_> dmaza: you'll have to wait another 3 months or so :) [16:35:07] <_joe_> then hopefully HHVM will have gone the way of the dodo [16:35:41] <_joe_> I'll comment on that talk page tomorrow if I remember to do it [16:38:20] anomie, _joe_: Sounds good. Thank you [16:39:19] dmaza: I did the bold thing and added it [16:48:46] tgr: I guess it should be fine for Classes or arrays (array type is supported right?) [16:48:46] If eventually this is gonna be encouraged I don't see why not get ahead and start adding it to the new code [16:48:46] I just wanna make sure it is not frown upon [16:48:47] every little helps (as long as it doesn't break on HHVM) :) [16:48:47] for those two types at least [16:48:47] I think some newer Wikidata code is definitely getting it [16:48:47] dmaza: yeah, class names, array and callable should be fine, scalars after we drop HHVM compat, void and iterable after we drop 7.0 compat [16:48:48] and object type hint is stupid and pointless anyway [16:48:48] (that would come with 7.2) [16:48:48] I thnk object is disallow in codesniffer too [16:48:48] iirc [16:48:48] jenkins should tell you no [16:48:48] right now all the ones that we need to drop compat for are disallowed [16:48:49] worth noting that before 7.4 (IIRC) PHP is not very clever about restricting type hints in subclasses [16:48:49] coolio [16:53:04] James_F: fancy merging a couple of vendor patches to pull out some copy pasta libraries from OATHAuth? [16:56:26] Reedy: Yeah, I was wondering if we had a way to annotate in composer.json where each dependency came from. [16:56:47] comments? in json? [16:57:02] Maybe we just put a README or something and require people annotate in it [16:57:24] GLWT. [16:57:43] (filed T220719 task for the spacing issue) [16:57:50] Maybe we should have composer.json be an executable shell script that reads composer.yaml which has comments. ;-) [16:57:55] Haha [16:58:30] Well, it's that... Or we add some sort of structured data file in... and compare it in some sort of simple test [16:58:38] check all the requires are documented [16:58:41] * Reedy files a TODO [16:59:07] T220719: Standardize return type hint spacing - https://phabricator.wikimedia.org/T220719 [16:59:22] James_F: there was some discussion of that in T178137 IIRC [16:59:45] if you have mediawiki/vendor in mind [16:59:56] Yeah. [17:00:37] Of course, in the Magical Future™ we're going to deploy MW in built containers, which means we could construct /vendor automatically as part of the build process. [17:01:01] But for the next little while before that happens (;-)) we should find ways for reality to suck less. [17:01:21] one option I have been playing with is to have an executable instead which is a bunch of composer require commands with comments on why those were added [17:04:26] well, not instead, but alongside [17:04:27] T178137: MediaWiki-Vendor creates a scenario in which incompatible versions of dependencies can be present - https://phabricator.wikimedia.org/T178137 [17:04:27] Right. [17:04:28] T220720 filed for posterity [17:04:28] you can run the file as proof that it matches composer.json; you can delete composer.json and run the file to see if there is anything that can be removed [17:04:28] Why does composer's generated autoload.php have terminal whitespace on lines? Eurgh. [17:04:28] not great but better than the status quo [17:04:28] Yeah, we could add that to the CI job for vendor. [17:05:16] T220720: Document what requires mediawiki-vendor required libraries - https://phabricator.wikimedia.org/T220720 [17:05:22] James_F: Cheers :) [17:17:03] James_F: That patch of Max's is just silly conflicts in MWServices [17:19:07] I think with Tims alpha sorting [17:32:28] Oh, ha. [17:32:28] The problem with CI flakiness is that my first assumption on a CI failure is a flake, not an actual failure, so I just re-run it. [20:37:53] duesen: I don't really like https://www.mediawiki.org/wiki/Wikimedia_Engineering_Architecture_Principles, but more because it's too heavy on principle-buzzwords for me to properly parse than for anything I can usefully point to. [21:12:51] git #bd292da0 - Check line length of HISTORY by James D. Forrester [21:13:10] I see the release note bot uses comitter not author ;P [21:15:55] There's a release notes bot? [21:16:46] Well, the script that does https://www.mediawiki.org/wiki/MediaWiki_1.33/wmf.25#Core_changes :P [21:20:00] Oh, right, that's part of scap isn't it? [21:21:37] The person who seems to have been running isn't :P [21:22:36] https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/tools/release/+/master/make-deploy-notes/make-deploy-notes says it's using `git log --format=medium --cherry-pick --right-only --no-merges` (tsk, no `--topo-order`), which should credit appropriately. [21:26:42] I'm not sure it's that one [21:27:26] The totals on the MW page isn't on there [21:48:18] Hmm. [21:50:52] It's not been that script since https://www.mediawiki.org/wiki/MediaWiki_1.32/wmf.26 [21:51:03] starting with 1.33 a volunteer is doing them, don't know with what [21:51:35] nope, Im wrong. [21:51:46] that page is not where it is hosted, it's another page [21:51:53] https://www.mediawiki.org/wiki/MediaWiki_1.33/wmf.2/Changelog [21:52:05] And those used to be edited by an IP, and now by Tyler. so heah, maybe a scap plugin. [21:52:25] But it's RoanKattouw's fault for https://www.mediawiki.org/w/index.php?title=MediaWiki_1.33/wmf.25/Changelog&action=history [21:52:49] I was impatient, sorry [21:52:53] The important thing is that we all blame Roan. [21:53:07] RoanKattouw: Did you run an old version of the script? [21:53:11] https://github.com/wikimedia/mediawiki-tools-release/blob/805fc873387f28239ed38ecd6240e172f6511e9e/make-deploy-notes/makedeploynotes.py [21:53:16] It's in the same repo still [21:53:18] but a py file now [21:53:33] the tell tale is the " by " word joining them [21:53:42] This is the new version as of 1.33 [21:53:44] Oh. [21:53:57] And yes, that's pulling committer not author. [21:53:59] before that, no names were included at all. [21:54:00] Yes I ran that [21:54:01] yeah [21:54:12] And it's pulling committer not author which is very annoiying [21:54:15] Chad's code, apparently. [21:55:26] There's also a PHP script in the same repo that wraps this .py script and uses the MW API to publish the results on mw.org, but I couldn't easily get that working so I just copypasted the output of the .py script onto the wiki [21:55:43] (I didn't try very hard) [21:56:12] uploadChangelog.php [21:56:34] The old php script used git CLI on a local clone. [21:56:39] This uses the Gitiles API instead. [22:02:21] James_F: I think I ran the latest version but I'm not certain [22:02:22] The committer not author issue is not unique to my upload, it's been bothering me for months [22:02:23] Yeah, it's just how Gitiles JSON api formats it by default [22:02:23] but it does have an 'author' field as well. [22:02:23] https://gist.github.com/Krinkle/b62bc6f7eddd6f172d38ed5d50c1542a from https://gerrit.wikimedia.org/g/mediawiki/core/+log/wmf/1.33.0-wmf.17..wmf/1.33.0-wmf.18?format=JSON&no-merges [22:02:24] https://gerrit.wikimedia.org/r/#/c/mediawiki/tools/release/+/503126 but untested.