VDR 2.4.7 für Arch, vdr-projects.github.io, TravisCI und ein paar andere Gedanken

Hallo VDR Community,

um folgenden Text kurz und knapp zusammenzufassen: Ich habe fast meinen ganzen Samstag damit verbracht VDR 2.4.7 für Arch Linux (im Kontext "vdr4arch") halbwegs zum Laufen zu bekommen. Eigentlich hätte es ein einfaches "Automatisch Versions-Nummern durch die PKGBUILDs jagen und neubauen" sein sollen, wenn da nicht unnötige Steine im Weg gelegen wären. Dazu aber später mehr.

Nur das schon vorweg: Klaus hat alles richtig gemacht. Die neue VDR-Version ist top und alle Plugins kompilieren wie gehabt. Dickes für das GIT-Archiv und auch für das "Verteilen der Releases via GIT". Hätte nicht mehr für möglich gehalten das man sowas für das VDR-Projekt mal bekommt.

Und um auch das Fazit noch in "knapp" vorwegzunehmen: Ich werde in Zukunft nicht mehr so viel Zeit für sowas übrig haben. Sehr viel meiner Zeit wird schon von Arbeit und Studium beansprucht und in der übrigen Zeit kann ich mir, gerade bei schönem Wetter, auch besseres vorstellen als stundenlang Buildscripte zu reparieren.

Quellcodeverfügbarkeit, Patches, und andere unnötige Steine im Weg

VDR ist kein großes Projekt und in der Zeit in der sehr viele vom "Live TV" zu "Streaming" migrieren ist es um so schwerer Nutzer und vor allem Entwickler zu halten.

Entsprechend schädlich ist jede auch noch so kleine Hürde die vom Mitarbeiten abhält. Das sorgt nur dafür, dass neue Entwickler abgeschreckt werden oder bestehende irgendwann keinen Bock mehr haben.

Leider gibt es im VDR-Kontext recht viele Steine im Weg. Viele Plugins sind lange ungepflegt. Das ist erstmal der "normale Lauf der Dinge". Weniger schön ist aber das für den "Weiterbetrieb" der Plugins nötige Patches dann "gefühlt überall" landen. Ich habe das Thema "projects.vdr-developer.org" mal so verstanden das hier ggf. ein neuer Entwickler leicht Zugriff bekommt und Plugins eben nicht "verwaisen". Das Verwalten von sowas aber einer einzigen Person aufzubürden war vermutlich von Anfang an keine gute Idee. An der Stelle mal vielen Dank an Tobi das er so viel Freizeit in das Thema gesteckt hat. Fakt ist aber: Commit-Rechte hat man schon vor Monaten faktisch nicht mehr bekommen und aktuell ist die Homepage komplett "down".

Dieses "Gefühlt überall" hat in der Vergangenheit unnötig Zeit verbraten wenn es um Arch Linux geht. Bei Arch werden keine Kopien der Quellcode-Archive gehalten sondern es gibt im PKGBUILD eine Quell-URL und eine Prüfsumme. Ich will jetzt nicht alles aufzählen, aber fakt ist: Ein großes Portal wie GitHub oder GitLab ist deutlich weniger wahrscheinlich "down" wie das VDR-Portal oder projects.vdr-developer.org.

Ich hab jetzt im Zuge des Upgrades auf VDR 2.4.7 einige Plugins auf https://github.com/vdr-projects umgezogen. Eigentlich hätte ich noch ein paar mehr umziehen müssen, aber noch ist ja Zugriff auf projects.vdr-developer.org/git möglich.

Ich hab gute Lust alle Plugins die ich für Arch baue, und noch ausschließlich auf projects.vdr-developer.org liegen, auf https://github.com/vdr-projects zu übertragen. Optimum wäre wenn der Entwickler selbst das neue Repo als zweites "remote" einträgt. Andernfalls halte ich diese Mirrors selber aktuell. Ist einfacher als ständig die PKGBUILDs nachzuziehen und wenn projects.vdr-developer.org tatsächlich von heute auf morgen komplett "down" geht, dann ist der letzte Stand wenigstens gesichert.

Fehlende Arbeitsteilung

Betrifft sicher nicht nur mich sondern auch die Maintainer anderer Distributionen, aber ich kann direkt nur für Arch sprechen.

