Arch Linux User Repository

CI's running now, lemme know if it gets outdated for some reason

Alternate versions

llama.cpp
llama.cpp-vulkan
llama.cpp-sycl-fp16
llama.cpp-sycl-fp32
llama.cpp-cuda
llama.cpp-cuda-f16
llama.cpp-hip

welp the AUR-team have disabled pushes altogether due to the recent attacks :/

the CI-jobs are still running so once they enable pushes again, the package will automatically be updated

sorry about the delay, I was waiting for this pr to be merged, which simplified building the webui, but now it should be working! lemme know if not otherwise :)

For those recently dealing with the broken UI when using this PKGBUILD, there are a couple of discussions related to it:

https://github.com/ggml-org/llama.cpp/issues/23379

https://github.com/ggml-org/llama.cpp/issues/23156

Adding the below lines made it work for me again. They were mostly lifted from the llama.cpp-vulkan PKGBUILD. Unlike llama.cpp-vulkan, I switched to LLAMA_BUILD_UI since LLAMA_BUILD_WEBUI is marked deprecated now: https://github.com/ggml-org/llama.cpp/blob/bb28c1fe246b72276ee1d00ce89306be7b865766/CMakeLists.txt#L118

@@ -18,6 +18,8 @@
 makedepends=(
   cmake
   git
+  nodejs
+  npm
   shaderc
   ninja
 )
@@ -51,8 +53,19 @@

 prepare() {
   ln -sf "${pkgname}-${pkgver}" llama.cpp
+  # Tailwind v4's oxide scanner walks up looking for the nearest .git to anchor
+  # .gitignore lookup. In AUR helpers (yay/paru) the parent .git is the AUR
+  # clone, whose .gitignore is `*` + an allowlist for PKGBUILD/.SRCINFO. That
+  # rule ignores tools/ui/src/lib/**/*.svelte, so Tailwind scans zero files and
+  # the built bundle.css ships without any utility classes. An empty .git in
+  # the extracted source tree stops the upward walk before that point.
+  mkdir -p "${pkgname}/.git"
 }
 build() {
+  pushd "${pkgname}/tools/ui"
+  npm ci
+  npm run build
+  popd
   local _cmake_options=(
     -G Ninja
     -B build
@@ -62,6 +75,7 @@
     -DBUILD_SHARED_LIBS=ON
     -DLLAMA_BUILD_TESTS=OFF
     -DLLAMA_USE_SYSTEM_GGML=OFF
+    -DLLAMA_BUILD_UI=ON
     -DGGML_ALL_WARNINGS=OFF
     -DGGML_ALL_WARNINGS_3RD_PARTY=OFF
     -DGGML_BUILD_EXAMPLES=OFF

True, that wouldn't hurt as a warning, I've added

NOTE: Running sudo userdel -r llama-cpp (with '-r' added) would nuke /var/lib/llama-cpp."

to post_remove, hopefully that's enough to prevent it (will be pushed on the next release)

All looks great, thank you! Yeah, I think it was just saying, hey if someone reads that post-remove and decides to add a -r, they might regret it. But, I think its good as is.

Oh wow, thanks a lot for the info, it was really helpful! I've updated the files (hopefully pushed by the time you're reading this) with your suggested changes (good catch on the pkgrel too) and added a notice when installing the package about where the model files should be stored

And yeah, my concern initially with the systemwide systemd service was that it then would have systemwide access too, but I guess that's why we're creating the llama.cpp user now lol

I'm not sure where Claude got userdel -r from, that wasn't in the original version either, so I didn't add any new notes to post_remove

One other thing, the pkgrel value should be reset back to 1, see:

https://wiki.archlinux.org/title/PKGBUILD#pkgrel

Awesome, that was fast, looking good, thank you so much! As I said, it has been a while since I did this stuff, and in full transparency, used claude to check your changes, and output also helped me remember different components that I had learned before.

I believe you can remove the post_upgrade function if you add Z /var/lib/llama-cpp 0750 llama-cpp llama-cpp - to the tmpfiles.conf. The uppercase will handle recursive for pre-existing installs. d and Z will handle a case of a fresh install after an uninstall with the directory still existing.

Reading the manpage, the group is auto-created using the u (or u!) in sysusers, so technically redundant if you want to remove the g line.

As for your last question, I'm not sure about deep reasons, but if the llama-cpp service is running as my login user, it would have all the permissions of my user, and access to all my files. Feels sketchy. Having it run as its own system user will limit what it can touch. Also, all the packages I see in the official repos use a system user, so :shrug: :) Best I can do is follow what I see others doing haha.

You may want to print a notice that the model files will now need to be accessible by the dedicated user for anyone using the systemd service. I used to have them in my home folder, but will be moving them to /var/lib/llama-cpp/., owned by llama-cpp:llama-cpp.

edit: one specific quote from claude,

Note: Suggesting userdel -r would nuke /var/lib/llama-cpp since it's set as the user's home directory in sysusers.conf. The instructions should recommend userdel llama-cpp (without -r) and mention removing /var/lib/llama-cpp as a separate step.

This sort of falls inline with calling pacman -Rn vs pacman -R. But, I'm not sure setting /var/lib/llama-cpp as a backup= in the PKGBUILD makes sense. imo just noting this in the post_remove is probably fine, at least until an official Arch Package Maintainer says/recommends to do something else.

It took me a while to figure out how to setup sysusers.conf and tmpfiles.conf (I'm dailying Artix Linux, so I rarely touch systemd lol), but I think I got it working now!

I wasn't sure if I should define the runtime directory in tmpfiles.conf or in the service file with RuntimeDirectory, but I choose the latter since it seemed more consistent with other services I could find. Please lemme know if it works for you and anything you think should be changed / is currently not best practices :)

(just a random thought: this would still require running the service systemwide (at least from my testing on a different machine), is there any reason not to prefer an user service?)

Could you please add a sysusers.conf and tmpfiles.conf, and run the systemd service as that user:group?

Besides the base level separation it would provide, llama.cpp allows listening on a unix socket instead of a network port. A dedicated group would allow limiting write permissions to members of the llamacpp group, or whatever you decide to name it (not sure if "." is allowed in a user or group name).

I've written these confs a long time ago for a package I used to maintain. If you are up to adding it and need help, I can re-learn and check for up-to-date implementation best practices and help out adding them.

Thanks!