Wie man ein Problem berichtet

Problembericht für ein Release

1. Prüfe zuerst die Korrekturroutinen und Hinweise für das Release.
2. Als Nächstes prüfe, ob es ein neueres Release gibt.
3. Als Letztes prüfe die Änderungen, die zwischen den OpenBSD-Releases gemacht wurden.

Wenn es anscheinend auf keiner der Seiten eine Lösung für dein Problem gibt, so mache dich bitte mit sendbug(1) vertraut, bevor du einen Fehlerbericht einsendest.

Um herauszufinden, welche Fehlerberichttypen erwünscht sind, lies weiter unten.

Problemberichte für das aktuelle Release

1. teste das Problem mindestens zweimal mit Quelltexten, die im Abstand von mehreren Tagen aktualisiert wurden.
2. melde keine Kompilierungsprobleme im Quelltextbaum, es sei denn sie bleiben länger bestehen. Das sind meistens deine Fehler oder es wird bereits an ihnen gearbeitet, bevor du ihnen begegnest. Die Leute im Projekt erzeugen mindestens einmal am Tag ein make build (normalerweise mehrmals am Tag), mit verschiedenen Architekturen.
3. denke daran, dass die anoncvs-Server mit deutlichem Zeitabstand zum eigentlichen Quelltextbaum aktualisiert werden.
4. prüfe, ob dein Problem vielleicht mit den Änderungen zwischen den OpenBSD-Releases erledigt wurde.
5. Viel Aufwand wird bei der Erzeugung von Schnappschüssen betrieben. Manchmal werden Fehler gemacht, und unsere Entschuldigungen sind vielfältig. Es ist daher meist angebrachter, unsere Mailinglisten zu lesen und in einer davon über das Problem zu schreiben, statt einen Problembericht zu senden.

Wie man einen Fehlerbericht schreibt

Bitte fange nicht an, Probleme zu beseitigen, die ein gewisses Maß an Arbeit benötigen, bis du absolut sicher bist, dass du sie auch verstehst; insbesondere während wir kurz vor der Veröffentlichung eines neuen Releases stehen und keine großen Teile unseres Quelltextes ändern können. Wenn du eine Menge Quelltext schreibst, prüfe möglichst viele Foren, um zu prüfen, ob nicht bereits jemand anderes an dem Problem arbeitet.

Die folgenden Punkte sollten in jedem Fehlerbericht enthalten sein:

1. Die exakte Abfolge der Schritte, von Anfang an, um das Problem zu reproduzieren. Sie sollte unbedingt vollständig sein: ein einfaches Kommando ohne die Argumente oder andere Daten reicht nicht aus. Wenn ein Fehler eine bestimmte Befehlsfolge erfordert, so liste sie bitte auf. Selbstverständlich ist es gut, wenn du dein Beispiel möglichst klein hälst - wichtiger ist aber die Reproduzierbarkeit.

2. Die Ausgabe, die du erhältst. Sage bitte nicht so was wie »funktionierte nicht« oder »schlug fail«. Wenn es eine Fehlermeldung gibt, zeige sie, selbst wenn du sie nicht verstehst. Wenn OpenBSD mit einem bestimmten Fehler abstürzt, sag uns mit welchem. Wenn gar nichts passiert, sag das ebenfalls. Selbst wenn dein Problemfall ein Programm ist, das abstürzt oder etwas anderes Offensichtliches, muss das in unserer Umgebung nicht auftreten. Am einfachsten ist es, die Ausgabe - falls möglich - direkt von der Konsole zu kopieren.

   Hinweis: Im Falle fataler Fehler muss die ausgegebene Fehlermeldung nicht alle verfügbaren Informationen enthalten. In diesem Fall sieh dir auch die Ausgabe der Systemlogdateien an, die sich in /var/log befinden. Wenn du ein Problem mit einer Anwendung hast, die ihre eigene Logdatei schreibt (z. B. httpd), suche in der passenden Logdatei nach Fehlern (im Falle von httpd ist das /var/www/logs).

