Audacious music player will unter Freebsd 14.1 nichts abspielen.

[Linuxfreakgraz]

Unter Freebsd 13.2 funktionierte der Player noch tadellos.
Ich erhalte im Terminal folgenden Fehler.

audacious
ERROR ../src/libaudcore/plugin-load.cc:70 [plugin_load]: /usr/local/lib/audacious/Input/sid.so could not be loaded: /usr/local/lib/libsidplayfp.so.6: Undefined symbol "__kmpc_fork_call"
ERROR ../src/pipewire/pipewire.cc:311 [init_core]: PipeWireOutput: unable to connect context
ERROR ../src/pipewire/pipewire.cc:311 [init_core]: PipeWireOutput: unable to connect context
ERROR ../src/pipewire/pipewire.cc:311 [init_core]: PipeWireOutput: unable to connect context

Pipewire ist in der Version 1.0.4_3 installiert und libsidplayfp ist in der Version 2.7.1 installiert.

Der VLC spielt dagegen alles ab, an der Quelldatei kann es also nicht liegen.
Vorschläge?

Edit: wenn ich in den Player Einstellungen die Ausgabe von Pipewire auf Pulseaudio umstelle funktioniert der Player, Pipewire ist wohl noch zu experimentell für Freebsd.

 

[Abrexxes]

Liegt die sid.so (lib) denn in dem angegebenen Ordner? Wenn nicht such sie im Programm Ordner und kopiere sie mal dahin. Sudo Rechte erforderlich. Deswegen kann es sein das dies nicht passiert ist.

 

[andy_m4]

Unter Freebsd 13.2 funktionierte der Player noch tadellos.

Hast Du ein Upgrade von FreeBSD 13.2 gemacht oder ist das ein frisches FreeBSD 14.1 ?

libsidplayfp ist in der Version 2.7.1 installiert.

Möglicherweise passt die Version nicht (was dann ein Bug im Package/Port wäre).

Auf Anhieb fallen mir zwei Möglichkeiten ein, das Problem (möglicherweise) zu beheben.

1. Du wechselst zum latest-Repository (was insbesondere für ein Desktop-System eh zu empfehlen wäre)
2. Du baust den Port selbst (/usr/ports/multimedia/audacious-plugins) und wirfst via make config den SID-Support raus (den Du vermutlich eh nicht brauchst?)

Pipewire ist wohl noch zu experimentell für Freebsd.

Mir ist dahingehend noch nichts aufgefallen. Was aber nicht unbedingt was heißen muss. :-)

Ergänzung (26. Juli 2024)

Im Bugzilla gibts ein Bug der in die Richtung geht:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277844
Bisher kümmert sich da aber noch keiner drum.

 

[Linuxfreakgraz]

Hast Du ein Upgrade von FreeBSD 13.2 gemacht oder ist das ein frisches FreeBSD 14.1 ?

Nein ist eine frische Installation, beim Versuch von 13.2 direkt auf 14.1 upzugraden hab ich nämlich die Installation geschrottetet.

Das mit den Ports hab ich noch nicht ausprobiert.

@Abrexxes ich werde das überprüfen.

 

[andy_m4]

hab ich nämlich die Installation geschrottetet.

Das eine Installation nach einem Upgrade "geschrottet" war ist mir bisher noch nie passiert, weshalb ich natürlich neugierig wäre, was da eigentlich geschehen ist.

Gibt so zwei klassische Probleme (die sich aber ohne Neuinstall beheben lassen):

1. Man benutzt einen Kernel-Treiber aus den Packages/Ports. Typisch ist hier so was wie der Grafiktreiber. Wenn der noch gegen den alten Kernel gebaut ist, dann funktioniert der auf den Neuen i.d.R. nicht. Im schlimmsten Fall hat man einen schwarzen Bildschirm. Wenn man den über die /etc/rc.conf lädt ist es i.d.R. kein Problem. Dann bootet man FreeBSD im SingleUserMode, mountet den Root-Disk as r/w, kommentiert den Treiber und rebooten dann. Updated den Treiber (bzw. wird das ja mit gemacht im Zuge von pkg-static upgrade -f). Testet mit kldload ob der funktioniert und kann ihn dann in der /etc/rc.conf wieder rein nehmen.
2. Man hat ein zpool upgrade gemacht ohne den Bootloader neu zu schreiben.
   In dem Fall kann man das dadurch beheben, in dem man von einem FreeBSD-Install-Medium booten und das nachholen

