wger: fix PowerSync SQLite import failing on admin.logentry (#3134) (#3135)

* wger: drop admin.logentry exclude from the PowerSync SQLite import (#3134)

wger does not install django.contrib.admin, so dumpdata rejected
--exclude admin.logentry with "Unknown model" and the import aborted.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* wger: README, say when /ps/ is unrouted and when wger refuses to start (#3134)

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

---------

Co-authored-by: BirdNET-Go Addon Builder <addon-builder@users.noreply.github.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Alexandre
2026-10-21 07:29:22 +03:00
committed by GitHub
parent e39427b13e
commit 09ca012050
4 changed files with 20 additions and 7 deletions

View File

@@ -1,3 +1,8 @@
## 2.8.0-dev.1.3 (2026-10-20)
- Fix the PowerSync SQLite import failing with `CommandError: Unknown model: admin.logentry`, which kept wger from starting. wger does not install Django's admin app, so the import no longer asks `dumpdata` to exclude its log table (#3134).
- README: correct when `/ps/` stays unrouted and when wger still starts. A wrong `wal_level` is detected only after wger is up, so `/ps/` then answers 502 rather than being unrouted (#3134).
## 2.8.0-dev.1.2 (2026-10-19)
- Fix `root is not in the sudoers file` at startup, which made the PowerSync SQLite import fail (and wger refuse to start), and stopped the JWT keys from being generated. The image's `/etc/sudoers` only allowed the `wger` user; it now allows root too (#3123).

View File

@@ -211,8 +211,15 @@ reason other than `wal_level`, the add-on log carries PowerSync's own error.
With everything in place the add-on log reports the PowerSync URL, and
`<SITE_URL>/ps/probes/liveness` answers instead of logging `Not Found: /ps/probes/liveness`.
If a prerequisite is missing the add-on still starts wger normally and the log says
exactly which variable is wrong; `/ps/` stays unrouted in that case.
If a variable is missing or invalid, the log says exactly which one and `/ps/` stays
unrouted. wger itself still starts, unless `PS_DATABASE_URI` points at Postgres while
there is SQLite data waiting to be imported: then it refuses to start, so the empty
Postgres database is not set up as a new instance. Fix the variable, or remove
`PS_DATABASE_URI` to go back to SQLite.
The `wal_level` check and the PowerSync storage setup only run once wger is up, after
`/ps/` is already routed. If either fails, the log says so, PowerSync is not started,
and `/ps/` answers `502 Bad Gateway` until you fix the cause and restart the add-on.
If you put your own reverse proxy in front of the add-on, nothing extra is needed: the
`/ps/` route forwards an incoming `X-Forwarded-Proto` unchanged and only falls back to

View File

@@ -27,5 +27,5 @@ schema:
slug: wger
udev: true
url: https://github.com/alexbelgium/hassio-addons
version: "2.8.0-dev.1.2"
version: "2.8.0-dev.1.3"
webui: "[PROTO:ssl]://[HOST]:[PORT:80]"

View File

@@ -333,14 +333,15 @@ import_sqlite_data() {
fi
# Dumped from the copy, with the tables Django rebuilds for itself left out: content
# types and permissions are recreated by migrate, and admin log entries and sessions
# point at them. --natural-foreign keeps those references resolvable; primary keys
# are deliberately kept as they are so the rows land unchanged.
# types and permissions are recreated by migrate, and sessions point at them. wger
# does not install django.contrib.admin, so there is no admin.logentry to exclude:
# naming it makes dumpdata fail with "Unknown model" (#3134). --natural-foreign keeps
# those references resolvable; primary keys are deliberately kept as they are so the
# rows land unchanged.
if ! sqlite_manage "$copy" dumpdata \
--natural-foreign \
--exclude contenttypes \
--exclude auth.Permission \
--exclude admin.logentry \
--exclude sessions.session \
--output "$dump"; then
bashio::log.error "PowerSync: reading the SQLite database failed, nothing was written to Postgres"