Vollständige Anleitung zum Melden von Fehlern in Debian Linux

Das Melden von Fehlern ist eine der vielen Möglichkeiten, wie Sie Linux beim Wachsen helfen können. Alle freien Software-Distributionen und -Projekte haben unterschiedliche Systeme, in denen Fehler gesammelt, analysiert, gekennzeichnet und behoben werden, abhängig von der Anzahl der Personen, die den Quellcode kennen.

Da ich Debian liebe, zeige ich Ihnen, wie Sie Fehlerberichte in Debian einreichen.

Wie man Fehler in Debian Linux meldet

Das Goto-Tool in Debian zum Melden von Fehlern ist Reportbug. Ich wünschte, ich hätte davon gewusst, als ich mit dem Melden von Fehlern anfing, hätte mir und dem Betreuer einiges an Sodbrennen erspart.

Mal sehen, wie wir Reportbug zum Melden von Fehlern in Debian Linux verwenden können.

Schritt 1. Bug-Installation melden

Verwenden Sie den folgenden Befehl, um Reportbug zu installieren:

sudo aptitude install reportbug

Schritt 2. Bug melden:Der erste Durchlauf

Nachdem Sie Reportbug installiert haben, müssen Sie es bei der ersten Ausführung konfigurieren, damit es zum Einreichen von Fehlerberichten verwendet werden kann.

Verwenden Sie den folgenden Befehl, um es auszuführen.

reportbug

Und dann eine Reihe von Abfragen, wie unten zu sehen ist:

	Willkommen beim Reportbug! Da es so aussieht, als ob Sie reportbug zum ersten Mal verwenden, konfigurieren wir sein Verhalten. Diese Einstellungen werden in der Datei "/home/shirish/.reportbugrc" gespeichert, die Sie weiter bearbeiten können.
	Bitte wählen Sie den Standardbetriebsmodus für Reportbug.
	1 Anfänger Bieten Sie einfache Eingabeaufforderungen an und umgehen Sie technische Fragen.
	2 standard Bieten Sie umfangreichere Eingabeaufforderungen an, einschließlich Fragen zu Dingen, die mäßig anspruchsvoll sind vom Benutzer wird erwartet, dass er über Debian Bescheid weiß.
	3 advanced Wie Standard, setzt aber voraus, dass Sie etwas mehr über Debian wissen, einschließlich "eingehend".
	4 expert Umgehen Sie die meisten Handhaltungsmaßnahmen und vorläufigen Triage-Routinen. Dieser Modus sollte nicht von Personen verwendet werden, die mit den Richtlinien und Betriebsverfahren von Debian nicht vertraut sind.
	Modus auswählen:[Anfänger] 2
	Bitte wählen Sie die Standardschnittstelle für Reportbug.
	1 text Eine textorientierte Konsolen-Benutzeroberfläche
	2 gtk2 Eine grafische (GTK+) Benutzeroberfläche.
	Schnittstelle wählen:1
	Wird reportbug oft direkten Internetzugang haben? (Sie sollten diese Frage mit Ja beantworten, es sei denn, Sie wissen, was Sie tun, und planen zu prüfen, ob über einen anderen Kanal doppelte Meldungen eingereicht wurden.) [Y|n|q|?]? n
	Welcher richtiger Name sollte zum Senden von Fehlerberichten verwendet werden?
	[shirisch]>:
	>Welche Ihrer E-Mail-Adressen soll beim Senden von Fehlerberichten verwendet werden? (Beachten Sie, dass diese Adresse im Bug-Tracking-System sichtbar sein wird, also sollten Sie vielleicht eine Webmail-Adresse oder eine andere Adresse mit guten Spam-Filterfähigkeiten verwenden.)
	[[email protected]]>[email protected]

sehen Sie sich rawreportbug-first-run.txt an, das mit ❤ von GitHub gehostet wird

Hinweise zum ersten Ausführen von Reportbug:

a. Da ich Debian schon seit geraumer Zeit verwende, kann ich zwischen 2 und 3 umschalten. Für Leute, die beim Melden von Fehlern extrem neu sind, können sie sich an [1] halten, was als Anfänger und Standard angezeigt wird, drücken Sie einfach die Eingabetaste.

b. Zwischen der Text-UI und der gtk2/3-Schnittstelle finde ich die gtk2/3-Schnittstelle unattraktiv und nimmt auch ein wenig Speicherplatz in Anspruch, daher wähle ich die ganze Zeit 1. Wenn Sie sich für den gtk2/3-Editor entschieden haben, sind die folgenden Anweisungen für Sie immer noch dieselben, nur dass Sie den gtk-Editor sehen werden, der dasselbe auf eine etwas schönere Weise zeigt.

