How to Report Bugs in LibreOffice

From The Document Foundation Wiki
< QA
Jump to: navigation, search
This page is a translated version of the page QA/BugReport and the translation is 14% complete.

Outdated translations are marked like this.
Other languages:
العربية • ‎Deutsch • ‎Ελληνικά • ‎English • ‎español • ‎français • ‎galego • ‎italiano • ‎日本語 • ‎Nederlands • ‎português do Brasil • ‎русский • ‎Türkçe • ‎中文(中国大陆)‎ • ‎中文(简体)‎ • ‎中文(台灣)‎

Glad you made it here. You are about to make an important contribution to LibreOffice. A good bug report is very helpful for our developers. Below, you'll find some guidance to make this process easier.

Verbesserungsvorschläge

Verbesserungsvorschläge werden genauso wie Fehlermeldungen in Bugzilla eingereicht. Einige der im Folgenden beschriebenen Schritte bzw. Angaben bezüglich Bug Reports passen für Verbesserungsvorschläge nicht so ganz. Für diese stellt Bugzilla daher nur einen Rahmen zu Verfügung, in dem Du relativ frei bist, Deinen Vorschlag zu formulieren.

Class of Bugs Where to file the bug
LibreOffice Extensions With the extension author
TDF/LibreOffice Infrastructure (websites, mailing lists, etc.) Redmine
Building LibreOffice Developer mailing list
LibreOffice Unit Tests Developer mailing list

Bevor es losgeht

Vorab solltest Du einige Fragen geklärt haben:

Ist Dein Problem überhaupt ein Fehler?

Falls Du nicht sicher bist, ob Dein Problem überhaupt ein Fehler ist, solltest Du eine Anfrage an die discuss-Mailingliste schicken. Falls Deine Anfrage dort nicht geklärt wird, kannst Du es auch auf der user-Mailingliste oder bei Ask LibreOffice probieren. Auch eine Anfrage an eines der Foren kann möglicherweise hilfreich sein.

Confirm that it really is a bug. Most of the time, a bug is something that makes the software behave in a way that a reasonable user would not want it to behave. This includes the software not doing what you want it to do, doing what you never asked it to do, or just plain crashing under normal use. Going behind the scenes, a bug may be something that causes the software to take a lot longer and use a lot more resources doing stuff than it should.

Sind alle Fehler in Bugzilla zu melden?

Nein! Fehler in den deutschen Texten der LibreOffice-Benutzeroberfläche und in der Hilfe können an die discuss-Mailingliste gemeldet werden. In der Regel können Sie dann 'auf dem kurzen Dienstweg' korrigiert werden. Alle anderen Fehler sind aber per Bug Report in Bugzilla zu melden.

At a certain point what look like bugs are actually more like feature requests, where we know how the software should work in an ideal world, even though the feature we want hasn't been built yet. Fortunately, you don't have to worry that much about separating bugs from feature requests. If it's something that interferes with normal, valid use of the application, report it as a bug.

It helps a lot if you know your way around LibreOffice, though, so you have a good sense of what normal, valid use is. You don’t want to spend a lot of time reporting what you think are bugs when the issue is that you don’t know how to use a certain feature yet. Consider reading the user documentation, and use the apps a lot so you become familiar with what they normally do.

If you know LibreOffice fairly well and run into something that may be a bug, but may be just something you don’t understand, you can post a question at LibreOffice Users Mailing List or Ask LibreOffice.

But let’s say what you found really does look like a bug. Here’s what to do next:

Bug Report auf Englisch?

Jein! Da die Entwickler und Qualitätssicherer von LibreOffice auf der ganzen Welt zu finden sind, ist es leider notwendig, den Bug Report auf Englisch zu erstellen. Es gibt auch die Möglichkeit einen deutschen Fehlerbericht per Mail zu erstellen und einzureichen. Es ist aber z.Z. nicht sichergestellt, dass er weiterbearbeitet, d.h. übersetzt und in Bugzilla eingestellt wird.

Ist der Fehler reproduzierbar?

Damit der Fehler korrigiert werden kann, ist es wichtig, dass er reproduziert werden kann. Wenn Du unsicher bist, ob dies der Fall, kannst Du Dich ebenfalls an die discuss-Mailingliste wenden und darum bitten, dass ein Mitleser dieser Liste versucht, den Fehler zu reproduzieren.

