[03:14:51] TimStarling: http://people.wikimedia.org/~ori/2014-12-13.svg shows we spend about 3.25% of backend processing time in ComposerAutoloaderInitwikidata_1_25wmf11::getLoader. I have a dim recollection of you and bd808|BUFFER investigating the composer autoloader... was that related? Did you figure anything out? [03:15:19] I don't know if the change we came up with has been deployed [03:17:39] no, it definitely hasn't, not successfully anyway [03:18:42] on line 41 of extensions/Wikidata/vendor/composer/autoload_real.php it should call register() with $prepend=false [03:21:23] i'll submit a patch [03:24:29] ah, it looks like you set prepend-autoloader: false in composer.json, and the call to register in the generated autoload_real will be modified accordingly [04:42:50] ori: https://github.com/wmde/WikidataBuilder/pull/32 [04:49:26] oh [04:51:51] TimStarling: eep, I completely missed the news about the hostage situation in Sydney. Looks bad. [05:18:59] yeah, pretty bad [07:23:09] 3MediaWiki-Core-Team: Logs flooded with "MessageCache::parse called by ..." - https://phabricator.wikimedia.org/T78517#847298 (10faidon) 3NEW [07:29:23] 3MediaWiki-Core-Team: Logs flooded with "MessageCache::parse called by ..." - https://phabricator.wikimedia.org/T78517#847307 (10Nemo_bis) Those lines don't seem too useful to identify the code which needs fixing, so disabling the log is probably no big deal. Alternatively, sample it 1:10000 or even more (cf. 1a... [07:40:30] 3MediaWiki-Core-Team: Logs flooded with "MessageCache::parse called by ..." - https://phabricator.wikimedia.org/T78517#847309 (10Legoktm) https://gerrit.wikimedia.org/r/#/c/179519/ is going to make the log messages more useful, but it hasn't been deployed yet. Sampling the log sounds like a good idea though. [14:18:50] Krinkle|detached: Was there discussion of [[mw:Special:Diff/1305323/1314590]] somewhere that I missed? [14:41:53] 3Phabricator, MediaWiki-Core-Team, Project-Creators, MediaWiki-General-or-Unknown: Allow to search tasks about MediaWiki core and core only - https://phabricator.wikimedia.org/T76942#848047 (10Nemo_bis) > So then a database bug for MediaWiki core would be tagged [MediaWiki], [Database] instead of [MediaWiki-Data... [15:06:33] 3Phabricator, MediaWiki-Core-Team, Project-Creators, MediaWiki-General-or-Unknown: Allow to search tasks about MediaWiki core and core only - https://phabricator.wikimedia.org/T76942#848084 (10Chad) >>! In T76942#848047, @Nemo_bis wrote: >> So then a database bug for MediaWiki core would be tagged [MediaWiki], [... [15:13:12] <_joe_> so, beta is down, and I don't get why [15:13:41] <_joe_> or better, any request for enwiki will cause HHVM to segfault, and it will happen on a call to Hooks::run( [15:13:46] <_joe_> 'BitmapHandlerCheckImageArea', [15:13:50] <_joe_> array( $file, $params, &$checkImageAreaHookResult ) [15:13:54] <_joe_> ); [15:13:56] <_joe_> ow, sorry for the bad paste [15:14:53] not for everyone, I guess, since I can load pages? [15:16:11] okay, main page does not load [15:17:16] in hooks.txt $params is defined with reference [15:17:19] <_joe_> it's related to this - https://gerrit.wikimedia.org/r/#/c/142046/16 [15:18:37] okay, someone forgot to update hooks.txt then [15:20:12] I wouldn't be surprised if the removal of the pass-by-reference has something to do with it [15:20:52] <_joe_> me neither [15:32:59] VipsScaler seems to be the only extension using that hook, and it is expecting reference (unless I have old code) [15:35:11] <_joe_> Nikerabbit: you're right, RoanKattow was trying to fix that as well [15:36:25] <_joe_> https://gerrit.wikimedia.org/r/#/c/179932/ [15:52:34] 3Multimedia, MediaWiki-Core-Team, MediaWiki-extensions-GWToolset: Upload stopps regularly - https://phabricator.wikimedia.org/T76450#848157 (10Nicolas_Rueck_WMDE) After a cuple of days, the tool suddenly went on uploading the missing files. [16:08:59] 3MediaWiki-Core-Team, MediaWiki-API: Query error in ApiOpenSearch::search - https://phabricator.wikimedia.org/T78074#848168 (10Anomie) 5Resolved>3Open Found another code path giving this same error. Rather than filing a nearly-identical bug, let's just reopen. [16:13:25] <_joe_> SMalyshev: ping [16:14:03] <_joe_> (it may be very early in the morning, it's very low priority right now so don't worry) [16:30:53] 3MediaWiki-Core-Team: Logs flooded with "MessageCache::parse called by ..." - https://phabricator.wikimedia.org/T78517#848189 (10Umherirrender) >>! In T78517#847309, @Legoktm wrote: > https://gerrit.wikimedia.org/r/#/c/179519/ is going to make the log messages more useful, but it hasn't been deployed yet. Sampli... [16:38:17] 3Phabricator, MediaWiki-Core-Team, Project-Creators, MediaWiki-General-or-Unknown: Allow to search tasks about MediaWiki core and core only - https://phabricator.wikimedia.org/T76942#848206 (10Nemo_bis) > You'd search for [Database] and not [MediaWiki] Is "and not" allowed in the search, filters and workboard d... [16:42:18] 3Phabricator, MediaWiki-Core-Team, Project-Creators, MediaWiki-General-or-Unknown: Allow to search tasks about MediaWiki core and core only - https://phabricator.wikimedia.org/T76942#848212 (10Chad) >>! In T76942#848206, @Nemo_bis wrote: >> You'd search for [Database] and not [MediaWiki] > > Is "and not" allowe... [17:31:19] <^d> legoktm: Heh. https://twitter.com/SwiftOnSecurity/status/544350312710959104 [17:32:07] :D [17:32:26] I found https://github.com/swiftlinux [17:32:51] <^d> Oh I hadn't found the github. [17:32:59] <^d> I was looking at swiftlinux.org and their sourceforge. [17:33:59] It's on launchpad: https://launchpad.net/swiftlinux [17:34:28] <^d> Haha, https://blueprints.launchpad.net/swiftlinux/+spec/python [17:53:30] 3Librarization, MediaWiki-Core-Team: Deploy Monolog logging configuration for WMF production - https://phabricator.wikimedia.org/T76759#848349 (10bd808) The group0 wikis (testwiki, test2wiki, wikidatatest, mediawikiwiki and zerowiki) are now logging via monolog. Dashboard at 3Librarization, MediaWiki-Core-Team: Deploy Monolog logging configuration for WMF production - https://phabricator.wikimedia.org/T76759#848357 (10bd808) [17:57:20] <_joe_> swtaarrs: you named a patch we may want to apply for solving a memleak - does that apply to 3.3.1 as well? [18:02:04] <_joe_> SMalyshev, AaronS: meeting? [18:05:05] legoktm: That GlobalTitleFile message is kind of ridiculously loud in the logs. Now that I have that channel being logged in logstash for group0 it really stands out -- https://logstash.wikimedia.org/#/dashboard/elasticsearch/monolog [18:05:49] Anything that happens more often than runJobs makes my crappy log event sense tingle [18:06:48] bd808: I have a patch to sample that 1:10000... [18:07:00] bd808: https://gerrit.wikimedia.org/r/179870 [18:30:28] legoktm: does it need to be sampled or fixed? [18:31:11] 3MediaWiki-Core-Team, MediaWiki-API: Query error in ApiOpenSearch::search - https://phabricator.wikimedia.org/T78074#848459 (10Umherirrender) 5Open>3Resolved [18:31:33] ori: well the log entries should be fixed, but most of them are the same, so sampling makes sense for now [18:33:36] I have a patch open for one and filed bugs for a few others [18:43:08] _joe_: gah, for some reason I thought it was tue/thur [18:43:30] manybubbles: so my stuff is at https://github.com/AaronSchulz/WikiDataQueryOrient (got that up since last week, with updates) [18:43:43] thanks! [18:43:49] * AaronS is glad https://github.com/orientechnologies/orientdb/issues/3191 is high priority [18:44:29] * AaronS should stop staying up late debugging stuff [18:45:14] bleh [18:45:18] legoktm: Your patch led me to find a missing feature in my monolog integration. Sampling is only sort of supported. [18:45:37] AaronS: thats almost certainly a memory leak [18:45:41] manybubbles: yep [18:46:06] manybubbles: do have time to g hangout? [18:46:15] (again, I guess :/) [18:46:16] AaronS: sure! [18:46:45] it's 'calling' you [18:47:26] I think I have that sidebar thing turned off for browser performance [18:47:34] we could just use the wdq link [18:48:49] manybubbles: https://plus.google.com/hangouts/_/wikimedia.org/wikidata-query [19:20:39] AaronS: which table should i query if i want to get all the titles a page may have had? (assume the page may have been renamed) [19:21:35] <^d> if a page was moved there's no record of the old page outside of `log` [19:21:52] <^d> We update page_title on move, not a new entry. [19:22:16] <^d> You could join page & log to find them, but it won't work if a page was deleted and restored (new page_id) [19:23:46] hmmm [19:23:51] ^d: thanks, very useful [19:23:55] <^d> you're welcome [19:27:26] Keegan: I think all of the global merge crashers on beta have been fixed now. Wanna try it before I respond on the thread saying it's fixed? My test merge went through fine [19:27:51] Sure sure I'll give it a whirl right now [19:44:02] 3Multimedia, MediaWiki-Core-Team, MediaWiki-extensions-GWToolset: Upload stopps regularly - https://phabricator.wikimedia.org/T76450#848660 (10Steinsplitter) Sounds like a lag in the job queue. [19:59:57] ^d: that whole removing a page just DELETEs it thing is so weird to me. I'm used to databases being forever [20:00:22] <^d> Revisions are forever, but not pages :) [20:00:25] <_joe_> AaronS, manybubbles, SMalyshev: u got root on einsteinium.eqiad.wmnet, enjoy [20:00:33] mmmmm [20:01:16] <_joe_> let the titan rise! [20:01:23] * _joe_ dinner [20:01:34] AaronS: it has 64GB of ram so it could get pretty close to measuring the ram only use case. closish [20:01:39] _joe_: thanks! [20:02:19] manybubbles: the indexes could certainly fit into RAM in that case [20:02:43] AaronS: I know in PostgreSQL that is comfortably within the first breaking point on performance [20:03:25] there are typically two discontinuities in performance based on data size - everything in ram is pretty flat, indexes in ram is less flat, and nothing fits in ram is even less flat [20:11:49] legoktm: http://meta.wikimedia.beta.wmflabs.org/wiki/Special:GlobalRenameProgress/Teke1 :D [20:12:21] Wait wat [20:12:22] http://meta.wikimedia.beta.wmflabs.org/wiki/Special:Contributions/Teke1 [20:12:26] Account not registered [20:13:34] uhh [20:13:37] :o [20:14:07] Hm [20:14:13] The talk pages still exist [20:14:17] I'm seeing stuff [20:14:18] http://meta.wikimedia.beta.wmflabs.org/wiki/Special:Undelete/User_talk:Teke1 [20:14:35] That all looks proper, the second edit was done by Teke2 and it now says Teke1 [20:14:50] OH [20:14:58] Maybe it's cuz the contributions are deleted. Let's see [20:15:26] Oh this just got more fun http://meta.wikimedia.beta.wmflabs.org/wiki/Special:Contributions/Teke1 [20:19:35] 3Librarization, MediaWiki-Core-Team: Get support for xhprof_frame_begin & xhprof_frame_end functions added to XHProf PECL package - https://phabricator.wikimedia.org/T1325#848793 (10bd808) p:5Normal>3Low [20:20:45] 3MediaWiki-Core-Team: InfoSec Taylor Swift bot for #mediawiki-core - https://phabricator.wikimedia.org/T78589#848806 (10Chad) 3NEW a:3Legoktm [20:21:01] ^d: What do I need to do to get +2 added for someone? -- https://www.mediawiki.org/wiki/Gerrit/Project_ownership#.2B2_for_Niharika_Kohli_in_wikimedia.2Fwikimania-scholarships [20:22:10] <^d> {{done}} [20:22:17] :) thanks [20:22:20] <^d> yw [20:23:32] Keegan: It just...vanished. [20:24:00] Majik. [20:29:17] wtf [20:29:39] anomie: There was no specific discussion recently about empty(), but I think it should speak for itself. I'm documenting status quo for the less experienced developers and so I don't have to repeat myself. I've seen various people remove it, and always with support. I've yet to see someone cheer on usage of it. Just being bold by putting it there. Feel free to open a discussion if you have good reason [20:29:39] s for using it. [20:30:12] legoktm: and I reproduced it again. Definitely deleting the accounts. [20:30:27] Krinkle: My main reason for using it is that when I want to say "!isset( $foo ) || !$foo", that's what it's designed for. [20:31:07] anomie: I'd argue that using that is never correct in the first place, and abstracting it behind empty() wold make the code worse than it arleady was. [20:31:43] Krinkle: I'll disagree with you on both of those points. [20:31:55] boolean cast is huge. If you need all that, you're using a bad API or masking errors. [20:32:49] If a variable is more-or-less known to be a boolean, then I'd say isset() || !foo is fine, and much mor explicit than empty() [20:33:06] And there's any sort of point to the excess verbosity? [20:33:30] anomie: The problem with empty() is not that there are no good uses. the problem is that reviewers can't distinguish it from a common error, and it's far too often inorrectly used, and there are alternatives with just a few more characters that don't look like a hack and are not semantically ambigious. [20:33:54] anomie: It's not verbose, it's just not hackily-short [20:34:08] I've never had a problem reviewing it. [20:34:29] Krinkle: And what's with "forbidding" casting an array to boolean? Same deal, that you think it's hacky? [20:35:53] anomie: Casting is OK, but only when there's no ambiguity about type. I think that goes for any programming language. If a property is known to be boolean, !foo is fine, no need for foo === false. Same for arrays (in php). [20:36:27] But if other types are at play, the code is just sloppy. [20:36:57] and prone to errors, that I guarantee people (including you and me) will not have accounted for. [20:37:37] Personally, I doubt the claimed advantage to using count() instead of boolean cast is worth even the minor overhead of the function call. [20:37:53] OK. [20:38:37] When I see code using empty(), I face palm and have to check every call of it. Did he get this one right? Did he get that one right? It's trickyness with no added value other than a few saved characters. [20:39:55] <^demon|lunch> You know what's worse than empty()? [20:39:57] Again, if you want to defend it, by all means. I"m happy to see how others feel about it, but from the past 3-4 years I got a pretty strong impression that "we" generally avoid it and very much not encourage it. [20:40:00] <^demon|lunch> The error suppression operator. [20:40:34] I'm sure there's many cases where @ can help make code shorter, and you'll know it's OK. But the code doesn't speak confidence. [20:44:10] <^demon|lunch> From the coding conventions: "empty( $var ) essentially does !isset( $var ) || !$var. Its behaviour also changed throughout past PHP releases." [20:44:22] <^demon|lunch> The fact that it's changed is concerning for use :) [20:44:47] Define "changed", is that referring to the fact that it used to choke on non-variables or something more interesting? [20:45:22] <^demon|lunch> No idea, I just copy+pasted from mw.org [20:45:48] I was mainly asking Krinkle (probably should have pinged), he wrote that. [20:46:18] Or the bit where empty($string['string']) used to be true before 5.3? [20:46:29] err, false before 5.3 [20:46:47] err, in or before 5.3 [20:53:27] <^demon|lunch> Krenair: re: T78589, legoktm already found a twitter-to-irc library :p [20:53:51] :D [20:54:01] 3Librarization, MediaWiki-Core-Team: Document use of Monolog with MediaWiki - https://phabricator.wikimedia.org/T78596#848918 (10bd808) 3NEW a:3bd808 [20:55:30] 3Librarization, MediaWiki-Core-Team: Document use of Monolog with MediaWiki - https://phabricator.wikimedia.org/T78596#848918 (10bd808) Created https://www.mediawiki.org/wiki/Manual:$wgMWLoggerDefaultSpi [21:13:30] see -tech - #mediawiki.wikipedia has been silent for hours (despite changes on the site), #meta.wikimedia is fine? [21:15:13] <^demon|lunch> You know I haven't ever once signed onto irc.wm.o [21:33:03] 3Librarization, MediaWiki-Core-Team: Document use of Monolog with MediaWiki - https://phabricator.wikimedia.org/T78596#849136 (10bd808) Created https://www.mediawiki.org/wiki/Manual:MWLoggerMonologSpi which needs a lot more work I think. [21:38:01] 3Wikimedia-IRC, Librarization, MediaWiki-Core-Team: IRC feed broken on group0 wikis - https://phabricator.wikimedia.org/T78599#849156 (10bd808) [21:40:56] 3Librarization, MediaWiki-Core-Team: Deploy Monolog logging configuration for WMF production - https://phabricator.wikimedia.org/T76759#849159 (10bd808) [21:42:59] 3MediaWiki-Core-Team: Central Code Repository - https://phabricator.wikimedia.org/T1238#849169 (10RobLa-WMF) [21:50:24] 3MediaWiki-Core-Team: Review change 127460 - https://phabricator.wikimedia.org/T1115#849210 (10RobLa-WMF) [21:50:25] 3Multimedia, MediaWiki-Core-Team: SHA-1 file name support - https://phabricator.wikimedia.org/T1210#849211 (10RobLa-WMF) [22:13:11] 3Wikimedia-General-or-Unknown, MediaWiki-Core-Team: Certain users are unable to log into their account (HTTP 503 upon login attempt) - https://phabricator.wikimedia.org/T75462#849277 (10Legoktm) [22:13:39] 3Librarization, MediaWiki-Core-Team: Rename composer package from cdb/cdb to wikimedia/cdb - https://phabricator.wikimedia.org/T77934#849283 (10Legoktm) 5Open>3Resolved [22:14:30] 3MediaWiki-Parser, MediaWiki-API, MediaWiki-Core-Team: Carriage return character (\r) no longer being converted to a newline when used in API edit submissions - https://phabricator.wikimedia.org/T78488#849288 (10Anomie) a:3Anomie [22:14:34] manybubbles, ^demon|lunch - i was poking at prod schema and saw "copy_to":["suggest","all","all","all","all","all","all","all","all","all","all","all","all","all","all","all","all","all","all","all","all","all_near_match","all_near_match","all_near_match","all_near_match","all_near_match","all_near_match","all_near_match","all_near_match","all_near_match","all_near_match","all_near_match","all_near_match","all_near_match","all_near_match","all_near_ [22:14:34] match","all_near_match","all_near_match","all_near_match","all_near_match","all_near_match"] [22:14:45] 3MediaWiki-Core-Team, SUL-Finalization, Wikimedia-Site-requests: Run sendConfirmAndMigrateEmail.php for all unconfirmed emails on all wikis - https://phabricator.wikimedia.org/T73241#849294 (10Legoktm) [22:14:50] is that repetition intended? [22:15:00] MaxSem: oh god yes [22:15:00] 3MediaWiki-Core-Team, SUL-Finalization, MediaWiki-extensions-Echo, MediaWiki-extensions-CentralAuth: "User must be logged in to view notification!" exception during global merge - https://phabricator.wikimedia.org/T78423#849298 (10Legoktm) a:3Legoktm [22:15:22] that is a weighting technique [22:15:35] 3MediaWiki-Core-Team, SUL-Finalization, MediaWiki-extensions-Echo, MediaWiki-extensions-CentralAuth: "User must be logged in to view notification!" exception during global merge - https://phabricator.wikimedia.org/T78423#844826 (10Legoktm) I think https://gerrit.wikimedia.org/r/#/c/179969/ might have fixed this,... [22:15:37] uh [22:15:38] 3MediaWiki-Parser, MediaWiki-API, MediaWiki-Core-Team: Carriage return (\r) line endings not being normalized before being passed to the preprocessor - https://phabricator.wikimedia.org/T78488#849302 (10Anomie) [22:15:44] :P [22:15:55] multiple copy_tos lets us weight individual fields up front. I fucking wish there was a less lame way to do it. [22:17:09] copy it 20 times over until es gives up [22:28:03] 3WMF-Design, MediaWiki-Core-Team: Interwiki search needs design input - https://phabricator.wikimedia.org/T1224#849360 (10csteipp) [22:28:28] 3MediaWiki-API, Language-Engineering, MediaWiki-Core-Team: API: Allow for documenting individual values of 'prop' parameters - https://phabricator.wikimedia.org/T77930#849361 (10csteipp) [22:31:10] <^demon|lunch> legoktm: http://amidumb.com/ [22:32:42] 3MediaWiki-Core-Team: Fix SectionProfiler percents - https://phabricator.wikimedia.org/T76668#849384 (10bd808) 5Open>3Resolved [22:32:57] 3Wikidata, wikidata-query-service, MediaWiki-Core-Team: Look into WDQ tool API language - https://phabricator.wikimedia.org/T78203#849388 (10bd808) 5Open>3Resolved [22:33:07] 3CirrusSearch, MediaWiki-Core-Team: Implement "simple" query degradation - https://phabricator.wikimedia.org/T77922#849390 (10bd808) 5Open>3Resolved [22:33:14] 3MediaWiki-Core-Team: LoadBalancer slave lag tweaks - https://phabricator.wikimedia.org/T78124#849391 (10bd808) 5Open>3Resolved [22:35:30] 3Wikimedia-IRC, MediaWiki-Recent-changes, Librarization, MediaWiki-Core-Team: IRC feed broken on group0 wikis - https://phabricator.wikimedia.org/T78599#849402 (10Krinkle) [22:49:32] 3MediaWiki-General-or-Unknown, Librarization, MediaWiki-Core-Team: Create a general UDP transport class instead of abusing wfErrorLog - https://phabricator.wikimedia.org/T74572#849425 (10bd808) [22:50:38] 3MediaWiki-General-or-Unknown, Librarization, MediaWiki-Core-Team: Create a general UDP transport class instead of abusing wfErrorLog - https://phabricator.wikimedia.org/T74572#849431 (10bd808) a:3Legoktm [22:52:08] greg-g: What's the process nowadays for marking a regression as blocker for further deployment? https://phabricator.wikimedia.org/T78599 must imho block further deployment unless fixed as that will destroy countervanalism efforts otherwise, which can have unrecoverable impact on tools and vandalism. [22:52:39] 3Collaboration-Team, Wikimedia-General-or-Unknown, MediaWiki-Core-Team, Scrum-of-Scrums: Set $wgContentHandlerUseDB = true on all WMF wikis - https://phabricator.wikimedia.org/T51193#849436 (10Spage) a:5Springle>3None [22:54:02] Krinkle: Noted. I will not be rolling out monolog to more wikis until we fix the irc feed [22:54:05] 3Wikimedia-IRC, MediaWiki-Recent-changes, Librarization, MediaWiki-Core-Team: IRC feed broken on group0 wikis - https://phabricator.wikimedia.org/T78599#849441 (10Krinkle) This should be fixed or block further deployment to phase1 or phase2 wikis as Countervandalism tools (including ClueBot, CVNBot, Huggle and w... [22:54:09] bd808: OK :) [22:54:33] Krinkle: I think this patch will fix it -- https://gerrit.wikimedia.org/r/#/c/170080 [22:56:13] I should actually split my part of that change from legoktm's part. I didn't need to jam them together like that when I was manually rebasing [22:56:40] Oh I remember why. Then it is only one patch to backport [23:03:49] 3Wikimedia-General-or-Unknown, MediaWiki-Core-Team: Certain users are unable to log into their account (HTTP 503 upon login attempt) - https://phabricator.wikimedia.org/T75462#849479 (10Aklapper) Same for Mirzali on Zazaki Wikipedia, see last task merged into this one. [23:07:31] 3Wikimedia-IRC, MediaWiki-Recent-changes, Librarization, MediaWiki-Core-Team: IRC feed broken on group0 wikis - https://phabricator.wikimedia.org/T78599#849483 (10bd808) >>! In T78599#849441, @Krinkle wrote: > This should be fixed or block further deployment to phase1 or phase2 wikis I agree and will not be pro... [23:07:35] 3MediaWiki-Recent-changes, MediaWiki-Core-Team, Wikimedia-IRC, WMF-Server-Backports, Librarization: IRC feed broken on group0 wikis - https://phabricator.wikimedia.org/T78599#849484 (10Aklapper) [23:33:17] manybubbles: from what I read, Titan and Orient should be able to handle super nodes