De/Feedback

From GnuCash
Revision as of 18:02, 5 January 2020 by Fell (talk | contribs) (→‎Ist das Problem bereits gelöst?: mehr Details über branches)
Jump to: navigation, search

Wie man einen Fehler meldet oder einen Verbesserungsvorschlag einreicht ...

Ein paar allgemeine Empfehlungen

Da die Problematik der Fehlermeldung ja viele Projekte gleichermaßen betrifft, wird den Anwendern zunächst die Lektüre mindestens eines der beiden folgenden, teils recht unterhaltsamen Dokumente wärmstens empfohlen:

Obacht, jene Seiten bieten KEINEN SUPPORT für GnuCash, daher bitte weiterlesen.

Die verschiedenen Meldungsebenen des Programms

GnuCash versucht auf verschiedenen Ebenen mit dem Benutzer zu kommunizieren. Während für das Tagesgeschäft die Ausgaben der Programmoberfläche reichen, sind bei Fehlermeldungen häufig die Ausgaben der Anderen erforderlich.

Die Programmoberfläche

Normalerweise kommuniziert GnuCash über seine Benutzeroberfläche mit dem Benutzer durch Hinweise in der Statuszeile, Dialog- oder Meldungsfenstern. Falls dort eine unbefriedigende Fehlermeldung erscheint wie "Beim Lesen der Datei »/Pfad/Name« ist ein Fehler aufgetreten.", sollte der nächste Punkt versucht werden.

Die Ausgaben auf der Konsole

Wenn man das Programm nicht über das Start-Menü aufruft, sondern in einem Befehlsfenster, erscheinen dort zusätzliche Informationen. Meist sollte man zumindest diese Informationen bereithalten, wenn man einen Fehler melden möchte. In unserem Beispiel könnte hier etwa als Grund "Datei nicht gefunden", "Zugriff abgelehnt" oder ... stehen.

Wie öffnet man nun so ein Befehlsfenster?

  • Gnome: Rechner->Anwendungen->Weitere Anwendungen->System->Terminal,
  • KDE: K-Menü->System->Terminals->Konsole,
  • MacOSX: Finder->Programme->Dienstprogramme->Terminal und
  • Windows: Start->Alle Programme->Zubehör->Eingabeaufforderung.

Ein Aufruf darin von 

gnucash --help

listet einem dann eine ganze Reihe möglicher Parameter auf. Für die Fehlersuche bedeutsam sind die im nächsten Beispiel augeführten. Weitere Möglichkeiten zum Feintuning der Ausgaben werden auf der englischsprachigen Seite Logging erläutert.

Falls man des Englischen einigermaßen mächtig ist, empfiehlt es sich insbesondere dann, wenn man vorhat, einen Bugzilla-Eintrag zu erstellen oder ergänzen, das Programm gleich auf Englisch mit 

LANG=C gnucash [--log ...] [--logto ...] [--debug|--extra]

zu starten, um Fehler bei der Rückübersetzung der Meldungen zu vermeiden.

"Der Wodka war gut, aber das Steak war gammlig." soll ja seinerzeit das Ergebnis der ersten maschinellen Rückübersetzung von
"Der Geist war willig, aber das Fleisch war schwach." gewesen sein.


Manchmal reicht aber auch das nicht, dann geht's zum nächsten Punkt.

Die normale GnuCash Protokoll-Datei .trace

GnuCash schreibt während jedem Programmdurchlauf eine Protokolldatei "gnucash.trace", genannt "Trace-Datei". Bitte nicht mit dem ähnlich klingenden Stacktrace verwechseln! In vielen Fehlersituationen wird die ausführliche Information zu dem vorliegenden Fehler in diese Prokolldatei geschrieben. Deshalb brauchen die Entwickler in einem Fehlerbericht häufig als erstes den Inhalt dieser Protokolldatei. (Siehe auch die englische Seite "Tracefile".)

