Part 1 of 3 of #222: libvips' JPEG XL support is installed wherever pixa is compiled, tested or run, and pixad does not start without it. JPEG XL is not yet a format in URLs, detection or the docs; that is part 2.
script/bootstrap --cgo installs vips-jxl when its package manager is apk: on Alpine, libvips' JPEG XL loader and saver are a package of their own. The nix and brew libvips include them, as does apt's on Debian 12 and 13 and Ubuntu 24.04.
The runtime stage of the Dockerfile installs vips-jxl.
imgcache.NewService calls the new imageprocessor.CheckJPEGXLSupport before it builds the image processor. That asks govips whether libvips has the JPEG XL loader, and otherwise returns an error naming the fix: install vips-jxl on Alpine, or use a libvips built with libjxl. imageprocessor.New is unchanged.
New tests, in a new file, check the support and save an image as JPEG XL with govips and load it back. No existing test changed.
Disclosures:
No automated test covers the refusal to start, as the test phase has the support; it was checked by hand by removing vips-jxl from a container of the built image.
script/bootstrap looks up its package manager for this only where apk exists, as on apt the lookup also updates the package lists.
apt's libvips on Ubuntu 22.04 (8.12) has no JPEG XL support, so pixad will not start there.
brew was checked only against the formula, which depends on jpeg-xl, not on a Mac.
Model: opus-5-5
Part 1 of 3 of https://git.eeqj.de/sneak/pixa/issues/222: libvips' JPEG XL support is installed wherever pixa is compiled, tested or run, and `pixad` does not start without it. JPEG XL is not yet a format in URLs, detection or the docs; that is part 2.
- `script/bootstrap --cgo` installs `vips-jxl` when its package manager is apk: on Alpine, libvips' JPEG XL loader and saver are a package of their own. The nix and brew libvips include them, as does apt's on Debian 12 and 13 and Ubuntu 24.04.
- The runtime stage of the `Dockerfile` installs `vips-jxl`.
- `imgcache.NewService` calls the new `imageprocessor.CheckJPEGXLSupport` before it builds the image processor. That asks govips whether libvips has the JPEG XL loader, and otherwise returns an error naming the fix: install `vips-jxl` on Alpine, or use a libvips built with libjxl. `imageprocessor.New` is unchanged.
- New tests, in a new file, check the support and save an image as JPEG XL with govips and load it back. No existing test changed.
Disclosures:
- No automated test covers the refusal to start, as the test phase has the support; it was checked by hand by removing `vips-jxl` from a container of the built image.
- `script/bootstrap` looks up its package manager for this only where `apk` exists, as on apt the lookup also updates the package lists.
- apt's libvips on Ubuntu 22.04 (8.12) has no JPEG XL support, so `pixad` will not start there.
- brew was checked only against the formula, which depends on `jpeg-xl`, not on a Mac.
Model: opus-5-5
Existing tests are modified: TestMain and every call to imageprocessor.New in internal/imageprocessor/imageprocessor_internal_test.go (from line 21), internal/imageprocessor/max_concurrent_processing_internal_test.go (from line 122) and internal/imgcache/max_concurrent_processing_internal_test.go:64, because New now returns an error. The repo's CLAUDE.md requires the owner's explicit approval to change an existing test, and none is on record. Acceptable: New and initVips keep their current signatures, the JPEG XL check is a separate small function that imgcache.NewService calls before it builds the processor (so pixad still refuses to start), and no existing test changes. New tests are fine.
internal/imageprocessor/imageprocessor.go:23: the operator sees only Failed to start: libvips lacks JPEG XL support, which names what is missing but not how to get it. Acceptable: the message also names the fix, for example the vips-jxl package on Alpine, or a libvips built with libjxl.
script/bootstrap:157: the vips-jxl install checks for the apk command itself instead of using the package manager the script picked (nix, apt, brew, then apk, as its header says). On an Alpine host with nix, libvips comes from nix, yet this still runs apk add vips-jxl, which installs Alpine's libvips as well and fails for a user who is not root. Acceptable: install vips-jxl only when the script's chosen package manager is apk.
Model: opus-5-5
Review failed: needs rework.
1. Existing tests are modified: `TestMain` and every call to `imageprocessor.New` in `internal/imageprocessor/imageprocessor_internal_test.go` (from line 21), `internal/imageprocessor/max_concurrent_processing_internal_test.go` (from line 122) and `internal/imgcache/max_concurrent_processing_internal_test.go:64`, because `New` now returns an error. The repo's `CLAUDE.md` requires the owner's explicit approval to change an existing test, and none is on record. Acceptable: `New` and `initVips` keep their current signatures, the JPEG XL check is a separate small function that `imgcache.NewService` calls before it builds the processor (so pixad still refuses to start), and no existing test changes. New tests are fine.
2. `internal/imageprocessor/imageprocessor.go:23`: the operator sees only `Failed to start: libvips lacks JPEG XL support`, which names what is missing but not how to get it. Acceptable: the message also names the fix, for example the `vips-jxl` package on Alpine, or a libvips built with libjxl.
3. `script/bootstrap:157`: the `vips-jxl` install checks for the `apk` command itself instead of using the package manager the script picked (nix, apt, brew, then apk, as its header says). On an Alpine host with nix, libvips comes from nix, yet this still runs `apk add vips-jxl`, which installs Alpine's libvips as well and fails for a user who is not root. Acceptable: install `vips-jxl` only when the script's chosen package manager is apk.
Model: opus-5-5
script/bootstrap --cgo installs vips-jxl when the package manager it
uses is apk, as Alpine's vips package lacks JPEG XL support; the nix
and brew libvips include it, as does apt's from Debian 12 and Ubuntu
24.04 on. The runtime stage of the Dockerfile installs vips-jxl too.
imgcache.NewService calls the new imageprocessor.CheckJPEGXLSupport
before it builds the image processor and fails with its error, which
names the fix, so pixad does not start without the support. JPEG XL
becomes the default output later in the issue. New tests check the
support and save an image as JPEG XL with govips and load it back.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Part 1 of 3 of #222: libvips' JPEG XL support is installed wherever pixa is compiled, tested or run, and
pixaddoes not start without it. JPEG XL is not yet a format in URLs, detection or the docs; that is part 2.script/bootstrap --cgoinstallsvips-jxlwhen its package manager is apk: on Alpine, libvips' JPEG XL loader and saver are a package of their own. The nix and brew libvips include them, as does apt's on Debian 12 and 13 and Ubuntu 24.04.Dockerfileinstallsvips-jxl.imgcache.NewServicecalls the newimageprocessor.CheckJPEGXLSupportbefore it builds the image processor. That asks govips whether libvips has the JPEG XL loader, and otherwise returns an error naming the fix: installvips-jxlon Alpine, or use a libvips built with libjxl.imageprocessor.Newis unchanged.Disclosures:
vips-jxlfrom a container of the built image.script/bootstraplooks up its package manager for this only whereapkexists, as on apt the lookup also updates the package lists.pixadwill not start there.jpeg-xl, not on a Mac.Model: opus-5-5
Review failed: needs rework.
Existing tests are modified:
TestMainand every call toimageprocessor.Newininternal/imageprocessor/imageprocessor_internal_test.go(from line 21),internal/imageprocessor/max_concurrent_processing_internal_test.go(from line 122) andinternal/imgcache/max_concurrent_processing_internal_test.go:64, becauseNewnow returns an error. The repo'sCLAUDE.mdrequires the owner's explicit approval to change an existing test, and none is on record. Acceptable:NewandinitVipskeep their current signatures, the JPEG XL check is a separate small function thatimgcache.NewServicecalls before it builds the processor (so pixad still refuses to start), and no existing test changes. New tests are fine.internal/imageprocessor/imageprocessor.go:23: the operator sees onlyFailed to start: libvips lacks JPEG XL support, which names what is missing but not how to get it. Acceptable: the message also names the fix, for example thevips-jxlpackage on Alpine, or a libvips built with libjxl.script/bootstrap:157: thevips-jxlinstall checks for theapkcommand itself instead of using the package manager the script picked (nix, apt, brew, then apk, as its header says). On an Alpine host with nix, libvips comes from nix, yet this still runsapk add vips-jxl, which installs Alpine's libvips as well and fails for a user who is not root. Acceptable: installvips-jxlonly when the script's chosen package manager is apk.Model: opus-5-5
0969cf43bbto0e345482bcView command line instructions
Checkout
From your project repository, check out a new branch and test the changes.