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

M-Reimer · 2021-04-25T13:05:02+02:00

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.

mini73

Moderator

Reaktionen

117

Beiträge

9.962
31. Mai 2021
- #41
Letztlich zählt ja auch nur, dass Bugfixes es irgendwie nach Upstream schaffen...
vdr2: yaVDR 0.5/softhddevice @ G540, Intel DH67BLB3, Asus GT610/2GB, DDBridge + 2x DuoFlex C/T
hdvdr: yaVDR unstable/softhddevice @ E8400, Asus P5Q SE Plus, 1x L4M-TwinCI + Flex C/T, 1x Sundtek MediaTV Pro, GT520
Plugins: | avahi4vdr | dbus2vdr | dynamite | epg2timer | noepg | pvrinput | sundtek |
1

Inhalt melden
- 1
- 2
- 3Seite 3 von 3

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen Schließen

In Ihrem Webbrowser ist JavaScript deaktiviert. Um alle Funktionen dieser Website nutzen zu können, muss JavaScript aktiviert sein.

Jetzt mitmachen!

Teilen