Fakt ist wohl, dass Arch im VDR-Bereich ein ganz kleines Licht ist. VDR-Nutzer sind ohnehin langsam eine "Seltenheit" und Arch ist keine gute Einsteigerdistribution. Entsprechend entfallen von den VDR-Nutzern entsprechend wenige auf Arch.

Trotzdem sieht man schon anhand der Signaturen das es einige Arch-Nutzer gibt. Und ganz ehrlich: Mich ärgert es jedes mal wenn so ein User dann in irgendeinem Plugin-Thread freudig verkündet das eine neue Version mit Arch funktioniert, ich die Arbeit, das PKGBUILD anzupassen, aber dann nochmal machen darf.

Ich unterstütze gerne beim "Einlernen" in GIT, aber es ist wirklich keine Kunst einen Fork zu ziehen, da drauf dann einen eigenen "privaten Branch" mit "Extra-Patches" zu hauen und Plugin-Updates gelegentlich auf "master" zu übertragen um einen Pull-Request anzulegen. Die Arbeit ist dann ohnehin schon getan und ich müsste mich nicht um alles selber kümmern!

TravisCI

Ich will mich jetzt mal noch nicht allzu breit darüber auslassen weil erstmal noch ein Ticket offen ist, aber aktuell habe ich folgenden Text in dicken Lettern in meinem Travis-Profil:

Builds have been temporarily disabled for public repositories due to a negative credit balance. Please go to the Plan page to replenish your credit balance or alter your Consume paid credits for OSS setting.

Rechnerisch sollte ich pro Monat 1000 Minuten Build-Zeit haben. Das wären 16 Stunden Kompilieren. So viel Zeit habe ich mit Sicherheit nicht gebraucht. Ich gehe deshalb erstmal von einem Fehler aus und warte auf die Antwort auf mein Ticket.

Sollte sich hier keine Lösung ergeben, dann würde ich Travis komplett abschalten. Ab dann gibt es "Pakete" wieder nur über das "AUR" inklusive der passenden Helper.

Ich würde sagen "keine Antwort ist auch eine Antwort".

Weil ich das starke Gefühl habe, dass die Anzahl der Nutzer der Binär-Pakete, die über Travis gebaut werden, kaum über meine Nutzer im direkten privaten Umfeld hinausgeht und ich selber absolut kein Gefühl dafür habe welche Plugins schon seit Jahren nur noch "der Form halber" am Leben erhalten werden, aber eigentlich doch keiner mehr nutzt, gilt für vdr4arch ab sofort:

• Es wird nicht nochmal vorkommen das ich mir die Mühe mache jedes einzelne Plugin auf eine neue VDR-Version update. Plugins, die keiner in meiner Bekanntschaft direkt nutzt, werden bei egal wie kleinen Problemen dann einfach aus der repo-make.conf auskommentiert. Was nicht sofort und ohne jeglichen Aufwand gegen eine neue VDR-Version baut --> RAUS. Ein Updaten der "_vdrapi" erfolgt dann auch nicht und entsprechend wird es auch beim Bauen aus dem AUR zu einer Fehlermeldung kommen weil ein Plugin mit der neuen VDR-Version eben nicht mehr kompatibel ist. Die Liste der Plugins die ich und meine direkte Bekanntschaft nutzen umfasst folgende Liste, die ab jetzt die "Liste Plugins erster Prioritätsstufe" ist:
  • vnsiserver
  • live
  • epgsearch
  • epgborder
  • satip
  • (streamdev) nice to have

• Es besteht für jeden die Möglichkeit fehlende Plugins selber nachzuziehen. Ein Pull-Request wird gerne gesehen. In einem überschaubaren Rahmen kann gerne auch via Issue um ein Update eins Plugins gefragt werden. Gleiches gilt für "Flag out of date" im AUR. Diese "Flags" sind einem Issue auf GitHub gleichgestellt. Plugins die aktiv angefragt werden trage ich auf eine "Plugins zweiter Prioritätsstufe"-Liste ein und versuche die bei VDR-Updates auch nachzuziehen, sofern das in einem überschaubaren Zeitfenster machbar ist. Plugins auf dieser Liste "zweiter Prioritätsstufe" können jederzeit wieder runterfliegen (bei entsprechenden Problemen) und kommen dann erst durch erneutes Nachfragen ("Flag out of date" oder Issue auf GitHub) wieder drauf.

