build: run one base across the whole stack (debian:trixie-slim) - #731
Conversation
HuggeK
changed the title
|
Cross-repo follow-up: the Home Assistant add-on builds Handled in srcfl/home-assistant-addons#6, which is marked blocked by this PR. Verified there on the real new base: fixtures build, the add-on image builds on top of them, and |
|
Alternative route now available as #746 — one Headline from building both in one session: the Alpine route consolidates only two of three images. Because |
256f939 to
6720ec1
Compare
6720ec1 to
f710031
Compare
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 01792f464b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // without tzdata. The failure it guards against is invisible — production | ||
| // code reads time.Local, and the tzdata tests skip rather than fail — so the | ||
| // ~450 KB is worth it. | ||
| _ "time/tzdata" |
There was a problem hiding this comment.
When /etc/localtime is unavailable and TZ is unset—as it is in the checked Compose configuration—importing time/tzdata does not protect time.Local: Unix initialization reads /etc/localtime and otherwise falls directly back to UTC, while embedded data is only consulted when loading a named zone. The exact missing-tzdata scenario described here therefore still silently mis-times code using time.Local; explicitly load/configure a named local zone rather than relying on this blank import.
Useful? React with 👍 / 👎.
| # major versions on some future rebuild. The `debian base currency` workflow | ||
| # watches for a new stable and files an issue, so the bump stays deliberate. |
There was a problem hiding this comment.
There is no debian base currency workflow—or any equivalent Debian-stable check—under .github/workflows in this commit. Because trixie is deliberately pinned, a future Debian stable release will not produce the tracking issue promised here, leaving the base on the old suite without the stated notification; either include the watcher or remove this assurance until it lands.
Useful? React with 👍 / 👎.
| This makes the container's own tooling agree with the host. Whether the FTW | ||
| process itself resolves a device's `.local` name is a separate question, | ||
| answered by `internal/mdnsresolve`. |
There was a problem hiding this comment.
The added troubleshooting guidance directs operators to internal/mdnsresolve, but a repo-wide search finds no such package or generated artifact. During an actual .local failure this leaves readers without the promised explanation; document the current static-core behavior and workaround, or land the resolver before referring to it.
AGENTS.md reference: AGENTS.md:L139-L140
Useful? React with 👍 / 👎.
srcfl#731 landed the base move itself, so this branch keeps only the part that was never in it: a check that notices when the pinned codename stops being what Debian calls stable. Dependabot cannot cover this. It orders numeric tags, and `trixie` is a codename with no numeric component — the same is true of the suite half of `python:3.12-slim-trixie`. It bumps the interpreter and leaves the suite alone. This reads Debian's own Release file for `stable` instead of a registry tag listing, and also fails when the three images stop agreeing on one suite, which is the whole reason they were aligned. Co-authored-by: HuggeK <48095810+HuggeK@users.noreply.github.com>
* build: follow Core and Optimizer onto the trixie base @ srcfl/ftw#731 moves the whole FTW stack onto Debian 13 "trixie". This repo inherits that automatically -- the add-on image is built FROM the Optimizer image -- so the change that matters here is the test fixtures, which stood in for Core and Optimizer on bookworm and would have gone on testing a base that no longer ships. Also say, once, why libnss-mdns is not installed here even though Core has it: it only forwards to avahi-daemon over a Unix socket, and Supervisor gives an add-on no way to bind an arbitrary host path. FTW resolves ".local" in-process instead, which is what host_network is for. Documented in DOCS.md for operators who hit a name that will not resolve. Co-authored-by: HuggeK <48095810+HuggeK@users.noreply.github.com> @ * docs: correct how `.local` resolves under Supervisor Tested on a pilot HA green instead of reasoning about it, and the earlier text was wrong in the way that matters. `.local` does not need anything from FTW here: Supervisor points every app at its own CoreDNS, which carries an mdns plugin backed by systemd-resolved, and that answers over ordinary unicast DNS. A lookup failure names it — "on 172.30.32.3:53". The avahi paragraph stands but for a further reason: HA OS runs no avahi at all. Its multicast plugin is mdns-repeater, a packet relay with no query API, so there is no socket to bind even in principle. Evidence: srcfl/ftw#728 (comment). Co-authored-by: HuggeK <48095810+HuggeK@users.noreply.github.com> * docs: say what `.local` resolution depends on, and what it does not Someone reading the previous version could reasonably ask which plugin they have to install. The answer is none, and that is worth stating rather than leaving implied. Supervisor hard-codes five built-in services and starts them itself (supervisor/plugins/manager.py: cli, dns, audio, observer, multicast). They are not add-ons — an app cannot install one, and cannot declare a dependency on one either. A failure there becomes a repairable system issue Supervisor raises on its own. The one real host requirement is systemd-resolved, which HA OS always has and which the Supervised installer's first step sets up. A host that skipped it resolves no .local names, so that case is called out with its workaround. Also documents the resolver address in the failure message, since seeing 172.30.32.3 is what separates "device is not there" from "resolution never got that far". Co-authored-by: HuggeK <48095810+HuggeK@users.noreply.github.com> * docs: qualify local-name network failures Signed-off-by: Fredrik Ahlgren <fredrik@sourceful-labs.com> --------- Signed-off-by: Fredrik Ahlgren <fredrik@sourceful-labs.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> Co-authored-by: Fredrik Ahlgren <fredrik@sourceful-labs.com>
2 participants
Warning
#746 is the alternative to this PR plus #728. Merge one route, never both.
#746 keeps core and updater on Alpine and resolves
.localin Go. This PRdeliberately leaves
.localto #728.Scope
This is the Debian base root for the container route from #730. It moves the
runtime of core and the updater to
debian:trixie-slim, and moves theoptimizer from
python:3.12-slim-bookwormtopython:3.12-slim-trixie.The builder stages remain Alpine Go toolchain images;
CGO_ENABLED=0keeps theGo binaries static. The runtime images use one Debian stable family and one
libc. The optimizer stays on Python/Debian because CVXPY and its solver stack
do not publish the required musllinux wheels.
This PR does not include #728, #733, #714, #746, #776, #777, #779 or #770.
The
.localresolver, Debian currency watcher, setup UI, overlappingcontainer work and host-OS patching stay separate.
Runtime changes
debian:trixie-slimwithca-certificates,tzdata,wgetandlibnss-mdns;wgetremains because the updater uses it as its readinessgate.
debian:trixie-slimwithca-certificatesandtzdata; Docker CLI27.5.1 and Compose 2.33.0 are copied from the official
docker:27-cli@sha256:851f91d241214e7c6db86513b270d58776379aacc5eb9c4a87e5b47115e3065cmulti-arch index. It stays root because it is the only sidecar allowed to
use the Docker socket.
100:101. GID 101 preserves accessto the optimizer socket and existing bind mounts.
retains the solver dependencies and runs a healthcheck as UID/GID
100:101.CA certificates and zoneinfo.
Validation
Rebased on
srcfl/ftw@a520ebbband pushed as commitf710031eon2026-08-04. The final PR diff is 10 files, 171 additions and 20 deletions;
there are no resolver, driver, web, Compose or host-update files. The two
review follow-ups are included: the
.localdocumentation names the actualgetentandwgettools in core, and the updater pins the Docker OfficialImages multi-arch index digest above.
make verifypassed: Go tests, 49 optimizer tests, external optimizer tests,Compose migration, boundary checks,
go vetand native build.make verify-allpassed: Linux arm64, Linux amd64 and Windows amd64cross-compiles.
linux/amd64,linux/arm64as local OCI manifests. The final manifestdigests were
sha256:1dcd1068e67c95497bc1bbdbfdc381c6f0112795ef5c3c78aba34bb411d9bfd0,sha256:99cc29d20412c208e9b9bd8fce0284bea6d6c708d2ab2c9ffd526cc1aac89265,and
sha256:42d1e30d6226805567810953f68bcf339df92ce7b869465073ae878ccc316306.CA bundle, zoneinfo, UID/GID, Docker CLI/Compose, and a CLARABEL solve using
CVXPY/HiGHS dependencies.
tree; no generated drivers are part of this PR.
Review and merge order
This PR remains draft. It needs a new independent review after the rebase,
including confirmation of the cross-repo Home Assistant add-on follow-up
(
srcfl/home-assistant-addons#6), before merge. After this root lands, rebase#728 and #733 separately; keep #714 after the resolver and human web review.
🤖 Generated with Claude Code