[0.5] testing/stable-vdr-Update - PPAs sind wieder freigegeben (war: kein dist-upgrade machen!)

  • Moin!


    Heute im Laufe des Tages und Abends werde ich die precise-Pakete aus testing-vdr nach stable-vdr kopieren (immer noch vdr 1.7.27) und danach dann den vdr 1.7.33 aus unstable-vdr nach testing-vdr kopieren.
    Sinn des ganzen: Den Stand aus unstable-vdr "sichern" und Platz für die nächste Version machen (keine Sorge, die ist noch nicht so weit...).


    Also: Bis ich wieder Entwarnung gebe, darf kein dist-upgrade gemacht werden.
    Falls es doch jemand macht, muss er warten, bis der Umzug fertig ist. Danach sollte ein weiteres dist-upgrade wieder für Ruhe sorgen. Wenn nicht... Naja, irgendjemand wird schon wissen, wie man das wieder gerade biegt... :)


    2013-03-07 19:00
    Update: Meines Wissens nach sind alle drei PPAs (unstable-/testing-/stable-vdr) wieder in sich konsistent. => Entwarnung
    Die ersten haben auch schon erfolgreich ein Update durchgeführt, ich werde meinen vdr am Wochenende auch auf den aktuellen stable-Stand bringen. Tut euch selbst einen Gefallen und macht ein Update nur dann, wenn ihr auch ein wenig Zeit habt, nicht zwischen Tür und Angel oder wenn viele, wichtige Aufnahmen anstehen... :)
    Insbesondere ist ein Update nicht unbedingt ein Muss, der vdr selbst hat sich eigentlich nicht verändert. Das einzige ist ein Bugfix im Zusammenhang mit rotorng, das sollte jetzt hoffentlich funktionieren.


    Ein Hinweis an Entwickler: Auch wenn es alte vdr-Versionen sind (1.7.27 und 1.7.33), beinhaltet das vdr-dev-Paket jetzt eine pkg-config-Datei (/usr/lib/pkgconfig/vdr.pc). Falls ihr da also manuell eine angelegt habt, entfernt diese vor dem Update bitte.
    Vorteil ist, dass Plugins mit neuem Makefile problemlos für den alten vdr gebaut werden können. Ein paar Plugins nutzen das sogar schon (in unstable zumindest), die Theorie scheint also zumindest teilweise zu funktionieren. Ich hoffe, das hilft euch bei der Portierung der Plugins für den bald kommenden vdr 2.0.


    Lars.

  • Das gleiche gilt natürlich für meine XBMC-PVR-PPAs, da vdr-plugin-xvdr und vdr-plugin-vnsiserver immer gegen die entsprechende VDR-Version gebaut sein müssen.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Moin!


    Schon mal die erste gute Nachricht: stable-vdr ist in sich wieder konsistent.


    Durch ein leichtes menschliches Versagen auf meiner Seite sind allerdings ein paar Plugins neuer als vorher, es betrifft aber nur ein paar. Auf ein paar dieser Updates haben sich auch schon einige länger gefreut. Eventuell sollten jetzt vielleicht nicht gleich alle ein Update ziehen, sondern erst mal die Mutigen vorlassen. :)
    Ich freue mich über positive Rückmeldungen, wenn das Update keine Probleme bereitet. Wenn was nicht läuft, dürft ihr das natürlich auch gerne sagen, ich sorge dann dafür, dass es behoben wird.


    Wer eigene Plugins oder welche aus fremden PPAs benutzt, sollte sie gegen den aktuellen vdr noch einmal neu bauen.
    Das geht ungefähr so:

    Code
    sudo apt-get update
    sudo apt-get build-dep vdr-plugin-<name>
    mkdir ~/src
    cd ~/src
    apt-get source vdr-plugin-<name>
    cd <hier passenden Verzeichnisnamen angeben>
    dpkg-buildpackage -tc -us -uc
    cd ..
    sudo dpkg -i <Paketname>


    testing und unstable sind noch nicht ganz wieder da, da fehlt noch restfulapi, das weigert sich noch ein wenig zu bauen. Aber ich bin zuversichtlich, dass ich das bald im Griff habe.


    Have fun!


    Lars.

  • Moin,


    beim dist-upgrade möchte er yavdr-essential und yavdr-webfrontend entfernen. Soll das so sein?

  • Eigentlich nicht - kannst du festmachen an welchen Paketen das hängt?


    BTW: meine PVR-PPAs sollten angepasst sein.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Das gibt er mir zurück

    Code
    Die folgenden Pakete werden ENTFERNT:
    vdr-plugin-restfulapi yavdr-essential yavdr-webfrontend


    :modon Bitte Boardregeln beachten, war zwar schon ausge-x-t, aber trotzdem... :) :modoff

    Einmal editiert, zuletzt von mini73 ()

  • Wo kommt dein restfulapi-Plugin her? Hast du das selbst gebaut?


    yavdr-essential und yavdr-webfrontend hängen von restfulapi ab, wenn das Paket nicht installiert werden kann, können die Abhängigkeiten nicht aufgelöst werden.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Einmal editiert, zuletzt von seahawk1986 ()

  • restful-api ist selbst gebaut und stumpf drüber kopiert


    Habe aber eben mal in meine yavdr.list geschaut - da steht testing-vdr
    nach dem Wechsel zurück auf stable wird nichts entfernt


    sorry :whistling:

  • Moin!


    Kein Problem, ist ja ein typisches Szenario:


    Wenn man eigene Versionen von Plugins benutzt, von denen yavdr-essentials abhängt, ist es immer etwas problematisch. Dann muss man mit untie-packages (oder so ähnlich, siehe Doku) arbeiten.


    Wenn man externe Plugins benutzt, muss man sie vor einem Update deinstallieren, das Update durchführen (manchmal ist ein Neustart empfehlenswert), sie neu bauen und dann wieder installieren.


    Lars.

  • Oder viel viel viel einfacher: erstellt euch ein eigenes PPA für diese Plugins. Wenn sich die VDR-Version in den yaVDR-Quellen ändert, einfach das Plugin im eigenen PPA mit Bauabhängigkeit von den gewünschten yaVDR-PPAs neu bauen lassen. Dann kommt alles in einem Rutsch mit dem nächsten Paketupdate rein.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Noch ein kleiner Status-Bericht von mir:


    mit yavdr/stable-vdr und xxx/testing-vdr läuft das dist-upgrade sauber durch und nichts wird deinstalliert.


    Dann startet der VDR wegen dem play-plugin nicht mehr.
    play hatte ich zwar aus dem git gebaut aber das ist doch auch aktuallisiert worden?
    Habe es dann nochmal neu gebaut und alles ist gut.


    Danke

  • Moin zusammen,


    seit dem gestrigen Upgrade (ca. 21:30 gemacht) bekomme ich sporadisch beim Start des VDR folgende Fehler:

    Code
    Mar  8 09:47:26 htpc vdr: video/vdpau: can't create presentation queue: A catch-all error, used when no other error code applies.
    Mar  8 09:47:26 htpc kernel: [   18.498870] dbus2vdr messag[2183]: segfault at 18 ip 00007f626fe51674 sp 00007f6206ac08a0 error 4 in libc-2.15.so[7f626fdd2000+1b5000]
    Mar  8 09:47:27 htpc kernel: [   18.620238] init: vdr main process (1286) killed by SEGV signal
    Mar  8 09:47:27 htpc kernel: [   18.622472] init: graphtft-fe-DL main process (1468) killed by TERM signal
    Mar  8 09:47:27 htpc kernel: [   18.624277] init: vdr-frontend main process (2172) killed by TERM signal


    Kann das etwas mit dem Update zu tun haben oder stirbt meine GraKa?


    Cheers,
    Ole


    PS: Testweise werde ich mal meine DisplayLink-Scripte wegkopieren, nicht dass die mir mal wieder in die Suppe spucken...

  • Das sieht nach einem Problem mit den DisplayLink-Scripten aus. Kopiere ich sie weg, startet das System sauber.
    Ich teste jetzt mal mit Scripten und vdr-dbg.


    Cheers,
    Ole

  • Dann bin ich beruhigt... :)


    Ich nicht. :D


    Gibt's schon beim Booten einen Unterschied, ob ich vdr-dbg verwende oder den normalen VDR?
    Mit DAEMON=/usr/bin/vdr-dbg in /etc/default/vdr bootet das System auch mit DisplayLink-Scripten sauber,
    zumindest die letzten 10x. :§$%


    Cheers,
    Ole

Jetzt mitmachen!

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