Nur optional: Ist der Fehler bereits gemeldet worden?

Fehler werden oft mehrfach in Bugzilla gemeldet. Dies bedeutet für die Qualitätssicherer zusätzlichen Aufwand, um diese sogenannten 'Duplicates' zu finden und zu verwalten. Du kannst es denen etwas erleichtern, in dem Du selber in Bugzilla nach 'Deinem' Fehler suchst. Falls der Fehler bereits gemeldet wurde, ist es natürlich nicht mehr notwendig, ihn nochmal zu melden. Möglicherweise kannst Du aber hilfreiche Ergänzungen oder den Fehler für bestimmte LibreOffice-Versionen oder Betriebssysteme bestätigen. Du kannst Dich auch bei diesem Bug unter CC eintragen. Du erhältst dann immer, wenn es Neuigkeiten zum Bug gibt, eine E-Mail-Nachricht.

Nur optional: Ist der Fehler in der aktuellsten Version noch vorhanden?

Oftmals sind Fehler in neueren Versionen bereits behoben worden. Ein zusätzlicher Bug Report macht in solch einem Fall natürlich keinen Sinn mehr. Wenn Du den Bug nicht in der aktuellsten Version aus der neuesten Entwicklungsreihe festgestellt hast, wäre es wünschenswert, dass Du 'Deinen' Bug mit der aktuellsten Version überprüfst. Auch dieses entlastet die Qualitätssicherer.

    1. If you selected Extended Help: select the appropriate subcomponent, or the [1] at the bottom of the list if you did not find or do not know the appropriate subcomponent.
    2. You will see a list of bugs with that subcomponent. At the bottom of the page, select Edit Search. There, you can modify the search according to your needs.
    3. If you find a bug report that concerns your problem, you can contribute to it. If you don’t find a bug report that concerns your problem, file a new bug report.
  1. If the bug only occurs on Ubuntu or is related to printing, go to #More Information.
  2. After all that, if it does not look like there is a bug report about this issue, follow the instructions at #Submitting a bug.

Deinen Fehler melden

Um einen Fehler zu melden, hast Du 2 Möglichkeiten:

  • Erstellung des Bug Report direkt in Bugzilla.
  • Erstellung eines Fehlerberichts auf Deutsch als Mail an die deutschsprachige Discuss-Mailing-Liste.

Beides wird im Folgenden beschrieben.

File a separate bug report for each bug you run into, even if the symptoms from a user’s point of view seem identical. Different problems with different roots that appeared in different LibO versions might have to be fixed by different people, for different versions, and at different times. It is impossible to track that in a single bug report.

Go to Bugzilla.

Einen Fehler direkt in Bugzilla melden

Startseite von Bugzilla: https://bugs.documentfoundation.org

If you are prompted to sign in, log in with your Bugzilla account.

Component

In Component, choose the component.

Wichtige Tipps und Hinweise:

  • Einen Fehler pro Fehlerbericht: Falls Du mehrere Fehler melden möchtest, schreibe bitte für jeden Fehler einen getrennten Bericht, auch wenn Du meinst, dass sie miteinander in Verbindung stehen. Du kannst dann später in der Beschreibung auf den jeweilig anderen Fehler hinweisen.
  • Sprache der Benutzeroberfläche: In vielen Fällen wird es notwendig sein, Begriffe der Benutzeroberfläche in den Bug Reports zu verwenden. Hierfür sollten die Begriffe aus der englischen Oberfläche benutzt werden. Es ist daher notwendig, auf die englische Benutzeroberfläche umzuschalten. Dies erfolgt in den Optionen: Menü: Extras > Optionen... > Spracheinstellungen > Sprachen > Sprache für > Benutzeroberfläche“. Damit diese Änderung wirksam wird, ist es notwendig, LibreOffice zu beenden und neu zu starten.

If there is a Sub-component section, select the subcomponent.

  • Automatische Übersetzungen: Verwende bitte keine automatischen Übersetzungen (z.B. Google Translator), da diese in der Regel unverständlich sind.
  • Benutzereingaben beschreiben: Um die Reihenfolge von Eingaben zu beschreiben, hat sich die Nutzung des Zeichens ">" bewährt. Beispiel: "From the Menu select: File > Open > File Type: Text documents > Double Click on example document"

