Slackware SlackBuild für VDR-1.6.0

  • hi
    Chrissi1993
    ne du hast da nix falsch ferstanten
    struktur oder ein kontzebt habe ich bei keinen gefunden und deshalb auch hier nicht weiter gemacht
    mfg det

    Jeder sollte sein Leben so leben können wie er/sie es möchte, frei und
    unabhängig, in der Not anderen zur Seite stehend, nie vergessen was man
    ist, eben einfach nur Mensch sein mit allen Schwächen und Stärken
    Lieber stehend sterben als ewig gebückt leben

  • ganz so ist das nicht.. es gibt so etwas wie einen Slackware-Standart nicht! Es gibt nur eine Form, die sich als brauchbar herauskristalisiert hat.


    Struktur haben sicher beide Lösungen... anders gehts ja garnicht... Beide releasen wir z.B pro Plugin ein eigenes Paket. Selbstgebastelte Scripts kommen auch wieder extra,... so ist alles schön geordnet.


    Wo sich dann aber wirklich die Geister scheiden kommt dann beim Rest.


    Ich will folgendes:


    Streaming-Server mit Budget-Only Multi-VDR und per Netzwerk angebundenen Clients über XinelibOutput.


    Soll heißen mehr als 1 VDR am Rechner und keine Lokale ausgabe.



    Mreimer will folgendes:


    1 FF-VDR auf dem Rechner.


    Beide wollen wir:


    Slackware drauf
    VDR-Pakete der Wahl drauf
    Config-Script abarbeiten (Plugins auswählen, ...)
    Ein Produktiv-VDR ist fertig :)


    Bzw. als Alternative:


    SlackVDR installieren, Config-Script starten und VDR ist fertig



    Aber eines haben wir gemeinsam:


    Wir haben beide eine sehr genaue Vorstellung von dem was wir haben wollen bzw was wir brauchen.


    Ich sehe da auch keine Probleme... Ob das Build-Script jetzt so aufgezogen ist wie bei mir oder ein klassisches SlackBuild ist... für mich ists so weniger Wartung-Aufwand weil ich eben Binaries für meinen Slackware-Basierenden VDR brauche und dem OpenSuse basierenden meines Vaters (der verwendet die Kiste ua auch als Firmen Server).


    Zu sagen ich verfolge bei meinem Scriptset kein Konzept oder hätte keine Struktur drinnen ist etwas... naja... sagen wir mal dreist... det hast du dir überhaupt die mühe gemacht und geschaut wie ich das aufgebaut habe?


    Falls das zu Compilierende Plugin keine Paches braucht, gibts ein wunderbares Script (das noch ein dialog-frontend bekommen wird), das einem ein wunderbares Buildscript baut.


    Man braucht eingentlich nur Name, Version und Download-URL (alle anderen Infos dienen nur der Übersichtlichkeit in den Package-Meta-Daten).. den Rest macht das Script...


    So ähnlich wie Mreimer habe ich mir ursprünglich auch das vorgestellt.. es hat sich eben nur gezeigt, dass ich 1. eine weitere Distri unterstützen MUSS (mit identer funktionalität) und 2. dass ich Automatismen für die mittlerweile 2 Server und 4 Streaming-Clients brauche um alle immer am gleichen Softwarestand halten zu können.


    Mein Script kann nun das alles... Ich sage "hg pull && hg update && ./Build.sh 1.6.0" und habe alle Packages für den jeweiligen Server.


    Das Streamin-Clientupdate werde ich ähnlich machen... Das Package-Dir am Server wird per nfs gemountet und ein installpkg *.tgz erledigt mir den Rest.


    Also ich habe mir sogar schon einige abzudeckende Use-Cases zurecht gelegt. Das ist alles für einen "Normalen"-VDR der im Wohnzimmer steht "etwas" übertrieben nur bei mir ist alles Vernetzt und muss so sein... Bei mir wird am Streaming-Client auch noch entweder MMS oder XBMC rennen, da ich lokale DVDs, Photos von USB-Sticks, CDs,.. auch noch abspielen darf... und das muss alles so einfach,dass auch die Generation 50+, die vorher noch nie einen Video-Rekorder hatte geschweige denn einen DVD-Player, das MÖGLICHST INTUITIV bedienen kann.


    Wenn das nicht alles bei mir einfließen würde, hätte ich eigentlich keinen Grund nicht einfach eine X-beliebigen andere VDR-Distri zu nehmen.. aber das was ich vor habe und bereits umgesetzt habe, gibts eben noch nicht.



    Falls jetzt sich noch jemand bemüßigt fühlt, mir zu sagen, dass alles was bisher so von mir in den Raum gestellt wurde, sei für A&F möge es bitte für sich zu behalten... es sei denn, er hat schonmal sowas umgesetzt und weis was da bei meinen Gedankengängen kompletter schrott ist.


    Auf jedenfall würde ich es für "dumm" zu erachten, wenn 2 Leute mit ähnlichen Anforderungen an die Distri (also an die zur Verfügung stehende Software) 2 mal die selbe Distri soweit ausschalten wie es geht und danach um die selben Packete erweitern...


    Daher SlackVDR heißt das Kind... Je nachdem welche Packet-Serie man installiert hat man eben meine Packages oder die von Mreimer.. der Rest ist gleich...


    Binary kompatibel ists auch noch.. Also müsste man schlimmstenfall ein Package (per Script) umpacken und könnte so ohne Probleme meine Plugins für Mreimers VDR verwenden und umgekehrt.. falls einem was fehlen sollte...


    Dazu noch ein kleines Zitat von Mreimer:


    Quote

    Mein erstes Ziel wird auf jedem Fall sein, dass ich auf einem abgespeckten Slackware die grundlegenden Pakete aufbaue und zum Laufen kriege. Für's erste lege ich mich darauf fest, dass es von mir nur ein SlackVDR für FF-Karten geben wird. Primär brauche ich für meinen eigenen Bedarf eine Distribution bei der man auch eine Chance hat, "unter der Haube zu arbeiten". Dinge die ich selber nicht nutze und auch nicht testen kann, wird es von mir persönlich auch nicht geben.


    Genau so seh ich das auch!


    Ob jetzt die Binaries in Dir A oder in Dir B liegen ist vollkommen Wurscht (ums auf gut Österreichisch zu sagen ;) Viel wichtiger ists, einmal gewisse Use-Cases abzudecken.. darum auch mein Vorschlag zu VDR-Budget und VDR-FF Series (damit meine ich die Verzeichnisse unter slackware/ auf der CD wie a ap x ...).


    Wenn jemand VDR-FF installiert, hat er eine Ausgangsbasis für FF-VDRs die zumindest bei Mreimer geht... bei VDR-Budget eben die meinigen Packeten, die bei mir rennen...


    Durch die Spezialisierung wird die Installation viel einfacher => Mehr potentielle VDR-User => Besser für alle!



    73

  • hi
    soll das jetzt heisen das ich keine ahnung habe ?
    gut nach 3 distris hat man die nicht da hast du recht .
    hartware wo slackware und vdr mit s2 leuft hab ich auch nicht .
    vdr und plugins , configs ligen bei mir auch total ferstreut auf der blate aber das macht ja nix da hier eh keiner durchbliken mus .
    schribte von dier hab ich auch nie angeschaut wozu auch leuft ja eh nicht .
    so ungefehr kommt das bei mir an aber is schon ok .
    wenn man ein brojekt in dieser art aufziehen will solte als 1 das gruntgerüst stehen und hier kann ich in den gantzen keins finden , irgentwan habe ich mal gefragt wo soll was hin und keine antwort bekomen .
    beim vdr >1.5.x mus beim übersetzen für ferschitene pugins das schon ins macke file aber macht ja nix kann sich ja jeter endern auch der opa mit seinen geringen kentnisen .
    derzeitige hartware (grafigkarten sat/kabel ) laufen teilweise nichtmehr mit kerneltreibern aber hier setzt du auf einen orginal kernel was meiner ansicht nach ein fehler ist.
    so könte ich weitermachen aber schreiben ist nicht mein ding ,befor jetzt wider was mit meiner signatur kommt ich gehöre zur 1 sorte
    mfg det

    Jeder sollte sein Leben so leben können wie er/sie es möchte, frei und
    unabhängig, in der Not anderen zur Seite stehend, nie vergessen was man
    ist, eben einfach nur Mensch sein mit allen Schwächen und Stärken
    Lieber stehend sterben als ewig gebückt leben

  • Quote

    Original von oe6jwf
    ganz so ist das nicht.. es gibt so etwas wie einen Slackware-Standart nicht! Es gibt nur eine Form, die sich als brauchbar herauskristalisiert hat.


    Es gibt einen Weg, den alle Slackware-Nutzer in irgendeiner Form kennen. Und das sind die SlackBuilds, wie sie auch von Patrick kommen oder von slackbuilds.org geladen werden können.


    Für ein "echtes" Slackware-basiertes System wäre mir wichtig, dass alles in eben dieser Form gelöst ist.


    Später wäre ein slackbuilds.org-ähnliches System schön, um anderen Leuten eine Mitarbeit (Buildscripte für Plugins bauen) zu ermöglichen.


    Quote


    Auf jedenfall würde ich es für "dumm" zu erachten, wenn 2 Leute mit ähnlichen Anforderungen an die Distri (also an die zur Verfügung stehende Software) 2 mal die selbe Distri soweit ausschalten wie es geht und danach um die selben Packete erweitern...


    Sehe ich ganz ähnlich, aber ich suche halt nach etwas, das in jeder Hinsicht den von Patrick definierten Vorgaben für Slackware entspricht und auch slackbuilds.org-ähnlich die Mitarbeit von jedem beliebigen SlackBuild-Schreiber ermöglicht.


    Würde mir nicht ständig etwas anderes dazwischen kommen, dann hätte ich vielleicht auch endlich mal was, das ich vorzeigen könnte. Um meine SlackBuilds zu sammeln und ein Wiki + SlackBuilds-Datenbank zu fahren, werde ich aber auf jedem Fall Webspace mit eigener Subdomain besorgen.


    Da ich endlich mal kapieren will, wie VDR wirklich im System verankert werden muss und wie die wichtigsten Grundfunktionen gebaut werden müssen, beginne ich auf jedem Fall bei 0,0% und baue von dort auf, während ich wesentliches gleich im Wiki dokumentieren würde. Sobald ich irgendwo fertige Binaries brauche, habe ich nichts anderes wie LinVDR, vor dem ich auch recht hilflos sitze und versuche herauszufinden, wie das Ding denn nun wirklich funktioniert.

  • Was mich noch interessieren würde.. wie löst du es eigentlich das entpacken des VDR-Sources?


    gehst du davon aus, dass der bereits irgendwo liegt und kopierst/linkst dann das plugin dort rein?


    Zitat vom SlackWiki...

    Quote

    First, you need to understand that you can write your SlackBuild script in any manner you choose so long as it creates a working package; the method described here is more or less the way Pat Volkerding [[1]] does it, but even Pat has several different styles for writing the official SlackBuild scripts. Therefore, if you see something you would do a different way, feel free to do it that way - it's okay.


    Für VDR-Plugins etwas aufzubauen wie SlackBuilds.org finde ich... nennen wir es übertrieben... Lieber ein Repository in das man neue Slackbuilds einpflegt und ab und an gibts einen Snapshot der stable ist... sonst kann man sich "current" aus dem Repository holen...


    Für die Dependencies wärs überlegenswert die Slackbuilds gleich auf Slackbuilds.org zur Verfügung zu stellen...


    Naja meine Ideen zu dem ganzen...



    73

  • Noch habe ich zum Plugin-Bauen garkeine endgültige Lösung. Das wird, sobald ich die nötige Zeit finde. Leider ist VDR mit all seinen Scripten und kleinen Basteleien unwahrscheinlich komplex und unübersichtlich. Da muss man erstmal Herr drüber werden...


    Auch noch nicht geklärt ist, wo ich dann die Fortschritte zugänglich mache. Bezüglich vdr-developer.org bekomme ich keine Antwort.


    Alle SlackBuilds werde ich zentral in einem FTP halten und unter einem VCS verwalten. Auch die Abhängigkeiten.

  • Das Build-System würde mich echt interessieren... ich habe meins so "Struktur- und Konzeptlos" aufgezogen, da ich immer wieder zum Punkt gekommen bin, dass zumindest der VDR-Source immer entpackt sein muss...


    Ich werde mir aber noch was überlegen dürfen, da z.B das epgsearch-plugin noch einen patch haben will damit man das Standart-EPG vom VDR ersetzen kann... xineliboutput mit softosd hätte auch noch einen patch für den VDR damits noch etwas augenfreundlicher wird und sonst gibts sicher noch einige Plugins die für die Entfaltung aller Möglichkeiten gerne einen gepatchten VDR hätten...


    Nur wär mir ein Vanilla-VDR irgendwie am Liebsten... mal schaun wie ich das aufziehe.. vllt mach ich einen vdr-build vor allen plugin-builds und dann noch einen nachdem alle gebuildet sind mit dem gepatchten VDR.. dann hätte ich zwar 2 verschiedene VDR-Packages aber die Wahl zwischen Vanilla und patched VDR...


    73

  • Servus,


    Quote

    Bezüglich vdr-developer.org bekomme ich keine Antwort.


    @Mreimer:
    Da kann ich Dir evtl. weiterhelfen, wenn Du mir Deine Frage stellst :)


    Güsse,
    -Siegmar

    kostenlosen Webspace + Subdomain etc. für VDR-Projekte: pm an mich!
    Activy, 160GB HD, Celeron 633MHz, Gentoo Linux, vdr 1.4.1, PSone-Display an GraphTFT

  • hallo
    sory das ich das wider ausgrabe .
    hat jemand noch die Build-Scripte für den vdr ?
    mfg det

    Jeder sollte sein Leben so leben können wie er/sie es möchte, frei und
    unabhängig, in der Not anderen zur Seite stehend, nie vergessen was man
    ist, eben einfach nur Mensch sein mit allen Schwächen und Stärken
    Lieber stehend sterben als ewig gebückt leben