Das mit den Ports hab ich noch nicht ausprobiert.

Die Ports sind per default on-par mit dem lastest-Package-Repository. Wenn man das also "einfach so" macht, kann gut sein, das per Abhängigkeiten noch mehr upgraded wird, und dann hätte man ein Quarterly-Latest-Mischmasch-System, was erst mal nicht so gut ist.

Wichtig ist daher, dann den entsprechenden quarterly-Branch zu nehmen (https://cgit.freebsd.org/ports/log/?h=2024Q2 musste das sein) wenn Du quarterly-Packages hast.

 

[Linuxfreakgraz]

Der Sicherheitsschlüssel von passwd hat nicht gepasst und ich bin in Vi gelandet wusste aber nicht was ich in der Config ändern muß und habe abgebrochen.
Später versuchte ich einfach ein pkg upgrade und danach startete Xorg nicht mehr. Keine Ahnung ich hätte mir mir die Ausgabe auf der Textkonsole aufschreiben müssen weil so hab ich mir das im Detail nicht gemerkt.

Ich hab weder einen Kernel Treiber noch sonst was aus Ports. Das einzige was ich aus Ports hate war Steam, bei der alten Installation. Bei der Neuen hab ich noch nichts aus Ports installiert.

 

[andy_m4]

Der Sicherheitsschlüssel von passwd hat nicht gepasst

Das sagt mir jetzt nix.

Ich hab weder einen Kernel Treiber noch sonst was aus Ports.

Das bezweifle ich.
Theoretisch geht es zwar auf dem Desktop auch ohne. Nur macht das nicht wirklich Spaß, weil man dann nur irgendwelche "VESA"-Modes hat.

bzw. ich spreche nicht explizit von Ports, sondern von Packages und Ports. Je nachdem, was man benutzt.

 

[Linuxfreakgraz]

Das bezweifle ich.

 

[andy_m4]

Okokok. Ich sag ja schon gar nichts mehr. :-)
Wobei sich dann natürlich für mich die Frage stellt, ob das ein speziellen Grund hat.
Ich meine, wenn Dir das so reicht und Du auch via VESA alles so hinkriegst, wie Du es haben willst, ist es ja im Prinzip auch in Ordnung.

Mir ist übrigens noch ne was zur passwd-Sache eingefallen. Wenn man seine Standard-Shell auf eine Nicht-Base-System-Shell ändert (z.B. bash), kann es einem nach einem Upgrade auch auf die Füße Fallen weil die dann nicht mehr funktionieren kann, bevor nicht das gesamte System upgraded ist. Ich würde zumindest den Root-Account immer auf der Standardshell lassen. Oder man macht es direkt so, das man die Shell erst automatisiert beim Start des Desktop-Systems wechselt.

Aber das nur so am Rande.

Hat sich in der Audacious-Geschichte noch irgendwie was ergeben?

@Abrexxes : Das die /usr/local/lib/audacious/Input/sid.so fehlen könnte, diese Frage hat sich nie ernsthaft gestellt. Der hat ja nicht darüber gemeckert das die fehlt, sondern das die nicht geladen werden kann wegen Fehler.

__kmpc_fork_call gehört mit zu LLVM. Man kann nämlich in Quelltext Annotations machen, bestimmte Dinge parallelisiert ausführen zu lassen. Und genau diese Funktion wird intern dafür verwendet.

Ohne "in deep" zu gehen, ist es schwer zu sagen, warum es zu dem Fehler kommt.
Ein paar Vorschläge, was man probieren könnte, kamen ja schon. Theoretisch kann man auch die Parallelisierung abschalten.

 

[Linuxfreakgraz]

