* fix(wger): set the database env vars the upstream image stopped shipping
wger/server:latest no longer defines DJANGO_DB_ENGINE or DJANGO_DB_DATABASE in
its image environment, and upstream settings/main.py reads both with no
fallback. Every fresh install therefore died at startup with
"ImproperlyConfigured: Set the DJANGO_DB_ENGINE environment variable".
Set both explicitly in the Dockerfile, pointing at the sqlite database in
/data/database.sqlite that the add-on already persists, and add
DJANGO_PERFORM_MIGRATIONS=True so an existing database picks up new migrations
when the image is rebuilt against a newer upstream release.
With the path now set through the environment, the cont-init rewrite of the
database path in the Python settings is dead code — upstream no longer
hardcodes /home/wger/db/database.sqlite anywhere, so it only logged a warning.
Also move the add-on to the addon_configs location, as the issue asks: the
shared 01-config_yaml.sh template migrates an existing
/homeassistant/addons_config/wger/config.yaml on the first start.
Fixes#3043
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* docs(wger): use the ISO date format the rest of this CHANGELOG uses
The 2.6.4 heading was written 04-09-2026 while every other dated heading
in this file, and 22937 of the 23999 dated headings in the repo, use ISO
YYYY-MM-DD. Copilot flagged the inconsistency on #3044.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
* fix(linkwarden): stop installing packages Debian 11 no longer serves
The 2.16.2 updater build failed in the first RUN layer:
E: Failed to fetch .../sudo_1.9.5p2-3%2bdeb11u4_amd64.deb 404 Not Found
E: Failed to fetch .../vim-runtime_8.2.2434-3%2bdeb11u3_all.deb 404 Not Found
Debian 11 reached LTS end on 2026-08-31. Its bullseye-security index is frozen
at that date and still lists debs that deb.debian.org no longer serves; sudo is
one of them and still 404s on every deb.debian.org edge checked today, so the
build fails deterministically rather than transiently. Every package in
postgresql-16's own dependency chain that comes from bullseye-security was
checked and does fetch, so removing this first install unblocks the build.
None of the four packages is needed:
- vim was never used by the add-on.
- gnupg2 was only there for "gpg --dearmor"; apt reads the ASCII-armoured key
from /etc/apt/trusted.gpg.d/postgresql.asc directly.
- lsb-release was only there for "lsb_release -cs"; /etc/os-release carries
VERSION_CODENAME.
- sudo is replaced by su in the Postgres bootstrap, which is what the ente and
postgres_15 add-ons already use for the same job.
curl is already present in the upstream linkwarden image, so no install step is
needed before the PGDG repository is configured.
The su rewrite keeps the argv psql receives identical. Because "su -" starts a
login shell, the service call now uses an absolute path (the login PATH has no
/usr/sbin) and the bootstrap SQL is written to and read from /tmp rather than
the script's working directory.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(linkwarden): fetch bullseye-security from its origin, not the CDN
Dropping vim/gnupg2/lsb-release/sudo got the build past the first RUN, but
"apt-get install -y postgresql-16" then 404'd on its own dependencies, on arm64:
E: Failed to fetch .../glibc/libc-l10n_2.31-13%2bdeb11u14_all.deb 404
E: Failed to fetch .../exim4/exim4-base_4.94.2-7%2bdeb11u6_arm64.deb 404
E: Failed to fetch .../python3.9/libpython3.9-minimal_3.9.2-1%2bdeb11u7_arm64.deb 404
All three are 200 on security.debian.org, the origin that deb.debian.org is a
CDN alias for. The rot is per-file and moves: exim4-base was 404 during the
build and 200 minutes later, so retrying is a coin flip rather than a fix.
Rewrite the security suite in /etc/apt/sources.list to security.debian.org
before "apt-get update". The main suite is left on the CDN; it is intact, and
bullseye main is already on archive.debian.org whereas bullseye-security is not.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(linkwarden): feed the bootstrap SQL on stdin, and fix two comments
Review follow-up on the temp file, the Dockerfile comment and the CHANGELOG
wording.
The bootstrap SQL no longer goes through a file at all. Both reviewers objected
to the predictable root-written /tmp path; passing the statements to psql on
stdin removes the file rather than defending it, and is less code than either
the version being reviewed or the suggested mktemp. It also restores what the
original did before this branch: sudo ran "cat file | psql", so psql read the
statements from stdin then too.
The Dockerfile comment said "PGDATA repository" where it meant the PGDG apt
repository; PGDATA is the data-directory env var set two lines above, so the
wording was actively misleading.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* chore: record the shipped upstream release in updater.json
Each PR publishes an upstream version the updater bot had already selected
before CI reverted its commit, but updater.json still recorded the previous one.
The updater reads upstream_version as CURRENT and enters its update path
whenever it differs from the latest tag, so its next run would process the same
release again and derive a synthetic trailing-.1 version, producing a redundant
release, a duplicate CHANGELOG entry and a wasted build.
These values are exactly what the bot itself wrote in the reverted commit; this
restores its own record for a release now being shipped rather than choosing a
new one.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* fix(linkwarden): keep the Postgres password out of process arguments
CodeRabbit flagged that the password appears in the command string of the
password-setting call, and that the database-creation call reaches Postgres over
a TCP URI carrying the same password with sslmode=prefer. Both predate this
branch, but both lines are touched here.
Sending each statement to psql on stdin removes the password and the URI from
argv, and is shorter than either form it replaces: the escaped-quote nesting on
the ALTER USER call disappears with it.
The connection method is unchanged for the ALTER USER call, which already went
over the local socket as the postgres user. The database-creation call moves
from TCP to that same socket. This is safe by construction rather than by
assumption: the ALTER USER call runs first under "set -e" with no "|| true", so
the container cannot reach the second call unless socket access already worked.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
* fix(mealie): build the frontend with pnpm and the upstream lockfile
Upstream mealie migrated frontend/ from yarn to pnpm in v3.24.0 and deleted
frontend/yarn.lock. Our builder stage kept running "yarn install
--frozen-lockfile", which silently degraded to a fresh, unpinned resolution of
every dependency. That worked until a newer vuetify 4.x release dropped the
"vuetify/labs/rules" entry point, at which point "nuxt generate" failed with:
Rolldown failed to resolve import "vuetify/labs/rules" from
"virtual:nuxt:.nuxt%2Fvuetify-nuxt-plugin.client.mjs"
and the v3.25.1 updater build was reverted.
Mirror upstream's docker/Dockerfile frontend stage instead: node:24, a global
pnpm@11, and "pnpm install --frozen-lockfile" against the committed
pnpm-lock.yaml, so the dependency set is the one upstream tests. Also copy the
frontend tree with "cp -a frontend/." so dotfiles such as .nuxtignore come
across, and shallow-clone the tag.
Bumps the add-on to v3.25.1, the version the updater bot could not build.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* chore: record the shipped upstream release in updater.json
Each PR publishes an upstream version the updater bot had already selected
before CI reverted its commit, but updater.json still recorded the previous one.
The updater reads upstream_version as CURRENT and enters its update path
whenever it differs from the latest tag, so its next run would process the same
release again and derive a synthetic trailing-.1 version, producing a redundant
release, a duplicate CHANGELOG entry and a wasted build.
These values are exactly what the bot itself wrote in the reverted commit; this
restores its own record for a release now being shipped rather than choosing a
new one.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
2026-09-05 07:47:32 +02:00
8 changed files with 35 additions and 26 deletions
- Update to latest version from mealie-recipes/mealie (changelog : https://github.com/mealie-recipes/mealie/releases)
- Build the ingress frontend with pnpm and the upstream lockfile: upstream dropped frontend/yarn.lock in v3.24.0, so the previous yarn install resolved dependencies unpinned and the build broke on a vuetify release without "vuetify/labs/rules"
## v3.24.0 (2026-08-29)
- Update to latest version from mealie-recipes/mealie (changelog : https://github.com/mealie-recipes/mealie/releases)
- Fix the add-on failing to start on a fresh install with `django.core.exceptions.ImproperlyConfigured: Set the DJANGO_DB_ENGINE environment variable`. The upstream `wger/server` image stopped shipping database defaults, and `settings/main.py` reads `DJANGO_DB_ENGINE` and `DJANGO_DB_DATABASE` with no fallback, so the add-on now sets them explicitly to sqlite at `/data/database.sqlite` — the same location the previous startup rewrite produced, so existing databases keep working.
- Set `DJANGO_PERFORM_MIGRATIONS=True`, as upstream's own docker deployment does, so an existing database gets new migrations applied when the add-on is rebuilt against a newer upstream release.
- Drop the startup rewrite of the database path in the Python settings: upstream no longer hardcodes `/home/wger/db/database.sqlite` anywhere, so the rewrite silently did nothing and only logged a warning.
- ⚠ MAJOR CHANGE : switch to the new config logic from homeassistant. Your configuration file will have migrated from /config/addons_config/wger to a folder only accessible from my Filebrowser addon called /addon_configs/xxx-wger. This avoids the addon to mess with your homeassistant configuration folder, and allows to backup the options. Migration is automatic only for a config.yaml sitting at the default /config/addons_config/wger/config.yaml. If you had pointed CONFIG_LOCATION somewhere else inside the homeassistant config folder, or had a custom script at /homeassistant/addons_autoscripts/wger.sh, move the file to /addon_configs/xxx-wger/ by hand and update the option. Please be sure to update all your links ! For more information, see here : https://developers.home-assistant.io/blog/2023/11/06/public-addon-config/
## 2.6.3 (2026-08-01)
- Version renamed from `2.6-dev-3`, which Home Assistant could not order and therefore could not reliably offer as an update: every number of the previous version is kept, as a section of its own. The addon itself and the upstream version it tracks are unchanged
sed -i "s|/home/wger/db/database.sqlite|/data/database.sqlite|g""$settings_file"
done
else
bashio::log.warning "Unable to find Python settings containing database path under /home, skipping rewrite"
fi
#####################
# Adapt directories #
#####################
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