Ich hätte einige Ideen gehabt wie man das Pflegen der Plugins teilweise automatisieren könnte. Ein Python-Skript das für alle Plugins die auf GitHub oder GitLab liegen einen Versioncheck macht hätte ich faktisch fertig gehabt. Ebenfalls wäre es z.B. möglich gewesen bei einem ffmpeg-Update automatisch über einen Bot ein Issue auf GitHub anzulegen. Leider bedeutet nämlich ein ffmpeg-Update in aller Regel das alle Plugins, die darauf basieren, einen Rebuild brauchen. Diese ganzen Infos sind aber nur dann hilfreich wenn auch jemand Bock hat darauf basierend entsprechende Aktionen einzuleiten. Und eigentlich war, vor allem mit der Travis-Automatisierung, der Plan das für Arch keiner mehr selber bauen müsste. Wenn wenigstens ein oder zwei weitere Arch-Nutzer statt "selber kompilieren" ein Update über Pull-Request eingestellt hätten hätte man für alle Arch-Nutzer ein Binär Repo über drei Architekturen aktuell halten können. Das ist aber nichts was ich ganz alleine stemmen will.

Ich selber fokusiere mich in nächster Zeit lieber auf VDR-Themen die ich selber auch aktiv nutze und spannend finde. Allen voran mein Python-Modul für SVDRP. Ich hab hier z.B. einen kleinen Python-Daemon der mir direkt aus einer externen Quelle EPG-Daten holt, die in Event-Objekte überträgt und dann mit einem einzigen Aufruf in mein Python-Modul in den VDR spielt. Also ganz ohne irgendein "xmltv2vdr" oder sonstwas dazwischen. Einfach direkt von Python in den VDR ohne irgendwelche EPG-Plugins.

Zur ersten Aussage: Das ist ne Weile her. Mittlerweile nutze ich eigentlich auch die Travis-Builds. Aktuell bekomme ich aber nichts gebaut. Sieht so aus als liegt es an Mirrors. Mal morgen nochmal anstoßen.

Zur zweiten: Ja, das stimmt so. Das "vdr-git"-Paket braucht aber mal ein Update. Mit den Änderungen von kls kann die "pkgver"-Funktion stark vereinfacht werden. Quelle ist auch nicht mehr "mein" GIT sondern direkt das von Klaus. Alle Plugin-Pakete sollte eigentlich mit "vdr-git" kompilierbar sein.

Zitat von utiltiy

was dem eigenen Einsatzzweck als reines Backend mit Kodi als Frontend geschuldet ist, sieht man ja das kein einziges Ausgabeplugin in der obigen Liste ist.

Aktuell bin ich der einzige der noch regelmäßig aktiv an vdr4arch arbeitet und es ist nunmal fakt das "Fernsehen" bei mir und meiner direkten Verwandtschaft mittlerweile eine Priorität hat die ganz stark zu Null tendiert. TV-Anschluss habe ich nur noch am aktuellen "Zweitwohnsitz". Am "Erstwohnsitz" habe ich keinerlei TV-Anschluss und nutze auch keinen entsprechenden Online-Dienst. Ich nutze den VDR mit Kodi fast nur noch für "Sat-Radio" und habe zwei Suchtimer laufen die Kram aufnehmen den ich eigentlich einfacher über die Mediatheken bekommen könnte.

Daraus folgt auch: Ich kann keine Ausgabe-Plugins testen. Ich kann checken ob die kompilieren, weiß dann aber auch nicht wann ein Rebuild wegen Library-Updates nötig wäre weil ich die Plugins selber gar nicht laufen lassen kann. Nein, ich werde mir hier kein Testsystem für "VDR-Ausgabe" hinstellen und ich werde meinen HTPC auch nicht so vergurken das da eine VDR-Ausgabe geht. Das Ding ist "Arbeitstier" und soll nach einem langen Tag am Abend ohne große Mucken Amazon-Prime, Twitch oder YouTube wiedergeben. Außerdem ist mir die Gefahr zu groß das ich jetzt wieder Aufwand treibe, oder gar Geld in die Hand nehme, nur das dann letztlich doch keiner die entsprechenden Plugin-Pakete nutzt. Schade um die Zeit.

