Hallo Liste, mein YaST hat mir den Dienst gekündigt. Praktischerweise auch gleich doppelt, denn sowohl die GUI-Variante, als auch die Konsole wollen nicht mehr. GUI sagt: YaST got signal 11 at YCP file /usr/share/YaST2/clients/sw_single.ycp:187 /sbin/yast2: line 386: 6160 Speicherzugriffsfehler $ybindir/y2base $module "$@" "$SELECTED_GUI" $Y2_GEOMETRY $Y2QT_ARGS Die Konsole gibt gar keine Fehlermeldung von sich. Im y2log steht: [...] (nur die letzten Zeilen) 2009-03-15 13:23:41 <1> Dirac(6859) [zypp] PathInfo.cc(_Log_Result):295 recursive_rmdir /var/cache/zypp/raw/server:eGroupWareSQLplX 2009-03-15 13:23:41 <1> Dirac(6859) [wfm] Source.cc(SourceLoad):425 Rebuilding cache for 'server:eGroupWare'... 2009-03-15 13:23:41 <5> Dirac(6859) [Measure] Measure.cc(Impl):152 START MEASURE(Check tables exist) 2009-03-15 13:23:41 <5> Dirac(6859) [Measure] Measure.cc(elapsed):174 ELAPSED(Check tables exist) 0 (u 0.00 s 0.00 c 0.00) 2009-03-15 13:23:41 <5> Dirac(6859) [Measure] Measure.cc(~Impl):160 MEASURE(Check tables exist) 0 (u 0.00 s 0.00 c 0.00) [0 (u 0.00 s 0.00 c 0.00)] 2009-03-15 13:23:41 <1> Dirac(6859) [zypp] CacheInitializer.cc(CacheInitializer):97 Repository cache already initialized 2009-03-15 13:23:41 <3> Dirac(6859) [liby2] genericfrontend.cc(signal_handler):59 got signal 11 at YCP file /usr/share/YaST2/clients/sw_single.ycp:187 Im zypper.log sieht man nichts von diesem Fehler, der tritt wohl früher auf. Den Workaround: - remove /var/cache/zypp/zypp.db and /var/cache/zypp/zypp.db-journal - then run 'zypper refresh' habe ich im Netz gefunden. Ich habe den Verdacht, dass er nicht mehr in der Lage ist, seine Online-Repositories einzulesen. Wenn ich die nämlich ausknipse, liest er das nächste aus und bricht dann mit einem Speicherzugriffsfehler ab. Dirac:/var/cache/zypp # zypper refresh Repository 'server:eGroupWare' ist aktuell. Speicherzugriffsfehler Dirac:/var/cache/zypp # zypper refresh Aktualisiere 'Netbeans und anderer Entwicklerkram' Speicherzugriffsfehler Was kann ich den noch tun, um dem YaST auf die Sprünge zu helfen. System ist SuSE 10.3 mit allen Update bis Freitag, den 13.03.2009. Da habe ich KDE4 und ein paar andere Update über die Updatefunktion eingespielt. bash4, readline ließen sich schon seit ihrem Erscheinen nicht überreden, zu installieren. Die habe ich infolgedessen immer ausgelassen. Weiß jemand Rat? Helga -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, Am Son, 15 Mär 2009, Helga Fischer schrieb:
System ist SuSE 10.3 mit allen Update bis Freitag, den 13.03.2009. Da habe ich KDE4 und ein paar andere Update über die Updatefunktion eingespielt. bash4, readline ließen sich schon seit ihrem Erscheinen nicht überreden, zu installieren. Die habe ich infolgedessen immer ausgelassen.
Das riecht so langsam nach kaputtem Speicher... -dnh --
Why is the speed of light so slow? If the quantum police catch its starship speeding again, it'll be forced to walk the Planck. -- The Usenet Oracle -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Sonntag 15 März 2009 schrieb David Haller:
Hallo,
Am Son, 15 Mär 2009, Helga Fischer schrieb:
System ist SuSE 10.3 mit allen Update bis Freitag, den 13.03.2009. Da habe ich KDE4 und ein paar andere Update über die Updatefunktion eingespielt. bash4, readline ließen sich schon seit ihrem Erscheinen nicht überreden, zu installieren. Die habe ich infolgedessen immer ausgelassen.
Die haben aber an Abhängigkeiten rumgemäkelt. Die anderen konnte ich mit viel Geduld und nacheinander einspielen (mit YaST).
Das riecht so langsam nach kaputtem Speicher...
Hab' nicht den Eindruck, dass es da dran klemmt. Aber kann ja mal einen Memtest laufen lassen. Helga -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, Am Son, 15 Mär 2009, Helga Fischer schrieb:
Am Sonntag 15 März 2009 schrieb David Haller:
Am Son, 15 Mär 2009, Helga Fischer schrieb:
System ist SuSE 10.3 mit allen Update bis Freitag, den 13.03.2009. Da habe ich KDE4 und ein paar andere Update über die Updatefunktion eingespielt. bash4, readline ließen sich schon seit ihrem Erscheinen nicht überreden, zu installieren. Die habe ich infolgedessen immer ausgelassen.
Die haben aber an Abhängigkeiten rumgemäkelt. Die anderen konnte ich mit viel Geduld und nacheinander einspielen (mit YaST).
Achso, die ohne Segfaults? Aber daß bei yast nicht nur die QT-GUI sondern auch die ncurses-TUI und zypper absemmeln bedeutet IMO, daß entweder deine libzypp bzw. deren Caches etc. verkorkst ist (Update / RAM- oder Festplattenproblem wären da Möglichkeiten), zu prüfen u.a. mit 'rpm -Vf /lib/libzypp.so.dingens' und löschen der libzypp Caches, Ansonsten könntest du mal 'ltrace zypper <irgendwas>' oder 'catchsegv zypper ...' laufenlassen um zu gucken, ob der Segfault in der libzypp auftritt. Aber viel mehr als libzypp und libc gibt's da nicht.
Das riecht so langsam nach kaputtem Speicher...
Hab' nicht den Eindruck, dass es da dran klemmt. Aber kann ja mal einen Memtest laufen lassen.
Der findet auch nicht alles (zumindest, wenn man begrenzte Geduld hat). Hab hier eine Runde laufen lassen (4h oder so) -> ohne Befund. Aber das RAM war eindeutig defekt. Ein Stresstest mit mprime und/oder mencoder könnte evtl. helfen das einzugrenzen. Hat auch den Vorteil, daß du nebenher weiterwursteln kannst, mencoder hat hier IIRC nur ein oder zweimal die Kiste aufgehängt, die anderen vielen vielen Male gab's nur den Segfault. Seit dem RAM-Tausch läuft's ohne Probleme. Naja, schaden kann's ja nicht, memtest mal laufen zu lassen, braucht halt viel Zeit, in der du nix anderes an der Kiste machen kannst. Ansonsten könntest du mal (wenn du 2 oder mehr Riegel hast) mit nur einem RAM-Riegel testen. Wenn's damit besser wird (war bei mir so), den nächsten Riegel ... RAM ist (bei Desktops) i.d.R. schnell ein- oder ausgebaut. Aber das alles bzgl. RAM erstmal noch "mit Vorbehalt". -dnh -- Liebe ist die Leidenschaft die Leiden schafft. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo David, Am Montag 16 März 2009 schrieb David Haller:
Am Son, 15 Mär 2009, Helga Fischer schrieb:
Am Sonntag 15 März 2009 schrieb David Haller:
Am Son, 15 Mär 2009, Helga Fischer schrieb:
System ist SuSE 10.3 mit allen Update bis Freitag, den 13.03.2009. Da habe ich KDE4 und ein paar andere Update über die Updatefunktion eingespielt. bash4, readline ließen sich schon seit ihrem Erscheinen nicht überreden, zu installieren. Die habe ich infolgedessen immer ausgelassen.
Die haben aber an Abhängigkeiten rumgemäkelt. Die anderen konnte ich mit viel Geduld und nacheinander einspielen (mit YaST).
Achso, die ohne Segfaults?
Ja. Da wollte eine ganze Reihe von Paketen nicht mehr. Fand ich reichlich seltsam, weil der Update-Mechanismus sonst ja extrem zuverlässig ist. Das ein oder andere Update über alle Pakete war auch dabei - ebenfalls mit ein wenig Handarbeit.
Aber daß bei yast nicht nur die QT-GUI sondern auch die ncurses-TUI und zypper absemmeln bedeutet IMO, daß entweder deine libzypp bzw. deren Caches etc. verkorkst ist (Update / RAM- oder Festplattenproblem wären da Möglichkeiten),
Gefallen tut das mir alles nicht.
zu prüfen u.a. mit 'rpm -Vf /lib/libzypp.so.dingens' und löschen der libzypp Caches,
Danke für Deinen hilfreichen Hint.
Ansonsten könntest du mal 'ltrace zypper <irgendwas>' oder 'catchsegv zypper ...' laufenlassen um zu gucken, ob der Segfault in der libzypp auftritt. Aber viel mehr als libzypp und libc gibt's da nicht.
Prima. Dann habe ich die Kandidaten ja schön eingegrenzt.
Das riecht so langsam nach kaputtem Speicher...
Hab' nicht den Eindruck, dass es da dran klemmt. Aber kann ja mal einen Memtest laufen lassen.
Der findet auch nicht alles (zumindest, wenn man begrenzte Geduld hat). Hab hier eine Runde laufen lassen (4h oder so) -> ohne Befund. Aber das RAM war eindeutig defekt. Ein Stresstest mit mprime und/oder mencoder könnte evtl. helfen das einzugrenzen. Hat auch den Vorteil, daß du nebenher weiterwursteln kannst,
Das ist fein; das kranke System ist nämlich leider auch mein Arbeitsrechner. Da ist so ein Memtest wirklich lästig.
mencoder hat hier IIRC nur ein oder zweimal die Kiste aufgehängt, die anderen vielen vielen Male gab's nur den Segfault. Seit dem RAM-Tausch läuft's ohne Probleme.
Knallt der wirklich immer an der gleichen Stelle?
Naja, schaden kann's ja nicht, memtest mal laufen zu lassen, braucht halt viel Zeit, in der du nix anderes an der Kiste machen kannst.
Stimmt :((
Ansonsten könntest du mal (wenn du 2 oder mehr Riegel hast) mit nur einem RAM-Riegel testen. Wenn's damit besser wird (war bei mir so), den nächsten Riegel ... RAM ist (bei Desktops) i.d.R. schnell ein- oder ausgebaut.
OK. Auch wenn ich da jetzt nicht begeistert bin.
Aber das alles bzgl. RAM erstmal noch "mit Vorbehalt".
Helga -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Liste, hallo David, Am Montag 16 März 2009 schrieb Helga Fischer:
Am Montag 16 März 2009 schrieb David Haller:
Am Son, 15 Mär 2009, Helga Fischer schrieb:
Am Sonntag 15 März 2009 schrieb David Haller:
Am Son, 15 Mär 2009, Helga Fischer schrieb:
System ist SuSE 10.3 mit allen Update bis Freitag, den 13.03.2009. Da habe ich KDE4 und ein paar andere Update über die Updatefunktion eingespielt. bash4, readline ließen sich schon seit ihrem Erscheinen nicht überreden, zu installieren. Die habe ich infolgedessen immer ausgelassen.
Die haben aber an Abhängigkeiten rumgemäkelt. Die anderen konnte ich mit viel Geduld und nacheinander einspielen (mit YaST).
Achso, die ohne Segfaults?
Ja. Da wollte eine ganze Reihe von Paketen nicht mehr. Fand ich reichlich seltsam, weil der Update-Mechanismus sonst ja extrem zuverlässig ist. Das ein oder andere Update über alle Pakete war auch dabei - ebenfalls mit ein wenig Handarbeit.
Dein ltrace mit seinen mit seinen eher kryptischen Ausgaben hat mich an noch etwas erinnert: Einer der Stresskandidaten beim Update war sqlite. Und da fällt mir doch auf, dass sich die die alte /var/cache/zypp/zypp.db bei Ansicht mit dem Konqi als sqlite3-Datenbank meldet; die neue, viel kleinere, von der ich nicht weiß, wo sie herkommt, dagegen als Paradox-Datenbank. Erstere macht knoda anstandslos auf, zweitere wird als kaputt deklariert, Daten gibt es nicht. Das Generieren einer neuen Datenbank funktioniert ja leider nicht. [...]
zu prüfen u.a. mit 'rpm -Vf /lib/libzypp.so.dingens' und löschen
Meinst Du wirklich, den ganzen Verzeichnisbaum unter /var/cache/zypp löschen? Der Verify rpm -Vf /usr/lib/libzypp.so.324.3.3 lief ohne Kommentar durch. Ich vermute mal, dass das ein Fall von: »Keine Nachrichten sind gute Nachrichten« ist. [...]
Ansonsten könntest du mal 'ltrace zypper <irgendwas>'
ltrace zypper lu
[...]
_ZNSsC1ERKSs(0x8140020, 0x81402c0, 9, 0xb78afff4, 1)
= 0x8140020
_ZNSsC1ERKSs(0x8140024, 0x81402c4, 9, 0xb78afff4, 1)
= 0x8140024
_ZNSsC1ERKSs(0x8140028, 0x81402c8, 9, 0xb78afff4, 1)
= 0x8140028
_ZNSsC1ERKSs(0x814002c, 0x81402cc, 9, 0xb78afff4, 1)
= 0x814002c
_ZNSsC1ERKSs(0x8140030, 0x81402d0, 9, 0xb78afff4, 1)
= 0x8140030
_ZNSsC1ERKSs(0x8140034, 0x81402d4, 9, 0xb78afff4, 1)
= 0x8140034
_ZNSsC1ERKSs(0x8140038, 0x81402d8, 9, 0xb78afff4, 1
oder 'catchsegv zypper ...' laufenlassen um zu gucken, ob der Segfault in der libzypp auftritt. Aber viel mehr als libzypp und libc gibt's da nicht.
Den habe ich mal unter http://www.eschkitai.de/tmp/catchsegv-zypper geparkt. Ich kann damit nichts anfangen. Helga -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Montag 16 März 2009 schrieb Helga Fischer:
ltrace zypper lu
Da habe ich noch eine Entdeckung gemacht: zypper lu liefert beim user 'helga' ein Ergebnis: [...] Die Daten für das Repository 'openSUSE BuildService - Mail Server' sind nicht mehr aktuell. Sie können als 'root' das Kommando 'zypper refresh' ausführen um die Daten zu aktualisieren. Die Daten für das Repository 'Haupt-Repository (NON-OSS)' sind nicht mehr aktuell. Sie können als 'root' das Kommando 'zypper refresh' ausführen um die Daten zu aktualisieren. Speicherzugriffsfehler Es werden anstandslos alle meine Repos durchlaufen. Beim root gibt's ohne Kommentar gleich den Speicherzugriffsfehler. Dirac:/var/tmp/kdecache-helga # zypper -vv refresh Ausführlichkeitsgrad: 2 Ziel wird initialisiert Überspringe deaktiviertes Repository 'openSUSE-10.3-DVD 10.3' Überspringe deaktiviertes Repository 'server:eGroupWare' Überprüfe, ob die Meta-Daten für Netbeans und anderer Entwicklerkram erneuert werden müssen. Lade herunter: http://download.opensuse.org/repositories/Education/openSUSE_10.3/repodata/r... * Downloading [100%] Repository 'Netbeans und anderer Entwicklerkram' ist aktuell. Speicherzugriffsfehler Wenn ich das letzte Repo ausknipse, bricht er beim nächsten ab. Löschen mit YaST kann ich es nicht, dann kommt wieder der sattsam bekannte Fehler. Helga -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Helga, Am Montag, 16. März 2009 schrieb Helga Fischer:
Hallo Liste, hallo David, ... an noch etwas erinnert: Einer der Stresskandidaten beim Update war sqlite. Und da fällt mir doch auf, dass sich die die alte /var/cache/zypp/zypp.db bei Ansicht mit dem Konqi als sqlite3-Datenbank meldet; die neue, viel kleinere, von der ich nicht weiß, wo sie herkommt, dagegen als Paradox-Datenbank. Hast Du die "neue" mal umbenannt oder gelöscht? Ich hatte mit dieser Datei auch mal Streß, habe sie dann umbenannt und durch zypper up neu generieren lassen.
Erstere macht knoda anstandslos auf, zweitere wird als kaputt deklariert, Daten gibt es nicht.
Das Generieren einer neuen Datenbank funktioniert ja leider nicht. Sollte aber mit zypper up oder irgendeiner anderen Option schon klappen...
Gruß Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, Am Mon, 16 Mär 2009, Helga Fischer schrieb:
Am Montag 16 März 2009 schrieb Helga Fischer:
Am Montag 16 März 2009 schrieb David Haller: [..]
zu prüfen u.a. mit 'rpm -Vf /lib/libzypp.so.dingens' und löschen
Meinst Du wirklich, den ganzen Verzeichnisbaum unter /var/cache/zypp löschen?
Äh, was genau hab ich nicht geschaut, IIRC aber ja.
Der Verify rpm -Vf /usr/lib/libzypp.so.324.3.3 lief ohne Kommentar durch. Ich vermute mal, dass das ein Fall von: »Keine Nachrichten sind gute Nachrichten« ist.
Korrekt. [ltrace ohne '-f' bring hier nix]
oder 'catchsegv zypper ...' laufenlassen um zu gucken, ob der Segfault in der libzypp auftritt. Aber viel mehr als libzypp und libc gibt's da nicht.
Den habe ich mal unter http://www.eschkitai.de/tmp/catchsegv-zypper geparkt. Ich kann damit nichts anfangen.
Ich schon. Welche SUSE hast du nochmal? Unter der 11.1 hab ich hier die libzypp.so.523.2.3, die tut's. Jedenfalls, wenn ich mich nicht irre wird der Segfault beim Zusammenspiel von libzypp und libsqlite3 verursacht, und zwar wohl beim Zugriff auf den Cache von libzypp(!). Schau dir mal im "Backtrace:" die lesbaren Teile der Funktionen (von unten her beginnend) an... zypp RepoManager buildCache ... zypp cache CacheInitializer ... [was aus der libboost] sqlite3x sqlite3_connection ... sqlite3x sqlite3_connection resetprogresshandlerEv [PENG] D.h. -> Cache von Zypp kapott -> s.o., Cache wird bei 'zypper ref' wiederhergestellt. Evtl. reicht auch statt dem "manuellen" löschen der Caches ein 'zypper clean'. Falls das mit dem Cache nicht hilft wären die Kandidaten für Up-/Downgrades dann: libzypp, libboost*, libsqlite3. Genaue Pakete: rpm -qf /usr/lib/libsqlite3.so.0.8.6 \ /usr/lib/libboost_filesystem.so.1.33.1 \ /usr/lib/libboost_regex.so.1.33.1 \ /usr/lib/libzypp.so.324.3.3 Über Abhängigkeiten dürften noch Pakete dazukommen (sqlite3-devel, sqlite3 etc). HTH, -dnh -- BUGS It is not yet possible to change operating system by writ ing to /proc/sys/kernel/ostype. -- Linux sysctl(2) manpage -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo David, wie gut, dass es Dich gibt. Am Dienstag 17 März 2009 schrieb David Haller:
Am Mon, 16 Mär 2009, Helga Fischer schrieb:
Am Montag 16 März 2009 schrieb Helga Fischer:
Am Montag 16 März 2009 schrieb David Haller:
[..]
zu prüfen u.a. mit 'rpm -Vf /lib/libzypp.so.dingens' und löschen
Meinst Du wirklich, den ganzen Verzeichnisbaum unter /var/cache/zypp löschen?
Äh, was genau hab ich nicht geschaut, IIRC aber ja.
Hab' ihn halt umbenannt. Das Ergebnis nach einem zypper refresh war immer eine leere Datenbank. [...]
oder 'catchsegv zypper ...' laufenlassen um zu gucken, ob der Segfault in der libzypp auftritt. Aber viel mehr als libzypp und libc gibt's da nicht.
Den habe ich mal unter http://www.eschkitai.de/tmp/catchsegv-zypper geparkt. Ich kann damit nichts anfangen.
Ich schon. Welche SUSE hast du nochmal?
10.3 (und die möchte ich auch noch eine ganze Weile benutzen, bis meine HW auch unter 11.1 läuft und meine Lieblingsapplikationen entweder portiert wurden oder ich einen adäquaten Ersatz gefunden habe).
Unter der 11.1 hab ich hier die libzypp.so.523.2.3, die tut's.
Der zypper ist eine ganz andere Versionsnummer.
Jedenfalls, wenn ich mich nicht irre wird der Segfault beim Zusammenspiel von libzypp und libsqlite3 verursacht, und zwar wohl beim Zugriff auf den Cache von libzypp(!).
sqlite3 ging mir auch so als Verdächtiger durch den Kopf. Das war nämlich eines der letzten Pakete, die sich dem Update entzogen. Das löste sich zwar dann ohne Zwang irgendwann mal auf, aber ich meine, danach war das Problem mit dem zypper da.
Schau dir mal im "Backtrace:" die lesbaren Teile der Funktionen (von unten her beginnend) an...
zypp RepoManager buildCache ... zypp cache CacheInitializer ... [was aus der libboost] sqlite3x sqlite3_connection ... sqlite3x sqlite3_connection resetprogresshandlerEv [PENG]
OK, ich guck' noch mal rein.
D.h. -> Cache von Zypp kapott -> s.o., Cache wird bei 'zypper ref' wiederhergestellt. Evtl. reicht auch statt dem "manuellen" löschen der Caches ein 'zypper clean'.
Bei mir wird gar nichts mehr neu aufgebaut. Die zypp.db enthält lediglich die Tabellendefinitionen, die knoda gar nicht auslesen kann. Dazu mußte ich kwrite nehmen. Die alte zypp.db läßt sich mit knoda öffnen und ich kann da auch in den Tabelleninhalten 'spazieren gehen'.
Falls das mit dem Cache nicht hilft wären die Kandidaten für Up-/Downgrades dann: libzypp, libboost*, libsqlite3.
Ja, da werde ich wohl nicht drum rum kommen, nachdem ein Update der libzypp nicht geholfen hat. Und ein Neueinspielen vom zypper auch nicht.
Genaue Pakete:
rpm -qf /usr/lib/libsqlite3.so.0.8.6 \ /usr/lib/libboost_filesystem.so.1.33.1 \ /usr/lib/libboost_regex.so.1.33.1 \ /usr/lib/libzypp.so.324.3.3
Über Abhängigkeiten dürften noch Pakete dazukommen (sqlite3-devel, sqlite3 etc).
Das Geschäft lasse ich mir für heute Abend ;). Helga -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Dienstag 17 März 2009 schrieb David Haller: [...]
Genaue Pakete:
rpm -qf /usr/lib/libsqlite3.so.0.8.6 \ /usr/lib/libboost_filesystem.so.1.33.1 \ /usr/lib/libboost_regex.so.1.33.1 \ /usr/lib/libzypp.so.324.3.3
Über Abhängigkeiten dürften noch Pakete dazukommen (sqlite3-devel, sqlite3 etc).
Ich war mal ganz vorsichtig: Dirac:/home/helga/Desktop # rpm -e --test libsqlite3-0-3.6.2 error: Failed dependencies: libsqlite3.so.0 is needed by (installed) libopensync-0.22-50.i586 libsqlite3.so.0 is needed by (installed) digikam-0.9.3-0.pm.2.i586 libsqlite3.so.0 is needed by (installed) amarok-1.4.10-100.pm.1.i586 libsqlite3.so.0 is needed by (installed) libredland0-1.0.8-3.3.i586 libsqlite3.so.0 is needed by (installed) python-2.5.1-39.8.i586 libsqlite3.so.0 is needed by (installed) mozilla-nss-3.12.2-4.1.i586 libsqlite3.so.0 is needed by (installed) hk_classes-0.8.3-175.1.i586 libsqlite3.so.0 is needed by (installed) rekall-sqlite-2.4.6-107.2.i586 libsqlite3.so.0 is needed by (installed) libqt4-sql-sqlite-4.5.0-43.1.i586 libsqlite3.so.0 is needed by (installed) python-sqlite2-2.4.1-2.4.i586 libsqlite3.so.0 is needed by (installed) perl-DBD-SQLite-1.13-74.i586 libsqlite3.so.0 is needed by (installed) sqlite-3.6.2-14.1.i586 libsqlite3.so.0 is needed by (installed) php5-sqlite-5.2.8-32.9.i586 libsqlite3.so.0 is needed by (installed) libzypp-3.27.3-0.1.i586 libsqlite3-0 = 3.6.2 is needed by (installed) sqlite-3.6.2-14.1.i586 Das ist alles nicht sonderlich lustig. Ein Update von sqlite3 habe ich gefunden. Das will aber ein Update von rpm und das schreit auch gleich wieder nach einem neuen Päckchen. Dieses Puzzle verschiebe ich mir jetzt mal auf's Wochende. (YaST hat's einem schon arg bequem gemacht). Helga -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, Am Die, 17 Mär 2009, Helga Fischer schrieb:
Dirac:/home/helga/Desktop # rpm -e --test libsqlite3-0-3.6.2 error: Failed dependencies: [..]
Die von libsqlite3 abhängigen Pakete wirst du nur auch aktualisieren müssen, wenn die "neue" libsqlite inkompatibel ist ...
Das ist alles nicht sonderlich lustig.
Ein Update von sqlite3 habe ich gefunden. Das will aber ein Update von rpm und das schreit auch gleich wieder nach einem neuen Päckchen.
Hast du einen lustigen Mischmasch an Repos? Woher hast du eigentlich zypper und sqlite? Im Zweifelsfall könntest du vielleicht die libzypp, zypper, sqlite, yast* nochmal von DVD/CD "reinprügeln", zur Not auch mit --nodeps oder so damit hoffentlich wenigestens zypper/yast2 wieder laufen. Anschließend kannst du dann übersichtlicher die Abhängigkeiten wieder zurechtbasteln. -dnh -- Zwar sind, beispielsweise für OS/2, Clients zu bekommen, aber mir fallen im Moment mehr Leute ein, die zum Mond geflogen sind, als Leute, die diesen Client zum Funktionieren gebracht haben. [Bernhard Erren in c't 10/2000 (S.117) zum Thema NDS-Clients auf Nicht-Windows-Plattformen] -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Liste, hallo David, Am Mittwoch, 18. März 2009 schrieb David Haller:
Am Die, 17 Mär 2009, Helga Fischer schrieb:
Dirac:/home/helga/Desktop # rpm -e --test libsqlite3-0-3.6.2 error: Failed dependencies:
Dieses Päckchen war tatsächlich der Störenfried. Das habe ich mit einem rpm -e --nodeps an die Luft gesetzt und das originale wieder eingespielt. Dummerweise enthielt dieses Paket und das originale mit dem Namen sqlite-3.4.1-14.i586.rpm den gleichen Inhalt, nämlich libsqlite3, aber mit bekannter verheerender Wirkung. Der Ersatz ließ sich mit einem rpm -i ganz problemlos einspielen. YaST hatte dann nur etwas Mühe, seinen Cache wieder aufzubauen, aber er funktioniert wieder.
[..]
Hast du einen lustigen Mischmasch an Repos?
Ich vermute mal, dass ich wirklich ein Mischmasch an Repos hatte, obwohl ich den Störenfried libsqlite3-0-3.6.2 meine, nicht bewußt installiert zu haben.
Woher hast du eigentlich zypper und sqlite?
Im Vorfeld der schnellen Aktion hatte ich mir zur Begutachtung noch eine SuSE 10.3 als VM erstellt, diese aktualisiert und da geguckt, was die so zu libzypp und libsql zu bieten hat. Danach habe ich mich dann an die Operation getraut ;). Meine gute 10.3 will ich schließlich noch eine Weile behalten. Danke an meine Helfer. Helga -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, Am Mon, 16 Mär 2009, Helga Fischer schrieb:
Am Montag 16 März 2009 schrieb David Haller: [..]
mencoder hat hier IIRC nur ein oder zweimal die Kiste aufgehängt, die anderen vielen vielen Male gab's nur den Segfault. Seit dem RAM-Tausch läuft's ohne Probleme.
Knallt der wirklich immer an der gleichen Stelle?
Nein, mit beiden alten Riegeln aber bei mir quasi zuverlässig bevor die 60% "done" eines Durchgangs erreicht waren, wenn ich ne Serienfolge von DVD umkodieren wollte. Mit einem Riegel lief mit einem einzelner mencoder ein Durchgang (des Two-Pass Encodings) _manchmal_ durch. So etwa jeder achte oder so. Seit dem RAM-Tausch läuft es zuverlässig (und dabei laß ich auf dem Dualcore hier auch 2 mencoder rennen). Mit 2 mencodern wurde mit den alten Riegeln selten mal die 10% Marke eines Durchgangs geknackt, mit dem neuen RAM rennen 2 mencoder stundenlang ohne Probleme (mehrere Folgen ;) Das praktische an der Methode ist, wenn du Material hast, mit dem mencoder klarkommt (und das ist das meiste), kannst du den oder die mencoder (je nach Core-Anzahl) ruhig per 'nice' nebenher laufen lassen. Nur andere CPU-Last solltest du nicht verursachen, aber E-Mail lesen, schreiben, und das meiste andere verursacht ja auch keine ;) Je nach RAM und diversen anderen Faktoren _könnte_ dir dir Kiste absemmeln, mir ist das IIRC 2 mal passiert (bei bestimmt >100 Versuchen, die anderen Male gab's eben nur nen Segfault). Die mencoder-Version und Kodier-Parameter können wir ggfs. per PM bequatschen. Achso: natürlich ist das ganze kein RAM-Test -- aber (speziell wenn's mit nur einem statt 2 oder mehr Riegeln, evtl. durchgetauscht, deutlich besser läuft) ein Test, den man eben "nebenher" laufen lassen kann. Achso, mprime kannst du auch nebenher laufen lassen und ist eindeutiger (im Testmodus prüft es nur bekannte Ergebnisse).
Ansonsten könntest du mal (wenn du 2 oder mehr Riegel hast) mit nur einem RAM-Riegel testen. Wenn's damit besser wird (war bei mir so), den nächsten Riegel ... RAM ist (bei Desktops) i.d.R. schnell ein- oder ausgebaut.
OK. Auch wenn ich da jetzt nicht begeistert bin.
Och, is doch kaum Aufwand -- und du mußt ja zwischendurch nicht alle Schrauben vom Gehäuse verwenden ;) In der Folgemail verdichten sich aber die Hinweise auf eine andere Ursache. Aber vielleicht wäre es trotzdem mal sinnvoll mprime mal nebenher laufen zu lassen. -dnh -- 148: Flame Flames sind der dumpfe Knall, wenn die Schädeldecke auf die Mauer aufschlägt. (Frank Hufschmied) -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Sonntag, 15. März 2009 schrieb Helga Fischer:
Hallo Liste,
mein YaST hat mir den Dienst gekündigt. Praktischerweise auch gleich doppelt, denn sowohl die GUI-Variante, als auch die Konsole wollen nicht mehr.
GUI sagt:
YaST got signal 11 at YCP file /usr/share/YaST2/clients/sw_single.ycp:187 /sbin/yast2: line 386: 6160 Speicherzugriffsfehler $ybindir/y2base $module "$@" "$SELECTED_GUI" $Y2_GEOMETRY $Y2QT_ARGS
Ich hatte das auch schon und es lag an QT. Hast Du ein Repo eingebunden, welches QT 44 oder 45 enthält? Schalte die aus und spiele wieder die ursprünglichen ein bzw. nur die, die im Update-Repo sind. Dann müsst es wieder klappen. Gruß Brian -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Brian, Am Sonntag 15 März 2009 schrieb Brian:
Am Sonntag, 15. März 2009 schrieb Helga Fischer:
mein YaST hat mir den Dienst gekündigt.
[...]
YaST got signal 11 at YCP file /usr/share/YaST2/clients/sw_single.ycp:187 /sbin/yast2: line 386: 6160 Speicherzugriffsfehler $ybindir/y2base $module "$@" "$SELECTED_GUI" $Y2_GEOMETRY $Y2QT_ARGS
Ich hatte das auch schon und es lag an QT. Hast Du ein Repo eingebunden, welches QT 44 oder 45 enthält?
Nicht bewußt. Ja, doch, KDE4-Factory. Das enthält libqt-4.5. Das habe ich aber schon seit etlichen Tagen drauf - Updates ziehe ich mir fast jeden Tag. Dann wäre der Fehler aber sehr plötzlich aufgetreten.
Schalte die aus und spiele wieder die ursprünglichen ein bzw. nur die, die im Update-Repo sind. Dann müsst es wieder klappen.
Das wird lästig mit rpm auf der Kommandozeile. Helga -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Sonntag, 15. März 2009 22:51:05 schrieb Helga Fischer:
Hallo Brian,
Am Sonntag 15 März 2009 schrieb Brian:
Am Sonntag, 15. März 2009 schrieb Helga Fischer:
mein YaST hat mir den Dienst gekündigt.
[...]
YaST got signal 11 at YCP file /usr/share/YaST2/clients/sw_single.ycp:187 /sbin/yast2: line 386: 6160 Speicherzugriffsfehler $ybindir/y2base $module "$@" "$SELECTED_GUI" $Y2_GEOMETRY $Y2QT_ARGS
Ich hatte das auch schon und es lag an QT. Hast Du ein Repo eingebunden, welches QT 44 oder 45 enthält?
Nicht bewußt. Ja, doch, KDE4-Factory. Das enthält libqt-4.5. Das habe ich aber schon seit etlichen Tagen drauf - Updates ziehe ich mir fast jeden Tag. Dann wäre der Fehler aber sehr plötzlich aufgetreten.
Helga, ich benutze Qt 4.4 aus einem Qt-Repo, bin zu faul, jetzt die URL zu suchen... Bei mir ist Yast auch mal mit exakt derselben Meldung abgeschmiert. Ich habe die Ursache gefunden: ich habe damals meine ISDN-Karte konfiguriert und da gab es Probleme. Danach ist Yast beim Aufrufen jedesmal abgeschmiert. Ich habe dann die ISDN-Konfiguration händisch vorgenommen. Meine Vermutung ist, du hast mit Yast irgendwas neu konfiguriert oder eingerichtet, sei es ISDN, einen Scanner oder whatever und dabei wurde etwas in eine Konfigurationsdatei geschrieben, was Yast nun zum Absturz bringt. Hast du in letzter Zeit irgendwas mit Yast eingerichtet oder eine Konfig neu gestaltet? Gruß Malte -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Malte, Am Montag 16 März 2009 schrieb Malte Gell:
Am Sonntag, 15. März 2009 22:51:05 schrieb Helga Fischer:
Am Sonntag 15 März 2009 schrieb Brian:
Am Sonntag, 15. März 2009 schrieb Helga Fischer:
mein YaST hat mir den Dienst gekündigt.
[...]
YaST got signal 11 at YCP file /usr/share/YaST2/clients/sw_single.ycp:187 /sbin/yast2: line 386: 6160 Speicherzugriffsfehler $ybindir/y2base $module "$@" "$SELECTED_GUI" $Y2_GEOMETRY $Y2QT_ARGS
Ich hatte das auch schon und es lag an QT. Hast Du ein Repo eingebunden, welches QT 44 oder 45 enthält?
Nicht bewußt. Ja, doch, KDE4-Factory.
Helga, ich benutze Qt 4.4 aus einem Qt-Repo, bin zu faul, jetzt die URL zu suchen...
Würde ich sicher finden. Da hängt bloß der komplette Kram mit KDE 4.2 dran.
Bei mir ist Yast auch mal mit exakt derselben Meldung abgeschmiert. Ich habe die Ursache gefunden: ich habe damals meine ISDN-Karte konfiguriert und da gab es Probleme. Danach ist Yast beim Aufrufen jedesmal abgeschmiert. Ich habe dann die ISDN-Konfiguration händisch vorgenommen.
*urghs* Das wäre aber ein heftiger Nebeneffekt.
Meine Vermutung ist, du hast mit Yast irgendwas neu konfiguriert oder eingerichtet, sei es ISDN, einen Scanner oder whatever und dabei wurde etwas in eine Konfigurationsdatei geschrieben, was Yast nun zum Absturz bringt.
Hast du in letzter Zeit irgendwas mit Yast eingerichtet oder eine Konfig neu gestaltet?
Nicht wirklich. Ich habe mysql installiert und als Dienst angeworfen. Das hat mich auf die Idee gebracht, mal ein paar andere Module von YaST anzuwerfen. Der Runlevel-Editor wollte erst nach dem x-ten Versuch starten. Die anderen Modulen ließen sich ohne Murren starten. Helga -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Sonntag, 15. März 2009 schrieb Helga Fischer:
Schalte die aus und spiele wieder die ursprünglichen ein bzw. nur die, die im Update-Repo sind. Dann müsst es wieder klappen.
Das wird lästig mit rpm auf der Kommandozeile.
Du kannst von der DVD booten und eine Aktualisierung auswählen. Wähle als Option aus, dass nur installierte Pakete installiert werden und im Paketmanagement zunächst alle Pakete behalten. Dann gezielt nach qt suchen und nur diese downgraden. Eventuelle Abhängigkeiten sind dann leichter zu lösen. Gruß Brian -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Sonntag, 15. März 2009 22:51:05 schrieb Helga Fischer:
Ich hatte das auch schon und es lag an QT. Hast Du ein Repo eingebunden, welches QT 44 oder 45 enthält?
Nicht bewußt. Ja, doch, KDE4-Factory. Das enthält libqt-4.5. Das habe ich aber schon seit etlichen Tagen drauf - Updates ziehe ich mir fast jeden Tag. Dann wäre der Fehler aber sehr plötzlich aufgetreten.
Soweit ich weiß, ist Qt 4.5 nicht bei KDE4 aus Factory dabei, im Gegenteil, Factory ist für Qt 4.4 gebaut und daher sollte man auch das entsprechende repo nutzen, d.h. KDE:Qt44. Wenn also rpm -qa | grep libqt4 4.5 ergibt, solltest du diese Pakete auf 4.4 ändern. Wenn man nicht weiß, welche repos wofür gebraucht werden, benutzt man am besten die one-click-installs, die tragen automatisch die richtigen ein. Qt 4.5 ist für die UNSTABLE repos. Sven -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Sven, Am Montag 16 März 2009 schrieb Sven Burmeister:
Am Sonntag, 15. März 2009 22:51:05 schrieb Helga Fischer:
Ich hatte das auch schon und es lag an QT. Hast Du ein Repo eingebunden, welches QT 44 oder 45 enthält?
Nicht bewußt. Ja, doch, KDE4-Factory. Das enthält libqt-4.5. Das habe ich aber schon seit etlichen Tagen drauf - Updates ziehe ich mir fast jeden Tag. Dann wäre der Fehler aber sehr plötzlich aufgetreten.
Soweit ich weiß, ist Qt 4.5 nicht bei KDE4 aus Factory dabei, im Gegenteil, Factory ist für Qt 4.4 gebaut und daher sollte man auch das entsprechende repo nutzen, d.h. KDE:Qt44.
http://download.opensuse.org/repositories/KDE:/Qt/openSUSE_10.3/i586/ - Das war eingebunden. Weiß aber nicht mehr, ob ich das extra gemacht habe oder im Zuge einer Ein-Klick-Installation. Ansonsten sind für meine KDE4-Installationen konsequent nur Factory-Zweige ausgewählt. UNSTABLE wollte ich mir nicht antun.
Wenn also rpm -qa | grep libqt4 4.5 ergibt, solltest du diese Pakete auf 4.4 ändern.
libqt4-4.5.0-43.1 Gibt's hier.
Wenn man nicht weiß, welche repos wofür gebraucht werden, benutzt man am besten die one-click-installs, die tragen automatisch die richtigen ein.
Ich bin mir inzwischen gar nicht mehr sicher, ob mein eher freizügiger Gebrauch von One-Klick-Geschichten nicht eine Ursache sein könnte. Da habe ich aber Multimedia-Minikram installiert, den es per Default nicht gab. Böse abgeschossen hatte ich YaST, als download.opensuse.de in der Nacht weg war und YaST sich da in einer Endlosschleife mit seinen Repos aufhing. Der konnte einfach nicht einsehen, dass weg halt weg ist und das irgendwann auch mal Schluß mit der Fragerei sein muss. Zwei Tage später funktionierte aber alles wieder. Ich habe nur das PID-File löschen müssen. Mit einer kaputten GUI könnte ich ja noch leben, aber bei mir ist halt der YaST-Unterbau kaputt. Das ist schon heftig. Helga -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Montag, 16. März 2009 11:06:08 schrieb Helga Fischer:
Hallo Sven,
Am Montag 16 März 2009 schrieb Sven Burmeister:
Am Sonntag, 15. März 2009 22:51:05 schrieb Helga Fischer:
Ich hatte das auch schon und es lag an QT. Hast Du ein Repo eingebunden, welches QT 44 oder 45 enthält?
Nicht bewußt. Ja, doch, KDE4-Factory. Das enthält libqt-4.5. Das habe ich aber schon seit etlichen Tagen drauf - Updates ziehe ich mir fast jeden Tag. Dann wäre der Fehler aber sehr plötzlich aufgetreten.
Soweit ich weiß, ist Qt 4.5 nicht bei KDE4 aus Factory dabei, im Gegenteil, Factory ist für Qt 4.4 gebaut und daher sollte man auch das entsprechende repo nutzen, d.h. KDE:Qt44.
http://download.opensuse.org/repositories/KDE:/Qt/openSUSE_10.3/i586/ - Das war eingebunden. Weiß aber nicht mehr, ob ich das extra gemacht habe oder im Zuge einer Ein-Klick-Installation. Ansonsten sind für meine KDE4-Installationen konsequent nur Factory-Zweige ausgewählt. UNSTABLE wollte ich mir nicht antun.
Das QT repo wurde ganz am Anfang für die 4.1 glaub ich mal automatisch eingebunden. Das wurde dann erst danach in 4.4, 4.5 aufgesplittet.Das könnte dann wirklich die Ursache sein. Und bei 10.3 brauchst du ja halt ein QT Repo ( dann halt die 4.4)
Wenn also rpm -qa | grep libqt4 4.5 ergibt, solltest du diese Pakete auf 4.4 ändern.
libqt4-4.5.0-43.1 Gibt's hier.
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Montag, 16. März 2009 11:06:08 schrieb Helga Fischer:
http://download.opensuse.org/repositories/KDE:/Qt/openSUSE_10.3/i586/ - Das war eingebunden. Weiß aber nicht mehr, ob ich das extra gemacht habe oder im Zuge einer Ein-Klick-Installation. Ansonsten sind für meine KDE4-Installationen konsequent nur Factory-Zweige ausgewählt. UNSTABLE wollte ich mir nicht antun.
Das war bestimmt keine ein-klick installation, da die URL falsch ist, ein repo wird ohne die Architektur (i586, x86_64 etc), d.h. http://download.opensuse.org/repositories/KDE:/Qt/openSUSE_10.3/ eingebunden. Und wie vermutet ist es KDE:Qt, d.h. Qt 4.5 und du solltest die URL des repo austauschen gegen http://download.opensuse.org/repositories/KDE:/Qt44/openSUSE_10.3/
Mit einer kaputten GUI könnte ich ja noch leben, aber bei mir ist halt der YaST-Unterbau kaputt. Das ist schon heftig.
Der erste Schritt zur Besserung bzw. Fehlersuche wäre auf jeden Fall Qt 4.5 durch Qt 4.4 zu ersetzen, damit man Qt 4.5 als Fehlerquelle ausschließen kann. Sven -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Montag 16 März 2009 schrieb Sven Burmeister:
Am Montag, 16. März 2009 11:06:08 schrieb Helga Fischer:
http://download.opensuse.org/repositories/KDE:/Qt/openSUSE_10.3/ i586/ - Das war eingebunden. Weiß aber nicht mehr, ob ich das extra gemacht habe oder im Zuge einer Ein-Klick-Installation. Ansonsten sind für meine KDE4-Installationen konsequent nur Factory-Zweige ausgewählt. UNSTABLE wollte ich mir nicht antun.
Das war bestimmt keine ein-klick installation, da die URL falsch ist, ein repo wird ohne die Architektur (i586, x86_64 etc), d.h. http://download.opensuse.org/repositories/KDE:/Qt/openSUSE_10.3/ eingebunden.
OK. Das habe ich nicht gewußt. Dann habe ich es vielleicht manuell eingebunden.
Und wie vermutet ist es KDE:Qt, d.h. Qt 4.5 und du solltest die URL des repo austauschen gegen http://download.opensuse.org/repositories/KDE:/Qt44/openSUSE_10.3/
Das bekomme ich vermutlich auch ohne YaST hin. Nur wird mir der zypper die neuen Informationen nicht holen.
Mit einer kaputten GUI könnte ich ja noch leben, aber bei mir ist halt der YaST-Unterbau kaputt. Das ist schon heftig.
Der erste Schritt zur Besserung bzw. Fehlersuche wäre auf jeden Fall Qt 4.5 durch Qt 4.4 zu ersetzen, damit man Qt 4.5 als Fehlerquelle ausschließen kann.
Das soll hoffentlich nicht heißen, dass zypper irgendwie von qt abhängt... Ich denke, es ist einfacher, erst mal den Untergrund zu reparieren und sich dann um den GUI-Kram zu kümmern. Helga -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
participants (7)
-
Brian -
Daniel Fuhrmann -
David Haller -
Helga Fischer -
Malte Gell -
Martin Hofius -
Sven Burmeister