[12:56:00] <wm-bot>	 !log lucaswerkmeister@tools-bastion-15 tools.lexeme-forms deployed 4bdcac2b61 (l10n updates: pa)
[12:56:04] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools.lexeme-forms/SAL
[23:31:52] <derenrich>	 am i right that toolforge only supports up to node20? it seems that's EOL soon?
[23:34:46] <lucaswerkmeister>	 I’m pretty sure the build service supports newer node versions, let me take a peek
[23:35:58] <derenrich>	 i just got "[step-build] 2026-01-22T23:24:53.430288880Z Couldn't resolve Node.js version: >=24.0.0 <25.0.0-0"
[23:36:34] <derenrich>	 `toolforge webservice --help` only lists 16, 18, 20
[23:36:34] <lucaswerkmeister>	 try adding --use-latest-versions to the `toolforge build start` command?
[23:36:53] <lucaswerkmeister>	 (the versions in `toolforge webservice --help` are unrelated to the build service, they’re for non-buildservice tools)
[23:37:01] <derenrich>	 well i'm trying to do this with a "toolforge.yaml"
[23:37:41] <derenrich>	 (the intent is to setup CD from gitlab)
[23:38:26] <lucaswerkmeister>	 but [step-build] sounds like you’re still using the build service?
[23:38:53] <lucaswerkmeister>	 (I don’t have any experience with toolforge.yaml yet… I look forward to testing it once it supports webservices)
[23:39:18] <derenrich>	 oh i thought it did support webservices...well this may all be for not then
[23:39:55] <lucaswerkmeister>	 not yet afaik
[23:40:00] <derenrich>	 ok thanks
[23:40:44] <lucaswerkmeister>	 anyway regarding the EOL-ness – Node 20 is apparently the version shipped by latest Debian stable (https://packages.debian.org/trixie/nodejs), so I think as far as we’re concerned it’ll remain supported (by Debian) for a while (even if upstream EOLs it)
[23:42:19] <wm-bb>	 <jeremy_b> that may be a problem if you're relying on something from npm? idk how much difference there is between 20 and 25
[23:44:30] <wm-bb>	 <jeremy_b> speaking of I've been wondering:
[23:44:31] <wm-bb>	 <jeremy_b> if you use software from Debian main then you should I think not have to worry about toolforge license compatibility. is there documentation or tooling for checking (automatically or otherwise if a given lockfile (npm or python or rust or whatever) uses any problematic licenses?
[23:48:08] <wm-bb>	 <jeremy_b> I did some searching a few weeks ago. now changed my search strategy and found this https://github.com/rethab/license-locker
[23:48:45] <wm-bb>	 <lucaswerkmeister> I’m trying to find out if unlicensed packages are even allowed on npmjs.com but it seems surprisingly difficult to get a straight answer
[23:48:46] <wm-bb>	 <jeremy_b> currently says it supports cargo and npm.
[23:49:01] <wm-bb>	 <lucaswerkmeister> (or non-freely licensed per OSI or whatever)
[23:49:19] <wm-bb>	 <lucaswerkmeister> but paragraph 4 of https://docs.npmjs.com/policies/open-source-terms#your-content sounds like non-free npm packages are possible, meh
[23:56:09] <wm-bb>	 <lucaswerkmeister> anyway, license check sounds like it could be built into the toolforge platform 🤔
[23:56:55] <wm-bb>	 <lucaswerkmeister> would fit relatively well into the build service; for non-buildservice tools it would be trickier (I guess you’d have to regularly scan ~/www/js/package.json etc. in NFS)
[23:58:36] <wm-bb>	 <lucaswerkmeister> only question is how tool developers will react when it blocks a build/deploy because some deeply nested dependency is technically not compliant – will they try to fix the issue in a way we’d want, or will they try to just circumvent the mechanism
[23:58:46] <wm-bb>	 <jeremy_b> toolforge already has a way for tools to record metadata. description, license, etc.
[23:58:47] <wm-bb>	 <jeremy_b> there could be a field for files to check for license and then authors could specify. (re @lucaswerkmeister: would fit relatively well into the build service; for non-buildservice tools it would be trickier (I guess you’d have to regular...)