Fehler:KDE

aus openSUSE, der freien Wissensdatenbank

KDE-Fehlerberichte

Allgemein

Beim Einreichen von Fehlerberichten auf bugzilla.novell.com ist es sinnvoll zu wissen, welche Pakte installiert sind. Manche Leute haben nur die gewöhnlichen von openSUSE veröffentlichten Pakete installiert (manchmal mit und manchmal ohne Online-Aktualisierungen) und andere haben ihr KDE aus den Build Service-Paketdepots von software.opensuse.org aktualisiert. Einige haben sogar experimentelle Pakete laufen, die eventuell noch weitere Fehler enthalten können.

Weitere Informationen: KDE debuggen

Bevor Sie einen Fehler melden

Nicht alle Fehler die Sie finden gehören in Novells Bugzilla. Bevor Sie also irgendetwas unter bugzilla.novell.com melden, beachten Sie folgendes:

Welche Paketdpots brauchen Tests?

KDE4:STABLE ist wichtig, KDE4:Factory wird umso wichtiger, je näher eine neue openSUSE-Ausgabe heranrückt. UNSTABLE ist für das openSUSE-Team komplett nutzlos, da es weder Teil einer veröffentlichten openSUSE-Version ist, noch darin an einer kommenden Ausgabe gearbeitet wird. Das gleiche gilt für noch nicht veröffentlichte Versionen von Anwendungen. Letztere sind in der Regel durch ein svn12345 als Teil des Paketnamens erkennbar.

Meldungen an bugzilla.novell.com oder bugs.kde.org?

Mit seinen beschränkten Ressourcen muss sich das openSUSE-Team auf STABLE und openSUSE-spezifische Fehler/Funktionen konzentrieren. Des weiteren kann es kein Experte für jede einzelne Anwendung sein, weshalb der Betreuer eine Anwendung auf bugs.kde.org wahrscheinlich mehr Ahnung hat und Probleme schneller beheben kann.

Deshalb sollten alle nicht-openSUSE-spezifischen Fehler, insbesondere solche, die auch auf andere Distributionen zutreffen, an bugs.kde.org gemeldet werden. Im Fall einer wirklich wichtigen Funktion, wie bspw. einer nicht funktionierenden Bluetooth-Unterstützung, oder einem wirklich wichtgen Fehler, der im Ursprungsprojekt schon behoben sein könnte, macht es Sinn, die Meldung auch downstream (unter bugzilla.novell.com ) einzureichen und den upstream-Fehlerbericht in das URL-Feld einzutragen. Auf diesem Weg kann das openSUSE-Team showstopper vor einer Veröffentlichung im Auge behalten und nach einer Veröffentlichung schnell reagieren.

Nützliche Absturzberichte

Ablaufverfolgungen (backtraces) sollten immer nur mit installierten -debuginfo-Paketen gemeldet werden. Falls der Text des Berichts zur Ablaufverfolgung Stellen wie "This backtrace appears to be of no use." enthält, dann fehlen ihnen entweder die debuginfo-Pakete oder die Versionen stimmen nicht überein. Sie können diese Pakete auch noch installieren, wenn Dr. Konqi erscheint - bevor Sie auf den Backtrace-Reiter klicken, allerdings müssen sie aus der gleichen Quelle stammen, aus der auch die Anwendungspakete kommen (beta2-Debuginfo passt nicht zu beta1-Anwendungen). Normalerweise benötigen Sie dazu kdepim3/4-debuginfo, kdelibs3/4-debuginfo, kdebase3/4-debuginfo und qt3-debuginfo bzw. libqt4-debuginfo.

Jedes Quellpaket generiert eine debuginfo, wird aber vielleicht selber in viele binäre RPMs aufgeteilt. Dies erschwert die Suche nach der zu installierenden debuginfo. Wenn Sie nicht sicher sind, welche debuginfo Sie brauchen, dann gehen Sie wie folgt vor:

• Identifizieren Sie den Prozess, der abgestürzt ist, bspw. /usr/bin/kwin
• Finden Sie heraus, in welchem RPM die Datei gepackt ist: "rpm -qf /usr/bin/kwin" zeigt, dass kwin Teil von kde4-kwin ist.
• Finden Sie heraus, aus welchem Quellpaket das binäre RPM erstellt wurde: "rpm -qi kde4-kwin | grep Source\ RPM" zeigt, dass sich die Quellen von kwin in kdebase4-workspace befinden.
• Installieren Sie das zugehörige debuginfo-Paket, in diesem Fall kdebase4-workspace-debuginfo.

Wenn Sie viele Tests durchführen oder oft Fehler suchen, dann hilft es, bereits debuginfos der Basis-KDE-Plattform installiert zu haben. Sie befinden sich im gleichen Paketdepot wie die von ihnen installierten nicht-debuginfo-KDE4-Pakete. Das sind

• libqt4-debuginfo
• kdelibs4-debuginfo
• kdepimlibs4-debuginfo
• kdebase4-runtime-debuginfo
• kdebase4-workspace-debuginfo

Um Fehler gegen openSUSE Factory (nicht, wenn Sie eine veröffentlichte Ausgabe plus KDE4:/Factory:/ verwenden) oder openSUSE Beta-Versionen zu melden, müssen sowohl das Factory-Depot als auch das zugehörige Debuginfo-Depot eingebunden sein - Betas haben keine debuginfo-Pakete. Installieren Sie das zugehörige Paket von Factory und seine debuginfo- und debugsource-Unterpakete um gute Rückverfolgungen mit Zeilennummern zu erhalten.

Weitere Informationen: Leitfaden für KDE-Fehlerberichte

Spezifische Hinweise und Tricks

Normalerweise ist $HOME/.xsession-errors die einzig sinnvolle Protokolldatei - lediglich für Fehler im KDM und während der Anmeldung werden auch noch weitere gebraucht, namentlich /var/log/messages, /var/log/kdm.log und /var/log/Xorg.0.log.

Das Debuggen von kio_slaves (jedes Problem mit einem Protokoll in Konqueror bspw.) ist ein wenig komplizierter. Eine Beschreibung für diese Fälle finden Sie hier .

Wenn Sie einem Prozess GDB anhängen, dann denken Sie daran, dass wenn der Prozess "[kdeinit]" im Namen trägt, die richtige Startdatei nicht bspw. dcopserver ist, sondern kdeinit.

Die Netzwerkverwaltung debuggen

Lesen Sie unseren Problemlösungsleitfaden zur Netzwerkverwaltung in KDE UserBase , wo Sie Tipps zur Diagnose von Problemen mit unserer Netzwerkverwaltung finden.