Account für Bugzilla einrichten

Um überhaupt einen Fehler zu melden, benötigst Du einen Account (Konto) für Bugzilla:

  • Klicke dafür auf „New Account“. Auf der folgenden Seite musst Du nur Deine E-Mail-Adresse eingeben.
  • Du erhältst eine E-Mail an die angegebene Adresse, klicke dort auf den angegebenen Link. Im Browser wird die Bugzilla-Anmeldeseite geöffnet.
  • Optional kannst Du dort Deinen echten Namen angeben, ein Passwort musst Du hingegen angeben. Nach einem Klick auf „Create" solltest Du direkt eine Bestätigung erhalten, dass der Account eingerichtet worden ist.

Schritt 1: Anmelden (Log In)

Klicke auf „Log In“ und melde Dich mit Deiner E-Mail-Adresse, die Du bei der Anmeldung angegeben hast, und Deinem Passwort an.

Schritt 2: Eingabe eines neuen Bugs starten

Check in possibly related Bugs table on the bug-reporting page and additionally in the Duplicates Table to see whether the problem really has not been reported yet.

Klicke auf „File a Bug“ oder auf „New“. Die Produktauswahl-Seite wird angezeigt. Wähle das Produkt aus, zu der Du einen Fehler melden möchtest (in der Regel "LibreOffice"). Die Eingabemaske für das gewählte Projekt wird angezeigt.

    • If the subcomponent can be confused with parts of a word (for example, UI is part of the word quit), surround the subcomponent with square brackets.
    • Use at most two subcomponents.
    • Use subcomponents exactly as they appear in the list, but you may integrate them into the subject line sentence like “WIKIHELP [UI] not available in all languages”.
  • Summarize the problem fairly precisely.
    • bad example: “File is broken”
    • better example: “Menu File > Save as not available (greyed out)”
  • Avoid short forms like “doesn’t” or “isn’t” to ease queries for strings in the Summary; instead, use the full form, such as “does not” or “is not”.
  • If the problem written in the report is that LibreOffice crashes or stops responding (“hangs”), add the word CRASH to the Summary, so that these bugs can be located and tracked easily.

Schritt 3: Standard-Daten zum Bug eingeben

In the Long Description or Description section, give a lengthier, factual description of the problem:

In der Maske gibt es einige Standardfelder, die Du entweder ausfüllen bzw. in denen Du eine Angabe aus einer Liste auswählen musst:

Component: Der Begriff „Component“ ist hier nicht ganz wörtlich zu nehmen. Hier werden damit bestimmte Bereiche der Software unterschieden. Wähle die Komponente aus der Liste aus, die am Besten zu Deinem Bug passt. Wenn Du eine Komponente anklickst, wird rechts daneben eine kurze Erklärung für die jeweilige Komponente angezeigt. Ggf. kannst Du die Komponente korrigieren. Eine deutsche Beschreibung der Komponenten findest Du auf der Seite Detailinfos.

Version: Wähle hier einfach die LibreOffice-Version aus, bei der der Fehler auftritt. Die genaue Versionsbezeichnung findest Du im Menü unter: „Hilfe > Info zu LibreOffice“. Manchmal ist die angebotene Liste nicht ganz aktuell. Wähle dann einfach die nächstältere Version aus und weise in der Beschreibung auf die richtige Version hin. Wenn Du weißt, dass der Fehler in mehreren Versionen vorhanden ist, kannst Du auch die älteste Version angeben und später in der Beschreibung auf die anderen Versionen hinweisen.

Summary: Trage hier eine kurze, möglichst prägnante Beschreibung (so ca. max. ein Satz) des Fehlers ein. Der hier eingetragene Text wird beispielsweise angezeigt, wenn man die Fehler in Bugzilla nach bestimmten Kriterien durchsucht.

  • If you want to attach more than one screenshot, you should collect them all in one document (copy / paste to a LibreOffice Draw document) and attach as a PDF. Please add a short comment to each screenshot to tell what you want to demonstrate with it.
  • If you attach a sample document that exhibits the bug you are reporting, please make the document as minimal as possible. For example, for Writer bugs, the document should ideally have just a single paragraph. To make it easy to find the text from your document in debug tracing, use some very easily recognizable text, like AAAAAAAAAA ₂ ZZZZZZZZZZ for a bug that is triggered by that character.
  • It is preferable to upload attachments individually. However, if you want to attach more than half a dozen documents, create a .zip file containing all documents and attach that .zip.
  • If your attachment is too big to be attached in Bugzilla (bigger than 1 MB) you can use the Experimental upload page.