c. Den Teil, in dem Reportbug nach Netzzugriff fragt, verweigere ich immer aus praktischen und Sicherheitsgründen. Ein bisschen mehr Erklärung für die Gründe, warum ich das tue, würde unten geteilt werden.

d. Wenn Sie schließlich nach dem Namen gefragt werden, drücken Sie die Eingabetaste, wenn Ihnen der vorhandene Name gefällt (entspricht der Variable [email protected]). Falls Sie möchten, dass es etwas anderes ist, geben Sie den Namen ein, unter dem er angezeigt werden soll.

Schritt 3. Umgang mit Gmail-Eigenheiten

Wenn Reportbug das erste Mal ausgeführt wird, fragt es nach der E-Mail-Einrichtung:

	Haben Sie einen "Mail Transport Agent" (MTA ) wie Exim, Postfix oder SSMTP, die auf diesem Computer konfiguriert sind, um E-Mails an das Internet zu senden? [y|N|q|?]?n
	Bitte geben Sie den Namen Ihres SMTP-Hosts ein. Normalerweise heißt es so etwas wie "mail.example.org" oder "smtp.example.org". Wenn Sie einen anderen Port als den Standardport verwenden müssen, verwenden Sie das alternative Format :. Drücken Sie einfach die EINGABETASTE, wenn Sie keinen haben oder nicht wissen, und so wird ein Debian-SMTP-Host verwendet.
	>
	Bitte geben Sie den Namen Ihres Proxy-Servers ein. Dieser Parameter sollte nur verwendet werden, wenn Sie sich hinter einer Firewall befinden. Das PROXY-Argument sollte als gültige HTTP-URL formatiert sein, einschließlich (falls erforderlich) einer Portnummer; zum Beispiel http://192.168.1.1:3128/. Drücken Sie einfach die EINGABETASTE, wenn Sie keine haben oder nicht wissen.
	>

siehe rawreportbug-first-run-webmail-quirks.txt, gehostet mit ❤ von GitHub

Die erste Frage ist, ob Sie eine Software haben, die es ermöglicht, E-Mails automatisch zu versenden.

Wenn Sie einen Desktop-E-Mail-Client wie Evolution oder Thunderbird eingerichtet haben, wählen Sie Ja. Sonst nein.

Sobald die Standardeinstellungsdatei geschrieben ist, wird sie unter /home/shirish/.reportbugrc gespeichert. Sie können die Konfiguration später ändern, indem Sie diese Datei bearbeiten.

Auf der Konsole können Sie STRG+C verwenden um Reportbug jederzeit zu beenden.

Schritt 5. Herausfinden eines Anwendungspaketnamens aus einer Binärdatei

Lassen Sie mich das Beispiel von Aiselriot nehmen. Es ist eines der GTK-Kartenspiele, das meine Mutter oft spielt. Nun, wenn es ein Problem mit dem Spiel gibt, wie finde ich heraus, unter welchem ​​Paket ich einen Fehlerbericht einreichen soll?

Das erste, was ich tue, wenn ich versuche, eine GUI-Anwendung zu beheben, ist, ihr Symbol zu nehmen und es auf das Bedienfeld zu legen und seine Eigenschaften zu sehen, genau wie ich es hier zeige –

Jetzt weiß ich, dass der Name der App. ist nicht Aiselriot, sondern sol und der Pfad, in dem die Anwendung abgelegt wird, ist /usr/games/sol .

Versuchen wir nun herauszufinden, wie das Paket heißt –

dpkg -S /usr/games/sol

Die Ausgabe ist:

aisleriot: /usr/games/sol

Wir haben das Glück, dass das Paket auch aiselriot heißt, aber das passiert nicht immer.

Weiter geht es mit unserem ersten Fehlerbericht. Da ich Debian testing/stretch/bald verwende, um in ein paar Monaten stabil zu sein, werde ich dort einen Fehlerbericht veröffentlichen.

Schritt 6. Mit Reportbug einen Fehlerbericht erstellen

Jetzt brauchen wir ein Paket mit einem Problem/Fehler, das wir der Debian-Community melden müssen.

