[08:59:00] <gehel>	 dcausse: I'll be 5' late for our 1:1
[08:59:07] <dcausse>	 np!
[08:59:23] <dcausse>	 taking a 5min break then :)
[10:15:40] <dcausse>	 lunch
[11:34:36] <pfischer>	 dcausse: Would you have a few minutes to discuss the deduplication approach with boost_factors, this afternoon?
[12:36:44] <dcausse>	 pfischer: sure, when you want
[12:38:38] <pfischer>	 dcausse: meet.google.com/uop-njxo-wfe
[12:47:10] <inflatador>	 <o/
[13:20:24] <dcausse>	 o/
[14:58:53] <ebernhardson>	 \o
[14:59:19] <dcausse>	 o/
[16:00:37] <inflatador>	 workout, back in ~40
[16:01:37] <gehel>	 dinner
[17:01:58] <inflatador>	 sorry, been back
[17:02:23] * ebernhardson now realizes ooui autocomplete never sends a session-start event
[17:03:14] <ebernhardson>	 it's extremely fun to have three different javascript autocomplete implementations to harmonize....
[17:17:34] <inflatador>	 ryankemper wcqs bullseye reimages are done in codfw, I'm starting eqiad now
[17:18:05] <ryankemper>	 inflatador: I'd meant to kick off the data transfer for 2003 but didn't do so last night. Have we done that yet?
[17:18:27] <ryankemper>	 I see it's re-pooled now so presumably so, but just checking
[17:18:28] <inflatador>	 ryankemper Y, I did it yesterday
[17:18:37] <inflatador>	 finished the manual steps this morning
[17:18:42] <ryankemper>	 excellent
[17:18:49] <ryankemper>	 ah I probably didn't need to depool it at all then! oh well :P
[17:19:05] <inflatador>	 no, it was good to depool it overnight, I wasn't done till today
[17:21:54] <ryankemper>	 then perfect!
[17:23:08] <inflatador>	 Y, sorry for not communicating that better yesterday
[17:27:04] <dcausse>	 dinner
[17:44:44] <inflatador>	 lunch, back in time for pairing
[18:24:16] <inflatador>	 back
[19:09:57] <inflatador>	 ebernhardson just for confirmation, https://qlever.cs.uni-freiburg.de/api/dblp is the correct URL for the whitelist? (and I guess https://qlever.cs.uni-freiburg.de/api/wikidata as well?)
[19:16:20] <ebernhardson>	 inflatador: yes. Verified by visiting the UI (ex: https://qlever.cs.uni-freiburg.de/wikidata/) and submitting a request
[19:26:29] <inflatador>	 Thanks, will get the PR up shortly
[19:40:02] <ebernhardson>	 kinda wish there was a simple way for browser testing event collection, while this data collection might work when it's first deployed who knows what it does the following week :(
[20:19:02] <inflatador>	 oops, looks like ryankemper beat me to the whitelisting. Will abandon my patch
[20:25:42] * ebernhardson wonders if browser testing could somehow inject javascript into the page that wraps event logging and provides a list of events to be returned to the test suite
[20:31:11] * ryankemper just noticed that the ticket had the correct URLs / query listed, but we just missed it (https://phabricator.wikimedia.org/T339347)
[20:34:14] <inflatador>	 yeah, I noticed that too ;(
[20:34:29] <inflatador>	 I created a ticket for the whitelist changes we talked about: https://phabricator.wikimedia.org/T343856
[20:39:20] <inflatador>	 hmm, looks like the query given in the ticket still doesn't work? https://w.wiki/6q2i
[20:40:11] <ebernhardson>	 inflatador: curious, we would have to check if there is a way to tell that api what kind of response we want
[20:40:29] <ebernhardson>	 I assume they are running qlever, would have to read some docs
[20:40:58] <inflatador>	 yeah, that part is beyond me...I hate to put it back on the submitter, but I think I'll do just that ;(
[20:41:44] <ebernhardson>	 the summary would be it's returning application/sparql-results+xml but we only know how to process application/sparql-results+json, application/qlever-results+json
[20:41:57] <ebernhardson>	 i would assume since their url has qlever in it they can return applicatoin/qlever-reseults+json, hopefully :)
[20:42:03] * ebernhardson fails typing
[20:42:45] <inflatador>	 Nah, that makes sense
[20:44:54] * ebernhardson is surprised to find qlever is c++
[20:45:01] <ebernhardson>	 nothing wrong with that, it's just not so common these days :)
[20:48:11] <inflatador>	 Yeah, only C++ thing that immediately comes to mind is envoy
[20:51:51] <ryankemper>	 https://www.irccloud.com/pastebin/COWjHrBM/
[20:52:17] <ryankemper>	 Seems like we're only getting `application/sparql-results+xml` as ebernhardson indicated
[20:52:59] <ebernhardson>	 more curious is i just double checked their sources, they default to application/sparql-results+json. So something is telling it to use xml.  This suggests we should be able to send an appropriate accept header, but i've now clue if we can configure blazegraph to send the right ones
[20:53:57] <ryankemper>	 really hope we don't end up having to fork blazegraph to support it :P
[20:53:59] <ryankemper>	 stepping out, lunch
[20:54:06] <ebernhardson>	 "The first media type in this list is the default, if no other type is specified in the request. It's "application/sparql-results+json", as required by the SPARQL standard."
[21:05:33] <inflatador>	 interesting...I would've thought BG could give json if asked, but clearly I haven't looked closely
[21:07:24] <inflatador>	 ryankemper just FYI, I repooled eqiad wcqs , but wcqs1003 is still depooled as it's reimaging now. I should be around long enough to see it finish, but if not you can follow https://wikitech.wikimedia.org/wiki/Wikidata_Query_Service#I've_got_a_new_WDQS_host,_how_do_I_get_it_ready_for_production? 
[22:31:28] <inflatador>	 ryankemper OK, wcqs1003 is back up and pooled...we can start on the rest of the wdqs servers Thursday if you like. See ya then
[23:49:32] <ryankemper>	 Thursday sounds good to me. Have a good say off