Severity (nur optional): Die Standard-Angabe ist „normal“. Diese Angabe solltest Du beibehalten, es sei denn Du möchtest explizit einen Verbesserungsvorschlag machen, dann solltest Du „enhancement“ wählen. Die endgültige Bewertung erfolgt später durch ein Mitglied der Qualitätssicherung, wenn Dein Bug geprüft wird.

The only time you should change the status to NEW is, if someone already confirmed the bug elsewhere (Ask, mailing list, some forum). In these cases, provide a link to the discussion with the confirmation.

Hardware (nur optional): Die Standard-Angabe ist „Other“. Diese Angabe solltest Du so belassen.

Click Submit, and your report will be added to the Bugzilla database.

OS (optional): Wähle hier das von Dir verwendete Betriebssystem aus.

If the Bugzilla bug tracking system seems daunting or too hard to understand, you should post your problem here:

Schritt 4: Fehlerbeschreibung (Description)

In der Beschreibung ist es wichtig einen aussagekräftigen, aber keinen ausufernden Bericht zu erstellen. Das Wichtigste dabei ist, dass ein Anderer den Bug auch reproduzieren kann. In der Regel sollte Folgendes in die Beschreibung aufgenommen werden: Schritt-für-Schritt-Beschreibung: Für die Reproduzierbarkeit eignet sich am Besten eine Schritt-für-Schritt-Beschreibung. Manchmal kann es notwendig sein, dabei wirklich jeder Tastendruck und jeden Mausklick aufzuführen. Beobachtetes Verhalten: Beschreibe das fehlerhafte Verhalten möglichst detailliert, so dass ein Leser versteht, was Du als falsch ansiehst. Erwartetes Verhalten: Bitte beschreibe möglichst genau und konkret, was Du als korrektes Verhalten erwartest.

Schritt 5: Anhänge (Attachments, optional)

Eine Beispieldatei oder ein Screenshot erklären manchmal mehr als tausend Worte. Wenn Du auf „Add an attachment“ klickst, und dann auf „Durchsuchen“ (Weiß der Himmel, warum dieser Button auf mal deutsch beschriftet ist.), kannst Du eine Datei von Deinem Rechner nach Bugzilla hochladen. Unter „Description“ solltest Du dann noch einen kurzen Kommentar hinterlassen, um was es sich bei der Datei handelt. Weitere Anhänge kannst Du hinzufügen, nach dem Du den Bug eingereicht hast (Schritt 6).

Schritt 6: Bug einreichen (Submit)

Am Ende wird der Bug mit einem Klick auf „Submit“ eingereicht. Am Besten Du prüfst vorher noch mal, ob Dein Bericht vollständig und korrekt ist. Nach „Submit“ erhält Dein Fehler eine Nummer und der Bericht wird in der Bug-Standard-Anzeige von Bugzilla angezeigt. Der Fehler erhält zunächst den Status UNCONFIRMED.

Was passiert danach?

Informationen zum Ablauf wie ein Bug bearbeitet wird, findest Du auf der Seite Bugzilla. Nur soviel soll hier gesagt werden, dass Du zu allen Änderungen am Bug Report per E-Mail benachrichtigt wirst. Es kann sein, dass es noch Fragen an Dich gibt, die Du dann auch, natürlich nur so weit es Dir möglich ist, beantworten solltest. In diesem Fall bekommt der Fehler den Status NEEDINFO. Wenn Du die Frage(n) beantwortest hast, setze den Status auf den vorherigen Status (in der Regel UNCONFIRMED) zurück. Du kannst auch unabhängig von Fragen jederzeit weitere Kommentare "Deinem" Bug hinzufügen, weil Du z.B. neue Erkenntnisse zum Bug hast.

Einen Fehlerbericht an die deutsche Mailing-Liste schicken

