Wie man ein Problem berichtet

Berichte über Probleme vorhandener Versionen

1. Prüfe zuerst die Patches und Hinweise für die Version.
2. Als nächstes prüfe, ob es eine neuere Version gibt.
3. Als letztes prüfe die Änderungen, die zwischen den OpenBSD-Versionen gemacht wurden.

Wenn es darunter scheinbar keine Lösung für dein Problem gibt, mach dich bitte mit sendbug(1) vertraut, bevor du einen Fehlerbericht einsendest.

Um herauszufinden, welche Fehlerbericht-Typen erwünscht sind, lies weiter unten.

Fehlerberichte von Current-Versionen

1. teste das Problem mindestens zweimal, mit Quelltexten, die im Abstand von mehreren Tagen aktualisiert wurden.
2. berichte nicht von Kompilierungsproblemen im Source-Tree, 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 machen mindestens einmal am Tag einen make build, normalerweise mehrmals am Tag mit verschiedenen Architekturen.
3. denk daran, dass die anoncvs-Server mit deutlichem Zeitabstand zum eigentlichen Source-Tree aktualisiert werden.
4. prüfe nach, ob dein Problem vielleicht mit den Änderungen zwischen den OpenBSD-Versionen erledigt wurde.
5. Viel Mühe wird beim Erzeugen von snapshots aufgewendet. Manchmal werden Fehler gemacht, und unsere Entschuldigungen sind vielfältig. Lesen der Mailinglisten oder Schreiben an eine davon ist meist angebrachter als ein Fehlerbericht.

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 Auslieferung einer neuen Version stehen und keine großen Teile unseres Quelltextes ändern können. Wenn du eine Menge Code 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 Schrittabfolge, von Anfang an, um das Problem zu reproduzieren. Sie sollte unbedingt vollständig sein, ein einfaches Kommando ohne die Argumente oder andere Daten reichen nicht aus. Wenn ein Fehler eine bestimmte Sequenz an Befehlen erfordert, liste sie bitte auf. Natürlich ist es gut, wenn du dein Beispiel möglichst klein hälst, wichtiger ist aber die Reproduzierbarkeit.

2. Die Ausgabe, die du erhälst. Sage bitte nicht sowas wie ,didn't work' oder ,failed'. Wenn es eine Fehlermeldung gibt, zeige sie, selbst, wenn du sie nicht verstehst. Wenn OpenBSD mit einem bestimmten Fehler ,eine panic wirft', sag uns mit welchem. Wenn gar nichts passiert, sag das ebenfalls. Selbst wenn dein Problemfall ein Programm ist, das abstürzt oder etwas anderes, was offensichtlich ist, muss das in unserer Umgebung nicht auftreten. Die einfachste Möglichkeit ist, 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 Systemlogfiles an, die sich in /var/log befinden. Wenn du ein Problem mit einer Anwendung hast, die ihr eigenes Logfile schreibt, wie z.&nbbsp;B. httpd, suche im passenden Logfile nach Fehlern (im Falle von httpd ist das in /var/www/logs).

3. Die OpenBSD-Kernelausgabe. Die bekommst du mit dem dmesg-Befehl, aber es ist 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 einer dritten Partei benutzt, die mit deinem Fehler zu tun hat, sage 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. Ein ,traceback' von deinem Systemabsturz. Wenn dein Kernel panic'ed und du an einem ddb>-Prompt bist, dann zeig uns deine ,panic message', genauso wie die Ausgabe der trace- und ps-Befehle in deinem Fehlerbericht.
   Sollte die ,panic message' aus irgendeinem Grund nicht sichtbar sein, kannst du sie erneut mit dem Befehl show panic bekommen.
   Das ist unbedingt notwendig. Panic-Berichte ohne die ,panic message', traceback- und ps-Ausgaben sind sinnlos.
   Die Ausgabe von show registers könnte ebenso von Interesse sein. Du bootest dann am besten mit boot dump, so dass ein Kernelimage von savecore(8) gesichert werden kann, um weitere Informationen für unser post-mortem debugging zu liefern.

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

Mach dir keine Sorgen, wenn dein Fehlerbericht ziemlich lang wird. Das ist eben 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.

Und zuletzt solltest du beim Schreiben eines Fehlerberichts unbedingt unmissverständliche Worte wählen.

Einsenden eines Fehlerberichts

Wenn irgendwie möglich, benutze das sendbug(1)-Kommando, um den Fehlerbericht in unser Verfolgungssystem zu bekommen. Du kannst dem Verfolgungssystem (tracking system) auf dieser Webseite folgen. Zum Nutzen von Sendbug muss dein System wenigstens zeitweise Internet E-Mail versenden können. Wenn du Sendbug nicht auf einer funktionierenden OpenBSD-Maschine nutzen kannst, sende deinen Fehlerbericht bitte an bugs@openbsd.org.

Vielleicht sendest du ja auch eine Anfrage nach einer Funktionalität, und keinen Fehlerbericht. Neue Funktionalitäten 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üsen wir die Hardware passend zum Problem haben. Bitte bedenke, dass die Ressourcen des OpenBSD-Projekts begrenzt sind. Du könntest Hardware spenden.

Arten von Fehlerberichten in sinkender 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 erzeugen willst.