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 :thumbup: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.

  • Seit solchen Aussagen, die immer wieder mal im Umlauf waren, baue ich selbst:

    Für meinen eigenen Bedarf baue ich via "repo-make" mein eigenes Repository. Dies ist auch weiterhin der empfohlene Weg um ein Repository für den eigenen Bedarf zu erstellen.

    In Zukunft wird sich "VDR-Entwickler-Patch für Arch bereitstellen" von meiner Seite auf "ins VDR-GIT einchecken" beschränken.

    Über das VCS-Paket kann sich das dann jeder bei Bedarf selber neu kompilieren.


    Das PKGBUILD für "vdr" dagegen ist ab jetzt immer das aktuellste stabile Release. Über kleinere Patches kann man ggf. noch reden (nur Patches von Klaus! Eigentlich würde ich am liebsten auch MainMenuHooks loswerden. Weitere "nichtoffizielle" Patches aber auf garkeinen Fall!), aber dort werden keine Patches landen die irgendwelche Header verändern und somit ein Plugin-Neukompilieren erfordern.

    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.


    Ich nutze den VDR immer noch als VDR mit Bildausgabe sowie allem was dazu gehört mit speziellen Erweiterungen und einem gepatchten VDR sowie Plugins, diese baue ich zudem nicht als TAG Versionen sondern per COMMIT und das mitunter bei Änderungen mehrmals die Woche. Das ist immer noch annähernd der Weg wo damals dem geneigten Arch User mitgegeben wurde (siehe Zitate), deshalb versteh ich die aktuelle "Aufregung" dazu nicht da es meiner Meinung nach ein "hausgemachtes" Problem ist.


    Trotzdem Danke was bisher für arch im Bezug auf den VDR gemacht wurde.

    Gruß utiltiy



    VDR Projekte VDR Projects

  • 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.

    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.

  • Es hat seine Gründe warum hier bewusst auf das absolute Minimum gesetzt wurde.

    Kein Thema, es hat aber auch seine Gründe warum ich gerne einen gepatchden VDR nutze und in dem Fall von der Vorgabe abweiche und somit nicht mehr für den Standard um was es hier geht kompatibel bin.


    Vielleicht findet sich noch jemand, dem der Weg taugt, ist ja alles noch möglich ;)

    Gruß utiltiy



    VDR Projekte VDR Projects