[01:40:17] <kakakakwkw>	 Hi
[01:40:50] <kakakakwkw>	 Oi
[02:36:18] <andrewbogott>	 !log admin restarting mariadb on cloudcontrol1004
[02:36:20] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Admin/SAL
[04:27:06] <legoktm>	 I am wondering if anyone has already figured out a way to run tools requiring nodejs 14+ on Toolforge, whether compiling nodejs yourself or using a binary from elsewhere
[04:27:27] <legoktm>	 One of the upstream tools I run now requires it and the latest Toolforge has is nodejs 12 (from bullseye): https://github.com/matrix-org/mjolnir/releases/tag/v1.3.0
[04:27:55] <legoktm>	 It's not really a big deal for me right now to upgrade, but mostly curious if someone else has already done the hard work... :)
[06:59:10] <wm-bot>	 !log tools.mjolnir <legoktm> Updating uatu to v0.1.11
[06:59:12] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.mjolnir/SAL
[11:42:10] <urbanecm>	 !log tools.heritage Run `python erfgoedbot/update_database.py -countrycode:cz -langcode:cs` with 759229 applied to ensure fix for T300252 works
[11:42:14] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.heritage/SAL
[11:42:14] <stashbot>	 T300252: 78 datasets fail harvest because `"title() takes 1 positional argument but 2 were given` - https://phabricator.wikimedia.org/T300252
[12:30:46] <urbanecm>	 !log tools.heritage Run P19935 in `s51138__heritage_p` to workaround T300252 for Czech
[12:30:49] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.heritage/SAL
[12:30:50] <stashbot>	 T300252: 78 datasets fail harvest because `"title() takes 1 positional argument but 2 were given` - https://phabricator.wikimedia.org/T300252
[12:47:27] <wm-bot>	 !log tools.heritage <jeanfred> Deploy 2715e85 (T300252)
[12:47:31] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.heritage/SAL
[12:49:48] <wm-bot>	 !log tools.heritage <jeanfred> Trigger full update_monuments.sh run now that T300252 is fixed
[12:49:50] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.heritage/SAL
[16:22:01] <zabe>	 hmm, the 'next page' button is missing for me on https://sal.toolforge.org/production
[16:22:52] <Lucas_WMDE>	 “1 results” 🤔
[16:23:38] <Lucas_WMDE>	 but https://sal.toolforge.org/tools.sal says it was last touched on Jan 23rd, and I think I’ve seen a working “next” link since then
[16:40:12] <bd808>	 zabe: hmm... not sure what is going on there at the moment. I did double check that searches for prior days are working at least, but I agree that the missing pagination is not normal.
[17:04:53] <arturo>	 !log project-project add ws-export-test.wmcloud.org to XFF allowlist (af9e47341ad063f3f0c34b516f8963f7fe82cff9) (T279111)
[17:04:54] <stashbot>	 arturo: Unknown project "project-project"
[17:04:54] <stashbot>	 T279111: Request to enable XFF headers for wikisource VPS project - https://phabricator.wikimedia.org/T279111
[17:05:03] <arturo>	 !log project-proxy add ws-export-test.wmcloud.org to XFF allowlist (af9e47341ad063f3f0c34b516f8963f7fe82cff9) (T279111)
[17:05:04] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Project-proxy/SAL
[19:53:50] <musikanimal>	 hello Cloud Services! starting around 5 hours ago, xtools.wmflabs.org can't seem use PHP's `file_get_contents` on this meta page: https://meta.wikimedia.org/w/index.php?action=raw&ctype=application/json&title=MediaWiki:XTools-AutoEdits.json
[19:54:02] <musikanimal>	 it always returns `false` (meaning an error occurred)
[19:54:05] <taavi>	 musikanimal: https://phabricator.wikimedia.org/T300751
[19:54:17] <taavi>	 no, not that
[19:54:18] <taavi>	 sorry
[19:54:19] <taavi>	 wrong task
[19:54:23] <musikanimal>	 haha I was gonna say...
[19:54:30] <taavi>	 https://phabricator.wikimedia.org/T300366
[19:55:07] <taavi>	 I've tried pinging the relevant SREs a few times about that now without luck
[19:55:07] <musikanimal>	 hmm that's not the symptoms I'm seeing
[19:55:43] <taavi>	 file_get_contents uses http 1.0 underneath
[19:55:44] <musikanimal>	 my problem has nothing to do with images
[19:55:50] <musikanimal>	 ohhh, I see
[19:56:04] <musikanimal>	 well, why does it work xtools-dev.wmflabs.org and on my local?
[19:56:35] <taavi>	 they're probably hitting cp nodes that aren't running envoy
[19:56:37] <musikanimal>	 I thought maybe the public IP was blocked on Meta, but I checked and it is not
[19:57:09] <mutante>	 19:07 < taavi> fallout from their TLS termination experiments, envoy does not support http 1.0
[19:57:16] <mutante>	 that one?
[19:57:49] <taavi>	 mutante: that too, plus I pinged -traffic directly earlier today and during the weekend when I first saw it
[19:58:10] <mutante>	 ACK, just did that as well
[20:10:09] <musikanimal>	 do you think I could get around this problem temporarily using cURL or something else?
[20:11:50] <bd808>	 musikanimal: seems likely if the issue is lack of HTTP/1.0 protocol support
[20:14:26] <musikanimal>	 yep that seemed to work! thanks :)
[20:14:58] <bd808>	 In theory you could also use stream_context_create() to configure a context for file_get_contents() that told it to use HTTP/1.1
[20:15:08] <musikanimal>	 I of course had to check StackOverflow on what cURL options to set, etc.
[20:16:31] <bd808>	 :) No shame in that.
[21:32:01] <bd808>	 ohi ChanServ. welcome back :/
[21:33:51] <RhinosF1>	 It was a networking blip
[21:34:31] <bd808>	 *nod* I saw the WALL message
[23:22:48] <wm-bb>	 <bd808> I'm kind of amazed that the irc<->telegram bridge survived that netsplit without needing a restart. Putting a ZNC instance between the matterbridge software and libra.chat was a good thing. :)