Paketaktualisierung nach abgeschlossenem Leap 15.1 online upgrade liefert viele Abhängigkeiten, die nicht gefunden werden (z.B. libtevent.so.0(TEVENT_0.9.37)(64bit) )

Hinweis: In dem Thema Paketaktualisierung nach abgeschlossenem Leap 15.1 online upgrade liefert viele Abhängigkeiten, die nicht gefunden werden (z.B. libtevent.so.0(TEVENT_0.9.37)(64bit) ) gibt es 19 Antworten auf 2 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • Hallo OpenSuse Gemeinde,


    ich bekomme seit einigen Wochen von der Paketaktualisierung in Leap 15.1 folgende Fehlerliste, wenn ich die angebotenen Pakete aktualisieren lasse:


    libtevent.so.0(TEVENT_0.9.37)(64bit) benötigt von samba-winbind-4.9.5+git.176.375e1f05788-lp151.2.3.1.x86_64 wird nirgends zur Verfügung gestellt
    libx86emu.so.2()(64bit) benötigt von hwinfo-21.66-lp151.2.3.1.x86_64 wird nirgends zur Verfügung gestellt
    libtevent.so.0(TEVENT_0.9.37)(64bit) benötigt von samba-libs-4.9.5+git.176.375e1f05788-lp151.2.3.1.x86_64 wird nirgends zur Verfügung gestellt
    python3-linux-procfs benötigt von tuned-2.10.0-lp151.5.3.1.noarch wird nirgends zur Verfügung gestellt
    libtevent.so.0(TEVENT_0.9.37)(64bit) benötigt von samba-libs-4.9.5+git.176.375e1f05788-lp151.2.3.1.x86_64 wird nirgends zur Verfügung gestellt
    libldb1 >= 1.4.3 benötigt von samba-dsdb-modules-4.9.5+git.176.375e1f05788-lp151.2.3.1.x86_64 wird nirgends zur Verfügung gestellt
    libtevent.so.0(TEVENT_0.9.37)(64bit) benötigt von samba-libs-4.9.5+git.176.375e1f05788-lp151.2.3.1.x86_64 wird nirgends zur Verfügung gestellt
    libtevent.so.0(TEVENT_0.9.37)(64bit) benötigt von samba-libs-4.9.5+git.176.375e1f05788-lp151.2.3.1.x86_64 wird nirgends zur Verfügung gestellt
    libtevent.so.0(TEVENT_0.9.37)(64bit) benötigt von samba-libs-4.9.5+git.176.375e1f05788-lp151.2.3.1.x86_64 wird nirgends zur Verfügung gestellt
    remmina-1.3.4-lp150.2.3.1.x86_64 benötigt libssh_threads.so.4()(64bit), kann jedoch nicht zur Verfügung gestellt werden
    ibus-branding-openSUSE-KDE-1.5.17-lp150.4.3.1.noarch benötigt ibus = 1.5.17, kann jedoch nicht zur Verfügung gestellt werden
    libQtQuick5-5.9.4-lp150.2.3.1.x86_64 benötigt libQt5Widgets.so.5(Qt_5.9.4_PRIVATE_API)(64bit), kann jedoch nicht zur Verfügung gestellt werden
    remmina-1.3.4-lp150.2.3.1.x86_64 benötigt libssh_threads.so.4()(64bit), kann jedoch nicht zur Verfügung gestellt werden
    remmina-1.3.4-lp150.2.3.1.x86_64 benötigt libssh_threads.so.4()(64bit), kann jedoch nicht zur Verfügung gestellt werden
    libtevent.so.0(TEVENT_0.9.37)(64bit) benötigt von samba-libs-4.9.5+git.176.375e1f05788-lp151.2.3.1.x86_64 wird nirgends zur Verfügung gestellt
    libqt5-qtwebengine-5.10.1-lp150.3.4.2.x86_64 benötigt libQt5Core.so.5(Qt_5.9.4_PRIVATE_API)(64bit), kann jedoch nicht zur Verfügung gestellt werden
    remmina-1.3.4-lp150.2.3.1.x86_64 benötigt libssh_threads.so.4()(64bit), kann jedoch nicht zur Verfügung gestellt werden


    Ich hatte davor Leap 15.0 installiert und habe die online Update Möglichkeit gewählt, um auf das nun aktuelle Leap 15.1 zu wechseln.
    Der Vorgang hat auch ohne ersichtliche Fehler funktioniert.
    Danach konnte ich einfach nahtlos weiterarbeiten. Super!
    Als dann nach einigen Tagen die ersten Paketaktualisierungen angeboten wurden, trat das beschriebene Problem auf und hält nun seit einigen Wochen an.
    Ich habe versucht, nicht alle Pakete auf einmal, sondern nur ein einzelnes aktualisieren zu lassen. Aber auch das hat keinen Erfolg gehabt.


    Kann mir bitte jemand weiterhelfen, wie ich dieses Problem lösen kann, um wieder ein gut gewartetes System zu bekommen?
    Vielen Dank
    Christian Wrobel

  • Und benutze bitte für Konsolenausgaben Code-Tags.

  • Danke Dir Forentroll!
    Ergebnis:


    Ich sehe Deine Vermutung bestätigt, daß einige Leap 15.0 Repos aktiv sind.
    Ich habe die offensichtlichen Leap 15.0 Repos mit "zypper rr ..." entfernt (Danke @Sauerland für die Links!). Jetzt sieht es so aus:

    Wenn ich über Yast interaktiv nochmal nach Updates suche, dann kommen wieder ähnliche Fehler wie oben beschrieben.
    In den hinteren Spalten der zypper lr Ausgabe sehe ich immer noch einige URLs mit Leap 15.0 im Namen. Da bin ich mir jetzt aber nicht sicher, ob ich die auch entfernen sollte? Klingen recht wichtig, wie z.B. "Haupt-Repository".
    Soll ich trotzdem auch all die Repos mit "Leap 15.0" in der URL entfernen?
    Oder umgekehrt: welche Repos soll ich denn auf jeden Fall drin lassen?


    Vielen Dank!
    Christian

  • Oder umgekehrt: welche Repos soll ich denn auf jeden Fall drin lassen?

    Die letzten beiden. Alle anderen müssen durch zu openSUSE Leap 15.1 passend ersetzt werden.

    Für den Inhalt des Beitrages 141125 haftet ausdrücklich der jeweilige Autor: tomfa-ng

  • Vielen Dank @tomfa-ng


    ich habe die Repos auf Leap 15.1 umgeändert. Sieht nun so aus:


    Nach einem Reboot werden jetzt erheblich mehr Aktualisierungen gefunden, das prinzipielle Problem ist aber immer noch da: es werden jetzt halt andere Abhängigkeiten nicht gefunden (immerhin sind es jetzt nur noch 2 ;) )

    Code
    ibus-branding-openSUSE-KDE-1.5.17-lp150.4.3.1.noarch benötigt ibus = 1.5.17, kann jedoch nicht zur Verfügung gestellt werden
    libqt5-qtwebengine-5.10.1-lp150.3.4.2.x86_64 benötigt libQt5Gui.so.5(Qt_5.9.4_PRIVATE_API)(64bit), kann jedoch nicht zur Verfügung gestellt werden

    Was sollte ich denn als nächstes probieren?


    Vielen Dank schon mal im Voraus
    Christian

  • Wie man unschwer am Namen der Pakete erkennen kann, gehören die zu einer Installation von openSUSE 15.0. Das erkennt man am Zusatz hinter lp im Dateinamen. Der gibt die openSUSE Version an.
    Was sagt denn


    Code
    zypper se -s ibus-branding-openSUSE-KDE libqt5-qtwebengine

    Da müssten diese beiden Pakete eigentlich als Systempakete auftauchen, da sie keinem Repository mehr zugewiesen werden können.
    Hast du schon versucht die Pakete einfach zu löschen?

  • Ein normales Update funktioniert auch nicht, was passiert bei:

    Code
    zypper dup --allow-vendor-change

    Abbrechen und Ausgabe hier posten.

  • Und, was immer und immer wieder vergessen wird.
    Nicht nur das Packman - Repo hinzufügen, sondern es auch entsprechend priorisieren und darauf umstellen!
    Alle Repos inkl. Packman auf 99 zu setzen ist komplett sinnfrei!

  • Danke Euch allen für Eure guten Ratschläge!


    Hier die Ergebnisse:


    Trekkie00: Die beiden erwähnten Pakete tauchen tatsächlich als Systempakete auf:


    einfach auf Verdacht die beiden Pakete löschen könnte doch viele andere Programme beschädigen die sie evtl. benötigen, oder?


    @Sauerland:
    Die Ausgabe von "zypper dup --allow-vendor-change" ist so lang, daß ich danach die Antwort nicht mehr senden darf.
    Daher habe ich den Log Text als Datei "KonsolAusgabe.txt" angehängt.



    Alero: und wie sollten die Prios Deiner Erfahrung nach sinnvollerweise eingestellt sein?