[06:34:18] <samwilson>	 Good morning. I'm looking at T332450 and wondering if it's best to upgrade a VPS in-place, or to create a new instance and switch to that. I'd rather the latter I think.
[06:34:19] <stashbot>	 T332450: Upgrade ws-export VMs to Bullseye - https://phabricator.wikimedia.org/T332450
[07:08:46] <JJMC89>	 The advice I've seen is to make a new instance.
[07:09:34] <JJMC89>	 Upgrading in place would leave things like horizon saying it is still the old OS.
[07:11:27] <samwilson>	 Oh yeah, I didn't think of that. I'll make a new instance. It's a good opportunity to update the docs anyway and to make sure everything's still needed and working.
[07:19:17] <wm-bb>	 <Sufi> can one convert eml files to webm files on video2commons?
[10:01:26] <taavi>	 !log tools rebooting tools-sgeweblight-10-18, -24, -25, to get rid of a large number of jobs in deleting status
[10:01:30] <stashbot>	 Logged the message at https://wikitech.wikimedia.org/wiki/Nova_Resource:Tools/SAL
[15:47:36] <wm-bb>	 <chicocvenancio> Sufi  I don't think so. What do you mean convert eml files? (google says its an email message format)
[16:04:28] <wm-bb>	 <Sufi> Yeah, I was wondering if it's possible that it's the format that appears for videos downloaded from Outlook. (re @chicocvenancio: Sufi  I don't think so. What do you mean convert eml files? (google says its an email message format))
[16:04:40] <wm-bb>	 <Sufi> However, might be just the case that the person downloaded the email instead of the file
[16:08:22] <wm-bb>	 <chicocvenancio> I think so. EML can have video attachments, but video2commons certainly wouldn't know what to do with the EML wrapper. You might be able to extract the attachment from the eml file with an mail client and then upload the video file directly
[16:14:17] <bd808>	 An exchange between Amir1 and Yuvipanda on the fediverse today reminded me about how far we have come in Toolserver->Tool Labs->Toolforge technology and practices over the last ~10 years. I can't wait to see what the collective us does next. :) https://octodon.social/@bd808/111613211869164924
[16:35:12] <wm-bb>	 <Sufi> Makes sense, thanks 👍🏾 (re @chicocvenancio: I think so. EML can have video attachments, but video2commons certainly wouldn't know what to do with the EML wrapper. You might...)
[19:20:21] <wm-bb>	 <lucaswerkmeister> does anyone know why packages from my Aptfile https://gitlab.wikimedia.org/toolforge-repos/wd-shex-infer/-/blob/5c4e6e0148868fd16c294642c285b8006eb06454/Aptfile don’t seem to show up in the resulting container image?
[19:20:28] <wm-bb>	 <lucaswerkmeister> I build the image in the lucaswerkmeister-test tool using the command
[19:20:30] <wm-bb>	 <lucaswerkmeister> `toolforge build start https://gitlab.wikimedia.org/toolforge-repos/wd-shex-infer --ref k8s`
[19:20:51] <wm-bb>	 <lucaswerkmeister> and the build output shows that the Aptfile was recognized and various packages including jq and maven were installed
[19:21:25] <wm-bb>	 <lucaswerkmeister> but when I run the image, either via toolforge jobs or locally via docker run, `mvn` isn’t found, and apt can’t find the packages
[19:21:46] <wm-bb>	 <lucaswerkmeister> (local command: `sudo docker run -it --entrypoint bash tools-harbor.wmcloud.org/tool-lucaswerkmeister-test/tool-lucaswerkmeister-test:latest`)
[20:26:29] <taavi>	 @lucaswerkmeister: it seems like they are installed under /layers/fagiani_apt/apt/, but why they're not in $PATH is a mystery to me.
[20:29:26] <don-vip>	 Hi, I'm trying to setup my first Trove database. After requesting a quota upgrade in T353670, I was able to launch a 250GB instance which is "buiding" for 30 minutes now, I have no idea how long it should take, and if it's normal? The instance id is 42b452a9-446e-4a0a-828a-72c91dc228e5
[20:29:27] <stashbot>	 T353670: disk quota increase (+200 GB) for spacemedia Cloud VPS project - https://phabricator.wikimedia.org/T353670
[20:34:01] <don-vip>	 ah, it just became "healthy". I didn't expect it would take 40 minutes, sorry for the noise
[20:34:22] <dhinus>	 don-vip: it can take a long time yes, and sometimes it does not complete... but I'm glad it worked this time :)
[20:34:47] <dhinus>	 there is some formatting going on that takes longer the bigger the drive is
[20:34:58] <don-vip>	 ok :)
[21:34:03] <wm-bb>	 <lucaswerkmeister> taavi: good find… but I can’t run them from there either, I guess the ld path isn’t right or something
[21:34:04] <wm-bb>	 <lucaswerkmeister> `/layers/fagiani_apt/apt/usr/bin/jq: error while loading shared libraries: libjq.so.1: cannot open shared object file: No such file or directory`
[21:34:58] <bd808>	 @lucaswerkmeister: maybe you can figure something out from poking around in https://gitlab.wikimedia.org/repos/cloud/toolforge/apt-buildpack
[21:37:22] <wm-bb>	 <lucaswerkmeister> `source /layers/fagiani_apt/apt/.profile.d/000_apt.sh` defines some extra variables
[21:37:32] <wm-bb>	 <lucaswerkmeister> adding the fagiani_apt layer to PATH, LIBRARY_PATH, CPPPATH and others
[21:37:44] <wm-bb>	 <lucaswerkmeister> still results in the “libjq.so.1: cannot open shared object file: No such file or directory” error though
[21:46:22] <wm-bb>	 <lucaswerkmeister> hm, there’s genuinely no *libjq* in the image o_O
[21:48:46] <wm-bb>	 <lucaswerkmeister> okay, and maven doesn’t work because `/layers/fagiani_apt/apt/usr/share/maven/bin/m2.conf` is a symlink to `/etc/maven/m2.conf`, which doesn’t exist
[21:49:13] <wm-bb>	 <lucaswerkmeister> I don’t think arbitrary Debian/Ubuntu packages are expected to work in a non-root subdirectory just by adjusting a handful of env variables
[21:49:18] <wm-bb>	 <lucaswerkmeister> but this apt buildpack seems to assume that?
[21:49:31] <wm-bb>	 <lucaswerkmeister> unless it’s just a bug that the layer isn’t overlaid on `/` or something
[21:58:25] <bd808>	 it does all look a bit goofy
[22:25:25] <wm-bb>	 <lucaswerkmeister> the jq issue seems to be because libjq1 is a separate package, which for some reason wasn’t downloaded and installed (I can’t really figure out why)
[22:26:34] <wm-bb>	 <lucaswerkmeister> hm, the build output says “0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 26 not upgraded.” for jq
[22:26:45] <wm-bb>	 <lucaswerkmeister> it sounds like that apt runs on a system where jq is already installed?
[22:26:55] <wm-bb>	 <lucaswerkmeister> so it (re)downloads the jq package itself into the apt buildpack’s custom apt cache
[22:26:59] <wm-bb>	 <lucaswerkmeister> (from where it’s later installed into the image layer)
[22:27:03] <wm-bb>	 <lucaswerkmeister> but not any of its dependencies
[22:27:54] <wm-bb>	 <lucaswerkmeister> may I ask how well we’ve tested this apt buildpack anyway?
[22:28:00] <wm-bb>	 <lucaswerkmeister> since the readme says that “This buildpack is experimental and not yet intended for production use”
[22:28:12] <wm-bb>	 <lucaswerkmeister> I’m wondering if i’m running into particularly unusual corner cases
[22:28:20] <wm-bb>	 <lucaswerkmeister> or if it’s just not that good
[22:33:53] <bd808>	 @lucaswerkmeister: I think you can reasonably assume that it is buggy. 
[22:35:42] <bd808>	 Raymond_Ndibe: https://wikicontrib.toolforge.org/ seems to be having problems. Likely really https://contraband.toolforge.org that is struggling based on what I see in my browser console.
[22:37:13] <wm-bb>	 <lucaswerkmeister> bd808: alright, then I guess I’ll create a phab task to track that ^^
[23:06:24] <wm-bb>	 <lucaswerkmeister> filed T353847
[23:06:38] <wm-bb>	 <lucaswerkmeister> (https://phabricator.wikimedia.org/T353847 if we don’t have a link bot around here)
[23:07:06] <wm-bb>	 <lucaswerkmeister> the title is pretty meh tbh, it’s really just a list of things I found so far that aren’t working