Falls Du aufgrund fehlender Englischkenntnisse oder falls es Dir zu aufwändig ist, einen englischen Fehlerbericht zu schreiben, kannst Du einen Fehlerbericht an die deutsche Discuss-Mailing-Liste (discuss@de.libreoffice.org) schicken. Es ist dann aber nicht sichergestellt, dass sich jemand 'Deines' Fehler annimmt, da die meisten Teilnehmer dort ehrenamtlich tätig sind. Falls dies der Fall ist, kannst Du es später - nach einigen Tage oder wenigen Wochen - noch einmal probieren. Vielleicht findes sich dann jemand.

  • ACHTUNG: Alles, was Du in Mails an Mailing-Listen schreibst, ist unwiderruflich öffentlich zugänglich. Auch Deine E-Mail-Adresse selbst gehört dazu.
  • WICHTIG: Falls jemand auf Deinen Bericht antwortet, wird sie/er diese Mail in der Regel an die Mailing-Liste schicken und nicht an Dich selber. Damit Du bei Bedarf antworten kannst, solltest Du Dich entweder zumindest temporär bei der Mailing-Liste anmelden oder in den Tagen nachdem Du deinen Fehlerbericht geschickt hast, in den Mail-Archiven nachschauen, ob es Antworten zu Deinem Bericht gibt.

