Sólo request@bugs.debian.org permite la obtención de datos y documentación de fallos por correo electrónico, control@bugs.debian.org permite manipular informes de fallos de varias maneras.
El servidor de control funciona de la misma manera que el de peticiones («request»); en realidad, son el mismo programa. Sencillamente, las dso direcciones están separadas para evitar errores de los usuarios y que puedan causar problemas cuando sólo quieran obtener información.
Se envía una notificación al mantenedor del paquete o paquetes al que están asignados los fallos, ya que las órdenes específicas al servidor de control cambian el estado de un fallo. Además, se registran el mensaje enviado al servidor y los cambios realizados y están disponibles en las páginas web.
Si desea obtener detalles de operación básica de los servidores de
correo y las órdenes comunes, lea por favor la
página Cómo pedir informes de
fallo por correo disponible en Internet, en el fichero
bug-log-mailserver.txt, o envíe help a
cualquiera de los servidores de correo.
La tarjeta de referencia de los
servidores de correo está disponible mediante WWW, en
bug-mailserver-refcard.txt o mediante correo electrónico
usando la orden refcard.
| General | Versionado | Duplicados | Varios |
reassign numerofallo
paquete [ versión ]Registra que el fallo #númerodefallo pertenece al paquete. Puede usarse para establecer el paquete si el usuario lo olvidó en la pseudocabecera, o para cambiar una asignación previa. No se enviarán notificaciones a nadie (excepto la información normal en la transcripción del proceso).
Si proporciona una versión, el sistema de seguimiento de fallos notará que el fallo afecta a esa versión del nuevo paquete asignado.
Puede asignar un fallo a dos paquetes a la vez separando los nombres de los paquetes con una coma. Sin embargo, sólo debería hacerlo si el fallo se puede arreglar mediante un cambio en cualquiera de ellos. Si no es este el caso, debería clonar el fallo y reasignar el clon al otro paquete.
reopen numerofallo
[ dirección_del_originador | = | ! ]Reabre el #númerodefallo en caso de que estuviera cerrado.
Por defecto, o si específica =, se mantendrá el informador
original del fallo tal cual, de manera que obtendrá una notificación
cuando vuelva a ser cerrado.
Si proporciona una dirección del descubridor entonces se
cambiará la dirección de correo del informador del fallo por esta otra. Si
desea ser el nuevo informador del informe reabierto, puede usar el atajo
! o especificar su propia dirección de correo.
Suele ser buena idea decirle a la persona que va a ser registrada como descubridor que está usted reabriendo el informe, de manera que sepa que recibirá una notificación cuando vuelva a ser cerrado.
Si el fallo no está cerrado, reabrirlo no hará nada, siquiera
cambiar quién envió el fallo. Para cambiar esto de un informe de fallo
abierto, use la orden submitter; percátese de que esto informará
a la persona que envió el fallo en primer lugar del cambio.
Si el fallo se registró como que había sido cerrado en una versión
particular de un paquete pero reapareció en una versión posterior, es mejor
usar la orden found en su lugar.
found númerodefallo [
versión ]Registra que #númerodefallo se ha encontrado en la versión dada en versión del paquete al que se asignó.
El sistema de seguimiento de fallos utiliza esta información, junto con los registros de las versiones arregladas al cerrar los fallos, para mostrar listas de fallos abiertos en varias versiones de cada paquete. Considera que un fallo está abierto cuando no tiene versión arreglada, o cuando se ha encontrado más recientemente de lo que ha sido arreglado.
Si no se da una versión, entonces la lista de versiones
arregladas para el fallo se limpia. Este comportamiento es idéntico al de
reopen.
Esta orden sólo hará que un fallo como no arreglado si no se especifica una
versión, o si la version que está marcada es igual a la
version que es la última márcada como arreglada. (Si está
seguro de que quiere marcar el fallo como no arreglado,
use reopen junto a found.)
Esta orden se introdujo, prefiriéndose a reopen,
porque era difícil añadir una versión a esa sintaxis de órdenes
sin sufrir ambigüedad.
notfound númerodefallo
versiónBorra el registro de #númerodefallo que se encontró en la versión dada del paquete al que está asignado.
Esto difiere de cerrar el fallo en esa versión en que no se lista como arreglado en versión alguna; no se conocerá información sobre esa versión. Se pretende que sea para guardar en el registro cuándo se encontró un fallo.
fixed númerodefallo
versiónIndica que el fallo #númerodefallo se arregló en la versión dada del paquete al que está asignado.
Esto no hace que se marque el fallo como cerrado, simplemente añade otra versión en la que el fallo está arreglado. use la dirección númerodefallo-done para cerrar un fallo y marcarlo como arreglado en una versión particular.
notfixed númerodefallo
versiónElimina el registro de que el fallo #númerodefallo está arreglado en la versión versión.
Esta orden es equivalente a found seguida de
notfound (el «found» elimina el arreglo en una versión
particular, y el «notfound» elimina el «found».
submitter númerodefallo
dirección_del_originador | !Cambia el informador del fallo #número a dirección del informador.
Si desea ser la nueva persona origen del fallo, puede usar la
abreviatura ! o especificar su propia dirección de correo.
Mientras la orden reopen cambia también el origen de otros
fallos fusionados con el que se está reabriendo, la orden submitter
no afecta a los fallos fusionados.
forwarded númerodefallo
dirección
notforwarded
númerodefalloretitle númerodefallo nuevo título
Cambia el título del informe de fallo por el que se específica (por
defecto se toma la cabecera Asunto) del mensaje original).
Al contrario que la mayoría de las otras órdenes de manipulación de fallos, cuando se usa en un conjunto de mensajes fusionados, sólo cambiará el título del número de fallo solicitado, y no el de aquellos con los que fue fusionado (merged).
severity númerodefallo gravedadEstablece el nivel de gravedad del informe de fallo que informó de él.
Las posibles gravedades son critical, grave,
serious, important, normal,
minor, and wishlist.
Si desea saber sus significados, sírvase consultar la documentación general para desarrolladores sobre el sistema de fallos.
clone númerodefallo nuevoID [ nuevosIDs ... ]
La orden de control clone le permite duplicar un informe. Es útil en
caso de que un mismo informe indique realmente que han ocurrido varios
fallos diferentes. NuevosIDs
son números negativos,
separados por espacios, que se usarán en órdenes de control subsecuentes
para referirse a los informes recién duplicados. Se genera un nuevo
informe por cada nuevo ID.
Ejemplo de uso:
clone 12345 -1 -2
reassign -1 foo
retitle -1 foo: foo apesta
reassign -2 bar
retitle -2 bar: bar apesta cuando se usa con foo
severity -2 wishlist
clone 123456 -3
reassign -3 foo
retitle -3 foo: foo apesta
merge -1 -3
merge númerodefallo númerodefallo ...Fusiona dos o más informes de fallo. Cuando se fusionan informes, las operaciones de apertura apertura y cierre; marcado y desmarcado como reenviados; y la reasignación de cualquiera de los informes a un nuevo paquete, tendrán un efecto idéntico en el resto de los informes fusionados.
Antes de que se puedan fusionar mensajes, deben encontrarse
exactamente en el mismo estado: todos abiertos, o todos cerrados; indicando
la misma dirección de reenvío al autor original, o sin marcar; todos
asignados al mismo paquete o paquetes (se realiza una comparación exacta
sobre el nombre del paquete al que se asignó el fallo), y todos de la
gravedad. Si no comienzan en el mismo estado, debería usar
reassign (reasignar), reopen (reabrir), etc., para asegurarse de
que lo están antes usar merge (fusionar). No es necesario
que coincidan los títulos ya que no afectará a la fusión.
Tampoco es necesario que coincidan las etiquetas ya que se unirán éstas.
Si cualquiera de los informes listados en una orden merge
ya se encuentra fusionado con otro fallo, entonces todos los informes
fusionados con cualquiera de los indicados entrará en la fusión. La fusión
es como la igualdad: es reflexiva, transitiva y simétrica.
Fusionar informes hace que aparezca una nota en cada uno de ellos; en la página web se reflejan como enlaces a los otros.
Los informes fusionados expiran todos a la vez, y sólo cuando todos y cada uno, por se parado, cumplan el criterio de expiración.
forcemerge númerodefallo númerodefallo ...Fusiona a la fuerza dos o más informes de fallos. El primer fallo listado es el maestro, y se le asignan sus parámetros (los parámetros que deben ser iguales en una fusión normal) a los siguientes fallos en la lista. Para evitar fusionar fallos por erratas al escribir, los fallos deben estar en el mismo paquete. Mire un poco más arriba en el texto si desea una descripción de lo que significa fusionar.
Dese cuenta que esto hace posible cerrar fallos fusionándolos; Es usted responsable de avisar a los remitentes con un mensaje de cierre apropiado si lo hace.
unmerge númerodefalloDesconecta un informe de fallo de cualquier otro informe con el que esté fusionado. El resto de los paquetes con los que estuviera fusionado quedan unidos; sólo se elimina su asociación con el informe indicado explícitamente.
Si tiene muchos informes fusionados y desea separarlos en dos grupos, deberá separar cada uno de los mensajes que quiera poner en otro grupo, para luego fusionarlos en el nuevo grupo que se desea.
Sólo puede separar un informe con cada orden unmerge. Si
desea desconectar más de un informe, no tiene más que incluir varias
órdenes unmerge en su mensaje.
tags númerodefallo [ + | - | = ] etiqueta [ etiqueta ...]
Añade a las etiquetas del informe de fallo
enviará notificación alguna al usuario que informó del fallo.
Si la acción es + se añade, si la acción es -
se sustrae y si es = se
indica que se han de ignorar las etiquetas que hayan
en este momento, y que se deben fijar los valores que se indican en ese momento.
La acción en su defecto es añadir.
Ejemplo de uso:
# lo mismo que 'tags 123456 + patch'
tags 123456 patch
# lo mismo que 'tags 123456 + help security'
tags 123456 help security
# añadir las etiquetas 'fixed' y 'pending'
tags 123456 + fixed pending
# eliminar la etiqueta 'unreproducible'
tags 123456 - unreproducible
# fijar las etiquetas a 'moreinfo'y 'unreproducible'
tags 123456 = moreinfo unreproducible
Entre las etiquetas disponibles en este momento se incluyen
patch, wontfix, moreinfo,
unreproducible, help, pending,
fixed, fixed-in-experimental,
fixed-upstream, security, upstream,
confirmed, d-i, ipv6,
lfs, l10n, potato, woody,
sarge, sarge-ignore, etch,
etch-ignore, sid y experimental.
Consulte la documentación general para desarrolladores sobre el sistema de fallos si desea conocer sus significados.
block númerodefallo by fallo ...unblock númerodefallo by fallo ...close númerodefallo [ versión arreglada ]
(obsoleto)Cierra el informe de fallo #númerodefallo.
Se envía una notificación al usuario que informó del fallo, pero (en
contraste a enviar númerodefallo-done@bugs.debian.org)
no se incluirá en la notificación el texto del mensaje que causó
el cierre del fallo. El mantenedor que cierra el fallo debería asegurarse,
probablemente enviando un mensaje aparte, de que el usuario que informó
del fallo sabe por qué ha sido cerrado.
Por tanto, el uso de esta orden es obsoleto.
Consulte la información dirigida a mantenedores para ver
cómo cerrar un fallo correctamente.
Si proporciona una versión arreglada, el sistema de seguimiento de fallos se dará cuenta de que el fallo se arregló en esa versión del paquete.
package [ nombredelpaquete ... ]Limita las órdenes siguientes para que sólo se apliquen a los fallos registrados sobre los paquetes indicados. Puede listar uno o más paquetes. Si no indica ninguno, las órdenes siguientes se aplicarán a todos los fallos. Se le anima a usar esta orden como medida de seguridad para el caso en que use accidentalmente números de fallo erróneos.
Ejemplo de uso:
package foo
reassign 123456 bar 1.0-1
package bar
retitle 123456 bar: bar apesta
severity 123456 normal
package
severity 234567 wishlist
owner númerodefallo dirección | !Hace que dirección sea el «dueño» de #númerodefallo. El dueño de un fallo se hace responsable de arreglarlo. Esto es útil para compartir trabajo en caso de que un paquete tenga un equipo de mantenedores.
Si desea convertirse en el dueño de un fallo, puede usar el atajo
! o especificar su propia dirección de correo.
noowner númerodefalloarchive númerodefallounarchive númerodefallo#...# debe estar al inicio
de la línea. El texto de los comentarios será incluido en los créditos
enviados al emisor y a los mantenedores afectados, para que así pueda
utilizarlo para documentar las razones de sus órdenes.quitstopthankthanksthankyouthank you--Otras páginas del Sistema de seguimiento de fallos (BTS en inglés):
Debian bug tracking system
Copyright © 1999 Darren O. Benham, 1997, 2003 nCipher Corporation Ltd,
1994-1997 Ian Jackson.