Konflikte beim Update von ffmpeg-7 via Myrlyn

luigi · 14. Juli 2026

Dann sage doch bitte was du genau gemacht hast und wie die Fehlermeldung lautet, wenn du ^{zypper up} ausführst.

Hidalgo · 14. Juli 2026

Betrifft #21 und #22:

Wenn du nicht abwarten willst bis der Bug behoben ist und du auch kein flatpak nutzen willst, dann würde ich aus den angebotenen Problemlösungen

Lösung 3

auswählen. Die betroffene Multimedia-Bibliothek wird dann vorerst auf dem alten Stand belassen. Das System bleibt stabil, und das restliche Update sollte durchlaufen.

Mit Lösung 3 umgehst du das fehlerhafte Update elegant und dein restliches System wird aktualisiert - digiKam kannst du wie gewohnt weiterbenützen.

Nach ein paar Tagen, wenn der Bug in den openSUSE-Repositories behoben wurde, läuft das nächste zypper dup dann ganz ohne Konflikte durch.

Warum das bei Sauerland läuft? (bp160.1.4)
Schaue dir die Versionsnummern ganz genau an:

Bei dir (Fehlermeldung): libdigikamcore8_7_0-8.7.0-bp160.1.3.x86_64
Bei Sauerland: libdigikamcore8_7_0-8.7.0-bp160.1.4.x86_64

Der feine Unterschied liegt am Ende: .1.4 statt .1.3.

Das bedeutet, dass in dem Repository von sauerland (OSS-DO-org) der Bug bereits behoben wurde. Die Maintainer haben digiKam dort neu gegen das neue FFmpeg-7 gebaut, wodurch die Abhängigkeiten bei ihm fehlerfrei auflösen.

Er nutzt ein anderes Repository (OSS-DO-org). Dieses Repository war beim Synchronisieren der neuen Pakete einfach schneller als das Repository, das dein System aktuell abfragt.

Das bringt mich auf eine Idee:

Zwingen zypper dazu, die Repository-Indizes komplett frisch vom Hauptserver zu laden, anstatt lokale Caches zu nutzen:

Code

sudo zypper ref -f
sudo zypper dup --allow-vendor-change

Falls die Version .1.4 nun auch bei dir auftaucht, verschwindet die Fehlermeldung sofort und das Update läuft ohne Konflikt durch wie bei sauerland.

Ansonsten: Lösung 3.

Sauerland · 14. Juli 2026

Zitat von Hidalgo

Er nutzt ein anderes Repository (OSS-DO-org).

No, das ist nur ein Name und der ist Schall und Rauch.

Hab ich wegen Problemen bei mirrorcache wieder auf downlaod.opensuse.org umgestellt, deswegen das do im Namen:

Code

                      | 
 7 | OSS                              | OSS                              | Nein    | ----      | ----    | -    |   99     | rpm-md   | https://mirrorcache-eu.opensuse.org/distribution/leap/16.0/repo/oss                          | 
25 | oss-do-org                       | OSS-DO-org                       | Ja      | (rp) Ja   | Ja      | -    |   99     | rpm-md   | https://download.opensuse.org/distribution/leap/16.0/repo/oss

Also noch einmal:

wichtig bei der Anzeige von Repos ist nur!!!! die URL, den Rest kann man als User (root) selber vergeben.

Hidalgo

Einen allgemeinen:

Code

sudo zypper dup --allow-vendor-change

würde ich ohne Kenntnisse der eingebundenen Repos nie empfehlen.

Ich tendiere immer zu:

Code

sudo zypper dup --allow-vendor-change --from XXXXX

wenn ich die eingebundenen Repos kenne.

Hidalgo · 14. Juli 2026

Zitat von Sauerland
No, das ist nur ein Name und der ist Schall und Rauch.
Hab ich wegen Problemen bei mirrorcache wieder auf downlaod.opensuse.org umgestellt, deswegen das do im Namen:
Code
                      | 
 7 | OSS                              | OSS                              | Nein    | ----      | ----    | -    |   99     | rpm-md   | https://mirrorcache-eu.opensuse.org/distribution/leap/16.0/repo/oss                          | 
25 | oss-do-org                       | OSS-DO-org                       | Ja      | (rp) Ja   | Ja      | -    |   99     | rpm-md   | https://download.opensuse.org/distribution/leap/16.0/repo/oss   
Also noch einmal:
wichtig bei der Anzeige von Repos ist nur!!!! die URL, den Rest kann man als User (root) selber vergeben.

Hidalgo

Einen allgemeinen:
Code
sudo zypper dup --allow-vendor-change
würde ich ohne Kenntnisse der eingebundenen Repos nie empfehlen.

Ich tendiere immer zu:
Code
sudo zypper dup --allow-vendor-change --from XXXXX
wenn ich die eingebundenen Repos kenne.
Alles anzeigen

Ja - die URL ist entscheidend - das wusste ich auch, nur beim suchen nach den Unterschieden berücksichtigte ich das nicht.

