Manpages

BEZEICHNUNG

bts - Befehlszeilenschnittstelle der Entwickler zum Debian Bug Tracking System

ÜBERSICHT

bts [Optionen] Befehl [Argumente] [#Kommentar] [.|, Befehl [Argumente] [#Kommentar]] …

BESCHREIBUNG

Dies ist eine Befehlszeilenschnittstelle zur Debian-Fehlerdatenbank ( BTS ), die hauptsächlich für den Gebrauch durch Entwickler gedacht ist. Sie ermöglicht die Manipulation des BTS durch einfache Befehle, die an der Eingabeaufforderung oder in einem Skript ausgeführt werden können, führt verschiedene Plausibilitätsprüfungen der Eingabe durch und konstruiert und sendet E-Mails für Sie an die BTS-Steueradresse. Außerdem kann ein lokaler Zwischenspeicher von Webseiten und E-Mails vom BTS erzeugt und aktualisiert werden.

Im Allgemeinen ist die Befehlszeilenschnittstelle das, was Sie in einer Mail an control [AT] bugs.org schreiben würden, nur mit vorangestelltem »bts«. Zum Beispiel:

% bts severity 69042 normal
% bts merge 69042 43233
% bts retitle 69042 blah blah

Für Ihren Komfort wurden ein paar zusätzliche Befehle hinzugefügt und dieses Programm ist ist weniger strikt in dem, was eine gültige Fehlernummer darstellt. Beispielsweise wird »severity Bug#85942 normal« wie auch »severity #85942 normal« verstanden. (Allerdings könnte Ihre Shell »#« als Kommentarzeichen ansehen, weswegen Sie es maskieren müssen!)

Außerdem ermöglicht Ihnen dieses Programm zu Ihrer Annehmlichkeit Befehle auf die kleinste eindeutige Teilzeichenkette abzukürzen (ähnlich wie Sie CVS Befehle abkürzen lässt). So versteht es Dinge wie »bts cl 85942«.

Es ist ebenfalls möglich, der E-Mail an das BTS einen Kommentar beizufügen. Falls Ihre Shell nicht den Kommentar in einem Befehl wie »bts severity 30321 normal #inflated severity« streicht, dann ist dieses Programm schlau genug herauszufinden, wo der Kommentar ist und ihn in die E-Mail einzufügen. Beachten Sie, dass die meisten Shells solche Kommentare streichen, bevor sie beim Programm ankommen, es sei denn, der Kommentar ist maskiert. (Etwas wie »bts severity #85942 normal« wird nicht als Kommentar angesehen!)

Sie können mehrere Befehle angeben, indem Sie sie durch einen einzelnen Punkt trennen, ungefähr wie update-rc.d; ein einzelnes Komma könnte auch benutzt werden; alle die Befehle werden in einer einzigen E-Mail gesandt. Es ist wichtig, dass der Punkt/das Komma von Leerzeichen umgeben ist, damit es nicht als Teil des Befehls missverstanden wird. Zum Beispiel (wo nötig maskieren, so dass bts den Kommentar sieht):

% bts severity 95672 normal , merge 95672 95673 \#sie sind identisch!

Die Abkürzung »it« könnte benutzt werden, um auf die zuletzt erwähnte Fehlernummer Bezug zu nehmen, daher können Sie schreiben:

% bts severity 95672 wishlist , retitle it "bts: please add a --foo option"

Bitte benutzen Sie dieses Programm verantwortungsvoll und berücksichtigen Sie unsere Benutzer.

OPTIONEN

bts durchsucht die devscripts-Konfigurationsdateien wie oben beschrieben. Befehlszeilenoptionen setzen jedoch die Einstellungen der Konfigurationsdatei außer Kr.
-o, --offline

sorgt dafür, dass bts zwischengespeicherte Fehler für die Befehle show und bugs benutzt, falls für die angeforderten Daten ein Zwischenspeicher verfügbar ist. Im Nachstehenden finden Sie Informationen zum Befehl cache, wie Sie einen Zwischenspeicher einrichten.

--online, --no-offline

Gegenteil von --offline; setzt alle Konfigurationsdatei-Direktiven außer Kraft, um offline zu arbeiten

-n, --no-action

sendet keine E-Mails, gibt sie aber auf der Standardausgabe aus.

--cache, --no-cache

Soll versucht werden, neue Versionen der BTS-Seiten bei der Ausführung der Befehle show/bugs zwischenzuspeichern? Vorgabe ist Zwischenspeicherung.

--cache-mode={min|mbox|full}

Soll nur der reine Fehler (min) oder auch die Mbox-Version (mbox) wiedergegeben werden oder soll das ganze Ding, einschließlich der Mbox, den langweiligen Anhängen an die BTS-Fehlerseiten und die Bestätigungs-E-Mails (full) wiedergegeben werden, wenn ein bts cache-Befehl ausgeführt wird? Vorgabe ist min.

--cache-delay=Sekunden

Zeit in Sekunden, die zwischen jedem Herunterladen gewartet wird, um zu verhindern, dass auf den BTS-Webserver eingehämmert wird. Vorgabe ist fünf Sekunden.

--mbox

öffnet ein E-Mail-Programm, um die Mbox zu lesen, die zu einer gegebenen Fehlernummer für show- und bugs-Befehle gehört.

--mailreader=E-MAIL-PROGRAMM

gibt den Befehl zum Lesen der Mbox an; muss eine »%s«-Zeichenkette (ohne Anführungszeichen) enthalten, die durch den Namen der Mbox-Datei ersetzt wird. Der Befehl wird bei Leerzeichen getrennt und nicht an eine Shell übergeben. Vorgabe ist »mutt -f %s«. (Außerdem wird %% durch ein einzelnes % ersetzt, falls dies nötig ist.)

--cc-addr= CC_E-MAIL_ADRESSE

Send carbon copies to a list of users. CC_EMAIL_ADDRESS should be a comma-separated list of email addresses. Multiple options add more CCs.

--use-default-cc

fügt die in der Konfigurationsdateioption BTS_DEFAULT_CC angegebenen Adressen der Liste hinzu, die mittels --cc-addr angegeben wurde. Dies ist die Vorgabe.

--no-use-default-cc

fügt der Liste der Kopien keine in BTS_DEFAULT_CC angegebenen Adressen hinzu.

--sendmail=SENDMAIL-BEFEHL

gibt den sendmail-Befehl an. Der Befehl wird bei Leerzeichen getrennt und nicht an eine Shell übergeben. Vorgabe ist /usr/sbin/sendmail. Die Option -t wird automatisch hinzugefügt, falls der Befehl /usr/sbin/sendmail oder /usr/sbin/exim* lautet. Für andere E-Mail-Programme muss dies, falls sie eine -t-Option benötigen, in den SENDMAIL-BEFEHL eingefügt werden, zum Beispiel: --sendmail="/usr/sbin/mymailer -t".

--mutt

benutzt mutt für den Versand von E-Mails. Standardmäßig wird mutt nicht benutzt, außer für einige Befehle.

Beachten Sie, dass $DEBEMAIL oder $EMAIL in der Umgebung gesetzt sein müssen, um mutt zum Senden von E-Mails zu verwenden.

--no-mutt

benutzt mutt nicht für den Versand von E-Mails.

--soap-timeout= SEKUNDEN

gibt eine Zeitüberschreitung für SOAP-Aufrufe an, wie sie durch die Befehle select und status benutzt wird.

--smtp-host= SMTPHOST

gibt einen SMTP-Rechner an. Falls angegeben wird bts E-Mails versenden, indem es direkt mit diesem Rechner kommuniziert, statt den sendmail-Befehl aufzurufen.

Dem Rechnername könnte ein Doppelpunkt (»:«) und eine Port-Nummer folgen, um einen anderen Port als den vorgegebenen zu benutzen, Er könnte außerdem mit »ssmtp://«; oder »ssmtps://«; beginnen, um anzuzeigen, dass SMTPS benutzt werden soll.

Falls SMTPS nicht angegeben wurde, wird bts weiterhin versuchen, STARTTLS zu verwenden, falls es vom SMTP-Server angezeigt wird.

Beachten Sie, dass $DEBEMAIL oder $EMAIL in der Umgebung gesetzt sein müssen, um direkte SMTP-Verbindungen zum Senden von E-Mails zu verwenden.

Beachten Sie, wenn Sie direkt über einen SMTP-Rechner senden, dass die Angabe von Adressen in --cc-addr oder BTS_DEFAULT_CC , für die der SMTP-Rechner keine Weiterleitung durchführt, dazu führt, dass der SMTP-Rechner die ganze E-Mail abweist.

Note also that the use of the reassign command may, when either --mutt or --force-interactive mode is enabled, lead to the automatic addition of a Cc to $newpackage@packages.debian.org. In these cases, the note above regarding relaying applies. The submission interface (port 587) on reportbug.debian.org does not support relaying and, as such, should not be used as an SMTP server for bts under the circumstances described in this paragraph.

--smtp-username= BENUTZERNAME , --smtp-password= PASSWORT

gibt die Anmeldedaten an, die benutzt werden, wenn eine Verbindung zu dem durch --smtp-host angegebenen SMTP-Server hergestellt wird. Falls der Server keine Authentifizierung verlangt, dann sollten diese Optionen nicht verwendet werden.

Falls ein Benutzername aber kein Passwort angegeben wurde, wird bts vor dem Senden der E-Mail nach dem Passwort fragen.

--smtp-helo= HELO

gibt den Namen an, der im Befehl HELO benutzt wird, wenn eine Verbindung zu dem SMTP-Server hergestellt wird; Vorgabe ist der Inhalt der Datei /etc/mailname, falls sie existiert.

Beachten Sie, dass einige STMP-Server die Benutzung eines HELO möglicherweise abweisen, die sie entweder nicht auflösen oder die nicht zum benutzenden Rechner gehören.

--bts-server

benutzt einen anderen Debbugs-Server als https://bugs.debian.org.

-f, --force-refresh

lädt einen Fehlerbericht erneut herunter, sogar dann, wenn er sich seit dem letzten cache-Befehl nicht geändert zu haben scheint; nützlich, falls ein --cache-mode=full zum ersten Mal angefragt wurde (andernfalls werden unveränderte Fehlerberichte nicht erneut heruntergeladen, nicht einmal, wenn die langweiligen Teile nicht heruntergeladen wurden.

--no-force-refresh

unterdrückt jegliche --force-refresh-Konfigurationsdateioptionen.

--only-new

lädt nur neue Fehler beim Zwischenspeichern herunter; prüft nicht, ob es in bereits vorhandenen Fehlern Aktualisierungen gibt.

--include-resolved

wenn Fehlerberichte zwischengespeichert werden, die einbeziehen, die als gelöst markiert sind. Dies ist das Standardverhalten.

--no-include-resolved

kehrt das Verhalten der vorherigen Option um. Sprich, Fehler, die als gelöst markiert sind, werden nicht zwischengespeichert.

--no-ack

unterdrückt Bestätigungs-E-Mails vom BTS. Beachten Sie, dass dies nur die CC-Kopien der Nachrichten beeinflusst, die Kopien für Fehler sind, die nicht an das Steuerungsprogramm gesandt wurden.

--ack

unterdrückt keine Bestätigungs-E-Mails. Dies ist das Standardverhalten.

-i, --interactive

zeigt vor dem Senden einer E-Mail an das Steuerungsprogramm den Inhalt an und ermöglicht, ihn zu bearbeiten oder das Versenden abzubrechen.

--force-interactive

ähnlich wie --interactive, mit der Ausnahme, dass sich ein Editor öffnet bevor nach der Bestätigung gefragt wird, ob die Nachricht versandt werden soll.

--no-interactive

sendet Steuerungs-E-Mails ohne Bestätigung. Dies ist das Standardverhalten.

-q, --quiet

zeigt, wenn bts cache ausgeführt wird, nur Informationen über neu zwischengespeicherte Seiten an, keine Nachrichten, die aussagen, was bereits zwischengespeichert ist. Falls diese Option zweimal angegeben wurde, werden nur Fehlermeldungen (an die Standardfehlerausgabe) ausgegeben.

--no-conf, --noconf

keine Konfigurationsdateien lesen, Dies kann nur als erste auf der Befehlszeile angegebene Option benutzt werden.

BEFEHLE

Sämtliche Einzelheiten über die Befehle finden Sie in der BTS-Dokumentation. <https://www.debian.org/Bugs/server-control>;
show [Optionen] [Fehlernummer | Paket | Paketbetreuer | : ] [Opt=Wert
…]
show [Optionen] [src:Paket | from:Absender] [Opt=Wert …]
show [Optionen] [tag:Markierung | usertag:Markierung ] [Opt=Wert …]
show [release-critical | release-critical/ … | RC ]

Dies ist ein Synonym für bts bugs.

bugs [Optionen] [Fehlernummer | Paket | Paketbetreuer | : ] [Opt=Wert
…]
bugs [Optionen] [src:Paket | from:Absender] [Opt=Wert …]
bugs [Optionen] [tag:Markierung | usertag:Markierung ] [Opt=Wert …]
bugs [release-critical | release-critical/ … | RC ]

zeigt die Seite, die die angefragten Fehler in einem Webbrowser auflistet, unter Benutzung von sensible-browser(1).

Optionen könnten nach dem Befehl bugs zusätzlich oder anstelle von Optionen am Anfang der Befehlszeile angegeben werden: An diesem Punkt erkannte Optionen sind: -o/--offline/--online, -m/--mbox, --mailreader und --[no-]cache. Diese wurden an früherer Stelle in dieser Handbuchseite beschrieben. Falls Sie entweder die Option -o oder --offline benutzt haben oder es bereits eine aktuelle Kopie des lokalen Zwischenspeichers gibt, wird die zwischengespeicherte Version benutzt.

Die möglichen Argumente haben folgende Bedeutung:

Fehlernummer

zeigt Fehler Nummer Fehlernummer.

src:Paket

zeigt die Fehler des Quellpakets Paket.

Paketbetreuer

zeigt die Fehler für die Paketbetreuer-E-Mail-Adresse Paketbetreuer

from:Absender

zeigt die Fehler für die Absender-E-Mail-Adresse Absender

tag:Markierung

zeigt die Fehler, die mit Markierung gekennzeichnet sind.

usertag:Markierung

zeigt die Fehler, die mit der Benutzermarkierung Markierung gekennzeichnet sind. Weitere Informationen über Benutzermarkierungen finden Sie in der BTS-Dokumentation. Dies wird die Verwendung der Option users=E-Mail erfordern.

release-critical, RC

zeigt die Einstiegssseite der release-kritischen Seiten des BTS. Dies ist ein Synonym für https://bugs.debian.org/release-critical/index.html. Es ist außerdem möglich, release-critical/debian/main.html und dergleichen zu sagen. RC ist ein Synonym für release-critical/other/all.html.

Nach dem Argument, das spezifiziert, was angezeigt wird, können Sie wahlweise Optionen angeben, um die Seite zu formatieren oder um zu ändern, was angezeigt wird. Diese werden in der heruntergeladenen URL an das BTS übergeben. Übergeben Sie zum Beispiel »dist=stable«, um Fehler zu sehen, die die stabile Version des Pakets beeinflussen, »version=1.0«, um Fehler zu sehen, die diese Version des Pakets beeinflussen oder »reverse=yes«, um die neuesten Nachrichten im Fehlerprotokoll zuerst zu sehen.

Falls Zwischenspeicherung aktiviert wurde (sprich --no-cache wurde nicht benutzt und BTS_CACHE wurde nicht auf no gesetzt), dann wird automatisch jede durch bts show angeforderte Seite zwischengespeichert und danach offline verfügbar sein. Seiten, die automatisch auf diese Weise zwischengespeichert wurden, werden bei nachfolgenden Aufrufen von »bts show|bugs|cache« gelöscht, falls nicht innerhalb von 30 Tagen darauf zugegriffen wurde. Warnung: Auf einem Dateisystem, das mit der Option »noatime« eingehängt wurde, aktualisiert die Ausführung von »bts show|bugs« nicht die Zugriffszeiten der Zwischenspeicherdateien; ein zwischengespeicherter Fehler wird dann Gegenstand der automatischen Bereinigung 30 Tage nach seinem anfänglichen Herunterladen, sogar dann, wenn auf ihn in der Zwischenzeit zugegriffen wurde.

Alle anderen bts-Befehle, die dieser Befehlszeile folgen, werden nach dem Beenden des Browsers ausgeführt.

Der gewünschte Browser kann durch Setzen der Umgebungsvariable BROWSER angegeben und konfiguriert werden. Die Konventionen folgen denen, die Eric Raymond auf http://www.catb.org/~esr/BROWSER/ definiert hat; hier wird der maßgebliche Teil wiedergegeben.

Der Wert von BROWSER kann aus einer Reihe von durch Doppelpunkt getrennten Browser-Befehlsteilen bestehen. Diese sollten nacheinander durchprobiert werden, bis einer erfolgreich ist. Jeder Befehlsteil kann optional die Zeichenkette %s enthalten; ist dies der Fall, wird die URL, die betrachtet werden soll, dort ersetzt. Falls der Befehlsteil kein %s enthält, wird der Browser gestartet, als ob die URL als sein erstes Argument bereitgestellt worden wäre. Die Zeichenkette %% muss durch ein einzelnes % ersetzt werden.

Begründung: Es muss möglich sein, mehrere Browser-Befehle anzugeben, damit Programme, die dieser Konvention folgen, in X- oder Konsolenumgebungen das Richtige tun können. Dabei wird X zuerst probiert. Die Angabe mehrerer Befehle kann außerdem für Leute nützlich sein, die Dateien wie .profile über mehrere Systeme hinweg gemeinsam benutzen. %s wird benötigt, da einige populäre Browser eine Aufrufsyntax aus der Ferne haben, die dies erfordern. Falls %% nicht auf % verkürzt würde, wäre es unmöglich, ein Buchstabensymbol %s in der Zeichenkette zu haben.

Auf den meisten Linux-Systemen wäre zum Beispiel Folgendes ein gute Sache:

BROWSER=’mozilla -raise -remote "openURL(%s,new-window)":links’

select [Schlüssel:Wert …]

benutzt die SOAP-Schnittstelle, um eine Liste von Fehlern auszugeben, die zu den gegebenen Auswahlanforderungen passen.

Die folgenden Schlüssel sind erlaubt und können mehrmals abgegeben werden.

maintainer

E-Mail-Adresse des Paketbetreuers

submitter

E-Mail-Adresse des Absenders

severity

Schweregrad des Fehlers

correspondent

Adresse von jemandem, der E-Mail an das Protokoll sandte

Um zum Beispiel die Sammlung von Fehlern auszuwählen, die von jrandomdeveloper [AT] example.com versandt und mit wontfix markiert würde, könnte Folgendes benutzt werden:

bts select submitter:jrandomdeveloper [AT] example.com tag:wontfix

Falls ein Schlüssel mehrfach benutzt wird, dann enthält die ausgewählte Fehlerzusammenstellung jene, die auf einen der bereitgestellten Werte passen, zum Beispiel gibt

bts select package:foo severity:wishlist severity:minor

alle Fehler des Pakets Foo zurück, die entweder den Schweregrad »wishlist« oder »minor« haben.

status [Fehler | file:Datei | fields:Feld[,Feld …] | verbose] …

benutzt die SOAP-Schnittstelle, um Informationen über die angegebenen Fehler auszugeben (oder die, die aus den aufgelisteten Dateien gelesen wurden – verwenden Sie -, um die Standardeingabe auszuwählen).

Standardmäßig werden alle ausgefüllten Felder für einen Fehler angezeigt.

Falls verbose angegeben ist, werden außerdem leere Felder angezeigt.

Falls fields angegeben ist, werden nur diese Felder angezeigt. Es wird keine Gültigkeitsprüfung für irgendwelche angegebenen Felder durchgeführt.

clone Fehler neue_Kennung [neue_Kennung …]

Der Steuerbefehl clone ermöglicht es Ihnen, einen Fehlerbericht zu kopieren. Das ist in dem Fall nützlich, in dem ein einziger Bericht tatsächlich anzeigt, dass mehrere eigenständige Fehler aufgetreten sind. »Neue Kennungen« sind durch Leerzeichen getrennte negative Zahlen, die in nachfolgenden Steuerbefehlen benutzt werden können, um auf die neu kopierten Fehler Bezug zu nehmen. Für jede neue Kennung wird ein neuer Fehler erzeugt.

done Fehler [Version]

markiert einen Fehler als erledigt. Dies erzwingt einen interaktiven Modus, da erledigt-Nachrichten eine Erklärung enthalten sollten, weshalb der Fehler geschlossen wird. Sie sollten angeben, welche Version des Pakets den Fehler schließt, falls möglich.

reopen Fehler [Absender]

öffnet einen Fehler mit optionalem Absender erneut.

archive Fehler

archiviert einen Fehler, der vorher archiviert war, es gegenwärtig aber nicht ist. Der Fehler muss alle Anforderungen für die Archivierung außer den zeitbasierten erfüllen.

unarchive Fehler

nimmt einen derzeit archivierten Fehler aus dem Archiv heraus.

retitle Fehler Titel

ändert den Titel des Fehlers.

summary Fehler [Nachrichtennummer]

wählt eine Nachrichtennummer, die als Zusammenfassung von Fehler benutzt werden soll.

Falls keine Nachrichtennummer angegeben ist, wird die Zusammenfassung geleert.

submitter Fehler [Fehler] … Absender-E-Mail-Adresse

ändert die Adresse des Einreichenden eines Fehlers oder einer Reihe von Fehlern. ! bedeutet »die Adresse der aktuellen E-Mail als neue Adresse des Einreichenden verwenden«.

reassign Fehler [Fehler …] Paket [Version]

weist einem Fehler oder einer Reihe von Fehlern einem anderen Paket zu. Das Feld Version ist optional; lesen Sie die Erklärung auf <https://www.debian.org/Bugs/server-control>;.

found Fehler [Version]

zeigt an, dass ein Fehler in einer bestimmten Paketversion gefunden wurde. Ohne Version wird die Liste reparierter Versionen bereinigt und der Fehler wird erneut geöffnet.

notfound Fehler Version

entfernt den Datensatz, mit dem Fehler in der gegebenen Version des Pakets, dem er zugewiesen ist, vorgefunden wurde.

fixed Fehler Version

zeigt an, dass ein Fehler in einer bestimmten Paketversion behoben wurde ohne den Offen-/Geschlossenstatus des Fehlers zu beeinflussen.

notfixed Fehler Version

entfernt den Datensatz mit dem ein Fehler in der gegebenen Version des Pakets, dem er zugewiesen ist, behoben wurde.

Dies ist gleichbedeutend mit der Abfolge der Befehle »found Fehler Version«, »notfound Fehler Version«.

block Fehler by|with Fehler [Fehler …]

weist darauf hin, dass ein Fehler von der Behebung durch einen Satz anderer Fehler blockiert ist.

unblock Fehler by|with Fehler [Fehler …]

weist darauf hin, dass ein Fehler nicht länger von der Behebung durch einen Satz anderer Fehler blockiert ist.

merge Fehler Fehler [Fehler …]

fügt einen Satz Fehler zusammen.

forcemerge Fehler Fehler [Fehler …]

fügt einen Satz Fehler mit Gewalt zusammen. Der erste aufgeführte Fehler ist der Hauptfehler und seine Einstellungen (diejenigen, die denen in einem normalen merge entsprechen müssen) werden den nachfolgend aufgeführten Fehlern zugewiesen.

unmerge Fehler

macht das Zusammenführen eines Fehlers rückgängig.

tag Fehler [+|-|=] Markierung [Markierung …]
tags Fehler [+|-|=] Markierung [Markierung …]

setzt oder entfernt eine Markierung für einen Fehler. Die Markierung kann entweder der exakte Markierungsname sein oder er kann auf eine eindeutige Teilzeichenkette abgekürzt werden. (Daher wird fixed beispielsweise die Markierung fixed, nicht fixed-upstream setzen, aber fix wäre nicht zulässig.) Mehrere Markierungen können ebenfalls angegeben werden. Die beiden Befehle (»tag« und »tags«) sind identisch. Wenn der Schalter = nicht benutzt wird, muss mindestens eine Markierung angegeben werden, wobei der Befehl

bts tags <Fehler> =

alle Markierungen vom angegebenen Fehler entfernen wird.

Das Hinzufügen/Entfernen der security-Markierung wird der Cc-Liste der Steuerungs-E-Mail »team\@security.debian.org« hinzufügen.

Die Liste gültiger Markierungen und ihre Bedeutung ist unter <https://www.debian.org/Bugs/Developer#tags>; verfügbar. Derzeit sind folgende Markierungen gültig:

patch, wontfix, moreinfo, unreproducible, fixed, help, security, upstream, pending, d-i, confirmed, ipv6, lfs, fixed-upstream, l10n, newcomer, a11y, ftbfs

Es gibt auch eine Markierung für jede Veröffentlichung von Debian seit »Potato«. Beachten Sie, dass diese Liste möglicherweise nicht aktuell ist, die aktuellste Quelle bietet die Website.

affects Fehler [+|-|=] Paket [Paket …]

zeigt an, dass ein Fehler ein anderes Paket betrifft, als das, gegen das er eingereicht wurde, was dazu führt, dass der Fehler standardmäßig in der Paketliste des anderen Pakets aufgeführt wird. Dies sollte üblicherweise benutzt werden, wo der Fehler ernst genug ist, um mehrere Berichte von Benutzern dem falschen Paket zuzuweisen. Es muss mindestens ein Paket angegeben werden, sogar, wenn der Schalter = benutzt wird, wobei der Befehl

bts affects <Fehler> =

alle Hinweise entfernt, dass Fehler andere Pakete beeinflusst.

user E-Mail-Adresse

gibt eine Benutzer-E-Mail-Adresse an, bevor der Befehl usertags verwendet wird.

usertag Fehler [+|-|=] Markierung [Markierung …]
usertags Fehler [+|-|=] Markierung [Markierung …]

setzt oder entfernt eine Benutzermarkierung für einen Fehler. Die Markierung muss exakt den gewünschten Markierungsnamen haben; es gibt dort keine Vorgaben oder Prüfungen von Markierungsnamen. Mehrere Markierungen können ebenfalls angegeben werden. Die beiden Befehle (usertag und usertags) sind identisch. Wenn der Schalter = nicht benutzt wird, muss mindestens eine Markierung angegeben werden, wobei der Befehl

bts usertags <Fehler> =

alle Benutzermarkierungen vom angegebenen Fehler entfernt.

claim Fehler [Anspruch]

zeichnet auf, dass Sie Anspruch auf einen Fehler erheben (z.B. für ein Fehlerbearbeitungstreffen, eine »Bug Squashing Party«). Anspruch sollte ein eindeutiges Kürzel sein, das es ermöglicht, die Fehler, auf die Sie Anspruch erheben, zu identifizieren; oft wird eine E-Mail-Adresse benutzt.

Falls kein Anspruch angegeben wurde, wird die Umgebungsvariable DEBEMAIL oder EMAIL (in dieser Reihenfolge geprüft) benutzt.

unclaim Fehler [Anspruch]

entfernt den Datensatz, mit dem Sie Anspruch auf einen Fehler erheben.

Falls kein Anspruch angegeben wurde, wird die Umgebungsvariable DEBEMAIL oder EMAIL (in dieser Reihenfolge geprüft) benutzt.

severity Fehler Schweregrad

ändert den Schweregrad eines Fehlers. Verfügbare Schweregrade sind: wishlist, minor, normal, important, serious, grave und critical. Der Schweregrad kann auf irgendeine eindeutige Teilzeichenkette abgekürzt werden.

forwarded Fehler Adresse

markiert den Fehler als an die angegebene Adresse weitergeleitet (üblicherweise eine E-Mail-Adresse oder eine URL für eine Fehlerdatenbank der Originalautoren).

notforwarded Fehler

markiert einen Fehler als nicht weitergeleitet.

package [Paket …]

Die folgenden Befehle werden nur auf Fehler gegen die aufgeführten Pakete angewendet; dies dient als Sicherheitsmechanismus für die Fehlerdatenbank. Falls keine Pakete aufgeführt sind, wird die Prüfung wieder ausgeschaltet.

limit [Schlüssel[:Wert]] …

Die folgenden Befehle werden nur auf Fehler angewendet, die dem angegebenen Kriterium entsprechen; dies dient als Sicherheitsmechanismus für die Fehlerdatenbank. Falls keine Werte aufgeführt sind, werden die Beschränkungen für diesen Schlüssel wieder ausgeschaltet. Falls keine Schlüssel angegeben wurden, werden alle Beschränkungen zurückgesetzt.
submitter

E-Mail-Adresse des Absenders

severity

Schweregrad des Fehlers

Um zum Beispiel die Zusammenstellung von Fehlern, die von nachfolgenden Steuerbefehlen beeinflusst werden, auf diejenigen zu beschränken, die von jrandomdeveloper [AT] example.com versandt und mit wontfix markiert wurden, könnte Folgendes verwendet werden:

bts limit submitter:jrandomdeveloper [AT] example.com tag:wontfix

Falls ein Schlüssel mehrfach benutzt wird, dann enthält die ausgewählte Fehlerzusammenstellung jene, die auf einen der bereitgestellten Werte passen, zum Beispiel gibt

bts limit package:foo severity:wishlist severity:minor

wird nur auf nachfolgende Steuerbefehle für Fehler des Pakets Foo angewendet, die entweder den Schweregrad wishlist oder minor aufweisen.

owner Fehler Besitzer-E-Mail-Adresse

ändert die »Besitzer«-Adresse eines Fehlers, wobei ! »benutze die Adresse der aktuellen E-Mail als neue Besitzeradresse« bedeutet.

Der Besitzer eines Fehlers akzeptiert die Verantwortung, ihn zu erledigen.

noowner Fehler

markiert, dass ein Fehler keinen »Besitzer« hat.

subscribe Fehler [E-Mail]

abonniert die gegebene E-Mail-Adresse für den angegebenen Fehler. Falls keine E-Mail-Adresse angegeben wurde, wird die Umgebungsvariable DEBEMAIL oder EMAIL (in dieser Reihenfolge) benutzt. Falls diese nicht gesetzt sind oder ! als E-Mail-Adresse angegeben ist, wird Ihre Standard-E-Mail-Adresse verwendet.

Nach der Ausführung dieses Befehls wird ihnen eine Abonnement-Bestätigung gesandt, auf die Sie antworten müssen. Wenn Sie einen Fehlerbericht abonniert haben, erhalten Sie alle relevanten E-Mails und Benachrichtigungen, Benutzen Sie den Befehl unsubscribe, um das Abonnement zu beenden.

unsubscribe Fehler [E-Mail]

beendet das Abonnement der angegebenen E-Mail-Adresse für den angegebenen Fehlerbericht. Wie beim vorhergehenden Abonnieren werden, falls keine E-Mail-Adresse angegeben wurde, die Umgebungsvariablen DEBEMAIL oder EMAIL (in dieser Reihenfolge) benutzt. Falls diese nicht gesetzt sind oder ! als E-Mail-Adresse angegeben ist, wird Ihre Standard-E-Mail-Adresse verwendet.

Nach der Ausführung dieses Befehls wird Ihnen eine Bestätigung für das Beenden des Abonnements gesandt, auf die Sie antworten müssen. Benutzen Sie zum Abonnieren den Befehl subscribe.

reportspam Fehler …

Der Befehl reportspam ermöglicht es Ihnen, zu melden, dass ein Fehlerbericht Spam enthält. Er bewahrt davor, auf die Fehler-Website gehen zu müssen, um dies zu tun.

spamreport Fehler …

spamreport ist ein Synonym für reportspam.

cache [Optionen] [Betreuer-E-Mail-Adresse | Paket | src:Paket |
from:Absender]
cache [Optionen] [release-critical | release-critical/ … | RC ]

erzeugt oder aktualisiert einen Zwischenspeicher von Fehlerberichten für die angegebene E-Mail-Adresse oder das gegebene Paket. Standardmäßig lädt es alle Fehler herunter, die zu der E-Mail-Adresse in der Umgebungsvariable DEBEMAIL gehören (oder der Umgebungsvariable EMAIL , falls DEBEMAIL nicht gesetzt ist). Dieser Befehl kann wiederholt werden, um Fehler zwischenzuspeichern, die zu mehreren Personen oder Paketen gehören. Falls mehrere Pakete oder Adressen mitgegeben werden, werden Fehler zwischengespeichert, die zu allen Argumenten gehören; diejenigen, die zu mehr als einem Argument gehören, werden nur einmal heruntergeladen. Die zwischengespeicherten Fehler werden in $XDG_CACHE_HOME/devscripts/bts/ gespeichert oder, falls XDG_CACHE_HOME nicht gesetzt ist, in ~/.cache/devscripts/bts/.

Sie können die zwischengespeicherten Fehler mit dem Schalter -o verwenden. Zum Beispiel:

bts -o bugs
bts -o show 12345

Außerdem wird bts die Dateien darin auf unsystematische Weise aktualisieren, da es Informationen von der Fehlerdatenbank unter Benutzung des Befehls show herunterlädt. Sie könnten daher den Zwischenspeicher einrichten, indem Sie die automatischen Zwischenspeicheraktualisierungen die Fehler aktualisieren lassen, auf die Sie häufig während der Woche Bezug nehmen.

Einige Optionen beeinflussen das Verhalten des Befehls cache. Die erste ist die Einstellung von --cache-mode, die steuert, wieviel bts von den referenzierten Verweisen von der Fehlerseite herunterlädt, einschließlich langweiliger Teile, wie den Bestätigungs-E-Mails, E-Mails an den Steuer-Bot und der Mbox-Version des Fehlerberichts. Sie kann drei Werte annehmen: min (das Minimum), mbox (das Minimum plus der Mbox-Version des Fehlerberichts herunterladen) oder full (alles). Die zweite ist --force-refresh oder -f. Sie erzwingt das Herunterladen sogar dann, wenn der zwischengespeicherte Fehler aktuell ist. Die Option --include-resolved zeigt an, ob Fehlerberichte, die als behoben markiert sind, während des Zwischenspeicherns heruntergeladen werden sollen.

Jedes davon ist, wie nachfolgend beschrieben, in der Konfigurationsdatei einstellbar. Dies könnte außerdem nach dem Befehl cache, ebenso wie am Anfang der Befehlszeile angegeben werden.

Schlussendlich wird -q oder --quiet Nachrichten darüber, ob der Zwischenspeicher aktuell ist, unterdrücken. Wird diese Option zweimal angegeben, werden alle Zwischenspeichernachrichten (mit Ausnahme von Fehlermeldungen) unterdrückt.

Vorsicht allerdings beim Zwischenspeichern von RC-Fehlern: Es wird LANGE dauern! (Mit über 1000 RC-Fehlern und einer Verzögerung von fünf Sekunden zwischen Fehlern, sehen Sie sich mindestens 1,5 Stunden und wahrscheinlich bedeutend mehr als dem gegenüber.)

cleancache Paket | src:Paket | Paketbetreuer
cleancache from:Absender | tag:Markierung | usertag:Markierung | Zahl |
ALL

bereinigt den Zwischenspeicher für das angegebene Paket, den Paketbetreuer. etc., wie oben für den Befehl bugs beschrieben oder bereinigt den kompletten Zwischenspeicher, falls ALL angegeben wurde. Dies ist nützlich, falls Sie einen permanenten Netzwerkzugang haben oder falls Ihre Datenbank aus irgend einem Grund beschädigt wurde. Beachten Sie, dass dieser Befehl aus Sicherheitsgründen nicht standardmäßig den Wert DEBEMAIL oder EMAIL hat.

listcachedbugs [Zahl]

listet zwischengespeicherte Fehlerkennungen auf (für die Unterstützung der Bash-Vervollständigung gedacht). Das optionale Argument »Zahl« beschränkt die Liste auf jene Fehlerkennungen, die mit dieser Zahl beginnen.

version

zeigt Version und Copyright-Information an.

help

zeigt eine kurze Zusammenfassung der Befehle, verdächtig ähnlich zu Teilen dieser Handbuchseite.

UMGEBUNGSVARIABLEN

DEBEMAIL

Falls diese gesetzt ist, wird die Von:-Zeile in der E-Mail gesetzt, um diese E-Mail-Adresse anstelle Ihrer normalen E-Mail-Adresse zu benutzen (als wäre sie durch mail festgelegt).

DEBFULLNAME

Falls DEBEMAIL gesetzt ist, wird DEBFULLNAME geprüft, um den vollständigen Namen, der verwendet wird, zu bestimmen; falls dies nicht gesetzt ist, versucht bts einen Namen von Ihrem passwd-Eintrag zu bestimmen.

BROWSER

Falls gesetzt, gibt es den Browser an, der für die Optionen show und bugs verwendet wird. Lesen Sie die vorhergehende Beschreibung.

KONFIGURATIONSVARIABLEN

Die beiden Konfigurationsdateien /etc/devscripts.conf und ~/.devscripts werden in dieser Reihenfolge durch eine Shell eingelesen, um Konfigurationsvariablen zu setzen. Befehlszeilenoptionen können benutzt werden, um Einstellungen aus Konfigurationsdateien außer Kraft zu setzen. Einstellungen aus Umgebungsvariablen werden zu diesem Zweck ignoriert. Die derzeit bekannten Variablen sind:
BTS_OFFLINE

Falls dies auf yes gesetzt ist, dann ist es genauso, als wenn der Befehlszeilenparameter --offline benutzt würde. Es hat nur Auswirkungen auf die Befehle show und bugs. Vorgabe ist no. Weitere Informationen finden Sie in der vorhergehenden Beschreibung des Befehls show.

BTS_CACHE

Falls dies auf no gesetzt ist, dann ist es genauso, als wenn der Befehlszeilenparameter --no-cache benutzt würde. Es hat nur Auswirkungen auf die Befehle show und bug. Vorgabe ist yes. Weitere Informationen finden Sie wieder beim Befehl show weiter oben.

BTS_CACHE_MODE={min,mbox,full}

Wieviel von der Fehlerdatenbank sollte gespiegelt werden, wenn danach gefragt wird, etwas zwischenzuspeichern? Nur das Minimum oder auch die Mbox oder das Ganze? Vorgabe ist min, was die gleiche Bedeutung hat wie der Befehlszeilenparameter --cache-mode. Dies hat nur Auswirkungen auf den Zwischenspeicher. Weitere Informationen finden Sie beim Befehl cache.

BTS_FORCE_REFRESH

Falls dies auf yes gesetzt ist, dann ist es genauso, als wenn der Befehlszeilenparameter --force-refresh benutzt würde. Es hat nur Auswirkungen auf den Befehl cache. Vorgabe ist no. Weitere Informationen finden Sie beim Befehl cache.

BTS_MAIL_READER

Falls dies gesetzt ist, gibt es ein E-Mail-Programm an, der anstelle von mutt benutzt wird. Entspricht der Befehlszeilenoption --mailreader.

BTS_SENDMAIL_COMMAND

Falls dies gesetzt ist, gibt es einen sendmail-Befehl an, der anstelle von /usr/sbin/sendmail verwendet wird. Entspricht der Befehlszeilenoption --sendmail.

BTS_ONLY_NEW

lädt beim Zwischenspeichern nur neue Fehler herunter; prüft nicht auf Aktualisierungen in Fehlern, die bereits vorliegen. Vorgabe ist no. Entspricht der Befehlszeilenoption --only-new.

BTS_SMTP_HOST

Falls dies gesetzt ist, gibt es einen SMTP-Host an, der für den Versand von E-Mail gegenüber dem Befehl sendmail den Vorzug bekommt. Entspricht der Befehlszeilenoption --smtp-host.

Beachten Sie, dass diese Option eine höhere Priorität hat als BTS_SENDMAIL_COMMAND , falls beide gesetzt sind, außer wenn die Option --sendmail verwendet wird.

BTS_SMTP_AUTH_USERNAME , BTS_SMTP_AUTH_PASSWORD

Falls diese Optionen gesetzt sind, ist es, als ob die Optionen --smtp-username und --smtp-password benutzt würden.

BTS_SMTP_HELO

entspricht der Befehlszeilenoption --smtp-helo.

BTS_INCLUDE_RESOLVED

Falls dies auf no gesetzt ist, ist es, als ob der Befehlszeilenparameter --no-include-resolved benutzt würde. Es hat nur Auswirkungen auf den Befehl cache. Vorgabe ist yes. Weitere Informationen finden Sie beim Befehl cache.

BTS_SUPPRESS_ACKS

Falls dies auf yes gesetzt ist, dann ist es, als ob der Befehlszeilenparameter --no-ack benutzt würde. Vorgabe ist no.

BTS_INTERACTIVE

Falls dies auf yes oder force gesetzt ist, dann ist es, als ob die Befehlszeilenparameter --interactive oder --force-interactive benutzt würden. Vorgabe ist no.

BTS_DEFAULT_CC

gibt eine Liste von E-Mail-Adressen an, an die eine Kopie der erzeugten E-Mail an den Steuer-Bot automatisch gesandt werden sollte.

BTS_SERVER

gibt den Namen des Debbugs-Servers an, der anstelle von https://bugs.debian.org benutzt werden soll.

SIEHE AUCH

Bitte lesen Sie <https://www.debian.org/Bugs/server-control>;, um weitere Einzelheiten zu erhalten, wie die Fehlerdatenbank unter Benutzung von E-Mails gesteuert wird und <https://www.debian.org/Bugs/>;, um weitere Informationen über die Fehlerdatenbank zu erhalten.

pts-subscribe(1), querybts(1), reportbug(1), devscripts.conf(5)

COPYRIGHT

Dieses Programm unterliegt dem Copyright (C) 2001-2003 von Joey Hess <joeyh [AT] debian.org>. Es wurden viele Änderungen vorgenommen unter dem Copyright (C) 2002-2005 von Julian Gilbey <jdg [AT] debian.org> und dem Copyright (C) 2007 von Josh Triplett <josh [AT] freedesktop.org>.

Es ist lizensiert unter den Bedingungen der GPL, entweder Version 2 der Lizenz oder (nach Ihrer Wahl) irgendeiner späteren Version.