Aus Mageia wiki
Wechseln zu: Navigation, Suche
Warnung.png
Warnung!

Das Wiki ist umgezogen und befindet sich nun unter https://wiki.mageia.org/en/Hauptseite-de . Bitte nutzen Sie das neue Wiki.

Die hier enthaltenen Informationen werden nicht aktualisiert und sind deshalb veraltet oder sogar falsch!
Diese Seite befindet sich im neuen Wiki hier: https://wiki.mageia.org/en/Verfolgungsanleitung-de


Diese Seite ist ein Entwurf
Wenn du diese Seite verändern willst, so melde dich einfach an und klicke auf den Tabulator Bearbeiten. Betrachte auch andere Seiten verbessern und betreuen.


Gehe zum Portal der Fehlertruppe

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.

Was zu geschehen hat

  • füge weitere Informationen über die Installation hinzu (welche Pakete zu wählen sind)
  • Hinzufügen von Informationen über die Infrastruktur und Webseitenfehler
  • und über Anfrage 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 Fehler 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 kompletx 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. ein Bericht einen Absturz in einer GNOME-Anwendung berichtet, betrachte auch dass das Problem in einer darunterliegenden Ebene liegen kann, so z.B. die Bibliotheken GTK+ oder Pango. Suche auch in diesen Bereichen.

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 ensprechenden 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 ist z.B. der Bericht über den Absturz in einem bestimmten Programm, 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 abgeschlossen werden. Wenn z.B. ein Fehler zu Cauldron berichtet und anschließend in einer stabilen Version, so schließe den zweiten Bericht nicht als Duplikat vom ersten. Der Grund dafür liegt darinn, 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 Mageie Versionen.

48px-Hinweis.png
Bitte Beachten!
Anstatt getrennte Fehlerberichte für verschiedene Versionen zu besitzen, haben wir begonnen MGA2TOO auf dem Whiteboard der Cauldron Fehlerberichte zu setzen so dass diese ebenfalls für Mageia 2 gültig sind. Wurde der Fehler in Cauldron behoben, so kann die Version auf 2 gesetzt werden und MGA2TOO 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 Komponenten 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 Beispiele eines Berichtes der diese 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, aber einen Fehler verursacht oder eine Ausgabe von der Hardware auf dem Computer des Anwenders veranlasst.

Wenn dieser Test nicht bestanden wird, solltest du den Fehler auf den Status RESOLVED INVALID setzen und deine Entscheidung in einem Kommentar zusammenfassen.

Manchmal ist ein Fehlerbericht eine Supportausgaben, anstelle eines wirklichen Fehlers. In diesem Falle kannst du den Fehlerbericht als INVALID schließen und dem Berichtersteller empfehlen unter http://forum.mageia.org um Hilfe zu ersuchen.

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 es kann 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, wenn diese mit der letzten Cauldron oder einem unterstützten Produkt übereinstimmt. Pinge ihn nach zwei Wochen an, wenn er nicht antwortet. Wenn er nicht innerhalb zweier weiterer Wochen antwortet, so kannst die den Zustand auf RESOLVED OLD setzen, zusammen mit einem Kommentar der den Grund erklärt. Dies gilt nicht für Verbesserungsanforderungen, sollten die meisten von ihnen auf die Version Cauldron gesetzt sein (modifiziere das Versionsfeld, wenn erforderlich).

Sind alle nötigen Informationen vorhanden?

Wenn die Fehlermeldung 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 diese Fehlermeldung 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 beinhaltet, 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 Anwedung angezeigt werden, oder an der Konsole, wenn die Anwendung an der Konsole gestartet wird
  • Hardware Information 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.

Ein sehr guter Weg um zu überprüfen ob alle notwendigen Informationen zur Verfügung gestellt wurden ist, zu sehen 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 Kopien der 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 Fehlermeldung 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.

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 leichter Weg um dies zu erreichen ist, den Berichterstatter zu fragen auf die Konsole 2 zu wechseln (durch Betätigen von Ctrl-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 auf der Diskette/dem USB Stick.

Ebenso werden traditionelle Installer-Fehler normalerweise an das Install-Team zugewiesen.

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

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

lspcidrake -v

benötigt. Für USB Geräten, 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 weiss 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, als root führe folgendes Kommando aus: 

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

und 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 er bereits läuft.

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 neu gestartet wurde).

Speedboot Probleme

Der Anwender kann einfach ohne speedboot starten, indem er 

speedboot=no

an der Kernel-Kommandozeile einfügt. Hier einige anomalien die bei einem speedboot auftreten können:

  • Der Anwender kann nach dem Starten mit einem Schwarzen Bildschirm enden.
  • Mit aktivierten speedboot und autologin kann es möglich sein dass kmix nicht in den KDE4 Desktop geladen wird.
  • Die Dienste des NTP (Network Time Protocol) starten manchmal nicht korrekt.
  • Die WIFI Verbindung werden nicht schnell genug gestartet (so bleiben z.B. einige KDE4 Plasma Widgets, die eine aktive Internetverbindung benötigen, bleiben leer, wenn keine aktive Verbindung vorhanden ist und die Anmeldung ausgeführt wird).
  • Hängen Sie auf, um AND/OR zu rammen, aufhängen auf angerufene Platte am KDE4-Menü arbeiten nicht
Suspend to RAM and/or suspend to disk invoked from the KDE4 menu don't work.

System starten nicht, wengen 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 überhaut 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 Network ü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 dem Anhängen von

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

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.

Pulseaudio Probleme

Wenn einige Berichten dass sie nur dann Probleme haben, wenn pulseaudio aktiviert ist (so solltest du beim Berichterstatter nachfragen, dass dieser ohne pulseaudio testet. Dies kann in draksound deaktiviert werden). Der Berichterstatter sollte folgende Schritte ausführen: Zuerst soll sie/er das existierende pulsaudio mit 

pulseaudio -k

killen, dann 

pulseaudio -vvv

ausführen und das Terminal offen haben. Die debug fließt, wenn die pulse audio Clients verwendet werden, und dass ist, wonach wir suchen. 

pacmd ls output

wird verwendet um den Zustand der Komponente zu erhalten (ist nach der Meldung von colin noch zu vervollständigen)

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

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

Stand by/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.

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
  • installilere 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 trivial sollte verwendet werden wenn es fast keine materielle Wirkung auf die Benutzbarkeit eines Pakets gibt.
  • Der Schweregrad normal sollte für alle anderen Fehler verwendet werden.

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 in den nachfolgenden Blockoptionen, des Feldes Comment gesetzt werden.

Für Komponenten

  • 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.
  • Anforderung neuer RPM Pakete: 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 das 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 überpü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ütziche 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>
  • 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.

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 gestzt 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.

Whiteboard:

  • errata (ahmad)
  • check (für zu schließende Fehler)
  • Mdv (für Paketanforderungen, wenn das Paket in Mandriva existiert)
  • X (für Packete die nicht in Mdv 2010.2 zu finden sind)
  • cauldron (für Paketanforderungen, wenn das Paket bereits in Cauldron existiert - also wenn die Cauldron Version eines Pakets angefordert wird um nach stable Rückportiert zu werden)
  • MGA2TOO (für Fehler die sich gegen Cauldron richten, aber ebenso in Mageia 2 vorhanden sind)

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

Abgerufen von „https://wiki.mageia.org/mw-de/index.php?title=Verfolgungsanleitung&oldid=4637“