From Mageia wiki
Jump to: navigation, search


Drakconf multiflag.png
 Andere Sprachen
Deutsch ; Englisch ; Français
Diese Seite wurde im März 2019 von wiki.mageia.org/de/ übernommen und erweitert. Für die ursprüngliche/n Seite/Autoren siehe hier. Hierbei handelt es sich um eine Übersetzung aus dem englischen.
diese seite ist ein entwurf.
Diese Seite benötigt Verbesserungen. Falls Sie diese Seite verbessern möchten, melden Sie sich einfach an und klicke auf den Tabulator Edit.

Entferne diese {{Draft-de}} Vorlage, wenn Sie sicher sind, dass diese Seite vollständig und korrekt ist.

Siehe weitere Seiten, die als Entwurf markiert sind oder alle anderen Seiten, die verbessert und bearbeitet werden müssen.

Diese Seite ist eine Anleitung um Fehler zu verfolgen die an Mageia gemeldet wurden. Es ist prinzipiell für Mitglieder des Fehlertruppe beabsichtigt und sollte als Anleitung für neue Mitglieder und als hilfreiche Nachschlageseite für erfahrene Mitglieder dienen.

Contents

Was zu geschehen hat

  • füge weitere Informationen über die Installation hinzu (welche Pakete zu wählen sind)
  • füge Informationen über die Infrastruktur und Webseitenfehler ein
  • und über Anfragen um ein Paket aus Cauldron zu entfernen
  • ändere die Sätze eventuell so, dass diese verständlich sind
  • füge Leerzeilen ein, falls dies nötig ist

Zuallererst, ist das ein Duplikat?

Das erste was zu bestimmen ist, ob dieser Fehlerbericht ein Duplikat eines bereits geöffneten Fehlerberichts ist. Du kannst dich vielleicht erinnern einen ähnlichen Bericht schon gesehen zu haben. Ansonsten, wird empfohlen die gesamte Datenbank zu durchsuchen, indem ein Schlüsselwort verwendet wird der sich auf den Fehler bezieht und am ehesten zutrifft um ähnliche Fehlerberichte als Antwort zu liefern.

Wenn Bugzilla durchsucht wird, so ist es empfehlenswert die Schnittstelle "Advanced Search" zu verwenden; zu Beginn kann es den Eindruck erwecken, dass dies zu komplex ist, wenn du dich aber an den Umgang gewöhnt hast, so ist es ein sehr mächtiges Suchwerkzeug mit dem du nach Teilen von Abstürzen zurückverfolgen kannst, einige eindeutige Worte/Zeichenketten die sich auf einen Fehlerbericht beziehen.

Betrachte auch die Beziehung zwischen den Komponenten wenn du eine Suche startest. Wenn z.B. jemand über den Absturz einer GNOME-Anwendung berichtet, beachte auch, dass das Problem in einer darunterliegenden Ebene liegen kann, so z.B. die Bibliotheken GTK+ oder Pango. Suche auch in diesen Bereichen.

Im Fall, dass der Fehlerbericht ein Duplikat ist, welcher bereits behoben wurde, vergiss nicht, die als RESOLVED markierten Fehlerberichte in die Suche mit einzubeziehen.

Füge "ALL" vor dem Suchwort ein, wenn du sicher bist, dass eine "schnelle Suche" ausreichend ist. Als Beispiel, wenn jemand einen Fehlerbericht bezüglich dansguardian geschrieben hat, wird die Suche nach 

 ALL dansguardian

auch die bereits behobenen Fehlerberichte anzeigen.

Du kannst auch die meisten der gemeldeten Fehler innerhalb der letzten 7 Tage auf der duplikate-Seite in Bugzilla anzeigen lassen (oder seit Anbeginn der Distribution, wenn du ein wenig mit den Einstellungen spielst).

OK, es ist ein Duplikat, was nun?

Ist dieser Fehler ein Duplikat eines vorhergehenden Berichtes, solltest du den Fehler auf den Status RESOLVED DUPLICATE, mit der entsprechenden Fehlernummer setzen. Dies ist normalerweise die einzige Aktion die auszuführen ist. Die Tatsache, dass der Fehler ein Duplikat ist, ist für den Berichtersteller nicht immer offensichtlich - so handelt zum Beispiel ein Bericht über den Absturz einer bestimmten Anwendung, aber das Problem liegt in der zugrundeliegenden Bibliothek und wurde bereits früher berichtet - du kannst dies in einem Kommentar erklären um sicherzustellen, dass der Berichterstatter diese Lösung versteht.

Der Fehler betrifft zwei verschiedene Versionen! Was nun?

Identische Fehler die sich auf verschiedene Versionen beziehen sollten nicht als Duplikate geschlossen werden. Wenn z.B. ein Fehler zu Cauldron berichtet wurde und anschließend auch in einer stabilen Version, so schließe den zweiten Bericht nicht als Duplikat vom ersten. Der Grund dafür liegt darin, dass die Lösung für einen Fehler in einer Distribution nicht unbedingt die Lösung für den Fehler in einer anderen Distribution darstellt, sodass wir im gültigen Bugzilla System, unterschiedliche Berichte für jede Distribution besitzen und dies der beste Weg ist solche Situationen zu behandeln. Du musst auch Blocker und entsprechende Abhängigkeiten setzen: Cauldron Fehler blockieren Fehler in anderen Mageia Versionen.

