Arch Linux User Repository

is it possible to ship pre-built package?

Upstream recommends using docker, for which they have pre-built images (that might also work with podman).

PostgreSQL 18 is coming to the Arch repos. Before upgrading, backup the files for vectorchord and pgvector somewhere, and then follow https://wiki.archlinux.org/title/PostgreSQL#Upgrading_PostgreSQL instructions. (In the next release, I'll also update the postinstall message to recommend changing postgresql.conf instead of doing ALTER SYSTEM SET.)

Also, you may find yourself updating VectorChord in this process. When doing so, remember to follow the migration steps at https://docs.immich.app/administration/postgres-standalone/#updating-vectorchord .

immich-web (localhost/immich-server:2283) used to be broken for some users of this package.

As @yparitcher also noticed, this was most likely caused by the following additions to .gitignore from f4e0aad2c495, which have since be reverted:

src/
pkg/
*.pkg.tar.zst
LICENSES/

The reason—for both this change sometimes and unpredictably breaking the build, and builds under a clean chroot still working—is unknown. I meant to investigate this on 2025-08-19 while updating the package but called it a day due to the unpredictability and long time of building. Help with figuring out why this happened would be greatly appreciated.

You may notice pacman refuse to upgrade this package, saying warning: cannot resolve "vectorchord", a dependency of "immich-server".

This is due to required manual intervention within the immich server database.

Newer versions of immich server have deprecated pgvecto.rs in favor of vectorchord.

Before updating from 1.133.1 or older, please follow steps 1 and 2 of the manual migration steps (should be the second dropdown) at https://immich.app/docs/administration/postgres-standalone/#migrating-to-vectorchord and uninstall pgvecto.rs.

Remember to remove references to "vectors.so" (which is shipped by pgvecto.rs) in shared_preload_libraries before pgvecto.rs in uninstalled. (For vectorchord to work, you'll need to add "vchord.so" to shared_preload_libraries after the upgrade as well.)

After that, you may upgrade this package. Please remember to follow steps 4 and 5 of the manual migration steps after the upgrade is finished to prevent data loss.

Immich provides release files, I wonder if there is a prebuilt frontend there? Just to avoid building that mess:

--- Last few GCs --->

[25393:0x598a99c4c000]    49922 ms: Scavenge (interleaved) 472.4 (479.9) -> 471.1 (484.4) MB, pooled: 0 MB, 16.16 / 0.00 ms  (average mu = 0.208, current mu = 0.111) allocation failure; 
[25393:0x598a99c4c000]    50428 ms: Mark-Compact (reduce) 475.3 (484.4) -> 473.1 (479.6) MB, pooled: 0 MB, 110.03 / 0.00 ms  (+ 322.6 ms in 0 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 506 ms) (average mu = 0.244, c

<--- JS stacktrace --->

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

 1: 0x598a815eb9db node::OOMErrorHandler(char const*, v8::OOMDetails const&) [node]
 2: 0x598a81ab9f64 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [node]
 3: 0x598a81aba339 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [node]
 4: 0x598a81d0557c  [node]
 5: 0x598a81d055a4  [node]
 6: 0x598a81d1c8fe  [node]
 7: 0x598a81d1fb04  [node]
 8: 0x598a82772a67  [node]
/home/dmig/.cache/yay/immich/PKGBUILD: line 70: 25382 Aborted                 (core dumped) npm run build
==> ERROR: A failure occurred in build().
    Aborting...

Thank you for maintaining. According to https://v1.120.2.archive.immich.app/docs/install/environment-variables#database , both pgvector and pgvecro.rs should be supported. Additionally, can you separate immich-machine-learning into a separate sub package, so that it can be installed on different machines instead of being strongly dependent on the immich-server ontology using optdepends. Finally, I took over the maintenance of python-ftfy and python-insightface. Now, all the Python packages required for immich-machine-learning can be obtained from the official repository and AUR, and can no longer be installed in a virtual environment. I have tested it myself and it runs like this. All the required Python packages for immichh machine learning are as follows:

gunicorn
python-aiocache
python-fastapi
python-ftfy
python-huggingface-hub
python-insightface
python-onnxruntime
python-orjson
python-python-multipart
python-rich
python-tokenizers
uvicorn

There are several dependency packages for immich-machine-learning that have already been dependent on the packages mentioned above:

python-opencv
python-pillow
python-pydantic

v1.102.2-2 fixes software transcode and thumbnail generation for videos due to upstream PR. After @mertalev kindly made us aware of this, ffmpeg dependency was switched for jellyfin-ffmpeg - however since the latter depends on the former, both are installed and immich carried on using the standard version.

v1.102.2-2 forces usage of jellyfin-ffmpeg by using BindReadOnlyPaths= in the systemd service file.

If you have an failed thumbnails/transcoded videos, after upgrading, run the transcode video and generate thumbnail admin jobs for missing items.

@zynex I've been unable to reproduce this with immich v1.120.2 and openexr v3.3.2-1. Clean chroot build and installation hasn't thrown up any problems. Can you please check with this combination?

I've tried recompiling and it still has the libOpenEXR-3_2.so.31 error.

@zynex that sounds like recompiling Immich could fix it.

Just a note, the latest openexr v3.3.1 will break Immich. I had to downgrade to v3.2.4 to get it up and running again. It will fail with error ERR_DLOPEN_FAILED: libOpenEXR-3_2.so.31: cannot open shared object file: No such file or directory.

Thanks mertalev. Dependency now updated in 1.119.1-1.

Hi! Immich maintainer here. I see that this package uses the standard FFmpeg build as a dependency. We highly suggest using jellyfin-ffmpeg (https://archlinux.org/packages/extra/x86_64/jellyfin-ffmpeg/) instead for a number of reasons:

• We assume FFmpeg has been built with support for certain features and libraries
• We assume the custom filters and encoders added by the Jellyfin team are available
• This FFmpeg build has a number of important fixes and improvements not present in the standard build
• This is the build we use to test our transcoding pipeline

Importantly, release v1.120.0 will use a different SW tone-mapping filter not in the standard build. This means that unless jellyfin-ffmpeg is used, HDR videos will fail to transcode and thumbnails for these videos will fail to be generated in the default configuration.

Any one else experience issues with RAW-files (NEF in my case) using a low res thumbnail when generating previews? Have a thread on their GitHub regarding this (https://github.com/immich-app/immich/issues/13576), but the issue doesn't seem to affect the dev using Docker installation.

[EDIT] It seems to be an issue within the libvips, converting NEF files produces a small 160x120 image :P

Confirmed the error. Needed to rebuild libvips with -Dtiff=disabled option (the Docker installation from the devs is compiled with this option), after this the conversion works. I added a package to resolve this for those who needs it here https://aur.archlinux.org/packages/libvips-notiff.