Mein Packman Repo hat die höchste eingestellte Prio, bisher lief der Befehl des möglichen Anbieterwechsels problemlos. Ist halt Gewohnheit - und natürlich kenne ich die Prioritäten des Users nicht und wenn es nicht so läuft, fragt der eben nochmal nach. Es geht wenigstens nichts kaputt - das wäre mir wirklich oberpeinlich!

Omegator · 15. Juli 2026

Aktuell ergibt der Befehl die folgende Ausgabe:

Code

zypper dup --allow-vendor-change
Dienst 'openSUSE' wird aktualisiert.
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...
Warnung: Sie sind im Begriff, eine Distributionsaktualisierung mit allen aktivierten Repositorys durchzuführen. Vergewissern Sie sich, dass diese Repositorys kompatibel sind, bevor Sie fortfahren. Weitere Informationen zu diesem Kommando finden Sie unter 'man zypper'.
Distributions-Aktualisierungen werden verarbeitet...

Die folgenden 4 Objekte sind gesperrt und werden durch keine Aktivität geändert:
 Verfügbar:
  r8168-blacklist-r8169 r8168-debugsource r8168-kmp-default r8168-kmp-default-debuginfo

Die folgenden 18 Pakete werden aktualisiert:
  ffmpeg-7 ffmpegthumbs ffmpegthumbs-kf5 kpipewire6-imports libavcodec61 libavdevice61 libavfilter10
  libavformat61 libavutil59 libdigikamcore8_7_0 libdigikamcore9_1_0 libKPipeWire6 libKPipeWire6-lang
  libKPipeWireDmaBuf6 libKPipeWireRecord6 libpostproc58 libswresample5 libswscale8

Die folgenden 2 Pakete werden GELÖSCHT:
  glibc-gconv-modules-extra-32bit libdigikamcore9_0_0

18 Pakete werden aktualisiert, 2 zu entfernen.

Paketgröße zum Herunterladen:
            |      29,5 MiB  Gesamtpaketgröße
       0 B  |  -   29,5 MiB  bereits im Cache

Änderung der Installationsgröße des Pakets:
              |      88,2 MiB  erforderlich für Pakete, die installiert werden sollen
   -39,6 MiB  |  -  127,7 MiB  freigegeben von Paketen, die entfernt werden sollen

Backend:  classic_rpmtrans
Fortfahren? [j/n/v/...? zeigt alle Optionen] (j): 

Im Cache libavutil59-7.1.4-160000.4.2.x86_64.rpm                                         (1/18), 351,0 KiB    
Im Cache libswscale8-7.1.4-160000.4.2.x86_64.rpm                                         (2/18), 197,2 KiB    
Im Cache libpostproc58-7.1.4-160000.4.2.x86_64.rpm                                       (3/18),  54,7 KiB    
Im Cache libswresample5-7.1.4-160000.4.2.x86_64.rpm                                      (4/18),  71,6 KiB    
Im Cache libavcodec61-7.1.4-160000.4.2.x86_64.rpm                                        (5/18),   5,2 MiB    
Im Cache libavformat61-7.1.4-160000.4.2.x86_64.rpm                                       (6/18),   1,1 MiB    
Im Cache libavfilter10-7.1.4-160000.4.2.x86_64.rpm                                       (7/18),   1,5 MiB    
Im Cache libavdevice61-7.1.4-160000.4.2.x86_64.rpm                                       (8/18),  82,4 KiB    
Im Cache ffmpeg-7-7.1.4-160000.4.2.x86_64.rpm                                            (9/18),   2,0 MiB    
Im Cache libKPipeWire6-6.4.2-bp160.1.3.x86_64.rpm                                       (10/18), 103,3 KiB    
Im Cache libdigikamcore8_7_0-8.7.0-bp160.1.4.x86_64.rpm                                 (11/18),   9,2 MiB    
Im Cache ffmpegthumbs-25.04.3-bp160.1.3.x86_64.rpm                                      (12/18),  78,2 KiB    
Im Cache libKPipeWireDmaBuf6-6.4.2-bp160.1.3.x86_64.rpm                                 (13/18),  27,8 KiB    
Im Cache libKPipeWire6-lang-6.4.2-bp160.1.3.noarch.rpm                                  (14/18),  36,5 KiB    
Im Cache ffmpegthumbs-kf5-25.04.3-bp160.1.3.x86_64.rpm                                  (15/18),  71,0 KiB    
Im Cache libKPipeWireRecord6-6.4.2-bp160.1.3.x86_64.rpm                                 (16/18),  67,1 KiB    
Im Cache kpipewire6-imports-6.4.2-bp160.1.3.x86_64.rpm                                  (17/18),  47,4 KiB    
Im Cache libdigikamcore9_1_0-9.1.0-lp160.274.3.x86_64.rpm                               (18/18),   9,5 MiB    