3. Die OpenBSD-Kernelausgabe. Diese erhältst du mit dem dmesg-Befehl. Es ist aber möglich, dass deine dmesg-Ausgabe nicht alle Informationen bietet, die in /var/run/dmesg.boot zu finden sind. Wenn das der Fall ist, füge die Daten von Beiden hinzu. Bitte füge sie unbedingt zu allen Fehlerberichten hinzu.

4. Wenn du Software von Drittanbietern benutzt, die mit deinem Fehler zu tun hat, schreibe das auch, inklusive aller Versionsangaben, die deine Software bietet. Wenn du über einen CVS- oder FTP-Snapshot redest, erwähne das ebenso, einschließlich Datum und Uhrzeit.

5. Eine Rückverfolgung von deinem Systemabsturz. Wenn dein Kernel abstürzte und du an einem ddb>-Prompt bist, dann zeig uns deine Panikmeldung genauso wie die Ausgabe der Befehle trace und ps in deinem Fehlerbericht. Wenn das System hängt, versuche sysctl ddb.console=1 vorher zu aktivieren und DDB entweder über Strg+Alt+Esc auf der Tastatur (du darfst dich dabei nicht in X befinden) oder über das Senden von BREAK per serieller Konsole zu erreichen.
   Sollte die Panikmeldung aus irgendeinem Grund nicht sichtbar sein, so kannst du sie die mit dem Befehl show panic erneut zeigen lassen.
   Das ist unbedingt notwendig. Panik-Berichte ohne die Panikmeldung, traceback- und ps-Ausgaben sind sinnlos.
   Die Ausgabe von show registers könnte ebenso von Interesse sein. Du startest dann am besten mit boot dump, sodass ein Kernelabbild mit savecore(8) (wie in der Handbuchseite crash(8) beschrieben) gesichert werden kann, um weitere Informationen für unser »post mortem«-Entwanzen zu liefern.

6. Wenn du von einem Problem mit dem X Fenstersystem auf einer Plattform berichten willst, die auch den X.Org-Server nutzt, so füge bitte die komplette Datei /var/log/Xorg.0.log zusätzlich zu den Informationen aus dmesg.boot hinzu.

Mach dir keine Sorgen, wenn dein Fehlerbericht ziemlich lang wird. Das ist halt so - und viel besser, als dass wir dir jede Information aus der Nase ziehen müssen. Andererseits ist es natürlich auch fair vorher zu fragen, ob sich jemand deinen Fehlerbericht ansehen will.

Einsenden eines Fehlerberichts

Wenn irgendwie möglich, benutze das Kommando sendbug(1), um den Fehlerbericht einzusenden. Damit du sendbug verwenden kannst, muss dein System über das Internet E-Mails versenden können. Wenn du sendbug nicht auf einer funktionierenden OpenBSD-Maschine nutzen kannst, sende deinen Fehlerbericht bitte an bugs@openbsd.org.

Es kann aber auch passieren, dass du keinen Fehlerbericht sendest, sondern eine Anfrage nach einer neuen Funktionalität. Diese werden akzeptiert, insbesondere mit Quelltext, der deine neuen vorgeschlagenen Funktionalitäten implementiert. Wenn jemand anderes den Quelltext für deinen Vorschlag schreibt, kann es gut passieren, dass dabei irgendein Missverständnis auftritt und du das gar nicht bemerkst.

Zum Debuggen einiger Probleme müssen wir die Hardware passend zum Problem besitzen. Bitte bedenke, dass die Ressourcen des OpenBSD-Projekts begrenzt sind. Du könntest Hardware spenden.

Arten von Fehlerberichten in absteigender Beliebtheitsreihenfolge:

1. Reproduzierbare Probleme mit Quelltextkorrekturen sind die besten.
2. Reproduzierbare Probleme, die nicht von deinem Hardware/Softwarelayout abhängig sind.
3. Reproduzierbare Probleme, die spezifisch für dein Softwarelayout sind.
4. Reproduzierbare Probleme, die spezifisch für dein Hardwarelayout sind.
5. Nicht reproduzierbare Probleme - oder Probleme die du nicht erneut hervorrufen willst.