VDR4Arch: Neues Binär-Repo wartet auf Tester (Travis CI)

Hallo,

wir hatten bei VDR4Arch schon länger "repo-make" im Einsatz um den Paketsatz komplett automatisiert zu bauen. Durch tmn505 bin ich darauf gekommen, dass Travis CI genutzt werden kann um den Build-Prozess dann sauber in die GitHub-Infrastruktur zu integrieren. Die erste Variante hat er freundlicherweise als Pull-Request zur Verfügung gestellt: https://github.com/VDR4Arch/vdr4arch/pull/219

In den letzten Tagen hab ich im Kontext des repo-make-Projekts ein Hilfsscript gebaut das die Anbindung von Travis CI komplett kapselt und die Einrichtung im jeweiligen Repository entsprechend einfach macht. Der kleine Helfer heißt "repo-make-ci.sh" und ist bei den Releases jeweils mit abgelegt: https://github.com/M-Reimer/repo-make/releases

Das ergibt dann letztlich sowas ähnliches wie "PPA" bei Ubuntu.

Wer die resultierenden Pakete gerne ausprobieren möchte wird hier fündig: https://vdr4arch.github.io/repo/

In Zukunft sollten jetzt auch Pull-Requests direkt kompiliert werden, sofern die pkgrel sauber hochgezählt wurde.

Der Pfad hat sich nochmal geändert. Ich hatte "Ausganssperren-bedingt" etwas viel Zeit und habe mal geschaut wie ich Travis CI so hinbasteln kann, dass es ARM-Builds für den Raspberry baut. Das hat aber zur Folge das es sinnvoll ist zwei Ziel-Repositories zu haben. Es gibt als "Quelle" deshalb jetzt folgende zwei:

https://vdr4arch.github.io/armv7h/

https://vdr4arch.github.io/x86_64/

Wer Arch Repos kennt weiß wo das hinführen soll. Ich werde hier aber noch keine Anleitung veröffentlichen wie man das in die makepkg.conf einträgt. Ich warte noch auf Rückmeldungen von (hoffentlich hier vertretenen) Testern.

Die neue Architektur "armv7h" deckt die Raspberrys 2, 3 und 4 ab. Ich habe den "1er" mal noch rausgelassen. So schwache Hardware ist meiner Meinung nach zu meiden. Ein 2er darf es schon sein. Am besten ein 3er. Nur für den 1er noch eine "ARM6" reinbauen wäre im Prinzip aber möglich. Aber nur wenn sich wirklich großer Bedarf zeigt, denn dann müsste nochmal gebastelt werden.

Das Repository für ARM ist bewusst stark reduziert und ich nehme nur mit guter Begründung noch Pakete auf. Mein persönliches Ziel ist die "Basis" für einen kleinen VDR-Server und der Vollständigkeit halber noch die nötigen Plugins für einen kleinen Client mit dem rpihddevice Plugin. Alle Skins sind erstmal raus und so "große Kaliber" wie Skindesigner kommen da auch nicht rein. Über sehr kleine und schlanke Skins kann noch verhandelt werden.

Es gibt und wird auch keine Kodi Client-Addons geben. Wenn ihr einen Kodi-Client braucht, dann nehmt LibreElec! Mir ist das zu viel Gebastel!

Vielleicht mag ja jemand die ARM-Builds mal testen. Für Rückmeldung wäre ich dankbar.

Nachtrag: Das hier sollte im Prinzip der Eintrag für die "pacman.conf" sein:

[vdr4arch]
Server = https://vdr4arch.github.io/$arch
SigLevel = Never

Ist bei x86_64 und ARM gleich.

Wäre praktisch wenn die ARM-Binaries jemand testen könnte. Ansonsten baue ich mir morgen selber einen Raspi 4 zum Testen auf.

So. Habe jetzt selber getestet. Auf dem Raspi 4 (wo ich letztlich meinen Server aufbauen will) kann ich VDR einfach so installieren. Geht also.

War nochmal etwas Arbeit aber jetzt gibt es auch armv6h. Also falls jemand einen kleinen Client mit einem 1er Raspberry bauen will wäre jetzt alles da. Testen werde ich das selber nicht.

Mein Hauptziel für die ARM-Repos ist ein VDR-Server auf einem Raspi 4 und dafür brauche ich armv7h. Die Pakete die ich dafür brauche sind getestet und erstmal für gut befunden.

Falls es noch nicht aufgefallen ist: armv6h wird jetzt auch gebaut. Damit ist alles abgedeckt was als "unterstützte Plattform" in Frage kommt. Auf 64 bit ARM verzichte ich noch solange bis es zumindest auf dem Raspberry 4 sauber funktioniert und offizielle Arch Images dafür da sind.

