[00:48:41] <Геннадий> 0⁰00 [09:52:51] !log lucaswerkmeister@tools-bastion-13 tools.lexeme-forms deployed f28c3414ad (upgrade dependencies, including Werkzeug 3.1.0); also upgraded pip from 24.2 to 24.3.1 [09:52:54] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.lexeme-forms/SAL [13:29:57] if someone has some spare time, can someone email me at @toolforge.org and @tools.wmflabs.org, separately? (Trying to figure out if I've got wrong settings or a bug) [13:31:20] (subject and body doesn't really matter) [13:38:43] revi: done [13:39:48] thanks, turns out my filter was wrong [13:40:15] (I was still targeting `mail.tools.wmflabs.org`) [14:01:06] !log lucaswerkmeister@tools-bastion-13 tools.lexeme-forms deployed 4fdd9491ee (improve Wikifunctions UI) [14:01:09] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.lexeme-forms/SAL [16:54:03] !log lucaswerkmeister@tools-bastion-13 tools.lexeme-forms deployed a6768b885c (add setting for using Wikifunctions) [16:54:06] Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.lexeme-forms/SAL [18:06:12] Hi, I went into the node18 shell in Toolforge. And ran `npm install` in my codebase. It seems it is broken because process is being Killed in middle of package install so there is not node_module directory. [18:06:12] tools@shell-1730569510:~/frontend$ npm install [18:06:12] Killed#⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂) ⠴ idealTree:webpack: timing idealTree:node_modules/webpack Completed in 545ms [18:07:06] I am using `toolforge webservice node18 shell` in Toolforge. [18:21:12] you could try to run the webservice command with a higher -mem option [18:21:17] e.g. -mem 1g [18:21:26] “Killed” might be an out-of-memory error [18:21:44] (though it’s generally surprising to see this in an `npm install` tbh… I wonder if npm is trying to build some C package from source?) [18:27:16] Okay, let me check with higer mem option. [18:32:16] toolforge webservice node18 shell -m 1g [18:32:17] usage: toolforge webservice [-h] [--template TEMPLATE_FILE] [-m MEMORY] [-c CPU] [-r REPLICAS] [--buildservice-image BUILDSERVICE_IMAGE] [18:32:17] [--mount {all,none}] [--health-check-path HEALTH_CHECK_PATH] [-f] [-l LAST] [18:32:18] [TYPE] ACTION [... ...] [18:32:18] toolforge webservice: error: argument -m/--mem: 1g is not a valid Kubernetes quantity [18:32:38] I tried both -m and --mem [18:33:59] try 1G then [18:34:11] (I thought I’d seen lowercase but maybe that was back on the grid) [18:34:53] it might want it as '1Gi' [18:35:07] 1G worked. [18:35:27] yay [18:41:14] Thank you so much Lucas. `npm install` worked well with higher memory. [18:54:13] Hi, Can I run a self-hosted runner from GitHub Actions Runner on toolforge, to run code tests on the toolforge server, just asking to make sure this doesn't violate the terms of use? [19:20:26] Do anyone know how to back database? It seems mysqldump is not working. [19:20:51] https://wikitech.wikimedia.org/wiki/Help:Toolforge/Database#ToolsDB_Backups [19:21:13] I mean mysqldump is not there at all. [19:22:02] > ~$ mysqldump -u -p toolwatch > db_backup.sql [19:22:03] bash: mysqldump: command not found [19:24:17] huh. true. that means my backups have been broken for a while true [19:24:29] *too [19:25:33] I guess “The Kubernetes image mariadb can be used for that” now means “*must* be used for that”? [19:25:59] but that’s probably worth a phabricator task imho [19:28:01] the mariadb images should probably just be renamed "common unix tools" [21:08:46] Created one: https://phabricator.wikimedia.org/T378882 (re @lucaswerkmeister: but that’s probably worth a phabricator task imho) [21:10:09] You could port forward through SQL and then dump out the data that way ? (re @gopavasanth: Created one: https://phabricator.wikimedia.org/T378882) [21:12:25] possibly looks like a workaround for now... will give a try (re @sohom_datta: You could port forward through SQL and then dump out the data that way ?) [21:32:12] thanks! (re @gopavasanth: Created one: https://phabricator.wikimedia.org/T378882)