Überprüfung auf Dateikonflikte läuft: ................................................................[fertig]
/var/tmp/rpm-tmp.dLPbnt: line 1: /usr/sbin/iconvconfig-32: cannot execute binary file: Exec format error
error: %preun(glibc-gconv-modules-extra-32bit-2.40-160000.5.1.x86_64) scriptlet failed, exit status 126
error: glibc-gconv-modules-extra-32bit-2.40-160000.5.1.x86_64: erase failed
( 1/20) glibc-gconv-modules-extra-32bit-2.40-160000.5.1.x86_64 wird entfernt .........................[Fehler]
Entfernen von (52242)glibc-gconv-modules-extra-32bit-2.40-160000.5.1.x86_64(@System) fehlgeschlagen:
Fehler: Subprocess failed. Error: RPM fehlgeschlagen: Kommando mit Status 1 beendet.
Abbrechen, wiederholen, ignorieren? [a/w/i] (a):

Alles anzeigen

Wenn ich dem Befehl noch ein " --from XXXXX", z.B. von Packman anhängen, kommt die Meldung "zu viel Argumente"

Alero · 15. Juli 2026

Zitat von Omegator

Wenn ich dem Befehl noch ein " --from XXXXX", z.B. von Packman anhängen, kommt die Meldung "zu viel Argumente"

Das wird ja auch nicht hinten angehangen sondern kommt nach dup

Sauerland · 15. Juli 2026

Zitat von Omegator

Entfernen von (52242)glibc-gconv-modules-extra-32bit-2.40-160000.5.1.x86_64( System) fehlgeschlagen: Fehler: Subprocess failed. Error: RPM fehlgeschlagen: Kommando mit Status 1 beendet.

Der Fehler ist schon lange behoben:

Als root:

Code

rpm -e --allmatches --nodeps --noscripts --notriggers glibc-gconv-modules-extra-32bit

1246497 – error: glibc-gconv-modules-extra-32bit-2.40-160000.2.7.x86_64: erase failed

Sauerland · 15. Juli 2026

Zitat von Alero

Das wird ja auch nicht hinten angehangen sondern kommt nach dup

Code

linux64:/home/stephan # zypper dup --allow-vendor-change --from publishing 
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...
Distributions-Aktualisierungen werden verarbeitet...

Das folgende Objekt ist gesperrt und wird durch keine Aktivität geändert:
 Verfügbar:
  switcheroo-control

Die folgenden 7 Pakete werden durch eine ältere Version ausgetauscht:
  dblatex docbook-xsl-stylesheets libplotter2 sgml-skel texi2html texi2html-lang transfig

Die folgenden 7 Pakete werden den Anbieter ändern:
  dblatex                  SUSE LLC <https://www.suse.com/> -> obs://build.opensuse.org/Publishing
  docbook-xsl-stylesheets  SUSE LLC <https://www.suse.com/> -> obs://build.opensuse.org/Publishing
  libplotter2              SUSE LLC <https://www.suse.com/> -> obs://build.opensuse.org/Publishing
  sgml-skel                SUSE LLC <https://www.suse.com/> -> obs://build.opensuse.org/Publishing
  texi2html                SUSE LLC <https://www.suse.com/> -> obs://build.opensuse.org/Publishing
  texi2html-lang           SUSE LLC <https://www.suse.com/> -> obs://build.opensuse.org/Publishing
  transfig                 SUSE LLC <https://www.suse.com/> -> obs://build.opensuse.org/Publishing

7 Pakete werden zurückgestuft, 7  Anbieterwechsel.

Paketgröße zum Herunterladen:     5,9 MiB

Änderung der Installationsgröße des Pakets:
            |      30,7 MiB  erforderlich für Pakete, die installiert werden sollen
       1 B  |  -   30,7 MiB  freigegeben von Paketen, die entfernt werden sollen

Backend:  classic_rpmtrans
Fortfahren? [j/n/v/...? zeigt alle Optionen] (j):

Alles anzeigen

Fragen?`???

Omegator · 15. Juli 2026

Zitat von Sauerland
Der Fehler ist schon lange behoben:
Als root:
Code
rpm -e --allmatches --nodeps --noscripts --notriggers glibc-gconv-modules-extra-32bit
https://bugzilla.suse.com/show_bug.cgi?id=1246497

So, nach diesem Befehl konnte ich ganz normal aktualisieren, keinerlei Fehler mehr vorhanden.

Ich denke der TS kann jetzt mal den Haken setzen.

negatron

negatron · 15. Juli 2026

Zitat von Omegator

So, nach diesem Befehl konnte ich ganz normal aktualisieren, keinerlei Fehler mehr vorhanden.
Ich denke der TS kann jetzt mal den Haken setzen.
negatron

Auf meiner Seite passt auch alles wieder, danke an alle!

Konflikte beim Update von ffmpeg-7 via Myrlyn

Ubuntu 26.10 „Stonking Stingray“ ist erschienen

Tumbleweed-Update bricht ab

KDE Plasma 6.8 verabschiedet sich von X11

VBox - gemeinsame Zwischenablage

Linux-Kernel: Kennzeichnungspflicht für KI-generierten Code soll entfallen

k.113

BlackPhoenix

aitexturegenerator

Giorgio68

pavelstr

Teilen

Tags