[06:44:05] Nemo_bis: ? [06:47:23] legoktm: yes? [06:47:50] [03:10:22] uuuuuh [06:47:50] what was that about? [06:53:42] legoktm: fedora :) [06:53:53] oh :P [06:54:05] Maybe in fedora 22 even docker/mediawiki vagrant works! [06:54:49] I tried getting mediawiki-vagrant to work under lxc, but it kept running into weird errors [14:10:22] anomie: around ? [14:10:29] matanya: Yes [14:10:41] hi, regarding : https://phabricator.wikimedia.org/T104328 [14:10:59] would some names in PM help you? and do you have staff rights ? [14:11:30] anomie: or at least a way to test with some eleveated rights ? [14:11:31] Names in PM would help, yes. No staff rights. [14:11:41] I can test with eval.php if it comes to it. [14:11:56] Or on my local wiki once I know a test case to set up. [16:53:57] csteipp: Do you know anything about search engine indexing / robots.txt? [16:54:15] csteipp: There's a thread on-wiki about it, and I'm trying to find someone who does. [16:55:38] csteipp: Basically, people are complaining that userspace pages are being indexed, and perhaps it's just my faulty memory but I don't think it was always that way. [16:56:45] csteipp: I saw the thread, I haven't looked too much into how we do our robots.txt honestly. Is there a security concern with it? [18:22:24] Hi legoktm, around? I was looking at the tracking task for converting extension registration and saw some of the already converted extensions. I see that in some patches we've emptied the PHP entry point but not in some others. For example https://phabricator.wikimedia.org/rEINB4cb32f29de0b89006860684d72251b389c2df885 and [18:22:24] https://phabricator.wikimedia.org/rELSG0eef626b6d7be8f03e99dd51989c9dc2527697ae [18:23:06] What's the reason behind not emptying out the PHP entry points for some? [18:38:13] Niharika: previously we were attempting to maintain PHP entry points and extension.json in parallel, but that didn't work out, so I fixed the performance of the PHP shims, and we started emptying out the PHP entry points so we didn't have to duplicate stuff. The only reason we'd still duplicate it is if the extension wants to keep pre-1.25 compatability like LocalisationUpdate. On https://tools.wmflabs.org/extreg-wos/, (duplicated) means the PHP [18:38:14] entry point hasn't been emptied out yet. [18:43:25] legoktm: Okay. I'm working on GuidedTour registration conversion. Should I keep the PHP entry points or not? [18:57:52] Niharika: nope :) [19:00:18] legoktm: Cool. I got a patch up. [19:30:13] awesome, I'll take a look [19:54:29] Niharika: left comments :) [22:24:58] legoktm: Do you think I should do anything about https://packagist.org/packages/mediawiki/confirmaccount or just ignore that it exists? [22:25:48] There is a shiny red "delete" button when I log in as the mediawiki user [22:26:31] lol, paladox [22:26:52] you should look at the history on his fork. [22:27:38] why am i not surprised [22:28:15] version control exists to record every keystroke individually! [22:29:15] Please press the delete button [22:29:40] do it, see what it does! [22:29:55] (i am just kidding, saying just in case) [22:32:03] bd808: I guess he plans to remove it eventually? he commented on https://gerrit.wikimedia.org/r/#/c/190027/ saying it was a test. But I don't think anyone will ever merge that... [22:32:12] I nuked it [22:32:34] I'd like to nuke all of the extensions on packagist honestly [22:32:36] ok, you should comment on the patch otherwise he's going to re-add it again [22:35:02] {{done}} [22:36:26] legoktm: any objection to me publishing a v1.2.1 of composer-merge-plugin to pick up that classmap fix? [22:36:40] please do [22:38:55] The problem I worked around? [22:39:05] yeah [22:39:25] https://github.com/wikimedia/composer-merge-plugin/commit/56f06606cd40a8502ba15beda5965097987fe3ad