[gelöst] yavdr 0.5 testing skinnopacity funktioniert nach update nicht mehr

  • Hallo, nachdem mein yavdr für ein paar tage prima mit dem testing - Stand funktionierte, habe ich heute nach einem Update Probleme mit dem Plugin skinnopacity. VDR stirbt kurz nach dem Start mit einem SegFault in der Plugin Lib.


    Das Problem war verschwunden nachdem ich das Paket "curl" installiert habe. Laut louis wird libcurl seit nOpacity 0.1.1 benötigt. Bei der Installation über apt-get wird diese Abhängigkeit nicht automatisch aufgelöst.


    Falk

  • Ich benutze definitiv NICHT unstable, sondern testing. Mit der Version von nOpacity bin ich mir nicht so sicher (kann gerade nicht nachsehen), das war eine Vermutung von "louis".


    Auf jeden Fall besteht da eine Abhängigkeit, die nicht automatisch gelöst wurde.


    Falk

  • Sorry für die falsche Versionsangabe für das Plugin. Ich hatte dem Autor des Plugins einfach geglaubt, dass er weiß, ab welcher Version welche zusätzlichen libs benötigt werden.


    Hier noch mal (genau), wie die Entstehungsgeschichte war:


    - yavdr 0.5.0 installiert
    - testing ppa's hinzugefügt
    - dist-upgrade durchgeführt
    - Plugin skinnopycity installiert
    - ein weiteres Plugin selbst gebaut und installiert
    - VDR einige Tage benutzt
    - nochmals dist-upgrade durchgeführt
    - Plugin nOpacity produziert SEGFAULT
    - Plugin nOpacity de-installiert (apt-get remove)
    - VDR funktioniert


    - Plugin nOpacity neu installiert (apt-get install)
    - wieder SEGFAULT
    - nach Rücksprache mit Plugin Autor paket "curl" installiert (apt-get install curl)
    - nOpacity funktioniert wieder.


    Wenn die Abhängigkeiten alle ok wären, hätte das fehlende Paket ja schon bei der ersten Installation von nOpacity mit installiert werden müssen, oder aber, das Plugin hätte da schon versagt. Scheinbar hat aber bei der ersten Installation nichts gefehlt. Es wurde aber auch definitiv nichts de-installiert. Das Problem trat unmittelbar nach dem 2. dist-upgrade auf, bei dem nOpacity aktualisiert wurde. Unmittelbar danach hat's gekracht, während unmittelbar davor alles ok war.


    Vielleicht hat es ja an genau dieser Vorgehensweise gelegen, dass da irgendwelche Abhängigkeiten durcheinander gekommen sind.

  • Moin!


    Es wäre schön, wenn alle Beteiligten einfach mal wieder tief durchatmen, bitte. Mit gegenseitigen Beleidigungen kommen wir nicht weiter und es hilft niemandem.
    Ich werde mich in Abstimmung mit fnu darum kümmern, dass für xine, skinnopacity und sonstige beteiligten Pakete dbg-Pakete in das PPA kommen, damit problemlos ein Backtrace erstellt werden kann (egal von wem).


    Letztendlich wollen wir alle doch einfach nur dabei helfen, den Fehler zu finden. Lasst uns das bitte tun. :)
    Außerdem ist doch jetzt endlich Frühling, seit dem Wochenende sind's hier endlich ab und zu über 10°C! Und es scheint sogar ein bisschen die Sonne!


    Lars.

  • Außerdem ist doch jetzt endlich Frühling, seit dem Wochenende sind's hier endlich ab und zu über 10°C! Und es scheint sogar ein bisschen die Sonne!

    Hier sind's sogar schon über 20 Grad. Liegt vielleicht an den erhitzten Gemütern. :D


    Zitat

    Letztendlich wollen wir alle doch einfach nur dabei helfen, den Fehler zu finden. Lasst uns das bitte tun

    Gute Idee, hat denn nach meiner nun etwas genaueren Beschreibung eine Idee, wie es dazu gekommen sein könnte. Ich habe das Problem für mich zwar gelöst, aber andre könnten noch drüber stolpern

  • Das aktuelle Paket hat eine Abhängigkeit zu libcurl4-openssl-dev, müsste eigentlich passen.
    Baut noch in testing, kann noch ein klein wenig dauern.


    Lars.

  • Das aktuelle Paket hat eine Abhängigkeit zu libcurl4-openssl-dev, müsste eigentlich passen.
    Baut noch in testing, kann noch ein klein wenig dauern.


    Ich glaube nicht, dass das Paket curl wirklich gebraucht wird. Wahrscheinlich geht es um einer der Abhängigkeiten von curl:

    Code
    apt-cache depends curl
    curl
      Hängt ab von: libc6
      Hängt ab von: libcurl3
      Hängt ab von: zlib1g
      Ersetzt: <curl-ssl>
        curl
      Ersetzt: <curl-ssl:i386>
        curl:i386
      Kollidiert mit: curl:i386


    auch libcurl4-openssl-dev hängt unter anderem von libcurl3 ab. Wenn libcurl support wirklich rein kompiliert ist, dann müsste die Abhängigkeit eigentlich automatisch gefunden werden.


    spitzb: Interessant wäre mal:

    Code
    apt-cache depends vdr-plugin-skinnopacity
    ldd /usr/lib/vdr/plugins/libvdr-skinnopacity.so.2.0.1


    (aus dem Kopf getippt, verifizieren!)


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Ich habe curl installiert, weil es das einzige Paket war, das ich finden konnte, das diese lib enthält.


    Nein, das enthält die libcurl nicht. Das ist nur abhängig von ihr. In dem Paket ist nur das Executable curl drin.


    Wie ist es jetzt mit den Ausgaben um die ich gebeten hatte?


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • gda


    Code
    apt-cache depends vdr-plugin-skinnopacityvdr-plugin-skinnopacity  Hängt ab von: libc6  Hängt ab von: libgcc1  Hängt ab von: libmagick++4  Hängt ab von: libstdc++6  Kollidiert mit: vdr-plugin-skinnopacity:i386



    und


    Code
    ldd /usr/lib/vdr/plugins/libvdr-skinnopacity.so.2.0.0        linux-vdso.so.1 =>  (0x00007fff751bb000)        libMagick++.so.4 => /usr/lib/libMagick++.so.4 (0x00007f949a262000)        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f9499f62000)        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f9499d4b000)        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f949998c000)        libMagickWand.so.4 => /usr/lib/libMagickWand.so.4 (0x00007f9499677000)        libMagickCore.so.4 => /usr/lib/libMagickCore.so.4 (0x00007f94991f3000)        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f9498ef7000)        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f9498cda000)        /lib64/ld-linux-x86-64.so.2 (0x00007f949a732000)        libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f94989a5000)        libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007f9498797000)        liblcms.so.1 => /usr/lib/x86_64-linux-gnu/liblcms.so.1 (0x00007f9498560000)        libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f94982c3000)        liblqr-1.so.0 => /usr/lib/liblqr-1.so.0 (0x00007f94980af000)        libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f9497e79000)        libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f9497c67000)        libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007f9497a57000)        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f9497840000)        libltdl.so.7 => /usr/lib/x86_64-linux-gnu/libltdl.so.7 (0x00007f9497635000)        libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f9497417000)        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f9497213000)        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f949700a000)        libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f9496d15000)        libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f9496aea000)        libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f94968e7000)        libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f94966e1000)        libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f94964a3000)


    Irgendwie gehen mir in den "code" feldern immer die Zeilenschaltungen verloren.


    Falk

  • Irgendwie gehen mir in den "code" feldern immer die Zeilenschaltungen verloren.


    Einfach die code-Tags hinterher drum herum tippen.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Zumindest diese Version von skinnopacity greift nicht auf libcurl zu. Sieh einfach auf die Ausgabe von ldd. Deshalb gibt es bei der darüber liegenden Ausgabe auch keine Abhängigkeit zu einer libcurl.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Ich habe spaßeshalber mal das Paket "curl" entfernt. Und siehe da, VDR samt nOpacity funktioniert immer noch.


    Sieht also so aus, als hätte es wirklich an einer der Abhängigkeiten von curl gelegen, wie z.B. libcurl3. Vielleicht hatte ich nur einen schlechten Tag für den dist-upgrade erwischt.


    Falk

  • Moin!


    Hast du jetzt eigentlich das Paket von gestern mit 0.1.1 installiert?


    Was beim Einfügen von Code hilft, ist die Quellcode-Ansicht des Editors.


    Lars.

  • Sieht also so aus, als hätte es wirklich an einer der Abhängigkeiten von curl gelegen, wie z.B. libcurl3. Vielleicht hatte ich nur einen schlechten Tag für den dist-upgrade erwischt.


    Du hörst mir nicht zu! Es gibt keine Abhängigkeit zur libcurl3. ldd beweist, dass das Plugin die libcurl3 nicht benutzt. Selbst wenn das Plugin die libcurl zur Linkzeit schon gebraucht hätte, aber nicht bekam, dann hätte ein nachinstallieren der Lib zu Laufzeit nicht geholfen, weil der Loader gar nicht weiß, dass er sie laden soll.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Moin!


    So sieht es übrigens beim aktuellen Paket aus:



    Zumindest aktuell sieht alles gut aus.


    Lars.

  • Moin,


    also ich kann nur sagen, dass ich


    C
    #include <curl/curl.h>
    #include <curl/easy.h>


    im Code habe...im makefile habe ich


    Code
    LIBS += $(shell pkg-config --libs libcurl)


    Ich habe nicht genauer geforscht, welches Paket da benötigt wird, bei mir hat es direkt funktioniert.


    Edit: ah jetzt sehe ich es, beim ldd von Lars wird ja auch


    libcurl.so.4 => /usr/lib/x86_64-linux-gnu/libcurl.so.4


    angezeigt...hatte mich schon gewundert, dass gar nix bezüglich curl benötigt wird.


    Ciao Louis

  • Moin!


    Wenn die Abhängigkeit zu dem libcurl-Paket nicht angegeben wäre, dann würde das Plugin ja auch gar nicht kompilieren, weil es curl.h nicht finden würde. :)
    Von meiner Seite aus sehe ich jetzt auch kein Problem, bei mir läuft das Skin auch.


    Lars.

  • und wo war jetzt das problem ?


    wenn es nicht kompilieren würde, könnte es spitzb ja auch nicht aus dem ppa installieren ??
    irgendwas muss ja anders sein bei spitzb als bei den anderen ? nur was ? bei mir reichte es das paket zu installieren, und geht ohne segfault.

Jetzt mitmachen!

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