Posts by utiltiy

You can also install on arch an output Plugin, choose what you want and install it

Unter arch ist die Version libnsl 2.0.0-1 verfügbar, beim bauen kommt:

Kann man auch über /etc/sudoers lösen und das entsprechende Skript dort hinterlegen, mach ich seit Jahren so.

Kann man mit einsprechender Konfiguration (*.conf) über /etc/apt/apt.conf.d/ steuern

seahawk1986 wrote:

ich habe das yavdr-frontend Skript vom mittlerweile schon länger ungepflegten pydbus-Modul für die Kommunikation mit Systemd und dbus2vdr auf dasbus umgestellt

Ist dass für das: https://github.com/seahawk1986/arch-frontend ebenfalls möglich, die Anpassung wenn es soweit läuft?

Wäre wohl ein BT hilfreich zur Fehlersuche

Ich hab eventlircd damals ziemlich schnell eingerichtet gehabt für mein Imon. Die Configs hab ich von yaVDR mit rüber genommen, läuft seit Jahren.

Dazu gab es schon mehrfach Anfragen, hat bis heute aber keiner in Angriff genommen und gelöst:

epgd / epg2vdr => Aufnahme mit VPS startet und bricht gleich wieder ab, mehrmals

Log dazu: https://pastebin.com/8qQNRHhM

[epg2vdr] VPS Status

arch: 11.1.0-1

Ich hab das Build-Verzeichnis nun mal gelöscht und neu aufgesetzt, jetzt passt es - sorry

Aktuelle Version, laut GIT 1.3.5, wird als Version 1.3.4 gebaut unter arch. tvguideng dagegen mit der richtigen Versionsnummer vom Paket.

seahawk1986 wrote:

IIRC macht der die Darstellung einiger Plugins mit dem Skindesigner (z.B. systeminfo-Plugin) kaputt.

Nicht mehr, Systeminfo 0.1.5 funktioniert zumindest unter arch damit im Bezug auf die Darstellung der Belegung.

M-Reimer wrote:

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

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

M-Reimer wrote:

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.

M-Reimer wrote:

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.

S:oren wrote:

Das finde ich genau richtig so. Ist ein separater Entwicklungsbranch, und der hat noch keine Versionsnummer oder Tag (mehr s.u.).

War nur ein Gedanke, in der osdteletext.c steht nämlich dazu: *VERSION = "2.1.0.beta.2";. Liegt wohl an der Strategie die sich mir auch noch nicht so ganz erschließt

Natürlich steht die Weiterentwicklung an erster Stelle, dafür ebenfalls ein Danke von mir

Wenn man das Repo von markad mal nimmt als Beispiel, da ist der Master Zweig und wenn erweitert wird der Zweig V02 der wo entwickelt wird, wenn es passt kommt es nach Master rüber gemerged.

Hat jetzt nichts mit Zoo oder so zu tun, ist schlicht, einfach, funktionell. Kann auch sein dass du es nicht so machen willst sondern einen eigenen Weg hast, dann eben diesen

pbrb wrote:

So, mein 2.1.0 branch ist nun im offiziellen "milestone-2.1.0" Branch reinmigriert

Naja, meldet sich wieder mit 2.0.2_38_gb2f5e02 als Version weil kein Tag vorhanden ist. Nach welcher Grundlage werden die großen Sprünge in kurzer Zeit der jeweiligen Versionen hier eigentlich geändert?

Soweit weg kannst Du ja nicht sein, von einer Funktionsweise im Umgang mit dem GIT damit das Pushen und Taggen passt. Wenn es wo klemmt wird dir sicher hier geholfen und eine Frage ist ebenfalls kein Beinbruch

Du müsstest auch nicht die Version als "beta" umschreiben, es reicht doch zu jedem Tag (also neues Release) die Version anzupassen. Die Stände dazwischen sind "Entwicklungsstände", das machen doch alle anderen auch so. In der obigen Zeile wäre es dann der 38igste Commit nach dem Release 2.0.2

Welche Distri nutzt du zum entwickeln, testen ?

Es gibt ja genug Plugins wo man aus einem Repo sowohl die Tags und die Commits raus bauen kann, wie man will. Bei diesem Plugin hier ist halt das "gewurschtel" zwischen den beiden "Adressen" sehr groß wie bereits beschrieben

pbrb wrote:

Release erstellt

Die beiden GIT Stände sind aber nicht per Commit auf den Stand 2.0.2.

Hab gerade beide GIT Stände gebaut vom Plugin aber keinen Tag....