Bemerkung: Das Original ist neuer als diese Übersetzung.
Informationen über das Fehlerverwaltungssystem für Paketbetreuer und Leute, die mit dem Sichten von Fehlern beschäftigt sind
Eingangs wird ein Fehlerbericht als
normale E-Mail-Nachricht an submit@bugs.debian.org
eingeschickt. Diese muss zwingend eine Package:
-Zeile
enthalten (Näheres unter Debian BTS –
Fehler berichten).
Der Fehler bekommt dann eine Nummer, der Einsender
erhält eine Empfangsbestätigung und die Nachricht wird an
debian-bugs-dist
weitergeleitet. Wenn die
Package
-Zeile den Namen eines Pakets mit bekanntem
Betreuer enthält,
dann erhält auch der Betreuer eine Kopie des Fehlerberichts.
Zu der Subject
-Zeile wird noch Bug#
nnn:
hinzugefügt und das Reply-To
wird so geändert, dass es beide, den Absender des Fehlerberichts und
nnn@bugs.debian.org
, enthält.
- Fehlerberichte schließen
- Folge-Nachrichten
- Schweregrad
- Markierungen für Fehlerberichte
- Aufzeichnen, dass Sie den Fehlerbericht weitergeleitet haben
- Besitzer eines Fehlers ändern
- Falsch angezeigte Paketbetreuer
- Wiedereröffnung, Neuzuweisung und Manipulation von Fehlerberichten
- Fehler abonnieren
- Das mehr oder weniger veraltete subject-scanning-Feature
- Das veraltete
X-Debian-PR: quiet
-Feature
Fehlerberichte schließen
Fehlerberichte von Debian sollten geschlossen werden, wenn das Problem behoben ist. Probleme in Paketen können nur als behoben erachtet werden, wenn das Paket, das die Fehlerbehebung enthält, das Debian-Archiv erreicht.
Üblicherweise sind die einzigen Personen, die einen Fehlerbericht schließen sollten, der Einreicher des Fehlerberichts und der/die Betreuer des Paketes, gegen das der Fehler berichtet wurde. Es gibt Ausnahmen von dieser Regel, zum Beispiel, wenn der Fehler gegen unbekannte Pakete oder gewisse generelle Pseudo-Pakete berichtet wurde. Ein Fehlerbericht kann ebenso von jedermann geschlossen werden, wenn er ein verwaistes Paket betrifft oder der Paketbetreuer vergessen hat, ihn zu schließen. In letzterem Fall ist es jedoch sehr wichitg, dass dabei die Version genannt wird, in der der Fehler behoben wurde. Falls Sie Zweifel haben, schließen Sie den Fehler nicht, sondern fragen Sie zuerst auf der Mailingliste debian-devel um Rat.
Fehlerberichte sollten geschlossen werden, indem man eine E-Mail an
nnn-done@bugs.debian.org
schickt. Der Inhalt der E-Mail
muss die Erklärung enthalten, wie der Fehler behoben wurde.
Alles, was Sie zum Schließen des Berichts tun müssen, ist eine Antwort auf
die E-Mail zu schreiben, die Sie von der Fehlerdatenbank erhalten haben, und
das To
-Feld auf
nnn-done@bugs.debian.org
ändern
(statt nnn-done
kann man auch
nnn-close
verwenden).
Wo anwendbar, geben Sie eine Version
-Zeile in den Pseudo-Kopfzeilen Ihrer Nachricht an, wenn
Sie einen Fehler schließen, so dass die Fehlerdatenbank weiß, in welcher
Veröffentlichung des Paketes die Korrektur enthalten ist.
Die Person, die den Fehler schließt, die Person, die den Fehlerbericht
verfasst hat und die debian-bugs-closed
-Mailingliste bekommen
alle eine Hinweis-E-Mail über die Änderungen im Status des Berichts. Der
Einsender und die Mailingliste erhalten ebenfalls den Inhalt der Nachricht,
die an nnn-done
geschickt wurde.
Folge-Nachrichten
Die Fehlerdatenbank wird die Adresse des Einreichers und die Fehleradresse
(nnn@bugs.debian.org
) in die Reply-To
-Kopfzeile
aufnehmen, nachdem der Fehlerbericht weitergeleitet wurde. Bitte beachten Sie,
dass dies zwei unterschiedliche Adressen sind.
Jeder Entwickler, der auf einen Fehlerbericht antworten möchte, sollte
einfach unter Respektierung der Reply-To
-Kopfzeile
auf die Nachricht antworten. Das wird den Fehlerbericht nicht
schließen.
Benutzen Sie auf keinen Fall die Allen
antworten
- oder die followup
-Funktion Ihres E-Mail-Programms, es sei
denn, Sie möchten die Liste der Empfänger anschließend selbst überarbeiten.
Achten Sie insbesondere darauf, dass Sie keine Folge-Nachrichten an
submit@bugs.debian.org
verschicken.
Nachrichten können an die folgenden Adressen geschickt werden, um in der Fehlerdatenbank abgelegt zu werden:
-
nnn
@bugs.debian.org
– solche Nachrichten werden auch an den Paketbetreuer geschickt und andebian-bugs-dist
weitergeleitet, jedoch nicht an den Einreicher; -
nnn
-submitter@bugs.debian.org
– diese Nachrichten werden auch an den Einreicher geschickt und andebian-bugs-dist
weitergeleitet, jedoch nicht an den Paketbetreuer; -
nnn
-maintonly@bugs.debian.org
– diese werden nur an den Paketbetreuer geschickt, nicht an den Einreicher oder andebian-bugs-dist
; -
nnn
-quiet@bugs.debian.org
– diese werden nur in der Fehlerdatenbank gespeichert (wie alle anderen oben erwähnten auch), aber nicht an irgendjemanden sonst weitergeleitet.
Hinsichtlich weiterer Informationen über Kopfzeilen, mittels denen ACK-Benachrichtigungen unterdrückt werden können, und darüber, wie mit Hilfe des Fehlerverwaltungssystems Kopien verschickt werden können, schauen Sie in die Anleitung zum Einreichen von Fehlerberichten.
Schweregrad
Die Fehlerdatenbank speichert zusätzlich zu jedem Fehler einen
Schweregrad. Dieser wird standardmäßig auf normal
gesetzt, was jedoch entweder durch das Hinzufügen einer
Severity
-Zeile im Pseudo-Header beim Verfassen des
Fehlerberichts (siehe Anweisungen für
Fehlerberichte) oder durch das Benutzen des severity
-Kommandos
über den Control Request Server
geändert werden kann.
Die Schweregrade:
critical
- Beschädigt Software im System, die in keinem Bezug zum fehlerhaften Paket steht (oder sogar das ganze System), oder verursacht einen ernsthaften Datenverlust oder öffnet eine neue Sicherheitslücke auf dem System, auf dem Sie das Paket installieren.
grave
- Macht das betreffende Paket (fast) unbrauchbar oder verursacht einen Datenverlust oder öffnet eine Sicherheitslücke, die es erlaubt, auf die Benutzerkonten derjenigen Benutzer zuzugreifen, die das Paket verwenden.
serious
- Ist eine ernsthafte Verletzung der Debian Policy (bedeutet ungefähr, dass
es eine
muss
- odererfordert
-Klausel verletzt) oder macht das Paket nach Meinung des Betreuers oder der Veröffentlichungsverwalter ungeeignet für eine Veröffentlichung. important
- Ein Fehler, der wesentliche Auswirkungen auf die Benutzbarkeit des Pakets hat, ohne es völlig unbrauchbar für jedermann zu machen.
normal
- Standardwert, anwendbar auf die meisten Fehler.
minor
- Ein Problem, das die Nützlichkeit des Pakets nicht beeinflusst, und das vermutlich sehr leicht zu beheben ist.
wishlist
- Für beliebige Feature-Requests, aber auch für beliebige Fehler, die aufgrund wesentlicher konzeptioneller Erwägungen sehr schwer zu beheben sind.
Bestimmte Schweregrade werden als veröffentlichungskritisch erachtet, was bedeutet, dass der Fehler einen Einfluss auf die Veröffentlichung des Paketes mit dem stabilen Release von Debian hat. Im Augenblick sind das critical, grave und serious. Die vollständigen und kanonischen Regeln, welche Probleme diese Schweregrade rechtfertigen, finden Sie in der Liste der veröffentlichungskritischen Probleme für die stabile Veröffentlichung.
Markierungen für Fehlerberichte
Jeder Fehler kann eine oder mehrere Markierungen (engl. Tags) aus einer gegebenen Menge haben. Diese Markierungen werden in der Liste der Fehler angezeigt, wenn Sie auf der Paket-Seite oder im vollständigen Fehlerprotokoll nachschauen.
Die Markierungen können durch das Einfügen einer Tags
-Zeile in
den
Pseudo-Kopfzeilen beim Abschicken des Fehlerberichts
(siehe Anweisungen für Fehlerberichte),
oder durch das Benutzen des tags
-Kommandos über den
Control Request Server gesetzt werden.
Mehrere Markierungen können Sie durch Kommata, Leerzeichen oder beides
trennen.
Die zurzeit verfügbaren Fehler-Markierungen sind:
patch
, wontfix
, moreinfo
, unreproducible
,
help
, security
, upstream
, pending
, confirmed
,
ipv6
, lfs
, d-i
, l10n
, newcomer
, a11y
, ftbfs
,
fixed-upstream
, fixed
, fixed-in-experimental
,
potato
,
woody
,
sarge
,
etch
,
lenny
,
squeeze
,
wheezy
,
jessie
,
stretch
,
buster
,
bullseye
,
bookworm
,
trixie
,
forky
,
sid
,
experimental
,
sarge-ignore
,
etch-ignore
,
lenny-ignore
,
squeeze-ignore
,
wheezy-ignore
,
jessie-ignore
,
stretch-ignore
,
buster-ignore
,
bullseye-ignore
,
bookworm-ignore
,
trixie-ignore
forky-ignore
.
Hier sind ein paar zusätzliche Informationen über die Markierungen:
patch
- Ein Patch oder eine andere leichte Prozedur, die den Fehler behebt, ist im Fehlerprotokoll enthalten. Wenn es einen Patch gibt, der jedoch den Fehler nicht hinreichend behebt, oder irgendwelche andere Probleme verursacht, dann sollte diese Markierung nicht verwendet werden.
wontfix
- Dieser Fehler wird nicht behoben. Möglicherweise weil hier eine Wahl getroffen wurde zwischen zwei beliebigen Wegen, um bestimmte Dinge zu erledigen und dabei stimmen der Paketbetreuer und der Absender des Fehlerberichts in ihrer Meinung, wie diese Dinge erledigt werden sollten, nicht überein, möglicherweise auch, weil die Änderung des Verhaltens andere, schlimmere Probleme nach sich ziehen würde oder aber auch aus anderen Gründen.
moreinfo
- Dieser Fehler kann nicht bearbeitet werden, bevor der Absender des
Fehlerberichts mehr Informationen zur Verfügung stellt. Der Fehler
wird für geschlossen erklärt, falls der Absender keine weiteren
Informationen innerhalb eines angemessenen Zeitraumes (ein paar
Monate) liefert. Das ist für Fehler der Art:
Das geht nicht
. Was geht nicht? unreproducible
- Dieser Fehler kann nicht auf dem System des Paketbetreuers reproduziert werden. In diesem Fall wird die Hilfe einer Drittpartei bei der Diagnose der Ursachen des Problems benötigt.
help
- Der Paketbetreuer ersucht um Hilfe beim Beheben des Fehlers.
Entweder hat der Betreuer nicht das nötige Wissen, um diesen Fehler
zu beheben und wünscht die Mitarbeit durch andere, oder er ist überlastet
und möchte diese Aufgabe deshalb an andere abgeben. Dieser Fehler
könnte für Anfänger unpassend sein, außer er ist zusätzlich auch
mit
newcomer
markiert. newcomer
- Für diesen Fehler existiert eine bekannte Lösung, aber der Paketbetreuer ersucht darum, dass jemand anderes diese implementiert. Dies ist eine ideale Aufgabe für Anfänger, die sich in Debian einbringen oder die ihre Fähigkeiten verbessern wollen.
pending
- Eine Lösung für dieses Problem wurde gefunden und ein repariertes Paket wird bald hochgeladen.
fixed
- Dieser Fehler wurde behoben oder es existiert ein Workaround (der
von einem Nicht-Betreuer eingereicht wurde). Es gibt jedoch immer noch
ein Randproblem, das beseitigt werden soll. Diese Markierung ersetzt den
alten Schweregrad
fixed
. security
- Dieser Fehler beschreibt ein Sicherheitsproblem in einem Paket
(z.B. falsch gesetzte Rechte, die Zugriff auf Daten erlauben, auf die
nicht zugegriffen werden sollte; Pufferüberlauf, der es den Leuten
erlaubt, das System so zu kontrollieren, wie sie es eigentlich nicht
dürften; Diensteverweigerungs-Angriffe, die behoben werden sollten, usw.).
Die meisten sicherheitsrelevanten Fehler sollten außerdem auch auf
den Schweregrad
critical
odergrave
gesetzt werden. upstream
- Dieser Fehler bezieht sich auf Programm-Code des ursprünglichen Autors.
confirmed
- Der Paketbetreuer hat den Fehlerbericht gelesen, verstanden und sieht ihn als korrekt an, hat den Fehler aber noch nicht behoben. (Die Benutzung dieser Markierung ist optional; sie ist hauptsächlich für Betreuer gedacht, die eine große Anzahl offener Fehler verwalten müssen.)
fixed-upstream
- Der Fehler wurde vom Upstream-Betreuer behoben, ist aber noch nicht im Paket enthalten (aus welchem Grund auch immer: möglicherweise ist es zu kompliziert, die Änderungen zurückzuportieren, oder der Fehler ist zu gering, um sich darüber den Kopf zu zerbrechen).
fixed-in-experimental
- Der Fehler wurde in dem Paket behoben, das in der Experimental-Distribution enthalten ist, aber noch nicht in der Unstable-Distribution.
d-i
- Dieser Fehler ist für die Entwicklung des debian-installers relevant. Diese Markierung sollte verwendet werden, wenn der Fehler die Entwicklung des Debian-Installers beeinflusst, das Paket, das davon betroffen ist, aber kein direkter Teil des Installers selbst ist.
ipv6
- Dieser Fehler beeinträchtigt die Unterstützung für das Internet-Protokoll Version 6.
lfs
- Dieser Fehler beeinträchtigt die Unterstützung großer Dateien (über 2 Gigabyte).
l10n
- Dieser Fehler ist für die Lokalisierung des Pakets relevant.
a11y
- Dieser Fehler ist bezüglich der Barrierefreiheit des Pakets relevant.
ftbfs
- Der Bau des Pakets aus dem Quellcode schlägt fehl. Wenn der Fehler einem Quellpaket zugewiesen ist, schlägt der Bau dieses Pakets fehl. Falls der Fehler einem Binärpaket zugewiesen ist, schlägt der Bau des dazugehörigen Quellpakets fehl. Diese Markierung kann auch für nicht-standardkonforme Build-Umgebungen angewandt werden (z.B. durch Verwendung von Build-Depends aus Experimental), allerdings sollte der Schweregrad in diesem Fall niedriger als serious sein (also: der Fehler ist nicht release-kritisch).
-
potato
,woody
,sarge
,etch
,lenny
,squeeze
,wheezy
,jessie
,stretch
,buster
,bullseye
,bookworm
,trixie
,forky
,sid
,experimental
- Dies sind Release-abhängige Markierungen, die zwei verschiedene Auswirkungen haben: Wenn sie für einen Fehler gesetzt werden, ist dieser Fehler nur noch für die entsprechende Veröffentlichung relevant (obwohl es möglich ist, dass er auch andere Veröffentlichungen betrifft, wenn deren Markierungen gesetzt sind), aber ansonsten gelten die normalen fehlerhaft/behoben/nicht-zutreffend-Regeln. Auch sollte dieser Fehler nicht archiviert werden, bis er in der entsprechenden Veröffentlichung behoben ist.
-
sarge-ignore
,etch-ignore
,lenny-ignore
,squeeze-ignore
,wheezy-ignore
,jessie-ignore
,stretch-ignore
,buster-ignore
,bullseye-ignore
,bookworm-ignore
,trixie-ignore
forky-ignore
- Veröffentlichungskritische Fehler mit dieser Markierung sollen zum Zwecke der Veröffentlichung des entsprechenden Releases ignoriert werden. Diese Markierung sollte nur von Veröffentlichungsleitern verwendet werden; setzen Sie sie nicht selbst ohne deren ausdrückliche Berechtigung.
Ein Wort über die Bedeutung von Distributions-spezifischen Markierungen:
die ignore
-Markierungen ignorieren
Fehler zum Zweck des Übergangs nach Testing. Die
Veröffentlichungs-Markierungen zeigen an, dass der betreffende Fehler
noch nicht archiviert werden soll, bis er in den durch die Markierungen
bezeichneten Veröffentlichungen behoben wurde. Außerdem zeigen die
Veröffentlichungs-Markierungen an, dass ein Fehler nur in den
entsprechenden Veröffentlichungen als Fehler betrachtet wird.
[Mit anderen Worten ist der Fehler in jeder Veröffentlichung
nicht vorhanden, deren korrespondierende Markierung
nicht gesetzt ist, wenn überhaupt
Veröffentlichungs-Markierungen gesetzt sind. Ansonsten gelten die
normalen found
- und fixed
-Regeln.]
Veröffentlichungs-Markierungen sollten nicht verwendet werden, wenn durch die korrekte Versionierung des Fehlers der gewünschte Effekt erreicht wird, weil sie manuell hinzugefügt und wieder gelöscht werden müssen. Wenn Sie unsicher sind, ob eine Veröffentlichungs-Markierung notwendig ist, wenden Sie sich an die Administratoren des Debian-Fehlerverwaltungssystems (owner@bugs.debian.org) oder an das Release-Team.
Aufzeichnen, dass Sie den Fehlerbericht weitergeleitet haben
Wenn ein Entwickler einen Fehlerbericht an den Entwickler des Upstream-Quellpakets, von dem das Debian-Paket abstammt, weiterleitet, dann sollte er das in der Fehlerdatenbank wie folgt vermerken:
Stellen Sie sicher, dass das To
-Feld Ihrer Nachricht an den
Autor nur die Adresse(n) des Autors/der Autoren enthält; fügen Sie die
Person, die den Fehler gemeldet hat,
nnn-forwarded@bugs.debian.org
und
nnn@bugs.debian.org
in das
CC
-Feld ein.
Bitten Sie den Autor, das CC
an
nnn-forwarded@bugs.debian.org
beim Antworten stehen zu
lassen, so dass die Fehlerdatenbank die Antwort des Autors mit dem
Originalfehlerbericht zusammen protokollieren kann. Diese Nachrichten werden
nur abgelegt und nicht weitergeleitet; um eine Nachricht normal zu senden,
schicken Sie sie auch an nnn@bugs.debian.org
.
Wenn die Fehlerdatenbank eine Nachricht an
nnn-forwarded
erhält, dann wird der
relevante Fehler als weitergeleitet markiert, die Weiterleitungsadresse
ist dann die Adresse aus dem To
-Feld der Originalnachricht,
die die Datenbank bekommt, falls der Fehler nicht bereits als weitergeleitet
markiert ist.
Sie können auch die forwarded to
-Information manipulieren, indem
Sie eine Nachricht an control@bugs.debian.org
schicken.
Besitzer eines Fehlers ändern
Wenn die Person, die für die Fehlerbehebung verantwortlich ist, nicht der zugewiesene Betreuer des Pakets ist (zum Beispiel, wenn das Paket von einer Gruppe betreut wird), kann es nützlich sein, diese Tatsache im Fehlerverwaltungssystem festzuhalten. Um dabei zu helfen, kann jeder Fehler wahlweise einen Besitzer haben.
Der Besitzer kann beim Senden eines Fehlerberichts durch eine
Owner
-Zeile in den Pseudo-Kopfzeilen festgelegt werden
(siehe die Anweisungen über das Berichten
von Fehlern) oder durch die Verwendung der Befehle
owner
und noowner
im Zusammenhang mit dem
Control Request Server.
Falsch angezeigte Paketbetreuer
Wenn ein Paketbetreuer falsch angezeigt wird, dann liegt es meistens
daran, dass sich der Paketbetreuer vor kurzem geändert hat und der neue
Betreuer es versäumt hat, eine neue Version des Pakets mit einem
abgeänderten Maintainer
-Feld in der Kontrolldatei
hochzuladen. Das wird behoben, sobald das Paket hochgeladen wird;
als Alternative können die Archivbetreuer den Betreuereintrag per Hand
ändern, zum Beispiel wenn ein neues Build oder ein erneutes Hochladen
des Pakets in nächster Zukunft nicht zu erwarten ist. Setzen Sie sich
mit override-change@debian.org
in Verbindung, um
Änderungen an der override-Datei zu veranlassen.
Wiedereröffnung, Neuzuweisung und Manipulation von Fehlerberichten
Es ist möglich, Fehlerberichte anderen Paketen zuzuweisen,
fälschlicherweise für geschlossen erklärte Fehler neu zu eröffnen, die
Information über das Ziel der Weiterleitung (falls eine existiert) eines
Fehlerberichts zu modifizieren, Schweregrade und Titel der
Berichte zu ändern, den Besitzer eines Fehlers festzulegen,
Fehlerberichte zu verschmelzen bzw. wieder auseinander zu ziehen und die
Versionen des Paketes, in der der Fehler gefunden und in der er behoben wurde,
festzuhalten. Das können Sie machen, indem Sie eine Nachricht an
control@bugs.debian.org
senden.
Das Format dieser Nachrichten ist in einem
anderen Dokument, das entweder im WWW oder in der Datei
bug-maint-mailcontrol.txt
verfügbar ist, beschrieben. Eine
Volltextversion können Sie auch durch das Senden des Wortes
help
an den oben genannten Server erhalten.
Fehler abonnieren
Die Fehlerdatenbank erlaubt denen, die Fehler berichten sowie Entwicklern
und anderen
interessierten dritten Parteien, individuelle Fehler zu abonnieren. Diese
Fähigkeit kann von Leuten verwendet werden, die ein Auge auf einen Fehler
halten wollen, ohne das gesamte Paket über den
Debian Package Tracker zu abonnieren. Alle
Nachrichten, die bei nnn@bugs.debian.org
empfangen werden,
werden an die Abonnenten geschickt.
Ein Fehler kann durch Versand einer E-Mail an
nnn-subscribe@bugs.debian.org
abonniert werden. Der
Betreff und der Textkörper der E-Mail werden vom BTS ignoriert. Sobald diese
Nachricht verarbeitet wurde, wird den Benutzern eine Bestätigung-E-Mail
zugestellt, auf die sie antworten müssen, bevor ihnen die Nachrichten, die
den Fehler betreffen, zugeschickt werden.
Es ist auch möglich, das Abonnement eines Fehlers zu beenden. Dies kann über
eine E-Mail an nnn-unsubscribe@bugs.debian.org
erfolgen. Der Betreff und der Textkörper der E-Mail werden wieder vom BTS
ignoriert. Den Benutzern wird eine Bestätigungsnachricht übersandt, die sie
beantworten müssen, um das Abonnement des Fehlers zu beenden.
Standardmäßig wird die Adresse abonniert, die in der From
-Kopfzeile gefunden wird. Falls Sie für eine andere Adresse den Fehler
abonnieren wollen, müssen Sie die Adresse, auf die der Fehler abonniert
werden soll, in die Abonnier-Nachricht kodieren. Dies erfolgt in der Form:
nnn-subscribe-
Lokalteil=
beispiel.com@bugs.debian.org
.
Dieses Beispiel würde Lokalteil@beispiel.com
eine
Abonniermeldung für Fehler nnn schicken. Das
@
-Zeichen muss durch Änderung in ein =
-Zeichen
kodiert werden. Ähnlich nimmt die Beendigung des Abonnements die Form
nnn-unsubscribe-
Lokalteil=
beispiel.com@bugs.debian.org
an.
In beiden Fällen werden der Betreff und der Textkörper der E-Mail an die
E-Mail-Adresse, die in der Anforderung einkodiert ist, im Rahmen der
Bestätigungsanfrage weitergeleitet.
Das mehr oder weniger veraltete subject-scanning-Feature
Nachrichten, die bei submit
oder bei bugs
ankommen und deren Betreffzeile mit Bug#
nnn
anfängt, werden so behandelt, als wären sie an
nnn@bugs.debian.org
geschickt worden. Das passiert, um
Abwärtskompatibilität zu den Nachrichten, die von alten Adressen
weitergeleitet wurden, zu erhalten, sowie dazu, Nachrichten abzufangen,
die irrtümlich an submit
geschickt wurden (z.B. durch das
Benutzen der Allen antworten
-Funktion des jeweiligen
E-Mailprogramms).
Ein ähnliches Schema gilt auch für maintonly
,
done
, quiet
und
forwarded
, die ankommende E-Mails mit einer Betreff-Markierung so
behandeln, als wären sie zu der entsprechenden
nnn-wasauchimmer@bugs.debian.org
-Adresse geschickt worden.
Nachrichten, die nur mit forwarded
und done
– das heißt ohne die Nummer des Fehlerberichts in der Adresse und ohne
Fehlernummer in der Betreffzeile – verschickt werden, werden unter
junk
einsortiert und
für ein paar Wochen gespeichert, ansonsten jedoch ignoriert.
Das veraltete X-Debian-PR:
quiet
-Feature
Früher war es möglich, die Fehlerdatenbank davon abzuhalten, die
Nachrichten, die es an die debian-bugs
Adresse bekam,
irgendwohin weiterzuleiten, indem man die Zeile X-Debian-PR:
quiet
in die eigentlichen E-Mail-Kopfzeilen einfügte.
Diese Kopfzeile wird nun ignoriert. Stattdessen können Sie Ihre
Nachricht an quiet
oder nnn-quiet
(oder maintonly
bzw. nnn-maintonly
)
schicken.
Weitere Seiten der Fehlerdatenbank:
- Hauptseite der Fehlerdatenbank
- Instruktionen für das Melden von Fehlern
- Zugriff auf die Fehlerberichte
- Informationen für Entwickler
- Entwickler-Informationen zur Manipulation von Fehlern mit der E-Mail-Schnittstelle
- Referenzkarte des Mailservers
- Abfragen von Fehlern per E-Mail
Debian BTS administrators <owner@bugs.debian.org>
Debian bug tracking system
Copyright © 1999 Darren O. Benham, 1997, 2003 nCipher Corporation Ltd,
1994-1997 Ian Jackson.