Mitmachen
LibreScoot ist Open Source und freut sich über Beiträge. Die meisten Services sind in Go, das Dashboard-UI in Qt/C++. Das komplette OS-Image wird per Yocto zusammengebaut.
Voraussetzungen
- Go 1.25+ zum Bauen der MDB-Services
- Qt 6.4+ (Quick, QML, Svg, Network, Sql, Concurrent) und CMake 3.16+ für scootui-qt (Dashboard-UI)
- Docker für Yocto-Image-Builds
- Redis zum lokalen Testen der Services
- Linux-Host empfohlen; WSL2 reicht für die Go-Service-Entwicklung
Repository-Struktur
LibreScoot ist auf ~45 Repositories in der GitHub-Organisation librescoot verteilt. Die wichtigsten:
| Repo | Inhalt |
|---|---|
| librescoot/librescoot | Meta-Repo: Yocto-Build-System, Docker-Build-Skript, Release-Tooling |
| meta-librescoot | Yocto-Layer: Rezepte für alle Services und die OS-Konfiguration |
| scootui-qt | Qt-Dashboard-Anwendung |
| vehicle-service | Zentraler Fahrzeug-Zustandsautomat |
| redis-ipc | Gemeinsame Redis-IPC-Library für alle Go-Services |
Jeder Service ist ein eigenständiges Go-Modul mit eigenem Git-Repo und eigener Version-Tag-Historie.
Einen Go-Service bauen
Jeder Service hat ein Standard-Makefile. Build-Targets:
make build # Cross-Compile für ARM (Roller-Hardware) make build-host # Für den lokalen Rechner bauen (Entwicklung/Tests) make test # Tests ausführen make lint # golangci-lint ausführen make fmt # Code formatieren (gofmt)
Die Cross-Kompilierung zielt auf ARMv7 (MDB und DBC sind beide Cortex-A):
CGO_ENABLED=0 GOOS=linux GOARCH=arm GOARM=7 go build ...
Auf einen Test-Roller deployen
# ARM-Binary bauen make build # Auf den Roller kopieren (nach /data, nicht nach /tmp) scp bin/my-service root@<mdb-ip>:/data/my-service-test # Tauschen und neu starten ssh root@<mdb-ip> "systemctl stop librescoot-my-service \ && cp /data/my-service-test /usr/bin/my-service \ && systemctl start librescoot-my-service" # Logs ansehen ssh root@<mdb-ip> journalctl -u librescoot-my-service -f
LibreScoot-Services nutzen den Präfix
librescoot-: z.B. librescoot-alarm, librescoot-vehicle. Mit lsc service list siehst du alle laufenden Services.
Das Dashboard bauen (scootui-qt)
scootui-qt ist eine Qt-6/QML-Anwendung für das DBC (Dashboard Computer).
# Mit eingebautem Simulator auf dem Desktop laufen lassen (keine Hardware nötig) ./run-desktop.sh # Oder manuell: cmake -B build -DDESKTOP_MODE=ON -DCMAKE_BUILD_TYPE=Debug cmake --build build -j$(nproc) SCOOTUI_REDIS_HOST=none ./build/bin/scootui # Cross-Build für ARM (i.MX6) per Docker ./cross-build.sh Release
Der Desktop-Modus bringt ein Simulator-Panel mit – so entwickelst du auch ohne physische Hardware. Setze SCOOTUI_REDIS_HOST=none, um die Redis-Verbindung zu überspringen und stattdessen den Simulator zu nutzen.
Yocto / komplette Image-Builds
Komplette OS-Image-Builds laufen in Docker, damit die Umgebung reproduzierbar bleibt.
# Im Repo librescoot/librescoot: ./build.sh
Das Docker-Image bringt alle Yocto-Abhängigkeiten mit. Output ist entweder ein Mender-.mender-Artefakt für OTA oder ein Raw-Image für den initialen Flash.
Einzelne Pakete baust du im Build-Container schneller neu mit bitbake <recipe-name>. Die meisten Mitwirkenden brauchen das nur, wenn sie meta-librescoot-Rezepte oder die Kernel-Konfiguration ändern.
Alle Details im Build-Guide.
Code-Style
- Go: Standard-
gofmt-Formatierung;golangci-lintfürs Linting - C++/Qt:
clang-format - Commits: Conventional Commits (
feat:,fix:,chore:,refactor:, etc.) - Versionierung: jeder Service nutzt semantische Versionierung mit Git-Tags (
v0.1.0,v0.2.0, …)
Änderungen einreichen
- Fork das jeweilige Repository auf GitHub
- Branch von
mainerstellen - Änderungen machen; sicherstellen, dass
make testdurchläuft - Pull Request öffnen und beschreiben, was du warum geändert hast
- Vor größeren Änderungen auf Discord abstimmen
Bugreports und Feature-Wünsche gehen an librescoot/librescoot/issues.