Das bedeutet auch: Ab jetzt kann ich im Prinzip von unterwegs via Handy einen Pull-Request akzeptieren und Travis baut innerhalb von wenigen Minuten die Pakete. Das mal als Anreiz für Arch-Nutzer, die VDR nutzen, beim Projekt mitzuhelfen.

AUR synchronisiere ich natürlich weiterhin, falls jemand nach wie vor selber bauen will. Ich habe jetzt aber alle meine Systeme auf die neuen Repos umgestellt. Ist einfach praktisch alles via "pacman -Syu" aktuell zu bekommen.

Das Signatur-Paket müsste eigentlich raus. Danke für den Tipp.

Man könnte mit Travis mit Tricks durchaus signiert bauen. Das würde aber eher zweifelhafte Sicherheit suggerieren. Um mit Travis zu signieren müsste ein privates Zertifikat erstellt werden das nicht mit einem Passphrase gesichert ist. Dieses müsste dann komplett in eine "sichere Umgebungsvariable" abgelegt und aus dieser bei jedem Build-Lauf wiederhergestellt werden. In der Summe würde es aber keine zusätzliche Sicherheit bringen, die man durch die Übertragung via HTTPS nicht auch hat.

Eine Signatur ist dafür da, dass über die Signatur garantiert wird, dass dieses Paket von genau dieser Person erstellt wurde und auf dem Weg nicht manipuliert worden ist. Eine solche Sicherheit kann ein Autobuild-Prozess per Definition nicht bieten. Wenn jemand einen Github-Account, der berechtigt ist, hacken würde, dann könnte er auch beliebig manipulierte Pakete ablegen.

Wenn man den Statistiken von GitHub glauben schenken darf, dann ist der Nutzerkreis, der VDR mit Arch Linux nutzt extrem klein. Also im Rahmen von "kann man an einer Hand abzählen".

Dazu kommt, dass gerade im Bereich "VDR-OSD" (also gemeint ist bei Nutzung des VDR-OSD) gerade diverse neue Projekte entstehen die für mich ohne Testmöglichkeit nicht sinnvoll paketierbar sind (gemeint ist vor allem die Arbeit im Bereich HBBTV).

Eigentlich war meine Hoffnung etwas mehr Zuarbeit zu bekommen. Pull-Requests kann ich ggf. auch mit dem Handy aus dem Zug raus akzeptieren und Travis würde dann automatisch kompilieren. So müsste im Prinzip kein Arch-Nutzer mehr irgendwas selber kompilieren. Das wäre vor allem für die ganzen Raspberry-Nutzer interessant. Gerade auf dem kleinen ARM-Rechner ist Kompilieren nämlich eher lästig.

Solange das aber nicht klappt muss ich davon ausgehen das es kein Interesse an weiterem Ausbau der Arch-Pakete gibt. Deshalb werde ich mich in Zukunft bevorzugt auf die Plugins und Pakete beschränken die ich selber nutze. Wenn mir hier im Portal auffällt das es für ein bereits paketiertes Plugin ein Update gibt, dann ziehe ich das nach, aber ich erstelle keine neuen PKGBUILDs für kommende Plugins mehr.

Ist ja auch OK. Schade ist nur wenn jemand mit AUR arbeiten würde, eine nicht aktuelle Version dann lokal updatet und das nicht wieder ins Projekt zurückgibt. Das macht halt die ganze Idee kaputt.

Ich bin gerne bereit für Arch weiterhin VDR-Pakete zu unterstützen aber ich habe halt keine Lust mir dafür ein Testsystem aufzubauen das ich selber so nicht nutzen werde. Bei mir ist der VDR eben Backend only. Und das bleibt auch so.

Wenn jemand also z.B. HBBTV unter Arch will, dann müsste er auch die Vorarbeit machen. Wäre ja auch wenig sinnvoll wenn ich die dafür nötigen Programme "irgendwie" paketiere, aber garnicht testen kann ob man damit letztlich auch was sinnvoll anstellen kann.

Mein aktuelles Thema ist eher Kodi mal testhalber mit Wayland laufen zu lassen. Kodi kann Wayland. Meine Intel-Grafik auch. Fehlt nur etwas Gescripte dazwischen. Und einen eigenen Compositor werde ich auch brauchen. Was es gibt taugt für meinen Anwendungsfall (direkt auf Kodi booten) eher nicht.

Nachtrag zum Thema Binär-Repo: Das Cross-Compilieren nach ARM hab ich aufgegeben. Das war ein ständiges Hinterherrennen hinter Fehlern in qemu. Stattdessen laufen die Builds jetzt auf den ARM64-VMs von Travis direkt. Das scheint schneller und auch weniger problembehaftet zu laufen.