mpv funktioniert nicht nach dist-upgrade auf bookworm (gelöst))

[fischig]

Nach einem dist-upgrade von bullseye auf bookworm wirft mpv diesen Fehler:

Code: Alles auswählen

~$ mpv
mpv: symbol lookup error: mpv: undefined symbol: ass_track_set_feature

¹⁾
¹⁾ siehe auch: viewtopic.php?t=187197&hilit=mpv+lookup
Abgesehen davon, dass ich die „Erledigung“ im zitierten Thread nicht recht verstehe, ist celluloid bei mir nicht installiert. Zahlreiche weitere Hinweise auf github-Seiten zu diesem Fehler bringen mich auch nicht weiter.

[tobo]

Hast du was vom dmo installiert?
https://bugs.debian.org/cgi-bin/bugrepo ... ug=1026891

Ansonsten, hat wohl offensichtlich (ass==libass) was mit libass9 zu tun. Auf einem Bullseye:

Code: Alles auswählen

# grep -Frl ass_track_set_feature /usr/lib/x86_64-linux-gnu/
/usr/lib/x86_64-linux-gnu/libass.so.9.1.1
#

[fischig]

Hast du was vom dmo installiert?

Ich dachte eigentlich nein. Kein Eintrag in /etc/apt/sources.list und in /etc/apt/sources.list.d. ævidemux hatte ich früher mal von dort benutzt. Aber offenbar gibt's Altlasten:

Code: Alles auswählen

dpkg -l | grep dmo
ii  libass9:amd64                        2:0.14.0-dmo1                           amd64        library for SSA/ASS subtitles rendering
ii  libdvdcss2:amd64                     1.3.0-dmo1                              amd64        Simple foundation for reading DVDs - runtime libraries
ii  libfaac0:amd64                       1:1.29.9.2-dmo1                         amd64        AAC audio encoder - library files.
ii  libmp3lame0:amd64                    1:3.99.5-dmo4                           amd64        Shared libraries for MP3 encoding
ii  librtmp1:amd64                       2:2.4~20150315.gita107cef9b-dmo1        amd64        Toolkit for RTMP streams (shared library)
ii  libxvidcore4:amd64                   3:1.3.3-dmo1                            amd64        High quality ISO MPEG4 codec library

Das wird jetzt wohl ziemlich aufwendig, die zu beseitigen, insbesondere wegen libass9!

Danke für den Hinweis!

[dudax]

Ich würde versuchen die Ursache der Fehlermeldung systematisch einzukreisen. Also beispielsweise mal einen Test-User anlegen - wie verhält sich mpv dann?
Vielleicht ist der Fehler in der ~/.config/mpv/mpv.conf, die würde bei einem neuen User neu generiert werden.

[tobo]

Das wird jetzt wohl ziemlich aufwendig, die zu beseitigen, insbesondere wegen libass9!

Code: Alles auswählen

# apt-get install libass9/bookworm 	## etc.

[Livingston]

Hast du was vom dmo installiert?

Ich dachte eigentlich nein. Kein Eintrag in /etc/apt/sources.list und in /etc/apt/sources.list.d. ævidemux hatte ich früher mal von dort benutzt. Aber offenbar gibt's Altlasten:

Code: Alles auswählen

dpkg -l | grep dmo
ii  libass9:amd64                        2:0.14.0-dmo1                           amd64        library for SSA/ASS subtitles rendering
ii  libdvdcss2:amd64                     1.3.0-dmo1                              amd64        Simple foundation for reading DVDs - runtime libraries
ii  libfaac0:amd64                       1:1.29.9.2-dmo1                         amd64        AAC audio encoder - library files.
ii  libmp3lame0:amd64                    1:3.99.5-dmo4                           amd64        Shared libraries for MP3 encoding
ii  librtmp1:amd64                       2:2.4~20150315.gita107cef9b-dmo1        amd64        Toolkit for RTMP streams (shared library)
ii  libxvidcore4:amd64                   3:1.3.3-dmo1                            amd64        High quality ISO MPEG4 codec library

Das wird jetzt wohl ziemlich aufwendig, die zu beseitigen, insbesondere wegen libass9!

Alle diese Libs liegen in bookworm ohne Einbindung von dmo-Kram in höheren Versionen vor, auch libass9:

Code: Alles auswählen

$ dpkg -l libass9
ii  libass9:amd64  1:0.17.1-1   amd64        library for SSA/ASS subtitles rendering

Das sieht auf dem ersten Blick machbar aus.

[fischig]

Das sieht auf dem ersten Blick machbar aus.

Ja, hab's hingekriegt. mpv läuft sowohl auf bookworm als auch devuan/daedalus.

Nochmals danke!