Bitte beachten!
Anstatt getrennte Fehlerberichte für verschiedene Versionen zu erstellen, haben wir begonnen MGA5TOO auf dem Whiteboard der Cauldron Fehlerberichte zu setzen, so dass diese ebenfalls für Mageia 5 gültig sind. Wurde der Fehler in Cauldron behoben, so kann die Version auf 5 gesetzt werden und MGA5TOO kann vom Whiteboard entfernt werden.

Wird der Bericht vom Mageia Fehlerprozess abgedeckt?

Betrachte zuerst die Definition eines Fehlers

Aus der Fehlerstrategie: "Ein Fehler ist definiert als Fall, in dem eine Komponente der Mageia Linux Distribution (oder anderer Produkte die von Bugzilla abgedeckt werden, wie die Mageia Webseite(n)) die erwartete Funktion nicht erfüllt." Betrachte den Bericht unter diesen Aspekten. Beachte, dass es hier eine Ausnahme für gültige Anfrageerweiterungen gibt - siehe in der Fehlerstrategie für weitere Details.

Ein Beispiel eines Berichtes der diesen Test nicht besteht, ist eine Anforderung für eine zusätzliche Fähigkeit eines Stückes Software, die nicht vom Mageia Entwicklerteam entwickelt wurde, oder ein Bericht der sich eindeutig nicht an eine Mageia Komponente richtet, sondern es sich hierbei um einen Anwenderfehler oder ein Hardwareproblem des vom Berichtersteller betreffenden Computer handelt.

Wenn ein Fehlerbericht den Test nicht besteht, dann sollte ein Kommentar geschrieben werden, der ausführt, weshalb es sich hierbei um keinen Bug handelt, der Magiea betrifft und der Status sollte auf RESOLVED INVALID gesetzt werden.

Das selbe sollte auch getan werden, wenn die Software "kein offizielles Mageia Paket" ist. Dies ist nicht immer offensichtlich, da jeder ein Paket bauen kann, welches aussieht, als wäre es ein von Mageia zur Verfügung gestelltes Paket, obwohl es nicht über unsere Server erstellt wurde und nicht von uns signiert wurde.

Dies kann überprüft werden, indem man ein Leerzeichen und den Paketnamen nach dem folgenden Befehl eingibt: 

rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE} %{SIGPGP:pgpsig}\n'

wie dies im unteren Beispiel für translate-shell folgendermaßen angezeigt wird: 

[m@c ~]$ rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE} %{SIGPGP:pgpsig}\n' translate-shell
translate-shell-0.9.6.11-1.mga8 RSA/SHA256, zo 28 jul 2019 11:53:22 CEST, Key ID b742fa8b80420f66
[m@c ~]$

Falls der Befehl als Ausgabe "Key ID b742fa8b80420f66" anzeigt, wie in dem Beispiel oben, dann ist dies gut: das Paket, auf dem Computer, wurde von Mageia signiert.

Vorallem wenn ein Bug nicht bestätigt werden kann ist es eine gute Idee, den Melder des Fehlerberichts zu fragen, ob er überprüfen kann, ob Pakete von Drittanbieter installiert sind. Um eine Liste von installierten Paketen zu erhalten, welche nicht von Mageia signiert wurden, kann folgender Befehl verwendet werden (der gesamte Befehl in einer Zeile): 

 rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE} %{SIGPGP:pgpsig}\n' | grep -v b742fa8b80420f66

dies wird alle Pakete als Ausgabe zurückgeben, die auf dem System des Anwenders vorhanden sind.

Manchmal ist ein Fehlerbericht ein Support-Problem anstelle eines wirklichen Fehlers oder der Melder des Fehlers ist nicht fähig den Fehler ausführlich mit allen benötigten Informationen zu beschreiben. In diesem Fall ist es ratsam dem Melder vorzuschlagen in unserem deutschsprachigen Forum oder englischsprachigen Forum oder in unserer discuss@ml.mageia.org Mailingliste nach Hilfe zu fragen. Es ist häufig besser, solche Meldungen für eine Zeit lang offen zu lassen und diese ein paar Wochen später (als RESOLVED-OLD) zu schließen, falls keine Informationen hinzugefügt wurden, welche zeigen, dass es den Fehler wirklich gibt, oder wenn der Melder des Fehlers keine weiteren Informationen liefert. Offiziell sollten die Fehlerberichte in den Status RESOLVED-INVALID gewechselt werden, jedoch kann dies für einige unerfahrene Anwender zu einem großen Schamgefühlen führen.

Zweitens, sollte der Fehler irgendwo behandelt werden?

(Normalerweise durch den Entwickler der in Frage kommenden Software). Tritt z.B. ein Fehler durch einen fundamentalen Mangel im Quellcode auf, sollte dies vom Upstream-Entwicklerteam gelöst werden, auch wenn dies theoretisch von einem Mageia-Entwickler durch einen Patch gelöst werden könnte. Das Lösen solcher Ausgaben durch "upstream" reduziert die Belastung der Patch-Verwaltung durch das Mageia Entwicklerteam (und das damit verbundene Risiko von Fehlern und Instabilitäten).

Ist im Fehlerbericht ein "stack trace" vorhanden, berücksichtige das "upstream" Fehlerverwaltungssystem (so z.B. GNOME oder KDE Bugzilla) um zu sehen ob ein Fehler mit einem ähnlichen "stack trace" bereits berichtet wurde.

