[04:39:47] https://gerrit.wikimedia.org/r/198661 may be of interest to people in here. [11:47:05] Fiona: yes [12:39:39] 7Blocked-on-MediaWiki-Core, 10MediaWiki-User-preferences, 10MediaWiki-extensions-ContentTranslation, 5ContentTranslation-Release4, 3LE-Sprint-84: CX beta-feature does not stay enabled - https://phabricator.wikimedia.org/T92232#1140414 (10Nikerabbit) [12:40:27] This ^^ one was brough up in SoS last week. It is currently blocking new features in CX. [12:41:54] 7Blocked-on-MediaWiki-Core, 10MediaWiki-extensions-Translate, 7I18n, 3LE-Sprint-84, 5Patch-For-Review: Not able to mark big pages for translation at mediawiki.org - https://phabricator.wikimedia.org/T90704#1140416 (10Nikerabbit) [12:51:40] 6MediaWiki-Core-Team, 10CirrusSearch: CirrusSearch: * or ? at the start of a word is ignored - https://phabricator.wikimedia.org/T91666#1140423 (10Manybubbles) 5duplicate>3Open [14:46:27] 6MediaWiki-Core-Team, 6operations: Figure out a replication strategy for Swift - https://phabricator.wikimedia.org/T91869#1140576 (10fgiunchedi) no affinity features at the moment, we run swiftrepl in an ad-hoc fashion, I looked into container replication and setup an initial trial but got stuck with some cont... [15:29:35] 7Blocked-on-MediaWiki-Core, 10MediaWiki-User-preferences, 10MediaWiki-extensions-ContentTranslation, 5ContentTranslation-Release4, 3LE-Sprint-84: CX beta-feature does not stay enabled - https://phabricator.wikimedia.org/T92232#1140643 (10bd808) User::saveSettings() should be invalidating the memcache cac... [15:29:38] <^d> bd808: Possibly crazy idea. Since you no longer need a forwarded key for scap or git, would it be insane to make scap start itself in a screen by default? [15:29:52] <^d> No reason you can't screen it, and would protect against a disconnect [15:30:11] hmmm [15:30:24] where would that logic go? [15:31:00] starting in a screen wouldn't work from inside the python app I don't think [15:31:01] <^d> nfc. [15:31:24] <^d> unless `scap` wasn't the python app anymore and was just a bash wrapper that calls the python one with screen [15:32:20] yeah. you'd have to do something like that I think. And then get into the complexity of figuring out if you really wanted to reattach to an existing screen session or not maybe [15:32:33] starts to feel pretty janky to me [15:32:59] <^d> Just a thought. Want me to toss it in Phab low prio so we don't forget? [15:33:10] Really the whole deploy should be in a screen [15:33:12] <^d> Can always decline later if we think it's batshit [15:33:24] ssh tin -- screen -R -D [15:33:56] Or tmux if we joined the 21st century :) [15:34:18] * bd808 switched from screen to tmux a long time ago [15:34:39] scap can only be called by the deploy webapp [15:34:50] heh [15:34:51] big red button o' doom [15:35:14] sounds like a fun project that I'm not supposed to work on [15:35:29] * greg-g laughs an evil laugh [15:37:22] <^d> !phab T93588 [15:37:22] https://phabricator.wikimedia.org/T93588 [15:37:27] <^d> created ^ [15:38:56] mosh -> tin -> tmux session == profit! [15:39:24] for the next time someone does a deploy from a ferry crossing the english channel [15:50:30] * YuviPanda is crossing the english channel in june! [15:50:44] needs public IP for tin tho. Mosh doesn’t do forwarding / proxycommand still. [15:52:28] you can hop through a proxy I thought with the right .ssh/settings magic? [15:52:44] but you key forwarding is a no go for various good reasons [15:52:49] 6MediaWiki-Core-Team, 10OCG-General-or-Unknown, 7HHVM, 7Wikimedia-log-errors: OOM reported at SpecialPage.php:534 due to large output from Special:Book - https://phabricator.wikimedia.org/T89918#1140825 (10ori) 5Open>3Resolved [15:54:03] bd808: yeah, but last I looked you can’t proxy through... [15:54:28] yeah guess not. you could launch mosh from a bastion to the inside [15:54:38] which is not really worth much [15:56:48] 6MediaWiki-Core-Team, 10OCG-General-or-Unknown, 7HHVM, 7Wikimedia-log-errors: OOM reported at SpecialPage.php:534 due to large output from Special:Book - https://phabricator.wikimedia.org/T89918#1141249 (10bd808) 5Resolved>3Open Commit message that auto-closed is "Increasing the memory limit won't fix... [16:02:23] bd808: yup, not worth much at all. [17:02:58] legoktm: Don't we still need to make sure the User is unstubbed? [17:06:22] bd808: I don't think so, the only other usages of that object just call getName() which we set [17:06:31] ok [17:37:19] bd808: thanks for commeting on T92232... is there anything I can do to fix the race condition? I think ULS language switching might also have the same issue [17:37:56] Where is the code that triggers the pref toggle? [17:38:22] There's a wait-for-slave thing that could in theory be done I think [17:39:24] what would probably be the fix would be to repopulate the cache with the new data preemptively [17:39:41] so save pref and then load cache from master [17:40:13] rather than emptying cache and then waiting for the next request to populate the cache [17:40:32] aspiecat: Does that sound reasonable? ^ [17:42:03] https://github.com/wikimedia/mediawiki-extensions-ContentTranslation/blob/master/specials/SpecialContentTranslation.php#L28 [17:42:05] 6MediaWiki-Core-Team, 10Datasets-General-or-Unknown, 6Services, 10Wikimedia-Hackathon-2015, 7Epic: Improve Wikimedia dumping infrastructure - https://phabricator.wikimedia.org/T88728#1141848 (10Aklapper) p:5Triage>3Normal [17:43:33] bd808: it sounds reasonable to me! [17:43:52] but does it still leave rarer race condition of two threads updating the user preferences at the same time? [17:44:13] We always will have that with the current code [17:45:13] The only way to fix that is with some kind of revision id that you can check for on save [17:45:32] so I guess the big Q is whether it is easy to load user info from master to populate the cache [17:45:49] yeah. [17:47:12] could just call to saveToCache() do it? since we already have the data in the user object [17:48:18] actually, yeah that should work [17:49:03] bd808: placed on saveSettings after (or instead) the call to clearSharedCache() [17:49:16] *nod* [17:50:28] I think instead of would work [17:50:48] I'd want aspiecat to review for sure [17:53:18] bd808: well, I can craft the simple patch while we wait for A to appear ;) [17:53:28] totally! [17:53:45] I actually already have 3 in queue ;) [17:54:04] manybubbles: just fyi, you're not on releng@, so you won't see replies necessarily :) [17:54:31] greg-g: ah! I thought reply-all would magic that in. oh well. [17:54:36] thanks for posting the ticket [17:55:58] manybubbles: I forgot to reply all and just replied-list [17:56:09] * greg-g hates ever expanding to/cc fields [18:09:50] bd808: and not unexpectedly, I found another bug while writing the patch [18:10:19] https://gerrit.wikimedia.org/r/#/c/198760/ is the patch - untested [18:15:45] anomie: Is T87645 waiting for you and/or Parent5446? (obviously I'm still in learning mode here) [18:15:57] * anomie looks [18:16:40] meeple27: At the moment, it's waiting on https://gerrit.wikimedia.org/r/#/c/190416/ so the maintenance script will work more correctly. [18:17:09] anomie: right, but what is that gerrit waiting on? It looks like it needs review from you and parent? [18:17:10] 6MediaWiki-Core-Team, 10Wikidata-Query-Service: Build a tool for synchronizing Wikidata changes into Blazegraph - https://phabricator.wikimedia.org/T89852#1142137 (10Manybubbles) https://gerrit.wikimedia.org/r/#/c/198723/ [18:19:02] meeple27: Waiting on resolution of the discussion on PS5 line 366. [18:19:53] woah, new nick [18:20:21] nick changers confuse me a lot :o [18:21:03] sorry about that. i had to pick a nick on my first day, with no context. Now that I've been here a couple weeks, I have picked what I hope is my permanent one. I'm Kevin Smith, btw [18:21:26] anomie: Ok, so the ball is back in Tim's court to fix up the patch, right? [18:22:39] 6MediaWiki-Core-Team, 10CirrusSearch: Fix highlighting for phrase prefix queries - https://phabricator.wikimedia.org/T93014#1142165 (10Manybubbles) Oh, actually, that looks like its working.... Are you using the experimental highlighter? [18:22:47] we have a couple people which change nick every month or so ;) [18:22:55] meeple27: Yes. Or, I suppose, someone else could make a followup to fix that issue and I'd review+merge both at the same time. [18:23:06] got it. thanks. [20:03:50] 6MediaWiki-Core-Team, 10Wikidata-Query-Service: Add bestRank to RDF export - https://phabricator.wikimedia.org/T92990#1142650 (10Smalyshev) `?r >= "normal"^^wdo:rank` is not the same as best rank. Best rank is tricky - if there is preferred statements somewhere on this property, then it's `?r >= "preferred"^^w... [20:06:07] 6MediaWiki-Core-Team, 10MediaWiki-extensions-CentralAuth, 10SUL-Finalization, 5Patch-For-Review: Special:GlobalRenameRequest is notifying all users with a shared name of a completed request - https://phabricator.wikimedia.org/T93444#1142656 (10hoo) 5Open>3Resolved Still needs to be deployed... guess th... [20:06:25] hoo: yeah I'll SWAT it today [20:06:31] : [20:06:33] * :) [20:12:58] 6MediaWiki-Core-Team, 10Wikidata-Query-Service: Add bestRank to RDF export - https://phabricator.wikimedia.org/T92990#1142672 (10Manybubbles) >>! In T92990#1142650, @Smalyshev wrote: > `?r >= "normal"^^wdo:rank` is not the same as best rank. Yeah. I'm not sure what kind of crazy juice I was drinking when I s... [20:13:56] 6MediaWiki-Core-Team, 10Wikidata-Query-Service: Add bestRank to RDF export - https://phabricator.wikimedia.org/T92990#1142673 (10Smalyshev) Yeah I'll make a patch to add it on generation side. [20:38:58] <_joe_> mmmh I can't find anything in the mediawiki-core gdoc about this evening's meeting [20:39:23] * bd808 hasn't written anything there... [20:39:23] <_joe_> which I will not be able to attend (I have a sore throat and basically I am unable to speak right now) [20:39:48] Feel better. I'll give your regrets [20:39:58] <_joe_> thanks [20:40:28] <_joe_> I just got to my hometown this morning, which means -15 C and +60% humidity compared to Rome [20:40:46] <_joe_> well, not -15, but -10 [22:39:49] 6MediaWiki-Core-Team, 10Security-Reviews, 10Wikidata-Query-Service: BlazeGraph Security Review - https://phabricator.wikimedia.org/T90115#1143393 (10csteipp) Talked with Nik today about running this. We're planning to expose sending raw queries into our cluster. The biggest threats are a malicious users cau... [22:52:03] 6MediaWiki-Core-Team, 10Security-Reviews, 10Wikidata-Query-Service: BlazeGraph Security Review - https://phabricator.wikimedia.org/T90115#1143411 (10Smalyshev) > it sounds like there might be capabilities to cause Blazegraph to query an external db, or load local files There's definitely a LOAD command that... [23:16:42] legoktm: https://gerrit.wikimedia.org/r/#/c/199046/ seems to be unbroken now [23:16:58] bd808: yeah, gallium and lanthanum both ran out of disk space [23:17:04] see -releng for fun :) [23:17:05] ouch [23:34:39] 6MediaWiki-Core-Team, 10Gather: Quick perf review of Gather - https://phabricator.wikimedia.org/T93417#1143544 (10aaron) Would be nice to clean up the primary key as mentioned in CR of course. [23:46:58] 6MediaWiki-Core-Team, 10Gather: Quick perf review of Gather - https://phabricator.wikimedia.org/T93417#1143630 (10Jdlrobson) @aaron T93434 [23:55:49] aude: OutputPageJsConfigBuilder.php line 67 calls User->isBlockedFrom() [23:55:51] OutputPageJsConfigBuilder.php line 44 calls Wikibase\OutputPageJsConfigBuilder->getUserConfigVars() [23:56:00] aude: looks like that is using the master DB [23:56:27] there is an argument to not do that in isBlockedFrom