Das ist ein Laptop mit Intel Grafik.

Zu der Änderung der Shell, ja mir ist aufgefallen das in den Terminal Emulator en Xfce4-Terminal und Alacrity die Bash läuft, das hab ich aber nicht extra so eingestellt. Ist das jetzt der neue Standard?

 

[andy_m4]

Das ist ein Laptop mit Intel Grafik.

Für Intel gibts den i915kms-Treiber (der im Wesentlichen auf dem entspricht, was im Linux-Kernel enthalten ist). Den kriegt man, wenn man das Package drm-kmod installiert.
Wie gesagt. Geht auch ohne, nur nutzt man dann ganz viel von der Grafikkarte nicht (inkl. der Stromsparmodi, was ja für ein Laptop nicht uninteressant ist).

Ist das jetzt der neue Standard?

Ich hol mal etwas aus. :-)
FreeBSD liefert ja 3 Shells mit.
Die sh (die im Wesentlichen dem entspricht, was POSIX vorgibt), die C-Shell und die TC-Shell. Die letzten beiden sind eigentlich mehr oder weniger noch aus historischen Gründen drin (werden auf absehbare Zeit aber nicht entfernt werden). Die sh ist sozusagen der default, den man jetzt auch im Zuge von FreeBSD 14 für den root-User so einträgt (der hatte vorher als default die C-Shell).

Das die bash irgendwann ins System einzieht, ist eher unwahrscheinlich. Die steht schließlich unter GPL und das GPL-Code möchte man so gut wie möglich vermeiden.
Ist aber i.d.R. kein Problem, da die ja auch über die Packages/Ports erhältlich ist. Man sollte - wie gesagt - nur nicht solche externen Shells als Standard-Shell setzen, damit man sich nicht ausversehen aus dem System aussperrt, wenn man damit was nicht in Ordnung ist.

das in den Terminal Emulator en Xfce4-Terminal und Alacrity die Bash läuft,

Es gibt ja zwei Stellen, wo man die Shell konfigurieren kann. Einmal halt die Systemshell (also das, was man mit dem Programm chsh konfigurieren kann und dann auch in der /etc/master.passwd bzw. /etc/passwd hinterlegt ist) oder halt im Xfce-Terminal selbst über Preferences.

 

[Linuxfreakgraz]

Gut dann probiere ich den Intel Treiber mal aus.

Ergänzung (28. Juli 2024)

Einmal halt die Systemshell (also das, was man mit dem Programm chsh konfigurieren kann und dann auch in der /etc/master.passwd bzw. /etc/passwd hinterlegt ist) oder halt im Xfce-Terminal selbst über Preferences.

Genau diese Config Dateien hätte ich beim freebsd-update upgrade Befehl mit vi editieren sollen, wusste aber nicht was ich da editieren soll.

 

[andy_m4]

Gut dann probiere ich den Intel Treiber mal aus.

Das ist ja auch im Handbuch beschrieben:
https://docs.freebsd.org/en/books/handbook/x11/#x-configuration-intel

Bevor Du das in den /etc/rc.conf einträgst, würde ich aber nach der Installation (und ohne laufendes Xorg) erst mal einen Test machen mit
kldload i915kms

Xorg musst Du dann ggf. noch gesondert konfigurieren.

Genau diese Config Dateien hätte ich beim freebsd-update upgrade Befehl mit vi editieren sollen, wusste aber nicht was ich da editieren soll.

Das kann gut sein, wenn er die neue Datei nicht mit der vorhandenen automatisch "mergen" kann, das er einen an in den Editor verweist, um das ggf. von Hand zu fixen (wobei es Hinweise gibt, was er hinzufügt bzw. rausnehmen würde durch die <<<<<, ===== und >>>>> Tags, die man dann auch vollständig rauslöschen muss).

Wenn man übrigens mit dem vi nicht glücklich ist:
freebsd-update richtet sich nach der Umgebungsvariable EDITOR. Man kann dann auch einen anderen Editor nehmen wie z.B. EasyEditor:
env EDITOR=ee freebsd-update ...