Ideal wäre es, wenn in Deinem Fehlerbericht folgende Informationen enthalten sind. Aber auch wenn etwas fehlt, ist es oftmals möglich, Dein Problem zu reproduzieren:

  1. Komponente: Eine Liste der möglichen Komponenten findest Du hier.
  2. Dein Betriebssystem (Version, Sprache, gegebenenfalls Distribution)
  3. Deine genaue LibreOffice-Version: Einfach aus Hilfe ▸ Info Über LibreOffice kopieren, beispielsweise "LibreOffice 4.2.5.2". Wenn Du eine Testversion verwendest, bitte auch die Build-ID (z.B.: dc9775d-05ecbee-0851ad3-1586698-727bf66") mit angeben.
  4. Letzte Version ohne Fehler: Falls Dir bekannt ist, dass der Fehler in einer früheren Version nicht vorhanden war, gib hier bitte die Version(en) an, in der der Fehler noch nicht auftrat.
  5. Gewählte Sprache der Benutzeroberfläche
  6. Fehler-Kurzbeschreibung: 1-Zeilige stichwortartige, aussagekräftige Beschreibung des Problems
  7. Schritt-für-Schritt-Anleitung: Für die Reproduzierbarkeit eignet sich am Besten eine Schritt-für-Schritt-Beschreibung. Manchmal kann es notwendig sein, dabei wirklich jeder Tastendruck und jeden Mausklick aufzuführen.
  8. Beobachtetes Verhalten: Beschreibe hier das fehlerhafte Verhalten möglichst genau und detailliert, so dass ein Leser es auch nachvollziehen kann.
  9. Erwartetes korrektes Verhalten: Bitte beschreibe hier möglichst genau und konkret, was Du als korrektes Verhalten erwartest.
  10. URL-Adresse/n für Anhang/Anhänge (optional): Eine Beispieldatei oder ein Screenshot erklären manchmal mehr als tausend Worte. Anhänge von Mails an die Mailing-Listen werden nicht weitergeleitet. Wenn Du Deiner Fehlermeldung also eine Datei hinzufügen möchtest, musst Du sie an eine öffentliche Stelle im Internet hochladen und den Link in Deinem Bericht angeben. Du kannst auch mehrere Anhänge hinzufügen.
  11. Dateiinhalt/e (optional): Gib hier kurz an, was die beigefügte/n Datei/en enthält/enthalten.
  12. Ergänzungen (optional): Du bist hier frei, weitere Angaben zu machen, z.B. zu bestimmten Randbedingunen oder auch warum der Fehler für Dich besonders ärgerlich. Verzichte hier aber bitte auf all zu weitschweifende Erläuterungen. Gegebenenfalls kann ja noch mal nachgefragt werden.

Dieser Link öffnet Dein Standard-E-Mailprogramm für eine neue Mail mit den oben aufgeführten Punkten. Bitte ergänze die einzelnen Punkte und schick dann die Mail ab. Falls Du kein E-Mail-Programm nutzt, kannst Du einfach den folgenden Text in eine neue Mail kopieren: Bug Report: (1) Komponente: (2) Mein Betriebssystem: (3) Meine LibreOffice-Version: (4) Letzte Version ohne Fehler (optional): (5) Sprache der Benutzeroberfläche: deutsch (6) Fehler-Kurzbeschreibung: (7) Schritte, wie das Problem reproduziert werden kann: (8) Beobachtetes Verhalten: (9) Erwartetes Verhalten: (10) URL-Adresse/n für Anhang/Anhänge (optional): (11) Dateiinhalt/e (optional): (12) Ergänzungen (optional): (13) E-Mail-Adresse für Rückfragen:

LibreOffice-Fehler in Linux-Distibrutionen melden

If nobody has reviewed your report within an appropriate time (24 hours for a critical bug, 14 days for an enhancement request), consider asking someone else to reproduce your bug report on the users@global.libreoffice.org mailing list or IRC channel #libreoffice connect via webchat.

Falls Du eine LibreOffice-Version aus Deiner Linux-Distribution verwendest, kannst Du Fehler auch im Bugtracker der jeweiligen Distribution melden:

  • Avoid posting “me too” comments which contain no additionally useful information.
    The exception to this is when you comment on a bug that has been UNCONFIRMED so far. In that case, please provide reproduction steps (or confirm the ones given by the original reporter) and move the issue to status NEW. Note that if there are no clear reproduction steps, the issue might quickly move back to NEEDINFO, so finding a good and simple reproduction scenario is essential.
  • Refrain from adding comments along the line of “we have 1000 seats here and only this bug prevents us from migrating”, as it contains no additional information relevant to QA or to the priority of the issue.

Eine zusätzliche Fehlermeldung im LibreOffice-Bugzilla ist hilfreich, da solche "Upstream Meldungen" dann für andere LibreOffice-Versionen geprüft und ggf. auch behoben werden können.

Debug Informationen beim Absturz/Hängenbleiben

Minimum requirements

  1. OS/LibreOffice version;
  2. enumerated reproducible steps;
  3. simple attachments where appropriate; and
  4. observed/expected results.

Für den Fall, dass LibreOffice abstürzt (crashed) oder hängen bleibt, kann es sinnvoll sein, sogenannte Debug-Informationen zu erzeugen und diese dem Bug Report als Anhang hinzuzufügen. Wenn Dein Bug von der Qualitätssicherung nachvollzogen werden kann, brauchst Du Dich nicht darum zu kümmern. Anders sieht es aus, wenn Dein Bug nicht reproduziert werden kann. In diesem Fall kann es sein, dass Du im Bug Report gebeten wirst, Debug-Informationen zu erzeugen. Das Vorgehen dafür ist recht komplex, Du musst letztendlich selber entscheiden, ob Du Dich daranwagen willst. Für jedes Betriebssystem ist das Vorgehen unterschiedlich:

  • tdf#85004 - Writer: Crash when clicking the Reminder icon on the Navigation toolbar
  • tdf#87907 - DIALOG: Page preview in print dialog refreshes when opening print details
  • tdf#74839 - EDITING: Position of connectors connected to a group aren't updated when editing group content

Reports can be less than ideal for a number of reasons. Below are some of the common problems:

Describing a bug report in paragraphs of text is one of the most common problems. Developers do not have the time to read paragraphs of text. Clear, succinct, enumerated steps are always better.

One Report, Five Bugs

One report should only have a single bug in it. Grouping bugs, or listing a whole list of issues with a single document, is utterly unhelpful. In order to find developers to tackle issues, it is best to give them a single issue to focus on. They are unlikely to take on a bug that has multiple issues listed

Missing Details/Steps

All bug reports should have at minimum:

  1. your Operating System and version of LibreOffice;
  2. clear reproducible steps;
  3. expected results;
  4. observed results; and
  5. a simple attachment where appropriate.

Adding Superfluous Information

Adding a lot of extra details that aren’t relevant is another common problem. Examples include:

  1. “this is a blocker”;
  2. a long list of reasons why it’s a blocker;
  3. “I can’t use LibreOffice because of this bug”;
  4. “LibreOffice sucks” (or any variation of that); and
  5. I’m going to start using your competitor unless you fix it.

Complex Attachments

Attachments should be as simple as possible. Take the time to prune your examples to the bare minimum. This helps tremendously in diagnosing problems.

Assuming Contributors Know Everything

Do not assume contributors know what you’re talking about. Describe your steps clearly, each step of the way.

More Information