[15:52:34] tgr|away: 127.0.0.1:4430 would be a port forward of 443 in the vm to 4430 on the host. [15:53:03] Vagrant won't be able to attach to a port <1024 on the host side without root [15:54:20] that makes sense [15:54:58] the problem is that mediawiki is configured so that directly targeting the guest's 443 port doesn't work [15:55:05] I opened a ticket about it [18:38:31] how do you add a wikitext link in a lua module? I want to add an anchor tag link to the deployment calendar. I want to add, basically, "[[#deploycal-item-%s]]" to line 150 in https://wikitech.wikimedia.org/w/index.php?title=Module:Deployment_schedule (and the related "os.date( "!%Y%m%dT%H%M", utc )," on 158 to pair with that %s) [18:38:55] greg-g: the output the module returns is wikitext [18:39:35] elseif utc == pdt then [18:39:36] * Reedy blink [18:39:36] yeah, but [ is a special character in lua, but %[%[ / %]%] isn't working either [18:39:37] s [18:40:35] https://www.mediawiki.org/wiki/Extension:Scribunto/Lua_reference_manual#Returning_text [18:41:04] * greg-g reads [18:42:55] %s–%s UTC [[#deploycal-item-%s]]
%s %s–%s %s [18:43:34] doesn't work because on line 149 it starts: table.insert( retval, string.format( [[ [18:43:40] (those [[ are not wikitext [[) [18:44:02] * greg-g wishes he could push this up for code review so you can see what I'm trying [18:44:34] greg-g: paste what you have on a random wiki page and then use Special:ComparePages [18:45:08] TIL [18:45:39] You can compare arbitary pages for the luls [18:46:22] ugh, probably needs to be another page in module: NS? [18:46:24] * greg-g tries without [18:46:56] shouldn't have to be, but then your page won't be highlighted [18:47:35] http://ur1.ca/nmh3y [18:47:40] that was an ugly url :) [19:33:19] greg-g: if text is enclosed in [[]], you need to change those to [=[]=], then just add the link as normal [19:33:47] .-=[ l33t ]=-. [20:02:31] hey all! does anybody know why "mwscript getConfiguration.php --wiki ruwiki" works on my multiwiki install but "php5 maintenance/getConfiguration.php --wiki ruwiki" doesn't (it still returns "en" settings, not "ru" settings)? [20:06:08] Because --wiki is a parameter to mwscript [20:06:35] Reedy: and to Maintenance.php judging from its code [20:06:45] maybe [20:06:52] mwscript is bootstrapping code though [20:06:59] so the question is - why doesn't it work? [20:08:21] Also how this: https://github.com/wikimedia/mediawiki/blob/master/includes/SiteConfiguration.php#L545 is supposed to work? [20:08:26] https://github.com/wikimedia/mediawiki/blob/master/maintenance/Maintenance.php#L1000-L1007 [20:09:10] Reedy: yes, I've seen this, but not sure what it means. Does it mean it works only for DB but not for other things? [20:09:19] I've honestly no idea [20:09:22] It's pretty hacky [20:10:39] AaronSchulz: are you around? [20:11:50] yeah I wouldn't even mind hacky but doesn't look like it works... unless I miss some important piece [20:12:21] why not just use mwscript if it works? [20:12:41] Reedy: SiteConfiguration.php doesn't [20:12:43] SMalyshev: if you run "php " then you've already picked the file path. mwscript (MWScript.php) is supposed to do that for you. [20:13:02] AaronSchulz: so how this works? https://github.com/wikimedia/mediawiki/blob/master/includes/SiteConfiguration.php#L545 [20:13:05] I don't think scripts can (or should) be called that way [20:13:24] we have a hook in wmf-config [20:13:47] it modifies that path to shell out to [20:14:34] ok, in multiversion/ in the media-config repo, there is onWfShellMaintenanceCmd() [20:15:07] CommonSettings has $wgHooks['wfShellWikiCmd'][] = 'MWMultiVersion::onWfShellMaintenanceCmd'; [20:15:13] SMalyshev: is vagrant just missing that logic? [20:15:20] AaronSchulz: doesn't seem to exist in my vagrant setup [20:15:28] ahh :) [20:15:49] AaronSchulz: so it may be that vagrant is missing that detail [20:16:29] yeah, CommonSettings.php for vagrant has nothing about wfShellWikiCmd [20:17:03] neither do its vassal scripts [20:19:24] So I guess this one: https://git.wikimedia.org/blob/operations%2Fmediawiki-config/4887c4164a9296934c4829a7cf26516259b43224/wmf-config%2FCommonSettings.php#L197 [20:20:16] If I just add it to Vagrant I get: Invalid callback MWMultiVersion::onWfShellMaintenanceCmd in hooks for wfShellWikiCmd [20:20:58] looks like Vagrant's MWMultiVersion doesn't have this part [20:21:01] Does that exist in the vagrant mwm... [20:21:02] Yeah [20:21:10] It was modified for vagrant usage [20:23:04] Hmm I wonder where Vagrant one lives [20:24:06] https://github.com/wikimedia/mediawiki-vagrant/blob/1bec49c1fcbdf5fd90eddfd41aa2e61d89c699a5/puppet/modules/mediawiki/templates/docroot/w/MWMultiVersion.php.erb [20:24:18] https://github.com/wikimedia/mediawiki-vagrant/tree/master/puppet/modules/mediawiki/templates/docroot/w [20:25:04] Reedy: aha, I see, thanks... So I guess I'll submit a patch to that [20:25:14] sounds good to me :) [20:38:54] jackmcbarn: that got me closer, but I've failed to accomplish what I wanted to for now, will try again later. Thanks! [21:14:20] so who should review mediawiki-vagrant patches? [21:14:55] Bryan and Dan, but they are added automatically [21:15:02] <- or bd808|MEETING [21:15:19] tgr: doesn't seem to happen here: https://gerrit.wikimedia.org/r/#/c/235132/ [21:15:34] it takes a few seconds [21:15:56] aha, ok [21:17:33] https://tools.wmflabs.org/gerrit-reviewer-bot/ [22:14:58] legoktm: https://en.wikipedia.org/w/index.php?title=List_of_popes&action=history [22:15:11] looks like it merits admin intervention, but i dunno, so asking you :P [23:01:22] bd808|MEETING: So, back in the old days we had a PHP extension ( https://github.com/wikimedia/mediawiki-php-wmerrors ) that put backtraces in fatal.log . But that feature seem to have been dropped in the Great Logging Rewrite of late 2014? Because now MWExceptionHandler::handleFatalError() appears to be what handles fatals, and it has no facility for backtraces [23:02:45] RoanKattouw: bd808|MEETING is probably the person who has spent the most time grappling with that :P [23:02:53] Is there another way I can get a backtrace for a fatal, or have we lost that feature? [23:03:34] ori: What do you mean exactly? [23:03:55] I think we lost the feature for now. It's an upstream bug. There's a task for it somewhere. [23:04:17] oh, hang on [23:04:20] Oh I now see what you said in the other channel, that it's an HHVM issue [23:04:22] there's another source for fatal errors [23:04:36] I confused it with the logging rewrite stuff, because the code that now logs fatals was written by him [23:04:48] There's hhvm-fatal.log but I couldn't find my fatals in there [23:05:15] Also it looks like those are hhvm segfauls instead [23:05:24] yeah [23:06:36] TimStarling: Would like your eyes on https://gerrit.wikimedia.org/r/#/c/234509/ if you have a minute later today [23:49:52] Krinkle: I saw that you did your homework on that one [23:51:06] TimStarling: I was somewhat uncertain because what I mentioned in the commit message matches what you and Roan were saying back in 2011 and yet the commit was made either way. [23:51:38] did you get Roan to comment on it? [23:51:39] So you reckon it won't cause any redirects to &* after this? [23:51:48] Roan deferred to you but said it looks good [23:51:56] TimStarling: When Krinkle asked me about this last week, I said something like "I remember Tim convincing me that we needed this back in 2011, and I remember understanding why we need it, but I've forgotten, so maybe Tim remembers" [23:53:05] I think we discussed it on IRC [23:53:28] Unit tests added in https://gerrit.wikimedia.org/r/#/c/234506/ [23:55:20] yeah, we discussed it by private message [23:56:33] * Krinkle adores Tim for keeping 5 years worth of IRC logs