libdvdcss2 lässt sich aber auf tobos Weise nicht ersetzen. Wenn ich recht sehe, gibt's das nicht für bookworm/daedalus.
Im Hinterkopf habe ich aber, dass man auf libdvdcss2 bei Multimedia-Programmen kaum verzichten kann. Ein purge-Versuch gibt allerdings keine Warnungen.

[Livingston]

libdvdcss2 lässt sich aber auf tobos Weise nicht ersetzen. Wenn ich recht sehe, gibt's das nicht für bookworm/daedalus.

Einspruch, Euer Ehren:

Code: Alles auswählen

ii  libdvdcss2:amd64 1.4.3-1~local amd64        library for accessing encrypted DVDs

Ganz regulär bei mir in bookworm installiert. (Übrigens auch auf einem anderen Rechner auf Devuan daedalus)

[tobo]

Wird das nicht durch libdvd-pkg generiert? Also:

Code: Alles auswählen

# apt-get install libdvdcss2- libdvd-pkg

[Livingston]

Wird das nicht durch libdvd-pkg generiert? Also:

Code: Alles auswählen

# apt-get install libdvdcss2- libdvd-pkg

Yes, jetzt sehe ich es auch. libdvdcss2 ist als locally gekennzeichnet. libdvd-pkg löst den Knoten.

[dudax]

Freut mich, wenn es wieder funktioniert.

Die Frage sei gestattet, was war denn nun die eigentliche Ursache für das Problem? Wenn ich es richtig verstehe, hat das dist-upgrade nicht einwandfrei funktioniert?

[Livingston]

Naja, mal sehen, ob es bei fischig auch geht. Tatsache ist, dass es generell ohne Fremdquellen wie debian-multimedia funktioniert.
Mit debian-multimedia kam es in der Vergangenheit immer mal zu Problemen, wenn Debian und das Multimediaprojekt unterschiedliche Paketabhängigkeiten forderten.
Inzwischen ist das größtenteils obsolet, weil Debian inzwischen fast alles von sich aus mitbringt, wofür man früher debmulti einbinden musste.
libdvdcss2 ist ein Paradebeispiel. Lizenztechnisch konnte Debian das Ding nicht gestatten (urheberrechtlich war da, glaube ich, auch was im Argen). Aber seit Kurzem - sprich seit ca. 10 Jahren - behilft man sich eines Tricks. Das Paket libdvd-pkg lädt den bösen Kram aus öffentlich zugänglichen Quellen nach, und übernimmt die Verantwortung, dass alles glatt gefunden und aufbereitet wird. libdvd-pkg selbst steht unter einer freien Lizenz und darf daher Teil des Debian-Projektes sein.

[fischig]

Hmm!

Ihre Suche nach Paketen, deren Name libdvdcss2 enthält, in allen Suites, allen Bereichen, und auf allen Architekturen:

Leider ergab Ihre Suche kein Ergebnis¹⁾

Was hab' ich denn da jetzt wieder falsch gemacht?

Vielleicht so:

Code: Alles auswählen

~# apt-get -s install libdvdcss2/bookworm
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Hinweis: »libdvd-pkg« wird an Stelle von »libdvdcss2« gewählt.
Version »1.4.3-1-1« (Debian:12.1/stable [all]) für »libdvd-pkg« gewählt.
Die folgenden Pakete wurden automatisch installiert und werden nicht mehr benötigt:
  libfuse3-3 libgnutls-deb0-28 libhogweed2 libnettle4 libntfs-3g89
Verwenden Sie »apt autoremove«, um sie zu entfernen.
Die folgenden NEUEN Pakete werden installiert:
  libdvd-pkg

¹⁾ https://packages.debian.org/search?keyw ... ection=all

tobo war schneller!

[edit]
@dudax

Die Frage sei gestattet, was war denn nun die eigentliche Ursache für das Problem?

bookworm-mpv vertrug sich nicht mit meiner libass9-Version von deb-multimedia.org

[Livingston]

@fischig, kleiner Tipp: Ich glaube, Du kannst alle Abhängigkeiten zu multimedia loswerden. Sieht nicht danach aus, als hättest Du allzu exotische Anforderungen, die das Original bookworm/daedalus nicht auch drauf hätte.

[fischig]

@@fischig, kleiner Tipp: Ich glaube, Du kannst alle Abhängigkeiten zu multimedia loswerden.

Bin ich jetzt auch. Aber das mit libdvdcss2/libdvd-pkg kommt mir erst mal als ein ziemliches Gewürge vor. Und automatische Upgrades mag ich ja überhaupt nicht. Mal sehen, was meine Ablehnung dessen da wieder mit meinem löchrigen Gedächtnis in Zukunft produziert.

[Livingston]

