Debian Eine kleine Anleitung für das Bugreporting

Absolut fehlerfreie Software gibt es nicht und somit kann es immer einmal vorkommen, dass eine Anwendung aus den Repositories von Debian nicht genau jenes macht was sie eigentlich sollte. Unerfahrene, aber erfahrene Benutzer haben unnötigerweise Argwohn gegenüber dem Melden von Fehlern, dabei geht das Melden von Fehlern unter Debian mit Hilfe von grafischen Werkzeugen mittlerweile sehr schnell und einfach. Ein kleiner einfacher Einblick in das Melden von Fehlern als Leitfaden und einem Beispiel mit einem Bug in dem für mich besten Fenstermanager der Welt

Die nicht funktionierende Konfiguration

Ich liebe meinen Fenstermanager notion.
Seit mehr als einem Jahrzehnt sind wir ein treues Gespann und auch ein Blick auf die anderen großen TilingWMs wie i3, awesome, dwm, wmii etc änderten dies nicht.

Entstanden ist der auf der Programmiersprache LUA basierende Fenstermanager aus der Prämisse, dass der frühere Entwickler des Fenstermanagers ion3 jenen nicht weiter entwickeln wollte.
Weitere Erklärungen spare ich mir, denn über das Thema könnte man nun einige lange Kapitel schreiben und dies würde zu weit führen.
Grundlegend sei zu sagen, dass der Fenstermanager genau richtig für meine Belange ist und perfekt wie ein Maßanzug sitzt. Ich finde es mehr als Gut, dass es einen Fork des Originals unter dem Namen notion gibt und gehe davon aus, dass der Fortbestand bis zur Unendlichkeit und noch viel weiter gesichert ist.

Da ich nun von meiner Seite aus docker evaluieren musste, kam ich als Debianer auf die plausible Idee die jetzige Testversion von Debian, Jessie, auf einem Dell Latitude E6400 mit 4GB RAM und einer SSD zu installieren. Wer Docker noch nicht verinnerlicht hat, sollte dies auf jeden Fall nachholen.

Es gibt wie bei jedem anderen Benutzer Standards bei meiner Installation.
Sei es der Fenstermanager, der Dateimanager, das Mailprogramm etc. Es gibt dieses definitive muß an Anwendungen, sonst startet das Grauen nach maximal einer Stunde Arbeit.
Workflow, der eigene, muss sein.
Nach dem Laden der Konfigurationsdateien aus meinem git und der Anpassung der Konfigurationen von Thinkpad auf DELL, wollte ich mit dem Fenstermanager arbeiten. Jener aber ignorierte die gemachten Änderungen geflissentlich.

Nach einem kurzen hin und her, des Rätsels Lösung ist, dass innerhalb des Konfigurationverzeichnisses, $HOME/.notion, sich der Fenstermanager immer noch auf die Datei cfg_ioncore.lua stützt, obwohl er die Datei cfg_notioncore.lua nutzen sollte.

Die sorgte bei mir gleich zweimal für Verwirrungen sorgte.

Erstens, da sich die Hauptkonfigurationsdatei unter dem Namen /etc/X11/notion/cfg_notioncore.lua befindet und zweitens, damals erstellte ich auf dem Thinkpad unter Wheezy die cfg_notioncore.lua, da dort der Fenstermanager direkt aus den Quellen kompiliert und installiert wurde.

Also habe ich einen Grund einen Bugreport für notion zu schreiben und auch gleich einen kleinen Leitfaden zu verfassen.

Debian eine kleine Anleitung für das Bugreporting

Installation

Um einen Bugreport zu generieren genügt es entweder die grafische, oder die kommandozeilenorientierte Variante des Programms reportbug zu installieren.

Ich empfehle zu Beginn die grafische Variante , welche durch ein

aptitude install reportbug-ng

installiert wird und auch hier vorerst einmal vorgezogen wird.

reportbug-ng ist eine auf QT basierende Oberfläche um Fehler entweder im DBTS zu suchen, und/oder an das Debian Bugtracking System ( Debian BTS) zu melden.

Da das Melden von Fehlern sehr umfangreich zu Fuß sein kann und vor allem für Einsteiger verwirrend ist, ist diese Alternative zu Beginn gegenüber reportbug definitiv vorzuziehen. Nach meinem Empfinden erleichtert das Programm doch sehr vieles und nimmt dem Benutzer mit seinem Automatismus auf positive Art einiges aus den Händen und an die selbigen.

Shellthusiasten können auf jeden Fall reportbug vorziehen :)

Einige Gedanken vorab

Keine Angst Fehler zu melden. Um einen Fehler zu finden muss man kein Programmierer sein, welches viele Anwender auch schon bemerkten ;)

Auch muss man kein Programmierer sein um den Fehler zu melden, denn man ist im Normalfall nicht dafür zuständig den Fehler anhand des Codes zu berichten und vor allem mit Hilfe von selbst geschriebenen Code zu berichtigen.
Wobei letzteres der Idealfall wäre, nach genauerer Überlegung, aber Idealfälle gibt es nicht immer und auch ist nicht immer der Anwender ein Programmierer.