Um ernsthaft wieder "runden" Support für Ausgabe-Plugins möglich zu machen bräuchte es im Team wenigstens einen weiteren Helfer der das auch aktiv noch nutzt und so, nicht wie ich, rein nur auf "baut noch" prüft sondern auch mal ein Plugin wirklich laufen lassen kann. Solange das nicht der Fall ist, stimme ich dir voll und ganz zu: Weil im aktuell aktiven vdr4arch-Team keiner mehr die VDR-Ausgabe nutzt gibt es keinerlei Garantie das die tatsächlich funktioniert oder gar Plugins regelmäßig die "pkgrel" hochgezählt bekommen um bei Library-Updates einen Rebuild zu triggern.

Zu Patches: Es hat seine Gründe warum hier bewusst auf das absolute Minimum gesetzt wurde. Einen Patch der "unbedingt sein muss" bitte mit Klaus diskutieren und irgendwie in den VDR direkt einbauen. Bei Plugins, die Patches brauchen, besteht immer die Gefahr das es irgendwann an einem fehlenden Patch scheitert. Solche Plugins würden dann recht schnell wieder rausfliegen.

AUR habe ich selber nie für irgendeine Art von "automatischem Bauen" genutzt. Ich lade mir die PKGBUILDs von dort immer erst runter, lese da grob drüber und führe das erst dann aus.

Auf dem GIT landen Updates definitiv schneller. Upload zum AUR ist aber nur ein Aufruf und läuft dann automatisch. Werde ich also schon weiter updaten, aber wird trotzdem immer mal wieder vergessen.

Bitte aber meine Liste von Plugins "erster Prioritätsstufe" beachten. Bei der aktuellen Situation garantiere ich nur noch dafür halbwegs zeitnahe Updates. Für alles andere müssten dann und wann auch mal Pull-Requests kommen. Ich sehe nicht mehr ein auf Verdacht die komischsten Plugins aktuell zu halten wenn man die Anzahl der Nutzer ohnehin an einer Hand abzählen kann.

Zitat von berndb

Nichtsdestotrotz war es meiner Erinnerung nach immer schwierig, für die gewünschten Plugins alle Patches von hier und dort zusammenzusammeln. Die PKGBUILDS auf AUR sind daher eine willkommende Quelle für mich, um diese Suche abzukürzen.

Mein Glückwunsch. Ich werde das in Zukunft aber auch nicht mehr machen. Was nicht baut fliegt raus. Es sei denn es ist ein Plugin auf der Prioritätsliste.

Patches irgendwo im VDR-Portal "reinwerfen" IST MIST. Es gibt entsprechende Upstream-Projektseiten. Da und nur da hin gehören Patches.

Zitat von berndb

Danke für die Glückwünsche. Wollte damit aber eigentlich zum Ausdruck bringen, dass die Arbeit jenseits von Binärpaketen, deren Downloadzugriffe wenn ich richtig lese den Aufwand nicht lohnen, nicht umsonst war.

Ich nutze die Binärpakete selber und brauche die auch für einen Bekannten bei dem ich noch VDR laufen habe. Aber eben nur für die "Plugins Prio 1".

Zitat von berndb

Aber wo geht die Reise jetzt hin:

Im AUR wird man weiterhin die oben genannten fünf Plugins finden?

Der Rest, bleibt oder fliegt raus? Oder wird eben aktualisiert, wenn jemand sich mit einem Patch etc meldet?

Letzteres. Nur noch auf "Zuruf" oder am allerliebsten direkt über Pull-Request.

"Zuruf" dann entweder über Issue auf GitHub oder über "Flag as out of date" im AUR.

Ich verlange einfach ein Grundmaß an Unterstützung von denjenigen die das Zeug auch nutzen. Und sei es nur ein Hinweis das etwas aktualisiert werden müsste. Damit fliegen Plugins, die keiner mehr braucht, nämlich ganz automatisch raus. Wenn sich niemand darum schert ob ein Plugin noch baut oder ob es aktuell ist, dann ist es auch den Aufwand nicht wert noch "am Leben erhalten" zu werden.

Zitat von berndb

Das wir alle vdr-Projekte top-gepflegt an einen Ort bekommen, scheint ja ein Wunsch zu bleiben.

"an einem Ort" müsste ja garnicht sein. "An einem bekannten Ort" würde voll und ganz reichen. Dort dann aber auch halbwegs zuverlässig und wenn jemand einen Patch hat, dann bitte auch dorthin schicken und nicht irgendwo "reinwerfen" wo ihn dann nach X Monaten keiner mehr findet.

