Build and Update

Build and Update

Aktueller Stand 16.10.2026

Verbindlich: main@8fb581b730f7a3833566c4bbb7c87875ad921e69; veröffentlicht bleibt v1.9.0. PR #74–#97 sind integriert. Deployment/Discovery, Imagebuilder, Pi-VPN und Syslog sind auf main, nicht mehr nur historische Vorschau. 26 reguläre Rollen einschließlich Deployment-VM; Provisioning ist optional zusätzlich.

Betreiberbestätigt: KDE-Boot, Rufe, SDS, Aufnahme/RF-Wiedergabe und WLAN am 13.10.; 28/28 Discovery-Agenten aktualisiert und keine ungeklärten Remote-Aufträge mehr am 15.10. Ein aktueller Backend-Gesamtrollout, NAS-Entlastung, SIP/Telegram, VPN-Wechsel und Dauerlauf bleiben separat offen. Vier alte Git-/Timeoutfehler bleiben Fehler.

Gesamtroadmap · Upstream-Vergleich · Roadmap und Releases. NETCORE-IAM-01 ist weiterhin Planung; AD-SSO-Pilot und Gruppenmapping sind konkretisiert, Produkt-/Betriebsentscheidung und Umsetzung offen.

Aktuelle Updates erhalten Konfiguration, Units und Nutzdaten, bauen vor dem Diensttausch und prüfen Dateihashes/Prozessbelege. Für die Flotte, VM und exakten Quittungsabgleich gilt die aktuelle Updateanleitung.

Kanonische aktuelle Fachanleitung.

Historischer Seitenstand bis 07.10.2026

Die folgende frühere Fassung bleibt als datierte Historie erhalten. Frühere Dienstzahlen, Featurebranch-Aussagen, offene Tests und Prioritäten sind keine aktuelle Statusaussage; heutige Verfahren stehen oben beziehungsweise in den verlinkten kanonischen Docs.

Build, Update und Rollback

Aktueller Quellenstand 07.10.2026: main 990bffb2; Release weiterhin v1.9.0. PR #59 mit Hell/Dunkel ist integriert, PR #60 ergänzt Projektarchive. Nur main ist als Branch vorhanden. Deployment/Discovery, Imagebuilder, Pi-VPN und neuere Syslog-Pipeline bleiben ausschließlich am historischen Featurecommit bbf0397 vorhanden. Keine neue Live-Abnahme. Roadmap und Releases · Upstream-Vergleich

Aktueller Updateweg

PR #59 ist auf main; der frühere Branch feat/netcore-dashboard-design existiert nicht mehr. Alte Branchwechsel in den TBS- und Dienstanleitungen durch einen geprüften main-/SHA-Checkout ersetzen. Aktive Unit, ExecStart, Binary- und Konfigurationspfad erfassen; lokale Änderungen, Konfiguration und vorherige Binary sichern. Erst erfolgreich bauen, dann gezielt installieren und Fachfunktion prüfen.

Für das reine TBS-Designupdate MIGRATE_LOCAL_TTS_CONFIG=0 und DISABLE_LOCAL_PIPER=0 verwenden. Dienst-Updater können zusätzliche Konfigurationen verändern; gezielte Binary-/Python-Updates gemäß tatsächlicher Unit bevorzugen. Rückweg über die gesicherte passende Binary und den dokumentierten früheren Quell-SHA, ohne aktuelle Konfiguration pauschal zu überschreiben. Ein Checkout allein aktualisiert keinen installierten Dienst.

Ein Update beginnt mit Ist-Stand, Sicherung und Testplan. Die Basisstation und der LXC-Verbund haben unterschiedliche Installer; diesen Ablauf nur für die lokale TBS verwenden. Open-Lab-Deployment beschreibt die Backends.

Version und Arbeitsbaum

cd /opt/netcore-tetra
git status --short --branch
git rev-parse HEAD
git remote -v
git fetch --all --prune

Lokale Änderungen und installierte Konfiguration erhalten. Bei Branchwechseln oder divergierenden Branches kein reset --hard oder erzwungenes pull verwenden. Nach Sicherung kann für einen sauberen Tracking-Branch git pull --ff-only folgen.

TBS bauen und installieren

cargo build --release -p bluestation-bs
sudo systemctl stop tetra.service
sudo install -m 0755 target/release/bluestation-bs /usr/local/bin/bluestation-bs
sudo systemctl start tetra.service
sudo journalctl -u tetra.service -b -n 200 --no-pager

Die systemd-Unit muss diese Binärdatei und die tatsächlich geprüfte TOML starten. Nach Feature-/Toolchain-/nativen ABI-Wechseln oder rätselhaften Cache-Fehlern gezielt cargo clean und erneut bauen; das Löschen des gesamten Build-Verzeichnisses bei jeder kleinen Änderung ist nicht erforderlich. Default-Features umfassen Asterisk, Recording und Audio-Player. Common-Build-Errors

Abnahme und Rückweg

Version im Dashboard/Log, geladene Konfiguration, RF-/SDR-Erkennung, Registrierung, Gruppen-/Einzelruf, SDS, Audio und Release nach dem Neustart kontrollieren. Bei Fehlern die letzte kompatible Binärdatei und Konfiguration gemeinsam zurückstellen. Ein altes Binary mit migrierter Datenbank ist kein verlässlicher Rollback. Abnahme · Backup-and-Fallback

Dashboard-Updates können einen Quellcode-Updatevorgang anstoßen; die gleichen Sicherungs- und Prüfschritte gelten. Der Rust-Workspace-Wert 1.3.0 aus Cargo.toml ist nicht automatisch der Git-Release-Tag oder die Version eines entfernten Hosts. Projektstand

Release v1.9.0 und neu angelegte Historie

main wurde neu angelegt; frühere Stände bleiben über Archiv-Tags erhalten. Vor einem Wechsel lokale Änderungen und aktive Konfiguration sichern. Einen frischen Clone des Tags v1.9.0 oder expliziten Fetch/Detached-Checkout verwenden; keinen erzwungenen Pull als Standard. Cargo.lock ist repariert, Builds möglichst mit --locked ausführen. Workspace-Version und Release-Tag unterscheiden. Roadmap und Releases

Die Warn-Inbetriebnahme hat eine eigene Reihenfolge; Warnzentrale. Einen laufenden Funkprozess und Dienste nur im passenden Wartungsfenster aktualisieren.

Entwicklungsvorschau vom 28 September 2026

Entwicklungsvorschau vom 28.09.2026: Historischer Featurecommit bbf0397, Deployment-Komponente 0.2.3. Diese Funktionen sind noch nicht auf main und kein neuer Gesamtrelease. PR #57 wurde in den Entwicklungsbranch gemergt. Rollouts werden vor dem Versand auf einen vollständigen SHA fixiert. Bei verlorener POST-Antwort denselben Auftrag prüfen, nicht erneut auslösen. Git-index.lock wird nicht gelöscht; ein neuer verwalteter Clone kann verwendet werden. Hostrollen seit 0.2.3 begrenzen die betroffenen Dienste. Ein allgemeiner atomarer Rollback ist nicht vorhanden. Deployment-und-Discovery