In Tool-wdactle, I’ve worked around this by shipping my own mime.types file and configuring it in uwsgi.ini. But this seems pretty brittle (I’ll presumably have to remember to update mime.types if I want to add e.g. an SVG file or a favicon.ico) and also just cumbersome.

Tagging as Upstream because we do not build these base images locally.

Any volunteers for telling upstream about the issue? I can try to do it tomorrow, but I don’t know much about the build service infrastructure, so I might report it in the wrong place.

So far I’ve managed to reproduce working and broken container images (based on testing locally) with pack-cli build --builder tools-harbor.wmcloud.org/toolforge/heroku-builder:22 myimage and pack-cli build --builder tools-harbor.wmcloud.org/toolforge/heroku-builder:24_0.20.7 myimage respectively (run the image with docker run --rm -e PORT=8000 -p 8000:8000 myimage and then curl -I http://localhost:8000/index.js), though I’m not convinced upstream would accept that issue report given that it’s still using a Toolforge builder (by the looks of it).

Okay, it’s also reproducible with the upstream builders, pack-cli build --builder docker.io/heroku/builder:22 myimage and pack-cli build --builder docker.io/heroku/builder:24 myimage respectively.

You can install the media-types package using project.toml and then point uwsgi/gunicorn at it (it will exist under /layers rather than the root file system).

Sometimes the dependency resolution is wrong (it thinks the package is there, so skips it), that can be forced in the configuration as required (see https://github.com/cluebotng/external-redis/blob/main/project.toml for an example).

Is project.toml something all tools can use? I couldn’t find any documentation about it on Wikitech. (That repo looks like it’s meant to be deployed as a separate continuous job, not as a webservice?)

Anyway, given that upstream already merged a fix and seems to be releasing new image versions reasonably often, I’m fine with just keeping my current workaround for a couple more weeks.

In T403303#11140456, @LucasWerkmeister wrote:

Is project.toml something all tools can use? I couldn’t find any documentation about it on Wikitech. (That repo looks like it’s meant to be deployed as a separate continuous job, not as a webservice?)

project.toml is the --use-latest-versions replacement for an Aptfile to configure the apt buildpack. T394466: [build-service] remove legacy fagiani/apt 0.2.5 builder from `--use-latest-versions` stack

Thanks, that’s good to know (⇒ T403509). I take it documentation will appear once this version of the build service moves out of the --use-latest-versions flag, then :)

In T403303#11140540, @LucasWerkmeister wrote:

Thanks, that’s good to know (⇒ T403509). I take it documentation will appear once this version of the build service moves out of the --use-latest-versions flag, then :)

If you use Aptfile you will get a deprecation warning in the logs, which eventually leads you to the upstream docs.