Ich habe ein Paket piuparts, das Symptome eines Problems zeigte, für das ich mich an Reportbug gewandt habe, wie im Wesentlichen gezeigt:

	[$] reportbug piuparts –severity=normal
	*** Willkommen bei reportbug. Benutzen ? um Hilfe bei Eingabeaufforderungen. ***
	Hinweis:Fehlerberichte werden öffentlich archiviert (einschließlich der E-Mail-Adresse des Einsenders ).
	Erkannter Zeichensatz:UTF-8
	Bitte ändern Sie Ihr Gebietsschema, falls dies nicht korrekt ist.
	Verwendung von 'shirisch' als Absenderadresse.
	Status für piuparts wird abgerufen…
	Verifizierung der Paketintegrität…
	Wird einen Bericht an Debian senden (per lsb_release).
	Maintainer für piuparts ist das 'piuparts-Entwicklerteam'.
	Nachschlagen von Abhängigkeiten von piuparts…
	Geänderte Konfigurationsdateien werden abgerufen…
	Beschreiben Sie kurz das Problem (max. 100 Zeichen erlaubt). Dies wird der Betreff der Fehler-E-Mail sein, also halten Sie die Zusammenfassung so kurz wie möglich, z.
	Beispiel:"E-Mail kann nicht gesendet werden" oder "beginnt nicht mit - q Option angegeben" (geben Sie Strg+c ein, um reportbug zu beenden, ohne einen Fehler zu melden)
	> Angemessene Berichte obsolete-conffile für piuparts
	Umschreiben unterliegt 'piuparts:Angemessene Berichte obsolete-conffile für piuparts'?
	Führen Sie einen der folgenden Schritte auf diesen Bericht zu
	1 d-i Dieser Fehler ist relevant für die Entwicklung von debian-installer.
	2 ipv6 Dieser Fehler betrifft die Unterstützung für Internet Protocol Version 6.
	3 l10n Dieser Fehler meldet ein Lokalisierungs-/Internationalisierungsproblem.
	4 lfs Dieser Fehler betrifft die Unterstützung großer Dateien (über 2 Gigabyte).
	5 Neuling Für diesen Fehler gibt es eine bekannte Lösung, aber der Betreuer bittet jemand anderen um die Implementierung es.
	6 Patch Sie fügen einen Patch hinzu, um dieses Problem zu beheben.
	7 Upstream Dieser Fehler betrifft den Upstream-Teil des Pakets.
	8 keine
	Bitte Tags auswählen:(eins nach dem anderen) [keine]

view rawpiuparts reportbug bug-reporthosted with ❤ by GitHub

Lassen Sie mich nun erklären, wie die Dinge funktionieren. Ich verwende ein Tool namens „adäquat“ (das ein Debian-Tool zum Überprüfen von Paketen ist), wenn ich Pakete installiere. Ich werde in einem zukünftigen Blog-Beitrag ausführlich darauf eingehen.

Was Reportbug tut, ist, alle Informationen, die es über das Paket hat, zu erhalten und zu parsen, damit es weiß, ob es weitermachen soll oder nicht.

Jetzt läuft das Tool immer im Hintergrund. Eine seiner Hauptaufgaben findet ganz am Ende einer Paketinstallation statt, z. für piuparts teilt/zeigte es mir das –

adequate found packaging bugs
 -----------------------------
piuparts: obsolete-conffile /etc/piuparts/scripts/post_setup_experimental

was mir sagte, dass das piuparts-Paket ein veraltetes Conffile hatte. Conffile steht für Konfigurationsdatei.

Also ist der erste Befehl, den ich mache, wenn ich einen Fehler finde, der es wert ist, gemeldet zu werden, ich tue dies –

reportbug piuparts --severity=normal

Gibt/erzählt von dem Paket, das das Problem hat, in diesem Fall piuparts.

Es ist eine knifflige Angelegenheit, jedem Fehler Schwere zuzuweisen. Wenn ich nicht ziemlich starke Gefühle gegenüber einem Paket habe und zweifelsfrei weiß, dass der Fehler tatsächlich schwerwiegend ist, erhöhe ich den Schweregrad nicht. Das ist meine eigene persönliche Ethik, auch ein bisschen weniger Arbeit für einen Betreuer.

Abgesehen davon würden sich die meisten Betreuer einen Fehler ansehen, unabhängig davon, welchen Schweregrad Sie angeben. Ich habe Betreuer bekommen, die mir schnell geantwortet haben, selbst wenn ich Bugs auf der Wunschliste gemeldet habe und Betreuer sich nicht gemeldet haben. MIA (Missing-In-Action) auch nach dem Einreichen schwerwiegender Fehler. Das Archivieren und ein gesundes Gespräch mit dem Betreuer ist sowohl eine technische als auch eine soziale Aktivität.

