[00:03:29] <James_F>	 anomie: Is the plan for https://gerrit.wikimedia.org/r/#/c/321406/ to merge it this week (e.g. tomorrow, just after the cut)?
[00:04:51] <tgr>	 the plan was to merge it last week but I keep getting distracted :(
[00:05:44] * James_F nods.
[00:05:50] <James_F>	 tgr: Tomorrow, then! ;-)
[00:31:22] <ostriches>	 Hss anyone ever bothered looking into the "pl proc line:  2959: warning: points must have either 4 or 2 values per line" spam? It's ploticus...
[00:34:18] <Reedy>	 I presume those need tying down to the individual wiki pages
[00:34:35] <ostriches>	 Great, we don't have that
[00:34:49] <James_F>	 ploticus -> EasyTimeline issues?
[00:35:53] <Reedy>	 yeah
[00:36:22] <Reedy>	 ostriches: Might be worth filing a task to add that to the output
[00:36:30] <Reedy>	 Do we get any more information?
[00:36:33] <ostriches>	 Nope
[00:36:47] <ostriches>	 It's basically hhvm raising an INFO-level message from the failed shelling out?
[00:36:56] <James_F>	 Or capture the error and spit it back into the output, so users can fix it?
[00:37:17] <James_F>	 (Do we do that already?)
[00:37:22] <ostriches>	 I dunno :)
[00:37:29] * James_F neither. :-)
[00:37:36] <Reedy>	 			if ( $ret == "" || $retVal > 0 ) {
[00:37:36] <Reedy>	 				// Message not localized, only relevant during install
[00:37:36] <Reedy>	 				return "<div class=\"error\" dir=\"ltr\"><tt>Timeline error. "
[00:37:36] <Reedy>	 					. "Command line was: " . htmlspecialchars( $cmdline ) . "</tt></div>";
[00:38:00] <Reedy>	 i guess, probably not if it's info
[00:38:19] <ostriches>	 Adding a tracking cat would make it easier.
[00:38:47] <ostriches>	 I don't even have a wiki name :(
[00:38:58] <Reedy>	 Yeah, could be useful
[00:38:59] <MaxSem>	 ostriches, basically, it does &2>3
[00:39:01] <Reedy>	 Well, that's crap
[00:41:44] <MaxSem>	 we need to intercept stdout and log it if not empty
[00:42:10] <MaxSem>	 which should be easier with https://gerrit.wikimedia.org/r/#/c/319505/
[01:00:14] <tgr>	 how does this error end up in HHVM in the first place? does it report all stdout of processes initiated by PHP?
[01:34:55] <ostriches>	 Reedy, tgr: 'messagestr' => $response->message->toString() is you guys right?
[01:35:11] <ostriches>	 It's spamming Message::toString using implicit format: parse
[01:35:18] <Reedy>	 um.. where?
[01:35:25] <ostriches>	 CommonSettings
[01:35:38] <ostriches>	 Probably want message->plain->toString()
[01:35:43] <ostriches>	 er, plain()
[01:35:45] <Reedy>	 Not new code
[01:35:58] <Reedy>	 But I guess, yeah, that's us
[01:36:05] <ostriches>	 Eh, just sayin' :)
[01:36:33] <tgr>	 ostriches: yeah, that warning was added recently
[01:36:48] <tgr>	 should be $response->message->parse()
[01:36:53] <ostriches>	 Or parse :)
[01:36:55] <ostriches>	 Whatever
[01:37:01] <ostriches>	 Mainly, shouldn't be implicit :)
[01:37:56] <tgr>	 I grepped for it but did not think to do that in the config
[01:38:12] <ostriches>	 Easily missed :)
[01:40:43] <tgr>	 ostriches: https://gerrit.wikimedia.org/r/#/c/324008/
[01:41:05] <ostriches>	 I'm assuming the message will get cast to string at some point?
[01:41:11] <ostriches>	 Since it's implicit now
[01:41:43] <tgr>	 __toString effectively calls parse()
[01:42:02] <tgr>	 in the past it called whatever method was used last
[01:42:36] <tgr>	 so it will be stringified in the same cases it used to be (whenever PHP attempts a type cast) but with more deterministic behavior
[01:42:41] <ostriches>	 mergifying
[01:44:04] <tgr>	 if you just log the raw Message object, it's up to the log handler; the logstash handler probably transforms it to JSON which is I think more like an object->array cast in PHP
[14:15:18] <anomie>	 James_F, tgr|away: I haven't had any plans for when exactly https://gerrit.wikimedia.org/r/#/c/321406/ should be merged, I've just been waiting for reviews. Unless someone finds an issue with it, as far as I'm concerned it's good to go.
[16:06:11] <James_F>	 anomie: Understood.