[07:35:33] 6MediaWiki-Core-Team, 10MediaWiki-Page-editing, 7I18n, 5Patch-For-Review: Long edit comments get entirely removed instead of truncated (error in cutting multibyte chars?) - https://phabricator.wikimedia.org/T85700#1077227 (10Aklapper) >>! In T85700#1075849, @MaxBioHazard wrote: > not fixed Correct, as thi... [14:05:19] 6MediaWiki-Core-Team, 10Continuous-Integration, 10MediaWiki-Configuration, 7Blocked-on-Continuous-Integration: Update jenkins for extension registration changes - https://phabricator.wikimedia.org/T86359#1077966 (10Krinkle) 5Open>3Resolved p:5Triage>3Normal a:3Legoktm [15:00:40] <_joe_> manybubbles: I am doing good progress experimenting with docker for running zookeeper for blazegraph, and I think it may be an interesting way to run blazegraph itself as well [17:11:33] Guest51625: eta for https://phabricator.wikimedia.org/T90409 ? [17:13:41] (@ csteipp) [17:14:00] I can keep changing nicks if it lets me dodge the question :) [17:14:15] It's not too bad, I can probably get to it this week. [17:14:37] awesome [17:14:39] thank you [17:15:15] csteipp: hey, wanna do a security review of SMW? :P (there's another request to install it, this time on affcom's wiki) [17:15:39] greg-g: Yeah, I just responded on the ticket [17:16:06] If they really want to shoot themselves in the head, I can at least make sure SMW will do it cleanly... [17:16:25] bah, now my comment is kind of out of order, that's what I get for multitasking [17:16:45] greg-g: It's going to be a couple weeks though. SMW it like 20 extensions now. [17:17:03] csteipp: yeah, I'm not expecting any miracles here, I wasn't even expecting you to say yes, honestly [17:21:05] greg-g, csteipp: WONTFIX cc T10390 [17:22:29] I read the request and what I see is "we are trying to use a wiki to do things that a wiki doesn't do, but if you give us some other tools we can maybe mash it into doing part of what we want." [17:22:55] bd808: see also: wikidata [17:22:59] :P [17:23:03] It will take a seriously non-trivial amount of work to run SMW on the general cluster as far as I know [17:23:24] I don't think wikidata does the things they want [17:23:57] * greg-g nods [17:24:53] The appeal to authority arguments don't help either [17:25:05] <^d> I think SMW could run anywhere we wanted it to except the largest wikis. [17:25:08] "NASA does it so I must be safe" [17:25:15] <^d> But I'm not sure it's the right tool for the job. [17:25:25] <^d> And wikitech was supposed to be a one-off exception to a rule [17:25:28] * ^d shrugs [17:25:41] and they are working on killing it in wikitech [17:25:47] All of this could be done with Lua tbh... [17:26:18] legoktm: interesting [17:27:09] <^d> Heh, I don't ever remember who originally said no to SMW [17:27:20] <^d> It was so freaking long ago [17:27:28] hey, has anyone done the crazy dance of asking for permission to travel to Lyon? I got the email and wondered how this was suddenly different from the trips I took for WMF last year [17:27:45] might need a gadget to make editing nicer like SemanticForms, but that shouldn't be too hard. [17:29:11] ^d: https://gerrit.wikimedia.org/r/#/c/193278/1/SpoofUser.php [17:34:20] legoktm: re Lua, you're right, but that turns the solution to one needing someone who feels comfortable with Lua instead of just wikitext/forms [17:34:48] bd808: Das ist verboten. [17:34:57] (I've no idea what it'd be in French :P) [17:35:00] "Non." [17:35:39] Reedy: heh. my French isn't even as good as my Spanish. At least in Spanish I can curse and start a fight [17:35:52] SACREBLEU. MERD [17:36:49] * greg-g doesn't need words to start a fight [17:37:16] greg-g: yup. But it should save them a lot of time of not having to wait for SMW to be deployed... [17:37:26] legoktm: true :) [17:37:27] "16.7% of 2015 completed. Time moves too quick now." [17:37:28] Wut, [17:50:28] * anomie sees talk about SMW, and reflects on how all of his interactions with SMW devs have been negative. [17:50:51] but smw is awesome and there is no correct view to the contrary [17:51:13] 6MediaWiki-Core-Team, 7Epic: General authentication improvements for MediaWiki - https://phabricator.wikimedia.org/T90925#1078724 (10Tnegrin) [17:53:24] <^d> Reedy: Why ist verboten? [17:53:29] * ^d can't remember who originally said no [17:53:42] It was about not allowing him to travel to Lyon [17:53:45] Not about SMW [17:53:54] But I'm sure various people have said no to various capacity [17:54:03] Tim finding trivial security bugs very easily etc [17:54:50] There's also a scalability issue - at least for wikipedias etc [17:54:56] I guess for arbcom that's not so much of an issue [17:55:05] this is chapcom :P [17:55:10] ^d: https://gerrit.wikimedia.org/r/#/c/193285/2 [17:55:12] lol [17:55:21] it's a small private wiki [17:55:24] whatever [17:56:11] the problem becomes when the next task comes in saying "but you let X do it!" [17:56:12] Of course, whatever we do, they will want git head of everything I bet [17:56:20] heh [17:56:33] wikitech was an exception... [17:56:36] first rule of parenting: be consistent [17:56:42] Maybe ask Ryan about "why smw etc?" [17:56:45] I think the answer was ease [17:56:58] Noting it was pre lua [17:58:14] <^d> Yeah, but he'll also say "I wish I hadn't done that :)" [17:58:20] heh [18:23:50] 6MediaWiki-Core-Team, 10Wikidata-Query-Service: BlazeGraph Finalization: Plan for no downtime upgrade - https://phabricator.wikimedia.org/T90445#1078869 (10Manybubbles) [18:25:41] 6MediaWiki-Core-Team, 7Epic, 5Patch-For-Review: Augment user_touched with an in-memory field - https://phabricator.wikimedia.org/T91279#1078874 (10aaron) 3NEW a:3aaron [18:26:52] 6MediaWiki-Core-Team, 10Wikidata-Query-Service: BlazeGraph Finalization: Plan for no downtime upgrade - https://phabricator.wikimedia.org/T90445#1078881 (10Manybubbles) @Thompsonbry.systap, does BlazeGraph has a documented process for rolling upgrades in HA mode? [18:33:00] Krinkle|detached: Please comment on https://gerrit.wikimedia.org/r/#/c/188543/ whether the implementation of "initialTags" is what you wanted. Thanks. [18:34:17] manybubbles: "Jesus has two birth days and that's ok." <-- Made me laugh. [18:35:39] anomie: glad I can amuse! [18:36:48] 6MediaWiki-Core-Team: Augment user_touched with an in-memory field - https://phabricator.wikimedia.org/T91279#1078922 (10bd808) [18:37:08] 6MediaWiki-Core-Team, 10Wikidata-Query-Service: BlazeGraph Finalization: Plan for no downtime upgrade - https://phabricator.wikimedia.org/T90445#1078924 (10Thompsonbry.systap) HA uses versioned RMI messages to avoid potential conflicts in rolling upgrades. To upgrade, simply shutdown a given HAJournalServer p... [18:38:11] 6MediaWiki-Core-Team, 7Epic, 5Patch-For-Review: Augment wl_notificationtimestamp with an in-memory field - https://phabricator.wikimedia.org/T91284#1078933 (10aaron) 3NEW a:3aaron [18:39:34] 6MediaWiki-Core-Team: Augment wl_notificationtimestamp with an in-memory field - https://phabricator.wikimedia.org/T91284#1078944 (10bd808) [18:41:10] <^d> bd808, AaronS: I rebased and amended the http profiling branch [18:43:55] ^d: $timeout was optional [18:44:03] won't this give undefined indexes notices then? [18:44:20] <^d> grrrrr [18:45:09] <^d> It's always going to be set [18:45:14] <^d> It had a default [18:45:32] <^d> s/had/has/ [18:45:49] yeah, I guess that works [18:46:22] <^d> Another way could be if !is_array() [18:48:41] 6MediaWiki-Core-Team, 10Wikidata-Query-Service: BlazeGraph Finalization: Pluggable inline values - https://phabricator.wikimedia.org/T90131#1078996 (10Smalyshev) a:3Smalyshev [18:48:55] Hey AaronS, would you be the person to ask about job queue brokenness? [18:52:08] maybe, depends on what it is [18:52:38] So deployment-prep's deployment-jobrunner01 is out of space due to the log file being full - of broken requests and their entire HTML responses. the wiki and type parameters are formatted wrongly, an issue that seems to come from bad-looking job queue data in redis [18:53:08] I was looking at that type/wiki thing yesterday [18:53:14] in beta we have entries like "cirrusSearchLinksUpdatePrioritized%2Fenwiki/webVideoTranscode%2Fenwiki" [18:53:14] but prod - cirrusSearchLinksUpdatePrioritized/commonswiki [18:53:14] But I don't know why that's happening [18:53:23] oh, you're already aware of this? [18:53:38] I was looking around yesterday and happened to see it [18:56:16] Do those entries get put there by the mediawiki code? [18:56:37] could this break production in the next train deploy? [19:00:13] not seeing any bad entries on prod [19:00:24] I did see those html page errors though [19:01:31] no, prod's redis data for jobqueue:aggregator:h-ready-queues:v2 looks exactly how I would expect after reading the code that interprets it [19:01:46] but beta's data has issues [19:03:09] you could just delete that key [19:03:17] it will regenerate fully in 5 min [19:03:32] if the bad keys came back then that would be interesting [19:04:03] _joe_: all you did was restart redis right? Did it lose all the keys or did they stay? [19:04:24] okay [19:05:07] JobQueueAggregatorRedis can also regenerate it more quickly [19:05:22] though I'd like to get more of that code exclusively in the daemon [19:05:36] <_joe_> AaronS: they do stay [19:05:48] <_joe_> but we had ~ 1 hour of redis not working [19:06:21] MW would just use 1003 and log the error [19:06:22] <_joe_> so queues could not be written to [19:06:35] its confusing since the logs go to exception.log though [19:06:41] <_joe_> AaronS: if it can't write to the queue but redis accepts connections? [19:06:42] * AaronS needs to move that to another log [19:06:53] <_joe_> AaronS: redis.log on fluorine had a lot of failures [19:06:58] that would still throw a redis error, so it would switch [19:07:08] the errors are logged regardless [19:07:09] <_joe_> AaronS: but that didn't happen [19:07:11] <_joe_> :) [19:07:36] <_joe_> also, jobrunners just didn't recover [19:07:43] did you see "X partitions tried" in exception.log [19:08:10] <_joe_> AaronS: honestly I didn't look there, it was 11 PM and I was basically the only one responding [19:08:43] but yes, the *service* seemed to hang or something [19:15:18] _joe_: https://ganglia.wikimedia.org/latest/?r=week&cs=&ce=&m=cpu_report&c=Miscellaneous+eqiad&h=terbium.eqiad.wmnet&tab=m&vn=&hide-hf=false&mc=2&z=medium&metric_group=ALLGROUPS [19:15:27] jobs built up because they were still being added [19:15:36] I think the problem is just with the runners [19:16:16] <_joe_> AaronS: ok, so the runners and ocg as well, but still, I think we should revisit how we do redis failovers [19:16:29] <_joe_> sorry, in a meeting ATM [19:16:37] <_joe_> we could try to pair up on that [19:17:52] I thought ocg has it's own queue? [19:18:14] (in redis, but still totally different) [19:18:34] <_joe_> AaronS: yes [19:18:37] <_joe_> correct [19:22:26] Krenair: also, did you git pull the jobrunner code [19:22:34] there was a change to truncate those html errors [19:22:47] I noticed it was still undeployed (with 3 other things) on prod yesterday [19:22:50] * AaronS fixed that [19:23:37] how can I make site list cache update itself? [19:27:18] ^d: https://gerrit.wikimedia.org/r/#/c/193874/ [19:29:08] robla: http://blog.phacility.com/post/phacility_launch/ [19:30:05] AaronS, nope, should I do that now? [19:30:21] I assumed all that was auto-deployed [19:38:03] I don't think it is deployed to beta automatically [19:41:06] <^d> AaronS: I was wrong about func_get_args() [19:41:10] <^d> It doesn't include defaults [19:45:33] 6MediaWiki-Core-Team, 10MediaWiki-RfCs: RfC: AuthManager - https://phabricator.wikimedia.org/T91105#1079217 (10bd808) @daniel We would like to request an IRC discussion of this RfC at the earliest convenience of the committee [19:51:43] <^d> csteipp: Do you have any strong opinions on $wgAllowMicrodataAttributes? [19:52:23] Ahh.... Oh, no, it's OK [19:52:44] Content translation had a bug that was triggered by allowing it, but they fixed it. [19:52:46] anomie, csteipp, AaronS, manybubbles: Weekly status update emails welcome :) [19:52:56] <^d> csteipp: hewikisource wants to turn it on. It wasn't on anywhere else so I thought I'd ask first [20:10:35] 6MediaWiki-Core-Team, 10MediaWiki-Authentication-and-authorization: Audit extensions for use of $wgAuth - https://phabricator.wikimedia.org/T91303#1079388 (10bd808) 3NEW [20:15:51] <^d> bd808: Just grepping for /\$wgAuth[^a-z]/ was scary [20:17:07] greg-g: Any idea when 1.26 wmf branches start? [20:19:44] http://www.gossamer-threads.com/lists/wiki/wikitech/509839 says April 15th, but that was hexmode's date [20:22:55] 6MediaWiki-Core-Team, 10MediaWiki-General-or-Unknown: Augment wl_notificationtimestamp with an in-memory field - https://phabricator.wikimedia.org/T91284#1079474 (10Aklapper) [20:23:49] 6MediaWiki-Core-Team, 10MediaWiki-General-or-Unknown: Augment user_touched with an in-memory field - https://phabricator.wikimedia.org/T91279#1079477 (10Aklapper) [20:27:41] AaronS: re: your comment on the statsd patch -- I don't understand the point [20:27:53] ("This makes the Context interface a lot wider. Would it be possibly to make the buffer here even dumber and just queue up metric actions and have the flush/shutdown stuff in global functions talk to the library?") [20:41:41] ori: meh, it doesn't matter [20:41:53] anything that uses RC can't be librarized anyway [20:44:56] getConfig() is the only method that returns anything with reasonable interface [20:46:49] anomie: Hm.. what would initialTags be for? [20:47:03] Krinkle: You asked for it on that patch [20:47:14] heh [20:47:32] anomie: Hm.. I'll look further but it seems confusing at first. [20:47:44] anomie: If someone listens for edits, they'd only get the tags if and when someone changes them. [20:47:57] As opposed to with the initial edit event. [20:48:30] If there's a change, add/remove should be enough. Or perhaps the newTags. Not sure if having prevTags is useful. It can be constructed from the change add/remove if needed, but more commonly one would want current tags. [20:59:29] legoktm: https://gerrit.wikimedia.org/r/#/c/190735/1 tiny change [21:17:53] csteipp: could you review https://gerrit.wikimedia.org/r/#/c/193497/ ? [21:18:03] haaaa, perfect timing :D [21:19:22] I've been known to read minds occasionally. [21:25:49] <_joe_> hey, I won't make it to the meeting today sorry, got a bad headache and I need to rest [21:31:05] rest well [21:31:10] *REST well [21:31:55] _joe_: I've had weird headaches for a few days now [21:32:33] not so much painful as just really weird and annoying...and I feel a little dizzy if I move beyond old-man speed [21:32:51] AaronS: :( [21:34:06] living by a hospital, fire station, and right next to the loud playground of a school isn't helping [21:39:14] 6MediaWiki-Core-Team, 5Patch-For-Review: Reduce SpoofUser deadlocks from rename jobs - https://phabricator.wikimedia.org/T90967#1079894 (10aaron) [21:42:36] <^demon|lunch> manybubbles: All registered for next week (just got speaker code) [21:42:46] sweet [21:49:51] 6MediaWiki-Core-Team, 10CirrusSearch: inefficient work of CirrusSearch in Russian Wikipedia - https://phabricator.wikimedia.org/T88724#1079944 (10Jdouglas) >>! In T88724#1068305, @Manybubbles wrote: > So what ruwiki needs is for the phrase rescore to still work for searches > like ```foo* bar*```. That _curre... [22:02:24] 6MediaWiki-Core-Team, 10CirrusSearch: inefficient work of CirrusSearch in Russian Wikipedia - https://phabricator.wikimedia.org/T88724#1080003 (10Manybubbles) >>! In T88724#1079944, @Jdouglas wrote: >>>! In T88724#1068305, @Manybubbles wrote: >> So what ruwiki needs is for the phrase rescore to still work for... [22:12:15] hmm ori, how far are we from not having Zend on the cluster? :P [22:12:46] joe has a trusty/hhvm scaler provisioned but some additional testing is needed before the scalers are migrated [22:13:01] so we're not far in terms of work required, but i don't know where it fits on his schedule [22:13:32] and then only shell scripts? [22:14:06] (I'm just tired of typing aray()) [22:17:58] * AaronS wonders why hangouts broke on his FF :/ [22:42:48] bd808: you missed a fun meeting on Friday re that, I explicitly didn't invite you this time [22:43:07] greg-g: :) [22:43:44] don't tell rob, but there's always a place for you on RelEng :) [22:50:47] oh hey, csteipp has a first coat of paint on the wall [22:51:08] yes I do ;) [23:23:52] hmm, why doesn't CommonSettings load wikipedia.dblist? [23:24:29] this whole wiki <--> wikipedia distinction is horibly misleading [23:25:54] misleading and imprecise [23:27:32] anyway, any objections to me adding the wikipedia group? [23:30:15] where? [23:30:52] I see we load special.dblist already [23:32:46] I suppose "wikipedia" could be loaded as a tag, it seems potentially confusing though [23:32:51] I mean https://phabricator.wikimedia.org/T91174 [23:33:01] eh, I guess it's ok [23:33:06] would appreciate a sanity check:) [23:33:10] like I say, special is already loaded [23:33:37] you can't say 'wiki but not special' [23:33:50] the wiki suffix consists of special wikis and wikipedias, by definition [23:33:55] I don't think it is imprecise [23:33:56] (at least preserving sanity:P) [23:34:01] it's certainly confusing [23:35:08] anyway, don't complain unless you are volunteering to change it ;) [23:35:44] so is ^^ ok? [23:36:11] i mean https://gerrit.wikimedia.org/r/193988 [23:36:53] I'm reading [23:38:48] just reviewing refresh-dblist now [23:40:39] yes, it's fine, gave it +2 [23:40:56] thanks:) [23:43:12] MaxSem: All the other 'wiki' settings in InitializeSettings should probably be changed in a followup [23:43:38] or the confusion will continue [23:44:21] I'll create a task, but generally it seems that every setting has to be reviewed where it should go [23:44:30] yeah [23:45:06] to see if it really meant pedia+special+some other stuff or just pedia [23:45:08] I think the sites should use prefixes, separated by an underscore, instead of suffixes [23:45:34] like 'wikipedia_en'? [23:45:41] yes [23:45:54] That would be easier to understand [23:45:55] but I inherited this system (including mixed special and wikipedias under *wiki) when I got shell access in 2003 and have never bothered to change it [23:46:40] meh, only 12 years [23:46:50] it would have been much easier to change at the time [23:47:05] we did actually rename wikis back then [23:47:13] IIRC we did wikidb -> enwiki [23:48:10] now it's complicated by ES, etc [23:48:14] the database name wasn't used in so many places [23:48:35] also, all object cche keys will be invalidated [23:49:31] when I started, we had a separate LocalSettings.php for each wiki [23:49:32] Wikidata stores db names in page text, centralauth uses dbname in its tables [23:49:41] with loads of random local edits [23:50:38] so the DB name was just set with $wgDBname = 'frwiki'; or whatever [23:51:06] I introduced the idea of detecting DB names from hostnames, so I can probably take the blame for locking in the pre-existing system [23:55:38] 6MediaWiki-Core-Team, 10Wikimedia-Site-requests: InitializeSettings: decide upon 'wiki' vs. 'wikipedia' group usage - https://phabricator.wikimedia.org/T91340#1080486 (10MaxSem) 3NEW [23:55:57] ^_^