Wer gerne einen Fehler melden möchte, sollte sich über einige Schritte im Klaren sein und die folgende Liste als Leitfaden ansehen :

  • Wiederholt sich der Fehler bei gleicher Verfahrensweise ?
    Bsp: Wenn Gimp anstelle das Bild abzuspeichern einfach nicht wirklich etwas auf ein lokales Laufwerk schreibt, dann ist das schlecht. Lässt sich dies mit einem anderen Laufwerk reproduzieren, oder auf einem anderen Rechner, dann ist das ein gefundener Fehler.
  • Handelt es sich wirklich um genau jenes Programm, welches den Fehler produziert ?
    Bsp: Bleiben wir bei Gimp.
    Lässt sich das Bild nicht auf einem eingebundenen Netzlaufwerk abspeichern, aber auf einem lokalen Speicher, dann ist nicht Gimp das Problem, sondern das Netzlaufwerk, cifs/nfs etc. Also ist es nicht ein Fehler in Gimp, sondern woanders. Kein gefundener Fehler
  • Wurde der Fehler schon gemeldet, oder vielleicht schon behoben ?
    Hat die Suche mit reportbug ergeben, dass der Fehler schon bekannt ist, muss jener nicht gemeldet werden und man kann schauen, ob man etwas zu der Lösung beitragen kann, wenn man möchte.
  • Wie ist der Schweregrad des Fehles zu definieren ?
    Bsp: Bleiben wir auch hier bei Gimp.
    Das nicht Abspeichern eines Bildes im RAW-Format ist nicht critical zu bezeichnen. Eher als normal, oder important, wobei man hier auch darüber streiten könnte. Aber es ist nicht absolut kritisch. Ich denke man versteht mich.
  • Beschreibe den Fehler so Gut wie möglich, dass der Entwickler ihn auch direkt nachvollziehen kann.
  • Bist Du Willens den Fehler mit Deiner Hilfe einzukreisen ?
    Bsp: Das ist aber jetzt das absolut letzte Beispiel mit Gimp.
    Der Entwickler schickt Dir eine neue Version, mit dessen Hilfe Du automatisch einen Bugreport erstellst und welche den Fehler gefixt haben sollte. Du installierst sie und wiederholst den Abspeichervorgang und teilst das Ergebnis dem Entwickler mit. Dies kann natürlich einige Male nötig sein, aber dann sollte der Fehler nicht mehr vorkommen.

Die Schweregrade lassen sich wie folgt definieren

Wishlist
Für beliebige Feature Requests , aber auch beliebige Fehler, die aufgrund wesentlicher konzeptioneller Erwägungen schwer zu beheben sind.

Minor
Ein Problem, das die Nützlichkeit des Pakets nicht beeinflusst, und das vermutlich sehr leicht zu beheben ist

Normal
Standardwert, anwendbar auf die meisten Fehler

Important
Ein Fehler, der wesentliche Auswirkungen auf die Benutzbarkeit des Pakets hat, ohne es völlig unbrauchbar für jedermann zu machen

Serious
Ist eine ernsthafte Verletzung der Debian Policy ( bedeutet ungefähr, dass es eine muss– oder erfordert-Klausel verletzt), oder macht das Paket nach Meinung des Betreuers ungeeignet für eine Veröffenltichung

Grave
Macht das betreffende Paket (fast) unbrauchbar, oder verursacht einen Datenverlust. Und/oder öffnet eine Sicherheitslücke, die es erlaubt, auf die Benutzeraccounts derjenigen Benutzer zuzugreifen, die das Paket verwenden.

Critical
Beschädigt Software im System, die keinem Bezug zum fehlerhafte Paket steht, (oder sogar das ganze System) oder verusacht einen ernsthaften Datenverlust, oder öffnet eine neue Sicherheitslücke auf dem System, auf dem sie das Paket installieren.

Den Fehler melden, das eigentliche Bugreporting

 

Informelles:
WNPP ist für eine Fehlermeldung nicht von belang. Es geht um verwaiste, oder Pakete, welche einen neuen Maintainer suchen.

Der gemeldete Fehler

Der fertig Bugreport hat die Nummer #754589 und leider vor lauter Anleitung schreiben habe ich vergessen die Hilfslinie:
— Please enter the report below this line. —
zu löschen ツ

Schwer ist das Fehlermelden nicht.
Wenn einmal reportbug-ng gestartet wurde ergibt sich im Grunde alles von selbst und mit einem gesunden Menschenverstand ist das Melden von Fehlern auch kein großes Rätsel und mit Programmierung hat auch dies sehr wenig zu tun. Berührungsängste sind somit Fehl am Platz.
Für den Shelltusiast empfehle ich die Shellversion reportbug, welche am Anfang eine textbasiert-, urwid– oder gtkbasierte Oberfläche als Auswahl anbietet.

2 Gedanken zu „Debian Eine kleine Anleitung für das Bugreporting“

  1. „Wer Docker noch nicht verinnerlicht hat, sollte dies auf jeden Fall nachholen.“

    Bringt mir als Privatnutzer Docker irgendetwas? Auf der Webseite sehe ich nur etwas von „Software in die Cloud schieben“, ich besitze jedoch nur einen Raspberry Pi mit Owncloud darauf…Docker ist nicht geeignet, um die Windows-Funktion zu imitieren, das Gesamte System in einem VHD-Image zu betreiben, oder?

Kommentare sind geschlossen.