Zitat von CvH

Keiner aus unserem Team nutzt VDR, gefühlt ist eh 3/4 zu Tvheadend gewechselt (Webinterface ist hier der Hauptgrund).

Hab ich ausprobiert und ich muss sagen: Ich finde das Webinterface von Tvheadend ziemlich Sch💩. Der einzige positive Grund für dieses Webinterface ist, dass es existiert und direkt vom Start weg da ist. Das war es aber auch. Aus Sicht eines Webentwicklers ist hier dringend "einmal neu machen" angesagt. Wird aber auch da niemand mehr machen. TV an sich hat gerade in der "technikaffinen" Zielgruppe viel an Boden verloren. Selber aufnehmen (und eventuell sogar noch schneiden) ist einfach ein Aufwand der einem von einem Streaming-Dienst abgenommen wird.

Zitat von CvH

Fazit für uns ist solange es baut alles gut, wenn es nicht mehr geht fliegts raus.

Schön das auch mal von anderer Stelle so zu lesen.

Zitat von wirbel

Und was das gelobte github betrifft, kann man bei rofafor froh sein, wenn er in zwei Wochen überhaupt reagiert. Einen VDR hat er nicht mehr.

Änderungen durch zu bekommen, die *notwendig* sind, ist extrem schwer, seit alles dort nur noch per github geht. Habe ich hier aufgegeben.

Die Frage ist: Was macht GitHub an der Stelle schlechter? Man kann sich ohne viel Verrenkung einen Fork ziehen, dort so viel committen wie man lustig ist und dann über einen Pull-Request nicht nur die eigenen Commits sondern auch direkt den eigenen Namen ins Upstream-Projekt bekommen. Viel besser und einfacher kann man es doch garnicht haben.

Und wenn der ursprüngliche Autor längere Zeit (oder gar nicht) auf einen Pull-Request antwortet? Dann committe ich einfach lustig in meinem Fork weiter und irgendwann spricht sich dann schon rum (ggf. auch nach Ankündigung hier im Forum) das das Projekt eben jetzt in aktueller Version dort zu finden ist.

Nicht anders habe ich es mit einigen Plugins gemacht die bei vdr4arch drin sind. Wenn ein Entwickler sich mehrere Jahre nicht um sein Projekt kümmert und die Patches, die nötig sind um es zu nutzen, sich schon an verschiedenen Stellen stapeln, dann gibt es doch keine Verpflichtung das Projekt vergammeln zu lassen. Die Lizenz unter der der Quellcode veröffentlicht wurde erlaubt sogar ganz ausdrücklich eine Anpassung und Erweiterung.

Ganz ehrlich: Wenn die Projekte faktisch ungepflegt sind, dann migriere die in deinen GitHub-Account und gut ist. Wenn der ursprüngliche Autor selber keinen VDR mehr hat kann ich mir auch nicht vorstellen das er bei einer freundlichen Mail mit der Bitte das Projekt "offiziell mit seinem Segen" übernehmen zu können ein "Nein" zurückschreibt.

Genau dafür habe ich ja mal diese Liste angeregt: https://vdr-projects.github.io/

Wo wer seine Projekte pflegt ist seine Sache. Man muss aber einfach mal irgendwo hinschreiben wo es aktuell und aktiv gepflegt wird, denn Entwickler kommen und gehen. Jeder verliert mal an einem Projekt das Interesse (erst Recht wenn es in der Freizeit entsteht) und ein anderer übernimmt ab einem gewissen Punkt.

Und bei einem wirklich aktiv gepflegten Projekt ist ein Review eines Pull-Request jetzt erstmal nicht wirklich ungewöhnlich. Ich reiche die auch nur selten komplett ohne "Review" durch. Erst wenn ich mit der Anpassung zu sagen wir 90% zufrieden bin nehme ich den Pull-Request an, schiebe dann aber ein/zwei "Fix-Commits" nach um aus 90% die anzustrebenden 100% zu machen. Wenn ein Pull-Request aber z.B. komplett gegen meinen Coding-Style geht und ich durch Annehmen mehr Zeit ins Reparieren stecken muss als den Fix selber zu coden, dann werde ich immer erstmal Nachbesserung fordern.