Package Details: immich-cli 3.0.3-1

Git Clone URL: https://aur.archlinux.org/immich.git (read-only, click to copy)
Package Base: immich
Description: Self-hosted photos and videos backup tool (command-line client)
Upstream URL: https://github.com/immich-app/immich
Keywords: backup photos
Licenses: AGPL-3.0-only
Submitter: wabi
Maintainer: aliu
Last Packager: aliu
Votes: 25
Popularity: 2.43
First Submitted: 2022-12-30 11:41 (UTC)
Last Updated: 2026-07-18 21:47 (UTC)

Pinned Comments

aliu commented on 2026-01-17 21:44 (UTC) (edited on 2026-01-17 21:46 (UTC) by aliu)

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).

aliu commented on 2025-10-25 02:49 (UTC)

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 .

aliu commented on 2025-08-21 15:21 (UTC)

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.

aliu commented on 2025-06-30 02:49 (UTC) (edited on 2025-07-01 16:35 (UTC) by aliu)

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.

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 .. 33 Next › Last »

musta_ruhtinas commented on 2026-01-20 17:38 (UTC)

The following error occurs when building in a clean chroot after today's update:

dependencies:
+ three ^0.179.1

. prepare$ svelte-kit sync
. prepare: [dotenv@17.2.3] injecting env (0) from .env -- tip: ✅ audit secrets and track compliance: https://dotenvx.com/ops
. prepare: Done
Done in 23.5s using pnpm v10.24.0
/startdir/PKGBUILD: line 106: cd: server: No such file or directory
==> ERROR: A failure occurred in prepare().
    Aborting...
==> ERROR: Build failed, check /home/musta/chroot/musta/build
❌ Error: makechrootpkg failed for 'immich'.

jwh commented on 2026-01-19 01:25 (UTC)

@aliu on a separate issue though, npm is indeed missing in a chroot, could you add it to makedepends?

jwh commented on 2026-01-19 01:24 (UTC)

@aliu yeah, actually looks like aurto/makepkg lost its mind, looks like next release should have 1.0.0 support anyway, thanks

dmig commented on 2026-01-18 16:43 (UTC)

... but in this case is probably preferred over build failures.

This is exactly what I'm trying to tell. There is no other point of setting NODE_OPTIONS during build process.

AlD commented on 2026-01-18 16:18 (UTC)

Ah, I see. The problem though is that the default in NodeJS is meant to prevent swapping, which generally makes sense, but in this case is probably preferred over build failures.

aliu commented on 2026-01-18 15:52 (UTC) (edited on 2026-01-18 15:55 (UTC) by aliu)

@jwh vectorchord-immich provides vectorchord=$pkgver. It can be used to satisfy the vectorchord dependency.

@AID I get your argument with "unconditionally" now. I'll do that.

(That's not what I meant with -lt vs -gt, though. We know that exporting the flag increases the memory limit. So with -lt, the branching would say "increase the memory limit if available memory is lower than this number", which doesn't make sense to me since the condition's supposed to prevent allocating more memory than we have.

It was designed to not increase the memory allocation when there's 2 GB RAM, and do increase when there's >5 GB RAM. And if we matched the code snippet's 15 GB–gate, exporting the flag would be meaningless since the default would be 4 GB anyways.)

AlD commented on 2026-01-18 07:51 (UTC)

@dmig is right though, the condition should be true if the available memory is lower (-lt) than the threshold.

But the larger memory limit really should just be set unconditionally, because compilation is afaiu guaranteed to fail otherwise. According to the Medium article, the threshold to check against should also be 16 GB, not 5.

Maybe the code snippet from the Medium article is confusing?

  // Increase the heap size from 2GB to 4GB for 64-bit systems with physical
  // memory at least 16GB. The theshold is set to 15GB to accomodate for some
  // memory being reserved by the hardware.
  constexpr bool x64_bit = Heap::kHeapLimitMultiplier >= 2;
  if (v8_flags.huge_max_old_generation_size && x64_bit &&
      (physical_memory / GB) >= 15) {
    DCHECK_EQ(max_size / GB, 2u);
    max_size *= 2;
  }

You're correct that it's using >=, but that just means that these systems are taken care of already. The PKGBUILD needs to cover the remaining systems, i.e. the inverse condition.

But again, as there are only two states, just setting the higher memory limit unconditionally would have the exact same result.

jwh commented on 2026-01-18 03:55 (UTC)

The vectorchord dependency is a problem - vectorchord<1 is not resolvable as vectorchord is already 1.0.0 for a while and it would be nice if it was an optional dependency as postgres may not be on the same machine anyway. Alternatively, depend on vectorchord-immich?

aliu commented on 2026-01-18 02:59 (UTC) (edited on 2026-01-18 03:04 (UTC) by aliu)

Please see https://nodejs.org/en/learn/diagnostics/memory/understanding-and-tuning-memory#command-line-flags-for-memory-tuning . As it mentions, 4 GB is an increase from the default limit.

At the time https://medium.com/@ulrich.vdh/what-is-the-default-value-of-max-old-space-size-on-node-js-32fbd2e9fae9 was written, the default limit was 2 GB for systems either 32-bit or <15 GB of physical memory, and 4 GB otherwise.

dmig commented on 2026-01-17 23:26 (UTC)

Again, -gt in line 119 is WRONG:

# on 2GB ram:
$ [[ $(grep MemTotal /proc/meminfo | awk '{print $2}') -gt $((5 * 1024 * 1024)) ]] && echo node_options

# on 16GB ram:
$ [[ $(grep MemTotal /proc/meminfo | awk '{print $2}') -gt $((5 * 1024 * 1024)) ]] && echo node_options
node_options

It should be -lt!