Nach der Frage nach dem Betreff fragt/gibt reportbug verschiedene Optionen, wenn eine der Bedingungen zutrifft. Sie können any verwenden, wenn Sie glauben, dass Ihr Fehler betroffen ist oder eines der oben genannten Dinge auf der Liste betrifft. Wenn Sie beispielsweise einen Patch zur Behebung des Problems freigeben möchten, wählen Sie 6 oder einen der anderen aus. Wenn keiner von ihnen benötigt wird, geben Sie einfach ein und fahren Sie fort.

Sobald das obige erledigt ist, dauert es ein paar Augenblicke und wir erhalten etwas Ähnliches wie diesen gemeinsamen Kern:

	Subject:piuparts:adäquate Berichte obsoletes Conffile für piuparts
	Paket:piuparts
	Version:0.75
	Schweregrad:normal
	Sehr geehrter Betreuer,
	*** Reporter, please consider answering these questions, where appropriate ***
	* What led up to the situation?
	* What exactly did you do (or not do) that was effective (or
	ineffective)?
	* What was the outcome of this action?
	* What outcome did you expect instead?
	** End of the template – remove these template lines **
	— System Information:
	Debian Release:9.0
	APT prefers testing
	APT policy:(600, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (1, 'experimental-debug'), (1, 'experimental'), (1, 'unstable')
	Architecture:amd64 (x86_64)
	Foreign Architectures:i386
	Kernel:Linux 4.9.0-1-amd64 (SMP w/2 CPU cores)
	Locale:LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
	Shell:/bin/sh linked to /bin/dash
	Init:systemd (via /run/systemd/system)
	Versions of packages piuparts depends on:
	ii debootstrap 1.0.87
	ii debsums 2.2
	ii dpkg 1.18.18
	ii lsb-release 9.20161125
	ii lsof 4.89+dfsg-0.1
	ii piuparts-common 0.75
	ii python-debian 0.1.30
	pn python:any
	Versions of packages piuparts recommends:
	ii adequate 0.15.1
	Versions of packages piuparts suggests:
	ii schroot 1.6.10-3
	— no debconf information

view rawdefault reportbug piuparts templatehosted with ❤ by GitHub

Now what this does is, it gives an idea to the maintainer of the state of your system. As you all know, almost all GNU/Linux distributions and the packages therein are based on a complex set of relationships with other packages. The maintainer needs to know what version of the package you were using, which other packages were there, what version were they at, apart from knowing that the integrity of the package hasn’t been tampered with in any way.

Now you need to fill in the banks –

I usually remove/delete cut the following, if you are a new user you could just answer the questions below and your bug report would be ready.

Step 7. The final changes made to spend the report

And in its place, I put the details as being shared right here:

	Subject:piuparts:adequate reports obsolete conffile for piuparts
	Package:piuparts
	Version:0.75
	Severity:normal
	User:[email protected]
	Usertags:obsolete-conffile adequate
	Dear Maintainer,
	Adequate reports broken obsolete-conffile –
	[$] adequate piuparts
	piuparts:obsolete-conffile /etc/piuparts/scripts/post_setup_experimental
	Maybe you could use what pabs (Paul Wise) did in #815563, in that the
	proper thing to do would be –
	Use the dpkg-maintscript-helper support provided by dh_installdeb to remove such similar obsolete conffiles on upgrade
	Also https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
	You can also see manpage of dh_installdeb via debhelper package which is the same thing.
	I ran the same command as he did –
	[$] pkg=piuparts; adequate $pkg; dpkg-query -W -f='${Conffiles}\n' $pkg | grep obsolete
	piuparts:obsolete-conffile /etc/piuparts/scripts/post_setup_experimental
	/etc/piuparts/scripts/pre_remove_40_find_obsolete_conffiles
	dce83ee504ba336d8a2930fb6053635c
	/etc/piuparts/scripts/post_setup_experimental
	f7a1f3d45dc43106d1cd9b124b7c1ca8 obsolete
	Please fix the above.
	— System Information:
	Debian Release:9.0
	APT prefers testing
	APT policy:(600, 'testing'), (500, 'unstable-debug'), (500,
	'testing-debug'), (1, 'experimental-debug'), (1, 'experimental'), (1,
	'unstable')
	Architecture:amd64 (x86_64)
	Foreign Architectures:i386
	Kernel:Linux 4.9.0-1-amd64 (SMP w/2 CPU cores)
	Locale:LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
	Shell:/bin/sh linked to /bin/dash
	Init:systemd (via /run/systemd/system)
	Versions of packages piuparts depends on:
	ii debootstrap 1.0.87
	ii debsums 2.2
	ii dpkg 1.18.18
	ii lsb-release 9.20161125
	ii lsof 4.89+dfsg-0.1
	ii piuparts-common 0.75
	ii python-debian 0.1.30
	pn python:any
	Versions of packages piuparts recommends:
	ii adequate 0.15.1
	Versions of packages piuparts suggests:
	ii schroot 1.6.10-3
	— no debconf information

view rawgistfile1.txthosted with ❤ by GitHub

Some more info. now – These two tags signal/tell the maintainers few things –

 User: [email protected]

The first tag is signaling that the bug being raised is part of debian-qa efforts.

Usertags: obsolete-conffile adequate

The second tag is telling the tool we have used and one of the common issues under which it has come -in this case obsolete-conffile.

There are few common and uncommon use-cases that adequate looks into. As shared before, will need another blog post to share about it in detail.

The other thing I’m telling/sharing the maintainer is s/he should be looking into debhelper (a toolkit for debian/rules) and to look for specific bits therein.

Tip – Paul Wise, better known as pabs in Debian community. He is a prolific contributor to Debian. As you can see from his wiki page and the secondary apps. He always has a never-ending list of applications, packages that would be interesting to package alongwith things that could be/need to be improved. I dunno if he has done any mentoring or not, do see signs of a good and goofy mentor in him. I sometimes ask, sometimes steal his ideas to help in Debian QA :)

