Beiträge von rkbwde

Seltsam. Evtl. gibt es Probleme, weil bis Leap 15.6 Kernel und Bibliotheken mit gcc7 gebaut wurden, während für die neueren Systeme gcc15 verwendet wird.

Du kannst doch das installierte System auch mit der Installations-DVD von 15.6 bzw. einem Ventoy-Stick booten, oder ? Vermutlich läuft es dann mit dem Kernel von 15.6 - wäre einen Versuch wert ...

Ansonsten chroot - Anleitungen gibt es z.B. unter https://support.scc.suse.com/s…cue-System?language=en_US ...

Läuft KillerPDF auch unter Linux, z.B. mit wine ?

Hat jemand einen Vorschlag für einen einfachen POP3-Server, etwa wie früher (q)popper ?

Er müsste nur Thunderbird erlauben, lokale mails über Port 110 abzurufen (Nein, ich will dafür kein IMAP !).

Da ich nach längerer Suche nichts gescheites fand, habe ich es mal mit dovecot probiert.

Dovecot 24 ist leider die reine Katastrophe - da sind noch die config-Files von Version23 beigefügt, obwohl sich die Syntax massiv geändert hat - elende Schlamperei. Nach ca. 20 vergeblichen Anpassungen habe ich das Handtuch geworfen und bin ich notgedrungen auf die Vorversion dovecot23 ausgewichen ...

Das läuft jetzt mal provisorisch ...

Probleme gibt es aber noch mit Wayland: auf seat0 funktioniert die Wayland-Session zwar, hat aber eine bescheidene Bildqualität. Und seat1 friert beim Login ein, wenn Wayland ausgewählt wird.

X11 läuft auf beiden Seats aber prima - hoffentlich gilt auch hier: Totgesagte leben länger

Dieses WE wurde es ernst - ich habe meinen Multiseat-Rechner von Leap 15.6 auf Slowroll hochgezogen.

An den befürchteten Knackpunkten (Logins auf beiden Seats und geteilter Sound via pulseaudio im Systemmodus) gab es erstaunlich wenig Probleme.

Stress gemacht hat dagegen meine Nextcloud, die nach dem Upgrade seltsame Fehler meldete. Zum Glück fand ich dann im Nextcloud-Log eine bessere Erläuterung für den Fehler "500 Internal Error", nämlich "Exception thrown: OCP\\Files\\GenericFileException" - und das brachte mich zu einem Post mit der richtigen Lösung:

 occ files:scan-app-data

Das hat es dann zum Glück gerichtet.

Wenn Du es nächstesmal ganz genau wissen willst, lass ein strace mitlaufen:

strace -o <logfile> -f firefox

Dann kannst Du im (verm. sehr umfangreichen) logfile u.a. schauen, welche libs gezogen werden ...

Meinst Du eigentlich python 3.1.3 oder python 3.13 ?

Wenn Du wissen willst, zu welchem Package eine Datei oder ein Verzeichnis gehört:

rpm -q --whatprovides <file>

Dann kannst Du probieren, es zu löschen:

rpm -e <package>

rpm sagt Dir dann, ob das Package noch gebraucht wird und wenn ja, von welchen anderen Packages.

So kannst Du Dich Package für Package voranarbeiten - das kann aber mühsam werden.

Schneller geht es mit

zypper rm <package>

Aber Vorsicht: zypper kennt dabei keine Gnade und schmeisst ggfs. das halbe System weg - also gut nachdenken, bevor Du die Löschung(en) bestätigst

Zitat von bekr

Es waren so viele, dass ich sie mit Wildcards nicht mehr löschen konnte und alphabetisch vorgehen musste: rm -f aa*; rm -f ab*.

xargs ist Dein Freund, z.B.

cat fileliste | xargs rm