Arch Linux User Repository

@almanac, Because of how open-webui is structured, and the docker-first approach upstream, it requires a fair bit of manual setup when starting the application, what with the environment variables and everything.

So basically, in order to un-dockerise and make it so that open-webui runs as applications are supposed to on Arch, and so that everyone doesn't need to fiddle with environment variables and such, we use a systemd service, so to start open-webui, you should run: sudo systemctl start open-webui.service

Secondly, the reason why you can't do a simple open-webui serve, and can't find open-webui in the PATH anywhere is due to the way this package is currently structured.

We're using a virtual environment to manage the Python dependencies required to run the application, because that was the way this was set up since before I was maintaining this PKGBUILD (open-webui-git is the original PKGBUILD, I just yoinked and un-git-ified it).

In my personal opinion, this is an ugly way, hence I tried to un-virtualenv it, but a few dependencies fail in the check() portion, so it was decided to keep the current approach to reduce user friction.

You can find the non-virtualenv package at open-webui-no-venv, which does work, apart from needing to comment out the check() portions of the PKGBUILD of the dependencies that are failing.

You can do a open-webui serve when using open-webui-no-venv, but the aforementioned environment variables still need to be set, so even then it's still recommended to use the systemd service, but it is technically possible to do it.

Hope this lengthy explanation helps.

Edit: I should probably pin this, so I'll do that.

Due to failing build dependencies, the rework has been reverted, as of 0.5.3-3. As suggested by @Davidyz, I've created a separate package, open-webui-no-venv, that uses the reworked PKGBUILD.

PSA everyone, I intend to rework major parts of the PKGBUILD and the way open-webui is installed on the system so that we can get rid of the virtualenv and the long time it takes to build on every install. Also, it should make it so that you don't need to do the things that I mentioned in the first pinned note.

I've tested the changes on my end, and you don't need to do anything when updating from the old way to the new way, it should work just fine as it is, but still, this is a major change. I'll be moving installing the python dependencies from inside a virtualenv to installing the python dependencies system-wide.

If there are any bugs after the rework, which will be updated as 0.5.3-2 pkgrel bump, which are related to open-webui itself, rather than it's dependencies, please add a comment, and I'll fix them, and if there are too many, or some are unfixable, I'll revert the rework.

Note to all existing users (those who will be upgrading the package, not installing it anew, people installing anew should be fine):

When major Python versions switch (as just happened with Python 3.12 -> 3.13), I believe it would be prudent to delete the virtual environment created by the backend, done so manually by doing a sudo rm -r /opt/open-webui/backend/venv, and then reinstalling the open-webui package, thus rebuilding the virtual environment with the new Python major version.

Just reinstalling the open-webui package without removing or uninstalling makes sure that your user data, that is used in openwebui, for e.g., your admin password, remains as it is.

As an addendum, this might be applicable when the python package itself is changed due to dependency mismatches (again, as just happened when I changed the dependency from python to python312, and would happen again once python 3.13 is supported upstream back to python from python312), I'm not so sure about this, so testing might be needed, but just to be safe, please do so as well.

This is so that any mismatches between the Python version that created the virtualenv and the Python version in use, and any problems that might arise from that, can be avoided.

@almanac, Because of how open-webui is structured, and the docker-first approach upstream, it requires a fair bit of manual setup when starting the application, what with the environment variables and everything.

So basically, in order to un-dockerise and make it so that open-webui runs as applications are supposed to on Arch, and so that everyone doesn't need to fiddle with environment variables and such, we use a systemd service, so to start open-webui, you should run: sudo systemctl start open-webui.service

Secondly, the reason why you can't do a simple open-webui serve, and can't find open-webui in the PATH anywhere is due to the way this package is currently structured.

We're using a virtual environment to manage the Python dependencies required to run the application, because that was the way this was set up since before I was maintaining this PKGBUILD (open-webui-git is the original PKGBUILD, I just yoinked and un-git-ified it).

In my personal opinion, this is an ugly way, hence I tried to un-virtualenv it, but a few dependencies fail in the check() portion, so it was decided to keep the current approach to reduce user friction.

You can find the non-virtualenv package at open-webui-no-venv, which does work, apart from needing to comment out the check() portions of the PKGBUILD of the dependencies that are failing.