Now, that the bug-report is complete, I have to send it via gmail.com . If you have enabled MTA (Mail Transfer Agent) and don’t have a gmail.com you can just send and it will be done. If on the other hand, you haven’t enabled MTA (like me) and like to do things yourself, log on to your gmail account, hit compose and then –

Step 8. The final step

To - [email protected]
 Subject - piuparts: adequate reports obsolete conffile for piuparts

Body of your mail should start with Package

something like this –

You might have noticed some labels, they are just to help me be somewhat organized as after you have reported some bugs it can become chaotic to know what’s going on. Gmail’s labels and filters make things somewhat sanish with the amount of mail I receive.

At that point, make sure to recheck the mail once more before clicking the send mail button. I usually click on save draft, review it once or twice before sending it over.

If you are satisfied click send and your bug-report will be sent to Debian BTS .

Step 9. Getting acknowledgment from Debian BTS server saying the bug has reached them.

Usually, within minutes I get a short acknowledgment mail from the Debian BTS, like in the gist being shared

Look at the time-stamp given, just 3 minutes apart from when the mail was sent. I sent the bug mail on 05:03 and got the automated reply saying everything went fine on 05:06 itself.

What I look for into the acknowledgment mail is the bug number as that is how I come to know how things are going with the bug. #854317

Post bug-reporting cycle.

Coincidentally, as can be seen, the package maintainer somehow was around the time when I filed the bug. I do know the importance of piuparts in the debian ecosystem but I didn’t think Andreas will act so quickly, so now probably the next point release or even bug-fix release will have the fix. As can be seen though, Andreas seems to be a busy bee seeing the number of packages he’s maintaining/co-maintaining, besides uploading Non-Maintainer Uploads (NMU) and QA uploads.

I hope I have given enough insight so you know what to do as and when things go wrong.

Tip – Nowadays, I usually follow couple of rules before filing a bug. First check the bts for existing list of bugs, for e.g. piuparts bugs page (as also shared by Simon Tatham above). If the bug is not listed there, more often than not, it the package has not too many dependencies, and I know there aren’t any configuration files that I might have to recreate then I usually purge the package and install the package afresh. If adequate still finds a fault, I usually report it. I don’t do that though for obsolete conffiles as they usually happen when you are upgrading from version x.1 to x.2 or something like that.

Using such simple tips I save time and energy for myself as well as the maintainer of a package.

At first, it may take sometime, after a while, the whole thing may take 10-15 minutes or even less, depending on the package in which the bug is found, the bug itself, replication of the bug etc.

That’s about it to make a bug-report in Debian using Reportbug.

Hopefully, you have gotten some idea the steps to finding bugs and reporting them. Please post any queries you have in the comments below and I’ll try my best to answer/share whatever little I know.