Zum Auffinden der Protokolldatei: Sofern die Standardeinstellung nicht durch --logto <PfadName> geändert wird, wird diese an folgendem Ort angelegt:

  • Linux/BSD/*nix: /tmp/gnucash.trace
  • Windows
    • bis XP: C:\Documente und Einstellungen\MeinName\Lokale Einstellungen\Temp\gnucash.trace.XXXXXX
    • ab Vista: C:\Users\myname\AppData\Local\Temp\gnucash.trace.XXXXXX
Die Zeichenkette "XXXXXX" sind sechs zufällig wechselnde Buchstaben. Anhand des Änderungsdatum muss man jene Datei heraussuchen, die beim Auftreten des Fehlers erstellt wurde.
  • MacOS: in einem temporären Ordner unter /var/folders, welcher weder im Finder angezeigt wird, noch von Searchlight gefunden wird. :-(
find /var/folders -name gnucash.trace -exec less \{\} \;
sollte das Anzeigen ermöglichen.

Die Datei variiert stark in der Größe - wenige Zeilen oder viele Megabyte können beide vorkommen. Die Datei besteht aus einfachem Text und kann in jedem Texteditor betrachtet werden.

Falls gewünscht, kann man die Auswahl der dort protokollierten Informationen genauer einstellen. Ein Beispiel und weitere Details wie Loglevel und Module finden sich auf der englischen Seite "Logging" oder auch in der technische Dokumentation. Falls man nun das Programm immer wieder mit denselben Einstellungen starten möchte, ohne sie jedesmal auf der Befehlzeile neu eingeben zu müssen, kann man die entsprechenden Optionen auch in einer Datei ~/.gnucash/log.conf ablegen.

Aqbanking Protokolle

Sofern das Problem im Zusammenhang mit Online-Banking auftritt, siehe auch De/HBCI#Fehlersuche.

Die unkomprimierte Gnucash-Datei

Bisweilen kann es auch hilfreich sein, einen Blick in die unkomprimiert gespeicherte Gnucash-Datei zu werfen. Dafür ist vor dem Speichern unter Bearbeiten->Einstellungen->Allgemein das Häkchen bei "Datei komprimieren" zu entfernen.

Falls man vergessen hat, wo die Datei gespeichert wird, kann man das durch Öffnen des Dialogs "Datei->Speichern unter" in Erfahrung bringen.

In Fehlerberichten ist es zuweilen sinnvoll, eine möglichst kleine Beispieldatei anzuhängen, mit deren Hilfe das Problem nachvollzogen werden kann. In einigen ganz seltenen Fällen tritt aber das Problem auf, daß ein Fehler in der eigenen Datei vermutet wird, sich jedoch nicht ohne Weiteres reproduzieren läßt. Bevor man nun seine ganzen persönlichen Finanzdaten an eine relativ fremde Person weitergibt, sollte man die Daten verschleiern, ohne die Struktur der Datei zu verändern. Dazu gibt es auf der englischen Seite ObfuscateScript ein Perl-Skript, welches man auf die zu verschickende Kopie anwenden kann, um das zu bewerkstelligen. Da Perl bei Linux-Distributionen zum Lieferumfang gehört, wird für Windows-Benutzer auf die möglicherweise noch erforderliche Installation verwiesen.

Der Stacktrace

Wenn es einen Programmabsturz gegeben hat, ist die wichtigste Information für die Entwickler ein Stacktrace (auch genannt Call Stack), die Abfolge der Funktionsaufrufe im Programm. Wenn irgend möglich, sollte man bei einem Programmabsturz versuchen, diesen Stacktrace zu bekommen und mit einzuschicken. Dafür muss man GnuCash im Debugger gdb ausführen. Die Anleitung dazu steht auf der englischen Seite "Stack Trace".

Informationen des Betriebssystems

Es gibt ein paar Ursachen, die mit dem Zustand des Computers zusammenhängen und mit dessen Bordmitteln überprüft werden können:

Schreib- und Leserechte

Hier sollte man mit dem Dateimanager seiner Wahl überprüfen, ob der Benutzer Schreib- und Leserechte für

  • die Datei und
  • das Verzeichnis, in dem sie sich befindet, hat - zwecks Anlegen der Backup- und Protokolldateien.

An der Befehlszeile geht das auch mit

  • Linux: ls -al /pfad/zum/gnucash-verzeichnis
  • Windows: dir /pfad/zum/gnucash-verzeichnis

Verfügbarer Speicherplatz

Bisweilen treten Fehler auch auf, weil auf dem Speichermedium - Festplatte, USB-Stick, Netzwerklaufwerk, ... - schlichtweg kein Platz mehr ist. Auch dies kann man gewöhnlich im Dateimanager überprüfen.

Sprach- und Regionaleinstellungen

Eine weitere Fehlerquelle sind unterschiedliche Einstellungen von Sprache, Zeichensatzcodierung oder Formaten. In der Regel verfügen Betriebssyteme, Distributionen oder Desktop-Umgebungen wie GNOME oder KDE über eine Komponente Systemeinstellungen und darin ein Modul für Internationales, Sprach- und Regionaleinstellungen o.ä., um diese zu überprüfen oder zu ändern.

Ist das Problem bereits gelöst?

Anmerkung
Je nach Aufwand kann dieser Schritt auch später erfolgen.

Falls die eigene Gnucash-Version schon älter ist - aktuell ist 5.9 - sollte man zuächst sein System auf den neuesten Stand bringen.

Neben den [[[:Template:WebURL]]/download.phtml offiziellen Veröffentlichungen] gibt es auch tägliche Testversionen für

nur aktuelle Bugfixes neue Features, Bugfixes verzögert
Flatpak (Linux) flatpak/maint flatpak/master
Windows win32/maint win32/master

sofern man es nicht selber bauen (englisch) kann oder will.

Die Recherche: Ist das Problem bereits bekannt?

Da man ja nicht der einzige GnuCash-Benutzer ist, gibt es eine recht hohe Wahrscheinlichkeit, dass vor einem selbst schon jemand anderes auf das gleiche Problem gestoßen ist und unter Umständen ein – wie auch immer gearteter – Lösungsweg gefunden wurde.

Der schnelle Weg: Rückfrage im Chat

Falls man sein Problem knapp und fließend auf Englisch - manchmal sind auch Deutschsprachige anwesend, da muß man halt mal fragen - beschreiben kann, findet man im Chat auch meistens jemanden, der einem helfen kann, zu entscheiden, ob es sich wirklich um einen Programmierfehler oder ein Verständnisproblem handelt.

Wer nicht weiß, was Internet Relay Chat ist und was man dafür braucht, sollte einen Blick auf die englische Seite werfen.

Mittels Copy&Paste kann man sich ja ganz schnell auch größere Textbrocken zuwerfen. Im Chat ist das aber verpönt, da es einfach zu unübersichtlich ist. Falls man also aufgefordert wird die Konsolenausgabe oder eine Protokolldatei zu zeigen, sollte man einen Pastebin wie z.B. https://pastebin.com verwenden. Text dort hineinkopieren, Submit anklicken und den zurückgegebenen Link in den Chat kopieren, damit die anderen darauf zugreifen können.

Suche in Mailinglisten

Auch die Suche in den GnuCash-Mailinglisten mit Google oder einer anderen Suchmaschine kann hilfreich sein - wahrscheinlich ist schon jemand anderes zuvor über das Problem gestolpert. Und in der Zeit, in der Entwickler Fragen beantworten, können sie nun mal nicht entwickeln.

Da es zur Zeit - Herbst 2010 - Probleme mit dem Such-Index auf der GnuCash-Seite gibt, empfiehlt es sich die Google-Suche mit dem Parameter site:lists.gnucash.org oder in der erweiterten Google-Suche Domains Ausschließlich Antwortseiten von der Site oder Domain lists.gnucash.org zu verwenden.

Suche für Komponenten von Dritten

Für eigenständige Projekte wie

bitte deren jeweiliges System verwenden.

Suche im BugZilla

Bugzilla ist das Verzeichnis für Fehlermeldungen und Verbesserungsvorschläge. }

Seit dem 30.6.2018 betreibt das Gnucash-Team einen eigenen Server, zuvor wurde der des Gnome Projekts benutzt. GnuCash wurde dort als eigenes Produkt geführt.

Besonders, wenn man nicht die aktuellste Version verwendet, ist es sinnvoll, in einem 2. Durchgang die Einschränkungen des bug_status rauszunehmen, da der Fehler inzwischen behoben sein könnte.

Endlich: Fehler oder Verbesserungsvorschlag melden oder kommentieren

Häufig ist die Untersuchung von Fehlerberichten recht mühsam, weil der Berichterstatter für ihn selbstverständliche Informationen nicht mitliefert - Wieso, ich arbeite doch immer unter Betriebssystem XYZ, gibt's da etwa auch noch andere?. Trifft er damit auf einen gutgelaunten Freiwilligen, dann fragt der nach. Ist der selber gerade im Stress, wird die Meldung unter Umständen sogar ignoriert.

Ab Version 2.3 ist es auch hilfreich anzugeben, welches Backend verwendet wird - also was unter Datei speichern unter steht:

  • file: (XML-Datei, komprimiert oder nicht) oder
  • SQL: (MySQL/PGSQL/SQLite-Datenbank)

Daher sollte der Bericht möglichst alle der folgenden Angaben enthalten:

  • Ich benutze Gnucash Version <x.y.z> unter <Distribution> <a.b/Codename> <Betriebssystem> [<Version>] [mit Servicepack <j>] [mit den <relevante Zusatz>-Paketen aus dem Repositorium <wunderbar>] und speichere meine Daten in {[un]komprimierter XML-Datei|MySQL|PGSQL|SQLite}.
  • Wenn ich, nachdem ich <dies und das> gemacht habe, <Menü><Untermenü><Menüpunkt> öffne, <erscheinen kleine grüne Männchen>.
  • Ich hätte aber erwartet, dass <Engelchen Halleluja singen>.

Der Inhalt der <spitzen> Klammern ist dabei natürlich durch zutreffende Angaben zu ersetzen.

Zum Herausfinden der verwendeten Versionen gibt es, wie in den meisten modernen Programmen,

  • den Menüpunkt Hilfe->Über, sowie
  • die Befehlszeilenoptionen
    • -v als Abkürzung für
    • --version.

Falls man das Programm selbst gebaut hat, ist auch der Git-Hashwert oder zumindest der Zeitstempel der letzten Aktualisierung wichtig, da sich der Inhalt des Git-Repositorium ja sehr schnell ändern kann.

Oft ist es auch hilfreich, das Programm statt über das Startmenü oder eine andere Verknüpfung, direkt in einem Terminalfenster zu starten und das, was es dorthin schreibt, zu analysieren oder als Anhang mitzusenden.

In BugZilla

Bugzilla dient der Verwaltung von Fehlern und Verbesserungsvorschlägen.

Zunächst sollte man die dortige Suche verwenden, um herauszufinden, ob der Fehler schon bekannt ist.

Falls der Fehler schon bekannt ist, kann man durch weitere Kommentare die Informationen ergänzen, etwa "Der Fehler tritt nur bei abnehmendem Mond auf, nie bei zunehmendem". Damit hilft man den Entwicklern, den Fehler einzugrenzen. Am Besten ist es natürlich, gleich einen Patch einschicken. ;-)

Falls er noch nicht bekannt ist, meldet man ihn, am allerbesten auf Englisch, und zwar unter:

  • Falls für die Fehlersuche eine Gnucash-Datei eingeschickt werden soll, kann man den wirklichen Inhalt der Kopie einer unkomprimierten XML-Datei mit dem ObfuscateScript vernebeln.

Auf UserVoice

Seit Februar 2011 besteht auch die Möglichkeit, UserVoice für die Verwaltung von Verbesserungsvorschlägen zu nutzen.

Tip
Ganz unten auf der Seite kann man die Oberfläche auf Deutsch umstellen.

Auf der Mailingliste

Wer mit dem Englischen Probleme hat, kann auch auf der deutschen Mailing-Liste anfragen, ob jemand mit dem Übersetzen helfen kann. Dafür ist wegen der Spammer allerdings eine Anmeldung sinnvoll. Andernfalls landet die Mail in einer Warteschlange und muß erst von einem Moderator freigegeben werden.

Hier sollten auch Verbesserungen an spezifisch deutschsprachigen Komponenten wie Kontenrahmen und Übersetzung von Programm-Meldungen oder Dokumentationen eingereicht und diskutiert werden.

Im Betreff der Email sollte das Problem schon möglichst prägnant umrissen werden. Wer eine Email mit dem Betreff GnuCash oder Hilfe schickt, braucht sich nicht zu wundern, wenn er keine Antwort bekommt, da ein solcher Betreff niemanden vom Hocker reißt. Auch würde eine derartige Mail von Leidensgenossen desselben Problems bei der Mailinglistensuche nicht gefunden.

Antworten sollte man immer auch an die Liste - jedes Mailprogramm hat auch irgendwo im Menü verborgen Befehle wie "Allen antworten" und "An die Liste antworten". Wirklich nur ganz persönliche Nachrichten wie Einladung zum Kaffeetrinken sollten nicht an die Liste geschickt werden. Der vorherige Autor könnte nämlich nach Diktat verreist sein - dann liegt die Antwort wochenlang in seinem Posteingang rum und kein Schwein kümmert sich drum - oder andere Leute könnten noch bessere Ideen zu dem Problem haben.

Falls man sich die Gnucash-Mails täglich gebündelt zusenden läßt, ist es auch sinnvoll beim Antworten den Betreff auf die tatsächlich beantwortete Original-Mail anzupassen, also statt "Re: [gnucash-de] gnucash-de Nachrichtensammlung, Band 94, Eintrag 6" aus der betreffenden Nachricht die Subject-Zeile "Re: [gnucash-de] DTAUS" übernehmen.

Optional: Patch senden

Falls es bereits gelungen ist, das eigene Sytem zu verbessern, sind die Entwickler natürlich an einem Patch interessiert. Für diese am einfachsten zu handhaben sind

  • Pull-Requests auf GitHub, siehe Git.
  • Alternativ kann man den Patch auch an den entsprechenden Bugzilla-Eintrag hängen.
  • Das Einsenden als Anhang via Mailingliste ist im Prinzip auch möglich, birgt aber die Gefahr, daß er übersehen oder vergessen wird.
  • Direkt an einen Entwickler sollte man ihn wirklich nur nach expliziter Aufforderung senden.

Zurück zur Hauptseite

Retrieved from "https://code.gnucash.org/wiki/index.php?title=De/Feedback&oldid=15992"