You can do a open-webui serve when using open-webui-no-venv, but the aforementioned environment variables still need to be set, so even then it's still recommended to use the systemd service, but it is technically possible to do it.

Hope this lengthy explanation helps.

Edit: I should probably pin this, so I'll do that.

Hey I just installed this package however. According the webui docs I should be able to start the server with open-webui serve in the terminal but open-webui command does not exist. Or is not in my PATH. Is there a bug in this build or am I doing something wrong?

Hi, I had an issue with this package not updating properly for a while and turns out it was because the python3.12 symlink (and every other version specific symlink) in the venv pointed to venv/bin/python which pointed to /usr/bin/python. venv/bin/python is supposed to point to venv/bin/python3.12 and that to /usr/bin/python3.12 instead. In case anyone else has the same problem writing here

@klari, that's nice to hear, besides the build dependencies failing, everything with open-webui itself worked fine on my end too. But as @Davidyz said, perhaps it would be better to wait until the build dependencies issues are resolved.

Also, sudo pacman -Qtdq can list out packages that have been installed previously but are not needed now by any package, I'm pretty sure. It's been useful in the past in such situations.

Yeah @mistersmee, other than the failing builds, everything I used out of open-webui was working no problem. But, now I have several dozen explicitly installed packages that I'll have to remove, if the rework has been reverted. Not a huge problem to resolve, though.

And sure, I can go spread the word around.

Due to failing build dependencies, the rework has been reverted, as of 0.5.3-3. As suggested by @Davidyz, I've created a separate package, open-webui-no-venv, that uses the reworked PKGBUILD.

I can confirm the failed dependencies suggested by @klari. While it's worth reporting to the maintainers of those packages, this package remains unusable due to the broken dependencies (for both new users and existing users trying to upgrade). I suggest that this package should be reverted to using the old way of installing dependencies (with a virtual environment) until the dependency issue is resolved. If necessary, the refactored PKGBUILD with AUR dependencies can be a separate package that people can use to help and test it.

@klari, thanks for testing it out and letting us know, but it's slightly strange, I had problems with other packages, not those. I wasn't able to fix any of the problems with the fixes provided by the AUR package maintainers, but luckily there were -bin packages available for each, so I put the -bin version of those packages in open-webui's make dependencies: python-tensorstore-bin, python-jaxlib-bin, python-primp-bin and python-ctranslate2-bin.

What makes this slightly more frustrating is that none of these packages we even need to run open-webui, just need them to build dependencies that are actually needed, but oh well, such is Linux, sometimes.

Were there any problems other than the failing make dependencies, particularly with the package itself, did open-webui itself run and run fine, @klari?

Also, I would suggest commenting on the AUR packages that failed, letting the maintainers know that the check() portion fails, maybe they can fix something with the PKGBUILD on their end, or suggest some other fix.

I think I found some problematic dependencies when trying to build this major package rework on my system.

• python-chromadb
• python-colbert-ai
• python-datasets
• python-faster-whisper
• python-sentence-transformers
• python-transformers

because of the following make dependencies:

• python-multiprocess
• python-chex
• python-opentracing
• python-opentelemetry

Building the above four dependencies (especially the first two) failed at the check() stage. I "solved" this by manually installing each of open-webui's new dependencies (still through pacman, of course), and adding --nocheck on the critically-problematic make dependencies.

I don't know if anyone else can confer this behavior, but I thought I'd let you know just in case.

PSA everyone, I intend to rework major parts of the PKGBUILD and the way open-webui is installed on the system so that we can get rid of the virtualenv and the long time it takes to build on every install. Also, it should make it so that you don't need to do the things that I mentioned in the first pinned note.

I've tested the changes on my end, and you don't need to do anything when updating from the old way to the new way, it should work just fine as it is, but still, this is a major change. I'll be moving installing the python dependencies from inside a virtualenv to installing the python dependencies system-wide.

If there are any bugs after the rework, which will be updated as 0.5.3-2 pkgrel bump, which are related to open-webui itself, rather than it's dependencies, please add a comment, and I'll fix them, and if there are too many, or some are unfixable, I'll revert the rework.