@mistersmee That works, but I would install the data
directory with --mode=700
(or maybe 750
or 770
) since on a multiuser system you probably don't want other users being able to read those files.
Search Criteria
Package Details: open-webui 0.5.4-1
Package Actions
Git Clone URL: | https://aur.archlinux.org/open-webui.git (read-only, click to copy) |
---|---|
Package Base: | open-webui |
Description: | Web UI and OpenAI API for various LLM runners, including Ollama |
Upstream URL: | https://github.com/open-webui/open-webui |
Licenses: | MIT |
Conflicts: | open-webui-git |
Submitter: | mistersmee |
Maintainer: | mistersmee |
Last Packager: | mistersmee |
Votes: | 5 |
Popularity: | 3.68 |
First Submitted: | 2024-10-09 08:08 (UTC) |
Last Updated: | 2025-01-05 16:38 (UTC) |
Dependencies (5)
- python312AUR
- npm (corepackerAUR, python-nodejs-wheelAUR) (make)
- nvmAUR (nvm-gitAUR) (make)
- ollama (ollama-rocm-gitAUR, ollama-gitAUR, ollama-cuda-gitAUR, ollama-nogpu-gitAUR) (optional)
- tika-serverAUR (optional)
Required by (0)
Sources (3)
Latest Comments
« First ‹ Previous 1 2 3
dbb commented on 2024-11-22 14:00 (UTC)
mistersmee commented on 2024-11-22 10:26 (UTC)
@dbb, the latest version I pushed, 0.4.3-1 should fix this alongside being the latest upstream version, please test and see if it was fixed.
dbb commented on 2024-11-21 13:18 (UTC) (edited on 2024-11-21 13:19 (UTC) by dbb)
With a fresh install there's an peewee.OperationalError: unable to open database file
exception on startup. Seems to be because while the package installs /var/opt/open-webui
it does not install /var/opt/open-webui/data
. I created that directory, chown
-ed it to open-webui
, chmod
-ed it to 700
, and it seems to startup and run fine now.
Pinned Comments
mistersmee commented on 2025-01-05 15:52 (UTC)
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.mistersmee commented on 2025-01-03 11:45 (UTC)
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.
mistersmee commented on 2024-12-24 16:27 (UTC) (edited on 2024-12-26 07:20 (UTC) by mistersmee)
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
topython312
, and would happen again once python 3.13 is supported upstream back topython
frompython312
), 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.