Posts by utiltiy

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


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


    Code
    1. pkgver=1.3.4
    2. _gitver=666391005879113c4f8241f9d40b0939c39b824b

    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.

    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 ;)

    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

    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 ;)