Difference between revisions of "De/Feedback"
m (→Die normale GnuCash Protokoll-Datei .trace: format) |
m (→Der Stacktrace: format) |
||
Line 80: | Line 80: | ||
=== Der Stacktrace === | === Der Stacktrace === | ||
− | Wenn es einen | + | Wenn es einen Programm'''absturz''' 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 == | == Informationen des Betriebssystems == |
Revision as of 02:17, 18 February 2021
Wie man einen Fehler meldet oder einen Verbesserungsvorschlag einreicht ...
Contents
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.
Verwendete Versionen
In den meisten Fällen ist es sinnvoll, die verwendeten Versionen von GnuCash und den benutzten Hilfsprogrammen zu notieren. Die meisten davon stehen im Dialog Hilfe->Info.
Um auch die Version von Aqbanking und seiner Hilfsbibliothek Gwenhywfar anzuzeigen, nimmt man die Befehlszeile$ gnucash --version
GnuCash 3.8 development version
Build ID: git 3.8b-163-g0e6c9e219+(2020-02-19)
$ aqbanking-cli versions
Versions:
AqBanking-CLI: 6.0.1
Gwenhywfar : 5.1.2.0
AqBanking : 6.0.1.0
$ flatpak run --command=sh org.gnucash.GnuCash
[📦 org.gnucash.GnuCash ~]$ gnucash --version
GnuCash 3.8 development version
Build ID: git e6b3c56+(2020-01-26)
[📦 org.gnucash.GnuCash ~]$ aqbanking-cli versions
Versions:
AqBanking-CLI: 6.0.2
Gwenhywfar : 5.1.3.0
AqBanking : 6.0.2.0
[📦 org.gnucash.GnuCash ~]$ exit
exits
In diesem Beispiel hat der Anwender ein neueres GnuCash selbst gebaut, während AqBanking im Flatpak neuer ist als in der Distribution.
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 aufgefü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 es 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
-
- seit Vista
- C:\Users\myname\AppData\Local\Temp\gnucash.trace.XXXXXX
- bis XP
- C:\Documente und Einstellungen\MeinName\Lokale Einstellungen\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, also:
find /var/folders -name gnucash.trace -exec less \{\} \;
Falls mehrere Dateien vorhanden sind, sollte der Zeitstempel der letzten Modifikation mit dem Sitzungsende übereinstimmen.
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 jedes mal 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, dass ein Fehler in der eigenen Datei vermutet wird, sich jedoch nicht ohne Weiteres reproduzieren lässt. 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.
Netzwerkverbindung
Sofern man seine Datei nicht auf dem lokalen Rechner, sondern im Netz - LAN oder Internet - speichert, sollte man natürlich auch seine Netzwerk-Verbindung überprüfen.
Sprach- und Regionaleinstellungen
Eine weitere Fehlerquelle sind unterschiedliche Einstellungen von Sprache, Zeichensatzcodierung oder Formaten. In der Regel verfügen Betriebssysteme, 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 zunä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
- GnuCash für Android: GitHub Issues,
- die Online-Kursabfrage Finance::Quote: Request Tracker des Comprehensive Perl Archive Network oder
- das Online-Banking AqBanking, sofern klar ist, dass es nicht an Gnucash liegt,
bitte deren jeweiliges System verwenden.
Suche im BugZilla
Bugzilla ist das Verzeichnis für Fehlermeldungen und Verbesserungsvorschläge von GnuCash, egal, ob es das Programm oder die Dokumentation betrifft.
- Ausnahme
- Missstände in diesem Wiki sollten hier direkt behoben werden. Rechts oben einloggen oder - sofern noch nicht geschehen: Konto beantragen, auf Bestätigung warten - und loslegen.
- Wichtiger Hinweis
- Seit 1.7.2018 können keine neuen Fehlerberichte mehr in Gnomes Bugzilla erstellt werden. GnuCash hat seine Bugs daher in der Nacht von Freitag, dem 29. auf Samstag, den 30.06.2018 in eine selbst betriebene Instanz auf https://bugs.gnucash.org migriert.
- Alle offenen GnuCash Bugs auf https://bugzilla.gnome.org wurden dann geschlossen als RESOLVED OBSOLETE und alle, offen oder geschlossen, erhielten einen Kommentar mit ihrer neuen URL.
- Benutzerkonten einschließlich Email-Adressen wurden übertragen, aber keine Paßwörter oder Email-Beobachtungslisten. Benutzer, die sich bereits auf bugzilla.gnome.org registriert hatten, müssen daher einmalig ihr Paßwort über den Link Forgot Password rechts oben zurücksetzen. Beobachtungslisten, um dieselben Benachrichtigungen wie andere Benutzer - einschließlich der Pseudo-Benutzer aus Bugzilla#Configure Notifications - zu erhalten, müssen im
Email Preferences
-Reiter der persönlichen EinstellungenPreferences
oben auf der Seite nach dem Einloggen neu erstellt werden.
- Suche nach offenen GnuCash Bugs und Verbesserungsvorschlägen, eingeschränkt auf unspezifizerte oder Versionen >=5.0. Ältere Versionen werden nicht mehr gepflegt.
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:
- Erstelle einen neuen GnuCash Fehlerbericht oder Verbesserungsvorschlag; falls man einen Absturz berichtet, bitte hier - leider noch auf english - nachsehen, wie man einen stack trace für den Bug Report erstellt und anfügt.
- 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 muss 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ässt, 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, dass er übersehen oder vergessen wird.
- Direkt an einen Entwickler sollte man ihn wirklich nur nach expliziter Aufforderung senden.