Wenn das Problem in der Software selbst liegt, setze das Schlüsselwort UPSTREAM.

Wird der Code nur schwach oder gar nicht "upstream" verwaltet, kann es sein, dass du es als für den Mageia-Prozess geeignet betrachtest, so dass es eine höhere Wahrscheinlichkeit gibt, dass das Mageia Entwicklungsteam in der Lage sein wird, es zu lösen, als das vom inaktiven "upstream" Betreuer wahrgenommen wird.

Wenn das "upstream" Entwicklerteam die Software gut betreut, so solltest du einen Kommentar senden indem du deine Argumente erklärst und empfiehlst dass der Berichterstatter des Fehlers einen Bericht an die entsprechende Stelle sendet (abhängig vom Paket, kann dies ein anderes Fehlerverfolgungssystem, ein Forum oder eine Mail-Liste sein). Idealerweise, fügst du einen Link zum entsprechenden Platz in deinen Kommentar ein, als Annehmlichkeit für den Berichterstatter. Frage den Berichterstatter dass dieser einen Kommentar sendet, nachdem er seinen "upstream"-Bericht abgeschickt hat, mit einem Link zum Bericht. Hat der Berichterstatter dies getan, solltest du den Link in den "upstream"-Bericht, im URL aufzunehmen, bevor dieser dem Betreuer zugewiesen wird. Wurde der Fehler vom "upstream"-Entwicklerteam behoben, dann diese Lösung durch eine Aktualisierung in das Mageia Paket eingebaut werden. Es steht natürlich unseren Entwicklern frei, das Paket zu "patchen" bevor der Fehler behoben werden kann.

Drittens, ist der Fehler in einer unterstützten Version enthalten?

Wird die Mageia Version in der dieser Fehler aufgetreten ist, nicht mehr unterstützt, füge das Schlüsselwort NEEDINFO ein und frage den Berichterstatter nach Tests, ob dieser Fehler in der neusten Cauldron-Version, oder einer unterstützten Version, weiterhin auftritt. Pinge ihn nach zwei Wochen an, wenn er nicht antwortet. Wenn er nicht innerhalb zweier weiterer Wochen antwortet, so kannst du den Zustand auf RESOLVED OLD setzen, zusammen mit einem Kommentar der den Grund erklärt. Dies gilt nicht für Erweiterungsanforderungen, da die meisten von ihnen auf die Version Cauldron gesetzt sein sollten (modifiziere das Versionsfeld, wenn erforderlich).

Sind alle nötigen Informationen vorhanden?

Wenn der Fehlerbericht alle Tests überstanden hat, ist eine Aktion vom Betreuer erforderlich, und sollte eventuell dem Betreuer für eine Aktion zugewiesen werden. Du solltest dies natürlich erst dann tun wenn die Information zu diesem Fehler so vollständig wie nur möglich ist.

Die allgemeine Regel ist, dass ein Fehlerbericht letztendlich genügend Informationen enthalten soll, um das Problem für den Betreuer reproduzierbar und verständlich zu machen. Wertvolle Informationen sollten folgendes beinhalten, ist aber nicht darauf beschränkt:

  • Exakte Version des Pakets (der Pakete) das verwendet wird (verwendet werden)
  • Architektur (i586 oder x86-64)
  • Präzise Schritte um das Problem nachvollziehen zu können ("gedit stürzt ab" ist nicht ausreichend; "gedit stürzt ab wenn ich es vom Menü aus aufrufe, 'abracadabra' eingebe und auf Print klicke" ist gut)
  • Fehlermeldungen die von der Anwendung angezeigt werden, oder an der Konsole, wenn die Anwendung an der Konsole gestartet wird
  • Information zur Hardware, wenn dies ein ausschlaggebender Faktor ist - IDE/SCSI/SATA Festplatten, USB-Speichergeräte, lsusb, lspci, 'lspcidrake -v' ...usw. Ausgabe ...
  • Information über die Betriebssystemumgebung: welcher Desktop/welche Shell wird verwendet, wird die Anwendung "remote" ausgeführt, welche anderen Paket könnten sich eventuell auf die verwendete Anwendung auswirken, welche Konfiguration wird verwendet ... usw.

Eine sehr gute Möglichkeit, um zu überprüfen ob alle notwendigen Informationen zur Verfügung gestellt wurden, ist es, zu prüfen, ob du selbst den Fehler nachvollziehen kannst, indem du die Informationen verwendest, die im Fehlerbericht enthalten sind. Mitglieder des Auswahlteams sind gut beraten, Kopien aller zur Zeit unterstützten Versionen von Mageia zu haben, da dies sehr hilfreich ist. Du kannst zu diesem Zweck die VirtualBox, VMware, qemu ... usw. verwenden.

Wurden wichtige Informationen noch nicht zur Verfügung gestellt, so solltest du das Schlüsselwort NEEDINFO in die Fehlerbeschreibung einfügen, und einen Kommentar einfügen der dem Berichterstatter erklärt welche zusätzliche Informationen noch benötigt werden - falls nötig - und wie man zu diesen Informationen gelangt. Pinge ihn an wenn er nicht innerhalb von zwei Wochen antwortet. Gibt es innerhalb von weiteren zwei Wochen noch immer keine Antwort, so kannst du den Zustand auf RESOLVED INVALID setzen mit einem Kommentar der den Grund erklärt und idealerweise mit dem Hinweis, dass der Reporter den Fehlerbericht erneut öffnen kann, wenn er weitere benötigte Informationen mit einbringt.

