[04:29:43] anyone know if autolist is running? [04:31:03] I can try it [04:31:09] it worked yesterday [04:31:14] didn't try today [04:31:49] eurodyne: it work for me [04:32:11] :/ [04:33:30] Harmonia_Amanda: on the autolist page it said it was running, but my account made no changes on wikidata [04:33:44] uh [04:33:46] strange [04:36:02] eurodyne: ok, I found a query where I can do modifications, I try [04:36:38] eurodyne: autolist did the edit for me https://www.wikidata.org/w/index.php?title=Q12125325&diff=prev&oldid=309126467 [04:38:22] eurodyne: you want me to do your editions? [04:38:33] add P54:Q650829 ? [04:39:35] eurodyne: it worked https://www.wikidata.org/w/index.php?title=Q1004330&type=revision&diff=307998868&oldid=307122032 [04:39:52] eurodyne: why did you say there was a problem? [04:39:59] eurodyne: you did your edits [04:43:35] eurodyne: you did half the query done, I can do the other half if you have trouble right now [04:49:52] eurodyne: autolist running right now for me, and it's working, so this will get done [04:50:02] eurodyne: still no idea what your problem is [05:01:02] Harmonia_Amanda: check the date [05:01:06] that was 2 days ago [05:01:35] eurodyne: yes, I know [05:01:58] what I don't understand is why you stopped autolist before the end two days ago [05:02:15] Harmonia_Amanda: perma link me? [05:02:18] and why it doesn't work for you today when it work for me [05:02:40] eurodyne: https://tools.wmflabs.org/autolist/?language=en&project=wikipedia&category=Toronto%20Blue%20Jays%20players&depth=0&wdq=claim[31%3A5]%20and%20noclaim[54]&pagepile=&wdqs=&statementlist=&run=Run&mode_manual=or&mode_cat=or&mode_wdq=not&mode_wdqs=or&mode_find=or&chunk_size=10000 [05:02:40] El búfer 54 está vacío. [05:02:58] it's you query eurodyne i didn't change anything [05:04:05] 642 items loaded, only 362 in reality (like usual, autolist isn't up to date), and I treated 80 out of these 362 already [08:46:05] Lydia_WMDE: Thiemo_WMDE: benestar|cloud: is there a reason https://phabricator.wikimedia.org/T126795 has been removed from the current sprint? it has a patch in review though.. [09:23:55] nikki: another great set of statements https://www.wikidata.org/wiki/Q22712541 [09:41:21] anyone knows why the constraint violation report of https://www.wikidata.org/wiki/Property_talk:P789 isn't updating? [11:02:16] sjoerddebruin: wikimania: yes \o/ [11:02:22] :D [11:03:41] * Harmonia_Amanda grmbll and grmbll and grmblll because Wikipedias have too many erros and then import them on Wikidata [11:04:37] * Lydia_WMDE hands Harmonia_Amanda a little fluffy kitten [11:04:53] :) [11:06:18] seems like a quarter of the IBDB identifiers are wrong [11:06:27] and it's all wikipedias fault [11:06:33] *sigh* [11:06:35] :( [11:06:48] well, I'll clean it up [11:06:58] but still [11:07:01] That's our job, cleaning up. Every day again [11:07:09] I shouldn't have to [11:09:37] maybe I should query all items with identical IMDB and IBDB identifiers [11:09:44] seems like the most frequent error [11:09:52] +1 [11:14:07] Lydia_WMDE: https://phabricator.wikimedia.org/tag/mediawiki-extensions-wikibasemediainfo/ \o/ [11:14:54] hmm, don't really know how to query that... [11:17:30] it wouldn't be the same id on wikidata since we have the imdb prefix on WD and there is no ibdb prefix [11:19:40] where's jonas? [13:59:33] yikes https://www.wikidata.org/w/index.php?title=Q12737077&curid=14108396&action=history [14:11:13] Thiemo_WMDE: i am getting qunit test failure https://phabricator.wikimedia.org/P2696 [14:11:27] it might be related to https://gerrit.wikimedia.org/r/#/c/266727/ [14:11:44] (the build also fails, and i'm guessing it's the same issue) [14:18:31] https://phabricator.wikimedia.org/T128589 [15:34:57] And I thought I had bad connectivity tethering in a train :P [15:43:41] * hoo hands Lydia a box of connectivity :P [17:51:14] Lydia_WMDE: https://phabricator.wikimedia.org/T89733 [21:10:19] DanielK_WMDE: around? [21:54:55] SMalyshev: at the ArchCom session. RFC triage coming up on #wikimedia-offic [21:55:29] SMalyshev: what's up? [21:56:04] DanielK_WMDE: check out https://phabricator.wikimedia.org/T128486#2081542. I think we don't purge URLs with ?flavor= from cache [21:56:33] and we probably should... [21:57:41] SMalyshev: requests with parameters just shouldn't be cached. we should probably set the headers accordingly, want to file a ticket? [21:57:56] But I thought varnish was configured to not cache anythign with url parameters anyway... [21:58:01] DanielK_WMDE: I'd like flavors to be cached. Just purged like the rest [21:58:05] can it work? [21:58:44] SMalyshev: not difficult, but I don't know about the performance implication. We have to send a purge command for every possible combinations of parameters. Not nice... [21:59:04] DanielK_WMDE: is it? I see this in headers: x-cache:cp1052 miss(0), cp4016 miss(0), cp4017 frontend hit(1) for https://www.wikidata.org/wiki/Special:EntityData/Q3361378.ttl?flavor=dump [21:59:26] SMalyshev: I thought it was. But maybe I was wrong. [22:00:08] well, either I am misreading what "frontend hit" means there or it's cached :) Also I did quick check on sandbox and flavor URL is not updated immediately after edit or after purge [22:00:43] DanielK_WMDE: so I thought maybe I miss something but looks like it's indeed a bug. If so, I'll file a ticket [22:01:12] flavors aren't much used except by WDQS now but that's not the reason to mishandle them... [22:01:30] may be tricky to get list of flavors for cache reset though... [22:02:55] SMalyshev: that'S exactly the point. and that the list may be rather long. [22:04:11] DanielK_WMDE: yeah I know... but we need to either disable the cache or purge it properly. Otherwise we'd get a lot of weirdness down the road. I'll check if it can be handled easily after filing the issue [22:05:39] SMalyshev: disabling the cache if flavor= is set would be the easiest fix [22:06:27] SMalyshev: Special:EntityData should handle If-Modified-Since properly, btw. [22:06:44] and varnish should pass it through afaik [22:08:12] can anyone check my merge candidates ? [22:08:13] can you bypass the cache by setting IMS? would be kind of the inverse of it's original purpose ;) [22:08:42] api, Special:Merge and quickstatements can't merge but only merge.js does the merge [22:08:59] DanielK_WMDE: IMS? [22:10:31] aude: DanielK_WMDE: Can I have a quick review for https://gerrit.wikimedia.org/r/274506 (configuration one liner) ? :) [22:10:31] if-modified-since? maybe but if I knew I need to bypass cache I could do that by adding something like ?nocache=$time, but it's be nice to make it work properly with purging and caching [22:10:45] I've 304 candidates , hard to do manually :/ [22:11:38] to clarify, api and quickstatements does the merge, but redirect fails [22:14:23] hoo: i don't have +2 there, and i probably shouldn't ;) [22:14:42] SMalyshev: IMS = If-Modified-Since [22:14:43] DanielK_WMDE: I just want a +1 [22:14:55] I can deploy it myself, but will probably rather sign it up for SWAT tonight [22:15:35] hoo: like that? [22:15:52] Yeah, guess that is enough [22:16:42] putnik: Around? [22:17:33] hoo: sorry for that ;) [22:18:18] Last week I broke all test wikis by syncing out a variable with missing $... just want to guard against knocking stuff out [22:23:03] hoo: let's hope null is actually the correct value then. Maybe it expects false instead :D [22:23:14] DanielK_WMDE: I checked [22:23:19] but that actually throws on false [22:23:23] I didn't :O [22:23:43] thus set it to false and stuff will go sideways [22:23:50] yay for checking config variables! [22:23:55] (as that's hit on every page view that's not from parser cache) [22:24:15] hehehe... [23:57:22] hoo, hi =) [23:57:44] putnik: hey :) [23:57:56] I already posted it to your user talk page: https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%81%D1%83%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5_%D1%83%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0%BA%D0%B0:Putnik#MediaWiki:Sidebar-related.js_api_call [23:58:16] Guess that will improve client performance on ruwiki by a fair bit :) [23:58:17] I removed API request, hope that everything will be alright. [23:59:27] We have usage statistics for that api module at https://grafana.wikimedia.org/dashboard/db/wikidata-api-wbgetclaims [23:59:46] will probably take two days to be reflected there, but I guess we're going to see a big dip