[00:00:10] bd808: Right. [00:00:39] The Monolog handlers can filter based on log severity (debug, info, warning...) and can sample [00:00:45] bd808: I heard some signals about using syslog locally (which is already aggregated to logstash?). What is the plan now, to switch to one other transport, or to split it up between high prio and low prio messages? [00:00:52] bd808: cool [00:01:35] And handlers are attached to "channels" like the legacy $wgDebugLogGroups stuff [00:02:28] In prod we have a null handler on the default route and explicitly create ones that send to fluorine/logstash based on the channel [00:02:49] In beta the default only sends to udp2log [00:03:57] We have rsyslog forwarding rules on each mw server today that relay apache2 and hhvm logs to logstash. We could do the same for monolog to make rsuyslog act as a local buffer [00:04:05] or we can send direct to logstash [00:04:39] the difference will just be changing the host:port as far as MediaWiki is concerned [00:04:52] And logstash won't see any difference [00:05:03] so the only thing really effected would be rsyslog [00:06:18] I came up with a way in mediawiki-config to generate the monolog config from $wgDebugLogGroups so today there is no real difference in setting up a new log group [00:06:49] eventually I imagine we will phase that out in our config and setup monolog directly but there's no big rush [00:08:15] For a default MediaWiki install I wrote a PSR-3 logger implementation based on the prior code from GlobalFunctions. It acts just like the historic logging by default [00:08:33] Down to taking great pains to replicate the various goofy log message formats [00:08:57] That's all in the MWLoggerLegacyLogger class [00:09:22] * bd808 should have namespaced all that mess [00:09:53] MediaWiki\DebugLog\Legacy\Logger [00:15:59] bd808, MaxSem: we'll raise a normal php fatal for the oom too; so you should get one anyway... [00:16:24] hmmm... maybe we do. We tired to make some last ditch error logging [00:16:38] *tried [00:18:18] MWExceptionHandler::handleFatalError tries to trap fatals [00:19:03] which would in theory put them in error.log [00:22:01] which... we are not capturing in prod [00:22:08] major fail [00:22:39] it got mixed in with the warning/notice log stream and shut off [00:23:23] so we need a distinct fatal log stream and to set that up to save the data [00:23:30] seems not so hard [00:25:40] 3Release-Engineering, MediaWiki-Core-Team, Wikimedia-Logstash: Log php fatals with full backtraces again (fatal.log on fluorine) - https://phabricator.wikimedia.org/T89169#1029608 (10bd808) ``` [17:15] < MaxSem> bd808, MaxSem: we'll raise a normal php fatal for the oom too; so you should get one a... [00:28:20] Deskana|Away: I haven't gotten your SecurePoll test wiki farm built yet. :( I got sidetracked by logging things this weekend [01:08:09] bd808: No problem. Do you think you'll get it done by Friday? [01:08:13] bd808: It's fine if you won't, I just need to know whether to schedule a meeting with LCA. [01:17:00] Deskana: I should have time to do it on Thursday. [01:17:11] * bd808 blocks out an hour specifically for that [01:17:32] bd808: I'll probably schedule something for the start of next week then so that we're not red in the face if it goes wrong. ;-) [01:18:16] bd808: Thank you, sir! [01:18:44] Deskana: yw. us Product dorks need to stick together ;) [01:18:52] Hah. :-p [01:57:30] 3CirrusSearch, MediaWiki-Core-Team: CirrusSearch: Ignore ( and ) in prefix search - https://phabricator.wikimedia.org/T89201#1029734 (10Manybubbles) 3NEW [01:59:45] 3CirrusSearch, MediaWiki-Core-Team: CirrusSearch: Ignore ( and ) in prefix search - https://phabricator.wikimedia.org/T89201#1029767 (10Manybubbles) This should be reasonably simple to implement. We already have a character map on this field. Just map ( and ) to empty string. Add tests, rebuild index. Boom. [02:49:55] TimStarling: if you get a second, can you weigh in on https://gerrit.wikimedia.org/r/#/c/188883/ ? [02:58:27] if we don't expose TRY_FIXING there then it will presumably be done in Lua calling code instead [02:58:50] which would seem to rule out efficient implementation [03:08:13] 3MediaWiki-Vendor, MediaWiki-Core-Team, Librarization: Upgrade monolog to 1.12.0 - https://phabricator.wikimedia.org/T85535#1029829 (10bd808) p:5Triage>3Normal a:3bd808 [03:41:48] Rrrrrrrr! I spent almost an hour debugging why a file is created in a test but never removed eventhough it is added to MediaWIkiTestCase::tmpFIles. Finally realised that tmpFiles is a private property and as such it is silently re-created in subclasses but this member is naturally a no-op from the perspective of the parent class tearDown() [03:55:57] 3wikidata-query-service, MediaWiki-Core-Team: Investigate BigData for WDQ - https://phabricator.wikimedia.org/T88717#1029870 (10Beebs.systap) Thanks to Nik for chatting today. Here's a few of the key items we discussed. The slides are also attached.{F39207} I will email you is a much more detailed technical... [04:32:21] 3wikidata-query-service, MediaWiki-Core-Team: Investigate BigData for WDQ - https://phabricator.wikimedia.org/T88717#1029901 (10Manybubbles) >>! In T88717#1029870, @Beebs.systap wrote: > > Thanks to Nik for chatting today. Here's a few of the key items we discussed. The slides are also attached.{F39207} Tha... [04:51:10] https://wikiapiary.com/wiki/Main_Page [04:52:40] some weird sites there... [10:37:29] 3Wikidata, wikidata-query-service, MediaWiki-Core-Team: Deploy a Wikidata complex query service into production - https://phabricator.wikimedia.org/T85159#1030466 (10Bugreporter) [16:45:33] Fun with punycode: http://╯‵д′╯彡┻━┻.wmflabs.org/wiki/Main_Page and http://ಠ-ಠ.wmflabs.org/wiki/Main_Page [16:46:06] (xn--d1a644lha820cjib27ad0264k.wmflabs.org and xn----ncfb.wmflabs.org respectively) [16:47:45] why not [16:48:59] the first renders for me, the second is tofu [16:49:26] but, the first is not a clickable link in gnome-terminal, but the second is... [16:50:03] reason number 12917491 why I wouldn't know where to start with i18n [16:50:08] greg-g: You can't see the disapproving stare? ಠ_ಠ [16:50:14] nope [16:50:21] blame freedom [16:50:44] * bd808 actually lol'd [16:50:55] :) [17:10:54] 3MediaWiki-Core-Team: Fatal error causing phpunit tests to fail - https://phabricator.wikimedia.org/T89261#1031539 (10Jsahleen) 3NEW [17:11:34] 3MediaWiki-Core-Team: Fatal error causing phpunit tests to fail - https://phabricator.wikimedia.org/T89261#1031549 (10Jsahleen) [17:13:05] greg-g: works in Konsole [17:13:54] With my system's default monospace font which I don't remember what is, probably DejaVu [17:23:10] <^d> bd808: Ping. Evan's on-topic about xhprof in #phab. Ping him :p [17:30:29] * bd808 looks [17:42:00] <^d> bd808: bleh, can't do anything else. [17:42:54] yeah. I got basically the same response the last time I pinged him a month or more ago. [17:43:20] jehovahsays/mediawiki#4 (master - 5e5fa17 : jehovahsays): The build passed. [17:43:21] Change view : https://github.com/jehovahsays/mediawiki/compare/422faf56c9f3...5e5fa173f136 [17:43:21] Build details : http://travis-ci.org/jehovahsays/mediawiki/builds/50376765 [17:43:33] wtf [17:43:50] it passed? [17:44:05] Oh, that's not our repo [17:44:19] no, why is jehovasays pinging our channel [17:44:40] He probably just forked the repo and didn't alter the notification settings in composer.json [17:44:45] Happens to me all the time :P [17:45:01] * travis.yaml [17:45:10] yup. https://github.com/jehovahsays/mediawiki/blob/master/.travis.yml#L61 [17:46:07] and they don't have issues turned on :/ [17:52:08] Submitted https://github.com/jehovahsays/mediawiki/pull/1 to remove the irc pings [18:05:47] jehovahsays/mediawiki#8 (master - 2ea81ab : jehovahsays): The build was broken. [18:05:48] Change view : https://github.com/jehovahsays/mediawiki/compare/1bcbb209f366...2ea81ab52815 [18:05:49] Build details : http://travis-ci.org/jehovahsays/mediawiki/builds/50379135 [18:15:00] <^d> AaronS: https://phabricator.wikimedia.org/P283 is all over the fatal monitor [18:15:08] <^d> slow queries from flaggedrevs_promote [18:16:01] MediaWiki message delivery? [18:16:17] what's that account doing now? [18:16:40] <^d> Actually, I'm seeing other slow queries too [18:16:45] <^d> I don't think it's FR's fault [18:16:46] legoktm: do we have any method to check for MW role accounts? [18:17:04] no :( [18:17:08] <^d> 1 [42604ms] at runtime/ext_mysql: slow query: DELETE /* MessageGroupStats::clear 127.0.0.1 */ FROM `translate_groupstats` WHERE tgs_group IN ('page-Wikimedia Foundation/Annual Report/2013-2014','agg [18:17:09] <^d> -Wikimedia_Foundation') AND tgs_lang = 'en' [18:17:14] well, you can check if the username is reserved [18:17:30] <^d> No, I anon'd the user id [18:17:39] <^d> It was 160k something [18:18:02] ^d: right but the username looks like MediaWiki messa... [18:18:20] <^d> Ahhh, in the comment [18:19:15] AaronS: User::isUsableName() should work in this case [18:19:18] <^d> Ah, db1033 yelling in dbperformance.log [18:52:27] <^d> AaronS: On the FR front: https://gerrit.wikimedia.org/r/#/c/189854/ [18:53:42] ^d: https://gerrit.wikimedia.org/r/#/c/186630/ :) [18:56:17] Nothing surprising from Scrum of Scrums. Folks have patches that they want review on but they all seem to be things someone has already been giving feedback on. [18:57:07] the name "Scrum of Scrums" is hilarious [19:12:36] which reminds me, AaronS whenever you might have time, could you check https://gerrit.wikimedia.org/r/#/c/189319/ is sane and how much further work you would like to see [19:59:21] 3MediaWiki-Core-Team: Use message IDs for email jobs - https://phabricator.wikimedia.org/T89285#1032316 (10aaron) 3NEW [20:13:57] manybubbles: SMalyshev: you two are both in Germany next week, correct? If so, I'm wondering if you still want 1:1s or if you want to cancel. I'm cool either way. [20:14:26] robla: may as well cancel. I can do that on my end if you'd like [20:14:31] robla: I think we may cancel [20:14:52] alrighty, I can do it...I'm already shuffling calendar stuff around [20:15:00] thanks! [20:15:05] cool! [20:16:13] 3MediaWiki-Core-Team: Use message IDs for email jobs - https://phabricator.wikimedia.org/T89285#1032374 (10aaron) [20:49:05] AaronS: could you look at https://gerrit.wikimedia.org/r/178779 when you have some time? [21:36:49] Does ProfilerStandard not work anymore? [21:37:30] no, you pretty much have to use ProfilerXhprof now https://www.mediawiki.org/wiki/Manual:Profiling/Xhprof [21:41:23] s/pretty much// [21:46:40] <^d> ProfilerStandard isn't a thing :p [21:46:45] <^d> (anymore) [21:48:43] I suppose we should get someone to rubberstamp the RfC since the work is merged now ;) [21:52:03] ^d, do the evil thing and make standard an alias for xhprof? :P [21:52:27] <^d> I avoided basically any back-compat when we did this work. [21:52:32] <^d> Don't wanna add ugly things like that :p [22:02:35] <^d> legoktm: [22:02:37] <^d> 1 Undefined index: editCount in /srv/mediawiki/php-1.25wmf15/extensions/CentralAuth/includes/api/ApiQueryGlobalUserInfo.php on line 94 [22:02:37] <^d> 1 Undefined index: blocked in /srv/mediawiki/php-1.25wmf15/extensions/CentralAuth/includes/api/ApiQueryGlobalUserInfo.php on line 96 [22:03:44] ^d: do we know the API queries those warnings are associated with? [22:04:04] <^d> I don't think so, these aren't exceptions. [22:06:55] 3MediaWiki-extensions-CentralAuth, MediaWiki-Core-Team: Undefined index warnings in ApiQueryGlobalUserInfo.php - https://phabricator.wikimedia.org/T89295#1032772 (10Legoktm) 3NEW [22:11:54] If T88393 were fixed, we could match timestamps against api.log. [22:19:20] <^d> csteipp: Why do people bang insane bullshit into text fields? [22:20:06] <^d> I'm not even talking the guy who puts in things trying to trigger XSS or something [22:20:13] <^d> Just the guy who pastes like a google url like 500 times [22:21:17] <^d> I just want to meet the guy who uses a computer and is like "ooh, a textbox, let me see what happens if I type 8000 characters into it!" [22:21:20] <^d> "Oh nothing, bummer" [22:39:00] ^demon|lunch: or the person was cutting and pasting columns from a spreadsheet full of their site's referers, then they went to wikipedia to search for something and hit paste... [22:39:14] * csteipp might have been guilty of that once... [23:37:53] 3wikidata-query-service, MediaWiki-Core-Team: Investigate BigData for WDQ - https://phabricator.wikimedia.org/T88717#1032996 (10Smalyshev) a:3Smalyshev