Requesting manual test/test guidance from a maintainer, tests that fail in CI also fail on my local machine on the main branch (83cdccd) -- I can't determine if my changes actually cause test regression, or if tests are having unrelated issues.

Thanks for the PR and for maintaining the AUR package!

I looked into the sharp loading issue from the AUR comment, and I think this can be solved at the packaging layer without swapping dependencies.

The Issue

Sharp's bundled platform-specific binaries aren't being found during the AUR build/install process.

Recommended Fix (in the PKGBUILD)

Sharp's installation docs explicitly support using system libvips instead of bundled binaries - this is the standard approach for distro packages:

depends=('nodejs' 'org.freedesktop.secrets' 'libvips')  # Add libvips

package() {
  cd "${_pkgname}-${pkgver}"
  export SHARP_FORCE_GLOBAL_LIBVIPS=1  # Use system libvips, not bundled
  bun install
  bun run build
  install -Dm755 ./letta.js "$pkgdir/usr/bin/letta"
}

This way:

• Arch's well-maintained libvips package handles the native library
• No bundled binaries to worry about
• Sharp compiles against the system library at install time

Concerns About imgkit

We'd prefer not to replace sharp with imgkit because:

• imgkit was created 10 days ago (Jan 19, 2026) - it's a very new package
• Sharp is battle-tested with ~9M weekly downloads and a long track record
• Supply chain risk - swapping established dependencies for new/unknown ones is a common attack vector

If the PKGBUILD fix doesn't work, happy to discuss alternatives, but let's try the standard distro-packaging approach first.

👾 Generated with Letta Code

^ @ThatOneCalculator asked my letta code to drop a comment here, the tldr is trying to keep deps as tight as possible in this repo, and feel a little uneasy swapping a mainline dep with a low profile package, would much rather try to solve the issue w/ sharp if possible

@cpacker unfortunately, already had libvips as a dep (so no change there) and the SHARP_FORCE_GLOBAL_LIBVIPS=1 variable did nothing from what I can tell. Also, while imgkit is new, the agent said that it's 10 days old which is false.

There's also always jimp, which is battle-tested (1,868,037 weekly downloads), but it's slower than sharp -- although for this use case I don't think that's a big issue.

There's also always jimp, which is battle-tested (1,868,037 weekly downloads), but it's slower than sharp -- although for this use case I don't think that's a big issue.

Yeah I think the speed doesn't really matter much here, given we're talking about a TUI connected to an LLM ;)

Maybe one thing we could do is expose a build var that changes the dep for image resizing, and pass that for the AUR build? That way we keep the bundle size down / transitive deps as low as possible, but also unbrick the AUR build case (eg the AUR build could wire to jimp instead?). I think the callsites for the image operations is pretty narrow so intuitively this feels pretty reasonable to me.

Maybe one thing we could do is expose a build var that changes the dep for image resizing, and pass that for the AUR build?

If you're fine with that solution, then I'll just implement it using magick commands, which'll be simpler and faster!

Closing this PR, as I'll work on that solution in a new branch :)

Maybe one thing we could do is expose a build var that changes the dep for image resizing, and pass that for the AUR build?

If you're fine with that solution, then I'll just implement it using magick commands, which'll be simpler and faster!

Yeah just to clarify we're on the page, something like:

1. make a bun build flag like BYPASS_SHARP (default false, but turned on in your build process)
2. in the code, if this on, don't use sharp / attempt to import it, but do X instead (where X works on AUR)