Ich hab mir libdvd-pkg noch mal genauer angeschaut. Automatisch passiert da gar nix. Wenn Du (manuell) upgradest, schaut es halt nach, was es Neues gibt, und zwar hier: https://salsa.debian.org/multimedia-tea ... /libdvdcss
Wie Du siehst, ist das eine Seite des Debian-Projektes, der Inhalt liegt aber außerhalb des regulären Repositorys, da wie gesagt die Lizenzen dies erzwingen.
Die eigentliche Upstream-Quelle ist das Projekt Videolan, das auch für den vlc verantwortlich zeichnet. Allerdings werden nicht einfach die Original-Inhalte von Videolan blind übernommen, sondern sie werden von der Gruppe Debian Multimedia Maintainers und dem (Original?)-Autor Dmitry Smirnov betreut und begutachtet, wie man hier in der rechten Spalte der Seite sehen kann.
Meiner Meinung nach ist damit der Spagat zwischen Lizenzschwierigkeiten und guter Paketbetreuung vorbildlich gelöst.

Hier ist übrigens der Original-Upstream von libdvdcss: https://download.videolan.org/pub/libdvdcss/
Das Erste, was mir auffiel: Die "aktuelle" Version ist 2,5 Jahre alt. Muss nix Böses heißen, denn es ist sehr unwahrscheinlich, das sich an dieser Stelle (DVD-Kopierschutz) inhaltlich noch was tut. Wenn alle Beteiligten Sicherheitsrelevantes auf dem Schirm haben, gibt es dort auch Updates. Das dürfte sich so bemerkbar machen, dass auch das Paket libdvd-pkg ein Sicherheits-Update verpasst bekommt, und dann die korrigierte Fassung geladen wird.

[dudax]

Danke für die Antworten ... ich lese mit großem Interesse mit

[Livingston]

Sowas ähnliches gibt es auch hier: ttf-mscorefonts-installer
Das Ding lädt die wichtigsten Fonts von Microsoft runter. Microsoft würde einem den Kopf abreißen, wenn man deren patentierten und rechtlich 1000x abgesicherten Schriftsätze selbst hosten würde. Es spricht aber nix dagegen, einen Installer zu basteln, der die öffentlich zugänglichen Dateien runterlädt.
Im Unterschied zu libdvd-pkg werden hier die MS-Dateien nicht nochmal von Debian-Betreuern quergelesen, sondern 1:1 direkt gedownloadet.

[fischig]

Bitte führen Sie »sudo dpkg-reconfigure libdvd-pkg« aus, um diesen Prozess erstmalig in Gang zu setzen.

von Debian hätte ich das nicht erwartet.

Falls aktiviert, kümmert sich der APT-Hook nach dem Aufruf um automatische Upgrades von libdvdcss2 (die durch neue Versionen von libdvd-pkg ausgelöst werden
können). Wenn Aktualisierungen verfügbar sind, wird der Hook das Herunterladen der Quellen in Gang setzen, sie erneut kompilieren und (falls »apt-get check«
keine Fehler zurückgibt) die neuen Versionen mittels »dpkg -i« installieren. Alternativ kann der Prozess manuell durch Ausführen von »sudo dpkg-reconfigure libdvd-pkg« gestartet werden.

Meiner Meinung nach ist damit der Spagat zwischen Lizenzschwierigkeiten und guter Paketbetreuung vorbildlich gelöst.

Das mag so sein. Die Dialogführung ist es meiner Meinung nach nicht, ich finde die ziemlich undurchsichtig.

APT-Hook: Insider-Sprech. VDR-Entwickler: dito.

[dudax]

Nochmal laut nachgedacht ... ich bin doch ziemlich darüber überrascht, das der Befehl ' apt dist-upgrade' auf Inkompatibilitäten einzelner Pakete nicht hinweist, sondern offensichtlich ohne Rücksicht auf Verluste darauf loslegt.
Wäre aptitude in diesem Fall hilfreicher gewesen?
Oder anders gefragt, welche Vorgehensweise wäre in diesem Fall optimal gewesen?

[fischig]

ch bin doch ziemlich darüber überrascht, das der Befehl ' apt dist-upgrade' auf Inkompatibilitäten einzelner Pakete nicht hinweist, sondern offensichtlich ohne Rücksicht auf Verluste darauf loslegt.

Das ist etwas unfair. apt weiß nichts von Fremdpaketen, zumal von solchen, die gar nicht in der sources.list stehen. Ich benutze es zwar nicht, aber ich denke, das ist bei aptitude nicht anders.

Oder anders gefragt, welche Vorgehensweise wäre in diesem Fall optimal gewesen?

Vorher nachschauen, ob Fremdpakete auf dem System sind und gegebenenfalls eliminieren/ersetzen.

[Livingston]

