So richtig angelaufen ist das mit den DVB-Treibern im Kernel ja nie. Und jetzt wo das Thema auf dem absteigenden Ast ist (Hersteller nehmen ab und noch eine DVB-Karte in einen Rechner zu bauen ist heutzutage echt exotisch) wird das auch nicht mehr gelöst werden. Läuft wohl drauf hinaus das man, wenn man ein System aufbaut, sich auf einen Hersteller beschränkt und dann halt dessen Treiber installiert. Mischen von Herstellern besser sein lassen. Und auf lange Sicht wohl eher Sat>IP als noch DVB-Tuner im Rechner.
Posts by M-Reimer
-
-
Was genau bedeutet denn "sind auch viele Plugins inkompatibel geworden" im Ursprungsposting, besonders im Fall rcu-Plugin? Wir haben ein großes Interesse daran, das rcu "weiterlebt".
Ich glaube die API-Änderungen in letzten VDR-Versionen hatten keinen Einfluss auf das rcu Plugin.
Stand aktuell ist das es wohl noch lauffähig ist. Wenn das mal nicht mehr der Fall ist, dann fällt das erstmal auch keinem direkt auf. Ich glaube die Menge an nachgebauten "RCUs" kann man an 10 Fingern abzählen. In dem Fall dann entweder selbst versuchen zu fixen und den Fix im Idealfall beim Repo als Pull Request anlegen oder jemanden finden der dir beim Fixen hilft.
-
Wie bekommen wir heraus, wann ein Plugin in Rente gehen darf? Jemand ne Idee?
Es gibt auf https://vdr-projects.github.io/ die Spalte "Working?". Alles was da ein "X" hat kann als "In Rente" gesehen werden. Läuft nicht mehr und hat auch keiner mehr Interesse dran.
Es gibt da auch so ein paar Exoten wie z.B. "vdr-plugin-serial". Der ursprüngliche Entwickler hat das ganz offiziell abgekündigt, aber "Serielle Ports" (RS232) hat auch kein aktuelles Mainboard mehr. Bei yaVDR wird es wohl noch mitgezogen aber keine Ahnung ob es noch von irgendwem genutzt wird.
Ich hab jetzt alles in der Liste was bei yaVDR dabei ist (wenn ich nichts vergessen habe). Alles was keine richtige "Heimat" mehr hatte ist in der Organisation neu angelegt. Ich habe keinerlei Patches angewendet. Wenn es kein anderer tut würde ich irgendwann die Patches die bei "vdr4arch" mittlerweile drin sind, wieder alle in die Repos übertragen. Bin aber nicht wirklich scharf drauf das selbst zu machen.
-
Ich hab in letzter Zeit immer mal wieder weiter ausgebaut.
Mit mini73 hatte ich kurz via PN abgestimmt weil ich schon wusste das er keinen VDR mehr hat. Seine Plugins liegen jetzt in der Organisation. Auch ein paar alte, die noch bei yaVDR liegen, aber eigentlich keine Quelle mehr haben, habe ich teilweise über archive.org "gerettet" und möglichst viele Versionen (für die Historie) in ein Repo gepackt.
Das sind alles Kopien wie Original. Ich hab keinerlei Ahnung was davon unverändert baut und ich werde auch die Zeit nicht haben die ganzen Patches zu suchen und zu übertragen.
Auch das Team "Community Maintainers" wurde im gleichen Zug ausgebaut. Aktuell hat das Team (aktuell bestehend aus zwei Personen) Commit-Rechte auf 64 Repos, großteils mit alten Plugins.
-
Hi M-Reimer, ich würde gerne meinen Stand von StreamDev mit folgenden Ergänzungen pushen:
Gibt es Einwände?
Ist mir ehrlich gesagt ziemlich egal
Force-Push ist gesperrt. Wenn jemand Probleme mit einer Änderung hat kann sie also jederzeit rückgängig gemacht werden.
Ich nutze VDR, Stand jetzt, gar nicht mehr.Ich habe nicht vor irgendwelche "Reviews" zu machen.
-
um das Plugin zu kompilieren, soll man die beiden Pakete tntnet-2.2.1.tar.gz und cxxtools-2.2.1.tar.gz herunterladen. Aber wie integriert man die dann in den Quellcode von vdr-plugin-live?
Gar nicht. Die beiden Pakete separat kompilieren und installieren. Noch besser wäre wenn deine Distribution diese Abhängigkeiten eventuell sogar als Paket hat.
-
Ich hab mich mal bei yaVDR orientiert welche Plugins da noch gebaut werden und gegengeprüft welche davon bei "vdr-projects" liegen. Alle diese Repos sind jetzt auch für das neu erstellte Team zugreifbar. Aktuell sind wir bei 49 Repos die ich dem Team zugewiesen habe.
Bleibt noch eine gewisse Anzahl von Plugins die yaVDR zwar enthält, deren Quelle aber aktuell noch unklar ist. Das wird ein eigenes Thema zu versuchen die einzufangen.
-
Für Patches könnte ich ggf. das hier freiräumen: https://github.com/vdr-projects/vdr-patches
Ich würde was da liegt dann umbenennen damit es nicht verloren geht.
-
Hi,
ich versuche ja die vdr-Pakete bei Gentoo Linux zu pflegen und habe auch schon das eine oder andere gefixt - was aber innerhalb von Gentoo geblieben ist.
Gerne helfe ich ("madmartin") in der Organisation mit, würde dann auch meine vdr-repos in de Organisation überstellen (vdr-clock, noad).Davon abgesehen wäre es hilfreich ein Repository (oder mehrere repos) einzurichten für Patche die auf die vdr-source angewendet werden (müssen) - wie z.b. naludump, permashift, ttxtsubs.
Wenn du Interesse hast kann ich dich gerne mit aufnehmen. Dafür ist das neue Team ja da. Unabhängig davon besteht seit eh und je die Möglichkeit Pull-Requests zu erstellen.
Das Thema "Patches" würde ich persönlich aber nicht unbedingt größer aufstellen wie unbedingt nötig. Ich fand die Idee den VDR dauerhaft zu patchen schon immer daneben. Wenn jemand was umsetzen will das mit den aktuellen Plugin-Schnittstellen noch nicht geht, dann glaube ich schon das kls da ein offenes Ohr hätte um ggf. eine schöne und auch allgemein nutzbare Erweiterung der Schnittstellen umzusetzen.
Letztlich kann aber alles was den VDR betrifft auch in der Organisation als Repo liegen. Es gibt für Patches aber definitiv nur ein einziges Repo. Namen nach Wunsch. Ich würde das leer anlegen und als Maintainer dann ggf. dich eintragen.
Edit: In vdr4arch haben wir seit "ewig" den "MainMenuHooks" drin. Klaus hatte da (ebenfalls vor "ewig") mal vor das Hauptmenü anpassbar zu machen und dann hätte der einzige Patch, der bei mir noch drin ist, fallen können. Wenn sich ein Repo ergibt wo Patches gesammelt (und hoffentlich auch aktuell gehalten) werden, dann würde ich den Patch aus dem vdr4arch-Repo rauskicken und direkt vom "zentralen Patch-Repo" anziehen.
-
Dafür bieten sich "Branches" an...
Nein. Besser nicht. Aktuell noch "unklare" Änderungen bitte als PR und den dann offen lassen. Grund: Der PR bietet dann gleich eine Diskussionsplattform wo sich ggf. jemand melden kann der diese Änderung benötigt um dann eventuell offene Fragen zu beantworten oder zu begründen warum diese Änderung übernommen werden sollte. Ein Branch dagegen "liegt halt da".
Nachtrag: Ohne Branch geht gar nicht. Ich hatte den Fall auch schon und hab da auch einen "Hilfs-Branch" gebaut. Trotzdem sollte aber auch ein Pull-Request dafür erstellt werden. Beispiel:
-
Was man prinzipiell (eigentlich als nicht wirklich bindende) Regel festhalten könnte wäre, dass "Community maintained" im Idealfall wirklich nur die "Kompilierfähigkeit" erhält. Komplexere Änderungen und Feature-Erweiterungen können gerne, sofern man sie nicht auch selbst bewerten kann oder testen kann, einfach als neuer Pull-Request angelegt werden und bleiben dann so erstmal stehen. Das könnte dann bei Bedarf immer noch mit einem Klick übernommen werden und ist dann auf jeden Fall erstmal im richtigen Kontext "archiviert".
-
M-Reimer, wie handhaben wir das denn generell mit Updates. Üblicherweise teste ich das natürlich in meiner Build-Umgebung. Aber wie schließen wir aus, dass es dann am Schluss zwar bei mir, aber eventuell nicht bei Selbstbauern oder "Packagern" mit ganz unterschiedlichen/anderen Build-Umgebungen knirscht?
Gibt es da so etwas wie einen Review-Prozess, bspw. per Pull-Request und Validierung in mindestens einer weiterem (unabhängigen) Umgebung?
Andernfalls würde ich meinen Stand pushen und bei Problemen gegebenenfalls natürlich nachbessern.
Ein "Review Prozess" würde voraussetzen das es einen Projektleiter gibt. Und den gibt es gerade bei den "Community managed" ja eben nicht.
-
Gab es nicht für github die Möglichkeit, automatische builds für alle möglichen Umgebungen ausführen zu lassen?
Ja und nein. Ja, das gibt es aber nein, das ist nicht mal eben schnell zu lösen. Dafür müsste man eine Regel für GitHub Actions bauen. Und das dann auch noch für jedes Plugin. Letztlich sagt das dann auch nur "baut in der Umgebung". Also nichts anderes als wenn man selbst einen Build ausführt.
-
Im Prinzip ist es auch durchaus machbar ein Submodule wieder rauszuhauen. Hatte da bisher keine Probleme mit. Zum Entwickeln ist das durchaus eine praktische Lösung das eigene Plugin-Repo (oder die Repos) als Submodul direkt in den VDR-Tree zu hängen.
-
Wenn Repos nicht zugreifbar sind, dann ggf. melden. Ich werde noch ein paar nachziehen aber alles größer 5 Jahre alt würde ich dann langsam außen vor lassen und davon ausgehen das es keiner mehr braucht. Also solange bis sich jemand meldet weil eben doch wer das noch nutzt.
-
Gerne doch…
Einladung ist raus.
-
könnte man auch mal das Git vom VTUNER-NG mit aufnehmen?
Erledigt
-
Falls Plugins, die noch genutzt werden, noch komplett fehlen, dann bitte auch melden. Oder falls was in der Übersicht nicht aktuell ist.
Bei "radio" habe ich vor ein paar Tagen schonmal eine Anfrage hier gestellt: https://github.com/siricco/vdr-plugin-radio/issues/1
Zwei Jahre Inaktivität sieht für mich da aus als wäre das auch "verwaist". Ich würde dann nach einem Monat Wartezeit die Änderungen dort in einen Pull Request verpacken und nach https://github.com/vdr-projects/vdr-plugin-radio übertragen welches dann auch "Community maintained" wäre.
-
Es gibt jetzt ein Team "Community Maintainers" in das ich auch Interessierte einladen kann.
Jeder in diesem Team kann direkt auf Repos pushen die im Status "Community maintained" sind. Es gibt damit also keine Rechte auf Repos für die sich ein "Aktiver Maintainer" bereit erklärt hat. Auf solchen Repos sollte ausschließlich der Projektleiter entscheiden. Außenstehende haben hier generell nur über Pull Requests die Möglichkeit beizutragen.
Zusätzlich habe ich mal als zusätzliche Sicherheits-Maßnahme das Force-Pushen auf den Haupt-Branch in allen Repos generell gesperrt. So ist die Historie immer nachvollziehbar.
Es sind noch nicht alle Repos eingetragen. Alles älter als ein paar Jahre habe ich jetzt nicht manuell hinzugefügt. Vielleicht füge ich später noch ein paar Dutzend hinzu. Wenn welche fehlen dann bitte melden, denn ich werden jetzt nicht größer 100 Repos hinzufügen bei denen sicher viele Plugins dabei sind die eh nur noch aus historischen Gründen abliegen aber keiner mehr nutzt.
Edit: Es geht wohl nicht Teams öffentlich sichtbar zu machen. Link oben entfernt.
-
Genau das ist das Problem. Und es gibt in der Organisation auch Plugins bei denen sich jemand als "Aktiver Projektleiter" bereiterklärt hat. Bei denen sollte "von oben" eh nichts eingecheckt werden. "In der Organisation" soll ja nicht gleichbedeutend sein mit "du bekommst Commits untergeschoben".
Aber eventuell hat GitHub für den Fall sogar was das die Situation abdeckt. Muss ich später mal testen.
