[00:01:26] Yeah. That's not ideal. [00:01:45] I appreciate we need to do *some* string chopping, but… [00:10:51] -'MobileFrontend\Devices\viceDetector' [00:10:51] +'MobileFrontend\Devices\AMFDeviceDetector' [00:11:00] Actually ends up with a load of test failures locally for some reason... [00:12:08] * Reedy files a task [00:15:20] Reedy: Off-by-five error?! [00:15:49] lol [00:16:27] Might be an off-by-one error plus an encoding error (\\\\ -> \ x2), of course. [00:16:51] Code is Hard® [00:17:05] // Check that the expected class name (based on the filename) is the [00:17:05] // same as the one we found. [00:17:05] // Strip directory prefix from front of filename, and .php extension [00:17:05] $abbrFileName = substr( substr( $file, strlen( $dir ) ), 0, -4 ); [00:17:05] $expectedClassName = $prefix . str_replace( '/', '\\', $abbrFileName ); [00:22:55] It's a bit odd that it's substituting /s after it's removed the directory from the path… in what cases does one have files with /s in their names? [00:31:23] TimStarling: CC-ed you on https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/460613/ [00:43:46] legoktm: Does PSR-4 autoloading pick up class_alias()? [00:50:28] Ok, no [00:50:29] I'm confused [00:50:41] Manually add them... test fails [00:50:48] Remove them, depedancies fail [00:56:56] class_alias have to be listed in the autoloader explicitly, and have to be in the same file as the target class. [00:57:10] haven't checked if you're doing that alreay. [00:58:57] Yeah, it's in the same file [00:59:14] When we have them in autoloadclasses... We get the fails like on https://integration.wikimedia.org/ci/job/wmf-quibble-vendor-mysql-hhvm-docker/7577/console [00:59:25] Remove them... [00:59:43] (from autoload classes) [00:59:47] Usages of them in other extensions then fail [00:59:59] I can't see any examples in MW extensions where they use PSR-4 autoloading with class_alias [01:00:14] Krinkle: https://phabricator.wikimedia.org/T206728 puts it all in one place [01:01:30] https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Echo/+/465562/36/includes/AttributeManager.php [01:04:57] Reedy: I see PS36 (latest) specifying DiscussionParser as namespaced, but not the global class name. PS35 before that specifies DiscussionParseras global class in the original place, but with the file not under the PSR-4 directory, right? [01:05:17] Presumably it would work if PSR-4 classes are under includes/Notifications, and aliases outside that [01:05:39] or even directly in includes should work I guess. [01:06:12] Afaik the only thing we don't support is an alias within a namespace, because the prefix would match the PSR-4 autoload first and those look for the wrong file. But afaik that's not the case here, right? [01:09:47] "specifying DiscussionParser as namespaced" [01:09:49] ? [01:09:57] It's not in extension.json in either patch set [01:10:04] It's expected PSR-4 would load it [01:13:33] Not sure what is the right answer.... Like I say, we don't seem to have any extensions examples of actually doing this [01:14:30] in core... [01:14:46] We have class_alias entries shoved into $wgAutoloadLocalClasses [01:15:19] But they're not PSR-4'd [01:15:26] Reedy: includes/Storage has both PSR-4 and class_alias iirc [01:15:36] (or at least, LoadBalancer and friends isn't) [01:15:42] Yes. I'd expect the outcome to be: PSR4 dir[ 'MediaWiki\Notifications' ] = ...; and autoloadclasses[old names] = [new class file] [01:15:54] legoktm: No class_alias in Storage [01:16:33] includes/Revision/ [01:16:39] It seems to work right with the aliases defined in autoloadclasses, just the structure test that says no [01:17:19] Yeah, it's there in revision... Both are namespaced (not that that should really make a difference) [01:19:17] Hm.. well, we can look at the structure test again to see if something needs to be fixed, but it'll be in that area. They definitlely need to be in autlloadclasses [01:21:08] And if it was being double loaded.. We'd presumably get some sort of error saying it's already declared etc [01:21:16] Which points more towards the structure test [01:22:39] $this->assertArrayHasKey( $alias, $otherClasses, [01:22:39] 'Alias must be in the classmap autoloader' [01:22:39] ); [01:27:58] https://phabricator.wikimedia.org/T206728 was filed anyway :P [01:28:07] I need to get some sleep soon, so not gonna be poking around it much further [01:40:40] Definitely one of those that would've bitten us eventually [02:10:09] legoktm: if you're still around, https://gerrit.wikimedia.org/r/c/mediawiki/php/luasandbox/+/465837 [02:10:13] otherwise I will self-merge it [02:10:46] +2'd [02:10:50] thanks [02:13:56] anomie: due: https://phabricator.wikimedia.org/T206732 - might be relevant to something recent. Seeing ActorMigration and Wikibase in the stack trace. Might be beta-specific, or something that could break in wmf.26. [02:14:06] * Krinkle away Away [02:14:53] TimStarling: does PECL have a way to upload signed tarballs? [02:15:30] I don't think so [02:17:48] test failure [02:18:02] is it the timer one? [02:18:08] yes [02:18:26] that one is flakey rarely [02:21:35] hmm, so it requires the CPU time to be accurate to within 0.1s? [02:23:33] unfortunately the console output does not tell us how far off it was [02:30:08] whoops, is incorrectly formatted [02:30:18] PHP Notice: Undefined index: release in /usr/share/php/PEAR/PackageFile/Generator/v2.php on line 372 [02:30:41] that validator checks the most stupid things, like whether every single tag is in the "correct" order, but misses this [02:32:31] >.< [02:33:24] https://gerrit.wikimedia.org/r/c/mediawiki/php/luasandbox/+/465921 [02:37:47] aaand a test failure [02:43:32] I wonder if there is a tool that will fuzz the time taken by syscalls [04:54:38] TimStarling: https://integration.wikimedia.org/ci/job/php-compile-php72-docker/138/ jenkins will now keep the failure logs (if any) [13:23:45] legoktm: Does that mean T205453 is resolved now, or is it only for php-compile-php72-docker and not the other jobs yet? [13:23:47] T205453: Capture failure logs from php-compile jobs (at least for luasandbox) - https://phabricator.wikimedia.org/T205453 [15:26:47] anomie: I fixed it for all PHP versions [15:30:25] legoktm: Great, thanks. Do you want to close the bug with details? [15:30:44] I did :) [15:30:50] thanks [15:53:06] James_F: for jshint and jscs not being upgraded, https://gerrit.wikimedia.org/r/466672 will fix it in the future [15:53:37] legoktm: Fun. [15:54:10] it's frustrating that there's no command that will tell you exactly what "npm audit fix" will do, you have to parse it out yourself [15:54:20] Yeah. [15:54:37] I mean, `npm audit fix --force` will do the full set, but we don't want that. :-) [15:58:17] https://gerrit.wikimedia.org/r/c/mediawiki/skins/apex/+/466647 is also weird, because the "debug" vuln is fixed, but I'm not sure why [15:58:34] oh you commented [16:05:04] ok, before we can commit package-lock.json, we need to switch CI over to npm6 [16:05:37] PHP 7.1 this week, npm6 the next... [16:41:08] legoktm: :-D [17:16:41] legoktm question... you know the jenkins bot that does code coverage (which I really like btw)? what if code coverage of *new* files were added? right now if you add a new file, it's totally fine if it remains at zero. [17:52:57] legoktm: Should I just abandon "wrong" libraryupgrader npm commits, then? Or will it be able to re-use the Change-Id and push new patchsets? [18:05:32] davidwbarratt: can you file a task in the phpunit-patch-coverage project with more details/examples? [18:06:07] James_F: hmm, I need to write logic for it to re-use change ids, so I guess this is a good time to do so [18:09:10] legoktm: Focus on PHP 7.1 first, we can do nice-to-haves later. [18:10:56] legoktm sure! [20:03:13] SMalyshev: could you take a look at https://gerrit.wikimedia.org/r/384050 ? it would be nice to get JSON-LD into MW 1.32 [20:19:41] cscott: sure, will do [20:27:21] SMalyshev: thanks! [21:03:04] Rofl [21:03:07] This one is great [21:03:07] https://integration.wikimedia.org/ci/job/mediawiki-quibble-composertest-php70-docker/7749/console [21:03:14] LocalSettings.php fails PHPCS in 1.27 [21:04:04] nice [21:04:37] i'm just it would segfault if it had a look at the 10-yr-old hacked-upon LocalSettings.php in my dev install [21:04:53] (metaphorically. maybe not literally) [21:06:09] Just attached localsettings from CI [21:06:11] https://phabricator.wikimedia.org/T206805 [21:11:06] https://gerrit.wikimedia.org/r/466782 [21:11:09] ^ easy fix is easy [21:12:59] Ta Krinkle [21:14:45] Anyone got PHP 5.5 laying around? [21:19:15] tools! [21:19:24] Whats the reward for the would-be public embarrassment if I say yes? [21:19:44] heh [21:19:49] I'm sure you won't be the only one [21:21:28] Hehe, I checked, and the place where I thought I had it I don't anymore. It used to be that my main apache dev localhost (for non-mediawiki) was php 5.5 from macOS (which it ships for some reason), but looks like that became php 7.1.66 in latest macOS. [21:21:48] .66? :P [21:21:54] 7.1.19 on mine [21:21:54] 7.1.16 [21:22:07] I've got 7.1.22 in /usr/local from Homebrew [21:22:14] 7.1.16 on /usr/bin from the sytem [21:22:55] Maybe that tells you indirectly which macOS version I'm running [21:23:04] 10.13.6 (17G65) [21:23:25] I'm on 10.14 [21:26:12] Ugh. Why is composer on php 5.5.9 creating autoload_static which isn't valid [21:26:17] It's also 7.1.19 on 10.14.1b3, FWIW. [21:31:25] Reedy: that file should be ignored from linting [21:31:52] legoktm: It is now. Apparently we only added that ignore in 1.29. [21:32:11] heh [21:32:20] Are we still ignoring it? [21:32:33] Cause when we bumped to PHP7... we should be able to lint it [21:34:39] it creates it but won't execute it. [21:34:49] but yeah, our linters need to exclude it there. [21:34:53] or gitignore? [21:35:05] you can't gitignore it because then it'll break on 5.6+ users [21:35:18] Does phpcs know to skip gitignore'ed files? [21:35:25] I know eslint does, but… [21:35:46] no [21:35:51] but phpcs shouldn't look into /vendor [21:36:15] .phpcs.xml takes care of not looking there right? [21:36:19] LocalSettings.php isn't in /vendor though? [21:36:47] It's directly in CI's /src checkout. [21:36:55] I don't think it's in /vendor James_F [21:37:06] I've mentioned two differnt things [21:37:10] LS and autoload_static [21:37:27] Oh, sorry, yes, autoload's in /vendor. :-) [21:42:23] ! [remote rejected] HEAD -> refs/publish/master/REL1_27 (implicit merges detected) [21:42:24] :/ [21:43:13] no merge for you [21:43:47] Tut, rebase. [21:44:26] Doesn't fix it [21:44:40] remote: ERROR: Implicit Merge of f049e1a Bump wikimedia/ip-set to 1.1.0 [21:44:41] remote: ERROR: Implicit Merge of 77b6619 Add .htaccess to disallow web access [21:45:15] Give yourself super-duper implicit merge authority enough to push it up and we can take a peek? [21:45:32] Hmm. [21:46:08] push merge commit? [21:46:20] Yeah. [21:46:37] Oh, in /vendor? [21:46:41] I can't change the perms in /vendor [21:48:45] `git log --decorate` definitely shows the penultimate patch as origin/master? [21:49:07] origin/REL1_27 [21:49:23] Oh, yes. [21:50:45] 77b6619a84 origin/REL1_27? [21:50:54] yup [21:51:04] And you're doing `git review REL1_27`? [21:51:06] no [21:51:14] OH [21:51:15] ffs [21:51:19] :-) [21:51:19] defaultbranch=master [21:51:25] I get caught out by that all the time. [21:51:48] Why is .gitreview not fixed in vendor? [21:51:50] It's "easier" for git review to be totally useless, apparently. Not sure for *whom* it's easier, though. [21:52:41] there we go [21:52:50] added a commit to add track=1 to REL1_27 [21:53:02] REL1_30 et al already have it [21:55:02] And CI is trying to run composer test [22:02:29] "scripts": { [22:02:30] "test": "" [22:02:30] } [22:02:31] HAAAACK [22:09:20] gate and submit is a bit backed up [22:10:14] libraryupgrader's patches [22:10:43] Nope [22:10:45] https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/465515/ is holding it up [22:11:12] right [22:11:22] I'm not sure why they're all glued together [22:11:36] it merges them as a sort of FIFO queue I think [22:11:37] isn't it better that they merge as soon as the tests pass? [22:12:17] yay, merging [22:23:07] James_F: Seemed easier than trying to add php-parallel-lint and trying to make it pass and stuff :P [22:23:20] Reedy: Yeah, I just loathe track=1. ;-) [22:23:30] It's in other branches, soooo [22:23:41] I blame Chad. [22:23:57] heh [22:24:01] Explicitness in git commands is good. Automagic is not. [22:24:22] Especially for things that *should* be scary, like back-porting patches. [22:25:01] gerrit cherry pick ftw [22:29:16] you will soon be able to cherry pick changes even with merge conflicts :) [22:29:31] force all the things [22:30:19] oh it was merged [22:30:25] https://gerrit-review.googlesource.com/c/gerrit/+/198610 [22:30:58] Reedy: for https://gerrit.wikimedia.org/r/#/c/operations/mediawiki-config/+/466778/ do I need to run https://github.com/wikimedia/mediawiki-extensions-ShortUrl/blob/master/populateShortUrlTable.php in addition to populateExtensionTables? [22:31:34] s/populate/createExtensionTables.php [22:31:42] You don't have to [22:31:43] But you can [22:32:00] It'll just be done on demand... Presumably on page views [22:32:29] DB write on read?! [22:32:41] That sounds like a "no". [22:33:29] Yup [22:33:31] Looks like we do [22:33:41] addToolboxLink calls encodeTitle [22:33:59] Which does an select, if no results, do a write [22:34:16] very nice, high five [22:34:18] so we can alleviate the db a bit by populating the current pages [22:34:41] or maybe we can just leave MediaWiki to take care of that [22:34:49] It's not like gomwiki has a huge level of reader traffic. But… ick. [22:34:58] * Hauskatze looks James_F worried face [22:35:26] it never gave problems in the past [22:35:32] "Yet". [22:35:36] indeed [22:35:38] Doesn't make it right [22:35:54] First rule of MW is don't write to the DBs on GETs. [22:36:05] It should add them on page edit/creation [22:36:13] With the expectation the script is run at time of enabling [22:36:19] Yeah. [22:36:27] Reedy: probably at edit/creation is better [22:36:35] Possibly even purge? [22:36:44] when a page is deleted? [22:36:48] action=purge [22:37:12] Should act on a page action, yes. [22:37:30] I think we've found a good Manifest Task for ShortUrl :) [22:38:00] there's already a bug filed for it [22:38:12] https://phabricator.wikimedia.org/T122708 [22:38:20] oh well [22:38:54] this is the first I heard of short URLs in the sidebar [22:39:01] Dec. 31, 2015 [22:39:23] * James_F upgrades 'should' to 'must'. [22:39:50] UrlShortener doesn't do that, does it? [22:39:55] the plan is to replace ShortUrl with UrlShortener but that's blocked on me :| [22:39:57] no [22:40:02] Good. [22:40:16] UrlShortener does an ajax post request to get the shortened URL for the sidebar [22:40:49] on demand I assume? [22:40:54] yes [22:41:08] you click "Get shortened URL" and then it generates it for you [22:41:19] I think we have that on Beta right? [22:42:15] Krinkle: should I go ahead and run a script for https://phabricator.wikimedia.org/T206485#4659454 or did you want to have it discussed by the FSG first? [22:42:36] Okay so for future ShortUrl activation requests, maybe we should not do it or do it only for small wikis? [22:42:39] legoktm: Do it. [22:42:39] just taking credit afterward, as a topic. Go ahead [22:43:14] Hauskatze: Ideally we'd stop new deployments of ShortUrl. [22:43:45] alright [22:43:45] James_F: alright, shall we do the one for gomwiki as the latest one? [22:43:53] Yeah. [22:44:10] 23:24:48 npm ERR! shasum check failed for /tmp/npm-325-37027591/registry.npmjs.org/unicode-5.2.0/-/unicode-5.2.0-0.7.5.tgz [22:44:13] ffs [22:44:36] Okay. We should put the notice that no more ShortUrl installs will be allowed, and that people should wait for UrlShortener [22:44:48] where, not sure [22:45:19] I can start with the Conpherence room the Site-Request people have [22:46:21] Reedy: It'd be lovely if we could run npm's fetches in ALOHA mode. [22:46:49] ALOHA? [22:47:07] I know the Hawaiian meaning... [22:47:09] Hula dancers [22:47:34] Also see https://phabricator.wikimedia.org/T206816 [22:47:56] legoktm: The original networking back-off protocol. Developed at the University of Hawai'i. [22:48:41] legoktm: https://en.wikipedia.org/wiki/ALOHAnet [23:11:06] Reedy: Is https://gerrit.wikimedia.org/r/c/mediawiki/vendor/+/346351 (zordius/lightncandy bump) going anywhere? [23:11:22] Nope [23:11:36] * James_F sighs. [23:12:19] The people who added it.. Don't seem to know how to (or don't care about) maintain it/upgrade it in MW and Flow [23:12:32] Someone from WMDE did help me make some progress, but never really got any further [23:13:06] It wouldn't surprise me if it starts causing problems/noise in PHP 7 or newer [23:13:17] Oh, and upstreams docs are well, shite [23:13:43] James_F / Reedy : busy? it seems no one is around for SWAT... [23:13:57] I can do it [23:14:08] fantastic, thanks [23:26:34] * paladox just implemented the UI to go along with the cherry pick with conflicts https://gerrit-review.googlesource.com/c/gerrit/+/199730 [23:37:04] anomie: if you get a chance, can you check if anything at https://phabricator.wikimedia.org/T205369 stands out? I suspect it is some recent MCR changes. [23:44:37] https://gerrit.wikimedia.org/r/466771 and https://gerrit.wikimedia.org/r/466775 to finish cleaning up the mail_mime-decode