Falls andere Quellen in /etc/apt/sources.list und /etc/apt/sources.list.d/... als üblich stehen, hat man sie ja bewusst eingebaut und weiß, man sich da antut. apt macht nichts anderes, als zu versuchen, die Wünsche des Herrn und Meisters umzusetzen.
aptitude ist ganz schnuckelig, weil man es ohne Parameter zum Browsen durch die Pakete nutzen kann, ohne sich synaptic o.ä. antun zu müssen.
Mit Parametern aufgerufen macht es das, was apt auch tut.

[tobo]

Nochmal laut nachgedacht ... ich bin doch ziemlich darüber überrascht, das der Befehl ' apt dist-upgrade' auf Inkompatibilitäten einzelner Pakete nicht hinweist, sondern offensichtlich ohne Rücksicht auf Verluste darauf loslegt.

Das hier sind ja keine Inkompatibilitäten von Paketen - eine Inkompatibilität wäre z.B., dass das Paket xyz (als Abhängigkeit) in der entsprechenden Version nicht vorliegt. Wenn dann eine bestimmte Datei in einem Paket nicht vorhanden ist, dann ist das kein Problem für das Paketsystem, sondern für den entsprechenden Paketbetreuer. Und wenn Funktionalität einer Datei im Paket fehlt, dann ist das Sache der Programmierung.

Wäre aptitude in diesem Fall hilfreicher gewesen?

Nein. Für das Paketsystem ist ja alles ok - jede Abhängigkeit ist erfüllt.

Oder anders gefragt, welche Vorgehensweise wäre in diesem Fall optimal gewesen?

Ist nicht klar zu beantworten, aber grundsätzlich Fremdquellen nicht (über Distributionsgrenzen) zu verwenden ist bestimmt weit vorne...

[Livingston]

Ergänzend zu tobos Beitrag:
Fremdquellen sollte man maximal kontrollieren. Dass es möglich ist, sie einzubinden ist eine bewusste Entscheidung des Debian-Projektes. Wie man es umsetzt ebenso: Es gibt apt-pinning, was es ermöglicht, zielgenau einzelne Pakete oder ganze Bereiche an Software außerhalb des Debian.org-Universums direkt einzubinden. Das setzt aber eine Auseinandersetzung mit der ganzen Materie voraus.
Wenn man das ernsthaft getan hat, kann man damit arbeiten. Was aber in 99% aller Fälle zu Problemen führt ist, wenn man "mal eben" die sources.list ergänzt und den Rest Gott anvertraut. Ähnliche Schnellschüsse haben schon die Heilige Inquisition zu Fehlurteilen verleitet.

Und weil ich niemanden im Regen stehen lassen will, hier noch ein wenig Lesestoff zum Thema:
man apt_preferences
https://wiki.debian.org/de/AptPreferences
AptPinning
Forensuche: apt pinning

Und wenn man nicht weiter kommt: Hier fragen, da wird Sie gehilft.

Zugegeben, apt-pinning ist auf Anhieb nicht leicht zu durchschauen. Es sollten müssten dürfen werden sich ganz bestimmt diejenigen von uns, die sich damit auskennen, unser Wiki verbessern, um Fragen um dieses Thema zielgerichteter beantworten zu können.

[dudax]

Fremdquellen sollte man maximal kontrollieren. Dass es möglich ist, sie einzubinden ist eine bewusste Entscheidung des Debian-Projektes. Wie man es umsetzt ebenso: Es gibt apt-pinning, was es ermöglicht, zielgenau einzelne Pakete oder ganze Bereiche an Software außerhalb des Debian.org-Universums direkt einzubinden. Das setzt aber eine Auseinandersetzung mit der ganzen Materie voraus.

Vor ein paar Jahren habe ich mir mal Probleme mit Fremdquellen eingefangen, seitdem möchte ich mich als kuriert bezeichnen.
Allenfalls entpacke ich mal ein Java-Programm im Benutzerverzeichnis, installiere jedoch nicht an apt vorbei.
Was mir Debian an Paketen anbietet, ist für meine Anforderungen mehr als ausreichend.

Das Pinning ist eine sehr interessante Sache, denn vor ein paar Tagen wollte ich ein Paket installieren, das in testing nicht verfügbar ist:

Code: Alles auswählen

Paket eboard ist nicht verfügbar, wird aber von einem anderen Paket
referenziert. Das kann heißen, dass das Paket fehlt, dass es abgelöst
wurde oder nur aus einer anderen Quelle verfügbar ist.
Doch die folgenden Pakete ersetzen es:
  zseal

E: Für Paket »eboard« existiert kein Installationskandidat.

Jedoch ist das Paket in stable verfügbar:

https://packages.debian.org/search?keyw ... ection=all

Pinning erlaubt es Ihnen gewisse Pakete aus einer bestimmten Version zu verwenden (Stable, Testing, Unstable), ohne die Notwendigkeit das ganze System zu aktualisieren.

https://wiki.debian.org/de/AptPreferences

Klingt doch gut. Ich werde für Testzwecke demnächst mal eine VM einrichten.