Spezielle Fälle, die spezielle Informationen benötigen

Nachfolgend einige spezielle Fehlertypen für die spezielle Typen an Informationen benötigt werden:

Installer-bezogene Fehler

Für Fehler die sich auf den traditionellen Installer beziehen, DrakX (d.h. die Free DVD, nicht die Live CD's), sollte der Berichterstatter die Datei /root/drakx/report.bug.gz als Anhang zur Verfügung stellen. Ein einfacher Weg um dies zu erreichen ist, den Berichterstatter zu fragen auf die Konsole 2 zu wechseln (durch Betätigen von Strg-Alt-F2), während die Installation durchgeführt wird, eine Diskette in das Laufwerk einzulegen oder einen USB-Stick anzustecken und 

bug

einzugeben und dann Enter zu betätigen. Dies generiert die Datei report.bug. Falls die Datei zu groß ist um diese dem Fehlerbericht anzuhängen, komprimiere diese mit xz: xz report.bug und füge die Ausgabe report.bug.xz dem Bericht bei.

Bitte beachten!
Falls der bug-Befehl nicht funktioniert, versuche es erneut (wenn dein USB-Stick als /dev/sdsdb eingebunden ist) mit: 
 bug /dev/sdb1

Passe den Befehl falls nötig an. Du kannst durch das Ausführen des Befehls 

 dmesg

herausfinden, ob dein USB-Stick als "/dev/sdb", "/dev/sdc" oder "/dev/sdd", etc. eingebunden ist.

Fehler im traditionellen Installer werden den Mageia Tools Maintainern zugewiesen.

Bitte beachten!
Zum Zeitpunkt, an dem dies geschrieben wurde (im Zeitraum der Mageia 4 Beta 2 Veröffentlichung), stammt bei den traditionellen Installer-Upgrades die Datei /root/drakx/report.bug.xz von der originalen Installation, nicht vom Upgradevorgang. /root/drakx/report.bug ist stammt vom Upgradevorgang. Falls dies weiterhin zutrifft während du dies liest, dann nimm natürlich die zuletzt angesprochene Datei, komprimiere diese und füge sie als Anhang hinzu.

Live Installationen

Für Fehler welche den Installationsvorgang von einer Live-CD/DVD betreffen, nachdem das System im Live-Modus gestartet wurde, führe als root 

 journalctl -a > journalctl-a.txt

aus, bevor, nach der Installation, neu gestartet wird und füge die Datei journalctl-a.txt dem Fehlerreport bei. Wenn die Datei sehr groß ist (was sie möglicherweiße ist), komprimiere diese zu erst.

Fehler beim Erkennen der Hardware, Hardware wird nicht unterstützt

Wird ein Teil der Hardware falsch erkannt oder anscheinend überhaupt nicht unterstützt, so wird die Ausgabe des Kommandos 

lspcidrake -v

benötigt. Für USB-Geräte, frage den Berichterstatter usbutils zu installieren und dann 

lsusb

zu verwenden. Gibt es überhaupt keine Unterstützung, so ist es sehr hilfreich zu wissen ob der Berichterstatter etwas von einem Treiber weiß der potentiell das Gerät unterstützen könnte.

Gibt es Probleme mit ansteckbarer Hardware die nicht korrekt funktioniert oder nicht entsprechend/überhaupt nicht entdeckt wird, können die benötigten Informationen über folgende Prozedur angezeigt werden kann: Öffne ein Terminal und führe als root folgendes Kommando aus: 

tailf /var/log/messages 2>&1 | tee output.txt

Lasse diesen Bericht als Datei output.txt an die Fehlermeldung anhängen. Dies gilt auch für die gesamte Hardware die am Computer angeschlossen wird, wenn das System bereits läuft.

Langsamer Systemstart

Frage nach der boot.svg, welche die Ausgabe bei der Ausführung von systemd-analyze plot > boot.svg in einer Konsole oder Terminal ist,
und auch nach der journal.txt, welches die Ausgabe des Befehls journalctl -ab > journal.txt als root ist.

X Server stürzt beim Start ab

Es ist nicht selten, dass der X Server abstürzt, wenn er gestartet wird, in diesem Falle, sollte der Berichterstatter gefragt werden die Datei /var/log/Xorg.0.log an den Bericht anzuhängen (kopieren, bevor X wieder gestartet wird, oder die Datei/var/log/Xorg.0.log.old nachdem X neu konfiguriert und gestartet wurde).

System starten nicht, wegen einer falschen menu.lst Datei

Du musst den Berichterstatter fragen, dass er die Datei /boot/grub/menu.lst an den Fehlerbericht anhängt und die entsprechende Datei menu.lst, wenn möglich. Um weiter mehr über die Partitionierungstabelle zu wissen, sollte der Berichterstatter die Ausgabe von 

fdisk -l /dev/sd[a-z]

ebenfalls mitliefern.

Druckerprobleme

Entdecken

Gibt es Probleme mit einer ansteckbaren Hardware die nicht korrekt funktioniert oder nicht korrekt/oder überhaupt nicht entdeckt wird, können die benötigten Informationen mit folgender Prozedur angezeigt werden: Öffne ein Terminal, als root führe folgendes Kommando aus: 

tailf /var/log/messages 2>&1 | tee output.txt

und lasse den Berichterstatter die Datei output.txt anhängen. Dies gilt für die gesamte Hardware die an den Computer angesteckt wir wenn dieser Bereits läuft.

Zusätzlich sollte noch gefragt werden wie der Drucker mit dem PC verbunden ist, z.B. über USB, Parallel Port, eine Art von USB-Parallel Konverter oder einer anderen Verbindung (direkt verbunden über Ethernet oder Wireless, in einem Netzwerk über einen Drucker-Server ...)

Der Auswähler sollte auch "upstream" sehen ob und und im welchen Ausmaß der Drucker unterstützt wird und welcher Treiber verwendet werden soll:

Alle anderen

Frage nach der Ausgabe von 

 rpm -qa cups

und von 

 systemctl status cups.service cups.socket -al -n50

und nach dem Anhang von

  • /etc/cups/printers.conf
  • /var/log/cups/error_log

und verweise auf z. B. http://fedoraproject.org/wiki/How_to_debug_printing_problems#Printing_troubleshooter , um das aktivieren des Cups debug logging und/oder cups logs über journalctl zu erhalten.

Scanner Probleme

Dir nachfolgende Ausgabe sollte zusätzlich zu den allgemeinen Ausgaben zur Verfügung gestellt werden: 

sane-find-scanner

und 

scanimage -L

Beide Kommandos sollten als root ausgeführt werden um alle angeschlossenen Scanner zu finden (wie auch für einige Geräte/Treiber, ohne Änderung der udev Regeln oder Hinzufügen des normalen Anwenders zu einigen Gruppen, wie lpadmin um die korrekten Einschränkungen wiederzugeben wie der normale Anwender den Scanner verwenden kann, der Scanner wird nicht angezeigt wenn diese Kommandos als normaler Anwender ausgeführt werden)

initrd-bezogene Fehler

initrd-bezogene Fehler können leicht mit Kernel-Fehler verwechselt werden, so solltest du den Bericht sorgfältig betrachten um die Ursache korrekt zu identifizieren. Ist ein Fehler initrd-bezogen, sollte das Paket-Feld auf 

mkinitrd

gesetzt werden und der Fehler dem Kernel-Team zugewiesen werden.

Tonprobleme

Bitte klicke auf den Link und lese Colins Empfehlungen, wie man Tonprobleme debuggt Flag-united-kingdom02.png

Netzwerkausgaben

Dies kann entweder durch Treiber oder Konfigurationsprobleme verursacht werden, deshalb sollte nach folgenden Dinge gefragt werden

  • Fehler in {{Datei|/var/log/messages} die sich auf auf die Verbindung beziehen
  • dmesg.txt die sich aus der Ausführung von dmesg > /tmp/dmesg.txt ergibt, so dass eventuelle Ausgabe sichtbar werden die mit dem Kernelmodulen in Verbindung stehen.
  • lspcidrake -v sollte ebenfalls erfragt werden.

Wenn sich dies auf eine Wireless-Verbindung bezieht, so wird folgende Ausgabe benötigt:

  • iwconfig und
  • iwlist scan
  • iw dev wlp5s0 scan (ändere "wlp5s0" auf den Namen deiner WLAN-Karte, falls nötig)

Hinweis für Auswähler: allgemeine Linux Unterstützung für Wireless Geräte findet man unter http://linuxwireless.org/ oder auf http://linux-wless.passys.nl/index.php?lang=english

Wird ein Treiber von ndiswrapper unterstützt, so frage nach der Ausgabe von

  • ndiswrapper -l

und mit pcmcia Karten verwende

  • lspcmcia

Standby/Ruhezustand

Frage immer nach der Ausgabe von dmesg, nach einer Wiederaufnahme der Arbeit, falls möglich (so wie oben frage den Berichterstatter auch danach, dem Bericht die Datei dmesg.txt anzuhängen, die man durch Ausführen von 

dmesg > /tmp/dmesg.txt

erhält. Zuerst müssen wir wissen ob dieser Fehler von X verursacht wird oder nicht. Aus diesem Grund frage bitte den Anwender, dass er X ausschaltet 

service dm stop

, sich als root anmeldet und 

pm-{suspend,hibernate}

ausführt. Wenn dies funktioniert, so sollte dies ein X-Problem sein. Dann frage den Berichterstatter nach den Dateien /var/log/Xorg.0.log, /etc/X11/xorg.conf und 

lspcidrake -v

. Wenn dies nicht funktioniert, so frage den Berichterstatter dass er versuchen soll den Stand by/Ruhezustand mittels 

echo mem|disk > /sys/power/state

ausführen soll.

Nützliche Links

https://wiki.archlinux.org/index.php/Power_management#Power_management_with_systemd

Thinkpad spezifisch: http://www.thinkwiki.org/wiki/How_to_make_use_of_Power_Management_features

Plymouth Probleme

  • Plymouth kann ganz einfach deaktiviert werden, indem an der Kernel-Kommandozeile 
    init=/sbin/init/
    angehängt wird.
  • Starte im verbose Mode, entferne die Argumente "splash=silent" oder "splash" und "quiet" wenn diese auftauchen.

Samba Ausgaben

Normalerweise sind die Inhalten von /var/log/samba sehr hilfreich, wenn man versucht Probleme mit Samba zu lösen, so ist es empfehlenswert den Anwender zu fragen diese an den Fehlerbericht anzuhängen.

Abstürze

Normalerweise versucht der Berichterstatter zusätzliche debug Pakete zu installieren um hilfreiche Rückmeldungen zu einem Absturz zu erhalten. Der Anwender sollte zuerst hier nachlesen unter: Fehlersuche bei Softwareabstürzen wie man hilfreiche Rückmeldungen über Abstürze erhält.

Drakxtools Abstürze

Für Abstürze von Drakxtools solltest du den Anwender fragen, nachfolgende Schritte auszuführen (gemeldet von Thierry Vignaud auf alter Fehlerbericht):

  • stelle sicher dass gdb installiert ist
  • installiere die Pakete glib2.0-debug, glibc-debug, gtk+2.0-debug, perl-Gtk2-debug & perl-debug aus der Repo "Core debug", dies ist als Vorgabe nicht aktiviert, so dass es der Anwender in Medien konfigurieren..., oder diese als root vom Terminal mit 
     urpmi.update --no-ignore -v Core\ debug
    aktivieren muss
  • dann sind folgende Pakete zu installieren: 
    urpmi glib2.0-debug glibc-debug gtk+2.0-debug perl-Gtk2-debug perl-debug
  • Ausführen der folgenden Kommandos in einem Terminal: 
    gdb -q --args perl /usr/bin/<application name>
  • dann run eingeben und Enter betätigen
  • Wenn die Anwendung abstürzt, bt eingeben und Enter betätigen
  • das Ergebnis des "stack trace" an den Fehlerbericht anhängen

Perl - CPAN Ausgaben

Wenn der Anwender versuch die Module von cpan zu aktualisieren, indem er "cpan" verwendet, sollte der Fehler als INVALID markiert werden, da dies nicht der offizielle Weg ist eine Aktualisierung durchzuführen, da wir die cpan Module als Paket in den offiziellen Repositorys zur Verfügung stellen. Weitere Informationen findet man in Jerome Quelin's Kommentar in dessen Fehlerbericht.

Setzten der Produktpriorität, des Schweregrad und der Komponentenfelder

Es ist in deiner Verantwortung als Mitglied des Auswahl-Teams, das Produkt, die Priorität, den Schweregrad und die Komponentenfelder entsprechend zu setzen.

Das Produkt ist einfach die Produktlinie in der dieser Fehler auftritt. Der größte Teil der Fehler werden auf Mageia zutreffen.

Die Optionen sind normalerweise selbsterklärend.

Priorität

  • Die Priorität release_blocker ist nur für Fehler relevant die auf Cauldron oder Beta-Versionen zutreffen, und sollten nur dann verwendet werden wenn diese ausreichend kritisch sind dass diese die Gesamtqualität der Version gefährden würden, wenn wird diese Veröffentlichen ohne diese Fehler zu beheben.
  • Die Priorität high sollte dann veröffentlicht werden wenn diese ausreichend kritisch sind und vor anderen Fehlerbehebungen gelöst werden sollten, aber für einen release_blocker nicht kritisch genug sind.
  • Die Priorität low sollte für Fehler verwendet werden die ausreichend Trivial und/oder begrenzt sind, so dass es wichtiger ist andere Fehler früher zu beheben.
  • Die Priorität normal sollte für alle anderen Fälle verwendet werden.

Versuche die dem Verfolgungsteam noch nicht zugewiesene Fehlermeldungen dem Auswahlteam nicht als release_blocker zuzuteilen, es sei denn sie sind wirklich wirklich schwerwiegend.

Schweregrad

  • Der Schrweregrad critical sollte für Fehler verwendet werden die ein Paket wirklich unbenutzbar machen (so z.B., Abstütze die den größten Teil des Pakets unbenutzbar machen, oder wenn es völlig unmöglich ist das Paket zu installieren oder auszuführen).
  • Der Schweregrad major sollte verwendet werden wenn eine signifikanten Fähigkeit eines Pakets unbenutzbar ist, oder das Paket im allgemeinen instbil wird.
  • Der Schweregrad minor sollte verwendet werden die nur eine beschränkte Auswirkung auf die Verwendbarkeit des Pakets besteht oder der Fehler nur eine Auswirkung auf einen kleinen Teil der Anwender oder Anwendungsfälle besitzt.
  • Der Schweregrad normal sollte für alle anderen Fehler verwendet werden.
  • Der Schweregrad enhancement, siehe unten für Details.


Du solltest auch das Feld RPM Package setzen, wenn es vom Berichterstatter nicht ausgefüllt wurde, und du weißt auf welchen Wert es gesetzt werden sollte. Dieses Feld kann auf der rechten Seite der Fehlerseite geändert werden.

Für Komponenten

  • Backports: Anfrage, um Pakete (neue Version) für stabile Mageia Veröffentlichungen zu portieren.
  • Installer: Fehlerberichte über den traditionellen Installer von Mageia, drakx, (der Installer verwendet die DVD und die Dual ISO's), für Fehler des LiveCD Installers verwende RPM package und füge draklive-installer im Feld installer hinzu.
  • New RPM package request: Fehler für all die gewünschte Software (erlaubt um in die Distribution eingebunden zu werden), ein Fehler pro Software, um die Fehlerliste sauber zu halten, und um dem Packer und dem QA-Team zu helfen.
  • RPM Paket: Fehler über alle RPMs (offizielle Repositorie, wir unterstützen nichts von Drittanbietern)
  • Version (Medium oder Prozess): Fehler die sich auf Probleme mit den Medien beziehen die zur Installation von Mageia zur Verfügung gestellt werden (Spiegelserver, CD, DVD, ...)
  • Security: Sicherheitsfehler in den Mageia RPMs

Akzeptiere den Fehler und vergewissere dich, dass er korrekt zugewiesen wurde

Wenn der Fehlerbericht bis hierher ausgeführt wurde, bist du nun bereit den Fehler zu akzeptieren und das Schlüsselwort Triaged hinzufügen. Du kannst auch einen Kommentar in den Fehlerbericht hinzufügen der dies anzeigt, z.B. "Assigning to the maintainer". Der Betreuer kann eine Person oder ein Team sein.

Es ist wichtig zu überprüfen, dass der Fehlerbericht dem richtigen Betreuer zugewiesen wurde. In den meisten Fällen kann die Zuweisung korrekt ermittelt werden, z.B. Bugzilla Abfragender Betreuerdatenbank und Ausfüllen des Fehlerzuweisungsfeldes ("Assigned To") basiert automatisch auf dem Paket im Feld "RPM Package", aber manchmal ist der Betreuer in der Bugzilla-Datenbank nicht korrekt und der Fehler wird der falschen Person zugewiesen, so dass dies in jedem Fehlerbericht zu überprüfen ist.

Wenn du vermutest, dass diese Angabe falsch sein kann, überprüfe die letzten changelog-Einträge für das Paket. Bist du nicht sicher wem dieser Fehler zugeteilt werden soll, versuche das beste anzunehmen und bevorzuge jene Betreuer die schnell auf Bugzilla-Angelegenheiten antworten.

Nützliche Links um etwas über die Paketbetreuer zu erfahren:

  • Diese Mageia Betreuer Datenbank, ändert rpm auf das was du suchen willst (wir haben auch eine Betreuer Textseite oder eine Liste der Mitarbeiter oder eine Liste aller nicht betreuter Pakete)
    • Hier geschehen die Abfragen unter dem Namen der SRPM (source RPM), du kannst dies unter Verwendung folgender Kommandos herausfinden:
      • Vorausgesetzt du hast folgendes Paket auf deinem System installiert: 
        rpm -q --qf '%{SOURCERPM}\n' <package-name>
      • ist das Paket nicht installiert so kannst du urpmq verwenden, womit die urpmi Datenbank abgefragt werden kann und sollte funktionieren ob das Paket installiert ist oder nicht (verwende rpm direkt, wenn das Package bereits auf deinem System installiert ist, um Zeit (und Bandbreite) beim Herunterladen der urpmi Syntheses-Dateine von den Online Repos zu sparen): 
        urpmq --sourcerpm <package-name>
  • Eine Website eines Mitwirkenden, welche die gleiche API wie das Greasemonkey-Skript verwendet.
Es zeigt dir eine Liste an Beitragenden, wenn kein Betreuer für das Paket vorhanden ist. Es funktioniert sowohl für RPMs, als auch für SRPMs.
  • Sophie
    • du kannst die Web Schnittstelle von Sophie verwenden um alle Arten an Informationen über ein rpm Paket zu erfahren, inklusive dem Betreuer eines Pakets
    • Bist du mit der Verwendung des IRC vertraut, so kannst du den Sophie bot direkt abfragen, siehe auf der Seite Sophie für weitere Informationen darüber wie man den bot in IRC verwendet. Verwende den Sophie bot auf IRC ist der schnellste Weg um Informationen über ein Paket zu erhalten, so dass es eine gute Idee ist die Verwendung von Sophie zu erlernen.
  • In einigen IRC Kanälen kannst du auch [mbot Flag-united-kingdom02.png verwenden. Durch verwenden von ",maint <paketname>" wird es die gleichen Informationen wie auf der contrib-Webseite liefern.

TRACKER Fehler

Ist für ein Paket mehr als ein Fehlerbericht geöffnet, so ist es zweckmäßig all diese Berichte in einem einzelnen Fehlerbericht zusammenzufassen. Dies erreicht man durch Öffnen eines Fehlerberichtes und diese auf "Depend" zu setzen, indem <die Anzahl aller Fehlerberichte für dieses Paket gesetzt werden> im Feld "Depends on" von Bugzilla. Auf diese Weise, wenn der Zustand einer dieser Fehlerausgaben sich ändert, ändert sich auch dieser Zustand, dies ist hilfreich um ein Gesamtbild über die verschiedenen Pakete zu erhalten (idealerweise passiert dies für core/important Pakete).

Wie erstellt man einen tracker ?

  • füge [TRACKER] in der Zusammenfassung und im Schlüsselwort ein
  • in diesem tracker:
    • einen Fehler-tracker für die benötigte Implementierung
    • Ein Fehler zum Verfolgen des Fehlers in/von der Implementierung
  • füge keine Erweiterungsanforderungen in einem blocker Fehler ein
  • mische keine technischen mit 'physikalischen' Fehler (artwork/oxygen Thema)

Liste der TRACKER Fehler

Erweiterungsanforderungen

Gültige Erweiterungsanforderungen sind Anforderungen die an einem Paket für ein Produkt ausgeführt werden, oder eine Anforderung zur Erweiterung im Code einer Anwendung die vom Mageia-Entwicklerteam betreut wird. Um Erweiterungsanforderungen zu behandeln, überprüfe ob der Bericht ein Duplikat ist, dann überprüfe ob die Fehlermeldung verständlich und vollständig geschrieben wurde. Wenn nicht, setze den Bericht auf NEEDINFO und frage den Berichterstatter um Klärung. Ist der Bericht entsprechend verständlich und vollständig, setze den Schweregrad auf enhancement und die Priorität auf normal und Zuweisen des Fehlers an der Paketbetreuer.

Auf der anderen Seite, wenn eine Erweiterungsanforderung direkt durch den "upstream" ausgeführt wird, so musst du den Fehler als INVALID schließen und den dem Anwender nahelegen diese Fehlerbericht direkt dort zu stellen.

Die meisten der Anforderungen werden normalerweise in Cauldron für zukünftige Mageia-Versionen behoben (so wie Installer bezogene Anforderungen), dann solltest du versuchen die Version zumeist auf cauldron zu setzen, ausgenommen für Fehleranforderungen, z.B. eine Paket-Rückportierung.

Anfrage nach neuen Paketen

  • Prüfe, dass das Paketanfragen der Vorgabe Wie_ein_Fehler_berichtet_wird-de#Wie_man_eine_Paketanforderung_ausf.C3.BCllt entsprechen.
  • Prüfe, dass die Software freie SOftware ist, damit wir diese in der Distribution hinzufügen können
  • Optional, füge Paketbauer oder Gruppen an Paketbauer hinzu, von denen du weißt, dass diese möglicherweise an einem CC interessiert sind; als Beispiel: Die KDE Maintainergruppe für KDE Anwendungen, oder ein Paketbauer, der Spiele mag und daran interessiert sein könnte.
  • Das komplette Paketbau-Kollektiv hinzufügen (dies ist das grundsätzliche Vorgehen): pkg-bugs@ml.mageia.org mit dem folgenden Kommentar (auf englisch):
 Assigning this package request to all packagers collectively.

 On a voluntary basis, one of them might, if there are no license or other legal issues, want to integrate it to the distribution and maintain it for bug and security fixes.

 You might also want to join the packager team to maintain this piece of software: see https://wiki.mageia.org/en/Becoming_a_Mageia_Packager

Whiteboard

  • FOR_ERRATA7 : Muss auf die Seite Mageia 7 Errata hinzugefügt werden.
  • IN_ERRATA7 : Wurde auf die Seite Mageia 7 Errata hinzugefügt.
  • FOR_RELNOTES7: Muss auf die Seite Mageia 7 Veröffentlichungshinweise hinzugefügt werden.
  • IN_RELNOTES7: Wurde auf die Seite Mageia 7 Veröffentlichungshinweise hinzugefügt.
  • FOR_ERRATA6 : Muss auf die Seite Mageia 6 Errata hinzugefügt werden.
  • IN_ERRATA6 : Wurde auf die Seite Mageia 6 Errata hinzugefügt.
  • check : Für Fehler zum schließen
  • cauldron : Für gewünschte Pakete, wenn das Paket bereits in Cauldron existiert - auch wenn gewünscht ist, eine in Cauldron vorhandene Version eines Paket auf die stabile Mageia Veröffentlichung zurück zu portieren
  • MGA5TOO : (für Fehlerberichte, welche Cauldron betreffend ausgefüllt wurden, aber auch in Mageia 5 vorhanden sind)
  • only_in:MGA5 oder only_in:MGA5,MGA6 : Fehlerberichte, welche nur eine stabile Mageia Veröffentlichung betreffen, aber entweder in Cauldron behoben wurden oder nicht relevant sind. Diese Information hilft, wenn das EOL erreicht ist, um zu wissen, dass wir diese Fehler schließen können, ohne diese einer nachfolgeden Mageia Veröffentlichung zugeordnet werden muss.
    • (MGA5) : für Fehler die den Installer betreffen, um zu zeigen, dass diese für die finale Veröffentlichung von Mageia 5 weiterhin zutreffen
  • 3<$step_of_the_dev> : eventuell wird dies helfen, das Errata auf dem aktuellsten Stand zu halten, um andere Leute danach zu fragen, ob diese den Fehler bestätigen können oder ob dieser ungültig ist.
  • OK : Für den Empfänger des Fehlerberichts, welches er in das Whiteboard einfügt, wenn er mit der Zuordnung einverstanden ist, aber den Status nicht auf ASSIGNED setzen kann
  • LibOUpdate : um eine Liste an aktuellen Fehler in LibreOffice anzuzeigen (welches zur Zeit 'veraltet' ist)
  • start7 : für *drak* Fehler, für die ein Patch verfügbar ist: Risiko, dass alles nach der Veröffentlichung von Mga6 nicht mehr funktioniert, sobald Mga 7 Cauldron geöffnet wurde.

QA-Teams Whiteboard Einträge

Siehe die Liste an Schlüsselwörter, die das QA-Team verwendet Flag-united-kingdom02.png

Veraltete Whiteboard Einträge

  • Mdv (für gewünschte Pakete, wenn das Paket in Mandriva vorhanden ist) (veraltet)
  • X (für Pakete die in Mdv 2010.2 nicht gefunden wurden) (veraltet)

Aussagekräftige Kommentare

Muss noch besprochen werden

Was machen wir mit:

  • Wie erreichen wir, dass Packer in unbetreuten Paketen Fehler beheben, wenn es verfügbare Patches gibt?

Grundlegende Upstream Fehlerverfolgung


Gehe zum Portal der Fehlertruppe

Retrieved from "https://wiki.mageia.org/mw-en/index.php?title=Verfolgungsanleitung-de&oldid=54733"