[00:05:53] 6operations, 10Beta-Cluster: Beta Cluster no longer listens for HTTPS - https://phabricator.wikimedia.org/T70387#1218274 (10mmodell) @robh: I apologize for the snark. Perhaps a bit of an over-reaction to the age and severity of the bug - it had been sitting for over 7 months, had the operations tag, and I don'... [01:00:40] !log running forceRenameUsers.php (SUL finalization) on large wikis (minus dewiki, enwiki) [01:00:48] Logged the message, Master [01:00:57] jamesofur: ^ :) [01:21:55] legoktm: \o/ yay! (sorry, my limechat started deciding to die every time I sent am essage) [01:26:14] legoktm: 22K queries/sec on S3 master atm. Not surprised that you saw some lock wait timeouts earlier :) [01:26:51] springle: uhoh :/ should I slow down? [01:27:10] right now I'm on arwiki which is s7 [01:27:47] these are from your jobs? : SELECT /* CentralAuthUser::importLocalNames [01:28:46] yes [01:29:40] if we can throttle that select load back a bit it would help S3 db1038 [01:31:18] are those queries still showing up on s3? I shouldn't be running anything on that db anymore... [01:32:51] the centralauth db is on db1033 right? not 1038? [01:33:02] they are, yes. spiked for a few hours earlier. paused a while, then spiked again 30m ago [01:33:07] correct [01:34:25] all from jobrunners [01:36:27] lowering the limit from 85 concurrent renames to 50 [01:38:02] ok, this code is doing a query on every single wiki to see if the user exists :/ [01:38:17] S3 master load dropping back [01:38:24] happier now [01:38:57] probably wouldn't have noticed if that SELECT traffic had used a slave [01:39:41] so the old rate would have been fine if it were using a slave? [01:39:58] yep. probably also only an issue for S3 [01:48:35] springle: I'll have blazecat look at https://gerrit.wikimedia.org/r/#/c/205070/1 to switch that function to use a slave [01:49:36] * blazecat thought he heard a ding from the kitchen (even though the headphones were across the room) [01:50:15] o/ [01:50:35] your wikisense must have tingled [01:59:35] legoktm: might be easier to use $wgJobBackoffThrottling for now in config [02:00:49] blazecat: right now I'm limting it to no more than 50 concurrent renames by just counting the rows in the renameuser_status table [02:03:18] sure [02:04:20] does $wgJobBackoffThrottling provide any advantage over that? [02:04:44] if the current limiting works then I'd just leave it [02:06:30] * blazecat wanders [02:12:00] !log sending post-SULF rename notifications to renamed users on medium wikis [02:12:08] Logged the message, Master [02:19:24] !log l10nupdate Synchronized php-1.26wmf1/cache/l10n: (no message) (duration: 05m 46s) [02:19:36] Logged the message, Master [02:23:57] !log LocalisationUpdate completed (1.26wmf1) at 2015-04-19 02:22:54+00:00 [02:24:01] Logged the message, Master [02:38:17] !log l10nupdate Synchronized php-1.26wmf2/cache/l10n: (no message) (duration: 05m 01s) [02:38:22] Logged the message, Master [02:42:21] !log LocalisationUpdate completed (1.26wmf2) at 2015-04-19 02:41:18+00:00 [02:42:25] Logged the message, Master [03:47:41] PROBLEM - puppet last run on wtp2001 is CRITICAL Puppet has 1 failures [04:05:40] RECOVERY - puppet last run on wtp2001 is OK Puppet is currently enabled, last run 1 minute ago with 0 failures [05:12:37] !log LocalisationUpdate ResourceLoader cache refresh completed at Sun Apr 19 05:11:33 UTC 2015 (duration 11m 32s) [05:12:45] Logged the message, Master [06:06:11] PROBLEM - DPKG on analytics1014 is CRITICAL: CHECK_NRPE: Socket timeout after 10 seconds. [06:06:42] PROBLEM - configured eth on analytics1014 is CRITICAL: CHECK_NRPE: Socket timeout after 10 seconds. [06:07:01] PROBLEM - puppet last run on analytics1014 is CRITICAL: CHECK_NRPE: Socket timeout after 10 seconds. [06:07:11] PROBLEM - SSH on analytics1014 is CRITICAL - Socket timeout after 10 seconds [06:07:20] PROBLEM - Disk space on analytics1014 is CRITICAL: CHECK_NRPE: Socket timeout after 10 seconds. [06:07:31] PROBLEM - RAID on analytics1014 is CRITICAL: CHECK_NRPE: Socket timeout after 10 seconds. [06:07:50] PROBLEM - dhclient process on analytics1014 is CRITICAL: CHECK_NRPE: Socket timeout after 10 seconds. [06:07:50] PROBLEM - salt-minion processes on analytics1014 is CRITICAL: CHECK_NRPE: Socket timeout after 10 seconds. [06:07:50] PROBLEM - Hadoop NodeManager on analytics1014 is CRITICAL: CHECK_NRPE: Socket timeout after 10 seconds. [06:07:50] PROBLEM - Hadoop DataNode on analytics1014 is CRITICAL: CHECK_NRPE: Socket timeout after 10 seconds. [06:16:11] RECOVERY - configured eth on analytics1014 is OK - interfaces up [06:16:40] RECOVERY - puppet last run on analytics1014 is OK Puppet is currently enabled, last run 24 minutes ago with 0 failures [06:16:41] RECOVERY - SSH on analytics1014 is OK: SSH OK - OpenSSH_6.6.1p1 Ubuntu-2ubuntu2 (protocol 2.0) [06:16:50] RECOVERY - Disk space on analytics1014 is OK: DISK OK [06:17:01] RECOVERY - RAID on analytics1014 is OK no disks configured for RAID [06:17:20] RECOVERY - Hadoop NodeManager on analytics1014 is OK: PROCS OK: 1 process with command name java, args org.apache.hadoop.yarn.server.nodemanager.NodeManager [06:17:20] RECOVERY - dhclient process on analytics1014 is OK: PROCS OK: 0 processes with command name dhclient [06:17:20] RECOVERY - salt-minion processes on analytics1014 is OK: PROCS OK: 2 processes with regex args ^/usr/bin/python /usr/bin/salt-minion [06:17:20] RECOVERY - Hadoop DataNode on analytics1014 is OK: PROCS OK: 1 process with command name java, args org.apache.hadoop.hdfs.server.datanode.DataNode [06:17:20] RECOVERY - DPKG on analytics1014 is OK: All packages OK [06:29:51] PROBLEM - puppet last run on db1034 is CRITICAL puppet fail [06:30:10] PROBLEM - puppet last run on cp3042 is CRITICAL Puppet has 2 failures [06:30:11] PROBLEM - puppet last run on elastic1030 is CRITICAL Puppet has 1 failures [06:30:40] PROBLEM - puppet last run on analytics1030 is CRITICAL Puppet has 1 failures [06:30:51] PROBLEM - puppet last run on cp4008 is CRITICAL Puppet has 1 failures [06:31:01] PROBLEM - puppet last run on virt1006 is CRITICAL Puppet has 1 failures [06:31:11] PROBLEM - puppet last run on cp3037 is CRITICAL Puppet has 2 failures [06:31:11] PROBLEM - puppet last run on cp3016 is CRITICAL Puppet has 1 failures [06:31:40] PROBLEM - puppet last run on mira is CRITICAL puppet fail [06:34:42] PROBLEM - puppet last run on mw2184 is CRITICAL Puppet has 1 failures [06:34:51] PROBLEM - puppet last run on mw2127 is CRITICAL Puppet has 1 failures [06:34:51] PROBLEM - puppet last run on mw2022 is CRITICAL Puppet has 2 failures [06:36:01] PROBLEM - puppet last run on mw2212 is CRITICAL Puppet has 1 failures [06:36:30] PROBLEM - puppet last run on mw2050 is CRITICAL Puppet has 1 failures [06:36:30] PROBLEM - puppet last run on mw2045 is CRITICAL Puppet has 1 failures [06:45:31] RECOVERY - puppet last run on cp4008 is OK Puppet is currently enabled, last run 9 seconds ago with 0 failures [06:45:40] RECOVERY - puppet last run on virt1006 is OK Puppet is currently enabled, last run 32 seconds ago with 0 failures [06:45:51] RECOVERY - puppet last run on cp3037 is OK Puppet is currently enabled, last run 19 seconds ago with 0 failures [06:45:51] RECOVERY - puppet last run on cp3016 is OK Puppet is currently enabled, last run 1 minute ago with 0 failures [06:46:20] RECOVERY - puppet last run on mw2045 is OK Puppet is currently enabled, last run 4 seconds ago with 0 failures [06:46:21] RECOVERY - puppet last run on cp3042 is OK Puppet is currently enabled, last run 1 minute ago with 0 failures [06:46:21] RECOVERY - puppet last run on elastic1030 is OK Puppet is currently enabled, last run 2 seconds ago with 0 failures [06:46:51] RECOVERY - puppet last run on analytics1030 is OK Puppet is currently enabled, last run 1 minute ago with 0 failures [06:47:30] RECOVERY - puppet last run on mw2212 is OK Puppet is currently enabled, last run 1 minute ago with 0 failures [06:47:41] RECOVERY - puppet last run on db1034 is OK Puppet is currently enabled, last run 1 minute ago with 0 failures [06:47:51] RECOVERY - puppet last run on mw2184 is OK Puppet is currently enabled, last run 1 minute ago with 0 failures [06:48:00] RECOVERY - puppet last run on mw2127 is OK Puppet is currently enabled, last run 1 minute ago with 0 failures [06:48:00] RECOVERY - puppet last run on mw2050 is OK Puppet is currently enabled, last run 1 minute ago with 0 failures [06:48:00] RECOVERY - puppet last run on mw2022 is OK Puppet is currently enabled, last run 1 minute ago with 0 failures [06:49:41] RECOVERY - puppet last run on mira is OK Puppet is currently enabled, last run 1 minute ago with 0 failures [07:00:41] PROBLEM - Outgoing network saturation on labstore1001 is CRITICAL 10.34% of data above the critical threshold [100000000.0] [07:23:21] RECOVERY - Outgoing network saturation on labstore1001 is OK Less than 10.00% above the threshold [75000000.0] [07:48:05] (03CR) 10Prtksxna: "Sorry for such a long delay in this Alex, it fell off my radar. The changes that Jared has mentioned have been made and merged." [mediawiki-config] - 10https://gerrit.wikimedia.org/r/175406 (https://phabricator.wikimedia.org/T73477) (owner: 10Glaisher) [08:21:45] Is the topic up to date? [08:23:06] not sure... it's multiple days old [08:23:25] I'm having some major slowness atm but it may be my network (and I'm not europe) [08:28:29] 6operations, 10Wikimedia-General-or-Unknown: dbtree loads third party resources - https://phabricator.wikimedia.org/T96499#1218427 (10Nemo_bis) 3NEW [08:44:20] (03PS1) 10Nemo bis: Add missing space in README [software] - 10https://gerrit.wikimedia.org/r/205078 [08:55:32] 6operations, 10Wikimedia-General-or-Unknown: dbtree loads third party resources - https://phabricator.wikimedia.org/T96499#1218436 (10Nemo_bis) [09:41:51] PROBLEM - puppet last run on suhail is CRITICAL puppet fail [09:59:41] RECOVERY - puppet last run on suhail is OK Puppet is currently enabled, last run 57 seconds ago with 0 failures [10:38:11] PROBLEM - Outgoing network saturation on labstore1001 is CRITICAL 24.14% of data above the critical threshold [100000000.0] [10:44:21] legoktm: how long it will take until all accounts renamed? [11:09:26] (03PS1) 10Glaisher: Enable Other Projects Links by default on svwikivoyage [mediawiki-config] - 10https://gerrit.wikimedia.org/r/205081 (https://phabricator.wikimedia.org/T96502) [11:12:31] RECOVERY - Outgoing network saturation on labstore1001 is OK Less than 10.00% above the threshold [75000000.0] [12:24:01] PROBLEM - puppet last run on mw1191 is CRITICAL Puppet has 1 failures [12:40:12] RECOVERY - puppet last run on mw1191 is OK Puppet is currently enabled, last run 1 minute ago with 0 failures [13:06:29] (03CR) 10Tim Landscheidt: [C: 031] Add missing space in README [software] - 10https://gerrit.wikimedia.org/r/205078 (owner: 10Nemo bis) [13:07:03] (03PS1) 10Tim Landscheidt: dbtree: Remove obsolete .gitignore [software] - 10https://gerrit.wikimedia.org/r/205085 [14:11:43] (03PS1) 10Tim Landscheidt: [WIP] swiftrepl: Fix pyflakes warnings [software] - 10https://gerrit.wikimedia.org/r/205086 [14:14:34] (03CR) 10Tim Landscheidt: [C: 04-1] "Don't know at the moment how to understand:" [software] - 10https://gerrit.wikimedia.org/r/205086 (owner: 10Tim Landscheidt) [15:08:00] (03PS1) 10Andrew Bogott: On post-kvm distros, link kvm binary to qemu-system-x86_64 [puppet] - 10https://gerrit.wikimedia.org/r/205093 [15:09:29] (03PS2) 10Andrew Bogott: On post-kvm distros, link kvm binary to qemu-system-x86_64 [puppet] - 10https://gerrit.wikimedia.org/r/205093 [15:11:37] (03CR) 10Andrew Bogott: [C: 032] On post-kvm distros, link kvm binary to qemu-system-x86_64 [puppet] - 10https://gerrit.wikimedia.org/r/205093 (owner: 10Andrew Bogott) [15:38:38] 6operations, 6WMF-Legal, 10Wikimedia-General-or-Unknown: dbtree loads third party resources - https://phabricator.wikimedia.org/T96499#1218691 (10Krenair) [15:42:46] 6operations, 6WMF-Legal, 10Wikimedia-General-or-Unknown: dbtree loads third party resources - https://phabricator.wikimedia.org/T96499#1218693 (10Krenair) a:3Springle Looks like this was caused by https://gerrit.wikimedia.org/r/#/c/192771/ [15:43:33] (03CR) 10Alex Monk: "See T96499 - this loads jquery and other things from external domains!" [software] - 10https://gerrit.wikimedia.org/r/192771 (owner: 10Springle) [15:46:30] (03PS1) 10Andrew Bogott: Switch nova scheduler pool to use new labvirt* nodes [puppet] - 10https://gerrit.wikimedia.org/r/205094 [15:48:45] (03CR) 10Andrew Bogott: [C: 032] "Take note y'all, I'm switching the scheduler over to the new HP virt nodes." [puppet] - 10https://gerrit.wikimedia.org/r/205094 (owner: 10Andrew Bogott) [16:05:39] (03PS1) 10Andrew Bogott: Revert "Switch nova scheduler pool to use new labvirt* nodes" [puppet] - 10https://gerrit.wikimedia.org/r/205096 [16:06:51] (03CR) 10Andrew Bogott: [C: 032] Revert "Switch nova scheduler pool to use new labvirt* nodes" [puppet] - 10https://gerrit.wikimedia.org/r/205096 (owner: 10Andrew Bogott) [16:07:04] (03CR) 10Glaisher: "Manybubbles, should the search index be rebuilt with this?" [mediawiki-config] - 10https://gerrit.wikimedia.org/r/204536 (https://phabricator.wikimedia.org/T94856) (owner: 10Glaisher) [16:15:49] Steinsplitter: I don't really know at this time, it just depends on how fast we're renaming people and if nothing breaks...if that happens maybe by the end of the week? [16:35:11] (03CR) 10Glaisher: "Could someone state exactly which strings are problematic (lots of hits) and which ones are not?" [mediawiki-config] - 10https://gerrit.wikimedia.org/r/196782 (https://phabricator.wikimedia.org/T50491) (owner: 10Glaisher) [17:48:41] PROBLEM - puppet last run on analytics1014 is CRITICAL: CHECK_NRPE: Socket timeout after 10 seconds. [17:48:41] PROBLEM - RAID on analytics1014 is CRITICAL: CHECK_NRPE: Socket timeout after 10 seconds. [17:48:42] PROBLEM - configured eth on analytics1014 is CRITICAL: CHECK_NRPE: Socket timeout after 10 seconds. [17:48:51] PROBLEM - Disk space on analytics1014 is CRITICAL: CHECK_NRPE: Socket timeout after 10 seconds. [17:49:00] PROBLEM - DPKG on analytics1014 is CRITICAL: CHECK_NRPE: Socket timeout after 10 seconds. [17:49:50] PROBLEM - SSH on analytics1014 is CRITICAL - Socket timeout after 10 seconds [17:50:01] PROBLEM - Hadoop DataNode on analytics1014 is CRITICAL: CHECK_NRPE: Socket timeout after 10 seconds. [17:50:01] PROBLEM - Hadoop NodeManager on analytics1014 is CRITICAL: CHECK_NRPE: Socket timeout after 10 seconds. [17:50:01] PROBLEM - dhclient process on analytics1014 is CRITICAL: CHECK_NRPE: Socket timeout after 10 seconds. [17:50:01] PROBLEM - salt-minion processes on analytics1014 is CRITICAL: CHECK_NRPE: Socket timeout after 10 seconds. [18:02:00] PROBLEM - Host analytics1014 is DOWN: PING CRITICAL - Packet loss = 100% [18:17:30] PROBLEM - HTTP 5xx req/min on graphite1001 is CRITICAL 7.14% of data above the critical threshold [500.0] [18:30:31] RECOVERY - HTTP 5xx req/min on graphite1001 is OK Less than 1.00% above the threshold [250.0] [18:37:21] PROBLEM - Disk space on hafnium is CRITICAL: DISK CRITICAL - free space: / 67 MB (0% inode=75%) [18:40:20] PROBLEM - HTTP 5xx req/min on graphite1001 is CRITICAL 7.14% of data above the critical threshold [500.0] [18:46:02] PROBLEM - HTTP error ratio anomaly detection on graphite1001 is CRITICAL Anomaly detected: 10 data above and 2 below the confidence bounds [18:52:02] PROBLEM - Outgoing network saturation on labstore1001 is CRITICAL 23.33% of data above the critical threshold [100000000.0] [18:55:11] RECOVERY - Disk space on hafnium is OK: DISK OK [18:56:42] PROBLEM - puppet last run on maerlant is CRITICAL puppet fail [19:01:31] RECOVERY - HTTP 5xx req/min on graphite1001 is OK Less than 1.00% above the threshold [250.0] [19:14:40] RECOVERY - puppet last run on maerlant is OK Puppet is currently enabled, last run 1 minute ago with 0 failures [19:21:21] RECOVERY - Outgoing network saturation on labstore1001 is OK Less than 10.00% above the threshold [75000000.0] [19:25:40] PROBLEM - Slow CirrusSearch query rate on fluorine is CRITICAL: CirrusSearch-slow.log_line_rate CRITICAL: 0.00333333333333 [19:36:41] PROBLEM - puppet last run on cp3019 is CRITICAL puppet fail [19:54:31] RECOVERY - puppet last run on cp3019 is OK Puppet is currently enabled, last run 1 minute ago with 0 failures [20:10:20] RECOVERY - Slow CirrusSearch query rate on fluorine is OK: CirrusSearch-slow.log_line_rate OKAY: 0.0 [20:20:12] RECOVERY - HTTP error ratio anomaly detection on graphite1001 is OK No anomaly detected [20:37:35] (03PS2) 10Ricordisamoa: Add categories for quality badges on itwiki [mediawiki-config] - 10https://gerrit.wikimedia.org/r/205013 [20:39:54] (03CR) 10Ricordisamoa: "Uses ContentAlterParserOutput now, only adds the template on wikitext pages in the main namespace." [mediawiki-config] - 10https://gerrit.wikimedia.org/r/205013 (owner: 10Ricordisamoa) [22:37:29] (03PS1) 10Tim Landscheidt: Tools: Ensure that webservice is not called by normal users [puppet] - 10https://gerrit.wikimedia.org/r/205184 (https://phabricator.wikimedia.org/T66219) [22:39:59] (03CR) 10Tim Landscheidt: "Tested for scfc and tools.admin-test." [puppet] - 10https://gerrit.wikimedia.org/r/205184 (https://phabricator.wikimedia.org/T66219) (owner: 10Tim Landscheidt) [22:49:29] (03CR) 10Alex Monk: "Almost entirely "nimp" entries, followed by a few CSS abuse entries." [mediawiki-config] - 10https://gerrit.wikimedia.org/r/196782 (https://phabricator.wikimedia.org/T50491) (owner: 10Glaisher) [22:51:44] (03CR) 10MZMcBride: "I'm confused about the number of hits per day; Alex's grep suggests 208 hits in an hour, but Lego's comment suggests approximately 45 hits" [mediawiki-config] - 10https://gerrit.wikimedia.org/r/196782 (https://phabricator.wikimedia.org/T50491) (owner: 10Glaisher) [22:53:44] (03CR) 10Tim Starling: [C: 031] "I don't think there's a need to review the log. Any spam that falls through can be dealt with as normal. This is obviously not a modern wa" [mediawiki-config] - 10https://gerrit.wikimedia.org/r/196782 (https://phabricator.wikimedia.org/T50491) (owner: 10Glaisher) [22:57:45] (03PS1) 10Alex Monk: Run updateArticleCount on the 28th of each month, not 29th [puppet] - 10https://gerrit.wikimedia.org/r/205187 (https://phabricator.wikimedia.org/T68867) [23:00:40] Tim-away: Thanks. :-) I was going to respond that, modern or not, regex on input is still the basic principle either way. [23:01:10] (03CR) 10Nemo bis: "Why is it a problem to miss February? There are other maintenance scripts running on the 28th, it may not be the best day. Did someone ass" [puppet] - 10https://gerrit.wikimedia.org/r/205187 (https://phabricator.wikimedia.org/T68867) (owner: 10Alex Monk) [23:01:21] But it seems better to just keep quiet at this point, I think it'll get merged if I stay out of the way. [23:01:44] I think my grep was correct. [23:01:49] (03CR) 10Alex Monk: "@MZMcBride: I think my original grep was wrong because I was taking into account all spam.log entries (it's not all for wgSpamRegex). Just" [mediawiki-config] - 10https://gerrit.wikimedia.org/r/196782 (https://phabricator.wikimedia.org/T50491) (owner: 10Glaisher) [23:01:56] :P [23:02:38] Cool. [23:03:19] Just out of curiosity, which is faster: $wgSpamRegex or a global AbuseFilter filter? [23:03:43] $wgSpamRegex [23:03:58] wgSpamRegex is obviously going to be faster [23:04:20] I'm not sure which we run first [23:04:30] Little is obvious to me. :P [23:04:45] Anyway, this type of config cleanup is great. [23:04:46] spamregex goes first [23:05:12] I was thinking they'd actually probably run pretty close together. But that was purely a guess on my part. [23:05:40] Isn't there some check page text function that does internal checks and then extension-level checks? [23:05:45] Alright, so in cases where we'd previously hit wgspamregex, we'll do a bit of extra processing to determine that an abuse filter was tripped instead. Meh. [23:05:46] For the various blacklists and such? [23:05:53] it's Editpage::internalAttemptSave() [23:06:53] The blessed EditPage.php. [23:07:12] (03PS2) 10Alex Monk: Remove $wgSpamRegex in favor of AbuseFilter and SpamBlacklist [mediawiki-config] - 10https://gerrit.wikimedia.org/r/196782 (https://phabricator.wikimedia.org/T50491) (owner: 10Glaisher) [23:07:23] "Did someone ass" [puppet] [23:07:30] Nemo_bis: Gotta love mid-word truncation. [23:07:34] (03CR) 10Alex Monk: "(rebased)" [mediawiki-config] - 10https://gerrit.wikimedia.org/r/196782 (https://phabricator.wikimedia.org/T50491) (owner: 10Glaisher) [23:09:31] Fiona: maybe [23:10:03] I missed that we're running updateArticleCount.php regularly now. [23:10:12] (03CR) 10Alex Monk: "It's not actually monthly unless we do it every month. It's silly to miss out only February because of our ridiculous calendar." [puppet] - 10https://gerrit.wikimedia.org/r/205187 (https://phabricator.wikimedia.org/T68867) (owner: 10Alex Monk) [23:10:22] For a long time, we hesitated to run it at all due to jumps in stats. [23:10:32] I guess we've moved on from that. [23:10:45] The Wiktionaries wanted it run for a long time. [23:10:53] Due to the various ways in which we've counted articles at different points. [23:11:03] Comma count! [23:11:19] We still don't run it on wikibooks. [23:11:31] Just Wikibooks is excluded? [23:11:41] Ahh, https://gerrit.wikimedia.org/r/#/c/178170/ [23:11:43] And multilingual wikis, because no body cares about article count there [23:12:06] Krenair: How is the config backlog these days? [23:12:06] Poor oldwikisource/betawikiversity [23:12:11] I know you were tracking it for a while. [23:12:13] (03CR) 10Nemo bis: "I don't see anything silly in doing something 11 times in a year. If I knew a better day I would have already chosen it. :)" [puppet] - 10https://gerrit.wikimedia.org/r/205187 (https://phabricator.wikimedia.org/T68867) (owner: 10Alex Monk) [23:12:34] in terms of tasks or commits? [23:12:47] I thought we had a backlog of open Gerrit changesets. [23:12:58] Which probably usually have open Phabricator tasks. [23:13:04] I saw a paste somewhere with a list. [23:13:12] Just wondering if it's getting better. Reedy is still gone, I guess. :-/ [23:13:22] https://gerrit.wikimedia.org/r/#/q/project:operations/mediawiki-config+status:open+-ownerin:wmf-deployment+-label:Code-Review-1%252Ckrenair,n,z [23:14:05] A bunch of those I plan to just do next time I have spare time after a swat deployment [23:14:13] Oh, -label. Neat. [23:14:14] Or just do because someone puts them up for swat deployment or whatever [23:14:49] but other than that... https://phabricator.wikimedia.org/project/sprint/board/178/query/open/ [23:14:56] Echo isn't enabled everywhere...? [23:15:21] Ah, deprecating echowikis.dblist, really. [23:16:47] It's enabled almost everywhere. [23:16:48] >>> set(open('all.dblist').read().splitlines()) - set(open('echowikis.dblist').read().splitlines()) [23:16:49] set(['votewiki', 'legalteamwiki', 'loginwiki', 'zerowiki']) [23:16:49] Krenair: ReferenceError: open is not defined [23:16:50] legalteamwiki? [23:17:02] I don't know what they have against it. [23:17:05] How is that wiki special? [23:17:09] * Krenair shrugs [23:17:14] Something's screwy there. [23:17:18] hmm? [23:17:24] what's the question? [23:17:24] https://gerrit.wikimedia.org/r/#/c/139326/4/wmf-config/InitialiseSettings.php,unified [23:17:31] How is legalteamwiki different from other private wikis? [23:17:34] jamesofur, do you listen for 'legal'? :P [23:17:47] no, but all my channels scroll in the bottom of my window so I see it [23:17:57] Like I can't see a configuration pattern where legalteamwiki needs a specific config that, say, boardwiki wouldn't also need. [23:18:10] votewiki and loginwiki are weirder cases. [23:18:13] It was mostly set up like checkuserWiki [23:18:25] I don't think I ever asked for echo to be turned off... [23:18:25] Hmm. [23:18:32] wouldn't have crossed my mind [23:18:39] I certainly have no issue with it being on there [23:18:50] votewiki no, but legalteam wiki I have no issue [23:19:08] unless it would somehow leak cross site but I find that unlikely [23:19:10] Yeah, votewiki and loginwiki are weirder cases. [23:19:23] But generally the private wikis list uniformly handles private wiki config. [23:19:34] So like legalteamwiki, checkuserwiki, boardwiki, stewardswiki would all be the same. [23:20:02] yeah, that was the goal with legalteamwiki [23:20:02] stewardwiki * [23:20:06] zerowiki is a weird wiki in general. They're group 0 but private. [23:20:07] https://noc.wikimedia.org/conf/private.dblist [23:20:21] We try to minimise extensions on loginwiki IIRC. No one needs to do much there other than log in. [23:20:21] that diff looks like someone didn't know better and so lumped legalteam with the "really weird" wikis [23:20:40] Krenair: There was also a general request (from me) to maybe consolidate/abstract the default/loginwiki/votewiki pattern. [23:20:41] yup, loginWiki and voteWiki are the ones most locked down really. Not gadgets etc [23:20:48] It gets repeated a lot in the config files, as I recall. [23:20:53] * jamesofur nods [23:20:55] it does [23:21:57] zerowiki is weird for many, many reasons [23:22:02] true [23:22:25] No gadgets on loginwiki... hmm [23:22:48] I don't think any local groups have the ability to modify MediaWiki: there anyway [23:23:01] But obviously it runs CentralAuth [23:23:04] gadgets wouldn't work anyways because $wgUseSiteCSS/JS = false; [23:24:07] (03CR) 10MZMcBride: "In discussion on IRC, I don't think legalteamwiki needs special treatment here." [mediawiki-config] - 10https://gerrit.wikimedia.org/r/139326 (owner: 10Withoutaname) [23:24:43] Wouldn't MediaWiki:Group-*.css still work? [23:24:54] Oh, nope, we even prevent that. Huh. [23:25:32] > clueless discussions where we're asked to prove that no, there is no teapot in orbit around the sun. [23:25:42] There's that classic Nemo charm! [23:25:52] And also the '*' group is a special case in the group CSS/JS code - you can't have a Group-*.css or whatever [23:26:26] Well, you have Common.css/js and the skin pages for '*'. :P [23:27:11] not on loginwiki [23:27:13] (03CR) 10Jalexander: "Just confirmation as the one stewarding legalteamWiki that it's fine with echo." [mediawiki-config] - 10https://gerrit.wikimedia.org/r/139326 (owner: 10Withoutaname) [23:27:24] as kunal said, UseSiteCss/Js = false there [23:27:30] who's kunal? [23:27:31] Right. [23:27:55] You can kunal a marriage if you make a terrible mistake. [23:28:38] jamesofur: How is anyone to believe you if your account doesn't contain "-WMF"?! [23:29:06] my ldap group [23:29:07] duh [23:54:21] (03CR) 10Alex Monk: [C: 031] Remove $wgSpamRegex in favor of AbuseFilter and SpamBlacklist [mediawiki-config] - 10https://gerrit.wikimedia.org/r/196782 (https://phabricator.wikimedia.org/T50491) (owner: 10Glaisher) [23:54:48] (03CR) 10Alex Monk: [C: 031] Enable Other Projects Links by default on svwikivoyage [mediawiki-config] - 10https://gerrit.wikimedia.org/r/205081 (https://phabricator.wikimedia.org/T96502) (owner: 10Glaisher) [23:55:23] (03CR) 10Alex Monk: [C: 031] Disable Commons file search on officewiki [mediawiki-config] - 10https://gerrit.wikimedia.org/r/204536 (https://phabricator.wikimedia.org/T94856) (owner: 10Glaisher) [23:57:03] legoktm, Fiona: any particular thoughts on https://gerrit.wikimedia.org/r/#/c/195886/3 ? do all of the numbers seem reasonable? [23:57:31] (03CR) 10Alex Monk: "Ugh... This could mean things like Parsoid don't work as expected." [mediawiki-config] - 10https://gerrit.wikimedia.org/r/205013 (owner: 10Ricordisamoa) [23:58:31] seems reasonable